Handling of extra macros
I've seen conflicting advice about how to handle extra macros, whether developed locally or from the archive. What's the best way to get them into configure? I think this reduces to the question of how to make aclocal aware of them. 1. AC_CONFIG_MACRO_DIR doesn't work, according to prior posts on this list, my tests, and, ambiguously, the manual (which refers to future versions). 2. The man page for aclocal on my (Debian) system says At startup, aclocal scans all the .m4 files it can find, looking for macro definitions. Then it scans configure.in. Any mention of one of the macros found in the first step causes that macro, and any macros it in turn requires, to be put into aclocal.m4. This doesn't seem to be the case, even if the file is in the same directory as configure.ac. Or one could say the quoted description is true, but aclocal can't find macros in the project directory. Either way, it doesn't work. 3. Other advice says to stick the macros in aclocal.m4. I did, but they got overwritten the first time aclocal ran. 4. If I put the macros in a directory and do aclocal -I thedirectory things work, but this seems to be asking for trouble. 5. The autoconf manual has no index entry for aclocal. There is one for aclocal.m4, and the text refers to aclocal. Is aclocal deprecated? I have Debian autoconf 2.59a-7 and am looking at the manual for 2.59, dated 5 Nov 2003 (direct from GNU). I've also been looking at the somewhat dated Autoconf, Automake, and Libtool book. I'm not using automake. -- Ross Boylan wk: (415) 514-8146 185 Berry St #5700 [EMAIL PROTECTED] Dept of Epidemiology and Biostatistics fax: (415) 514-8150 University of California, San Francisco San Francisco, CA 94107-1739 hm: (415) 550-1062 ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: Handling of extra macros
On Thu, 2005-12-01 at 21:38 +0100, Alexandre Duret-Lutz wrote: RB == Ross Boylan [EMAIL PROTECTED] writes: RB 5. The autoconf manual has no index entry for aclocal. There is one for RB aclocal.m4, and the text refers to aclocal. Is aclocal deprecated? aclocal is part of Automake, not autoconf. The Automake manual documents aclocal and explains how to handle local macros properly. Thank you. For the record, the file acinclude.m4 is automatically included. It seems odd that a routine part of using autoconf requires automake. I realize technically aclocal is not required to use autoconf, but my understanding is that it's use is routine. ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Problems running autoscan
$ autoscan autom4te: configure.ac: no such file or directory autoscan: /usr/bin/autom4te failed with exit status: 1 This is a puzzling message, since the purpose of autoscan, as I understand it, is to produce a file which, if blessed by me, becomes configure.ac. So why would it complain that configure.ac is missing? Does this just indicate that autoscan does additional stuff for people who have configure.ac, or is something wrong? $ autoscan --version autoscan (GNU Autoconf) 2.59 Written by David J. MacKenzie and Akim Demaille. Running on Debian GNU/Linux. It may be relevant that the project has parts in subdirectories. ___ Autoconf mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/autoconf
kdelibs build problem: possibly undefined macro: AC_CHECK_MKDTEMP
I am trying to build KDE on a Debian GNU/Linux testing system (build from cvs head). I keep running into problems that I think are related the versions of the auto* tools I'm using. Do I need particular versions of autoconf to work with particular versions of automake, for example? How do I find which ones are consistent? And how can I figure out what is going on with errors like the following, while trying to build kdelibs: make -k -f Makefile.cvs This Makefile is only for the CVS repository *** Creating acinclude.m4 *** Creating list of subdirectories *** Creating configure.in *** Creating aclocal.m4 *** Creating configure configure.in:105: error: possibly undefined macro: AC_CHECK_MKDTEMP If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. Some version info autoconf (GNU Autoconf) 2.57 automake (GNU automake) 1.7.5 gcc.real (GCC) 3.3 (Debian) autotools-dev 20030519.1 (provides config.guess and config.sub) I had some lower version number tools installed earlier, and managed to get past some problems by removing them. I believe I only have one each of autconf and automake now, though several flavors of gcc are on the system. Some of the KDE scripts explicitly search for particular versions of the tools. Thanks.
Re: kdelibs build problem: possibly undefined macro: AC_CHECK_MKDTEMP
On Thu, Jun 05, 2003 at 01:33:29PM -0700, Ross Boylan wrote: I am trying to build KDE on a Debian GNU/Linux testing system (build from cvs head). I keep running into problems that I think are related the versions of the auto* tools I'm using. Do I need particular versions of autoconf to work with particular versions of automake, for example? How do I find which ones are consistent? And how can I figure out what is going on with errors like the following, while trying to build kdelibs: make -k -f Makefile.cvs This Makefile is only for the CVS repository *** Creating acinclude.m4 *** Creating list of subdirectories *** Creating configure.in *** Creating aclocal.m4 *** Creating configure configure.in:105: error: possibly undefined macro: AC_CHECK_MKDTEMP If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. OK, this problem was an odd side effect of mixing cvs and cvsup, which froze some files at older versions. The macro is defined in some other KDE files. I am still interested in answers on the general questions raised at the top of the message.
