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
