bug-make
[Top][All Lists]
Advanced

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



reply via email to

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