Ludovic Courtès <l...@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
signature.asc
Description: PGP signature
_______________________________________________ Gnutls-help mailing list Gnutls-help@lists.gnutls.org http://lists.gnupg.org/mailman/listinfo/gnutls-help