You are not alone.

I released my smartmake tool last year to allow people to specify then directories they’ve changed, and in return the tool would perform a correct incremental build. No hassle, no sweat. The name was deceptive; it was a pretty dumb tool, but it got the job done with a little help from the user. However, there is a rule that any build system tool eventually reimplements the functionality of make, and so I am proud to release smartmake v2, which requires less work than ever before to produce correct incremental builds.

Thanks to the hard work of the illustrious Till Schneidereit (till on IRC), smartmake now finds every source file modified since the last time you performed an incremental build, and performs a (mostly) minimal rebuild. It will also complain if it comes across any modified files for which it doesn’t have any dependency information, and suggest you perform a full build instead.

Go ahead, give it a shot! Tell me (or Till) what goes wrong so that we can fix it. I recommend doing a full build, then making a small change and running smartmake.py '5 minutes ago' to kick it off and get the timestamp caching happening.

If you’re not a bzexport user, and you write patches that are submitted to bugzilla, you’re missing out. Bzexport simplifies that process of getting a patch out of your local machine and into the hands of your reviewer, making you a happier and more productive person.

What’s supported right now:

nsCOMPtr<nsIFoo>

If you print an nsCOMPtr, you’ll see one of two things:
[(nsIFoo*) 0x0]
or
[(nsConcreteFoo*) 0x12345678]

In addition, pretty-printers chain, so if there’s a pretty printer for nsConcreteFoo*, you’ll see that printed instead of just the pointer value. Furthermore, nsRefPtr and nsAutoPtr are also supported, and maybe nsWeakPtr (untested).

nsCString/nsString

It prints the string inline, up to the limit specified by gdb. This probably only works for ascii strings at the moment; the code is a bit of a mess.

nsTArray/InfallibleTArray

You’ll get output along the lines of [0x12345678, 0x12345678] at the moment. Like the smart pointers, each printed element will be pretty-printed if possible.

nsStandardURL*

You’ll see the spec printed. This works wonderfully when you’re looking at an object with nsCOMPtr<nsIURI> foo, where foo is actually pointing to an nsStandardURL object.

Tagged reference counts

You know in cycle-collected objects when the refcount shows you mTagged = 0x8? Yeah, not any more.

PRPackedBool

I found the existing display of mBoolVal = 1 '\001' to be silly.

What’s coming up?

I’ve got a list of things that still need fixing/improving, and I’m open to suggestions/patches.

• Auto arrays – the kinda-sorta work right now, but it looks gross.
• COM/void/observer arrays – don’t work at all
• Hashtables – don’t work at all right now
• Stricter regexes for matching types – things like pointers to arrays are matched by the nsTArray printer right now
• Auto strings – I don’t remember if they don’t work at all or semi-work
• PRUnichar* – doesn’t work.

and so on and so forth. It’s really not difficult to write more printers, and it improves the output of gdb immensely in my opinion. Give it a shot! The instructions for how to set this up can be found in the README file. You’ll need a version of gdb > 7.2 (probably trunk, at the time of writing), since my printers rely on gdb.Type.dynamic_type.

python cancel.py

will be enough to get you going – you’ll be prompted for your username, password, branch and hg revision. The builds displayed also show their state (running, pending or complete) as well, so it’s easier to find what you’re looking for. Let me know if there are more changes you’d like made!

I’m a big fan of the self-serve tool that RelEng provided for people with LDAP access. When I can see a try build going bad, I can cancel all the remaining builds and free up resources, or retrigger completed builds if I want to get extra results. Unfortunately, the server is fairly slow to respond and the UI to perform these actions is clumsy. Luckily, there’s a really simple API available to allow anyone with access to make use of these tools in more traditional (read: non-graphical) means. Allow me to introduce you to a new repo I set up today to make working with the self-serve API easier – self-serve tools. selfserve.py contains simple wrappers for every API point exposed, and some basic documentation of the values returned by most of the calls. cancel.py is an example of a really simple tool that can be built on top of the wrappers to allow for bulk cancellation. Here’s what a session looks like:

[jdm@Phaethon self-serve-tools]$ python cancel.py -u "jmatthews@mozilla.com" -p my5ecureP4ssword123 -r 306838f27b33 -b try
1: Linux x86-64 tryserver leak test build
2: Linux tryserver build
3: OS X 10.6.2 tryserver build
4: WINNT 5.2 tryserver build
5: Maemo 5 QT tryserver build
6: OS X 10.6.2 tryserver leak test build
7: Maemo 5 GTK tryserver build
8: Android R7 tryserver build
9: Linux tryserver leak test build
10: WINNT 5.2 tryserver leak test build
11: OS X 10.5.2 tryserver leak test build
12: Linux QT tryserver build
13: Linux x86-64 tryserver build
14: all
Builds to cancel: 1 3 5
Cancelling Linux x86-64 tryserver leak test build
Cancelling OS X 10.6.2 tryserver build
Cancelling Maemo 5 QT tryserver build

This is just the first cut, but I’m excited not to have to use the web interface any more. Please feel free to add further documentation, or even new tools! I’m excited to see what other people can build with this.

You’re looking at a mind-bogglingly alpha Jetpack prototype running out of process. Yesterday was a black triangle moment for me, as I finally saw the culmination of 2.5 months of work to make the words “Gmail it” appear in the status bar.

In this implementation, when a Jetpack tries to do something that doesn’t really make sense in its own process (say, adding an element to the status bar), it proxies this operation to the chrome process and continues on its way. Theoretically this allows the main chrome to focus on important things like being responsive or not freezing, so the main work of running Jetpack scripts can be delegated to another process.

There’s lots and lots more work from here (for example, clicking “Gmail it” does nothing for various reasons I need to explore), but this inauspicious screenshot demonstrates that the out of process future is alive and kicking!

It wasn’t quite that easy – since Megazeux uses a non-standard configure script, I had to correct a few faulty assumptions. I never figured out the correct way to use

/usr/i686-pc-mingw32/sys-root/mingw/bin/sdl-config

instead of the default one, so that got hardcoded somewhere. Also, Megazeux relies on libogg and libvorbis, which haven’t been pushed to the fedora repository yet (packaging limbo ahoy!), but I was able to grab some rpms that the mingw32 packager helpfully left lying around. All in all, a very successful and satisfying experience.