Monday, July 8, 2013

Bringing support to Mac OS X

Greetings readers,

After getting acceptable support for Visual Studio 2008, 2010, and 2012 on Windows, it's time to turn attention over to Mac OS X and Xcode.

Premake and Xcode

Not being at all familiar with Xcode, I had to spend a lot of time last week simply wrapping my head around its many differences (as opposed to Visual Studio, Eclipse, etc.) I still have a lot to learn with this IDE, but I think I figured out enough to work through this part of the project. The first step in this process was cloning my GSoC repository on Mountain Lion and making sure the hand-rolled Xcode projects would build, link, and run properly. They did, as the SDL buildbot said they should.

Next, I basically just copied over the Visual Studio meta-build premake setup I've been working on and used it to generate Xcode 4 projects. Needless to say, it obviously did not build. After getting rid of the windows-specific dependencies and cross referencing with the files the manual Xcode project included, I was able to reproduce a buildable, linkable, and runnable SDL within a matter of hours over just a few days.

However, like everything else I've had to deal with when using premake, there was one concern I had. After reading some changes to premake over the last couple years, I thought it would generate an Xcode project for each of my defined projects in the generated lua file. Regardless, I was happy to find out it generated a workspace file which works essentially identically to that of a VS solution file.

The main pieces left to work out are various configurations on Xcode (such as having multiple build schemas), properly handling architecture differences (the generated builds for 64-bit but SDL was previously built for 32-bit), and ensuring the new setup for SDL's Xcode projects is acceptable.

Consolidating Differences

The next challenge was consolidating the differences between the VS and Xcode solution files. As per my mentor's suggestion, making major directory changes in a repository is often ill-advised, so if I must do it, I should do it asap.

What directory changes? Well, I originally created my premake solution for VS in SDL's VisualC folder. To be similar, I also created a similar directory in SDL's Xcode folder recently. This is obviously not a happy solution to keeping things simple using premake, so my most recent work prior to this blog post had been creating a premake folder in the root SDL folder, removing the other premake folders, and consolidating all build configurations into a single, unified script. I also created subdirectories for VisualC and Xcode within that premake folder. That last part was quickly thrown together, so more work will be done to ensure the projects are generated and built relative to those folders, which they currently are not.

Consolidating the two files has also led to increased hardcoding and, thus, some more complexity. A lot of future work will be to cleanup the central premake file, simplify the dependency tree and project definitions using a lighter syntax (like premake uses for its project and solution definitions), and determining a smart way to do cross-platform dependency checking. Xcode and premake are smart enough to make the hassle of porting from VS to Xcode very minimal (especially with a reference Xcode project), but other complexities have arisen that need to be taken care of, especially if any sort of template system is going to be implemented or if even more platforms are targeted.

Until the next post,

No comments:

Post a Comment