[gnutls-help] Guile-Gnutls bindings to separate git repo?

[Simon Josefsson]

Ludovic Courtès <ludo at gnu.org> writes:

>> I can understand that you would want to build from git instead of
>> tarballs.  How does the download and build process work in Guix?
>> Without knowing anything about the environment, I imagine there is some
>> part of the process that downloads the git archive from gitlab, checks
>> out a particular git tag and verify the PGP signature or compute a hash
>> checksum and compares it?  Can't that process be teached how to also
>> download the git submodule?
>
> Yes, we can change the origin to grab sub-modules as well:
>
>         (origin
>           (method git-fetch)
>           (uri (git-reference
>                 (url home-page)
>                 (recursive? #t)  ; ← here

Ah, great, so at least there is no fundamental problem with git
submodules.

> starting phase `pre-bootstrap'
> patch-shebang: autopull.sh: changing `/bin/sh' to `/gnu/store/4y5m9lb8k3qkb1y9m02sw9w9a6hacd16-bash-minimal-5.1.8/bin/sh'
> phase `pre-bootstrap' succeeded after 0.0 seconds
> starting phase `bootstrap'
> running './bootstrap'
> patch-shebang: ./bootstrap: changing `/bin/sh' to `/gnu/store/4y5m9lb8k3qkb1y9m02sw9w9a6hacd16-bash-minimal-5.1.8/bin/sh'
> ./bootstrap: Bootstrapping from checked-out guile-gnutls sources...
> ./autopull.sh: getting gnulib files...
> fatal: not a git repository (or any of the parent directories): .git
> ./bootstrap: autopull.sh failed.

Strange, I wonder what is happening there, and why it doesn't happen on
GitLab CI/CD -- it also checks out the git repository including
submodules, and then ./bootstrap is ran.

> Taking a step back, we’re using Gnulib for these modules:
>
>   git-version-gen
>   havelib
>   gitlog-to-changelog
>   readme-release
>   update-copyright
>
> Does Gnulib “pay for its weight”?  In this case, I don’t think so.
>
> In Guix, I manually copied ‘git-version-gen’ and ‘gitlog-to-changelog’
> in the tree, back in the day.  The ‘bootstrap’ script does little more
> than “autoreconf -vfi” (nowadays it does weird things related to i18n,
> but that’s another story).  Yes, this duplicates two files and a few
> lines in ‘Makefile.am’ and ‘configure.ac’, but the end result is far
> more tractable IMO¹.
>
> Mind you, this is not criticism of Gnulib in general; as you know I was
> an early adopter and promoter, and it’s served us well in Guile for its
> C portability helpers.  I think we have to check the cost/benefit ratio,
> which has both technical and social aspects to it, and in this
> particular case, I view Gnulib an unnecessary burden.
>
> WDYT?
>
> Ludo’.
>
> ¹ The bootstrap + Gnulib machinery in Guile-GnuTLS is almost 900 lines:
>
> $ wc -l bootstrap* cfg.mk
>   214 bootstrap
>    44 bootstrap.conf
>   594 bootstrap-funclib.sh
>    39 cfg.mk
>   891 total

I share your frustration with complex dependencies.  Is your problem
mainly that it is harder to build guile-gnutls, or is it the size of the
added code, or the actual code?  Maybe a combination, but I'm not sure
which is the main problem here.

The main reason I added the dependencies was 1) to get 'make web-manual'
to produce a manual during CI/CD, 2) to get a proven 'make release'
infrastructure including the README-release file, 3) added
git-version-gen to avoid manual work and to get CI/CD tarballs with good
naming, 4) 'make syntax-check', 5) havelib, and maybe some other parts
that I forgot.

When I look at what changed between these releases, I think the main
complication is the new bootstrap infrastructure.  That is not critical
for using gnulib, and in fact it is highly complex for what it should be
doing: copying a couple of files and then run autoreconf.  I don't see
what extra features it brings guile-gnutls.

I have pushed a branch 'jas/drop-bootstrap' which reverts back to a
simple ./bootstrap script but still uses gnulib-tool from the git
submodule to import some files.  What do you think?

https://gitlab.com/gnutls/guile/-/commit/ec362e8bdb7604295fc24f6f20aea5e5ecf78117

Maybe this strikes a better balance between reusing elements from gnulib
but keeping complexity low.  CI/CD passes with no changes, suggesting
that we really never relied on anything else from ./bootstrap.

If you think using gnulib-tool is too costly as well, we can replace it
with a couple of 'cp' commands, but I'm hoping this complexity reduction
is sufficient.

Would you like to make a 3.7.12 out of this?  I'm happy to do it if you
prefer, but it would be nice to get your PGP key into distributors'
trust anchors for guile-gnutls, and I don't know of any mechanism except
having the person make a release.

/Simon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 255 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnutls-help/attachments/20221220/424138c5/attachment-0001.sig>