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

[Peter Rosin]

On 2013-01-25 17:03, Peter Rosin wrote:
> 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?

This time with documentation and a NEWS entry. I also fixed the case
of including something above the current base Makefile.am with a
relative path, e.g.:

        include ../top.mk

That change shaved a couple of more lines. Neat.

I also rebased it, so now it is against master.

Cheers,
Peter

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