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Ä
> 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
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