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