Re: Intermittent test failures
Hi Ralf! Ralf Wildenhues ralf.wildenh...@gmx.de writes: * Ralf Wildenhues wrote on Sat, Jul 31, 2010 at 02:11:59PM CEST: * Ludovic Courtès wrote on Tue, Jul 27, 2010 at 11:08:39AM CEST: FYI the Automake test suite currently fails on Hydra. The build at http://hydra.nixos.org/build/502179 has 5 failures; the one at http://hydra.nixos.org/build/502171 has 2 failures, etc. thanks again for the report. Can you please check with the system administrator to find out whether the system has 1s granularity on time stamps or higher? ls -l --full-time in some directory on the same partition should hopefully answer that, if coreutils is not borked. And if better, we need to find out whether perl supports subsecond granularity and if that is true, whether Automake may have a bug in not getting/using that information correctly. If the file system granularity is 1s, then, the next steps are either: - making sure between start of configure and start of config.status at least 1s has passed (i.e., either reinstate the sleep in the sanity test or start a background sleep and check that before starting config.status) I now have a patch for the issue introduced in Automake git master with http://thread.gmane.org/gmane.comp.sysutils.automake.patches/3643/ where the sanity check was changed to not sleep for a second by default any more. The patch is below. It would be nice if you could test it and report back. Or, if you prefer, I can apply and we see how build daemons react. [...] Fix timestamp issues by ensuring configure takes at least a second. * m4/sanity.m4 (AM_SANITY_CHECK): If we didn't sleep here, start a sleep in the background and wait for it to finish before creating config.status, hopefully fixing all spurious testsuite failures involving botched time stamps. * NEWS: Update. Reports by Ludovic Courtès, Peter Breitenlohner, and others. I applied the patch yesterday for the Hydra builder, so builds done with the tarball from build #600499 or later have the patch: http://hydra.nixos.org/jobset/gnu/automake-master/all I’ll let you analyze the results. ;-) Besides, python11.test fails, whereas it should just be skipped, I think (Python isn’t available in the build environment.) Thanks, Ludo’.
Re: Intermittent test failures
Hi Ralf! Ralf Wildenhues ralf.wildenh...@gmx.de writes: * Ralf Wildenhues wrote on Sat, Jul 31, 2010 at 02:11:59PM CEST: * Ludovic Courtès wrote on Tue, Jul 27, 2010 at 11:08:39AM CEST: FYI the Automake test suite currently fails on Hydra. The build at http://hydra.nixos.org/build/502179 has 5 failures; the one at http://hydra.nixos.org/build/502171 has 2 failures, etc. thanks again for the report. Can you please check with the system administrator to find out whether the system has 1s granularity on time stamps or higher? ls -l --full-time in some directory on the same partition should hopefully answer that, if coreutils is not borked. And if better, we need to find out whether perl supports subsecond granularity and if that is true, whether Automake may have a bug in not getting/using that information correctly. If the file system granularity is 1s, then, the next steps are either: - making sure between start of configure and start of config.status at least 1s has passed (i.e., either reinstate the sleep in the sanity test or start a background sleep and check that before starting config.status) I now have a patch for the issue introduced in Automake git master with http://thread.gmane.org/gmane.comp.sysutils.automake.patches/3643/ where the sanity check was changed to not sleep for a second by default any more. The patch is below. It would be nice if you could test it and report back. Or, if you prefer, I can apply and we see how build daemons react. [...] Fix timestamp issues by ensuring configure takes at least a second. * m4/sanity.m4 (AM_SANITY_CHECK): If we didn't sleep here, start a sleep in the background and wait for it to finish before creating config.status, hopefully fixing all spurious testsuite failures involving botched time stamps. * NEWS: Update. Reports by Ludovic Courtès, Peter Breitenlohner, and others. I applied the patch yesterday for the Hydra builder, so builds done with the tarball from build #600499 or later have the patch: http://hydra.nixos.org/jobset/gnu/automake-master/all I’ll let you analyze the results. ;-) Besides, python11.test fails, whereas it should just be skipped, I think (Python isn’t available in the build environment.) Thanks, Ludo’.
convert a pattern rule to a suffix rule
Hello, I know that pattern rules are not portable. When we use one pattern rule, then we call autoreconf, we can see this warning : man/Makefile.am:8: `%'-style pattern rules are a GNU make extension So if we want a protable project, we should not use them in a Makefile.am file. But we can use a old fashioned suffix rule which is portable. The problem is when the prerequisites arn't in the same directory than the target and when the prerequisites have no suffix. In this Makefile.am (see below) -the target is in the . directory -the prerequisites are in the ../src/ directory -the prerequisites have no suffix Makefile.am --- dist_man_MANS = t4e.1 HELP2MAN = help2man -h -h -v -v -N RM = rm -rfv all-local: $(dist_man_MANS) %.1: ../src/% $(HELP2MAN) $ -o $@ clean-local: $(RM) *.1 --- I use a pattern rule which is not portable because I don't know how to convert it in a suffix rule. How to convert this pattern rule in a suffix rule? Thank you. -- YuGiOhJCJ Mailing-List yugiohjcj-mailingl...@laposte.net
order of variables and rules in output
In a Makefile, the relative order of variable and rule definitions matters, because variables used in targets are expanded when rules are read. If a variable is used in a target before the variable is changed, the variable's former expansion is used in the target, not the latter expansion. Current Automake appears to reorder the Makefile.am so that all variable assignments precede all rules, so in a Makefile.am the relative order of variable and rule definitions does not matter. Is this behavior documented? Is it guaranteed to remain in the future? I could not easily find mention of it in the manual, but it is sometimes convenient. Thanks, Ben. -- Ben Pfaff http://benpfaff.org
Re: order of variables and rules in output
Hi Ben, * Ben Pfaff wrote on Wed, Aug 25, 2010 at 07:22:58PM CEST: Current Automake appears to reorder the Makefile.am so that all variable assignments precede all rules, so in a Makefile.am the relative order of variable and rule definitions does not matter. Right. Is this behavior documented? I thought so, but can't find it right away now. In any case, we cannot guarantee to *not* reorder because the flattening of += and the expansion of conditionals would probably not work otherwise. Is it guaranteed to remain in the future? I could not easily find mention of it in the manual, but it is sometimes convenient. Yes, that is the intention, and yes, I agree that it is convenient. Thanks, Ralf
Re: convert a pattern rule to a suffix rule
Hello, * YuGiOhJCJ Mailing-List wrote on Wed, Aug 25, 2010 at 11:14:15AM CEST: I know that pattern rules are not portable. When we use one pattern rule, then we call autoreconf, we can see this warning : man/Makefile.am:8: `%'-style pattern rules are a GNU make extension So if we want a protable project, we should not use them in a Makefile.am file. Or you use -Wno-portability to silence the warning, and require GNU make for building your project. But we can use a old fashioned suffix rule which is portable. The problem is when the prerequisites arn't in the same directory than the target and when the prerequisites have no suffix. Then you cannot use suffix rules in a portable way, unfortunately; you can get around the directory fairly portably by setting something like VPATH = @srcdir@:../src:@srcdir@/../src in the Makefile.am and then forget about the directory (but you need a new Autoconf for this to work because we recently found an Autoconf bug in this area), but single suffix rules work the other way round; see for example `info Autoconf Single Suffix Rules'. If you don't want to require GNU make, the only fully portable way I know is to spell out the rule for each target. Hope that helps. Cheers, Ralf
