todo

autoconf是一个产生可以自动配置源代码包

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

** AC_PROG_INSTALL
This test should be extended to check that install supports the GNU
Install syntax: install FILES... DIR.  This will relieve everybody
form having to use mkinstalldirs to create the directories, as install
does it itself.  install-sh is already handling this case.  This also
makes it simple not to create the directories where nothing will be
installed because of configuration options, which is next to
impossible using the current setting.

In other words: everything is ready (install-sh and Automake), we just
need a good reimplementation of AC_PROG_INSTALL.

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

** AC_GNU_SOURCE, AC_AIX, and AC_MINIX
Deprecate these, as they will be superseded by the AC_PROG_CC changes.


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

** Document AC_COMPILE_IFELSE, AC_LANG_PROGRAM etc.
And make AC_TRY_COMPILE etc. obsolete.

** 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 <[e-mail]>
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], $@)!

** Tracing builtins
GNU M4 1.4's tracing of builtins is buggy.  When run on this input:

| divert(-1)
| changequote([, ])
| define([m4_eval], defn([eval]))
| eval(1)
| m4_eval(2)
| undefine([eval])
| m4_eval(3)

it behaves this way:

| % m4 input.m4 -da -t eval
| m4trace: -1- eval(1)
| m4trace: -1- m4_eval(2)
| m4trace: -1- m4_eval(3)
| %

Conversely:

| % m4 input.m4 -da -t m4_eval
| %

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

* 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