[MacPorts] #26466: finer control of boost

[MacPorts]

#26466: finer control of boost
-------------------------------+--------------------------------------------
 Reporter:  manphiz@…          |       Owner:  adfernandes@…           
     Type:  enhancement        |      Status:  new                     
 Priority:  Normal             |   Milestone:                          
Component:  ports              |     Version:  1.9.1                   
 Keywords:  haspatch           |        Port:  boost                   
-------------------------------+--------------------------------------------

Comment(by manphiz@…):

 Replying to [comment:4 adfernandes@…]:
 > Hi, `manphiz` - I've been thinking a lot about this over the past couple
 of days, and here are my thoughts:
 >
 >  * I've looked into it, and allowing static runtime linking on a Mac is
 really a bad idea unless developers know what they are doing. Shared vs.
 static c++ runtimes are important for exception-handling propagation over
 shared-object boundaries. I don't pretend to understand it, but in my
 tests of Apple's vs MacPorts' gcc variants, `-static-libgcc` and `-shared-
 libgcc` give different results in terms of linking. I'm not even sure how
 this affects the `c++` runtime, never mind the `c`-runtime.

 I guess I have to look deeper in this regard to have a better
 understanding.

 > * Boost is really an infrastructure that a lot of ports depend on (see
 `port echo depends:boost`). These programs may be single or multithreaded,
 and may prefer shared or dynamic libraries.
 > * Since MacPorts can't depend on a given variant, I'm inclined to leave
 all of boost there (single and multithreaded, static and dynamic).
 >
 > Boost doesn't release versions very often, so I'm inclined to leave the
 port the way it is. It sucks in terms of build times, but that's the way
 it is with infrastructure libraries.
 >
 > Is the finer control you desire simply a matter of build-times?

 Sort of, since there are chances that some patches can be applied for
 testing purpose. After all, I agree such infrastructure library is better
 to provide all flavors for more audience. The other way around is my
 original propose to disable certain flavors by variants, such as
 no_single, no_static, etc., so that brave people can have more options.
 How does this sound?

-- 
Ticket URL: <https://trac.macports.org/ticket/26466#comment:5>
MacPorts <http://www.macports.org/>
Ports system for Mac OS