From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-02-28 14:44:37
----- Original Message -----
From: "witt_ive" <witt_at_[hidden]>
Sent: Thursday, February 28, 2002 2:10 PM
Subject: [jamboost] Re: patch boost-base.jam project wide settings
> --- In jamboost_at_y..., "David Abrahams" <david.abrahams_at_r...> wrote:
> > Maybe it makes sense to use C++-style, rather than Python-style
> > for these things. IOW, the names would be available without
> qualification to
> > all subprojects of a given project.
> I do not like this idea. It would let us end up with three different
> namespacing schemes
> 1 variant (global)
> 2 requirement (C++ like)
> 3 target (Python like)
> This would be an 50% increase in complexity compared to the current
> system, with small if any benefit.
1 is just a special case of 2.
Furthermore, we have already decided to implement default requirements
inheritance from projects to their subprojects and targets, so it's not a
> As I can see introducing option 2 does not solve any real problem.
It solves the problem that occurs when:
1. multiple-project builds use the same template name
2. The projects are large enough that writing <requirements>../../../my-reqs
is cumbersome compared to <requirements>my-reqs.
> Subprojects do know the path to the root anyway its in the
> sub-project rule. Even if the sub-project rule is eliminated
That is planned.
> one can
> reasonably assume knowledge about a certain part of the tree
Yes, but it does make one more thing for people to get right.
> And to be safe no project should try to grab beyond this
> known part of the structure. To me this is just too clever.
You may be right that it's not worth the extra complexity, but I am not yet
convinced. Using the system should be really comfortable for people, and IMO
the less people have to write long relative paths the more comfortable it
> I recently introduced boost jam with templates to a colleague. He
> installed a jam build system with templates in his project after a
> 30s introduction to the template feature. The introduction goes like
> this: "Works like target dependencies, copies req's.". This might
> indicate that handling req's like targets fits with the rest of the
Fantastic! Seriously, I really like that there's an analogy, but a
requirement set is /so/ different from a target. There are neither sources,
nor target files, nor dependencies. It seems to me that requirement sets
will be most useful when given (sub)project scope.
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