[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
The state of the 1.4.x branch
From: |
Bruno Haible |
Subject: |
The state of the 1.4.x branch |
Date: |
Wed, 04 Mar 2020 11:33:34 +0100 |
User-agent: |
KMail/5.1.3 (Linux/4.4.0-174-generic; KDE/5.18.0; x86_64; ; ) |
Hi all,
The 'branch-1.4' of the git repository
https://git.savannah.gnu.org/gitweb/?p=m4.git;a=shortlog;h=refs/heads/branch-1.4
uses a git submodule that connects it to a particular version of gnulib,
from 2016.
This makes it impossible to use the normal checkout or the m4-1.4.18 release
for building on recent glibc systems and on recent macOS systems:
1) On recent glibc systems, the code base does not build. This was reported
multiple times, in
https://lists.gnu.org/archive/html/bug-m4/2018-08/msg00000.html
https://lists.gnu.org/archive/html/bug-m4/2018-11/msg00001.html
https://lists.gnu.org/archive/html/bug-m4/2019-04/msg00000.html
https://lists.gnu.org/archive/html/bug-m4/2019-10/msg00000.html
The fix is included in gnulib since 2018-03-05.
2) On macOS 10.13 and newer, the code builds, but m4 fails at runtime
with an 'Abort trap: 6' error. This was reported multiple times as well
and analyzed by Jeremy Huddleston Sequoia <address@hidden>
and Rainer J.H. Brandt <address@hidden>
https://lists.gnu.org/archive/html/bug-m4/2018-05/msg00000.html
https://lists.gnu.org/archive/html/bug-m4/2018-06/msg00000.html
https://lists.gnu.org/archive/html/bug-m4/2019-11/msg00004.html
https://lists.gnu.org/archive/html/bug-m4/2020-02/msg00007.html
The fix is included in gnulib since 2017-07-07.
So, it seems like every user's "simple" way out is to forget about the
git submodule and use the newest gnulib instead? Well, this is not
working either, because
- The invocation conventions of 'bootstrap' make it hard to use
a version of gnulib other than the one in the git submodule,
- Since 2018-10-23, it produces a gnulib-tool error:
https://lists.gnu.org/archive/html/bug-m4/2019-11/msg00000.html
I now need a working m4 tarball in order to do Emacs testing (since
Emacs depends on gnutls, gnutls depends on nettle, and nettle depends
on m4).
For this reason, I've set up a continuous integration that produces
a working m4-1.4.x tarball, once every week.
It is based on the 1.4.x branch, since the 'master' branch has many
changes that have not undergone release testing.
The newest created (snapshot) tarball is available through the Gitlab UI
https://gitlab.com/gnu-m4/ci-distcheck
> CI/CD > Jobs > Finished (check-optimized)
> Job artifacts > Browse > m4-snapshot.tar
or directly through the following command sequence:
wget -O m4-snapshot.tar
'https://gitlab.com/gnu-m4/ci-distcheck/-/jobs/artifacts/master/raw/m4-snapshot.tar?job=check-optimized'
tar xf m4-snapshot.tar
I invite the m4 maintainers, if they are unwilling to make a new m4
release, to at least point the users to the tarball available from this
continuous integration. For example through a couple of lines added
to the HACKING file.
I also invite the m4 maintainers to collaborate on the said continuous
integration project, if they want to.
Bruno
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- The state of the 1.4.x branch,
Bruno Haible <=