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: Peter Rosin <peda <at> lysator.liu.se>
Cc: 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 12:33:33 +0100

On 02/04/2013 10:35 AM, Peter Rosin wrote:
> On 2013-02-04 00:10, Peter Rosin wrote:
>> On 2013-02-03 21:42, Stefano Lattarini wrote:
>>> I've pushed the promised patches to the rewindable branch
>>> 'experimental/preproc' (based off of maint).  I'll also soon
>>> send them to the list to simplify review (I will drop the
>>> bug tracker from CC:, to avoid cluttering up the report).
>>>
>>> As usual, reviews are welcome.
>>
>> I like the end result of this series, I especially like that I don't have
>> to type &{this}& anymore.
> 
> *snip*
> 
> Oops, a couple more things. The new naming will clobber
> anyone using a Makefile variable named RELDIR with brace
> syntax.
Yikes, I didn't think of that.  *blush*

> E.g., this previously working code is broken by
> the series.
> 
> RELDIR = src
> foobar_CPPFLAGS = $(AM_CPPFLAGS) -DRELDIR=${RELDIR}
> 
> It will be preprocessed into
> 
> RELDIR = src
> foobar_CPPFLAGS = $(AM_CPPFLAGS) -DRELDIR=$src
>
Ouch.

> and quasi-expanded into (assuming $s is empty)
> 
> foobar_CPPFLAGS = $(AM_CPPFLAGS) -DRELDIR=rc
> 
> Not sure what to do about it, or if it matters...
>
It does IMHO, since the failure you pointed out, albeit easy to
work around, wouldn't be very obvious to diagnose, from the point
of view of a non-particularly-expert user.

What about doubling the curly braces?  As in '{{RELDIR}}'.
Would that be tolerable?  Other possibilities (none particularly
pleasant either, IMHO):

  {+RELDIR+}
  {:RELDIR:}
  {.RELDIR.}
  {-RELDIR-}

Other proposals?

> 
> Further, the use of /dev/full in the demo test is not
> portable. If I create /dev on Windows (i.e. C:\dev, or have
> it previously, I didn't, but not unlikely), and am allowed
> to write there (likely, on Windows), and /dev/full isn't
> supported (where is it supported, except Linux?), then the
> test falls apart. The MinGW program happily writes "dummy"
> to /dev/full (i.e. C:\dev\full from its view of the file
> system) but the MSYS script does not think /dev/full is a
> character device and it is not be allowed to write to
> /dev/full either, because typically /dev doesn't exist as
> a real directory. Typically /dev is virtual in MSYS (if it
> existed, it would be C:\MinGW\msys\1.0\dev from the MSYS
> view of the file system) so it assumes the MinGW program
> skipped, but it didn't.
> 
> Why use special features like /dev/full in the testsuite of
> Automake? Surely there are better things one can do to check if
> a Makefile works. Mixing in stuff like that is just a recipe
> for strange bug reports and hardship for those on weird
> platforms. The gain for Automake is zero.
> 
> Also, creating the file /dev/full with content "dummy" is
> bad manors, even if someone runs the testsuite as root (on a
> system not supporting /dev/full) and arguably deserves it.
>
Mostly agreed; I tried to create the test as a reasonable
demo mimicking real-world packages, but I've probably gotten
carried too far, for no real advantage (but with potential
lurking issues down the road).  I will simplify the test.

Thanks,
  Stefano

Previous Next

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