finer control of boost

[manphiz@…]

Currently boost build all threading and link variants, and build release-only by default and can be configured to build debug versions. It'll be great to be able to more finer-control the flavors of boost. The patch attached is a preliminary prototype with variants to make boost build only multi-thread and shared libraries.

Another option is that we can let it build multi-thread and shared flavors by default (which are used more often), with variants to add single-thread and static flavors.

[manphiz@…]

Patch to add variants to build multi-thread / shared flavor(s) only

[adfernandes (Andrew Fernandes)]

You know, building boost is such a horrible experience... I like your suggestions.

So... boost should build, buy default, only the release, multithreaded, shared code. That should cut down on build times.

I am quite busy for the next few days - could I ask you to patch the Portfile so that threading=multi, link=shared is the default, with single and static as variants, and test it?

I believe that on a Mac, runtime-link=shared is the only option that has any effect; OS X, as far as I know, does not support static linking of the runtime the way Linux or FreeBSD do.

Thanks for your input!

[manphiz@…]

New Portfile to enable multithreading/shared/release by default with other options through variants

[manphiz@…]

Patch against current boost Portfile

[manphiz@…]

New Portfile attached. It still keeps the runtime-link option, feel free to remove it. Tested locally on 10.6.4 with xcode 3.2.3.

[adfernandes (Andrew Fernandes)]

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?

[manphiz@…]

Replying to 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?

[adfernandes (Andrew Fernandes)]

Hi, manphiz - sorry for the delay replying!

Your suggestion of no_single and no_static sound great, actually. If you roll them up, I'll commit them.

One caveat, though - I've looked (more) into it, and I think that the runtime-link should be left as dynamic. If users want static runtime linking, they should be advanced enough c++ programmers that they really want to compile their own boost, I think. Static runtimes, especially when exceptions are used (intentionally or unintentionally), can really lead to hard-to-diagnose problems.

[manphiz@…]

patch against current Portfile with variants no_single and no_static

[manphiz@…]

Sorry for the delay (midterm...). I've attached a patch with variants no_single and no_static.

Note that there might be a problem: as boost is configured as "layout=tagged", by disabling single threading flavor, only libraries with libboost_<foo>-mt.* will exist. So far my reverse dependency is not affected, but there is a chance. So it may be necessary to manually provide symlinks for libboost_<foo>.* (without -mt). (I tried to provide one, but my limited knowledge on tcl doesn't help much.)

Note that removing layout=tagged, hence remove -mt named files may break other program relying on that flavor, so is not considered. Also, as the interfaces of both flavors are same, so it is safe to use the symlink strategy.

[adfernandes (Andrew Fernandes)]

Note that there might be a problem: as boost is configured as "layout=tagged"

You know, at some point, you have to say "enough is enough" when it comes to building different configurations. :-) I think that if people want to disable certain types of build, then they should not be surprised when dependencies fail.

Also, linking (faking) mt builds as st is not a good idea. Even though the interfaces are the same, there may be runtime linking and compile time changes (thread-local storage is a good example) that might break, without a trace.

Committed in r72562.

(Good job, BTW!)