Skip to content

Use scons as the default MSVSSCONS variable #4810

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
madmiraal wants to merge 2 commits into from
+4 −36
Closed

Use scons as the default MSVSSCONS variable #4810

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
46bf8fd
Use scons as the default MSVSSCONS variable
madmiraal Jan 2, 2026
7628f7c
Merge branch 'master' into change-default-MSVSSCONS
bdbaddog Jan 18, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
3 changes: 3 additions & 0 deletions CHANGES.txt
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -15,6 +15,9 @@ RELEASE VERSION/DATE TO BE FILLED IN LATER
From John Doe:
- Whatever John Doe did.

From Marcel Admiraal:
- Use scons as the default MSVSSCONS variable.

From Joseph Brill:
- Add possible build failure when targeting 32-bit arm using
Visual Studio 2022 with Windows SDK version 10.0.26100.0 or later
Expand Down
37 changes: 1 addition & 36 deletions SCons/Tool/msvs.py
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -152,41 +152,6 @@ def msvs_parse_version(s):
num, suite = version_re.match(s).groups()
return float(num), suite

# This is how we re-invoke SCons from inside MSVS Project files.
# The problem is that we might have been invoked as either scons.bat
# or scons.py. If we were invoked directly as scons.py, then we could
# use sys.argv[0] to find the SCons "executable," but that doesn't work
# if we were invoked as scons.bat, which uses "python -c" to execute
# things and ends up with "-c" as sys.argv[0]. Consequently, we have
# the MSVS Project file invoke SCons the same way that scons.bat does,
# which works regardless of how we were invoked.
def getExecScriptMain(env, xml=None):
if 'SCONS_HOME' not in env:
env['SCONS_HOME'] = os.environ.get('SCONS_HOME')
scons_home = env.get('SCONS_HOME')
if not scons_home and 'SCONS_LIB_DIR' in os.environ:
scons_home = os.environ['SCONS_LIB_DIR']
if scons_home:
exec_script_main = "from os.path import join; import sys; sys.path = [ r'%s' ] + sys.path; import SCons.Script; SCons.Script.main()" % scons_home
else:
version = SCons.__version__
exec_script_main = "from os.path import join; import sys; sys.path = [ join(sys.prefix, 'Lib', 'site-packages', 'scons-%(version)s'), join(sys.prefix, 'scons-%(version)s'), join(sys.prefix, 'Lib', 'site-packages', 'scons'), join(sys.prefix, 'scons') ] + sys.path; import SCons.Script; SCons.Script.main()" % locals()
if xml:
exec_script_main = xmlify(exec_script_main)
return exec_script_main

# The string for the Python executable we tell the Project file to use
# is either sys.executable or, if an external PYTHON_ROOT environment
# variable exists, $(PYTHON)ROOT\\python.exe (generalized a little to
# pluck the actual executable name from sys.executable).
try:
python_root = os.environ['PYTHON_ROOT']
except KeyError:
python_executable = sys.executable
else:
python_executable = os.path.join('$$(PYTHON_ROOT)',
os.path.split(sys.executable)[1])

class Config:
pass

Expand Down Expand Up @@ -2147,7 +2112,7 @@ def generate(env) -> None:
# MSVSSCONSFLAGS. This helps support consumers who use wrapper scripts to
# invoke scons.
if 'MSVSSCONS' not in env:
env['MSVSSCONS'] = '"%s" -c "%s"' % (python_executable, getExecScriptMain(env))
env['MSVSSCONS'] = 'scons'
Copy link
Copy Markdown
Contributor

@bdbaddog bdbaddog Jan 2, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

probably not this as well. MSVSSCONS is meant to override the existing mechanism explicitly, and not by default.

Copy link
Copy Markdown
Contributor

@bdbaddog bdbaddog Jan 2, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The right way to do this is to find the path to the scons being executed and use that, instead of defaulting to site-scons...

Copy link
Copy Markdown
Collaborator

@mwichmann mwichmann Jan 2, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmmm, I got email with a comment about using sys.executable, and it doesn't show here on the PR page. Weird.

Anyway, sys.exectuable can be unset, according to the docu (can be emtpy string or None). I'm not sure the circumstances - odd packaging is one known cause (like a pyinstaller bundle) but maybe there are others.

Copy link
Copy Markdown
Contributor

@bdbaddog bdbaddog Jan 2, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sure. but people doing really silly things aren't generally worthy adding bunches of code for.. ?

Copy link
Copy Markdown
Collaborator

@mwichmann mwichmann Jan 2, 2026 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The right way to do this is to find the path to the scons being executed and use that, instead of defaulting to site-scons...

It seems like this is the intent, anyway. From the manpage:

MSVSSCONS - The SCons used in generated Microsoft Visual C++ project files. The default is the version of SCons being used to generate the project file.

In any case, the stanza used to figure out the value isn't updated for how a pip-installed scons is invoked ("console script", which is a little .exe made during packaging), so it could use some work. But that wasn't the case in the issue report, with the scoop install. Anyway, here's the comment from the msvs tool:

# This is how we re-invoke SCons from inside MSVS Project files.         
# The problem is that we might have been invoked as either scons.bat        
# or scons.py.  If we were invoked directly as scons.py, then we could     
# use sys.argv[0] to find the SCons "executable," but that doesn't work
# if we were invoked as scons.bat, which uses "python -c" to execute
# things and ends up with "-c" as sys.argv[0].  Consequently, we have
# the MSVS Project file invoke SCons the same way that scons.bat does,
# which works regardless of how we were invoked.

if 'MSVSSCONSFLAGS' not in env:
env['MSVSSCONSFLAGS'] = '-C "${MSVSSCONSCRIPT.dir.get_abspath()}" -f ${MSVSSCONSCRIPT.name}'

Expand Down