Re: [jamboost] Re: target references

From: Vladimir Prus (ghost_at_[hidden])
Date: 2004-07-16 09:27:30

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. 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. 
Providing some way to

- automatically build all children project, 
- locate subprojects by 'id' or auto-compute subproject ids

would be good.

> >> Maybe it was Ali. I distinctly remember discussing the idea that an
> >> existing "top-level" project could be moved into another project as a
> >> sub-project.
>
> This is not ruled out by any usage patterns we now have AFAIK, except
> that possibly the other project might impose undesired inherited
> attributes.

....

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

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

> > In general, top-level project need to name subproject only if it want
> > them to be automatically build when you build top-level project.
>
> ...or if you want to be able to refer to the subproject foo/bar/baz from an
> unrelated project after doing a use-project only for the top-level
> project foo?

Yes.

> That's an important use case.

Agreed.

> > 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, and the rules which map 
ids relative to top-level project into directories. But directories themself 
have no control on project ids, right? In fact, the "id' parameter to the 
'project' rule would be deprecated.

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.

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.

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. 

- Volodya