[Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Rob Clark]

On Fri, Mar 24, 2017 at 3:10 PM, Kristian Høgsberg <hoegsberg at gmail.com> wrote:
> On Fri, Mar 24, 2017 at 6:42 AM, Jose Fonseca <jfonseca at vmware.com> wrote:
>> On 23/03/17 01:38, Rob Clark wrote:
>>>
>>> On Wed, Mar 22, 2017 at 9:18 PM, Jonathan Gray <jsg at jsg.id.au> wrote:
>>>>
>>>> On Wed, Mar 22, 2017 at 01:10:14PM -0700, Dylan Baker wrote:
>>>>>
>>>>> On Wed, Mar 22, 2017 at 12:40 PM, Alex Deucher <alexdeucher at gmail.com>
>>>>> wrote:
>>>>>>
>>>>>> I guess I'm a little late to the party here, but I haven't had time to
>>>>>> really let all of this sink in and actually look at meson.  It doesn't
>>>>>> seem so bad with a quick look and I think I could probably sort it out
>>>>>> when the time came, but there would still be a bit of a learning
>>>>>> curve.  While that may not be a big deal at the micro level, I have
>>>>>> concerns at the macro level.
>>>>>>
>>>>>> First, I'm concerned it may discourage casual developers and
>>>>>> packagers.  autotools isn't great, but most people are familiar enough
>>>>>> with it that they can get by.  Most people have enough knowledge of
>>>>>> autotools that they can pretty easily diagnose a configuration based
>>>>>> failure. There are a lot of resources for autotools.  I'm not sure
>>>>>> that would be the case for meson.  Do we as a community feel we have
>>>>>> enough meson experience to get people over the hump?  Anything that
>>>>>> makes it harder for someone to try a new build or do a bisect is a big
>>>>>> problem in my opinion.
>>>>>
>>>>>
>>>>> One of the things that's prompted this on our side (I've talked this
>>>>> over with
>>>>> other people at Intel before starting), was that clearly we *don't* know
>>>>> autotools well enough to get it right. Emil almost always finds cases
>>>>> were we've
>>>>> done things *almost*, but not quite right.
>>>>>
>>>>> For my part, it took me about 3 or 4 days of reading through the docs
>>>>> and
>>>>> writing the libdrm port to get it right, and a lot of that is just the
>>>>> boilerplate of having ~8 drivers that all need basically the same logic.
>>>>>
>>>>>> Next, my bigger concern is for distro and casual packagers and people
>>>>>> that maintain large build systems with lots of existing custom
>>>>>> configurations.  Changing from autotools would basically require many
>>>>>> of these existing tools and systems to be rewritten and then deal with
>>>>>> the debugging and fall out from that.  The potential decreased build
>>>>>> time is a nice bonus, but frankly a lot of people/companies have years
>>>>>> of investment in existing tools.
>>>>>
>>>>>
>>>>> Sure, but we're also not the only ones investigating meson. Gnome is
>>>>> using it
>>>>> already, libepoxy is using it, gstreamer is using it. There are patches
>>>>> for
>>>>> weston (written by Daniel Stone) and libinput (written by Peter
>>>>> Hutterer), there
>>>>> are some other projects in the graphics sphere that people are working
>>>>> on. So
>>>>> even if we as a community decide that meson isn't for us, it's not going
>>>>> away.
>>>>
>>>>
>>>> It is worth pointing out that it is currently required by no component
>>>> of an x.org stack.  In the case of libepoxy it was added by a new
>>>> maintainer
>>>> on a new release and even then autoconf remains.
>>>>
>>>> And as far as I can tell nothing in the entire OpenBSD ports tree
>>>> currently requires meson to build including gnome and gstreamer.
>>>>
>>>
>>> but I guess that is conflating two completely different topics..
>>> addition of meson and removal of autotools.  It is probably better
>>> that we treat the topics separately.  I don't see any way that the two
>>> can happen at the same time.
>>>
>>> The autotools build probably needs to remain for at least a couple
>>> releases, and I certainly wouldn't mind if some of the other desktop
>>> projects took the leap of dropping autotools first (at least then
>>> various different "distro" consumers will have already dealt with how
>>> to build meson packages)
>>>
>>> None of that blocks addition of a meson build system (or what various
>>> developers use day to day)
>>>
>>> BR,
>>> -R
>>
>>
>> I tend to disagree.  While we can't avoid a transitory period, when we
>> embark on another build system (Meson or something else) I think we should
>> aim at 1) ensure such tool can indeed _completely_ replace at least _one_
>> existing build system, 2) and aim at migration quickly.
>>
>> Otherwise we'll just end up with yet another build system, yet another way
>> builds can fail, with some developers stuck on old build systems because it
>> works, or because the new build system quite doesn't work.
>>
>> And this is from (painful) experience.
>
> I agree, adding a meson build system should aim to phase out one of
> the other build systems within one or two release cycles. But (and
> maybe that was Robs point) that doesn't have be autotools. What if we
> phase out scons? It doesn't seem like anybody is really attached to it
> and if meson is as good as scons on windows, then if nothing else
> happens we end up with the same number of build systems. What's more
> likely to happen is that a lot of Linux developers (and CI systems)
> will also start using meson, which means that life gets easier for
> vmware wrt maintaining the build system, and easier for all developers
> who have spent to much of their life waiting for autogen.sh.  Then
> decommissioning autotools can be a separate topic as Rob suggests,
> something we'll do when the world is ready.


yup, that was basically my point.. scons seemed like an easier first target

BR,
-R


> Kristian
>
>>
>>
>> So I think we should identify stake holders soon, collect requirements (OSes
>> platforms, etc), make sure the prospective tool meets them, have all
>> stakeholders collaborate on a prototype, them embark on mass migration.
>>
>> That is, if this fails, let it fail early.  If it succeeds, may it succeed
>> early.  Anything but a slow death / zombie life.
>>
>>
>>
>> BTW, how about migrating mesademos to Meson?  It currently has autotools and
>> cmake.  I was hoping that cmake would replace autotools, but I couldn't run
>> fast enough, so I couldn't practice what preached above, hence cmake doing
>> almost but not all what autotools does.
>>
>> And is not a crucial project for Linux distros -- few distros package it --
>> and even if they do, no other package would depend on it.  And is one of
>> those sort of projects that should be easy to port to any build too.
>>
>> Even if we ignore everything else, just replacing autotools + cmake with
>> just one thing would be a net win.
>>
>>
>> Jose
>>
>> _______________________________________________
>> mesa-dev mailing list
>> mesa-dev at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/mesa-dev