#49903: libcxx: undo changes to system directories when deactivating ---------------------------+------------------------ Reporter: ryandesign@… | Owner: jeremyhu@… Type: enhancement | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.3.4 Resolution: | Keywords: Port: libcxx | ---------------------------+------------------------ Comment (by jeremyhu@…): Replying to [comment:6 ryandesign@…]:
Replying to [comment:5 jeremyhu@…]:
Replying to [comment:4 ryandesign@…]:
I'm not concerned about the disk space; I'm concerned about unregistered components being left on the user's system which might have an effect on it. For example, software like aria2 that checks for libc++ would find it and would build against it.
Shouldn't aria2 be honoring configure.cxx_stdlib?
aria2 requires C++11, so it requires libc++. Its configure script looks for libc++ and uses it if found; otherwise, it displays an error. My intention is to set "configure.cxx_stdlib libc++" to indicate this; to include the cxx11 1.0 portgroup; and to modify the cxx11 1.0 portgroup so that when configure.cxx_stdlib is set to libc++ on darwin 9 or 10, a dependency on port:libcxx is added.
In the llvm ports, we're just doing that unconditionally.
I'm looking for a solution that also works on the buildbot buildslaves, where builds happen automatically and nobody is reading instructions. I don't want the installation of one port that declares a dependency on libcxx (as I propose to do for aria2 via a modification to the libcxx portgroup) to cause libc++ to be permanently available on the Snow Leopard build slave and potentially cause other ports built on that build slave to build differently in the future.
Wouldn't that then be a bug in those other ports for not honoring configure.cxx_stdlib?
Yes, in the same way that it is a bug when ports have undeclared dependencies on optional software, but we developed trace mode to counteract that, and until trace mode can be enabled, the buildbot buildslaves are configured so that all ports are deactivated before any port build is attempted, so that such bugs do not affect the automated builds; the behavior of the libcxx port seems like it would invite problems. For example it might be the case that a build on the Snow Leopard builder would succeed, because the software in question included code in its build system to check for and use libc++ if present; that same port would fail to run on user systems unless they had also installed port:libcxx. Or, for users not using binaries, the port would fail to build.
Yes, I agree that is a problem, I'm just cautious about trying to address it. I'll have to be extra diligent in testing this change. -- Ticket URL: <https://trac.macports.org/ticket/49903#comment:7> MacPorts <https://www.macports.org/> Ports system for OS X