Boost logo

Boost-Build :

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
linker specific.

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.

- Reece


Boost-Build list run by bdawes at, david.abrahams at, gregod at, cpdaniel at, john at