Boost C++ Libraries: Ticket #4863: Support for building with multiple toolsets

Dave Abrahams — Wed, 17 Nov 2010 19:02:25 GMT

Perhaps the best strategy would be to do as Boost.IOStreams does for bzip2 and libz: give people an option to point at the sources and then build the library dependencies under Boost.Build itself.

anonymous — Thu, 18 Nov 2010 16:45:35 GMT

Perhaps the best strategy would be to do as Boost.IOStreams does for bzip2 and libz: give people an option to point at the sources and then build the library dependencies under Boost.Build itself.

No chance of that: the ICU build process does all kinds of scarey things that I wouldn't dream of trying to reproduce in Boost.Build.

A per-toolset solution might be possible using Boost.Build's features, but that won't be easy either :-(

Sorry Dave, but as you may be the only person in the world who needs this, this one will have to be a low priority...

Dave Abrahams — Thu, 18 Nov 2010 17:23:23 GMT

OK. Is it really true that people are rebuilding ICU binaries to match whatever C++ compiler (and settings) they're using, though? That seems so difficult as to be effectively impossible. Seems more likely to me that different VC++ versions are close enough to abi-compatible that they can link with the prebuilt ICU binaries(?)

How do you test this stuff?

anonymous — Thu, 18 Nov 2010 18:45:36 GMT

OK. Is it really true that people are rebuilding ICU binaries to match whatever C++ compiler (and settings) they're using, though? That seems so difficult as to be effectively impossible. Seems more likely to me that different VC++ versions are close enough to abi-compatible that they can link with the prebuilt ICU binaries(?)

How do you test this stuff?

With whatever msvc version I used to compile ICU with ;-)

On Linux it's much easier as most Linux compilers are ABI compatible with GCC anyway.

With MSVC it's true that you can mix VC versions, and release and debug binaries, and mostly it will all work. But it does come back to bite you in the end... usually. BTW the binaries that ICU provides are useless for this purpose, as they only supply release mode builds, and not binaries that link to the debug runtime.

Dave Abrahams — Thu, 18 Nov 2010 19:43:43 GMT

Then forgive me for being so bold as to suggest that this state of affairs is a Regex library bug. Isn't it a library author's responsibility to make sure that his library can be thoroughly tested by the automated regression testers? It seems you may need to do a bit more to make it practical to verify your code.

status changed; resolution set

John Maddock — Fri, 18 Mar 2011 16:37:23 GMT

status new → closed
resolution → wontfix

I closing this, because it's basically unfixable as suggested:

1) Boost.Build's command line won't allow you to specify a specific/different build property for each toolset anyway (actually there is a way, but it's undocumented and only semi-works). So there's nothing in the Jamfile I can do to handle multiple toolsets differently.

2) There is also a simple method that works right now, without any intervention from me - for the tester to modify their user-config.jam to add the necessary -I and -L options to the compiler so that ICU will be found and used with that toolset. No need to set any macros on the command line at all then.

I'll modify the docs to mention the latter point.

John Maddock — Fri, 18 Mar 2011 16:47:04 GMT

(In [70131]) Add info on building/testing ICU with multiple compilers. Refs #4863.

Dave Abrahams — Sun, 27 Mar 2011 12:52:58 GMT

Replying to johnmaddock:

1) Boost.Build's command line won't allow you to specify a specific/different build property for each toolset anyway (actually there is a way, but it's undocumented and only semi-works). So there's nothing in the Jamfile I can do to handle multiple toolsets differently.

I understand the rest of what you wrote, but not this part. How is what can be specified on the command line related to what can be done in a Jamfile?

anonymous — Sun, 27 Mar 2011 16:25:06 GMT

There's no mechanism by which a user can invoke bjam with more than one toolset *and* different build options for each toolset.

So since the user would have to inform the regex Jamfile where each set of ICU binaries was (ie a different set of binaries for each toolset), it's basically impossible to support building with multiple toolsets, all with different ICU versions. Except of course, if they add the necessary options to their toolset configurations in user-config.jam when it just works as is anyway.

Not sure if that's any clearer ;)

anonymous — Mon, 28 Mar 2011 20:37:54 GMT

Replying to anonymous:

There's no mechanism by which a user can invoke bjam with more than one toolset *and* different build options for each toolset.

Not quite true true. you can add values for the "icu" build property to the toolset declaration in your site-/user-config.jam file. Last I checked, you can also write something like this on the command-line:

bjam toolset=msvc-7.1/icu=/path/to/icu7.1 toolset=msvc-10.0/icu=/path/to/icu10.0

So since the user would have to inform the regex Jamfile where each set of ICU binaries was (ie a different set of binaries for each toolset), it's basically impossible to support building with multiple toolsets, all with different ICU versions. Except of course, if they add the necessary options to their toolset configurations in user-config.jam when it just works as is anyway.

OK, setting raw compiler flags in user-config.jam is crude, but a perfectly acceptable workaround.

Thanks