[Boost-build] Adding "on target" variables "on the fly"

Subject: [Boost-build] Adding "on target" variables "on the fly"
From: Stefan Seefeld (stefan_at_[hidden])
Date: 2017-06-17 11:21:11

Hi Steven,

I've run into a bjam use-case that I'm attempting to serve by making a
few modifications to the bjam C code, and I'd like to ask for your
feedback. (For avoidance of doubt: I'm doing this in the context of my
faber project, which uses a Python interface to bjam, rather than b2's
Jam interface.)

Here is the use-case:

I'm trying to implement a config check that consists of this chain of
actions:

1) determine whether the given Python version has the "numpy" module
installed, and if so, report the associated include path

2) with that include path, try-compile a little app to make sure all
compiler flags work.

The problem (in the original bjam logic) is that all "on target"
variables had to be defined before the scheduler's "update" function
(the "update_now" rule in Jam lingua) would be called. I.e., it isn't
possible for one target action to add or modify variables used in
another, unless the two were built by separate calls to the "update_now"
rule.

I have just come up with a patch that I *think* works (for my Python
frontend, at least), and I wanted to bounce it back from you in case you
see any side-effects that I'm not yet aware of: I inject a new function
which would set the variables into the make1cmds() function, just before
they are needed to construct commands from actions:

https://github.com/stefanseefeld/faber/blob/tmp/src/bjam/make1.c#L1021-L1023

(The function is defined in
https://github.com/stefanseefeld/faber/blob/tmp/src/bjam/bjam.c#L395-L414)

Do you see anything obviously wrong with that approach ? (I'm aware that
I shouldn't modify any variables that would influence the binding of
names of targets (such as done by the "search" rule), as that would
create inconsistencies.)

Many thanks,

        Stefan

-- 
      ...ich hab' noch einen Koffer in Berlin...