On 22.01.2014 14:45, Rob Weir wrote:
On Wed, Jan 22, 2014 at 8:32 AM, Andre Fischer <awf....@gmail.com> wrote:
Not quite a week ago I wrote about an idea to use XML files to store the
declarative part of our makefiles: dependencies of libraries on source
files, which resources are to be created and so on. In the meantime I have
found the time to do make (conduct?) an experiment. I am now able to build
module sw from the XML files with the help of the ninja build 'system' [3].
Most of the work of converting the XML files into one single build.ninja
file was done on one weekend. You can see the source code at [1] ([2]
contains everything zipped together).
The results are promising. It runs faster and the build.ninja generator
looks more maintainable than our solenv/gbuild/... makefiles. But I am
certainly biased.
Before I give you some numbers, I should say that I have collected the
numbers totally unscientifically and it may be necessary to add some missing
steps to the ninja build. To the best of my knowledge all C++ files are
compiled, libraries linked, resource files built, XML files copied. Only
the single sw.component file somehow escaped.
I ran my experiments on ani7 2.2GHz, 8GB notebook.
Complete build of a clean module:
gbuild about 9m30s (make -sr -j8)
ninja about 7m15s (ninja)
Cleaning up
gbuild about 40s (make clean)
ninja less then 1s (ninja -t clean)
rebuild after touching one single header (sw/inc/section.hxx)
gbuild about 1m10s (make -sr -j8)
ninja about 50s (ninja)
Building an already built module (nothing to do): depends very much on
whether the disk cache is warm or cold. Best times:
gbuild more than 3s (make -sr -j8)
ninja about 0.4s (ninja)
Why is ninja faster than make/gbuild?
- Make runs each recipe in its own shell (bash), ninja executes its command
directly.
- Ninja understands the header dependencies created by gxx/clang and msvc
and stores them in a compact format that can be read in very fast on
startup.
- I avoided some steps of build that are unnecessary in ninja
= Ninja creates directories for the targets it makes. Gbuild creates them
explicitly.
= GBuild first creates empty dependency files and later, in a second step,
fills them with the actual dependency information created by one of the
C/C++ compilers.
But, for me, these numbers are just a welcome side effect. More important
to me is maintainability.
Ninja follows a very different approach from (GNU) make. Its lack of even
simplest control structures such as if/then/else or foreach, requires the
generation of the main makefile (by default that is called build.ninja) by
program or script. This leads to my current approach:
- Use XML to represent the static data (C++ files, libraries, resource
files, XML files).
- Use a Perl script to translate the XML files into the build.ninja file.
The best tool for each job (XML: data representation, Perl: data
processing). Instead of Perl we could use any language that is part of our
current build requirements (Java, C/C++, Python (we would have to compile
that first, though)). Look at the Perl files in [1] or [2]
(build/source/ninja/*pm) and compare them to solenv/gbuild/*mk and see which
you can understand better.
I think this could be one way to set up a better maintainable build system
that is even slightly faster then what we currently have.
Do you get a sense for how well-maintained Ninja is? Are there many
contributors? Many users?
I only know that it was developed by/for the chrome project [4] and that
cmake has support for ninja as back end.
Are we confident it will be around in 5
years? I worry (but only a little) of another DMake.
Then I probably should not tell you that I may make a similar experiment
with tup as backend.
-Andre
[4] http://www.aosabook.org/en/posa/ninja.html
[5] http://gittup.org/tup/
-Rob
Best regards,
Andre
[1] http://people.apache.org/~af/build/
[2] http://people.apache.org/build.zip
[3] http://martine.github.io/ninja/manual.html
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org
