Hi Stefano,

On Tue, 2011 Nov  1 11:31+0100, Stefano Lattarini wrote:
>
> Wikipedia tells me that NeXTSTEP is now 16 years old, so I have a
> quite strong opinion against the possitility of tweaking/uglifying
> automake in order to support such an ancient and corner case system.
> My advice is that, if you want to continue using NeXTSTEP, you install
> GNU make and use it instead of the native make.
>
> I'm thus closing this bug report as "won't fix".  But if you more
> observations or remarks to add, feel free to  continue the discussion
> here (we can still re-open the bug report at a later date, if the need
> arises).

A few remarks:

* This isn't about NeXTSTEP, but more broadly about older make(1)
  implementations. NeXTSTEP is built on BSD; this is an old BSD make,
  so the same problem is likely to crop up on other old BSD and
  BSD-derived systems.

* All other aspects of the Automake-generated makefiles (that I've
  tried) are compatible with this old make. It's not like there are a
  number of other issues that would not be worth the effort to fix,
  just this one.

* The incompatibility here is particularly pressing, because if a
  package uses AM_SILENT_RULES, there is no way of configuring it that
  will hide away the nested variable references, and thereby the deadly
  parens. --disable-silent-rules only changes AM_DEFAULT_VERBOSITY. The
  situation would be different if this controlled some AM_CONDITIONAL-
  like logic that could comment out the troublesome constructs
  altogether, but that's not how it's implemented.

  (Running "make AM_V_CC=" isn't a solution either, because this make
  can't override variables defined in the makefile, let alone recursed
  makefiles. And users wouldn't know to do this anyway.)

* What is the cost/benefit to breaking compatibility here? Is avoiding
  uglification worth losing the ability to work with this old make?

  I do understand that sometimes, breaking compatibility with old
  systems can be a big win for flexibility. When the Autoconf folks
  decided that they would use shell functions in generated configure
  scripts instead of faking them via M4 macros, they lost the ability to
  run on museum-piece /bin/sh implementations (pre-dating NeXTSTEP) that
  don't know about functions. But they gained a useful construct for
  organizing and simplifying configure scripts whose value was more than
  worth the systems left out in the cold.

  I don't see what is being gained here that is worth the cost. For my
  part, I don't use Autotools because they are beautiful; I use them
  because they *work*.

* The patch to address this issue touches only two lines of code. (See
  attached, against automake-1.11.1)


--Daniel


-- 
Daniel Richard G. || skunk@iSKUNK.ORG
My ASCII-art .sig got a bad case of Times New Roman.