From: John K. H. <hi...@al...> - 2004-03-29 20:33:59
|
I'm having configure/automake trouble building the CVS head on Debian even after upgrading my automake (to 1.8.3) and autoconf (to 2.59) which upgrades usually fix these things... The Makefile seems to concatenate together all the "configure.in" for all the modules - even if I am not building them, into one big file "configure.ac" which contains duplicate definitions from the various modules: cat src/configure.in modules/wildcard/configure.in modules/regexp/configure.in modules/clx/new-clx/configure.in modules/postgresql/configure.in modules/dirkey/configure.in modules/syscalls/configure.in modules/oracle/configure.in modules/fastcgi/configure.in modules/berkeley-db/configure.in modules/pcre/configure.in ffcall/configure.in ffcall/avcall/configure.in ffcall/vacall/configure.in ffcall/trampoline/configure.in ffcall/callback/configure.in ffcall/callback/vacall_r/configure.in ffcall/callback/trampoline_r/configure.in utils/hln/configure.in libcharset/configure.in | grep -v AC_INIT | grep -v AC_OUTPUT >> configure.ac Then this command fails: aclocal -I src/m4 --output=src/autoconf/aclocal.m4 w/ the error: configure.ac:344: error: `config.h' is already registered with AC_CONFIG_HEADERS. autoconf/status.m4:424: AC_CONFIG_HEADERS is expanded from... configure.ac:344: the top level autom4te: /usr/bin/m4 failed with exit status: 1 aclocal: autom4te failed with exit status: 1 make[1]: *** [src/autoconf/aclocal.m4] Error 1 make[1]: Leaving directory `/u/hin/src/clisp' make: *** [../src/VERSION] Error 2 I looked at the "configure.ac" and it appears the line AC_CONFIG_HEADERS(config.h) is drawn in from most of the various modules' configure.in ... what to do? ... As quick fix I tried commenting out the redundant directives in the configure.in files for just the modules I am building, but then there are many, many other duplicates, such as AC_CONFIG_FILES([Makefile]) Is there a way to tell automake's "aclocal" to just ignore the duplicates and keep going? Or some way to fix the build environment? |
From: Sam S. <sd...@gn...> - 2004-03-29 21:07:42
|
> * John K. Hinsdale <uva@nyzn.pbz> [2004-03-29 15:33:54 -0500]: > > The Makefile seems to concatenate together all the "configure.in" for > all the modules - even if I am not building them, into one big file > "configure.ac" which contains duplicate definitions from the various > modules: this is the development makefile. if you find yourself using it, something is amiss. usually the right solution is to touch(1) the files that triggered the rule, like src/VERSION &c. I think we need to add --enable-maintainer-mode option to the top-level configure and makemake so that only the few people "in the know" will ever have to deal with these. Bruno? please try the appended patch for now. -- Sam Steingold (http://www.podval.org/~sds) running w2k <http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/> <http://www.mideasttruth.com/> <http://www.honestreporting.com> The difference between genius and stupidity is that genius has its limits. --- Makefile.devel 18 Mar 2004 19:00:56 -0500 1.106 +++ Makefile.devel 29 Mar 2004 15:59:40 -0500 @@ -135,7 +135,7 @@ src/autoconf/aclocal.m4 : $(wildcard src/m4/*.m4) $(addsuffix .in,$(CONFIGURES)) grep AC_INIT src/configure.in > configure.ac - cat $(addsuffix .in,$(CONFIGURES)) | grep -v AC_INIT | grep -v AC_OUTPUT >> configure.ac + cat $(addsuffix .in,$(CONFIGURES)) | grep -v AC_INIT | grep -v AC_CONFIG_HEADERS | grep -v AC_OUTPUT >> configure.ac echo AC_OUTPUT >> configure.ac aclocal -I src/m4 --output=src/autoconf/aclocal.m4 $(RM) configure.ac |
From: Bruno H. <br...@cl...> - 2004-03-31 19:47:43
|
Sam wrote: > I think we need to add --enable-maintainer-mode option to the top-level > configure and makemake so that only the few people "in the know" will > ever have to deal with these. > Bruno? --enable-maintainer-mode doesn't have many friends, and automake went into the opposite direction: things don't work differently for Joe User than for the maintainer, in most GNU packages. For this to work, 1. people working off the CVS need to read the instructions usually written in a file called README-alpha, 2. the maintainer needs to be careful to not introduce unnecessary dependencies. I consider a dependency from configure.in to src/VERSION as annoying, because configure.in is modified more often than the version changes. You can solve this problem by putting the version in a separate file, say version.sh, where configure will fetch it. =================== version.sh ================= # Version number and release date. VERSION_NUMBER=2.33 RELEASE_DATE=2004-03-17 # in "date +%Y-%m-%d" format ================================================ configure.in then contains AC_PREREQ(2.57) . $srcdir/version.sh AC_INIT(GNU CLISP,$VERSION_NUMBER ($RELEASE_DATE),http://clisp.cons.org/) Bruno > this is the development makefile. > if you find yourself using it, something is amiss. > usually the right solution is to touch(1) the files that triggered the > rule, like src/VERSION &c. > > I think we need to add --enable-maintainer-mode option to the top-level > configure and makemake so that only the few people "in the know" will > ever have to deal with these. > Bruno? > > please try the appended patch for now. |