Expose more Ninja-related build options
I've been testing out the ninja=yes build option (introduced in #89452) and found myself wanting a little bit more control out of it.
Instead of it always generating a build.ninja file regardless of build options, forcing me to run SCons whenever I want to switch said build options, it would be nice if you could have multiple Ninja files. As it turns out, this is already supported by SCons through the NINJA_FILE_NAME construction variable, so this PR adds a build option (ninja_file) to set that variable.
I also noticed that the setting of the disable_execute_ninja option that's currently happening does not seem to work at all for me (on Windows with SCons 4.8.0). Ninja will always run after SCons has run, as opposed to just emitting the Ninja file and stopping. This is contrary to what the documentation states, but the documentation also mentions this other construction variable called NINJA_DISABLE_AUTO_RUN that serves the same purpose. That one does work for me, for some reason, so this PR switches to use that instead. I also threw in a build option to control it, rather than effectively hardcoding it to false like before, which seemed like it might be useful to anyone who wants to use Ninja but doesn't want to run it separately all the time.
I should also mention that I am relatively new to SCons, so I could be misunderstanding how these construction environments/variables work, or whether it's even appropriate to be setting them like this. If there's some way of injecting these NINJA_FILE_NAME and NINJA_DISABLE_AUTO_RUN construction variables from the system environment I'd love to know.
I'd be curious to hear your take on this, @Riteo, given that you authored the original ninja option.
@mihe thank you for letting me know about this PR! Yeah, that disable_execute_ninja part is weird. On 4.6.0 it worked fine. I just updated to your version and it now does not work. I wonder if that's a bug :/
That said, your approach works fine indeed! I think that setting the construction variables themselves is fine, as there's really no other way of doing that, from what I can tell. SCons makes sure to not import anything from the external environment by default as it might create too much variability.
If there's some way of injecting these NINJA_FILE_NAME and NINJA_DISABLE_AUTO_RUN construction variables from the system environment I'd love to know.
You could check for os.environ and set it from there, although I'm not sure that would be terribly useful, since there's very little stuff that reads the environment in the main SConstruct file in the first
I dug up the manual to double-check things and I think that this chapter might also be useful for you: https://scons.org/doc/production/HTML/scons-user/ch07.html
Yeah, that
disable_execute_ninjapart is weird. On 4.6.0 it worked fine. I just updated to your version and it now does not work. I wonder if that's a bug :/
See #94993 and #94805.
SCons makes sure to not import anything from the external environment by default as it might create too much variability.
Right, yeah, I can understand that, with it being focused on reproducible builds and whatnot. Having it implicitly read from the system environment was indeed what I was mostly interested in. I don't see much point in explicitly using os.environ over these new options, I guess.
See https://github.com/godotengine/godot/pull/94993 and https://github.com/godotengine/godot/issues/94805.
I actually tried from HEAD with this change already in and it does not work still :gdsweat:
See #94993 and #94805.
I actually tried from HEAD with this change already in and it does not work still :gdsweat:
Yeah I meant this change might have broken the behavior, despite being suggested by a SCons upstream maintainer.
Thanks!