|
List Info Thread: Using multiple toolsets at the same time ( was: Simple WiX toolset)
[1]
|
||||||||||||
|
about | contact Other archives ( Real Estate discussion Medical topics ) |
||||||||||||
Using multiple toolsets at the same time ( was: Simple WiX toolset) |
|
List Info Thread: Using multiple toolsets at the same time ( was: Simple WiX toolset)
[1]
|
||||||||||||
|
about | contact Other archives ( Real Estate discussion Medical topics ) |
||||||||||||
cs.msu.su> 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.