gfx/harfbuzz/README-mozilla@6474c204b198 (annotated)
gfx/harfbuzz/README-mozilla
Wed, 31 Dec 2014 06:09:35 +0100
- author
- Michael Schloh von Bennewitz <michael@schloh.com>
- date
- Wed, 31 Dec 2014 06:09:35 +0100
- changeset 0
- 6474c204b198
- permissions
- -rw-r--r--
Cloned upstream origin tor-browser at tor-browser-31.3.0esr-4.5-1-build1
revision ID fc1c9ff7c1b2defdbc039f12214767608f46423f for hacking purpose.
| michael@0 | 1 | gfx/harfbuzz status as of 2012-08-16: |
| michael@0 | 2 | |
| michael@0 | 3 | This directory contains the "harfbuzz-ng" source from the 'master' branch of |
| michael@0 | 4 | git://anongit.freedesktop.org/git/harfbuzz. |
| michael@0 | 5 | |
| michael@0 | 6 | UPDATING: |
| michael@0 | 7 | |
| michael@0 | 8 | Note that hb-ot-shape-complex-indic-machine.hh and gfx/harfbuzz/src/hb-version.h |
| michael@0 | 9 | are not present in the upstream Git repository. These are created at build time |
| michael@0 | 10 | by the harfbuzz build system; but as we don't use that build system in mozilla, |
| michael@0 | 11 | it is necessary to refresh these files when updating harfbuzz, and check them in |
| michael@0 | 12 | to the mozilla tree. (This avoids adding the ragel processor to mozilla's build |
| michael@0 | 13 | prerequisites.) |
| michael@0 | 14 | |
| michael@0 | 15 | The normal approach to updating harfbuzz, therefore, is to pull the latest HB |
| michael@0 | 16 | source into a scratch directory and do a local build; then copy the original |
| michael@0 | 17 | sources AND the generated headers mentioned above from the build directory into |
| michael@0 | 18 | the mozilla tree. |
| michael@0 | 19 | |
| michael@0 | 20 | In addition, the src/Makefile.in file here is NOT from upstream, nor is it |
| michael@0 | 21 | generated from src/Makefile.am (the original harfbuzz version); it is a mozilla- |
| michael@0 | 22 | specific makefile that is maintained by hand. It should only need updating when |
| michael@0 | 23 | new source files or exported headers are added in harfbuzz. |
