LibreOffice/core: reading the C++ tree behind the office suite

Pull requests are refused here, so Gerrit is the only real door

Reading the repository description is the fastest way to avoid wasted effort: this mirror takes no pull request, and the description tells contributors not to download a zip archive either. Change review happens on Gerrit, which is what .gitreview in the repository root points at. That constraint shapes everything else. There is no way to sketch a patch in a browser here, no CI run attached to a fork, and no GitHub release page to fall back on; recent releases list for this repository is empty. The GPL-3.0 licence plus the LGPL and MPL texts sitting next to it (COPYING.LGPL, COPYING.MPL) means a derived product carries source obligations, which is a legal question for your own counsel rather than something this README answers. What it does answer plainly is where work goes: the mailing list [email protected] takes messages with no subscription, and IRC on irc.libera.chat in #libreoffice-dev takes questions.

Two doors into the code: UNO extension APIs or the C++ tree itself

The README names two ways in and prefers one. The SDK route builds an extension against the generic UNO APIs, the same interfaces that StarBasic macros drive from inside a document, documented at api.libreoffice.org. The preferred route is working on the C++ base directly, because it compiles and builds your own change, it sidesteps whatever limits the scripting layer imposes, and it is what the project considers simpler for a competent C++ programmer. The trade is concrete: UNO keeps your change out of a full compile but boxes you inside the interface, while the tree route costs build cycles and puts you inside the module's own data structures. With two hundred modules in the repository, picking the wrong entry point is the first mistake worth avoiding.

The layered module map: sal, tools, vcl, framework, sfx2

Layered dependency order is the map worth memorising before reading any file. sal/ is the System Abstraction Layer. tools/ holds basic internal types such as Rectangle and Color. vcl/ is the widget toolkit and the rendering abstraction above it. framework/ is the UNO framework that assembles toolbars, menus, status bars and the document chrome from VCL widgets described by XML in /uiconfig/ files. Under that sits sfx2/, described as the legacy core framework used by Writer, Calc and Draw for the document model, load and save, and action signals, with svx/ holding drawing model helper code that includes much of Draw and Impress. Applications come last: desktop/ holds main() and the bootstrap, whose name the README traces back to a StarOffice desktop, then sw/ for Writer, sc/ for Calc, sd/ for Draw and Impress. Graphics work adds basegfx/, canvas/, cppcanvas/ and drawinglayer/, where drawinglayer/ breaks drawable objects into renderable primitives.

Build baselines that decide your hardware before you start

No install command appears in README.md. The project points you at the TDF wiki build instructions for your platform and at the distro-configs/ directory for the configure switches the TDF builds use, with LODE scripts offered to set up the initial build environment on Windows and macOS. The baselines are strict enough to rule machines out early. Windows needs Windows 10 at runtime and builds under wsl-as-helper with Visual Studio 2022. macOS runs on 11 and builds on macOS 14 with Xcode 16.2 or later. Linux builds need GCC 13, or Clang 18 with libstdc++ 11, on a RHEL 9 or CentOS 9 comparable runtime. Java is required for many modules, with JDK 17 as the baseline and the dependent modules listed in the TDF Development/Java wiki article; Python 3.11 is the baseline, chosen to match SUSE Linux Enterprise Desktop and the Red Hat Enterprise Linux maintenance support version. Android builds with NDK 27 and SDK 30.0.3, and the WASM target needs a browser with SharedMemory support for threads and atomics, built with Qt 5.15 and Emscripten 1.39.8, documented separately in README.wasm. Using Clang with the LibreOffice compiler plugins needs Clang 18, and on macOS you must compile your own Clang because Xcode ships no plugin headers.

includeform.cxx enforces the quote and bracket rule in code review

One compiler plugin decides a style question for you. The rule is exact: use the "..." form when the included file sits next to the including file, and <...> otherwise. UNO API include files always take double quotes, since external users of that API read them. The plugin at compilerplugins/clang/includeform.cxx checks this during builds. Static analysis runs alongside: the README points at PVS-Studio for C, C++ and Java code, alongside Coverity, Best Practices and Weblate badges at the top of the file.

Two hundred module READMEs, and the contradiction between "primary" and peripheral

The repository asks every module to carry a README.md and renders them at docs.libreoffice.org, but the same README that points you there admits two hundred modules exist, many of them of peripheral interest for a specialist audience. That tension is the catch worth stating plainly: the documentation effort is real and the signal is thin. The table that follows is the shortlist the project itself gives when it says "where is the good stuff", and it covers six core modules plus four application directories, not two hundred. Anyone using docs.libreoffice.org as a map should expect the curated table, not the full index, to be the usable part. The same paragraph also invites patches that improve those per module files.

Where a C++ patch does not fit: scripting limits and build cost

The failure modes follow from the two routes already described. Anything you try through UNO hits the limits of a scripting interface the README calls extremely generic, and the workaround is to abandon the SDK route and touch the base class, which means a full build cycle instead. On Linux, Clang users with libstdc++ below 11 are outside the baseline, and macOS users who want the compiler plugins must build their own Clang, because Xcode lacks the plugin headers. The iOS baseline is narrower still: runtime 14.5 and 64 bit devices only, built with Xcode 12.5 and iPhone SDK 14.5, and the README marks that target as being for LibreOfficeKit. None of this is a defect, but all of it is cost, and the fork you submit against a moving master carries that cost again on every rebase.

Editorial conclusion

Adopt LibreOffice/core if you intend to patch the suite in C++ or to study how sfx2, VCL and the UNO framework fit together, and accept a full build cycle for every change. Stay away if you only want a document editor, or if your toolchain is older than the baselines, since master asks for JDK 17, Python 3.11, GCC 13 or Clang 18 and a manual configure step. Before writing a patch, check the configure switches in the distro-configs/ directory and the per platform baselines in README.md, because those decide whether your machine can build master at all.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository