We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

Bug 2830 - Improve CMake support for MinGW
Summary: Improve CMake support for MinGW
Status: ASSIGNED
Alias: None
Product: SDL
Classification: Unclassified
Component: build (show other bugs)
Version: 2.0.3
Hardware: x86 Windows Vista
: P2 enhancement
Assignee: Ryan C. Gordon
QA Contact: Sam Lantinga
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-12-30 14:01 UTC by DarioOO
Modified: 2017-08-14 01:02 UTC (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description DarioOO 2014-12-30 14:01:08 UTC
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) :(
Comment 1 DarioOO 2014-12-30 14:05:17 UTC
actually the DLL created by MinGW using CMake is 4 MBs (really big compared to the 300 kb of the VS counterpart)