So most of my day I write code which is cool. I usually don’t have to redeploy things because I end up testing in the same environment that I work on it isn’t until I start a release cycle that I need to start to package things up that I really utilise build scripts. Initially I used to just export from SVN and tar things up by hand. I had also recently heard a few proponents to suggest Phing, a PHP based build tool that uses XML files similar to ANT, as something to use with my build scripts. The scripting that I had done was all in Bash, a rather flexible shell environment but lacking in a few features that a dedicated build tool gives me.

What triggered a lot of this is a set of rather strange bash scripts that form the build tool for Joomla!. It handles building the packages, exporting the packages and building the patch packages (diff of new files and updated files from the old release). Wilco always says that we should use Phing instead because it has all of these features. So this project called JAuthTools that I work on started becoming big and it was a pain to build things for it by hand so I decided that now was the time to get into Phing.

Phing
Phing (http://phing.info/) is as stated before a PHP based build tool. Its web site says it can do anything you can do with a traditional build system, which is really kind of your base expectation when you think about it. Why would you replace your build system with something that provides you less? Phing comes with by default all of the nice things you’d want from a build tool, tasks to do things, output things, make directories, move and copy things, call other tasks and a few other nice things.

Problem is that what I’m after is something to build tarballs, and these are marked as optional tasks for the system. This has some cool things like DbDeploy, which connects to a special DB and builds SQL delta files (version control for your DB), coverage analysis, PDO SQL executor, PHPUnit and my personal favourites, tasks for Zip, Tar and Subversion.

So I went to install Phing on my work box. Its a Linux machine so I decided that I wanted to avoid the PEAR path because that is just as good as installing things all over my system. Phing lived happily in my personal bin directory until I realised that to get SVN working I needed to get this thing from PEAR. I decided that I might as well fight PEAR (and my work proxy for that matter) and install it that way. It only took a few attempts to get PEAR to work through my work proxy, it appears that between the last time I was fighting it they fixed it up which is nice. CPAN is another one that is a pain as well because it wants to pull things left and right and my proxy decides that half of the files it wants are too big and it should ask for them after 5pm instead or use a special download request system. But I digress, Phing ends up being mostly unhappily installed via PEAR with a few complaints (I said, “yes download your dependencies” which bombed out when it figured out that its dependency was still marked unstable and refused to install it (so why err bother? why not ask me! I want to install it, I even said so, that is what “alldpes” means right?)). So now I have a SVN capable Phing! Shiny!

So I go off and build all sorts of things and suddenly the installer rejects the package I just built with Phing complaining its an invalid zip file. So I ended up by working around this with a Bash script that basically rebuilt the ZIP archive after Phing was done with its business. So I progress from Bash to…err…Bash via Phing! This is on a PHP 5.2.5 latest build so I’m not sure where the fault for this lays, but if I end up using the old tool then as far as I’m concerned it isn’t a replacement for my build system.

The next thing that I ended up finding is that the nested dependencies appeared not to be fully supported by the tool, which didn’t particularly bother me however as you’ll read later Make supported this perfectly fine. So I ended up having to alter my build file to handle Subversion check outs better because it would check it out for each sub dependencies. So I would have a top level one and then sub-dependencies so that each individual item wouldn’t have to do it themselves, especially for the targets that matched the same repository. I ended up just moving this into a common parent dependency and going from there.

And then I wanted to do some work on my Mac at home. I have a slightly out of date PHP, 5.2.0, which appears to have caused issues. This time I went straight to using PEAR to install things and again this caused issues, but given I was expecting some hassles I managed to get things working. I also don’t have a nasty proxy or firewall so that makes life easier for me as well when installing these things. I tried out my first build script and it spewed out a horrible amount of errors. For some reason on this combination SVN doesn’t want to work which dies silently which then causes the rest of the script to fail because it expects the SVN task to succeed and given I’m using a build tool to ensure that errors get properly trapped it doesn’t bail out or check that directories exist like I could do with a shell script.

Whilst this all sounds bad I did however like one feature that allowed me to control what the zip task (or selected other tasks) included and excluded which made things easier for building packages and controlling operations that are slightly harder in bash or make.

Make
Today I started off making a few new scripts on my Mac to replace the non functional Phing scripts. It wasn’t too hard to go from Phing to Make but I ended up re-expanding out my SVN scripts now that I have a system where the dependencies work better. Strangely enough my zip files also started building properly which was nice to have. But this got me thinking: why do we reinvent the wheel?

Sure it is nice to have a fancy XML file that takes a lot of control away, but at the end of the day when I compare what I wrote to get SVN to export in Phing and what I have to do with Make or BASH, on sheer number of characters I end up finding that Phing loses again.

But here is the really simple thing: Phing’s SVN support is a wrapper around the regular command line SVN client. The advantage of using Make or BASH is their portability for myself. My primary environments are Mac and Linux, and when I have been on Windows for extended periods of time I ended up installing Cygwin. So at the end of the day my build system is portable between systems. Additionally the “Gotcha’s” page for Phing shows that it isn’t really a walk in the park to get it to work on Windows either. The question is that do you really want to play with your build system each time you want to change platforms or do you want to go and get up and go without too many issues.

Make and BASH are both staples of the Unix environment and have had years of testing. Whilst it is nice to have something with a whole heap of new features, the fact is that some of the basic functionality doesn’t work properly or is a pain to get working across platforms: I ended up replicating these features anyway.