Like most cross platform programs, LO has its own platform abstraction layer called Sal. According to experience, these kinds of libraries usually have the nastiest build configurations requiring a ton of configure checks and the like. The most prominent example is GLib, whose configure steps are awe-inspiring.
Sal turned out to be fairly simple to port to Meson. It did not require all that much in platform setup, probably because the C++ stdlib provides a lot more out of the box than libc. After a few hours I could compile all of Sal and run some unit tests. The results of the experiment can be found in this Github repo. The filenames and layouts are probably not the same as in the "real" LO build, but for a simple experiment like this they'll do.
So what did we learn?
- Basic compilation seems to be straightforward, but there were some perennial favourites including source files that you must not compile standalone, magic compilation defines, using declarations hidden at the bottom of public headers behind #ifdefs and so on.
- There may be further platform funkiness in the GUI toolkit configuration step.
- A lot of code seems to be generated from IDL files, which might require some work.
- Meson's Java support probably needs some work to build all the JARs.
- Meson should scale at least to building LO itself, building all dependency projects at the same time is a different matter.
How would one express LO's sheer size with a single number?
It has more than 150 000 lines of Makefiles.