summaryrefslogtreecommitdiffstats
path: root/i18npool/Library_collator_data.mk
Commit message (Collapse)AuthorAgeFilesLines
* gbuild: Remove MSVC 2013 legacy codeDavid Ostrovsky2017-04-211-4/+0
| | | | | | | | | 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>
* upgrade to ICU 53.1, fdo#77071 relatedEike Rathke2014-04-291-1/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Move to MPLv2 license headers, with ESC decision and author's permission.Michael Meeks2013-04-301-23/+4
|
* gbuild: invert handling of standard system libraries:Michael Stahl2012-09-281-2/+0
| | | | | | | Always link in gb_STDLIBS, except when the library explicitly opts out with gb_LinkTarget_disable_standard_system_libs. Change-Id: I489a99114fbfa46d0421a27cf6c7b899dc268a4a
* gbuild: replace direct gb_STDLIBS use with ...Michael Stahl2012-09-281-1/+2
| | | | | | ... new gb_LinkTarget_add_standard_system_libs Change-Id: Ib2bc843098db3d8c6822b45a3d21724e67f57d69
* gbuild: split uwinapi out of gb_STDLIBSMichael Stahl2012-09-281-0/+1
| | | | Change-Id: I53316e0b9369d806197bccb42cf22d3497af43e7
* gbuild: "use" vs. "add":Michael Stahl2012-04-081-1/+1
| | | | | | | | | 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)
* i18npool: use CustomTarget_*.mk makefilesMatúš Kukan2012-03-241-3/+2
| | | | Also done lot of simplification and modernization.
* Link most libs and executables with gb_STDLIBS as presumably is intendedTor Lillqvist2011-12-201-0/+4
|
* convert i18npool to gbuildMatúš Kukan2011-08-171-0/+37