Re: [Boost-build] RFC: problems lazy loading modules referenced using source target-ids

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]

AMDG

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
features.

In Christ,
Steven Watanabe