On Thu, Mar 16, 2017 at 5:25 PM, Dylan Baker <dy...@pnwbakers.com> 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>
Probably mkdir... > > 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 haven't looked at meson or your patches in detail, but autotools supports 2 very important use-cases very well: 1. ./configure --help 2. Cross-compilation with minimal requirement from the project being built Can you comment on how these are handled in meson? Cheers, -ilia _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
