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? Are we confident it will be around in 5 years? I worry (but only a little) of another DMake. -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
