zsh and autoconf-2.50

zsh and autoconf-2.50

[Jos Backus]

This is with a just checked out copy. Am I doing something wrong?

taiko:/depot/src/zsh% ./Util/preconfig
cd . && ./.preconfig
configure.in:55: error: undefine: undefined: zsh-debug
configure.in:55: the top level
./Util/preconfig: ./.preconfig failed (status 1)

(I want to build this on Solaris using Purify.)

-- 
Jos Backus                 _/  _/_/_/        "Modularity is not a hack."
                          _/  _/   _/                -- D. J. Bernstein
                         _/  _/_/_/             
                    _/  _/  _/    _/
josb@cncdsl.com     _/_/   _/_/_/            use Std::Disclaimer;

Re: zsh and autoconf-2.50

[Bart Schaefer]

On May 30,  2:48pm, Jos Backus wrote:
> Subject: zsh and autoconf-2.50
> This is with a just checked out copy. Am I doing something wrong?

I don't think so ...

> taiko:/depot/src/zsh% ./Util/preconfig
> cd . && ./.preconfig
> configure.in:55: error: undefine: undefined: zsh-debug

That's pretty silly.  This is like C++ generating an error if you #undef
a constant that has never been #define'd.  Did autoconf-2.50 redefine the
m4 undefine function, or did something change in a new version of m4?

My m4 info page says:

   It is not an error for NAME to have no macro definition.  In that
case, `undefine' does nothing.

Anyway, those undefines are probably entirely extraneous anyway, so try
just deleting them.

Re: zsh and autoconf-2.50

[Jos Backus]

On Wed, May 30, 2001 at 03:01:46PM -0700, Bart Schaefer wrote:
> That's pretty silly.  This is like C++ generating an error if you #undef
> a constant that has never been #define'd.  Did autoconf-2.50 redefine the
> m4 undefine function, or did something change in a new version of m4?

It's strange indeed. This is with a freshly built m4-1.4 (haven't seen
anything newer).
 
> My m4 info page says:
> 
>    It is not an error for NAME to have no macro definition.  In that
> case, `undefine' does nothing.

So does mine.
 
> Anyway, those undefines are probably entirely extraneous anyway, so try
> just deleting them.
 
That fixes it (obviously).

Btw, running ``./configure'' yields

    configure: creating ./config.status
    ./config.status: syntax error at line 1063: `end of file' unexpected

before printing the configuration. That doesn't look normal. The file has
1062 lines and the end looks like

#
# CONFIG_COMMANDS section.
#
for ac_file in : $CONFIG_COMMANDS; do test "x$ac_file" = x: && continue
  ac_dest=`echo "$ac_file" | sed 's,:.*,,'`
  ac_source=`echo "$ac_file" | sed 's,[^:]*:,,'`

  case $ac_dest in
    default ) \
test -z "$CONFIG_HEADERS" || echo > stamp-h ;;
  esac
done

{ (exit 0); exit 0; }

As a result, some other files aren't being generated (e.g. the Makefile).

Thanks,
-- 
Jos Backus                 _/  _/_/_/        "Modularity is not a hack."
                          _/  _/   _/                -- D. J. Bernstein
                         _/  _/_/_/             
                    _/  _/  _/    _/
josb@cncdsl.com     _/_/   _/_/_/            use Std::Disclaimer;

Re: zsh and autoconf-2.50

[Clint Adams]

> That's pretty silly.  This is like C++ generating an error if you #undef
> a constant that has never been #define'd.  Did autoconf-2.50 redefine the
> m4 undefine function, or did something change in a new version of m4?

Yes, autoconf 2.50 undefines `define' and `undefine'.

Re: zsh and autoconf-2.50

[Bart Schaefer]

On May 30,  6:40pm, Clint Adams wrote:
> 
> Yes, autoconf 2.50 undefines `define' and `undefine'.

Whatever for?

Re: zsh and autoconf-2.50

[Clint Adams]

> > Yes, autoconf 2.50 undefines `define' and `undefine'.
> 
> Whatever for?

It "renames" them to m4_define and m4_undefine.  I don't know why.
Akim, can you enlighten us?

Re: zsh and autoconf-2.50

[Oliver Kiddle]

Clint Adams wrote:

> It "renames" them to m4_define and m4_undefine.  I don't know why.
> Akim, can you enlighten us?

Is it using the --prefix-builtins (-P) option to m4 for this then? If
so, that sounds quite sensible because it can be quite annoying in m4
having to remember to quote any builtins. Anyway, that sounds like it
will be a fairly trivial fix to configure.in when we come to switch to
autoconf 2.5.

> We might want to send configure.in to the Attic and name it configure.ac
> after 4.0 gets branched off.

Why out of interest? What would autoconf 2.5 have it replaced by then?

Oliver

Re: zsh and autoconf-2.50

[Clint Adams]

> Is it using the --prefix-builtins (-P) option to m4 for this then? If
> so, that sounds quite sensible because it can be quite annoying in m4
> having to remember to quote any builtins. Anyway, that sounds like it
> will be a fairly trivial fix to configure.in when we come to switch to
> autoconf 2.5.

No, this is what it does:

## ------------------------------- ##
## 1. Simulate --prefix-builtins.  ##
## ------------------------------- ##

# m4_define
# m4_defn
# m4_undefine
define([m4_define],   defn([define]))
define([m4_defn],     defn([defn]))
define([m4_undefine], defn([undefine]))

m4_undefine([define])
m4_undefine([defn])
m4_undefine([undefine])

> Why out of interest? What would autoconf 2.5 have it replaced by then?

configure.ac is the new canonical name.  Something about "configure.in"
being too vague, I think.

Re: zsh and autoconf-2.50

[Akim Demaille]

>>>>> "Clint" == Clint Adams <clint@zsh.org> writes:

>> > Yes, autoconf 2.50 undefines `define' and `undefine'.
>> 
>> Whatever for?

Clint> It "renames" them to m4_define and m4_undefine.  I don't know
Clint> why.  Akim, can you enlighten us?

Err, this is both right and wrong :)

Autoconf is on top of M4sh, a pure sh layer, itself on top of M4sugar,
a pure M4 layer.  It is today considered bad design to have kept some
primitive such as define etc. out of any pseudo name space.  That's
why M4sugar moves all the builtins (but dnl) into the `m4_' pseudo
name space.

Nevertheless, for backward compatibility, autoconf.m4 restores these:

     # We discourage the use of the non prefixed macro names: M4sugar maps
     # all the builtins into `m4_'.  Autoconf has been converted to these
     # names too.  But users may still depend upon these, so reestablish
     # them.
     
     m4_copy_unm4([m4_builtin])
     m4_copy_unm4([m4_changequote])
     m4_copy_unm4([m4_decr])
     m4_copy_unm4([m4_define])
     m4_copy_unm4([m4_defn])
     m4_copy_unm4([m4_divert])
     m4_copy_unm4([m4_divnum])
     m4_copy_unm4([m4_errprint])
     m4_copy_unm4([m4_esyscmd])
     m4_copy_unm4([m4_ifdef])
     m4_copy([m4_if], [ifelse])
     m4_copy_unm4([m4_incr])
     m4_copy_unm4([m4_index])
     m4_copy_unm4([m4_indir])
     m4_copy_unm4([m4_len])
     m4_copy_unm4([m4_patsubst])
     m4_copy_unm4([m4_popdef])
     m4_copy_unm4([m4_pushdef])
     m4_copy_unm4([m4_regexp])
     m4_copy_unm4([m4_sinclude])
     m4_copy_unm4([m4_syscmd])
     m4_copy_unm4([m4_sysval])
     m4_copy_unm4([m4_traceoff])
     m4_copy_unm4([m4_traceon])
     m4_copy_unm4([m4_translit])
     m4_copy_unm4([m4_undefine])
     m4_copy_unm4([m4_undivert])

So yes, define and undefine are undefined (in M4sh and M4sugar), but
no, you should not know about this (in Autoconf), you should not be
aware of it.

What happens?

Re: zsh and autoconf-2.50

[Clint Adams]

> So yes, define and undefine are undefined (in M4sh and M4sugar), but
> no, you should not know about this (in Autoconf), you should not be
> aware of it.
> 
> What happens?

% autoconf2.50
configure.in:55: error: undefine: undefined: zsh-debug
configure.in:55: the top level

The offending construct is here.

undefine([zsh-debug])dnl
AC_ARG_ENABLE(zsh-debug,
[  --enable-zsh-debug         compile with debug code and debugger symbols],
[if test x$enableval = xyes; then
  AC_DEFINE(DEBUG)
fi])

Re: zsh and autoconf-2.50

[Akim Demaille]

| > So yes, define and undefine are undefined (in M4sh and M4sugar), but
| > no, you should not know about this (in Autoconf), you should not be
| > aware of it.
| > 
| > What happens?
| 
| % autoconf2.50
| configure.in:55: error: undefine: undefined: zsh-debug
| configure.in:55: the top level
| 
| The offending construct is here.
| 
| undefine([zsh-debug])dnl
| AC_ARG_ENABLE(zsh-debug,
| [  --enable-zsh-debug         compile with debug code and debugger symbols],
| [if test x$enableval = xyes; then
|   AC_DEFINE(DEBUG)
| fi])

This 

| configure.in:55: error: undefine: undefined: zsh-debug

reads `there is an error declared by undefine: zsh-debug is
undefined'.

I agree the original `undefine' from M4 does not do that.  I agree the
message should be

| configure.in:55: error: undefine: undefined macro: zsh-debug

But by experience I know we need to be stricter to catch asap bad
bugs, so I definitely prefer the 2.50 behavior.  I'd use
ifdef(,,undefine()).

RE: zsh and autoconf-2.50

[Andrej Borsenkow]

> |
> | % autoconf2.50
> | configure.in:55: error: undefine: undefined: zsh-debug
> | configure.in:55: the top level
> |
> | The offending construct is here.
> |
> | undefine([zsh-debug])dnl
> | AC_ARG_ENABLE(zsh-debug,
> | [  --enable-zsh-debug         compile with debug code and
> debugger symbols],
> | [if test x$enableval = xyes; then
> |   AC_DEFINE(DEBUG)
> | fi])
>

I have started with updating and am staring at this with some surprise. Why
do we need this undefine at all? Is not AC_ARG_ENABLE([zsh-debug],...)
enough?

Akim?

-andrej

Re: zsh and autoconf-2.50

[Akim Demaille]

>>>>> "Andrej" == Andrej Borsenkow <Andrej.Borsenkow@mow.siemens.ru> writes:

Andrej> I have started with updating and am staring at this with some
Andrej> surprise. Why do we need this undefine at all? Is not
Andrej> AC_ARG_ENABLE([zsh-debug],...)  enough?

Andrej> Akim?

I have no idea why you had this undefine.  In addition it's an
``impure'' macro name, i.e., you can only use this macro via defn, or
indir, but not as is.

To me it is useless (but I have not read your configure.in).  autoconf
thinks its useless too as it complains about undefining something not
defined.



I believe you, zsh people, should find some simplifications to your
configure.in.  In particular, note that you no longer have to perform
tricks to have AC_OUTPUT work on builddir/srcdir files, it's now
built in Autoconf.

RE: zsh and autoconf-2.50

[Tim Van Holder]

> > | % autoconf2.50
> > | configure.in:55: error: undefine: undefined: zsh-debug
> > | configure.in:55: the top level
> > |
> > | The offending construct is here.
> > |
> > | undefine([zsh-debug])dnl
> > | AC_ARG_ENABLE(zsh-debug,
> > | [  --enable-zsh-debug         compile with debug code and
> > debugger symbols],
> > | [if test x$enableval = xyes; then
> > |   AC_DEFINE(DEBUG)
> > | fi])
> >
> 
> I have started with updating and am staring at this with some 
> surprise. Why
> do we need this undefine at all? Is not AC_ARG_ENABLE([zsh-debug],...)
> enough?
> 
Yes it is.  I have seen such undefines before; basically it's a
bit paranoid: 'zsh-debug' is passed to AC_ARG_ENABLE unquoted, so
they wanted to avoid it being a macro (and getting expanded).
As you say, simply drop the undefine, and quote zsh-debug.

Re: zsh and autoconf-2.50

[Peter Stephenson]

Akim Demaille wrote:
> | The offending construct is here.
> | 
> | undefine([zsh-debug])dnl
> | AC_ARG_ENABLE(zsh-debug,
> | [  --enable-zsh-debug         compile with debug code and debugger symbols]
> ,
> | [if test x$enableval = xyes; then
> |   AC_DEFINE(DEBUG)
> | fi])
> 
> This 
> 
> | configure.in:55: error: undefine: undefined: zsh-debug
> 
> reads `there is an error declared by undefine: zsh-debug is
> undefined'.

Index: configure.in
===================================================================
RCS file: /cvsroot/zsh/zsh/configure.in,v
retrieving revision 1.58
diff -u -r1.58 configure.in
--- configure.in	2001/05/20 10:59:27	1.58
+++ configure.in	2001/06/01 09:35:43
@@ -52,7 +52,7 @@
 zsh_COMPILE_FLAGS($CPPFLAGS, $CFLAGS, $LDFLAGS, $LIBS)
 
 dnl Do you want to debug zsh?
-undefine([zsh-debug])dnl
+ifdef([zsh-debug],,undefine([zsh-debug]))dnl
 AC_ARG_ENABLE(zsh-debug,
 [  --enable-zsh-debug         compile with debug code and debugger symbols],
 [if test x$enableval = xyes; then

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR Ltd., Unit 300, Science Park, Milton Road,
Cambridge, CB4 0XL, UK                          Tel: +44 (0)1223 392070


**********************************************************************
The information transmitted is intended only for the person or
entity to which it is addressed and may contain confidential 
and/or privileged material. 
Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by 
persons or entities other than the intended recipient is 
prohibited.  
If you received this in error, please contact the sender and 
delete the material from any computer.
**********************************************************************

Re: zsh and autoconf-2.50

[Clint Adams]

> +ifdef([zsh-debug],,undefine([zsh-debug]))dnl

Is that not backwards?

Re: zsh and autoconf-2.50

[Peter Stephenson]

Clint Adams wrote:
> > +ifdef([zsh-debug],,undefine([zsh-debug]))dnl
> 
> Is that not backwards?

Oh, you're expecting to work...

This can probably go if configure.in gets rewritten, but it should be
safe for now.

Index: configure.in
===================================================================
RCS file: /cvsroot/zsh/zsh/configure.in,v
retrieving revision 1.58
diff -u -r1.58 configure.in
--- configure.in	2001/05/20 10:59:27	1.58
+++ configure.in	2001/06/01 12:42:57
@@ -52,7 +52,7 @@
 zsh_COMPILE_FLAGS($CPPFLAGS, $CFLAGS, $LDFLAGS, $LIBS)
 
 dnl Do you want to debug zsh?
-undefine([zsh-debug])dnl
+ifdef([zsh-debug],undefine([zsh-debug]))dnl
 AC_ARG_ENABLE(zsh-debug,
 [  --enable-zsh-debug         compile with debug code and debugger symbols],
 [if test x$enableval = xyes; then

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR Ltd., Unit 300, Science Park, Milton Road,
Cambridge, CB4 0XL, UK                          Tel: +44 (0)1223 392070


**********************************************************************
The information transmitted is intended only for the person or
entity to which it is addressed and may contain confidential 
and/or privileged material. 
Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by 
persons or entities other than the intended recipient is 
prohibited.  
If you received this in error, please contact the sender and 
delete the material from any computer.
**********************************************************************

RE: zsh and autoconf-2.50

[Andrej Borsenkow]

> > reads `there is an error declared by undefine: zsh-debug is
> > undefined'.
>

There are a dozen more. Moreover, half of parameters do use this undefine
half do not. I believe, it is totally redundant - should I just remove them?

-andrej

Re: zsh and autoconf-2.50

[Peter Stephenson]

"Andrej Borsenkow" wrote:
> > > reads `there is an error declared by undefine: zsh-debug is
> > > undefined'.
> >
> 
> There are a dozen more. Moreover, half of parameters do use this undefine
> half do not. I believe, it is totally redundant - should I just remove them?

Gag.  OK, here's a full paranoid replacement just for now, instead of the
previous two attempts.  It produces an identical configure, which is all
I'm really worried about.  As soon as 4.0.1 is out of the way, configure.in
can be tidied up.  I'm quite happy for these to go then.

I'm just putting in the finishing touches (I hope), so it would help if
non-urgent patches could be kept out until everything's tagged.

Index: configure.in
===================================================================
RCS file: /cvsroot/zsh/zsh/configure.in,v
retrieving revision 1.58
diff -u -r1.58 configure.in
--- configure.in	2001/05/20 10:59:27	1.58
+++ configure.in	2001/06/01 13:29:48
@@ -52,7 +52,7 @@
 zsh_COMPILE_FLAGS($CPPFLAGS, $CFLAGS, $LDFLAGS, $LIBS)
 
 dnl Do you want to debug zsh?
-undefine([zsh-debug])dnl
+ifdef([zsh-debug],undefine([zsh-debug]))dnl
 AC_ARG_ENABLE(zsh-debug,
 [  --enable-zsh-debug         compile with debug code and debugger symbols],
 [if test x$enableval = xyes; then
@@ -60,7 +60,7 @@
 fi])
 
 dnl Do you want zsh memory allocation routines.
-undefine([zsh-mem])dnl
+ifdef([zsh-mem],undefine([zsh-mem]))dnl
 AC_ARG_ENABLE(zsh-mem,
 [  --enable-zsh-mem           compile with zsh memory allocation routines],
 [if test x$enableval = xyes; then
@@ -68,7 +68,7 @@
 fi])
 
 dnl Do you want to debug zsh memory allocation routines.
-undefine([zsh-mem-debug])dnl
+ifdef([zsh-mem-debug],undefine([zsh-mem-debug]))dnl
 AC_ARG_ENABLE(zsh-mem-debug,
 [  --enable-zsh-mem-debug     debug zsh memory allocation routines],
 [if test x$enableval = xyes; then
@@ -76,7 +76,7 @@
 fi])
 
 dnl Do you want to print warnings when errors in memory allocation.
-undefine([zsh-mem-warning])dnl
+ifdef([zsh-mem-warning],undefine([zsh-mem-warning]))dnl
 AC_ARG_ENABLE(zsh-mem-warning,
 [  --enable-zsh-mem-warning   print warnings for errors in memory allocation],
 [if test x$enableval = xyes; then
@@ -84,7 +84,7 @@
 fi])
 
 dnl Do you want to turn on error checking for free().
-undefine([zsh-secure-free])dnl
+ifdef([zsh-secure-free],undefine([zsh-secure-free]))dnl
 AC_ARG_ENABLE(zsh-secure-free,
 [  --enable-zsh-secure-free   turn on error checking for free()],
 [if test x$enableval = xyes; then
@@ -93,7 +93,7 @@
 
 dnl Do you want debugging information on internal hash tables.
 dnl This turns on the `hashinfo' builtin command.
-undefine([zsh-hash-debug])dnl
+ifdef([zsh-hash-debug],undefine([zsh-hash-debug]))dnl
 AC_ARG_ENABLE(zsh-hash-debug,
 [  --enable-zsh-hash-debug    turn on debugging of internal hash tables],
 [if test x$enableval = xyes; then
@@ -101,12 +101,12 @@
 fi])
 
 dnl Pathnames for global zsh scripts
-undefine([etcdir])dnl
+ifdef([etcdir],undefine([etcdir]))dnl
 AC_ARG_ENABLE(etcdir,
 [  --enable-etcdir=DIR        the default directory for global zsh scripts],
 [etcdir="$enableval"], [etcdir=/etc])
 
-undefine([zshenv])dnl
+ifdef([zshenv],undefine([zshenv]))dnl
 AC_ARG_ENABLE(zshenv,
 [  --enable-zshenv=FILE       the full pathname of the global zshenv script],
 [zshenv="$enableval"],
@@ -119,7 +119,7 @@
   AC_DEFINE_UNQUOTED(GLOBAL_ZSHENV, "$zshenv")
 fi
 
-undefine([zshrc])dnl
+ifdef([zshrc],undefine([zshrc]))dnl
 AC_ARG_ENABLE(zshrc,
 [  --enable-zshrc=FILE        the full pathname of the global zshrc script],
 [zshrc="$enableval"],
@@ -132,7 +132,7 @@
   AC_DEFINE_UNQUOTED(GLOBAL_ZSHRC, "$zshrc")
 fi
 
-undefine([zprofile])dnl
+ifdef([zprofile],undefine([zprofile]))dnl
 AC_ARG_ENABLE(zprofile,
 [  --enable-zprofile=FILE     the full pathname of the global zprofile script],
 [zprofile="$enableval"],
@@ -145,7 +145,7 @@
   AC_DEFINE_UNQUOTED(GLOBAL_ZPROFILE, "$zprofile")
 fi
 
-undefine([zlogin])dnl
+ifdef([zlogin],undefine([zlogin]))dnl
 AC_ARG_ENABLE(zlogin,
 [  --enable-zlogin=FILE       the full pathname of the global zlogin script],
 [zlogin="$enableval"],
@@ -158,7 +158,7 @@
   AC_DEFINE_UNQUOTED(GLOBAL_ZLOGIN, "$zlogin")
 fi
 
-undefine([zlogout])dnl
+ifdef([zlogout],undefine([zlogout]))dnl
 AC_ARG_ENABLE(zlogout,
 [  --enable-zlogout=FILE      the full pathname of the global zlogout script],
 [zlogout="$enableval"],
@@ -178,19 +178,19 @@
 AC_SUBST(zlogout)dnl
 
 dnl Do you want large file support, if available?
-undefine([lfs])dnl
+ifdef([lfs],undefine([lfs]))dnl
 AC_ARG_ENABLE(lfs,
 [  --disable-lfs              turn off support for large files],
 [lfs="$enableval"], [lfs=yes])
 
 dnl Do you want dynamically loaded binary modules.
-undefine([dynamic])dnl
+ifdef([dynamic],undefine([dynamic]))dnl
 AC_ARG_ENABLE(dynamic,
 [  --disable-dynamic          turn off dynamically loaded binary modules],
 [dynamic="$enableval"], [dynamic=yes])
 
 dnl Do you want to disable restricted on r* commands
-undefine([restricted-r])dnl
+ifdef([restricted-r],undefine([restricted-r]))dnl
 AC_ARG_ENABLE(restricted-r,
 [  --disable-restricted-r     turn off r* invocation for restricted shell],
 [if test x$enableval = xyes; then
@@ -213,7 +213,7 @@
 [  --enable-ansi2knr          translate source to K&R C before compiling],
 [ansi2knr="$enableval"], [ansi2knr=default])
 
-undefine([fndir])dnl
+ifdef([fndir],undefine([fndir]))dnl
 AC_ARG_ENABLE(fndir,
 [  --enable-fndir=DIR         the directory in which to install functions],
 dnl ${VERSION} to be determined at compile time.
@@ -223,7 +223,7 @@
   fndir="$enableval"
 fi], [fndir=${datadir}/${tzsh_name}/'${VERSION}'/functions])
 
-undefine([sitefndir])dnl
+ifdef([sitefndir],undefine([sitefndir]))dnl
 AC_ARG_ENABLE(sitefndir,
 [  --enable-site-fndir=DIR    same for site functions (not version specific)],
 [if test $enableval = yes; then
@@ -232,7 +232,7 @@
   sitefndir="$enableval"
 fi], [sitefndir=${datadir}/${tzsh_name}/site-functions])
 
-undefine([function_subdirs])
+ifdef([function_subdirs],undefine([function_subdirs]))
 AC_ARG_ENABLE(function-subdirs,
 [  --enable-function-subdirs  install functions in subdirectories])
 
@@ -248,7 +248,7 @@
 AC_SUBST(FUNCTIONS_SUBDIRS)dnl
 
 dnl Do you want maildir support?
-undefine([maildir_support])dnl
+ifdef([maildir_support],undefine([maildir_support]))dnl
 AC_ARG_ENABLE(maildir-support,
 [  --enable-maildir-support   enable maildir support in MAIL and MAILPATH],
 [if test x$enableval = xyes; then
@@ -256,7 +256,7 @@
 fi])
 
 dnl Do you want to set a maximum function depth?
-undefine([max_function_depth])dnl
+ifdef([max_function_depth],undefine([max_function_depth]))dnl
 AC_ARG_ENABLE(max-function-depth,
 [  --enable-max-function-depth=MAX   limit function depth to MAX],
 [if test x$enableval = xyes; then
@@ -419,7 +419,7 @@
 
 AC_MSG_CHECKING(what to set MAXJOB to)
 dnl Do you want to alter the maximum job table size?
-undefine([max_jobtable_size])dnl
+ifdef([max_jobtable_size],undefine([max_jobtable_size]))dnl
 AC_ARG_ENABLE(max-jobtable-size,
 [  --enable-max-jobtable-size=MAX    limit job table size to MAX],
 
-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR Ltd., Unit 300, Science Park, Milton Road,
Cambridge, CB4 0XL, UK                          Tel: +44 (0)1223 392070


**********************************************************************
The information transmitted is intended only for the person or
entity to which it is addressed and may contain confidential 
and/or privileged material. 
Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by 
persons or entities other than the intended recipient is 
prohibited.  
If you received this in error, please contact the sender and 
delete the material from any computer.
**********************************************************************

Re: zsh and autoconf-2.50

[Bart Schaefer]

On Jun 1,  2:33pm, Peter Stephenson wrote:
} Subject: Re: zsh and autoconf-2.50
}
} I'm just putting in the finishing touches (I hope), so it would help if
} non-urgent patches could be kept out until everything's tagged.

Do we want 14578?

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Re: zsh and autoconf-2.50

[Peter Stephenson]

"Bart Schaefer" wrote:
> On Jun 1,  2:33pm, Peter Stephenson wrote:
> } Subject: Re: zsh and autoconf-2.50
> }
> } I'm just putting in the finishing touches (I hope), so it would help if
> } non-urgent patches could be kept out until everything's tagged.
> 
> Do we want 14578?

I'd say leave it out for now, then put it in after the release --- it
doesn't seem to be that urgent.

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR Ltd., Unit 300, Science Park, Milton Road,
Cambridge, CB4 0XL, UK                          Tel: +44 (0)1223 392070


**********************************************************************
The information transmitted is intended only for the person or
entity to which it is addressed and may contain confidential 
and/or privileged material. 
Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by 
persons or entities other than the intended recipient is 
prohibited.  
If you received this in error, please contact the sender and 
delete the material from any computer.
**********************************************************************

RE: zsh and autoconf-2.50

[Andrej Borsenkow]

> 
> Gag.  OK, here's a full paranoid replacement just for now, instead of the
> previous two attempts.  It produces an identical configure, which is all
> I'm really worried about.

I must be stupid, but it does not work foe mr:

bor@itsrm2% autoconf         
configure.in:55: error: undefine: undefined: zsh-debug
configure.in:55: the top level

even with

dnl Do you want to debug zsh?
ifdef([zsh-debug],undefine([zsh-debug]))dnl

-andrej

RE: zsh and autoconf-2.50

[Andrej Borsenkow]

[-- Attachment #1: Type: text/plain, Size: 423 bytes --]


>
> I must be stupid, but it does not work foe mr:
>
> bor@itsrm2% autoconf
> configure.in:55: error: undefine: undefined: zsh-debug
> configure.in:55: the top level
>
> even with
>
> dnl Do you want to debug zsh?
> ifdef([zsh-debug],undefine([zsh-debug]))dnl
>

Quoting, quoting ...

ifdef([zsh-debug],[undefine([zsh-debug])])dnl

Please, PLEASE, test it this still works with 2.13. I do not have it anymore
:-)

-andrej

[-- Attachment #2: ac-2.50.diff --]
[-- Type: application/octet-stream, Size: 7048 bytes --]

Index: configure.in
===================================================================
RCS file: /cvsroot/zsh/zsh/configure.in,v
retrieving revision 1.59
diff -u -r1.59 configure.in
--- configure.in	2001/06/01 13:38:46	1.59
+++ configure.in	2001/06/01 14:03:20
@@ -52,7 +52,7 @@
 zsh_COMPILE_FLAGS($CPPFLAGS, $CFLAGS, $LDFLAGS, $LIBS)
 
 dnl Do you want to debug zsh?
-ifdef([zsh-debug],undefine([zsh-debug]))dnl
+ifdef([zsh-debug],[undefine([zsh-debug])])dnl
 AC_ARG_ENABLE(zsh-debug,
 [  --enable-zsh-debug         compile with debug code and debugger symbols],
 [if test x$enableval = xyes; then
@@ -60,7 +60,7 @@
 fi])
 
 dnl Do you want zsh memory allocation routines.
-ifdef([zsh-mem],undefine([zsh-mem]))dnl
+ifdef([zsh-mem],[undefine([zsh-mem])])dnl
 AC_ARG_ENABLE(zsh-mem,
 [  --enable-zsh-mem           compile with zsh memory allocation routines],
 [if test x$enableval = xyes; then
@@ -68,7 +68,7 @@
 fi])
 
 dnl Do you want to debug zsh memory allocation routines.
-ifdef([zsh-mem-debug],undefine([zsh-mem-debug]))dnl
+ifdef([zsh-mem-debug],[undefine([zsh-mem-debug])])dnl
 AC_ARG_ENABLE(zsh-mem-debug,
 [  --enable-zsh-mem-debug     debug zsh memory allocation routines],
 [if test x$enableval = xyes; then
@@ -76,7 +76,7 @@
 fi])
 
 dnl Do you want to print warnings when errors in memory allocation.
-ifdef([zsh-mem-warning],undefine([zsh-mem-warning]))dnl
+ifdef([zsh-mem-warning],[undefine([zsh-mem-warning])])dnl
 AC_ARG_ENABLE(zsh-mem-warning,
 [  --enable-zsh-mem-warning   print warnings for errors in memory allocation],
 [if test x$enableval = xyes; then
@@ -84,7 +84,7 @@
 fi])
 
 dnl Do you want to turn on error checking for free().
-ifdef([zsh-secure-free],undefine([zsh-secure-free]))dnl
+ifdef([zsh-secure-free],[undefine([zsh-secure-free])])dnl
 AC_ARG_ENABLE(zsh-secure-free,
 [  --enable-zsh-secure-free   turn on error checking for free()],
 [if test x$enableval = xyes; then
@@ -93,7 +93,7 @@
 
 dnl Do you want debugging information on internal hash tables.
 dnl This turns on the `hashinfo' builtin command.
-ifdef([zsh-hash-debug],undefine([zsh-hash-debug]))dnl
+ifdef([zsh-hash-debug],[undefine([zsh-hash-debug])])dnl
 AC_ARG_ENABLE(zsh-hash-debug,
 [  --enable-zsh-hash-debug    turn on debugging of internal hash tables],
 [if test x$enableval = xyes; then
@@ -101,12 +101,12 @@
 fi])
 
 dnl Pathnames for global zsh scripts
-ifdef([etcdir],undefine([etcdir]))dnl
+ifdef([etcdir],[undefine([etcdir])])dnl
 AC_ARG_ENABLE(etcdir,
 [  --enable-etcdir=DIR        the default directory for global zsh scripts],
 [etcdir="$enableval"], [etcdir=/etc])
 
-ifdef([zshenv],undefine([zshenv]))dnl
+ifdef([zshenv],[undefine([zshenv])])dnl
 AC_ARG_ENABLE(zshenv,
 [  --enable-zshenv=FILE       the full pathname of the global zshenv script],
 [zshenv="$enableval"],
@@ -119,7 +119,7 @@
   AC_DEFINE_UNQUOTED(GLOBAL_ZSHENV, "$zshenv")
 fi
 
-ifdef([zshrc],undefine([zshrc]))dnl
+ifdef([zshrc],[undefine([zshrc])])dnl
 AC_ARG_ENABLE(zshrc,
 [  --enable-zshrc=FILE        the full pathname of the global zshrc script],
 [zshrc="$enableval"],
@@ -132,7 +132,7 @@
   AC_DEFINE_UNQUOTED(GLOBAL_ZSHRC, "$zshrc")
 fi
 
-ifdef([zprofile],undefine([zprofile]))dnl
+ifdef([zprofile],[undefine([zprofile])])dnl
 AC_ARG_ENABLE(zprofile,
 [  --enable-zprofile=FILE     the full pathname of the global zprofile script],
 [zprofile="$enableval"],
@@ -145,7 +145,7 @@
   AC_DEFINE_UNQUOTED(GLOBAL_ZPROFILE, "$zprofile")
 fi
 
-ifdef([zlogin],undefine([zlogin]))dnl
+ifdef([zlogin],[undefine([zlogin])])dnl
 AC_ARG_ENABLE(zlogin,
 [  --enable-zlogin=FILE       the full pathname of the global zlogin script],
 [zlogin="$enableval"],
@@ -158,7 +158,7 @@
   AC_DEFINE_UNQUOTED(GLOBAL_ZLOGIN, "$zlogin")
 fi
 
-ifdef([zlogout],undefine([zlogout]))dnl
+ifdef([zlogout],[undefine([zlogout])])dnl
 AC_ARG_ENABLE(zlogout,
 [  --enable-zlogout=FILE      the full pathname of the global zlogout script],
 [zlogout="$enableval"],
@@ -178,19 +178,19 @@
 AC_SUBST(zlogout)dnl
 
 dnl Do you want large file support, if available?
-ifdef([lfs],undefine([lfs]))dnl
+ifdef([lfs],[undefine([lfs])])dnl
 AC_ARG_ENABLE(lfs,
 [  --disable-lfs              turn off support for large files],
 [lfs="$enableval"], [lfs=yes])
 
 dnl Do you want dynamically loaded binary modules.
-ifdef([dynamic],undefine([dynamic]))dnl
+ifdef([dynamic],[undefine([dynamic])])dnl
 AC_ARG_ENABLE(dynamic,
 [  --disable-dynamic          turn off dynamically loaded binary modules],
 [dynamic="$enableval"], [dynamic=yes])
 
 dnl Do you want to disable restricted on r* commands
-ifdef([restricted-r],undefine([restricted-r]))dnl
+ifdef([restricted-r],[undefine([restricted-r])])dnl
 AC_ARG_ENABLE(restricted-r,
 [  --disable-restricted-r     turn off r* invocation for restricted shell],
 [if test x$enableval = xyes; then
@@ -213,7 +213,7 @@
 [  --enable-ansi2knr          translate source to K&R C before compiling],
 [ansi2knr="$enableval"], [ansi2knr=default])
 
-ifdef([fndir],undefine([fndir]))dnl
+ifdef([fndir],[undefine([fndir])])dnl
 AC_ARG_ENABLE(fndir,
 [  --enable-fndir=DIR         the directory in which to install functions],
 dnl ${VERSION} to be determined at compile time.
@@ -223,7 +223,7 @@
   fndir="$enableval"
 fi], [fndir=${datadir}/${tzsh_name}/'${VERSION}'/functions])
 
-ifdef([sitefndir],undefine([sitefndir]))dnl
+ifdef([sitefndir],[undefine([sitefndir])])dnl
 AC_ARG_ENABLE(sitefndir,
 [  --enable-site-fndir=DIR    same for site functions (not version specific)],
 [if test $enableval = yes; then
@@ -232,7 +232,7 @@
   sitefndir="$enableval"
 fi], [sitefndir=${datadir}/${tzsh_name}/site-functions])
 
-ifdef([function_subdirs],undefine([function_subdirs]))
+ifdef([function_subdirs],[undefine([function_subdirs])])
 AC_ARG_ENABLE(function-subdirs,
 [  --enable-function-subdirs  install functions in subdirectories])
 
@@ -248,7 +248,7 @@
 AC_SUBST(FUNCTIONS_SUBDIRS)dnl
 
 dnl Do you want maildir support?
-ifdef([maildir_support],undefine([maildir_support]))dnl
+ifdef([maildir_support],[undefine([maildir_support])])dnl
 AC_ARG_ENABLE(maildir-support,
 [  --enable-maildir-support   enable maildir support in MAIL and MAILPATH],
 [if test x$enableval = xyes; then
@@ -256,7 +256,7 @@
 fi])
 
 dnl Do you want to set a maximum function depth?
-ifdef([max_function_depth],undefine([max_function_depth]))dnl
+ifdef([max_function_depth],[undefine([max_function_depth])])dnl
 AC_ARG_ENABLE(max-function-depth,
 [  --enable-max-function-depth=MAX   limit function depth to MAX],
 [if test x$enableval = xyes; then
@@ -419,7 +419,7 @@
 
 AC_MSG_CHECKING(what to set MAXJOB to)
 dnl Do you want to alter the maximum job table size?
-ifdef([max_jobtable_size],undefine([max_jobtable_size]))dnl
+ifdef([max_jobtable_size],[undefine([max_jobtable_size])])dnl
 AC_ARG_ENABLE(max-jobtable-size,
 [  --enable-max-jobtable-size=MAX    limit job table size to MAX],
 

Re: zsh and autoconf-2.50

[Clint Adams]

> Quoting, quoting ...
> 
> ifdef([zsh-debug],[undefine([zsh-debug])])dnl
> 
> Please, PLEASE, test it this still works with 2.13. I do not have it anymore
> :-)

It does.

RE: zsh and autoconf-2.50

[Andrej Borsenkow]

>
> > Quoting, quoting ...
> >
> > ifdef([zsh-debug],[undefine([zsh-debug])])dnl
> >
> > Please, PLEASE, test it this still works with 2.13. I do not
> have it anymore
> > :-)
>
> It does.
>

It (I mean, the whole configure.in)  does not work with 2.50 anyway, so I
won't commit it:

cd . && \
  CONFIG_FILES=Config/defs.mk CONFIG_HEADERS= /bin/sh ./config.status
./config.status: syntax error at line 1021: `end of file' unexpected
cd . && \
  CONFIG_FILES=./Makefile CONFIG_HEADERS= /bin/sh ./config.status
./config.status: syntax error at line 1021: `end of file' unexpected
cd /tools/src/zsh && autoheader
echo > /tools/src/zsh/stamp-h.in
cd . && \
  CONFIG_FILES= CONFIG_HEADERS=./config.h /bin/sh ./config.status
./config.status: syntax error at line 1021: `end of file' unexpected
...


Peter, does it make sense to put a word about it? Probably, in
zsh-devleopment-guide?

-andrej

Re: zsh and autoconf-2.50

[Peter Stephenson]

> It (I mean, the whole configure.in)  does not work with 2.50 anyway, so I
> won't commit it:

You might as well, since it's better than my attempt which I've already
committed (I was only worried that it didn't break the old autoconf).

> Peter, does it make sense to put a word about it? Probably, in
> zsh-devleopment-guide?

Index: Etc/zsh-development-guide
===================================================================
RCS file: /cvsroot/zsh/zsh/Etc/zsh-development-guide,v
retrieving revision 1.6
diff -u -r1.6 zsh-development-guide
--- Etc/zsh-development-guide	2001/04/14 16:34:15	1.6
+++ Etc/zsh-development-guide	2001/06/01 14:24:41
@@ -23,6 +23,10 @@
   of the config.status files that get generated.  See the comments in
   configure.in and at the end of Src/mkmakemod.sh for an explanation.)
 
+  Note that configure.in has not yet been modified to work with autoconf
+  2.50.  Use version 2.13 until configure.in and associated files have
+  been updated.
+
 * GNU m4.  (Required by autoconf.)
 
 * yodl.

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR Ltd., Unit 300, Science Park, Milton Road,
Cambridge, CB4 0XL, UK                          Tel: +44 (0)1223 392070


**********************************************************************
The information transmitted is intended only for the person or
entity to which it is addressed and may contain confidential 
and/or privileged material. 
Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by 
persons or entities other than the intended recipient is 
prohibited.  
If you received this in error, please contact the sender and 
delete the material from any computer.
**********************************************************************

RE: zsh and autoconf-2.50

[Andrej Borsenkow]

>
> > It (I mean, the whole configure.in)  does not work with 2.50
> anyway, so I
> > won't commit it:
>
> You might as well, since it's better than my attempt which I've already
> committed (I was only worried that it didn't break the old autoconf).
>

Makes no sense (unless 2.13 is broken aas well). I will remove these undefs
anyway. Let's finally release 4.0.1 :-)

BTW anybody else working on 2.50? Else I hope to produce new configure.ac
next week. I cannot promise to resolve this issue with current configure.in
though (unless it happens as a side effect).

-andrej

Re: zsh and autoconf-2.50

[Clint Adams]

> BTW anybody else working on 2.50? Else I hope to produce new configure.ac
> next week. I cannot promise to resolve this issue with current configure.in
> though (unless it happens as a side effect).

If you remove the hunk beginning with

dnl The standard config.status is missing some essential features.
dnl So add them now.  See the comment at the end of Src/mkmakemod.sh.

config.status will be happier.  I haven't looked into why.

PATCH: Re: zsh and autoconf-2.50

[Andrej Borsenkow]

[-- Attachment #1: Type: text/plain, Size: 1761 bytes --]

Clint Adams wrote:

>>BTW anybody else working on 2.50? Else I hope to produce new configure.ac
>>next week. I cannot promise to resolve this issue with current configure.in
>>though (unless it happens as a side effect).
>>
> 
> If you remove the hunk beginning with
> 
> dnl The standard config.status is missing some essential features.
> dnl So add them now.  See the comment at the end of Src/mkmakemod.sh.
> 
> config.status will be happier.  I haven't looked into why.
> 
> 


"Curiouser and curiouser!" cried Alice.

Anyway - 2.50 generates totally different config.status and our 
modification breaks it. Moreover, as Akim said, 2.50 does not need this 
mod anymore. But what's worse - mkmakemod.sh relies on our mod so if we 
just leave it out it does not work any more :-) It does not work anyway 
because check for dynamic build does not work with 2.50 ...

Here is patch that

- checks for autoconf version. It thinks that anything <= 2.13 needs our 
hack, anything over - does not. It breaks with beta autoconf versions 
like 2.49f. It smells.

- adds a string to config.status and lets mkmakemod.sh grep for it to 
decide when to use this hack.

- adds check for 2.50-like subst's (t check for dynamic build).

This is intended for 4.0.x only, and just to allow some poor soul to 
compile off CVS when we advice it without much fuss. And to allow me to 
build both 4.0.x and HEAD without maintaining two autoconf versions. :-) 
This is an absolute hack. Should I commit it?

-andrej

P.S. I just built freshly checked out 4.0 branch in sepearate build 
directory with these mods.

P.P.S. 2.50 seems to not use cache by default - you need explicit option 
--cache-file (or --config-cache to default to config.cache). One more 
change in Makefiles.

[-- Attachment #2: zsh-ac2.50.diff --]
[-- Type: text/plain, Size: 3647 bytes --]

Index: aczsh.m4
===================================================================
RCS file: /cvsroot/zsh/zsh/aczsh.m4,v
retrieving revision 1.10
diff -u -r1.10 aczsh.m4
--- aczsh.m4	2001/04/23 19:59:03	1.10
+++ aczsh.m4	2001/06/01 22:24:35
@@ -683,3 +683,21 @@
 	then LIBS="$4"
 	else LIBS="$enable_libs"
 	fi)])
+
+dnl These macros are copied over from autoconf-2.13
+dnl They for not work with beta versions and are intended
+dnl only to allow use of autoconf-2.50 for a transition time
+
+AC_DEFUN(zsh_ACVERSION_SPLIT, [translit($1, ., [, ])])
+
+AC_DEFUN(zsh_ACVERSION_CANON, [$1, $2, ifelse([$3], , 0, [$3])])
+
+AC_DEFUN(__zsh_CHECK_ACVERSION,
+  [ifelse(builtin([eval],
+  [$3 + $2 * 1000 + $1 * 1000000 <= $6 + $5 * 1000 + $4 * 1000000]), 1, [$7], [$8])])
+   
+AC_DEFUN(zsh_CHECK_ACVERSION,
+  [__zsh_CHECK_ACVERSION(zsh_ACVERSION_CANON(zsh_ACVERSION_SPLIT(AC_ACVERSION)),
+                                zsh_ACVERSION_CANON(zsh_ACVERSION_SPLIT($1)),
+				[$2],
+				[$3])])
Index: configure.in
===================================================================
RCS file: /cvsroot/zsh/zsh/configure.in,v
retrieving revision 1.60
diff -u -r1.60 configure.in
--- configure.in	2001/06/01 14:40:39	1.60
+++ configure.in	2001/06/01 22:24:36
@@ -1909,12 +1909,18 @@
 
 dnl The standard config.status is missing some essential features.
 dnl So add them now.  See the comment at the end of Src/mkmakemod.sh.
-[rm -f $CONFIG_STATUS.old
+dnl Starting from 2.50 Autoconf no more needs it and this modification
+dnl results in broken config.status so check for version. We check only
+dnl for officially released versions.
+zsh_CHECK_ACVERSION([2.13],
+[
+rm -f $CONFIG_STATUS.old
 cp $CONFIG_STATUS $CONFIG_STATUS.old
-sed '1,$s@^\( *ac_file_inputs=\).*$@\1`echo $ac_file_in | sed -e "s%^%:%" -e "s%:\\([^!]\\)% $ac_given_srcdir/\\1%g" -e "s%:!% %"`@' \
+sed '1,$s@^\( *ac_file_inputs=\).*$@\1`echo $ac_file_in | sed -e "s%^%:%" -e "s%:\\([[^!]]\\)% $ac_given_srcdir/\\1%g" -e "s%:!% %"`@' \
  $CONFIG_STATUS.old >$CONFIG_STATUS
+echo '# Hack for autoconf 2.13' >>$CONFIG_STATUS
  chmod +x $CONFIG_STATUS
- rm -f $CONFIG_STATUS.old]
+ rm -f $CONFIG_STATUS.old])
 
 test "$real_no_create" = yes || ${CONFIG_SHELL-/bin/sh} $CONFIG_STATUS || exit 1
 
Index: Src/mkmakemod.sh
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/mkmakemod.sh,v
retrieving revision 1.11
diff -u -r1.11 mkmakemod.sh
--- Src/mkmakemod.sh	2001/05/20 10:59:28	1.11
+++ Src/mkmakemod.sh	2001/06/01 22:24:38
@@ -111,7 +111,9 @@
     sed -e '/^#/d' -e 's/ .*/ /' -e 's/^name=/ /'`"
     module_list="${bin_mods}${dyn_mods}"
 
-    if grep '%@D@%D%' config.status >/dev/null; then
+    # check both 2.13 and 2.50 syntax
+    if grep '%@D@%D%' config.status >/dev/null ||
+       grep ',@D@,D,' config.status >/dev/null; then
 	is_dynamic=true
     else
 	is_dynamic=false
@@ -463,7 +465,12 @@
 
 fi
 
-if $second_stage; then
+if $second_stage ; then
+    if grep 'Hack for autoconf 2.13' ./config.status > /dev/null 2>&1 ; then
+        bang=\!
+    else
+	bang=
+    fi
 
     trap "rm -f $the_subdir/${the_makefile}" 1 2 15
 
@@ -472,7 +479,7 @@
     # tree, this is a problem.  zsh's configure script edits config.status,
     # adding the feature that an input filename starting with "!" has the
     # "!" removed and is not mangled further.
-    CONFIG_FILES=$the_subdir/${the_makefile}:\!$the_subdir/${the_makefile}.in CONFIG_HEADERS= ${CONFIG_SHELL-/bin/sh} ./config.status
+    CONFIG_FILES=$the_subdir/${the_makefile}:$bang$the_subdir/${the_makefile}.in CONFIG_HEADERS= ${CONFIG_SHELL-/bin/sh} ./config.status
 
 fi
 

Re: PATCH: Re: zsh and autoconf-2.50

[Bart Schaefer]

On Jun 2,  2:31am, Andrej Borsenkow wrote:
}
} - checks for autoconf version. It thinks that anything <= 2.13 needs our 
} hack, anything over - does not. It breaks with beta autoconf versions 
} like 2.49f. It smells.

How about the following:

Create a new file "zshconf.ac" (or "zshconf.in" or whatever, it really
doesn't matter).  Most of the contents of the current configure go into
this file -- everything up to the "missing some essential features" hack.

Add a macro to aczsh.m4 to output the "zsh configuration" report at that
appears at the end of the current configure.in.

Create a new file configure.ac that contains:

    m4_include([zshconf.ac])
    test "$real_no_create" = yes || 
	${CONFIG_SHELL-/bin/sh} $CONFIG_STATUS || exit 1
    zsh_SHOWCONFIG

Change configure.in to be a file that contains only:

    dnl Backwards compatibility with autoconf 2.13.

    builtin([include], [zshconf.ac])

    dnl The standard config.status is missing some essential features.
    dnl (etc. etc.)

    test "$real_no_create" = yes || 
	${CONFIG_SHELL-/bin/sh} $CONFIG_STATUS || exit 1
    zsh_SHOWCONFIG

Use this part of Andrej's patch:

} - adds a string to config.status and lets mkmakemod.sh grep for it to 
} decide when to use this hack.

Finally, fix various calls to autoheader to pass zshconf.ac as the file
to be scanned.

If I read the docs correctly, any version of autoconf that knows about
configure.ac will read that file preferentially, thereby skipping the
"missing some essential features" hack.  Older versions of autoconf
will ignore configure.ac and read configure.in instead, thereby getting
the hack.  Assuming that the new config.status was introduced at close
to the same time as autoconf.ac, this should cover nearly all cases
without an explicit version test.

I suggest this because, upon further consideration, I don't want to
require zsh developers to install autoconf 2.50.  They may need the
older version of autoconf for other packages that have not been updated
for the 2.50 changes.

Thoughts?

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Re: PATCH: Re: zsh and autoconf-2.50

[Clint Adams]

> I suggest this because, upon further consideration, I don't want to
> require zsh developers to install autoconf 2.50.  They may need the
> older version of autoconf for other packages that have not been updated
> for the 2.50 changes.
> 
> Thoughts?

I think it's a good plan during this time when autoconf 2.50 is fresh,
but I don't think effort should be expended to maintain compatibility
with 2.13 in future.  After all, it's neither impossible nor difficult
for zsh developers to have multiple versions of autoconf on hand, should
they be required.

Re: PATCH: Re: zsh and autoconf-2.50

[Zefram]

Bart Schaefer wrote:
>I suggest this because, upon further consideration, I don't want to
>require zsh developers to install autoconf 2.50.  They may need the
>older version of autoconf for other packages that have not been updated
>for the 2.50 changes.
>
>Thoughts?

Cute technique.  But previously we have never attempted to maintain
compatibility with more than one version of autoconf; we have always had
a flag day where all developers have had to switch to the new version, and
it has never been a problem.  When dealing with packages as convoluted as
ours, such as to require a specific version of autoconf, it does not seem
too much of a burden for developers (specifically, developers that modify
the configure source) to marshall more than one version of autoconf.

I'm glad we won't need that config.status kludge any more.

-zefram

Re: PATCH: Re: zsh and autoconf-2.50

[Bart Schaefer]

On Jun 4,  8:36am, Zefram wrote:
}
} Cute technique.  But previously we have never attempted to maintain
} compatibility with more than one version of autoconf; we have always had
} a flag day where all developers have had to switch to the new version, and
} it has never been a problem.

Previously, however, we were not maintaining the source code in CVS, and
the developers therefore always had the configure script and did not need
to run autoconf.  Since SourceForge, it's quite likely that a developer
might get the source code without getting the configure script.

This means that even "casual" developers would be forced to upgrade to
the latest autoconf.

Putting the configure script into CVS too is certainly an option, but it
is somewhat error-prone -- it's too easy to commit one without the other,
and eventually we start running into issues with autoconf 2.5x vs. 2.5y,
e.g. both autoconfs work with configure.ac but produce slightly different
configure scripts so that spurious diffs can get committed.

} When dealing with packages as convoluted as ours, such as to require
} a specific version of autoconf, it does not seem too much of a burden
} for developers (specifically, developers that modify the configure
} source) to marshall more than one version of autoconf.

My specific objections are that (a) as already noted, it's not limited
just to developers who modify the configure source, and (b) when dealing
with package-manager-based installations such as most linux distributions,
it's somewhat more difficult to "marshall more than one version" without
causing unintended side-effects.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

RE: PATCH: Re: zsh and autoconf-2.50

[Andrej Borsenkow]

>
> } When dealing with packages as convoluted as ours, such as to require
> } a specific version of autoconf, it does not seem too much of a burden
> } for developers (specifically, developers that modify the configure
> } source) to marshall more than one version of autoconf.
>
> My specific objections are that (a) as already noted, it's not limited
> just to developers who modify the configure source,

Anybody who fiddles with configure.in^H^Hac should be prepared to deal with
(in-)compatibilities so it is not really a question. It is 500KB and needs
just GNU m4 to run.


and (b) when dealing
> with package-manager-based installations such as most linux distributions,
> it's somewhat more difficult to "marshall more than one version" without
> causing unintended side-effects.
>

Yes, I have not thought about it. This is the real argument. Even Mandrake
cooker has not dared to update to 2.50 yet. Still, I do not speak about
4.0.x - it will remain as is. I speak about 4.1.x that is development
version anyway.

No I do not push it. 2.50 is nice and more clean and some tasks can be
implemented in much more natural way but there is nothing really pressing.

So, I'm personally inclined to implement Bart's idea for 4.0.x and redesign
for 2.50 in 4.1.x at some point near 4.1.1.

-andrej

Commited: RE: PATCH: Re: zsh and autoconf-2.50

[Andrej Borsenkow]

>
> How about the following:
>
> Create a new file "zshconf.ac" (or "zshconf.in" or whatever, it really
> doesn't matter).  Most of the contents of the current configure go into
> this file -- everything up to the "missing some essential features" hack.
>
> Add a macro to aczsh.m4 to output the "zsh configuration" report at that
> appears at the end of the current configure.in.
>
> Create a new file configure.ac that contains:
>
>     m4_include([zshconf.ac])
>     test "$real_no_create" = yes ||
> 	${CONFIG_SHELL-/bin/sh} $CONFIG_STATUS || exit 1
>     zsh_SHOWCONFIG
>
> Change configure.in to be a file that contains only:
>
>     dnl Backwards compatibility with autoconf 2.13.
>
>     builtin([include], [zshconf.ac])
>
>     dnl The standard config.status is missing some essential features.
>     dnl (etc. etc.)
>
>     test "$real_no_create" = yes ||
> 	${CONFIG_SHELL-/bin/sh} $CONFIG_STATUS || exit 1
>     zsh_SHOWCONFIG
>

I commited it in HEAD. I do not post diffs as this would be just current
configure.in; still here are configu.in and conifgure.ac for review.

I had to use AC_INIT to allow overriding of no_create; I then decided to use
correct AC_INIT for 2.50 and found one more problem. It requires literal
version number; having two versions (in configure.in and Config/version.mk)
is obviously silly. I'm inclined to put version in configure.{in,ac} and
create version.mk out of version.mk.in. This means the least changes in
Makefiles.

Please add any copyrights you feel needed.

Note, that config.cache is incompatible between two versions. 2.50 by
default does not cache anything; you can persuade it but then better remove
old cache.

-andrej

bor@itsrm2% cat configure.in

AC_INIT(Src/zsh.h)

real_no_create=$no_create
no_create=yes

builtin([include], [zshconfig.ac])

dnl The standard config.status is missing some essential features.
dnl So add them now.  See the comment at the end of Src/mkmakemod.sh.
[rm -f $CONFIG_STATUS.old
cp $CONFIG_STATUS $CONFIG_STATUS.old
sed '1,$s@^\( *ac_file_inputs=\).*$@\1`echo $ac_file_in | sed -e "s%^%:%" -e
"s%:\\([^!]\\)% $ac_given_srcdir/\\1%g" -e "s%:!% %"`@' \
 $CONFIG_STATUS.old >$CONFIG_STATUS
 echo "# Hack for autoconf-2.13" >>$CONFIG_STATUS
 chmod +x $CONFIG_STATUS
 rm -f $CONFIG_STATUS.old]

test "$real_no_create" = yes || ${CONFIG_SHELL-/bin/sh} $CONFIG_STATUS ||
exit 1


bor@itsrm2% cat configure.ac

AC_INIT(zsh, 4.1.0-dev-0, [zsh-workers@sunsite.dk])
AC_PREREQ(2.50)
AC_CONFIG_SRCDIR(Src/zsh.h)

m4_include([zshconfig.ac])

Re: Commited: RE: PATCH: Re: zsh and autoconf-2.50

[Peter Stephenson]

"Andrej Borsenkow" wrote:
> It requires literal
> version number; having two versions (in configure.in and Config/version.mk)
> is obviously silly. I'm inclined to put version in configure.{in,ac} and
> create version.mk out of version.mk.in. This means the least changes in
> Makefiles.

That's a pain in the neck.  Your solution is about the only way round.

> Please add any copyrights you feel needed.

Copyright on configuration stuff traditionally seems to be lax --- probably
because it would make it impossible for projects with different copyrights
otherwise.

> Note, that config.cache is incompatible between two versions. 2.50 by
> default does not cache anything; you can persuade it but then better remove
> old cache.

Can we turn this on, or is there some good reason for not having it?

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR Ltd., Unit 300, Science Park, Milton Road,
Cambridge, CB4 0XL, UK                          Tel: +44 (0)1223 392070


**********************************************************************
The information transmitted is intended only for the person or
entity to which it is addressed and may contain confidential 
and/or privileged material. 
Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by 
persons or entities other than the intended recipient is 
prohibited.  
If you received this in error, please contact the sender and 
delete the material from any computer.
**********************************************************************

Re: Commited: RE: PATCH: Re: zsh and autoconf-2.50

[Bart Schaefer]

On Jun 6, 10:44am, Peter Stephenson wrote:
}
} > Note, that config.cache is incompatible between two versions. 2.50
} > by default does not cache anything; you can persuade it but then
} > better remove old cache.
} 
} Can we turn this on, or is there some good reason for not having it?

autoconf.texi from the autoconf 2.50 cvs repository says:

-------------
By default, @code{configure} uses no cache file (technically, it uses
@option{--cache-file=/dev/null}), to avoid problems caused by accidental
use of stale cache files.

To enable caching, @code{configure} accepts @option{--config-cache} (or
@option{-C}) to cache results in the file @file{config.cache}.

 ....

@c FIXME: Do we really want to document this guy?
@defmac AC_CACHE_LOAD
@maindex CACHE_LOAD
Loads values from existing cache file, or creates a new cache file if a
cache file is not found.  Called automatically from @code{AC_INIT}.
@end defmac
-------------

So we could explicitly call AC_CACHE_LOAD, but it could go away in the
future.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

RE: Commited: RE: PATCH: Re: zsh and autoconf-2.50

[Andrej Borsenkow]

>
> So we could explicitly call AC_CACHE_LOAD, but it could go away in the
> future.
>

This won't go away (it is documented interface) but will happily source
/dev/null. You still have to set valid cache file.

-andrej

RE: Commited: RE: PATCH: Re: zsh and autoconf-2.50

[Andrej Borsenkow]

>
> > Note, that config.cache is incompatible between two versions. 2.50 by
> > default does not cache anything; you can persuade it but then
> better remove
> > old cache.
>
> Can we turn this on, or is there some good reason for not having it?
>

It depends. For initial configure run you have to manually
use --cache-file=config.cache (or --config-cache) or set cache file in site
config file ($prefix/{share,etc}/site.config -whatever exists or
CONFIG_SITE=...). For Makefile dependencies we can
add --cache-file=config.status - the only problem is if user specified
another cache file when running conifgure ... hopefully rare.

Why it was turned off by default - dunno, I never followed autoconf
development too closely. I Cc it to the autoconf list.

-andrej

Re: Commited: RE: PATCH: Re: zsh and autoconf-2.50

[Akim Demaille]

>>>>> "Andrej" == Andrej Borsenkow <Andrej.Borsenkow@mow.siemens.ru> writes:

>> > Note, that config.cache is incompatible between two
>> versions. 2.50 by > default does not cache anything; you can
>> persuade it but then better remove > old cache.
>> 
>> Can we turn this on, or is there some good reason for not having
>> it?

Yes, zillions of them.  Look for `config.cache considered harmful' in
the archives.

Andrej> It depends. For initial configure run you have to manually use
Andrej> --cache-file=config.cache (or --config-cache) 

Or -C.

Andrej> or set cache file in site config file
Andrej> ($prefix/{share,etc}/site.config -whatever exists or
Andrej> CONFIG_SITE=...). For Makefile dependencies we can add
Andrej> --cache-file=config.status

s/status/cache/.

I fear I understand what you mean, but I might be wrong.  The use of a
cache is a decision that belongs to the user and no one else.  You
should not try to change this.

Andrej> Why it was turned off by default - dunno, I never followed
Andrej> autoconf development too closely. I Cc it to the autoconf
Andrej> list.

We will write something about it in 2.51's docs, thanks.

RE: Commited: RE: PATCH: Re: zsh and autoconf-2.50

[Andrej Borsenkow]

>
> I fear I understand what you mean, but I might be wrong.  The use of a
> cache is a decision that belongs to the user and no one else.  You
> should not try to change this.
>

To clarify - if I have used conifgure -C initially and have

config.status: $(sdir)/configure
        $(SHELL) ./config.status --recheck

in Makefile. Will config.status --recehck (re-)use cache file? If yes, it is
O.K. then.

-andrej

Re: Commited: RE: PATCH: Re: zsh and autoconf-2.50

[Akim Demaille]

>>>>> "Andrej" == Andrej Borsenkow <Andrej.Borsenkow@mow.siemens.ru> writes:
Andrej> To clarify - if I have used conifgure -C initially and have

Andrej> config.status: $(sdir)/configure $(SHELL) ./config.status
Andrej> --recheck

Andrej> in Makefile. Will config.status --recehck (re-)use cache file? 
Andrej> If yes, it is O.K. then.

Of course it works!

/tmp % echo "AC_INIT()AC_OUTPUT()" > configure.ac                nostromo 14:45
/tmp % ace                                                       nostromo 14:45
/tmp % ./configure MY_SHELL=zsh -C                               nostromo 14:45
configure: creating cache config.cache
updating cache config.cache
configure: creating ./config.status
/tmp % ./config.status --recheck                                 nostromo 14:45
running /bin/sh ./configure  MY_SHELL=zsh -C  --no-create --no-recursion
configure: loading cache config.cache
configure: creating ./config.status

RE: Commited: RE: PATCH: Re: zsh and autoconf-2.50

[Andrej Borsenkow]

> > It requires literal
> > version number; having two versions (in configure.in and
> Config/version.mk)
> > is obviously silly. I'm inclined to put version in configure.{in,ac} and
> > create version.mk out of version.mk.in. This means the least changes in
> > Makefiles.
>
> That's a pain in the neck.  Your solution is about the only way round.
>

I gave up. In all cases I needed vesion number in at least two files
(configure.in and configure.ac) that makes the whole story useless.

I would suggest that for 4.1.1 (or when we decide to switch to autoconf-2.50
completely) we use version number in AC_INIT and VERSION_DATE autogenerated
from configure.ac change date. That leaves us with exactly one place to
edit. There remains version.yo but it can happily depend on configure.ac in
this case.

-andrej

I'm going to commit this in 4.0 as final version.

Index: configure.ac
===================================================================
RCS file: /cvsroot/zsh/zsh/configure.ac,v
retrieving revision 1.1
diff -u -r1.1 configure.ac
--- configure.ac        2001/06/06 08:37:21     1.1
+++ configure.ac        2001/06/06 12:30:20
@@ -1,7 +1,6 @@

-AC_INIT(zsh, 4.1.0-dev-0, [zsh-workers@sunsite.dk])
+AC_INIT(Src/zsh.h)
 AC_PREREQ(2.50)
-AC_CONFIG_SRCDIR(Src/zsh.h)

 m4_include([zshconfig.ac])

Re: Commited: RE: PATCH: Re: zsh and autoconf-2.50

[Bart Schaefer]

On Jun 6, 12:45pm, Andrej Borsenkow wrote:
} Subject: Commited: RE: PATCH: Re: zsh and autoconf-2.50
}
} > Create a new file "zshconf.ac" (or "zshconf.in" or whatever, it really
} > doesn't matter).  Most of the contents of the current configure go into
} > this file -- everything up to the "missing some essential features" hack.

I think you forgot to pass the name of zshconf.ac as an argument to the
autoheader command in Makefile.in.  Does it work for you anyway?  (I
haven't tried yet.)

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

RE: Commited: RE: PATCH: Re: zsh and autoconf-2.50

[Andrej Borsenkow]

> }
> } > Create a new file "zshconf.ac" (or "zshconf.in" or whatever, it really
> } > doesn't matter).  Most of the contents of the current
> configure go into
> } > this file -- everything up to the "missing some essential
> features" hack.
>
> I think you forgot to pass the name of zshconf.ac as an argument to the
> autoheader command in Makefile.in.  Does it work for you anyway?  (I
> haven't tried yet.)
>

You do not need to. autoheader-2.13 calls m4 on input file and
autoheader-2.50 is using autoconf --trace (very useful to debug configure
problem - check docs). In both cases all include files are correctly
processed.

-andrej

Re: zsh and autoconf-2.50

[Peter Stephenson]

> Quoting, quoting ...
> 
> ifdef([zsh-debug],[undefine([zsh-debug])])dnl

OK, go ahead and commit this will I'm fiddling around.

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR Ltd., Unit 300, Science Park, Milton Road,
Cambridge, CB4 0XL, UK                          Tel: +44 (0)1223 392070


**********************************************************************
The information transmitted is intended only for the person or
entity to which it is addressed and may contain confidential 
and/or privileged material. 
Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by 
persons or entities other than the intended recipient is 
prohibited.  
If you received this in error, please contact the sender and 
delete the material from any computer.
**********************************************************************

Re: zsh and autoconf-2.50

[Peter Stephenson]

"Andrej Borsenkow" wrote:
> > Gag.  OK, here's a full paranoid replacement just for now, instead of the
> > previous two attempts.  It produces an identical configure, which is all
> > I'm really worried about.
> 
> I must be stupid, but it does not work foe mr:

Urgh.  Well, it's harmless (and anyway I'm not using the latest autoconf
for the 4.0.1 distribution).  It can simply disappear without trace when
the present nightmare is over.  Might be something to do with quoting, but
what I wrote seems to agree with what the info pages for M4 suggest.

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR Ltd., Unit 300, Science Park, Milton Road,
Cambridge, CB4 0XL, UK                          Tel: +44 (0)1223 392070


**********************************************************************
The information transmitted is intended only for the person or
entity to which it is addressed and may contain confidential 
and/or privileged material. 
Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by 
persons or entities other than the intended recipient is 
prohibited.  
If you received this in error, please contact the sender and 
delete the material from any computer.
**********************************************************************

Re: zsh and autoconf-2.50

[Clint Adams]

> This is with a just checked out copy. Am I doing something wrong?
> 
> taiko:/depot/src/zsh% ./Util/preconfig
> cd . && ./.preconfig
> configure.in:55: error: undefine: undefined: zsh-debug
> configure.in:55: the top level
> ./Util/preconfig: ./.preconfig failed (status 1)

If you just delete the "undefine" lines it complains about, it
will be happy.  However, if you run autoupdate, it will make
a mess.

Re: zsh and autoconf-2.50

[Jos Backus]

On Wed, May 30, 2001 at 06:33:38PM -0400, Clint Adams wrote:
> If you just delete the "undefine" lines it complains about, it
> will be happy.  However, if you run autoupdate, it will make
> a mess.

Right.

I just installed the previous version of autoconf, 2.13, and lo and behold:
both the m4 undefine and the config.status problem aren't there. So this looks
like some weird interaction between autoconf-2.50 and m4, no?

Off to building zsh with Purify... Has anybody done this before? Is it really
useful? Any tips?

Thanks,
-- 
Jos Backus                 _/  _/_/_/        "Modularity is not a hack."
                          _/  _/   _/                -- D. J. Bernstein
                         _/  _/_/_/             
                    _/  _/  _/    _/
josb@cncdsl.com     _/_/   _/_/_/            use Std::Disclaimer;

Re: zsh and autoconf-2.50

[Andrej Borsenkow]

It is pretty useless as of now (BTW 2.50 is known to break some packages).
I wait for 4.0.1 release before starting hacking configure.in.

-andrej

Re: zsh and autoconf-2.50

[Clint Adams]

> It is pretty useless as of now (BTW 2.50 is known to break some packages).

Mainly those that use autoconf-internal functions.

> I wait for 4.0.1 release before starting hacking configure.in.

We might want to send configure.in to the Attic and name it configure.ac
after 4.0 gets branched off.

RE: zsh and autoconf-2.50

[Andrej Borsenkow]

>
> > I wait for 4.0.1 release before starting hacking configure.in.
>
> We might want to send configure.in to the Attic and name it configure.ac
> after 4.0 gets branched off.
>

Yes, that is what I intended to do. Still, it may be impossible to maintain
both configure.in and configure.ac so I prefer to not disturb things until
release.

-andrej