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.
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.
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.
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.
./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. It lists 6 .src files to be turned
into one .srs files (line 44: SRC1FILES = ...) It even contains a line
(line 99)
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.
-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-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org
