| Summary: | Improve CMake support for MinGW | ||
|---|---|---|---|
| Product: | SDL | Reporter: | DarioOO <oliveridario89> |
| Component: | build | Assignee: | Ryan C. Gordon <icculus> |
| Status: | ASSIGNED --- | QA Contact: | Sam Lantinga <slouken> |
| Severity: | enhancement | ||
| Priority: | P2 | CC: | oliveridario89 |
| Version: | 2.0.3 | ||
| Hardware: | x86 | ||
| OS: | Windows Vista | ||
actually the DLL created by MinGW using CMake is 4 MBs (really big compared to the 300 kb of the VS counterpart) |
I know you are doing a hard work to support many build systems, maybe this is just more a todolist, but I provided it because I'm focused only on CMake, so I hope I could help spotted something you may missed having to focus on many toolchains. Actually building SDL2 with supported CMake platforms is trivial (even with MinGW), just setup some path in the environment and call Cmake (full example on SDL forum), however there are several issues in the build system currently that could improve usability ( since Cmake is almost a "1 click and get it", many users could benefit from that, I see to much people using alternative frameworks just because don't know hot to compile SDL with MinGW): 1) reduce number of Cache variables. - compilers already generate good assembly for specific target architectures, but almost all assemblies can be configured at toolchain level (especially buildling for mobile like Android), so no need for all those Cache variables regarding assembly, SDL could autodetect, and eventually show a warning/message when compiling using specific extensions, but having variables for that is just "Global namespace pollution" 2) improve description of cache variables - Give a more in depth knowledge on what each variable is doing (in example "SSE: enable optimizations that target SSE capable processors and thus make your binary not compatible for processors that don't have SSE features). 3) reduce executable size. - I have various guess about how it get so big 4) prefix all cache variables with "SDL" or "SDL2", this is a important change, because when configuring using cmake-gui in complex projects you get SDL related stuff sorted alphabetically and hence grouped and separed from options of other projects (by the way I never use cmake-gui, but for some people that may be important!) 5) I tried to force "Release" build (CMAKE_BUILD_TYPE). but seems SDL is doing what he wants :D 6) reduce compile time: with unity build it becomes few seconds instead of 5 minutes (there are already scripts for that, and I'm using it in every my project) A good Cmake project should just provide - Few compile options (in example: subsystems to include, shared or static) - customize default build targets (Release, Debug, Profile, Test), users set CMAKE_BUILD_TYPE, then SDL knows wich flags are best -Release: most optimized (you know where optimize for size and where for speed -Debug: no or few optimization and debug symbols -Profile: optimized but with symbols for profiler -Test: only used for automated unit-testing it just avoid to hide symbols so that also internal functionality can be accessed and tested. (I do automated unit testing with "Test" target while integration testing with "Debug" target) All other stuff, like where to find compiler, wich IDE target and native target is already setted externally (path to compilers or eventually a toolchain file for most complex platforms like Android, but that is stuff that should be SDL-agnostic). This way SDL could be easily integrated in complex project toolchains (so instead of "pre-buildling SDL" you automatically build it for each platform where is needed) it reduces a lot manual building and allows to further automated reducing chance for human errors and reducing iteration time. I'd really like to give a more in depth help, or also provide a patch for CMake, but actually I know so few about SDL (just used it as API I don't know internals) :(