Re: [jamboost] Re: target references

From: Vladimir Prus (ghost_at_[hidden])
Date: 2004-07-19 10:54:53

David Abrahams wrote:

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

Ok, I get you. Though we'd still need to enumerate all libraries.

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

Understood.

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

Okay, sounds reasonable.

> I don't know what "auto-compute subproject ids" means, but I don't
> think it's needed if we have the above.

I meaning adding prepending boost "boost" to project-ids of all libraries.

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

Ok.

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

And it's very appreciated!

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

Would every project be required to provide such mapping? I guess if it does 
not, it can just "build-project" all child projects?

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

Okay.

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

Agreed.

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

I think we'd still want global ids. Suppose I have 10 projects which use 
boost. They use ids like "/boost/foobar". I would like to put a single line 
to my user-config.jam which tells the location of Boost, and don't configure 
those 10 projects whenever I decide to rearrange my directories again.

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

Ok ;-) 

I think there are some questions to be solved yet:

1. Should we retain ability to specify absolute ids in 'project' rule 
invocation. What are we to do if this id has several components? E.g. will 
"/boost/foobar", be looked up by searching global id "/boost/foobar", or 
asking project "/boost" for subproject "/foobar".

2. What's the syntax to specify id->dir mapping? Just function in Jamfile?

3. Maybe something else I forgot

- Volodya