SCons: Warn user about unrecognized options

[dustdfg]

• Supersedes Warn user about unrecognized or misspelled builtin_* options #98298
• Supersedes SCons: Warn when passing unknown variables #91213

I couldn't wait anymore because bugs are painful...

I glued parts of two PR's and added some logic to recognize valid options but defined for other platforms:

• SCons: Refactor profile option for custom.py-style overrides #91794
• SCons: Warn when passing unknown variables #91213

Do you need any explanations? It is just bunch of spaghetti which works and will work pretty good because here we almost fully control what happens and can workaround SCons bugs... Here also some minor bug fixes: use already present platform_name variable, delete unnecessary check isdir, add some undeclared options

# custom.py

custom_hh="hate_scons"
builtin_hh="hate_scons"
hh="hate_scons"

silence_msvc="hate_scons"
osxcross_sdk="hate_scons"

target="editor"

Runned command: scons hh="hate_scons_twice" custom_hh="hate_scons_twice" p="web"

Result:

WARNING: Unknown SCons variables were passed and will be ignored:
	custom_hh = hate_scons_twice
	builtin_hh = hate_scons
	hh = hate_scons_twice 
WARNING: Following SCons variables aren't defined for web but defined for macos and will be ignored:
	osxcross_sdk = hate_scons 
WARNING: Following SCons variables aren't defined for web but defined for windows and will be ignored:
	silence_msvc = hate_scons 

[dustdfg]

And yeah user_args is a silver buller for 3-4 issues but tbh I can't recall them now

[Repiteo]

While I'm pretty sure this can be further refined, I'm not about to look a gift horse in the mouth. This'll make for a MUCH more convenient jumping-off point in any case.

[dustdfg]

Rebased and solved merge blocking conflict. No functional changes

[Calinou]

Should be good to merge after applying suggestions.

[dustdfg]

Calinou suggestions + rebase. Nothing else

[dustdfg]

Why p is in the list? SCons have a bug. If key is an alias, you can't determine if key is a valid option without relying on internals :/

I am already not sure about use_static_cpp. Pushed too early... Need to investigate further

EDIT: Looks like I fully messed up with use_static_cpp and it was another issue caused by side effect of one of my experiments

[dustdfg]

@akien-mga I know you are busy so sorry for ping but just want to make sure it wasn't lost in void

[dustdfg]

I am not going to do anything to update this PR. But it is not bad in IMO so I am not closing it... Over time some merge conflicts can occur... There are people with "write access" so if you need it you can correct it. I am abandoning this PR... If you want close it

---

I generally want this to be merged but if you will do it, do it on your own risk. I won't do anything if there is any new bugs will be introduced or anything else...

[dustdfg]

Github send me notification so I am here 😅. Looks like I can abandon anything except this PR 😅.

---

@Repiteo I saw your PR and it is great but it would be a mistake. Why? Because as I mentioned somewhere in this PR user_args is a silver bullet for several places. It is not a first time we need to know if it is a user provided argument or not... Just look at original akien's PR: #91794. There we need user_flags to determine if we can or cannot override value from platform_args. We just need user_args anyway. Additionally look at this code:

godot/SConstruct

Lines 595 to 609 in d09d82d

	# 'dev_mode' and 'production' are aliases to set default options if they haven't been
	# set manually by the user.
	if env["dev_mode"]:
	env["verbose"] = methods.get_cmdline_bool("verbose", True)
	env["warnings"] = ARGUMENTS.get("warnings", "extra")
	env["werror"] = methods.get_cmdline_bool("werror", True)
	env["tests"] = methods.get_cmdline_bool("tests", True)
	env["strict_checks"] = methods.get_cmdline_bool("strict_checks", True)
	if env["production"]:
	env["use_static_cpp"] = methods.get_cmdline_bool("use_static_cpp", True)
	env["debug_symbols"] = methods.get_cmdline_bool("debug_symbols", False)
	if platform_arg == "android":
	env["swappy"] = methods.get_cmdline_bool("swappy", True)
	# LTO "auto" means we handle the preferred option in each platform detect.py.
	env["lto"] = ARGUMENTS.get("lto", "auto")

Write in custom.py verbose="no" and run scons dev_mode="yes" and you will see it is still verbose... If you run scons dev_mode="yes" verbose="no", it will work as expected. But it can be tackled by replacing usage of ARGUMENTS with user_args... And it is not the end there are some more placer where user_args will be helpful. Though can't say that for other places user_args is the only option but in some places it could easier life... So while I agree that that conditional scons > (4.8.1) is more native to SCons, I don't agree we need to choose that way (but I agree that we need to add comment that from 4.8.1 scons supports unknown variables from files...)