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

[Jose Fonseca]

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.


Jose