On Jan 12, 2016, at 1:05 PM, Craig Treleaven wrote:
> On Jan 12, 2016, at 4:09 AM, Ryan Schmidt wrote:
>> On Jan 11, 2016, at 9:03 AM, Craig Treleaven wrote:
>>> I’m having buiild failures due to includes pointing to old/other headers
>>> installed in /opt/local/include.
>>>
>>> As I understand it, 'pig-config —cflags’ returns an empty string when a
>>> header is installed in /usr/include. The port I’m working on, MythTV
>>> 0.28-pre, uses pkg-config to check for several dependencies. Under
>>> MacPorts, I end up with '-I/opt/local/include’ early in the compiler
>>> arguments and thus picks up old or unintended versions of headers. Under
>>> Linux, no problem.
>>>
>>> Is there some way I can coerce pkg-config to treat /opt/local/include like
>>> it does /usr/include? I’ve looked at the man page for pkg-config and tried
>>> using some of the environment variables but without success.
>>>
>>> Eg, with MacPorts:
>>> $ pkg-config --cflags x264
>>> -I/opt/local/include ## want to make this disappear!
>>>
>>> is there a magic recipe?
>>
>> You should not want to make -I/opt/local/include disappear. It is where the
>> headers of dependencies are installed, so it is needed. If it is causing
>> problems, it is likely because your project's build system does not place
>> the include flags in the correct order. The correct order is (relative)
>> project include paths first, (absolute) dependency include paths second. If
>> you cannot fix the build system to do that, you can use your sed trick to
>> replace -I/opt/local/include with -isystem/opt/local/include which will have
>> the same effect.
>>
>
> Hi Ryan:
>
> I asked over on the pkg-config mailing list and got:
>
>> This isn't documented (should be), but you can override pkg-config's notion
>> of the system include path with the environment variable
>> PKG_CONFIG_SYSTEM_INCLUDE_PATH. If that's not set, it uses the compiled in
>> defaults. That's been in pkg-config for a long time, so it should work with
>> the version you have. This should be in the form of a path style variable
>> with : separators.
I didn't know about that variable. Thanks for finding out about that.
> This is exactly what I wanted:
>
> $ pkg-config --cflags-only-I libass
> -I/opt/local/include -I/opt/local/include/freetype2 -I/opt/local/include
> -I/opt/local/include/libpng16 -I/opt/local/include
> -I/opt/local/include/fribidi -I/opt/local/include/glib-2.0
> -I/opt/local/lib/glib-2.0/include -I/opt/local/include
> -I/opt/local/include/freetype2
>
> $ PKG_CONFIG_SYSTEM_INCLUDE_PATH=/opt/local/include pkg-config
> --cflags-only-I libass
> -I/opt/local/include/freetype2 -I/opt/local/include/libpng16
> -I/opt/local/include/fribidi -I/opt/local/include/glib-2.0
> -I/opt/local/lib/glib-2.0/include -I/opt/local/include/freetype2
>
> Adding 'configure.env-append
> PKG_CONFIG_SYSTEM_INCLUDE_PATH=${prefix}/include’ makes the MythTV build
> work the way it does on Linux (aka “successfully”).
But is that because -I/opt/local/include then gets inserted into the correct
place in the compile line, or because -I/opt/local/include is omitted from the
compile line and it only works because MacPorts also happens to set
CPATH=/opt/local/include and you're using a newer compiler that supports that?
(Granted, only very old versions of clang don't support CPATH.)
> As to whether this is the “right” thing to do, you have far more knowledge
> and experience than me. I think Myth’s configure is relying on a quirk of
> pkg-config. I would think that other folks that are cross-compiling--or even
> just using a different prefix—must be hitting this problem. I get very
> little traction with the Myth devs. They writeoff stuff like this as a
> “MacPorts problem”.
Yeah they would be incorrect to blame bugs in their build system on us just
because we use their build system in a slightly different way than they
apparently do.
_______________________________________________
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
