freetype header location about veejay HOT 11 CLOSED

Hooray!

I have freetype headers in both mentioned paths

the configure script already tries to figure out where they are (freetype, freetype2 + freetype2 with header location change), if the later option works that would be fine

from veejay.

Ok I'll look into why they're not found properly here.

from veejay.

Regarding the headers in both paths, this seems a bit odd to me. I mean I have only ft2build.h next to the mentioned freetype/ subdirectory. What distro are you on, are these orphan files perhaps? Just wondering, actually not related to the autoconf question, will look into this soon.

from veejay.

I have that file too in /usr/include, along with a bunch of others

bash-4.2$ ls /usr/include/freetype2/
config      ftbbox.h    ftcffdrv.h    ftgasp.h   ftincrem.h  ftmm.h      ftpfr.h     ftsynth.h   ftwinfnt.h  tttags.h
freetype    ftbdf.h     ftchapters.h  ftglyph.h  ftlcdfil.h  ftmodapi.h  ftrender.h  ftsystem.h  ftxf86.h    ttunpat.h
freetype.h  ftbitmap.h  ftcid.h       ftgxval.h  ftlist.h    ftmoderr.h  ftsizes.h   fttrigon.h  t1tables.h
ftadvanc.h  ftbzip2.h   fterrdef.h    ftgzip.h   ftlzw.h     ftotval.h   ftsnames.h  ftttdrv.h   ttnameid.h
ftautoh.h   ftcache.h   fterrors.h    ftimage.h  ftmac.h     ftoutln.h   ftstroke.h  fttypes.h   tttables.h

This is on Slackware 14.1 x86_64
current code fuss also works on Ubuntu 14 LTS and 14.10

from veejay.

Slackware is still alive? crazy :) So I suppose that one of the sets of header files is leftover cruft from an earlier freetype version, I know they moved the headers to the subfolder upstream at some point, not exactly when. I always wondered with slackware anyways, being based on tarballs only (true?) how they handle things like this. Am I able to find the owner of a given file at all on a slack system?

from veejay.

You can find the Slackware build script for the source package here: http://ftp.slackware.com/pub/slackware/slackware-14.1/source/l/freetype/

It applies a couple of patches, that do a couple of things and this:

freetype2/freetype.h

/***************************************************************************/
/*                                                                         */
/* If you think breaking almost 100% of all source that links with         */
/* freetype (anything using a configure file for sure) is a good idea,     */
/* then feel free to uncomment this block.                                 */
/*                                                                         */
/* #ifndef FT_FREETYPE_H                                                   */
/* #error "`ft2build.h' hasn't been included yet!"                         */
/* #error "Please always use macros to include FreeType header files."     */
/* #error "Example:"                                                       */
/* #error "  #include "                                        */
/* #error "  #include FT_FREETYPE_H"                                       */
/* #endif                                                                  */
/***************************************************************************/

from veejay.

Eww this is ugly :/ Then doing this?

# This shouldn't be needed (apps should pick up -I/usr/include/freetype2 from
# `freetype-config --cflags` while compiling), but it's so often reported as
# a bug that I'll give in to the point.  Now that Freetype1 is pretty much gone
# having this link shouldn't hurt anything.  Try not to rely on it, though.
mkdir -p $PKG/usr/include
( cd $PKG/usr/include
  rm -rf freetype
  ln -sf freetype2/freetype .
)

I generally disapprove with such "convenience" mechanisms I must say. Sometimes things need to be broken in order to get fixed right. Does the package maintainer not think that these compatibility concerns have been considered by the upstream developers? That's one thing I really love about arch, their basic KISS approach of interfering with upstream packages to the minimum possible extent.

Anyways just my opinion, does not answer why it does not work on my system, which I will look into hopefully today, just that the problem in veejay would probably have long been discovered without those helpful patches :)

from veejay.

Ok I looked through it, automake is fine it actually uses freetype-config --cflags for the include path. The headers are also found basically, since the include macros are used. However, veejay defines the location of two header itself in config.h

/* location of ftsnames.h (freetype) */
#define FT_FTSNAMES_H "freetype2/ftsnames.h"

/* location of ttnameid.h (freetype) */
#define FT_TTNAMEID_H "freetype2/ttnameid.h"

The problematic part in configure.ac is this:

if test x$have_freetype2 != xtrue; then
    AC_CHECK_PROG(FREETYPE_CONFIG, freetype-config,yes,no)
    if test $FREETYPE_CONFIG = yes; then
        FT_CFLAGS="`freetype-config --cflags`" 
        FT_WORD="`freetype-config --libs`"
        FT_LIBS=""
        for word in $FT_WORD; do    
            beginning=`echo $word |cut -c -2` 
            if test ".$beginning" = ".-L"; then
                FT_LDFLAGS="$FT_LDFLAGS $word"
            else
                FT_LIBS="$FT_LIBS $word"
            fi
        done
        AC_DEFINE(HAVE_FREETYPE,1,[compiling with freetype])
        FTPATHTOKENS=${FT_CFLAGS##*/}
        AC_DEFINE_UNQUOTED(FT_FTSNAMES_H,"$FTPATHTOKENS/ftsnames.h",[location of ftsnames.h (freetype)])
        AC_DEFINE_UNQUOTED(FT_TTNAMEID_H,"$FTPATHTOKENS/ttnameid.h",[location of ttnameid.h (freetype)])
        AC_SUBST(FT_LIBS)
        AC_SUBST(FT_LDFLAGS)
        AC_SUBST(FT_CFLAGS)
        have_freetype=true
        AC_MSG_NOTICE([Compiling with FreeType])
    else
        AC_MSG_ERROR([Cannot find the freetype-config program])
    fi
fi

Where ftsnames.h and ttnameid.h are appended directly to $FTPATHTOKENS, which seems not to be valid on all systems since there's the intermediate freetype/ directory. Will for now just insert that, issue PR in a branch so you can test. If that works for both we are fine but might want to look into a cleaner fix at times.

I also wonder why freetype itself does not provide those macros. Maybe the headers are not actually intended to be included by the client?

from veejay.

Ok so freetype actually defines those but with different names: http://www.freetype.org/freetype2/docs/reference/ft2-header_file_macros.html

Changed to code to use

#include FT_SFNT_NAMES_H
#include FT_TRUETYPE_IDS_H

And removed the own definition from configure.ac. Fixed, commited, move along :)

from veejay.

@flvi0 clean build well @ 43b3242 from ubuntu 15.04

from veejay.

Nice one! confirmed on Slackware

On Tue, Nov 10, 2015 at 4:53 AM, Patric Schmitz [email protected]
wrote:

Closed #45 #45 via 6663297
6663297
.

—
Reply to this email directly or view it on GitHub
#45 (comment).

from veejay.