bug-automake
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Stefano Lattarini
Subject: bug#13524: Improving user experience for non-recursive builds
Date: Mon, 04 Feb 2013 18:19:45 +0100

On 02/04/2013 03:06 PM, Peter Rosin wrote:
> On 2013-02-04 14:43, Stefano Lattarini wrote:
>> On 02/04/2013 01:04 PM, Peter Rosin wrote:
>>> I {{think}} this one will be the easiest on us all.
>>>
>> I tend to agree (but see Peter Johansson's proposal to use
>> {AM_RELDIR} instead; what do you think about it?)
> 
> Well, I had @am_reldir@ in my original patch, so obviously I'm
> not totally against the am_ prefix, but I did think it was too
> long. You didn't really say in what way using @ was bad?
>
Yes, and I stand by that.  The proposal here was to use {AM_RELDIR},
not @address@hidden

> This might be the time to revisit that, so that we can come full
> circle on this issue? :-)
>
Not really.

> But seriously, why would it be bad
> to use @ for something that is not going to be seen by
> config.status anyway? 
>
Because it would mix up very different concepts: a '@...@' substitution
is meant for something that depends on configure-time check (or at
least from code in configure), and is substituted the same in *every*
Makefile and makefile fragment; while the proposed '{...}' would depend
merely on the relative position of the included fragment, and have
nothing to do with configure code or configure-time checks.

> Because grepping the source becomes
> 'difficult'? Trouble documenting? Users expecting to be able
> to AC_SUBST? What?
>
To summarize: conceptual confusion.

> You also suggested %percent% way back when but didn't like it.
>
Again, it would cause confusion between automake-time substitutions
in the private makefile fragments 'lib/am/*.am' (invisible and
transparent to the user) and substitutions meant to be visible and
actively employed by the user; albeit in this case only automake
developers would be exposed to this source of confusion, so the
situation wouldn't be nearly as bad.

> How bad was that?
>
Honestly, something like:

   %RELDIR_CANON%_foo_SOURCES = ...

seems quite ugly to me; albeit

   %RELDIR-CANON%_foo_SOURCES = ...

seems a little better.  But I still prefer the "substitution starts",
"substitution ends" hinted at by the symmetric '{' and '}' characters

> What about §reldir§ (not ascii, so I guess
> not) or [reldir]? Are square brackets legit in a Makefile for
> anything?
>
Anyone using '[FOO]' in a make variable name probably deserve to suffer,
and uses of  the'[C]' or '[D]' literal strings in recipes or variables'
expansions should be rare enough not to cause real problems (and such
problem could be easily worked around anyway).  I still marginally prefer
'{{...}}', but happily I'll go with '[...]' instead if its proponents
rewrite the patch series for me (hint hint, nudge nudge).  Anyone
actually painting the shed gets to choose its color :-)

> If we do go with the prefix, do we really want to advertice
> so obviously? I mean, {AM_D}, come on... :-)
>
Ah, LOL.  And the use of namespace in the shorthands would destroy their
beauty and handiness ...

> I don't really care, just pick something that works. And stick
> to it.
> 
> Cheers,
> Peter
> 

Regards,
  Stefano





reply via email to

[Prev in Thread] Current Thread [Next in Thread]