Per-source requirements

From: Vladimir Prus (ghost_at_[hidden])
Date: 2002-09-10 04:54:29

Hi,

a recent discussion with Markus Sch?pflin
(http://groups.yahoo.com/group/jamboost/message/1561)
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 
"exported" requirements.
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
do:

lib libgraph : parser.y:<define>BGL_UNDIRECTED_PARSER 
parser.y:<define>BGL_DIRECTED_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.

Opinions?

- Volodya