Re: [RFC] Make build and install dirs used by distcheck configurable. (was: Re: absolute build directory with spaces)
Hello automakers and gnulibers. Is anyone still interested in this feature? If yes, I have some simple updates, second thoughts, and new ideas, for which comments are welcome. If not, let me know before I start investing more time on the implementation! On Monday 06 September 2010, Stefano Lattarini wrote: On Sunday 05 September 2010, Ralf Wildenhues wrote: Hello, * Jim Meyering wrote on Sat, Sep 04, 2010 at 07:28:58PM CEST: Stefano Lattarini wrote: What about instead making the names of the temporaries source/build/install directories used by make distcheck configurable? It turns out that making the srcdir configurable is not very easy or natural; also, I don't see any real use case for that. So I didn't add this feature in the patch series. If anyone would find this feature useful nonetheless, please speak up. This will offer more flexibility, and won't introduce still another automake option which would make backward-compatibility more problematic. I was thinking of something on these lines: $ cat Makefile.am ... AM_DISTCHECK_BUILDDIR_NAME = _ b u i l d ## will be relative to $(distdir) AM_DISTCHECK_SRCDIR_NAME = . ## likewise AM_DISTCHECK_INSTALLDIR_NAME = i...@l1 ## likewise In the end, I went for the slighty shorter names `AM_DISTCHECK_BUILDDIR' and `AM_DISTCHECK_INSTALLDIR'. If you like the proposal, I might try to implement this (but not right away). I do like it. Thanks! Nonetheless, I'm starting to think that making `AM_DISTCHECK_BUILDDIR_NAME' and `AM_DISTCHECK_INSTALLDIR_NAME' defined at configure time might be a better policy. This way we could: - warn about bad values for them at ./configure time rather than at make distcheck time; - allow *any* character in their values (also `#' and single-quotes) - allow leading and trailing whitespaces in their values. - make it easier for developers working on more limited system to stick with less stressful values, thus avoiding potential spurious failures. Opinions? Me too, but the onus for quoting should probably be with the person defining the variables, because there is no well-defined way to do otherwise. (And of course you cannot have comments in variables.) This problems would be solved by having `AM_DISTCHECK_BUILDDIR_NAME' and `AM_DISTCHECK_INSTALLDIR_NAME' properly processed at configure time. In my patch, I let Automake take the onus for quoting, the only additional limit being that AM_DISTCHECK_BUILDDIR and AM_DISTCHECK_INSTALLDIR cannot contain the single-quote character. Not entirely true, in hindsight. They also can not contain the `#' character and leading and trailing whitespaces. We might still change this of course, as the attached patch is mostly tentative. I like it also because some packages will never want to care about being buildable under more stressful circumstances. Also, some developers will never want to care about making distcheck under more stressful circumstances on some more limited systems. The configure-time definition policy would cater to this situation, too. IMPORTANT NOTE: I still haven't run the whole testsuite against this patch. I will if they are no serious objection or proposals of changes/extensions. Regards, Stefano -*-*-*- Make build and install dirs used by distcheck configurable. * automake.in (generate_makefile): Define makefile variables AM_DISTCHECK_BUILDDIR and AM_DISTCHECK_INSTALLDIR when needed; they default respectively to `_build' and `_inst'. * lib/am/distdir.am (distcheck): Sanitize and honour variables $(AM_DISTCHECK_BUILDDIR) and $(AM_DISTCHECK_INSTALLDIR). * tests/distcheck0.test: New test script. * tests/distcheck1a.test: Likewise. * tests/distcheck1b.test: Likewise. * tests/distcheck2a.test: Likewise. * tests/distcheck2b.test: Likewise. * tests/distcheck3.test: Likewise. * tests/distcheck4.test: Likewise. * tests/distcheck5.test: Likewise. * tests/distcheck6.test: Likewise. * tests/distcheck7.test: Likewise. * tests/distcheck8.test: Likewise. * tests/distcheck9.test: Likewise. Clearer and more expressive names for the new testcases are in order, also. * tests/Makefile.am (TESTS): Updated. Regards, Stefano
Re: [PATCH] New tests on obsoleted usages of automake/autoconf macros.
Hi Stefano,
* Stefano Lattarini wrote on Wed, Nov 03, 2010 at 07:12:27PM CET:
http://lists.gnu.org/archive/html/automake-patches/2010-11/msg3.html
[...]
--- /dev/null
+++ b/tests/backcompat6.test
@@ -0,0 +1,105 @@
+# Backward-compatibility test: try to build and distribute a package
+# using obsoleted forms of AC_INIT, AM_INIT_AUTOMAKE and AC_OUTPUT.
+# This script can also serve as mild stress-testing for Automke.
+# See also the similar test `backcompat5.test'.
+cat Makefile.am 'END'
+bin_PROGRAMS = foo
+foo_SOURCES = quux.c
+DISTCLEANFILES = *.tmp
+check-local:
+ rm -f exp got
+ echo 'PACKAGE = nonesuch-zardoz' exp.tmp
+ echo 'VERSION = nonesuch-0.1' exp.tmp
+ echo 'PACKAGE = $(PACKAGE)' got1.tmp
+ echo 'VERSION = $(VERSION)' got1.tmp
+ ./foo got2.tmp
+ cat exp.tmp
+ cat got1.tmp
+ cat got2.tmp
+ diff exp.tmp got1.tmp
+ diff exp.tmp got2.tmp
+END
+
+cat quux.c 'END'
+#include config.h
+#include stdio.h
+int main (void)
+{
+ printf(PACKAGE = %s\nVERSION = %s\n, PACKAGE, VERSION);
+ return 0;
+}
+END
The diff between exp.tmp and got2.tmp fails on MinGW/MSYS because the
foo program uses w32-style CRLF newlines whereas the shell prints LF
only.
The easiest fix would be to grep for the lines in question, I guess.
Thanks,
Ralf
Re: [PATCH] {maint} More tests on macro `AM_WITH_REGEX'.
Hello Stefano, * Stefano Lattarini wrote on Mon, Sep 20, 2010 at 11:08:34PM CEST: This patch increase coverage for a macro I'm planning to touch soon (to make it use AS_HELP_STRING). OK for maint? Does *anybody* use AM_WITH_REGEX? Have you checked? This seems so obsoleted by gnulib that I don't think it is worth investing any more time into. More tests on macro `AM_WITH_REGEX'. * tests/regex.test: Extend with more configure runs. Add trailing `:' command. * tests/regex2.test: New test. * tests/regex3.test: Likewise. * tests/Makefile.am (TESTS): Updated --- a/tests/regex.test +++ b/tests/regex.test @@ -15,6 +15,7 @@ # along with this program. If not, see http://www.gnu.org/licenses/. # Make sure AM_WITH_REGEX compiles and runs. +# See also related tests `regex2.test' and `regex3.test' . ./defs || Exit 1 @@ -28,3 +29,8 @@ $ACLOCAL $AUTOCONF ./configure ./configure --without-regex +./configure --with-regex +./configure --with-regex=no +./configure --with-regex=yes But what do these new lines bring us in terms of coverage, except wasted time? The AC_ARG_WITH macro is tested in Autoconf already. --- /dev/null +++ b/tests/regex2.test +# Make sure AM_WITH_REGEX compiles and runs as advertised in +# documentation. +# See also sister test `regex3.test' Both of these tests seem so low-level, and yet so unlike what any user code would do, that I don't really see how they help the code. IOW, I fail to see how they ensure that the macro is actually useful for some package. Thanks, Ralf
Re: [PATCH] {maint} More tests on macro `AM_WITH_REGEX'.
On Friday 12 November 2010, Ralf Wildenhues wrote: Hello Stefano, * Stefano Lattarini wrote on Mon, Sep 20, 2010 at 11:08:34PM CEST: This patch increase coverage for a macro I'm planning to touch soon (to make it use AS_HELP_STRING). OK for maint? Does *anybody* use AM_WITH_REGEX? Pratically nobody, according to google code search; the only occurrences I found were either from more than a decade ago, or in copied of automake tarball, or dnl'd out. Have you checked? Only today, after having written and sent the patch (how smart, eh?) This seems so obsoleted by gnulib that I don't think it is worth investing any more time into. In fact, I now think we should deprecate it, and then remove it. WDYT? Both of these tests seem so low-level, and yet so unlike what any user code would do, that I don't really see how they help the code. IOW, I fail to see how they ensure that the macro is actually useful for some package. They just tried to ensure basic functionalities of AM_WITH_REGEX; that code was the best I could concoct given my scarce knowledge of the macro usage in the real world. But this is moot now. Let's just drop this patch, which would do more harm than good. Thanks, Stefano
Re: [PATCH] {maint} More tests on macro `AM_WITH_REGEX'.
* Stefano Lattarini wrote on Fri, Nov 12, 2010 at 09:12:53PM CET: On Friday 12 November 2010, Ralf Wildenhues wrote: This seems so obsoleted by gnulib that I don't think it is worth investing any more time into. In fact, I now think we should deprecate it, and then remove it. WDYT? Good idea. Let's deprecate it for 1.12, and remove it a couple of years later. Thanks, Ralf
Re: [PATCH] New tests on obsoleted usages of automake/autoconf macros.
* Stefano Lattarini wrote on Fri, Nov 12, 2010 at 08:57:05PM CET: How about * tests/backcompat6.test (Makefile.am): Grep the output from the test program, rather than diffing it, to avoid spurious failures on MinGW/MSYS due to LF vs. CRLF line endings. Sure, thanks! Ralf
Re: AM_V_GEN - better docs
Patrick Rutkowski rutsk...@gmail.com writes: I don't get from that page how to apply to all my $(CC) build commands, and I really want to quiet down this very messy make output I now have. When silent-rules is enabled, you don't need to do anything special in Makefile.am for normal commands (those commands which get invoked via standard make rules), only those commands you invoke explicitly. For commands which you invoke explicitly, you can just add $(AM_V_GEN) before the command name, e.g., change: foo.barf: foo.blarghhh barfify -o $@ $ to: foo.barf: foo.blarghhh $(AM_V_GEN)barfify -o $@ $ That just prints GEN foo.barf when building foo.barf; to print something more target specific, you can follow the pkg_... example in the doc, e.g.: barf_verbose = $(barf_verbose_$(V)) barf_verbose_ = $(barf_verbose_$(AM_DEFAULT_VERBOSITY)) barf_verbose_0 = @echo BARF $@; foo.barf: foo.blarghhh $(barf_verbose)barfify -o $@ $ The doc page there doesn't even suggest where to look to learn how to apply it to your build. It does, kinda, but maybe it doesn't go far enough; right now it says: To enable less verbose build rules, both the developer and the user of the package have to take a number of steps. The developer needs to do either of the following: + Add the silent-rules option as argument to AM_INIT_AUTOMAKE. + Call the AM_SILENT_RULES macro from within the configure.ac file. .. but even after you do that, silent-rules mode defaults to off; the user may then turn it on by using the --enable-silent-rules option to configure. Maybe it would be good to specify what the should be done to make it default to _on_, e.g.: + To enable silent-rules by default, specify an argument of yes to AM_SILENT_RULES, i.e., add AM_SILENT_RULES([yes]) to the configure.ac file [I know that because somebody else posted it on this list recently :] -miles -- 1971 pickup truck; will trade for guns
Re: execvp: /bin/sh: Argument list too long
On Thu, Nov 11, 2010 at 09:54:35PM +0100, Ralf Wildenhues wrote: In other words, I can't make dist even with GNU make 3.82? What do you suggest, then? Well, you could try my patch from http://article.gmane.org/gmane.comp.gnu.make.bugs/4219 (append /raw to the URL to get it unmangled). I still think letting GNU make avoid the issue on Linux systems would be the easiest way out here. As already written, alternative workarounds include reorganizing your code a bit to have a bit more recursive makefile setup, so that each makefiles' list would remain below the limit. Hi Ralf, I was able to reduce the number of files sufficiently so I am currently not hitting the limit. In the future, when more tests are added, I will go for your second suggestion. The testsuite/ directory won't suffer much from a recursive setup. I just need to move out the .as - .c build rule to a common rules file included in all the testsuite makefiles as well as the main build makefile. Thanks, Pippijn signature.asc Description: Digital signature
Re: [RFC] Make build and install dirs used by distcheck configurable. (was: Re: absolute build directory with spaces)
Hello automakers and gnulibers. Is anyone still interested in this feature? If yes, I have some simple updates, second thoughts, and new ideas, for which comments are welcome. If not, let me know before I start investing more time on the implementation! On Monday 06 September 2010, Stefano Lattarini wrote: On Sunday 05 September 2010, Ralf Wildenhues wrote: Hello, * Jim Meyering wrote on Sat, Sep 04, 2010 at 07:28:58PM CEST: Stefano Lattarini wrote: What about instead making the names of the temporaries source/build/install directories used by make distcheck configurable? It turns out that making the srcdir configurable is not very easy or natural; also, I don't see any real use case for that. So I didn't add this feature in the patch series. If anyone would find this feature useful nonetheless, please speak up. This will offer more flexibility, and won't introduce still another automake option which would make backward-compatibility more problematic. I was thinking of something on these lines: $ cat Makefile.am ... AM_DISTCHECK_BUILDDIR_NAME = _ b u i l d ## will be relative to $(distdir) AM_DISTCHECK_SRCDIR_NAME = . ## likewise AM_DISTCHECK_INSTALLDIR_NAME = i...@l1 ## likewise In the end, I went for the slighty shorter names `AM_DISTCHECK_BUILDDIR' and `AM_DISTCHECK_INSTALLDIR'. If you like the proposal, I might try to implement this (but not right away). I do like it. Thanks! Nonetheless, I'm starting to think that making `AM_DISTCHECK_BUILDDIR_NAME' and `AM_DISTCHECK_INSTALLDIR_NAME' defined at configure time might be a better policy. This way we could: - warn about bad values for them at ./configure time rather than at make distcheck time; - allow *any* character in their values (also `#' and single-quotes) - allow leading and trailing whitespaces in their values. - make it easier for developers working on more limited system to stick with less stressful values, thus avoiding potential spurious failures. Opinions? Me too, but the onus for quoting should probably be with the person defining the variables, because there is no well-defined way to do otherwise. (And of course you cannot have comments in variables.) This problems would be solved by having `AM_DISTCHECK_BUILDDIR_NAME' and `AM_DISTCHECK_INSTALLDIR_NAME' properly processed at configure time. In my patch, I let Automake take the onus for quoting, the only additional limit being that AM_DISTCHECK_BUILDDIR and AM_DISTCHECK_INSTALLDIR cannot contain the single-quote character. Not entirely true, in hindsight. They also can not contain the `#' character and leading and trailing whitespaces. We might still change this of course, as the attached patch is mostly tentative. I like it also because some packages will never want to care about being buildable under more stressful circumstances. Also, some developers will never want to care about making distcheck under more stressful circumstances on some more limited systems. The configure-time definition policy would cater to this situation, too. IMPORTANT NOTE: I still haven't run the whole testsuite against this patch. I will if they are no serious objection or proposals of changes/extensions. Regards, Stefano -*-*-*- Make build and install dirs used by distcheck configurable. * automake.in (generate_makefile): Define makefile variables AM_DISTCHECK_BUILDDIR and AM_DISTCHECK_INSTALLDIR when needed; they default respectively to `_build' and `_inst'. * lib/am/distdir.am (distcheck): Sanitize and honour variables $(AM_DISTCHECK_BUILDDIR) and $(AM_DISTCHECK_INSTALLDIR). * tests/distcheck0.test: New test script. * tests/distcheck1a.test: Likewise. * tests/distcheck1b.test: Likewise. * tests/distcheck2a.test: Likewise. * tests/distcheck2b.test: Likewise. * tests/distcheck3.test: Likewise. * tests/distcheck4.test: Likewise. * tests/distcheck5.test: Likewise. * tests/distcheck6.test: Likewise. * tests/distcheck7.test: Likewise. * tests/distcheck8.test: Likewise. * tests/distcheck9.test: Likewise. Clearer and more expressive names for the new testcases are in order, also. * tests/Makefile.am (TESTS): Updated. Regards, Stefano
Re: AM_V_GEN - better docs
On Friday 12 November 2010, Ralf Wildenhues wrote: Hello Patrick, Miles, * Miles Bader wrote on Fri, Nov 12, 2010 at 09:00:55AM CET: Patrick Rutkowski rutsk...@gmail.com writes: I don't get from that page how to apply to all my $(CC) build commands, and I really want to quiet down this very messy make output I now have. *snip explanations* Thanks. A doc change to improve the situation here would be nice; any volunteers? I might give it a try (not right now); but I'll probably need some guidance, as I'm not well up on the issue. For example, the silencing stuff could be part of a new section somewhere between the Miscellaneous and the Not Enough nodes, and it could treat `make -s', `make /dev/null || make' and other tricks as well as a discussion of silent-rules and maybe even the tradeoffs mentioned in automake/lib/am/depend2.am. (There is no need that a patch does all of this, just one step would be nice already.) Good. The doc page there doesn't even suggest where to look to learn how to apply it to your build. It does, kinda, but maybe it doesn't go far enough; Yes, but I agree that it's also still fairly obscure. Especially the `make V=1' part probably cannot be documented too prominently. [...] Maybe it would be good to specify what the should be done to make it default to _on_, e.g.: + To enable silent-rules by default, specify an argument of yes to AM_SILENT_RULES, i.e., add AM_SILENT_RULES([yes]) to the configure.ac file [I know that because somebody else posted it on this list recently :] We've intentionally not documented that yet, because we weren't sure whether it's a good idea having this functionality. At least some distro maintainers would be more happy to see less bug reports with too little data because of this. It might be time to reconsider this decision. If we document it, we should at least advise against it IMHO. Regards, Stefano
Re: AM_V_GEN - better docs
Patrick Rutkowski rutsk...@gmail.com writes: I don't get from that page how to apply to all my $(CC) build commands, and I really want to quiet down this very messy make output I now have. When silent-rules is enabled, you don't need to do anything special in Makefile.am for normal commands (those commands which get invoked via standard make rules), only those commands you invoke explicitly. For commands which you invoke explicitly, you can just add $(AM_V_GEN) before the command name, e.g., change: foo.barf: foo.blarghhh barfify -o $@ $ to: foo.barf: foo.blarghhh $(AM_V_GEN)barfify -o $@ $ That just prints GEN foo.barf when building foo.barf; to print something more target specific, you can follow the pkg_... example in the doc, e.g.: barf_verbose = $(barf_verbose_$(V)) barf_verbose_ = $(barf_verbose_$(AM_DEFAULT_VERBOSITY)) barf_verbose_0 = @echo BARF $@; foo.barf: foo.blarghhh $(barf_verbose)barfify -o $@ $ The doc page there doesn't even suggest where to look to learn how to apply it to your build. It does, kinda, but maybe it doesn't go far enough; right now it says: To enable less verbose build rules, both the developer and the user of the package have to take a number of steps. The developer needs to do either of the following: + Add the silent-rules option as argument to AM_INIT_AUTOMAKE. + Call the AM_SILENT_RULES macro from within the configure.ac file. .. but even after you do that, silent-rules mode defaults to off; the user may then turn it on by using the --enable-silent-rules option to configure. Maybe it would be good to specify what the should be done to make it default to _on_, e.g.: + To enable silent-rules by default, specify an argument of yes to AM_SILENT_RULES, i.e., add AM_SILENT_RULES([yes]) to the configure.ac file [I know that because somebody else posted it on this list recently :] -miles -- 1971 pickup truck; will trade for guns
Re: AM_V_GEN - better docs
On Sat, Nov 13, 2010 at 5:19 AM, Stefano Lattarini stefano.lattar...@gmail.com wrote: It might be time to reconsider this decision. If we document it, we should at least advise against it IMHO. ... or just give the pros and cons. That seems likely to be more convincing and less annoying... -miles -- Cat is power. Cat is peace.
