godot-cpp icon indicating copy to clipboard operation
godot-cpp copied to clipboard

Add SCons variant_dir support

Open Ivorforce opened this issue 11 months ago • 4 comments

Supersedes #1439 - it's basically just a rebase. It compiles, but I haven't checked if it does what it says it does (allow godot-cpp to be included from elsewhere).

Ivorforce avatar Dec 10 '24 15:12 Ivorforce

Alright, code wise, I think this is ready now. I still haven't tested it though. Someone should probably do that before a merge (i may, but it may take a few more days).

Ivorforce avatar Dec 18 '24 14:12 Ivorforce

Alright, I tested this, it seems to work.

To use it, one has to call SConscript like env = SConscript("../SConstruct", variant_dir="build_folder"). I tested this from the test project.

Ivorforce avatar Jan 29 '25 18:01 Ivorforce

To use it, one has to call SConscript like env = SConscript("../SConstruct", variant_dir="build_folder"). I tested this from the test project.

I tested this in the same way and it worked for me!

However, shouldn't this be an option given on the command-line, rather than something that developers hard-code into their project? Why not add this to other default options?

Also, this only seemed to affect the build artifacts from godot-cpp itself, and not the test project. What do developers need to do so that their artifacts also build in a separate directory?

dsnopek avatar Feb 18 '25 15:02 dsnopek

However, shouldn't this be an option given on the command-line, rather than something that developers hard-code into their project? Why not add this to other default options? Also, this only seemed to affect the build artifacts from godot-cpp itself, and not the test project. What do developers need to do so that their artifacts also build in a separate directory?

This would be possible! I tested this as well, and arrived at this solution:

  • Add a variant_dir command line option
  • Call the VariantDir function with the appropriate value, if passed
  • Compile <variant_dir>/* instead of src/* in godotcpp.py (or analogously, the user SConstruct)

As you observed, applying variant_dir godot-cpp side would only move godot-cpp object files, so the option would need to be added on the user side (godot-cpp-template?).

Ivorforce avatar Feb 18 '25 16:02 Ivorforce

We might want to add something like:

diff --git a/test/SConstruct b/test/SConstruct
index b949bca..20f62b1 100644
--- a/test/SConstruct
+++ b/test/SConstruct
@@ -1,6 +1,6 @@
 #!/usr/bin/env python
 
-env = SConscript("../SConstruct")
+env = SConscript("../SConstruct", variant_dir=ARGUMENTS.get("variant_dir", None))
 
 # For the reference:
 # - CCFLAGS are compilation flags shared between C and C++

to the test SConstruct, or the cpp-template so people can "guess" how to use this feature.

But it isn't really important for this PR right now, so let's not block it for this.

Faless avatar Jul 03 '25 14:07 Faless

Thanks!

dsnopek avatar Jul 03 '25 17:07 dsnopek

After this change, custom_api_file isn't working for me. This PR added converter=normalize_path for this option, but it still seems to be looking for the file relative to the "godot-cpp" directory, rather than relative to the directory where scons was run which is at a higher-level for my extension

Also, there's a bunch of options that take paths, that don't have the converter=normalize_path, for example: build_profile, compiledb_file, custom_tools. Shouldn't these also have the converter (assuming it actually worked)?

dsnopek avatar Jul 17 '25 02:07 dsnopek

I think this is a SCons version thing. I normally use SCons 4.0.1, because that's what comes with my distro (Ubuntu 22.04). I tried updating to SCons 4.9.1 via pip, and then this seemed to work fine.

We still have EnsureSConsVersion(4, 0) in our SConstruct. We should either rework this to work for SCons 4.0+, or update our version requirement

dsnopek avatar Jul 17 '25 02:07 dsnopek

After this change, custom_api_file isn't working for me. This PR added converter=normalize_path for this option, but it still seems to be looking for the file relative to the "godot-cpp" directory, rather than relative to the directory where scons was run which is at a higher-level for my extension

Hrm, I suppose that means normalize_path has to be fixed? I'm a bit surprised by that since the function hasn't been touched. Perhaps just a SCons bug?

We still have EnsureSConsVersion(4, 0) in our SConstruct. We should either rework this to work for SCons 4.0+, or update our version requirement

If SCons comes with 22.04 Ubuntu, it would be unfortunate to increase the minimum requirement beyond that. I'd rather work around the issue for the moment if it's a SCons bug.

Also, there's a bunch of options that take paths, that don't have the converter=normalize_path, for example: build_profile, compiledb_file, custom_tools. Shouldn't these also have the converter (assuming it actually worked)?

Personally, I think so. Assuming we get it to work as intended anyway.

Ivorforce avatar Jul 17 '25 09:07 Ivorforce

@Ivorforce I just posted https://github.com/godotengine/godot-cpp/pull/1819 which fixes this for me

Hrm, I suppose that means normalize_path has to be fixed? I'm a bit surprised by that since the function hasn't been touched. Perhaps just a SCons bug?

In some further testing, it looks like normalize_path() works as expected, but it's the converter=... bit that doesn't do its thing correctly. Seems like a SCons bug that was later fixed

Also, there's a bunch of options that take paths, that don't have the converter=normalize_path, for example: build_profile, compiledb_file, custom_tools. Shouldn't these also have the converter (assuming it actually worked)?

Personally, I think so. Assuming we get it to work as intended anyway.

Well, it seems we can't rely on converter=... if we're going to support SCons 4.0.1, so we'll have to leave those as they are (which call normalize_path() manually)

dsnopek avatar Jul 17 '25 14:07 dsnopek

Cherry-picked for 4.4 in PR https://github.com/godotengine/godot-cpp/pull/1836

dsnopek avatar Aug 21 '25 13:08 dsnopek