|
From: | Ryan Schmidt |
Subject: | Re: [ft] freetype build failing when flow-tools is present |
Date: | Thu, 2 Apr 2009 17:58:08 -0500 |
On Apr 2, 2009, at 11:21, Werner LEMBERG wrote:
[...] is there a way that we can have FreeType look for its ftconfig.h in the build directory anyway and not look to a possibly wrong one in the directory given in CPPFLAGS?Yes. You can change the `CFLAGS' variable as follows while calling `make':CFLAGS="$CFLAGS -UFT_CONFIG_CONFIG_H -DFT_CONFIG_CONFIG_H=..."
Hmm. It just seems odd to me that I should have to tell freetype where its config file is, when it should already know this.
The failing compile line is: libtool: compile: \ /usr/bin/gcc-4.0 \ -I/opt/local/include \ -I/opt/local/var/.../work/freetype-2.3.9/objs -I./builds/unix \ -I/opt/local/var/.../work/freetype-2.3.9/include \ -c \ -O2 \ -DFT_CONFIG_OPTION_SYSTEM_ZLIB \ -DDARWIN_NO_CARBON "-DFT_CONFIG_CONFIG_H=<ftconfig.h>" \ -DFT2_BUILD_LIBRARY "-DFT_CONFIG_MODULES_H=<ftmodule.h>" \ builds/unix/ftsystem.c -fno-common \ -DPIC \ -o /opt/local/var/.../work/freetype-2.3.9/objs/.libs/ftsystem.o I see -I/opt/local/include is first, hence that's where ftconfig.h is found first. Perhaps that should be the last -I that's listed, instead of the first?I don't think so. The idea of `CPPFLAGS' is to override other preprocessor flags.
I see. So what you're saying is, freetype knows where its config file is, but by using CPPFLAGS in this way, we are telling freetype that we know better? I think we don't know better. :)
Should MacPorts be using a different mechanism, then? I'm not an expert at compiling things. Someone suggested we change CPPFLAGS="-I$ {prefix}/include" to CPPFLAGS="-isystem${prefix}/include", and this does seem to work, for freetype, so I committed that change yesterday, for freetype. Does that seem reasonable?
What we need in MacPorts is a way to tell all ports "When you need extra includes and libraries from other software, look for them in the following prefix before looking in /, /usr, and /usr/local." For some time we have been using CPPFLAGS="-I${prefix}/include" and LDFLAGS="-L${prefix}/lib" to do this. Is this not a good way? We do not want these includes and libraries to override the ones being created by the package being built.
[Prev in Thread] | Current Thread | [Next in Thread] |