openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andre Fischer <>
Subject Re: Building sw/ with ninja
Date Wed, 22 Jan 2014 16:55:27 GMT
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 

> 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  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.xml
     xml2mk $< $@

and then include

For ninja this is already working in my experiment.  Change one of the 
xml files and 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.


> Sincerely,
>     Armin
>> -Andre
>>> -Andre
>>> [4]
>>> [5]
> ----8<-----8<-----
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message