On 1/22/14 2:45 PM, 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? Are we confident it will be around in 5 > years? I worry (but only a little) of another DMake.
Ninjas are known that they can survive ;-) But it is indeed a valid question. The fact that it is used by Google to build Chromium is at least promising. Juergen > > -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
