Opened 14 years ago

Closed 13 years ago

#26466 closed enhancement (fixed)

finer control of boost

Reported by: manphiz@… Owned by: adfernandes (Andrew Fernandes)
Priority: Normal Milestone:
Component: ports Version: 1.9.1
Keywords: haspatch Cc:
Port: boost

Description

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.

Attachments (4)

patch-boost-Portfile-finer-control.diff (988 bytes) - added by manphiz@… 14 years ago.
Patch to add variants to build multi-thread / shared flavor(s) only
Portfile (7.6 KB) - added by manphiz@… 13 years ago.
New Portfile to enable multithreading/shared/release by default with other options through variants
patch-Portfile.diff (1.1 KB) - added by manphiz@… 13 years ago.
Patch against current boost Portfile
boost_without_static_single.patch (814 bytes) - added by manphiz@… 13 years ago.
patch against current Portfile with variants no_single and no_static

Download all attachments as: .zip

Change History (12)

Changed 14 years ago by manphiz@…

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

comment:1 Changed 14 years ago by jmroot (Joshua Root)

Cc: adfernandes@… removed
Keywords: haspatch added
Owner: changed from macports-tickets@… to adfernandes@…

comment:2 Changed 14 years ago by 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!

Changed 13 years ago by manphiz@…

Attachment: Portfile added

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

Changed 13 years ago by manphiz@…

Attachment: patch-Portfile.diff added

Patch against current boost Portfile

comment:3 Changed 13 years ago by 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.

comment:4 Changed 13 years ago by 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?

comment:5 in reply to:  4 Changed 13 years ago by 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?

comment:6 Changed 13 years ago by 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.

Changed 13 years ago by manphiz@…

patch against current Portfile with variants no_single and no_static

comment:7 Changed 13 years ago by 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.

comment:8 in reply to:  7 Changed 13 years ago by adfernandes (Andrew Fernandes)

Resolution: fixed
Status: newclosed

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!)

Note: See TracTickets for help on using tickets.