|
From: Nicholas N. <nj...@ca...> - 2004-07-06 22:02:36
|
Hi,
Looking at some of the tool Makefile.am files, some have this:
all-local:
mkdir -p $(inplacedir)
-rm -f $(addprefix $(inplacedir)/,$(val_PROGRAMS))
ln -f -s $(addprefix $(top_builddir)/$(subdir)/,$(val_PROGRAMS)) $(inplacedir)
and some have this:
all-local:
mkdir -p $(inplacedir)
-rm -f $(inplacedir)/$(val_PROGRAMS)
ln -f -s $(top_builddir)/$(subdir)/$(val_PROGRAMS) $(inplacedir)/$(val_PROGRAMS)
ie. no "addprefix". Does the difference matter? Is one preferred?
Can you do #includes in Makefile.am files? That's what is needed here for
the common parts.
N
|
|
From: Jeremy F. <je...@go...> - 2004-07-06 22:11:25
|
On Tue, 2004-07-06 at 23:02 +0100, Nicholas Nethercote wrote: > ie. no "addprefix". Does the difference matter? Is one preferred? The addprefix is necessary if $(val_PROGRAMS) expands to more than one word. If you don't have it you end up with something like "my/valgrind/ tool/foo1 foo2" when you wanted "my/valgrind/tool/foo1 my/valgrind/tool/ foo2". They should probably all have addprefix for consistency's sake. > Can you do #includes in Makefile.am files? That's what is needed here for > the common parts. I've never understood what the best level to do this is at. There's at least 3 places you could do it, I think: as autoconf macros, some automake thing, or just plain Makefile includes. I think. It's tricky because Makefile.am isn't really a makefile, and gets interpreted in magic ways, so you can't do anything clever with make variable expansion without confusing automake. J |
|
From: Bob F. <bfr...@si...> - 2004-07-06 22:23:07
|
On Tue, 6 Jul 2004, Jeremy Fitzhardinge wrote: > automake thing, or just plain Makefile includes. I think. It's tricky > because Makefile.am isn't really a makefile, and gets interpreted in > magic ways, so you can't do anything clever with make variable expansion > without confusing automake. Makefile.am is both a makefile, and not a makefile (binomial personality disorder). Normal (non-GNU-specific) makefile rules will be passed to the output Makefile. In order to interface with what Automake generates, you need to read its output Makefile and become familiar with what it generates. Then you can use the funny variable names and targets that it generates in your own rules. Of course future Automake's may change the way the generated Makefile works so it is risky to depend on internals. Bob ====================================== Bob Friesenhahn bfr...@si... http://www.simplesystems.org/users/bfriesen |
|
From: Bob F. <bfr...@si...> - 2004-07-06 22:17:04
|
On Tue, 6 Jul 2004, Nicholas Nethercote wrote: > > Can you do #includes in Makefile.am files? That's what is needed here for > the common parts. No, you can not. Valgrind should consider using one Makefile.am to build everything in the package and avoid recursive Makefile.am's. There are definite advantages to this since then 'make' is aware of the full dependency tree. As a developer it is nice to type 'make' when there is nothing to do and have it immediately say that there is nothing to do rather than to watch 'make' go off and do a lot of unnecessary work. Bob ====================================== Bob Friesenhahn bfr...@si... http://www.simplesystems.org/users/bfriesen |
|
From: Nicholas N. <nj...@ca...> - 2004-07-06 22:40:32
|
On Tue, 6 Jul 2004, Bob Friesenhahn wrote: > Valgrind should consider using one Makefile.am to build everything in the > package and avoid recursive Makefile.am's. There are definite advantages to > this since then 'make' is aware of the full dependency tree. As a developer > it is nice to type 'make' when there is nothing to do and have it immediately > say that there is nothing to do rather than to watch 'make' go off and do a > lot of unnecessary work. Indeed, that would be wonderful! So, how do you do it? Can you have a single Makefile for multiple directories? A patch for this would be most welcome :) N |
|
From: Nicholas N. <nj...@ca...> - 2004-07-09 08:36:15
Attachments:
Makefile.am
|
On Tue, 6 Jul 2004, Nicholas Nethercote wrote: >> Valgrind should consider using one Makefile.am to build everything in the >> package and avoid recursive Makefile.am's. There are definite advantages >> to this since then 'make' is aware of the full dependency tree. As a >> developer it is nice to type 'make' when there is nothing to do and have >> it immediately say that there is nothing to do rather than to watch 'make' >> go off and do a lot of unnecessary work. > > Indeed, that would be wonderful! I gave this a red hot go, but haven't managed to do it properly. I had it doing basic builds correctly, but I couldn't get "make distcheck" to work, nor could I get it to work if top_srcdir != top_builddir. It's attached if anyone want to have a fiddle; note that the basic build case is broken at the moment because I changed something when trying to fix make distcheck and I can't remember what it was, and cannot be bothered to work it out. The whole experiment was disappointing. I read the "Recursive Make Considered Harmful" paper, but the advantages of a single Makefile mentioned in that didn't come out in practice. The pros and cons of having a single Makefile.am were: Pros: + Avoids some repetition + Building when up-to-date is marginally quicker (ie. 0.7s instead of 1.4s on my machine) + Avoids the screenful of "Making all in foo" messages. + One big Makefile.am instead of 39 small ones; this results in fewer lines of Makefile.am code (but more characters...) Cons: - Doing a full make is slightly slower - Have to do some awkward things with flags and so on in the Makefile.am, so it's arguably harder to understand - Er, couldn't actually get it to work properly I get the feeling that automake is sufficiently brittle (seemingly much more brittle when you use a single monolithic Makefile.am), and our build is sufficiently complex (eg. building multiple .so files, generating .h files with perl scripts, generating test .c files from perl scripts, reusing .o files in more than one .so, special ld scripts, needing different CFLAGS for multiple .c files in the one executable...) that in the end it's a bad idea. It's certainly a no-go while the monolithich Makefile.am doesn't work... N |
|
From: Bob F. <bfr...@si...> - 2004-07-06 22:55:09
|
On Tue, 6 Jul 2004, Nicholas Nethercote wrote: > On Tue, 6 Jul 2004, Bob Friesenhahn wrote: > >> Valgrind should consider using one Makefile.am to build everything in the >> package and avoid recursive Makefile.am's. There are definite advantages >> to this since then 'make' is aware of the full dependency tree. As a >> developer it is nice to type 'make' when there is nothing to do and have >> it immediately say that there is nothing to do rather than to watch 'make' >> go off and do a lot of unnecessary work. > > Indeed, that would be wonderful! > > So, how do you do it? Can you have a single Makefile for multiple > directories? A patch for this would be most welcome :) I would be happy to supply a patch but unfortunately I don't have available time to work on it. :-( Recent/modern Automake's support non-recursive builds quite well. The rules are exactly the same as with a normal Makefile.am except that you reference sources with full relative paths (from the top), and targets need to reflect the full relative path to where they will be placed. There is one annoying twist in that target paths need to have the '/' replaced with '_' using the same rules as used for the special characters that Automake doesn't otherwise support in target names. If the existing Makefile.am's are written cleanly, it should not be a difficult task to roll up into a single Makefile.am. It is mostly a matter of adding prefix paths and ensuring that script code does not assume that files are always in the "current" directory since the "current" directory will always be the top directory in a non-recursive build. A side effect of using one Makefile.am is that you would always type 'make' from the top directory. So you would do make path/to/tool if you wanted to build only 'tool' rather than cd path/to make tool or make -C path/to tool Unless the software takes a long time to build, using a non-recursive build signficantly reduces the desire/need to build just one component since no-time is wasted needlessly rebuilding components or checking to see if components need to be built. Valgrind is very small so this should not be a problem. Bob ====================================== Bob Friesenhahn bfr...@si... http://www.simplesystems.org/users/bfriesen |
|
From: Nicholas N. <nj...@ca...> - 2004-07-07 00:54:41
|
On Tue, 6 Jul 2004, Bob Friesenhahn wrote: > Recent/modern Automake's support non-recursive builds quite well. The rules > are exactly the same as with a normal Makefile.am except that you reference > sources with full relative paths (from the top), and targets need to reflect > the full relative path to where they will be placed. There is one annoying > twist in that target paths need to have the '/' replaced with '_' using the > same rules as used for the special characters that Automake doesn't otherwise > support in target names. I've started attempting this. I started by just trying to remove helgrind/Makefile.am. I basically just moved its contents into Makefile.am. It's almost working, but I'm getting the following problem. This line: vgskin_helgrind_so_SOURCES = $(top_srcdir)/helgrind/hg_main.c works, but it causes vgskin_helgrind.so to be built in $(top_builddir), rather than $(top_builddir)/helgrind where I want it to be built. I tried using '_' as (I think) you suggested, viz: helgrind_vgskin_helgrind_so_SOURCES = $(top_srcdir)/helgrind/hg_main.c but automake complains that helgrind_vgskin_helgrind_so_SOURCES is an invalid unused variable name. I tried a couple of ways to declare the helgrind directory, but that didn't work either. Am I doing something wrong? N |
|
From: Bob F. <bfr...@si...> - 2004-07-07 02:36:26
|
On Wed, 7 Jul 2004, Nicholas Nethercote wrote: > > I've started attempting this. I started by just trying to remove > helgrind/Makefile.am. I basically just moved its contents into Makefile.am. > It's almost working, but I'm getting the following problem. > > This line: > > vgskin_helgrind_so_SOURCES = $(top_srcdir)/helgrind/hg_main.c > > works, but it causes vgskin_helgrind.so to be built in $(top_builddir), > rather than $(top_builddir)/helgrind where I want it to be built. I tried > using '_' as (I think) you suggested, viz: > > helgrind_vgskin_helgrind_so_SOURCES = $(top_srcdir)/helgrind/hg_main.c > > but automake complains that helgrind_vgskin_helgrind_so_SOURCES is an invalid > unused variable name. I tried a couple of ways to declare the helgrind > directory, but that didn't work either. > > Am I doing something wrong? Yes, and I suspect that the problem is that your target statement is incorrect. It should be something like: val_PROGRAMS = helgrind/vgskin_helgrind.so helgrind_vgskin_helgrind_so_SOURCES = helgrind/hg_main.c helgrind_vgskin_helgrind_so_LDFLAGS = -shared Notice that the target is helgrind/vgskin_helgrind.so and "helgrind/" is translated to "helgrind_" for any further references related to that target. Since the overall Makefile.am may install more stuff in $(libdir)/valgrind than the existing subordinate Makefile.am's, the list of targets will need to incorporate all targets installed in that directory. Bob ====================================== Bob Friesenhahn bfr...@si... http://www.simplesystems.org/users/bfriesen |
|
From: Bob F. <bfr...@si...> - 2004-07-07 02:40:36
|
On Tue, 6 Jul 2004, Bob Friesenhahn wrote: >> rather than $(top_builddir)/helgrind where I want it to be built. I tried >> using '_' as (I think) you suggested, viz: >> >> helgrind_vgskin_helgrind_so_SOURCES = $(top_srcdir)/helgrind/hg_main.c Note that you don't need to include $(top_srcdir) in the sources declaration because Automake takes care of finding the sources for you and things will still work fine for VPATH builds. All you need to do is specify relative paths from where Makefile.am is located. Bob ====================================== Bob Friesenhahn bfr...@si... http://www.simplesystems.org/users/bfriesen |
|
From: Nicholas N. <nj...@ca...> - 2004-07-07 16:09:11
|
Hi again, Playing with this some more, the single biggest difficulty I can see is that different C files are compiled with different options. Most notably: - Main Valgrind files use -O -fomit-frame-pointer - All the regression test files use -O0 -fno-omit-frame-pointer AFAICT, the only two ways of setting compiler flags is: 1. Use AM_CFLAGS, which affects every compilation 2. Use foo_CFLAGS, which affects just the compilation of 'foo' What I really want is "use these options for these N files, and these options for those M files". I don't think that's possible; AFAICT the best I can do is put the regtest flags in AM_CFLAGS, and then use individual foo_CFLAGS to overwrite the AM_CFLAGS for the Valgrind files. (This is less typing than the other way around, because there are 100+ regtest files and < 20 main Valgrind files.) A bit sucky, though. N |
|
From: Bob F. <bfr...@si...> - 2004-07-07 16:17:52
|
On Wed, 7 Jul 2004, Nicholas Nethercote wrote: > > AFAICT, the only two ways of setting compiler flags is: > > 1. Use AM_CFLAGS, which affects every compilation > > 2. Use foo_CFLAGS, which affects just the compilation of 'foo' > > What I really want is "use these options for these N files, and these options > for those M files". It does seem like about the only way you can apply different options is to build them for different targets. One way to accomplish that would be to build the object files into uninstalled libraries (targets) which are then used to build the program. I expect that there is a way to specify compilation at the per-file level (by altering build rules), but I don't think you want to go there. Bob ====================================== Bob Friesenhahn bfr...@si... http://www.simplesystems.org/users/bfriesen |
|
From: Nicholas N. <nj...@ca...> - 2004-07-07 17:49:07
|
On Wed, 7 Jul 2004, Nicholas Nethercote wrote: > Playing with this some more, the single biggest difficulty I can see is that > different C files are compiled with different options. Another awful thing: all the intermediate (.o) files are built in $(top_builddir), ugh. There are more than 100 when the regression tests are built. It turns out you can to Makefile.am includes, according to the info pages, so maybe that's a good compromise. N |
|
From: Bob F. <bfr...@si...> - 2004-07-07 18:25:16
|
On Wed, 7 Jul 2004, Nicholas Nethercote wrote: > On Wed, 7 Jul 2004, Nicholas Nethercote wrote: > >> Playing with this some more, the single biggest difficulty I can see is >> that different C files are compiled with different options. > > Another awful thing: all the intermediate (.o) files are built in > $(top_builddir), ugh. There are more than 100 when the regression tests are > built. The cure: Add "subdir-objects" to AUTOMAKE_OPTIONS. For example AUTOMAKE_OPTIONS = subdir-objects With this option, the objects appear next to the source files as before, or in the same relative location for a VPATH build. Bob ====================================== Bob Friesenhahn bfr...@si... http://www.simplesystems.org/users/bfriesen |