Re: [Boost-build] Using multiple toolsets at the same time ( was: Simple WiX toolset)

From: Andrei Melnikov (andy.melnikov_at_[hidden])
Date: 2006-07-22 12:49:16

On 22/07/06, Vladimir Prus <ghost_at_[hidden]> wrote:
>
> IIUC, there's that "MSI" target type, that you can produce using
> different tools. You've added WiX tool support, and used <toolset> to
> indicate that WiX tool should be used, and not other other one.
>
> How about using "msi_toolset" feature instread? That would allow me to write:
>
>   bjam toolset=msvc msi_toolset=wix
>
Your solution looks good for now, but it won't work well in a long
term perspective.

Should we have cpp_toolset then? What about c_toolset, idl_toolset?
And what about features? Are we going to end with <msi_linkflags> and
all these ugly prefixes (cpp_, msi_) everywhere, even if they are
redundant and can be guessed?

* Use case 1 *

 Look at the following line:

msi x : y.whatever : <linkflags>-a <toolset>b ;

BB can guess that it's msi_linkflags and msi_toolset and not
cpp_linkflags and cpp_toolset.

* Use case 2 *

msi x : y : <linkflags> -a ;
whatever y : z.foo z.bar : <linkflags>-b ;

If we combine these lines together and write just

msi x : z.foo ;

There should be a way to specify  fully qualified features and to
resolve the ambiguities

msi x : z.foo : <msi-linkflags>-a <whatever-linkflags>-b ;

or

msi x : z.foo : <msi:linkflags>-a <whatever:linkflags>-b ;

or

msi x : z.foo : <language>msi:<linkflags>-a <language>whatever:<linkflags>-b ;

or

msi x : z.foo : <type>msi:<linkflags>-a <type>whatever:<linkflags>-b ;

Also I think we shouldn't change the meaning of "toolset" term. A
toolset is just a set of tools installed and configured together. IMO
a toolset should be just a configuration unit and should be an
orthogonal concept to "the notion of languages" we discuss here.

I mean that Microsoft Visual Studio should be represented by a single
toolset, and not by multiple separate toolsets for C++, C#, MSBuild,
VCDeploy, IDL, RC etc... Telling "I have MSVS installed, please look
up" should be enough for a user. The configuration process should be
as simple as possible.

The meaning of "features" and "feature normalization" should be
reviewed too. Now we have:

1) global C++ features like <inlining> and <runtime-link>;

2) toolset specific features like msvc-only <debug-store> and
docutils-only <docutils> feature.

In a true multilanguage build tool I would expect more levels of
feature normalization:

1) Global language-neutral features. For example, <optimization>on/off
or <runtime-diagnostics>on/off can be applied to a wide range of
tools... <runtime-diagnostics> feature can turn on Internal
Consistency Validators/ICVs in Microsoft Installer builds, array bound
checks in an Object Pascal compiler, and a debug version of RTL in C++
builds.

2) Language-specific features
3) Toolset-specific features

There are a lot of corner cases in this situation, for example
different link time optimizations or bound checking span multiple
languages. Don't know what to do with them.