Would you write a 911 location app?

John Oliver talked in his show’s most recent episode about the US emergency services phone number, 911. It seems that now nobody uses land lines anymore, sometimes the emergency services have a hard time locating people from their cell phones.

John Oliver: “And if you’re thinking, ‘wait a minute, I can find my location on my cell phone,’ you’re not alone. Dispatchers wonder the same thing.”

Dispatcher: “I can check in on Facebook and it’ll tell you exactly what building I’m in. […] But when you call 911 we don’t get that accurate location information. The technology’s out there, it’s just not getting to us at this point.”

JO: “That’s a good point, because even the Domino’s app can tell where you are, and they’ve barely mastered the technology to make a palatable pizza! So we asked […] why it seems Ubers can find you better than ambulances can, and there doesn’t seem to be a simple satisfying answer.”

Here is my best guess at that answer, as a software engineer. Our industry has a pervasive culture of rush-jobs that get 90% of the way there and then save the rest for version 2; move fast and break things, yada yada. No emergency services provider would adopt it because it would not be reliable.

It’s reasonable to think that 90% would be better than what 911 apparently has now, which according to the video is sometimes only accurate to the nearest cell tower. However, the litigious nature of US society makes that impossible. The first time the software failed, the maker would get sued out of business.

Thus we are stuck, because we teach ourselves not to go the extra mile; and even if we went it, no-one could afford to take responsibility for making things better.

GJS and Autoconf

Here’s a leftover from the GNOME Developer Experience Hackfest that I participated in back in January: in my last post about it, I mentioned I had worked on some Autoconf macros for GJS that got added to the Autoconf Archive.

My plan was to port an existing GNOME application written in GJS to use the new macros, as an example for other projects to follow. I did so for GNOME Documents a while ago, but then forgot all about it as the patches sat spoiling on my hard drive. Recently I fixed that up and submitted a patch as I should have done long ago.

Here’s the guide to using the new macros in your project:

• Replace any AC_PATH_PROG([GJS], [gjs]) (or, possibly, pkg-config --variable=gjs_console gjs-1.0; I might add this to the macro) with the shorter AX_PROG_GJS.
• Use AX_CHECK_GIRS_GJS to check that you have the correct API version of each introspected dependency that you import in your code. Easy rule of thumb in a one-liner: git grep imports\.gi\. | cut -d: -f2 | awk '{$1=$1};1' | sort | uniq will pick out all the GIRs that you import. (Take special note for Cairo: its GIR name starts with a lowercase letter!)
• Since GIRs don’t have a concept of versions other than the API version, use AX_CHECK_GIR_SYMBOLS_GJS to check for APIs that you use that aren’t available in all versions. For example, if you use the new GtkShortcutsWindow in your code, don’t try to check for GTK 3.20; instead check for the ShortcutsWindow symbol using this macro. (Use this sparingly, of course; there’s no need to check exhaustively for every new API that was added since 3.0, only the latest that you use!)

You might ask “why should I check these dependencies at build-time when they are only necessary at runtime?” You would be correct, it’s not necessary to check them at build time. However, these macros were originally born of the frustration that happens when you “make all install” a tarball only to run it and find out you’re missing GIR dependencies. And especially in the case of using new API, like ShortcutsWindow that I mentioned above, your program might even start up correctly and crash halfway through when you try to open a ShortcutsWindow. It’s a courtesy to your users (not to mention downstream operating system packagers, for whom your runtime dependencies might not be obvious.)

The macros are now also available in your JHbuild setup, through the m4-common module. How that module works is not very discoverable, and Philip W was kind enough to explain it to me when I asked how to get the new macros in. So I’ll explain it again here for future reference.

M4-common contains the agreed-upon set of M4 macros from the Autoconf Archive that GNOME applications use for building. It’s a Git repository that pulls in a known version of the Autoconf Archive as a Git submodule, and installs the M4 macros from it that GNOME applications need to build. If your application uses any of these macros, then it should have a dependency on m4-common in JHbuild.

As written on the GNOME Wiki, if you get an error like

./configure: line 12053: syntax error near unexpected token `GOBJECT_INTROSPECTION_CHECK'
./configure: line 12053: `AX_REQUIRE_DEFINED(GOBJECT_INTROSPECTION_CHECK)'

then you probably need to build m4-common and make sure you have a dependency on it.

Note that you don’t need to care about any of that if you’re building from a released tarball; that’s because Autotools bundles all the macros you use in the tarball when you run “make dist”.

Thanks to Philip Withnall and Cosimo Cecchi for code review and good ideas; and thanks to Endless Computers for allowing me to contribute these macros developed on company time to the Autoconf Archive.