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: Vladimir Prus (ghost_at_[hidden])
Date: 2002-11-14 05:00:04

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.

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

> + 
> + IMPORT $(__name__) : main-target-rule : : $(n) ;
> +# feature.compose <main-target-type>$(type) : <base-target-type>$(type) ;
> } 
> }
> }

> Index: generators.jam
> ===================================================================
> RCS file: /cvsroot/boost/boost/tools/build/new/generators.jam,v
> retrieving revision 1.15
> retrieving revision 1.16
> diff -u -d -r1.15 -r1.16
> --- generators.jam	11 Nov 2002 22:53:50 -0000	1.15
> +++ generators.jam	12 Nov 2002 14:37:42 -0000	1.16
> @@ -124,6 +124,10 @@
> self.name-pre-post.$(m[1]) = $(m[3]) $(m[4]) ;
> }
> 
> + self.optional-properties
> + = [ feature.expand <base-target-type>$(self.target-types) ]
> + ;
> + 
> rule id ( )
> {
> return $(self.id) ;
> @@ -154,6 +158,7 @@
> # TODO: comment is out of date.
> rule optional-properties ( )
> {
> + return $(self.optional-properties) ;
> }
> 
> # Tries to invoke this generator on the given sources. Returns a
> @@ -558,24 +563,79 @@
> # Select generators that can create the required target type.
> local viable-generators = ;
> local generator-rank = ;
> - # TODO: rank generators by optional properties.
> - for local g in $(.generators.$(target-type))
> +
> + 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. 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.

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?

> +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!

- Volodya