[MacPorts] #35943: alps: update to 2.1.1_1

[MacPorts]

#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