Skip to content
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.

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

use_mingw="yes" not Honored in custom.py #60719

Open
bcsmith2846 opened this issue May 3, 2022 · 2 comments · May be fixed by #81700
Open

use_mingw="yes" not Honored in custom.py #60719

bcsmith2846 opened this issue May 3, 2022 · 2 comments · May be fixed by #81700

Comments

@bcsmith2846
Copy link

bcsmith2846 commented May 3, 2022

Godot version

4.0.dev (0275d60)

System information

Windows 10, MinGW, LLVM Build

Issue description

If I run scons in the shell without use_mingw=yes even when it's in my custom.py file, the build crashes. This seems to be due to the fact that the if statement in the SConstruct file (line 106 in the referenced hash) that is supposed to assign custom_tools to ["mingw"] is reading from the command line only. The assignment of custom_tools actually happens before custom.py is even read.

It also doesn't seem to be honoring the platform variable from custom.py for this one if statement either (because custom.py hasn't been loaded), but that's not causing an issue because the detection is working as intended (i.e. I'm not building for Android or JavaScript).

custom.py:

use_mingw = "yes"
use_llvm = "yes"
use_lto = "yes"
platform = "windows"
tools = "yes"
target = "debug"
verbose = "yes"

Relevant lines in SConstruct:

custom_tools = ["default"]

platform_arg = ARGUMENTS.get("platform", ARGUMENTS.get("p", False))

if os.name == "nt" and (platform_arg == "android" or methods.get_cmdline_bool("use_mingw", False)):
    custom_tools = ["mingw"]
elif platform_arg == "javascript":
    # Use generic POSIX build toolchain for Emscripten.
    custom_tools = ["cc", "c++", "ar", "link", "textfile", "zip"]

#............ BREAK .....................

customs = ["custom.py"]

profile = ARGUMENTS.get("profile", "")
if profile:
    if os.path.isfile(profile):
        customs.append(profile)
    elif os.path.isfile(profile + ".py"):
        customs.append(profile + ".py")

opts = Variables(customs, ARGUMENTS)

This is fairly simple to correct, but I wanted to get some feedback first in the case that there's a reason it is done this way.

Steps to reproduce

  1. Checkout 0275d60 on a Windows x64 host (targeting Windows x64)
  2. Create custom.py with the following text
use_mingw = "yes"
use_llvm = "yes"
use_lto = "yes"
platform = "windows"
tools = "yes"
target = "debug"
verbose = "yes"
  1. Ensure a mingw32/llvm environment is accessible to SCons
  2. Run scons without arguments and attempt a build
  3. Run scons use_mingw=yes to run a successful build

Minimal reproduction project

No response

@Lokno
Copy link

Lokno commented Jul 25, 2023

I ran into this same issue with the current version (#79851) helping someone try to compile for mingw. This might be part of a larger issue for any discrepancies between the command line arguments and what appears in custom.py

Specifically in the case of this flag, I don't think the build should fail. If anything, the use_mingw = "yes" in custom.py should be ignored after it has been read in SConstruct

To ignore the custom.py value we could do the same thing that is being done with selected_platform. Let's refer to this as the correction strategy.

platform_arg = ARGUMENTS.get("platform", ARGUMENTS.get("p", False))
use_mingw_arg = methods.get_cmdline_bool("use_mingw", False)

if platform_arg == "android":
    custom_tools = ["clang", "clang++", "as", "ar", "link"]
elif platform_arg == "web":
    # Use generic POSIX build toolchain for Emscripten.
    custom_tools = ["cc", "c++", "ar", "link", "textfile", "zip"]
elif os.name == "nt" and use_mingw_arg:
    custom_tools = ["mingw"]

...

# Update the environment to take platform-specific options into account.
opts.Update(env_base)
env_base["platform"] = selected_platform  # Must always be re-set after calling opts.Update().
env_base["use_mingw"] = use_mingw_arg     # Must always be re-set after calling opts.Update().

Note that opts.Update(env_base) is called multiple times within the file.

Another option would be to add the evaluated argument to ARGUMENTS

platform_arg = ARGUMENTS.get("platform", ARGUMENTS.get("p", False))
ARGUMENTS.update({"use_mingw": str(methods.get_cmdline_bool("use_mingw", False))})

However, the user should be informed that their setting in custom.py is being override because its not at the command line. Using the correction strategy, we can detect the discrepancy and report:

# Update the environment to take platform-specific options into account.
opts.Update(env_base)
env_base["platform"] = selected_platform  # Must always be re-set after calling opts.Update().
if use_mingw_arg != env_base["use_mingw"]:
    env_base["use_mingw"] = use_mingw_arg
    print(f'Warning: Value for "use_mingw" defined in custom.py ignored. Please set this flag via the commandline')

This is only an example of how it could be handled. It would be better to write something more general for any flags assumed to be command line only.

shana added a commit to shana/godot that referenced this issue Sep 15, 2023
…ingw

Let the platforms optionally override the default build tools with a
`get_custom_tools` method, so the default SConstruct only needs to set the
defaults and not worry about each individual platform requirements.

Fix the order of initialization, so we can pick up the use_mingw option
from all the different places where it can be set, and use it during
environment initialization.

This also fixes a related issue where, if a platform sets a default target
in `get_flags`, if the platform doesn't support the `editor` target, and the user
doesn't pass in the target in the command line, the `editor` target would be
briefly selected during a portion of SConstruct execution, just long enough
for some wrong variables to be set, and cause the build to fail, or include
bad defines.

Fixes godotengine#60719
shana added a commit to shana/godot that referenced this issue Sep 15, 2023
… user overrides of use_mingw

Let the platforms optionally override the default build tools with a
`get_custom_tools` method, so the default SConstruct only needs to set the
defaults and not worry about each individual platform requirements.

Fix the order of initialization, so we can pick up the use_mingw option
from all the different places where it can be set, and use it during
environment initialization.

This also fixes a related issue where, if a platform sets a default target
in `get_flags`, if the platform doesn't support the `editor` target, and the user
doesn't pass in the target in the command line, the `editor` target would be
briefly selected during a portion of SConstruct execution, just long enough
for some wrong variables to be set, and cause the build to fail, or include
bad defines.

Fixes godotengine#60719
shana added a commit to shana/godot that referenced this issue Sep 15, 2023
… user overrides of use_mingw

Let the platforms optionally override the default build tools with a
`get_custom_tools` method, so the default SConstruct only needs to set the
defaults and not worry about each individual platform requirements.

Fix the order of initialization, so we can pick up the use_mingw option
from all the different places where it can be set, and use it during
environment initialization.

This also fixes a related issue where, if a platform sets a default target
in `get_flags`, if the platform doesn't support the `editor` target, and the user
doesn't pass in the target in the command line, the `editor` target would be
briefly selected during a portion of SConstruct execution, just long enough
for some wrong variables to be set, and cause the build to fail, or include
bad defines.

Fixes godotengine#60719
shana added a commit to shana/godot that referenced this issue Sep 15, 2023
… user overrides of use_mingw

Let the platforms optionally override the default build tools with a
`get_custom_tools` method, so the default SConstruct only needs to set the
defaults and not worry about each individual platform requirements.

Fix the order of initialization, so we can pick up the use_mingw option
from all the different places where it can be set, and use it during
environment initialization.

This also fixes a related issue where, if a platform sets a default target
in `get_flags`, if the platform doesn't support the `editor` target, and the user
doesn't pass in the target in the command line, the `editor` target would be
briefly selected during a portion of SConstruct execution, just long enough
for some wrong variables to be set, and cause the build to fail, or include
bad defines.

Fixes godotengine#60719
shana added a commit to shana/godot that referenced this issue Sep 15, 2023
… user overrides of use_mingw

Let the platforms optionally override the default build tools with a
`get_custom_tools` method, so the default SConstruct only needs to set the
defaults and not worry about each individual platform requirements.

Fix the order of initialization, so we can pick up the use_mingw option
from all the different places where it can be set, and use it during
environment initialization.

This also fixes a related issue where, if a platform sets a default target
in `get_flags`, if the platform doesn't support the `editor` target, and the user
doesn't pass in the target in the command line, the `editor` target would be
briefly selected during a portion of SConstruct execution, just long enough
for some wrong variables to be set, and cause the build to fail, or include
bad defines.

Fixes godotengine#60719
shana added a commit to shana/godot that referenced this issue Oct 5, 2023
… user overrides of use_mingw

Let the platforms optionally override the default scons environment tools
via a `custom_tools` flag, so the default SConstruct only needs to set the
defaults and not worry about each individual platform requirements.
Users can also override the tools via a `custom_tools` option.

Fix the order of initialization, so we can pick up the use_mingw option
from all the different places where it can be set, and use it during
environment initialization.

This also fixes a related issue where, if a platform sets a default target
in `get_flags`, if the platform doesn't support the `editor` target, and the user
doesn't pass in the target in the command line, the `editor` target would be
briefly selected during a portion of SConstruct execution, just long enough
for some wrong variables to be set, and cause the build to fail, or include
bad defines.

Fixes godotengine#60719
shana added a commit to shana/godot that referenced this issue Oct 12, 2023
… user overrides of use_mingw

Let the platforms optionally override the default scons environment tools
via a `custom_tools` flag, so the default SConstruct only needs to set the
defaults and not worry about each individual platform requirements.
Users can also override the tools via `custom_tools`.

Fix the order of initialization, so we can pick up the use_mingw option
from all the different places where it can be set, and use it during
environment initialization.

This also fixes a related issue where, if a platform sets a default target
in `get_flags`, if the platform doesn't support the `editor` target, and the user
doesn't pass in the target in the command line, the `editor` target would be
briefly selected during a portion of SConstruct execution, just long enough
for some wrong variables to be set, and cause the build to fail, or include
bad defines.

Fixes godotengine#60719
shana added a commit to shana/godot that referenced this issue Oct 12, 2023
… user overrides of use_mingw

Let the platforms optionally override the default scons environment tools
via a `custom_tools` flag, so the default SConstruct only needs to set the
defaults and not worry about each individual platform requirements.
Users can also override the tools via `custom_tools`.

Fix the order of initialization, so we can pick up the use_mingw option
from all the different places where it can be set, and use it during
environment initialization.

This also fixes a related issue where, if a platform sets a default target
in `get_flags`, if the platform doesn't support the `editor` target, and the user
doesn't pass in the target in the command line, the `editor` target would be
briefly selected during a portion of SConstruct execution, just long enough
for some wrong variables to be set, and cause the build to fail, or include
bad defines.

Fixes godotengine#60719
shana added a commit to shana/godot that referenced this issue Oct 12, 2023
… user overrides of use_mingw

Let the platforms optionally override the default scons environment tools
via a `custom_tools` flag, so the default SConstruct only needs to set the
defaults and not worry about each individual platform requirements.
Users can also override the tools via `custom_tools`.

Fix the order of initialization, so we can pick up the use_mingw option
from all the different places where it can be set, and use it during
environment initialization.

This also fixes a related issue where, if a platform sets a default target
in `get_flags`, if the platform doesn't support the `editor` target, and the user
doesn't pass in the target in the command line, the `editor` target would be
briefly selected during a portion of SConstruct execution, just long enough
for some wrong variables to be set, and cause the build to fail, or include
bad defines.

Fixes godotengine#60719
shana added a commit to shana/godot that referenced this issue Oct 12, 2023
… user overrides of use_mingw

Let the platforms optionally override the default scons environment tools
via a `custom_tools` flag, so the default SConstruct only needs to set the
defaults and not worry about each individual platform requirements.
Users can also override the tools via `custom_tools`.

Add a temporary SCons environment to only process `use_mingw`, `platform`,
`target` and `custom_tools` options from all the different places where
they can be set, and then use those values to initialize the actual
environment that we use to build, as well as determine which builder scripts
to load based on the target.

This fixes a related issue where, if a platform sets a default target
in `get_flags` different from editor, and the user doesn't pass in the
target in the command line, the `editor` target would be briefly selected
during a portion of SConstruct execution, just long enough for some wrong
variables to be set, and cause the build to fail, or include bad defines.

Fixes godotengine#60719
shana added a commit to shana/godot that referenced this issue Oct 12, 2023
… user overrides of use_mingw

Let the platforms optionally override the default scons environment tools
via a `custom_tools` flag, so the default SConstruct only needs to set the
defaults and not worry about each individual platform requirements.
Users can also override the tools via `custom_tools`.

Fix the order of initialization, so we can pick up the use_mingw option
from all the different places where it can be set, and use it during
environment initialization.

This also fixes a related issue where, if a platform sets a default target
in `get_flags`, if the platform doesn't support the `editor` target, and the user
doesn't pass in the target in the command line, the `editor` target would be
briefly selected during a portion of SConstruct execution, just long enough
for some wrong variables to be set, and cause the build to fail, or include
bad defines.

Fixes godotengine#60719
shana added a commit to shana/godot that referenced this issue Oct 12, 2023
…bey overrides of use_mingw

Let the platforms optionally override the default scons environment tools
via a `custom_tools` flag, so the default SConstruct only needs to set the
defaults and not worry about each individual platform requirements.
Users can also override the tools via `custom_tools`.

Add a temporary SCons environment to only process `use_mingw`, `platform`,
`target` and `custom_tools` options from all the different places where
they can be set, and then use those values to initialize the actual
environment that we use to build, as well as determine which builder scripts
to load based on the target.

This fixes a related issue where, if a platform sets a default target
in `get_flags` different from editor, and the user doesn't pass in the
target in the command line, the `editor` target would be briefly selected
during a portion of SConstruct execution, long enough to set the
env.editor_build to true, causing editor files and defines to be set
for non-editor builds.

Fixes godotengine#60719
shana added a commit to shana/godot that referenced this issue Oct 12, 2023
…bey overrides of use_mingw

Let the platforms optionally override the default scons environment tools
via a `custom_tools` flag, so the default SConstruct only needs to set the
defaults and not worry about each individual platform requirements.
Users can also override the tools via `custom_tools`.

Add a temporary SCons environment to only process `use_mingw`, `platform`,
`target` and `custom_tools` options from all the different places where
they can be set, and then use those values to initialize the actual
environment that we use to build, as well as determine which builder scripts
to load based on the target.

This fixes a related issue where, if a platform sets a default target
in `get_flags` different from editor, and the user doesn't pass in the
target in the command line, the `editor` target would be briefly selected
during a portion of SConstruct execution, long enough to set the
env.editor_build to true, causing editor files and defines to be set
for non-editor builds.

Fixes godotengine#60719
shana added a commit to shana/godot that referenced this issue Oct 12, 2023
…bey overrides of use_mingw

Let the platforms optionally override the default scons environment tools
via a `custom_tools` flag, so the default SConstruct only needs to set the
defaults and not worry about each individual platform requirements.
Users can also override the tools via `custom_tools`.

Add a temporary SCons environment to only process `use_mingw`, `platform`,
`target` and `custom_tools` options from all the different places where
they can be set, and then use those values to initialize the actual
environment that we use to build, as well as determine which builder scripts
to load based on the target.

This fixes a related issue where, if a platform sets a default target
in `get_flags` different from editor, and the user doesn't pass in the
target in the command line, the `editor` target would be briefly selected
during a portion of SConstruct execution, long enough to set the
env.editor_build to true, causing editor files and defines to be set
for non-editor builds.

Fixes godotengine#60719
@shana
Copy link
Contributor

shana commented Oct 12, 2023

#81700 should fix this issue (along with others), so for people running into this, if you could give that PR a try, that would be great!

adamscott added a commit to adamscott/godot that referenced this issue Apr 1, 2024
…bey overrides of use_mingw

Let the platforms optionally override the default scons environment tools
via a `custom_tools` flag, so the default SConstruct only needs to set the
defaults and not worry about each individual platform requirements.
Users can also override the tools via `custom_tools`.

Add a temporary SCons environment to only process `use_mingw`, `platform`,
`target` and `custom_tools` options from all the different places where
they can be set, and then use those values to initialize the actual
environment that we use to build, as well as determine which builder scripts
to load based on the target.

This fixes a related issue where, if a platform sets a default target
in `get_flags` different from editor, and the user doesn't pass in the
target in the command line, the `editor` target would be briefly selected
during a portion of SConstruct execution, long enough to set the
env.editor_build to true, causing editor files and defines to be set
for non-editor builds.

Fixes godotengine#60719

Co-authored-by: Adam Scott <ascott.ca@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: In progress / Assigned
Development

Successfully merging a pull request may close this issue.

5 participants