Boost logo

Boost-Build :

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


> 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

   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ć

Boost-Build list run by bdawes at, david.abrahams at, gregod at, cpdaniel at, john at