Re: Makefile dependency
Ralf == Ralf Corsepius [EMAIL PROTECTED] writes: Ralf = automake-1.7's AM_MAINTAINER_MODE deactivates regeneration of Ralf Makefile's. Ralf I am inclined to interpret this as a bug and/or regression from earlier Ralf versions of automake. I agree. The rule for maintainer mode was that it would deactivate rules for which you needed special maintainer tools. Rebuilding Makefile doesn't fit this category -- all you need is config.status, which you've got. Tom
1-gary-strip-target-suffix-from-default-source.patch [was Re: Default source file names]
On Tue, 18 Nov 2003 11:02:04 -0700, Kevin P. Fleming
[EMAIL PROTECTED] said:
Gary V. Vaughan wrote:
with the simpler:
~pkglibexec_LTLIBRARIES = gnu.la . traditional.la
~AM_LDFLAGS = -module
but unfortunately Automake wants to build `gnu.la' from `gnu.la.c', so the
repetitive sources declarations are necessary, unless I rename all my
source
files.
This would help me out too, I thought of the same thing.
I dusted off my copy of Programming Perl and came up with the attached
patch. I don't know whether stripping the lib prefix from {LT,}LIBRARIES
targets for a default source is also appropriate...
The problem
though is that a library is a collection of objects, it's not really a
single object (even though we're both using them that way).
But so is a program if you look at it that way. And `bin_PROGRAMS = foo'
is enough to build foo from foo.c, so it seems natural to have
`lib_LTLIBRARIES = foo.la' work similarly.
Cheers,
Gary.
--
())_. Gary V. Vaughangary@(lilith.warpmail.net|gnu.org)
( '/ Research Scientist http://www.oranda.demon.co.uk ,_())
/ )= GNU Hacker http://www.gnu.org/software/libtool \'
`
`(_~)_ Tech' Author http://sources.redhat.com/autobook
=`---d__/
1-gary-strip-target-suffix-from-default-source.patch
Description: application/unknown
Verba Volant
The following email address, [EMAIL PROTECTED] has been removed from the Verba Volant Newsletter list. If you did not cancel your email address or you wish to continue receiving Verba Volant, please send an e-mail to [EMAIL PROTECTED] Thank you and best regards, Verba Volant
[Fwd: Re: m4 from cvs, cygwin]
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Gary V. Vaughan wrote:
|
| | ---
| | When I configured using --enable-static --disable-shared:
| |
| | make install failed (actually, make install DESTDIR=...) because libtool
| | was looking for m4.exe in .libs, even though for static builds, m4.exe
| | is in the main builddir.
| |
| | Note that libtool is not confused about this point during normal
| | builds. I believe the problem is with dlpreopen or dlopen or somesuch.
| | It's a module thing.
|
| Before I can release libtool-1.6, I want dlpreopening to work without .la
| files. It looks like cygwin is hit harder than most, but for this
| particular
| case preloaded modules should just work when I have fixed that.
Ok...
| | ---
| | When I configured using --disable-static --enable-shared:
| |
| | The build did not succeed. Apparently my fix to the global symbols
| | filter wasn't good enough. It's picking up (allowing thru) a whole
| | bunch of symbols that actually come from cygwin1.dll or crt1.o etc.
| | Symbols like __DTOR_LIST__ __RUNTIME_PSEUDO_RELOC_LIST__
| | ___w32_sharedptr _imp__m4_current_file etc.
| |
| | My fix worked in the testcase (mdemo) but...it still needs more work in
| | this torture test. [Later note: on further investigation, it MAY be
| | that somehow the old version of the export_symbols_cmds filter got used.
| | Because this behavior is exactly what I would've expected BEFORE my fix
| | was applied)
|
| Ugh. I don't know the cygwin platform well enough to help you with this
| one,
| but I will gladly apply any patches you find necessary.
I think I should probably try this again, once the libtool/ltdl inside
m4 is more closely synced with the libtool installed on my box...
| | ---
| | When I configured using --enable-static --enable-shared:
| |
| | build and install went okay. But...
| |
| | m4.exe is intrinsically linked to m4-0.dll, traditional-0.dll, and
| | gnu-0.dll, as well as to cygm4-0.dll. But only cygm4-0.dll is installed
| | in ${bindir} -- the others are in libexec/m4 -- which is not in PATH.
|
| Argh! That is definitely all wrong. libtool is supposed to dlpreload
| all of
| those modules without any dependency on the dlls. Is libtool stupidly
| preloading the import libs or something?
probably something like that. There is no testcase in libtool that
explicitly tests preloading. But...
If you configure --enable-shared --disable-static, but dlpreload
certain libraries, is libtool supposed to magically figure out that
THOSE libraries should really be built static [and NOT dynamic?] and
link against the static libs, but all the OTHER libraries should be
dynamic only and NOT static? If not, then in this case you'd still have
dll linkage.
| I have been concentrating on
| getting
| libtool into the right shape to support the next release of m4 for a
| couple of
| months,
which explains my nervousness -- as you don't have a cygwin machine
anymore. And I don't know of anybody but me who would ever just
randomly build the CVS libtool on cygwin and run the testsuite. And
since the testsuite doesn't seem to test the same stuff that m4 exercises...
And worse, it takes over 8 hours to run the testsuite as is on my
machine -- assuming I'm there to dismiss the 'dll not found' WinPopUps
that occur, by design, at several points during the test. Thanks to
Bill Gate's braindeadness, the testsuite is NOT an automated thing on
Windows. Blech.
And never mind the non-deterministic testsuite behavior. :-P
| so I should look at this again in m4 incase some of the
| configury has
| bit rotted.
perhaps. I think you're just finding the broken parts in libtool, not
in m4. Or maybe '...and in m4.'
| | rant
| |
| | 1) the autotools: most importantly autoconf, then automake, then
| | libtool, are KEY portability tools, used to help insure that stuff will
| | actually build on J-Q-random-platform.
|
| Agreed.
|
| | 2) autoconf depends on m4.
|
| Autoconf also depends on itself. It is configured with a configure.ac
| file.
Okay, perhaps I should have said that autoconf USES m4. Which means you
need a working m4 to use autoconf, in order to maintain 'Package X'.
| | 3) m4 now depends on some of the most arcane, poorly supported, dusty
| | corners of libtool.
|
| Not true. M4 depends on some of the newest, most poorly tested, fast
| changing
| parts of libtool.
Not really much consolation, there...
|
| | 4) libtool depends on automake and autoconf
| |
| | 5) which depends on m4, which...
|
| The Autoconf - M4 - Autoconf bootstrap dependency has been around
| forever.
Again, I used the wrong word. What I really meant was not dependency
exactly -- although it applies to a certain extent. What I should have
said was that effective use of libtool (when maintaining package X)
typically requires that automake be used as well -- and always requires
that autoconf be used.
|
| | Do you see the problem here? In the very near future, the
Re: m4 from cvs, cygwin
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
cwilson wrote:
| Gary V. Vaughan wrote:
| | ---
| | When I configured using --disable-static --enable-shared:
| |
| | The build did not succeed. Apparently my fix to the global symbols
| | filter wasn't good enough. It's picking up (allowing thru) a whole
| | bunch of symbols that actually come from cygwin1.dll or crt1.o etc.
| | Symbols like __DTOR_LIST__ __RUNTIME_PSEUDO_RELOC_LIST__
| | ___w32_sharedptr _imp__m4_current_file etc.
| |
| | My fix worked in the testcase (mdemo) but...it still needs more work in
| | this torture test. [Later note: on further investigation, it MAY be
| | that somehow the old version of the export_symbols_cmds filter got
| used.
| | Because this behavior is exactly what I would've expected BEFORE my
| fix
| | was applied)
|
| Ugh. I don't know the cygwin platform well enough to help you with
| this one,
| but I will gladly apply any patches you find necessary.
|
|
| I think I should probably try this again, once the libtool/ltdl inside
| m4 is more closely synced with the libtool installed on my box...
Just sychronised CVS HEADs of M4 and Libtool.
| | ---
| | When I configured using --enable-static --enable-shared:
| |
| | build and install went okay. But...
| |
| | m4.exe is intrinsically linked to m4-0.dll, traditional-0.dll, and
| | gnu-0.dll, as well as to cygm4-0.dll. But only cygm4-0.dll is
| installed
| | in ${bindir} -- the others are in libexec/m4 -- which is not in PATH.
|
| Argh! That is definitely all wrong. libtool is supposed to dlpreload
| all of
| those modules without any dependency on the dlls. Is libtool stupidly
| preloading the import libs or something?
|
|
| probably something like that. There is no testcase in libtool that
| explicitly tests preloading. But...
I ought to try and add one in my copious spare time. :-/
| If you configure --enable-shared --disable-static, but dlpreload
| certain libraries, is libtool supposed to magically figure out that
| THOSE libraries should really be built static [and NOT dynamic?] and
| link against the static libs, but all the OTHER libraries should be
| dynamic only and NOT static? If not, then in this case you'd still have
| dll linkage.
Ah-hah! Quite right, I think you have it. I'll look into this presently.
My guess is that the --disable-static to configure should be ignored by
libtool when it is building preloaded libraries... if it were only that easy :-/
| I have been concentrating on getting
| libtool into the right shape to support the next release of m4 for a
| couple of
| months,
|
| which explains my nervousness -- as you don't have a cygwin machine
| anymore. And I don't know of anybody but me who would ever just
| randomly build the CVS libtool on cygwin and run the testsuite. And
| since the testsuite doesn't seem to test the same stuff that m4
| exercises...
I do have an old PC laying around which I could install cygwin to if it
becomes an issue. I do hope there are more people than we two that care about
libtool working on cygwin enough to at least test the alpha releases?
| And worse, it takes over 8 hours to run the testsuite as is on my
| machine -- assuming I'm there to dismiss the 'dll not found' WinPopUps
| that occur, by design, at several points during the test. Thanks to
| Bill Gate's braindeadness, the testsuite is NOT an automated thing on
| Windows. Blech.
Ah yes, how I remember those heady days :-)
| | 3) m4 now depends on some of the most arcane, poorly supported, dusty
| | corners of libtool.
|
| Not true. M4 depends on some of the newest, most poorly tested, fast
| changing
| parts of libtool.
|
| Not really much consolation, there...
I meant that they are the bits I'm working on, not the bits I've forgotten
about. That should be some consolation!
| | 4) libtool depends on automake and autoconf
| |
| | 5) which depends on m4, which...
|
| The Autoconf - M4 - Autoconf bootstrap dependency has been around
| forever.
|
|
| Again, I used the wrong word. What I really meant was not dependency
| exactly -- although it applies to a certain extent. What I should have
| said was that effective use of libtool (when maintaining package X)
| typically requires that automake be used as well -- and always requires
| that autoconf be used.
But mandating m4-2.0 is some way off. And I am sure there will be some
interrim where having m4-2.x will have advantages, but m4-1.4 will still be
sufficient...
| | Do you see the problem here? In the very near future, the autotools
| | will CEASE TO WORK AT ALL on my platform -- because the new autoconf
| | will require the new m4, and the new m4 DOES NOT WORK on cygwin.
|
| I understand your frustration, and I am just as keen as you that
| autotools
| (including m4) continue to be useful on your platform. I have made a
| point of
| statically linking all of the functionality from m4-1.4 into cvs m4, and
| giving configure options to allow package builders
[Fwd: check_LTLIBRARIES and -module ??]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [I'm forwarding this to the automake list for their consideration, I think that is where the problem lies. You might tell them what version of automake you are using. ~gary] This is part of my Makefile.am for my test directory: ~ check_PROGRAMS = test ~ check_LTLIBRARIES = libtest.la ~ test_SOURCES = ... ~ test_DEPEDENCIES = libtest.la ~ libtest_la_SOURCES = ... ~ libtest_la_LDFLAGS = -module What's above doesn't result in a shared object at all, which is what I would have expected (-module should result in something that can be dlopen()'ed according to the manual). Instead I only get an archive (.a). Modifying the last line to read ~ libtest_la_LDFLAGS = -module -rpath /silly will result in both an archive and a shared object being created. Why didn't the first work the way I wanted? Is -module broken? /M $ libtool --version ltmain.sh (GNU libtool) 1.5.0a (1.1220.2.35 2003/11/12 18:51:58) Debian: 148 $ Copyright (C) 2003 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. - -- Magnus Therning mailto:[EMAIL PROTECTED] +31-40-2745179 http://pww.innersource.philips.com/magnus/ OpenPGP:0x4FBB2C40 Philips, the company that I work for, does not support my idle ramblings. The opposite, it goes without saying, is true as well. - -- ~ ())_. Gary V. Vaughangary@(lilith.warpmail.net|gnu.org) ~ ( '/ Research Scientist http://www.oranda.demon.co.uk ,_()) ~ / )= GNU Hacker http://www.gnu.org/software/libtool \' ` `(_~)_ Tech' Author http://sources.redhat.com/autobook =`---d__/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQE/u7NyFRMICSmD1gYRAj4dAJ4zL8hMAetDmNVbrXRvTQ7NSsGAKQCeMstq p7ZtNQubR8LWOPrmjN1fPwM= =Ex8p -END PGP SIGNATURE-
Re: Makefile dependency
Tom == Tom Tromey [EMAIL PROTECTED] writes: Ralf == Ralf Corsepius [EMAIL PROTECTED] writes: Ralf = automake-1.7's AM_MAINTAINER_MODE deactivates regeneration of Ralf Makefile's. Ralf I am inclined to interpret this as a bug and/or regression from earlier Ralf versions of automake. Tom I agree. Thirded :) (Lulin was taking about changing Makefile.am, though.) I'm installing the following on HEAD and branch-1-7. (Without the test case on branch-1-7, because m4_includes are not tracked.) 2003-11-19 Alexandre Duret-Lutz [EMAIL PROTECTED] * lib/am/configure.am (%MAKEFILE%): Remove %MAINTAINER-MODE%, mistakenly added on 2001-03-05. * tests/remake5.test: New file. * tests/Makefile.am (TESTS): Add remake5.test. Report from Ralf Corsepius. Index: lib/am/configure.am === RCS file: /cvs/automake/automake/lib/am/configure.am,v retrieving revision 1.27 diff -u -r1.27 configure.am --- lib/am/configure.am 17 Nov 2003 09:05:30 - 1.27 +++ lib/am/configure.am 19 Nov 2003 20:02:51 - @@ -58,7 +58,7 @@ ## ./config.status to recreate the lost Makefile. .PRECIOUS: %MAKEFILE% ## This rule remakes the Makefile. -%MAKEFILE%: %MAINTAINER-MODE% %MAKEFILE-DEPS% $(top_builddir)/config.status +%MAKEFILE%: %MAKEFILE-DEPS% $(top_builddir)/config.status ## If Makefile is to be updated because of config.status, then run ## config.status without argument in order to (i) rerun all the ## AC_CONFIG_COMMANDS including those that are not visible to Index: tests/Makefile.am === RCS file: /cvs/automake/automake/tests/Makefile.am,v retrieving revision 1.530 diff -u -r1.530 Makefile.am --- tests/Makefile.am 18 Nov 2003 20:40:48 - 1.530 +++ tests/Makefile.am 19 Nov 2003 20:02:51 - @@ -390,6 +390,7 @@ remake2.test \ remake3.test \ remake4.test \ +remake5.test \ req.test \ reqd.test \ reqd2.test \ Index: tests/remake5.test === RCS file: tests/remake5.test diff -N tests/remake5.test --- /dev/null 1 Jan 1970 00:00:00 - +++ tests/remake5.test 19 Nov 2003 20:02:52 - @@ -0,0 +1,76 @@ +#! /bin/sh +# Copyright (C) 2003 Free Software Foundation, Inc. +# +# This file is part of GNU Automake. +# +# GNU Automake is free software; you can redistribute it and/or modify +# it under the terms of the GNU General Public License as published by +# the Free Software Foundation; either version 2, or (at your option) +# any later version. +# +# GNU Automake is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with Automake; see the file COPYING. If not, write to +# the Free Software Foundation, Inc., 59 Temple Place - Suite 330, +# Boston, MA 02111-1307, USA. + +# Check that AM_MAINTAINER_MODE disable some rebuild rules, +# but not all. +# Report from Ralf Corsepius. + +required=GNUmake +. ./defs || exit 1 + +set -e + +cat configure.in 'EOF' +AM_MAINTAINER_MODE +m4_include(foo.m4) +if test ! -f rebuild_ok; then + ACLOCAL=false + AUTOMAKE=false + AUTOCONF=false +fi +AC_OUTPUT +EOF + +: foo.m4 +: Makefile.am + +$ACLOCAL +$AUTOCONF +$AUTOMAKE --add-missing +./configure +$MAKE + +# Make sure the rules to rebuild configure/Makefile.in are not +# triggered by default. ($MAKE will fail if they are, because the +# tools are set to false.) +$sleep +touch aclocal.m4 Makefile.am configure.in foo.m4 +$MAKE + +# Make sure the rebuild rule for Makefile is triggered. +$sleep +echo '# GrEpMe' Makefile.in +$MAKE +grep GrEpMe Makefile + +# Make sure the rebuild rule for config.status is triggered. +$sleep +grep 'AUTOCONF.*=.*false' Makefile +: rebuild_ok +./configure --no-create +$MAKE +grep 'AUTOCONF.*=.*false' Makefile exit 1 + +# Make sure rebuild rules do work if --enable-maintainer-mode is given. +./configure --enable-maintainer-mode +$sleep +echo 'AC_SUBST([YIPPY_YIPPY_YEAH])' foo.m4 +$MAKE +grep YIPPY_YIPPY_YEAH Makefile -- Alexandre Duret-Lutz
Non-recursive make intermediate objects
Using Automake 1.7.9, I am attempting to create a single Makefile.am which is capable of building all of the libraries used by the project. The source files to the project are located in subdirectories, and the output libraries should also be located in subdirectories. The objective is to replace an existing recursive build. Using a rule like: noinst_LIBRARIES = libs/somedir/libfoo.a libs_somedir_libfoo_a_SOURCES=foo.cc and then inpecting the output of 'make -n' (and the generated Makefile), I see evidence that the build will put all .Po files in a .deps subdirectory under the Makefile.am, and all the .o files in the same directory as Makefile.am. This approach seems quite wrong to me since it is quite possible that libraries and applications may use similarly named source files. Intermediate files should be placed either under the directory where the library is placed, or in the directory where the source files live. An even better solution would allow the user to specify where intermediate files are placed on a per-library and per application basis. Is there a way to convince Automake to behave more usefully? Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen
Re: Non-recursive make intermediate objects
On Thu, 2003-11-20 at 09:04, Bob Friesenhahn wrote: Using Automake 1.7.9, I am attempting to create a single Makefile.am which is capable of building all of the libraries used by the project. The source files to the project are located in subdirectories, and the output libraries should also be located in subdirectories. The objective is to replace an existing recursive build. Using a rule like: noinst_LIBRARIES = libs/somedir/libfoo.a libs_somedir_libfoo_a_SOURCES=foo.cc and then inpecting the output of 'make -n' (and the generated Makefile), I see evidence that the build will put all .Po files in a .deps subdirectory under the Makefile.am, and all the .o files in the same directory as Makefile.am. This approach seems quite wrong to me since it is quite possible that libraries and applications may use similarly named source files. Intermediate files should be placed either under the directory where the library is placed, or in the directory where the source files live. An even better solution would allow the user to specify where intermediate files are placed on a per-library and per application basis. subdir_objects in your automake options. Problem is, there is a design headache that makes recursive clean fail with this approach - I forget the bug #, but it's on my todo, waay down there :p. Rob
Re: Non-recursive make intermediate objects
On Thu, 20 Nov 2003, Robert Collins wrote: subdir_objects in your automake options. Problem is, there is a design headache that makes recursive clean fail with this approach - I forget the bug #, but it's on my todo, waay down there :p. Ahhh, subdir-objects. Since this is so important to non-recursive makes, it would be useful if it was referenced in the An Alternative Approach to Subdirectories section of the documentation. Please move the clean bug up in the priority level. Automake has a non-recursive user now. :-) I suspect/believe that libtool will have some problems as well. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen
Re: Non-recursive make intermediate objects
Bob Friesenhahn wrote: Please move the clean bug up in the priority level. Automake has a non-recursive user now. :-) More than one :-) My project also uses non-recursive Makefile to build a bunch of libraries (one normal, about 30 plugin modules) and a couple of other directories of executables, as well as includes and documentation.
