GNU bug report logs - #13524
Improving user experience for non-recursive builds

Previous Next

Full log

View this message in rfc822 format

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Eric Blake <eblake <at> redhat.com>
Cc: Peter Rosin <peda <at> lysator.liu.se>, Karl Berry <karl <at> freefriends.org>, 13524 <at> debbugs.gnu.org, "automake-patches <at> gnu.org" <automake-patches <at> gnu.org>, Miles Bader <miles <at> gnu.org>
Subject: bug#13524: Improving user experience for non-recursive builds
Date: Mon, 04 Feb 2013 19:11:50 +0100

On 02/04/2013 06:33 PM, Eric Blake wrote:
> On 02/04/2013 10:19 AM, Stefano Lattarini wrote:
>> 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;
> 
> Not so - in the section on preset output variables, autoconf documents
> that several @...@ substitutions are dependent on where in the hierarchy
> they are replaced (generally, the variables with all lower-case names).
> 
> https://www.gnu.org/software/autoconf/manual/autoconf.html#Preset-Output-Variables
>
OK, I stand corrected.  And while stuff like '@top_srcdir@' still depends
on the details of how configure is run, other stuff like '@top_builddir@'
actually depends *only* on the relative position of the file it is
being instantiated.  However, see below.

>> 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.
> 
> 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
deal, but not a great example of cleanliness and consistency either IMVHO).

> That said, the idea of using some syntax other than @...@ for automake
> substitutions, to make it clear that they are different than
> config.status substitutions, works for me.
>
I still marginally prefer to keep this distinction, so, since you seem
to have no fundamental objection, I'll stick to it.

> I just don't know that I
> have any better ideas for what syntax to prefer.
> 

Thanks,
  Stefano

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.