Untitled

<cloph> K​ompilainenn: it boils down to that whenever you need to do something that is not "the intended way" to do stuff, rules /will/ get complicated. I have no doubt that cmake is nice for an android project or similar, but even when they say they make cross-compilation easy: That's an empty promise/the proof is in the pudding. https://wiki.openoffice.org/wiki/Build_System_Analysis#CMake summaries some of the reasons back then. The problem of not really having a nice way to incrementally switch over is one of the biggest hurdles in creating a POC that would change my perception. LibreOffice is a huge project, that also uses external libraries that themselves use different build systems, and bringing that in compliance with cmake without also writing custom rules like we do now in gnu make is impossible. Also I just don't think cmake rules are any easier than makefile rules/targets. We have some unnecessary bloat dating back from the conversion/when having two systems simultanesously that might make the makefile rules look more complicated than they really are. Whenever someone has problems with makefile rules my #1 suggestion is: Write them without our macro calls first, don't try to copy'n'paste other rules because you think that is necessary. None of our calls are all that special.

 

<cloph> And yeah, the excourse with meson just reaffirmed my scepticism against build tools that configure stuff for you by "magic"

 

<cloph> And yeah, there is some portion of don't touch it if it works, as I don't really see make as a bottleneck in our build, even on windows where initial parsing of the makefiles takes a while, our build as a whole takes long, so that doesn't really matter all that much (and again it would have been proven first that a cmake based system would be significantly faster in the pre-build-bookkeeping/dependency generation steps)

 

<cloph> (and of course the makefiles themselves can also be optimized to not use so many shell/external process calls, reduce the number of makefiles (most if not all our splits are out of convention, not out of necessity)

 

<cloph> but if someone wants to start an attempt: Just start by replicating our current configure step in cmake - most of our checks are custom, not just "is header xy present". Maybe that will arlready be enough to say: Nah, I'm good...

 

<cloph> (also just reminded me about people hating on perl because of our installer code - sure it is written in "perl", but it is not really "perl", most certainly not nice perl, and pretty much overengineered. just last week I came across some stuff that bothered me enough to get rid of https://gerrit.libreoffice.org/c/core/+/185021 - and as written that's just the tip of the iceberg. And similar thing with our gbuild. Some stuff is using 4 or 5 levels of indirections that might have been useful at some point in the dual-build-times for one part, but people just copied'n'pasted that stuff over to other parts where it wasn't required in the first place, and then "If I don't touch it, I won't be responsible if it breaks" or "I have more important stuff to do" results in some level of bitrot.. But I'd say that is all existing issues, these days new concepts aren't introduced anymore/the build as a whole is already stable. It is unlikely that new stuff requires writing new makefile macros (well, adding a new sub-buildssytem like meson is an exception, but even then it was just simple macros and no magic rule generation / creating stuff that's eval'd again)