Make Chromium build

[dmik]

This is a continuation of https://github.com/bitwiseworks/qtwebengine-os2/issues/1 dedicated to building the original Chromium source code.

Note that the build process itself is intended to be started using qmake makefiles from within the qtwebengine repository. But qmake does no more than simply runs gn to generate ninja build files and then runs ninja. I.e. prepares and starts a native Chromium build process. While this process can be then started manually from $(BLDROOT)/qtwebengine/src/core/debug (or release) by calling ninja like this:

cd "$(BLDROOT)"/qtwebengine/src/core && "$(BLDROOT)"/qtwebengine/src/3rdparty/ninja/ninja.exe -v  -C "$(BLDROOT)"/qtwebengine/src/core/$(BUILD_TYPE) QtWebEngineCore

it's still recommended to use qmake makefiles to avoid any de-synchronization with Qt sources.

[StevenLevine]

To run at time critical, I tend to use setpri.exe. I really should spend some time with nice6. It's probably much more functional. It was written by an IBM employee and Dave Yeo got it released under the Apache license, which is a good thing.

The cc1plus OOM message looks a bit odd. Maybe it was not well tested.

Given the size of the source files, the memory utilization is not unexpected. The question is how to reduce it. Back when I was a kid and 64-bit addressing was a dream, we would never write a production compiler that could not spill data to a work file when needed. It would not surprise me if it is not possible to build chromium on a 32-bit Linux.

We might need to look a refactoring some of the larger files. The problem is how to merge future updates into the the refactored files. This issue came up for me recently in a slightly different context. My brother is involved in a project where a piece of his code is getting refactored for buzzword compilance (aka micro-services). The problem is how to backport cherry-picked fixes from the trunk to the maintenance branches that are based on the code as it existed before refactoring. Git provides some support for these kinds of merges, but we have not you come up with a fully automatable methodology.

[dmik]

With about 2900 compilation units left to go after some source changes, I'm starting getting kernel panic (and reboots) again. Sigh. Here is the postmortem (or almost postmortem) screenshot:

My guess is that it's OOM again from CC1PLUS.EXE (there are 6 processes again as this is what NINJA does by default here). I will try to lower it to 3 processes...

[dmik]

@StevenLevine yes, I second your thoughts about 64/32 bits and compiler optimization. It's clear that current GCC builds target 64-bit systems and Chromium compilation failing on a 32-bit Linux wouldn't make me surprised either.

Refactoring Chromium sources? Yes, that's an option but given how numerous and complex these these sources are and also further merging problems you mentioned this might become a real head ache. Frankly, I would invest this (potentially big) amount of time & effort into optimizing GCC instead. By using temporary on-disk "caches" or whatever. This will of course slow down compilation further but will make it at least possible. Another option (which I'm currently exploiting) is reducing parallelism (to make sure there is no more than 1-2 heavy processes at a time). But this is going to slow down compilation time even more...

[dmik]

With a few bits fixed (and a few changes still pending — collecting more patches) the number of compilation units left to go is around 1200.

As part of this process I need to add PM support to some of the remaining parts.

[dmik]

With a bunch of the above commits I got all 15k compilation units built! I'm pretty sure there will be a bunch of unresolved externals (platform specific parts of C++ classes intended to reside in separate source files which we miss on OS/2 yet). I expect it several dozen of missing exports. A link stage will show the exact list but I'm stuck there due to too long command line. Will continue in https://github.com/bitwiseworks/qtwebengine-os2/issues/1 with that as it belongs to the Qt side of things (this command is generated by qmake).

[dmik]

The above commits is a result of ~two weeks of work (including all distractions like https://github.com/bitwiseworks/libc/issues/82, https://github.com/bitwiseworks/libc/issues/83 and https://github.com/bitwiseworks/libc/issues/84).

With those commits the, DLL containing Chromium successfully links now. It's named Qt5WebC.dll (with an import libraryQt5WebEngineCore.lib) and has a size of 250 megabytes. The DLL itself appears to be fine (at least PMDLL loads it without any problem).

[dmik]

Note that there is a lot of stubs for the OS/2 platform instead of real code (done so to speed up getting first results ASAP). These stubs are mostly grabbed from the code for Fuchsia OS and basically do nothing ATM. It's about to be seen which ones of them are actually needed for Qt (and therefore will have to be implemented). This will be done in separate tickets. Closing this one as its main ticket is reached.