Date: prev next · Thread: first prev next last
2020 Archives by date, by thread · List index


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.

Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.