Re: autoreconf misses ltmain.sh
Thomas Dickey wrote: > > > In my opinion it is prohibitive and stupid > > It's equally stupid to . I think everyone knows that autoreconf is not ready for prime time. >From someone who gets cranky when working code breaks because someone thought I shouldn't do things that way, let me say this: Don't use autoreconf. Blow away your sources and rebootstrap. That must work whether autoreconf does or not. And volunteer your project for the regression suite :-)
Re: autoreconf misses ltmain.sh
On Mon, Sep 23, 2002 at 12:23:34PM +0200, Ralf Corsepius wrote: > In my opinion it is prohibitive and stupid not to have a libtool release > that can properly interact with autoconf. It's equally stupid to release a version of autoconf which cannot properly interact with released versions of libtool. (That's what engineering is all about - the converse is just playing games). -- Thomas E. Dickey <[EMAIL PROTECTED]> http://invisible-island.net ftp://invisible-island.net
Re: autoreconf misses ltmain.sh
Alexandre Duret-Lutz <[EMAIL PROTECTED]> writes: > >>> "Ralf" == Ralf Corsepius <[EMAIL PROTECTED]> writes: > > [...] > > Ralf> http://mail.gnu.org/pipermail/libtool-patches/2002-January/001659.html > > Ralf> .. which seems to indicate that libtool is the culprit. > Ralf> => There doesn't exist any officially released version of libtool that > Ralf> is usable with autoconf-2.54 and automake-1.7 > > Not exactly: there is no release of Libtool that honors > AC_CONFIG_AUX_DIR in configure.*ac*. It's sometime in January I sent the patch for that. Is there no chance of a bugfix release, given that the fix is trivial? If you use libtool and AC_CONFIG_AUX_DIR, you need to do ugly things like having a configure.in symlink for libtoolize to use. > Ralf> .. still nobody wanting to care to fix it? > > AFAICT it's fixed in CVS Libtool. And in Debian. -- Roger Leigh "Liberty and Livelihood" Support the Countryside Alliance www.march-info.org
Problem with 'make distcheck'
Hello, in a 'lib' directory I have the following Makefile.am: lib_LTLIBRARIES = libTACOExtensions.la libTACOExtensions_la_SOURCES = $(top_srcdir)/server/src/TACOServer.cpp \ $(top_srcdir)/common/src/TACOException.cpp \ $(top_srcdir)/common/src/TACOExtensions.cpp \ $(top_srcdir)/client/src/TACOClient.cpp libTACOExtensions_la_LDFLAGS = -version-info $(subst .,:,@VERSION@) -export-dynamic libTACOExtensions_la_LIBADD = $(LIB_TACO) A 'make distcheck' fails due to 'Error: files left after distclean'. These files are $find taco-ext-0.0.0/\=build/ taco-ext-0.0.0/=build/ taco-ext-0.0.0/=build/lib taco-ext-0.0.0/=build/client taco-ext-0.0.0/=build/client/src taco-ext-0.0.0/=build/client/src/TACOClient.cpp taco-ext-0.0.0/=build/client/python taco-ext-0.0.0/=build/client/include taco-ext-0.0.0/=build/common taco-ext-0.0.0/=build/common/res taco-ext-0.0.0/=build/common/src taco-ext-0.0.0/=build/common/src/TACOException.cpp taco-ext-0.0.0/=build/common/src/TACOExtensions.cpp taco-ext-0.0.0/=build/common/include taco-ext-0.0.0/=build/server taco-ext-0.0.0/=build/server/src taco-ext-0.0.0/=build/server/src/TACOServer.cpp taco-ext-0.0.0/=build/server/include exactly the source files of the library. Why are these files in the build directory? Ciao
Re: results with automake-1.6d
Alexandre Duret-Lutz writes: > Art> gettext (GNU gettext) 0.11.5 > [...] > Art> + /usr/bin/perl /home/arth/gnu/automake/objdir/tests/testSubDir/../../aclocal >-I /home/arth/gnu/automake/objdir/tests/testSubDir/../../m4 >--acdir=/home/arth/gnu/automake/tests/../m4 -I /home/arth/gnu/automake/tests/../m4 -I >/usr/local/share/aclocal > Art> aclocal: macro `gt_INTDIV0' required but not defined > Art> aclocal: macro `jm_AC_TYPE_UINTMAX_T' required but not defined > Art> aclocal: macro `gt_HEADER_INTTYPES_H' required but not defined > Art> aclocal: macro `gt_INTTYPES_PRI' required but not defined > Art> FAIL: gettext.test This looks like a bug in gettext-0.11.3 which is fixed in gettext 0.11.5. Bruno
Re: autoreconf misses ltmain.sh
Am Mon, 2002-09-23 um 10.49 schrieb Alexandre Duret-Lutz: > >>> "Ralf" == Ralf Corsepius <[EMAIL PROTECTED]> writes: > > [...] > > Ralf> http://mail.gnu.org/pipermail/libtool-patches/2002-January/001659.html > > Ralf> .. which seems to indicate that libtool is the culprit. > Ralf> => There doesn't exist any officially released version of libtool that > Ralf> is usable with autoconf-2.54 and automake-1.7 > > Not exactly: there is no release of Libtool that honors > AC_CONFIG_AUX_DIR in configure.*ac*. > > Ralf> .. still nobody wanting to care to fix it? > > AFAICT it's fixed in CVS Libtool. We are talking about released SW rsp. to be released SW here. The current situation is: libtool and autoreconf do not interact together, rendering autoreconf entirely useless and unreliable in total in many situations, no matter if libtool is the culprit or not. Pointing users to cvs versions is acceptable as long a tool is in development, however once a tool is release, this situation changes. Read: Users will yell at autoconf, because _it_ can't deal with released versions of libtool. In my opinion it is prohibitive and stupid not to have a libtool release that can properly interact with autoconf. Ralf
Re: autoreconf misses ltmain.sh
>>> "Ralf" == Ralf Corsepius <[EMAIL PROTECTED]> writes: [...] Ralf> http://mail.gnu.org/pipermail/libtool-patches/2002-January/001659.html Ralf> .. which seems to indicate that libtool is the culprit. Ralf> => There doesn't exist any officially released version of libtool that Ralf> is usable with autoconf-2.54 and automake-1.7 Not exactly: there is no release of Libtool that honors AC_CONFIG_AUX_DIR in configure.*ac*. Ralf> .. still nobody wanting to care to fix it? AFAICT it's fixed in CVS Libtool. -- Alexandre Duret-Lutz
