[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#13524: Improving user experience for non-recursive builds
From: |
Peter Rosin |
Subject: |
bug#13524: Improving user experience for non-recursive builds |
Date: |
Thu, 24 Jan 2013 13:22:45 +0100 |
User-agent: |
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 |
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
0001-curdir-add-support-for-relative-names-in-included-fr.patch
Description: Text Data
- bug#13524: Improving user experience for non-recursive builds, Stefano Lattarini, 2013/01/22
- bug#13524: Improving user experience for non-recursive builds, Peter Rosin, 2013/01/22
- bug#13524: Improving user experience for non-recursive builds, Stefano Lattarini, 2013/01/23
- bug#13524: Improving user experience for non-recursive builds, Peter Rosin, 2013/01/23
- bug#13524: Improving user experience for non-recursive builds, Stefano Lattarini, 2013/01/23
- bug#13524: Improving user experience for non-recursive builds,
Peter Rosin <=
- bug#13524: Improving user experience for non-recursive builds, Peter Rosin, 2013/01/25
- bug#13524: Improving user experience for non-recursive builds, Peter Rosin, 2013/01/26
- bug#13524: Improving user experience for non-recursive builds, Stefano Lattarini, 2013/01/27
- bug#13524: Improving user experience for non-recursive builds, Peter Rosin, 2013/01/27
bug#13524: Improving user experience for non-recursive builds, Miles Bader, 2013/01/23