Understanding how your environment’s controls are designed can be a very helpful thing. Consider this developer talking aboutgetting Chromium to work on Linux.

When Chromium was first announced in the beginning of September I was very surprised that it was a Windows only application given that WebKit is very much cross platform. The past few weeks I have been spending a little bit of time here and there hacking on the source code and thought I would write an update for those who are interested on the status of the native port of Chromium on Linux.

On day one you could checkout the source code on Linux and you could build some things. Of course all that you were building were some object files, nothing more, not even Webkit was being built. There was no test application, no linking and no Chrome.

From what I can tell nearly all of the development for Chrome was done on Windows in Visual Studio. There is even a c# tool that can be found in the sources. This lead to the case where the normal course of action when something didn’t build on Linux was to just disable it. So by the time that the release was made nearly nothing was being built. I am also pretty sure that the Chromium port was entirely different then the Android port

Starting with the glue directory I went file by file fixing the compiler errors. Developed in Windows there was fun fixes such as the Windows “String.h” include that was not used, but caused build breakage on non-Windows platforms. Many patches later a lot more builds and Linux. Linux is part of the build farm so as each file was fixed and enabled it became one more file that Windows developers could not break or their change would be reverted.

Once he gets the code to the point it will compile under Linux, he then uses the controls that exist in the software quality process to prevent the mainline Windows developers from checking in code that undoes his work on the Linux port. This is why automated software quality tools are generally a Good Thing.