On Tue, Jan 21, 2020 at 2:03 PM DJ Delorie <dj@xxxxxxxxxx> wrote: > > > I've taken a look at the new make release, and updating Fedora's make > won't be that tricky (aside from some noted backwards > incompatibilities[1], who knows) but I see no reason to rush it into a > last-minute update this close to branching F32. My current plan is to > introduce it to rawhide just after the F32 branch to give folks time > to see if the update breaks anything, but I'm open to convincing > arguments to push it (or backport it) into F32 also. > > We also have some paranoia patches leftover from the 3.8->4.0 update, > including one that changes how newlines are quoted in shell jobs > (upstream quotes backslashes and newlines with more backslashes, > Fedora quotes them with ''). Does anyone have any opinions on this? > Other distros don't have similar patches, but... paranoia :-) > > > > [1] From NEWS: > > * WARNING: Backward-incompatibility! > Number signs (#) appearing inside a macro reference or function invocation > no longer introduce comments and should not be escaped with backslashes: > thus a call such as: > foo := $(shell echo '#') > is legal. Previously the number sign needed to be escaped, for example: > foo := $(shell echo '\#') > Now this latter will resolve to "\#". If you want to write makefiles > portable to both versions, assign the number sign to a variable: > H := \# > foo := $(shell echo '$H') > This was claimed to be fixed in 3.81, but wasn't, for some reason. > To detect this change search for 'nocomment' in the .FEATURES variable. > > * WARNING: Backward-incompatibility! > Previously appending using '+=' to an empty variable would result in a value > starting with a space. Now the initial space is only added if the variable > already contains some value. Similarly, appending an empty string does not > add a trailing space. > > * NOTE: Deprecated behavior. > Contrary to the documentation, suffix rules with prerequisites are being > treated BOTH as simple targets AND as pattern rules. Further, the > prerequisites are ignored by the pattern rules. POSIX specifies that in > order to be a suffix rule there can be no prerequisites defined. In this > release if POSIX mode is enabled then rules with prerequisites cannot be > suffix rules. If POSIX mode is not enabled then the previous behavior is > preserved (a pattern rule with no extra prerequisites is created) AND a > warning about this behavior is generated: > warning: ignoring prerequisites on suffix rule definition > The POSIX behavior will be adopted as the only behavior in a future release > of GNU make so please resolve any warnings. These issues don't seem significant enough to hold back to Fedora 33... The backward incompatibility about appending is unlikely to be behavior that Makefiles depend on, and I haven't seen any Makefiles abusing the comment thing (not to say that there isn't any, but I think they'd be rare enough to be easily fixed if encountered). -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
