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.

Extension Authors, Say Hi to McCoy

McCoyI know all you extension authors out there have been understandably miffed at the add-on update security bits landing before you could do anything about it, so I’ve pushed hard and we can now make an early version of McCoy available.

McCoy is the tool to use if you are hosting your own add-ons and for whatever reason cannot use SSL to secure the updates. If you haven’t yet heard about the new security restrictions that will be in Firefox 3 or you don’t quite understand them yet then why not skip on over to the vastly improved add-on updates documentation and take particular note of the security section.

So what are you waiting for? Grab your copy of McCoy and get to work securing your add-ons.

I should point out that this is an early version, there are a bunch of improvements that we’d like to make so keep an eye on the homepage and here for updated releases. Also massive thanks to Mark Finkle for getting through the code reviews so quickly.

If you happen to hit any issues using McCoy or just have some ideas for it’s future then please file a bug (searching for dupes first of course!). Given that this is an early release there’s a number of issues already on file.