Re: GNU Autoconf test version 2.59d available

[Ralf Corsepius]

On Tue, 2006-06-06 at 08:29 +0200, Ralf Wildenhues wrote:
> Hi Ralf,
> 
> * Ralf Corsepius wrote on Tue, Jun 06, 2006 at 05:44:00AM CEST:
> > On Mon, 2006-06-05 at 23:15 +0200, Ralf Wildenhues wrote:
> > > GNU Autoconf test version 2.59d is now available.
> > > 
> > > This is a beta release, intended to be largely identical to 2.60,
> > > to be released very soon, if no unexpected issues turn up.  So test it
> > > now, use it with your code, and report any remaining issues, please!  
> > > 
> > > The important changes since 2.59c are listed below, but two changes
> > > introduced earlier, in version 2.59c, require special attention:
> > > 
> > > * Some directory variables have been added, and others adjusted to
> > >   changes in the GNU Coding Standards.  If your package expands
> > >   '$datadir', '$infodir', or '$mandir' anywhere, you need to check your
> > >   package, and possibly adjust it accordingly.  The URL to the older
> > >   NEWS entries below, and the FAQ node 'Defining Directories' in the
> > >   manual have more information.
> > Hmm, I can't find this helpful, because
> 
> What exactly can you not find helpful?
OK, I assume I need to be more direct: I consider this to a severe
regression in autoconf and to be harmful to automake.


>   What are you referring to here?
> 
> > a) Makefiles are not autoconf's business.
> 
> We haven't changed much since 2.59c wrt. makefiles.
Then it's my fault of not having noticed this regression, earlier.

>   If you are using
> Automake, the changed directory variables (assuming you are referring to
> them) will be picked up automatically.  If you are using hand-written
> Makefile.in's, config.status will warn you for files you have not
> adjusted.
IMO, you are overengineering a problem from the wrong side.

If automake requires gmake for VPATH builds, then automake is in trouble
and automake will have to cope with it.

autoconf has no way to know what kind of problem a configure script is
trying to with. It doesn't know if it is going to generate Makefiles
from automake generated Makefile.ins, manually written GNUmakefiles,
Solaris Makefiles, BSD-make Makefiles, or if it generating any Makefile
at all, nor if/how a developer is trying to cope with VPATHS.

(Consider autoconf generating a "build-script" written in an arbitrary
scripting language).

> > b) Over the years, a tremendous amount of effort had been invested into
> > non-gmake VPATH support in automake. If something has crept into
> > automake that makes gmake necessary for VPATH-builds, I'd call this an
> > automake regression.
> 
> Nothing has changed here or crept in, except gained knowledge: things
> can go horribly wrong even without any Automake regression:
> http://lists.gnu.org/archive/html/bug-coreutils/2006-06/msg00033.html
This might apply to coreutils and further packages, but not depending on
gmake is on automake's list of objectives. 

=> If automake doesn't hold what it promises, it's a bug in automake and
automake's problem, not autoconf's problems, nor autoconf's task to deal
with it.

> > I recommend to reconsider this change.
> 
> Which change?  We intend to suggest to end-users to use GNU make for
> VPATH builds;
This is what I consider to be stupid. If you make gmake mandatory for
VPATH, you should ditch large parts of automake at the same time.

>  we should suggest to developers to write Makefile.am for
> portable make, however.  Would you agree with that?
No, I disagree. IMO, you are approaching the problem from the wrong
side.


Ralf