Making godot-cpp scons more idiomatic

[Ivorforce]

Godot version

4.4 (master)

godot-cpp version

4.4 (c20a84e)

System information

macOS

Issue description

Can you explain in more detail the problem you were having?

I've been having a bit of friction with how godot-cpp and its dependents (i.e. our recommended setup godot-cpp-template) interact. Specifically, I've been running into several problems trying to get a structure better structure for my SConstruct (and subsequently, contributing the changes to godot-cpp-template). It's a WIP.

I've found the SCons documentation not to be exhaustive, but I've been talking to SCons maintainers on Discord, who have been incredibly helpful in filling my missing pieces of knowledge.

Here's my latest gripe.

Custom options

When a godot-cpp dependent defines a new config option, godot-cpp complains about the new variable through these lines of code:

godot-cpp/SConstruct

Lines 37 to 41 in c20a84e

	unknown = opts.UnknownVariables()
	if unknown:
	print("WARNING: Unknown SCons variables were passed and will be ignored:")
	for item in unknown.items():
	print(" " + item[0] + "=" + item[1])

This is because arguments persist in ARGUMENTS, and godot-cpp finds and does not recognize them. This is confusing to the CLI user. We could remove the argument check, but then it would also be gone from godot-cpp's standalone use. I think using its SConstruct for both standalone and dependants is a bit of a split of two different interests, and may lead to more issues like this. Not to mention, it could be worth it to work toward better compartmentalization to eventually support dependency chains linking against each other.

Modularizing

SCons maintainers suggested not to use SConscript. SConscript is intented for sub-projects, rather than for dependencies (though arguably, godot-cpp is both). In their suggestion, godot-cppp's SConstruct would be used only to build it standalone, while its dependants would have their own SConstruct and call its tools explicitly. I do like this idea, because it favors modularity. Trying to implement it, however, I ran into several issues:

• toolpaths are wrong, because toolpath is relative to pwd, unless SConscript is used. This would be solvable by Move tools to site_scons/site_tools, which is the canonical scons tools directory. Pass env["toolpath"] down the tool chain in godotcpp.py. #1645.
• imports are wrong, because godot-cpp is not part of sys.path, unless SConscript is used. You can add godot-cpp to sys.path, but it's a bit awkward.
• source locations are wrong, because they are resolved relative to pwd, unless SConscript is used. This could be solved using __file__ as a base, and add the cpp files as absolute paths.

Depending on your viewpoint, you could interpret this as either

• "godot-cpp makes too many assumptions about pwd, and should more agnostic, or state / adopt its assumptions more explicitly."
• "just use SConscript, that avoids all these problems."

Anyway, without making any judgement calls just yet, I opted to experiment more to see if godot-cpp could actually be compartmentalized into a toolchain. But I thought #1645 would be relatively uncontentional, since it merely adapts what is the tooling standard of SCons (I should note here that the authors were specifically confused as to why godot-cpp's tools were not in site_tools but rather elsewhere).