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
