Re: gettext-0.14.2 fails on parallel build
Hi,
On Wed, Mar 16, 2005 at 03:08:06PM +0100, Bruno Haible wrote:
mv -f elc-temp $@
..
mv -f elc-temp $@ || { touch $@; rm -f elc-temp; }
But this change is incorrect. It canmcels the whole trick:
touch tmp
...
mv tmp $@
ensures that the stamp file will be older than the files created by
If the rule were:
...
touch $@
then each make would rebuild the files, with new stamp.
Though with your code it doesn't happen always, the problem is still there.
Stepan
Re: gettext-0.14.2 fails on parallel build
Stepan Kasal wrote:
mv -f elc-temp $@
..
mv -f elc-temp $@ || { touch $@; rm -f elc-temp; }
But this change is incorrect. It canmcels the whole trick:
touch tmp
...
mv tmp $@
ensures that the stamp file will be older than the files created by
OK, then change
mv -f elc-temp $@
to
mv -f elc-temp $@ || rm -f elc-temp
Bruno
Re: gettext-0.14.2 fails on parallel build
On Wed, Mar 16, 2005 at 03:08:06PM +0100, Bruno Haible wrote: Alexandre Duret-Lutz wrote: Thanks, I'm installing the following fix on HEAD and branch-1-9. ... -## Recover from the removal of $@ - @if test ! -f $@; then \ +## Recover from the removal of [EMAIL PROTECTED] +## +## Make sure not to call `make elc-stamp' if emacs is not available, +## because as all *.elc files appear as missing, a parallel make would +## attempt to build elc-stamp several times. + @if test $(EMACS) != no test ! -f $@; then \ IMO this does not fix the bug. It only makes it less likely to appear. What happened was: In the rules elc-stamp: $(LISP) @rm -f elc-temp touch elc-temp ... @mv -f elc-temp $@ 3 independent 'make' processes started working on this rule. It seems you are trying to allow this, but that is precisely the bug I wanted to fix. The other points are consequences. Only one instance of any rule in a Makefile should run at the same time. Process 1 created elc-temp. Process 2 re-created elc-temp. Then process 1 and process 2 performed the ... task. Process 1 moved elc-temp to elc-stemp. Process 2 attempted to do so as well, but elc-temp was already gone. For this to happen, the contents of the ... task is irrelevant. Well, if you want to allow parallel executions of ..., its contents really matter since all instance are likely to use the same ressources (e.g. compiling the same files... eww). But really we do not want this: there is no reason to build the same target more than once. Adding test $(EMACS) != no doesn't change the problem. It gets rid of these 3 independent 'make' processes. (Those are not started when emacs exists, because when emacs exists the *.elc files have already been built and the `test ! -f $@' above fails.) Here is another angle to the problem that might help: this whole issue would not exist if the `$(am__ELCFILES): elc-stamp' rule did not have any command.
Re: gettext-0.14.2 fails on parallel build
Alexandre Duret-Lutz wrote:
Thanks, I'm installing the following fix on HEAD and branch-1-9.
...
-## Recover from the removal of $@
- @if test ! -f $@; then \
+## Recover from the removal of [EMAIL PROTECTED]
+##
+## Make sure not to call `make elc-stamp' if emacs is not available,
+## because as all *.elc files appear as missing, a parallel make would
+## attempt to build elc-stamp several times.
+ @if test $(EMACS) != no test ! -f $@; then \
IMO this does not fix the bug. It only makes it less likely to appear.
What happened was: In the rules
elc-stamp: $(LISP)
@rm -f elc-temp touch elc-temp
...
@mv -f elc-temp $@
3 independent 'make' processes started working on this rule.
Process 1 created elc-temp.
Process 2 re-created elc-temp.
Then process 1 and process 2 performed the ... task.
Process 1 moved elc-temp to elc-stemp.
Process 2 attempted to do so as well, but elc-temp was already gone.
For this to happen, the contents of the ... task is irrelevant.
Adding test $(EMACS) != no doesn't change the problem.
The bug could still occur when the ... task is very quick.
The fix I would propose instead is to change
mv -f elc-temp $@
to
mv -f elc-temp $@ || { touch $@; rm -f elc-temp; }
This will ensure that the process which comes too late succeeds nevertheless.
Bruno
Re: Including local macros with ACLOCAL_AMFLAGS
On Wednesday 16 March 2005 08:12, Ralf Wildenhues wrote: Oh, or are you invoking aclocal directly? Then you should do aclocal -I m4 ACLOCAL_AMFLAGS are only respected by the rebuilding rules put in Makefile.in and by autoreconf. Thanks for your help, Ralf. I was invoking aclocal directly. :) Best regards, -- Rohnny
help with these errors
Hi, I see the following errors during buildconf or configure and don't know what is causing them. Please advise what they mean and how to troubleshoot them. thanks, Hong Liu checking for ANSI C header files... no .. checking size of char... 0 checking size of int... 0 checking size of long... 0 checking size of short... 0 checking size of long double... 0 checking size of long long... 0 checking size of ssize_t... 0 checking size of size_t... 0 checking size of off_t... 0 checking size of pid_t... 0
make uninstall could do rmdir
Hello, recently, I run make uninstall with a package I previously installed by make install. The package heavily uses the feature foodir = ... foo_HEADERS = ... and thus created many directories. After the uninstall, the directories are empty. I imagined that make uninstall could remove them in such case. Why this is not working? Is there an easy way to accomplish this? I see the manual says: Note that `uninstall' is not meant as a replacement for a real packaging tool. So perhaps that is the answer. Thank you in advance for any comments. Stepan Kasal
Re: make uninstall could do rmdir
Hi Stepan, * Stepan Kasal wrote on Wed, Mar 16, 2005 at 04:40:01PM CET: recently, I run make uninstall with a package I previously installed by make install. The package heavily uses the feature foodir = ... foo_HEADERS = ... and thus created many directories. After the uninstall, the directories are empty. I imagined that make uninstall could remove them in such case. Why this is not working? Feature: the directories it would remove are not part of the package. This is arguable, but it would be very surprising if `make uninstall' removed /usr/local/bin which was previously set up with special permissions and owner. For nonstandard directories, this might be even more arguable. But then again, removing empty directories from a tree is trivial, and, as the comment you quoted says: Note that `uninstall' is not meant as a replacement for a real packaging tool. Regards, Ralf
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: I: adjust test suite for upcoming GNU Make 3.83
pds == Paul D Smith [EMAIL PROTECTED] writes: [...] pds I'm interested in discussing the issue and possible solutions. The one pds I added to the bug report involves using :=, since simply-expanded pds variables in GNU make are always only expanded one time, no matter how pds many times they're referenced (unless within an eval function). But, pds obviously, using := does not yield a portable makefile. Actually it does not appear to work here. I compiled CVS make, and patched Automake as follows. --- tests/dollar.test 14 Nov 2003 21:25:58 - 1.7 +++ tests/dollar.test 16 Mar 2005 22:32:49 - @@ -33,7 +33,7 @@ cat Makefile.am 'EOF' mydir = $(prefix)/my -dist_my_DATA = hello$$world +dist_my_DATA := hello$$world check-dist: distdir test -f '$(distdir)/hello$$world' @@ -43,7 +43,7 @@ $ACLOCAL $AUTOCONF -$AUTOMAKE +$AUTOMAKE -Wno-portability ./configure --prefix `pwd`/inst $MAKE install test -f 'inst/my/hello$world' This test still fails with | ~/projs/cvs/automake/HEAD3/tests % ./dollar.test | /home/adl/projs/cvs/automake/HEAD3/tests:/home/adl/usr/bin:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games | dollar: running make --version -v | grep GNU | GNU Make 3.81beta3 | === Running test ./dollar.test | ++ pwd | /home/adl/projs/cvs/automake/HEAD3/tests/testSubDir | + set -e | + echo AC_OUTPUT | + cat | + : | + aclocal-1.9a -Werror | + autoconf | + automake-1.9a --foreign -Werror -Wall -Wno-portability | ++ pwd | + ./configure --prefix /home/adl/projs/cvs/automake/HEAD3/tests/testSubDir/inst | checking for a BSD-compatible install... /usr/bin/install -c | checking whether build environment is sane... yes | checking for gawk... gawk | checking whether make sets $(MAKE)... yes | configure: creating ./config.status | config.status: creating Makefile | + make install | make: *** No rule to make target `helloorld', needed by `all-am'. Stop. the generated Makefile contains | dist_my_DATA := hello$$world | | DATA = $(dist_my_DATA) | | all-am: Makefile $(DATA) | | install-dist_myDATA: $(dist_my_DATA) | @$(NORMAL_INSTALL) | test -z $(mydir) || $(mkdir_p) $(DESTDIR)$(mydir) | @list='$(dist_my_DATA)'; for p in $$list; do \ | if test -f $$p; then d=; else d=$(srcdir)/; fi; \ | f=$(am__strip_dir) \ | echo $(dist_myDATA_INSTALL) '$$d$$p' '$(DESTDIR)$(mydir)/$$f'; \ | $(dist_myDATA_INSTALL) $$d$$p $(DESTDIR)$(mydir)/$$f; \ | done this seems to imply that simply-expanded variables are re-expanded when they appear inside deferred variables. If I manually change `DATA = $(dist_my_DATA)' (this is not a real solution, because this line is generated by Automake) to `DATA := $(dist_my_DATA)', then the all-am rule passes, but the test fails later with make[1]: *** No rule to make target `helloorld', needed by `install-dist_myDATA'. Stop. -- Alexandre Duret-Lutz
