Make 4.3 fix #493
Merged
Make 4.3 fix #493
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
… some cases The fix was found by @asavah.
|
And everything continues to work with prior versions of make? |
|
I tested mame rebuild with make-4.2.1 (windows, bash shell) and make-4.1 (windows, cmd shell) and make-4.2.1 (fedora, bash shell). I did not see any problems. |
AluisioASG
added a commit
to AluisioASG/mame2016-libretro
that referenced
this pull request
Oct 28, 2020
Apply the upstream fix from bkaradzic/GENie#493, which was verified to work with previous Make releases as well.
10 tasks
AluisioASG
added a commit
to AluisioASG/nixpkgs
that referenced
this pull request
Oct 28, 2020
Builds currently fail with `ar` trying to operate on what are clearly two paths concatenated together. It stems from a backward-incompatible change in Make: > 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. This issue was first reported on the MAME repository proper (mamedev/mame#6248), and affects libretro's 2016 snapshot as well. A fix that is reported to work with previous versions of Make was upstreamed to: - GENie, the build system: bkaradzic/GENie#493 - MAME: mamedev/mame#6262 - libretro: libretro/mame2016-libretro#47 The fetched patch comes from the last of these.
AluisioASG
added a commit
to AluisioASG/nixpkgs
that referenced
this pull request
Oct 30, 2020
Builds currently fail with `ar` trying to operate on what are clearly two paths concatenated together. It stems from a backward-incompatible change in Make: > 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. This issue was first reported on the MAME repository proper (mamedev/mame#6248), and affects libretro's 2016 snapshot as well. A fix that is reported to work with previous versions of Make was upstreamed to: - GENie, the build system: bkaradzic/GENie#493 - MAME: mamedev/mame#6262 - libretro: libretro/mame2016-libretro#47 The fetched patch comes from the last of these. (cherry picked from commit 8880179)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
As of make-4.3 vairables no longer start with space when += is user to prepend an empty variable [1]:
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.
This was causing issues when building mame [2].
[1] https://lwn.net/Articles/810071/
[2] mamedev/mame#6248