Pre-/Post-Build Scripting in BuildFactory 1.1

In addition to staring out the window wondering if the skies could acheive a more depressing grey color on this fine October saturday, I've been working on BuildFactory again. I spend most of the week working on other people's broken software, the weekend is my time, for my broken software :).

One of the most requested features (where requests > 1) for BuildFactory is the ability to add pre-/post-build scripting, which i've pointed to before as one of the features soon to come. Unfortunately, I've hit a writer's block of sorts, I can't exactly figure out how I want to do the pre-/post-build scripting.

Pre-build Scripting

The current schema for how pre-build scripts would be called is as follows:


Where the ${PROJECTDIR} and ${PROJECTNAME} variables are filled in on a per-project basis at runtime. The pre-build scripting is a bit easier in terms of implementation as there aren't a lot of expectations of a pre-build script, logically, because nothing has been built as of yet, so anything that needs to be done most likely will need nothing more than the directory of the project, and possibly the project name. An invocation of a pre-build script for Adium that resides on my desktop would be called as follows:


Seems simple enough, no? The invocation of this script can be called linearly before the actual building of the Adium project begins, so the implementation overhead to a pre-build script is quite low. The only question right now of course, is this enough for a pre-build script?

Post-build Scripting

Post-build scripts are a good deal more complex in how they might operate in comparision to the pre-build scripts developers might have. I'll be the first to admit that the disk image generation in BuildFactory is piss-poor, and makes far too many assumptions (its issue #211 actually "DMG Generation is too fragile"). The better bet for a developer, to generate nightlies for example, is to add disk image generation into a post-build script and handle everything there, after certain other actions have been performed. In this scenario, a post-build script should only need to know where the built products are right? Yes and no, what if the post-build script then needs to rsync the nightly to a server for mass consumption? What if it needs to copy the results to an internal file server? What if, what if, what if, what if. There's so many things that could be done, unfortunately, there's only so much information "I" can offer the post-build script, so here's the tentative schema for post-build scripting:


DSTROOT, is the built products directory (build/Debug, for example), SYMROOT is the build directory, and OBJROOT would be the intermediate files directory. The latter two are most likely over-kill and thus not needed for most post-build scripts. The unfortunate part, is that I cannot really gauge if passing the build configuration (Debug/Release), or the build target is completely necessary, so this is something I would love feedback on.

For most projects, the Products, Intermediate, and Build directory options (now under "Advanced Options") won't be used, so the "best guess" string would be inserted. For a project like Bonsoir, a typical post-build invocation might look like this:


The latter two options would be left off, I don't really think they are necessary to include unless you implicitly set them. The post-build script is also more complicated in how it should be executed. Should the script be executed in a linear progression? In effect, pre-build, build, post-build and then proceed to the next build, or should the post-build script be spawned in a separate thread, in order to save time (time wasted on rsyncing files, or any other post-build processing that may be necessary). Since the post-build script would logically not be tied to any running build by the time it's invoked, it is logical to throw it into an extra thread, but would the extra complexity of the application be worth the hypothetical speed boost?

I've mentioned this to a few people before, but my uses of BuildFactory are actually quite lame in comparision to the actual capabilities of the application, I really just use it to build all my projects, nothing fancy, just build en masse. I am however, aiming to build it into a complete Xcode-based Cruise Control competitor, so the more feedback on how to build it into a more effective continuous integration tool, the better.

[tags: bleep, buildfactory, cocoa, continuous, integration]

• Posted: 14/10/06 10:13PM
• Category: Programmr

Replies

Write reply