Review of Project GoalsIn review, my goals were as follows:
- Create a meta-build system that allows for simple generation of methods to build SDL2 on different platforms
- Replicate as much of the SDL2 build process as possible
- Keep the meta-build system portable and lightweight
- Make sure extending it as simple as can be, for future parts added to the project
Given my goals, I feel I accomplished all of them in one way or another. The following is a list of accomplishments from my perspective (development perspective):
- The meta-build system provides a method of rapidly and conveniently generating new projects related to the SDL2 build tree (such as a new test or SDL2 library)
- Provides a cross-platform way to generate various SDL2 build methods using the same meta-build interface (everything runs through premake4.lua for MinGW, Windows, Linux, Mac OS X, and Xcode)
- It provides the possibility of as complex dependency checking as CMake or Autotools with cross-platform convenience of Premake (with some tweaking, of course)
- It provides tested capabilities of generating GNU Makefiles; Visual Studio C++ (2008, 2010, and 2012) project and solution files; and Xcode (3 and 4) project and workspace environments
Features Support (Final)
The Premake project supports the following:
- Cross-platform project and solution generation for various operating systems and build environments
- Build environments include GNU Make (MinGW/Cygwin/Linux); Xcode 3 and 4 (both OS X and iOS); and Visual Studio 2008, 2010, and 2012 (Windows)
- Supported operating systems include Windows, Mac OS X, and Linux, with side targets for MinGW and iOS
- Support for building the SDL2 library and the side SDL2main and SDL2test libraries
- Support for building all of the projects in the test suite implemented at the time of this project
- Support for building all of the iOS demo projects
- Partial Cygwin support
- Interface for implementing CMake and Autotool-esque dependency checking routines (slightly demonstrated in the SDL2 project targeted at Linux)
As a reflection, I've noted many things that have gone wrong with this project, or just varied significantly from the original vision. I had very little build experience coming into this project (created a few of my own premake setups, created a few makefiles in the past to my own need, used Visual Studio for a couple of years, and used Apache Ant in the past). My Autotools experienced was limited to running a configure script.
Nevertheless, despite the huge barriers I had to overcome in order to understand what was needed to adequately replicate the complex build setup of the SDL2 library, I rose to the challenge and had a lot of fun creating the project. I gained a huge amount of build system experience and I hope that my work helps SDL2 in its efforts and all those who use it.
The project ended up going well beyond what I originally expected, though some of my stretch goals were missed. I wanted to implement iOS support as a stretch, plus build all of the SDL2 extra libraries (like SDL2_mixer, etc.) The second one proved to be well out of scope and there was simply not enough time to implement them. iOS ended up being one of the last major hurdles, and I feel it was well worth it. I hoped to have setup a good environment if others wish to add support for those extra libraries in the future.
Beyond that, the project moved to Linux support and I ended up creating extra goals that were not originally in the project description. Linux, itself, was a stretch goal because I originally signed on with my mentors' expectations I was focusing on Visual Studio and Xcode. Those weren't enough for me, though. After getting them working, I decided to turn my focus toward Linux and Cygwin. Dependency handling in Linux greatly challenged me, which is why I ended up developing the goal to replicate some sort of complex dependency checking system like CMake and Autotools have. I implemented a primitive one and demonstrated it worked. I hope others or myself can extend it in the future, perhaps even leading to it becoming part of Premake. As far as Cygwin support goes, I regret it ended up not happening. Cygwin currently has linker issues as is covered both in this blog and in the changelog I kept throughout the project.
One of the most unexpected parts of the project was how much I ended up committing to the Premake source code. I noted in the description of my project that Premake may lead to barriers in implementing a system as complex as SDL2 (especially with forward compatibility in mind), but how to approach solving the problems those barriers caused was the question. One could work around the code in hackish or unappealing ways (which was my original approach), or directly modify the Premake source code (which I ultimately decided to do later, when I reached insurpassable barriers). What was interesting was all of the changes I personally made to Premake ended up being committed to the stable branch of Premake, making the current Premake used in the SDL2 project one patch short of being the live version currently maintained (the one patch adding core iOS support).
Overall, I really enjoyed my time on this project. I am very excited to see how the community reacts to this project and I can only hope for the best. This was a great experience and I would recommend Google Summer of Code to anyone dedicated and willing to have a ton of fun, meet new people, and learn a huge amount of information in a topic of their choice, with the plus of getting paid for it.