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