From: Reece Dunn (msclrhd_at_[hidden])
Date: 2005-09-19 18:10:35
Andrey Melnikov wrote:
> Reece Dunn wrote:
>>I have now attached the resulting msvc assembler support patch.
> +feature asmflags : : free ;
> Are we going to have qbflags, rcflags, mocflags, doxflags etc? I dislike
> the idea to modify builtin.jam every time we add a new target type. For
> now it's ok, but in the feature we need to develop a more scalable
> framework. E.g. to put asmflags in types/asm.jam as it's unlikely that
> the feature will be used without the type.
I like that idea -- put the type-related things in types/*.jam. Also, we
could move the other types (C, H/HPP, etc.) there as well, along with
<cflags>, <cxxflags>, etc.
> IMO at some point in the feature we'll need to create an abstraction for
> tool types. For example, now we have:
> - C compilers
> - C++ compilers
> - linkers/librarians
> - fortran compilers
> - ...
> We'll have to separate tool type-specific and os-specific abstractions
> from builtin.jam. The file is very big. Also, builtin.jam and common.jam
> can be merged. Now it's unclear what should be done by common.jam and
> what - by builtin.jam
As far as I understand this, but Volodya or Dave would be better at
this, common.jam contains common methods/functionality whereas
builtin.jam defines common types, features and variants.
> Also, can we just use <flags>?
Then, if you have:
exe foo : ... : <flags>-machine:x86 ;
you add that to everything, where it should be <linkflags> as it is
Is it possible so that when registering types we automatically generate
a <type-flags> feature, so:
type C : c : cflags ; # defines feature cflags : : free ;
type CPP : cpp cxx cc : cxxflags ; # defines feature cxxflags : : free ;
where the last argument gives the prefix.
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