Hi all,
Trying to make comphelper depend on officecfg (to be able to use the new
simplified configmgr API in comphelper), this currently fails due to
officecfg depending on translations, translations depending on
l10ntools, and l10ntools in turn depending on tools (which is pretty
high up in the hierarchy, and depends on comphelper in particular).
While there is probably not much that can be done about the first two
dependencies in that chain (officecfg -> translations -> l10ntools),
l10ntools depending on tools looks like a relic of the past.
While some of the tools from l10ntools are actually Perl/Python scripts
(addkeyid2pot, fast_merge, keyidGen, po2lo, propex, propmerge), others
are C++ programs (cfgex, gsicheck, helpex, localize_sl, transex3, ulfex,
xrmex).
From what it looks like, those C++ programs carry forward some
stone-age code, and generally could use an overhaul. For example, there
is code that copies files around to temp files, only to strip a leading
BOM before feeding into flex. I think that can be drastically simplified.
Unless there's someone who screams "but all this should go away in the
next couple months, anyway!" I would therefore go ahead and clean that
code up, ridding it of any tools dependencies (should hopefully not be
too difficult to base it either on sal or even on the plain C++ standard
library).
An alternative might be to re-write those programs in Python (seeing
that there is already one other Python script, po2lo; re-writing in Perl
would *not* be an option, Perl not being a language to write programs in
in the first place). However, given the nature of those tools' work,
regressions might be hard to spot, so I would like to keep modifications
to the code in bounds.
What do people think?
Stephan
_______________________________________________
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
