#build script

[wdtweet-blog]

Building a WPF Project with Ant

Generally speaking, I never endorse deploying an application to a production environment unless it has been built from scratch in a clean environment. This means that building a portlet factory WAR from the eclipse IDE is not the way to do a production build, even though it is really convenient. Building with Ant Apache ant has been around for a long while now, is an excellent framework for building WAR files and is the tool that WPF uses to build its own WAR files. In older versions of WPF the build process was somewhat lacking, but the team at IBM has really done a great job with the latest release of the product (I think this improved build may have been available in 6.1.5, but we skipped over that and went straight to 7.0). Below is an example of how I've taken the sample build.xml provided with the product and modified it to pull code from CVS and allow for project specific settings. The build.properties is mostly unchanged:

CVSTag=HEAD # Build source root directory !NOTE! This value must be an absolute path. buildsrc.location=C:/wsad/GCPS_V7/PF_Build/WPF7/${project.name} # Build temp location. This is where the temporary project will be created for building purposes buildtmp.location=${buildsrc.location}/buildtmp # The root directory for the Portlet Factory files. wpf.artifacts.dir=C:/wsad/GCPS_V7/PF_Build/WPF7 # The output location for the generated war files. builddist.location=${buildsrc.location}/dist # The location of the pbportlet.jar file. This ships with portal c2a.lib.dir=${wpf.artifacts.dir}/WebSphere Portal # The name of the project (used for identifiying war files) project.name=SET PROJECT NAME IN XML BUILD FILE #-- The following properties should not need to be changed under normal circumstances. -- # The root directory of the temp project. This is used by projectDeploy.xml project.location=${buildtmp.location} # The WebContent directory of the project that will be created. This is also used by projectDeploy.xml webcontent.location=${project.location}/WebContent # The output directory for standalone deployment wars. build.deployment.war.builddir=${builddist.location} # The output directory for the portlet wars wpf.portletwar.location=${builddist.location} # The shipping version of Portlet Factory version=7.0.0

Note that I've added a new property CVSTag which is used to identify which label or branch to use with CVS. I've also changed the project.name property to a self descriptive value that will stand out during a build if it is not changed. The intent is that this build.properties file does not contain any project specific values - those will be set elsewhere. Next, I've taken the sample build.xml and made a few changes to it as well:

Your project ant script is missing a target named "addPackages". This is used to add WPF featuresets. Your project ant script is missing a target named "propertiesOverride".

Noteworthy, from top to bottom:

added depends="propertiesOverride" to the properties target.

added a call to the ant cvs task. This will retrieve any code that was added to source control.

removed the sample antcall to addFeatureSet and replaced it with a call to my own addPackages.

finally at the bottom I've added default implementations for the new targets that will cause the build to fail if they're not defined elsewhere.

Now that I've done some prep work, I can build any WPF project with a short bit of xml saved as MyAwesomeWPFProject.xml:

Template script for building a portlet factory WAR for deployment

The heavy lifting here is done with the import of build.xml, which is just like adding everything in that file to my script, but allowing me to override any targets within it. In this case I've added my own propertiesOverride where I can change values that were defined in build.properties and addPackages where I can add any featuresets that my project requires. Building my project is now as simple as

ant -f MyAwesomeWPFProject.xml

and if I need to build a specific version that has been labeled in CVS, I can provide that label like this

ant -f MyAwesomeWPFProject.xml -DCVSTag=MyLabel

which will override the value in build.properties. Piece of Cake Prior to this, I had my own homebrew build process that I am now glad to throw away. It served me well for the last three years, but this is more robust and I really like the way I can add featuresets.

[f06code]

spectrogram3d and gltut now buildable!

I've written short buildscripts for spectrogram3d_hs and gltut_haskell-gpipe which basically boil down to a wget and sh build.sh. No cabal hell necessary! Now you can build them from the comfort of your own home. Deets in the readmes!

spectrogram3d_hs

A live 3D spectrogram written in Haskell. It takes sound from JACK, and draws a mesh with GPipe. You can use it visualize audio from VLC, iTunes, or even microphone input (whistling is particularly interesting to watch).

gltut_haskell-gpipe

These are ports of the examples from Jason L. McKesson's wonderful online book Learning Modern 3D Graphics Programming from C++ and GLSL into Haskell. The ports use Tobias Bexelius' OpenGL framework GPipe [1] [2] to express OpenGL buffers, uniforms, vertex shaders, and fragment shaders in normal Haskell code.

new things

In lieu of continuing to work on GPipe projects I'm trying out LambdaCube3D [lc-dsl] for a spell, and with my new job being mostly clojure I expect to be making interesting things with it and posting them here soon. Stay tuned!

[kuym]

Build Systems

Build systems are the worst.  What if you were able to specify a simple dependency graph in e.g. JSON, with custom functionality scripted in a simple, Java(Script)-like domain-specific language and it can be trivially converted to one kind of system shell script or another by POSTing the file to a URL with curl?

curl -F [email protected] http://justbuild.it/bash \ > build.sh  # generate a Bash script

From there, simply run build.sh and it will perform your custom, structured build.  The output script will contain the original build recipe at the top and a checksum that can be used to verify integrity - if someone modifies the Bash-script output, the script won't run and will prompt you to upload the original recipe JSON or the output Bash script to the service for regeneration.  This sort of damage-resistance is really important when working on a team and/or maintaining a project long-term.

[sugendran]

Continuous Integration with XCode

Coming from the world of .NET with it's large crowd of over educated anal programmers I've been quite used to having continuous integration in all my programming work. It seems that the Objective-C camp lacks these unit testing evangelists - if it builds ship it right!? And for the most part this is cool because the Objective-C ideology seems to be about the user experience, so most bugs are found by user testing. And then comes the Apple approval process where they try to make sure your app is not in fact a piece of poorly held together bloatware. So why bother with continuous integration? From my point of view the best thing it can achieve is to build every night and send it out to your testers. There is the added benefit of making sure what's in the repository always compiles and whatever unit tests you have pass - just don't commit stupid code. This tutorial is going to use Test Flight for the distribution. If you haven't had a look at it yet, it's a pretty nifty tool. They host the ad-hoc distribution application files and allow for your testers to send you feedback. You don't have to use Test Flight, just replace the final part of the script to use your own delivery method. You're also going to need to create an ad-hoc distribution profile, instructions for this are on the Apple Dev Center. Oh, and I'm going to assume that you're building on a Mac since that's what Steve says you should do. The script itself is a BASH script, if you want to convert it to an ANT file or something sillier then this should hopefully make things clear about what has to happen. Also, this is designed for the iOS5 SDK since that is what is current.

Step 1 - Some variables

The following is taken straight from the script, hopefully the comments all make sense.

# I'm assuming that your project is in the src directory of your repository PROJECT_DIRECTORY="${PWD}/src" # The target we're building TARGET_NAME="My Project" # The name for the .app and .ipa files that get created APP_NAME="myproject" # I like to have build junk outside my source directory PROJECT_BUILDDIR="/tmp/iOSBuild"

Step 2 - Create an ad-hoc build configuration

I'm yet to work out a way to grab the provisioning certificate's identifier via command line so the easiest way is to just add a build target to your project. In XCode click on the project in the project navigator (⌘+1) then open the "Info" tab. You should see a list of configurations, press the plus sign and duplicate the "Release" configuration. Next, go to the "Build Settings" tab of your target and find the section called "Code Signing." In here we want to set the CODE_SIGNING_IDENTITY to your distribution profile that you created on the Apple Dev Center. I know the theory says that you can resign it post building, but I've never managed to get it to work in practice. Next we need to add an Entitlements plist. Right click on your project and select new file. Under the "Code Signing" section there is a template for "Entitlements" - add an entitlements file called "Entitlements" and change the "get-task-allow" setting to NO. Next go to your project settings and navigate to the build settings for your target. You want to set the CODE_SIGN_ENTITLEMENTS to "Entitlements.plist" for your Ad Hoc configuration.

Step 3 - xcodebuild

xcodebuild is a command line tool that comes with XCode and allows you to execute builds. It will look in your current directory for the project and run against that. Personally I like to run a clean before I build anything, so the following does two actions. First it runs a clean then it builds for a release.

xcodebuild -target "${PROJECT_NAME}" -sdk "iphoneos5.0" -configuration "Ad Hoc" clean CONFIGURATION_BUILD_DIR="${PROJECT_BUILDDIR}" xcodebuild -target "${PROJECT_NAME}" -sdk "iphoneos5.0" -configuration "Ad Hoc" build CONFIGURATION_BUILD_DIR="${PROJECT_BUILDDIR}"

You'll notice that the SDK is "iphoneos5.0" - you can get a list of available SDKs by running "xcodebuild -showsdks" in a terminal.

Step 4 - Package it up

To package it all up and produce the .ipa file required for distribution we need to use the PackageApplication tool. There is a command line called xcrun that lets us run XCode tools from the command line. This bit is magic, and I have no idea how it works - it just does.

/usr/bin/xcrun -sdk "iphoneos5.0" PackageApplication -v "${PROJECT_BUILDDIR}/${APP_NAME}.app" -o "${PROJECT_BUILDDIR}/${APP_NAME}.ipa"

Step 5 - Distribute to your testers

Since this is my nightly build script and I'm using git I will need to collect all the commit messages since midnight yesterday. If you don't want to do a fancy commit history then you can just change notes field that in the submission to something else.

#Get the time for midnight the day before so that we can get all the commit messages HOURS=`date "+%H"` MINS=`date "+%M"` SECS=`date "+%S"` PREVDAY=`date -v-1d -v-${HOURS}H -v-${MINS}M -v-${SECS}S` #Grab the commit messages from git COMMITMESSAGE=`git log --after="${PREVDAY}" -s --format=%s` echo "Commit message is: ${COMMITMESSAGE}" #testflight settings TF_API_TOKEN="YOUR API TOKEN HERE" TF_TEAM_TOKEN="YOUR TEAM TOKEN HERE" TF_DISTRIBUTION_LISTS="Nightly" echo "Sending to test flight" curl -F file=@"$PROJECT_BUILDDIR/${APP_NAME}.ipa" -F api_token="${TF_API_TOKEN}" -F team_token="${TF_TEAM_TOKEN}" -F notes="Nightly Build - ${COMMITMESSAGE}" -F notify=True -F distribution_lists="${TF_DISTRIBUTION_LISTS}" "http://testflightapp.com/api/builds.json"

The full script can be found on github, distributed on a-use-at-your-own-risk-and-don't-tell-me-about-your-personal-problems licence. https://github.com/sugendran/iOS-Build-Script reference: http://support.testflightapp.com/discussions/suggestions/16-build-upload-script-example