Fix issue running scons using a symlink to scons.py in an scons-local dir #3271
Conversation
This file contains hidden or 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
bdbaddog
reviewed
Jan 15, 2019
| @@ -14,11 +14,14 @@ RELEASE VERSION/DATE TO BE FILLED IN LATER | |||
| - Improve finding of Microsoft compiler: add a 'products' wildcard | |||
| in case 2017 Build Tools only is installed as it is considered a separate | |||
| product from the default Visual Studio | |||
| - scons.py and sconsign.py stopped working if script called as a symlink | |||
There was a problem hiding this comment.
Change to "Fixed issue running scons-local when called via a symlink"
2 similar comments
bdbaddog
reviewed
Jan 15, 2019
src/CHANGES.txt
Outdated
| @@ -14,11 +14,14 @@ RELEASE VERSION/DATE TO BE FILLED IN LATER | |||
| - Improve finding of Microsoft compiler: add a 'products' wildcard | |||
| in case 2017 Build Tools only is installed as it is considered a separate | |||
| product from the default Visual Studio | |||
| - Fixed issue running scons-local using a symlink to the scons.py in | |||
There was a problem hiding this comment.
oh is there and issue # for this, if so please reference?
There was a problem hiding this comment.
No, the report came in on irc and I don't see a GH issue for it.
Earlier fix to running with scons-local when the directory is a
symlink (i.e. scons-local symlinked to scons-local-{versiontag} and
invoked as scons-local/scons.py) broke running scons when the
"executable" is a symlink. Restoring that behavior.
This is dodgy to test reliably on a developer system, as the
fallback mechansim to find a usable scons goes on to look for
a system-installed scons, so it looked like it was working. I
will add a test if I can figure out a good way.
Signed-off-by: Mats Wichmann <mats@linux.com>
mwichmann
changed the title
Signed-off-by: Mats Wichmann <mats@linux.com>
mwichmann
force-pushed
the
scons-symlink
branch
from
1f59bd9 to
74187aa
Compare
|
Can you make a test for this so we don't break it again going forward? |
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.
Earlier fix to running with scons-local when the directory is a
symlink (i.e. scons-local symlinked to scons-local-{versiontag} and
invoked as scons-local/scons.py) broke running scons when the
"executable" is a symlink. Restoring that behavior.
This is dodgy to test reliably on a developer system, as the
fallback mechansim to find a usable scons goes on to look for
a system-installed scons, so it looked like it was working. I
will add a test if I can figure out a good way.
Signed-off-by: Mats Wichmann mats@linux.com
Contributor Checklist:
master/src/CHANGES.txtdirectory (and read theREADME.txtin that directory)