From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-01-03 16:37:07
----- Original Message -----
From: "Rene Rivera" <grafik666_at_[hidden]>
> Yea, I thought about that, and picking a max depth seems to me like a
> restriction. The way I did it on my shell script was to use $PWD and then
> easy to tell when the filesystem runs out [$(PWD:P) == $(PWD)], but then
> is not a portable solution.
There are other reasons why it would be useful to be able to translate a
path from relative to absolute. Maybe you should just add that capability.
> >3. Maybe the best approach for what you want to do would be to make a
> >builtin rule which causes binding but doesn't include anything. It would
> >best if we could detect the difference between "found in the current
> >directory" and "not found". That may already be possible if you put "."
> >the end of the SEARCH path, since you'd get ./<filename> instead of just
> ><filename> if the file were found.
> In that case, what would you prefer? I like the $(X:V=Y) approach because
> a variation of the current method to get at variable values. But a BIND
> more directly expresses what is actually going on.
Yes, but the real downside to your idea is that it won't work ;-(
There is no variable on a target which corresponds to its location,
especially not before it is bound.
> As for detecting "found in current directory" vs. "not found", choices are
> keep the same behaviour for found of just the filename, and to use
> when not found.
That seems like a plausible approach.
> If implemented as a BIND rule then having return a value of
> BOUND/UNBOUND might also be possible, if the bind is a side-effect.
> And no putting "." in the SEARCH path doesn't return "./filename", it
> "filename". And even more entertaining... putting "./" returns
> and "../../" returns "../..//filename", and finally putting "./." returns
> "././filename" :-\
Then we could do it with ././
I guess your idea of a BIND rule returning empty when the file isn't found
in SEARCH or LOCATE would be best.
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