updating gnulib-tool.py

[Bruno Haible]

Hi,

Recently I got frustrated again about how much time the creation of a
gnulib testdir takes. I found out that

1) There is not much difference between "bash gnulib-tool ..." and
   "dash gnulib-tool ...". Although bash is generally slower than other
   Bourne-compatible shells, for gnulib-tool is does not matter much.

2) Two thirds of the runtime is spent in the license compatibility checks,
   because for each module, we compute func_modules_transitive_closure
   and then extract the license of each module in this transitive closure.
   So, it's clear that what needs speedup is the string and list processing
   of func_verify_module, func_acceptable, func_get_dependencies,
   func_get_tests_module, and so on.

   This was also confirmed by doing bash profiling.

So, it becomes clear again that a shell script — because it has a relatively
small library of built-ins — is not suitable for massive string and list
processing. In other words, a shell script is useful for connecting programs
together (through files, pipes, sockets), but shell is just *NOT* a decent
_application_ programming language.

I considered splitting the low-level parts (dealing with module description
files and module description fields) to a C part, leaving the upper layer in
shell.
  (a) by compiling the C part as a shared library — but that is not future-
      proof because the interface between bash extensions and bash is not
      documented.
  (b) by compiling the C part as a program, run as bash 'coproc'. This is
      more solid. gnulib-tool would send strings that look like function
      invocations to the C coprocess, and this one would respond with strings
      sent back, that gnulib-tool would read into bash variables through
      "IFS= read -r -delim ''". Still, the amount of process communication
      frightens me.

Then I ran gnulib-tool.py again, found that it is faster than I expected
(maybe Python 3 has a better compiler now than 10 years ago?). Also, Python
is more popular than ever (but that helps us only if we don't have idio-
syncracies in our Python code).

So, I am now restarting the effort to bring gnulib-tool.py up-to-date with
gnulib-tool.

Today's changes:

2022-07-29  Bruno Haible  <bruno@clisp.org>

        gnulib-tool.py: Follow gnulib-tool changes, part 17.
        Follow gnulib-tool change
        2015-10-06  Pavel Raiskup  <praiskup@redhat.com>
        gnulib-tool: fix tests of 'extensions' module
        * pygnulib/GLEmiter.py (GLEmiter.preEarlyMacros): New function.
        * pygnulib/GLImport.py (GLImport.gnulib_comp): Invoke it.
        * pygnulib/GLTestDir.py (GLTestDir.execute): Likewise.

        gnulib-tool.py: Follow gnulib-tool changes, part 16.
        Follow gnulib-tool change
        2015-09-25  Pavel Raiskup  <praiskup@redhat.com>
        gnulib-common.m4: fix gl_PROG_AR_RANLIB/AM_PROG_AR clash
        * pygnulib/GLImport.py (GLImport.gnulib_comp): Put the
        gl_USE_SYSTEM_EXTENSIONS right before gl_PROG_AR_RANLIB into
        gnulib-comp.m4 (if the 'extensions' module is used).

        gnulib-tool.py: Modernize coding style.
        * pygnulib/*.py: Remove parentheses around return value expressions.

        gnulib-tool.py: Modernize the file headers.
        * pygnulib/*.py: Remove '#!/usr/bin/python' (not needed) and
        'encoding: UTF-8' lines (default in Python 3). Add copyright notice.

        gnulib-tool.py: Use mainstream coding style.
        * gnulib-tool.py: Clarify the coding style. Fix some pycodestyle
        warnings.
        * pygnulib/constants.py: Likewise.
        * pygnulib/GLEmiter.py: Likewise.
        * pygnulib/GLImport.py: Likewise.
        * pygnulib/GLMakefileTable.py: Likewise.

0001-gnulib-tool.py-Use-mainstream-coding-style.patch
Description: Text Data

0002-gnulib-tool.py-Modernize-the-file-headers.patch
Description: Text Data

0003-gnulib-tool.py-Modernize-coding-style.patch
Description: Text Data

0004-gnulib-tool.py-Follow-gnulib-tool-changes-part-16.patch
Description: Text Data

0005-gnulib-tool.py-Follow-gnulib-tool-changes-part-17.patch
Description: Text Data