automake
[Top][All Lists]
Advanced

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

recommendation for GNU make (was: GNU Autoconf test version 2.59d availa


From: Ralf Wildenhues
Subject: recommendation for GNU make (was: GNU Autoconf test version 2.59d available)
Date: Mon, 12 Jun 2006 19:56:40 +0200
User-agent: Mutt/1.5.11+cvs20060403

Hello Paul, Ralf,

* Paul Eggert wrote on Wed, Jun 07, 2006 at 12:18:55AM CEST:
> Ralf Corsepius <address@hidden> writes:
> 
> > The sub-sentence I consider to be wrong is this:
> >
> >   INSTALL now suggests VPATH builds (e.g., "sh ../srcdir/configure")
> >   only if you use GNU make.
> 
> This is merely a sentence taken from the NEWS file for Autoconf.  It
> isn't a constraint on Autoconf's (or Automake's) behavior; it's not
> even part of the documentation proper.
> 
> I think your real beef here is with the documentation, not with the
> news bulletin about it.  If so, it would be helpful to suggest
> specific wording that would improve the documentation.

I've thought a bit about this, and I agree more with Ralf Corepius'
concerns.  Coreutils simply needed to adjust to limitations of portable
make, and Automake should document this more prominently.

> Here's what the documentation currently says (in the INSTALL file):
*snip*

> For example, would it be OK if we simply changed the "should"s to
> "can"s?  If not, then what extra wording do you suggest?  Please bear
> in mind that the wording needs to be concise, accurate, and clear to
> non-experts.

Yes, using "can" seems better.  See a proposed patch below.

> By the way, I just now went through the Autoconf manual and found
> several examples containing makefile rules that won't work with
> Solaris make in a VPATH build.  I got tired of looking for them, so I
> haven't prepared a patch, but my favorite was this one:
> 
>         f.c: if.c
>                 cp `test -f if.c || echo $(VPATH)/`if.c f.c
> 
> This is in code that is _trying_ to be portable to Solaris make, and
> yet the expert author still messed up!  I suspect that bugs are quite
> common in this area, and we will be doing non-experts a service by
> steering them away from Solaris make for VPATH builds.

Well, I think the example is out of its context.  If one reads the whole
"Limitations of Make" section, one gets the correct impression of an
evolving rule that takes more and more limitations into account.  I'd
agree that this isn't the best way to describe these things, as users
would do it alike and pick just the example they see together with the
issue they are currently interested in.  But it's not like the section
gives wrong advice per se, it's just not as clear as it could be.

Anyway, here's the proposed patch.  Can we agree on this, and finish
up this topic for now?

Cheers,
Ralf


        * doc/install.texi (Compilers and Options): Weaken the
        suggestion to use GNU make for VPATH builds.

Index: doc/install.texi
===================================================================
RCS file: /cvsroot/autoconf/autoconf/doc/install.texi,v
retrieving revision 1.47
diff -u -r1.47 install.texi
--- doc/install.texi    4 Jun 2006 07:38:29 -0000       1.47
+++ doc/install.texi    12 Jun 2006 16:31:46 -0000
@@ -104,13 +104,13 @@
 
 You can compile the package for more than one kind of computer at the
 same time, by placing the object files for each architecture in their
-own directory.  To do this, you should use @acronym{GNU} @command{make}.
+own directory.  To do this, you can use @acronym{GNU} @command{make}.
 @command{cd} to the directory where you want the object files and
 executables to go and run the @command{configure} script.
 @command{configure} automatically checks for the source code in the
 directory that @command{configure} is in and in @file{..}.
 
-With a address@hidden @command{make}, you should compile the package for one
+With a address@hidden @command{make}, it is safer to compile the package for 
one
 architecture at a time in the source code directory.  After you have
 installed the package for one architecture, use @samp{make distclean}
 before reconfiguring for another architecture.




reply via email to

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