mirror of
git://git.sv.gnu.org/autoconf
synced 2024-12-09 02:10:22 +08:00
8b3a0fbaae
AC_CONFIG_COMMANDS, AC_CONFIG_FILES): Use a shell variable instead of an m4 variable to store what must be done, so that sh conditionals are honored. (_AC_OUTPUT_LINKS, _AC_OUTPUT_HEADERS, _AC_OUTPUT_COMMANDS, _AC_OUTPUT_FILES): Adjust. * tests/semantics.m4: Test the four AC_CONFIG sisters. * doc/autoconf.texi (Configuration Actions): Promote the use of literals, show it works properly with sh conditionals.
621 lines
23 KiB
Plaintext
621 lines
23 KiB
Plaintext
-*- 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.
|
|
|
|
|
|
------------------------------------------------------------------------------
|
|
|
|
* 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.
|
|
|
|
** Doc:
|
|
Should we document AC_LANG_* and AC_*_IFELSE? I hope the interface is
|
|
right...
|
|
|
|
** 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?
|
|
|
|
** 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?
|
|
|
|
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 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?
|
|
|
|
|
|
------------------------------------------------------------------------------
|
|
|
|
* Automake
|
|
|
|
** missing.m4
|
|
The test for a recent missing doesn't hide the error messages from the
|
|
old missing.
|
|
|
|
** AU_DEFUN
|
|
The section for old macros is not completely up to date. For
|
|
instance, there is still AM_PROG_LIBTOOL. Anyway, since autoupdate
|
|
takes care of them, it is no longer the role of Automake to handle
|
|
this. Most should be removed.
|
|
|
|
** AC_EXEXT, AC_OBJEXT
|
|
Support should be enabled by default.
|
|
|
|
|
|
------------------------------------------------------------------------------
|
|
|
|
* m4
|
|
|
|
** m4
|
|
The error messages for indir and dumpdef are uselessly different. Fix
|
|
this for translators.
|
|
|
|
** m4
|
|
F**k! --trace FOO does not catch indir([FOO], $@)!
|
|
|
|
|
|
------------------------------------------------------------------------------
|
|
|
|
* Autoconf 3
|
|
|
|
** Split all those &#@! files.
|
|
acgeneral and acspecific is a bad design. The split should be done
|
|
according to the families. For instance AC_CHECK_FUNCS,
|
|
AC_CHECK_FUNC, AC_FUNC_FNMATCH etc. *and* AH_CHECK_FUNCS, AU_* should
|
|
be in, acfunc.m4. I suppose there should be small exceptions, e.g.,
|
|
the family AC_REPLACE_FUNCS should still be in acfunc.m4.
|
|
|
|
** 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
|
|
|
|
------------------------------------------------------------------------------
|
|
|
|
* 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: Centralize information on POSIX, MS-DOS, cross-compiling, and
|
|
other important topics.
|
|
|
|
------------------------------------------------------------------------------
|
|
|
|
* 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:
|
|
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.
|
|
|
|
------------------------------------------------------------------------------
|
|
|
|
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 name space 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 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.
|
|
|
|
------------------------------------------------------------------------------
|
|
|
|
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>
|
|
|
|
------------------------------------------------------------------------------
|
|
|
|
Cache consistency checking: ignore cache if environment
|
|
(CC or PATH) differs.
|
|
From Mike Haertel
|
|
|
|
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.
|
|
|
|
------------------------------------------------------------------------------
|
|
|
|
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>
|
|
|
|
------------------------------------------------------------------------------
|
|
|
|
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.
|
|
|
|
------------------------------------------------------------------------------
|