mirror of
https://review.haiku-os.org/buildtools
synced 2024-11-23 07:18:49 +01:00
c62c4a49d7
git-svn-id: file:///srv/svn/repos/haiku/buildtools/trunk@15332 a95241bf-73f2-0310-859d-f6bbb57e9c96
581 lines
22 KiB
Plaintext
581 lines
22 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
|
|
|
|
------------------------------------------------------------------------------
|
|
|
|
* 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.
|
|
|
|
------------------------------------------------------------------------------
|
|
|
|
* Add AC_PROG_CC_POSIX to replace the current ad-hoc macros for AIX,
|
|
Minix, ISC, etc.
|
|
|
|
------------------------------------------------------------------------------
|
|
|
|
* Use AC_EGREP_CPP instead of AC_TRY_LINK to detect structures and members.
|
|
|
|
------------------------------------------------------------------------------
|
|
|
|
* Make AC_CHECK_FUNC[S] automatically use any particular macros for the
|
|
listed functions.
|
|
|
|
------------------------------------------------------------------------------
|
|
|
|
* 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 accomodate 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.
|
|
|
|
------------------------------------------------------------------------------
|
|
|
|
Have AC_CANONICAL_* cache the host/build/target types.
|
|
They have to be overridden by the command line arguments,
|
|
just as for X includes and libraries. Should they be cached
|
|
all in one variable, or three? In that case, what if only one
|
|
or two of the cache variables are set?
|
|
|
|
------------------------------------------------------------------------------
|
|
|
|
The argument HELP-STRING is a description of the option which
|
|
...
|
|
Avoid tabs in the help string. You'll need to enclose it in `['
|
|
and `]' in order to produce the leading spaces.
|
|
|
|
Except that [...] is the convention for telling the user the default,
|
|
So I guess a changequote(`,') or something would be in order in some cases.
|
|
From: "K. Berry" <kb@cs.umb.edu>
|
|
|
|
------------------------------------------------------------------------------
|
|
|
|
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 toplevel 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>
|
|
|
|
------------------------------------------------------------------------------
|
|
|
|
It is IMHO a bug that `config.status' cannot handle multiple
|
|
simultaneous invocations. It should include the process id (`$$' in sh)
|
|
as part of the name of any temporary files it creates.
|
|
|
|
From: fjh@kryten.cs.mu.oz.au (Fergus Henderson)
|
|
|
|
------------------------------------------------------------------------------
|
|
|
|
Timezone calculations checks.
|
|
|
|
------------------------------------------------------------------------------
|
|
|
|
Support different default filesystem layouts, e.g. SVR4, Linux.
|
|
Of course, this can be done locally with config.site.
|
|
|
|
------------------------------------------------------------------------------
|
|
|
|
Mention automake, libtool, etc. in the autoconf manual.
|
|
|
|
------------------------------------------------------------------------------
|
|
|
|
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>
|
|
|
|
------------------------------------------------------------------------------
|
|
|
|
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)
|
|
|
|
------------------------------------------------------------------------------
|
|
|
|
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.
|
|
|
|
------------------------------------------------------------------------------
|
|
|
|
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)
|
|
|
|
------------------------------------------------------------------------------
|
|
|
|
When using CONFIG_FILES= and CONFIG_HEADERS= for controlling
|
|
partial configuration, any AC_LINK_FILES is repeated in each case
|
|
(that is, usually, once for config.h and once per subdirectory).
|
|
This is not elegant.
|
|
|
|
Maybe Autoconf could use some kind of CONFIG_LINKS=<file-list>,
|
|
having all such AC_LINK(ed)_FILES by default, but usable by each
|
|
Makefile.in in rules for updating the particular links they need.
|
|
|
|
From: pinard@iro.umontreal.ca
|
|
|
|
------------------------------------------------------------------------------
|
|
|
|
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>
|
|
|
|
------------------------------------------------------------------------------
|
|
|
|
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>
|
|
|
|
------------------------------------------------------------------------------
|
|
|
|
Use automake to generate autoconf's Makefile.in's?
|
|
|
|
------------------------------------------------------------------------------
|
|
|
|
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>
|
|
|
|
------------------------------------------------------------------------------
|
|
|
|
Merge the two lex macros, AC_PROG_LEX and AC_DECL_YYTEXT?
|
|
|
|
------------------------------------------------------------------------------
|
|
|
|
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.
|
|
|
|
------------------------------------------------------------------------------
|
|
|
|
there is absolutely no guarantee that 'a' to 'z' are
|
|
contiguous, and the ISLOWER macro is not guaranteed to correctly
|
|
reproduce the result of islower. In all variants of ASCII however, it
|
|
will work correctly in the C locale.
|
|
|
|
There is also no guarantee that toupper(i) - i is the same constant if
|
|
non-zero. TOUPPER, hence, is not correct either. But, in all variants
|
|
of ASCII in the C locale, it works.
|
|
|
|
Tanmoy Bhattacharya (tanmoy@qcd.lanl.gov>
|
|
|
|
------------------------------------------------------------------------------
|
|
|
|
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.
|
|
|
|
------------------------------------------------------------------------------
|
|
|