On Thu, Mar 16, 2017 at 5:25 PM, 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 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. 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. my 2 cents. Alex _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
