Re: target references

From: David Abrahams (dave_at_[hidden])
Date: 2004-07-15 10:35:36

Vladimir Prus <ghost_at_[hidden]> writes:

>> > Anyway, what I'm really trying to do (besides deciding on the right
>> > syntax), is avoid asking the users to update Jamfiles once again, so
>> > probably we need to support existing syntax (maybe even without
>> > docs) for quite some time.
>>
>> Yes, I was thinking the same thing. We could probably add a
>> command-line option that updates Jamfiles automatically ;-)
>
> That would be cool, though maybe hard.

Maybe. Probably not worth it, regardless.

>> > In some sense you need to somehow refer to all sub-projects from
>> > top-level Jamfile. For example, when installing you need the list of all
>> > libraries. In V1, that list is computed via GLOB magic -- which V2 can do
>> > as well -- but we still need the list of all libraries. And we we have
>> > it, we can load Jamfiles.
>>
>> 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?"

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

>> > In fact, because some requirements are inherited from Boost Jamfile,
>> > moving one project is not possible.
>>
>> Maybe not in the case of Boost, but perhaps in general?
>
> 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.

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

>> > That never was implemented, though I don't know why -- now it seems
>> > straight-forward task.
>>
>> Right now a top-level project needs to name each of its subprojects,
>> and each subproject needs to name itself. I think it would be
>> valuable to reduce the amount of redundancy in the system.
>
> 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?

That's an important use case.

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

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com