Re: ESC meeting minutes: 2020-02-13
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. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: ESC meeting minutes: 2020-02-13
On Friday 14 of February 2020, Ilmari Lauhakangas wrote: > The minutes I wrote say: > + if there is interest in principle, we can seek independent > funding for a prototype > + prototype would make it easier to evaluate benefits > > Then Stephan was minuted as being opposed to the idea of paying external > devs to do a *full* migration. Nobody is pushing this idea, so there is > no need to be scared even in theory. I see. I got confused by the formulation in the minutes. -- Luboš Luňák l.lu...@collabora.com ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: ESC meeting minutes: 2020-02-13
Luboš Luňák kirjoitti 14.2.2020 klo 14.01: On Friday 14 of February 2020, Ilmari Lauhakangas wrote: Luboš Luňák kirjoitti 14.2.2020 klo 13.52: And FWIW I find the idea of paying somebody external to do a fire&forget conversion rather scary. I'll rather deal with gbuild than with that (and I say that as somebody who's dealt with that in sc/source/opencl). That is not what was proposed. Not by you, but according to the minutes it was. The minutes I wrote say: + if there is interest in principle, we can seek independent funding for a prototype + prototype would make it easier to evaluate benefits Then Stephan was minuted as being opposed to the idea of paying external devs to do a *full* migration. Nobody is pushing this idea, so there is no need to be scared even in theory. Ilmari ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: ESC meeting minutes: 2020-02-13
On Friday 14 of February 2020, Ilmari Lauhakangas wrote: > Luboš Luňák kirjoitti 14.2.2020 klo 13.52: > > And FWIW I find the idea of paying somebody external to do a > > fire&forget conversion rather scary. I'll rather deal with gbuild than > > with that (and I say that as somebody who's dealt with that in > > sc/source/opencl). > > That is not what was proposed. Not by you, but according to the minutes it was. -- Luboš Luňák l.lu...@collabora.com ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: ESC meeting minutes: 2020-02-13
Luboš Luňák kirjoitti 14.2.2020 klo 13.52: And FWIW I find the idea of paying somebody external to do a fire&forget conversion rather scary. I'll rather deal with gbuild than with that (and I say that as somebody who's dealt with that in sc/source/opencl). That is not what was proposed. Ilmari ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: ESC meeting minutes: 2020-02-13
On Thursday 13 of February 2020, Thorsten Behrens wrote: > Luboš Luňák wrote: > > [gbuild issues] > > Is there a list somewhere? > > While searching BZ for open issues on gbuild, this very apropos quip > came up: > > "mst: the magic of autoconf, randomly enabling features depending on > what's installed on the build machine --_rene_: that's only magic of > broken autoconf scripts -- mst: when's the last time you saw > non-broken autoconf script?" Actually what I'm asking about (or questioning, even) is primarily the justification. While there would be benefits to moving to something newer, so would there be costs, and the justification preferably shouldn't include unreasonable expectations (back in the day I found writing custom CMake features harder than autotools), corner cases (IMO the usual developer doesn't need non-trivial understanding of the build system features) or even unfairly blaming the current system (you can have randomly enabled features with any build system; and some of the stupid things about gbuild have to do with stupid decisions rather than with the build system itself). I find your paragraph below more convincing than the whole list from the minutes including the two blogposts. And FWIW I find the idea of paying somebody external to do a fire&forget conversion rather scary. I'll rather deal with gbuild than with that (and I say that as somebody who's dealt with that in sc/source/opencl). > I'm not massively enthusiastic to touch something as central as > gbuild. That said, there's also a cost having to rely on something as > complex as that, and being the only project maintaining it. Broadly, > people are moving away from autotools and make, so innovation > (e.g. the IDE integration like CMake recently got blessed with) will > increasingly happen elsewhere. > > So the ESC basically said "let's hear the meson sales pitch first". -- Luboš Luňák l.lu...@collabora.com ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: ESC meeting minutes: 2020-02-13
Luboš Luňák kirjoitti 13.2.2020 klo 19.57: 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. By "newcomers" I mean everyone without solid experience with writing makefiles. On my own part I remember the frustration when wrestling with the Help content htmlisation. I had to give up and wait for gbuild/make gurus to solve everything and I was not the only one. Not a very efficient way of working. I will get back to this after interviewing people involved in autotools -> Meson migrations, so we have something more concrete to chew on. Ilmari ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: ESC meeting minutes: 2020-02-13
Hi Luboš, Luboš Luňák wrote: > [gbuild issues] > Is there a list somewhere? > While searching BZ for open issues on gbuild, this very apropos quip came up: "mst: the magic of autoconf, randomly enabling features depending on what's installed on the build machine --_rene_: that's only magic of broken autoconf scripts -- mst: when's the last time you saw non-broken autoconf script?" I'm not massively enthusiastic to touch something as central as gbuild. That said, there's also a cost having to rely on something as complex as that, and being the only project maintaining it. Broadly, people are moving away from autotools and make, so innovation (e.g. the IDE integration like CMake recently got blessed with) will increasingly happen elsewhere. So the ESC basically said "let's hear the meson sales pitch first". Cheers, -- Thorsten signature.asc Description: PGP signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: ESC meeting minutes: 2020-02-13
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? > + 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 -- Luboš Luňák l.lu...@collabora.com ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice
