summaryrefslogtreecommitdiff
path: root/i18npool/Library_collator_data.mk
AgeCommit message (Collapse)Author
2017-04-21gbuild: Remove MSVC 2013 legacy codeDavid Ostrovsky
Uwinapi is discontinued. Change-Id: I063b4d0d8fab2d60de168e960a63b8181158ac01 Reviewed-on: https://gerrit.libreoffice.org/23198 Reviewed-by: David Ostrovsky <david@ostrovsky.org> Tested-by: David Ostrovsky <david@ostrovsky.org>
2014-04-29upgrade to ICU 53.1, fdo#77071 relatedEike Rathke
plus further work in i18npool to make that build adapt i18npool to ICU 53 upgrade, fdo#77071 Korean charset collator can't be built from ko_charset.txt because of "The runtime code decomposes Hangul syllables on the fly, with recursive processing but without making the Jamo pieces visible for matching. It does not work with certain types of contextual mappings." "While handling a Hangul syllable, contractions starting with Jamo L or V would not see the following Jamo of that syllable." (this is where we bail out already with the first syllable of ko_charset.txt) Another condition to fail is described as "A contraction ending with Jamo L or L+V would require generating Hangul syllables in addTailComposites() (588 for a Jamo L), or decomposing a following Hangul syllable on the fly, during contraction matching." Excluded the file from the build for ICU >=53 and hope that ICU in the mean time handles Korean collation correctly. Additionally, ICU 53 took ages (if it would had finished at all) to build the collator from zh_TW_charset.txt because of the \u#### escaped notation. Converted the file's content to characters using http://www.rishida.net/tools/conversion/ Change-Id: I64213214b4870e7077f72b95fee1ddc9782c2b21 Reviewed-on: https://gerrit.libreoffice.org/9204 Reviewed-by: Eike Rathke <erack@redhat.com> Tested-by: Eike Rathke <erack@redhat.com>
2013-04-30Move to MPLv2 license headers, with ESC decision and author's permission.Michael Meeks
2012-09-28gbuild: invert handling of standard system libraries:Michael Stahl
Always link in gb_STDLIBS, except when the library explicitly opts out with gb_LinkTarget_disable_standard_system_libs. Change-Id: I489a99114fbfa46d0421a27cf6c7b899dc268a4a
2012-09-28gbuild: replace direct gb_STDLIBS use with ...Michael Stahl
... new gb_LinkTarget_add_standard_system_libs Change-Id: Ib2bc843098db3d8c6822b45a3d21724e67f57d69
2012-09-28gbuild: split uwinapi out of gb_STDLIBSMichael Stahl
Change-Id: I53316e0b9369d806197bccb42cf22d3497af43e7
2012-04-08gbuild: "use" vs. "add":Michael Stahl
Naming convention for gbuild methods: - "add" is used for stuff that is logically a part of the target (i.e. not registered at the Module, but defined in the target's makefile) - "use" is used for stuff that is logically a different target (i.e. it is registered at the Module, has it's own makefile, may be in a different module than the target)
2012-03-24i18npool: use CustomTarget_*.mk makefilesMatúš Kukan
Also done lot of simplification and modernization.
2011-12-20Link most libs and executables with gb_STDLIBS as presumably is intendedTor Lillqvist
2011-08-17convert i18npool to gbuildMatúš Kukan