Re: New way to integrate gnulib into projects?

[Simon Josefsson]

Bruce Korb <bkorb@gnu.org> writes:

> On 5/15/21 1:01 AM, Simon Josefsson via Gnulib discussion list wrote:
>> However, running ./bootstrap remains painfully slow.
> Amen!!!
>> Then a second run of ./bootstrap in the directory would avoid the
>> gnulib-tool step, and only run autoreconf and friends.  A new cfg.mk
>> variable to tell ./bootstrap to avoid checking out the gnulib repository
>> and run gnulib-tool by default would be needed.
>>
>> Thoughts?
>>
>> I think most of the functionality I want could be achieved today by
>> clever use of 'AUTORECONF=true AUTOPOINT=true LIBTOOLIZE=true
>> ./bootstrap' and clever cfg.mk instrumenting with some hook together
>> with './bootstrap --no-git'.  So I could probably test my approach with
>> only minimal changes to ./bootstrap now.
>
> I'd add it as "./bootstrap --brief" and no-op the commands internally.

I did a couple of experiments with my idea, but for libidn eventually
gave up.  I removed all source files from git and use gnulib's
./bootstrap to re-generate everything.

I came up with another idea instead of the one I mentioned: introduce a
caching mechanism, so that after ./bootstrap has run, tar together all
files it created, and that tarball can be used as a quick variant of
./bootstrap step later on.  I think this approach is likely to work out
better in practice, and also addresses the slowness of autoreconf (which
appears to make up half of the ./bootstrap slowness).

There was two main problems that made speeding up ./bootstrap difficult:

  1) License-rewrites.  One way to speed up things is to not run
  ./gnulib-tool to find out which files to copy and copy them, is to use
  'rsync' for the files that are needed.  However, this doesn't work
  when you want to rewrite license headers.

  2) Ordering-dependent generation of M4 files.  Autopoint and
  libtoolize create M4 macros that must be overwritten by M4 macros from
  gnulib with gnulib-tool.  However, the rest of M4 macros autoreconf
  must be run after gnulib-tool because configure.ac etc depend on the
  gnulib M4 macros.

One approach is to try to fix those problems.  However I think there
will be similar instances like those problems in the future, and that
fixing them all isn't a viable solution.  Hence that is how I came up
with the tar-caching-idea.

> I still think the best solution is to put much of the gnulib stuff
> into an installable gnulib-dev package that would be required by the
> bootstrap script. I proposed that about 2 decades ago, but we're still
> spending gobs of compute and wall clock resources recomputing the same
> stuff. :(

The problem is what to do if your project requires a newer version of
some gnulib file.

/Simon

signature.asc
Description: PGP signature