----- Original Message -----
> From: "Jussi Pakkanen" <jpakk...@gmail.com>
> To: dev-builds@lists.mozilla.org
> Sent: Monday, October 6, 2014 2:52:32 PM
> Subject: Firefox nspr build experiment with the Meson build system
>
> Hello all
>
> I'm working on creating a new build system called Meson (
> https://jpakkane.github.io/meson/ ). To make sure it can handle the
> requirements of real projects I take random open source projects (usually
> large and complex) and rewrite their build systems in Meson.
>
> For Firefox I tried to see how much effort it would take to configure and
> build nspr including unit tests. After a few hours work I got it working on
> 64bit Linux. It took about 1000 lines of code (~750 of which go to defining
> unit tests). Most unit tests even run successfully. :)
>
> If you want to try it yourself, just get Meson and Mozilla from head and then
> download and extract this file in your source tree:
>
> https://dl.dropboxusercontent.com/u/37517477/mozilla-meson.tar.gz
>
> To configure and build just do this:
>
> mkdir buildmeson
> /path/to/meson.py ..
> ninja
> ninja test (note that since some tests freeze it currently looks like nothing
> is happening)
>
> That's about it. This is obviously not in any way a replacement for the
> current build system (which would be a huge task, yes I read the wiki :-)
> but I hope you find it interesting, even if only from a curiosity point of
> view.
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?
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).
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?
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 :(
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.
Thanks,
-Mike
_______________________________________________
dev-builds mailing list
dev-builds@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-builds
