autoconf/TODO

-*- outline -*-

Things it might be nice to do someday.  I haven't evaluated all of
these suggestions... their presence here doesn't imply my endorsement.
-djm & his successors.


------------------------------------------------------------------------------

* Required for 2.15

These are things mandatory to fulfill before releasing 2.15.  There
are also suggestions we should either satisfy right now (they're
easy), or remove (obsoleted since then).

** autoconf.texi: config.status in node names.
The info mode of Emacs seems to have problems with this.  If the info
reader catches that properly, we should not care.  If no info reader
can handle this, we should change the affected node names.  Bug
triggered by looking for `CONFIG_FILES' in the index.

** autoconf.texi: Document AC_CONFIG_FILES.
I didn't do it, because I don't know where to do that.  I would like
to have all the AC_CONFIG_ together, but it is not currently the
case.  An architecture for the docs needs to be decided.

** autoconf.texi, near fubar=27.
This example is *wrong*.  fubar is set in configure, not
config.status, therefore the extra commands will not know $fubar, as
the example let us believe.

** AC_C_STRUCT_MEMBER needs a full rewrite.
And once done, the former specialized macros should be adapted.
AC_CHECK_MEMBER/AC_CHECK_MEMBERS is a proposal, see the code.

** AC_CHECK_HEADER should not template config.h entries.
Its entry in autoheader.m4 should be removed.

** Allow tags for AC_OUTPUT_COMMANDS
so that we  can run ./config.status name-of-the command.

** Generalize the association of a commands to an output file.
See AC_CONFIG_FILES: it is possible to associate a command which is
run when the file is creating.  This should be extended to all the
other AC_CONFIG entities.  But then there is a question: should the
commands associated to a HEADER be in config.status's HEADER section,
ran right after the file is created, or we should just plug the
commands in the section of tagged AC_OUTPUT_COMMANDS.  There are two
issues here: if we want to display the commands ran, then we want them
to appear after `creating ...', not at the end.  It is also better wrt
trapping (since files are finalized sooner, there are less files to
remove when C-c is caught).  On the other hand, it is a bit less
pleasant to program in Autoconf.

** Rename AC_CONFIG_HEADER as AC_CONFIG_HEADERS?
See the FIXME note in the code.

** Allow --recursive to config.status
So that --recheck does not pass --no-recursive to configure.

** Allow --header, --command, --file to config.status.
I don't remember the purpose, ask Alexandre.

** Move AM_PROG_CC_STDC into Autoconf.
Autoconf should provide the means to determine the ANSIsm of the
compiler, not Automake.
I've done it, but this is the last opportunity to change this macro
name: AC_PROG_CC_ISO?  Or even more specific for the ISO version?

** Provide means to provides commands to run before AC_OUTPUT.
This is what is needed for LTLIBOBJS and others.

** Document GNATS?

** gettext (This is more for Automake, but I'm afraid to forget --akim)
There a nsl_cv_ which is actually nls_cv_.
It seems not valid to me to give twho empty strings to AC_LINK_FILES.
The user should check herself if she wants not to link, it is not
the job of Autoconf.

Currently there are hacks to keep it legal, but it should be made
illegal in the future.

** fnmatch
From: Stanislav Brabec <utx@k332.feld.cvut.cz>

If AC_LANG is c++ and c++ is (at least) gcc-2.95.1, the result is error;
it can be fixed on my system by #include <fnmatch.h>, but I don't
know, if it is general include.
Other possible fix is checking for fnmatch using cc in any case.


Log part:

configure:1955: checking for working fnmatch
configure:1973: c++ -o conftest  -O69 -fomit-frame-pointer  -I/usr/games/include  -I/usr/games/include  confte
st.C -lclanlayer2 -lclan -L/usr/X11R6/lib  -L/usr/games/lib 1>&5
configure: In function `int main()':
configure:1970: implicit declaration of function `int fnmatch(...)'
configure: failed program was:
#line 1966 "configure"
#include "confdefs.h"
#ifdef __cplusplus
extern "C" void exit(int);
#endif
main() { exit (fnmatch ("a*", "abc", 0) != 0); }


** We should remove obsolete things.
Both in the doc and the code.  Looking for the keyword `obsolete'
proves to be useful.

** Clarify exactly our position wrt `#define' templates.
The fact that there are `#define' templates forbids many useful
optimizations.  In fact, who really uses #define template in
config.h.in?

** Write the documentation of AC_ARG_VAR
where should it go?

** Mention automake, libtool, etc. in the Autoconf manual.

** 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?

hpa@yggdrasil.com (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 <roland@gnu.ai.mit.edu>

------------------------------------------------------------------------------

* Autoconf 3

** Use m4 lists?
I think one sad decision in Autoconf was to use white space separated
lists for some arguments.  For instance AC_CHECK_FUNCS(foo bar).  I
tend to think that, even if it is not as nice, we should use m4 lists,
i.e., AC_CHECK_FUNCS((foo, bar)) in this case.  This would ease
specializing loops, and more importantly, make them much more robust.

A typical example of things that can be performed if we use m4 lists
instead of white space separated lists is the case of things that have
a space in their names, eg, structures.

With the current scheme it would be extremely difficult to loop over
AC_CHECK_STRUCTS(struct foo struct bar), while it natural and well
defined for m4 lists: AC_CHECK_STRUCTS((struct foo, struct bar)).

I know that makes a huge difference in syntax, but a major release
should be ready to settle a new world.  We *can* provide helping tools
for the transition.  Considering the benefits, I really think it is
worth thinking. --akim

** Forbid shell variables as main arguments
The fact that we have to support shell variables as main argument
forbids many interesting constructions (specialization are not always
possible, equally for AC_REQUIRE'ing macros *with their arguments*).
Any loop should be handled by m4 itself, and nothing should be hidden
to it.  As a consequence, shell variables on the main arguments become
useless (the main reason we support shell variables is to allow the
loop versions of single argument macros, eg, to go from AC_CHECK_FUNC
to AC_CHECK_FUNCS). --akim

** Use the @SUBST@ technology also for headers instead of #undef.
This requires that acconfig.h becomes completely obsolete: autoheader
should generate all the templates.

** Specializing loops.
For instance, make AC_CHECK_FUNC[S] automatically use any particular
macros for the listed functions.
This requires to obsolete the feature `break' in ACTION-IF, since all
the loops are to be handled by m4, not sh.

** Merge the two lex macros, AC_PROG_LEX and AC_DECL_YYTEXT?
Add give a mean to *require* Flex instead of Lex.

** Faces of a test
Each macro can potentially come with several faces: of course the
configure snippet (AC_foo), a config.h snippet (AH_foo), a system.h
snippet (AS_foo), documentation (AD_foo) and, why not, the some C code
for instance to replace a function.

The motivation for the `faces' is to encapsulate.  It is abnormal that
once one has a configure macro, then she has to read somewhere to find
the piece of system.h to use etc.  The macros should come in a
self-contained way, or, said it another way, PnP.

A major issue is that of specialization.  AC_CHECK_HEADER (or another
name) for instance, will have as an effect, via system.h to include
the header.  But if the test for the header is specific, the generic
AS_CHECK_HEADER will still be used.  Conversely, some headers may not
require a specific AC_ tests, but a specialized AS_ macro.

------------------------------------------------------------------------------

* Matthew D. Langston's suggestions:

** Change all of Autoconf's macros that print a help string via
   "configure --help" to use new AC_HELP_STRING macro.

** Ensure that "make check" uses only the files from the build tree.  It
   currently uses some of the installed files from previously installed
   versions of Autoconf, like autoheader.m4f.

** Give autoheader.sh the capability to use a local version of
   autoheader.m4.  It currently always uses the installed frozen version
   autoheader.m4f.

------------------------------------------------------------------------------

* Write an automake Makefile.am to replace the existing Makefile.in.

------------------------------------------------------------------------------

* Make AC_CHECK_LIB check whether the function is already available
  before checking for the library.  This might involve adding another
  kind of cache variable to indicate whether a given function needs a
  given library.  The current ac_cv_func_ variables are intended to
  indicate whether the function is in the default libraries, but
  actually also take into account whatever value LIBS had when they
  were checked for.

  Isn't this the issue of AC_SEARCH_LIB? --akim
  How come the list of libraries to browse not an additional parameter
  of AC_CHECK_FUNC, exactly like for the headers? --akim

------------------------------------------------------------------------------

* Add AC_PROG_CC_POSIX to replace the current ad-hoc macros for AIX,
  Minix, ISC, etc.

------------------------------------------------------------------------------

* Support creating both config.h and DEFS in the same configure.

------------------------------------------------------------------------------

* Select the right CONFIG_SHELL automatically (for Ultrix, Lynx especially.)

------------------------------------------------------------------------------

* Doc: Add a concept index.

------------------------------------------------------------------------------

* Doc: Centralize information on POSIX, MS-DOS, cross-compiling, and
  other important topics.

------------------------------------------------------------------------------

* Split up AC_SUBST substitutions using a loop to accommodate shells
  with severely limited here document sizes, if it turns out to be a problem.
  I'm not sure whether the limit is on lines or bytes; if bytes, it
  will be less of a problem than it was with the long lines used for
  creating a header file.

------------------------------------------------------------------------------

* Allow [ and ] in AC_DEFINE args.

------------------------------------------------------------------------------

* Mike Haertel's suggestions:

** Provide header files containing decls for alloca, strings, etc.

** Cross compiling:

*** Error messages include instructions for overriding defaults using
config.site.

*** Distribute a config.site corresponding to a hypothetical bare POSIX system with c89.

** Site defaults:

*** Convention for consistency checking of env vars and options in config.site so config.site can print obnoxious messages if it doesn't like options or env vars that users use.

------------------------------------------------------------------------------

* autoscan: Tell the files that caused inclusion of each macro,
in a dnl comment.  (Seems to be hard.)

------------------------------------------------------------------------------

* Look at user contributed macros:
	prototypes
	IEEE double precision math
	more

------------------------------------------------------------------------------

For AC_TYPE_SIGNAL signal handlers, provide a way for code to know
whether to do "return 0" or "return" (int vs void) to avoid compiler
warnings.  (Roland McGrath)

------------------------------------------------------------------------------

In config.status comment, put the host/target/build types, if used.

------------------------------------------------------------------------------

The default of unlimited permission is fine, but there should be some easy
way for configure to have copyright terms passed through from configure.in.
Maybe AC_LICENSE([...]).
From: roland@gnu.ai.mit.edu (Roland McGrath)

------------------------------------------------------------------------------

AC_MSG_CHECKING([checking for ANSI #stringize])
AC_REVISION([ #(@) revision 2.1 ])

causes bogus code to be generated for whatever immediately follows.  The
problem goes away if the '#' is removed.  Probably the macros are not
disabling the m4 "comment" feature when processing user-supplied strings.
-Jim Avera jima@netcom.com

------------------------------------------------------------------------------

on hal.gnu.ai.mit.edu, configure is getting the wrong answer for
AC_CHECK_FUNCS(select).

The problem here is that there's severe namespace pollution: when
conftest.c includes <ctype.h> to pick up any __stub macro definitions,
it's getting a prototype declaration for select(), which collides
with the dummy declaration in conftest.c.  (The chain of includes
is conftest.c -> <ctype.h> -> <sys/localedef.h> -> <sys/lc_core.h>
-> <sys/types.h> -> <sys/select.h>.)

	#define $ac_func __dummy_$ac_func
	#include <ctype.h>
	#undef $ac_func
From: kwzh@gnu.ai.mit.edu (Karl Heuer)

The test for the isascii function was failing because that function is
also a macro.  He proposed that the test file look like this:

/* Remove any macro definition. */
#undef isascii
/* Override any gcc2 internal prototype to avoid an error.  */
char isascii(); isascii();

Andreas Schwab

------------------------------------------------------------------------------

put all the config.* stuff somewhere like config/?
All these extraneous files sure clutter up a top level directory.
From: "Randall S. Winchester" <rsw@eng.umd.edu>

------------------------------------------------------------------------------

It would be nice if I could (in the Makefile.in files) set
the path to config.h. You have config.h ../config.h ../../config.h's all
over the place, in the findutils-4.1 directory.
From: "Randall S. Winchester" <rsw@eng.umd.edu>

------------------------------------------------------------------------------

In libc and make in aclocal.m4 I have AC_CHECK_SYMBOL, which checks for
sys_siglist et al.  Using AC_CHECK_FUNC doesn't work on some system that
winds up caring that you reference it as a function and it is really a
variable.  My version always declares the symbol as a char *[]; if that
ends up a bad idea, we can have it take an arg with the C decl, but that is
a bit verbose to write if it's actually superfluous.
From Roland McGrath.
[I'd call it AC_CHECK_VAR, I think. -djm]

------------------------------------------------------------------------------

In a future version (after 2.2), make AC_PROG_{CC,RANLIB,anything else}
use AC_CHECK_TOOL.
From Roland McGrath.

------------------------------------------------------------------------------

	ls -lt configure configure.in | sort
doesn't work right if configure.in is from a symlink farm, where the
symlink has either a timestamp of its own, or under BSD 4.4, it has
the timestamp of the current directory, neither of which
helps. Changing it to
	ls -Llt configure configure.in | sort
works for me, though I don't know how portable that is
_Mark_ <eichin@cygnus.com>

------------------------------------------------------------------------------

Here is the thing I would like the most;
AC_PKG_WITH(PACKAGE, HELP_STRING, PACKAGE-ROOT, PACKAGE-LIBS, PACKAGE-DEFS,
	PACKAGE-CCPFLAGS)
like

AC_PKG_WITH(kerberos,,/usr/local/athena,-lkrb -ldes,[KERBEROS KRB4
CRYPT],include)
AC_PKG_WITH(hesiod,
[if hesiod is not in kerberos-root add --with-hesiod-root=somewhere]
,,-lhesiod,HESIOD,,)
AC_PKG_WITH(glue,,,-lglue,GLUE,,)
AC_PKG_WITH(bind,,/usr/local/bind, [lib/resolv.a lib/lib44bsd.a], ,include)
After the apropriate checks, the existance of the paths, and libs and such
LIBS=$LIBS $PKG-LIBS
DEFS=$DEFS $PKG-DEFS
CPPFLAGS=$PKG-CPPFLAGS $CPPFLAGS
$PKG-ROOT=$PKG-ROOT
The cppflags should reverse the order so that you can have;
-I/usr/local/bind/include -I/usr/local/athena/include
and
-L/usr/local/athena/lib -lkrb -ldes /usr/local/bind/lib/libresolv.a
as order matters.

also an AC_PKG_CHK_HEADER
and an AC_PKG_CHK_FUNCTION
so one can give alternate paths to check for stuff ($PKG-ROOT/lib for
example)
From: Randall Winchester

------------------------------------------------------------------------------

AC_C_CROSS assumes that configure was
called like 'CC=target-gcc; ./configure'. I want to write a package
that has target dependent libraries and host dependent tools. So I
don't like to lose the distinction between CC and [G]CC_FOR_TARGET.
AC_C_CROSS should check for equality of target and host.

It would be great if

GCC_FOR_TARGET
AR_FOR_TARGET
RANLIB_FOR_TARGET

would be set automatically if host != target.
AC_LANG_CROSS_C would be nice too, to check header files
etc. with GCC_FOR_TARGET instead of CC

Here is one simple test

if test "x$host" != "x$target"; then
AC_PROGRAMS_CHECK(AR_FOR_TARGET, $target-ar, $target-ar, ar)
AC_PROGRAMS_CHECK(RANLIB_FOR_TARGET, $target-ranlib, $target-ranlib, ranlib)
AC_PROGRAMS_CHECK(GCC_FOR_TARGET, $target-gcc, $target-gcc, gcc)
fi

This could be improved to also look for gcc in PATH, but require the
prefix to contain the target e.g.:

target=m68k-coff -->GCC_FOR_TARGET = /usr/gnu/m68k-coff/bin/gcc

From: nennker@cs.tu-berlin.DE (Axel Nennker)

------------------------------------------------------------------------------

The problem occurs with the following libc functions in SunOS 5.4:

	fnmatch glob globfree regcomp regexec regerror regfree wordexp wordfree

It also occurs with a bunch more libposix4 functions that most people
probably aren't worried about yet, e.g. shm_open.

All these functions fail with errno set to ENOSYS (89)
``Operation not applicable''.

Perhaps Autoconf should have a
specific macro for fnmatch, another for glob+globfree, another for
regcomp+regexec+regerror+regfree, and another for wordexp+wordfree.
This wouldn't solve the problem in general, but it should work for
Solaris 2.4.  Or Autoconf could limit itself to fnmatch and regcomp,
the only two functions that I know have been a problem so far.

From Paul Eggert.

------------------------------------------------------------------------------

Make easy macros for checking for X functions and libraries, such as Motif.

------------------------------------------------------------------------------

* Test suite: more things to test:
** That the shell scripts produce correct output on some simple data.
** Configuration header files.  That autoheader does the right thing,
   and so does AC_CONFIG_HEADER when Autoconf is run.

------------------------------------------------------------------------------

Autoheader in autoconf-2.4 doesn't produce entries for:

        AC_CHECK_TYPE(ssize_t, int)

and it seems like it could easily do so.

In general, it seems to me like Autoconf isn't set up to
let me periodically run autoheader, and then include my
"local" tests -- autoheader gets most stuff right, I'd like
to rerun it periodically without losing my local changes
to config.h.in.

One of the things that I need is to know is the type to use
for a fixed size on disk, e.g., what is the system's name
for an unsigned-32-bit integer?

I can use:

        AC_CHECK_SIZEOF(unsigned int)

and, in fact, that's what I do.  But I still have to build
sets of #if tests to get from there to the name of the type.

From:    bostic@bsdi.com (Keith Bostic)

------------------------------------------------------------------------------

There are basically three ways to lock files
        lockf, fnctl, flock
I'd be interested in adding a macro to pick the "right one" if you're
interested.

From:    Rich Salz <rsalz@osf.org>

------------------------------------------------------------------------------

Timezone calculations checks.

------------------------------------------------------------------------------

Support different default filesystem layouts, e.g. SVR4, Linux.
Of course, this can be done locally with config.site.

------------------------------------------------------------------------------

I wonder if it is possible to get the path for X11's app-defaults
directory by autoconf. Moreover, I'd like to have a general way of
accessing imake variables by autoconf, something like

AC_DEFINE(WINE_APP_DEFAULTS, AC_IMAKE_VAR(XAPPLOADDIR))

Slaven Rezic <eserte@cabulja.herceg.de>

------------------------------------------------------------------------------

So we need a general mechanism for storing variables' values in the cache,
and checking if they are the same after reading the cache.  Then we can add
to the list of variables as we come across the need.  So far we want
LD_LIBRARY_PATH and the internal variables for some of (all?) the args.
From: roland@gnu.ai.mit.edu (Roland McGrath)

Hmm.  That list might include LD_LIBRARY_PATH, LD_RUN_PATH (for solaris),
and PATH.  I can't think of any others so far.
From: friedman@splode.com (Noah Friedman)

------------------------------------------------------------------------------

So how about an option to configure --reset-cache, that says to ignore all
existing cached values for tests that configure runs, and then update the
cache normally.  This should be utterly trivial to do in AC_CACHE_VAL;
check the flag variable and always compute the value if it's set.

------------------------------------------------------------------------------

A number of people have tried to fix configuration problems by editing
acconfig.h. (Despite comments at the top of the file.) I think they're
confused because anything.h looks like a regular source file name.
Maybe acconfig.h could be called acconfig.extra or something?

From: kb@cs.umb.edu (K. Berry)

------------------------------------------------------------------------------

Every user running
X11 usually has a directory like *X11* in his PATH variable. By replacing
bin by include, you can find good places to look for the include files
or libraries.

From: rcb5@win.tue.nl (Richard Verhoeven)

------------------------------------------------------------------------------

In most cases, when autoscan suggests something, using the search
or index command into the Info reader for autoconf manual quickly
explains me what the test is about.  However, for header files
and functions, the search might fail, because the test is not of
the specific kind.  The Autoconf manual should reflect somewhere
all header files or functions (non-specific features, generally)
triggering autoscan to generate tests, and tell in a few words
what is the problem, and the suggested approach for a solution;
that is, how one should use the result of testing the feature.

From: pinard@iro.umontreal.ca

------------------------------------------------------------------------------

It would be nice if the configure script would handle an option such as
--x-libraries="/usr/openwin/lib /usr/dt/lib".

Rick Boykin <rboykin@cscsun3.larc.nasa.gov>

Under Solaris 2.4, the regular X includes and libs and the Motif
includes and libs are in different places.  The Emacs configure script
actually allows dir1:dir2:dir3 --

    if test "${x_libraries}" != NONE && test -n "${x_libraries}"; then
      LD_SWITCH_X_SITE=-L`echo ${x_libraries} | sed -e "s/:/ -L/g"`
      LD_SWITCH_X_SITE_AUX=-R`echo ${x_libraries} | sed -e "s/:/ -R/g"`
    fi
    if test "${x_includes}" != NONE && test -n "${x_includes}"; then
      C_SWITCH_X_SITE=-I`echo ${x_includes} | sed -e "s/:/ -I/g"`
    fi

------------------------------------------------------------------------------

    What messages should be produced by default, if any?

Probably only the few most important ones, like which configuration
name was used, whether X or Xt are in use, etc. The specific
decisions, and progress messages, should be recorded on the terminal
only if --verbose is used.

    --silent just supresses the "checking for...result"
    messages, not the "creating FOO" messages.

I think the default should be to suppress both.
From: Richard Stallman <rms@gnu.ai.mit.edu>

There is no distinction now between
important decisions (we have X) vs minor decisions (we have lstat).
However, there are probably only a few things you deem important enough to
announce and only those few things will need to be changed.
Perhaps config.status could be written with comments saying what was
decided.
From: Roland McGrath <roland@gnu.ai.mit.edu>

------------------------------------------------------------------------------

about the idea of using small configure.in/aclocal.m4 snippets:
this is the one idea in metaconfig (the autoconf-like program used by
Perl) that I like.  metaconfig looks for a "U" directory, and includes
each ".U" file into the generated Configure script (according to
various complicated rules).
From: Tom Tromey <tromey@creche.cygnus.com>

------------------------------------------------------------------------------

I'd much prefer to see the absolute paths substituted for all the
standard "dir" variables.  It would be nice to have variables in
configure that held the absolute paths.  And it is nice to be able to
substitute them into other files without relying on the destination
file supporting ${...}  syntax.  (It works in Perl, sh, and make --
but not guile)

From: Tom Tromey <tromey@creche.cygnus.com>

------------------------------------------------------------------------------

Another thing I wish for is a macro which figures out which libraries are
needed for BSD-sytle sockets.  AC_PATH_X already detects this
correctly...so it's just a matter of seperating out the socket-related code.
From: "Joel N. Weber II" <nemo@koa.iolani.honolulu.hi.us>

------------------------------------------------------------------------------

in order to use the AC_CANONICAL_SYSTEM macro, I have to
have install-sh somewhere nearby --- why is this?  I have no real
reason to distribute install-sh, other than that its absence breaks
this code.

Shouldn't the above loop be looking for config.sub and config.guess?
From: jimb@totoro.bio.indiana.edu (Jim Blandy)

adding AC_CANONICAL_HOST to my configure.in script caused
all sorts of odd/unexplained errors.  Obviously, I had to go
get copies of config.guess, config.sub and install-sh from the
autoconf distribution, but the error messages and autoconf docs
didn't explain that very well.
From: bostic@bsdi.com (Keith Bostic)

------------------------------------------------------------------------------

Perhaps also have AC_TRY_COMPILER try to link an invalid program, and
die if the compiler seemed to succeed--in which case it's not usable
with autoconf scripts.

------------------------------------------------------------------------------

autoreconf doesn't support having (in the same tree) both directories
that are parts of a larger package (sharing aclocal.m4 and acconfig.h),
and directories that are independent packages (each with their own ac*).
It assumes that they are all part of the same package, if you use --localdir,
or that each directory is a separate package, if you don't use it.

autoreconf should automatically figure out which ac* files to use--the
closest ones up the tree from each directory, probably, unless
overridden by --localdir.

Also, autoreconf recurses on all subdirectories containing a
configure.in, not just those given by an AC_CONFIG_SUBDIRS directive.
This may not be a problem in practice.

------------------------------------------------------------------------------