kumquat-buildroot/package/freetype/freetype.mk

104 lines
3.9 KiB
Makefile
Raw Normal View History

################################################################################
2005-04-26 08:26:14 +02:00
#
# freetype
#
################################################################################
FREETYPE_VERSION = 2.5.5
FREETYPE_SOURCE = freetype-$(FREETYPE_VERSION).tar.bz2
FREETYPE_SITE = http://downloads.sourceforge.net/project/freetype/freetype2/$(FREETYPE_VERSION)
FREETYPE_INSTALL_STAGING = YES
FREETYPE_MAKE_OPTS = CCexe="$(HOSTCC)"
FREETYPE_LICENSE = Dual FTL/GPLv2+
FREETYPE_LICENSE_FILES = docs/FTL.TXT docs/GPLv2.TXT
FREETYPE_DEPENDENCIES = host-pkgconf
FREETYPE_CONFIG_SCRIPTS = freetype-config
HOST_FREETYPE_DEPENDENCIES = host-pkgconf
HOST_FREETYPE_CONF_OPTS = --without-zlib --without-bzip2 --without-png
# Regen required because the tarball ships with an experimental ltmain.sh
# that can't be patched by our infra.
# autogen.sh is because autotools stuff lives in other directories and
# even AUTORECONF with _OPTS doesn't do it properly.
# POST_PATCH is because we still need to patch libtool after the regen.
define FREETYPE_RUN_AUTOGEN
cd $(@D) && PATH=$(BR_PATH) ./autogen.sh
endef
FREETYPE_POST_PATCH_HOOKS += FREETYPE_RUN_AUTOGEN
HOST_FREETYPE_POST_PATCH_HOOKS += FREETYPE_RUN_AUTOGEN
FREETYPE_DEPENDENCIES += host-automake host-autoconf host-libtool
HOST_FREETYPE_DEPENDENCIES += host-automake host-autoconf host-libtool
ifeq ($(BR2_PACKAGE_ZLIB),y)
FREETYPE_DEPENDENCIES += zlib
FREETYPE_CONF_OPTS += --with-zlib
else
FREETYPE_CONF_OPTS += --without-zlib
endif
ifeq ($(BR2_PACKAGE_BZIP2),y)
FREETYPE_DEPENDENCIES += bzip2
FREETYPE_CONF_OPTS += --with-bzip2
else
FREETYPE_CONF_OPTS += --without-bzip2
endif
ifeq ($(BR2_PACKAGE_LIBPNG),y)
FREETYPE_DEPENDENCIES += libpng
FREETYPE_CONF_OPTS += LIBPNG_CFLAGS="`$(STAGING_DIR)/usr/bin/libpng-config --cflags`" \
LIBPNG_LDFLAGS="`$(STAGING_DIR)/usr/bin/libpng-config --ldflags`"
FREETYPE_LIBPNG_LIBS = "`$(STAGING_DIR)/usr/bin/libpng-config --libs`"
else
FREETYPE_CONF_OPTS += --without-png
endif
# Extra fixing since includedir and libdir are expanded from configure values
define FREETYPE_FIX_CONFIG_FILE
$(SED) 's:^includedir=.*:includedir="$${prefix}/include":' \
-e 's:^libdir=.*:libdir="$${exec_prefix}/lib":' \
$(STAGING_DIR)/usr/bin/freetype-config
endef
FREETYPE_POST_INSTALL_STAGING_HOOKS += FREETYPE_FIX_CONFIG_FILE
# libpng isn't included in freetype-config & freetype2.pc :-/
define FREETYPE_FIX_CONFIG_FILE_LIBS
$(SED) "s,^Libs.private:,& $(FREETYPE_LIBPNG_LIBS)," \
$(STAGING_DIR)/usr/lib/pkgconfig/freetype2.pc
$(SED) "s,-lfreetype,& $(FREETYPE_LIBPNG_LIBS)," \
$(STAGING_DIR)/usr/bin/freetype-config
endef
FREETYPE_POST_INSTALL_STAGING_HOOKS += FREETYPE_FIX_CONFIG_FILE_LIBS
freetype: fix double installation Eric_L on IRC reported that the following strange behavior: the first installation of freetype works, and then each time you do "make freetype-dirclean freetype", it fails and works alternatively, in a fully reproducible manner. After some investigation, it turns out that the problem is caused by the creation of the symbolic link /usr/include/freetype2/freetype -> /usr/include/freetype2 for backward compatibility reasons by freetype.mk, in a post-staging installation hook. As the symbolic link is created *after* the installation, the first installation works fine. However, the second installation fails because the freetype build system does: ./builds/unix/mkinstalldirs \ /home/thomas/projets/buildroot/output/target/usr/include/freetype2/config [...] rm -f /home/thomas/projets/buildroot/output/target/usr/include/freetype2/freetype/config/* rmdir /home/thomas/projets/buildroot/output/target/usr/include/freetype2/freetype/config [...] /usr/bin/install -c -m 644 ./builds/unix/ftconfig.h \ /home/thomas/projets/buildroot/output/target/usr/include/freetype2/config/ftconfig.h This last line fails, because due to the symbolic link mentioned above, the command 'rmdir /home/thomas/projets/buildroot/output/target/usr/include/freetype2/freetype/config' has in fact the consequence of deleting the 'config' directory created by the mkinstalldirs command. The proposed solution to solve this problem is to remove the symbolic link in a pre-install hook, run the installation, and restore the symbolic link. [Peter: minor tweaks to commit message / comment] Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-07-03 22:19:24 +02:00
# Version 2.5.1 reorganized headers out of freetype2/freetype.
# It is unexpected for some packages so symlink it until it spreads
# upstream. Note that we also have to remove the symlink prior to the
# installation process, because the installation process of freetype
# removes usr/include/Freetype2/freetype/config, before installing
# something in usr/include/Freetype2/config/ which no longer exists
# due to the symbolic link.
define FREETYPE_REMOVE_FREETYPE_INCLUDE_SYMLINK
$(RM) -f $(STAGING_DIR)/usr/include/freetype2/freetype
endef
FREETYPE_PRE_INSTALL_STAGING_HOOKS += FREETYPE_REMOVE_FREETYPE_INCLUDE_SYMLINK
define FREETYPE_FIX_FREETYPE_INCLUDE
ln -sf . $(STAGING_DIR)/usr/include/freetype2/freetype
endef
FREETYPE_POST_INSTALL_STAGING_HOOKS += FREETYPE_FIX_FREETYPE_INCLUDE
freetype: fix double installation Eric_L on IRC reported that the following strange behavior: the first installation of freetype works, and then each time you do "make freetype-dirclean freetype", it fails and works alternatively, in a fully reproducible manner. After some investigation, it turns out that the problem is caused by the creation of the symbolic link /usr/include/freetype2/freetype -> /usr/include/freetype2 for backward compatibility reasons by freetype.mk, in a post-staging installation hook. As the symbolic link is created *after* the installation, the first installation works fine. However, the second installation fails because the freetype build system does: ./builds/unix/mkinstalldirs \ /home/thomas/projets/buildroot/output/target/usr/include/freetype2/config [...] rm -f /home/thomas/projets/buildroot/output/target/usr/include/freetype2/freetype/config/* rmdir /home/thomas/projets/buildroot/output/target/usr/include/freetype2/freetype/config [...] /usr/bin/install -c -m 644 ./builds/unix/ftconfig.h \ /home/thomas/projets/buildroot/output/target/usr/include/freetype2/config/ftconfig.h This last line fails, because due to the symbolic link mentioned above, the command 'rmdir /home/thomas/projets/buildroot/output/target/usr/include/freetype2/freetype/config' has in fact the consequence of deleting the 'config' directory created by the mkinstalldirs command. The proposed solution to solve this problem is to remove the symbolic link in a pre-install hook, run the installation, and restore the symbolic link. [Peter: minor tweaks to commit message / comment] Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-07-03 22:19:24 +02:00
define HOST_FREETYPE_REMOVE_FREETYPE_INCLUDE_SYMLINK
$(RM) -f $(HOST_DIR)/usr/include/freetype2/freetype
endef
HOST_FREETYPE_PRE_INSTALL_HOOKS += HOST_FREETYPE_REMOVE_FREETYPE_INCLUDE_SYMLINK
define HOST_FREETYPE_FIX_FREETYPE_INCLUDE
ln -sf . $(HOST_DIR)/usr/include/freetype2/freetype
endef
HOST_FREETYPE_POST_INSTALL_HOOKS += HOST_FREETYPE_FIX_FREETYPE_INCLUDE
$(eval $(autotools-package))
$(eval $(host-autotools-package))
# freetype-patch uses autogen.sh so add it as a order-only-prerequisite
# because it is a phony target.
$(FREETYPE_TARGET_PATCH): | host-automake