>>>>> "Steven" == Steven G Johnson <[EMAIL PROTECTED]> writes:
Steven> My inclination is to think that the list of things "required"
Steven> for 2.15 is a little overly ambitious. If some minor issue is
Steven> unchanged from 2.13, e.g. not enough environment variables
Steven> being documented, I don't see why it should hold up the
Steven> release considering the number of improvements that have been
Steven> made. You can always fix those things in the next release. I
Steven> would think that the main concern should be that no new
Steven> problems have been added.
I agree the documentation of the envvar is no big problem, but I do
think we must finish all the other pending issues before releasing.
We can snapshot before the documentation is completely revisited, but
I don't want to release things which are wrong, since that's an
engagement for the future.
Basically all the pending issues are either finishing undergone
changes, or making sure we engaged ourselves on the right track.
Nevertheless I agree there are some issues which I listed as required
which might not be really needed: those related to Automake.
My first idea was that Autoconf 2.50 should be Automake friendly, so
that the next release of Automake will be able to use the new features
meant for it. But today I think we will be able to release several
Autoconves before the birth of an Automake which really relies on
Autoconf. I checked in the version of TODO which reflects this change
of thoughts.
Akim
* Autoconf 2.50
** AC_INIT(PACKAGE)
Decide with the team whether they prefer that AC_PACKAGE_NAME etc. be
a macro, or a shell variable ac_package_name. Had we used AC_PACKAGE
anywhere in configure.in, we would have had to use an shvar. Also,
think of the capitalization! For instance this package is named
`Autoconf', but the tarball is `autoconf-'. What of the space?
Do we need another user input for the name of the tarball?
** Doc: autoconf
Document --install. Should --install `fix' configure.in for the user?
** DJGPP
2.15 cannot be released without having `make check' succeed under
DJGPP. EMX will be a requirement for the next release, not this one.
** AC_REQUIRE
Axel Thimm (Sp?) once sent a very nice bug report about some problems
when requirements are crossed. Fix it, and test it.
** Doc:
Should we document AC_LANG_* and AC_*_IFELSE? I hope the interface is
right...
** AC_CONFIG_LINKS
_Must_ support shell variables. Yet another patch to config.status...
** autoconf --install
We must finalize the interface we want.
** Portability
${1+"$@"}, set dummy.
** --target & AC_ARG_PROGRAM
Shouldn't *any* `program' be installed as `$target_alias-program' even
if AC_ARG_PROGRAM is not called? That would be much more predictable.
Ian?
** AC_SYS_LARGEFILE
We *need* it.
** More macros from Jim
Those related to *_SLASH_*.
** AC_FUNC_GETLOADAVG
We must find a solution for this macro which needs to find
`getloadavg.c'.
** AC_PROG_CC_STDC
Should be: AC_PROG_CC_ISO? Or even more specific for the ISO version?
Should include more tests (e.g., AC_C_CONST etc.)?
** Document
GNATS, bug-autoconf, Autoconf Macro Archive, Automake, Libtool.
** Pentateuch
Heck, there is nothing after `Deuteronomy'! We're stuck, but we
_must_ update the `history' section. Can't go to `New testament', we
might hurt feelings? In addition, it means that the Messiah has come,
which might be slightly presumptuous :). Still, someone fluent in
English should write it.
** AUTHORS
Now what?
** More C compilers (How come this has never been handled? --akim)
Question: at least one common UNIX variant has a "cc" that is old K&R
and "c89" for ANSI C. Is there any reason why AC_PROG_CC couldn't
check for c89 before cc if it can't find gcc?
[EMAIL PROTECTED] (H. Peter Anvin)
** @magic@ expanded in all the AC_SUBST (I think this one is obsoleted
with the existence of Automake. Remove this wish? --akim)
Perhaps Autoconf could have a single @magic@ frob that gets replaced with
assignments for all the *dir variables? There is quite a plethora for each
Makefile.in to have foodir = @foodir@.
From: Roland McGrath <[EMAIL PROTECTED]>
* Autoconf 2.51 or so
** AC_SYS_INTERPRETER
Defines $interpval. This is not a standard name. Do we want to keep
this? Clarify our policy on those names.
** AC_PROVIDE
I think it is the epilogue that should provide, not the prologue. Not
clear: there are risks of circular dependencies :(. In fact the
relationship AC_BEFORE should be given outside the macro themselves.
** AC_ARG_VAR
If should check that none of the envvar it is in charge of, has
changed. The configure.in writer may supply what to do (FATAL, WARN
etc.). See VALIDATE CACHE TUPLE. Document. Where?
Document more variables: CC, CXX etc.
** autoupdate
We should probably install the files which do not depend upon the
user, just the Autoconf library files. But conversely autoupdate must
be opened to user macros, i.e., for instance libtool itself must be
able to say that AM_PROG_LIBTOOL is now AC_PROG_LIBTOOL, and have
autoupdate do its job on old configure.in.
** AC_LIBOBJ_DECL
Decide with the Automake team whether this macro should list only `.c'
files, or it should include the `.h' too. For instance the
AC_FUNC_GNU_GETOPT macro could provide the three files, likewise for
the macro which allows to choose a regex engine.
** Document the coding style
Browse the Autoconf Macro Archive, spot what we don't like, and
document it. Explain AC_DEFUN vs. define. Explain people should
really quote the names of the macros when they define it. Stress that
AC_FUNC_* which AC_REPLACE should not inline the setup of the
replacement function, it's unreadable.
** Allow --recursive to config.status
So that --recheck does not pass --no-recursive to configure.
** config.status
Lars seemed to need to be able to apply both the AC_SUBST and
AC_DEFINE transformation on a single file, which implies that we must
be able to have `.in' files either in srcdir or in builddir. In fact,
have a look at the configuration of Zsh: they patch config.status on
the fly to have it look for the files in builddir instead of srcdir!!!
There is a real problem, Autoconf must help. BTW, why do they need
that?
