Re: debbugs, and a FAQ, for Autotools
On 14/02/11 05:12, Ralf Wildenhues wrote: [ Cross post; Reply-To and Mail-Followup-To set. Please followup to the automake list only, to avoid excessive spammage. Thank you. ] Hello everyone, I've been advertising debbugs before, I think we should be a good example. So, two proposals: 1) Autoconf and Libtool should also use debbugs. bug-automake has switched a few months ago, and I find it helpful to avoid losing reports. Given that we never have enough time on our hands, it becomes more important to not lose track. See http://debbugs.gnu.org/ and linked pages for details. 2) Autotools should have a FAQ document. Not of the sort of the FAQ chapter that answers seven random questions and that has a 1 year+ latency until it is updated, but one that answers both totally-newbie kinds of questions that get asked over and over again, or cross-tool bug questions like the infamous libtool echo problem (which was due to an incompatible m4sugar change). A document that, ideally, eventually obsoletes many of the third-party here's how autotools work, in quick kinds of pages. See e.g., this most recent thread which made the need so clear again: http://thread.gmane.org/gmane.comp.sysutils.automake.patches/5672 For (2) I'd suggest a wiki if we GNU the infrastructure, but something like a new page http://www.gnu.org/software/automake/Autotools-FAQ.html would certainly be good. (And yes, I've been arguing against wikis in the past. I was wrong. Sue me.) Now, I have very little spare time on my hands. Any volunteers on managing such a document? Any people interested in contributing answers or even only questions? I wouldn't mind handing out commit privs to any of the regulars on these lists. I'd ask more about how the internals of ./configure and autoconf works. And questions on how to make bison get handled without being forced to mimic standard yacc. I'm not in the mode of autoconf hacking atm though.
Re: debbugs and (was: slow make clean)
* Glenn Morris wrote on Sun, Feb 13, 2011 at 09:01:24PM CET: Ralf Wildenhues wrote (on Sun, 13 Feb 2011 at 19:01 +0100): I glanced over the debbugs documentation at debbugs.gnu.org now, but couldn't find a place that said something about subscribing to individual bugs. Glen, do you happen to know more about this? I know that it doesn't work, and personally I don't know how to implement it. :( http://debbugs.gnu.org/cgi/bugreport.cgi?bug=5439 Here's a Debian PR with discussion, and a patch and description: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=34071#62 Does that help any (haven't looked closely)? Thanks, Ralf
Re: debbugs and (was: slow make clean)
Ralf Wildenhues wrote (on Mon, 14 Feb 2011 at 22:02 +0100): Here's a Debian PR with discussion, and a patch and description: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=34071#62 Does that help any (haven't looked closely)? No, that is the initial implementation of the feature that we have and that as I describe in bug#5439 doesn't work. From the close message of #34071 * Added per bug subscription support to debbugs, which relies on an external MLM to actually deal with the requests; currently works with eoc and sends messages to bugnum\@$gListDomain. (closes: #34071) eoc = Enemies of Carlotta No use at all for GNU Mailman lists.
Re: [PATCH] {maint} python: extend and improve tests, fix minor glitches
Hi Stefano, * Stefano Lattarini wrote on Mon, Feb 14, 2011 at 11:23:54AM CET: On Sunday 13 February 2011, Ralf Wildenhues wrote: OK. That is, 'CONFIG_SITE=/dev/null; export CONFIG_SITE' of course. Done. Also, since in `python-virtualenv.test' we call `python' directly even after the virtualenv has been deactivated, I added `python' to $required. Cool. Attached is the amended patch that I'll push in 72 hours if there are no further objections. Feel free to go ahead. Thanks! Ralf Subject: [PATCH] python: fix spurious failure in tests * tests/python-vars.test: Ignore cached values from config.site by exporting CONFIG_SITE=/dev/null. Be laxer in matching the expected values of output variables `pythondir' and `pyexecdir', since they can change quite unpredictably among different python installations. Also, avoid hyping debugging output, thus offering smaller trace output and more informative diff. * tests/python-virtualenv.test: Require python, since we call it even after the virtualenv has been deactivated. Ignore cached values from config.site by exporting CONFIG_SITE=/dev/null.
Re: [Ping PATCHES] {master} Optimize tests `instspc-*.test' for speed.
Hi Stefano,
a while ago ...
* Stefano Lattarini wrote on Tue, Jan 25, 2011 at 06:38:50PM CET:
http://lists.gnu.org/archive/html/automake-patches/2010-11/msg00152.html
http://lists.gnu.org/archive/html/automake-patches/2010-12/msg6.html
OK for master?
Both are OK, with nits addressed.
Thanks,
Ralf
Subject: [PATCH 1/2] tests: optimize `instspc-*.test' for speed
After the split of `instspc.test' into various generated tests,
the running time of the testsuite has noticeably increased, since
all these new generated tests must run aclocal, autoconf and
automake, whereas previously they were run only once (at the
beginning of `instspc.test'). But luckily, since the new tests
share the same input files for the autotools, this situation can
be easily worked around (at the expenses of a slight increase of
complexity for the testsuite scaffolding).
* tests/instspc-data.test: New helper test, properly calling
the `instspc-tests.sh' script to generate input data for the
others `instspc-*.test' tests.
* tests/Makefile.am (TESTS): Add `instspc-data.test'.
($(instspc_tests:.test=.log)): Depend on its log file.
(instspc-data.log): Depend on `instspc-tests.sh'.
* tests/instspc-tests.sh: Recognize new action `generate-data',
and use it to create hand-written and autotools-generated static
files shared by all the `instspc-*.test' tests.
When sourced by the `instspc-*.test' tests, use those previously
created files instead of recreating them from scratch.
(deindent, create_input_data): New subroutines.
Some other related changes and refactorings.
--- a/tests/Makefile.am
+++ b/tests/Makefile.am
@@ -85,8 +85,11 @@ $(instspc_tests): Makefile.am
} $@-t
$(AM_V_at)chmod a+rx $@-t mv -f $@-t $@
-# All instspc*.test tests work by sourcing the instspc-tests.sh script.
-$(instspc_tests:.test=.log): instspc-tests.sh
+# All instspc-*.test tests work by sourcing the `instspc-tests.sh'
+# script. Also, they all use shared data generated by the helper
+# test `instspc-data.test', for reasons of speed.
+instspc-data.log: instspc-tests.sh
+$(instspc_tests:.test=.log): instspc-tests.sh instspc-data.log
MAINTAINERCLEANFILES += $(instspc_tests)
EXTRA_DIST += instspc-tests.sh
@@ -504,6 +507,7 @@ instman2.test \
instmany.test \
instmany-mans.test \
instmany-python.test \
+instspc-data.test \
$(instspc_tests) \
interp.test \
interp2.test \
--- /dev/null
+++ b/tests/instspc-data.test
+# Helper testcase which generate input data for the other test
+# `instspc-*.test'. It basically delegates the work to the helper
+# script `instspc-test.sh'.
As an alternative to a helper testcase, this could also just be a helper
script whose run is a prerequisite to the instspc*.log files. That way
you don't have a bogus test result. E.g.:
$(instspc_tests:.test=.log): instspc-tests.sh instspc-data.dir/.dirstamp
instspc-data.dir/.dirstamp:
srcdir=$(srcdir) $(SHELL) $(srcdir)/tests/instspc-setup
or so (with the script renamed to instspc-setup). And mostlyclean-local
removing instspc-data.dir.
You decide whether this is worthwhile.
+# Ensure proper definition of $testsrcdir.
+. ./defs-static || exit 99
+test -n $testsrcdir || exit 99 # sanity check
+
+instspc_action=generate-data
+. $testsrcdir/instspc-tests.sh
--- a/tests/instspc-tests.sh
+++ b/tests/instspc-tests.sh
@@ -94,6 +99,91 @@ define_problematic_string ()
esac
}
+# Helper subroutines for creation of input data files.
+
+deindent ()
unindent? Hmm. Both sound weird, but maybe unindent is easier to
read. Might wanna have it in tests/defs?
+{
+ sed 's/^ *//' # we don't strip leading tabs -- this is deliberate!
+}
+
+create_input_data ()
+{
+ mkdir sub
+
+ deindent configure.in 'EOF'
+AC_INIT([instspc], [1.0])
+AM_INIT_AUTOMAKE
+AC_CONFIG_FILES([Makefile])
+AC_PROG_CC
+AC_PROG_RANLIB
+AC_OUTPUT
+EOF
+
[...]
+ $ACLOCAL
+ $AUTOCONF
+ $AUTOMAKE -a
+
+ : success
This could then be .dirstamp instead.
+}
+
# Be sure to avoid interferences from the environment.
instspc_names_list=''
instspc_xfail_builds_list=''
@@ -189,102 +279,54 @@ if test x$instspc_action = xgenerate-makefile; then
exit 0
fi
-### If we are still here, we have to run a test ...
-
-# We'll need the full setup provided by `tests/defs'. Temporarly disable
+# We'll need the full setup provided by `tests/defs'. Temporarily disable
# the errexit flag, since the setup code might not be prepared to deal
# with it.
set +e
. ./defs || Exit 99
set -e
+# The directory set up by the `generate-data' action should contain all
+# the files we need. So remove the other files created by ./defs. And
+# check we really are in a temporary `*.dir' directory in the build tree,
+# since the last thing we want is to remove some random user files!
+test -f ../defs-static test -f ../defs || Exit 99
+case `pwd` in *.dir);;
Re: bug#7944: Should AM_PATH_PYTHON call AC_ARG_VAR?
On Monday 14 February 2011, Ralf Wildenhues wrote: * Stefano Lattarini wrote on Mon, Feb 14, 2011 at 12:35:17PM CET: On Friday 11 February 2011, Ralf Wildenhues wrote: There are a couple of things that I think could be better. One sentence as a paragraph on its own isn't too pretty. The PYTHON override doesn't seem to be the most important thing to me, so I'd put it last not first. This would be in line with how autoconf.texi documents many macros: cache and override variables are listed late. Also, I'd document that the PYTHON variable is set by the macro. Ahh, that is already done, further down in the text. I think the mention of override could be placed there as well. So, how about this instead? Feel free to squash in and push if you agree. Hmmm... is the diff you posted incomplete, or am I missing something? I'll refrain from pushing the patch until this issue is clarified. I think the diff was complete in the sense that all my intended changes were shown, Oh. I thought it was incomplete in the sense that it didn't address some of the issues you had brought up (``The PYTHON override doesn't seem to be the most important thing to me, so I'd put it last not first'', ``One sentence as a paragraph on its own isn't too pretty'', etc,). I think we are experiencing a communication problem here; i.e., I can't understand whether I'm supposed to address those issues myself, or whether you think that they are secondary, your squash-in diff is enough, and I should push after having just applied it. Could you please clarify? Thanks. but I just really botched up and sent a diff against a file that had further unrelated changes. Also, an unrelated issue: I couldn't find a way to apply the diff you posted automatically (with either 'git' or 'patch'), and I had to apply it manually (yuck!). I assume that I'm clearly missing something here. So, to spare myself similar situations in the future, I'd like to ask: how could I have applied the patch below automatically? Probably not at all. Sorry about that. I'll try to be better next time. (I'm mildly confused by your an unrelated issue; are they two separate issues?) See above. If you are OK with the intended changes of the diff, then IMVHO you can go ahead. At cost of being annoying, I'd rather wait for the clarification I've asked above (but sorry for all this fuss about such a simple patch). Thanks, and sorry for the noise, Stefano
Re: bug#7944: Should AM_PATH_PYTHON call AC_ARG_VAR?
* Stefano Lattarini wrote on Tue, Feb 15, 2011 at 12:37:58AM CET:
On Monday 14 February 2011, Ralf Wildenhues wrote:
* Stefano Lattarini wrote on Mon, Feb 14, 2011 at 12:35:17PM CET:
On Friday 11 February 2011, Ralf Wildenhues wrote:
There are a couple of things that I think could be better. One sentence
as a paragraph on its own isn't too pretty. The PYTHON override doesn't
seem to be the most important thing to me, so I'd put it last not first.
This would be in line with how autoconf.texi documents many macros:
cache and override variables are listed late. Also, I'd document that
the PYTHON variable is set by the macro. Ahh, that is already done,
further down in the text. I think the mention of override could be
placed there as well.
So, how about this instead? Feel free to squash in and push if you
agree.
Hmmm... is the diff you posted incomplete, or am I missing something?
I'll refrain from pushing the patch until this issue is clarified.
I think the diff was complete in the sense that all my intended changes
were shown,
Oh. I thought it was incomplete in the sense that it didn't address some
of the issues you had brought up (``The PYTHON override doesn't seem to
be the most important thing to me, so I'd put it last not first'', ``One
sentence as a paragraph on its own isn't too pretty'', etc,). I think
we are experiencing a communication problem here; i.e., I can't understand
whether I'm supposed to address those issues myself, or whether you think
that they are secondary, your squash-in diff is enough, and I should push
after having just applied it. Could you please clarify? Thanks.
Sorry, I'm probably just making myself not clear. Here's a patch that I
would squash in on top of your patch, and that I think addresses all
issues that I mention in my review. It basically reverses the doc part
of your patch and then applies the diff I posted earlier.
Thanks for your patience,
Ralf
diff --git a/doc/automake.texi b/doc/automake.texi
index fd9d33e..091d7a2 100644
--- a/doc/automake.texi
+++ b/doc/automake.texi
@@ -7632,24 +7632,19 @@ Python
installed (see the definitions of @code{pythondir} and
@code{pkgpythondir} below).
-@defmac AM_PATH_PYTHON (@ovar{version}, @ovar{action-if-found},
@ovar{action-if-not-found})
+@defmac AM_PATH_PYTHON (@ovar{version}, @ovar{action-if-found}, @
+ @ovar{action-if-not-found})
-Search for a Python interpreter on the system. The user can force the
-choice with the configuration variable @env{PYTHON}.
+Search for a Python interpreter on the system. This macro takes three
+optional arguments. The first argument, if present, is the minimum
+version of Python required for this package: @code{AM_PATH_PYTHON}
+will skip any Python interpreter that is older than @var{version}.
+If an interpreter is found and satisfies @var{version}, then
+@var{action-if-found} is run. Otherwise, @var{action-if-not-found} is
+run.
-This macro takes three optional arguments.
-
-The first argument, if present, is the minimum version of Python required
-for this package; @code{AM_PATH_PYTHON} will skip any Python interpreter
-that is older than @var{version}. Note that, if @env{PYTHON} was specified
-by the user, the version check will still take place, but no other Python
-interpreter will be tried if that fails.
-
-If an interpreter is found and satisfies @var{version} (which, in case
-@var{version} is empty or unspecified, means @emph{any} interpreter), then
-@var{action-if-found} is run. Otherwise, @var{action-if-not-found} is run.
-If @var{action-if-not-found} is not specified, as in the following example
-, the default is to abort @command{configure}.
+If @var{action-if-not-found} is not specified, as in the following
+example, the default is to abort @command{configure}.
@example
AM_PATH_PYTHON([2.2])
@@ -7664,6 +7659,9 @@ Python
AM_PATH_PYTHON([2.5],, [:])
@end example
+If the @env{PYTHON} variable is set when @code{AM_PATH_PYTHON} is
+called, then that will be the only Python interpreter that is tried.
+
@code{AM_PATH_PYTHON} creates the following output variables based on
the Python installation found during configuration.
@end defmac
@@ -7679,8 +7677,8 @@ Python
as follows.
@example
- AM_PATH_PYTHON(,, [:])
- AM_CONDITIONAL([HAVE_PYTHON], [test $PYTHON != :])
+AM_PATH_PYTHON(,, [:])
+AM_CONDITIONAL([HAVE_PYTHON], [test $PYTHON != :])
@end example
@item PYTHON_VERSION
