GNU Automake 1.10 released
to breaks backward compatibility with older versions.
If your package used both variables, as in
AM_LDFLAGS = common flags
bin_PROGRAMS = a b c
a_LDFLAGS = more flags
...
and assumed *_LDFLAGS would sum up, you should rewrite it as
AM_LDFLAGS = common flags
bin_PROGRAMS = a b c
a_LDFLAGS = $(AM_LDFLAGS) more flags
...
This new behavior of *_LDFLAGS is more coherent with other
per-target variables, and the way *_LDFLAGS variables were
considered internally.
* New installation targets:
- New targets mandated by GNU Coding Standards:
install-dvi
install-html
install-ps
install-pdf
By default they will only install Texinfo manuals.
You can customize them with *-local variants:
install-dvi-local
install-html-local
install-ps-local
install-pdf-local
- The undocumented recursive target `uninstall-info' no longer exists.
(`uninstall' is in charge of removing all possible documentation
flavors, including optional formats such as dvi, ps, or info even
when `no-installinfo' is used.)
* Miscellaneous changes:
- Automake no longer complains if input files for AC_CONFIG_FILES
are specified using shell variables.
- clean, distribution, or rebuild rules are normally disabled for
inputs and outputs of AC_CONFIG_FILES, AC_CONFIG_HEADERS, and
AC_CONFIG_LINK specified using shell variables. However, if these
variables are used as ${VAR}, and AC_SUBSTed, then Automake will
be able to output rules anyway.
(See the Automake documentation for AC_CONFIG_FILES.)
- $(EXEEXT) is automatically appended to filenames of TESTS
that have been declared as programs in the same Makefile.
This is mostly useful when some check_PROGRAMS are listed in TESTS.
- `-Wportability' has finally been turned on by default for `gnu' and
`gnits' strictness. This means, automake will complain about %-rules
or $(GNU Make functions) unless you switch to `foreign' strictness or
use `-Wno-portability'.
- Automake now uses AC_PROG_MKDIR_P (new in Autoconf 2.60), and uses
$(MKDIR_P) instead of $(mkdir_p) to create directories. The
$(mkdir_p) variable is still defined (to the same value as
$(MKDIR_P)) but should be considered obsolete. If you are using
$(mkdir_p) in some of your rules, please plan to update them to
$(MKDIR_P) at some point.
- AM_C_PROTOTYPES and ansi2knr are now documented as being obsolete.
They still work in this release, but may be withdrawn in a future one.
- Inline compilation rules for gcc3-style dependency tracking are
more readable.
- Automake installs a Hello World! example package in $(docdir).
This example is used throughout the new Autotools Introduction
chapter of the manual.
--
Alexandre Duret-Lutz
pgpF7loYDj2zG.pgp
Description: PGP signature
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: overriding libdir?
Olly Betts: | On 2006-04-12, Tyler MacDonald [EMAIL PROTECTED] wrote: | I'm trying to ion-diret automake/libtool to allow me to | install a library into PHP's extension directory. | | phpextdir = `$(PHP_CONFIG) --extension-dir` | phpext_LTLIBRARIES = php_mod_bt.la Unless `php-config --extension-dir` returns something like $(prefix)/foo/bar, this setup will prevent non-root installations and cause distcheck to fail. See the Hard-Coded Install Paths of the Automake FAQ for inspiration. -- Alexandre Duret-Lutz ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: [bug-gnulib] Re: libtool 2.1a failed mdemo-make.test on Solaris
Bruno == Bruno Haible [EMAIL PROTECTED] writes: [...] Bruno all-local $(libfoo_la_OBJECTS): $(ARGZ_H) Hmmm, why do you need this since $(ARGZ_H) is already in $(BUILT_SOURCES), and all depends on $(BUILT_SOURCES)? -- Alexandre Duret-Lutz ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: UTF-8 text files
Ralf == Ralf Wildenhues [EMAIL PROTECTED] writes: Ralf Didn't add a thank you note to the last ChangeLog entry yet -- Ralf are the Libtool developers alright with UTF-8 encoded ChangeLog*, Ralf THANKS, (maybe eventually AUTHORS) files? Automake has utf-8 ChangeLog and THANKS file since a few months. Gettext started a few years ago (IIRC it even uses unicode characters in C comments). I think it is safe to use utf-8 today as long as it is not in (portion of) files that get installed in user packages. Ralf Any emacs-foo I'd need to add at the top or bottom? ;; Variables: ;; coding: utf-8 ;; End: at the end, or -*- coding: utf-8 -*- at the beginning. Or nothing and rely on autodetection. -- Alexandre Duret-Lutz
GNU Automake 1.9.5 released
I'm pleased to announce the release of Automake 1.9.5. This is a bug-fix release, the list of bugs fixed is appended. You can find the new release here: ftp://ftp.gnu.org/gnu/automake/automake-1.9.5.tar.gz ftp://ftp.gnu.org/gnu/automake/automake-1.9.5.tar.gz.sig ftp://ftp.gnu.org/gnu/automake/automake-1.9.5.tar.bz2 ftp://ftp.gnu.org/gnu/automake/automake-1.9.5.tar.bz2.sig ftp://sources.redhat.com/pub/automake/automake-1.9.5.tar.gz ftp://sources.redhat.com/pub/automake/automake-1.9.5.tar.gz.sig ftp://sources.redhat.com/pub/automake/automake-1.9.5.tar.bz2 ftp://sources.redhat.com/pub/automake/automake-1.9.5.tar.bz2.sig Soon it will also appear on the sources and GNU mirrors listed here: http://www.gnu.org/order/ftp.html http://sources.redhat.com/mirrors.html Finally, here are the MD5 checksums: 3a534ad55d781861e1e92d3b8d898a9a automake-1.9.5.tar.bz2 f22b4cabccbb5243092a6d19912cb5fb automake-1.9.5.tar.gz Please report bugs to bug-automake@gnu.org. Bugs fixed in 1.9.5: * Longstanding bugs: - All m4 files have been relicensed under an all-permissive license. Previously they used a GPL license, and an all-permissive license was prepended when they were copied into aclocal.m4, leading to some confusion. - aclocal now recognizes AU_ALIAS. - Improve support for `make -k', it didn't work on cygwin. - Fix the definition of FCLINK for preprocessed Fortran. - Fixes for auxiliary scripts: - depcomp's tru64 mode did not work while compiling libtool libraries with static libraries disabled. - mdate-sh now copes with Darwin's non-standard ls output. - missing properly emulates makeinfo when neither -o nor @setfilename are used. - Don't output long variable definitions. Automake normally tries to output variable definitions as they are input, bug very long lines in Makefile.in can break some sed and make implementations with a limited line length. If a line in a variable definition is longer than 1000 characters, automake will wrap the definition around 80 columns. Other definitions are still output untouched. * Noteworthy manual updates: - Hard-Coded Install Paths: New FAQ entry. - How the Linker is Chosen: Rewritten. pgptJ5Xqa6t4C.pgp Description: PGP signature ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: libtool: unrecognized option `--tag=CC'
On Tue, Jan 04, 2005 at 02:10:14PM +0100, Ralf Wildenhues wrote: As your build also shows (I've deleted that because I could've guessed it), the automatic rebuilding rules call `automake' again, which is likely much newer than the shipped ltmain.sh. Automake creates the rules that contain `--tag', Automake outputs --tag only if the libtool.m4 file used supports them. So this indicates mismatch between libtool.m4 and ltmain.sh. ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: libtool --silent based on MAKEFLAGS?
Ralf == Ralf Wildenhues [EMAIL PROTECTED] writes: [...] Ralf So, how about this? Let's have Automake include $(LIBTOOLFLAGS) in Ralf their libtool invocation. The user can then use Ralf LIBTOOLFLAGS=--silent Ralf at either configure or make time. This approach is Automake-centric, Ralf but other buildtools can do similar. Sounds sensible to me. People have also asked this to specify --preserve-dup-deps, and --tag=FOO in cases Automake cannot guess it. Let's make it `$(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS)' with `$(AM_LIBTOOLFLAGS)' replaced by `libfoo_la_LIBTOOLFLAGS' if it exists. I'm working on this right now. -- Alexandre Duret-Lutz ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: Convincing Automake to support libtool
Bob == Bob Friesenhahn [EMAIL PROTECTED] writes: Bob What I have now learned the hard way is that aclocal ignores the Bob AC_CONFIG_MACRO_DIR([m4]) definition in configure.ac. IMHO it's a bug in whatever let you think aclocal would honor AC_CONFIG_MACRO_DIR to way you thought. It certainly isn't the Automake manual. See also http://lists.gnu.org/archive/html/libtool-patches/2004-11/msg00097.html -- Alexandre Duret-Lutz ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: License of m4/ltoptions.m4
Paul == Paul Eggert [EMAIL PROTECTED] writes: [...] Paul Would you use the exact same wording in #2 that you Paul already uses in the aux scripts? Does that wording still Paul apply? I think so. Another idea would be to use a bison-like exception just to match the license of aclocal.m4: As a special exception to the GNU General Public License, when this file is copied by aclocal into an aclocal output file, you may use that output file without restriction. However this seems quite restrictive too me, as it wouldn't work if the file were m4_included (we don't do that for Automake macros anyway, but is that a reason to disallow it?) -- Alexandre Duret-Lutz ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: TODO
Bob == Bob Friesenhahn [EMAIL PROTECTED] writes: Bob On Wed, 10 Nov 2004, Alexandre Duret-Lutz wrote: [...] 1. install all programs and libraries without relinking (in random order) 2. relink everything (in random order) [...] Bob I don't believe that this would work since dependencies are inherited Bob at link time based on existing registered library dependencies. This Bob means that a library may link against a wrong library version, and the Bob error would propagate. Bob Automake can at least keep its part of the house in order by ensuring Bob the correct library install order within the same Makefile. It does Bob build the libraries in the correct order, assuming that LDADD has been Bob used properly. I'm afraid I'm lost. I understand these two paragraphs as 1. dependencies are inherited at link time 2. libraries are already built (hence linked) in the correct order So when are the incorrect dependencies registered? At relink-time? Can't those of link-time be used? Bob One approach which could be used is for libtool to support a mode Bob where it is provided with a list of all the .la files for libraries to Bob be installed, and libtool returns a re-ordered list which is ordered Bob by increasing dependency. Automake would then use this to order its Bob installation of libtool libraries. Efficient implementation of this Bob capability in bourne shell sounds quite challenging. Not only that, but also supporting a arbitrary installation order of libraries in multi-Makefile projects. -- Alexandre Duret-Lutz ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: License of m4/ltoptions.m4
Paul == Paul Eggert [EMAIL PROTECTED] writes: [...] Paul As a special exception to the GNU General Public License, if you Paul distribute this file as part of a package that uses the file as input Paul to GNU Autoconf, GNU Automake, or GNU Libtool, then you may distribute Paul the resulting output files under the same terms that you use for the Paul rest of the package. I don't understand the intent of as input to GNU Autoconf, GNU Automake, or GNU Libtool. AFAICT Libtool does not input m4 files, only the Autoconf tools and aclocal do. I assume input to GNU Automake means read by aclocal to produce aclocal.m4. If so this text seems to imply that you can distribute aclocal.m4 (with an embedded copy of python.m4) under your licensing term only if you also distribute python.m4 (which is under GPL). But there is another case which I'd like to support: the case where python.m4 is distributed aside to aclocal.m4, and aclocal.m4 simply does m4_include([m4/python.m4]). Then python.m4 is not a resulting output file of aclocal. And still we'd like to relax the GPL. As a special exception to the GNU General Public License, if you distribute this file as part of a package that uses the file (or any derived output) as input to generate its configuration script with Autoconf, then you may distribute the file and resulting output files under the same terms that you use for the rest of the package. configuration script generated by Autoconf is what the aux scripts already use. or any derived output is a lame attempt to allow tools such as aclocal (without singling out aclocal) to preprocess the file, as long as the intent is to build a configure script. -- Alexandre Duret-Lutz ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: TODO
Noah == Noah Misch [EMAIL PROTECTED] writes: Noah On Wed, Nov 10, 2004 at 01:17:19AM +0100, Alexandre Duret-Lutz wrote: - the relinking dependency debacle: For libtool to relink libraries when installing them, all dependencies must have been installed. However automake cannot pre-compute this installation order when it is run, and computing it at compile-time look overly complicated and error prone. Instead, would it make sense to support a two-stage Noah The core problem appears to be that an Automake-generated Noah Makefile.in uses dependencies when building installable Noah products but then installs them in destination_PRIMARY Noah batches without observing the dependencies it already Noah knows. Indeed, if Automake did not know the dependency Noah graph of each object, it could not build them reliably. Strictly speaking automake does not know these dependencies. It knows some dependencies, but because of the possibility to AC_SUBST variables for conditional linking, and doest not know exactly all of them (think libfoo_la_DEPENDENCIES = @SOME_LA@). However these dependencies are indeed known later at make time. In other word Makefile.in and Makefile.am do not have the necessary information to compute an installation order, but Makefile does. So yes, this order could be recorded during the build. Libtool already does that, doesn't it? If so it seems easier to get the dependencies from it. Noah If Automake generated an install target for installable Noah product, just as it generated a build target, would that Noah not solve this problem? This sounds appealing, but wouldn't this imply that if two libraries depends on another one, the later will be installed twice? -- Alexandre Duret-Lutz ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: License of m4/ltoptions.m4
Gary == Gary V Vaughan [EMAIL PROTECTED] writes: Gary Alexandre Duret-Lutz wrote: [...] I don't understand the intent of as input to GNU Autoconf, GNU Automake, or GNU Libtool. AFAICT Libtool does not input m4 files, only the Autoconf tools and aclocal do. Gary Just trying to cover all bases to avoid more pain for future autotools Gary versions. Note that libtoolize does actually read through aclocal.m4 Gary and any files it m4_includes to find a few directory paths and decide Gary whether to copy particular files. But none of the path you are looking for are specified in user files, not those we are considering. Also that argument would apply to Gettext as well, and maybe several other tools. We cannot list all of them and should not discriminate some of them. Gary The use of GNU Autoconf is to prevent someone creating their Gary own tool and calling that Autoconf to circumvent the license. I don't have a problem with GNU Autoconf, only GNU Libtool :) (And to some extent with GNU Automake too, but I can understand it in some way.) -- Alexandre Duret-Lutz ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: License of m4/ltoptions.m4
Paul == Paul Eggert [EMAIL PROTECTED] writes: [...] Paul As a special exception to the GNU General Public License, Paul if you distribute this file as part of a package that Paul automatically derives from this file a configuration Paul script (and perhaps some associated intermediate files), Paul then you may distribute this file and the derived files Paul for that purpose, under the same terms that you use for Paul the rest of the package. [...] President Eggert, you have my vote! -- Alexandre Duret-Lutz ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: License of m4/ltoptions.m4
Gary == Gary V Vaughan [EMAIL PROTECTED] writes: Gary Hi Ralf, Gary Ralf Wildenhues wrote: Hi Peter, * Peter Ekberg wrote on Tue, Nov 09, 2004 at 01:33:29PM CET: Hello! There is no exception from the GPL in m4/ltoptions.m4, like there is in the other lt*.m4 files in that directory. Is that an oversight or is this file only needed for backwards compatibility or something like that? Gary I based this file on m4/options.m4 in automake and copied the Gary license from there :-( The lack of exception is troubling, The copyright notices of Automake's m4/*.m4 files were added by Paul on 2001-09-22 (that was after the 1.5 release). It looks like the missing exception to the GPL is an omission nobody noticed so far. Before this change there was no boilerplate, and when the files were concatenated to form aclocal.m4, it was prepended with: | # aclocal.m4 generated automatically by aclocal 1.5 | | # Copyright 1996, 1997, 1998, 1999, 2000, 2001 | # Free Software Foundation, Inc. | # This file is free software; the Free Software Foundation | # gives unlimited permission to copy and/or distribute it, | # with or without modifications, as long as this notice is preserved. | | # This program is distributed in the hope that it will be useful, | # but WITHOUT ANY WARRANTY, to the extent permitted by law; without | # even the implied warranty of MERCHANTABILITY or FITNESS FOR A | # PARTICULAR PURPOSE. Today this copyright notice is still output in aclocal.m4, but it is followed by the copyright notices of all the files included. This sounds confusing since the top says unlimited permission to copy and distribute with or without modifications while the concatenated parts also include each a notice that state GPL. (*) I don't really know what to think about this. Some ideas: 1. prefix all the m4/*.m4 licenses with `##' so aclocal omit them from aclocal.m4 (leaving only the unlimited permission to ... license added by aclocal) 2. add an exception to all the m4/*.m4 files similar to that used in the aux scripts 3. both Now you may also consider what happens when third-party m4 macros (with custom licensing) are intermixed into aclocal.m4. (Seems another good reason to prefer setups with m4_include). (*) Amusingly, Automake's own aclocal.m4 is probably the only aclocal.m4 where there is no such confusion. -- Alexandre Duret-Lutz ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: TODO
There are also at least two hot points at the interface between automake and libtool that may need work on both sides. - unifying locks between libtool and compile - the relinking dependency debacle: For libtool to relink libraries when installing them, all dependencies must have been installed. However automake cannot pre-compute this installation order when it is run, and computing it at compile-time look overly complicated and error prone. Instead, would it make sense to support a two-stage install as follows: 1. install all programs and libraries without relinking (in random order) 2. relink everything (in random order) Would this work? (I think I already asked and the answer was no, but I cannot find that answer in the archive.) -- Alexandre Duret-Lutz ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
GNU Automake 1.9.3 released
We're pleased to announce the release of Automake 1.9.3. This is a bug-fix release, the list of bugs fixed is appended. You can find the new release here: ftp://ftp.gnu.org/gnu/automake/automake-1.9.3.tar.gz ftp://ftp.gnu.org/gnu/automake/automake-1.9.3.tar.gz.sig ftp://ftp.gnu.org/gnu/automake/automake-1.9.3.tar.bz2 ftp://ftp.gnu.org/gnu/automake/automake-1.9.3.tar.bz2.sig ftp://sources.redhat.com/pub/automake/automake-1.9.3.tar.gz ftp://sources.redhat.com/pub/automake/automake-1.9.3.tar.gz.sig ftp://sources.redhat.com/pub/automake/automake-1.9.3.tar.bz2 ftp://sources.redhat.com/pub/automake/automake-1.9.3.tar.bz2.sig Soon it will also appear on the sources and GNU mirrors listed here: http://www.gnu.org/order/ftp.html http://sources.redhat.com/mirrors.html Finally, here are the MD5 checksums: 0ee08fb0ee48d20a4f8da99137340efd automake-1.9.3.tar.bz2 32d6ed7d94e3364bff23d1f80e8af2a6 automake-1.9.3.tar.gz Please report bugs to [EMAIL PROTECTED]. Bugs fixed in 1.9.3: * Bug introduced by 1.9: - Dependency tracking using mode dashmstdout or dashXmstdout did not work for libtool objects compiled with --tag (i.e., compiled with Libtool 1.5 or later). The compilation would succeed, but `depcomp' would emit a warning and not output any dependency information. * Long standing bugs: - Ignore comments from augmented variables, so that FOO = foo # bar FOO += baz no longer results in `FOO = foo # bar baz'. - `install-sh -d a/b/' failed to create `a/b/' because of the trailing `/'. - _PROGRAMS now always create programs. Before 1.9 it would mistakenly create a libtool library if the name of the program ended in `.la'. Between 1.9 and 1.9.2 a program with such a name would fail to build because half the code was assuming a program was being built, while the other half was considering a library... - `compile' now handles `*.obj' objects. - `aclocal' recognizes AC_DEFUN_ONCE. * Noteworthy manual updates: - LIBOBJS: more documentation and an example setup. - Libtool Convenience Libraries: show how to force the linker selection. - Extending: more comments about install-data-hook vs install-exec-hook. - Clean: document -local targets. pgprUIvIqtUn5.pgp Description: PGP signature ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: compile problem
Gary == Gary V Vaughan [EMAIL PROTECTED] writes: Gary But for a project built with `make -j', we still need AM_PROG_CC_C_O Gary and _LT_COMPILER_C_O to understand each others' locks :-( Seems so. I thought it was not needed because when AM_PROG_CC_C_O decides `compile' is required, it is also used when compiling libtool objects. However perhaps I was wrong, because `compile' does something only for *.o and *.obj files, it is a no-op for *.lo files. Maybe we need to tell AM_PROG_CC_C_O about *.lo files. To makes matter worse, because AM_PROG_CC_C_O horribly overwrites CC, it's not clear to me whether AM_PROG_CC_C_O LT_INIT is equivalent to LT_INIT AM_PROG_CC_C_O It looks like Libtool's `-c -o' check would not give the same answer. I haven't dug all this; I think Ralf W sent some mail about it, but I haven't flushed all my mails yet. I agree it would be better to set down a common lock scheme, although that really should not hold any release. -- Alexandre Duret-Lutz ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: compile problem
Gary == Gary V Vaughan [EMAIL PROTECTED] writes: [...] Gary I'm not saying that the compile script should be used, Gary just that the tests to determine whether it might be Gary needed are run as a matter of course. Looking at the Gary implementation of AM_PROG_CC_C_O, I see that it would Gary need a bit of refactoring to make that happen... Yeah. Presently you need `compile' if you use the macro, and people mind about extra useless scripts. Gary My feeling at the moment is that it would be a small price to pay for Gary simplifying the interface to automake (i.e. _not_ being sometimes told, Gary partway through the automake run, that you must change your configure.ac Gary and start again at the aclocal stage). I agree that being told to update configure.ac can be annoying, even if it only occur once, but I'm not convinced that we should call such macros unconditionally. By this argument it looks like we should also always run AC_INIT_LIBTOOL so that Automake does not demand it once you introduce the first variable _LTLIBRARIES variable in a Makfile.am. Likewise for AC_PROG_YACC, AC_PROG_RANLIB, etc. I once thought that since Automake knew what extra macros where required, it could generate a configure.ac fragment with these. But that sounds too fragile and tricky. -- Alexandre Duret-Lutz ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
GNU Automake 1.9.2 released (10th anniversary release)
We're pleased to announce the release of Automake 1.9.2. This is a small bug-fix release (the list of bugs fixed is appended), and this is also an anniversary release. Automake was started on 1994-09-19 so it has 10 years today. To celebrate this the manual has been augmented with a History chapter that tries to go through these 10 years. You can find the new release here: ftp://ftp.gnu.org/gnu/automake/automake-1.9.2.tar.gz ftp://ftp.gnu.org/gnu/automake/automake-1.9.2.tar.gz.sig ftp://ftp.gnu.org/gnu/automake/automake-1.9.2.tar.bz2 ftp://ftp.gnu.org/gnu/automake/automake-1.9.2.tar.bz2.sig ftp://sources.redhat.com/pub/automake/automake-1.9.2.tar.gz ftp://sources.redhat.com/pub/automake/automake-1.9.2.tar.gz.sig ftp://sources.redhat.com/pub/automake/automake-1.9.2.tar.bz2 ftp://sources.redhat.com/pub/automake/automake-1.9.2.tar.bz2.sig Soon it will also appear on the sources and GNU mirrors listed here: http://www.gnu.org/order/ftp.html http://sources.redhat.com/mirrors.html Finally, here are the MD5 checksums: b5799f983d0a062ec59810f6b289cd27 automake-1.9.2.tar.bz2 6f874b649fc3bbe8c54e7592f6fb2d10 automake-1.9.2.tar.gz Please report bugs to [EMAIL PROTECTED]. Bugs fixed in 1.9.2: * Sort rm commands output for mostlyclean-generic, clean-generic, distclean-generic and maintainer-clean-generic, so that the produced Makefile is not sensible to the way Perl sorts its hashes. * Support `+' in the name of directories given to `include'. * Preserve spaces in the arguments of `compile'. * `missing' will no longer try to emulate a tool that is run with `--version' or `--help' as argument. * Noteworthy manual update: - There is a new chapter about the history of Automake. pgpffXTDNhc6x.pgp Description: PGP signature ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: compile problem
Gary == Gary V Vaughan [EMAIL PROTECTED] writes: [...] Gary So does that simply mean that libtool objects can be correctly built Gary as subdir-objects without AM_PROG_CC_C_O? Sorry to bug you, just Gary making sure I understand why you made the patch the way you did... The purpose of AM_PROG_CC_C_O is to replace CC by the `compile' script which emulates a compiler that supports `-c -o' when the real CC does not. As you pointed out, libtool already supplies such emulation, so `compile' is never needed when compiling lo files. [...] Gary Meant to ask, why doesn't AM_INIT_AUTOMAKE (conditionally if Gary necessary) simply invoke AM_PROG_CC_C_O? We know it's needed only after processing the Makefile.am files. -- Alexandre Duret-Lutz ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
GNU Automake 1.9.1 released
We're pleased to announce the release of Automake 1.9.1. This is a tiny bug-fix release motivated by (1) the Debian GNU/Linux freeze, and (2) a three-week vacation starting in a couple of days :) The list of bug fixes is appended; we have not yet heard about regressions introduced by 1.9. You can find the new release here: ftp://ftp.gnu.org/gnu/automake/automake-1.9.1.tar.gz ftp://ftp.gnu.org/gnu/automake/automake-1.9.1.tar.gz.sig ftp://ftp.gnu.org/gnu/automake/automake-1.9.1.tar.bz2 ftp://ftp.gnu.org/gnu/automake/automake-1.9.1.tar.bz2.sig ftp://sources.redhat.com/pub/automake/automake-1.9.1.tar.gz ftp://sources.redhat.com/pub/automake/automake-1.9.1.tar.gz.sig ftp://sources.redhat.com/pub/automake/automake-1.9.1.tar.bz2 ftp://sources.redhat.com/pub/automake/automake-1.9.1.tar.bz2.sig Soon it will also appear on the sources and GNU mirrors listed here: http://www.gnu.org/order/ftp.html http://sources.redhat.com/mirrors.html Finally, here are the MD5 checksums: eb65202d00d498c8b0729110ee2d4d51 automake-1.9.1.tar.gz 65143af82931c2c4d703d3a17c1c9d15 automake-1.9.1.tar.bz2 Please report bugs to [EMAIL PROTECTED]. Bugs fixed in 1.9.1: This release fixes three longstanding bugs. * Adjust #line directives in `parser.h' (when ylwrap is not used). (PR/432) * Fix definition of YLWRAP when ylwrap is installed in a default aux directory found in a parent package. * Properly recognize AC_CANONICAL_BUILD and AC_CANONICAL_TARGET. pgpBkuBFB6Z4W.pgp Description: PGP signature ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: ltmain.sh
Gary == Gary V Vaughan [EMAIL PROTECTED] writes: [...] Gary I think that what we *really* need is for automake to not Gary assume ltmain.sh is in the source tree, and some way for Gary the libtool Makefile.am to declare that config/ltmain.sh Gary is a built file so that automake doesn't keep stopping Gary before it is built without the horrible bootstrap $fakes Gary hack. Two answers: short-term, and long-term. short-term: IMHO you are swimming against the stream, that's why it looks hard. Consider the following: Automake wants to distribute that file? So let's distribute it. The file is distributed? So let's update it in the source tree. The file is expected to be identical for all users installing the same revision of libtool? So let's not build it from ./configure (you should not do this for a distributed file anyway): have it created by bootstrap and write a custom Makefile rule that updates the file whenever configure.ac changes. This way you meet Automake expectations and never have to lie to it, so things should work as expected. The drawback is that you'll waste a few kilobytes, but I don't think the economy is worth the irritation one gets debugging clumsy hacks. Automake has a similar issue with its m4/amversion.m4 file. It must be generated from m4/amversion.in, but it's also a prerequisite to run autoconf. The setup is similar to the one I suggest above (except the rebuild rule does not depend on configure.ac because a bootstrap is needed anyway). long-term: To reduce the amount of hard-coded knowledge in Automake, I'd like to introduce a macro, say AM_REQUIRE_AUX_FILE, so that third-party Autoconf macros can instruct automake to 1. check that the files they need are present, 2. distribute them. Libtool could be equipped with m4_ifdef([A][M_REQUIRE_AUX_FILE], [A][M_REQUIRE_AUX_FILE([ltmain.sh])]) and the hard coded test removed from Automake. Then it seems it would not be too difficult to disable the above line in libtool itself, so that Automake never bothers about ltmain.sh. [...] Gary Rerunning autoreconf -fvi on all 8 test/*demo* trees and Gary the libtool source tree proper after every cvs update and Gary commit takes about 30 minutes on my high end Mac, and up Gary to an hour for some of our other developers :-( Does it? Running ./bootstrap takes 8 minutes on my poor PC. -- Alexandre Duret-Lutz ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
GNU Automake 1.9 released
We're pleased to announce the release of Automake 1.9. This release contains many bug fixes and improvements, but not as much as in previous major releases. The NEWS entry is appended. Thanks to all people who have been testing pre-release, reporting bugs, contributing code, suggesting enhancements, and answering user questions on the mailing lists. You can find the new release here: ftp://ftp.gnu.org/gnu/automake/automake-1.9.tar.gz ftp://ftp.gnu.org/gnu/automake/automake-1.9.tar.gz.sig ftp://ftp.gnu.org/gnu/automake/automake-1.9.tar.bz2 ftp://ftp.gnu.org/gnu/automake/automake-1.9.tar.bz2.sig ftp://sources.redhat.com/pub/automake/automake-1.9.tar.gz ftp://sources.redhat.com/pub/automake/automake-1.9.tar.gz.sig ftp://sources.redhat.com/pub/automake/automake-1.9.tar.bz2 ftp://sources.redhat.com/pub/automake/automake-1.9.tar.bz2.sig Soon it will also appear on the sources and GNU mirrors which are listed here: http://www.gnu.org/order/ftp.html http://sources.redhat.com/mirrors.html Finally, here are the MD5 checksums: c0b6434087e3be0606ef9d172238f26c automake-1.9.tar.bz2 8398de9b2100d3cb1c94f5cd29166b5d automake-1.9.tar.gz Please report bugs by mail to [EMAIL PROTECTED], or at http://sources.redhat.com/cgi-bin/gnatsweb.pl?database=automake New in 1.9: * Makefile.in bloat reduction: - Inference rules are used to compile sources in subdirectories when the `subdir-objects' option is used and no per-target flags are used. This should reduce the size of some projects a lot, because Automake used to output an explicit rule for each such object in the past. - Automake no longer outputs three rules (.o, .obj, .lo) for each object that must be built with explicit rules. It just outputs the rules required to build the kind of object considered: either the two .o and .obj rules for usual objects, or the .lo rule for libtool objects. * Change to Libtool support: - Libtool tags are used with libtool versions that support them. (I.e., with Libtool 1.5 or greater.) - Automake is now able to handle setups where a libtool library is conditionally installed in different directories, as in if COND lib_LTLIBRARIES = liba.la else pkglib_LTLIBRARIES = liba.la endif liba_la_SOURCES = ... * Changes to aclocal: - aclocal now ensures that AC_DEFUNs and AU_DEFUNs it discovers are really evaluated, before it decides to include them in aclocal.m4. This solves nasty problems with conditional redefinitions of Autoconf macros in /usr/share/aclocal/*.m4 files causing extraneous *.m4 files to be included in any project using these macros. (Calls to AC_PROG_EGREP causing libtool.m4 to be included is the most famous instance of this bug.) - Do not complain about missing conditionally AC_REQUIREd macros that are not actually used. In 1.8.x aclocal would correctly determine which of these macros were really needed (and include only these in the package); unfortunately it would also require all of them to be present in order to run. This created situations were aclocal would not work on a tarball distributing all the macros it uses. For instance running aclocal on a project containing only the subset of the Gettext macros in use by the project did not work, because gettext conditionally requires other macros. * Portability improvements: - Tar format can be chosen with the new options tar-v7, tar-ustar, and tar-pax. The new option filename-length-max=99 helps diagnosing filenames that are too long for tar-v7. (PR/414) - Variables aumented with `+=' are now automatically flattened (i.e., trailing backslashes removed) and then wrapped around 80 colummns (adding trailing backslashes). In previous versions, a long series of VAR += value1 VAR += value2 VAR += value3 ... would result in a single-line definition of VAR that could possibly exceed the maximum line length of some make implementations. Non-augmented variables are still output as they are defined in the Makefile.am. * Miscellaneous: - Support Fortran 90/95 with the new fc and ppfc languages. Works the same as the old Fortran 77 implementation; just replace F77 with FC everywhere (exception: FFLAGS becomes FCFLAGS). Requires a version of autoconf which provides AC_PROG_FC (=2.59). - Support for conditional _LISP. - Support for conditional -hook and -local rules (PR/428). - Diagnose AC_CONFIG_AUX_DIR calls following AM_INIT_AUTOMAKE. (PR/49) - Automake will not write any Makefile.ins after the first error it encounters. The previous Makefile.ins (if any) will be left in place. (Warnings will not prevent output, but remember they can be turned into errors with -Werror.) - The restriction that SUBDIRS must contain direct children is gone. Do not abuse.
Automake 1.8d uploaded (release candidate for Automake 1.9)
Hi people, This is a release candidate for Automake 1.9. If you have some time, please help us tracking down bugs by trying this beta with your packages and reporting any issue you encounter. Especially, please shout loud if your package works with 1.8.5 but does not with 1.8d. I plan to release 1.9 before the end of the month if no important regression is reported. ** Please report bugs to [EMAIL PROTECTED]. ** You can find this beta here: ftp://alpha.gnu.org/gnu/automake/automake-1.8d.tar.gz ftp://alpha.gnu.org/gnu/automake/automake-1.8d.tar.gz.sig ftp://alpha.gnu.org/gnu/automake/automake-1.8d.tar.bz2 ftp://alpha.gnu.org/gnu/automake/automake-1.8d.tar.bz2.sig Here are the MD5 sums: e1ce2805bbe4338b9e2a7107a51af7c4 automake-1.8d.tar.bz2 dd98fe7c2ea013d0ffc29ebb94086b4c automake-1.8d.tar.gz New between 1.8.5 and 1.8d: * Makefile.in bloat reduction: - Inference rules are used to compile sources in subdirectories when the `subdir-objects' option is used and no per-target flags are used. This should reduce the size of some projects a lot, because Automake used to output an explicit rule for each such object in the past. - Automake no longer outputs three rules (.o, .obj, .lo) for each object that must be built with explicit rules. It just outputs the rules required to build the kind of object considered: either the two .o and .obj rules for usual objects, or the .lo rule for libtool objects. * Change to Libtool support: - Libtool tags are used with libtool versions that support them. (I.e., with Libtool 1.5 or greater.) - Automake is now able to handle setups where a libtool library is conditionally installed in different directories, as in if COND lib_LTLIBRARIES = liba.la else pkglib_LTLIBRARIES = liba.la endif liba_la_SOURCES = ... * Changes to aclocal: - aclocal now ensures that AC_DEFUNs and AU_DEFUNs it discovers are really evaluated, before it decides to include them in aclocal.m4. This solves nasty problems with conditional redefinitions of Autoconf macros in /usr/share/aclocal/*.m4 files causing extraneous *.m4 files to be included in any project using these macros. (Calls to AC_PROG_EGREP causing libtool.m4 to be included is the most famous instance of this bug.) - Do not complain about missing conditionally AC_REQUIREd macros that are not actually used. In 1.8.x aclocal would correctly determine which of these macros were really needed (and include only these in the package); unfortunately it would also require all of them to be present in order to run. This created situations were aclocal would not work on a tarball distributing all the macros it uses. For instance running aclocal on a project containing only the subset of the Gettext macros in use by the project did not work, because gettext conditionally requires other macros. * Portability improvements: - Tar format can be chosen with the new options tar-v7, tar-ustar, and tar-pax. The new option filename-length-max=99 helps diagnosing filenames that are too long for tar-v7. (PR/414) - Variables aumented with `+=' are now automatically flattened (i.e., trailing backslashes removed) and then wrapped around 80 colummns (adding trailing backslashes). In previous versions, a long series of VAR += value1 VAR += value2 VAR += value3 ... would result in a single-line definition of VAR that could possibly exceed the maximum line length of some make implementations. Non-augmented variables are still output as they are defined in the Makefile.am. * Miscellaneous: - Support Fortran 90/95 with the new fc and ppfc languages. Works the same as the old Fortran 77 implementation; just replace F77 with FC everywhere (exception: FFLAGS becomes FCFLAGS). Requires a version of autoconf which provides AC_PROG_FC (=2.59). - Support for conditional _LISP. - Support for conditional -hook and -local rules (PR/428). - Diagnose AC_CONFIG_AUX_DIR calls following AM_INIT_AUTOMAKE. (PR/49) - Automake will not write any Makefile.ins after the first error it encounters. The previous Makefile.ins (if any) will be left in place. (Warnings will not prevent output, but remember they can be turned into errors with -Werror.) - The restriction that SUBDIRS must contain direct children is gone. Do not abuse. - The manual tells more about SUBDIRS vs. DIST_SUBDIRS. It also gives an example of nested packages using AC_CONFIG_SUBDIRS. pgpnHd7zYUu4d.pgp Description: PGP signature ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: Why doesn't ...
Gary == Gary V Vaughan [EMAIL PROTECTED] writes: [...] Gary FYI: I've made CVS libtoolize take its files from $aclocaldir again. Great! Thanks for doing this. Does it also handle the case where AC_CONFIG_MACRO_DIR isn't used? libtoolize used to install all the m4 files in the top-level directory, although nothing will read them here. -- Alexandre Duret-Lutz ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: about libtool's trace interface for tags
Scott == Scott James Remnant [EMAIL PROTECTED] writes: Scott On Wed, 2004-04-14 at 18:45, Alexandre Duret-Lutz wrote: Ah, thanks! Sorry for being dense, but since it takes tag names as argument, why is it called _LT_LANG? Scott Because it actually takes language configuration names, which just Scott happen to be the same as the tags that get generated. (There's a patch Scott floating around by me that breaks that assumption.) Sorry for the delay. Sorry also if this mail look uselessly long and finicky, but I am really confused and worried by your last comment. I must also precise I'm not reading everything on libtool@ and libtool-patches@, so I'm not aware of all the latest developments and patches floating around. Obviously my vocabulary is also out of date :) What is the difference between a tag name a language configuration name a language name an internal name ? So far I had been assuming that there was only to sort of names: language names (passed as argument to LT_LANG), and tag names (passed as arguments to --tag=). What exactly is the assumption that you'll break? The arguments passed to _LT_LANG will not always be tag names? If so I'm afraid Automake cannot use this macro. (See below.) How about calling it `LT_SUPPORTED_TAG' or something similar? I can supply a patch to rename and document this macro in the manual, if that sounds OK. I really think that this interface should be public, like every other traced macros (at least all those registered in autom4te.cfg). Scott Because it isn't public ... Call it a storm-resistant interface for third-party tools :) Scott LT_LANG is the public-facing version of this macro, Scott which takes friendly names like 'C++' and 'Fortran Scott 77'. It then calls _LT_LANG with the internal name, Scott which is the most convenient trace point for you. I don't want Automake to rely on anything internal to Libtool. This is not a safe road. If Libtool use some *internal* names, Automake should not rely on them. I couldn't find the documentation for libtool's --tag=TAG option, by I'm assuming it's a public option. It's list of allowed argument is therefore something public too. I will call these arguments tags. In order to generate Makefiles, Automake needs to know what language libtool has been configured for, and the corresponding tags to pass to the --tag option. So far I have been assuming that there would be a macro to trace that would return a list of enabled tags. I have also been assuming that the set of possible tags returned by this macro was constant (more precisely adding tags for new language is OK, but renaming the tag of an existing language is not). Automake knows these tags (these are public so it's ok) and can make the correspondence with the languages it supports. In other words, automake traces tags and uses these both as arguments to --tag and as unique identifier for languages. I your first statement implies that the tags will be renamed into language configuration names, then we must work out a more complex interface. Something that return pairs of (unique-language-id, tags) for instance. I hope we won't have to do this, though. Scott The trouble with making public macros is people will Scott tend to put them in their configure.ac, no matter how Scott large the instruction telling them not to. But you don't need to describe it as a macro if you prefer. For instance in the documentation for the --tag=TAG option there will likely be a list of allowed tags, and it would sound appropriate to state something like: It is sometimes helpful to query the list of tags configured in a package from a script or some automated tool. This can be done using `autoconf --trace LT_SUPPORTED_TAG=\$1'. Or something along these lines. Personally I would find more natural to have a `Tracing Interface' node listing all such macros of interest. Even if there is only one macro for now, this will make room for future additions, and clearly state what macro it is OK to trace (so that you don't have to care about people that abusively trace the inner guts of Libtool). I don't think people will monkeyly copy random documented macros to their configure.ac to see how they help breaking their package; but if they do, it's really their problem. Monkeys should not hinder the development of useful features :) -- Alexandre Duret-Lutz ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: about libtool's trace interface for tags
Scott == Scott James Remnant [EMAIL PROTECTED] writes: Scott On Tue, 2004-04-13 at 22:39, Alexandre Duret-Lutz wrote: Is it done or is there any obstacle to it? I'm dreaming about Automake 1.9, and if possible I would like to include support for this. Scott The current interface should be pretty good, trace for Scott invocations of _LT_TAG and the first argument will be a Scott tag name that maps equally to a language name (CC, CXX, Scott F77, etc.) Huh? ~/projs/cvs/libtool % autoconf --trace _LT_TAG configure.ac:199:_LT_TAG: configure.ac:199:_LT_TAG: configure.ac:199:_LT_TAG: configure.ac:199:_LT_TAG: configure.ac:199:_LT_TAG: configure.ac:199:_LT_TAG: configure.ac:199:_LT_TAG: configure.ac:199:_LT_TAG: configure.ac:199:_LT_TAG: -- Alexandre Duret-Lutz ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: about libtool's trace interface for tags
Scott == Scott James Remnant [EMAIL PROTECTED] writes: Scott On Wed, 2004-04-14 at 08:00, Alexandre Duret-Lutz wrote: Scott == Scott James Remnant [EMAIL PROTECTED] writes: Scott On Tue, 2004-04-13 at 22:39, Alexandre Duret-Lutz wrote: Is it done or is there any obstacle to it? I'm dreaming about Automake 1.9, and if possible I would like to include support for this. Scott The current interface should be pretty good, trace for Scott invocations of _LT_TAG and the first argument will be a Scott tag name that maps equally to a language name (CC, CXX, Scott F77, etc.) Huh? Scott Sorry, I'll put my brain on this time ... :o) Scott * _LT_LANG * Scott descent libtool-bootstrap% autoconf --trace=_LT_LANG Scott configure.ac:178:_LT_LANG:CXX Scott configure.ac:178:_LT_LANG:GCJ Scott configure.ac:178:_LT_LANG:F77 Scott configure.ac:178:_LT_LANG:RC Ah, thanks! Sorry for being dense, but since it takes tag names as argument, why is it called _LT_LANG? How about calling it `LT_SUPPORTED_TAG' or something similar? I can supply a patch to rename and document this macro in the manual, if that sounds OK. I really think that this interface should be public, like every other traced macros (at least all those registered in autom4te.cfg). -- Alexandre Duret-Lutz ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
about libtool's trace interface for tags
Is it done or is there any obstacle to it? I'm dreaming about Automake 1.9, and if possible I would like to include support for this. All we need is a (preferably documented) way to --trace for the list of tags that will be understood by the configure-generated libtool script. (I think it would make sense to document it because it might be useful to other tools, and this will likely reduce the odds of breakages, e.g., when renaming internal symbols.) -- Alexandre Duret-Lutz ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: multi part library?
Ralph == Ralph Schleicher [EMAIL PROTECTED] writes: Ralph I've sent Andreas an example project by email Ralph demonstrating the proper use of Automake and Libtool for Ralph his case. For future people reaching this thread in the archive and seeking up-to-date information, I'd like to point out that the keywords to grep the documentations for are convenience library. The Automake manual has a full section entitled `Libtool Convenience Libraries', and the Libtool manual mentions convenience libraries in a few paragraphs too. -- Alexandre Duret-Lutz ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Why doesn't ...
Scott == Scott James Remnant [EMAIL PROTECTED] writes:
Scott On Thu, 2004-02-05 at 03:40, name wrote:
Why doesn't installation copy libtool.m4 to aclocal?
Scott Assuming you are talking about CVS HEAD (libtool 1.5a, future 1.6
Scott release) this is because libtoolize now copies libtool.m4 from its own
Scott data directory into your macro directory.
[...]
Scott This is consistent with The Future of `aclocal' as outlined in the
Scott Automake manual chapter of the same title.
I know you are just explaining the libtoolize behavior with
this sentence, but I fear that some people might read it as a
justification for not putting things into /usr/share/aclocal/.
I'm installing the following patch on automake HEAD and
branch-1-8 to make things clearer.
Changing libtoolize to install libtool.m4 locally is a great
step, but it seems it would work as well if libtool.m4 was taken
from /usr/share/aclocal/. Moving it away might be too harsh for
users. AFAICT the real advantage with putting libtool.m4 out of
the way, is that it helps ./bootstrap to cope with the
shortcomings of the current aclocal implementation...
BTW, the conditionally defined AC_PROG_EGREP debacle (replace
AC_PROG_EGREP by any Autoconf macro) should not exist with the
replacement machinery Akim plotted, since AC_DEFUNs would be
traced instead of being hastily grepped. Actually I think this
part of the plot could be implemented now (i.e., in am-1.9)
easily. I'll try to look at it.
Scott The great advantage of this is that it ensures that
Scott libtool.m4 and ltmain.sh are matched versions, running
Scott libtoolize and forgetting to run aclocal, or the
Scott reverse, used to be the source of many developer's woes
Scott in the past.
Good point. I wonder if you'll have more complaints about
mismatched versions or about missing libtool.m4 (not meaning to
be flip, I don't read bug-libtool so I don't know how frequent
the version mismatch problem is, but the missing libtool.m4
problem seems to be quite popular already before the release).
Another way to ensure matching versions would be to turn
ltmain.sh into an m4 macro. (I wouldn't have dared suggesting
that if someone didn't already. I think it was Gary. Please
move the bazooka over him :))
2004-02-03 Alexandre Duret-Lutz [EMAIL PROTECTED]
* doc/automake.texi (Future of aclocal): Make clearer that
it's ok to install macros into /usr/share/aclocal/.
Index: doc/automake.texi
===
RCS file: /cvs/automake/automake/doc/automake.texi,v
retrieving revision 1.27
diff -u -r1.27 automake.texi
--- doc/automake.texi 1 Feb 2004 16:28:50 - 1.27
+++ doc/automake.texi 3 Feb 2004 22:05:44 -
@@ -2088,8 +2088,9 @@
The new implementation will probably be done slightly differently.
For instance it could enforce the @file{m4/}-style layout discussed in
[EMAIL PROTECTED] Macros}, and take care of copying (or even updating)
-third-party macro into this directory.
[EMAIL PROTECTED] Macros}, and take care of copying (and even updating)
+third-party macros from @file{/usr/share/aclocal/} into the local
[EMAIL PROTECTED]/} directory.
We have no idea when and how this will happen. This has been
discussed several times in the past, but someone still has to commit
@@ -2115,6 +2116,13 @@
should simplify its logic a lot (less things to maintain, yum!), it's
even likely you will not need the script anymore, and more to the point
you will not call @command{aclocal} directly anymore.
+
+For the time being, third-party packages should continue to install
+public macros into @code{/usr/share/aclocal/}. If @command{aclocal}
+is replaced by another tool it might make sense to rename the
+directory, but supporting @code{/usr/share/aclocal/} for backward
+compatibility should be really easy provided all macros are properly
+written (@pxref{Extending aclocal}).
@node Top level
--
Alexandre Duret-Lutz
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: libtool macros installed in pkgdatadir?
Braden == Braden McDaniel [EMAIL PROTECTED] writes: [...] Braden Right... But aclocal pulls them from a standard location on the Braden system. While this means the distribution may be colored by Braden characteristics of the system where it's built, it does mean that in Braden general package maintainers aren't responsible for maintaining the Braden macros they're using. Yes. The maintenance argument applies better to custom macros (e.g., maintaining acinclude.m4 is a pain). However lumping everything in aclocal.m4, also means users or developers cannot rebuild aclocal.m4 unless they have the macro installed. It don't happen if the macro is separately distributed. The `Local Macros' node of the Automake 1.8 manual discusses both issues. [...] Braden What I *am* concerned with is the prospect of having manually to copy Braden the file with PKG_CHECK_MODULES (for instance) to my project's Braden directories each time the system pkg-config is upgraded in order to Braden ensure parity. I'm also concerned that other users of my project's CVS Braden repository would have to do the same. Pushing my PKG_CHECK_MODULES Braden into my CVS repository is not a solution, as there may be a version Braden mismatch with the version of pkg-config on another user's system. The plan is to have this copy performed automatically by the aclocal replacement. As aclocal is slowly moving towards its replacement (which cannot exist yet because it requires M4 support), a next aclocal version may even include a --copy or --update option to try this behavior. Anyway, the point is that you should not fear this. Installing third-party macros in /usr/share/aclocal will continue to work. -- Alexandre Duret-Lutz ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Library dependencies make install
Bob == Bob Friesenhahn [EMAIL PROTECTED] writes: [...] Bob libraries are installed in the same order as specified by Bob lib_LTLIBRARIES. If the ordering of lib_LTLIBRARIES does Bob not jive with the library dependency order, then libtool Bob fails to re-link the library because some libraries it Bob depends are not installed yet. Even worse, it may appear Bob that installation is successful, but some of the libraries Bob are accidentally linked with older versions of the Bob libraries which were already installed. Bob It seems to me that Automake should compute an optimum library Bob installation order based on the specified libtool library (.la) Bob dependencies. This would help ensure that installation errors do not Bob occur due to some hap-hazard lib_LTLIBRARIES list order (e.g. they Bob could be in alphabetical order). It's not clear to me how circular dependencies would be handled. Also, I don't know how this order can be computed when all these libraries are built into many directories. Another idea is to split the installation procedure in two steps: copy all libraries, and once it is done relink all libraries. Would that work? If so, we need a way to tell libtool to copy libraries without relinking. -- Alexandre Duret-Lutz ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: using --tag=XXX in automake-generated rules
adl == Alexandre Duret-Lutz [EMAIL PROTECTED] writes: [...] adl 2004-01-02 Alexandre Duret-Lutz [EMAIL PROTECTED] adl Fix for PR automake/289: adl * automake.in (Automake::Struct::libtool_tag): New attribute. Define adl it for the language that have a Libtool tag. adl (%libtool_tags): New variable. adl (handle_languages, define_compiler_variable) adl (define_linker_variable): Pass --tag=XXX to libtool if supported. adl (scan_autoconf_traces): Scan for _LT_AC_TAGCONFIG and AC_LIBTOOL_TAGS. adl * tests/libtool3.test, tests/subobj9.test: Check that --tag=XXX is adl output. I'm installing this. -- Alexandre Duret-Lutz ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
using --tag=XXX in automake-generated rules (Was: Re: 'ccache gcc' as compiler with libtool)
Gary == Gary V Vaughan [EMAIL PROTECTED] writes:
[...about Automake passing --tag=XXX to libtool...]
Gary Alexandre Duret-Lutz wrote:
How can automake determine whether the version of libtool used in
a package supports --tag ?
[...]
Gary _LT_AC_TAGCONFIG exists in branch-1-5 and HEAD.
Not quite. branch-1-5 has _LT_AC_TAGCONFIG but HEAD has _LT_AC_TAG_CONFIG.
I prefer to rely on AC_LIBTOOL_TAGS, because this macro supplies
a list of supported tags (either the tags supplied by the users,
or the default list of tags). Is this OK with you?
Below is the implementation I propose, it traces both
_LT_AC_TAG_CONFIG for Libtool 1.5 and AC_LIBTOOL_TAGS for newer
versions.
BTW currently the --tag option and the AC_LIBTOOL_TAGS macro are
not documented in the Libtool manual.
2004-01-02 Alexandre Duret-Lutz [EMAIL PROTECTED]
Fix for PR automake/289:
* automake.in (Automake::Struct::libtool_tag): New attribute. Define
it for the language that have a Libtool tag.
(%libtool_tags): New variable.
(handle_languages, define_compiler_variable)
(define_linker_variable): Pass --tag=XXX to libtool if supported.
(scan_autoconf_traces): Scan for _LT_AC_TAGCONFIG and AC_LIBTOOL_TAGS.
* tests/libtool3.test, tests/subobj9.test: Check that --tag=XXX are
output.
Index: NEWS
===
RCS file: /cvs/automake/automake/NEWS,v
retrieving revision 1.260
diff -u -r1.260 NEWS
--- NEWS1 Jan 2004 18:54:20 - 1.260
+++ NEWS2 Jan 2004 18:37:17 -
@@ -1,5 +1,8 @@
New in 1.8a:
+* Libtool tags are used with libtool versions that support it.
+ (I.e., with Libtool 1.5 or greater.)
+
* Makefile.in bloat reduction.
- Inference rules are used to compile sources in subdirectories when
Index: automake.in
===
RCS file: /cvs/automake/automake/automake.in,v
retrieving revision 1.1533
diff -u -r1.1533 automake.in
--- automake.in 1 Jan 2004 21:57:23 - 1.1533
+++ automake.in 2 Jan 2004 18:37:21 -
@@ -76,6 +76,9 @@
# (defaults to [])
'flags' = @,
+ # Any tag to pass to libtool while compiling.
+ 'libtool_tag' = \$,
+
# The file to use when generating rules for this language.
# The default is 'depend2'.
'rule_file' = \$,
@@ -332,6 +335,9 @@
# Where AM_GNU_GETTEXT appears.
my $ac_gettext_location;
+# Lists of tags supported by Libtool.
+my %libtool_tags = ();
+
# TRUE if we've seen AC_CANONICAL_(HOST|SYSTEM).
my $seen_canonical = 0;
my $canonical_location;
@@ -663,6 +669,7 @@
'linker' = 'LINK',
'link' = '$(CCLD) $(AM_CFLAGS) $(CFLAGS) $(AM_LDFLAGS) $(LDFLAGS)
-o $@',
'compile_flag' = '-c',
+ 'libtool_tag' = 'CC',
'extensions' = ['.c'],
'_finish' = \lang_c_finish);
@@ -678,6 +685,7 @@
'compiler' = 'CXXCOMPILE',
'compile_flag' = '-c',
'output_flag' = '-o',
+ 'libtool_tag' = 'CXX',
'lder' = 'CXXLD',
'ld' = '$(CXX)',
'pure' = 1,
@@ -788,6 +796,7 @@
'compiler' = 'F77COMPILE',
'compile_flag' = '-c',
'output_flag' = '-o',
+ 'libtool_tag' = 'F77',
'lder' = 'F77LD',
'ld' = '$(F77)',
'pure' = 1,
@@ -820,6 +829,7 @@
'compile' = '$(F77) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES)
$(AM_CPPFLAGS) $(CPPFLAGS) $(AM_FFLAGS) $(FFLAGS)',
'compile_flag' = '-c',
'output_flag' = '-o',
+ 'libtool_tag' = 'F77',
'pure' = 1,
'extensions' = ['.F']);
@@ -837,6 +847,7 @@
'compiler' = 'RCOMPILE',
'compile_flag' = '-c',
'output_flag' = '-o',
+ 'libtool_tag' = 'F77',
'pure' = 1,
'extensions' = ['.r']);
@@ -852,6 +863,7 @@
'compiler' = 'GCJCOMPILE',
'compile_flag' = '-c',
'output_flag' = '-o',
+ 'libtool_tag' = 'GCJ',
'lder' = 'GCJLD',
'ld' = '$(GCJ)',
'pure' = 1,
@@ -1148,7 +1160,14 @@
if set_seen ($val);
}
- my $obj_ltcompile = '$(LIBTOOL) --mode=compile ' . $obj_compile;
+ my $libtool_tag = '';
+ if ($lang-libtool_tag exists $libtool_tags{$lang-libtool_tag})
+ {
+ $libtool_tag = '--tag=' . $lang-libtool_tag . ' '
+ }
+
+ my $obj_ltcompile =
+ '$(LIBTOOL) --mode=compile ' . $libtool_tag . $obj_compile;
# We _need_ `-o
GNU Automake 1.8 released
We're pleased to announce the release of Automake 1.8. Automake is a tool for automatically generating `Makefile.in's suitable for use with Autoconf, compliant with the GNU Makefile standards, and portable to various make implementations. This release contains many bug fixes and improvements. The NEWS entry is appended. Thanks to all people who have reported bugs, contributed code, suggested enhancements, or answered user questions on the mailing lists. You can find the new release here: ftp://ftp.gnu.org/gnu/automake/automake-1.8.tar.gz ftp://ftp.gnu.org/gnu/automake/automake-1.8.tar.gz.sig ftp://ftp.gnu.org/gnu/automake/automake-1.8.tar.bz2 ftp://ftp.gnu.org/gnu/automake/automake-1.8.tar.bz2.sig ftp://sources.redhat.com/pub/automake/automake-1.8.tar.gz ftp://sources.redhat.com/pub/automake/automake-1.8.tar.gz.sig ftp://sources.redhat.com/pub/automake/automake-1.8.tar.bz2 ftp://sources.redhat.com/pub/automake/automake-1.8.tar.bz2.sig Soon it will also appear on the sources and GNU mirrors which are listed here: http://www.gnu.org/order/ftp.html http://sources.redhat.com/mirrors.html Finally, here are the MD5 checksums: 0a83fd4a2a32dc966b83ca3be86f884b automake-1.8.tar.bz2 d1001db5ab96be087817e7b7b4ba3621 automake-1.8.tar.gz Please report bugs by mail to [EMAIL PROTECTED], or (preferred) at http://sources.redhat.com/cgi-bin/gnatsweb.pl?database=automake New in 1.8: * Meta-News - The NEWS file is more verbose. * Requirements - Autoconf 2.58 or greater is required. * New features - Default source file names in the absence of a _SOURCES declaration are made by removing any target extension before appending `.c', so to make the libtool module `foo.la' from `foo.c', you only need to do this: lib_LTLIBRARIES = foo.la foo_la_LDFLAGS = -module For backward compatibility, foo_la.c will be used instead of foo.c if this file exists or is the explicit target of a rule. However -Wobsolete will warn about this deprecated naming. - AR's `cru' flags are now set in a global ARFLAGS variable instead of being hard-coded in each $(AR) invocation, so they can be substituted from configure.ac. This has been requested by people dealing with non-POSIX ar implementations. - New warning option: -Woverride. This will warn about any user target or variable definitions which override Automake definitions. - Texinfo rules back up and restore info files when makeinfo fails. - Texinfo rules now support the `html' target. Running this requires Texinfo 4.0 or greater. `html' is a new recursive target, so if your package mixes hand-crafted `Makefile.in's with Automake-generated `Makefile.in's, you should adjust the former to support (or ignore) this target so that `make html' recurses successfully. If you had a custom `html' rule in your `Makefile.am', it's better to rename it as `html-local', otherwise your rule will override Automake's new rule (you can check that by running `automake -Woverride') and that will stop the recursion to subdirectories. Last but not least, this `html' rule is declared PHONY, even when overridden. Fortunately, it appears that few packages use a non-PHONY `html' rule. - Any file which is m4_included from configure.ac will appear as a configure and Makefile.in dependency, and will be automatically distributed. - The rules for rebuilding Makefiles and Makefile.ins will now rebuild all Makefiles and all Makefile.ins at once when one of configure's dependencies has changed. This is considerably faster than previous implementations, where config.status and automake were run separately in each directory (this still happens when you change a Makefile.am locally, without touching configure.ac or friends). Doing this also solves a longstanding issue: these rebuild rules failed to work when adding new directories to the tree, forcing you to run automake manually. - For similar reasons, the rules to rebuild configure, config.status, and aclocal.m4 are now defined in all directories. Note that if you were using the CONFIG_STATUS_DEPENDENCIES and CONFIGURE_DEPENDENCIES (formerly undocumented) variables, you should better define them in all directories. This is easily done using an AC_SUBST (make sure you prefix these dependencies with $(top_srcdir) since this variable will appear at different levels of the build tree). - aclocal will now use `m4_include' instead of copying local m4 files into aclocal.m4. (Local m4 files are those you ship with your project, other files will be copied as usual.) Because m4_included files are automatically distributed, it means for most projects there is no point in EXTRA_DISTing the list of m4 files which are used. (You can probably get rid of m4/Makefile.am if you had one.) -
Re: libtool 1.5a download broken
Rich == Richard Dawe [EMAIL PROTECTED] writes: Rich Hello. Rich David Favor wrote: Rich [snip] Is there an alternative way to access libtool 1.5a? Rich [snip] Rich I don't know. Maybe one of the GNU libtool maintainers can help? I have an entire duplicate of the CVSROOT of libtool, last synchronized in the night preceding the shutdown, in case someone want to work from it locally (make sure you comment out or update the LockDir option in CVSROOT/config before trying to use this tree). Here it is: http://gadl.nerim.net/pub/libtool-CVSROOT.tar.bz2 -- Alexandre Duret-Lutz ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Automake 1.7h uploaded (fourth beta for Automake 1.8)
Hi people, Due to two last minute new features, we have yet another weekly beta of Automake 1.8. I sincerly hope this is the last one. If you are not blasé, or if you have not had the occasion to test previous versions, please give this one a try. You can find this beta here: ftp://alpha.gnu.org/gnu/automake/automake-1.7h.tar.gz ftp://alpha.gnu.org/gnu/automake/automake-1.7h.tar.gz.sig ftp://alpha.gnu.org/gnu/automake/automake-1.7h.tar.bz2 ftp://alpha.gnu.org/gnu/automake/automake-1.7h.tar.bz2.sig or here: ftp://sources.redhat.com/pub/automake/automake-1.7h.tar.gz ftp://sources.redhat.com/pub/automake/automake-1.7h.tar.gz.sig ftp://sources.redhat.com/pub/automake/automake-1.7h.tar.bz2 ftp://sources.redhat.com/pub/automake/automake-1.7h.tar.bz2.sig Here are the MD5 checksums: 2ed0df2dc0ba74d0cc55fc8689f1ec22 automake-1.7h.tar.bz2 a8b9311d183345d8c2336a135d270c63 automake-1.7h.tar.gz Please report bugs to [EMAIL PROTECTED]. Changes between 1.7f and 1.7h: * New computation of default filenames (see the first New feature in the full NEWS below). * Ignore trailing comments in variable definitions (automake was confused by `bin_PROGRAMS = foo#bar'). * New machinery that allows Automake to expand variables which are part of filenames (as in `CLEANFILES = $(PROJ).info') when it processes a list of filenames. This is currently disabled everywhere except in CLEANFILES, because it improves backward compatibility in an undocumented hack to support non-distributed info files. However it is nice to have this feature handy, and we might turn on this expansion in more places later. New in 1.7h, since 1.7.9: * Meta-News - The NEWS file is more verbose. * Requirements - Autoconf 2.58 or greater is required. * New features - Default source file names in the absence of a _SOURCES declaration are made by removing any target extension before appending `.c', so to make the libtool module `foo.la' from `foo.c', you only need to do this: lib_LTLIBRARIES = foo.la foo_la_LDFLAGS = -module For backward compatibility, foo_la.c will be used instead of foo.c if this file exists or is the explicit target of a rule. However -Wobsolete will warn about this deprecated naming. - AR's `cru' flags are now set in a global ARFLAGS variable instead of being hard-coded in each $(AR) invocation, so they can be substituted from configure.ac. This has been requested by people dealing with non-POSIX ar implementations. - New warning option: -Woverride. This will warn about any user target or variable definitions which override Automake definitions. - Texinfo rules back up and restore info files when makeinfo fails. - Texinfo rules now support the `html' target. Running this requires Texinfo 4.0 or greater. `html' is a new recursive target, so if your package mixes hand-crafted `Makefile.in's with Automake-generated `Makefile.in's, you should adjust the former to support (or ignore) this target so that `make html' recurses successfully. If you had a custom `html' rule in your `Makefile.am', it's better to rename it as `html-local', otherwise your rule will override Automake's new rule (you can check that by running `automake -Woverride') and that will stop the recursion to subdirectories. Last but not least, this `html' rule is declared PHONY, even when overridden. Fortunately, it appears that few packages use a non-PHONY `html' rule. - Any file which is m4_included from configure.ac will appear as a configure and Makefile.in dependency, and will be automatically distributed. - The rules for rebuilding Makefiles and Makefile.ins will now rebuild all Makefiles and all Makefile.ins at once when one of configure's dependencies has changed. This is considerably faster than previous implementations, where config.status and automake were run separately in each directory (this still happens when you change a Makefile.am locally, without touching configure.ac or friends). Doing this also solves a longstanding issue: these rebuild rules failed to work when adding new directories to the tree, forcing you to run automake manually. - For similar reasons, the rules to rebuild configure, config.status, and aclocal.m4 are now defined in all directories. Note that if you were using the CONFIG_STATUS_DEPENDENCIES and CONFIGURE_DEPENDENCIES (undocumented) variables, you should better define them in all directories. This is easily done using an AC_SUBST (make sure you prefix these dependencies with $(abs_top_srcdir) since this variable will appear at different levels of the build tree). - aclocal will now use `m4_include' instead of copying local m4 files into aclocal.m4. (Local m4 files are those you ship with your project, other files will be copied as usual.)
Re: Automake 1.7f uploaded (third beta for Automake 1.8)
adl == Alexandre Duret-Lutz [EMAIL PROTECTED] writes: adl This is the third beta release of the next version of Automake (1.8). Sorry I messed with the URLs. The release is 1.7f, not 1.7e. Here are the corrected URL. ftp://alpha.gnu.org/gnu/automake/automake-1.7f.tar.gz ftp://alpha.gnu.org/gnu/automake/automake-1.7f.tar.gz.sig ftp://alpha.gnu.org/gnu/automake/automake-1.7ftar.bz2 ftp://alpha.gnu.org/gnu/automake/automake-1.7f.tar.bz2.sig ftp://sources.redhat.com/pub/automake/automake-1.7f.tar.gz ftp://sources.redhat.com/pub/automake/automake-1.7f.tar.gz.sig ftp://sources.redhat.com/pub/automake/automake-1.7f.tar.bz2 ftp://sources.redhat.com/pub/automake/automake-1.7f.tar.bz2.sig /ME makes mental note not to write announcements with one hand under the pillow. Sorry for the confusion. -- Alexandre Duret-Lutz ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: configuring libltdl
On Tue, Nov 25, 2003 at 02:31:10PM +, Gary V. Vaughan wrote: | To support this you need to rewrite Makefile.in without Automake (as | Gettext does), or let these people AC_CONFIG_SUBDIRS the selfcontained | libltdl package. Okay. Since we are trying to get rid of AC_CONFIG_SUBDIRS, we should try and build on gettext's work I think. Maybe we can collaborate with Bruno to generalize the rewriting and get it into the next automake? I'm afraid I have no idea what you talk about. By rewriting Makefile.in as in Gettext I was referring to the hand-written intl/Makefile.in that Bruno has to maintain because this directory is also used in non-automake projects. I don't know what you want to generalize here. ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: configuring libltdl
On Tue, Nov 25, 2003 at 03:07:53PM +, Gary V. Vaughan wrote: I thought you meant that Bruno had a macro that did AM_INIT_AUTOMAKE-a-like AC_SUBSTing for gettext's needs, and that another similar macro could do the necessary for libltdl. Would that it were so simple ;-) Wait a minute, we have such a macro: it's called AM_INIT_AUTOMAKE. ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: configuring libltdl
On Tue, Nov 25, 2003 at 03:35:25PM +, Gary V. Vaughan wrote: If so, all we need is to add a call to AM_INIT_AUTOMAKE to AC_LIB_LTDL. Hmmm, but then if a non-automake project calls AC_LIB_LTDL, when they run autoreconf, it will run automake -a :-( Running automake in this case sounds sensible to me. 1) You need to have libltdl/Makefile.in regenerated with the automake version that matches the aclocal version used to rebuild aclocal.m4 2) automake should only rebuild the Makefile.in which have a matching Makefile.am. So this is a no-op for the rest of the project. Unfortunately I think it won't work, because autoreconf probes for a Makefile.am in the top-level directory to decide whether automake must be run. (BTW, assuming the file is named Makefile.am is not always correct.) It should be easy to fix autoreconf, though. What is likely to fail with such a scheme are the automatic rebuild rules for libltdl/Makefile.in. They assume the top-level Makefile contains some special rules to rebuilds things. ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Automake 1.7f uploaded (third beta for Automake 1.8)
Hi people, This is the third beta release of the next version of Automake (1.8). Please try it and help us fixing as much bug as possible. If no important bug are reported against this version, I think it is ready to be called 1.8. I've appended the changes since 1.7d, as well as the updated full NEWS since 1.7.9 below. You can find this beta here: ftp://alpha.gnu.org/gnu/automake/automake-1.7e.tar.gz ftp://alpha.gnu.org/gnu/automake/automake-1.7e.tar.gz.sig ftp://alpha.gnu.org/gnu/automake/automake-1.7e.tar.bz2 ftp://alpha.gnu.org/gnu/automake/automake-1.7e.tar.bz2.sig or here: ftp://sources.redhat.com/pub/automake/automake-1.7e.tar.gz ftp://sources.redhat.com/pub/automake/automake-1.7e.tar.gz.sig ftp://sources.redhat.com/pub/automake/automake-1.7e.tar.bz2 ftp://sources.redhat.com/pub/automake/automake-1.7e.tar.bz2.sig Here are the MD5 checksums: 1c10b661adfc549be6fd868045727335 automake-1.7f.tar.bz2 88c4296fea4f4b543fc3c2970838f5d6 automake-1.7f.tar.gz Please report bugs to [EMAIL PROTECTED]. Changes between 1.7d and 1.7f: - More documentation about overriding automake targets (in manual and NEWS). - Work around a Texinfo 4.1 bug in html rules. - Make sure variables whose definitions have been wrapped by Automake on multiple lines such as in foo = ... \ @subst@ will not confuse HP-UX Make if @subst@ is replaced by an empty string. - Account for Makefile inputs being possibly AC_CONFIG_FILES output. - Do not append $(EXEEXT) do @substitutions@ when rewritting _PROGRAMS variables. - Never disable rebuild rules for Makefile, even with AM_MAINTAINER_MODE. New in 1.7f (since 1.7.9): * Meta-News - The NEWS file is more verbose. * Requirements - Autoconf 2.58 or greater is required. * New features - AR's `cru' flags are now set in a global ARFLAGS variable instead of being hard-coded in each $(AR) invocation, so they can be substituted from configure.ac. This has been requested by people dealing with non-POSIX ar implementations. - New warning option: -Woverride. This will warn about any user target or variable definitions which override Automake definitions. - Texinfo rules back up and restore info files when makeinfo fails. - Texinfo rules now support the `html' target. Running this requires Texinfo 4.0 or greater. `html' is a new recursive target, so if your package mixes hand-crafted `Makefile.in's with Automake-generated `Makefile.in's, you should adjust the former to support (or ignore) this target so that `make html' recurses successfully. If you had a custom `html' rule in your `Makefile.am', it's better to rename it as `html-local', otherwise your rule will override Automake's new rule (you can check that by running `automake -Woverride') and that will stop the recursion to subdirectories. Last but not least, this `html' rule is declared PHONY, even when overridden. Fortunately, it appears that few packages use a non-PHONY `html' rule. - Any file which is m4_included from configure.ac will appear as a configure and Makefile.in dependency, and will be automatically distributed. - The rules for rebuilding Makefiles and Makefile.ins will now rebuild all Makefiles and all Makefile.ins at once when one of configure's dependencies has changed. This is considerably faster than previous implementations, where config.status and automake were run separately in each directory (this still happens when you change a Makefile.am locally, without touching configure.ac or friends). Doing this also solves a longstanding issue: these rebuild rules failed to work when adding new directories to the tree, forcing you to run automake manually. - For similar reasons, the rules to rebuild configure, config.status, and aclocal.m4 are now defined in all directories. Note that if you were using the CONFIG_STATUS_DEPENDENCIES and CONFIGURE_DEPENDENCIES (undocumented) variables, you should better define them in all directories. This is easily done using an AC_SUBST (make sure you prefix these dependencies with $(abs_top_srcdir) since this variable will appear at different levels of the build tree). - aclocal will now use `m4_include' instead of copying local m4 files into aclocal.m4. (Local m4 files are those you ship with your project, other files will be copied as usual.) Because m4_included files are automatically distributed, it means for most projects there is no point in EXTRA_DISTing the list of m4 files which are used. (You can probably get rid of m4/Makefile.am if you had one.) - aclocal will avoid touching aclocal.m4 when possible, so that Autom4te's cache isn't needlessly invalidated. This behavior can be switched off with the new `--force' option. - aclocal now uses Autoconf's --trace to detect macros which are
Re: bootstrapping CVS libtool
Bob == Bob Friesenhahn [EMAIL PROTECTED] writes: [...] Bob I retrieved a package called automake-1.7d from Bob alpha.gnu.org but it is not clear what it really is (the Bob NEWS file is extended over the one from 1.7.9). You might want to join [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/autotools-announce [...] -- Alexandre Duret-Lutz ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Version numbering
Daniel == Daniel Reed [EMAIL PROTECTED] writes: [...] Daniel Several GNU projects (including GCC) do leave off .0's Daniel for anything past the minor number, so it seems ls -v Daniel can't be the final authority :/ Sorry I meant to compare only the version numbers not the full filename. Comparing version number is what automatic installation tools has to do in order to know which version is newer than the other. Such tools can deal with 1.2 being older than 1.10, but they have trouble realizing that 1.3pre2 before 1.3 is know to break them, because 1.3pre2 is lexically after 1.3. Debian at least has a special workaround (the maintainer of a package add a extra digit in front of the version number) to cope with such unsortable numbering scheme. Hence the suggestion of supporting at least `ls -v'. % ls -v1 1.5 1.5.0a 1.5.0b 1.5.1 1.5a 1.5b 1.6 1.10 Obviously, as long as characters are reserved for beta releases, we may not care about such installation tools. After all the real releases are easy to sort since they use only digit. As far as explaining the new scheme is concerned, I claim that it's easier to do if it works with `ls -v'. In the past, people have also argued that using characters was making it more difficult for tools to sort the versions. If you agree you might as well switch to the blessed FSF way of making beta releases (using .90, .91, .92, etc.). Texinfo and Coreutils switched to it recently. I don't really like it because I think it's horrible with branches and is less obvious than characters (I really like these extra characters). A scheme which I think would be compatible with Gary's will (maybe this is what he proposed, I simply did not understand whether he wanted to jump from 1.7d down to 1.7 or up to 1.8). 1.6 (release) 1.7a (CVS), 1.7b (beta), 1.7c (CVS), 1.7d (beta), 1.8 (release) on the branch: 1.8.1a (CVS) 1.8.1b (beta) 1.8.2 (release) etc. Keeping odd version for development ensure people cannot mis-sort versions with letters with others. It could also gives some feeling of sense to accustomed to the odd/even version numbering scheme of Linux. -- Alexandre Duret-Lutz ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Version numbering
Gary == Gary V Vaughan [EMAIL PROTECTED] writes: [...] Gary And that's why people find our version scheme confusing. I'm not sure Gary how we ended up working in this way, I think we copied it from Gary Automake? Tsk tsk tsk. Libtool used that scheme first. Automake copied it when we started to have branches. Gary Anyhow, I'm fed up of having to explain it, when we could Gary just make it intuitive :-) I didn't understand your proposal, but I hope you are not planning to make 2.2 2.3a 2.3. That would be counter intuitive. IMHO any numbering scheme ought to work with `ls -v'. -- Alexandre Duret-Lutz ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: 9-gary-reduce-dist-size.patch
On Fri, Sep 26, 2003 at 12:27:42AM +0900, Peter O'Gorman wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Alexandre Duret-Lutz wrote: | This seems to be an old version of Automake. The last Nestable | use was removed on 2003-08-12. I just checked out cvs HEAD via anonymous cvs from savannah.gnu.org, but looking at it the last ChangeLog entry was more than 6 months ago. I guess I did something wrong, care to enlighten me? :) Savannah used to be a mirror, I don't know why it stopped. CVS instructions are on the Automake home page at http://sources.redhat.com/automake/ ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: (With Patch) Re: DESTDIR trouble
R == R I P Deaddog [EMAIL PROTECTED] writes: [...] R For several _YEARS_, packagers for software were very troubled because R of not-completely-working staging install. I really hope this issue can R be sorted out, once and for all. One way to address the once for all part would be to write a test case. [...] -- Alexandre Duret-Lutz ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: 1.5 automatically generating C++, F77 tags
Albert Chin [EMAIL PROTECTED] writes: [...] | --- libtool.m4.orig 2003-06-01 16:07:41.276467000 -0500 | +++ libtool.m42003-06-03 10:22:57.667598339 -0500 [...] | +AC_PROVIDE_IFELSE([AC_LIBTOOL_TAGS],, | + [AC_LIBTOOL_TAGS([C C++ F77])]) Since the tag for C++ is called CXX and there is no tag for C, it would seem more natural to read AC_LIBTOOL_TAGS([CXX F77]) I think Bob's suggestion of AC_LIBTOOL_LANGUAGES is better if you really want to pass language names as arguments. [...] | + [m4_if(_LT_TAG, C, , | + [m4_if(_LT_TAG, C++, [...] | + [m4_if(_LT_TAG, F77, [...] | + [m4_if(_LT_TAG, GCJ, [...] | + [m4_if(_LT_TAG, RC, [...] | + m4_errprintn(m4_location[: error: invalid tag name: ]_LT_TAG) Maybe this can be simplified to something around the lines of m4_case([_LT_TAG], [C], , [CXX], [...], [F77], [...], [GCJ], [...], [RC], [...], [m4_fatal([unsupported tag name: ]_LT_TAG)]) -- Alexandre Duret-Lutz ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: 1.5 automatically generating C++, F77 tags
Albert == Albert Chin [EMAIL PROTECTED] writes: Albert On Mon, Jun 02, 2003 at 05:06:42PM -0500, Bob Friesenhahn wrote: On Mon, 2 Jun 2003, Albert Chin wrote: It's really annoying to have 1.5 automatically generate the C++ and F77 tags. I'm trying to figure out why it does this. We have the following in libtool.m4: dnl If AC_PROG_CXX has already been expanded, run AC_LIBTOOL_CXX dnl immediately, otherwise, hook it in at the end of AC_PROG_CXX. AC_PROVIDE_IFELSE([AC_PROG_CXX], [AC_LIBTOOL_CXX], [define([AC_PROG_CXX], defn([AC_PROG_CXX])[AC_LIBTOOL_CXX ])]) [...] Albert I'm trying to do it automatically. I want to run AC_LIBTOOL_CXX *only* Albert if AC_PROG_CXX is called. Can autoconf do this? Automake setups its dependency tracking code for various languages with code similar to the above. Actually, the above would work if Libtool was not running expanding AC_PROG_CXX itself! (This happens when AC_LIBTOOL_LANG_CXX_CONFIG is expanded in _LT_AC_TAGCONFIG.) As I see it, the only way to achieve what you want would be to rewrite the `case $tagname' switch from _LT_AC_TAGCONFIG in plain M4 (instead of shell). This way you can ensure that AC_LIBTOOL_LANG_CXX_CONFIG is expanded only if AC_PROG_CXX has been called first. Likewise for other languages. However I don't think you can do this and still allow AC_PROC_CXX to be called after AC_PROG_LIBTOOL. -- Alexandre Duret-Lutz ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: 1.5 automatically generating C++, F77 tags
Albert == Albert Chin [EMAIL PROTECTED] writes: [...] Albert I don't have a problem requiring AC_PROG_CXX, AC_PROG_F77, or Albert AM_PROG_GCJ before AC_PROG_LIBTOOL. Anyone see this as a problem? As a user I wouldn't care about this little inconvenience if it allows Libtool not to bloat my configure with useless checks. However, requiring this will break thousands of configure.ac. I expect most of them to run AC_INIT, AM_INIT_AUTOMAKE, AC_PROG_LIBTOOL early, and then go on with other checks such as language checks. Maybe this could be changed as follows: - if any of AC_PROG_CC, AC_PROG_CXX, AC_PROG_F77, or AM_PROG_GCJ are called before AC_PROG_LIBTOOL, define the tags only for those which are called. (I think there is no tag for CC, but if only AC_PROG_CC is called that would just means that CXX, F77, and GCJ are not wanted.) - if none of these macros is called before AC_PROG_LIBTOOL, assume they might be called latter and define all tags, as in the current implementation. See this as backward compatibility. Also, this would allow one to configure Libtool to use some languages and ignore other. E.g., # I only use Libtool with C programs, I don't need it for C++. ... AC_PROG_CC AC_PROG_LIBTOOL AC_PROG_CXX ... -- Alexandre Duret-Lutz ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Automake 1.7.2b uploaded (beta for 1.7.3)
' will work recursively. -- Alexandre Duret-Lutz ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
ANN: new mailing list: autotools-announce@gnu.org
[Please repost and forward wherever it is appropriate.] We have setup a new mailing list, [EMAIL PROTECTED], that will carry announcements for releases *and* beta-releases of Autoconf, Automake, Gettext, and Libtool. This is intended to be a read-only and low-traffic list, for people that cannot afford reading each tool's list, but still would like to hear about new releases, or are willing to test pre-releases. If you know such people, please tell them. You can subscribe here: http://mail.gnu.org/mailman/listinfo/autotools-announce Cheers, -- Alexandre Duret-Lutz ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Pending release of 1.5
Robert == Robert Boehne [EMAIL PROTECTED] writes: Robert Hello, Robert I'm just about to make the release of Libtool 1.5. If anyone would Robert like to test the current CVS on their favorite platform and report Robert any problems, please do so! If not, your woes may have to wait for Robert 1.5.1. Great news! How about making a test release (1.4f, say), and announcing it to more that just [EMAIL PROTECTED] to get wider testing? The last snapshot of this branch (1.4d) is one year old, and not everybody is able to test Libtool off CVS. Cheerio, -- Alexandre Duret-Lutz ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Pending release of 1.5
Robert == Robert Boehne [EMAIL PROTECTED] writes:
Robert Alexandre,
Robert Snapshots of CVS are made daily and reside at
Robert ftp://alpha.gnu.org/pub/gnu/cvs/libtool.tgz
CVS snapshots are differents from `make dist' tarballs. The
former still requires maintainer tools like Autoconf, Automake,
Texinfo... I don't think they are easier to test than a CVS
checkout. It is better to test a real candidate of what the
release will be, IMHO.
Besides, since generated files are not under CVS we don't know
what yours will look like. We should test the files that you
will distribute, not the files that we can build with our own
versions of the autotools.
Robert I'm not sure where to announce a pending release other
Robert than here, but I had just intended to re-release after
Robert bugs were fixed found in 1.5. If you have a suggestion
Robert on where to announce the pre-release, let us know.
I sent you a private mail entitled `RFC: [EMAIL PROTECTED]' on
January 15. (Only Akim, Jim, Pavel, and Paul answered to this; I was
hopping comments from you and Bruno.) Since then I've asked for
the creation of this list, but haven't heard anything from the GNU
sysadmins yet (the ticket ID is [gnu.org #17673]).
Presently, Autoconf and Automake prereleases are announced to
{autoconf,automake,libtool,bug-gnu-utils}@gnu.org. Also for
Automake prereleases I have been spamming anybody listed in
ChangeLog entries since the last release (this is mainly to make
sure bug reporters have a chance to check that their bug is
fixed before the real release).
--
Alexandre Duret-Lutz
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Automake and `libtool --mode=clean'
Would it make sense that Automake start using `libtool --mode=clean rm -f ...' during `make clean', or has there been any trouble with this feature recently? Has it been tested in any way? A can't find any occurence of `mode=clean' in the Libtool test suite. -- Alexandre Duret-Lutz ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Automake 1.7.2 released
We're pleased to announce the release of Automake 1.7.2 This is a bug fix release. The list of bug fixes is appended. You can find the new release here: ftp://ftp.gnu.org/gnu/automake/automake-1.7.2.tar.bz2 ftp://ftp.gnu.org/gnu/automake/automake-1.7.2.tar.gz ftp://sources.redhat.com/pub/automake/automake-1.7.2.tar.bz2 ftp://sources.redhat.com/pub/automake/automake-1.7.2.tar.gz Soon it will also appear on the sources and GNU mirrors listed here: http://www.gnu.org/order/ftp.html http://sources.redhat.com/mirrors.html Here are the MD5 checksums: 8cfa661dca69271b862bee4f841fcd80 automake-1.7.2.tar.bz2 753647afe9db0ec52c69c6b9bb7dd106 automake-1.7.2.tar.gz Please report bugs to [EMAIL PROTECTED]. - Akim, Alexandre, and Tom Bugs fixed in 1.7.2: * Fix installation and uninstallation of Info files built in subdirectories. * Do not run `./configure --with-included-gettext' during `make distcheck' if AM_GNU_GETTEXT([external]) is used. * Correctly uninstall renamed man pages. * Do not strip escaped newline in variables defined in one condition and augmented in another condition. * Fix ansi2knr rules for LIBOBJS sources. * Clean all known Texinfo index files, not only those which appear to be used, because we cannot know wich indexes are used in included files. (PR/375, Debian Bug #168671) * Honor only the first @setfilename seen in a Texinfo file. * Treat required file X not found diagnostics as errors (exit status 1). * Don't complain that a required file is not found when it is a Makefile target. (PR/357) * Don't use single suffix inference rules when building `.info'-less Info files, for the sake of Solaris make. * The `check' target now depends on `$(BUILT_SOURCES)'. (PR/359) * Recognize multiple inference rules such as `.a.b .c.d:'. (PR/371) * Warn about multiple inference rules when -Wportability is used. (PR/372) * Fix building of deansified files from subdirectories. (PR/370) * Add missing `fi' in the .c-.obj rules. * Improve install-sh to work even when names contain spaces or certain (but not all) shell metachars. * Fix the following spurious failures in the test suite: depcomp2.test, gnits2.test, gnits3.test, python3.test, texinfo13.test * Noteworthy manual updates: - Augment the section about BUILT_SOURCES. - Mention that AM_PROG_CC_STDC is a relic that is beter avoided today. ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: getting a locally built library
Bruce == Bruce Korb [EMAIL PROTECTED] writes: Bruce Alexandre Duret-Lutz wrote: /bin/sh ../libtool --mode=link gcc -g -O2 -L/sw/lib -o autogen \ -export-dynamic -lguile *.o -L/sw/lib -lguile -lm \ -L../autoopts/.libs -lopts -ldl ld: Undefined symbols: _aopts_alloc _aopts_realloc _aopts_strdup make[1]: *** [autogen] Error 1 [...] it should not output `-L../autoopts/.libs -lopts' but `../autoopts/libopts.la' since Bruce said `autogen_LDADD = $(top_builddir)/autoopts/libopts.la'. [...] Bruce That part I did not change from David's email. David, could you explain where `-L../autoopts/.libs -lopts' comes from? [...] -- Alexandre Duret-Lutz ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: [shell functions, was RE: solving of name conflicts in included.a]
Bruce == Bruce Korb [EMAIL PROTECTED] writes: [...] Bruce neither Autoconf nor Libtool want to be the first to say Bruce that 20 year old shells are too old for continued Bruce support. Ick. How completely disgusting. Cheer up and read the Autoconf 2.54c announcement entirely :) -- Alexandre Duret-Lutz ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Automake 1.7.1 released
We're pleased to announce the release of Automake 1.7.1 This is a bug fix release. The list of fixed bugs is appended below. You can find the new release here: ftp://sources.redhat.com/pub/automake/automake-1.7.1.tar.gz ftp://sources.redhat.com/pub/automake/automake-1.7.1.tar.bz2 Soon it will also appear at ftp://ftp.gnu.org/gnu/automake/automake-1.7.1.tar.gz ftp://ftp.gnu.org/gnu/automake/automake-1.7.1.tar.bz2 as well as on sources and GNU mirrors: http://www.gnu.org/order/ftp.html http://sources.redhat.com/mirrors.html Please report bugs to [EMAIL PROTECTED]. - Akim, Alexandre, and Tom Bugs fixed in 1.7.1: * Honor `ansi2knr' for files built in subdirectories, or using per-targets flags. * Aclocal should now recognize macro names containing parentheses, e.g. AC_DEFUN([AC_LANG_PREPROC(Fortran 90)], [...]). * Erase *.sum and *.log files created by DejaGnu, during `make distclean'. (Debian Bug#153697) * Install Python files even if they were built. (PR/369) * Have stamp-vti dependent upon configure instead of configure.ac, as the version might not be defined in the latter. (PR/358) * Reorder arguments passed to a couple of commands, so things works when POSIXLY_CORRECT=1. * Fix a regex that can cause Perl to segfault on large input. (Debian Bug#162583) * Fix distribution of packages that have some sources defined conditionally, as in the `Conditional compilation using Automake conditionals' example of the manual. * Fix spurious test suite failures on IRIX. * Don't report a required variable as undefined if it has been defined conditionally for the right conditions. * Fix cleaning of the /tmp subdirectory used by `make distcheck', in case `make distcheck' fails. * Fix distribution of included Makefile fragment, so we don't create spurious directories in the distribution. (PR/366) * Don't complain that a target lacks `.$(EXEEXT)' when it has it. ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Automake 1.7 released
We're pleased to announce the release of Automake 1.7. This release contains many bug fixes and improvements. The NEWS entry is appended. You can find the new release here: ftp://sources.redhat.com/pub/automake/automake-1.7.tar.gz ftp://sources.redhat.com/pub/automake/automake-1.7.tar.bz2 ftp://ftp.gnu.org/gnu/automake/automake-1.7.tar.gz ftp://ftp.gnu.org/gnu/automake/automake-1.7.tar.bz2 (Note that the files might not be already available at ftp.gnu.org by the time you read this.) Soon it will also appear on the sources and GNU mirrors. Follow these links for a list of them: http://sources.redhat.com/mirrors.html http://www.gnu.org/order/ftp.html Please report bugs by mail to [EMAIL PROTECTED], or (preferred) at http://sources.redhat.com/cgi-bin/gnatsweb.pl?database=automake - Akim, Alexandre, and Tom New in 1.7: * Autoconf 2.54 is required. * `aclocal' and `automake' will no longer warn about obsolete configure macros. This is done by `autoconf -Wobsolete'. * AM_CONFIG_HEADER, AM_SYS_POSIX_TERMIOS and AM_HEADER_TIOCGWINSZ_NEEDS_SYS_IOCTL are obsolete (although still supported). You should use AC_CONFIG_HEADERS, AC_SYS_POSIX_TERMIOS, and AC_HEADER_TIOCGWINSZ instead. `autoupdate' can upgrade `configure.ac' for you. * Support for per-program and per-library `_CPPFLAGS'. * New `ctags' target (builds CTAGS files). * Support for -Wmumble and -Wno-mumble, where mumble is a warning category (see `automake --help' or the manual for a list of them). * Honor the WARNINGS environment variable. * Omit the call to depcomp when using gcc3: call the compiler directly. * A new option, std-options, tests that programs support --help and --version when `make installcheck' is run. This is enabled by --gnits. * Texinfo rules now support the `ps' and `pdf' targets. * Info files are now created in the build directory, not the source directory. * info_TEXINFOS supports files in subdirectories (this requires Texinfo 4.1 or greater). * `make distcheck' will enforce DESTDIR support by attempting a DESTDIR install. * `+=' can be used in conditionals, even if the augmented variable was defined for another condition. * Makefile fragments (inserted with `include') are always distributed. * Use Autoconf's --trace interface to inspect configure.ac and get a more accurate view of it. * Add support for extending aclocal's default macro search path using a `dirlist' file within the aclocal directory. * automake --output-dir is deprecated. * The part of the distcheck target that checks whether uninstall actually removes all installed files has been moved in a separate target, distuninstallcheck, so it can be overridden easily. * Many bug fixes. ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
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 ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Automake 1.6f available (beta for Automake 1.7)
Thanks to all people who have send patches and bug reports here is another beta for Automake 1.7. Again, please SHOUT LOUD if your package works with Automake 1.6.3 but doesn't with 1.6f. Incompatibilities are best fixed before the release. Please report any issue by mail to [EMAIL PROTECTED], or (preferred) at http://sources.redhat.com/cgi-bin/gnatsweb.pl?database=automake You can find this snapshot here: ftp://sources.redhat.com/pub/automake/automake-1.6f.tar.gz ftp://sources.redhat.com/pub/automake/automake-1.6f.tar.bz2 Here are the news since 1.6. (There have been only bug fixes since 1.6d.) New in 1.6f: * Autoconf 2.54 is required. * `aclocal' and `automake' will no longer warn about obsolete configure macros. This is done by `autoconf -Wobsolete'. * AM_CONFIG_HEADER, AM_SYS_POSIX_TERMIOS and AM_HEADER_TIOCGWINSZ_NEEDS_SYS_IOCTL are obsolete (although still supported). You should use AC_CONFIG_HEADERS, AC_SYS_POSIX_TERMIOS, and AC_HEADER_TIOCGWINSZ instead. `autoupdate' can upgrade `configure.ac' for you. * Support for per-program and per-library `_CPPFLAGS'. * New `ctags' target (builds CTAGS files). * Support for -Wmumble and -Wno-mumble, where mumble is a warning category (see `automake --help' or the manual for a list of them). * Honor the WARNINGS environment variable. * Omit the call to depcomp when using gcc3: call the compiler directly. * A new option, std-options, tests that programs support --help and --version when `make installcheck' is run. This is enabled by --gnits. * Texinfo rules now support the `ps' and `pdf' targets. * Info files are now created in the build directory, not the source directory. * info_TEXINFOS supports files in subdirectories (this requires Texinfo 4.1 or greater). * `make distcheck' will enforce DESTDIR support by attempting a DESTDIR install. * `+=' can be used in conditionals, even if the augmented variable was defined for another condition. * Makefile fragments (inserted with `include') are always distributed. * Use Autoconf's --trace interface to inspect configure.ac and get a more accurate view of it. * Add support for extending aclocal's default macro search path using a `dirlist' file within the aclocal directory. * automake --output-dir is deprecated. * Many bug fixes. - Akim, Alexandre, and Tom -- Alexandre Duret-Lutz ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: autoreconf misses ltmain.sh
Ralf == Ralf Corsepius [EMAIL PROTECTED] writes: Ralf This bug has been present with previous versions of automake and Ralf autoconf (IIRC, it also has been reported several times before). I think this is the same issue as http://mail.gnu.org/pipermail/libtool/2002-August/006640.html -- Alexandre Duret-Lutz ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Automake 1.6d available (beta for Automake 1.7)
Here is a snapshot of the current development version of Automake. This should become Automake 1.7 *soon*. How soon will depends on the feedback we get on this beta. Please get it, install it, test it, torture it. Please report any issue by mail to [EMAIL PROTECTED], or (preferred) using the form at http://sources.redhat.com/cgi-bin/gnatsweb.pl?database=automake Please SHOUT LOUD if your package works with Automake 1.6.3 but doesn't with 1.6d. You can find this snapshot here: ftp://sources.redhat.com/pub/automake/automake-1.6d.tar.gz ftp://sources.redhat.com/pub/automake/automake-1.6d.tar.bz2 Here are the news since 1.6. (The `|' on the left indicates a change since the last snapshot, 1.6b.) New in 1.6d: |* Autoconf 2.54 is required. * `aclocal' and `automake' will no longer warn about obsolete configure macros. This is done by `autoconf -Wobsolete'. * AM_CONFIG_HEADER, AM_SYS_POSIX_TERMIOS and AM_HEADER_TIOCGWINSZ_NEEDS_SYS_IOCTL are obsolete (although still supported). You should use AC_CONFIG_HEADERS, AC_SYS_POSIX_TERMIOS, and AC_HEADER_TIOCGWINSZ instead. `autoupdate' can upgrade `configure.ac' for you. * Support for per-program and per-library `_CPPFLAGS'. * New `ctags' target (builds CTAGS files). * Support for -Wmumble and -Wno-mumble, where mumble is a warning category (see `automake --help' or the manual for a list of them). * Honor the WARNINGS environment variable. * Omit the call to depcomp when using gcc3: call the compiler directly. * A new option, std-options, tests that programs support --help and --version when `make installcheck' is run. This is enabled by --gnits. * Texinfo rules now support the `ps' and `pdf' targets. |* Info files are now created in the build directory, not the source directory. |* info_TEXINFOS supports files in subdirectories (this requires Texinfo 4.1 | or greater). * `make distcheck' will enforce DESTDIR support by attempting a DESTDIR install. * `+=' can be used in conditionals, even if the augmented variable was defined for another condition. |* Makefile fragments (inserted with `include') are always distributed. * Use Autoconf's --trace interface to inspect configure.ac and get a more accurate view of it. |* Add support for extending aclocal's default macro search path | using a `dirlist' file within the aclocal directory. * automake --output-dir is deprecated. * Many bug fixes. - Akim, Alexandre, and Tom ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Bug in conditional library building
Patrick == Patrick Guio [EMAIL PROTECTED] writes: [...] Patrick am_libmudfas2d_la_OBJECTS = $(am__objects_1) Patrick am_libmudfas3d_la_OBJECTS = $(am__objects_1) [...] This will be fixed in Automake 1.6.2. It is already fixed in CVS. -- Alexandre Duret-Lutz ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Bug in libltdl?
Stephano == Stephano Mariani [EMAIL PROTECTED] writes: Stephano libltdl (current from CVS) seems not to return NULL Stephano when lt_dlopen is passed the name of a non-existent Stephano file. I got the same error and sent this patch: http://mail.gnu.org/pipermail/libtool-patches/2002-March/001767.html A similar fix is present in Alexander Bluhm's set of patches against version 1.4.2: http://mail.gnu.org/pipermail/libtool-patches/2002-March/001770.html [...] -- Alexandre Duret-Lutz ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: PATCH: pointless code removal
adl == Alexandre Duret-Lutz [EMAIL PROTECTED] writes: [...] adl libtool --compile gcc -c foo.c -Xcompiler -M Of course, I meant libtool --mode=compile gcc -c foo.c -Xcompiler -M [...] -- Alexandre Duret-Lutz ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: libtool CVS permanently broken?
Bob == Bob Friesenhahn [EMAIL PROTECTED] writes: [...] Bob % ./bootstrap Bob autoheader: config-h.in is unchanged Bob Can't call method close on an undefined value at /usr/local/bin/automake line 7751. See these messages for a fix: http://mail.gnu.org/pipermail/automake-patches/2001-September/000234.html http://mail.gnu.org/pipermail/automake-patches/2001-October/000367.html [...] -- Alexandre Duret-Lutz ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: building same source with different flag
Ted == Ted Irons [EMAIL PROTECTED] writes:
[...]
Ted if test ${lt_cv_prog_compiler_c_o_CXX+set} = set; then
Ted echo $ECHO_N (cached) $ECHO_C 6
Ted else
Ted lt_cv_prog_compiler_c_o_CXX=no
[...]
Ted save_CFLAGS=$CFLAGS
Ted CFLAGS=$CFLAGS -o out/conftest2.$ac_objext
[...]
Ted If I change the CFLAGS to CXXFLAGS in configure the
Ted configure output gives g++ supports -c -o file.o
Ted ... yes; otherwise the answer given is no. Incidentally,
Ted configure does a prior check of gcc with -c and -o, and
Ted that passes.
Ted I have no idea why the configure check is using CFLAGS instead of
Ted CXXFLAGS. I changed the CXXFLAGS in ACX_CXXCOMPILE to
Ted AM_CXXFLAGS, but that made no difference.
It seems this was fixed a few days after libtool 1.4b was
announced. Can you try CVS libtool?
[...]
--
Alexandre Duret-Lutz
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: building same source with different flag
Ted Irons [EMAIL PROTECTED] writes:
[...]
| Am using autoconf-2.5.2, automake-1.5b, libtool-1.4b
| on an ix86 box run running Suse Linux with kernel-2.4.6.
[...]
| libohrnet_la_SOURCES = ascbin.cc
| libohrnet_la_CXXFLAGS = -DHIGHER_ORDER_NET ${HBP_CXXFLAGS}
| libohrnet_la_LDFLAGS = -version-info @PIPES_VERSION@
[...]
| source='ascbin.cc' object='libhrnet_la-ascbin.lo' libtool=yes \
| depfile='.deps/libhrnet_la-ascbin.Plo' tmpdepfile='.deps/libhrnet_la-ascbin.TPlo' \
| depmode=gcc /bin/sh ../../../pipes-1.0/config/depcomp \
| /bin/sh ../../libtool --mode=compile g++ -DHAVE_CONFIG_H
| -I. -I../../../pipes-1.0/tma/hbp.lib -I../.. -fpermissive
|-I../../../pipes-1.0/tma/util.lib -I../../../pipes-1.0/tma/trff.lib -g -O2 -c -o
|libhrnet_la-ascbin.lo `test -f ascbin.cc || echo
|'../../../pipes-1.0/tma/hbp.lib/'`ascbin.cc
| g++ -DHAVE_CONFIG_H -I. -I../../../pipes-1.0/tma/hbp.lib -I../.. -fpermissive
|-I../../../pipes-1.0/tma/util.lib -I../../../pipes-1.0/tma/trff.lib -g -O2 -c
|../../../pipes-1.0/tma/hbp.lib/ascbin.cc -Wp,-MD,.deps/libhrnet_la-ascbin.TPlo -fPIC
|-DPIC
| mv -f libhrnet_la-ascbin.o .libs/libhrnet_la-ascbin.o
| mv: cannot stat `libhrnet_la-ascbin.o': No such file or directory
| make[3]: *** [libhrnet_la-ascbin.lo] Error 1
[...]
I can reproduce your problem by manually setting compiler_c_o and
compiler_o_lo to no in the libtool script generated for a
pet-project. So ...
1) Libtool has decided at configure-time that you compiler
cannot run with both `-c' and `-o'. No idea why. It seems
bogus to me if you are using GCC. You should probably dig
config.log for clues.
2) Therefore `libtool' strips `-o libhrnet_la-ascbin.lo' from the compilation
command and assumes that the compiler will build an object file
called after the source file. That source file is assumed
to be the last argument of the compilation command.
3) However `libtool' is not called directly. Actually, `make' calls `depcomp'
which in turn calls `libtool'. Since you have `gcc', `depcomp' is in
`gcc' mode and has appended `-Wp,-MD,.deps/libhrnet_la-ascbin.TPlo' to the
the compilation command in order to track dependencies.
4) This last argument is taken by `libtool' to be the source file :).
It just strips the dirname (`-Wp,-Md,.deps/' !) and the extension (`.Tplo'),
append `.o', and you get `libhrnet_la-ascbin.o', the object `libtool'
thinks `gcc' will create.
(It's funny to see that this behavior leads to a correct
result if you do not use per-target CXXFLAGS; because the
dependency option is then `-Wp,-MD,.deps/ascbin.TPlo' which
`libtool' maps to `ascbin.o'.)
5) Finally the compilation command is run, ascbin.o is created,
and libtool fail to move the resulting object because it looks for
`libhrnet_la-ascbin.o' instead.
As an immediate work-around, you can prevent `depcomp' to add this
fatal last argument by configuring your package with
--disable-dependency-tracking. However it would be better to find out
why `gcc -c -o' doesn't work on your host.
I can see two ways to fix this: either teach `depcomp' to stick
`-Wc,' or `-Xcompiler' before dependency tracking options when
running libtool (some depcomp modes such as aix already do that
properly), or teach `libtool' to ignore options (`-*') when
updating $srcfile. Which one seems more sensible? both?
--
Alexandre Duret-Lutz
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
