[MacPorts] #55382: cmake @3.10.0: Cannot find a C++ compiler supporting C++11 on this system

[MacPorts]

#55382: cmake @3.10.0: Cannot find a C++ compiler supporting C++11 on this system
-------------------------+-------------------------------------------------
  Reporter:  ryandesign  |      Owner:  michaelld
      Type:  defect      |     Status:  new
  Priority:  High        |  Milestone:
 Component:  ports       |    Version:
Resolution:              |   Keywords:  tiger leopard snowleopard lion
      Port:  cmake       |  mountainlion
-------------------------+-------------------------------------------------

Comment (by ryandesign):

 Not circular dependency; activation conflict.

 ''If'' you're proposing that cmake should depend on clang-X.Y (where X.Y
 is 3.8 or greater), and you're proposing that clang-X.Y should depend on
 cmake39 as a bootstrapping measure, then here's what will happen:

 * User requests to install cmake deliberately, or requests to install a
 port that depends on `path:bin/cmake:cmake`
 * MacPorts installs cmake39
 * MacPorts uses cmake39 to build llvm-X.Y and clang-X.Y
 * MacPorts builds cmake using clang-X.Y
 * cmake fails to activate because it wants to install files that are
 already installed by cmake39

 This could potentially be worked around using the deactivate hack in the
 cmake port, but that feels fragile. For example, what happens if the user
 requests to install a port that depends on `path:bin/cmake:cmake`, and the
 process is interrupted after cmake39 is installed but before cmake is
 installed—either due to an error that can be resolved, or just because the
 user pressed `^C`? When the user tries again, /opt/local/bin/cmake will
 already be there from the cmake39 port and the user will from then on
 forever use the cmake39 port instead of the cmake port. If that's an
 acceptable outcome, why not just always offer cmake 3.9.6 to those systems
 (using a conditional in the cmake port) like I suggested?

 If we want to offer cmake 3.10 and later to libstdc++ systems—and I agree
 it would be best to do so if we can without too much grief for both us and
 the user—then having a cmake bootstrap port install cmake 3.9.6 to a
 different private location to avoid activation conflicts would be less
 error-prone.

 But I'm still not clear whether we need a cmake 3.9.6 bootstrap port at
 all. Can't cmake 3.10+ just build using clang-3.7, which does not depend
 on cmake, as Ken suggested in comment:1? cmake is only a program, not a
 library, so nothing will be linking with it; and as far as I can tell, of
 cmake's dependencies, only the ncurses port contains a library that uses
 C++, and cmake only links with libncurses, not libncurses++; so it should
 be fine to force cmake to use libc++ on older systems, just like I do for
 mongodb for the same reasons ([06570abb7bb41aaf8058fbad159163374a8ed61c
 /macports-ports], [7339137c4e501aa383516859235fa3fb17906332/macports-
 ports]).

 I'm not sure if we can use libc++ on Tiger and Leopard. I see that the
 current cmake 3.10.0 port built just fine on 10.5 PPC with gcc6. We could
 do the same on 10.5 Intel and 10.4. The cxx11-1.1 portgroup currently uses
 gcc6 only on PowerPC. Maybe it should be changed to use gcc6 on 10.5 and
 earlier regardless of arch.

--
Ticket URL: <https://trac.macports.org/ticket/55382#comment:26>
MacPorts <https://www.macports.org/>
Ports system for macOS