May 13, 2013

Build Systems

Build systems are painful, and I'm sure most developers will agree. Fortunately, there are many solutions for build systems which support various languages and offer a wide range of capabilities. For the typical developer you will never really need to worry that much about a build system. However, if you are serious about developing applications you should not ignore the productivity you will gain from a real build system. The main reason comes from the fact that you will need to deploy your application at some point. Is it really worth putting in all the time to invest in learning about various build systems? I would say yes and no.

Firstly, make sure you research the different build systems for your language(s) and their capabilities for deploying to your target(s). Once you have figured out which ones are feasible, then you really need to look into what people say about the build system. This will usually give you a good indication of what to expect from the build system (i.e. its pros and cons). Never get fooled into thinking you have 'the best' build system, because no matter how great you think it is, there will always be cons.

Secondly, spend the time to learn the build system, practice with some of the basics on how to use the system, build some dummy projects and work your way up to more complicated builds. Once you feel comfy with it, look at your project of interest and create a build for it. Along the way, figure out if this build system really fits what you want and need. If you did the last step, you know the alternatives and before you invest your time into setting up your project. That means you can easily switch to a different build system before you start getting frustrated.

Thirdly, use the build system. Make sure you can automate almost everything so that you will never really have to worry about deployment again. Doing deployment by hand is error-prone, slow, and usually fairly painful. The beauty of using a build system means you can easily do a cross-platform deployment and pre-package your application by simply pressing a button when you're ready. Additionally, you can check for library updates, run unit tests, or simply setup the versioning information for your deployment. This all happens automatically and you really only need to worry about it when you setup your project or make changes to the configuration. The best part is, most build systems provide a configuration script which you can throw into a VCS (Version Control System). When you decided to go back to an old version, the build system will grab everything it needs and run without you having to think about what you used to do to deploy the application.

The real cost is learning how to use a build system, but its no different than learning how to use an IDE, or learning how to use a VCS. The most commonly known build system is 'make' but just because it's common doesn't make it the best or the only one. Remember, there is no silver bullet and one size does not fit all.

Gradle, after doing some research I came to the conclusion this was probably the most ideal build system for me. However, it was designed for IntelliJ IDEA and not for my personal choice of IDE... the bloated Eclipse. Don't get me wrong, Eclipse is pretty sweet (hence why I use it), but it seriously has issues with performance, responsiveness, and memory usage. Netbeans I can't stand working with because it reminds me so much of Visual Studio, but that is more of a personal opinion than truth. Gradle's integration into Eclipse is pretty decent from the looks of things. Finding "Eclipse's Gradle plugin" is a bit of a pain (not to be confused with the "Gradle's Eclipse plugin") and you have to install Eclipse's Groovy plugin. Groovy, in simple terms is kind of an extension to Java so using it as a language for a build system is pretty epic.

It looks like Gradle offers support for Android and offers support for packaging and deploying applications to Windows, Mac, and *nix (read Linux/Unix) in a way that makes sense for each platform. It also has support for many of the JVM languages and comes with integration with other build systems, such as Maven, Ant and Ivy. Really, it sounds almost too good to be true. However, I still need to play with the Scala side of it, and see how effective I can combine the deployment plugins with the 4 platforms I target (Android, Windows, Mac, and Linux). Most importantly, I want to see how well they work with LibGDX and if that works out well I might also write a nice tutorial on how to get it all up and running.

I guess I should also mention how I'm considering writing a number of tutorials for LibGDX, but not a beginner tutorial. If anything, it would be tutorial that quickly covers the basics of LibGDX and then jumps into building an actual game with the above technologies.



No comments :

Post a Comment