Ralf Wildenhues | 1 Jun 2006 07:27
Picon
Picon

Re: Debian-specific Autoconf patches

Hi Paul,

* Paul Eggert wrote on Wed, May 31, 2006 at 09:57:48PM CEST:
> 
> It is a bit funny, though, since normally I tend to be the
> conservative one about compatibility and whatnot and others (like Akim
> :-) are more willing to push the envelope.

Well, this Autoconf work has the explicit goal of a stable release.
(That's not to say it's not fun, but I'm listed as maintainer of
Libtool, and we're now rather off the nice 3-4 month release cycle
we've had there before.)

> Ralf Wildenhues <Ralf.Wildenhues <at> gmx.de> writes:
> > - here document braced parameter expansion bug in ksh93f
> > (fixed in ksh93g 98-04-30):
> > http://lists.gnu.org/archive/html/autoconf-patches/2006-05/msg00122.html
> 
> Ah, I didn't know the ksh93g fix.  I'll add that to the Autoconf manual.

Kudos go entirely to Sven Mascheck here, who not only has a copy of the
release notes on his webpage, but also pointed this out to me.

> > If I had to decide (or nothing happens on these matters), I'd apply
> > the first, think some more about the second, skip the third, and go
> > ahead with 2.59d.
> 
> Sounds good, except I don't think you need to think more about the
> second, and that we can just go ahead as-is.

(Continue reading)

Paul Eggert | 1 Jun 2006 09:48
Favicon

add warning about ":" in directory names

I installed this:

2006-06-01  Paul Eggert  <eggert <at> cs.ucla.edu>

	* doc/autoconf.texi (File System Conventions): Warn about ":"
	anywhere in directory names.

--- doc/autoconf.texi	31 May 2006 20:20:13 -0000	1.1032
+++ doc/autoconf.texi	1 Jun 2006 07:47:24 -0000
 <at>  <at>  -10947,7 +10947,9  <at>  <at>  the following:

 Also, file names should not begin with  <at> samp{~} or  <at> samp{-}, and should
 contain neither  <at> samp{-} immediately after  <at> samp{/} nor  <at> samp{~}
-immediately after  <at> samp{:}.
+immediately after  <at> samp{:}.  On Posix-like platforms, directory names
+should not contain  <at> samp{:}, as this runs afoul of  <at> samp{:} used as the
+path separator.

 These restrictions apply not only to the files that you distribute, but
 also to the absolute file names of your source, build, and destination

Ralf Wildenhues | 1 Jun 2006 20:17
Picon
Picon

FYI: update imported files

I've applied this.

Cheers,
Ralf

	* config/texinfo.tex, doc/standards.texi: Sync from upstream.

Index: config/texinfo.tex
===================================================================
RCS file: /cvsroot/autoconf/autoconf/config/texinfo.tex,v
retrieving revision 1.18
diff -u -r1.18 texinfo.tex
--- config/texinfo.tex	17 May 2006 02:15:30 -0000	1.18
+++ config/texinfo.tex	1 Jun 2006 18:16:21 -0000
 <at>  <at>  -3,7 +3,7  <at>  <at> 
 % Load plain if necessary, i.e., if running under initex.
 \expandafter\ifx\csname fmtname\endcsname\relax\input plain\fi
 %
-\def\texinfoversion{2006-05-07.15}
+\def\texinfoversion{2006-05-28.17}
 %
 % Copyright (C) 1985, 1986, 1988, 1990, 1991, 1992, 1993, 1994, 1995,
 % 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006 Free
 <at>  <at>  -1084,15 +1084,24  <at>  <at> 
 \def\minus{$-$}

 %  <at> dots{} outputs an ellipsis using the current font.
-% We do .5em per period so that it has the same spacing in a typewriter
-% font as three actual period characters.
+% We do .5em per period so that it has the same spacing in the cm
(Continue reading)

Ralf Wildenhues | 1 Jun 2006 20:23
Picon
Picon

Re: AC_PROG_MKDIR_P documentation

> Stepan Kasal <kasal <at> ucw.cz> writes:
> 
> > The documentation says that FreeBSD 5.0 and NetBSD-current contain a
> > race-free implementations of mkdir -p.
> > Do they also understand -m and --?
[...]
> > And what about OpenBSD, does any of the readers here know?

I went ahead and checked these BSD systems:
http://www.freebsd.org/cgi/cvsweb.cgi/src/bin/mkdir/mkdir.c
http://cvsweb.netbsd.org/bsdweb.cgi/src/bin/mkdir/mkdir.c
http://www.openbsd.org/cgi-bin/cvsweb/src/bin/mkdir/mkdir.c

All of them support -m.

FreeBSD has a race-free mkdir -p since rev. 1.23 of mkdir.c, but I
wouldn't trust it before rev. 1.25, dated 2002, in FreeBSD 5.0.

NetBSD has a race-free mkdir -p since rev. 1.28 of mkdir.c, but I
wouldn't trust it before rev. 1.29, dated 2003, in NetBSD 2.0.2.

OpenBSD has a race-free mkdir -p since rev. 1.7 of mkdir.c, 1998,
OpenBSD 2.4, but looking at the source code, I found a small
bug in it (which is not so relevant to intended usage though):
http://cvs.openbsd.org/cgi-bin/query-pr-wrapper?full=yes&numbers=5141

> > If yes, is there any way to detect them, too?
> 
> Not that I know of; I don't have such systems easily available.

(Continue reading)

Stepan Kasal | 2 Jun 2006 14:41
Picon

Re: braced variable expansion in here documents

Hi,

attached please find a patch which checks for the ksh93f bug in
expanding here-documents.

I understand that changing the better shell routine might be
dangerous; but it is less dangerous in this case:

Ralf made a quick search and it seems that the UnixWare was the only
one having that among the candidates for a better shell.
(Solaris has it under the name `dtksh' and AIX under the name
`ksh93'.)

On Fri, May 26, 2006 at 10:24:09AM -0700, Paul Eggert wrote:
> The problem isn't dtksh; it is systems that use, or plan to use, ksh93
> under some name like 'ksh' or 'sh'.  This could well be more of a
> problem in the near future.

I think this was written before Ralf found out that ksh93g fixes the
bug.

To sum up, I believe my check won't stir up the better shell
selection too much.  Dear ``release engineer'' would you consider
installing it now?

In any case, I believe we need it in the long run: the bug is mean,
hard to identify, and it is possible that it will hit an innocent
user who has a long here-document in his configure.ac.

The patch also contains some sharpening of the documentation
(Continue reading)

Stepan Kasal | 2 Jun 2006 15:06
Picon

Improve the AC_REQUIRE error message

Hello,

I noticed that the following error message is suboptimal, it should mention
AC_DEFUN instead of m4_defun:

configure.ac:12: error: AC_REQUIRE(AC_PROG_CC): cannot be used outside of an m4_defun'd macro

What about the following hack to fix it?

Have a nice day,
	Stepan
2006-06-02  Stepan Kasal  <kasal <at> ucw.cz>

	* lib/m4sugar/m4sugar.m4 (m4_require): Modify the error
	message issued by AC_REQUIRE.

Index: lib/m4sugar/m4sugar.m4
===================================================================
RCS file: /cvsroot/autoconf/autoconf/lib/m4sugar/m4sugar.m4,v
retrieving revision 2.97
diff -u -r2.97 m4sugar.m4
--- lib/m4sugar/m4sugar.m4	20 Feb 2006 21:43:06 -0000	2.97
+++ lib/m4sugar/m4sugar.m4	2 Jun 2006 11:37:01 -0000
 <at>  <at>  -1249,7 +1249,8  <at>  <at> 
 [m4_ifdef([_m4_expanding($1)],
 	 [m4_fatal([$0: circular dependency of $1])])dnl
 m4_ifndef([_m4_divert_dump],
-	  [m4_fatal([$0($1): cannot be used outside of an m4_defun'd macro])])dnl
(Continue reading)

Ralf Wildenhues | 2 Jun 2006 16:42
Picon
Picon

Re: Improve the AC_REQUIRE error message

Hi Stepan,

* Stepan Kasal wrote on Fri, Jun 02, 2006 at 03:06:22PM CEST:
> 
> I noticed that the following error message is suboptimal, it should
> mention AC_DEFUN instead of m4_defun:
> 
> configure.ac:12: error: AC_REQUIRE(AC_PROG_CC): cannot be used outside of an m4_defun'd macro
> 
> What about the following hack to fix it?

It would need at least a test.  But it's broken anyway:
$ cat configure.ac
AC_DEFUN([FOO])
m4_defun([BAR])
AC_INIT
AC_REQUIRE([FOO])
m4_require([BAR])
AC_REQUIRE([AC_PROG_CC])
AC_OUTPUT
$ autoconf
configure.ac:4: error: AC_REQUIRE(FOO): cannot be used outside of an 'd macro

Cheers,
Ralf

> 2006-06-02  Stepan Kasal  <kasal <at> ucw.cz>
> 
> 	* lib/m4sugar/m4sugar.m4 (m4_require): Modify the error
> 	message issued by AC_REQUIRE.
(Continue reading)

Ben Pfaff | 2 Jun 2006 19:06
Picon

Re: Debian-specific Autoconf patches

Paul Eggert <eggert <at> CS.UCLA.EDU> writes:

> Ben Pfaff <blp <at> cs.stanford.edu> writes:
>
>> I could update the Debian package to the current CVS and we'd
>> find out pretty fast ;-)
>>
>> I'm willing to give it a try, if anyone thinks it's a good
>> idea...
>
> I do (though my vote in this area doesn't count for nearly as much as
> yours :-).  Thanks.

I just uploaded the current CVS (as of about 17:00 GMT) to
Debian.  It should become available for download within a few
hours.
--

-- 
Ben Pfaff 
email: blp <at> cs.stanford.edu
web: http://benpfaff.org

Paul Eggert | 3 Jun 2006 00:45
Favicon

Re: braced variable expansion in here documents

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

> 	* lib/m4sugar/m4sh.m4 (_AS_HERE_DOC_WORKS): Check for the
> 	ksh93f bug with long here-documents.
> 	(AS_INIT): Require this check.

I have some qualms about this, on efficiency grounds.  It will slow
down startup, for the sake only of (as far as we know) Unixware 7.1.1
which is a minority system.  Isn't there a faster way to do this?

The documentation change looks good, though.  Thanks.  I tweaked it a
bit and installed this:

2006-06-02  Stepan Kasal  <kasal <at> ucw.cz>
	and Paul Eggert  <eggert <at> cs.ucla.edu>

	* doc/autoconf.texi (Here-Documents): Add details about the
	pre-ksh93g bug.  Reword slightly to make it clearer.  Consistently
	use "here-documents" instead of "here documents".

--- doc/autoconf.texi	1 Jun 2006 07:47:40 -0000	1.1033
+++ doc/autoconf.texi	2 Jun 2006 22:42:10 -0000
 <at>  <at>  -10755,8 +10755,8  <at>  <at>  Posix standard, the challenge is to find

  <at> node Here-Documents
  <at> section Here-Documents
- <at> cindex Here documents
- <at> cindex Shell here documents
+ <at> cindex Here-documents
+ <at> cindex Shell here-documents
(Continue reading)

Paul Eggert | 4 Jun 2006 01:22
Favicon

style of command prompts in manual

I installed this:

2006-06-03  Paul Eggert  <eggert <at> cs.ucla.edu>

	* doc/autoconf.texi: Use a consistent style "$  <at> kbd{...}" for
	examples involving shell prompts.

--- doc/autoconf.texi	2 Jun 2006 22:42:33 -0000	1.1034
+++ doc/autoconf.texi	3 Jun 2006 23:21:06 -0000	1.1035
 <at>  <at>  -9820,9 +9820,9  <at>  <at>  Transform  <at> var{expression} into a valid 
 For example:

  <at> example
-$ type="char *"
-$ echo "#define AS_TR_CPP([HAVE_$type]) 1"
-#define HAVE_CHAR_P 1
+# This outputs "#define HAVE_CHAR_P 1".
+type="char *"
+echo "#define AS_TR_CPP([HAVE_$type]) 1"
  <at> end example
  <at> end defmac

 <at>  <at>  -9831,10 +9831,10  <at>  <at>  $ echo "#define AS_TR_CPP([HAVE_$type]) 
 Transform  <at> var{expression} into a valid shell variable name.  For example:

  <at> example
-$ header="sys/some file.h"
-$ AS_TR_SH([HAVE_$header])=yes
-$ if test "$HAVE_sys_some_file_h" = yes; then echo "Have it!"; fi
-Have it!
(Continue reading)


Gmane