Re: aclocal doesn't check AUTOMAKE_OPTIONS (VERSION)
Tom == Tom Tromey [EMAIL PROTECTED] writes: Tom We're planning to get rid of aclocal in the future. I forget Tom exactly what form that plan takes. Akim knows. First of all, the responsibility will move to Autoconf, aclocal has nothing to do with Automake. The main plan is to get rid of aclocal.m4 too, and to include, at the M4 level, all the m4/*.m4 files which are needed. This is doable, we actually have a proto since months. Wrt this actual problem, I'm afraid there will always have some problems due to incorrectly synchronized sets of tools :( In the future Automake will read the traces. We perfectly can imagine a macro to declare an Automake requirement, and automake checking this requirement. Conversely, hm... I dunno.
generator rules
Hi, I am not on the list, could you CC me please. Sorry if this is the wrong list, but I can not tell what the PRS list is about :( Basically I had a bunch of rules like this one: cp.o: generic_client.c $(COMPILE) \ -DCLIENT_FOP_TYPE=fileutils_copy_op \ -DCLIENT_FOP_NEW=fileutils_copy_new \ -DCLIENT_HEADER=\copy.h\ \ -o cp.o -c generic_client.c and using automake (cvs) and autoconf (2.50) all I get is $ make cp.o make: Nothing to be done for `cp.o'. $ ll cp.o ls: cp.o: No such file or directory Is there an FAQ on writing rules like this for the new automake someplace? Thanks. -- --- It's the question, http://witme.sourceforge.net If you think education is expensive, try ignorance. -- Derek Bok, president of Harvard
Re: aclocal doesn't check AUTOMAKE_OPTIONS (VERSION)
Akim Demaille wrote: Tom == Tom Tromey [EMAIL PROTECTED] writes: Tom We're planning to get rid of aclocal in the future. I forget Tom exactly what form that plan takes. Akim knows. First of all, the responsibility will move to Autoconf, aclocal has nothing to do with Automake. The main plan is to get rid of aclocal.m4 too, and to include, at the M4 level, all the m4/*.m4 files which are needed. This is doable, we actually have a proto since months. Wrt this actual problem, I'm afraid there will always have some problems due to incorrectly synchronized sets of tools :( In the future Automake will read the traces. We perfectly can imagine a macro to declare an Automake requirement, and automake checking this requirement. Conversely, hm... I dunno. How about something as simple as allowing a version to be specified in an *.m4 file. Then if the macro version is less than the version of the copy in the m4 dir then autoconf won't copy the new (old) version over m4/* unless forced? Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] CollabNet ( http://collab.net ) -- Travel advisories - Alaska: Tourists are warned to wear tiny bells on their clothing when hiking in bear country. The bells warn away MOST bears. Tourists are also cautioned to watch the ground on the trail, paying particular attention to bear droppings, to be alert for the presence of Grizzly Bears. One can tell Grizzly droppings by the tiny bells in them.
Re: AC_CONFIG_AUX_DIR now required when mdate-sh resides in subdir?
Jim Meyering wrote: Hi Derek, Recently, automake changed so that I get the following in fileutils-4.1, even though I've put a copy of mdate-sh (though not in the official tarball) in doc/. $ automake --gnits --include-deps doc/Makefile.am:2: required file `./mdate-sh' not found I don't use AC_CONFIG_AUX_DIR. The last time I checked, I found it didn't work because some of those aux files live at the top level, and others (like mdate-sh and texinfo.tex) belong in doc/. That's the way AC_CONFIG_AUX_DIR is defined. It allows for the relocation of _all_ of the auxiliary files used in configuration. This can be decidedly convenient if you have two doc directories for some reason. An explicit exception was made for texinfo.tex, but only when AC_CONFIG_AUX_DIR isn't set explicitly. I would guess that a similar exception for mdate-sh would be acceptable if others thought it a good idea. I don't know much about it, but glancing through the code seems to confirm that an exception wouldn't hurt. My glance through the code also seems to confirm that this shouldn't be too hard to accomplish. Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] CollabNet ( http://collab.net ) -- May the forces of evil become confused on the way to your house. -- George Carlin
Re: Automake release
On Sun, May 20, 2001 at 11:20:32AM -0600, Tom Tromey wrote: Allan == Allan Clark [EMAIL PROTECTED] writes: Allan So whatever happened to numeric point releases? Allan 1.5 will do that Allan this is release 1.4.3, automake-1.4.3 In gnits there are only two numbers. The third one, if it exists, indicates an alpha release. That is the problem. Looks like time for the Linux (and now more widely used) scheme of odd releases are development; even releases are stable. Of course, to abide by the broken gnits rule you refer to, it'll have to the be the major release number whose evenness matters: 1.x is development; 2.x stable. (That the gnits two-number rule is broken is only my opinion, of course, but that opinion was formed directly as a result of this thread :-) -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. - RFC 1925 (quoting an unnamed source)
Re: Deleting Makefile.in in maintainer-clean
On Sat, May 19, 2001 at 06:46:03PM +0100, Gary V . Vaughan wrote: On Saturday 19 May 2001 3:41 pm, Reinhard M?ller wrote: How about TOTALLYCLEAN or COMPLETELYCLEAN and defining it as removing everything that can be rebuilt somehow (e.g. with autoconf, automake, libtoolize, etc.) Yes, please! As long as there's also a way to bootstrap back from there to configure;make-ability. For a simple autoconf+automake package, I presume autoreconf will do this, but other things like libtool may make things more complicated. The bootstrap could be a simple shell script that makes no attempt to optimize out unnecessary actions -- after all, you would rarely be running it unless all the actions *were* necessary. REALLYREALLYCLEAN? CLEANOFTHECLEAN? :-) PRISTINE (No smiley; I mean it.) -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. - RFC 1925 (quoting an unnamed source)
Re: generator rules
Tom Tromey [EMAIL PROTECTED] writes: == monkeyiq [EMAIL PROTECTED] writes: cp.o: generic_client.c $(COMPILE) \ -DCLIENT_FOP_TYPE=fileutils_copy_op \ -DCLIENT_FOP_NEW=fileutils_copy_new \ -DCLIENT_HEADER=\copy.h\ \ -o cp.o -c generic_client.c BTW, why did you need an explicit rule like this? Maybe with the cvs automake you'd prefer per-executable CFLAGS. After a little kip the reason behind the problem came to me. A thoughtless cut and paste, I'm afraid :( the old tab -- spaces == boom. I actually though of this and went to the autotools book on the net and checked it out, the book prints that one needs automake 1.5, [witme-fileutils]$ automake --version automake (GNU automake) 1.4g the relavent section is at the bottom of: autobook-1.2/autobook_41.html#SEC41 I will play with converting to per-exe CFLAGS now that I have something that compiles :) Thanks. -- --- It's the question, http://witme.sourceforge.net If you think education is expensive, try ignorance. -- Derek Bok, president of Harvard
Re: generator rules
== monkeyiq [EMAIL PROTECTED] writes: I actually though of this and went to the autotools book on the net and checked it out, the book prints that one needs automake 1.5, [witme-fileutils]$ automake --version automake (GNU automake) 1.4g the relavent section is at the bottom of: autobook-1.2/autobook_41.html#SEC41 I haven't re-read the book text. But the book talked only of released versions of automake. 1.4f and 1.4g aren't releases -- they are alpha. Tom
