[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 4.4: embeds volatile information in MAKEFLAGS

From: Steffen Nurpmeso
Subject: Re: 4.4: embeds volatile information in MAKEFLAGS
Date: Mon, 07 Nov 2022 21:55:42 +0100
User-agent: s-nail v14.9.24-343-g9e3ff607d5

Paul Smith wrote in
 |On Mon, 2022-11-07 at 21:24 +0100, Steffen Nurpmeso wrote:
 |> What would interest me now.  Will there be GNU make 4.4.1?
 |> (On the left and right i see quite some changes of projects to
 |> become compatible with GNU make 4.4 though, CRUX Linux imported
 |> a pretty lengthy glibc patch, and on the ports list of OpenBSD
 |> there is also trouble..)
 |It looks like there will probably need to be one, yes.

Oh there is a sense of relief here.

 |However, I don't think that any changes being made for GNU Make 4.4
 |compatibility, would render the makefile unusable with GNU Make 4.3
 |(unless they start actually using the new features like the new
 |functions, but I don't know of any projects doing so yet... of course
 |that doesn't mean they are not) so sticking with 4.3 shouldn't render
 |any projects unbuildable.

To be honest i also struggled with what to do per se.  We want to
preserve MAKEFLAGS for future invocations, but now would need to
clean it up to work around things that cause problems further on.
(Parsing this requires understanding of shell quoting.  And noone
knows what users may want to do or use for flags.)

Small projects like mine can be lucky to have some packagers that
care for new releases in time at all, but beside this noone will
put more work in it than absolutely necessary.  (There are
packagers which manage dozens, or even _many hundreds_ of
packages.)  I could only make a new release.

 |Most of these changes are cleanups to always-problematic code, that
 |used to happen to work "by accident" but no longer does (or won't in
 |the future for deprecated things).

I personally do not use any sophisticated make(1) constructs, no
inclusions, conditionals, patterns.  It is only -j and (sorts of)

 --End of <e800cbde5eaac3785340c61be2bcdb936d63140f.camel@gnu.org>

Thank you, Paul Smith.

|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

reply via email to

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