GNU bug report logs -
#13524
Improving user experience for non-recursive builds
Previous Next
Reported by: Miles Bader <miles <at> gnu.org>
Date: Tue, 22 Jan 2013 09:20:02 UTC
Severity: wishlist
Tags: patch
Done: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Bug is archived. No further changes may be made.
Full log
Message #101 received at 13524 <at> debbugs.gnu.org (full text, mbox):
On 02/05/2013 12:03 AM, Peter Rosin wrote:
> On 2013-02-04 19:11, Stefano Lattarini wrote:
>> On 02/04/2013 06:33 PM, Eric Blake wrote:
>>> So they aren't quite affected by configure, but they are dependent on
>>> relative location, just like existing substitutions like @top_srcdir@
>>> are dependent on relative location.
>>>
>> Yes, but they are dependent on the relative position of an 'include'd
>> file w.r.t. the currently-processed Makefile.am, not the "top-level"
>> directory of the project. Not a big deal, but still, another minor
>> possible source of confusion, as in "all the same @subst@ in a Makefile.in
>> are substituted with the same text, even if they come from an automake-time
>> included fragment ... except for the @am_reldir@ etc. substs"; not a big
>
> To me, you are splitting hairs. However, I do see one strongish argument
> against @am_reldir@. The short forms (@D@ and @C@) will potentially
> break any project already doing AC_SUBST([C]) (or D). And @am_D@, @AM_D@
> or whatever isn't all that pretty. So, we can't really use @am_reldir@,
> because then we'll have to find some other notation for the short form.
> And that would be confusing. Or drop the short form, but we all want
> the short form, right?
>
>> deal, but not a great example of cleanliness and consistency either IMVHO).
>
> Having umpteen different replacement operators isn't all that minimal
> and neat either IMVHO.
>
Fine (see below for more).
> Anyway, summing up.
>
> 0. &{reldir}& is a pest to type.
> 1. {reldir} doesn't work, it conflicts with ${reldir}.
> 2. @am_reldir@ doesn't work, short form @D@ conflicts with AC_SUBST([D]).
>
Plus is conceptually confusing/misleading, IMVHO.
> 3. {am_reldir} doesn't work, short form {D} conflicts with ${D}.
>
> It is clear that we have to invent a new notation, much as I hate it.
> Whatever notation we try to overload is likely have a conflict when
> we mix in the short form.
>
> So, %reldir% is best so far IMHO, but if Automake developers are
> too easily confused
>
(in hindsight, I probably overemphasized the risk of confusion here)
> or if we don't control that namespace, I'd go
> with {{reldir}}.
>
I don't have a strong opinion about '{{...}}' vs '%...%' [1]; I marginally
prefer the former, but if people prefer the latter (as your and Miles'
messages suggest), I'm *perfectly* fine to use it as well.
So, shall we go for '%...%' in the end?
[1] OTOH, I'd have strongly preferred '{...}' over '%...%'; but alas,
as we've seen, this shorter and sweeter syntax remains unusable
if we want to avoid collisions and confusions with the ${FOO}
form for make and shell variable expansions.
> Oh, while I'm at it I have a wish, {reldir}/@am_reldir@/whatever is so
> much easier on the eyes compared to {RELDIR}/@AM_RELDIR@/WHATEVER. Can we
> please skip the capital letters in the naming that is finally decided?
> (using capital letter for the short form is fine though)
>
Fine as well. And of curse, if you want to speed thing up and have more
control on the final result, feel free to shepherd the pending patches to
the agreed form ;-) -- which if I'm not mistaken is:
- make the series consist of only two patches, one introducing the
feature (complete with documentation and NEWS additions, plus your
original test case), and one follow-up patch implementing my
testsuite enhancement;
- use the '%...%' form, and prefer lower-case for long names (so,
'%reldir%' a.k.a. '%D%' and '%canon-reldir%' a.k.a. '%C%').
Thanks,
Stefano
This bug report was last modified 12 years and 131 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.