Re: target references

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
reference remotely.

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

OK, understood.

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

Right. You might normally only go one level deep when doing that,
because the next level down can describe the mapping to *its*
subprojects.

> 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 ;" 
or something.

> 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
is "used"

> 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 
> mechanism.
>
> Do I understand your proposal correctly? If yes, then I think I find it 
> reasonable. 

I think you're close... :)
-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com