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

From: Reece Dunn (msclrhd_at_[hidden])
Date: 2006-07-22 15:33:58

Andrei Melnikov wrote:
> 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.

I agree with Andrei here.

At the moment, BB is very much designed around a single language model
(C++) and has grown from there.

Going with the idea that Volodya proposed, this would work for my wix toolset,
but would only be a short-term solution.

At the moment, assembly support is built into various toolsets, but I may
want to use an external toolset (e.g. nasm) to do the assembling, for example
xvid uses msvc/gcc with nasm.

> 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.

The problem here is feature inheritance. If you have:

   exe x : ... : <linkflags>xflags ;

   msi y : x : <linkflags>yflags ;

how would BB resolve <linkflags>xflags inherited in y by x?

> 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.

And it should be possible to say use this toolset along with the
assembler (or whatever) from another toolset.

> 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

I agree.

> 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.

Nor do I. Whatever we decide to go for, we need a more generic
framework that can handle more varied configurations and setups.

I have few answers. BBv2 is a good framework, but is only really
designed for configuring and specifying C++-only projects.

- Reece
_________________________________________________________________
Be one of the first to try Windows Live Mail.
http://ideas.live.com/programpage.aspx?versionId=5d21c51a-b161-4314-9b0e-4911fb2b2e6d