Re: [jamboost] Per-source requirements

From: David Abrahams (dave_at_[hidden])
Date: 2002-09-10 07:36:17

From: "Vladimir Prus" <ghost_at_[hidden]>

>
> 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 agree in principle, but I don't like the syntax much. It's too confusable
with a path:

exe a : a.cpp src/detail/b.cpp/<pch>off my_project_pch ;

Doesn't that scare you a little?

Also, we probably ought to be thinking in terms of a future where users
write pch=off instead of <pch>off, but that's a discussion for another
time.

> I think it might be easy to implement, and it will also handle
> "exported" requirements.

Do you mean requirements intended for dependents of the target being built?

> 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

?? To the exe ?? When was it applied there?

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

Could you write some pseudocode for this process? I don't think I get it
yet.

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

Huh? Don't you need to specify different intermediate target names
somewhere?

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

So when a library dependency adds #include paths, you plan to stick those
in the target path? Sounds like a huge mistake to me...

-----------------------------------------------------------
David Abrahams * Boost Consulting
dave_at_[hidden] * http://www.boost-consulting.com