#35943: alps: update to 2.1.1_1 --------------------------------+------------------------------------------- Reporter: gamperl@… | Owner: macports-tickets@… Type: defect | Status: closed Priority: Normal | Milestone: Component: ports | Version: Resolution: fixed | Keywords: haspatch maintainer Port: alps | --------------------------------+------------------------------------------- Changes (by ryandesign@…): * cc: ryandesign@… (added) * keywords: => haspatch maintainer * status: new => closed * resolution: => fixed Comment: Thanks. I committed it in r97566 with some changes. The line "conflicts boost" was not correct. The conflicts keyword is for activation-time conflicts, i.e. ports that install the same files. That's not the case with alps and boost; rather, alps includes its own internal copy of an older version of boost and it fails to build if the newer boost port is active. We don't have a built-in keyword for modeling build-time conflicts, but there is a block that I had been pasting into ports to handle this. Rather than pasting that whole block into alps as well, in r97494 I turned this block into a portgroup that provides a "conflicts_build" keyword so that it is easier to use. The configure args "-DCMAKE_CXX_COMPILER=g++ -DCMAKE_C_COMPILER=gcc" aren't correct; they override the CC and CXX environment variables that MacPorts automatically sets during the configure phase and make it so that alps is not UsingTheRightCompiler. When I remove these lines, the port fails to build with this message: {{{ alps/applications/dmrg/dmrg/dmrg.h:610:49: error: expected expression std::string name = simplify_name(it->get<1>()); ^ }}} This suggests to me that this part of the build process is not compatible with the clang compiler. The correct solution then is to add the line "compiler.blacklist clang" so that MacPorts will choose the next-best compiler instead, which is llvm-gcc (which is what "gcc" is a symlink to anyway, in current Xcode versions). This appears to only be necessary inside the +applications variant. For the new python variants, rather than duplicating the patchfile multiple times (which would make unnecessary extra effort when updating the port in the future), I retained the single patchfile and just used a reinplace to put the right python version into it. I disabled the universal variant because both openmpi and py-scipy do not have universal variants. Ideally the universal variant should remain enabled in the case that the user deselects the python and openmpi variants, but I couldn't find a way to do that. Your patch added the line "livecheck.type none" and I included that in the commit, but why did you add this line? Has alps been discontinued / are no new releases of alps expected to be made by its developers? Or do we just need to find the right livecheck.regex to properly detect them? -- Ticket URL: <https://trac.macports.org/ticket/35943#comment:1> MacPorts <http://www.macports.org/> Ports system for Mac OS