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

Fri Mar 24 21:20:30 UTC 2017

On Fri, Mar 24, 2017 at 2:16 PM, Jose Fonseca <jfonseca at vmware.com> wrote:

> On 24/03/17 20:08, Kristian Høgsberg wrote:
>
>> On Fri, Mar 24, 2017 at 12:44 PM, Jose Fonseca <jfonseca at vmware.com>
>> wrote:
>>
>>> On 24/03/17 19:10, Kristian Høgsberg 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.
>>>>
>>>
>>>
>>> There's zero overlap between SCons build users and Meson experience, so I
>>> don't see how that would work.  Who would lead the charge?
>>>
>>
>> It sounds like Dylan and the Intel team are interested in doing the
>> meson work. If that's the case, then perhaps you (or other SCons
>> users) would be willing to evaluate the result and see if it meets
>> your requirements for a SCons replacement?
>>
>> Kristian
>>
>
> Evaluating is one thing.  Actually migrating is another.
>
> Brian already said he'd take a look and evaluate.  And I'll help in what I
> can.  I agree we should all evaluate early.
>
>
> But I don't think that the proposal of first migrate scons to meson, then
> in a second separate step migrate autotools to meson, is viable. Like I
> said: there's no knowledge overlap.  The two group of people -- the Meson
> and Windows experts -- will be chasing each other tails.  And all that
> while, the build will continue to be broken or diverge because master dev
> will go on.

I don't think that's true.  I think a decent number of *nix mesa devs will
start using meson as their primary build system.  Also, we'll definitely be
using meson in our CI system because it's so much faster and we have a big
workhorse of a build machine.  Sure, there will be breakage, but I don't
think it will be one-sided.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20170324/f63bf634/attachment.html>