Re: [PATCH] maint: add a script to list libunistring modules

[Daiki Ueno]

Daiki Ueno  writes:

>> The modules are listed by a script that does:
>> - for each file listed by: git show --oneline --name-only 705f4efc
>>   - deduce the containing modules, based on "Files:"
>> - deduce the modules which depend on the containing modules, based
>>   on "Depends-on:"
>>
>> It's tempting to automate those steps.  Is it okay to add some scripts
>> for that to Gnulib?
>
> So here it is.  As noted in the comment, it's often too slow.

Actually, it would be trivial if gnulib-tool had support for:

- listing reverse dependencies: --extract-reverse-dependencies module
- listing containing module, like rpm -qf: --extract-containing-modules file
- recursive query for --extract-dependencies, etc: --recursive

Perhaps these features might be generally useful, but I doubt that they
are acceptable since gnulib-tool seems already too complex to
accommodate such new options (might be a good addition to
python-gnulib).

Thoughts?

Regards,
-- 
Daiki Ueno

Re: Compilation warnings on MinGW due to Gnulib's wcwidth

[Karl Berry]

Hello gnulib folks,

It looks as if we have out-of-date files in the [texinfo] repository.

Evidently, but I am puzzled as to how it came about.  We (I) have always
intended to use gnulib in the recommended way, namely (for the last few
years), gnulib-tool --add-import.  So why would a stale file like
wcwidth.h stick around?  Surely if a file is deleted from a gnulib
module foo, gnulib-tool -add-import removes it?

Anyway, more importantly, how do we check for other inconsistencies that
may be lurking?

Thanks,
Karl

Re: Compilation warnings on MinGW due to Gnulib's wcwidth

[Gavin Smith]

On 19 June 2015 at 13:36, Eli Zaretskii  wrote:
>> Date: Fri, 19 Jun 2015 13:12:00 +0100
>> From: Gavin Smith 
>> Cc: bug-gnulib@gnu.org, texinfo-de...@gnu.org
>>
>> On 19 June 2015 at 07:48, Eli Zaretskii  wrote:
>> > There was no wcwidth.h in texinfo-5.9.93's gnulib; now there is.  So
>> > the arrangement of how that declaration is pulled in changed
>> > significantly since then.
>>
>> I downloaded the texinfo-5.9.94 pretest
>> (http://alpha.gnu.org/gnu/texinfo/), and it doesn't have wcwidth.h
>> either: the file is in the repository, but isn't being distributed.
>
> Then I guess it isn't related to the problem at hand.  Sorry for
> confusing everybody.
>
> However, the original issue still needs to be resolved.

It's very hard for me to guess what might be going on on your system.
I suggest adding warning directives to wchar.h, like the following:

Index: gnulib/lib/wchar.in.h
===
--- gnulib/lib/wchar.in.h   (revision 6344)
+++ gnulib/lib/wchar.in.h   (working copy)
@@ -43,10 +43,12 @@
  the latter includes .  But here, we have no way to detect whether
   is completely included or is still being included.  */

+#warning ""
 #@INCLUDE_NEXT@ @NEXT_WCHAR_H@

 #else
 /* Normal invocation convention.  */
+#warning "BBB"

 #ifndef _@GUARD_PREFIX@_WCHAR_H

which would confirm which parts of the file were being included, and
the files that were being included at the time, e.g.:

gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I../.. -Wall -g -O0 -MT
printf-args.o -MD -MP -MF $depbase.Tpo -c -o printf-args.o
printf-args.c &&\
mv -f $depbase.Tpo $depbase.Po
In file included from printf-args.h:41:0,
 from printf-args.c:29:
./wchar.h:52:2: warning: #warning "BBB" [-Wcpp]
 #warning "BBB"
  ^

Re: Compilation warnings on MinGW due to Gnulib's wcwidth

[Gavin Smith]

On 19 June 2015 at 13:36, Eli Zaretskii  wrote:
>> Date: Fri, 19 Jun 2015 13:12:00 +0100
>> From: Gavin Smith 
>> Cc: bug-gnulib@gnu.org, texinfo-de...@gnu.org
>>
>> On 19 June 2015 at 07:48, Eli Zaretskii  wrote:
>> > There was no wcwidth.h in texinfo-5.9.93's gnulib; now there is.  So
>> > the arrangement of how that declaration is pulled in changed
>> > significantly since then.
>>
>> I downloaded the texinfo-5.9.94 pretest
>> (http://alpha.gnu.org/gnu/texinfo/), and it doesn't have wcwidth.h
>> either: the file is in the repository, but isn't being distributed.
>
> Then I guess it isn't related to the problem at hand.  Sorry for
> confusing everybody.
>
> However, the original issue still needs to be resolved.

I wonder if you could try compiling again now the file is gone from
the repository.

[PATCH] linked-list, linkedhash-list: avoid compiler warnings

[Pádraig Brady]

* lib/gl_anytree_list2.h: Add _GL_ATTRIBUTE_PURE to avoid
-Werror=suggest-attribute=pure (from GCC 5.1.1).
---
 ChangeLog|  6 ++
 lib/gl_anylinked_list2.h | 22 +++---
 2 files changed, 17 insertions(+), 11 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 66df3da..a9524fd 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,9 @@
+2015-06-19  P??draig Brady  
+
+   linked-list, linkedhash-list: avoid compiler warnings
+   * lib/gl_anytree_list2.h: Add _GL_ATTRIBUTE_PURE to avoid
+   -Werror=suggest-attribute=pure (from GCC 5.1.1).
+
 2015-06-19  Daiki Ueno  
 
libunistring: bump minimum version to 0.9.6
diff --git a/lib/gl_anylinked_list2.h b/lib/gl_anylinked_list2.h
index 12f732e..5ba2806 100644
--- a/lib/gl_anylinked_list2.h
+++ b/lib/gl_anylinked_list2.h
@@ -163,13 +163,13 @@ gl_linked_nx_create (gl_list_implementation_t 
implementation,
   return NULL;
 }
 
-static size_t
+static size_t _GL_ATTRIBUTE_PURE
 gl_linked_size (gl_list_t list)
 {
   return list->count;
 }
 
-static const void *
+static const void * _GL_ATTRIBUTE_PURE
 gl_linked_node_value (gl_list_t list, gl_list_node_t node)
 {
   return node->value;
@@ -215,19 +215,19 @@ gl_linked_node_nx_set_value (gl_list_t list, 
gl_list_node_t node,
   return 0;
 }
 
-static gl_list_node_t
+static gl_list_node_t _GL_ATTRIBUTE_PURE
 gl_linked_next_node (gl_list_t list, gl_list_node_t node)
 {
   return (node->next != &list->root ? node->next : NULL);
 }
 
-static gl_list_node_t
+static gl_list_node_t _GL_ATTRIBUTE_PURE
 gl_linked_previous_node (gl_list_t list, gl_list_node_t node)
 {
   return (node->prev != &list->root ? node->prev : NULL);
 }
 
-static const void *
+static const void * _GL_ATTRIBUTE_PURE
 gl_linked_get_at (gl_list_t list, size_t position)
 {
   size_t count = list->count;
@@ -312,7 +312,7 @@ gl_linked_nx_set_at (gl_list_t list, size_t position, const 
void *elt)
   return node;
 }
 
-static gl_list_node_t
+static gl_list_node_t _GL_ATTRIBUTE_PURE
 gl_linked_search_from_to (gl_list_t list, size_t start_index, size_t end_index,
   const void *elt)
 {
@@ -465,7 +465,7 @@ gl_linked_search_from_to (gl_list_t list, size_t 
start_index, size_t end_index,
   }
 }
 
-static size_t
+static size_t _GL_ATTRIBUTE_PURE
 gl_linked_indexof_from_to (gl_list_t list, size_t start_index, size_t 
end_index,
const void *elt)
 {
@@ -1027,7 +1027,7 @@ gl_linked_iterator_free (gl_list_iterator_t *iterator)
 
 /* -- Sorted gl_list_t Data Type -- */
 
-static gl_list_node_t
+static gl_list_node_t _GL_ATTRIBUTE_PURE
 gl_linked_sortedlist_search (gl_list_t list, gl_listelement_compar_fn compar,
  const void *elt)
 {
@@ -1045,7 +1045,7 @@ gl_linked_sortedlist_search (gl_list_t list, 
gl_listelement_compar_fn compar,
   return NULL;
 }
 
-static gl_list_node_t
+static gl_list_node_t _GL_ATTRIBUTE_PURE
 gl_linked_sortedlist_search_from_to (gl_list_t list,
  gl_listelement_compar_fn compar,
  size_t low, size_t high,
@@ -1093,7 +1093,7 @@ gl_linked_sortedlist_search_from_to (gl_list_t list,
   return NULL;
 }
 
-static size_t
+static size_t _GL_ATTRIBUTE_PURE
 gl_linked_sortedlist_indexof (gl_list_t list, gl_listelement_compar_fn compar,
   const void *elt)
 {
@@ -1114,7 +1114,7 @@ gl_linked_sortedlist_indexof (gl_list_t list, 
gl_listelement_compar_fn compar,
   return (size_t)(-1);
 }
 
-static size_t
+static size_t _GL_ATTRIBUTE_PURE
 gl_linked_sortedlist_indexof_from_to (gl_list_t list,
   gl_listelement_compar_fn compar,
   size_t low, size_t high,
-- 
2.4.1

Re: Compilation warnings on MinGW due to Gnulib's wcwidth

[Eli Zaretskii]

> Date: Fri, 19 Jun 2015 13:12:00 +0100
> From: Gavin Smith 
> Cc: bug-gnulib@gnu.org, texinfo-de...@gnu.org
> 
> On 19 June 2015 at 07:48, Eli Zaretskii  wrote:
> > There was no wcwidth.h in texinfo-5.9.93's gnulib; now there is.  So
> > the arrangement of how that declaration is pulled in changed
> > significantly since then.
> 
> I downloaded the texinfo-5.9.94 pretest
> (http://alpha.gnu.org/gnu/texinfo/), and it doesn't have wcwidth.h
> either: the file is in the repository, but isn't being distributed.

Then I guess it isn't related to the problem at hand.  Sorry for
confusing everybody.

However, the original issue still needs to be resolved.

Re: Compilation warnings on MinGW due to Gnulib's wcwidth

[Gavin Smith]

On 19 June 2015 at 13:12, Gavin Smith  wrote:
> On 19 June 2015 at 07:48, Eli Zaretskii  wrote:
>> There was no wcwidth.h in texinfo-5.9.93's gnulib; now there is.  So
>> the arrangement of how that declaration is pulled in changed
>> significantly since then.
>
> I downloaded the texinfo-5.9.94 pretest
> (http://alpha.gnu.org/gnu/texinfo/), and it doesn't have wcwidth.h
> either: the file is in the repository, but isn't being distributed.

According to gnulib's ChangeLog, wcwidth.h was removed in July 2007.
It looks as if we have out-of-date files in the repository.

2007-07-07  Bruno Haible  

* lib/wchar_.h: Include the GL_LINK_WARNING macro.
(wcwidth): New declaration.
* m4/wchar.m4 (gl_WCHAR_MODULE_INDICATOR, gl_WCHAR_H_DEFAULTS): New
macros.
(gl_WCHAR_H): Require gl_WCHAR_H_DEFAULTS. Don't set WCHAR_H to empty
here. Prepare for creating  unconditionally.
* modules/wchar (Depends-on): Add link-warning.
(Makefile.am): Substitute also GNULIB_WCWIDTH, HAVE_DECL_WCWIDTH,
REPLACE_WCWIDTH, and GL_LINK_WARNING.
* lib/wcwidth.h: Remove file.
* m4/wcwidth.m4 (gl_FUNC_WCWIDTH): Require gl_WCHAR_H_DEFAULTS. Set
HAVE_DECL_WCWIDTH, REPLACE_WCWIDTH, WCHAR_H.
* modules/wcwidth (Files): Remove lib/wcwidth.h.
(configure.ac): Invoke gl_WCHAR_MODULE_INDICATOR.
(Include): Replace wcwidth.h with .
* lib/wcwidth.c: Include  instead of wcwidth.h.
* lib/mbchar.h: Don't include wcwidth.h.
* lib/mbswidth.c: Likewise.
* NEWS: Mention the change.

2007-07-07  Bruno Haible  

* lib/wcwidth.c: New file, extracted from lib/wcwidth.h.
* lib/wcwidth.h: Don't include wctype.h. Replace inline function
definition with an external declaration.
* m4/wcwidth.m4 (gl_FUNC_WCWIDTH): Use wcwidth.c when wcwidth is not
defined as a function. Remove AC_C_INLINE requirement.
* modules/wcwidth (Files): Add lib/wcwidth.c.
(Makefile.am): Remove redundant statement.

Re: Compilation warnings on MinGW due to Gnulib's wcwidth

[Gavin Smith]

On 19 June 2015 at 07:48, Eli Zaretskii  wrote:
> There was no wcwidth.h in texinfo-5.9.93's gnulib; now there is.  So
> the arrangement of how that declaration is pulled in changed
> significantly since then.

I downloaded the texinfo-5.9.94 pretest
(http://alpha.gnu.org/gnu/texinfo/), and it doesn't have wcwidth.h
either: the file is in the repository, but isn't being distributed.

[PATCH] maint: add a script to list libunistring modules

[Daiki Ueno]

Daiki Ueno  writes:

> The modules are listed by a script that does:
> - for each file listed by: git show --oneline --name-only 705f4efc
>   - deduce the containing modules, based on "Files:"
> - deduce the modules which depend on the containing modules, based
>   on "Depends-on:"
>
> It's tempting to automate those steps.  Is it okay to add some scripts
> for that to Gnulib?

So here it is.  As noted in the comment, it's often too slow.
Comments would be appreciated.

Regards,
-- 
Daiki Ueno
>From 64fcd6dcccf5ee1a639e9171092c078a1b2b975a Mon Sep 17 00:00:00 2001
From: Daiki Ueno 
Date: Fri, 19 Jun 2015 17:53:35 +0900
Subject: [PATCH] maint: add a script to list libunistring modules

* libunistring-modules: New script.
---
 ChangeLog|   5 ++
 libunistring-modules | 147 +++
 2 files changed, 152 insertions(+)
 create mode 100755 libunistring-modules

diff --git a/ChangeLog b/ChangeLog
index 66df3da..385ab23 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,10 @@
 2015-06-19  Daiki Ueno  
 
+	maint: add a script to list libunistring modules
+	* libunistring-modules: New script.
+
+2015-06-19  Daiki Ueno  
+
 	libunistring: bump minimum version to 0.9.6
 	* all modules depending on updated Unicode data: Regenerate.
 	The modules are listed by a script that does:
diff --git a/libunistring-modules b/libunistring-modules
new file mode 100755
index 000..8b6f0b3
--- /dev/null
+++ b/libunistring-modules
@@ -0,0 +1,147 @@
+#!/bin/sh
+#
+# Copyright (C) 2015 Free Software Foundation, Inc.
+#
+# This program is free software: you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 3 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program.  If not, see .
+#
+
+# List modules copied into libunistring.  If a git commit is
+# specified, it identifies modules affected by the commit (it's
+# often too slow).
+
+# Usage: libunistring-modules [COMMIT]
+
+progname=$0
+
+# func_tmpdir
+# creates a temporary directory.
+# Input:
+# - progname name of this program
+# Sets variable
+# - tmp pathname of freshly created temporary directory
+func_tmpdir ()
+{
+  # Use the environment variable TMPDIR, falling back to /tmp. This allows
+  # users to specify a different temporary directory, for example, if their
+  # /tmp is filled up or too small.
+  : ${TMPDIR=/tmp}
+  {
+# Use the mktemp program if available. If not available, hide the error
+# message.
+tmp=`(umask 077 && mktemp -d "$TMPDIR/glXX") 2>/dev/null` &&
+test -n "$tmp" && test -d "$tmp"
+  } ||
+  {
+# Use a simple mkdir command. It is guaranteed to fail if the directory
+# already exists.  $RANDOM is bash specific and expands to empty in shells
+# other than bash, ksh and zsh.  Its use does not increase security;
+# rather, it minimizes the probability of failure in a very cluttered /tmp
+# directory.
+tmp=$TMPDIR/gl$$-$RANDOM
+(umask 077 && mkdir "$tmp")
+  } ||
+  {
+echo "$progname: cannot create a temporary directory in $TMPDIR" >&2
+func_exit 1
+  }
+}
+
+# func_exit STATUS
+# exits with a given status.
+# This function needs to be used, rather than 'exit', when a 'trap' handler is
+# in effect that refers to $?.
+func_exit ()
+{
+  (exit $1); exit $1
+}
+
+PREFIXES='
+unicase
+uniconv
+unictype
+unigbrk
+unilbrk
+uniname
+uninorm
+unistdio
+unistr
+uniwbrk
+uniwidth
+'
+
+# If no commit is specified, list all modules and exit.
+if test $# -eq 0; then
+  echo unitypes
+  for prefix in $PREFIXES; do
+./gnulib-tool --list | grep "^$prefix/"
+  done
+  func_exit 0
+fi
+
+func_tmpdir
+trap 'exit_status=$?
+  if test "$signal" != 0; then
+echo "caught signal $signal" >&2
+  fi
+  rm -rf "$tmp"
+  exit $exit_status' 0
+for signal in 1 2 3 13 15; do
+  trap '{ signal='$signal'; func_exit 1; }' $signal
+done
+
+COMMIT="$1"
+
+# List all modules included in libunistring.
+modules=unitypes
+for prefix in $PREFIXES; do
+  add=`./gnulib-tool --list | grep "^$prefix/"`
+  modules="$modules $add"
+done
+
+# List the containing modules.
+files=`git show --oneline --name-only "$COMMIT" | tail -n+2`
+for file in $files; do
+  (cd modules && grep -l "^$file\$" $modules)
+done | sort | uniq > "$tmp/modules"
+
+# Loop until the dependent module list does not change.
+found=
+while test -z "$found"; do
+  for module in $modules; do
+dependencies=`./gnulib-tool --extract-dependencies $module`
+f

Re: [PATCH] libunistring: update to Unicode 8.0.0

[Daiki Ueno]

Daiki Ueno  writes:

> Daiki Ueno  writes:
>
>> Due to the size limitation, I'm sending manually adjusted files only.
>> Generated files have been already committed too.
>
> Also updated uniname/uniname, which contains only generated content.

One more thing: I've bumped the minimum libstring version of affected
modules to 0.9.6, so libunistring-optional should work:

2015-06-19  Daiki Ueno  

libunistring: bump minimum version to 0.9.6
* all modules depending on updated Unicode data: Regenerate.
The modules are listed by a script that does:
- for each file listed by: git show --oneline --name-only 705f4efc
  - deduce the containing modules, based on "Files:"
- deduce the modules which depend on the containing modules, based
  on "Depends-on:"

It's tempting to automate those steps.  Is it okay to add some scripts
for that to Gnulib?

Regards,
-- 
Daiki Ueno