616 lines
23 KiB
Plaintext
616 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.
|
|
|
|
|
|
------------------------------------------------------------------------------
|
|
|
|
* Soon
|
|
|
|
** --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?
|
|
|
|
** RedHat's Autoconf page
|
|
should be removed.
|
|
|
|
** AC_CHECK_TOOL...
|
|
Write a test that checks that it honors the values set by the user.
|
|
|
|
* Autoconf 2.52 or later
|
|
|
|
** 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?
|
|
|
|
** autom4te
|
|
Eve it out of autoconf. Install support for Autotest, M4sugar, and
|
|
M4sh. Give a means to trace at the same time as we produce the
|
|
output. autoconf shall use this feature to make autoheader obsolete,
|
|
and to produce some kind of input file for automake which should no
|
|
longer *ever* try to parse Autoconf files.
|
|
|
|
** Autotest
|
|
Document it.
|
|
|
|
** Document AC_COMPILE_IFELSE, AC_LANG_PROGRAM etc.
|
|
And make AC_TRY_COMPILE etc. obsolete.
|
|
|
|
** Autoscan macros
|
|
Can be introduced even before specializing macros. It just means that
|
|
specializing macros will call them. OTOH, this doubles our work,
|
|
since specializing macros will save us from additional typing. But
|
|
the more powerful autoscan is, the better...
|
|
|
|
** 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.
|
|
|
|
** 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_FUNC_GETLOADAVG
|
|
We must find a solution for this macro which needs to find
|
|
`getloadavg.c'.
|
|
|
|
** 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.)?
|
|
|
|
** AC_SYS_INTERPRETER
|
|
Defines $interpval. This is not a standard name. Do we want to keep
|
|
this? Clarify our policy on those names.
|
|
|
|
** 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.
|
|
|
|
** Allow --recursive to config.status
|
|
So that --recheck does not pass --no-recursive to configure.
|
|
|
|
** AC_PROG_CC_STDC
|
|
Well, back onto this one :( 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.
|
|
|
|
* autoconf.texi
|
|
Move the specific macro documentation blocks into the source files,
|
|
and use a doc-block extraction/merge technique to get docuemntation
|
|
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.
|
|
|
|
------------------------------------------------------------------------------
|
|
|
|
* 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.
|
|
|
|
** Macros now swallowed by Autoconf.
|
|
error.m4, obstack.m4, ptrdiff.m4, strtod.m4, termios.m4, winsz.m4.
|
|
|
|
------------------------------------------------------------------------------
|
|
|
|
* 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
|
|
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.
|
|
|
|
------------------------------------------------------------------------------
|
|
|
|
* 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
|
|
|
|
------------------------------------------------------------------------------
|
|
|
|
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)
|
|
|
|
------------------------------------------------------------------------------
|
|
|
|
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.
|
|
|
|
------------------------------------------------------------------------------
|