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++
> 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.
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.
Be one of the first to try Windows Live Mail.
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk