lls 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
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
On Thu, Feb 16, 2006 at 03:55:44PM +0100, Alexandre Duret-Lutz wrote:
> Take the string "[EMAIL PROTECTED]@.la" (that's what
> Automake reads). To canonize it, replace characters that are neither
I meant to write "canonicalize". The above mistake should not be
On Thu, Feb 16, 2006 at 04:22:24PM +1100, Brendon Costa wrote:
>
> The configure script exports the following two variables for use in
> automake that help with versioning:
>
> PACKAGE_VERSION 1.0.6
> PACKAGE_VERSION_UNDERSCORE 1_0_6
>
Sorry, that makes no sense : the substitutions a
>>> "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 $(BU
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
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 contai
$(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
mply call the installed `libtool' as shown
in the manual. You do not need libtoolize in such a setup.
--
Alexandre Duret-Lutz
___
Libtool mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/libtool
IG_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
; 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
_
>>> "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
>>
>>> "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
>> depe
erms 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)
>>> "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>
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
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
ng) 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
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/g
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
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
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"
o 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 mai
on, Inc.
+# Copyright (C) 2003, 2004 Free Software Foundation, Inc.
#
# This file is part of GNU Automake.
#
@@ -33,8 +33,9 @@
END
cat > Makefile.am << 'END'
+AUTOMAKE_OPTIONS = subdir-objects
lib_LTLIBRARIES = libmod1.la mod2.la
-libmod1_la_SOURCES = mod1.c
+libmod1_la_SOURCES = sub/mod1.c
libmod1_la_LDFLAGS = -module
libmod1_la_LIBADD = -dlopen mod2.la
mod2_la_SOURCES = mod2.c
@@ -50,9 +51,9 @@
END
-mkdir liba
+mkdir sub liba
-cat > mod1.c << 'END'
+cat > sub/mod1.c << 'END'
int
mod1 ()
{
--
Alexandre Duret-Lutz
___
Libtool mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/libtool
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
inutes 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
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 enhanceme
On Tue, Jul 27, 2004 at 05:15:17PM +0100, Patrick Welche wrote:
> Reminder of the miscreant line:
>
> output_verbose_link_cmd="`$echo \"X$output_verbose_link_cmd\" | $Xsed -e
> \"$no_glob_subst\"`"
>
Why not replacing it with
output_verbose_link_cmd=`$echo "X$output_verbose_link_cmd" | $Xsed
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
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
>>> "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?
>&g
>>> "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
>>> "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 in
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.gn
eeking 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
lem 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
mov
clocal 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
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
>>> "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
>>> "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 --
On Wed, Dec 31, 2003 at 02:11:34PM +, Scott James Remnant wrote:
> The script and everything under CVSROOT that logged our commits and sent
> them to [EMAIL PROTECTED] has been lost.
>
> Don't suppose anyone kept a copy of this around, and could re-add it to
> CVSROOT (possibly fixing the broke
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. Th
erim.net/pub/libtool-CVSROOT.tar.bz2
--
Alexandre Duret-Lutz
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
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.g
>>> "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/autom
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
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 sen
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, w
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, w
On Tue, Nov 25, 2003 at 01:39:10PM +, Gary V. Vaughan wrote:
>
> Good point. As long as we ship Makefile.in (and libtoolize --ltdl installs
> only Makefile.in if $configure_ac has no reference to AM_INIT_AUTOMAKE) that
> should satisfy the autoconf/libtool only audience...
Hmm... you can't use
IL PROTECTED]
http://mail.gnu.org/mailman/listinfo/autotools-announce
[...]
--
Alexandre Duret-Lutz
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
annot
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
at 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
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 check
On Thu, Sep 25, 2003 at 11:40:26PM +0900, Peter O'Gorman wrote:
> I kept getting crap like this:
> autoreconf: running: automake --add-missing --copy --force-missing
> Can't locate object method "TIEHASH" via package
> "Tie::RefHash::Nestable" at /usr/local/bin/automake line 517.
> autoreconf: fail
ress 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
of
m4_case([_LT_TAG],
[C], ,
[CXX], [...],
[F77], [...],
[GCJ], [...],
[RC], [...],
[m4_fatal([unsupported tag name: ]"_LT_TAG")])
--
Alexandre Duret-Lutz
___
Libtool mailing list
[EMAIL PROTECT
e 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
_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 fo
ibltdl/configure.in, and replace the above code by
AC_CONFIG_AUX_DIR([../tools]) so that Automake find its files.
If you decide to start shipping auxiliary files with libltdl,
then this code can be changed to AC_CONFIG_AUX_DIR([.]). I
suppose some people will mind about the extra ki
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
ng 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
ease 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 L
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.
--
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
>>> "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 \
>> >&
mething like `*.o'; second, it should not output
`-L../autoopts/.libs -lopts' but `../autoopts/libopts.la'
since Bruce said `autogen_LDADD = $(top_builddir)/autoopts/libopts.la'.
I'm tempted to think that the link rule was hand-edited (either in the
Makefile(|.in|.am), or i
toconf 2.54c announcement entirely :)
--
Alexandre Duret-Lutz
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
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
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.
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&
one as PR automake/350.
Harlan> Is there a workaround/bugfix?
Here is a workaround. Define FOO_AB as "FOO_A or FOO_B"":
AM_CONDITIONAL(FOO_AB, test x"$FOO" = xa || test x"$FOO" = xb)
then use FOO_AB to define lib_LTLIBRARIES in a single place.
--
Alexa
lways 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 --ou
mail/libtool/2002-August/006640.html
--
Alexandre Duret-Lutz
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
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
>>> "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
Can you try Automake 1.6.1? It should clean subdir libtool objects correctly.
--
Alexandre Duret-Lutz
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
.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
__
>>> "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
times appends things like `-Wc,-M', but
I'm using the equivalent `-Xcompiler -M' here because it seems
your patch remove the support for this.
--
Alexandre Duret-Lutz
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
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
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
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
83 matches
Mail list logo
