Re: [PATCH] Minor improvements in bootstrap script.
On 06/10/2010 03:13 AM, Stefano Lattarini wrote: Will that always work on mingw, where you are not guaranteed the existence of /bin/sh? Honestly, I dind't think that there were systems missing /bin/sh which could be targets for automake :-( Anyway, the old bootstrap script too assumed existence of /bin/sh, since the temporary script `boot$$.sh' contained the shebang line #! /bin/sh. Right? Not necessarily. If I understand correctly, the MSYS environment knows that if a file is not a PE-COFF executable, but does have a she-bang, that it must be a shell script. So rather than invoking /bin/sh, which doesn't necessarily exist, it invokes sh (relying on a PATH search to find it). For that matter, it could always invoke sh, regardless of the she-bang, because bash knows how to re-invoke an interpreter based on the she-bang (or, it is pretty easy to patch the MSYS port of bash to do that). But the point is that the MSYS environment tries hard to avoid dictating layout of the file system, and does everything relative to PATH, since Windows systems do not have nearly the same notion of a common layout as Unix-like systems. Then again, mingw is one of the platforms where you want the path separator to be detected as ; rather than :. True; thus the script still works correctly, even if just by chance. So I guess I'm okay with your patch as is, but it's up to Ralf at this point. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: [PATCH] Minor improvements in bootstrap script.
Hi Stefano, * Stefano Lattarini wrote on Thu, Jun 10, 2010 at 03:15:39PM CEST: Well, after having read your considerations, I'm no more OK with the patch myself; maybe I'll amend it later, to keep just the spacing and comsetic changes, and adding a comment about the reason we can't assume existence of /bin/sh. But... I note that autoconf-generated configure scripts determine PATH separator in (more or less) the same way my pached bootstrap script does: [...] If we assume autoconf is correct, I think that it would be better to just copy this code snippet in the bootstrap script. Yes. The changes are ok if you split the patch into one purely without semantic changes, and the rest (so that we don't need to revert the former when the latter turns out to be bad); and for setting the PATH separator, please use the code from Autoconf. Bonus points for lower-casing the first words in error messages and prepending (pre-set) `$me: '. ;-) Thanks, Ralf
[PATCH] Testsuite now works with BSD make in parallel mode.
* tests/defs.in: Unset variables __MKLVL__ and MAKE_JOBS_FIFO, which are exported by BSD make when run in parallel mode, and which can confuse make processes spawned by our testsuite. This change fixes a lot of spurious failure when the testsuite is run with BSD make in parallel mode. --- ChangeLog |9 + tests/defs.in |2 +- -*-*-*- Without this patch, the automake testsuite reports at least 20 spurious failures when run in parallel mode with freebsd-make on my debian box. This is due to a couple of leaked environment variables, used internally by BSD make: - MAKE_JOBS_FIFO - __MKLVL__ (not exactly sure about the second one, but removing it just to be sure should be OK IMO). Ralf explored some of the parallel BSD make quirks in these old messages: http://lists.gnu.org/archive/html/automake-patches/2009-05/msg00023.html http://lists.gnu.org/archive/html/automake-patches/2009-05/msg00024.html This source code fragment of FreeBSD make can be instructive: http://fxr.googlebit.com/source/usr.bin/make/main.c?v=8-CURRENT (this code seems to be the same used in debian package freebsd-make). How I run the testsuite using freebsd-make: $ cd ~/tmp/src/automake $ ./configure make all $ cd tests $ MAKE=freebsd-make nice -n19 freebsd-make check -j12 -k The resulting `test-suite.log' files before and after the patch are attached (gzipped), for reference. Regards, Stefano From 89064c43e330e61e163c16de4ccd7fa19c1faa42 Mon Sep 17 00:00:00 2001 From: Stefano Lattarini stefano.lattar...@gmail.com Date: Thu, 10 Jun 2010 19:47:13 +0200 Subject: [PATCH] Testsuite now works with BSD make in parallel mode. * tests/defs.in: Unset variables __MKLVL__ and MAKE_JOBS_FIFO, which are exported by BSD make when run in parallel mode, and which can confuse make processes spawned by our testsuite. This change fixes a lot of spurious failure when the testsuite is run with BSD make in parallel mode. --- ChangeLog |9 + tests/defs.in |2 +- 2 files changed, 10 insertions(+), 1 deletions(-) diff --git a/ChangeLog b/ChangeLog index 8f33b63..888c351 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,12 @@ +2010-06-10 Stefano Lattarini stefano.lattar...@gmail.com + + Testsuite now works with BSD make in parallel mode. + * tests/defs.in: Unset variables __MKLVL__ and MAKE_JOBS_FIFO, + which are exported by BSD make when run in parallel mode, and + which can confuse make processes spawned by our testsuite. + This change fixes a lot of spurious failure when the testsuite + is run with BSD make in parallel mode. + 2010-06-09 Stefano Lattarini stefano.lattar...@gmail.com Modernize, improve and/or fix various test scripts. diff --git a/tests/defs.in b/tests/defs.in index fb056ff..e00aed5 100644 --- a/tests/defs.in +++ b/tests/defs.in @@ -308,7 +308,7 @@ cd ./$testSubDir # recursively invoked sub-make. Any $MAKE invocation in a test is # conceptually an independent invocation, not part of the main # 'automake' build. -unset MFLAGS MAKEFLAGS MAKELEVEL AM_MAKEFLAGS +unset MFLAGS MAKEFLAGS AM_MAKEFLAGS MAKELEVEL __MKLVL__ MAKE_JOBS_FIFO # Unset verbosity flag. unset V # Also unset variables that will let `make -e install' divert -- 1.6.5 after-patch--test-suite.log.gz Description: GNU Zip compressed data before-patch--test-suite.log.gz Description: GNU Zip compressed data
Re: [PATCH] Minor improvements in bootstrap script.
* Stefano Lattarini wrote on Thu, Jun 10, 2010 at 08:48:51PM CEST: At Thursday 10 June 2010, Ralf Wildenhues wrote: Yes. The changes are ok if you split the patch into one purely without semantic changes, and the rest (so that we don't need to revert the former when the latter turns out to be bad); Seems sensible. Agreed. The patches 1/3 and 2/3 are ok now for maint, thanks. Since I was at it, I also wrote a third patch, which adds code (again stolen from autoconf) to ensure that the bootstap script is run in bourne-compatibility mode. Is there any indication this change is needed? It looks ok, and I'm not against it if you plan on adding code later that needs it, but otherwise would prefer to not add this just for the heck of it. Thanks, Ralf
nodist_BUILT_SOURCES?
Hey all,
Potentially odd question...
How would I accomplish something like what's in the subject? I have a
source file that wants to be built before other files - so including it
in BUILT_SOURCES does the right thing, but I do _not_ want to have it
included in the dist tarball.
I tried removing it from BUILT_SOURCES and adding in a rule that looks like:
%.cc: drizzled/configmake.h
But that didn't work.
Any thoughts?
While we're at it - this whole thing is to get expanded values of
autoconf directories into a header file where I can consume them...
which because they contain nested variables
(localstatedir=${prefix}/var}) I seemingly have to do at make time. The
dist problem above could be solved if anybody knows a decent trick to
fully expand those variables at configure time... I've tried many
combinations of eval and quoting - but nothing seems to do what I'm
trying to do.
Thanks!
Monty
Re: nodist_BUILT_SOURCES?
Hello Monty,
first of all, let's ditch the cross-post, this is an Automake question
(and the interested readers read both lists anyway).
* Monty Taylor wrote on Thu, Jun 10, 2010 at 07:42:13PM CEST:
How would I accomplish something like what's in the subject? I have a
source file that wants to be built before other files - so including it
in BUILT_SOURCES does the right thing, but I do _not_ want to have it
included in the dist tarball.
What makes you think BUILT_SOURCES end up being put in the dist tarball?
Just listing something there does not do that, so it must be something
else in your Makefile.am.
Please show it, or better, a small reproducible example, and we'll be
able to quickly spot the issue here.
While we're at it - this whole thing is to get expanded values of
autoconf directories into a header file where I can consume them...
which because they contain nested variables
(localstatedir=${prefix}/var}) I seemingly have to do at make time. The
dist problem above could be solved if anybody knows a decent trick to
fully expand those variables at configure time... I've tried many
combinations of eval and quoting - but nothing seems to do what I'm
trying to do.
OK, well, I'm still clueless as to what you're doing, so I can recommend
info Autoconf Defining Directories
and showing us what you got. Please don't send generated files, and
please only to one list, and please pack large files with gzip.
Thanks,
Ralf
Re: nodist_BUILT_SOURCES?
Hi Monty,
On 6/10/2010 11:42 AM, Monty Taylor wrote:
Hey all,
Potentially odd question...
How would I accomplish something like what's in the subject? I have a
source file that wants to be built before other files - so including it
in BUILT_SOURCES does the right thing, but I do _not_ want to have it
included in the dist tarball.
Files listed in BUILT_SOURCES are not taken into account wrt
distribution. The distribution list is built from other primary-like
constructs, such as *_SOURCES. The example in the autoconf manual shows
how you would do what you want:
...
nodist_foo_SOURCES = bindir.h
BUILT_SOURCES = bindir.h
...
In this example, BUILT_SOURCES is used only to get bindir.h built up
front. The actual SOURCES variable used to list its use by a particular
product carries the nodist prefix, which keeps it from being distributed.
I tried removing it from BUILT_SOURCES and adding in a rule that looks like:
%.cc: drizzled/configmake.h
But that didn't work.
Any thoughts?
While we're at it - this whole thing is to get expanded values of
autoconf directories into a header file where I can consume them...
which because they contain nested variables
(localstatedir=${prefix}/var}) I seemingly have to do at make time. The
dist problem above could be solved if anybody knows a decent trick to
fully expand those variables at configure time... I've tried many
combinations of eval and quoting - but nothing seems to do what I'm
trying to do.
You can't (or rather shouldn't) fully expand these variables at
configure time because they may be modified at make time by the user on
the make command line (e.g., make prefix=xxx). There are two
widely-practiced options:
1. Replace such variables on the compiler command line for all or some
sources:
mylib_la_CPPFLAGS =\
-DSYSCONFDIR=\$(sysconfdir)\\
-DSYSLOGDIR=\$(syslogdir)\ ...
This works well for situations where you only have a few variables to
replace.
2. Add some custom rules to your Makefile.am scripts that build your
source files using variable replacement techniques like those used by
Autoconf:
EXTRA_DIST = myprog.cfg.in
edit = sed \
-e 's|@sysconfd...@]|$(sysconfdir)|g' \
-e 's|@sysrund...@]|$(sysrundir)|g' \
-e 's|@syslogd...@]|$(syslogdir)|g' \
-e 's|@libexecd...@]|$(libexecdir)|g' \
-e 's|@sbind...@]|$(sbindir)|g'\
-e 's|@pref...@]|$(prefix)|g'
all: myprog.cfg
# Build executable scripts
myprog.cfg : Makefile
$(edit) '$(srcdir)/$...@.in' $@
Then just format your input templates just like autoconf input templates
with @variable@ where ever you want variable replacement to occur at
make time.
Regards,
John
Re: nodist_BUILT_SOURCES?
On 06/10/2010 11:10 AM, Ralf Wildenhues wrote: Hello Monty, first of all, let's ditch the cross-post, this is an Automake question (and the interested readers read both lists anyway). * Monty Taylor wrote on Thu, Jun 10, 2010 at 07:42:13PM CEST: How would I accomplish something like what's in the subject? I have a source file that wants to be built before other files - so including it in BUILT_SOURCES does the right thing, but I do _not_ want to have it included in the dist tarball. What makes you think BUILT_SOURCES end up being put in the dist tarball? Just listing something there does not do that, so it must be something else in your Makefile.am. Please show it, or better, a small reproducible example, and we'll be able to quickly spot the issue here. YES! You are right. Some how I missed an entry in an included file that was including the file. Sorry for the false query - I looked through several times and just didn't see the entry. /me FAIL
