Re: [jamboost] Re: [Boost-build] CVS: boost/tools/build/new type.jam,1.7,1.8 targets.jam,1.46,1.47 generators.jam,1.15,1.16 gcc.jam,1.9,1.10 builtin.jam,1.27,1.28

From: David Abrahams (dave_at_[hidden])
Date: 2002-11-14 07:16:10

Vladimir Prus <ghost_at_[hidden]> writes:

> David Abrahams wrote:
>
>> Modified Files:
>> type.jam targets.jam generators.jam gcc.jam builtin.jam 
>> Log Message:
>> Attempt to handle derived target types
>> 
>> 
>> Index: type.jam
>
>> rule register ( type : suffixes * : base-type ? : main ? ) 
>> {
>> + # Type names cannot contain hyphens, because when used as
>> + # feature-values they will be interpreted as composite features
>> + # which need to be decomposed.
>> + switch $(type)
>> + {
>> + case *-* : errors.error "type name \"$(type)\" contains a hyphen" ;
>> + }
>> + 
>
> BTW, if you cd to examples-v2/hello and say
>
> bjam cxxflags=-DNDEBUG
>
> you'll get an error. I'm not yet sure what it's it, but may be related.

Maybe so. The basic deal is that subfeatures are separated by hyphens
and types are features, so I had to do something to keep them from
being broken into pieces during expansion.

However, maybe it would've been better to sort out whole property
names that contain hyphens before attempting to expand subproperties.

>> if $(main)
>> - { 
>> - IMPORT $(__name__) : main-target-rule : : $(type:L) ;
>> + {
>> + # Convert the type name to lowercase and convert all
>> + # underscores to hyphens to get the main target rule name.
>> + import regex ;
>> + local n = [ regex.split $(type:L) "_" ] ;
>> + n = $(n:J=-) ;
>> + .main-target-type.$(n) = $(type) ;
>
> Oh... that's too fancy. We have types in uppercase with underscores, and
> main target rules in lowecase with hyphens. Let's make rule name equal
> to type-name, and disallow "-" there, if needed. I believe my original
> downcasing to type name was an error.

I had no problem with it. I prefer not to disallow hyphens in rule
names, since that's our convention. Maybe I really need to fix the
feature module to allow values with hyphens.

>> +
>> + import type ;
>> + local t = [ type.all-bases $(target-type) ] ;
>> + 
>> + while $(t[1])
>> {
>> - # Avoid trying the same generator twice on different levels.
>> - if ! $(g) in $(.active-generators) 
>> - && ! ( [ is-a $(g) : composing-generator ] && $(.had-composing-generator) )
>> - { 
>> - if [ $(g).requirements ] in $(properties) 
>> - {
>> - viable-generators += $(g) ;
>> - generator-rank += [ sequence.length [ set.intersection 
>> - [ $(g).optional-properties ] : $(properties) ] ] ;
>> + for local g in $(.generators.$(t))
>
> I realize what's going on. You're picking generators for all types,
> including base types, and plan to use optional properties for
> selection. 

Nope. That was my plan at first, but I think you missed the line that says:

t = ;

So basically, it starts at the "most-derived" type and goes until it
finds a type with a matching generator.

> I don't know if this is right or wrong. What I do know, is that
> generators matching is far from finished. You've proposed the idea
> some time ago, and we have only one test that uses generator
> matching. Therefore, more thought is definitely needed.

Yes. I'm 
>
> I originally thought that we should not check base type generators if
> we have any generators for the actual type.
>
>> +# currently unused. Sorry for the cruft. Delete at will
>> +local rule find-viable-generators.new ( target-type : properties * )
>
> Is this just a version with better debug output?

Maybe. I used to think it was semantically different, but I can't see
that any more. Best to just kill it.

>> +local rule declare-type ( os * : type : suffixes * : base-type ? : main ? ) 
>> {
>> +
>> +declare-type NT : STATIC_LIB : a : LIB : main ;
>> +declare-type : STATIC_LIB : a : LIB : main ;
>
> I like this rule!

Thanks!

-- 
David Abrahams
dave_at_[hidden] * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution