Re: [Boost-build] Custom generator problem

Subject: Re: [Boost-build] Custom generator problem
From: Johan Nilsson (r.johan.nilsson_at_[hidden])
Date: 2009-11-26 03:45:21

Vladimir Prus wrote:
> On Wednesday 25 November 2009 16:48:22 Johan Nilsson wrote:
>

[...]

>>
>> I'm attaching the real, updated, generator to this posting. Even
>> though you won't be able to actully test it without having other
>> stuff installed, maybe you can find out what the problem is by
>> browsing the code. This is the the output when adding an alias for
>> the test targets (paths snipped to protect the innocent):
>
> local main-xml-target = [ new file-target $(name) : NUNIT_XML :
> $(project) : $(main-target-action) ] ; main-targets += [
>         virtual-target.register $(main-xml-target) ] ; ...
> local copy-xml-action = [ new action $(main-xml-target) : common.copy
> : $(xml-target-ps) ] ;
>
> At this point 'main-xml-target' is *still* the target constructed by
> 'new'. Although you have
> called virtual-target.register passing the current value of
> 'main-xml-target', you have stored
> the result in 'main-targets', and 'main-xml-target' is what it was.
>
> Does rewriting this as:
>
> local main-xml-target = [ new file-target $(name) : NUNIT_XML :
>            $(project) : $(main-target-action) ] ; main-xml-target =
> [ virtual-target.register $(main-xml-target) ] ;
> main-targets += $(main-xml-target) ;
>         ...
> local copy-xml-action = [ new action $(main-xml-target) : common.copy
> : $(xml-target-ps) ] ;
>
> Improve things?

Of course. How extremely embarrasing! I've spent so much time going through
the generated-targets method to find out the problem, and even when
Boost.Build tells me exactly what target is duplicated I wasn't able to
parse that.

I guess a fresh pair of eyes is what's necessary sometimes. Many thanks!

Some further questions and suggestions while I'm into extending Boost.Build:

- I use "virtual-target.from-file" in order to generate the "source targets"
for the common.copy invocation, but for those I do not use
virtual-target.register. Neither did you in your fixed version of the first
sample project. Is this ok because these "targets" are only used as sources?

- I also use the targets from generated-targets method's "sources" argument
without registering those. Is it generally safe to do so - can I rely on
them referring to registered targets before my generator is called?

- Again, same goes for the targets named using the <library-file> property
(this is an artifact of the dotnet generator, which change sources of type
SHARED_LIB to become a "<library-file>" property instead).

- It is a bit confusing at times when "sources" are "targets". Would it be
possible to have a more neutral name?

- It would likely be a good idea to emphasize and exemplify the need for
registering the targets before use even inside e.g. the "generated-targets"
method in the documentation.

- The generator's "generated-targets" method does not seem to have to return
all of the targets, only the top-level ones. The other ones are still
generated as they are dependencies of the main target(s). Is it ok to only
return the top-level targets, as long as all are registered?

- Do you have any other comments on the generator code itself? I'd be happy
for suggestions for improvements.

Thanks again,
Johan