Re: [v2] ALL_LOCATE_TARGET capability?

From: David Abrahams (dave_at_[hidden])
Date: 2004-12-10 12:59:58

Vladimir Prus wrote:
> On Friday 10 December 2004 19:14, David Abrahams wrote:
>> Vladimir Prus wrote:
>>> Another remark about --build-dir. We cannot use declare id of the
>>> project, because it can lead to clashes when you have two copies
>>> of the same project. Imagine:
>>> 
>>> cd my_project bjam --build_dir=foo --with_boost=1.32 bjam 
>>> --build_dir=foo --with_boost=cvs
>>> 
>>> If build location for boost does not encode project location,
>>> we'll be building both boosts to the same place....
>> 
>> I thought of that. Here are several solutions that can be used
>> together:
>> 
>> 1. keep a record of the directory of each project that was used to
>> build into a given target directory. Issue a prominent warning or
>> error if that directory changes, with instructions about deleting
>> the marker file.
> 
> Ouch. The implementation might get contrived.

C'mon, that's *easy* to do, and reasonable as well. The marker file can
just contain Jam code. You import it and you're done.

>> 2. Institute my target reference scheme that allows project
>> renaming (**), and use the ID assigned from the place where the
>> build was initiated to determine the target directory.
> 
> Well, we've agreed to use this scheme anyway.
> 
>> 3. Encourage versioned project IDs, so boost would expose itself as
>> boost-1.32.0//, and *that* would be used as a target directory
>> name.
> 
> But that won't prevent innocent user from shooting itself.

That's what #1 is for.

>> 4. Allow primary and secondary project IDs, so people who want to
>> can refer just to the secondary project ID (boost//)
> 
> Hmm.. I'd rather not compicate projects ID further.

I don't think this is really complicated. It's just a project alias. I
think it's important if anyone wants to use versioned project IDs
because they'll want to use the alias internally to that project anyway
for maintenance reasons.

>> 5. As a last resort, a command-line option that allows users to
>> direct the build directory of any project. I'm not at all certain
>> this is needed if you have #2.
> 
> Neither do I. I think that either #2 or my global dir proposal can
> solve this.
> 
>> (**) Yes I know I need to document it. It's a bit hard to
>> understand where any piece of documentation fits in because I don't
>> really understand the BBv2 documentation structure. If you can
>> make a suggestion I'll get right to it.
> 
> I think it would fit either in
> 
> http://boost.org/boost-build2/doc/html/bbv2/reference/definitions.html#bbv2.reference.ids
> 
> 
> (where target-id syntax is defined)
> 
> or
> 
> http://boost.org/boost-build2/doc/html/bbv2/advanced/jamfiles.html#bbv2.advanced.projects
> 
> 
> (where use-project rule is mentioned).

Thanks.

> In either way, content is much more important (at least for me), then
> the exact place in docs.

I understand that, but the docs are getting to be a scattered sprawl
with little or no coherent organization. It's very unclear where you'd
go to find out any particular answer you need. That needs to be not
only stopped, but repaired. So I really don't want it to get worse.

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