How to generate version.texi in builddir?
Hi all, I'm trying to change automake's behaviour to generate version.texi inside the builddir instead of srcdir. Based on https://www.gnu.org/software/automake/manual/html_node/Texinfo.html I've tried info-in-builddir , but that seems to affect only the final .info file and not the version.texi one. Which is not that suprising given the name (`info-'). But there is not texi-in-builddir option as far as I can tell. Is this currently possible at all or is version.texi being in srcdir hard-coded behavior? Thank you for your help, W. -- There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors. signature.asc Description: PGP signature
Re: Produce symlink into builddir on VPATH?
On 06/11/2014 04:18 PM, Rhys Ulerich wrote: > Other than resorting to the shell in a target, is there a way to cause > Automake to produce a symlink from the source tree into the build tree > if-and-only-if the build is VPATH? Yes, for new enough autotools. See how gnulib does it for GNUmakefile: http://git.savannah.gnu.org/cgit/gnulib.git/tree/modules/gnumakefile -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Produce symlink into builddir on VPATH?
Other than resorting to the shell in a target, is there a way to cause Automake to produce a symlink from the source tree into the build tree if-and-only-if the build is VPATH? I've some non-generated Python code (srcdir) relying on generated Python code (builddir) and I'd like to be able to just use it from the builddir (hence the symlink from srcdir) without monkeying with PYTHONPATH. Thanks, Rhys
Re: builddir
On 15/11/10 01:10, Ralf Wildenhues wrote: Hello Russell, * Russell Shaw wrote on Sun, Nov 14, 2010 at 02:49:07AM CET: In a Makefile.in generated by automake 1.9.6, it defines top_builddir ok, but builddir is used but not defined in there. This causes problems, because the automake manual says: — Variable: builddir Rigorously equal to ‘.’. Added for symmetry only. Automake 1.9.6 is very old. Presumably you're using an ancient version of Autoconf too, please state which. Normally I'd say upgrade and retry, but I might look at this if you post a small reproducer. Hi, I had a closer look at my system and found the debian alternatives system was pointing at an old version. I set it right now thanks.
Re: builddir
Hello Russell, * Russell Shaw wrote on Sun, Nov 14, 2010 at 02:49:07AM CET: > In a Makefile.in generated by automake 1.9.6, it defines > top_builddir ok, but builddir is used but not defined in there. > > This causes problems, because the automake manual says: > > — Variable: builddir > Rigorously equal to ‘.’. Added for symmetry only. Automake 1.9.6 is very old. Presumably you're using an ancient version of Autoconf too, please state which. Normally I'd say upgrade and retry, but I might look at this if you post a small reproducer. Thanks, Ralf
builddir
Hi, In a Makefile.in generated by automake 1.9.6, it defines top_builddir ok, but builddir is used but not defined in there. This causes problems, because the automake manual says: — Variable: builddir Rigorously equal to ‘.’. Added for symmetry only.
Re: builddir question
Andreas Otto wrote: is a "builddir" other than "." possible ? No http://www.gnu.org/software/autoconf/manual/autoconf.html#Preset-Output-Variables -- Peter Johansson svndigest maintainer, http://dev.thep.lu.se/svndigest yat maintainer, http://dev.thep.lu.se/yat
builddir question
Hi, is a "builddir" other than "." possible ? mfg aotto1968
$(builddir) is empty with automake <= 1.9
On Wed, 14 Oct 2009, Ralf Wildenhues wrote: * Vincent Torri wrote on Wed, Oct 14, 2009 at 07:48:35AM CEST: $(builddir)/eina_amalgamation.c: $(sources_used) Makefile -rm -f $(builddir)/eina_amalgamation.c $(builddir) is always equal to '.'; also, non-GNU makes don't identify FILE and ./FILE; so you are better off omitting '$(builddir)/', in both target name and command text. ok. I feared that it could break distcheck without $(builddir) but it seems not, at least with automake 1.10. With automake 1.10 or 1.11, there is no problem. But with automake 1.9, builddir seems empty and the command: rm -f /eina_almagamation.c is executed. No idea why that happens though. Might have forgotten the reason. maybe someone will remember :) thank you Vincent Torri
Re: builddir vs. srcdir
Hello, On Fri, Mar 18, 2005 at 09:34:15PM +0200, Paul Pogonyshev wrote: > Sorry, but I'll stick with my setup. My parser depends on my lowest- > level library (`libutils') and almost the whole build-tree depends on > the generated files. So, when I touched my `libutils' in any way, I > would get a full-blown rebuild of the project. That's why I used `cmp' > and only replaced the `.[ch]' files with the newly generated if they > differed. And so I need timestamps to avoid unecessary commands run yes, this indeed sounds as a good reason for usiong stamps. > Anyway, even if I don't accept your advice this time, thank you for > the help. :) You are welcome. It was a nice excercise for me, too. Stepan
Re: builddir vs. srcdir
> Hello, > > On Sat, Mar 12, 2005 at 06:56:20PM +0200, Paul Pogonyshev wrote: > > Everything seems to work just fine and as expected, > > your code, which is in whole cited below, doesn't actually know > about the dependency > foo.c foo.h: foo.list > > So if you change the .list file, the other files won't be rebuilt. > This might be a dangerous bug. It doesn't know about the dependency, but the files will be rebuilt as a ``side-effect'' of the timestamp rule. I actually just tried this out. > In general, stamps are always dangerous, so it's good to avoid them if > possible. I'd try something like this: > > [file `aux/list.make'] > SUFFIXES = .list > .list.c: Makefile $(PARSE_LIST_COMMAND) > $(PARSE_LIST_BUILD_RULE) > .list.h: Makefile $(PARSE_LIST_COMMAND) > $(PARSE_LIST_BUILD_RULE) > PARSE_LIST_BUILD_RULE = \ > $(PARSE_LIST_COMMAND) $(PARSE_LIST_FLAGS) \ > `test -f '$<' || echo '$(srcdir)/'`$< $*.h $*.c && \ > touch $*.h > > [usage] > LIST_FILES = foo.list bar.list > # Prevent problems with parallel make: > foo.h: foo.c > bar.h: bar.c > > PARSE_LIST_COMMAND = ... > PARSE_LIST_FLAGS = ... > > noinst_LIBRARIES = libfoo.a > libfoo_a_SOURCES = ... $(LIST_FILES) > > # This hint is needed only for included files; *.c files > # are handled by normal target dependencies: > BUILT_SOURCES = $(LIST_FILES:.list=.h) > > MOSTLYCLEANFILES = $(LIST_FILES:.list=.h) $(LIST_FILES:.list=.c) > > include $(top_srcdir)/aux/list.make Sorry, but I'll stick with my setup. My parser depends on my lowest- level library (`libutils') and almost the whole build-tree depends on the generated files. So, when I touched my `libutils' in any way, I would get a full-blown rebuild of the project. That's why I used `cmp' and only replaced the `.[ch]' files with the newly generated if they differed. And so I need timestamps to avoid unecessary commands run all the time (I want to see ``nothing to be done...'' when it is the case.) > Let me add some comments: > 1) The maintainer of Automake said that $(LIST_FILES:.list=.h) is safe, >and I trust him. Oh, great, that is what I was looking for! > 2) nodist_libfoo_a_SOURCES was redundant, especially the .c files. >Automake knows how to transform .list to .o, and listing the >intermediate files again could cause problems. With your setup, yes. Not with mine, unfortunately. > 3) I try to have the BUILT_SOURCES hist as small as possible, so when >the .c file is a prerequisite of the corresponding .o, there is no >need to pre-build it using BUILT_SOURCES. > 4) With parallel make, the PARSE_LIST_COMMAND cnnot be run twice in >parallel, because of the "foo.c: foo.h" dependency. So we are safe. I need to add this rule in my setup too. Anyway, even if I don't accept your advice this time, thank you for the help. :) Paul
Re: builddir vs. srcdir
Hello, On Sat, Mar 12, 2005 at 06:56:20PM +0200, Paul Pogonyshev wrote: > Everything seems to work just fine and as expected, your code, which is in whole cited below, doesn't actually know about the dependency foo.c foo.h: foo.list So if you change the .list file, the other files won't be rebuilt. This might be a dangerous bug. In general, stamps are always dangerous, so it's good to avoid them if possible. I'd try something like this: [file `aux/list.make'] SUFFIXES = .list .list.c: Makefile $(PARSE_LIST_COMMAND) $(PARSE_LIST_BUILD_RULE) .list.h: Makefile $(PARSE_LIST_COMMAND) $(PARSE_LIST_BUILD_RULE) PARSE_LIST_BUILD_RULE = \ $(PARSE_LIST_COMMAND) $(PARSE_LIST_FLAGS) \ `test -f '$<' || echo '$(srcdir)/'`$< $*.h $*.c && \ touch $*.h [usage] LIST_FILES = foo.list bar.list # Prevent problems with parallel make: foo.h: foo.c bar.h: bar.c PARSE_LIST_COMMAND = ... PARSE_LIST_FLAGS = ... noinst_LIBRARIES = libfoo.a libfoo_a_SOURCES = ... $(LIST_FILES) # This hint is needed only for included files; *.c files # are handled by normal target dependencies: BUILT_SOURCES = $(LIST_FILES:.list=.h) MOSTLYCLEANFILES = $(LIST_FILES:.list=.h) $(LIST_FILES:.list=.c) include $(top_srcdir)/aux/list.make Let me add some comments: 1) The maintainer of Automake said that $(LIST_FILES:.list=.h) is safe, and I trust him. 2) nodist_libfoo_a_SOURCES was redundant, especially the .c files. Automake knows how to transform .list to .o, and listing the intermediate files again could cause problems. 3) I try to have the BUILT_SOURCES hist as small as possible, so when the .c file is a prerequisite of the corresponding .o, there is no need to pre-build it using BUILT_SOURCES. 4) With parallel make, the PARSE_LIST_COMMAND cnnot be run twice in parallel, because of the "foo.c: foo.h" dependency. So we are safe. One more comment: 5) It looks that the PARSE_LIST_COMMAND will be executed twice: forst to create foo.c and then again to create foo.h. But this is actually not the case with GNU make: when command is to be called for the second time, make discovers, that the file foo.h has somehow appeared there, and that it's newer then its prerequisities, foo.list and foo.c (see the touch command in PARSE_LIST_BUILD_RULE), so there is no longer any need to rebuild it. Even if some inferior implementations of make were not that clever, the only problem would be that each pair of the files would be created twice. I think we can live with that. What if we used such an "inferior" make implementation for parallel build? Well, in general, this could bring problems. But I think this combination simply won't happen. Happy making, Stepan --- your code: > [file `aux/list.make'] > > SUFFIXES = .list > > $(LIST_STAMP_FILES) : Makefile $(PARSE_LIST_COMMAND) > > # `PARSE_LIST_COMMAND' and `PARSE_LIST_FLAGS' should be set by the > # includer. > # > PARSE_LIST = $(PARSE_LIST_COMMAND) $(PARSE_LIST_FLAGS) > > # We use `cmp' here to avoid unneeded recompilations of files that > # depend on generated ones (only really useful for `.h' files.) > # > PARSE_LIST_BUILD_RULE = \ > if $(PARSE_LIST) `test -f '$<' || echo '$(srcdir)/'`$< \ >$*.h.new $*.c.new; then\ > if cmp -s $*.c.new $*.c; \ > then rm -f $*.c.new; else mv -f $*.c.new $*.c; \ > fi; \ > if cmp -s $*.h.new $*.h; \ > then rm -f $*.h.new; else mv -f $*.h.new $*.h; \ > fi; \ > echo timestamp > $@; \ > else\ > (rm -f $*.c $*.c.new $*.h $*.h.new ; exit 1) \ > fi > > .list.stamp: > $(PARSE_LIST_BUILD_RULE) > > # Since $(LIST_GENERATED_FILES) defined by the includer don't (at > # least shouldn't) have any dependencies, if this rule is being > # executed, it probably means that one of the files was removed. > # Then all we can do is to force rebuilding of corresponding stamp > # file, which builds the required sources ``by side-effect.'' > # > $(LIST_GENERATED_FILES): > rm -f $*.stamp; > $(MAKE) $(AM_MAKEFLAGS) $*.stamp > > > [usage] > > noinst_LIBRARIES = libfoo.a > > LIST_FILES = foo.list bar.list > > LIST_STAMP_FILES = foo.stamp bar.stamp > > LIST_GENERATED_FILES = foo.c bar.c foo.h bar.h > > PARSE_LIST_COMMAND = ... > PARSE_LIST_FLAGS = ... > > include $(top_srcdir)/aux/list.make > > libfoo_a_SOURCES = ... $(LIST_FILES) > > nodist_libfoo_a_SOURCES = $(LIST_GENERATED_FILES) > > BUILT_SOURCES = $(LIST_STAMP_FILES) > > MOSTLYCLEANFILES = $(LIST_STAMP_FILES) $(LIST_GENERATED_FILES)
Re: builddir vs. srcdir
Stepan Kasal wrote: > About the side topic of suffixes: > [...] I finally decided that suffixes are good and ``are worth it'', mostly because I use generated files in 4 different directories (with two files in one of them), so rewriting the rule 5 times is kinda nasty. Based on your suggestions, study of GTK+ `Makefile.am' and own thoughts, I came up with this: [file `aux/list.make'] SUFFIXES = .list $(LIST_STAMP_FILES) : Makefile $(PARSE_LIST_COMMAND) # `PARSE_LIST_COMMAND' and `PARSE_LIST_FLAGS' should be set by the # includer. # PARSE_LIST = $(PARSE_LIST_COMMAND) $(PARSE_LIST_FLAGS) # We use `cmp' here to avoid unneeded recompilations of files that # depend on generated ones (only really useful for `.h' files.) # PARSE_LIST_BUILD_RULE = \ if $(PARSE_LIST) `test -f '$<' || echo '$(srcdir)/'`$< \ $*.h.new $*.c.new; then\ if cmp -s $*.c.new $*.c; \ then rm -f $*.c.new; else mv -f $*.c.new $*.c; \ fi; \ if cmp -s $*.h.new $*.h; \ then rm -f $*.h.new; else mv -f $*.h.new $*.h; \ fi; \ echo timestamp > $@; \ else\ (rm -f $*.c $*.c.new $*.h $*.h.new ; exit 1) \ fi .list.stamp: $(PARSE_LIST_BUILD_RULE) # Since $(LIST_GENERATED_FILES) defined by the includer don't (at # least shouldn't) have any dependencies, if this rule is being # executed, it probably means that one of the files was removed. # Then all we can do is to force rebuilding of corresponding stamp # file, which builds the required sources ``by side-effect.'' # $(LIST_GENERATED_FILES): rm -f $*.stamp; $(MAKE) $(AM_MAKEFLAGS) $*.stamp [usage] noinst_LIBRARIES = libfoo.a LIST_FILES = foo.list bar.list LIST_STAMP_FILES = foo.stamp bar.stamp LIST_GENERATED_FILES = foo.c bar.c foo.h bar.h PARSE_LIST_COMMAND = ... PARSE_LIST_FLAGS = ... include $(top_srcdir)/aux/list.make libfoo_a_SOURCES = ... $(LIST_FILES) nodist_libfoo_a_SOURCES = $(LIST_GENERATED_FILES) BUILT_SOURCES = $(LIST_STAMP_FILES) MOSTLYCLEANFILES = $(LIST_STAMP_FILES) $(LIST_GENERATED_FILES) Everything seems to work just fine and as expected, however I suspect that the ``rm -f $*.stamp; $(MAKE) $(AM_MAKEFLAGS) $*.stamp'' command will cause the problem with parallel make you mentioned. Is it so? Also, is there a way to automatically set `LIST_STAMP_FILES' and `LIST_GENERATED_FILES' from `LIST_FILES'? (I'm aware of GNU make's text manipulation functions, but they are GNU make specific...) Paul
Re: builddir vs. srcdir
Hello, On Thu, Mar 10, 2005 at 10:05:51PM +0200, Paul Pogonyshev wrote: > I'm not sure which one comes first. [...] I can just do > > foo.c : foo.h > foo.c foo.h : ... > if $(BUILD_THEM_FILES) foo.list foo.h foo.c; then \ > touch foo.c; \ > else\ > (rm -f foo.c foo.h; exit 1) \ > fi > > right? Correct, of course. About the side topic of suffixes: > Well, I also need something like `echo "$*" | sed 's/\.h$/.c/'` No, $* is the base without the suffix. > in one directory I have two `.list' files, one of which is processed > by my parser, while the other---by `glib-genmarshal' (I chose my > suffix before I even started with GTK+ GUI.) One option is to change the suffix for your parser, of course. Or you could do something like: LIST_H_CMDS = if $(BUILD_THEM_FILES) $*.list $*.h $*.c; then\ touch $*.c; \ else\ (rm -f $*.c $*.h; exit 1) \ fi BUILD_THEM_FILES = case $* in \ *marshal*) $(GENMARSHAL_CMD) $*.list ... ;; \ *) $(PARSE) $*.list ... ;; \ esac .list.h: $(LIST_H_CMDS) .list.c: $(LIST_H_CMDS) All the variables in the commands, are expanded just before execution, so the usage of $* ``outside of a rule'' is correct here. But when I recall that all this is done just to be able to do xx_SOURCES = foo.list ... intead of xx_SOURCES = ... nodist_xx_SOURCES = foo.c EXTRA_DIST = foo.list then I agree it's not worth it. (Setting CLEANFILES = foo.c foo.h; BUILT_SOURCES = foo.h is necessary in both cases.) Have a nice day, Stepan
Re: builddir vs. srcdir
> Hi, > > On Wed, Mar 09, 2005 at 11:21:35PM +0200, Paul Pogonyshev wrote: > > > And I'd like to suggest that you use SUFFIXES to handle the .list > > > source. Please look at the following example: > > > > Well, my generator is even more non-standard, since I need to pass an > > additional command-line parameter sometimes. So, `SUFFIXES' are not an > > option, although I agree it would have been nicer to use them. > > well, in the example I cited, I had several .list sources, but only one > in each directory. Thus I was able to have different rules in different > directories. > > This is not usable for you, but you can make the .list.h rule general: > > $(PARSE) `case "$*" in *this.list) echo "this options";; \ > *that.list) echo "that opt";; *) echo "default opt";;esac` $< > > ($* is substituted by make) Well, I also need something like `echo "$*" | sed 's/\.h$/.c/'` (not tested), so using suffix rules seems like too much trouble. Besides, in one directory I have two `.list' files, one of which is processed by my parser, while the other---by `glib-genmarshal' (I chose my suffix before I even started with GTK+ GUI.) > Or you can place the options at the first line of the .list source > and grep for them. Then I could just make the parser read them as well. That might be a good idea, actually, since these options are more like modes that are absolutely necessary to be set correctly to parse anything. > And if your generator creates *.c file after *.h file, you should > define the dependency: > foo.c: foo.h > and vice versa if the generator creates .h after .c. > That will make make happy and you won't observe repeated re-generation > of the .c file. I'm not sure which one comes first. They are generated on-the-fly in parallel (i.e. fprintf's to both files are mixed.) I assume in this case I can just do foo.c : foo.h foo.c foo.h : ... if $(BUILD_THEM_FILES) foo.list foo.h foo.c; then \ touch foo.c; \ else\ (rm -f foo.c foo.h; exit 1) \ fi right? BTW, I have just built everything in a separate directory for the first time :) I need to sort out that parallel building stuff, but otherwise all works perfectly. Thanks for your help. Paul
Re: builddir vs. srcdir
Alexandre Duret-Lutz wrote: > >>> "Paul" == Paul Pogonyshev <[EMAIL PROTECTED]> writes: > > Paul> Stepan Kasal wrote: > >> Hello, > >> > >> On Tue, Mar 08, 2005 at 11:56:56PM +0200, Paul Pogonyshev wrote: > >> > because the generated sources are placed into the build directory, > >> > while `make' looks for them in the source directory. > >> > >> generally, make should look for them in both places. > > Paul> Yes, and it does look in both places, but the dependencies make > `foo.o' Paul> depend on `$(srcdir)/foo.c', > > This could happen if this location was the right one in the > past, and building foo.c in the build directory is a recent > change. In that case the dependency file still have the old > info. > > The way to erase dependency info is distclean: > > make -k distclean; ./configure; make Yup, you are right, thanks. Should have guessed myself... >:[ Paul
Re: builddir vs. srcdir
>>> "Harald" == Harald Dunkel <[EMAIL PROTECTED]> writes: Harald> Whats about a more general case http://sources.redhat.com/automake/automake.html#Multiple-Outputs -- Alexandre Duret-Lutz
Re: builddir vs. srcdir
Hi, On Wed, Mar 09, 2005 at 11:21:35PM +0200, Paul Pogonyshev wrote: > > And I'd like to suggest that you use SUFFIXES to handle the .list > > source. Please look at the following example: > > Well, my generator is even more non-standard, since I need to pass an > additional command-line parameter sometimes. So, `SUFFIXES' are not an > option, although I agree it would have been nicer to use them. well, in the example I cited, I had several .list sources, but only one in each directory. Thus I was able to have different rules in different directories. This is not usable for you, but you can make the .list.h rule general: $(PARSE) `case "$*" in *this.list) echo "this options";; \ *that.list) echo "that opt";; *) echo "default opt";;esac` $< ($* is substituted by make) Or you can place the options at the first line of the .list source and grep for them. And if your generator creates *.c file after *.h file, you should define the dependency: foo.c: foo.h and vice versa if the generator creates .h after .c. That will make make happy and you won't observe repeated re-generation of the .c file. HTH, Stepan Kasal
Re: builddir vs. srcdir
* Harald Dunkel wrote on Thu, Mar 10, 2005 at 09:27:34AM CET: > Stepan Kasal wrote: > >On Tue, Mar 08, 2005 at 11:56:56PM +0200, Paul Pogonyshev wrote: > > > >>foo.c foo.h : $(srcdir)/foo.list $(PARSE_LIST) > >>$(PARSE_LIST) $(srcdir)/foo.list foo.h foo.c\ > >> || (rm -f foo.c foo.h ; exit 1) > > > >This rule can break with parallel make. > > > >You can solve the second issue by adding the dependency: > >foo.c: foo.h > > Whats about a more general case > > SOMEFILES=a b c d e > > $(SOMEFILES): srcfile > buildsomehow srcfile $(SOMEFILES) || (rm -f $(SOMEFILES); false) Please read info '(automake.info)Multiple Outputs' which comes with a recent Automake and documents the whole issue very thoroughly. Regards, Ralf
Re: builddir vs. srcdir
Stepan Kasal wrote: Hello, On Tue, Mar 08, 2005 at 11:56:56PM +0200, Paul Pogonyshev wrote: foo.c foo.h : $(srcdir)/foo.list $(PARSE_LIST) $(PARSE_LIST) $(srcdir)/foo.list foo.h foo.c\ || (rm -f foo.c foo.h ; exit 1) This rule can break with parallel make. You can solve the second issue by adding the dependency: foo.c: foo.h Whats about a more general case SOMEFILES=a b c d e $(SOMEFILES): srcfile buildsomehow srcfile $(SOMEFILES) || (rm -f $(SOMEFILES); false) ??? Regards Harri
Re: builddir vs. srcdir
>>> "Paul" == Paul Pogonyshev <[EMAIL PROTECTED]> writes: Paul> Stepan Kasal wrote: >> Hello, >> >> On Tue, Mar 08, 2005 at 11:56:56PM +0200, Paul Pogonyshev wrote: >> > because the generated sources are placed into the build directory, >> > while `make' looks for them in the source directory. >> >> generally, make should look for them in both places. Paul> Yes, and it does look in both places, but the dependencies make `foo.o' Paul> depend on `$(srcdir)/foo.c', This could happen if this location was the right one in the past, and building foo.c in the build directory is a recent change. In that case the dependency file still have the old info. The way to erase dependency info is distclean: make -k distclean; ./configure; make -- Alexandre Duret-Lutz
Re: builddir vs. srcdir
Stepan Kasal wrote: > Hello, > > On Tue, Mar 08, 2005 at 11:56:56PM +0200, Paul Pogonyshev wrote: > > because the generated sources are placed into the build directory, > > while `make' looks for them in the source directory. > > generally, make should look for them in both places. Yes, and it does look in both places, but the dependencies make `foo.o' depend on `$(srcdir)/foo.c', so `make' tells it has no rule to build the latter. How do I make dependencies tell `foo.o' depends on `$(builddir)/foo.c' instead? > Let me point out several problems: > > BUILT_SOURCES = \ > > foo.c \ > > foo.h > > You probably need only the foo.h file here. Right. > > foo.c foo.h : $(srcdir)/foo.list $(PARSE_LIST) > > $(PARSE_LIST) $(srcdir)/foo.list foo.h foo.c\ > > > > || (rm -f foo.c foo.h ; exit 1) > > This rule can break with parallel make. > > For details about these two issues, see > http://sources.redhat.com/automake/automake.html#Built-sources-example > > You can solve the second issue by adding the dependency: > foo.c: foo.h > > Yet it might be more readable if you change your generator so that it > would generate .c and .h in separate runs. I'd hate to hack the generator for such a goal. I'll better stick with the `foo.c: foo.h' solution. Maybe generating two files at once is non- standard, but it seems natural, since they are so closely related and are built from one source file, and that's the way it works already. > And I'd like to suggest that you use SUFFIXES to handle the .list > source. Please look at the following example: Well, my generator is even more non-standard, since I need to pass an additional command-line parameter sometimes. So, `SUFFIXES' are not an option, although I agree it would have been nicer to use them. Paul
Re: builddir vs. srcdir
Hello, On Tue, Mar 08, 2005 at 11:56:56PM +0200, Paul Pogonyshev wrote: > because the generated sources are placed into the build directory, > while `make' looks for them in the source directory. generally, make should look for them in both places. Let me point out several problems: > BUILT_SOURCES = \ > foo.c \ > foo.h You probably need only the foo.h file here. > foo.c foo.h : $(srcdir)/foo.list $(PARSE_LIST) > $(PARSE_LIST) $(srcdir)/foo.list foo.h foo.c\ > || (rm -f foo.c foo.h ; exit 1) This rule can break with parallel make. For details about these two issues, see http://sources.redhat.com/automake/automake.html#Built-sources-example You can solve the second issue by adding the dependency: foo.c: foo.h Yet it might be more readable if you change your generator so that it would generate .c and .h in separate runs. And I'd like to suggest that you use SUFFIXES to handle the .list source. Please look at the following example: noinst_LTLIBRARIES = libgoffice-utils.la libgoffice_utils_la_SOURCES = \ go-marshalers.list \ go-font.c CLEANFILES =\ go-marshalers.h \ go-marshalers.c # A hint is needed to build the header first: BUILT_SOURCES = go-marshalers.h GENMARSHAL_COMMAND = $(GLIB_GENMARSHAL) --prefix=go_ SUFFIXES = .list .list.h: $(GLIB_GENMARSHAL) $(GENMARSHAL_COMMAND) --header $< >$@ .list.c: $(GLIB_GENMARSHAL) (echo '/* This file has been automatically generated. Do not edit. */' && \ echo '#include "$*.h"' && \ $(GENMARSHAL_COMMAND) --body $< ) >$@ This works with current Automake 1.9.5 (which I recommend), as well as an ancient 1.7.x version. HTH, Stepan Kasal
builddir vs. srcdir
Hi. I'm currently massaging my `Makefile.am's to allow building in a separate directory. However, I have a problem which I cannot find how to solve. I have a few source (`.c' and `.h') files which are generated at build time from another source using a custom utility. When the build directory is the same as the source directory, everything is fine. However, with separate build directory things go hairy, because the generated sources are placed into the build directory, while `make' looks for them in the source directory. Automake pseudo-code looks like this: noinst_LIBRARIES = libfoo.a BUILT_SOURCES = \ foo.c \ \ foo.h PARSE_LIST = ./parse-list$(EXEEXT) foo.c foo.h : $(srcdir)/foo.list $(PARSE_LIST) $(PARSE_LIST) $(srcdir)/foo.list foo.h foo.c\ || (rm -f foo.c foo.h ; exit 1) libfoo_a_SOURCES = ... nodist_libfoo_a_SOURCES = $(BUILT_SOURCES) plus the lines to build the parser utility and other non-important stuff. Paul
Re: `make dist' with srcdir != builddir
>>>>> "adl" == Alexandre Duret-Lutz <[EMAIL PROTECTED]> writes: adl> Some weeks ago Bruno Haible reported (in private mail) that adl> running `make dist' with srcdir != builddir could produce adl> distributions which are not up-to-date, especially if you have adl> generated files like bison parsers adl> This can be easily fixed by changing the distdir code to look for adl> files in the builddir first and failling back to look in the adl> srcdir if needed. FYI, I looked at this the other day and came to the same conclusion. I made this change. Tom
Re: `make dist' with srcdir != builddir
Tom> I think what we want is for the positioning of the .c file not to Tom> matter for the developer, but for the file to end up in the Tom> distribution made by `make dist'. adl> The following is how I intended to fix this. I'm not sure adl> it's what you want. Anyway the patch below won't apply since adl> it predates Akim's sourcequake; I have yet to figure where the adl> relevent passage has been moved :) It is in distdir.am. adl>* automake.in (handle_dist_worker): When building the distdir, adl>copy files from the build directory in preference to the source adl>directory; that way the distribution is always built from the adl>latest version of generated files. I'm leery of changing orderings like this. I don't understand how the file can end up in both the source and build trees. That is the mystery. I want to understand it before implementing a change. Tom
Re: `make dist' with srcdir != builddir
>>> "Tom" == Tom Tromey <[EMAIL PROTECTED]> writes: [...] Tom> I think what we want is for the positioning of the .c file not to Tom> matter for the developer, but for the file to end up in the Tom> distribution made by `make dist'. The following is how I intended to fix this. I'm not sure it's what you want. Anyway the patch below won't apply since it predates Akim's sourcequake; I have yet to figure where the relevent passage has been moved :) 2001-01-05 Alexandre Duret-Lutz <[EMAIL PROTECTED]> * automake.in (handle_dist_worker): When building the distdir, copy files from the build directory in preference to the source directory; that way the distribution is always built from the latest version of generated files. --- automake.in.old Fri Jan 5 19:30:53 2001 +++ automake.in Fri Jan 5 20:50:01 2001 @@ -2689,6 +2689,10 @@ . "\t|| exit 1; \\\n" . "\t else \\\n" . "\ttest -f \$(distdir)/\$\$file \\\n" + # First, look for $$files in the build directory, + # and else get it from the source directory. + . "\t|| (test -f \$\$file && " + . "cp -p \$\$file \$(distdir)/\$\$file) \\\n" . "\t|| cp -p \$\$d/\$\$file \$(distdir)/\$\$file \\\n" . "\t|| exit 1; \\\n" . "\t fi; \\\n" [...] -- Alexandre Duret-Lutz
Re: `make dist' with srcdir != builddir
>>>>> "adl" == Alexandre Duret-Lutz <[EMAIL PROTECTED]> writes: adl> This can be easily fixed by changing the distdir code to look for adl> files in the builddir first and failling back to look in the adl> srcdir if needed. But maybe this is not the right fix; maybe adl> bison should not output its parsers in the builddir but in the adl> srcdir instead (actually, this is what the GNU Standards ask adl> for). I'm checking in your test case. The bison output issue is a more complicated than you might expect. GNU Standards requires bison output files to be in srcdir. However, at least historically, some people don't like this. That's why the rules are written the way they are -- they let us put the output in the srcdir or the build dir depending on how things are set up. I think what we want is for the positioning of the .c file not to matter for the developer, but for the file to end up in the distribution made by `make dist'. I'll investigate this at some point before 1.4f. Tom
`make dist' with srcdir != builddir
Some weeks ago Bruno Haible reported (in private mail) that
running `make dist' with srcdir != builddir could produce
distributions which are not up-to-date, especially if you have
generated files like bison parsers: $builddir/parser.c would be
updated whenever $srcdir/parser.y is changed but the
distribution would ship with an old $srcdir/parser.c instead of
the fresh $builddir/parser.c. Fortunately, this is detected if
you run `make distcheck' instead of `make dist', because the
buildir is non empty after `make distclean' (parser.c is left).
This can be easily fixed by changing the distdir code to look
for files in the builddir first and failling back to look in the
srcdir if needed. But maybe this is not the right fix; maybe
bison should not output its parsers in the builddir but in the
srcdir instead (actually, this is what the GNU Standards ask
for).
I have attempted to build a testcase that demonstrates the
failure, but unfortunately it fails before this error! (it is
expected to fail at the end of `make distcheck', where the build
directory is listed to see if there are any file left).
On Automake 1.4d it fails in `make distcheck' with:
make[3]: Entering directory
`/home/adl/projs/automake-1.4d/tests/testSubDir/sub/foo-0.1/=build'
chmod -R a+w foo-0.1 > /dev/null 2>&1; rm -rf foo-0.1
mkdir foo-0.1
/bin/sh ../../../mkinstalldirs foo-0.1/../.. ../..
cp: cannot create regular file `foo-0.1/../../install-sh': Permission denied
make[3]: *** [distdir] Error 1
make[3]: Leaving directory
`/home/adl/projs/automake-1.4d/tests/testSubDir/sub/foo-0.1/=build'
make[2]: *** [distcheck] Error 2
make[2]: Leaving directory `/home/adl/projs/automake-1.4d/tests/testSubDir/sub'
FAIL: yaccvpath.test
Today's CVS Automake fails likewise on another file.
I assume this is related to
...utomake-1.4d/tests/testSubDir % grep \^DIST_COMMON Makefile.in
DIST_COMMON = ../../depcomp ../../install-sh ../../missing \
I don't understand where these `../../' come from, I whish
someone could shed some light on this. It looks like the
Makefile uses the tools installed in Automake's directory
instead of those installed locally. If I run the test manually,
with Autoconf-1.4d installed in my PATH, it runs fine (i.e. it's
stop at the expected place and don't add those annoying
`../../').
Here is the file.
#! /bin/sh
# This attempts to `make distcheck' from a separate directory
# (i.e. builddir!=srcdir). Before doing `make distcheck' a parser
# definition is updated in the srcdir in order to check whether the
# archived perser is up-to-date or not.
. $srcdir/defs || exit 1
cat > configure.in << 'END'
AC_INIT
AM_INIT_AUTOMAKE(foo, 0.1)
PACKAGE=foo
VERSION=0.1
AC_PROG_CC
AC_PROG_YACC
AC_OUTPUT(Makefile)
END
cat > Makefile.am << 'END'
bin_PROGRAMS= foo
foo_SOURCES= parse.y foo.c
END
cat > parse.y << 'END'
%{
int yylex () {return 0;}
void yyerror (char *s) {}
%}
%%
foobar : 'f' 'o' 'o' 'b' 'a' 'r' {};
END
cat > foo.c << 'END'
int main () { return 0; }
END
# Fail gracefully if no autoconf.
$needs_autoconf
# Likewise for gcc.
(gcc -v) > /dev/null 2>&1 || exit 77
# Remove some files installed by defs.
# They will be reinstalled by automake.
rm -f install-sh missing mkinstalldirs
set -e
$ACLOCAL
$AUTOCONF
$AUTOMAKE -a
./configure
$MAKE
$MAKE distclean
# this should left parse.c in the current directory
cat >> parse.y << 'END'
fubar : 'f' foobar {};
END
mkdir sub
cd sub
../configure
$MAKE
$MAKE distcheck
--
Alexandre Duret-Lutz
Re: tags and config.in when srcdir!=builddir
> "Kevin" == Kevin Ryde <[EMAIL PROTECTED]> writes: Kevin> Using a recent cvs automake, I tried "make TAGS" in a separate Kevin> object directory, but the etags command got config.in without a Kevin> $(srcdir) path. Perhaps the @CONFIG@ in tags.am should be in Kevin> the list that gets uniquified and checked for needing Kevin> $(srcdir). The same might apply to $(LISP) there too, but I Kevin> haven't tried that. Yeah, you're probably right. That seems like an easy change to make in tags.am. Kevin> Actually, etags by default doesn't match anything in a Kevin> config.in containing only #undefs, so this isn't important, Kevin> it's just to get the target to go through. Maybe tags on the Kevin> generated config.h would be more use. I think so too. Tom
tags and config.in when srcdir!=builddir
Using a recent cvs automake, I tried "make TAGS" in a separate object directory, but the etags command got config.in without a $(srcdir) path. Perhaps the @CONFIG@ in tags.am should be in the list that gets uniquified and checked for needing $(srcdir). The same might apply to $(LISP) there too, but I haven't tried that. Actually, etags by default doesn't match anything in a config.in containing only #undefs, so this isn't important, it's just to get the target to go through. Maybe tags on the generated config.h would be more use. Or maybe not.
