ESC meeting minutes: 2020-02-13

[Luboš Luňák]

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.lunak at collabora.com