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.
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.
-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.**apache.org<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
