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
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: 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?
*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?
> "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?
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/
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
