Re: Build system issues make building GNU hello from git hard

[Reuben Thomas]

On Tue, 10 Oct 2023 at 14:09, Matthew Vernon <mvernon@wikimedia.org> wrote:

> 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.


GNU Hello certainly aspires to be a good choice! Thanks for feeding back
the problems you ran into.

GNU Hello has a problem in a situation like this: on the one hand it aims
to be an exemplar for newbie developers; on the other, it attempts to
showcase various GNU build system tech in a fairly fulsome way, and be an
example of best practice. And in particular, it does not try to lead,
either technically or procedurally, the state of the art, but follow, so
that what it shows is representative of current tools and projects.

So the place to address these concerns is probably not in GNU Hello. If
you're writing a tutorial, you have two choices:

1. Use another project.
2. Use GNU Hello, and make the tutorial longer. There are reasons for
everything it does, and something to be learned from them.
3. Both: say, write a simple short tutorial with another project, and use
GNU Hello to introduce real-world complexities.
4. Get the problems you note fixed upstream.

(I know, that's four options, and more than two choices.)

1) bootstrap installs git hooks that reject commit messages
>

The scripts are from coreutils. I think it's reasonable for GNU Hello
itself to be as strict as coreutils, so that it becomes a better example of
practice.

Can you think of a way to keep the strictness for Hello developers, but not
for those using Hello as a practice project?

> (if you commit a message from
> within emacs that the hook doesn't like your emacs spins indefinitely;
>

This sounds like a bug: maybe you could report it to coreutils? A quick
look suggests that this might be an already-fixed bug: does this sound
familiar:

    (main): Don't loop when stdout is redirected, as it is when
    invoked via vc-dwim.

? Coreutils commit a2b21e910. If so, we can simply import the fix to hello.

2) gnulib is used as a git submodule
>

This is an option that is clearly documented in gnulib's docs, and I'll
confess it's what I use on all my gnulib-using projects. It's also what
most GNU projects seem to use. I don't think we want to do something
different in Hello just because it's better. At the very least, what we do
should be clearly documented in gnulib's manual.

So, I'm open to suggestions!

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


This sounds like a potential bug. I'm sorry, I don't have the time to look
into it. (I'm answering your mail as current maintainer of last resort of
Hello, of which I'm more accurately an emeritus maintainer who has
consented to have their name on the package again because no-one else is
available.)


> 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.
>

You're quite right, and I hope I've shown why it's not that easy. I am
happy to have suggestions within the constraints I've mentioned above; I
only fear that it may be quite a lot of work to figure out something
that'll keep me happy.

One other idea that might fly: a parallel, simpler build system for GNU
Hello more suited to didactic purposes. It could avoid autotools altogether
and use CMake, for example.

-- 
https://rrt.sc3d.org