From: David Abrahams (dave_at_[hidden])
Date: 2004-07-16 11:38:35
Vladimir Prus <ghost_at_[hidden]> writes:
> David Abrahams wrote:
>> >> I understand... but do you think that's a good idea? If there were
>> >> some rules for searching based on project path it would reduce the
>> >> burden of project maintenance and the chance of error.
>> > What is good idea? Implementing automatic search for library Jamfiles
>> > like V1 install does. Yes, I think this is reasonable and we should do
>> > it.
>> No, what I mean is, "do you think the design where a top-level Jamfile
>> needs to refer to all sub-projects is a good idea?"
> I think for cases like installing this is necessary thing.
Not if you don't have to build all sub-projects for an install.
Don't forget that for example in Boost there are tests and tools.
> Probably you meant
> if it's good thing to *explicitly* refer to all sub-projects. I think such
> design is OK, since it explicitly specifies which projects you want
> to build.
...and all the ones you don't want to build but might want to
> Providing some way to
> - automatically build all children project,
> - locate subprojects by 'id' or auto-compute subproject ids
> would be good.
I would rather see us allow the user to:
- compute the names of subprojects that need to be built
- compute the names of subprojects that need to be installed
(these two could be as easy as allowing them to use [ glob ... ]
in the build/install specification)
- locate subprojects by 'id'
I don't know what "auto-compute subproject ids" means, but I don't
think it's needed if we have the above.
>> > I suspect that having project-wide requriements in top-level Jamfile
>> > is likely to be general practice. At least that's what I do in my
>> > project, and Jurgen's testcases (which, I believe, are based on his
>> > project), show the same.
>> I agree; I was not talking about de-coupling subprojects, but about
>> organizing top-level projects as subprojects.
> In the case of top-level projects, each one has project-root.jam, which blocks
> attributes inheritance from higher-level Jamfiles, if any. So, the only thing
> which can be done is 'use-project'.
> I wonder if this should be changed: i.e. drop a local copy of Boost in my
> project and have id automatically changed from /boost to /nm_model/boost.
Probably not, IMO. You can still put it in the subtree, and
use-project can still refer to a subdirectory.
>> >> > Likewise, I did not plan that -- or rather, did not though -- about
>> >> ^^^^^^
>> >> "think"?
>> > Yes.
>> FWIW, "though" is pronounced like "sew", "sow", and "though" (crazy
>> English language!) while "thought" (past tense of "think") is
>> pronounced light "ought", "taught", and "wrought". They are so
>> different to a native speaker that most people are unlikely to make a
>> connection between "though" and "think".
> The problem is that "though" and "thought" differs by a single letter, which
> makes we often mistype them. And stupid spellcheckers won't care.
Sure. Just trying to help.
>> > This is common behaviour, so maybe the rule to find and subprojects
>> > (needed for "install"), can have general utility.
>> > But I believe it's possible to want to build only *some* subprojects, so
>> > we need to retain explicit control.
>> Of building, yes. Not of project composition, IMO.
> So, the user can control the id of top-level project
For project-local purposes, at least. When another project refers to that
top-level project it can assign its own id. I guess you could
consider that an override
> and the rules which map ids relative to top-level project into
Right. You might normally only go one level deep when doing that,
because the next level down can describe the mapping to *its*
> But directories themself have no control on project ids, right? In
> fact, the "id' parameter to the 'project' rule would be deprecated.
Not exactly, I think. At the top level of boost we'd want to say
"I'm boost" so that:
a. all my subprojects can refer to project boost/whatever.
b. remote projects can say "use-project some/directory/boost_1_31_0 ;"
and get the name "boost" for that project if they don't
override it by saying
"use-project some/directory/boost_1_31_0 : boost-1.31 ;"
> Interesting.... let me see:
> 1. For Boost, this scheme will work OK.
> 2. For my project, this will work OK.
> 3. There are cases when we still need ids for projects: e.g. qt.jam and
> actually any toolset module which exposes some targets (in case of qt, after
> "using qt; " one can use " /qt//qt " everywhere. Guess that for this cases we
> can retain ability to specify absolute ids.
Let's just make the id a default that can be overridden locally by any
other project that wants to "use" the project.
> So, most top-level project will specify "local" ids. When building those
> projects, local ids will also become global one, so Boost Jamfile will have
> project boost
> and when building Boost, there will be also global id "/boost". When project
> is used via "use-project", this local id remains local.
Yes, except that I think there's really no such thing as a global
id. It's just a question of which local id is chosen when a project
> So, essentially we'll have a global name->top-level Jamfile map, and project
> lookup below top-level name will be performed using some additional
> Do I understand your proposal correctly? If yes, then I think I find it
I think you're close... :)
-- Dave Abrahams Boost Consulting http://www.boost-consulting.com
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