Using multiple toolsets at the same time (was: Simple WiX toolset)

Andrei Melnikov wrote:
> On 20/07/06, Reece Dunn <msclrhdhotmail.com> wrote:
> > Andrei Melnikov wrote:
> > > How should I configure the WiX installation
path? using wix : 3.0 :
> > > d:/experiments/wix-3.0 ; doesn't work.
> >
> > You need to specify the full path of candle.exe,
like you do with cl.exe
> > for msvc:
> >
> It didn't work because msvc was my default toolset.
When I specify wix
> on the command line, it works.

Yeah, sorry. I forgot about that!

> Is this a bug? msvc toolset doesn't have generators
for msi.

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.

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.

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

That way, if you do:

   bjam

the first toolset *in each language group* will be used for
that language
group. If you do:

   bjam msvc gcc wix

Then msvc-wix and gcc-wix are used - i.e. a cross product of
the selected
toolsets for each language.

I do not yet know how to implement this language group
functionality.

- Reece
____________________________________________________________
_____
Be one of the first to try Windows Live Mail.
http://ideas.live.com/progr
ampage.aspx?versionId=5d21c51a-b161-4314-9b0e-4911fb2b2e6d
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build

On 20/07/06, Reece Dunn <msclrhdhotmail.com> wrote:
> Andrei Melnikov wrote:
> > It didn't work because msvc was my default
toolset. When I specify wix
> > on the command line, it works.
>
> Yeah, sorry. I forgot about that!
>
> > Is this a bug? msvc toolset doesn't have
generators for msi.
>
> 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.
>
> 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.

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.
>
> 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
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build