Other Unixes
Various people interested in running Chrome on non-Linux unixes have sniffed around the project and eventually someone stepped up: there's a FreeBSD port that seems to work for some people. (I notice they've recently updated their page to ask for money; I'll note it seems pretty legit to me, since I have firsthand experience to tell you that author has put a lot of time into it.)
But dumping a multi-hundred-kb patch file is not enough to consider a product ported — all of the code ought to land the upstream Chrome tree, and quickly since it will rot quickly. This burden has fallen instead to an enthusiastic OpenBSD developer, who has taken the FreeBSD patch and started on this perhaps larger task: tediously splitting the patch up into bite-sized reviewable chunks, and then modifying each through the code review process (frequently resulting in larger changes than the original port). I feel like I've looked at twenty patches from him so far and more come every week.
Not to be left behind, recently I've also been seeing and reviewing patches from someone working on getting things to run on Solaris, though my perception is that it is much farther from working. Had I time to get multiple interns perhaps I'd have allocated some to these projects; in retrospect they also would've been good summer of code projects.
Porting from Linux in theory shouldn't be too much harder than just
recompiling, but practice is practice because it differs from theory.
The bulk of the patches just extend the ifdefs and build rules to add
the new platforms. When we only had three platforms to worry about,
we didn't go to much effort to make a distinction between
Linux-specific bits, marked with OS_LINUX, and "stuff that generally
is used on free Unix-like operating systems", such as making dotfiles
in your home directory, X11 clipboard behaviors, or GTK.
For the decent amount of code we do share between Linux and the Mac
(e.g., the IPC subsystems between Mac and Linux are nearly identical,
and implemented in terms of Unix domain sockets) there is a shared
OS_POSIX define already in use, but there is also some code that is
Linux-specific; it's a waste of time to try to anticipate in advance
the right layer for abstractions (like, say, how we currently find our
binary path by looking in /proc). The majority of the shared code,
however, is in bits like GTK that are going to be literally identical
across Linux/*BSD/Solaris and perhaps others.
The initial temptation was to make some sort of
OS_UNIX_THAT_ISNT_MACOSX define. But nobody could come up with a
good way to describe what that actually means, and instead we now we
have a larger set of feature-related defines, like TOOLKIT_GTK (that
is, the UI is implemented matching the GNOME interface guidelines),
USE_X11 (necessary for all of our backing store tricks), and even
USE_NSS (the crypto library used for SSL). The last one is
especially a victory of generalization done by porters because it
turns out for various reasons we're moving towards using NSS on
Windows, and to bring that previously Linux-specific code up on Windows
mostly involved flipping a few defines.
With that said, there's kind of an endless long tail of configurations that will get progressively harder and harder to support — even Linux at all is something like 1% of our user base, and I imagine the BSDs are 1% of that. I expect in the longer term, it will probably be the case that these ports will work like the FreeBSD one, where they get a working tree snapshot going every few months without consistently-working code in the interim. But on the other hand, free software means that if someone wants to run our code on NetBSD, they just need to step up with their editor.