bug#7833: automake uses two different values for DejaGNU srcdir
* Ian Lance Taylor wrote on Thu, Jan 13, 2011 at 06:29:39PM CET: Ralf Wildenhues writes: Am I correct in assuming that it is hopeless to assume GCC will work when either values are relative? Actually, as far as I know, GCC is likely to work with a relative srcdir. The problem arises with DejaGNU .exp files which themselves change directories. As far as I know, the GCC DejaGNU files do not do that. Thanks for the feedback. Through testing I found out again that DejaGNU does not cope with white space in absolute directory names anyway, regardless of srcdir being relative or absolute. That obviates my first point. Remains only the fairly minor src+build-tree relocatability point. I have these two alternative patches which I would both be happy with. I should note that the Life is easiest comment dates back to the very first addition of dejagnu support in Automake, from way before recorded history where we could learn from a related bug. Tried both in a multilib target directory in the GCC tree, both seem to work. Any preferences, from a DejaGNU standpoint? Thanks, Ralf * lib/am/dejagnu.am (check-DEJAGNU): Set srcdir to be relative, consistent with the --srcdir argument and the srcdir setting in site.exp. Report by Ian Lance Taylor in automake bug#7833. --- am/dejagnu.am.orig 2011-01-14 20:27:32.0 +0100 +++ am/dejagnu.am.1 2011-01-14 20:27:38.0 +0100 @@ -1,5 +1,5 @@ ## automake - create Makefile.in from Makefile.am -## Copyright (C) 1994, 1995, 1996, 1997, 2000, 2001, 2003, 2006 +## Copyright (C) 1994, 1995, 1996, 1997, 2000, 2001, 2003, 2006, 2011 ## Free Software Foundation, Inc. ## This program is free software; you can redistribute it and/or modify @@ -43,8 +43,7 @@ .PHONY: check-DEJAGNU check-DEJAGNU: site.exp -## Life is easiest with an absolute srcdir, so do that. - srcdir=`$(am__cd) $(srcdir) pwd`; export srcdir; \ + srcdir='$(srcdir)'; export srcdir; \ EXPECT=$(EXPECT); export EXPECT; \ ## Allow this to work when expect and DejaGnu are in tree. ## Only required when --cygnus in force. * lib/am/dejagnu.am (RUNTESTDEFAULTFLAGS): Quote argument to --srcdir. (site.exp): Set srcdir to $(abs_srcdir). Report by Ian Lance Taylor in automake bug#7833. --- am/dejagnu.am.orig 2011-01-14 20:27:32.0 +0100 +++ am/dejagnu.am.2 2011-01-14 20:20:22.0 +0100 @@ -1,5 +1,5 @@ ## automake - create Makefile.in from Makefile.am -## Copyright (C) 1994, 1995, 1996, 1997, 2000, 2001, 2003, 2006 +## Copyright (C) 1994, 1995, 1996, 1997, 2000, 2001, 2003, 2006, 2011 ## Free Software Foundation, Inc. ## This program is free software; you can redistribute it and/or modify @@ -19,7 +19,7 @@ DEJATOOL = $(PACKAGE) ## Default flags to pass to dejagnu. The user can override this. -RUNTESTDEFAULTFLAGS = --tool $$tool --srcdir $$srcdir +RUNTESTDEFAULTFLAGS = --tool $$tool --srcdir $$srcdir ## In Cygnus mode, these are found in the build tree. ## Otherwise they are looked for in $PATH. @@ -77,7 +77,7 @@ @echo '## these variables are automatically generated by make ##' site.tmp @echo '# Do not edit here. If you wish to override these values' site.tmp @echo '# edit the last section' site.tmp - @echo 'set srcdir $(srcdir)' site.tmp + @echo 'set srcdir $(abs_srcdir)' site.tmp @echo set objdir `pwd` site.tmp ## Quote the *_alias variables because they might be empty. ?BUILD?@echo 'set build_alias $(build_alias)' site.tmp
Re: [PATCH 7/9] Warnings win over strictness in AUTOMAKE_OPTIONS.
And below is the dif for the sanity check I'd like to squash in.
OK?
Regards,
Stefano
-*-*-
diff --git a/ChangeLog b/ChangeLog
index 78452d8..82ef6a1 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -8,6 +8,10 @@
This finally fixes Automake bug#7669 a.k.a. PR/547.
* automake.in (handle_options): Call 'process_option_list'
only once per set of options.
+ * lib/Automake/Options.pm (process_global_option_list,
+ process_option_list): Add sanity checks.
+ ($_options_processed, $_global_options_processed): New
+ internal variables, used by the sanity checks above.
* tests/warnings-win-over-strictness.test: Extend.
2011-01-02 Stefano Lattarini stefano.lattar...@gmail.com
diff --git a/lib/Automake/Options.pm b/lib/Automake/Options.pm
index 9f22178..d1b6af5 100644
--- a/lib/Automake/Options.pm
+++ b/lib/Automake/Options.pm
@@ -76,6 +76,12 @@ FMakefile.ams.
use vars '%_options'; # From AUTOMAKE_OPTIONS
use vars '%_global_options'; # from AM_INIT_AUTOMAKE or the command line.
+# Whether process_option_list has already been called for the current
+# Makefile.am.
+use vars '$_options_processed';
+# Whether process_global_option_list has already been called.
+use vars '$_global_options_processed';
+
=head2 Constants
=over 4
@@ -135,6 +141,7 @@ previous FMakefile.am.
sub reset ()
{
+ $_options_processed = 0;
%_options = %_global_options;
# The first time we are run,
# remember the current setting as the default.
@@ -345,14 +352,25 @@ sub _process_option_list (\%@)
return 0;
}
+# Note the sanity checks: these function should be called at most once for
+# each set of options having the same precedence; otherwise, we couldn't
+# guarantee that explicitly-specified warning levels take precedence
+# over strictness-implied ones.
+
sub process_option_list (@)
{
+ prog_error local options already processed
+if ($_options_processed);
return _process_option_list (%_options, @_);
+ $_options_processed = 1;
}
sub process_global_option_list (@)
{
+ prog_error global options already processed
+if ($_global_options_processed);
return _process_option_list (%_global_options, @_);
+ $_global_options_processed = 1;
}
=item Cset_strictness ($name)
Re: bug#7833: automake uses two different values for DejaGNU srcdir
* Ian Lance Taylor wrote on Thu, Jan 13, 2011 at 06:29:39PM CET: Ralf Wildenhues writes: Am I correct in assuming that it is hopeless to assume GCC will work when either values are relative? Actually, as far as I know, GCC is likely to work with a relative srcdir. The problem arises with DejaGNU .exp files which themselves change directories. As far as I know, the GCC DejaGNU files do not do that. Thanks for the feedback. Through testing I found out again that DejaGNU does not cope with white space in absolute directory names anyway, regardless of srcdir being relative or absolute. That obviates my first point. Remains only the fairly minor src+build-tree relocatability point. I have these two alternative patches which I would both be happy with. I should note that the Life is easiest comment dates back to the very first addition of dejagnu support in Automake, from way before recorded history where we could learn from a related bug. Tried both in a multilib target directory in the GCC tree, both seem to work. Any preferences, from a DejaGNU standpoint? Thanks, Ralf * lib/am/dejagnu.am (check-DEJAGNU): Set srcdir to be relative, consistent with the --srcdir argument and the srcdir setting in site.exp. Report by Ian Lance Taylor in automake bug#7833. --- am/dejagnu.am.orig 2011-01-14 20:27:32.0 +0100 +++ am/dejagnu.am.1 2011-01-14 20:27:38.0 +0100 @@ -1,5 +1,5 @@ ## automake - create Makefile.in from Makefile.am -## Copyright (C) 1994, 1995, 1996, 1997, 2000, 2001, 2003, 2006 +## Copyright (C) 1994, 1995, 1996, 1997, 2000, 2001, 2003, 2006, 2011 ## Free Software Foundation, Inc. ## This program is free software; you can redistribute it and/or modify @@ -43,8 +43,7 @@ .PHONY: check-DEJAGNU check-DEJAGNU: site.exp -## Life is easiest with an absolute srcdir, so do that. - srcdir=`$(am__cd) $(srcdir) pwd`; export srcdir; \ + srcdir='$(srcdir)'; export srcdir; \ EXPECT=$(EXPECT); export EXPECT; \ ## Allow this to work when expect and DejaGnu are in tree. ## Only required when --cygnus in force. * lib/am/dejagnu.am (RUNTESTDEFAULTFLAGS): Quote argument to --srcdir. (site.exp): Set srcdir to $(abs_srcdir). Report by Ian Lance Taylor in automake bug#7833. --- am/dejagnu.am.orig 2011-01-14 20:27:32.0 +0100 +++ am/dejagnu.am.2 2011-01-14 20:20:22.0 +0100 @@ -1,5 +1,5 @@ ## automake - create Makefile.in from Makefile.am -## Copyright (C) 1994, 1995, 1996, 1997, 2000, 2001, 2003, 2006 +## Copyright (C) 1994, 1995, 1996, 1997, 2000, 2001, 2003, 2006, 2011 ## Free Software Foundation, Inc. ## This program is free software; you can redistribute it and/or modify @@ -19,7 +19,7 @@ DEJATOOL = $(PACKAGE) ## Default flags to pass to dejagnu. The user can override this. -RUNTESTDEFAULTFLAGS = --tool $$tool --srcdir $$srcdir +RUNTESTDEFAULTFLAGS = --tool $$tool --srcdir $$srcdir ## In Cygnus mode, these are found in the build tree. ## Otherwise they are looked for in $PATH. @@ -77,7 +77,7 @@ @echo '## these variables are automatically generated by make ##' site.tmp @echo '# Do not edit here. If you wish to override these values' site.tmp @echo '# edit the last section' site.tmp - @echo 'set srcdir $(srcdir)' site.tmp + @echo 'set srcdir $(abs_srcdir)' site.tmp @echo set objdir `pwd` site.tmp ## Quote the *_alias variables because they might be empty. ?BUILD?@echo 'set build_alias $(build_alias)' site.tmp
Re: make -j1 fails
On Thu, Jan 13, 2011 at 07:22:20PM +0100, Ralf Wildenhues wrote: Thanks for the bug report. Which version of Automake are you using? If older than v1.10b-62-g0e411a0, then please update to 1.11.1 and retry. It may be possible that we overlooked one case in the above-mentioned commit, but I don't see where that should be. I am using automake (GNU automake) 1.11.1 from Debian squeeze. If the failure persists, please post short configure.ac and Makefile.am which expose the problem for you. You can start with what I show below, and adjust that if it doesn't expose it. The code didn't trigger the bug and I couldn't easily reproduce it by modifying it. It involves considerable effort to modify my existing project and upload it to the FreeBSD build machine and I don't have time to do that, now. GNU make does not misbehave this way, so for now I'll use that. Does the failure happen reliably, i.e., every time, or only sometimes? It happens reliably with any N in make -jN. Does 'make -B -jN' work for you reliably? Yes, that works as expected and executes the right command (the one also executed without -jN). Which exact FreeBSD version are you using? I'm kind of suspecting a bug in the make implementation, or we're overlooking something with one-shell issues. I am using FreeBSD 8.0-RELEASE-p4. -- Pippijn van Steenhoven signature.asc Description: Digital signature
Re: [CRAZY PROPOSAL] Automake should support only GNU make
On Thu, Jan 13, 2011 at 8:39 PM, stefano.lattar...@gmail.com wrote: ``I truly dislike the idea of not keeping configuration and build steps separated.'' Maybe I'd just like a system that *allows* me to keep configuration and build steps clerarly distinct if I want to. Yes, that would be enough for me I guess. Maybe it is just a matter of terms, but I think the concept of configuration (as software configuration) is only about deciding which configure option to set or not to set; the configure run itself IMHO does not need to be separated from the rest of the building. Wouldn't it be great to type make which automatically knows by depedencies that some configuration rules have to be executed (i.e. to determine facts about the environment if they are not available in form of small .h files or alike)? Yes, but then, this could be implemented by having the build system call the configuration system properly, no? More or less like is done by automake-generated rebuild rules, just on steroid I guess. Yes, except that automake-autoconf rules implement a phase or stage idea: when a configure run is needed, it is performed entirely. So it can be seen as separated where the build system can trigger the configure run. If, for example, Makefiles would have rules to check for the libraries as soon as needed etc, wouldn't this be good? Tests that are not needed for the configuration to be built would not even be executed (saving time). What do you mean exactly by this? I'm not sure if this makes any sense, but I could imagine that if some file conditionally (enabled by some configure-as-in-software-configuration option) uses some feature which in turn depends on a platform function that has to be checked, then in this moment this single test could be performed. Let's say I used some --enable-tcp switch. The build system finds that in this case it needs tcp.o. By some depedency tcp.o depends on some have_socket_h.check_result file. The creation rule for this file invokes a test for socket.h and stores the result, which is used by tcp.o building in some way. If no networking would be used, this check would not even be executed. The test result is just an input like a BUILT_SOURCE or so. Maybe this would work in some way. oki, Steffen
Re: [CRAZY PROPOSAL] Automake should support only GNU make
On Fri, 14 Jan 2011, Ralf Wildenhues wrote: (That, by the way, is what nobody ever tells you when they point you to the Recursive Make Considered Harmful paper: that walking the full dependency tree is more expensive than walking a factorized one. Sure, you need to keep the toplevel deps up to date manually then.) Yes. Walking the full dependency tree is more expensive, but it is also likely that if unnecessary work is done, then even more resources are wasted. I have no idea what project has the largest dependency tree but it would surely be one that uses a non-recursive build, or one that puts all the source files in one directory. Regardless, this should not be an argument against an inventory based build system which records and saves the actual rules used to build a target as well as the timestamp/checksum of the source files to those rules (and perhaps, optionally, even the source control version ID for thos files). My argument is that if the target has already been built, then only the rules already used need to be checked in order to decide if the target needs to be rebuilt. In case of added/removed dependencies such as implicit header file include dependencies, only the impacted part of the rules need to be re-checked for validity. It is not necessary to rescan the whole world and decide if one of the zillion other rules known to 'make' might be used to build the target. In addition to the above, Automake should be supplying enough explicit rule information (pertaining to the actual needs of the current project) that the underlying build tool should not have to go off in the weeds and try a million other incantations as well. Anyone who is not familiar with the zillion rules known/tested-by GNU make should run 'make -d' on their own projects. Those that feel that all that counts is the time for a from-scratch build and developer rebuilds are not important might consider that /bin/sh is a more efficient build tool than 'make' for that particular case. :-) Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: [CRAZY PROPOSAL] Automake should support only GNU make
On Friday 14 January 2011, Steffen Dettmer wrote: On Thu, Jan 13, 2011 at 8:39 PM, stefano.lattar...@gmail.com wrote: ``I truly dislike the idea of not keeping configuration and build steps separated.'' Maybe I'd just like a system that *allows* me to keep configuration and build steps clerarly distinct if I want to. Yes, that would be enough for me I guess. Maybe it is just a matter of terms, but I think the concept of configuration (as software configuration) is only about deciding which configure option to set or not to set; the configure run itself IMHO does not need to be separated from the rest of the building. Oh, I see your point now. And I agree that your more granular view might be useful and sensible. BTW, when one starts thinking in these terms, a new terminology is probably needed -- one that separates software configuration (e.g., setting of install directories, enabling/disabling of features, etc.) from requirements checks (e.g., determining if and where an external library or program is available, if the compiler supports a determinate type, and so on). Wouldn't it be great to type make which automatically knows by depedencies that some configuration rules have to be executed (i.e. to determine facts about the environment if they are not available in form of small .h files or alike)? Yes, but then, this could be implemented by having the build system call the configuration system properly, no? More or less like is done by automake-generated rebuild rules, just on steroid I guess. Yes, except that automake-autoconf rules implement a phase or stage idea: when a configure run is needed, it is performed entirely. So it can be seen as separated where the build system can trigger the configure run. If, for example, Makefiles would have rules to check for the libraries as soon as needed etc, wouldn't this be good? Tests that are not needed for the configuration to be built would not even be executed (saving time). What do you mean exactly by this? I'm not sure if this makes any sense, but I could imagine that if some file conditionally (enabled by some configure-as-in-software-configuration option) uses some feature which in turn depends on a platform function that has to be checked, then in this moment this single test could be performed. Let's say I used some --enable-tcp switch. The build system finds that in this case it needs tcp.o. By some depedency tcp.o depends on some have_socket_h.check_result file. The creation rule for this file invokes a test for socket.h and stores the result, which is used by tcp.o building in some way. If no networking would be used, this check would not even be executed. The test result is just an input like a BUILT_SOURCE or so. Maybe this would work in some way. oki, Steffen Thanks for the explanation, this makes sense now. And you have definitely good points. Just a couple of clarifications about what I think: - A user might want to run all the requirements checks before starting to build the package (otherwise, what if the build process punts halfway because a dependency is missing?). So he must be offered this possibility (and it should probably be made the default). - All the results of the requirements checks should be user-overridable. Regards, Stefano
Re: make -j1 fails
* Pippijn van Steenhoven wrote on Fri, Jan 14, 2011 at 09:38:36AM CET: On Thu, Jan 13, 2011 at 07:22:20PM +0100, Ralf Wildenhues wrote: If the failure persists, please post short configure.ac and Makefile.am which expose the problem for you. You can start with what I show below, and adjust that if it doesn't expose it. The code didn't trigger the bug and I couldn't easily reproduce it by modifying it. It involves considerable effort to modify my existing project and upload it to the FreeBSD build machine and I don't have time to do that, now. Understood. This sounds like a FreeBSD make bug, but I'm not sure. Can you make your project available for us to try and reproduce the bug (I have access to a couple of FreeBSD systems)? If not, then I'm afraid I'll not be able to pursue this further before seeing a reduced version. Thanks, Ralf
Re: [CRAZY PROPOSAL] Automake should support only GNU make
* Guido Draheim wrote on Thu, Jan 13, 2011 at 08:55:20PM CET: By the way, I would find it more interesting to see some automake-replacement that allows GNU-make extensions and compiles them down to standard make as far as possible... Generally, I wouldn't, as I don't like the idea of reimplementing GNU make inside Automake. A couple of ideas might be worth stealing though. On the other hand some automake-restrictions are really not needed anymore. (variables with . and / would be nice - along with http://www.gnu.org/software/automake/manual/make/Computed-Names.html it would easily allow a scheme to define generated compile-flags). Well, with a bit of luck, recursive variable expansion will be part of the next Posix standard. Unfortunately, there are limitations in existing make implementations that affect your (good) ideas, and also I don't think / is portable in variable names. See here for more info: http://thread.gmane.org/gmane.comp.sysutils.automake.general/12361 (Reminds me of which, I still need to do some portability testing for that ...) Cheers, Ralf
Re: [CRAZY PROPOSAL] Automake should support only GNU make
Hi Bob, * Bob Friesenhahn wrote on Fri, Jan 14, 2011 at 04:04:35PM CET: In addition to the above, Automake should be supplying enough explicit rule information (pertaining to the actual needs of the current project) that the underlying build tool should not have to go off in the weeds and try a million other incantations as well. I don't think Automake needs to bother with the difference of alpha or beta build systems at all until we get to the point where somebody proposes that Automake also output rules suitable for a suitable beta build system. Or, and that is what I would prefer, somebody implements a beta build system that parses, as much as possible, Posix or GNU makefiles. Because then Automake wouldn't have to change anything. :-) Cheers, Ralf
Re: [CRAZY PROPOSAL] Automake should support only GNU make
Ralf, Where do these terms 'alpha' and 'beta' build system originate from? Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: [CRAZY PROPOSAL] Automake should support only GNU make
* Bob Friesenhahn wrote on Fri, Jan 14, 2011 at 07:55:17PM CET: Where do these terms 'alpha' and 'beta' build system originate from? I've read them in http://gittup.org/tup/build_system_rules_and_algorithms.pdf. No idea whether they are standardized somehow or somewhere. Cheers, Ralf
Re: [CRAZY PROPOSAL] Automake should support only GNU make
On Fri, 2011-01-14 at 19:57 +0100, Ralf Wildenhues wrote: * Bob Friesenhahn wrote on Fri, Jan 14, 2011 at 07:55:17PM CET: Where do these terms 'alpha' and 'beta' build system originate from? I've read them in http://gittup.org/tup/build_system_rules_and_algorithms.pdf. No idea whether they are standardized somehow or somewhere. I really recommend that, in addition to that paper, you might read the thread that ensued on the help-make list after Mike posted a link to it there: http://www.mail-archive.com/help-make@gnu.org/msg08500.html I think some of that discussion was quite illuminating.
hello kkkkkkkkkg
hello: I have good news for you. Last week I have Order china 18 Products Apple MC226LLA 17 MacBook Pro Notebook I completed bank transfer payments,I have received the product! w e b:gouoboo.com It's amazing The item is original, brand new and has high quality, but it's muc cheaper. I'm pleased to share this good news with you! I believe you will find what you want there and have an good experience on shopping from them Regards! ghghkkkuyu.玵
Re: [CRAZY PROPOSAL] Automake should support only GNU make
hmm, is the tupfile syntax really as horrible as it looks? [ from the examples page: : hello.c | gcc -Wall -c hello.c -o hello.o | hello.o ] -miles -- Ich bin ein Virus. Mach' mit und kopiere mich in Deine .signature.
