Bumper XULRunner release day!

Thanks to the hard work of Nick Thomas and Lukas Blakk, today I can announce the availability of two new official releases of the XULRunner runtime and SDKs. XULRunner 1.9.0.12 is a maintenance release for the 1.9.0 branch (the code that matches Firefox 3.0.x). XULRunner 1.9.1 is the first official release of XULRunner on the 1.9.1 branch (which matches the code in Firefox 3.5.x). Unfortunately we’re not quite at the point of shipping XULRunner releases at the same time as Firefox 3.5.x releases, but we should have a 1.9.1.1 release soon.

Where is XULRunner 1.9.1?

A question I have been hearing quite a bit on IRC since Firefox 3.5 was released. We don’t quite have the build automation set up to do XULRunner 1.9.1 releases at the same time as Firefox yet, but Nick has been awesome and manually spun some release candidates. These should be pretty much good to go but it would be useful if anyone interested could try them out and report on any serious problems they see. Either just comment here or file a bug and mark it blocking bug 502915.

Without further rambling go get the release candidates.

XULRunner 1.9.1b3 builds, get them while they’re hot

In the process of switching from CVS to Mercurial (and behind the scenes Tinderbox to Buildbot), quite a lot of Mozilla’s build and release systems have had to be updated. Sadly one of the casualties that has yet to be resuscitated are nightly builds of XULRunner on the 1.9.1 branch and trunk. Catlee is now doing some excellent work to get these up and running, but until that gets going here are some semi-official builds using the code matching Firefox 3.1b3. I say semi-official, they were built on regular build slaves using the standard configuration, but just done by hand. I also haven’t tested all of them yet so let me know if you hit any issues, they might be good indicators of issues we’ll see with the nightlies.

Brussels bound

This weekend is FOSDEM 2009 and I’m actually managing to attend this year. It’s kind of weird, I keep doing all this travelling to the states yet I end up having to miss all the awesome stuff that goes on in Europe for various reasons (often because I am all travelled out from the states). But I’m going to be at FOSDEM even if it kills me, which considering the snow on the roads and serious travelling I have over the next few months is a possibility. Thankfully the jetlag from Europe is a lot easier to recover from.

I’m not giving any presentations however if you want to grab me to talk about extension development, XULRunner applications or anything else then feel free. Hopefully the lack of beard won’t leave me too unrecognisable.

Why 2 SDKs are better than 1

In the past the Gecko SDK was somewhat limited. You could compile against it, but only if you were using frozen components, of which there are exceptionally few. You can build an application with only them, but I’d be startled if any moderately complicated app or extension gets by with only them. Thankfully this has changed for 1.9 and the new style SDK contains all interfaces and headers, frozen and unfrozen. This gives you access to lots more, though has the minor disadvantage that you have to keep an eye on what you are using as it could break in the future.

Just one snag with this new SDK though. The Mac version was missing something. Like a bunch of the tools and the XUL framework snapshot. It turns out that the method of packaging the SDK really didn’t work too well when you’re building a universal XULRunner, which is of course what we do.

After a bunch of work by plasticmillion and myself and a bunch of reviewing and generally dealing with our pesky questions by bsmedberg, the Mac XULRunner tinderbox is now producing working SDKs for every build. And I do mean the plural there. Building just one unified SDK is pretty tricky, even manually, let alone trying to make the Mozilla build system do it. Instead two SDKs are build, one for the powerpc architecture and one for intel. This actually works out well if you are producing an unified application using the Mozilla build system. All you really need are these magic lines in the mozconfig for your application:

ac_add_app_options ppc  --with-libxul-sdk=<path to powerpc sdk>
ac_add_app_options i386 --with-libxul-sdk=<path to intel sdk>

I’m just about to update the McCoy application to use the SDKs rather than having to build a full XULRunner alongside. This will make building McCoy simpler, particularly a unified Mac version which for the initial release I pretty much had to stitch together by hand. It will also I hope resolve some stability issues on Linux. I hope to have a new version out soon with some popularly requested new features.

I should note that the powerpc SDK is not a pure powerpc SDK. It is designed to be used to compile the powerpc portion of an applicaton using a build machine that is intel based. Unfortunately some of the important build tools cannot be cross-compiled for the powerpc architecture since the dependencies are only one architecture. Hopefully this will suit the majority of people.