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

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

* Soon

** AC_CHECK_HEADERS

and the like, don't have a consistent way to handle multi-line

arguments.  Fix, test, and document.

** --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_CHECK_TOOL...

Write a test that checks that it honors the values set by the user.

** autom4te and warnings.

Decide what must be done.

** AC_DEFINE(func, rpl_func)

This scheme causes problems: if for instance, #define malloc

rpl_malloc, then the rest of configure will use an undefined malloc.

Hence some tests fail.  Up to now we simply #undef these functions

where we had a problem (cf. AC_FUNC_MKTIME and AC_FUNC_MMAP for

instance).  This is _bad_.  Maybe the #define func rpl_malloc should

be performed in another file than confdefs.h, say confh.h, which is

used for config.h generation, but not used in configure's own tests.

** AC_PROG_CC

Currently it tries to put the C compiler in ANSI C mode by default.

We should change this spec so that AC_PROG_CC tries to change the

compiler to be the "nicest" mode, i.e. support for the latest standard

features (currently ISO C99) plus support for all vendor extensions,

even if they are slightly incompatible with C99.  The basic idea here

is that AC_PROG_CC should disable pedanticisms and should enable

extensions.

Have a way to specify different default flags to try; see this thread

for more information:

<http://lists.gnu.org/archive/html/bug-autoconf/2008-08/msg00009.html>.

* Later

** config.site

This guy is really a problem.  It's contents should be read before

handling the options, so that the latter properly override the latter,

but most people would want a means to have a config.site that depends

on $prefix for instance.

Some other would like config.site to be looked for in the current

directory.

Harlan:

   I'll go further.

   I'd like to see several layers of config.site available.

   I'm starting to use "modules" at more places to handle software

   installation, and it would be helpful to set general things like:

	prefix=/opt/pkg/@PACKAGE@/@VERSION@

   once at a global level, and then, for example, have things like:

	--with-etcdir=$prefix/etc

   stuffed "above" the various versions of SSH so I wouldn't have to hunt for

   these things every time it was time to recompile a new version of a

   previously installed package.

   Something like:

     src/config.site		Global stuff

     ...

     src/ssh/config.site		package-specific stuff

     src/ssh/ssh-1.2.27/		the actual source code

   I'd like to see automake/autoconf better support packaging tools (like

   modules, the *BSD ports/ stuff, and others would like hooks for RPMs).

** Languages

Integrate other Fortrans etc.

** AC_CHECK_FUNCS and AC_TRY_LINK_FUNC

I have still not understood what's the difference  between the two

which requires to have two different sources: AC_LANG_CALL and

AC_LANG_FUNC_LINK_TRY (which names seem to be inappropriate).

Wouldn't one be enough?

** Libtool

Define once for all the hooks they need, any redefinition of

AC_PROG_CC etc. is way too dangerous and too limiting.  The GCC team

certainly has requirements too.

** AC_SEARCH_LIBS

From: Tom Tromey <tromey@cygnus.com>

Subject: AC_SEARCH_LIBS

I think AC_SEARCH_LIBS has an unfortunate interface.

ACTION-IF-FOUND is run in addition to the default action.  Most

autoconf macros don't work this way.  This is confusing.

In my case I can't use this macro because it always appends to LIBS.

I don't want that.  Instead I want to use ACTION-IF-FOUND to set my

own macro.

Also there is no documentation on the format of library names expected

by the macro.  Even a reference to some other function (e.g., "the

library name can have the same forms as with AC_HAVE_LIBRARY" (if that

is true, which I haven't looked up) would be fine.

** Revamp the language support

We should probably have a language for C89, and C99.  We must give the

means to the users to specify some needs over the compilers, and

actually look for a good compiler, instead of stopping at the first

compiler we find.

In fact, the AC_CHECK_PROG macro and variations have proved their

limitation: we really need something more powerful and simpler too.

We must take into account the specific problems of the GCC team.  We

must extend AC_CHECK_FUNCS in order to use the headers instead of fake

declarations as we currently do.  Default headers could be triggered

on when C99, but not with the other languages?

At the end, we should have a simple macro, such as AC_LANG_COMPILER

for instance, which is built over simpler macros.  Each language

support should come with these simpler macros, but each language

should follow the same process.

We also need to check the srcext which are supported by the compiler.

In fact, this macro is also probably the right place to check for

objext and exeext.

** 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.)?  See Peter for very

useful comments on the technology.  Should we make this a new

language?  AC_LANG(ISO C).  It would be great to introduce

AC_LANG_COMPILER in this release too.

** 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.ac.

* Even later

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

** AC_PATH_X

Hi Robert,

> Hi, autoconf people.  While packaging plotutils-2.2 (just released),

> I noticed what looks like a small error in the autoconf-2.13 texinfo

> documentation, the entry for AC_PATH_XTRA, in particular.

> The documentation says that AC_PATH_XTRA

>	... adds the C compiler flags that X needs to output variable

>	`X_CFLAGS', and the X linker flags to `X_LIBS'.  If X is not

>	available, adds `-DX_DISPLAY_MISSING' to `X_CFLAGS'.

> It doesn't seem to add -DX_DISPLAY_MISSING to X_CFLAGS.  X_DISPLAY_MISSING

> ends up defined in config.h, instead.

That's only because you're no doubt using AC_CONFIG_HEADER(..) to send

your defines to a config.h-style file.  If you were to not use

AC_CONFIG_HEADER and X was not available, then you would see

-DX_DISPLAY_MISSING being added to @DEFS@ as your output files were being

generated.

But you are right--the documentation is not clear about this.  I'll change

it.

> In fact it looks to me as if right now, X_CFLAGS is used only for

> specifying directories where X include files are stored, via the `-I' option.

> Maybe it should really be called X_CPPFLAGS?

Well, perhaps.  If you feel strongly about this, feel free to submit a

change-request.  There is a hyperlink to the bug tracking database from

http://sourceware.cygnus.com/autoconf/.  With the way it reads in the

manual right now, it's designed to allow the user to set additional flags

in the environment prior to running configure--and these don't need to be

limited to just -I flags.  Nevertheless, I can see a few clean ways to

improve this.

** AC_SYS_INTERPRETER

Defines $interpval.  This is not a standard name.  Do we want to keep

this?  Clarify our policy on those names.

** Allow --recursive to config.status

So that --recheck does not pass --no-recursive to configure.

* autoconf.texi

Move the specific macro documentation blocks into the source files,

and use a doc-block extraction/merge technique to get documentation

into texi-file.  This should help avoid bit-rot in the doc, and make

the doc easier to update when people add/change macros.  The name

"autodoc" is probably already taken so we probably need another one.

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

* m4

** I18n

The error messages for indir and dumpdef are uselessly different.  Fix

this for translators.

** Tracing `builtin'

F**k!  --trace FOO does not catch indir([FOO], $@)!

Fixed in M4 1.6, but we can't rely on it yet.

** m4 loops

As of 2.63, m4_for has a fixed iteration count for speed in the common

usage case.  But it used to allow the user to alter iteration count by

reassigning the iterator, allowing a break-like functionality (or even

infloops).  Does this need a new (but maybe slower) macro?  Should we

also provide something like m4_while([TEST], [EXPR])?  Maybe an

m4_break() that works inside a looping construct?

http://lists.gnu.org/archive/html/autoconf-patches/2008-08/msg00121.html

* Autoconf 3

** Cache name spaces.

Cf the discussion with Kaveh.  One would like to

AC_CHECK_FUNCS(bar)

# Do something that changes the environment

AC_CACHE_PUSH(foo)

AC_CHECK_FUNCS(bar)

AC_CACHE_POP

in order not to erase the results of a check with another.

** Cache var names

should depend upon the current language.

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

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

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

* 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

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

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

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

* Doc: Centralize information on POSIX, MS-DOS, cross-compiling, and

  other important topics.

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

* Mike Haertel's suggestions:

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

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

* Look at user contributed macros:

	IEEE double precision math

	more

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

* Provide a way to create a config.h *and* set the DEFS variable from within

the same configure script.

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

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

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

It would be nice if I could (in the Makefile.in files) set the

relative name of 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>

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

	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 appropriate checks, the existence of the files, 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 names 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_CHECK_PROGS(AR_FOR_TARGET,

	       [$target-ar, $prefix/$target/bin/ar], $target-ar)

AC_CHECK_PROGS(RANLIB_FOR_TARGET, $target-ranlib, $target-ranlib)

	       [$target-ranlib, $prefix/$target/bin/ranlib], $target-ranlib)

AC_CHECK_PROGS(GCC_FOR_TARGET, $target-gcc, $target-gcc)

	       [$target-gcc, $prefix/$target/bin/gcc], $target-gcc)

fi

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

(also look in the autoconf mailing list archives for the proposed

CHECK_TARGET_TOOL macro from Natanael Nerode, a gcc configury guru).

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

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.

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

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 file system layouts, e.g. SVR4, Linux.

Of course, this can be done locally with config.site.

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

I wonder if it is possible to get the name of 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>

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

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 suppresses 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>

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

Another thing I wish for is a macro which figures out which libraries are

needed for BSD-style sockets.  AC_PATH_X already detects this

correctly...so it's just a matter of separating 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.

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

Copyright (C) 1994-1996, 1999-2002, 2007-2012 Free Software Foundation,

Inc.

Copying and distribution of this file, with or without modification,

are permitted in any medium without royalty provided the copyright

notice and this notice are preserved.  This file is offered as-is,

without warranty of any kind.