Tracing where build time is spent

[Luboš Luňák]

 Hello,

 I've pushed https://gerrit.libreoffice.org/c/core/+/88754 , which allows 
viewing what actually happens during building. Exact instructions are in 
https://cgit.freedesktop.org/libreoffice/core/tree/solenv/gbuild/Trace.mk . 

 At http://ge.tt/9z4s0J13 I've uploaded a trace 
of './autogen.sh --enable-dbgutil --disable-java && make' Windows build on 16 
HT core Ryzen 7 that takes about 70 minutes, viewable using the 
chrome://tracing URL in Chromium.

 A couple of observations:

- The build gets to building actual LO sources only after half the build time. 
This means that the default of building most externals ourselves is kind of 
silly, especially on Windows without ccache. It would make sense to have 
some --with-system-libs=auto which would try to use as much system stuff as 
possible and print a summary, and --enable-debug/dbgutil could default to it. 
Even on Windows, e.g. python3 is an optional component installed by MSVC, I 
don't know why we don't even try to use it.

- About 9 minutes are spent building only nss and firebird, both apparently 
doing -j1 builds, and nss blocks most of LO sources, and nss itself is 
blocked by python3. IIRC somebody has already tried to do something about 
these and didn't manage. Nss's build page says that the recommended build is 
actually using some Mozilla build tool instead of autotools, has somebody 
tried that?

- Unittests in dbgutil take as much as half the time it takes to compile .cxx 
sources (not counting externals not built by gbuild). It could make sense to 
revisit using -O1/-Og, at least for Jenkins builds. Also, now that we do have 
Jenkins builds, maybe finally plain 'make' could be sensible and not run 
tests all the time.

- It takes 3 minutes to unpack the 100MiB bzip2 tarball of boost, which 
unpacks to about 0.5GiB of stuff including generated html docs. It would be a 
cheap gain to get rid of all doc/ example/ test/ and repack it as .xz .

-- 
 Luboš Luňák
 l.lunak at collabora.com