Hardscrabble 🍫

By Max Jacobson

another cookie crumb

21 Feb 2015

In Wednesday’s post about building Firefox from source the other day, I mentioned one thing I really liked about the experience of first looking at this code base: it kept dropping little hints about what I might need to do next in a way that was actually insightful and helpful. For example, after running their script which installs dependencies, there was some helpful output pointing me to where I could get the code base.

Today I checked in with the project and pulled the change from the last few days. There has been a flurry of activity, none of which means much of anything to me as an outside observer.

I was curious if I would be able to run ./mach build, and if it would take as long on the second run. Instead I got this interesting output:

0:00.35 /usr/bin/make -f client.mk -s
0:01.33 The CLOBBER file has been updated, indicating that an incremental
0:01.33 build since your last build will probably not work. A full/clobber
0:01.33 build is required.
0:01.33 The reason for the clobber is:
0:01.33  Bug 1119335 - (DOMString or sequence<DOMString> or ConstrainDOMStringParameters)
0:01.33  needs binding flush (Bug 1103153).
0:01.33 Clobbering can be performed automatically. However, we didn't
0:01.33 automatically clobber this time because:
0:01.33   Automatic clobbering is not enabled
0:01.33   (add "mk_add_options AUTOCLOBBER=1" to your mozconfig).
0:01.33 The easiest and fastest way to clobber is to run:
0:01.33  $ mach clobber
0:01.33 If you know this clobber doesn't apply to you or you're feeling lucky
0:01.33 -- Well, are ya? -- you can ignore this clobber requirement by
0:01.33 running:
0:01.33  $ touch /Users/maxjacobson/src/gecko-dev/obj-x86_64-apple-darwin14.3.0/CLOBBER
0:01.33 make: *** [/Users/maxjacobson/src/gecko-dev/obj-x86_64-apple-darwin14.3.0/CLOBBER] Error 1
0:01.36 78 compiler warnings present.

That’s super interesting! Things I learned from this:

  • There’s something called “The CLOBBER file” which is some kind of place to leave little messages about why someone else will need to do a full build after pulling in a change
  • Sometimes it’s possible for mach to do an “incremental build”, which I assume wouldn’t take very long
  • There’s a tool for clobbering, which I guess clears away stuff from earlier builds, requiring mach build to do a full, non-incremental build
  • Mozilla people make nerdy movie references

I took a look at The CLOBBER file by using my fuzzy file opener to look for a file called CLOBBER and found it, in the root-level of the project. It contains more details about how to use it:

# To trigger a clobber replace ALL of the textual description below,
# giving a bug number and a one line description of why a clobber is
# required. Modifying this file will make configure check that a
# clobber has been performed before the build can continue.
# MERGE NOTE: When merging two branches that require a CLOBBER, you should
#             merge both CLOBBER descriptions, to ensure that users on
#             both branches correctly see the clobber warning.
#                  O   <-- Users coming from both parents need to Clobber
#               /     \
#          O               O
#          |               |
#          O <-- Clobber   O  <-- Clobber
# Note: The description below will be part of the error message shown to users.
# Modifying this file will now automatically clobber the buildbot machines \o/

# Are you updating CLOBBER because you think it's needed for your WebIDL
# changes to stick? As of bug 928195, this shouldn't be necessary! Please
# don't change CLOBBER for WebIDL changes any more.

Bug 1119335 - (DOMString or sequence<DOMString> or ConstrainDOMStringParameters)
needs binding flush (Bug 1103153).

It’s probably gratuitous to just copy this whole thing in here, especially when the last few lines are designed to change, but it’s pretty interesting, and I have a weird superstition about linking to files on GitHub, for example, because what if that file gets moved and my link goes dead?

This file is like a cache. As long as it stays the same, you can keep building. As soon as it changes, you need to clobber before you can build. It seems like a clever solution to me (I especially like the detail about combining clobber notes so when two people insist on a clobber, they each get the benefit of the other’s). You just need to remember when to expire the cache, which leaves a little cookie crumb for the next developer to work on the project.

building firefox for the first time

18 Feb 2015

recently I came across two blog posts:

They kind of tell similar stories. Both Firefox and Chromium1 are open source and welcome contributions from the general public, but both of them are probably developed primarily by the companies behind them. These posts are sort of encouraging people to consider contributing back to the app they spend most of their computer time in and hoping to make it sound more doable and less terrifying.

I came away from the Chromium post with a lot of clear and friendly knowledge about how I might make a contribution but actually more convinced that I’m not qualified to do so, because I don’t know any of the languages she mentioned in the post and don’t currently plan to learn them. If I did, I’d know exactly where to start and how to proceed.

The firefox blog post was an offer to help mentor a select few through getting up and running and making a first few contributions. I thought about it for a few minutes while I read the blog post and filed it away in the back of my mind, but I was too slow, and the offer has now closed. I thought maybe I could do it because having a mentor helps a lot and, from the sounds of it, the front-end of Firefox is built using the tools of the web, which I already kind of know and work with. From the post:

We will use JavaScript, CSS, and XUL (similar to HTML).


Also, Firefox is my day-to-day browser, so selfishly I like the idea of submitting something that would benefit me. I first got excited about the internet in Firefox. I’ve occasionally switched to Chrome and Safari but I always come back to Firefox. I don’t know. And I kind of think it’s having a moment? Well just someone wrote one blog post about it recently:

I like dhh’s perspective there; sometimes I feel like a browser hipster and like I’m the only web developer not using Chrome (I know I’m not) but I do think he’s right that it’s important that any one company doesn’t have too strong a hold on how the internet works.

So tonight I took the first step and built Firefox locally. It was surprisingly easy but also surprisingly time-consuming. If you want to do the same I recommend following the Simple Firefox build instructions but I’m going to share here anyway the steps I took.

  • Visited that guide
  • Followed that link to Linux and MacOS build preparation which recommended I paste the following into my terminal to install the prerequisite dependencies:
wget -q https://hg.mozilla.org/mozilla-central/raw-file/default/python/mozboot/bin/bootstrap.py && python bootstrap.py
  • That asked me if I was interested in building Firefox for Desktop or Android. I answered Desktop, and it started doing stuff, and outputting what it was doing, and ultimately (actually this was pretty fast) it said it worked and made this suggestion:
Your system should be ready to build Firefox for Desktop! If you have not already,
obtain a copy of the source code by running:

    hg clone https://hg.mozilla.org/mozilla-central

Or, if you prefer Git:

    git clone https://git.mozilla.org/integration/gecko-dev.git
  • So I ran the second command, because I prefer git (well, because I know git)
  • And then I waited for like ten minutes? More? I don’t know. I had never cloned a 7 gigabyte git repo before. It felt new and strange. The .git directory is nearly 6 gigabytes, suggesting the sheer history of the project weighs significantly more than the current state of it. The repository has 407088 commits going back 17 years, 8 years before git existed.
  • After the project finished cloning, I ran cd gecko-dev and no magical incantation appeared giving me the next bread crumb to follow, so I returned to the guide.
  • It suggested using Firefox’s ./mach script to build and run the app. This felt kind of familiar, kind of like Ruby’s rake. I tried running just ./mach without any arguments and saw that it has a shitload of commands including google, so I ran ./mach google jake and amir (because I was just watching Jake and Amir episodes before this flight of fancy overtook me) and it opened Firefox to https://www.google.com/search?q=jake%20and%20amir, which, alright, sure.
  • I ran ./mach build and watched it do a shitload of stuff to build Firefox from the source I’d downloaded. I don’t have to estimate how long this took, because it output a running timestamp as it did everything. It took 37 minutes and 56.85 seconds. I guess that’s not bad? I hope I don’t need to wait that long every time I make a change (if I even figure out how to make a change). And when it was finished, I saw this output:
37:56.85 We know it took a while, but your build finally finished successfully!
To take your build for a test drive, run: |mach run|
For more information on what to do now, see https://developer.mozilla.org/docs/Developer_Guide/So_You_Just_Built_Firefox
  • I ran ./mach run and like lightning a bluish moonish earth appears in my Mac’s dock and Firefox Nightly opened.
  • I visited hardscrabble.net just kind of vainly to see what my site looks like in my freshly baked browser
  • I visited the URL from that last output (sidenote: I really love the trail of breadcrumbs this process has been) and found a kind of hilariously brief web page which mainly includes notes on how it should be succinct but also a tag indicating it needs more content?
  • I followed the first listed interesting link about how to run Firefox’s tests, and before I could overthink what’s about to happen I ran ./mach xpcshell-test and the most delightful thing happened, and I think it needs to be captured in a video:

I’m sorry this blog post became a bullet point list halfway through. That wasn’t really fair.

Probably in the morning I’ll forget I ever wanted to contribute to Firefox but hopefully not. I’m on the record now.

  1. Chromium is basically Chrome, but open source. 

discovering a problem

21 Jan 2015

view source on a recent post

That’s the “View Source” on a recent post here on the blog.

Do you ever discover a problem weeks or months or years after it was introduced? How did you discover it?

The HTML markup on my website has been broken for a while, but I only just noticed today, and then I noticed twice, the way you learn a new word and then hear it again right away.

I’ve looked at that view source several times while poking around on this site, and I can vaguely recall being concerned that some of those tags are highlighted in red, but never taking much notice of it, because the site works more or less fine.

Today while bored I took a look at a very neat iOS app called View Source, which provides an iOS 8 extension for viewing the source of any website right in Safari. When I tried to run it on my own blog (as you do), I saw this:

view source on a recent post in iOS

That… looks kind of wrong? Why’s all the head stuff in the body? Huh?

So just a few minutes ago I opened up my text editor and opened the relevant file to make a fix, and I saw this:

HTML in vim with syntastic

Hell yeah! Where was that error message when I first introduced the problem?

Well, it was nowhere, because I only started using that plugin like last week, and I introduced the problem a full 615 days ago while sloppily porting my layout from haml to Jekyll.

Probably my moral is: be careful out there! And pay attention to your inklings.

Here’s my second moral: even after making the fix, there are still some errors reported by the plugin because it’s confused by the Liquid tags, which aren’t valid HTML! I’m going to push the fix and use the online validator instead. Sooooo tools aren’t a panacea.