6:37 p.m.
Picks up fixes for gethostname compilation problems on mingw.
* .gnulib: Update to latest.
* build-aux/.gitignore: Regenerate.
* cfg.mk (local-checks-to-skip): Avoid new test not relevent to
libvirt.
---
This replaces
https://www.redhat.com/archives/libvir-list/2010-March/msg00915.html,
and should fix the issues Matthias was seeing with compiling gnulib
on mingw.
.gnulib | 2 +-
build-aux/.gitignore | 1 +
cfg.mk | 1 +
3 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/.gnulib b/.gnulib
index 10d66ae..4f01268 160000
--- a/.gnulib
+++ b/.gnulib
@@ -1 +1 @@
-Subproject commit 10d66aedfdd610f731c8c54152b9dfca3efbee12
+Subproject commit 4f01268d0c584c20704e42527f4fa125e7525aae
diff --git a/build-aux/.gitignore b/build-aux/.gitignore
index 29b1e03..8717628 100644
--- a/build-aux/.gitignore
+++ b/build-aux/.gitignore
@@ -6,6 +6,7 @@
/useless-if-before-free
/vc-list-files
arg-nonnull.h
+c++defs.h
config.rpath
gitlog-to-changelog
mkinstalldirs
diff --git a/cfg.mk b/cfg.mk
index 27cfca4..0c41ae5 100644
--- a/cfg.mk
+++ b/cfg.mk
@@ -51,6 +51,7 @@ local-checks-to-skip = \
sc_space_tab \
sc_sun_os_names \
sc_system_h_headers \
+ sc_texinfo_acronym \
sc_tight_scope \
sc_two_space_separator_in_usage \
sc_error_message_uppercase \
--
1.6.6.1
6:37 p.m.
New subject: [libvirt] [PATCH 2/2] build: don't lose prior configure args on autogen.sh
My prior patch forced an autogen.sh run, and I was surprised that the
suggested './autogen.sh' lost the fact that I had previously used
'./autogen.sh -C' for speed.
* autogen.sh: Use config.status, if present and there were no arguments.
Signed-off-by: Eric Blake <eblake(a)redhat.com>
---
I noticed this on the previous patch, because I blindly followed
make's instructions to rerun ./autogen.sh, only to later realize
that I just nuked my nice ./configure --enable-compiler-warnings=error
settings.
Hmm, as long as make is smart enough to warn, and now that running
./autogen.sh with no arguments is reliable at maintaining an
existing setup, I could even submit a followup patch to have make
blindly run ./autogen.sh instead of dying with the error that the
user has to run it. Any interest in such a followup?
autogen.sh | 10 +++++++---
1 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/autogen.sh b/autogen.sh
index b93cdba..a618d86 100755
--- a/autogen.sh
+++ b/autogen.sh
@@ -56,8 +56,8 @@ if test "x$1" = "x--system"; then
EXTRA_ARGS="--prefix=/usr --sysconfdir=/etc --localstatedir=/var"
echo "Running ./configure with $EXTRA_ARGS $@"
else
- if test -z "$*"; then
- echo "I am going to run ./configure with no arguments - if you wish "
+ if test -z "$*" && test ! -f "$THEDIR/config.status";
then
+ echo "I am going to run ./configure with no arguments - if you wish "
echo "to pass any to it, please specify them on the $0 command line."
fi
fi
@@ -92,7 +92,11 @@ if test "x$OBJ_DIR" != x; then
cd "$OBJ_DIR"
fi
-$srcdir/configure $EXTRA_ARGS "$@" && {
+if test -z "$*" && test -f config.status; then
+ ./config.status --recheck
+else
+ $srcdir/configure $EXTRA_ARGS "$@"
+fi && {
echo
echo "Now type 'make' to compile libvirt."
}
--
1.6.6.1
1:16 p.m.
New subject: [libvirt] [PATCH 2/2] build: don't lose prior configure args on autogen.sh
Eric Blake wrote:
My prior patch forced an autogen.sh run, and I was surprised that
the
suggested './autogen.sh' lost the fact that I had previously used
'./autogen.sh -C' for speed.
* autogen.sh: Use config.status, if present and there were no arguments.
Thanks.
This looks fine, too.
I confirmed that it works as advertised,
and am about to push this and the preceding 1/2.
A small word of warning to our readers:
For those new to configure's -C (--cache) option,
be aware that its use comes with a responsibility (or price).
You have to be careful to remove the cache periodically,
in case something about your system or the configure-time
tests makes it so a cached result is invalid.
If you forget, and reuse an invalid cache, you can easily
end up with subtle and hard-to-diagnose bugs.
I noticed this on the previous patch, because I blindly followed
make's instructions to rerun ./autogen.sh, only to later realize
that I just nuked my nice ./configure --enable-compiler-warnings=error
settings.
Hmm, as long as make is smart enough to warn, and now that running
./autogen.sh with no arguments is reliable at maintaining an
existing setup, I could even submit a followup patch to have make
blindly run ./autogen.sh instead of dying with the error that the
user has to run it. Any interest in such a followup?
I have a slight preference for automating it.
The current failure+instructions do serve to tell the user that something
unusual (and time-consuming) is about to happen, but it's easy
to print a warning to that effect while automating the job.
6:23 p.m.
New subject: [libvirt] [PATCH 3/2] build: automate the rerun of autogen.sh
Automate the reuse of autogen.sh, rather than just erroring out.
* cfg.mk (_update_required): Run autogen.sh, rather than just
warning about it.
(_autogen): New target.
---
> Hmm, as long as make is smart enough to warn, and now that
running
> ./autogen.sh with no arguments is reliable at maintaining an
> existing setup, I could even submit a followup patch to have make
> blindly run ./autogen.sh instead of dying with the error that the
> user has to run it. Any interest in such a followup?
I have a slight preference for automating it.
The current failure+instructions do serve to tell the user that something
unusual (and time-consuming) is about to happen, but it's easy
to print a warning to that effect while automating the job.
This automates it. It took me a while to figure out how to cause the
automation without losing output - the idea in GNUmakefile of using a
$(shell) to do a recursive make is not too good, because stdout is
consumed and the user can't see any progress. But the trick of adding
a dependency on Makefile works nicely, so maybe I should rewrite
GNUmakefile upstream in gnulib to use the same trick.
To test the patch, I temporarily added a newline to bootstrap.conf,
then ran 'make' twice; autogen.sh reran only on the first run of the
two. (Of course, reverting the temporary newline caused autogen.sh to
rerun again - you can save yourselves that hassle by saving off
.git-module-status before you test, and restoring it back when you
revert bootstrap.conf back to normal).
cfg.mk | 7 ++++++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/cfg.mk b/cfg.mk
index f01dbbf..9b8ee00 100644
--- a/cfg.mk
+++ b/cfg.mk
@@ -308,9 +308,14 @@ ifeq (0,$(MAKELEVEL))
stamp="$$($(_submodule_hash) $(_curr_status) 2>/dev/null)"; \
test "$$stamp" = "$$actual"; echo $$?)
ifeq (1,$(_update_required))
- $(error gnulib update required; run ./autogen.sh first)
+ $(info INFO: gnulib update required; running ./autogen.sh first)
+Makefile: _autogen
endif
endif
+.PHONY: _autogen
+_autogen:
+ $(srcdir)/autogen.sh
+
# Exempt @...@ uses of these symbols.
_makefile_at_at_check_exceptions = ' && !/(SCHEMA|SYSCONF)DIR/'
--
1.6.6.1
12:25 p.m.
New subject: [libvirt] [PATCH 3/2] build: automate the rerun of autogen.sh
Eric Blake wrote:
Automate the reuse of autogen.sh, rather than just erroring out.
* cfg.mk (_update_required): Run autogen.sh, rather than just
warning about it.
(_autogen): New target.
---
> > Hmm, as long as make is smart enough to warn, and now that running
> > ./autogen.sh with no arguments is reliable at maintaining an
> > existing setup, I could even submit a followup patch to have make
> > blindly run ./autogen.sh instead of dying with the error that the
> > user has to run it. Any interest in such a followup?
>
> I have a slight preference for automating it.
>
> The current failure+instructions do serve to tell the user that something
> unusual (and time-consuming) is about to happen, but it's easy
> to print a warning to that effect while automating the job.
This automates it. It took me a while to figure out how to cause the
automation without losing output - the idea in GNUmakefile of using a
$(shell) to do a recursive make is not too good, because stdout is
consumed and the user can't see any progress. But the trick of adding
a dependency on Makefile works nicely, so maybe I should rewrite
GNUmakefile upstream in gnulib to use the same trick.
Yes ;-)
To test the patch, I temporarily added a newline to bootstrap.conf,
then ran 'make' twice; autogen.sh reran only on the first run of the
two. (Of course, reverting the temporary newline caused autogen.sh to
rerun again - you can save yourselves that hassle by saving off
.git-module-status before you test, and restoring it back when you
revert bootstrap.conf back to normal).
...
- $(error gnulib update required; run ./autogen.sh first)
+ $(info INFO: gnulib update required; running ./autogen.sh first)
+Makefile: _autogen
endif
endif
+.PHONY: _autogen
+_autogen:
+ $(srcdir)/autogen.sh
+
# Exempt @...@ uses of these symbols.
_makefile_at_at_check_exceptions = ' && !/(SCHEMA|SYSCONF)DIR/'
Thanks! I like it.
I've confirmed that this works as advertised.
12:32 p.m.
New subject: [libvirt] [PATCH 3/2] build: automate the rerun of autogen.sh
On 03/30/2010 11:25 AM, Jim Meyering wrote:
Eric Blake wrote:
> Automate the reuse of autogen.sh, rather than just erroring out.
>
...
> - $(error gnulib update required; run ./autogen.sh first)
> + $(info INFO: gnulib update required; running ./autogen.sh first)
> +Makefile: _autogen
> endif
> endif
>
> +.PHONY: _autogen
> +_autogen:
> + $(srcdir)/autogen.sh
> +
> # Exempt @...@ uses of these symbols.
> _makefile_at_at_check_exceptions = ' && !/(SCHEMA|SYSCONF)DIR/'
Thanks! I like it.
I've confirmed that this works as advertised.
Thanks. Pushed, as well as the -fdiagnostics-show-option patch.
--
Eric Blake eblake(a)redhat.com +1-801-349-2682
Libvirt virtualization library http://libvirt.org
1:04 p.m.
Eric Blake wrote:
Picks up fixes for gethostname compilation problems on mingw.
* .gnulib: Update to latest.
* build-aux/.gitignore: Regenerate.
* cfg.mk (local-checks-to-skip): Avoid new test not relevent to
libvirt.
This looks fine and passes tests on F12 and rawhide.
I'm about to push it.
5385
days inactive
5390
days old
6 comments
2 participants
participants (2)
-
Eric Blake -
Jim Meyering