[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 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.
 * 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?

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