> On Jan 13, 2016, at 2:19 AM, Ryan Schmidt <ryandes...@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
_______________________________________________
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
