-
-
Notifications
You must be signed in to change notification settings - Fork 21.1k
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
Move most "drivers" as toggleable "modules" and split their thirdparty libraries in an own tree #6830
Conversation
Alright, as expected it doesn't build out of the box :) Should have tried to remove some system headers to ensure built-in libraries are ok. It looks like having made the ogg module build in its own env hid it for theora/vorbis/opus which need it, will fix. |
Uses the new structure agreed upon in godotengine#6157, but the thirdparty/ folder does not behave following a logic similar to that of modules/ yet. The png driver can't be moved to a module as discussed in godotengine#6157, as it's required by core together with a few other ImageLoader implementations (see drivers/register_driver_types.cpp:register_core_driver_types()) Dropped the possibility to disable PNG support, it's a core component of Godot.
Similar rationale as in previous commit.
Building against shared libraries only implemented for Linux X11 so far. TODO: Document Godot's modifications of upstream enet.
They are not particularly packaged in Linux distros so we do not facilitate unbundling via SCons. There could be done if/when there is interest. Also s/pnm/pbm/, long-lived typo :)
Note that there are two Godot-specific changes made to libwebp for the javascript/HTML5 platform. They are documented in the README.md.
Took the opportunity to undo the Godot changed made to the opus source. The opus module should eventually be built in its own environment to avoid polluting others with too many include dirs and defines. TODO: Fix the platform/ stuff for opus.
Same rationale as the previous commits.
This allows to pass include paths and flags only to a given thirdparty library, thus preventing conflicts between their files (e.g. between opus and openssl which both provide modes.h. This also has the nice effect of making the compilation command smaller for each module as it no longer related to all other modules, only the final linking brings them together. This however requires adding manually the ogg include path in opus and vorbis when building against the builtin ogg, since it is no longer in the global env. Also simplified template 'thirdparty_<module>_sources' to 'thirdparty_sources'. "Core" modules like cscript, gdscript, gridmap, ik and virtual_script still use the main env_modules, but it could be changed if need be.
Same rationale as the previous commits.
Rebased to fix a few things:
|
Sources are untouched, tarball from https://sourceforge.net/projects/libsquish
Not fully happy about the way this one interacts with the various platforms. Maybe the platform_config.h should be generated by the SCsub instead of passing a define just to know where is the header.
c812d06
to
0fcb765
Compare
5239d6b
to
91448b6
Compare
After a few hours of trial and error, it seems like it now builds fine for all platforms on our travis tests. I'd love to have people testing the PR on Windows though, both using MSVC and MinGW. |
Comment out the weird workaround for building on Windows at it might not be needed anymore. Testing needed to confirm.
The reordering of the SConscript includes allows to ensure that stuff like the builtin zlib headers will be available for libpng. Also moved glew back into global env, otherwise windows seems not to find it... Kind of shooting in the dark with this multi-env setup.
Fixed a wrong include path for winrt. According to @vnen it now builds fine with MSVC for both windows and winrt. |
I'm testing a build of all templates using this PR: https://travis-ci.org/GodotBuilder/godot-builds/builds/167937894 https://ci.appveyor.com/project/GodotBuilder/godot-builds/build/1.0.90 In parallel, I'm also building the current master branch for comparison: https://travis-ci.org/GodotBuilder/godot-builds/builds/167937619 https://ci.appveyor.com/project/GodotBuilder/godot-builds/build/1.0.89 |
It built properly on all platforms (apart from javascript which is timing out, but same for current master, and OSX which has timed out while master managed to build in timeout - 2 min :D). I'd propose to merge now that we know that it doesn't introduce big buildsystem regressions, and then fix issues as they come (as there should probably be a couple ones along the way). |
(Actually I finally got the javascript build to fail, but it looks like emscripten is going crazy: https://travis-ci.org/GodotBuilder/godot-builds/jobs/167937903) Edit: Same issues for the master branch, it's just random. Will have to investigate more for official binaries, but it shouldn't stop this PR. |
|
@zaps166 Yes to both. For the former I have no clue about it, but please make a PR :). For the latter, I also thought about it and had no strong opinion for either way, but yes I think it would likely be best to put the |
@akien-mga Ok, so maybe I'll try later :) |
Should address most of #6157.
While working on this, I got a bit more scons experience and could isolate most modules (and some of the remaining drivers) in their own environment, which means that their necessary defines and include paths can now be passed without polluting the global env. It means we could drop some dirty hacks we put in several thirdparty sources to hardcode include paths so that they match our repo, etc. There is also no more risk of confusion between headers of different projects that share the same name.
Most libraries that are typically available on a Linux distribution can be unbundled (i.e. you can just delete their
thirdparty/$libname
folder and build withlibname=system
). Some more work will be needed to put some order in the scons options as it's a bit messy now, but I'll do all this in a later PR. Currently onlyplatform/x11
has instructions to link against system libraries whensystem
options are chosen, but it could be extended for other relevant platforms.To disable a module, the syntax is now automatic:
module_$module_enable=yes|no
(seescons --help
). We might have to document this a bit better in the official compilation docs, and also rename the current arguments I used to specify the use of builtin or system libraries for more clarity (e.g.openssl=system
could becomesystem_openssl=yes
orbuiltin_openssl=no
.All in all, this was quite a lot of work and I might have made a few mistakes along the road. Therefore I'd appreciate:
That should be a first step towards making it much easier to maintain our thirdparty code, and also to get Godot packaged in Linux distributions.