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. 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 > >
