<div dir="ltr">On Thu, Mar 16, 2017 at 8:03 PM, Jason Ekstrand <<a href="mailto:jason@jlekstrand.net" target="_blank">jason@jlekstrand.net</a>> wrote: <div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On March 16, 2017 5:41:24 PM Emil Velikov <<a href="mailto:emil.l.velikov@gmail.com" target="_blank">emil.l.velikov@gmail.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> On 17 March 2017 at 00:21, Dylan Baker <<a href="mailto:dylan@pnwbakers.com" target="_blank">dylan@pnwbakers.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Hi Emil, Quoting Emil Velikov (2017-03-16 16:35:33) <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> 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 ;-) </blockquote> Perhaps I wasn't clear enough, I don't really expect this to land ever. I sent it out more because I'd written it and it works and is a useful demonstration of meson+ninja performance. Obviously 20 seconds -> 5 seconds isn't a huge deal :); but in a larger project, consider that a 4x speedup would be 4 minutes to 1 minute, and that is a huge difference in time. </blockquote> You are still failing to see past your usecase. As said before - if there's any need to improve things say so. Note that you simply cannot apply the 1000x speedup in any situation. </blockquote> Yes, you can't just linearly apply any scaling factor. However, when you build mesa on a machine with a decent number of threads (I think our build machine for the CI system has 32 threads), autotools+make is slow as mud. Also, there's very little you can do to speed up configure since it's a pile of shell and perl that inherently runs single-threaded and is fairly complex due to mesa's complicated dependencies. <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> As the port is not 1:1 wrt the autoconf one, the performance numbers above are comparing apples to oranges. </blockquote> I fail to see what I'm missing from meson that would have an effect on the times I reported. There are some files that are installed by autoconf that I didn't bother to install with meson (because I don't expect this to land). Since I didn't time installs, I don't see how it isn't an apples to apples comparison. </blockquote> You already (explicitly) mentioned some differences. Admittedly not a deal breaker. <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> I understand that libdrm is a pessimal case for recursive-make since most sub folders contain < 5 C files, However, even if you were to flatten the make files meson+ninja would still be faster when you consider that meson configures and builds faster than autotools configures. </blockquote> That's correct. If is so concerned - they should slim down the <a href="http://configure.ac" rel="noreferrer" target="_blank">configure.ac</a> ;-) </blockquote> There are real limits as to what you can do there. <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> 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 </blockquote> The real goal here is to do mesa (in case I didn't make that clear either), and the advantage for mesa is not just performance, it's that meson supports visual studio on windows; which means that we could hopefully not just get faster builds, but also replace both autotools and scons with a single build system. </blockquote> Yes that was more than clear. Yet it won't fly, I'm afraid. The VMWare people like their SCons, </blockquote> How much? I would really rather the VMWare people speak on behalf of VMWare. Meson is the single best shot we've ever had for replacing both with one build system. I'm sure the VMware people would like to have a build system that gets maintained by the community as a whole. </blockquote><div> </div><div>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. </div><div>-Brian </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> and Meson is not a thing on neither BSD(s), Solaris (and derivatives) nor Android :-\ </blockquote> I have trouble bringing myself to care. The BSDs need to stop using 10 year old compilers. It can be made to work on Solaris and BSD if someone bothered to put a little work into it. Besides, given that large chunks of GNOME are switching they're going to have to make it work some day soon anyway. Android is a bit unfortunate. Mesa is one of the few projects that let's the Android people carry their build system in-tree and I would like to keep that going if it were practical. Dylan and I have talked about this a decent bit and one potential solution is to see if the meson people would accept an Android back-end. Then we would be down to a single build system (wouldn't that be nice). <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> If there's something "slow" say what/where and we can improve upon things. You seems to be rewriting $world because someone sold you that A is the holy grail. </blockquote> I don't think that's fair. No, Meson is not the holy grail but it is the closest anyone has yet been able to come to a viable autotools replacement. Speed is only one aspect to this. Unifying the Linux and windows builds is also a significant advantage. Also, autotools is objectively terrible and having a build system that's modifiable be mere humans without the need for hours of pouring over documentation only to find that you did it wrong anyway is a definite plus.<div class="HOEnZb"><div class="h5"> _______________________________________________ mesa-dev mailing list <a href="mailto:mesa-dev@lists.freedesktop.org" target="_blank">mesa-dev@lists.freedesktop.org</a> <a href="https://lists.freedesktop.org/mailman/listinfo/mesa-dev" rel="noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/mesa-dev</a> </div></div></blockquote></div> </div></div>