#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