Re: [jamboost] Wrapping up new design

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
silly
> restriction. The way I did it on my shell script was to use $PWD and then
it's
> easy to tell when the filesystem runs out [$(PWD:P) == $(PWD)], but then
that
> 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
BIND
> >builtin rule which causes binding but doesn't include anything. It would
be
> >best if we could detect the difference between "found in the current
> >directory" and "not found". That may already be possible if you put "."
at
> >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
it's
> a variation of the current method to get at variable values. But a BIND
rule
> 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
to
> keep the same behaviour for found of just the filename, and to use
null/empty
> 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.

Yuck.

> And no putting "." in the SEARCH path doesn't return "./filename", it
returns
> "filename". And even more entertaining... putting "./" returns
".//filename",
> and "../../" returns "../..//filename", and finally putting "./." returns
> "././filename" :-\

Then we could do it with ././
Yuck #2.
I guess your idea of a BIND rule returning empty when the file isn't found
in SEARCH or LOCATE would be best.

-Dave