[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: New release of GNU make
From: |
Paul Smith |
Subject: |
Re: New release of GNU make |
Date: |
Sun, 04 Sep 2022 09:52:44 -0400 |
User-agent: |
Evolution 3.44.4 (by Flathub.org) |
On Sun, 2022-09-04 at 00:28 +0000, Martin Dorey wrote:
> https://git.savannah.gnu.org/cgit/make.git/commit/configure.ac?id=079
> 3658c09a8f33581dae6dfbe2483ea279e72b1
>
> ... imposed a dependency on autoconf 2.71.
I'm not sure if there's a need for this new autoconf version or not, I
can look at gnulib. The issue is that I have a version of autoconf and
that's the only one I test (and build) with. I'm not excited about
adding a suite of different autoconf versions :) but it would be good
to rely only on autoconf versions that are more widely available, if
possible.
I do agree that this should be mentioned in the NEWS file.
> > for people to try out who don't want to go through the process
> > of bootstrapping from a Git
>
> ... while I don't like to depend, I do struggle with this part ~every
> release. Today for instance I couldn't make clean or make distclean
> to get my existing git work area to build with those new autotools.
When switching these fundamental tools I just use `git clean -fdx`,
rather than bothering with `make clean`.
> After cloning fresh worked, I realized that I should have tried
> moving the gnulib subdirectory aside as well as the m4 one.
The way I work is I have a separate clone of gnulib, and I set
GNULIB_SRCDIR to point to that workspace, then make's bootstrap etc.
doesn't try to create its own clone. So to be honest I don't really
have any idea what issues might pop up when using gnulib that is
checked out inside the make workspace.
Also I have an un-pushed commit that sets GNULIB_REVISION to avoid
always pulling the latest gnulib version: we've seen build-from-git
fail before due to changes in gnulib.