disabled "lzD pOF h1   File not found. : l4( u( J9qţ -azD q)F? -*- 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: . * 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 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