Eric Blake <ebb9 <at> byu.net> writes:
>
> Next, I tried different --source-base dirs. With separate imports, this
> almost works (although I found that some modules, like unlocked-io and
> config-h, must be --imported into both libraries). The problem comes when
> doing "gnulib-tool --update" in the bootstrap script - gnulib-tool correctly
> determined that there were two gnulib-cache files and two libraries to
> update, but when updating the second library, func_import used stale
> --source-base and --macro-prefix values remembered from the first library
> rather than the correct values from the second cache. I suppose I could
> rewrite m4's bootstrap to do "gnulib-tool --m4-base=base1 --import;
> gnulib-tool --m4-base=base2 --import" instead of "gnulib-tool --update", but
> it seems like something that gnulib-tool should be able to support,
> especially since it already detects both caches.
>
OK to apply this patch, which lets "gnulib-tool --update" properly update two
gnulib libraries within the same directory hierarchy?
2006-08-30 Eric Blake <[EMAIL PROTECTED]>
* gnulib-tool (--update): When updating multiple m4bases, reset
variable state in between bases.
Index: gnulib-tool
===================================================================
RCS file: /sources/gnulib/gnulib/gnulib-tool,v
retrieving revision 1.150
diff -u -b -r1.150 gnulib-tool
--- gnulib-tool 28 Aug 2006 19:39:49 -0000 1.150
+++ gnulib-tool 30 Aug 2006 17:33:43 -0000
@@ -2416,6 +2416,20 @@
if test $# = 0; then
# No further arguments. Guess the user wants to update all of them.
for m4base in $m4dirs; do
+ if test $mode = update ; then
+ local_gnulib_dir=
+ libname=libgnu
+ supplied_libname=
+ sourcebase=
+ docbase=
+ testsbase=
+ inctests=
+ avoidlist=
+ lgpl=
+ makefile_name=
+ libtool=
+ macro_prefix=
+ fi
func_import
done
else
