-
-
Notifications
You must be signed in to change notification settings - Fork 593
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
GDExtension Bindings libraries built with SCons and CMake differ when built with MSVC #1459
Comments
As part of my work to modernise the cmake solution I have performed analysis on the actual command output of the build systems and there is dramatic variability between the cmake and the scons solution. See here for a comparison table. People who use CMake (myself included) expect that all of the transient dependencies to be defined in the projects they consume. So using a command like In the ideal scenario the consumed library(godot-cpp) is compiled and linked to your project as a build time dependency using the options you specify, not compiled separately and then linked. This is also the method scons uses, that is to build godot-cpp as part of your project, not separarely and then linked. I believe, that if my PR's get merged, then this issue will be solved. Just an FYI, Visual Studio is multi-config generator and ignores |
This issue is still relevant, the scons solution does not link to the MTd and MDd variants if debug symbols are enabled using dev_build. Which means that they arent interchangable at this moment, should I change the cmake code?or should I change the scons code? I'm thinking at this moment that I change the cmake to match the scons, and if its needed in the future then a flag can be introduced like the godot engine has in platforms/windows/detect.py:459 |
SCons does not link to /MDd or /MTd If needed in the future a flag can be introduced like the engine code at platforms/windows/detect.py:459
Per this comment from bruvzg, I think we update CMake to match scons (which is what it looks like your PR is doing) |
Thanks! |
Godot version
N/A
godot-cpp version
4.2.2 stable
System information
Windows 10
Issue description
Building the Godot-cpp Bindings via the provided SCons and CMake setups in Windows with MSVC result in
.lib
s with different configurations or at least built with different compiler flags. The SCons version seems to always have the/MT
flag set (for release and debug builds) and the CMake version the/MD
flag for release builds and the/MDd
flag for debug builds.This results in compile errors like
libgodot-cpp.windows.template_debug.x86_64.lib(error_macros.windows.template_debug.x86_64.obj) : error LNK2038: mismatch detected for 'RuntimeLibrary': value 'MT_StaticRelease' doesn't match value 'MDd_DynamicDebug' in gdexample.obj
when linking the bindings library built with SCons in debug with a GDExtension project that has not
/MT
explicitly set.Since in the CMake file
/MD
and/MDd
are explicitly set for release and debug builds respecivly, I assume this behaviour was not intended.Other compilers or OSs were not tested regarding this issue.
Steps to reproduce
Follow the instructions to get and build the Godot-Bindings and the GDExtension example from the C++ tutorial.
When both the bindings and the example are built with SCons it compiles without problem.
When using a
CMakeLists.txt
in the root directory liketo build the example with, compile errors like the one shown above should appear. Also when using
/MD
,/MDd
or/MTd
flags.When commenting in the
/MT
compiler flag, the errors are gone.When building the binding with CMake (debug build; as per example in the
CMakeLists.txt
in the bindings repository)and linking the resulting library with the GDExtension example (e.g. commenting out the SCons-
.lib
and commenting in the CMake-.lib
in myCMakeLists.txt
example) the errors appear only if the/MT
or/MTd
flags are set.This should show, that the bindings library configuration differs between the provided SCons and the CMake setups.
Minimal reproduction project
N/A
The text was updated successfully, but these errors were encountered: