On 22.01.2014 17:28, Armin Le Grand wrote:
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?).
Jan is working on a similar approach for msdev. Eclipse has its own
idea how building a project works. I can not say if that can,
eventually, mapped to our build system.
But I am currently working on a small Eclipse addon that provides a few
buttons (or menu entries, etc.) that start a build of the current
module, directory or file. That might be enough for the time being.
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.
Good point. As final outcome we should have only one build system, the
ability to have different back ends is primarily interesting for
evaluating different replacements of the current system. At best there
could be a secondary build system for the integration into IDEs. But
for building releases and reporting bugs we should use only one build
system.
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.
Think of the XML files as a replacement with a different syntax for the
makefiles like Library_sw.mk. The only difference is that make can not
includes these files directly but has to translate them first into
makefiles. This could be done with a simple make rule like
Library_sw.mk : Library_sw.xml
xml2mk $< $@
and then include Library_sw.mk
For ninja this is already working in my experiment. Change one of the
xml files and build.ninja is rebuilt, included, and the updated build
rules executed.
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...?
It depends on how much work one wants to invest. It would be possible
to write an addon for editing the xml files of the build system. It is
also possible, but more difficult, to add some hook that adds a new C++
file to the corresponding XML file when that C++ file is created via an
Eclipse wizard.
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!
Thank you, that is great to hear.
-Andre
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org
