AC_USE_SYSTEM_EXTENSIONS: Remove stray TR in doc
[autoconf.git] / TODO
blobe1c3a8d10411341052dd14a5bf65edc14a9e7add
1 -*- outline -*-
3 Things it might be nice to do someday.  I haven't evaluated all of
4 these suggestions... their presence here doesn't imply my endorsement.
5 -djm & his successors.
8 ------------------------------------------------------------------------------
10 * Soon
12 ** AC_CHECK_HEADERS
13 and the like, don't have a consistent way to handle multi-line
14 arguments.  Fix, test, and document.
16 ** --target & AC_ARG_PROGRAM
17 Shouldn't *any* `program' be installed as `$target_alias-program' even
18 if AC_ARG_PROGRAM is not called?  That would be much more predictable.
19 Ian?
21 ** AC_CHECK_TOOL...
22 Write a test that checks that it honors the values set by the user.
24 ** autom4te and warnings.
25 Decide what must be done.
27 ** AC_DEFINE(func, rpl_func)
28 This scheme causes problems: if for instance, #define malloc
29 rpl_malloc, then the rest of configure will use an undefined malloc.
30 Hence some tests fail.  Up to now we simply #undef these functions
31 where we had a problem (cf. AC_FUNC_MKTIME and AC_FUNC_MMAP for
32 instance).  This is _bad_.  Maybe the #define func rpl_malloc should
33 be performed in another file than confdefs.h, say confh.h, which is
34 used for config.h generation, but not used in configure's own tests.
36 ** AC_PROG_CC
37 Have a way to specify different default flags to try; see this thread
38 for more information:
39 <http://lists.gnu.org/archive/html/bug-autoconf/2008-08/msg00009.html>.
42 * Later
44 ** config.site
45 This guy is really a problem.  It's contents should be read before
46 handling the options, so that the latter properly override the latter,
47 but most people would want a means to have a config.site that depends
48 on $prefix for instance.
50 Some other would like config.site to be looked for in the current
51 directory.
53 Harlan:
55    I'll go further.
57    I'd like to see several layers of config.site available.
59    I'm starting to use "modules" at more places to handle software
60    installation, and it would be helpful to set general things like:
62         prefix=/opt/pkg/@PACKAGE@/@VERSION@
64    once at a global level, and then, for example, have things like:
66         --with-etcdir=$prefix/etc
68    stuffed "above" the various versions of SSH so I wouldn't have to hunt for
69    these things every time it was time to recompile a new version of a
70    previously installed package.
72    Something like:
74      src/config.site            Global stuff
75      ...
76      src/ssh/config.site                package-specific stuff
77      src/ssh/ssh-1.2.27/                the actual source code
79    I'd like to see automake/autoconf better support packaging tools (like
80    modules, the *BSD ports/ stuff, and others would like hooks for RPMs).
83 ** Languages
84 Integrate other Fortrans etc.
86 ** AC_CHECK_FUNCS and AC_TRY_LINK_FUNC
87 I have still not understood what's the difference  between the two
88 which requires to have two different sources: AC_LANG_CALL and
89 AC_LANG_FUNC_LINK_TRY (which names seem to be inappropriate).
90 Wouldn't one be enough?
92 ** Libtool
93 Define once for all the hooks they need, any redefinition of
94 AC_PROG_CC etc. is way too dangerous and too limiting.  The GCC team
95 certainly has requirements too.
97 ** AC_SEARCH_LIBS
98 From: Tom Tromey <tromey@cygnus.com>
99 Subject: AC_SEARCH_LIBS
101 I think AC_SEARCH_LIBS has an unfortunate interface.
103 ACTION-IF-FOUND is run in addition to the default action.  Most
104 autoconf macros don't work this way.  This is confusing.
106 In my case I can't use this macro because it always appends to LIBS.
107 I don't want that.  Instead I want to use ACTION-IF-FOUND to set my
108 own macro.
110 Also there is no documentation on the format of library names expected
111 by the macro.  Even a reference to some other function (e.g., "the
112 library name can have the same forms as with AC_HAVE_LIBRARY" (if that
113 is true, which I haven't looked up) would be fine.
115 ** Revamp the language support
116 We should probably have a language for C89, and C99.  We must give the
117 means to the users to specify some needs over the compilers, and
118 actually look for a good compiler, instead of stopping at the first
119 compiler we find.
121 In fact, the AC_CHECK_PROG macro and variations have proved their
122 limitation: we really need something more powerful and simpler too.
124 We must take into account the specific problems of the GCC team.  We
125 must extend AC_CHECK_FUNCS in order to use the headers instead of fake
126 declarations as we currently do.  Default headers could be triggered
127 on when C99, but not with the other languages?
129 At the end, we should have a simple macro, such as AC_LANG_COMPILER
130 for instance, which is built over simpler macros.  Each language
131 support should come with these simpler macros, but each language
132 should follow the same process.
134 We also need to check the srcext which are supported by the compiler.
135 In fact, this macro is also probably the right place to check for
136 objext and exeext.
138 ** AC_PROG_CC
139 How should the desired ISO version be specified?  AC_PROG_CC_C89
140 do not play well with each other, or with AC_PROG_CC.
141 Should be: AC_PROG_CC_ISO?  Or even more specific for the ISO version?
142 Should include more tests (e.g., AC_C_CONST etc.)?  See Peter for very
143 useful comments on the technology.  Should we make this a new
144 language?  AC_LANG(ISO C).  It would be great to introduce
145 AC_LANG_COMPILER in this release too.
147 ** autoupdate
148 We should probably install the files which do not depend upon the
149 user, just the Autoconf library files.  But conversely autoupdate must
150 be opened to user macros, i.e., for instance libtool itself must be
151 able to say that AM_PROG_LIBTOOL is now AC_PROG_LIBTOOL, and have
152 autoupdate do its job on old configure.ac.
154 * Even later
156 ** Pentateuch
157 Heck, there is nothing after `Deuteronomy'!  We're stuck, but we
158 _must_ update the `history' section.  Can't go to `New testament', we
159 might hurt feelings?  In addition, it means that the Messiah has come,
160 which might be slightly presumptuous :).  Still, someone fluent in
161 English should write it.
163 ** AC_PATH_X
164 Hi Robert,
166 > Hi, autoconf people.  While packaging plotutils-2.2 (just released),
167 > I noticed what looks like a small error in the autoconf-2.13 texinfo
168 > documentation, the entry for AC_PATH_XTRA, in particular.
170 > The documentation says that AC_PATH_XTRA
171 >       ... adds the C compiler flags that X needs to output variable
172 >       `X_CFLAGS', and the X linker flags to `X_LIBS'.  If X is not
173 >       available, adds `-DX_DISPLAY_MISSING' to `X_CFLAGS'.
175 > It doesn't seem to add -DX_DISPLAY_MISSING to X_CFLAGS.  X_DISPLAY_MISSING
176 > ends up defined in config.h, instead.
178 That's only because you're no doubt using AC_CONFIG_HEADER(..) to send
179 your defines to a config.h-style file.  If you were to not use
180 AC_CONFIG_HEADER and X was not available, then you would see
181 -DX_DISPLAY_MISSING being added to @DEFS@ as your output files were being
182 generated.
184 But you are right--the documentation is not clear about this.  I'll change
187 > In fact it looks to me as if right now, X_CFLAGS is used only for
188 > specifying directories where X include files are stored, via the `-I' option.
189 > Maybe it should really be called X_CPPFLAGS?
191 Well, perhaps.  If you feel strongly about this, feel free to submit a
192 change-request.  There is a hyperlink to the bug tracking database from
193 http://sourceware.cygnus.com/autoconf/.  With the way it reads in the
194 manual right now, it's designed to allow the user to set additional flags
195 in the environment prior to running configure--and these don't need to be
196 limited to just -I flags.  Nevertheless, I can see a few clean ways to
197 improve this.
199 ** AC_SYS_INTERPRETER
200 Defines $interpval.  This is not a standard name.  Do we want to keep
201 this?  Clarify our policy on those names.
203 ** Allow --recursive to config.status
204 So that --recheck does not pass --no-recursive to configure.
206 * autoconf.texi
207 Move the specific macro documentation blocks into the source files,
208 and use a doc-block extraction/merge technique to get documentation
209 into texi-file.  This should help avoid bit-rot in the doc, and make
210 the doc easier to update when people add/change macros.  The name
211 "autodoc" is probably already taken so we probably need another one.
213 ------------------------------------------------------------------------------
215 * m4
217 ** I18n
218 The error messages for indir and dumpdef are uselessly different.  Fix
219 this for translators.
221 ** Tracing `builtin'
222 F**k!  --trace FOO does not catch indir([FOO], $@)!
223 Fixed in M4 1.6, but we can't rely on it yet.
225 ** m4 loops
226 As of 2.63, m4_for has a fixed iteration count for speed in the common
227 usage case.  But it used to allow the user to alter iteration count by
228 reassigning the iterator, allowing a break-like functionality (or even
229 infloops).  Does this need a new (but maybe slower) macro?  Should we
230 also provide something like m4_while([TEST], [EXPR])?  Maybe an
231 m4_break() that works inside a looping construct?
232 http://lists.gnu.org/archive/html/autoconf-patches/2008-08/msg00121.html
234 * Autoconf 3
236 ** Cache name spaces.
237 Cf the discussion with Kaveh.  One would like to
238 AC_CHECK_FUNCS(bar)
239 # Do something that changes the environment
240 AC_CACHE_PUSH(foo)
241 AC_CHECK_FUNCS(bar)
242 AC_CACHE_POP
243 in order not to erase the results of a check with another.
245 ** Cache var names
246 should depend upon the current language.
248 ** Use m4 lists?
249 I think one sad decision in Autoconf was to use white space separated
250 lists for some arguments.  For instance AC_CHECK_FUNCS(foo bar).  I
251 tend to think that, even if it is not as nice, we should use m4 lists,
252 i.e., AC_CHECK_FUNCS([foo, bar]) in this case.  This would ease
253 specializing loops, and more importantly, make them much more robust.
255 A typical example of things that can be performed if we use m4 lists
256 instead of white space separated lists is the case of things that have
257 a space in their names, eg, structures.
259 With the current scheme it would be extremely difficult to loop over
260 AC_CHECK_STRUCTS(struct foo struct bar), while it natural and well
261 defined for m4 lists: AC_CHECK_STRUCTS([struct foo, struct bar]).
263 I know that makes a huge difference in syntax, but a major release
264 should be ready to settle a new world.  We *can* provide helping tools
265 for the transition.  Considering the benefits, I really think it is
266 worth thinking. --akim
268 ** Forbid shell variables as main arguments
269 The fact that we have to support shell variables as main argument
270 forbids many interesting constructions (specialization are not always
271 possible, equally for AC_REQUIRE'ing macros *with their arguments*).
272 Any loop should be handled by m4 itself, and nothing should be hidden
273 to it.  As a consequence, shell variables on the main arguments become
274 useless (the main reason we support shell variables is to allow the
275 loop versions of single argument macros, eg, to go from AC_CHECK_FUNC
276 to AC_CHECK_FUNCS). --akim
278 ** Use the @SUBST@ technology also for headers instead of #undef.
279 This requires that acconfig.h becomes completely obsolete: autoheader
280 should generate all the templates.
282 ** Specializing loops.
283 For instance, make AC_CHECK_FUNC[S] automatically use any particular
284 macros for the listed functions.
285 This requires to obsolete the feature `break' in ACTION-IF, since all
286 the loops are to be handled by m4, not sh.
288 ** Faces of a test
289 Each macro can potentially come with several faces: of course the
290 configure snippet (AC_foo), a config.h snippet (AH_foo), a system.h
291 snippet (AS_foo), documentation (AD_foo) and, why not, the some C code
292 for instance to replace a function.
294 The motivation for the `faces' is to encapsulate.  It is abnormal that
295 once one has a configure macro, then she has to read somewhere to find
296 the piece of system.h to use etc.  The macros should come in a
297 self-contained way, or, said it another way, PnP.
299 A major issue is that of specialization.  AC_CHECK_HEADER (or another
300 name) for instance, will have as an effect, via system.h to include
301 the header.  But if the test for the header is specific, the generic
302 AS_CHECK_HEADER will still be used.  Conversely, some headers may not
303 require a specific AC_ tests, but a specialized AS_ macro.
305 ------------------------------------------------------------------------------
307 * Make AC_CHECK_LIB check whether the function is already available
308   before checking for the library.  This might involve adding another
309   kind of cache variable to indicate whether a given function needs a
310   given library.  The current ac_cv_func_ variables are intended to
311   indicate whether the function is in the default libraries, but
312   actually also take into account whatever value LIBS had when they
313   were checked for.
315   Isn't this the issue of AC_SEARCH_LIB? --akim
316   How come the list of libraries to browse not an additional parameter
317   of AC_CHECK_FUNC, exactly like for the headers? --akim
319 ------------------------------------------------------------------------------
321 * Select the right CONFIG_SHELL automatically (for Ultrix, Lynx especially.)
323 ------------------------------------------------------------------------------
325 * Doc: Centralize information on POSIX, MS-DOS, cross-compiling, and
326   other important topics.
328 ------------------------------------------------------------------------------
330 * Mike Haertel's suggestions:
332 ** Cross compiling:
334 *** Error messages include instructions for overriding defaults using
335 config.site.
337 *** Distribute a config.site corresponding to a hypothetical bare POSIX system with c89.
339 ** Site defaults:
341 *** 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.
343 ------------------------------------------------------------------------------
345 * Look at user contributed macros:
346         IEEE double precision math
347         more
349 ------------------------------------------------------------------------------
351 * Provide a way to create a config.h *and* set the DEFS variable from within
352 the same configure script.
354 ------------------------------------------------------------------------------
356 In config.status comment, put the host/target/build types, if used.
358 ------------------------------------------------------------------------------
360 It would be nice if I could (in the Makefile.in files) set the
361 relative name of config.h. You have config.h ../config.h
362 ../../config.h's all over the place, in the findutils-4.1 directory.
363 From: "Randall S. Winchester" <rsw@eng.umd.edu>
365 ------------------------------------------------------------------------------
367         ls -lt configure configure.in | sort
368 doesn't work right if configure.in is from a symlink farm, where the
369 symlink has either a timestamp of its own, or under BSD 4.4, it has
370 the timestamp of the current directory, neither of which
371 helps. Changing it to
372         ls -Llt configure configure.in | sort
373 works for me, though I don't know how portable that is
374 _Mark_ <eichin@cygnus.com>
376 ------------------------------------------------------------------------------
378 Here is the thing I would like the most;
379 AC_PKG_WITH(PACKAGE, HELP_STRING, PACKAGE-ROOT, PACKAGE-LIBS, PACKAGE-DEFS,
380         PACKAGE-CCPFLAGS)
381 like
383 AC_PKG_WITH(kerberos,,/usr/local/athena,-lkrb -ldes,[KERBEROS KRB4
384 CRYPT],include)
385 AC_PKG_WITH(hesiod,
386 [if hesiod is not in kerberos-root add --with-hesiod-root=somewhere]
387 ,,-lhesiod,HESIOD,,)
388 AC_PKG_WITH(glue,,,-lglue,GLUE,,)
389 AC_PKG_WITH(bind,,/usr/local/bind, [lib/resolv.a lib/lib44bsd.a], ,include)
390 After the appropriate checks, the existence of the files, and libs and such
391 LIBS=$LIBS $PKG-LIBS
392 DEFS=$DEFS $PKG-DEFS
393 CPPFLAGS=$PKG-CPPFLAGS $CPPFLAGS
394 $PKG-ROOT=$PKG-ROOT
395 The cppflags should reverse the order so that you can have;
396 -I/usr/local/bind/include -I/usr/local/athena/include
398 -L/usr/local/athena/lib -lkrb -ldes /usr/local/bind/lib/libresolv.a
399 as order matters.
401 also an AC_PKG_CHK_HEADER
402 and an AC_PKG_CHK_FUNCTION
403 so one can give alternate names to check for stuff ($PKG-ROOT/lib for
404 example)
405 From: Randall Winchester
407 ------------------------------------------------------------------------------
409 AC_C_CROSS assumes that configure was called like 'CC=target-gcc;
410 ./configure'. I want to write a package that has target dependent
411 libraries and host dependent tools. So I don't like to lose the
412 distinction between CC and [G]CC_FOR_TARGET.  AC_C_CROSS should check
413 for equality of target and host.
415 It would be great if
417 GCC_FOR_TARGET
418 AR_FOR_TARGET
419 RANLIB_FOR_TARGET
421 would be set automatically if host != target.
422 AC_LANG_CROSS_C would be nice too, to check header files
423 etc. with GCC_FOR_TARGET instead of CC
425 Here is one simple test
427 if test "x$host" != "x$target"; then
428 AC_CHECK_PROGS(AR_FOR_TARGET,
429                [$target-ar, $prefix/$target/bin/ar], $target-ar)
430 AC_CHECK_PROGS(RANLIB_FOR_TARGET, $target-ranlib, $target-ranlib)
431                [$target-ranlib, $prefix/$target/bin/ranlib], $target-ranlib)
432 AC_CHECK_PROGS(GCC_FOR_TARGET, $target-gcc, $target-gcc)
433                [$target-gcc, $prefix/$target/bin/gcc], $target-gcc)
436 From: nennker@cs.tu-berlin.DE (Axel Nennker)
438 (also look in the autoconf mailing list archives for the proposed
439 CHECK_TARGET_TOOL macro from Natanael Nerode, a gcc configury guru).
441 ------------------------------------------------------------------------------
443 The problem occurs with the following libc functions in SunOS 5.4:
445         fnmatch glob globfree regcomp regexec regerror regfree wordexp wordfree
447 It also occurs with a bunch more libposix4 functions that most people
448 probably aren't worried about yet, e.g. shm_open.
450 All these functions fail with errno set to ENOSYS (89)
451 ``Operation not applicable''.
453 Perhaps Autoconf should have a specific macro for fnmatch, another for
454 glob+globfree, another for regcomp+regexec+regerror+regfree, and
455 another for wordexp+wordfree.  This wouldn't solve the problem in
456 general, but it should work for Solaris 2.4.  Or Autoconf could limit
457 itself to fnmatch and regcomp, the only two functions that I know have
458 been a problem so far.
460 From Paul Eggert.
462 ------------------------------------------------------------------------------
464 Make easy macros for checking for X functions and libraries, such as Motif.
466 ------------------------------------------------------------------------------
468 There are basically three ways to lock files
469         lockf, fnctl, flock
470 I'd be interested in adding a macro to pick the "right one" if you're
471 interested.
473 From:    Rich Salz <rsalz@osf.org>
475 ------------------------------------------------------------------------------
477 Timezone calculations checks.
479 ------------------------------------------------------------------------------
481 Support different default file system layouts, e.g. SVR4, Linux.
482 Of course, this can be done locally with config.site.
484 ------------------------------------------------------------------------------
486 I wonder if it is possible to get the name of X11's app-defaults
487 directory by autoconf. Moreover, I'd like to have a general way of
488 accessing imake variables by autoconf, something like
490 AC_DEFINE(WINE_APP_DEFAULTS, AC_IMAKE_VAR(XAPPLOADDIR))
492 Slaven Rezic <eserte@cabulja.herceg.de>
494 ------------------------------------------------------------------------------
496 Every user running X11 usually has a directory like *X11* in his PATH
497 variable. By replacing bin by include, you can find good places to
498 look for the include files or libraries.
500 From: rcb5@win.tue.nl (Richard Verhoeven)
502 ------------------------------------------------------------------------------
504 In most cases, when autoscan suggests something, using the search or
505 index command into the Info reader for autoconf manual quickly
506 explains me what the test is about.  However, for header files and
507 functions, the search might fail, because the test is not of the
508 specific kind.  The Autoconf manual should reflect somewhere all
509 header files or functions (non-specific features, generally)
510 triggering autoscan to generate tests, and tell in a few words what is
511 the problem, and the suggested approach for a solution; that is, how
512 one should use the result of testing the feature.
514 From: pinard@iro.umontreal.ca
516 ------------------------------------------------------------------------------
518 It would be nice if the configure script would handle an option such as
519 --x-libraries="/usr/openwin/lib /usr/dt/lib".
521 Rick Boykin <rboykin@cscsun3.larc.nasa.gov>
523 Under Solaris 2.4, the regular X includes and libs and the Motif
524 includes and libs are in different places.  The Emacs configure script
525 actually allows dir1:dir2:dir3 --
527     if test "${x_libraries}" != NONE && test -n "${x_libraries}"; then
528       LD_SWITCH_X_SITE=-L`echo ${x_libraries} | sed -e "s/:/ -L/g"`
529       LD_SWITCH_X_SITE_AUX=-R`echo ${x_libraries} | sed -e "s/:/ -R/g"`
530     fi
531     if test "${x_includes}" != NONE && test -n "${x_includes}"; then
532       C_SWITCH_X_SITE=-I`echo ${x_includes} | sed -e "s/:/ -I/g"`
533     fi
535 ------------------------------------------------------------------------------
537     What messages should be produced by default, if any?
539 Probably only the few most important ones, like which configuration
540 name was used, whether X or Xt are in use, etc. The specific
541 decisions, and progress messages, should be recorded on the terminal
542 only if --verbose is used.
544     --silent just suppresses the "checking for...result"
545     messages, not the "creating FOO" messages.
547 I think the default should be to suppress both.
548 From: Richard Stallman <rms@gnu.ai.mit.edu>
550 There is no distinction now between
551 important decisions (we have X) vs minor decisions (we have lstat).
552 However, there are probably only a few things you deem important enough to
553 announce and only those few things will need to be changed.
554 Perhaps config.status could be written with comments saying what was
555 decided.
556 From: Roland McGrath <roland@gnu.ai.mit.edu>
558 ------------------------------------------------------------------------------
560 Another thing I wish for is a macro which figures out which libraries are
561 needed for BSD-style sockets.  AC_PATH_X already detects this
562 correctly...so it's just a matter of separating out the socket-related code.
563 From: "Joel N. Weber II" <nemo@koa.iolani.honolulu.hi.us>
565 ------------------------------------------------------------------------------
567 in order to use the AC_CANONICAL_SYSTEM macro, I have to have
568 install-sh somewhere nearby --- why is this?  I have no real reason to
569 distribute install-sh, other than that its absence breaks this code.
571 Shouldn't the above loop be looking for config.sub and config.guess?
572 From: jimb@totoro.bio.indiana.edu (Jim Blandy)
574 adding AC_CANONICAL_HOST to my configure.in script caused
575 all sorts of odd/unexplained errors.  Obviously, I had to go
576 get copies of config.guess, config.sub and install-sh from the
577 autoconf distribution, but the error messages and autoconf docs
578 didn't explain that very well.
579 From: bostic@bsdi.com (Keith Bostic)
581 ------------------------------------------------------------------------------
583 Perhaps also have AC_TRY_COMPILER try to link an invalid program, and
584 die if the compiler seemed to succeed--in which case it's not usable
585 with autoconf scripts.
587 ------------------------------------------------------------------------------
589 Copyright (C) 1994-1996, 1999-2002, 2007-2016 Free Software Foundation,
590 Inc.
592 Copying and distribution of this file, with or without modification,
593 are permitted in any medium without royalty provided the copyright
594 notice and this notice are preserved.  This file is offered as-is,
595 without warranty of any kind.