Hi Damjan, This is really awesome. I will support you the best I can with intelligence. I am a bit lazy, so I wrote a programme that indexes all files, I want to go through all build configuration files, c++ and java file and see if I can consolidate all this information into Wikipages to start developers documentation on on our confluence wiki. My plan / hope is I can provide a Dependency tree on filebases until end of this year. Next step will be extended the documentation by classes and Namespaces and last I would like to add function and methods. I am sorry that I will not be faster. A lot to do currently.
All the best Peter Marcus <marcus.m...@wtnet.de> schrieb am Sa., 10. Dez. 2016, 10:35: > Am 12/09/2016 06:37 PM, schrieb Damjan Jovanovic: > > > > [...] > > > > --------------- > > The future > > --------------- > > 52 of 182 modules (29%) are currently using gbuild, up from 40 (22%) > > before my recent conversion burst began. > > > > I am hacking and porting as many modules to gbuild as possible, as > > soon as possible. The most important thing right now is to build up > > experience and document as much of gbuild as possible (and sadly > > dmake/build.pl/deliver, since understanding their files comes first), > > to prepare for tackling the large modules and making changes to the > > gbuild makefiles themselves. > > > > The UNO modules seem easier to convert and many are really small. I am > > currently converting the Java modules, and javaunohelper should be the > > next to get committed. > > > > I think another group needs to be added for libraries like > > libstore.so.3 whose naming format isn't provided by any library group. > > Yacc support also needs adding to gbuild for several modules that use > > it to parse languages (IDL compilers, main/connectivity for parsing > > SQL queries, etc.), and other gbuild infrastructure probably needs > > developing further. > > > > It seems Sun was trying to implement a "split build" before all the > > modules were ported, where modules in first part are built with > > build.pl, and those in the second part are built purely with a single > > GNU make instance that can build multiple modules concurrently at a > > file level, with maximum parallelization to give the highest > > performance ;-), and would no longer need the prj/ subdirectories. > > It's not clear to me how they were planning to do this or on exactly > > which modules (the "late" modules would have been the first to go into > > this gbuild-only part, of which Calc is the last of the "big 6" that > > aren't in gbuild yet), but I can't wait to start telling dmake and > > build.pl goodbye! > > unfortunately, I cannot provide you with much help. The only thing I can > do is bulding the beast and report back problems. > > But besides this I like your work. It's great to see a successful way > towards a single and improved build system. > > In the meantime we could paint a "Goodbye" sign for the special day. :-) > > Again, thanks for your effort. > > Marcus > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org > > -- Disclaimer: Diese Nachricht stammt aus einem Google Account. Ihre Antwort wird in der Google Cloud Gespeichert und durch Google Algorythmen zwecks werbeanaöysen gescannt. Es ist derzeit nicht auszuschließen das ihre Nachricht auch durch einen NSA Mitarbeiter geprüft wird. Durch kommunikation mit diesen Account stimmen Sie zu das ihre Mail, ihre Kontaktdaten und die Termine die Sie mit mir vereinbaren online zu Google konditionen in der Googlecloud gespeichert wird. Sollten sie dies nicht wünschen kontaktieren sie mich bitte Umgehend um z.B. alternativen zu verhandeln.
