Re: detection and support of OpenMP

On Sun, May 27, 2007 at 10:53:06PM +0200, Bruno Haible wrote:
> Noah Misch wrote on Tuesday:
> > If we reach the stage of testing additional compiler options, the current $CC
> > $CFLAGS failed to compile the test program.  If that compiler treats `-openmp'
> > like `-o penmp', it will still fail to compile the test program.  Do we really
> > need this special care?
> > 
> > Possible simplifying patch:
...
> Well, your patch never got to trying the second, third, etc. possibility,
> due to the unconditional 'break'. I have tested the appended modified patch:
> it works with gcc (with result -fopenmp) and with Sun cc (with result -xopenmp),
> therefore I believe the other compilers will work as well. Also I added
> the necessary comments.
> 
> The good thing about your patch is that it gets rid of the compiler brand
> tests, thus the Fortran support should work fine with this version (untested).
> 
> 
> 2007-05-27  Noah Misch  <noah <at> cs.caltech.edu>
>             Bruno Haible   <bruno <at> clisp.org>
> 
> 	* lib/autoconf/c.m4 (AC_OPENMP): Use a simple loop instead of compiler
> 	brand tests.

Thanks for checking and revising the patch.  I installed it.

Re: Prefer AM_CPPFLAGS to <at> CPPFLAGS <at>

Hello,

>   I suggest a change to the Autoconf manual, see the patch below.

oops, by mistake I attached autoconf.texi instead of the patch.
I apologize for the huge mail.  Attached to this mail please find the
patch.

Stepan Kasal

2007-06-06  Stepan Kasal  <kasal <at> ucw.cz>

	* doc/autoconf.texi (Defining Directories): Mention
	AM_CPPFLAGS, as the way to modify CPPFLAGS, because most users
	use Automake.

Index: doc/autoconf.texi
===================================================================
RCS file: /cvsroot/autoconf/autoconf/doc/autoconf.texi,v
retrieving revision 1.1160
diff -u -r1.1160 autoconf.texi
--- doc/autoconf.texi	4 Jun 2007 22:49:42 -0000	1.1160
+++ doc/autoconf.texi	6 Jun 2007 08:40:55 -0000
 <at>  <at>  -19152,10 +19152,10  <at>  <at> 

  <at> item
 This solution can be simplified when compiling a program: you may either
-extend the  <at> code{CPPFLAGS}:
+extend the  <at> code{CPPFLAGS}, e.g., when using Automake:

Prefer AM_CPPFLAGS to <at> CPPFLAGS <at>

Hello,
  I suggest a change to the Autoconf manual, see the patch below.

For people which use the standard set of Autotools, this can be
pasted to the project, while the previous version was not optimal
(breaking override of CPPFLAGS for "make").

For the rare species of Autoconf without Automake users, this does
not hurt, as it does hide any info.  Those uses know well how to
``extend CPPFLAGS.''

OK to commit?

Stepan

Re: Prefer AM_CPPFLAGS to <at> CPPFLAGS <at>

Stepan Kasal <kasal <at> ucw.cz> writes:

> 	* doc/autoconf.texi (Defining Directories): Mention
> 	AM_CPPFLAGS, as the way to modify CPPFLAGS, because most users
> 	use Automake.

Thanks, please install.

Re: Prefer AM_CPPFLAGS to <at> CPPFLAGS <at>

Hi Stepan,

* Stepan Kasal wrote on Wed, Jun 06, 2007 at 11:04:27AM CEST:
> 
> --- doc/autoconf.texi	4 Jun 2007 22:49:42 -0000	1.1160
> +++ doc/autoconf.texi	6 Jun 2007 08:40:55 -0000
>  <at>  <at>  -19152,10 +19152,10  <at>  <at> 
>  
>   <at> item
>  This solution can be simplified when compiling a program: you may either
> -extend the  <at> code{CPPFLAGS}:
> +extend the  <at> code{CPPFLAGS}, e.g., when using Automake:
>  
>   <at> example
> -CPPFLAGS = -DDATADIR='"$(datadir)"'  <at>  <at> CPPFLAGS <at>  <at> 
> +AM_CPPFLAGS = -DDATADIR='"$(datadir)"'
>   <at> end example

Why not show both (the non-Automake case is useful and conveys
additional information)?

Cheers,
Ralf

Re: Prefer AM_CPPFLAGS to <at> CPPFLAGS <at>

Hello Ralf,

On Sun, Jun 10, 2007 at 09:13:14AM +0200, Ralf Wildenhues wrote:
> > -CPPFLAGS = -DDATADIR='"$(datadir)"'  <at>  <at> CPPFLAGS <at>  <at> 
> > +AM_CPPFLAGS = -DDATADIR='"$(datadir)"'
> 
> Why not show both (the non-Automake case is useful and conveys
> additional information)?

A nice idea, but:

It would make the node too complex.
The node "19.5 How Do I `#define' Installation Directories?" is in
the FAQ section, so people might expect it is short.

More importantly: The node explains that a naive AC_DEFINE hardwires
an incorrect path and (though there are ways to hardwire the correct
one (one of them is to let `make' compute the actual path (which can
be done either by extending CPPFLAGS (example 1) or by a make-created
header file (example 2)))) you rather should not hardwire paths at all.

And you are effectively suggesting to replace "example 1" by a pair
of examples.  I do not think this is a place where the information
should be added, at least as it stands now.

Have a nice day,
	Stepan

Re: configure: error: no acceptable C compiler found in $PATH (+possible solution)

Thanks for the bug report.  I audited Autoconf looking for PATH
glitches and installed this patch:

2007-06-13  Paul Eggert  <eggert <at> cs.ucla.edu>

	* lib/m4sugar/m4sh.m4 (_AS_PATH_SEPARATOR_PREPARE): Set FPATH too.
	Problem reported by Fred Kreek in
	<http://lists.gnu.org/archive/html/bug-autoconf/2007-06/msg00009.html>.
	* doc/autoconf.texi (Special Shell Variables): Warn about FPATH.
	(Macro Names, Defining Directories): Don't mention PATH as a name
	for a fully qualified file name, as this usage violates the GNU
	coding standards and we shouldn't recommend it.

	* lib/autotest/general.m4 (AT_INIT): Don't set PATH to the empty
	string and then assume shell builtins like "test" will work.

Index: lib/m4sugar/m4sh.m4
===================================================================
RCS file: /cvsroot/autoconf/autoconf/lib/m4sugar/m4sh.m4,v
retrieving revision 1.206
diff -u -p -r1.206 m4sh.m4
--- lib/m4sugar/m4sh.m4	30 Apr 2007 17:11:50 -0000	1.206
+++ lib/m4sugar/m4sh.m4	13 Jun 2007 16:52:19 -0000
 <at>  <at>  -1027,7 +1027,7  <at>  <at>  if test "${PATH_SEPARATOR+set}" != set; 
   echo "#! /bin/sh" >conf$$.sh
   echo  "exit 0"   >>conf$$.sh
   chmod +x conf$$.sh
-  if (PATH="/nonexistent;."; conf$$.sh) >/dev/null 2>&1; then
+  if (PATH="/nonexistent;."; FPATH=$PATH; conf$$.sh) >/dev/null 2>&1; then
     PATH_SEPARATOR=';'

Re: problem with $srcdir and friends in autotest

On Tue, Jun 12, 2007 at 10:41:44PM -0400, Mike Frysinger wrote:
> AT_SETUP([lot])
> AT_CHECK([
> "$builddir/lot" "$srcdir/lot.input" > lot.out
> bzcmp "$srcdir/lot.out.bz2" lot.out
> ], [0])
> AT_CLEANUP
> 
> the tests/ subdir looks like:
> tests/lot.c (lot is compiled)
> tests/lot.input
> tests/lot.out.bz2
> 
> building in tree works ok, but building out of tree yields:
> srcdir="../../tests/../.."
> 
> using $top_srcdir/tests/lot.input works though both in and out of tree ...

Thanks; the test suite was computing $srcdir incorrectly.  I installed this fix:

2007-06-13  Noah Misch  <noah <at> cs.caltech.edu>

	* lib/autotest/general.m4 (AT_INIT): Compute $srcdir correctly.
	* tests/autotest.at (srcdir propagation): New test.
	* THANKS: Update.
	Reported by Mike Frysinger.

diff -Nurp -X dontdiff ac-clean/lib/autotest/general.m4 ac-atsrcdir/lib/autotest/general.m4
--- ac-clean/lib/autotest/general.m4	2007-06-13 13:36:58.000000000 -0400
+++ ac-atsrcdir/lib/autotest/general.m4	2007-06-13 20:29:44.000000000 -0400

Re: configure: error: no acceptable C compiler found in $PATH (+possible solution)

Hello Paul,

One very small nit:

* Paul Eggert wrote on Wed, Jun 13, 2007 at 06:53:15PM CEST:

> 	* doc/autoconf.texi (Special Shell Variables): Warn about FPATH.
> 	(Macro Names, Defining Directories): Don't mention PATH as a name
> 	for a fully qualified file name, as this usage violates the GNU
> 	coding standards and we shouldn't recommend it.

> --- doc/autoconf.texi	4 Jun 2007 22:49:42 -0000	1.1160
> +++ doc/autoconf.texi	13 Jun 2007 16:52:20 -0000
>  <at>  <at>  -10479,8 +10479,6  <at>  <at>  Posix group owners of files.
>  Header files.
>   <at> item LIB
>  C libraries.
> - <at> item PATH
> -Absolute names of files, including programs.

What was this change for?  AC_PATH_PROG and the like still exist, no?

>   <at> item PROG
>  The base names of programs.
>   <at> item MEMBER

Cheers,
Ralf

Re: problem with $srcdir and friends in autotest

Hello Noah, Mike,

* Noah Misch wrote on Thu, Jun 14, 2007 at 03:40:55AM CEST:
> 
> Thanks; the test suite was computing $srcdir incorrectly.  I installed this fix:

Thanks for report and patch.  One nit:

> --- ac-clean/tests/autotest.at	2007-05-05 00:39:14.000000000 -0400
> +++ ac-atsrcdir/tests/autotest.at	2007-06-13 20:41:30.000000000 -0400
>  <at>  <at>  -415,3 +415,64  <at>  <at>  AT_CHECK_KEYS([-3], [none|first|second],
[...]

> +# Build directory totally outside source directory.
> +cd vpath-outside
> +AT_CHECK([top_srcdir=$abs_top_srcdir ../pkg/configure], [0], [ignore])

You could additionally try
  `pwd`/../pkg/configure

> +cd t
> +AT_CHECK([../../pkg/t/suite], [0], [ignore])
> +cd ../..
> +
> +# Build directory as subdirectory of source directory.
> +cd pkg/vpath-inside
> +AT_CHECK([top_srcdir=$abs_top_srcdir ../configure], [0], [ignore])
[...]

and `pwd`/../configure (and fix the test failures that show up