bug-m4
[Top][All Lists]
Advanced

[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




reply via email to

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