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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

Dylan

Attachment: signature.asc
Description: signature

_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux