On Thu, Oct 16, 2014 at 10:17 PM, Michael Shal <ms...@mozilla.com> wrote:
> Hi Jussi, > > Thanks for writing in about this! Am I right in thinking that meson is > more of a meta build system, like CMake, gyp, or our in-house moz.build? It > essentially generates build files for another system (ninja) to consume? If > so, have you looked at moz.build and compared the two? > Yes, that is correct. An elevator pitch phrase for Meson could be "Like CMake but with better syntax and usability". I've had people describe it to me in those words without knowing that it was my original design target, so at least that part seems to have succeeded. :) > I watched your lightning talk with great interest. The library linking > feature seems particularly handy - have you considered trying to implement > support for this in the toolchain rather than in the build system? Ie: if > the linker knows to look for a separate ABI file rather than the full > shared library when linking, the regular file access patterns could be used > to avoid re-linking all the binaries even without domain-specific knowledge > in the build system (so it should work for all build systems out of the > box, more or less). > That could be done but it would require first specifying a format for the ABI file and then patch all toolchains to support it. This would take lots of coordination and months of work. By doing it in the build system I could make it happen in a few days (especially since I just stole the implementation from LibreOffice). That being said if any toolchain starts providing these ABI files, I'll be happy to add support for them in Meson. Currently something like this is already done in Meson's Fortran support, where binary ABI files are part of the language. > Correct me if I'm wrong, but it seems that most of the other features you > describe are really features of the underlying toolchains, and not of the > build system. For example, pre-compiled headers, unity builds, cross > compilation, etc can be done in other build systems by adding in the right > compiler flags or targets. Is there a reason you consider this to be much > improved in meson? > Most projects don't use precompiled headers in Linux for the simple reason that they are incredibly difficult to get to work reliably. If your build system does not support them natively, getting them to work is a nightmare. On the other hand precompiled headers are very commonly used in Visual Studio, where you just specify "for this target use this precompiled header". Meson provides the same ease of use on all platforms. All the mind numbingly boring and tedious work of herding compiler flags and the like has been done once, so Meson users can just use the result and not worry about it. Meson also aims to provide proper solutions rather than project specific one-offs. As an example, Meson can generate a unity build for a target where some source files are generated by an executable that is by itself generated during the build. WRT performance, have you tested scalability at all? I couldn't find any > info about it on your site, aside from the one test with 1000 files. I > wanted to run a few tests myself (with eg 1k, 10k, 100k files) to see how > it scaled, but I hit a maximum recursion error even when trying to > reproduce the 1k test :( > That should not be happening. Can you post full info so I can debug? I haven't tested 100k but configuring a Meson project of 10k files takes a few seconds. In practice what cause slowdowns are system introspection tests (i.e. the equivalent of Autoconf). > Also, I couldn't find any discussion on correctness. In the talk and on > your website, many of the performance comparisons are full build times, > which indicates to me that you likely consider a clean/full-rebuild part of > the normal workflow. But with a correct build system, you should only be > doing a full build once (the first time you download & build the project), > which means as a metric it isn't as useful as the incremental build time > (and the scalability of the incremental build times :). However, being > "correct" isn't as simple as merely re-compiling the set of C files that > include a header file that you changed. It also means taking into account > changes in the build configuration (ie: editing/adding/removing a > meson.build file), removing stale build targets, etc. I'd be interested to > hear how you have tackled this in meson. > Incremental build speed is really fast. Running ninja on a fully up to date build tree takes just fractions of a second even for 10k files. Correspondingly if you have changed something, Meson will start compiling code almost immediately after you have executed the build command. Incremental build speed is so important that it is one of the major reasons Meson does not have a Make backend: Make simply can not be made fast enough. Luckily we have Ninja, which is made of awesome. Correctness is extremely important for Meson, even more so than speed. For dependencies, Meson uses dependency information that compilers can be told to generate during compilation. This ensures that the dependency tree is always exact and optimal. Build outputs also implicitly depend on the command line used to generate them. If you change your build definition (add target etc), Meson will automatically detect that and reconfigure itself. What this means that if you, for example, change compiler flags for just one target, Meson will recompile only that target and things that depend on it. On a related note, if there are people coming to LCA2015, there will be a presentation on Meson by me: http://linux.conf.au/schedule/30101/view_talk?day=thursday
_______________________________________________ dev-builds mailing list dev-builds@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-builds
