Hi Dylan, On 16 March 2017 at 21:25, Dylan Baker <dylan@xxxxxxxxxxxxx> wrote: > Why bother, and why would we want this? │~ > > First it's written in python, which means the potential developer base > is massive. And it provides a recursive view for humans, but a > non-recursive view for the system. This is the best of both worlds, > humans can organize the build system in a way that makes sense, and the > machine gets a non-recursive build system. It also uses ninja rather > than make, and ninja is faster than make inherently. Meson is also a > simpler syntax than autotools or cmake it's not Turing Complete by > design nor does it expose python, again, by design. This allows meson > itself to be reimplemented in a another language if python becomes a > dead-end or a bottle-neck. It also makes it much easier to understand > what the build system is doing. > > What's different about using meson? > > Well, apart from a faster builds and less magic in the build system? The > configure flags are different, it uses -D<opt>=<value> more like cmake > than the --enable or --with flags of autotools, although oddly it uses > --prefix and friends when calling meson, but not with mesonconf, there's > a bug opened on this. Meson also doesn't support in-tree builds at all; > all builds are done out of tree. It also doesn't provide a "make dist" > target, fortunately there's this awesome tool called git, and it > provides a "git archive" command that does much the same thing. Did I > mention it's fast? > > Here are the performance numbers I see on a 2 core 4 thread SKL, without > initial configuration, and building out of tree (using zsh): > > For meson the command line is: > time (meson build -Dmanpages=true && ninja -C build) > > For autotools the command line is: > time (mdkir build && cd build && ../autotools && make -j5 -l4)<Paste> > > meson (cold ccache): 13.37s user 1.74s system 255% cpu 5.907 total > autotools (cold ccache): 26.50s user 1.71s system 129% cpu 21.835 total > meson (hot ccache): 2.13s user 0.39s system 154% cpu 1.633 total > autotools (hot ccache): 13.93s user 0.73s system 102% cpu 14.259 total > > That's ~4x faster for a cold build and ~10x faster for a hot build. > > For a make clean && make style build with a hot cache: > meson: 4.64s user 0.33s system 334% cpu 1.486 total > autotools: 7.93s user 0.32s system 167% cpu 4.920 total > > Why bother with libdrm? > > It's a simple build system, that could be completely (or mostly > completely) be ported in a very short time, and could serve as a tech > demo for the advantages of using meson to garner feedback for embarking > on a larger project, like mesa (which is what I'm planning to work on > next). > > tl;dr > > I wrote this as practice for porting Mesa, and figured I might as well > send it out since I wrote it. > > It is very likely that neither of these large patches will show up on the > mailing list, but this is available at my github: > https://github.com/dcbaker/libdrm wip/meson > While I can see you're impressed by Meson, I would kindly urge you to not use it here. As you look closely you can see that one could trivially improve the times, yet the biggest thing is that most of the code in libdrm must go ;-) As the port is not 1:1 wrt the autoconf one, the performance numbers above are comparing apples to oranges. If you/others are unhappy with the build times of libdrm - poke me on IRC. I will give you some easy tips on how to improve those. You have some good python knowledge - I would kindly urge you to improve/rewrite the slow and/or hacky python scripts we have in mesa. This is a topic that was mentioned multiple times, and a part where everyone will be glad to see some progress. Thanks Emil _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
