From: David Abrahams (dave_at_[hidden])
Date: 2007-03-10 10:43:00
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) : property-set ]
>> usage-requirements = $(targets) ;
>> targets = $(targets[2-]) ;
>> 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
> 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
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk