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
