summaryrefslogtreecommitdiff
path: root/recipes/harfbuzz.recipe
AgeCommit message (Collapse)AuthorFilesLines
2022-05-03harfbuzz: disable werror from internal pragmas1.20.2Matthew Waters1-1/+4
Part-of: <https://gitlab.freedesktop.org/gstreamer/cerbero/-/merge_requests/857>
2020-06-09harfbuzz.recipe: Fix build on MSVCNirbheek Chauhan1-3/+3
Fixes #274 Part-of: <https://gitlab.freedesktop.org/gstreamer/cerbero/-/merge_requests/501>
2020-06-06harfbuzz: build with mesonTim-Philipp Müller1-12/+20
Part-of: <https://gitlab.freedesktop.org/gstreamer/cerbero/-/merge_requests/494>
2020-06-06harfbuzz: update to v2.6.7Tim-Philipp Müller1-7/+3
Part-of: <https://gitlab.freedesktop.org/gstreamer/cerbero/-/merge_requests/494>
2020-04-06harfbuzz: add support for checking for gnustl for c++ libraryMatthew Waters1-1/+4
2019-09-03recipes: Upgrade harfbuzz to 2.6.1Edward Hervey1-4/+4
19months of improvements, a lot of fixes regarding building it also.
2019-02-04Extend licensing scheme, install & package licensesNirbheek Chauhan1-1/+1
Licensing was incorrect, incomplete, and at best, ambiguous. Some recipes were picking one license when there were many, others were listing all the licenses and you had to pick one. On the other hand, many projects are licensed under multiple BSD-like licenses, and you must adhere to the terms of all of them, and there was no way to know how from the binary packages. Now we have an extended syntax for declaring the licensing properties of a recipe. The licenses array can now also contain dictionaries with License enums as keys and relative paths to files in the source tree as values. All files specified in this way will be copied into `share/licenses/$recipe_name`. Common license texts which are copied verbatim by projects without adding any specific author/copyright information have been copied into `data/licenses/` and will be copied into `share/licenses/$recipe_name` when a license is specified without a corresponding source tree file. `share/licenses/$recipe_name/README-LICENSE-INFO.txt` contains a disclaimer that this is not legal advice, and uses (AND) and (OR) operators to declare the combinations of licenses you can pick when adhering to the license requirements of a project. `share/licenses/$recipe_name` is, of course, now also copied into the devel binary packages. I have made a best-effort to check and update the licenses in each recipe, but I have probably missed things. Reviews and updates are welcome. I also did not bother updating the toolchain recipe licenses too carefully since we do not ship them with our binary packages; except mingw-runtime.recipe (which does have an updated license).
2019-02-04licenses: Fix a couple of licenses and remove unused enumsNirbheek Chauhan1-1/+1
freetype: You have to pick between FTL and GPLv2 frei0r-plugins: It's GPLv2+, not LGPL openssl: Obviously, OpenSSL not BSD harfbuzz: Actually BSD, not LGPLv2+ lame: transitioned to LGPL2, no longer GPL nettle/gmp: licensed under all three licenses osx-framework: No license, just copying of files from other recipes gst-shell, vsintegration, etc: Match with gstreamer's license toolchain: All LGPLv2+, GPLv2+, or GPLv3+ other recipes: verified by `diff -uw` on license Remove most unused license enums, except Proprietary
2019-01-10recipes: Don't try to use `python3` on WindowsNirbheek Chauhan1-2/+4
Python 3 on Windows is still called python.exe; changing it to use python3.exe breaks Windows builds. For harfbuzz and libsoup, the proper fix is to port the recipes to Meson. The Meson ports are already upstream.
2018-12-20harfbuz: Allow python3 only Windows buildsNicolas Dufresne1-0/+2
2018-09-19recipes: Add tarball checksums for all recipesNirbheek Chauhan1-0/+1
This should cover all recipes; even those that aren't built by default https://bugzilla.gnome.org/show_bug.cgi?id=797177
2018-07-22recipes: Move all recipes to HTTPSNirbheek Chauhan1-1/+1
Also add a check in Cerbero to ensure that no insecure URLs are used.
2018-07-21cerbero: Rework environment modification in recipesNirbheek Chauhan1-1/+1
Environment variable modification in a recipe used to be done with: self.append_env, self.prepend_env, or self.new_env All of these were dictionaries of {string:string} mappings, which means that if a recipe wanted to, say, append to `CFLAGS` from multiple places within the recipe (f.ex., `glib.recipe`), you had to carefully juggle `=` and `+=` in recipes, which was error-prone (f.ex., `gstreamer-1.0.recipe` `variants.nodebug` was broken). Now that we also conditionally use `self.append_env['CFLAGS']` in `cerbero/build/build.py` for bitcode support with make-based build systems, it's impossible to get this right in recipes. This was causing the cross-ios-universal builds to fail on recipes that directly set `self.append_env['CFLAGS'] = 'foo'` such as pixman. The dictionaries have now been replaced with the following functions: self.append_env(varname, value1, value2, ..., sep=separator) self.prepend_env(varname, value1, value2, ..., sep=separator) self.set_env(varname, value1, value2, ..., sep=separator) The separator is used to join value1, value2, etc and also while appending/prepending to the value in the env. It is optional, and defaults to ` ` (space). Most often the usage is very simple to translate: self.append_env['CFLAGS'] = ' -funroll-loops ' => self.append_env('CFLAGS', '-funroll-loops') If values are omitted with `self.set_env()`, the variable is unset: self.new_env['MAKEFLAGS'] = None => self.set_env('MAKEFLAGS') An important intended feature is that multiple calls to these functions all take effect sequentially at build time for each build step. So, you can call append and prepend multiple times on the same variable, and the values will be appended and prepended in that order to the value at build time. Note that if you call `self.set_env()` on a variable, the variable will, of course, be set to that value and previous append/prepend declarations will be overriden. Reviewed-by: Jan Schmidt <jan@centricular.com>
2018-05-05ios: Build with -fembed-bitcodeOlivier Crete1-0/+1
2018-03-04recipes/harfbuzz: disable mmap usage on lower android targetsJan Schmidt1-0/+9
Fixes build with NDR r16
2018-02-21recipes: Upgrade harfbuzz to 1.7.5Edward Hervey1-1/+1
2016-12-13harfbuzz: Update to 1.2.7Sebastian Dröge1-2/+1
2015-08-31harfbuzz: Fix the DLL revision specified in the .def fileNirbheek Chauhan1-0/+1
Patch taken from upstream, with the same changes to Makefile.in also added in to avoid an autoreconf. https://bugzilla.gnome.org/show_bug.cgi?id=754043
2015-08-16recipes/harfbuzz: Upgrade to 1.0.1Edward Hervey1-1/+1
2015-04-07recipes; Bump harfbuzz to 0.9.40Edward Hervey1-1/+1
2015-03-02harfbuzz: Unconditionally disable ICU supportNirbheek Chauhan1-9/+1
Not really useful for us, and ICU isn't available on all distros anyway
2015-02-14recipes: Update most dependencies and build-toolsEdward Hervey1-1/+1
* Remove/Update patches where applicable * Tested on all linux/android variant, the build slaves will pick up the rest...
2014-12-11harfbuzz: Don't use libicu on no-distro systemsOlivier Crête1-1/+2
2014-09-13harfbuzz: Update to 0.9.35Sebastian Dröge1-1/+1
This builds fine with newer clang on ARM.
2014-06-26harfbuzz: Build static librariesSebastian Dröge1-0/+1
2014-06-16recipes: Use %(version)s for tarbal urls all aroundThibault Saunier1-1/+1
2014-06-16recipes: Add a Gtk+3 recipeThibault Saunier1-0/+21
Update some dependencies: + Update librsvg to version 2.40.1 + Update pango to version 1.36.1 and make it depend on harfbuzz + Update fontconfig to version 2.11.0 + Add a gnome-themes-standard recipe so we have the Adwaita theme installed + Add a harfbuzz recipe as pango now depends on it + Backport a patch to allow setting Gtk theme through the GTK_THEME env variable
generated by cgit v1.2.3 (git 2.39.1) at 2024-11-25 16:11:15 +0000