Hi Andre, On 22.01.2014 07:06, Andre Fischer wrote:
On 22.01.2014 14:58, Andre Fischer wrote:
----8<-----8<-----
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.
This is wonderful news, the build system is one of the 'blocking' factors for further development. Thank you very much for doing this experiments and driving this forward.
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. 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.
I think that seperation is a very good approach. Backends could be the numbered ones, but also script-created stuff for eclipse and msdev (probably?).
We will have to make sure then that - when different ways exist to build the office - that we all still build the same. We already have issues when comparing stuff e.g. when looking into bugfixes on different systems, we do not really want this on the same system for different ways of building the office.
This also means - if I get you right - that the creation of the needed build info from the xml description is an integral part of the build system, probably the first step. Thus, changing it (e.g. adding a new file to the AOO build tree) will (has to) always be done in the xml description. Then to rebuild the needed stuff - dependent of the build method, e.g. ninja - the build system needs to have a dependency that leads to recreation of the needed build data itself, then to the build of AOO.
When (just dreaming) applying this to something like eclipe or msdev this would mean that the created data for these 'helpers' would need to be somehow automatically recreated/reloaded on the fly, would somehing like that be possibe...?
I also see making the build faster as a nice side effect, better readability/maintainability is the biggest plus.
And reliable global dependencies would be a big plus, too, of course...Let's drive this forward, Im ready to help converting modules when it's principally working and the transition step is defined!
Sincerely,
Armin
-Andre-Andre [4] http://www.aosabook.org/en/posa/ninja.html [5] http://gittup.org/tup/
----8<-----8<-----
--------------------------------------------------------------------- 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
