Re: The non-recursive-gnulib-prefix-hack module

[Jim Meyering]

On Sat, Oct 22, 2016 at 10:25 AM, Bruno Haible  wrote:
> This is better now. But still better would be to not hardcode 'lib' at all,
> and instead use whatever value was passed to gnulib-tool via --source-base.
> Below is a proposed patch. (The variable $gl_source_base is already used in a
> similar way in the modules 'localcharset' and 'relocatable-prog'.)
> Untested on my side; can you please test it the next time you happen to
> build coreutils?
>
> Bruno
>
>
> 2016-10-22  Bruno Haible  
>
> non-recursive-gnulib-prefix-hack: Don't make assumptions about
> gnulib-tool's --source-base option value.
> * modules/non-recursive-gnulib-prefix-hack (configure.ac): Use
> gl_source_base.
>
> diff --git a/modules/non-recursive-gnulib-prefix-hack 
> b/modules/non-recursive-gnulib-prefix-hack
> index 80bc27f..f938d30 100644
> --- a/modules/non-recursive-gnulib-prefix-hack
> +++ b/modules/non-recursive-gnulib-prefix-hack
> @@ -12,7 +12,7 @@ configure.ac:
>  dnl Run our hack near the end, just before config.status creation.
>  dnl It must happen late, i.e., after gl_LIBOBJS has been finalized.
>  AC_CONFIG_COMMANDS_PRE([
> -  gl_NON_RECURSIVE_GNULIB_PREFIX_HACK([lib])
> +  gl_NON_RECURSIVE_GNULIB_PREFIX_HACK([$gl_source_base])
>])
>
>  Makefile.am:

Nice improvement.
I've confirmed that with that, coreutils still bootstraps and passes
"make distcheck".
Thank you.

an AM_ICONV tweak

[Bruno Haible]

I'm pushing this tweak of the AM_ICONV macro. It should have an effect only
on GNU libiconv itself, when built on a platform that does not have iconv
so far. In this situation, AM_ICONV used to not define ICONV_CONST, which
was OK before but leads to a compilation error now after some internal changes
in GNU libiconv.


2016-10-22  Bruno Haible  

iconv: Avoid compilation error when bootstrapping GNU libiconv.
* m4/iconv.m4 (AM_ICONV): When the system does not have an iconv()
declaration yet, define ICONV_CONST to empty.

diff --git a/m4/iconv.m4 b/m4/iconv.m4
index aa159c5..bdafc54 100644
--- a/m4/iconv.m4
+++ b/m4/iconv.m4
@@ -1,4 +1,4 @@
-# iconv.m4 serial 19 (gettext-0.18.2)
+# iconv.m4 serial 20
 dnl Copyright (C) 2000-2002, 2007-2014, 2016 Free Software Foundation, Inc.
 dnl This file is free software; the Free Software Foundation
 dnl gives unlimited permission to copy and/or distribute it,
@@ -258,14 +258,18 @@ size_t iconv();
 am_cv_proto_iconv=`echo "[$]am_cv_proto_iconv" | tr -s ' ' | sed -e 's/( 
/(/'`
 AC_MSG_RESULT([
  $am_cv_proto_iconv])
-AC_DEFINE_UNQUOTED([ICONV_CONST], [$am_cv_proto_iconv_arg1],
-  [Define as const if the declaration of iconv() needs const.])
-dnl Also substitute ICONV_CONST in the gnulib generated .
-m4_ifdef([gl_ICONV_H_DEFAULTS],
-  [AC_REQUIRE([gl_ICONV_H_DEFAULTS])
-   if test -n "$am_cv_proto_iconv_arg1"; then
- ICONV_CONST="const"
-   fi
-  ])
+  else
+dnl When compiling GNU libiconv on a system that does not have iconv yet,
+dnl pick the POSIX compliant declaration without 'const'.
+am_cv_proto_iconv_arg1=""
   fi
+  AC_DEFINE_UNQUOTED([ICONV_CONST], [$am_cv_proto_iconv_arg1],
+[Define as const if the declaration of iconv() needs const.])
+  dnl Also substitute ICONV_CONST in the gnulib generated .
+  m4_ifdef([gl_ICONV_H_DEFAULTS],
+[AC_REQUIRE([gl_ICONV_H_DEFAULTS])
+ if test -n "$am_cv_proto_iconv_arg1"; then
+   ICONV_CONST="const"
+ fi
+])
 ])

Re: The non-recursive-gnulib-prefix-hack module

[Mike Miller]

On Sat, Oct 22, 2016 at 19:25:46 +0200, Bruno Haible wrote:
> This is better now. But still better would be to not hardcode 'lib' at all,
> and instead use whatever value was passed to gnulib-tool via --source-base.
> Below is a proposed patch. (The variable $gl_source_base is already used in a
> similar way in the modules 'localcharset' and 'relocatable-prog'.)
> Untested on my side; can you please test it the next time you happen to
> build coreutils?

Hi, I had attempted to get non-recursive-gnulib-prefix-hack working with
Octave (where the gnulib subdirectory is not named 'lib'). I sent a
patch and a query for help to bug-gnulib last year and attracted no
interest, I assume because there are very few users.

Original (work-in-progress) patch attached, and see
http://lists.gnu.org/archive/html/bug-gnulib/2015-08/msg0.html,
still valid because Octave has still not managed to incorporate gnulib
cleanly into its non-recursive build.

I'd be grateful for any thoughts or help on making this module work more
generically.

-- 
mike
>From a017e33d890562e2bd456752345625c0bb8cc5f3 Mon Sep 17 00:00:00 2001
From: Mike Miller 
Date: Sat, 1 Aug 2015 12:25:48 -0400
Subject: [PATCH] non-recursive-gnulib-prefix-hack: fix when source-base !=
 "lib"

---
 build-aux/prefix-gnulib-mk | 3 ++-
 gnulib-tool| 4 
 m4/non-recursive-gnulib-prefix-hack.m4 | 2 +-
 3 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/build-aux/prefix-gnulib-mk b/build-aux/prefix-gnulib-mk
index 8af2916..3bb2a59 100755
--- a/build-aux/prefix-gnulib-mk
+++ b/build-aux/prefix-gnulib-mk
@@ -120,7 +120,8 @@ sub prefix_assignment ($$)
 
   # Variables which name depend on the location: libbison_a_SOURCES =>
   # lib_libbison_a_SOURCES.
-  $lhs_and_assign_op =~ s/($lib_name)/lib_$1/g;
+  my $dir = substr ($prefix, 0, -1);
+  $lhs_and_assign_op =~ s/($lib_name)/${dir}_$1/g;
 
   return $lhs_and_assign_op . $rhs;
 }
diff --git a/gnulib-tool b/gnulib-tool
index ec82f35..71e7d9f 100755
--- a/gnulib-tool
+++ b/gnulib-tool
@@ -3918,6 +3918,10 @@ func_emit_autoconf_snippet ()
 cat
   fi
 } \
+  | { if test "$sourcebase" != "lib"; then
+sed -e 's,\[lib\],'"[$sourcebase],g"
+  fi
+} \
   | { if $disable_gettext; then
 sed -e 's/AM_GNU_GETTEXT(\[external\])/dnl you must add AM_GNU_GETTEXT([external]) or similar to configure.ac./'
   else
diff --git a/m4/non-recursive-gnulib-prefix-hack.m4 b/m4/non-recursive-gnulib-prefix-hack.m4
index bf9ae7c..e827a52 100644
--- a/m4/non-recursive-gnulib-prefix-hack.m4
+++ b/m4/non-recursive-gnulib-prefix-hack.m4
@@ -10,7 +10,7 @@ dnl in the directory specified by LIB_DIR.
 AC_DEFUN([gl_NON_RECURSIVE_GNULIB_PREFIX_HACK],
 [
   # Tell AC_LIBSOURCES where to find source files like alloca.c.
-  AC_CONFIG_LIBOBJ_DIR([lib])
+  AC_CONFIG_LIBOBJ_DIR([$1])
 
   # This hack originated in bison.  It is required when using non-recursive
   # automake rules to build from gnulib-provided lib/ sources.  Hence, LIB_DIR
-- 
2.4.6

Re: The non-recursive-gnulib-prefix-hack module

[Bruno Haible]

Hi Mike,

> Hi, I had attempted to get non-recursive-gnulib-prefix-hack working with
> Octave (where the gnulib subdirectory is not named 'lib'). I sent a
> patch and a query for help to bug-gnulib last year and attracted no
> interest, I assume because there are very few users.
> 
> Original (work-in-progress) patch attached, and see
> http://lists.gnu.org/archive/html/bug-gnulib/2015-08/msg0.html,
> still valid because Octave has still not managed to incorporate gnulib
> cleanly into its non-recursive build.

The change to m4/non-recursive-gnulib-prefix-hack.m4 is no longer needed after
the two patches that I've submitted these days.

The change to gnulib-tool is not something I like: Replacing fixed strings
by variable strings a posteriori is a technique that produces good results
quickly but becomes more and more fragile the more it grows.

The change to build-aux/prefix-gnulib-mk is IMO lacking a conversion:
non-alphanumeric characters in $dir should be replaced by underscores. For
example, if $lib_name = "gnulib-lib", you don't want to produce a Makefile.am
variable name 'gnulib-lib_libbison_a_SOURCES' but rather
'gnulib_lib_libbison_a_SOURCES'.

> I'd be grateful for any thoughts or help on making this module work more
> generically.

The idea would be to have gnulib-tool emit the correct code for the
{Bison,coreutils,Octave} case right away, triggered by some command line
option.

If you want to help us here, please use the *current* gnulib-tool to
generate Makefile.am files. Then hand-edit these Makefile.am files with
a minimum of changes, so that they work in a non-recursive build (possibly
based on what prefix-gnulib-mk would produce). Then send us these files
(both the original and the edited Makefile.am) files, so that we can see
how gnulib-tool should be modified.

Bruno

Re: dependencies with incompatible licenses: parse-datetime

[Bruno Haible]

Jim Meyering wrote:
> > 2016-10-15  Bruno Haible  
> >
> > Avoid gnulib-tool warnings about the dependencies of 
> > 'parse-datetime'.
> > * gnulib-tool (func_get_license): Special-case the 'parse-datetime'
> > module.
> 
> Looks fine, and fine by me.
> Thank you.

OK, I've pushed it.

Re: fix some gcc warnings

[Bruno Haible]

Pádraig Brady wrote:
> > 2016-10-16  Bruno Haible  
> > 
> > Fix some "gcc -Wall" warnings.
> > * tests/test-ffsl.c (main): Use variable x, not i.
> > * tests/test-posix_spawn3.c (parent_main): Consider the return value of
> > freopen.
> > * tests/test-sethostname1.c (main): Explicitly ignore the return value
> > of sethostname.
>
> +1
> thanks

OK, I pushed this.

Re: The non-recursive-gnulib-prefix-hack module

[Bruno Haible]

Hi Jim,

> > 2016-10-16  Bruno Haible  
> >
> > gnulib-tool: Make --create-testdir on all modules work again.
> > * gnulib-tool (func_create_testdir): Don't include the
> > non-recursive-gnulib-prefix-hack module.
> That looks fine. Thanks again.

OK, I've pushed it.

> > 4) This module was added in September 2012. Does this mean that no one has 
> > used
> >gnulib-tool --create-testdir option to produce a testdir for all modules,
> >in four years?!
>
> Probably true.

At least Tom Christensen is running gnulib-tool --create-testdir daily
(see http://lists.gnu.org/archive/html/bug-gnulib/2016-10/msg00085.html),
and he apparently started to exclude the module 
'non-recursive-gnulib-prefix-hack'
when it started to introduce this problem.

> > 1) Both modules/non-recursive-gnulib-prefix-hack and
> >m4/non-recursive-gnulib-prefix-hack.m4 hardcode the subdirectory name 
> > 'lib'.
> >(Why does m4/non-recursive-gnulib-prefix-hack.m4 use 'lib' in one place 
> > and $1
> >in another place??)
> 
> That's a bug, but inconsequential. Thank you. I've just pushed a fix for it.

This is better now. But still better would be to not hardcode 'lib' at all,
and instead use whatever value was passed to gnulib-tool via --source-base.
Below is a proposed patch. (The variable $gl_source_base is already used in a
similar way in the modules 'localcharset' and 'relocatable-prog'.)
Untested on my side; can you please test it the next time you happen to
build coreutils?

Bruno


2016-10-22  Bruno Haible  

non-recursive-gnulib-prefix-hack: Don't make assumptions about
gnulib-tool's --source-base option value.
* modules/non-recursive-gnulib-prefix-hack (configure.ac): Use
gl_source_base.

diff --git a/modules/non-recursive-gnulib-prefix-hack 
b/modules/non-recursive-gnulib-prefix-hack
index 80bc27f..f938d30 100644
--- a/modules/non-recursive-gnulib-prefix-hack
+++ b/modules/non-recursive-gnulib-prefix-hack
@@ -12,7 +12,7 @@ configure.ac:
 dnl Run our hack near the end, just before config.status creation.
 dnl It must happen late, i.e., after gl_LIBOBJS has been finalized.
 AC_CONFIG_COMMANDS_PRE([
-  gl_NON_RECURSIVE_GNULIB_PREFIX_HACK([lib])
+  gl_NON_RECURSIVE_GNULIB_PREFIX_HACK([$gl_source_base])
   ])
 
 Makefile.am:

Re: Automatically-generated regexp documentation

[Bernhard Voelker]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 10/21/2016 10:17 PM, Eric Blake wrote:
> I count 97 such broken tags; and I verified I can push replacement tags (tag 
> 68c0e85 was for FINDUTILS_4_3_5-1; if
> you do a fresh clone, tag 68c0e85 is now gone, and replaced by an 
> identically-named annotated tag 6ee72b929 with my
> email as tagger).  I'm planning to script the conversion of all the tags, but 
> am trying to figure out if it is
> worth back-dating the tags, and whether an unsigned annotated tag or a 
> simpler lightweight tag is the better thing
> to push in place of each tag that gets corrected.

So why is this "broken"?  I can see 'git fsck' still running well with
version 2.1.4 while a later version complains about it.  Isn't this a
(maybe known?) regression or break in backward-compatibility in git itself?

Have a nice day,
Berny
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBAgAGBQJYCzCOAAoJEEZQLveWkXGV9WsH/0961mhqEP5I3W3jUF85gAQu
3mqfTkqbQ6pTc00a0Br+ZuX3gPuAqhBhMA1a3brgR9BueoskXz5+2VaSSZTHLYze
JPz3uc8SEmUlLPL0FSwzdk1DI4kTLkB0MqExWhhAiPNrGUBtc4+w2bnS2bed9N+8
YFhhWTW4YGM/7xQbvLWPMD64Q3faRlLp4/E8THSCed8gzFnmRclSYVavvlHZ0C/Y
4WzBH7TSIUEksUxA6USSEbElYYP9CBmoEQ5siPg4dZW7ws9gYr0K9UXWMe9DDTxi
iHCDF2dVy+4oQ+eQzg3HqgonVGJ5iVDxL3auujixJ/Vi+/OvF73ZCsG5alDJxDA=
=NVBy
-END PGP SIGNATURE-