pkg-config v. -I/opt/local/include

[Craig Treleaven]

> On Jan 13, 2016, at 2:19 AM, Ryan Schmidt <ryandesign at macports.org> wrote:
> 
> 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.)

There is no '-I/opt/local/include' anywhere in my compiler args now so I assume CPATH is used.  

BTW, you made me curious.  A recent Fedora23 compile log from a Myth’s buildbot is at:

https://code.mythtv.org/buildbot/builders/master-f23-64bit/builds/104/steps/compile%20core/logs/stdio

If you search for “-I/usr/include “, the only hits are invocations of Qt’s mod!  Never appears in the compiler args.  So I’m now building the “Myth-blessed” way!  ;)

> 
>> 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.

Agreed.

Craig