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
This is not ruled out by any usage patterns we now have AFAIK, except
that possibly the other project might impose undesired inherited
>> > 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
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
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
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