bug#13524: Improving user experience for non-recursive builds

[Peter Rosin]

On 2013-01-24 13:22, Peter Rosin wrote:
> 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? :-)

Zapping the NIH part reduced the code size significantly (the patch
is now short, sweet and unintrusive again) so I'm posting a new version.
After all, it's a new day, right?

I hope it's ok to use File::Spec->abs2rel () in Automake?

BTW, let me know if I should trim the CC list.

Cheers,
Peter

0001-curdir-add-support-for-relative-names-in-included-fr.patch
Description: Text Data