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

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

Andrei Melnikov wrote:
> On 20/07/06, Reece Dunn <msclrhd_at_[hidden]> wrote:
> > The problem is that wix is defined as a separate toolset as the logic to
> > build the MSI files is located in WiX. If I was to place the msi generators
> > in msvc (and all the other supported Windows toolsets!) I would be implying
> > that msi<->wix, which I don't want to do! WiX is a separate toolset, unlike
> > rc, asm, midl and other source file types/tools.
> 
> idl<->tlb link isn't better. We also have CORBA and XPCOM idl files.
> The situation is the same everywhere.

Yes. A solution would also need to support an external assembler (e.g. nasm).

> > I could get partially around this by having wixmsi, but that looks ugly. We
> > may end up doing that if you consider other MSI generators like Install Shield
> > that have their own source files.
> >
> > However, we would still need to import the generators into the host toolset.
> >
> > There is also a problem (I believe) in mixing codetrees that are dependant on
> > C++ and Fortran as these are done as separate toolsets.
> 
> The problem is inside $(condition) we use.
> 
> I "fixed" the problem with wix by removing $(condition) from the
> wix.init rule. This will break again if I would have wix-2.0 and
> wix-3.0 toolsets configured at the same time.

No good for me then :).

> Now we rely on having a single global <toolset> value. <toolset> and
> <toolset-version> should be set individually for each target depending
> on current toolsets and target's type.

Yes.

> > Ideally, we want a notion of language groups, e.g. all this information relates
> > to C++ toolsets (<language>cpp) or MSI (<language>msi) or
> > Fortran (<language>fortran). That way, we could associate toolsets with
> > a language group:
> >
> >    <language>cpp --> <toolset>msvc
> >    <language>cpp --> <toolset>gcc
> >    <language>msi --> <toolset>wix
> >    <language>msi --> <toolset>installshield
> >
> We already have target types. I think a separate notion isn't
> necessary. We just need to get rid of the single global <toolset>
> value we have now. target.type == CPP isn't worse than <language>cpp

I agree. However, there needs to be some logic to work out type families, e.g. CPP, C, HPP and H. It needs to support defaults (e.g. for ASM, use the toolset defined for CPP) or override where necessary (e.g. use this assembler instead of the default one). It must also retain the current behaviour of passing multiple toolsets to the build engine.

An interesting case is using an external assembler:

   bjam msvc nasm

Should the default msvc assembler be used for one build set, and msvc+nsam be used in another build set? If a toolset has a notion of primary types -- types that cannot be composed with other toolsets -- and all other types are secondary, then in the above case, msvc will define ASM as a secondary type, OBJ as a primary type, while nasm will define ASM as a primary type, OBJ as a secondary (i.e. it does not know how to link executable code). The two toolsets are merged (for the purpose of this build run) into msvc+nasm, where ASM and OBJ are both primary.

The primary/secondary list of supported types should be enough to support what we want. When evaluating the toolset list:

   bjam msvc borland nasm

the toolsets msvc and borland have ovrelapping primary typelists, so are not merged, but are evaluated as if they were executed on separate command lines. The nasm toolset will compose onto msvc and borland, giving the effective command line of:

   bjam msvc nasm
   bjam borland nasm

Toolsets from the toolsetlist are combined into a toolset t' only if:
   1.  t1.primary intersect t2.primary is empty
   2.  t1.secondary intersect t2.primary equals t2.primary
where:
   t'.primary = t1.primary union t2.primary
   t'.secondary = t1.secondary intersect t2.primary
until:
   there does not exists t in toolsetlist suchthat
      t.primary intersect t'.primary is empty

The toolsets to use as the buildset are given as the toolsets in the cross product of the toolsets passed to the command line that meet the above criteria.

Hmm, this is getting complicated. I hope it makes sense. Comments? Thoughts?

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