From: Vladimir Prus (ghost_at_[hidden])
Date: 2002-09-10 04:54:29
a recent discussion with Markus Sch?pflin
ended with the conclusion that we need per-source requirements, like this
exe a : a.cpp b.cpp/<pch>off my_project_pch ;
Which will compile b.cpp without pch, but a.cpp with.
I think it might be easy to implement, and it will also handle
Each virtual target will be assigned a set of "use requirements". They
will work in this way:
EXE <--------- a.obj <--------- a.cpp
<---------- b.obj <--------- b.cpp (<pch>off)
<---------- libboost_bgl (<include>/path/to/boost)
Each generator first builds a dependecy graph. After that, it decides
wether to apply "use requirements". Any given
use requirement is applied if
1. There's at least one generator, used for building the dependency
graph, for which the requirement is relevant
2. The requirement was not applied previously.
For example, generator for b.obj notices <pch>off requirement, which was
not yet applied and which is relevant.
So, it applies it to the action which builds b.obj from b.cpp. Later,
generator for EXE, notices that <pch>off was already
applied, so nothing is done about it. However, <include>/path/to/boost
was not yet applied and it relenant for obj<-cpp
generator, which was used to construct the graph for EXE. So, it is
applied to obj<-cpp actions.
There's another interesting use case. BGL needs to compile the same file
with two different defines. I wish we could
lib libgraph : parser.y:<define>BGL_UNDIRECTED_PARSER
This will work with the proposed scheme, except the we'll have two
imtermediate objects with different values of
free properties. Hey, why can't be support it? Simply: we can make free
properties added by use requirements special, and add them to target
path. This won't lead to much increase in path length, since such
properties are rare.
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