Re: [Boost-build] Issue in glob rule when invoked in <conditional>.

Subject: Re: [Boost-build] Issue in glob rule when invoked in <conditional>.
From: Jurko Gospodnetić (jurko.gospodnetic_at_[hidden])
Date: 2012-07-25 00:46:32

   Hi.

> This makes me pretty nervous.  I really
> don't like hacking in features as someone
> requests them.  I'm not even convinced
> that this is the correct behavior.
> If we're going to do something like
> this the documentation of glob needs
> to be updated to make it clear that
> it searches the 'current project' instead
> of the project of the current module.
> Also, how would the other project rules
> need to be updated to be consistent?

   Ok, I could not sleep so I did some more research on this... :-)

   The rule in question here is the project-rules.glob() rule added 
automatically to all project modules. It has already been implemented to 
work relative to the 'current project''s source location folder and 
Volodya's patch did not modify this behaviour.

   The only problematic topic here is how to interpret the term 'current 
project' at a given time.

   While loading Jamfiles this is the project corresponding to the 
Jamfile currently being loaded and, as Volodya already stated, is used 
as a global context used to identify the project newly declared main 
targets should belong to.

   However, this time the rule gets called at a later time when all the 
Jamfiles already got loaded and Boost Build started constructing virtual 
targets from all of its requested main targets. At this time the term 
'current project' has no special meaning. The variable identifying the 
'current project' (.current-project in the project module) has been left 
pointing to the 'last created project' but that seems to have been done 
by accident. In case of our failing unit-test - this is the app\Jamfile 
project.

   Volodya's patch sets the 'current project' in that phase to mean 'the 
project whose main target is being processed, i.e. is having its 
virtual-targets constructed'. This works out fine for what we need here, 
as long as we can not add indirect conditional properties on non-main 
targets, and I am not aware of any way to do that at the moment. Can 
anyone else think of one? [I tried adding it in a custom generator but 
that seems like it comes too late and found no way to add it using 
project requirements.]

   We could theoretically change the glob rule to mean 'relative to this 
Jamfile' (can be read using the built-in BACKTRACE rule) but that would 
require us to change the already preexisting project-rules.glob() rule. 
Or we could change it to mean 'relative to the current project folder in 
the Jamfile loading phase and relative to the current Jamfile 
afterwards' but that seems rather smelly.

   Well, we can also say - the project-rules.glob() rule can not be 
called once the Jamfile loading phase has finished its work, but that 
does not feel right either...

   Any thoughts?

   Best regards,
     Jurko Gospodnetić