On 2013-01-23 16:08, Stefano Lattarini wrote:
> On 01/23/2013 03:34 PM, Peter Rosin wrote:
>> On 2013-01-23 13:45, Stefano Lattarini wrote:
*snip*
>>> Too much automagic here IMO.  We'd better have two distinct subst, one for
>>> the "real" directory name, and one for the directory name "canonicalized"
>>> for use in Automake primaries.  I.e., from:
>>
>> The gain was that the '.' case needs to peak at, and perhaps eat, the
>> trailing separator anyway (or it will look bad, I mean, who wants __foo
>> after writing &{CANON_CURDIR}&_foo and curdir happens to be '.'?)
>>
> Good point.  We should allow the user to write something like
> "&{CANON_CURDIR}&foo_SOURCES" instead, so that it can work for the
> current directory too; not much important for human-written makefiles,
> but might be for autogenerated ones (I'm thinking ahead about a Gnulib
> integration here; the current support for non-recursive projects
> there is quite hacky, and could benefit from this new feature).

Are you saying that &{CURDIR}& should be replaced with the empty
string when the current relative directory is "." and the current
relative directory followed by a slash otherwise? (And similar, but
with a trailing underscore for &{CANON_CURDIR}&) I don't fancy
that, as I think &{CURDIR}&gazonk.c is that much harder to read than
&{CURDIR}&/gazonk.c.

So, I'd rather have the magic extend beyond the }& even if that is
ugly indeed. Maybe I'm just deluded to want that...

Or, do you mean that &{CURDIR}& should peak ahead and only add a
trailing "/" if it is not followed by a slash (or whitespace?)
already, making "&{CURDIR}&foo.c" and "&{CURDIR}&/foo.c" equivalent
except when &{CURDIR}& is "." (which would come out as "foo.c" and
"./foo.c" respectively)?

*snip*
> Thanks, I'll take a look at it tomorrow.

Another day, another version. I hope you didn't wast too much time
on v2...

I changed to &{CANON_CURDIR}& and &{CURDIR}&, added support for
$(top_srcdir) and improved the test. There's more code due to the
$(top_srcdir) support, and maybe there are some preexisting
functionality that strips common leading directory components that
could have been reused, but I'm ignorant. Besides, what's wrong
with NIH? :-)

Cheers,
Peter