Question about try-one-generator-really

  # Returns usage requirements + list of created targets
  local rule try-one-generator-really ( project name ? :
generator : 
      target-type : property-set : sources * )
  {
      local targets =
        [ $(generator).run $(project) $(name)
                         : $(property-set)
                         : $(sources)
        ] ;

      local usage-requirements ;
      local success ;

      generators.dout [ indent ] returned $(targets) ;

      if $(targets)
      {
          success = true ;

          if  [ class.is-a $(targets[1]) : property-set ]
          {
              usage-requirements = $(targets[1]) ;
              targets = $(targets[2-]) ;
          }
          else
          {
              usage-requirements = [ property-set.empty ] ;
          }
      }

Apparently this means it's optional for the first element
returned
from running a generator property-set of usage requirements.
 Why is
that a good idea?  Wouldn't it be better to use a single
protocol (all
generators return either nothing, or a sequence starting
with a
property-set of usage requirements and followed by generated
targets)?

Now as I modify gcc-linking-generator, I have to worry that
unix-linking-generator might not give me a property set of
usage
requirements.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build

On Saturday 10 March 2007 09:10, David Abrahams wrote:
> 
>   # Returns usage requirements + list of created
targets
>   local rule try-one-generator-really ( project name ?
: generator : 
>       target-type : property-set : sources * )
>   {
>       local targets =
>         [ $(generator).run $(project) $(name)
>                          : $(property-set)
>                          : $(sources)
>         ] ;
> 
>       local usage-requirements ;
>       local success ;
> 
>       generators.dout [ indent ] returned $(targets) ;
> 
>       if $(targets)
>       {
>           success = true ;
> 
>           if  [ class.is-a $(targets[1]) : property-set
]
>           {
>               usage-requirements = $(targets[1]) ;
>               targets = $(targets[2-]) ;
>           }
>           else
>           {
>               usage-requirements = [ property-set.empty
] ;
>           }
>       }
> 
> Apparently this means it's optional for the first
element returned
> from running a generator property-set of usage
requirements.  Why is
> that a good idea?  Wouldn't it be better to use a
single protocol (all
> generators return either nothing, or a sequence
starting with a
> property-set of usage requirements and followed by
generated targets)?

It would be better if the need for this property-set return
was known from
the very start. As it is, it was introduced relatively
later, so auditing all
generators did not seem like a good idea, and user-written
generators
are outside our control.

> Now as I modify gcc-linking-generator, I have to worry
that
> unix-linking-generator might not give me a property set
of usage
> requirements.

Practically, you can just check unix-linking-generator.

- Volodya
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build

on Sat Mar 10 2007, Vladimir Prus <ghost-AT-cs.msu.su>
wrote:
> On Saturday 10 March 2007 09:10, David Abrahams wrote:
>> 
>>   # Returns usage requirements + list of created
targets
>>   local rule try-one-generator-really ( project
name ? : generator : 
>>       target-type : property-set : sources * )
>>   {
>>       local targets =
>>         [ $(generator).run $(project) $(name)
>>                          : $(property-set)
>>                          : $(sources)
>>         ] ;
>> 
>>       local usage-requirements ;
>>       local success ;
>> 
>>       generators.dout [ indent ] returned
$(targets) ;
>> 
>>       if $(targets)
>>       {
>>           success = true ;
>> 
>>           if  [ class.is-a $(targets[1]) :
property-set ]
>>           {
>>               usage-requirements = $(targets[1]) ;
>>               targets = $(targets[2-]) ;
>>           }
>>           else
>>           {
>>               usage-requirements = [
property-set.empty ] ;
>>           }
>>       }
>> 
>> Apparently this means it's optional for the first
element returned
>> from running a generator property-set of usage
requirements.  Why is
>> that a good idea?  Wouldn't it be better to use a
single protocol (all
>> generators return either nothing, or a sequence
starting with a
>> property-set of usage requirements and followed by
generated targets)?
>
> It would be better if the need for this property-set
return was known from
> the very start. As it is, it was introduced relatively
later, so auditing all
> generators did not seem like a good idea, and
user-written generators
> are outside our control.

We're still in development; intentionally breaking backward
compatibility a few times is the right thing to do.  It
would be easy
enough to insert an assertion that would check for the new
protocol.

>> Now as I modify gcc-linking-generator, I have to
worry that
>> unix-linking-generator might not give me a property
set of usage
>> requirements.
>
> Practically, you can just check
unix-linking-generator.

We need well-specified interfaces.

Does the documentation for unix-linking-generator specify
that it will
use the new protocol?  No it does not (there's no
documentation).
Therefore there's nothing to stop someone from changing it
one day to
use the other protocol.  "Use the source" is the
wrong approach here.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build