ESC meeting minutes: 2020-02-13

[Michael Stahl]

On 13.02.20 18:57, Luboš Luňák wrote:
> On Thursday 13 of February 2020, Miklos Vajna wrote:
>> * Meson build system experiments by Jussi Pakkanen (Ilmari)
>>      + Ilmari’s perspective: want to make the codebase more approachable for
>> newcomers
> 
>   In what way? Newcomers need the Wiki page that basically tells them
> to "./autogen.sh --enable-dbgutil && make", which is neither that difficult
> nor would Meson make it noticeably simpler. Probably the only
> non-approachable parts of the build system is solenv/gbuild, which is not for
> newcomers, and touching that would be similar to hacking on Meson internals,
> which presumably is also not for newcomers.
> 
>>      + understand that we don’t want to drop something that works already
>> (Ilmari) + not yet asking for a decision, but please think about this
>>      + what problem does this solve? (Kendy)
>>        + usually LO breaks the tools
>>      + GNOME / wayland is moving to this from autotools (Ilmari)
>>      + sitting on the fence (Thorsten)
>>        + significant cost to migrate to anything
>>        + there are load of unsolved problems with the build system, though
> 
>   Is there a list somewhere?

not that i know of, maybe we should create one?

* make has problems with paths that contain spaces, so we need 8.3 
filenames enabled for WNT builds

* there's no option to warn on using an undefined function that doesn't 
warn on using an undefined variable (because those are the same thing); 
iirc Norbert implemented this once but upstream didn't like it

* make is a terrible programming language, and this causes some 
usability problems; this might be alleviated by using Guile Scheme 
instead of make functions but few Linux distros ship make with Guile enabled

* it can't incrementally rebuild properly in all cases when you change 
the makefiles themselves (this is some effort to implement but Linux's 
build system can do it iirc)

* there are still a few places where questionable wildcards and "find" 
invocations are used to do bulk operations (but that should be fixable)

* there is very little documentation of the implementation in 
solenv/gbuild... what is most lacking is some architectural overview and 
description of the patters that are used lots of times to solve 
recurring problems

on the other hand, gbuild generally works reliably, incremental builds 
only very rarely cause problems.

>>      + would not be great to pay some external developers to do the
>> migration and then let us maintain it (Stephan)
>> + agreed (Kendy, Cloph)
>>      + better spend funding money elsewhere (Kendy)
>>        + e.g. external libs that can’t build in parallel

yes, please replace Firebird's or OpenSSL's build system first :)

NSS is also affected and there's a humongous patch in our gerrit to make 
it build in parallel with make that really should be upstreamed because 
it would be quite unmaintainable as LO downstream patch... and also NSS 
has grown a 2nd build system using "gyp" in the meantime, which i don't 
know anything about but would presumably introduce new build dependencies.