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

[Stefano Lattarini]

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 @address@hidden 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