From: Keith M. <kei...@to...> - 2005-05-27 09:27:00
|
Max T. Woodbury wrote: > I've been having some trouble with the various auto<whatever> tools > getting invoked and then blowing up. Of course this means there is a > problem somewhere in the auto<whatever> installation, but the fact > remains that the tools should not be needed to build the packages > fresh out of the tarballs. You are correct. "./configure && make && make install" should be fully sufficient, without even requiring the autotools to be present. > Earnie has a partial solution embedded in his cygwin2msys script, but > it isn't complete. It lets autoconf be bypassed, but some packages > still want to run autoheader. > > ... > > As I mentioned, it does not quite do all that is needed with respect > to autoheader. I am missing something in my understanding of the > auto-tools. If someone who knows more about this could comment, I'd > appreciate it. If you can point me at a package which insists on this misbehaviour, I'll have a look when I can find the time. Best regards, Keith. |
From: Keith M. <kei...@to...> - 2005-05-27 14:13:52
|
Max T Woodbury wrote, quoting me: >> You are correct. "./configure && make && make install" should be >> fully sufficient, without even requiring the autotools to be present. > > I happen to like to use a separate build directory, but we are in > basic agreement. So do I. Perhaps I should have said "${top_srcdir}/configure ..." :-) >>> ... >>> >>> As I mentioned, it does not quite do all that is needed with respect >>> to autoheader. I am missing something in my understanding of the >>> auto-tools. If someone who knows more about this could comment, I'd >>> appreciate it. >> >> If you can point me at a package which insists on this misbehaviour, >> I'll have a look when I can find the time. > > grep It insists on doing an 'autoconf' and can't find macro > _m4_divert_diversion > make _m4_divert_diversion again > sh-utils automake macros AM_FUNC_ERROR_AT_LINE and AM_FUNC_STRTOD > tar some kind of automake or autoconf problem... > textutils same as sh-utils I just grabbed all the GNU canonical sources for these, and tried a quick configure and make on each. NONE exhibits any tendency to invoke either autoconf or autoheader, but then none build successfully either, with MinGW. Obviously some porting effort is required, and I guess that is why Earnie provides MSYS specific sources for them. The tendency to run autoconf during the build is apparently peculiar to these particular sources; perhaps, as Earnie says, the timestamp tracking in the tarballs is messed up. I don't have time to investigate further, at the moment. BTW, according to GNU, sh-utils and textutils have been merged into coreutils; the separate tarballs are no longer distributed by the FSF. Best regards, Keith. |
From: Earnie B. <ea...@us...> - 2005-05-27 15:20:57
|
On 2:07:29 pm 2005-05-27 Keith MARSHALL <kei...@to...> wrote: > Max T Woodbury wrote, quoting me: > >> You are correct. "./configure && make && make install" should be > >> fully sufficient, without even requiring the autotools to be > > present. > > I happen to like to use a separate build directory, but we are in > > basic agreement. > > So do I. Perhaps I should have said "${top_srcdir}/configure ..." :-) > > >>> ... > >>> > >>> As I mentioned, it does not quite do all that is needed with > >>> respect to autoheader. I am missing something in my > >>> understanding of the auto-tools. If someone who knows more > >>> about this could comment, I'd appreciate it. > >> > >> If you can point me at a package which insists on this > >> misbehaviour, I'll have a look when I can find the time. > > > > grep It insists on doing an 'autoconf' and can't find macro > > _m4_divert_diversion > > make _m4_divert_diversion again > > sh-utils automake macros AM_FUNC_ERROR_AT_LINE and > > AM_FUNC_STRTOD tar some kind of automake or autoconf > > problem... textutils same as sh-utils > > I just grabbed all the GNU canonical sources for these, and tried a > quick configure and make on each. NONE exhibits any tendency to > invoke either autoconf or autoheader, but then none build > successfully either, with MinGW. > > Obviously some porting effort is required, and I guess that is why > Earnie provides MSYS specific sources for them. The tendency to run > autoconf during the build is apparently peculiar to these particular > sources; perhaps, as Earnie says, the timestamp tracking in the > tarballs is messed up. I don't have time to investigate further, at > the moment. > Storing the generated autotools files in CVS tends to skew the timestamp ordering required for the makefile rules for the person who subsequently checks them out. Touching the generated files in the correct order will stop the need for the Makefile rules to try to build the files again. I think it is wrong for the autotools to provide those dependencies in the Makefile but I don't have time to fight that battle. > BTW, according to GNU, sh-utils and textutils have been merged into > coreutils; the separate tarballs are no longer distributed by the FSF. > I have it on my list of items to provide a coreutils version at some point. I will do that when I break out MSYS into tarball distributions for the new MinGW-4 installer. I will provide a minimal set of coreutils and a full set; I find the full set of utilities a good to have. Earnie -- MinGW - http://www.mingw.org/ Wiki - http://www.mingw.org/MinGWiki/ Bug Report - http://sourceforge.net/tracker/?group_id=2435&atid=102435 Submit Patch - http://sourceforge.net/tracker/?group_id=2435&atid=302435 SF Project - http://sourceforge.net/projects/mingw Job Listing - http://sf.net/people/viewjob.php?group_id=2435&job_id=21643 Job Listing - http://sf.net/people/viewjob.php?group_id=46778&job_id=22223 |
From: Julien L. <lec...@fr...> - 2005-05-27 17:13:05
|
> -----Original Message----- > From: min...@li... > [mailto:min...@li...] On Behalf Of > Earnie Boyd > > Storing the generated autotools files in CVS tends to skew > the timestamp ordering required for the makefile rules for > the person who subsequently checks them out. Touching the > generated files in the correct order will stop the need for > the Makefile rules to try to build the files again. I think > it is wrong for the autotools to provide those dependencies > in the Makefile but I don't have time to fight that battle. > I too have noticed that CVS touches the files (at least TortoiseCVS, since I rarely use CVS by command line). I don't know if this is a bug or by design. But "--disable-maintainer-mode" suppresses the need to relauch autoconf, automake & other autotools. In other words, if packages all used automake (which is not always appreciated among the community) and AM_MAINTAINER_MODE in configure.in, then we wouldn't have such problems. > -----Original Message----- > From: min...@li... > [mailto:min...@li...] On Behalf Of > Max T. Woodbury > #! /bin/sh > # Supress automatic invocation of autoconf and friends if > test "$1" == ""; then t="."; else t="$1"; fi find $t -name > configure.in -exec touch {} \; -print find $t -name > aclocal.m4 -exec touch {} \; -print find $t -name acconfig.h > -exec touch {} \; -print find $t -name Makefile.in -exec > touch {} \; -print find $t -name configure -exec touch {} \; > -print find $t -name config.h.in -exec touch {} \; -print > > As I mentioned, it does not quite do all that is needed with > respect to autoheader. I am missing something in my > understanding of the auto-tools. If someone who knows more > about this could comment, I'd appreciate it. Here is a more complete list of everything which is used (which I hope is in order): Aclocal -> - all *.m4 scripts in the m4 directory (usually top_src_dir, but can be specified by ACLOCAL_FLAGS in makefile.am) are never rebuilt but: - aclocal.m4 is rebuilt if configure.ac changes or if a m4 script file is changed (and probably if makefile.am is modified and ACLOCAL_FLAGS is used) - acconfig.h, config-top.h, config-bot.h are deprecated (AFAIK), so I don't really know what they depend on or what depends on them. Automake -> - Makefile.am: depends on nothing - Makefile.in: rebuilt if makefile.am, configure.ac, or aclocal.m4 is changed Autoconf -> - configure.ac: depends on nothing (configure.in is deprecated) - configure: depends on aclocal.m4 and configure.ac Autoheader -> - config.h.in: depends on aclocal.m4 and configure.ac (and probably also acconfig.h, config-top.h, config-bot.h) Autotest -> ( the tool used is actually autom4te) - package.m4: user defined rule, but usually only depends on configure.ac - testsuite.at: (usually called testsuite.at actually, but can be named otherwise) user defined rule, should depend on nothing - testsuite: (usually called testsuite actually) user defined rule, usually depends on testsuite.at and all the test files (usually *.at or *.test) To make matters worse, someone can add dependencies to testsuite (such a .c files) and also add user dependencies to normal configuration files (via CONFIGURE_DEPENDENCIES in Makefile.am) Julien |
From: Max T. W. <max...@ve...> - 2005-05-27 12:36:36
|
Keith MARSHALL wrote: > Max T. Woodbury wrote: > > I've been having some trouble with the various auto<whatever> tools > > getting invoked and then blowing up. Of course this means there is a > > problem somewhere in the auto<whatever> installation, but the fact > > remains that the tools should not be needed to build the packages > > fresh out of the tarballs. > > You are correct. "./configure && make && make install" should be fully > sufficient, without even requiring the autotools to be present. I happen to like to use a separate build directory, but we are in basic agreement. > > ... > > > > As I mentioned, it does not quite do all that is needed with respect > > to autoheader. I am missing something in my understanding of the > > auto-tools. If someone who knows more about this could comment, I'd > > appreciate it. > > If you can point me at a package which insists on this misbehaviour, > I'll have a look when I can find the time. grep It insists on doing an 'autoconf' and can't find macro _m4_divert_diversion make _m4_divert_diversion again sh-utils automake macros AM_FUNC_ERROR_AT_LINE and AM_FUNC_STRTOD tar some kind of automake or autoconf problem... textutils same as sh-utils max |