Hello Paul, Ralf, * Paul Eggert wrote on Wed, Jun 07, 2006 at 12:18:55AM CEST: > Ralf Corsepius <rc040203@xxxxxxxxxx> 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 non-@acronym{GNU} @command{make}, you should compile the package for one +With a non-@acronym{GNU} @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. _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx http://lists.gnu.org/mailman/listinfo/autoconf