Re: qt5-qtwebkit on < 10.9 (without libc++ being default)

[Marcus Calhoun-Lopez]

It was not so much intentional breakage as a reflection of what was happening 
anyway.
By default, qmake (the build system of qtwebkit) ignores the MacPorts build 
environment.
Some care must be taken to mimic what MacPorts expects.

Prior to the recent changes, you were probably building qtwebkit with libc++ 
whether you intended to or not.

Example 1:
Prior to http://trac.macports.org/changeset/15, qmake compiled source code 
with -mmacosx-version-min=10.7, which then forced the use of libstdc++
(see http://trac.macports.org/ticket/50249).
So svn2git was using libstdc++ regardless of the value of 
${configure.cxx_stdlib} 

Example 2:
qtwebkit uses CONFIG+=c++11, and qmake responds by still using 
-mmacosx-version-min=10.7 but also adding -std=libc++.
Again, the value of ${configure.cxx_stdlib} was ignored.

I inadvertently tried to build qtwebkit with libstdc++ and received predictable 
errors (not std::move, etc.)

So now you get an error instead of silently installing software in a way you 
did not expect.
I suppose that is progress of a sort.

-Marcus


> On Jan 11, 2016, at 1:50 PM, Mojca Miklavec  wrote:
> 
> Hi,
> 
> I have the following port installed:
> qt5-qtwebkit @5.5.1_2 (active)
> 
> But after
>http://trac.macports.org/changeset/144467/trunk/dports/aqua/qt5
> it no longer compiles:
>Error: qt5-qtwebkit does not support your selected MacPorts C++
> runtime. libc++ must be selected and C++-based ports built against it.
> 
> I know that libstdc++ is a ticking bomb (I still believe that it would
> be great to officially support libc++ with the buildbots), but
> nevertheless: is this recent "breakage" intentional?
> 
> Mojca
> ___
> macports-dev mailing list
> macports-dev@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-dev

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

qt5-qtwebkit on < 10.9 (without libc++ being default)

[Mojca Miklavec]

Hi,

I have the following port installed:
 qt5-qtwebkit @5.5.1_2 (active)

But after
http://trac.macports.org/changeset/144467/trunk/dports/aqua/qt5
it no longer compiles:
Error: qt5-qtwebkit does not support your selected MacPorts C++
runtime. libc++ must be selected and C++-based ports built against it.

I know that libstdc++ is a ticking bomb (I still believe that it would
be great to officially support libc++ with the buildbots), but
nevertheless: is this recent "breakage" intentional?

Mojca
___
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

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

[Craig Treleaven]

Hi:

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?

Thanks,

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

Re: [144513] trunk/dports/perl/p5-crypt-gcrypt/Portfile

[David Evans]

On 1/10/16 4:56 PM, s...@macports.org wrote:
> Revision
> 144513 
> Author
> s...@macports.org
> Date
> 2016-01-10 16:56:20 -0800 (Sun, 10 Jan 2016)
> 
> 
>   Log Message
> 
> p5-crypt-gcrypt: remove older perl support
> 
> 
>   Modified Paths
> 
>   * trunk/dports/perl/p5-crypt-gcrypt/Portfile 
> <#trunkdportsperlp5cryptgcryptPortfile>
> 
> 
>   Diff
> 
> 
> Modified: trunk/dports/perl/p5-crypt-gcrypt/Portfile (144512 => 
> 144513)
> 
> --- trunk/dports/perl/p5-crypt-gcrypt/Portfile 2016-01-11 00:53:53 UTC (rev 
> 144512) +++
> trunk/dports/perl/p5-crypt-gcrypt/Portfile 2016-01-11 00:56:20 UTC (rev 
> 144513) @@ -4,7 +4,7 @@ PortSystem 1.0 PortGroup
> perl5 1.0 -perl5.branches 5.16 5.18 5.20 5.22 +perl5.branches 5.22 
> perl5.setup Crypt-GCrypt 1.26 revision 2
> 
> 
> 
> ___
> macports-changes mailing list
> macports-chan...@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-changes
> 

Rather than doing this piecemeal, it would be better to do this with a single
bulk commit as we have done in the past.

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