On Wed, Jan 22, 2014 at 9:06 AM, Andre Fischer <awf....@gmail.com> wrote: > On 22.01.2014 14:58, Andre Fischer wrote: >> >> 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. > > > There are two different and independent ideas: > > - Use an easy to read data format for expressing module data (C++ files, > libraries, etc.) that is independent from the actual build tool. > > - Use ninja as a back end. > > The first part is much easier to accomplish and enables us to make > experiments regarding different back ends.
That's a fair point. Good design is always in style. -Rob > Our current gbuild system would be a natural choice for the first back end. > Pure make might be the second. And maybe ninja would be the third. > > -Andre > > >> >> -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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
