Boost logo

Boost-Build :

Subject: Re: [Boost-build] RFC: problems lazy loading modules referenced using source target-ids
From: Jurko Gospodnetić (jurko.gospodnetic_at_[hidden])
Date: 2012-08-07 09:26:03

[forwarded e-mail by Steven Watanabe that seems to not have been sent to
the list by mistake]


On 08/07/2012 03:05 AM, Jurko Gospodnetić wrote:
> Some ideas:
> --- ignore the issue ---
> Don't like this as we are leaving behind a problem that people are
> going to keep running into time and time again, causing them to waste
> a lot of time debugging the issue and possibly even give up on using
> Boost Build all together.

Agreed. This problem has to be addressed somehow.

> --- disallow explicit project module references in source target-ids
> ---
> Alternative is to reference the project module earlier using the
> use-project rule, assigning a project-id for it and then use that
> project-id to reference targets from that project. Bad thing about
> this is that we are possibly complicating simpler build scenarios and
> potentially slowing down more complex one with use this to lazy load
> project modules only when and id actually needed.

This is a major breaking change. I don't think
we can do this.

> --- disallow declaring features in modules loaded due to being
> explicitly references in a used source target id ---
> The only problems caused by such lazy loaded modules that I can
> currently see are caused by them declaring features. We could possibly
> report an error if this is enountered and allow such lazy module
> loading for projects not declaring additional features.
> --- disallow declaring non-optional features in modules loaded due to
> being explicitly references in a used source target id ---
> It is even possible (I am not 100% certain of this though) that
> declaring optional features (i.e. those that do not get their default
> value automatically added to all built targets) does not cause any
> problems and can be allowed. Just food for though...

--- Somehow fix up the property sets after the fact
to take new features into account ---
To make this work, we have to be able to prove that
the new features have no effect on the build products.
In fact, if we have a system for determining which
features are relevant (which is desirable for
other reasons.) then the problem should disappear.

--- Don't load projects lazily ---
If we parse the properties early and load the
project, then the only potential problem would be
in indirect conditionals.

--- Keep track of lazily loaded projects and
features and issue a better error message iff
there's a problem. ---

> Thanks in advance for your input...
> Best regards,
> Jurko Gospodnetić
> P.S.
> There is also a bit more general design change that could be done
> at a later time which I find like a nice idea, and that is to make
> features project-specific (or at least allow them to be declared as
> such). Then we could allow project-specific features to be declared
> as well but all this is a separate issue.

That isn't sufficient to solve the problem, though.
A Jamfile can import a module which declares

In Christ,
Steven Watanabe

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