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

[Jose Fonseca]

On 22/03/17 20:57, Dylan Baker wrote:
> Quoting Jose Fonseca (2017-03-22 10:59:10)
>> On 17/03/17 02:28, Brian Paul wrote:
>>>
>>> [snip]
>>>
>>> Sure, I'd like to see one build system instead of two.  Meson supports
>>> Windows so that's good.  But the big issue is our automated build
>>> system.  Replacing SCons with Meson could be a big deal in that
>>> context.  It would at least involve pulling Meson into our toolchain and
>>> rewriting a bunch of Python code to grok Meson.  I'd have to go off and
>>> investigate that to even see if it's a possibility.  Maybe next week.
>>
>>
>> I don't have any experience with Meson.  But for the record I don't have
>> much love for SCons.  I long stopped using SCons for anything but Mesa.
>>
>> And my have good experience with cmake + ninja/msvc is positive.  So
>> tools with similar architecture sound good overall.
>>
>> In fact, knowing what I know now, if I could go back in time, to when I
>> evaluated CMake and SCons, I'd chose CMake.
>>
>>
>> BTW, it seems that newer SCons will drop Python 2 support [1], which
>> might force us to rewrite a lot of SConsfiles/scripts any way.  So
>> perhaps that's a good time to evaluate migrating to something else.
>>
>>
>>
>> That said, moving to another build system is always a herculian task.
>> Thought the benefit of having a single build system is appealing and
>> might save time down the line.
>>
>>
>>
>> But there are many questions I have about Meson:  how confident are we
>> on Meson?  Are big projects using it?  How sure are we that it won't
>> become abandonware in a few years time?  How does it compare with other
>> newer gen build systems?
>>
>
> Here's a not so complete list: https://github.com/mesonbuild/meson/wiki/Users
>
> Notably gnome is moving to meson (and some parts already use it), weston and
> libinput have ports, libepoxy uses meson, and gstreamer is using meson. I
> can't say for sure it's going to be around forever, but its been in development
> since late 2012 and still lands several patches a day, they were responsive to
> me when I sent a patch (that I still need to respin), and they seem to be
> picking up momentum from downstreams.
>
> As to how it compares to other build systems, it's fairly different than cmake
> and scons, it's much less scripting and much more declarative, you can look at
> the libdrm patch or the meson in libepoxy (which is more mature) to see the
> syntax. It doesn't expose python or a full scripting language, though it does
> have some fairly simple logic like if/elif/else and foreach, and they support
> modules that add functionality, but need to be merged upstream, this is how
> pkgconfig writing is implemented, for example. One of the things that it does
> better than autotools and (IMHO) cmake, is dependency management, in most cases
> it requires no special handling, the only case it does in mesa (so far) is for
> local python module dependencies in generators. I think that these are actually
> strengths of meson, it's simplicity makes it easy to understand and use.
>
> For support, it's written in pure python (using only the stdlib with no
> external deps), and requires python 3.4+. It has backends for ninja on Linux,
> ninja and visual studio on Windows, and xcode on macOS; Clang, GCC, and MSVC
> are considered first class compilers, some others might work, but are
> unsupported.
>
> I have a partial port of piglit to meson that I put together to see what
> porting from cmake to meson was like (with no plans to send to the list), I can
> push that somewhere for you to look at if you want to see the difference.
>
>>
>> We also have special requirements: one is cross-build from Linux to
>> MinGW, which on Mesa case requires building portions of the tree twice
>> -- once for host -- another for cross-mingw.
>
> Cross compiling for mingw is supported, and it provides a way to differentiate
> the build, host, and target machines [1], I've cross compiled for
> aarch64-linux-gnu, and it was trivial (I've been told autotools has a flag for
> this, but the meson approach is to write an ini file once, and use it again and
> again), and the first example of cross compiling is using mingw from linux [2].
>
> [1]https://github.com/mesonbuild/meson/wiki/Reference-manual#build_machine-object
> [2]https://github.com/mesonbuild/meson/wiki/Cross-compilation

Thanks for the info.

It still scares me a bit that most Meson users are mostly Linux focused.

Another tool I heard good about but have not direct experience is 
https://bazel.build .  Any thoughts about it?



Jose