bug-hello
[Top][All Lists]
Advanced

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

Build system issues make building GNU hello from git hard


From: Matthew Vernon
Subject: Build system issues make building GNU hello from git hard
Date: Tue, 10 Oct 2023 10:15:55 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.15.1

Hi,

I wanted an example piece of software for a tutorial on packaging upstream software from git for binary .debs, and figured GNU Hello would be a good choice. I'm afraid the experience of building from a git tag (i.e. clone the repo, check out the tag of the release you want to build, build) is quite hostile; I found three key problems:

1) bootstrap installs git hooks that reject commit messages

I appreciate that for patches sent upstream you have coding standards, but the commit-message hook is confusing for newcomers, and particularly interacts badly with e.g. emacs' git mode (if you commit a message from within emacs that the hook doesn't like your emacs spins indefinitely; and then recovery is hard because the hook will look for the editor configured in git, so even if you do EDITOR=nano git commit to try and un-wedge things, it still tries to launch emacsclient if the commit message wasn't right.

2) gnulib is used as a git submodule

This adds unnecessary complexity to the build process, and requires special handling in CI too. Further, it's not necessary to use gnulib thus (e.g. man-db doesn't use it as a submodule), and submodules aren't really best practice (cf https://diziet.dreamwidth.org/14666.html which expounds on their limitations at length)

3) tests erroneously fail inside CI

I've made no modifications to gnulib, but my CI (inside gitlab, using GIT_SUBMODULE_STRATEGY: recursive ) fails because the test code thinks I've modified something in the submodule - the failing code is:

git submodule --quiet foreach                                   \
      'test "$(git rev-parse "$sha1")"                      \
          = "$(git merge-base origin "$sha1")"'             \
    || { echo 'maint.mk: found non-public submodule commit' >&2; \
         exit 1; };     

You can see a full build log here (error at the bottom):

https://gitlab.wikimedia.org/repos/data_persistence/matthewvernon-demo-hello/-/jobs/150946

It's hard to make headway on fixing that because the actual outputs from git rev-parse and git merge-base aren't emitted, and maint.mk is inside the submodule (which I can't edit without falling foul of that check for real).

Likewise, I can get my package to build by skipping the tests, but that's not really ideal for a tutorial showing how things should be done :)

Sorry to be picky about build systems, but GNU Hello does describe itself as an example of best development practice, and I think given that it ought to be more straightforward to build it from a git checkout.

Thanks for your consideration,

Matthew



reply via email to

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