Re: pkg-config v. -I/opt/local/include
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
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
> 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
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
> 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
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
> 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
