bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

New way to integrate gnulib into projects?


From: Simon Josefsson
Subject: New way to integrate gnulib into projects?
Date: Sat, 15 May 2021 10:01:43 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)

Hi.  There are a couple of different ways to use gnulib in projects:

https://www.gnu.org/software/gnulib/manual/html_node/VCS-Issues.html

At some point in some project I've used all variants, but today most of
my projects are converted into not commiting any gnulib files at all and
use gnulib's bootstrap.  This works fairly well, even in projects that
need multiple gnulib instances.

However, running ./bootstrap remains painfully slow.  For my projects,
it is taking the majority of build time.  I'm now looking at refreshing
'libidn' which is an old project that is using approach 1 in the link
above.  That is, no ./bootstrap but only 'gnulib-tool --add-update' and
put all generated files in git.  Building it is quick since no bootstrap
phase is needed, just autoreconf (which is the slowest part of that
build).  The problem is that updating of gnulib-tool-generated files
into VCS is a manual process.

FWIW, for libidn, on my laptop, it takes 30 seconds to run gnulib-tool,
20 seconds to run autoreconf etc, 20 seconds to run ./configure, 35
seconds to run make, 20 seconds to run make check (without valgrind).
For a project with excessive gnulib usage, like oath-toolkit, running
gnulib-tool takes 2 minutes and 42 seconds since there are multiple
gnulib-instances in it.

I'm thinking there may be room for another way of using gnulib in
projects: add one new option to ./bootstrap to cause it to retrieve all
gnulib files but NOT run autoreconf and friends.  I would then use
./bootstrap to retrieve all gnulib-related source files, and commit the
result in git.  Downloading a tarball-copy of that git repository would
allow people to do autoreconf && ./configure && make from a source-only
distribution, which is sometimes requested.

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.

/Simon

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]