Support for building with multiple toolsets

[Dave Abrahams]

The docs say:

your copy of ICU must have been built with the same C++ compiler (and compiler version) that you are using to build Boost. Boost.Regex will not work correctly unless you ensure that this is the case: it is up to you to ensure that the version of ICU you are using is binary compatible with the toolset you use to build Boost.

However, it only lets me point at a single copy of ICU per build invocation. It should be possible to set the version of ICU to use with *each* toolset.

[Dave Abrahams]

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]

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]

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]

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]

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.

[John Maddock]

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]

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

[Dave Abrahams]

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]

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]

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