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: [144564] trunk/dports

[David Evans]

On 1/12/16 3:40 PM, Mojca Miklavec wrote:
> On 13 January 2016 at 00:35, David Evans wrote:
>> On 1/12/16 3:27 PM, Mojca Miklavec wrote:
>>> On 13 January 2016 at 00:20, David Evans wrote:

 Why don't we just kill the p5-graveyard build on the buildbots.  It's
 irritating and doesn't serve any useful purpose.
>>>
>>> Do we end up with any spurious files on the buildbot if we do?
>>
>> I don't think so but maybe Ryan and/or Josh can weigh in on this. At least
>> we can remove the build waiting in the queue for 10.6 if it hasn't already
>> started.
> 
> I removed the job from 10.6 and cancelled it on one of the buildbots,
> but I'm a bit scared of that "pink warning".

I'll leave this to you. ;-)

> 
>>> One more thing: you already committed
>>> http://trac.macports.org/changeset/143602
>>> but I'm afraid that we need to repeat the exercise now that the
>>> previously default variant is gone.
>>>
>>> Are you willing to do the revbumps again?

Done.

>>
>> And lastly the perl5 port needs a revbump too.  Then we should be
>> in good shape.
> 
> I already revbumped it.
> 
> (Revbumping it now will only serve those infinitely small number of
> users that didn't upgrade after removal of +perl5_16, but upgraded in
> the very short timeframe when these variants were added back.)
> 
> Mojca
> 

Looks like I'm one of those.  If there are any others, we'll be sure
to hear from them. :-)

Going home now, will check later.

Dave


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

Re: [144564] trunk/dports

[Mojca Miklavec]

On 13 January 2016 at 00:35, David Evans wrote:
> On 1/12/16 3:27 PM, Mojca Miklavec wrote:
>> On 13 January 2016 at 00:20, David Evans wrote:
>>>
>>> Why don't we just kill the p5-graveyard build on the buildbots.  It's
>>> irritating and doesn't serve any useful purpose.
>>
>> Do we end up with any spurious files on the buildbot if we do?
>
> I don't think so but maybe Ryan and/or Josh can weigh in on this. At least
> we can remove the build waiting in the queue for 10.6 if it hasn't already
> started.

I removed the job from 10.6 and cancelled it on one of the buildbots,
but I'm a bit scared of that "pink warning".

>> One more thing: you already committed
>> http://trac.macports.org/changeset/143602
>> but I'm afraid that we need to repeat the exercise now that the
>> previously default variant is gone.
>>
>> Are you willing to do the revbumps again?
>
> And lastly the perl5 port needs a revbump too.  Then we should be
> in good shape.

I already revbumped it.

(Revbumping it now will only serve those infinitely small number of
users that didn't upgrade after removal of +perl5_16, but upgraded in
the very short timeframe when these variants were added back.)

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

Re: [144564] trunk/dports

[David Evans]

On 1/12/16 3:27 PM, Mojca Miklavec wrote:
> On 13 January 2016 at 00:20, David Evans wrote:
>>
>> Why don't we just kill the p5-graveyard build on the buildbots.  It's
>> irritating and doesn't serve any useful purpose.
> 
> Do we end up with any spurious files on the buildbot if we do?

I don't think so but maybe Ryan and/or Josh can weigh in on this. At least
we can remove the build waiting in the queue for 10.6 if it hasn't already
started.

> 
> One more thing: you already committed
> http://trac.macports.org/changeset/143602
> but I'm afraid that we need to repeat the exercise now that the
> previously default variant is gone.
> 
> Are you willing to do the revbumps again?

And lastly the perl5 port needs a revbump too.  Then we should be
in good shape.

I'll take care of it.

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

Re: [144564] trunk/dports

[Mojca Miklavec]

And while off-topic, I just have to say that: I'm completely amazed.
We no longer have any single failure of perl modules on the buildbots
(other than one single trivial problem that's easy to fix).

Thanks for keeping all the modules up to date and working!

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

Re: [144564] trunk/dports

[Mojca Miklavec]

On 13 January 2016 at 00:20, David Evans wrote:
>
> Why don't we just kill the p5-graveyard build on the buildbots.  It's
> irritating and doesn't serve any useful purpose.

Do we end up with any spurious files on the buildbot if we do?

One more thing: you already committed
http://trac.macports.org/changeset/143602
but I'm afraid that we need to repeat the exercise now that the
previously default variant is gone.

Are you willing to do the revbumps again?

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

Re: [144564] trunk/dports

[David Evans]

On 1/12/16 3:07 PM, Mojca Miklavec wrote:
> 
>>> (I'm only slightly inclined to wait a tiny bit until the buildbots
>>> have cought up with the history, else other unsuspected committers
>>> will be unable to extract whether anything was wrong with their
>>> commits.)
>>
>> Sorry, I don't understand.
> 
> It might take a day or more for the graveyard port to be compiled on
> the buildbot (unless someone breaks the build; which we might want to
> do anyway).
> 
> I wanted to make sure that there would be no other builds in the
> waiting list by the time the graveyard ports starts to build (because
> figuring out what went wrong with other builds would be a "nightmare"
> for the maintainer that would do the other commit; and breaking the
> build of graveyard would also break any other builds if they were in
> the waiting line).
> 
> Mojca
> 

Why don't we just kill the p5-graveyard build on the buildbots.  It's
irritating and doesn't serve any useful purpose.

Dave

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

Re: [144564] trunk/dports

[Mojca Miklavec]

On 12 January 2016 at 23:37, David Evans wrote:
>
> Now that you have removed the subports, you need to commit p5-graveyard
> to enable the replaced_by mechanism so that the old ports will update
> properly.

I know. I only wanted to wait a bit. The old jobs were finished on the
buildbots now (except for the 10.6 which was probably offline long
enough, so that many ports weren't prebuilt), so I committed the
changes.

>> (I'm only slightly inclined to wait a tiny bit until the buildbots
>> have cought up with the history, else other unsuspected committers
>> will be unable to extract whether anything was wrong with their
>> commits.)
>
> Sorry, I don't understand.

It might take a day or more for the graveyard port to be compiled on
the buildbot (unless someone breaks the build; which we might want to
do anyway).

I wanted to make sure that there would be no other builds in the
waiting list by the time the graveyard ports starts to build (because
figuring out what went wrong with other builds would be a "nightmare"
for the maintainer that would do the other commit; and breaking the
build of graveyard would also break any other builds if they were in
the waiting line).

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

Re: [144564] trunk/dports

[David Evans]

On 1/12/16 1:59 PM, Mojca Miklavec wrote:
> On 12 January 2016 at 22:36, David Evans  wrote:
>> On 1/12/16 1:17 PM, mo...@macports.org wrote:
>>> Revision
>>> 144564 
>>> Author
>>> mo...@macports.org
>>> Date
>>> 2016-01-12 13:17:36 -0800 (Tue, 12 Jan 2016)
>>>
>>>   Log Message
>>>
>>> remove perl5_16..5_20 variants from perl dependents (#50245)
>>>
>>
>> Mojca --
>>
>> You really need to removed the p5.* subports first and add them to
>> p5-graveyard so that they will update to p5.22 before removing
>> variants.
> 
> OK, sorry, maybe I got the order of commits a bit wrong, but:
> - If we would remove subports before we remove the variants, we would
> end up with invalid ports, depending on no longer existing ports (if
> what you say is true, then we have a chicken and egg problem anyway,
> so there's not much we can/could do anyway).
> - I have the graveyard port ready.

Now that you have removed the subports, you need to commit p5-graveyard
to enable the replaced_by mechanism so that the old ports will update
properly.

> 
> (I'm only slightly inclined to wait a tiny bit until the buildbots
> have cought up with the history, else other unsuspected committers
> will be unable to extract whether anything was wrong with their
> commits.)

Sorry, I don't understand.

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

Re: [144564] trunk/dports

[Mojca Miklavec]

On 12 January 2016 at 22:36, David Evans  wrote:
> On 1/12/16 1:17 PM, mo...@macports.org wrote:
>> Revision
>> 144564 
>> Author
>> mo...@macports.org
>> Date
>> 2016-01-12 13:17:36 -0800 (Tue, 12 Jan 2016)
>>
>>   Log Message
>>
>> remove perl5_16..5_20 variants from perl dependents (#50245)
>>
>
> Mojca --
>
> You really need to removed the p5.* subports first and add them to
> p5-graveyard so that they will update to p5.22 before removing
> variants.

OK, sorry, maybe I got the order of commits a bit wrong, but:
- If we would remove subports before we remove the variants, we would
end up with invalid ports, depending on no longer existing ports (if
what you say is true, then we have a chicken and egg problem anyway,
so there's not much we can/could do anyway).
- I have the graveyard port ready.

(I'm only slightly inclined to wait a tiny bit until the buildbots
have cought up with the history, else other unsuspected committers
will be unable to extract whether anything was wrong with their
commits.)

> Are we ready to do this?  (i.e. have all ports that depend on perl5.16
> directly, other than variants, been converted to perl5.22?)

I believe (or at least hope) so.

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

Re: [144564] trunk/dports

[David Evans]

On 1/12/16 1:17 PM, mo...@macports.org wrote:
> Revision
> 144564 
> Author
> mo...@macports.org
> Date
> 2016-01-12 13:17:36 -0800 (Tue, 12 Jan 2016)
> 
> 
>   Log Message
> 
> remove perl5_16..5_20 variants from perl dependents (#50245)
> 
> 
> 

Mojca --

You really need to removed the p5.* subports first and add them to
p5-graveyard so that they will update to p5.22 before removing
variants.

Are we ready to do this?  (i.e. have all ports that depend on perl5.16
directly, other than variants, been converted to perl5.22?)

Dave

___
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

[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