non-recursive automake with make 3.81,automake-1.10
Hello friends, In my laptop, I can very well use autotools with the following Makefile.am : bin_PROGRAMS = scasr scasr_SOURCES = src/main.f90\ src/constants.f90 src/environment.f90 src/util.f90 \ src/init.f90 src/constants.o : src/constants.f90 src/environment.o : src/environment.f90 src/init.o : src/init.f90 src/util.o src/constants.o src/main.o : src/main.f90 src/init.o src/constants.o src/environment.o src/util.o : src/util.f90 src/constants.o scasr_LDADD = EXTRA_DIST= autogen.sh CLEANFILES =*.mod In My laptop, I have: $ autoconf --version autoconf (GNU Autoconf) 2.69 $ automake --version automake (GNU automake) 1.13.4 $ make -v GNU Make 3.82 But, in the running environment, with SUSE Linux Enterprise Desktop 11 SP2, I have: $autoconf --version autoconf (GNU Autoconf) 2.63 $automake --version automake (GNU automake) 1.10.1 $make --version GNU Make 3.81 the same thing is giving error: $make make all-am make[1]: Entering directory `/home/physics/phslav/trunk' make[1]: *** No rule to make target `main.o', needed by `scasr'. Stop. make[1]: Leaving directory `/home/physics/phslav/trunk' I am concluding either automake or make is too old to handle non-recursive makefile. Is this correct? Or, in my Makefile.am itself is causing the error(may be with some non-standard)?
Re: non-recursive automake with make 3.81,automake-1.10
Hi, On 2013-07-26 16:53 +0100, Rudra Banerjee wrote: Hello friends, In my laptop, I can very well use autotools with the following Makefile.am : bin_PROGRAMS = scasr scasr_SOURCES = src/main.f90\ src/constants.f90 src/environment.f90 src/util.f90 \ src/init.f90 src/constants.o : src/constants.f90 src/environment.o : src/environment.f90 src/init.o : src/init.f90 src/util.o src/constants.o src/main.o : src/main.f90 src/init.o src/constants.o src/environment.o src/util.o : src/util.f90 src/constants.o [...] But, in the running environment, with SUSE Linux Enterprise Desktop 11 SP2, I have: $autoconf --version autoconf (GNU Autoconf) 2.63 $automake --version automake (GNU automake) 1.10.1 $make --version GNU Make 3.81 the same thing is giving error: [...] I am concluding either automake or make is too old to handle non-recursive makefile. Is this correct? Or, in my Makefile.am itself is causing the error(may be with some non-standard)? The release notes for Automake 1.11 say: subdir-object mode works now with Fortran ... Your Makefile is clearly depends on the subdir-object feature (typical for non-recursive setups), so it appears that you must require Automake 1.11 at minimum. Your SUSE install only has Automake 1.10.1. This is normally not a huge problem as it is normally only necessary to run automake when (re)generating the build system; this is not something users building from a release tarball will ordinarily need to do. Hope that helps, -- Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)
Re: Non-recursive automake and double-colon rules
On 2013-03-24 11:33 +, Roger Leigh wrote: If you switch to non-recursive make (i.e. no use of SUBDIRS), but you want to use include to retain Makefile.ams in subdirectories, you end up running into problems when you have multiple copies of -local and -hook rules. [...] I've used GNU make double-colon rules to allow the same target to be used multiple times. While this is GNU make-specific, it's a simple and effective way to convert an existing recursive automake setup to being nonrecursive. Possibly worth putting in the documentation (along with a portability caveat?) I'd be interested to know what other people's experiences have been here. While I could move everything into the top-level Makefile.am, keeping rules together with the files they operate on does have some advantages. The way I normally handle this is to not add commands directly to the -hook or -local rules, but instead to create new rules with commands and list them as prerequisites to the appropriate -hook or -local rules. This does not depend on GNU make. For example: all-local: extra-stuff extra-stuff: echo hello Looking at the GNU make manual, it looks like double-colon rules have an ordering to them; the above approach does not (and, in fact, allows the different rules to be run in parallel). So it may also be necessary to add prerequisites between the individual rules-with-commands as well. Cheers, -- Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)
Non-recursive automake and double-colon rules
Hi, Just a suggestion for the documentation: If you switch to non-recursive make (i.e. no use of SUBDIRS), but you want to use include to retain Makefile.ams in subdirectories, you end up running into problems when you have multiple copies of -local and -hook rules. For example, I have % grep include Makefile.am include $(top_srcdir)/scripts/global.mk include $(top_srcdir)/scripts/git-dist.mk include etc/Makefile.am include etc/pam/Makefile.am include etc/setup.d/Makefile.am include etc/bash_completion/Makefile.am include contrib/setup.d/Makefile.am include doc/Makefile.am include doc/historical/Makefile.am include man/Makefile.am include sbuild/Makefile.am include bin/schroot-listmounts/Makefile.am include bin/dchroot-dsa/Makefile.am include bin/csbuild/Makefile.am include bin/dchroot/Makefile.am include bin/schroot-sbuild/Makefile.am include bin/schroot-releaselock/Makefile.am include bin/schroot-base/Makefile.am include bin/schroot-mount/Makefile.am include bin/schroot/Makefile.am include test/Makefile.am % git grep -E '(-hook|-local):' Makefile.am:dist-hook:: bin/csbuild/Makefile.am:install-exec-hook:: bin/dchroot-dsa/Makefile.am:install-exec-hook:: bin/dchroot/Makefile.am:install-exec-hook:: bin/schroot-sbuild/Makefile.am:install-exec-hook:: bin/schroot/Makefile.am:install-exec-hook:: bin/schroot/Makefile.am:install-data-hook:: doc/Makefile.am:clean-local:: etc/Makefile.am:all-local:: profiles etc/Makefile.am:install-data-hook:: etc/Makefile.am:clean-local:: etc/setup.d/Makefile.am:install-exec-hook:: man/Makefile.am:clean-local:: man/Makefile.am:all-local:: man-update-po $(TRANSMAN) man/Makefile.am:dist-hook:: man-update-po test/Makefile.am:clean-local:: I've used GNU make double-colon rules to allow the same target to be used multiple times. While this is GNU make-specific, it's a simple and effective way to convert an existing recursive automake setup to being nonrecursive. Possibly worth putting in the documentation (along with a portability caveat?) I'd be interested to know what other people's experiences have been here. While I could move everything into the top-level Makefile.am, keeping rules together with the files they operate on does have some advantages. What about po/Makefile.in.in? Is there a nonrecursive variant of this available? The nonrecursive build is massively faster than the old recursive build, so quite a worthwhile improvement for this project! Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800
Re: GSoC project idea: non-recursive automake project
Harlan Stenn st...@ntp.org writes: Larry McVoy once said something like In theory, theory and practice are the same. But in practice, they are not. Maybe he did say that at some point, but it's a hoary old quote (attributed to Yogi Berra, among others), and certainly didn't originate with Larry... -Miles -- Love is a snowmobile racing across the tundra. Suddenly it flips over, pinning you underneath. At night the ice weasels come. --Nietzsche
Re: GSoC project idea: non-recursive automake project
Nick Bowler nbow...@elliptictech.com writes: * Modify gnulib so that it can be easily integrated into a non-recursive automake setup. One could look to libltdl for inspiration here. It doesn't have to be modified. An Automake setup can easily and usefully contain a mix of recursive and non-recursive subdirectories. -- Ben Pfaff http://benpfaff.org
Re: GSoC project idea: non-recursive automake project
On 2011-03-22 07:36 -0700, Ben Pfaff wrote: Nick Bowler nbow...@elliptictech.com writes: * Modify gnulib so that it can be easily integrated into a non-recursive automake setup. One could look to libltdl for inspiration here. It doesn't have to be modified. An Automake setup can easily and usefully contain a mix of recursive and non-recursive subdirectories. Sorry, I meant integrated in a manner such that the gnulib bits are built non-recursively. While you can of course use a recursive make to build gnulib, you still tend to be left with the usual problems that plague recursive builds: specifically that dependencies between the subtrees using separate makefiles tend to be incomplete, resulting in reduced concurrency and/or incorrect builds. A recursively-built gnulib is no exception here. -- Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)
Re: GSoC project idea: non-recursive automake project
On Mon, Mar 21, 2011 at 3:09 PM, Nick Bowler nbow...@elliptictech.com wrote: * Modify gnulib so that it can be easily integrated into a non-recursive automake setup. One could look to libltdl for inspiration here. How about modifying GCC. That should take some time, I think :) :) :)
Re: GSoC project idea: non-recursive automake project
On Mon, Mar 21, 2011 at 11:49:39AM -0400, NightStrike wrote: On Sat, Mar 19, 2011 at 3:45 PM, Harlan Stenn st...@ntp.org wrote: Pippijn wrote: On Fri, Mar 18, 2011 at 05:26:58PM -0700, Harlan Stenn wrote: If there was a student interested in showing how easy it was to use automake to do non-recursive Makefiles for a project, I'd be willing to co-mentor and work with them to convert NTP to that sort of operation. It's mostly trivial. How hard are GSoC projects supposed to be? I'll assume you have seen my reply to Ralf. From my POV, I have heard folks saying for a long time how easy it is to use automake to produce non-recursive Makefiles. But I haven't seen this in practice, and on the (few) attempts I have made to figure it out myself and look for examples, I have not yet been able to find a really useful solution. A solution to *what* exactly? Said another way, what *exactly* is the problem with automake+non-recursion that you would want solved? I personally have found that the only obstacle to me is minor -- all sources have to be specified relative to the top level directory, even in a subdir Makefile fragment that gets included in the top. Surely even this is a solvable problem. Can't automake rewrite the relative paths to be absolute? Obviously this wouldn't necessarily work for some complex custom rules, but in the general case it would be a big bonus. It would also mean that any variables such as foo_SOURCES in a subdirectory could have the absolute path prefixed to all the files on inclusion, which would mean I could convert to using a single top-level Makefile and keep all the separate Makefile.ams in the subdirectories, where it makes sense to have them alongside the code they build. I certainly wouldn't be averse to rewriting any custom rules to gain this. I've wanted something like this for years, in fact. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. signature.asc Description: Digital signature
Re: GSoC project idea: non-recursive automake project
On 2011-03-19 12:07 +0100, Ralf Wildenhues wrote: Maybe such a proposal could be enhanced to avoid having not enough work: [...] This way the student will not get bored. However, it might be harder to define specific goals to achieve, or to define success in the end. I have two suggestions which could be part of a GSoC project about non-recursive automake. I have no idea what the scope of these are. * Modify automake so that package authors can specify source files more easily in a non-recursive setup. Currently, the full path from the top of the source tree must be specified for every source file. Some ideas for how to go about this can be found in the mailing list archives. A successful solution here should allow a project with a well-written, non-recursive Makefile.am to rearrange their directory structure while only requiring relatively minor changes to Makefile.am. * Modify gnulib so that it can be easily integrated into a non-recursive automake setup. One could look to libltdl for inspiration here. -- Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)
Re: GSoC project idea: non-recursive automake project
On Mon, Mar 21, 2011 at 7:36 PM, Roger Leigh rle...@codelibre.net wrote: Can't automake rewrite the relative paths to be absolute? This would break things, for example when using WINE via wrapper scripts, require fixed srcdir pathes... oki, Steffen
Re: GSoC project idea: non-recursive automake project
Hello Pippijn, * Pippijn van Steenhoven wrote on Sat, Mar 19, 2011 at 10:47:35AM CET: On Sat, Mar 19, 2011 at 10:38:39AM +0100, Pippijn van Steenhoven wrote: On Fri, Mar 18, 2011 at 05:26:58PM -0700, Harlan Stenn wrote: If there was a student interested in showing how easy it was to use automake to do non-recursive Makefiles for a project, I'd be willing to co-mentor and work with them to convert NTP to that sort of operation. It's mostly trivial. How hard are GSoC projects supposed to be? Being a student, I'd be willing to prove it ;) If you would like to apply as student for this GSoC project, can you please formulate a project proposal (as is needed for a GSoC application anyway) and post it here? Please take into account what else was said in this thread about having enough work for a SoC term. (We can help with more ideas about how one could extend Automake if that's unclear.) Harlan's description of the task will soon appear in the archives of http://lists.gnu.org/archive/html/summer-of-code/2011-03/threads.html and eventually also on http://www.gnu.org/software/soc-projects/ideas-2011.html but it is still fairly vague. Then, I remember reading you on this list before, but not yet much in a development role. I have no idea whether you know the autotools code or NTP well. Now, I don't want to put you on the spot, and prior development experience is not a requirement for GSoC applications, but if your proposal is going to encompass hacking on NTP and/or Autotools, it would help to see or be able to judge your coding and working together skills in some way or other. You could help us with something like looking at the debbugs for Automake and working on some bug (or even just outlining strategies to do so); or addressing an issue that somebody reported on the mailing list; or enhancing the documentation in some way; or similar for NTP. There's no need for you to find out everything (or even much) yourself. In fact, if you ask questions on the way, that will probably make things easier for us. If you don't see something feasible to do, we can probably also come up with a small (maybe 1-2 hr) task. Finally, I should add that I'm off-list for the second half of this week (starting Wednesday; but I should be back sometime next weekend) and otherwise usually read mails twice a day, so expect some latency. Thanks, Ralf
Re: GSoC project idea: non-recursive automake project
On 03/19/2011 01:45 PM, Harlan Stenn wrote: Pippijn wrote: On Fri, Mar 18, 2011 at 05:26:58PM -0700, Harlan Stenn wrote: If there was a student interested in showing how easy it was to use automake to do non-recursive Makefiles for a project, I'd be willing to co-mentor and work with them to convert NTP to that sort of operation. It's mostly trivial. How hard are GSoC projects supposed to be? I'll assume you have seen my reply to Ralf. From my POV, I have heard folks saying for a long time how easy it is to use automake to produce non-recursive Makefiles. But I haven't seen this in practice, and on the (few) attempts I have made to figure it out myself and look for examples, I have not yet been able to find a really useful solution. What I think we'd want is a reasonably well-documented description of how to use automake to produce a source tree where one can: - run make from the top-level of the tree and all of the normal things happen (and all of the normal targets work) - run make from a subdir, which would handle all of the normal targets for that subdir, and would also automatically handle *all* of the dependencies needed for the specified targets in that subdir (like prerequisite libraries). I'd be *very* interested to see how this second item is done. One of the inherent benefits of recursive make is that there's a self-contained Makefile in each directory. Thus, you can run make from that directory. I'm wondering how you do that with only one top-level Makefile. --john
Re: GSoC project idea: non-recursive automake project
Hi Harlan, * Harlan Stenn wrote on Sat, Mar 19, 2011 at 01:26:58AM CET: If there was a student interested in showing how easy it was to use automake to do non-recursive Makefiles for a project, I'd be willing to co-mentor and work with them to convert NTP to that sort of operation. Thanks for the co-mentoring offer and the SoC idea! I have a question though: how much work do you expect this to be? Haven't looked at NTP in a long time, but typically, turning a project into non-recursive was either a straightforward to trivial task of maybe 1-2 days for somebody experienced with autotools, or something difficult to impossible due to limitations in either of Make, Automake, or third-party bits. Maybe such a proposal could be enhanced to avoid having not enough work: For example, while converting NTP, the student could start a document with a general recipe for this conversion. And then maybe try it out on a couple more projects, and possibly refine the recipe along the way. For students that get very far, they could also try working on limitations in other tools should they come across them. This way the student will not get bored. However, it might be harder to define specific goals to achieve, or to define success in the end. Would you be willing to formulate this as a proposal for the GNU proposals wiki page? I should note that I certainly don't have unlimited mentoring time. I expect to be able to mentor one student, and I'm sure co- or backup- mentoring beside that should be possible, but if we can find another person to help that would only be good. Cheers, Ralf
Re: GSoC project idea: non-recursive automake project
On Sat, Mar 19, 2011 at 10:38:39AM +0100, Pippijn van Steenhoven wrote: On Fri, Mar 18, 2011 at 05:26:58PM -0700, Harlan Stenn wrote: If there was a student interested in showing how easy it was to use automake to do non-recursive Makefiles for a project, I'd be willing to co-mentor and work with them to convert NTP to that sort of operation. It's mostly trivial. How hard are GSoC projects supposed to be? Being a student, I'd be willing to prove it ;) -- Pippijn van Steenhoven signature.asc Description: Digital signature
Re: GSoC project idea: non-recursive automake project
On Fri, Mar 18, 2011 at 05:26:58PM -0700, Harlan Stenn wrote: If there was a student interested in showing how easy it was to use automake to do non-recursive Makefiles for a project, I'd be willing to co-mentor and work with them to convert NTP to that sort of operation. It's mostly trivial. How hard are GSoC projects supposed to be? -- Pippijn van Steenhoven signature.asc Description: Digital signature
Re: GSoC project idea: non-recursive automake project
On Sat, Mar 19, 2011 at 10:38:39AM +0100, Pippijn van Steenhoven wrote: On Fri, Mar 18, 2011 at 05:26:58PM -0700, Harlan Stenn wrote: If there was a student interested in showing how easy it was to use automake to do non-recursive Makefiles for a project, I'd be willing to co-mentor and work with them to convert NTP to that sort of operation. It's mostly trivial. How hard are GSoC projects supposed to be? Ok, having taken a glance at the NTP Makefiles, I have to correct that. It's trivial to do it, but a little less so to do it right, making sure it works just like before. I'm still willing to do the project. -- Pippijn van Steenhoven signature.asc Description: Digital signature
Re: GSoC project idea: non-recursive automake project
Hi Ralf, Ralf wrote: * Harlan Stenn wrote on Sat, Mar 19, 2011 at 01:26:58AM CET: If there was a student interested in showing how easy it was to use automake to do non-recursive Makefiles for a project, I'd be willing to co-mentor and work with them to convert NTP to that sort of operation. Thanks for the co-mentoring offer and the SoC idea! I have a question though: how much work do you expect this to be? Haven't looked at NTP in a long time, but typically, turning a project into non-recursive was either a straightforward to trivial task of maybe 1-2 days for somebody experienced with autotools, or something difficult to impossible due to limitations in either of Make, Automake, or third-party bits. If my goal was only to get a basic non-recursive Makefile setup going for NTP, then yeah, I think it might be fairly easy. Larry McVoy once said something like In theory, theory and practice are the same. But in practice, they are not. There are various use cases that should be explored - running make from the top-level, running make from a subdir where a specific target is asked to be built, etc. The description, choices, and options should all be documented. Maybe such a proposal could be enhanced to avoid having not enough work: For example, while converting NTP, the student could start a document with a general recipe for this conversion. And then maybe try it out on a couple more projects, and possibly refine the recipe along the way. For students that get very far, they could also try working on limitations in other tools should they come across them. This way the student will not get bored. However, it might be harder to define specific goals to achieve, or to define success in the end. Yes, and I'd look at making it 'go' on NTP be part of the proof-of-concept that we had a reasonably robust design with adequate documentation. Would you be willing to formulate this as a proposal for the GNU proposals wiki page? I think so, yes. My problem is that I will only have a few hours' time to work on this between now and this Monday, and I will probably have no time from this Tuesday until the following Monday. I should note that I certainly don't have unlimited mentoring time. I expect to be able to mentor one student, and I'm sure co- or backup- mentoring beside that should be possible, but if we can find another person to help that would only be good. Yup, I suspect I'll be at my maximum load for GSoC this year, too. H
Re: GSoC project idea: non-recursive automake project
Pippijn wrote: On Fri, Mar 18, 2011 at 05:26:58PM -0700, Harlan Stenn wrote: If there was a student interested in showing how easy it was to use automake to do non-recursive Makefiles for a project, I'd be willing to co-mentor and work with them to convert NTP to that sort of operation. It's mostly trivial. How hard are GSoC projects supposed to be? I'll assume you have seen my reply to Ralf. From my POV, I have heard folks saying for a long time how easy it is to use automake to produce non-recursive Makefiles. But I haven't seen this in practice, and on the (few) attempts I have made to figure it out myself and look for examples, I have not yet been able to find a really useful solution. What I think we'd want is a reasonably well-documented description of how to use automake to produce a source tree where one can: - run make from the top-level of the tree and all of the normal things happen (and all of the normal targets work) - run make from a subdir, which would handle all of the normal targets for that subdir, and would also automatically handle *all* of the dependencies needed for the specified targets in that subdir (like prerequisite libraries). H
Re: GSoC project idea: non-recursive automake project
Pippijn wrote: On Sat, Mar 19, 2011 at 10:38:39AM +0100, Pippijn van Steenhoven wrote: On Fri, Mar 18, 2011 at 05:26:58PM -0700, Harlan Stenn wrote: If there was a student interested in showing how easy it was to use automake to do non-recursive Makefiles for a project, I'd be willing to co-mentor and work with them to convert NTP to that sort of operation. It's mostly trivial. How hard are GSoC projects supposed to be? Being a student, I'd be willing to prove it ;) I'm happy to participate on this one, too. H
GSoC project idea: non-recursive automake project
If there was a student interested in showing how easy it was to use automake to do non-recursive Makefiles for a project, I'd be willing to co-mentor and work with them to convert NTP to that sort of operation. -- Harlan Stenn st...@ntp.org http://ntpforum.isc.org - be a member!
Non-recursive automake vs. gettext
Hi Ralf and others,
I like to use a non-recursive makefile structure for my projects. However, if
the project also uses gettext, I end up having to constantly fight against both
gettext and auto{conf,make}.
If AM_GNU_GETTEXT appears in the configure.ac file, then automake refuses to
run, but gives the error:
configure.ac:336: required file `po/Makefile.in' not found
Makefile.am:5: AM_GNU_GETTEXT used but `po' not in SUBDIRS
There are ways to circumvent this of course. But I think that automake should
not do this if subdir-options is specified in AUTOMAKE_OPTIONS
Regards,
John
--
PGP Public key ID: 1024D/2DE827B3
fingerprint = 8797 A26D 0854 2EAB 0285 A290 8A67 719C 2DE8 27B3
See http://pgp.mit.edu or any PGP keyserver for public key.
signature.asc
Description: Digital signature
Re: Non-recursive automake vs. gettext
Hi John,
* John Darrington wrote on Wed, Feb 09, 2011 at 07:56:20PM CET:
I like to use a non-recursive makefile structure for my projects.
However, if the project also uses gettext, I end up having to
constantly fight against both gettext and auto{conf,make}.
If AM_GNU_GETTEXT appears in the configure.ac file, then automake
refuses to run, but gives the error:
configure.ac:336: required file `po/Makefile.in' not found
Makefile.am:5: AM_GNU_GETTEXT used but `po' not in SUBDIRS
There are ways to circumvent this of course. But I think that
automake should not do this if subdir-options is specified in
AUTOMAKE_OPTIONS
Agreed.
It might be worth fixing this. Even better would be if we got around to
implementing Bruno's proposal to move gettext's configury stuff to
Automake (as documented and tested in the pot-primary git branch).
That could fix this, and at the same time make several other issues go
away.
If somebody wants to beat me on this, I'd be delighted.
Thanks for the bug report,
Ralf
Re: Non-recursive automake
Hello, * Jan Engelhardt wrote on Sat, Oct 17, 2009 at 07:04:39PM CEST: when one decides to drive make in a non-recursive fashion, one has to write an Automake file like this: lib_LTLIBRARIES = foo/bar.la foo_bar_la_SOURCES = foo/one.c foo/two.c Usually I stuff that into a file called foo/Automakefile and include foo/Automakefile from the real Makefile.am. Despite being in a subdirectory, one may not omit foo/; that is ok. However, it is tiresome. Is there perhaps a way, or a planned development action, so that one can omit all foo/s inside foo/Automakefile and have automake automatically add foo/ upon seeing include (or a variant thereof) in the upper Makefile.am? Yes. The latest plan I couldn't get stabilized so left out for 1.11: http://thread.gmane.org/gmane.comp.sysutils.automake.general/9824/focus=9920 It would be a good idea to look at it again, though. Also, when subdir-objects is in effect, it will create odd long names such as foo/foo_bar_la-one.o where at least the foo_ prefix would be redundant in some cases. That might be worth thinking about, yes. Thanks. * Bob Friesenhahn wrote on Sun, Oct 18, 2009 at 03:09:08AM CEST: I complained about this perhaps five years ago since it is the most annoying issue related to non-recursive build. There was some discussion on this list at that time but nothing was done to make things better. Also, your pay check never made it to this side of the ocean. ;-) It seems that a problem is that much of the Makefile.am file is simply copied to the output Makefile.in and so these parts would need to be re-written rather than copied. The good news is that perl is good at re-writing text. The bad part is that whenever we rewrite, we introduce a chance to destroy. Experience tells me Automake should not rewrite arbitrary text, that has led to too many problems already. * Robert Collins wrote on Sun, Oct 18, 2009 at 03:34:20AM CEST: The way I tackled this in my proof of concept in 2001 was via a rewriting include: http://sources.redhat.com/ml/automake/2001-08/msg00112.html This added a new directive 'subdir_include' which does an include but adjusts all the paths in the make/automake rules in the included fragment to the relative path to the included rules. The devil is in the details. What about -I paths in *_CPPFLAGS? What with substituted variables? What about rewritten variable names, such as: libfoo_la_SOURCES becomes sub_libfoo_la_SOURCES, and what if the user references $(libfoo_la_SOURCES) elsewhere, say, in libbar_la_SOURCES? No. Search for several prior discussions on the Automake lists for why this cannot be done safely without highly altering the set of allowed semantics, and things the user can expect. Cheers, Ralf
Re: Non-recursive automake
On Sun, 2009-10-18 at 08:39 +0200, Ralf Wildenhues wrote: http://sources.redhat.com/ml/automake/2001-08/msg00112.html This added a new directive 'subdir_include' which does an include but adjusts all the paths in the make/automake rules in the included fragment to the relative path to the included rules. The devil is in the details. What about -I paths in *_CPPFLAGS? What with substituted variables? What about rewritten variable names, such as: libfoo_la_SOURCES becomes sub_libfoo_la_SOURCES, and what if the user references $(libfoo_la_SOURCES) elsewhere, say, in libbar_la_SOURCES? No. Search for several prior discussions on the Automake lists for why this cannot be done safely without highly altering the set of allowed semantics, and things the user can expect. I'll take it on faith; I must have missed those discussions (there was a period while I didn't receive forwarded mail from my old cygwin address before I resubscribed). Regardless, if something usable is added, +1. -Rob signature.asc Description: This is a digitally signed message part
Non-recursive automake
Hi, when one decides to drive make in a non-recursive fashion, one has to write an Automake file like this: lib_LTLIBRARIES = foo/bar.la foo_bar_la_SOURCES = foo/one.c foo/two.c Usually I stuff that into a file called foo/Automakefile and include foo/Automakefile from the real Makefile.am. Despite being in a subdirectory, one may not omit foo/; that is ok. However, it is tiresome. Is there perhaps a way, or a planned development action, so that one can omit all foo/s inside foo/Automakefile and have automake automatically add foo/ upon seeing include (or a variant thereof) in the upper Makefile.am? Also, when subdir-objects is in effect, it will create odd long names such as foo/foo_bar_la-one.o where at least the foo_ prefix would be redundant in some cases. Jan
Re: Non-recursive automake
On Sat, 17 Oct 2009, Jan Engelhardt wrote: when one decides to drive make in a non-recursive fashion, one has to write an Automake file like this: lib_LTLIBRARIES = foo/bar.la foo_bar_la_SOURCES = foo/one.c foo/two.c Usually I stuff that into a file called foo/Automakefile and include foo/Automakefile from the real Makefile.am. Despite being in a subdirectory, one may not omit foo/; that is ok. However, it is tiresome. Is there perhaps a way, or a planned development action, so that one can omit all foo/s inside foo/Automakefile and have automake automatically add foo/ upon seeing include (or a variant thereof) in the upper Makefile.am? I complained about this perhaps five years ago since it is the most annoying issue related to non-recursive build. There was some discussion on this list at that time but nothing was done to make things better. It seems that a problem is that much of the Makefile.am file is simply copied to the output Makefile.in and so these parts would need to be re-written rather than copied. The good news is that perl is good at re-writing text. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: Non-recursive automake
On Sat, 2009-10-17 at 20:09 -0500, Bob Friesenhahn wrote: I complained about this perhaps five years ago since it is the most annoying issue related to non-recursive build. There was some discussion on this list at that time but nothing was done to make things better. It seems that a problem is that much of the Makefile.am file is simply copied to the output Makefile.in and so these parts would need to be re-written rather than copied. The good news is that perl is good at re-writing text. The way I tackled this in my proof of concept in 2001 was via a rewriting include: http://sources.redhat.com/ml/automake/2001-08/msg00112.html This added a new directive 'subdir_include' which does an include but adjusts all the paths in the make/automake rules in the included fragment to the relative path to the included rules. e.g. subdir_include foo/Makefile.am would prepend 'foo' to the paths in foo/Makefile.am. Automake's core has probably changed so much that the patch is not worth even reading, but the concept worked tolerably well ;). -Rob signature.asc Description: This is a digitally signed message part
Re: Trouble w/ distcleaning vpath builds of elisp files using non-recursive automake
Hello Elias, * Elias Pipping wrote on Fri, Sep 25, 2009 at 03:19:03PM CEST: I've come across a problem w/ running distclean for vpath builds of elisp files when using non-recursive automake. Thanks for the report and the example package; confirmed. You can work around the issue by setting DISTCLEANFILES. There are more bugs in the lisp handling in this setup: make all make all isn't a no-op in the second invocation. Cheers, Ralf
Re: AC_LIBOBJ(subdir/file) doesn't work with non-recursive automake
Hello Russ, On Sun, Apr 23, 2006 at 12:09:22AM -0700, Russ Allbery wrote: An even better solution would be for Automake to pay attention to AC_CONFIG_LIBOBJ_DIR and look for AC_LIBOBJ files there. This is already fixed in CVS Automake. It needs CVS Autoconf though. And the LIBOBJDIR feature is somewhat, erm, controversial. Oh well. I hope this does end up being supported, since it's the only way that I see to make non-recursive builds work nicely with AC_LIBOBJ. well, it was me who created the controversy here. :-) I presume you use AC_CONFIG_LIBOBJ_DIR to specify a certain directory, and then you call AC_LIBOBJ with object names (without any directory components). Then you use LIBOBJS or LTLIBOBJS in the top directory. I think there is no doubt this should be supported. The controversy is about implementation: current implementation uses variable LIBOBJDIR to prepent the path, while I proposed that ./configure would insert the directory part to the substituted value of (LT)LIBOBJS. It is possible that Autoconf/Automake will support multiple libobj directories on future; in that case, the two possible implications will have consequences for the shape of that support. But the basic use case for AC_CONFIG_LIBOBJ_DIR shall continue to work in either case. Hope this explanation helps, Stepan Kasal
Re: AC_LIBOBJ(subdir/file) doesn't work with non-recursive automake
Stepan Kasal [EMAIL PROTECTED] writes: well, it was me who created the controversy here. :-) I presume you use AC_CONFIG_LIBOBJ_DIR to specify a certain directory, and then you call AC_LIBOBJ with object names (without any directory components). Then you use LIBOBJS or LTLIBOBJS in the top directory. That was the goal, yes. I think there is no doubt this should be supported. The controversy is about implementation: current implementation uses variable LIBOBJDIR to prepent the path, while I proposed that ./configure would insert the directory part to the substituted value of (LT)LIBOBJS. It is possible that Autoconf/Automake will support multiple libobj directories on future; in that case, the two possible implications will have consequences for the shape of that support. But the basic use case for AC_CONFIG_LIBOBJ_DIR shall continue to work in either case. Oh, excellent. Then I will look forward with great eagerness to the next releases of Autoconf and Automake, and in the meantime continue to apply my patch to work around the problem. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: AC_LIBOBJ(subdir/file) doesn't work with non-recursive automake
Hi Russ, * Russ Allbery wrote on Sun, Apr 23, 2006 at 04:05:11AM CEST: AC_LIBOBJ([util/snprintf]) configure.ac:25: required file `./util/snprintf.c' not found I think it wasn't intended that AC_LIBOBJ ever be called with something other than a plain name (i.e., no directory components). Not totally sure here, though. An even better solution would be for Automake to pay attention to AC_CONFIG_LIBOBJ_DIR and look for AC_LIBOBJ files there. This is already fixed in CVS Automake. It needs CVS Autoconf though. And the LIBOBJDIR feature is somewhat, erm, controversial. Oh well. Cheers, Ralf
Re: AC_LIBOBJ(subdir/file) doesn't work with non-recursive automake
Ralf Wildenhues [EMAIL PROTECTED] writes: * Russ Allbery wrote on Sun, Apr 23, 2006 at 04:05:11AM CEST: AC_LIBOBJ([util/snprintf]) configure.ac:25: required file `./util/snprintf.c' not found I think it wasn't intended that AC_LIBOBJ ever be called with something other than a plain name (i.e., no directory components). Not totally sure here, though. With this patch, everything (Autoconf and Automake both) seems to work fine, although of course without AC_CONFIG_LIBOBJ_DIR working, the Autoconf macros that call AC_LIBOBJ internally don't do the right thing. An even better solution would be for Automake to pay attention to AC_CONFIG_LIBOBJ_DIR and look for AC_LIBOBJ files there. This is already fixed in CVS Automake. It needs CVS Autoconf though. And the LIBOBJDIR feature is somewhat, erm, controversial. Oh well. I hope this does end up being supported, since it's the only way that I see to make non-recursive builds work nicely with AC_LIBOBJ. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
AC_LIBOBJ(subdir/file) doesn't work with non-recursive automake
I originally submitted this as a Debian bug, but it's more relevant here.
I'm using Automake with a package that has its source in various
subdirectories but builds the whole package with a single non-recursive
Makefile, as mentioned in the Automake manual under Directories /
Alternative. Everything works except that, after checking for a deficient
snprintf, I call AC_LIBOBJ([util/snprintf]). This results in the
following error from Automake:
configure.ac:25: required file `./util/snprintf.c' not found
even though the file exists.
The problem is in the dir_has_case_matching_file routine in
Automake/FileUtils.pm, which assumes that the file that it's passed is a
simple filename, or alternately is in require_file_internal in automake
itself, which doesn't detect this case. A quick inspection of the former
routine reveals that it will never work if passed a filename like
util/snprintf.c (and a $dir of ., which is what happens in this case).
The attached patch works around this and shouldn't have any negative side
effects. It may not be as clean as upstream wants, since it supports a
partial path as part of the filename, but the alternative of modifying
require_file_internal looked slightly more complex.
Let me know, though, if you'd rather have a patch for automake.
An even better solution would be for Automake to pay attention to
AC_CONFIG_LIBOBJ_DIR and look for AC_LIBOBJ files there. As near as I can
tell, Automake currently ignores that setting. I think this fix is
correct and should be used regardless of whether that bug is also fixed,
though.
--
Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
--- automake1.9-1.9.6/lib/Automake/FileUtils.pm.orig2005-05-14
13:21:06.0 -0700
+++ automake1.9-1.9.6/lib/Automake/FileUtils.pm 2006-03-29 20:46:43.0
-0800
@@ -339,6 +339,16 @@
my ($dirname, $file_name) = @_;
return 0 unless -f $dirname/$file_name;
+ # It's possible that the file name won't be a simple file name and
+ # instead will include a directory component. In that case, we have
+ # to figure out what the real directory is.
+ if ($file_name =~ m%/%)
+{
+ my $partial_dir;
+ ($partial_dir, $file_name) = ($file_name =~ m%^(.*)/([^/]*)%);
+ $dirname = $dirname/$partial_dir;
+}
+
# The file appears to exist, however it might be a mirage if the
# system is case insensitive. Let's browse the directory and check
# whether the file is really in. We maintain a cache of directories
Re: specifying target directories in non-recursive automake
John Darrington wrote: I've been trying to convert a rather largish automake controlled project from a recursive style build system, to a non-recursive one. I was rather suprised to see that automake decides to put all the object files in the root directory; not only ugly, but destroys the namespaces afforded by each directory. Consequently, things are falling down when in the cases where there are identically names source files in different directories. For example, this simple Makefile.am complains about main.o being created twice, when the two main.c files are clearly separate. bin_PROGRAMS = prog1/foo prog2/bar prog1_foo_SOURCES = prog1/main.c prog2_bar_SOURCES = prog2/main.c Reading the manual suggests that I should be able to prefix the SOURCES variables with nobase_ but it doesn't seem to work. Can anyone tell me the correct way to create a non-recursive automake system, which might have identically named source files? In your configure.ac, make sure AM_INIT_AUTOMAKE is given the subdir-objects option (you'll also need a recent automake): AM_INIT_AUTOMAKE([1.9 subdir-objects]) HTH, Gary. -- Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org} Research Scientist ( '/ http://tkd.kicks-ass.net GNU Hacker / )= http://www.gnu.org/software/libtool Technical Author `(_~)_ http://sources.redhat.com/autobook signature.asc Description: OpenPGP digital signature
Re: specifying target directories in non-recursive automake
Hi John, * John Darrington wrote on Mon, Feb 20, 2006 at 03:42:37AM CET: I've been trying to convert a rather largish automake controlled project from a recursive style build system, to a non-recursive one. I was rather suprised to see that automake decides to put all the object files in the root directory; not only ugly, but destroys the namespaces afforded by each directory. Read up on the Automake option subdir-objects in the documentation. To specify per-package like this: AC_INIT([foo-package], [1.23], [EMAIL PROTECTED]) AM_INIT_AUTOMAKE([subdir-objects ...]) or per-Makefile.am in `AUTOMAKE_OPTIONS = ...'. I prefer the first usually. Cheers, Ralf
Re: non-recursive automake advice?
Bob == Bob Friesenhahn [EMAIL PROTECTED] writes: Bob Note that the messages appear to indicate that Automake does recurse Bob once regardless. Some features require a $(MAKE) invocation in the same directory. Offhand I forget what. As I recall, removing this would be tricky. Tom
Re: non-recursive automake advice?
Hello Bob, % time gmake gmake all-am gmake[1]: Entering directory `/scratch/bfriesen/build/GraphicsMagick-16-static' gmake[1]: Leaving directory `/scratch/bfriesen/build/GraphicsMagick-16-static' gmake 0.78s user 0.10s system 88% cpu 0.990 total % Note that the messages appear to indicate that Automake does recurse once regardless. that's because you use BUILT_SOURCES. I think that you should drop it. You use it only for config headers; but Automake can handle headers itself, there is no need give him this hint. To be more specific: 1) When you first run configure, the config headers are generated, and probably up-to date. 2) After a build, the automatic dapendencies know that all files depend on config header, so the BUILT_SOURCES hint becomes redundant anyway. 3) If configure has to be regenerated, it is run afterwards, and then config.status is ran, so the config headers are also regenerated. Well, the above reasoning is perhaps not very clear, but there are two big reasons: 12) The Automake manual explains that BUILT_SOURCES is an ugly dirty hack. It should be used in minimal necessary doses. It shouldn't be used at all, unless absolute necessary. And: 77) If you remove it, the output will be even nicer. ;-) Just use the patch attached below. Have a nice day, Stepan 2005-08-30 Stepan Kasal [EMAIL PROTECTED] * Makefile.am (BUILT_SOURCES): Removed. * magick/Makefile.am (MAGICK_BUILT_SRCS): Removed, too. Index: Makefile.am === RCS file: /GraphicsMagick/GraphicsMagick/Makefile.am,v retrieving revision 1.134 diff -u -r1.134 Makefile.am --- Makefile.am 11 May 2005 05:09:23 - 1.134 +++ Makefile.am 30 Aug 2005 12:46:28 - @@ -37,9 +37,6 @@ $(TESTS_CLEANFILES) \ $(WAND_CLEANFILES) -BUILT_SOURCES = \ - $(MAGICK_BUILT_SRCS) - bin_PROGRAMS = \ $(UTILITIES_PGMS) Index: magick/Makefile.am === RCS file: /GraphicsMagick/GraphicsMagick/magick/Makefile.am,v retrieving revision 1.198 diff -u -r1.198 Makefile.am --- magick/Makefile.am 14 Apr 2005 15:32:43 - 1.198 +++ magick/Makefile.am 30 Aug 2005 12:46:28 - @@ -23,10 +23,6 @@ MAGICK_MANS = \ magick/GraphicsMagick-config.1 -MAGICK_BUILT_SRCS = \ - magick/magick_config.h \ - magick/magick_config_api.h - LIBMAGICK=magick/libGraphicsMagick.la if WITH_MODULES
non-recursive automake advice?
So I've been convinced that the effort involved in changing a build
system to not use recursive make is worth it, and I was wondering if
anyone had some good advice as to how I should go about doing this,
since my way seems to be having issues =).
I have a directory setup like the following:
/
/src/
/src/input/
/src/models/
/src/share/
/tests/
with configure.in in the /, and a Makefile.am in the root that just
recurses into /src/ and /tests/ (okay, so its not \emph{completely}
non-recursive...). Each subdirectory off of /src/ is essentially its
own self-contained module, or at least thats the hope/plan.
Basically I'd like each module to build their own libtool convenience
library, and then have /src/Makefile.am link all of those modules'
convenience libraries into one that is the union of all of them.
Without recursive make this is a little strange, but I've devised a
scheme to make each module 'feel' like it has its own, local
Makefile.am, by playing with includes.
Each module gets its own 'Inc.am'. In /src/Makefile.am, I setup
noinst_LTLIBRARIES, noinst_HEADERS, and BUILT_SOURCES. Then I include
every modules' 'Inc.am':
/src/Makefile.am
AM_CFLAGS=-I$(srcdir)/input/ -I$(srcdir)/share/ -I$(srcdir)/models/
# set variables before the includes, so include can append to the
# existing setup and not get overwritten later.
noinst_LTLIBRARIES = libAll.la libCur.la
noinst_HEADERS=jf_read.h jf_data.h bfield.h jf_bfield.h cmd_line.h
particle.h
BUILT_SOURCES=
include $(srcdir)/models/Inc.am
include $(srcdir)/share/Inc.am
include $(srcdir)/input/Inc.am
libCur_la_SOURCES = cmd_line.c consts.c bfield.c jf_bfield.c jf_read.c\
particle.c
libAll_la_LIBADD = \
$(srcdir)/models/libModels.la \
$(srcdir)/share/libShare.la \
$(srcdir)/input/libInput.la \
$(srcdir)/libCur.la
gcpt_SOURCES=main.c
bin_PROGRAMS=gcpt
gcpt_LDADD = \
libAll.la \
-ly -lfl
/src/Makefile.am
In all of the modules' 'Inc.am' files, I do some sort of
'noinst_LTLIBRARIES+=something.la' (note the plus-equals, not just
equals). This appears to work, insofar as 'autoreconf' doesn't yell at
me for doing something dumb.
Unfortunately in the 'Inc.am' files I need to remember to qualify every
filename with not just '$(srcdir)', but
'$(srcdir)/modules_directory_name/'. This is only a minor annoyance
and definitely worth the trouble, but perhaps I am missing something?
Anyway my real issue is that I just can't get the build system to find
the module-archives correctly. If I do (for example):
/src/models/Inc.am
noinst_LTLIBRARIES += $(srcdir)/models/libModels.la
libModels_la_SOURCES = ...
/src/models/Inc.am
Then automake complains that I made a typo. It sounds like its not
recognizing that 'libModels_la_SOURCES' is associated with
'$(srcdir)/models/libModels.la':
src/models/Inc.am:3: variable `libModels_la_SOURCES' is defined but no program
or
src/models/Inc.am:3: library has `libModels_la' as canonic name (possible typo)
src/Makefile.am:27: `src/models/Inc.am' included from here
However if I do NOT qualify libModels.la with '$(srcdir)/models/',
then autoreconf completes fine. Then when I go to 'make', make
complains that it doesn't know how to build libModels.la:
make[2]: Entering directory `/home/tfogal/tracer/src'
make[2]: *** No rule to make target `models/libModels.la', needed by
`libAll.la'. Stop.
make[2]: Leaving directory `/home/tfogal/tracer/src'
Which is true according to the generated 'Makefile' -- it knows how to
generate 'libModels.la', not 'models/libModels.la'.
Am I going about this completely the wrong way? Is there some software
I can look at for an example of a 'correct' way to do this?
Thanks for any help / advice you can offer. I also appreciate any
stylistic / readability / other advice beyond just what'll make it
work.
-tom
Re: non-recursive automake advice?
On Mon, 29 Aug 2005, tom fogal wrote: So I've been convinced that the effort involved in changing a build system to not use recursive make is worth it, and I was wondering if A noble objective. Unfortunately in the 'Inc.am' files I need to remember to qualify every filename with not just '$(srcdir)', but '$(srcdir)/modules_directory_name/'. This is only a minor annoyance and definitely worth the trouble, but perhaps I am missing something? Anyway my real issue is that I just can't get the build system to find the module-archives correctly. If I do (for example): Any Automake target name which would contain directory separators needs to have the directories separators replaced with underscores in the name. This can be painful. Also keep in mind that regardless of inclusion, Automake is not going to treat content differently based on where it is included from. Therefore, your sub-directory Makefile.am files are going to have to know that they are located in a sub-directory and need to use full paths from the directory where the top Makefile.am is located. Am I going about this completely the wrong way? Is there some software I can look at for an example of a 'correct' way to do this? Development GraphicsMagick 1.2 does use a completely non-recursive build. It uses Automake includes to include per-subdirectory .am files as you mention. A tarball may be downloaded from ftp://ftp.graphicsmagick.org/pub/GraphicsMagick/snapshots/; or you may look at the Makefile.am files via cvsweb at http://cvs.graphicsmagick.org/cgi-bin/cvsweb.cgi/GraphicsMagick/;. You will notice that the Makefile.am files don't use += at all. I don't know that there is anything wrong with using += but I felt more secure with using named variables and explicit concatenation for everything since I could be absolutely sure about ordering. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: non-recursive automake advice?
tom == tom fogal [EMAIL PROTECTED] writes: tom Basically I'd like each module to build their own libtool convenience tom library, and then have /src/Makefile.am link all of those modules' tom convenience libraries into one that is the union of all of them. Do you really want each separate convenience library, or is that just inertia? I ask because if you don't want separate ones, the task becomes even simpler. tom Without recursive make this is a little strange, but I've devised a tom scheme to make each module 'feel' like it has its own, local tom Makefile.am, by playing with includes. tom libAll_la_LIBADD = \ tom $(srcdir)/models/libModels.la \ tom $(srcdir)/share/libShare.la \ tom $(srcdir)/input/libInput.la \ tom $(srcdir)/libCur.la You don't want $(srcdir) here. The .la files are in the build tree, not the source tree. Just write: libAll_la_LIBADD = \ models/libModels.la \ share/libShare.la \ input/libInput.la \ libCur.la tom Unfortunately in the 'Inc.am' files I need to remember to qualify every tom filename with not just '$(srcdir)', but tom '$(srcdir)/modules_directory_name/'. This is only a minor annoyance tom and definitely worth the trouble, but perhaps I am missing something? Once upon a time I had a plan to introduce a new 'import' statement, that would work like 'include' but magically rewrite things like this as needed. That would make it really simple to do the kind of thing you're trying to do. It was fairly complex, though, and in the end I lost interest... tom noinst_LTLIBRARIES += $(srcdir)/models/libModels.la (Likewise no srcdir here) Tom
Re: non-recursive automake advice?
*mutter*, forgot to cc the list again... --- Forwarded Message From: tom fogal [EMAIL PROTECTED] To: Bob Friesenhahn [EMAIL PROTECTED] Subject: Re: non-recursive automake advice? In-Reply-To: Your message of Mon, 29 Aug 2005 18:29:09 CDT. [EMAIL PROTECTED] References: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Date: Mon, 29 Aug 2005 19:40:14 -0400 Sender: [EMAIL PROTECTED] [EMAIL PROTECTED]Bob Friesenhahn writes: On Mon, 29 Aug 2005, Tom Tromey wrote: tom == tom fogal [EMAIL PROTECTED] writes: tom Basically I'd like each module to build their own libtool convenience tom library, and then have /src/Makefile.am link all of those modules' tom convenience libraries into one that is the union of all of them. Do you really want each separate convenience library, or is that just inertia? I ask because if you don't want separate ones, the task becomes even simpler. This is a very good point. Convenience libraries are really an Nah, not really. I just recently learned about the 'create a convenience archive from a set of other convenience archives' feature and got a little giddy with newfound toys. Your arguments are convincing, I will switch my setup away from convenience archives. Thanks! - -tom --- End of Forwarded Message
Re: non-recursive automake advice?
On Mon, 29 Aug 2005, Tom Tromey wrote: tom == tom fogal [EMAIL PROTECTED] writes: tom Basically I'd like each module to build their own libtool convenience tom library, and then have /src/Makefile.am link all of those modules' tom convenience libraries into one that is the union of all of them. Do you really want each separate convenience library, or is that just inertia? I ask because if you don't want separate ones, the task becomes even simpler. This is a very good point. Convenience libraries are really an artifact of recursive builds. When using a non-recursive build, the rules to generate all targets is known at once and there is not much value associated with using convenience libraries. You can choose to put the built objects in the same relative directory as the sources, or they can be put somewhere else. Likewise, built libraries can be put wherever you want in the tree. While the former version of GraphicsMagick uses a recursive build and convenience libraries, the use of convenience libraries was easily eliminated due to the switch to a non-recursive build. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: non-recursive automake advice?
On Mon, 29 Aug 2005, tom fogal wrote: Your arguments are convincing, I will switch my setup away from convenience archives. As you proceed with your non-recursive build, be sure to keep in mind that you are leaving the common path so you can expect to encounter more bugs or things that need to be worked around. There are also asthetic differences such as that your object files may be given funny names. I think it is worthwhile in the long term though. There is something very satisfying to do 'make' on a large project and see: % time gmake gmake all-am gmake[1]: Entering directory `/scratch/bfriesen/build/GraphicsMagick-16-static' gmake[1]: Leaving directory `/scratch/bfriesen/build/GraphicsMagick-16-static' gmake 0.78s user 0.10s system 88% cpu 0.990 total % Note that the messages appear to indicate that Automake does recurse once regardless. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: Status of non-recursive automake
On Wed, Dec 03, 2003 at 02:38:52PM -0600, Bob Friesenhahn wrote: Does src1/foo.c exist? Yes. Are you using Automake 1.7.9? No. I was using 1.7.6 and it seemed that atl_SOURCES=src1/foo.c works fine with this version. So presumably the underscore thing was introduced between 1.7.6 and 1.7.9 J' -- PGP Public key ID: 1024D/2DE827B3 fingerprint = 8797 A26D 0854 2EAB 0285 A290 8A67 719C 2DE8 27B3 See http://wwwkeys.pgp.net or any PGP keyserver for public key. pgp0.pgp Description: PGP signature
Re: Status of non-recursive automake
On Thu, 4 Dec 2003, John Darrington wrote: On Wed, Dec 03, 2003 at 02:38:52PM -0600, Bob Friesenhahn wrote: Does src1/foo.c exist? Yes. Are you using Automake 1.7.9? No. I was using 1.7.6 and it seemed that atl_SOURCES=src1/foo.c works fine with this version. So presumably the underscore thing was introduced between 1.7.6 and 1.7.9 The underscore rule applies to the names to the *left* of the '=', not the right. Paths on the right are just fine. If your target library/program resides in a subdirectory, you will soon experience what I have been complaining about. :-) Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen
Status of non-recursive automake
Hi folks, Is non-recursive currently supported in automake or is it still in development/ideas stage? If it's already working, what version do I need, and what documentation exists? I've been trying to follow some threads in this list to gleem an insight, but I joined late ... so I'd be obliged if someone could tell me what the status is. Thanks, John -- PGP Public key ID: 1024D/2DE827B3 fingerprint = 8797 A26D 0854 2EAB 0285 A290 8A67 719C 2DE8 27B3 See http://wwwkeys.pgp.net or any PGP keyserver for public key. pgp0.pgp Description: PGP signature
Re: Status of non-recursive automake
On Wed, 3 Dec 2003, John Darrington wrote: Is non-recursive currently supported in automake or is it still in development/ideas stage? If it's already working, what version do I need, and what documentation exists? Based on my recent experience, non-recursive builds are working very well in the current automake release. Use 'subdir-objects' in AUTOMAKE_OPTIONS if you want the objects to be placed at the same relative location as the source files. An issue with the 'clean' target has been reported for the case where the makefile is also recursive (SUBDIRS is used). Objects get unnecessary funny naming in the case where TARGET_CPPFLAGS is used but this doesn't seem to break anything. Since the '/' in target definitions are not make syntax compatible, all the '/'s in target definitions need to be manually smashed to '_'. This is very tedious and error prone, and is something that Automake should fix. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen
Re: Status of non-recursive automake
On Tue, Dec 02, 2003 at 07:43:01PM -0600, Bob Friesenhahn wrote: Based on my recent experience, non-recursive builds are working very well in the current automake release. Use 'subdir-objects' in AUTOMAKE_OPTIONS if you want the objects to be placed at the same relative location as the source files. An issue with the 'clean' target has been reported for the case where the makefile is also recursive (SUBDIRS is used). Objects get unnecessary funny naming in the case where TARGET_CPPFLAGS is used but this doesn't seem to break anything. Since the '/' in target definitions are not make syntax compatible, all the '/'s in target definitions need to be manually smashed to '_'. This is very tedious and error prone, and is something that Automake should fix. Is there anything else that's required? I made a simple Makefile.am : AUTOMAKE_OPTIONS=subdir-objects bin_PROGRAMS=atl atl_SOURCES=src1_foo.c src2_bar.c But the resulting Makefile produces: make: *** No rule to make target `src1_foo.c', needed by `src1_foo.o'. Stop J' -- PGP Public key ID: 1024D/2DE827B3 fingerprint = 8797 A26D 0854 2EAB 0285 A290 8A67 719C 2DE8 27B3 See http://wwwkeys.pgp.net or any PGP keyserver for public key. pgp0.pgp Description: PGP signature
