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

[Craig Treleaven]

> On Jan 13, 2016, at 2:19 AM, Ryan Schmidt  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

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

[Ryan Schmidt]

On Jan 13, 2016, at 6:37 AM, Craig Treleaven wrote:On Jan 13, 2016, at 2:19 AM, Ryan Schmidt wrote:On Jan 12, 2016, at 1:05 PM, Craig Treleaven wrote: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.  I figured.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/stdioIf you search for “-I/usr/include “, the only hits are invocations of Qt’s mod!  Never appears in the compiler args.That's expected because /usr/include is a special location. Compilers know to check there automatically. They do not know to check in /opt/local/include automatically so you have to tell them to check there. The normal should-work-everywhere way to do that is by putting -I/opt/local/include into the CPPFLAGS environment variable. If that causes problems for the myth build, that is a bug in the myth build system that the myth developers should fix.So I’m now building the “Myth-blessed” way!  ;)It would be silly of them to say that it is not supported to build myth with dependencies installed in a prefix other than /usr.___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

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

[Brandon Allbery]

On Wed, Jan 13, 2016 at 2:19 AM, Ryan Schmidt 
wrote:

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


Note that some Linux distributions only package very old clang.

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

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

[Ryan Schmidt]

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

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

[Ryan Schmidt]

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.

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

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

[Craig Treleaven]

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

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

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

Craig

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

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

[Craig Treleaven]

> On Jan 11, 2016, at 10: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?

Didn’t find a magic recipe but I did come up with a workaround.  I overrode the 
pkg-config command used by configure ala:

set pkg_config_cmd  "${prefix}/bin/pkg-config $@ | sed 's|-I${prefix}/include 
||g’”

and added --pkg_config="${pkg_config_cmd}” to the configure arguments.  I get 
one no-harm warning but that is much better than random build failures!

I’m still open to better solutions.

Craig


___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev