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