Am Montag, 25. März 2013 um 20:52 schrieb janI: > On 25 March 2013 14:33, Andre Fischer <awf....@gmail.com> wrote: > > > On 25.03.2013 11:40, janI wrote: > > > > > On 25 March 2013 11:08, Andre Fischer <awf....@gmail.com> wrote: > > > > > > On 24.03.2013 21:19, janI wrote: > > > > > > > > Hi all. > > > > > > > > > > I have started to integrate genLang into the build structure replacing > > > > > the > > > > > currenct l10n part, or more correctly I have strugled to understand > > > > > head > > > > > and tail. > > > > > > > > > > I thought (as written in my document earlier and corrected by none) > > > > > that > > > > > somewhere localize_sl was called to do the extract/merge, but I cannot > > > > > find > > > > > a single file that contains a call to localize_sl. > > > > > > > > > > Hi Jan, > > > > > > > > as far as I know the extraction part was never part of our regular build > > > > system but was triggered by release engineers on demand. I guess that > > > > there where scripts for that that where never checked in. > > > > > > > > The part that is part of the build system is the integration of > > > > localized > > > > strings. > > > > > > > > That is what I found as well, build uses the sdf files to generate the > > > translated source, with genLang it is combined in one step (read source, > > > generate po, merge to source with languages). > > > > > > > > > > > > I then removed all unxlangx6.pro (I use ubuntu) and did a build --all > > > > > where > > > > > I recorded all output. Now I could see that transex3, helpex, ulfex, > > > > > cfgex > > > > > and xrmex was called directly. Having seen that I thought it is in the > > > > > local makefiles, but no luck. > > > > > > > > > > Keep in mind that we have two very different make file systems. The > > > > unxlingx6.pro directory is used in modules by the dmake system. > > > > The gbuild system stores its files (that is true for files visible only > > > > module locally as well as globally) in main/solver/ > > > > But as I said above, you will not find the extraction anywhere (that is > > > > my > > > > understanding but I could easily be wrong) in the makefiles. > > > > > > > > Are you saying the gbuild is partly integrated in trunk ??? I thought it > > > was still experimental in branch/gbuild. > > > > > > > > > Why do you thing that integrated and experimental are mutually exclusive? > > :-) > > > > To be serious, gbuild is not experimental anymore. But it is not flawless > > either. > > The gbuild branch contains more modules converted to gbuild. In various > > stages of completeness, I believe. > > > > > > > I am not just looking for extraction, but simply how to get genLang > > > integrated. > > > > > > > > > The following files have a reference to transex3: > > > > > ./toolkit/src2xml/source/****src2xml.py > > > > > > > > > > Don't know what this does but I am not sure that it is related to the > > > > text > > > > extraction. > > > > > > > > Toolkit is the API of AOO if I understand it correctly ? > > > > It contains some part of API implementation, for the com.sun.star.awt > > stuff for example. And other things that did not fit anywhere else. > > > > > > > > > > > > I tried to trigger the execution of the commands in question but was not > > > > successful. Touching a .src file in main/sw and then rebuilding sw > > > > should > > > > do the trick. But maybe the transex3 related commands are only triggered > > > > when gbuild is run globally, not on a per-module bases. Trouble is, the > > > > global mode (gbuild replaces build.pl) does not work, as far as I know. > > > > But this may server as a hint on how to integrate transex3 into gbuild > > > > modules. > > > > > > > > I did it with success, even though I did it by removing unxlng6.pro, > > > then > > > build (called locally) called transex3. So maybe I have used gbuild even > > > though I called build. > > > > > > > > > If there is a directory like unxlngx6.pro in your module then it is > > dmake. If there is a file Module_<module-name>.mk then it is gbuild. If > > both is true then there is an error. > > But you are right, toolkit is a gbuild module. > > > > > > > > > > > > > ./solenv/gbuild/****AllLangResTarget.mk > > > > > > > > This is interesting because it really applies transex3 to .src files in > > > > eg. main/sw. > > > > > > > > ./solenv/inc/os2gcci.mk > > > > > > > > > ./solenv/inc/libs.mk > > > > > ./solenv/inc/unitools.mk > > > > > > > > > > These define compile flags and libraries that are probably used to > > > > build > > > > the transex3 executable. > > > > > > > > > > > > > > > > But I cannot see how that connects into the build system. > > > > > > > > > > In order to integrate genLang I need to understand to things: > > > > > a) where the current system builds l10n parts > > > > > > > > > > If you mean extraction, then as already stated, I think that the > > > > current > > > > system does not do that. > > > > > > > > b) where I could attach genLang (it should only be called once for > > > > every > > > > > > > > > module, with a list of files to extract/merge). > > > > > > > > > > That is the one million dollar question. For gbuild you may have > > > > already > > > > found your answer, see above. > > > > For dmake: dmake builds a module directory by directory. The .src files > > > > are also handled per-directory. See for example main/sd/source/ui/app/ > > > > makefile**.mk <http://makefile.mk>. It lists 6 .src files to be turned > > > > > > > > into one .srs files (line 44: SRC1FILES = ...) It even contains a line > > > > (line 99) > > > > > > > > Now the 2 million dollard question, you told me long time ago, that > > > gbuild > > > would not be ready for a long time, it that still the case, is anyone > > > working actively on it ? > > > > > > > > > I am still working on some ideas on how to replace it with something > > readable and understandable that is fast on Windows. But if I ever finish, > > it will take some time. > > > > > > I might help here with the experience I have from vienna, where we had a > huge build system, and I am still in contact with the people > who maintains it. > > One idea just of the top, is not to start the compiler for each file, but > collect the filenames needing to be compiled, and then start the compiler > once with all filenames, that saves LOTS of cpu cycles. > > > > > > > > > Otherwise it seems I have to fight my way through both new an old build. > > > > Ahm, yes, I am afraid that is true. Even if we integrated the gbuild > > branch today, we would still be far from our goal of a total conversion. > > > > > > > > > > > > LOCALIZE_ME = tbxids_tmpl.src menuids2_tmpl.src menu_tmpl.src > > > > menuids_tmpl.src menuids4_tmpl.src popup2_tmpl.src toolbox2_tmpl.src > > > > menuportal_tmpl.src menuids3_tmpl.src > > > > > > > > which, I must admit, I have not seen before. > > > > > > > > If you want to do anything per-module then look at <module>/util/ > > > > makefile.mk. In sd/util/makefile.mk you will find (line 40) > > > > RESLIB1SRSFILES=\ > > > > $(SRS)$/app.srs \ > > > > $(SRS)$/dlg.srs \ > > > > $(SRS)$/core.srs \ > > > > $(SRS)$/html.srs \ > > > > $(SRS)$/accessibility.srs \ > > > > $(SRS)$/notes.srs \ > > > > $(SRS)$/animui.srs \ > > > > $(SRS)$/slideshow.srs \ > > > > $(SRS)$/slsview.srs \ > > > > $(SRS)$/uitable.srs \ > > > > $(SRS)$/view.srs \ > > > > $(SRS)$/uiannotations.srs \ > > > > > > > > a list of .srs files. The app.srs is built for the sd/source/ui/app > > > > directory as mentioned above. > > > > > > > > > > > > Now, for your changes. You may be able to use the existing lists from > > > > the > > > > makefiles (SRC1FILES and RESLIB1SRSFILES) and add new makefiles and new > > > > targets to solenv/inc that trigger your code. > > > > > > > > But that is already all I can say. Sorry. > > > > > > > > Thanks a lot, it is a great help since it gives me a starting point. > > > > > > I look forward to present the integrated genLang on this list. > > > > It is great to see that you are not (too much) discouraged by the sorry > > state of our build system. > > > > > Once I get my stuff integrated and running, then my next job will be the > build system, gbuild is a big step in the correct direction, but in my > opinion there are one big fundamental problems in the implementation: > gbuild tries to do everything everywhere to put it simply (like doing mkdir > on the fly and not in a separate "prepare" run), that makes it hard to > read, and costs lots of performance. > >
I think we are open for everything that bring us forward to a more reliable, fast, maintainable and more intuitive build system than the current gbuild system. The gbuild system is hard to debug, far away from being intuitive and ... Short I personally don't like it. Why introducing something similar to a scripting language based on gnu make? Juergen > > jan I. > > > > > > -Andre > > > > > > > rgds > > > Jan I. > > > > > > -Andre > > > > > > > > > > > > I hope someone can give me a hint on where to get more information, at > > > > > the > > > > > moment I am pretty lost. > > > > > > > > > > Once I get this working, I can do the final testing, and we can get > > > > > rid > > > > > of > > > > > the sdf files, coding is so far completed. > > > > > > > > > > thx in advance for any serious help. > > > > > Jan I. > > > > > > > > > > > > > > > ------------------------------****----------------------------** > > > > --**--------- > > > > To unsubscribe, e-mail: > > > > dev-unsubscribe@openoffice.**a**pache.org<http://apache.org> > > > > <dev-unsubscribe@**openoffice.apache.org<dev-unsubscr...@openoffice.apache.org> > > > > > > > > > > > > > > > > > For additional commands, e-mail: dev-h...@openoffice.apache.org > > > > ------------------------------**------------------------------**--------- > > To unsubscribe, e-mail: > > dev-unsubscribe@openoffice.**apache.org<dev-unsubscr...@openoffice.apache.org> > > For additional commands, e-mail: dev-h...@openoffice.apache.org > > > > >
