From: Vladimir Prus (ghost_at_[hidden])
Date: 2004-12-14 10:16:37
On Friday 10 December 2004 20:59, David Abrahams wrote:
> >> 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.
So, after computing build dir location for a project, we'll load something
from there and check if two project location --- current and recorded in a
file? That seems possible.
> >> 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.
There's a problem I see with computing build directory from project id
specified in "use-project". At the moment, build dir location is a property
of a project. So, when --build-dir is specified, we'd need to get all
"use-project" directives and modify build directories for the affected
projects. Workable, but not nice.
And what if you have
use-project boost : /home/ghost/Work/boost ;
use-project boost-1.32 : /home/ghost/Work/boost ;
Should this be an error? (Not that this is likely use case, but still we need
to consider this)
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