Frustration

For a while now I’ve been in a bit of a rut. I knew I was there I just hadn’t quite got the motivation to pull myself out of it. It wasn’t such a bad place to be, but the difference of being just ok with the way things are going and being exactly where you want to be and with the people you want to be with is a pretty large one. I’ve been exceptionally lucky that over the last few months a bunch of things have happened that will help take me to where I want to go and start some new and exciting changes in my life.

The problem is that almost none of them were instant changes, they are all gradual and still in the process of happening. Some of them may not even work out the way I’d like. It’s disconcerting to see where I want to be on the horizon yet now I don’t have control of getting myself there, I have to wait to for the cogs to turn. Now don’t get me wrong, I know that there are perfectly good reasons for having to wait, I don’t expect to be able to just move out to the States at a moments notice for example. But the wait and not knowing exactly what is going on is leaving me extremely frustrated. Do I assume everything is going to work out and look forward to my new life only to be disappointed later? Do I assume the worst and then not be prepared when it comes?

Frustration is something I’m normally fairly familiar with. It is after all pretty much the standard state of affairs for anyone working on Mozilla code, you have to wait for responses to design questions, you have to wait for patch reviews, you have to wait for the tree to be clear enough to land. All of this you slowly get used to, but it is still annoying. The problem is that now this is going on in pretty much all aspects of my life and is starting to drive me into the ground. I’ve been getting even less sleep than normal which is also leaving me kind of cranky.

Thankfully I have been able to arrange myself a temporary escape. Next month I’m going to go spend a week and a half with an friend in Austin, and while I’ll still be working for much of that time I can’t wait to hang out with him again. Also, just because it was fairly cheap, I’ll hop over to San Francisco for a long weekend with some other friends. Hopefully that will de-stress me enough to last the following months. And who knows some things may even have resolved themselves by then, or at least become a little clearer.

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.

Mac Intel Gecko SDK

Update: Mozilla now produce intel gecko SDKs so there is no need to use the version I have put here, I’ll leave it for posterity though.

It’s currently a bit of a pain building xpcom components in intel macs. The only officially available sdk is ppc only. Until Mozilla come up with an official version, here is an intel build of it for those that want it: gecko-sdk-mac-intel-1.8.1.3.zip

As the name suggests it’s built against Gecko 1.8.1.3. To the best of my knowledge it’s right but please don’t bug me if you can’t get your component to work with it unless you’re pretty positive that it’s the sdk that’s wrong.

Right now I have no clue how you’d go about making a universal sdk, maybe if you know of a simple way then you could get in touch.