Re: [BBv2][msvc] assembler support - asmflags note (low priority)

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