[MacPorts] #49903: libcxx: undo changes to system directories when deactivating

[MacPorts]

#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