Re: [114693] trunk/dports/sysutils/macportsscripts/Portfile
On Dec 13, 2013, at 21:14, Craig Treleaven wrote: > I gave the new version of port-depcheck.sh a try...with VLC, see following. > Very different results from the prior version. As I've said, I'm not a C/C++ > developer--the prior version reported a bunch of false positives due to > "over-linking"? In layman's terms, what's that? Example: php55 links with a library from the libxml2 port (libxml2.dylib) libxml2 links with a library from the xz port (liblzma.dylib) Under MacPorts 2.1.x and earlier, php55 might be linked to liblzma.dylib also, just because libxml2 is linked with it, even though php55 does not itself use liblzma. I don’t happen to have a MacPorts 2.1 installation handy anymore so I don’t know if these specific ports were actually affected by this issue, but this is the general principle of what we call overlinking. We fixed the problem in MacPorts 2.2 by clearing the dependency_libs line of .la files as they’re installed, or as of Mavericks by deleting the .la files entirely, but you will not be completely rid of overlinking in all ports you have installed until some distant future time when all ports have coincidentally been updated to newer versions in the right order, or until you uninstall and reinstall all ports from source. (Installing from a binary might get you an overlinked binary from our packages server.) ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [114668] trunk/dports/security/KeePassX/Portfile
On Fri, Dec 13, 2013 at 12:33 PM, Ryan Schmidt wrote:
>
> On Dec 13, 2013, at 11:25, ebori...@macports.org wrote:
>
> > +platform darwin {
> > +if {${os.major} < 13} {
> > +# Build fails with clang: unsupported
> -stack-protector-buffer-size=4
> > +# (even though clang -help lists option)
> > +compiler.blacklist clang
>
> This is probably wrong; you should probably base the blacklisting of clang
> on its version, not on the OS version. Use the compiler_blacklist_versions
> portgroup. Also list any affected MacPorts clang ports.
>
Agreed, I was just trying to push some ports out of c++ lib limbo land. :)
Taking a look closer, I really want - in order to be as close to what the
original option was doing, while still moving to libc++ - a clang that
supports -fsanitize=address, which the OSX version doesn't:
http://www.opensource.apple.com/source/clang/clang-425.0.24/src/tools/clang/test/Driver/darwin-asan-nofortify.c
I was thinking of just setting the compiler to be macports-clang-3.3 (which
does support it) and then adding the cxx_stdlib switch you also suggested
for CXX11 support on/off. Does that sound reasonable?
- Eric
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Fwd: [114693] trunk/dports/sysutils/macportsscripts/Portfile
Hi Eric: I gave the new version of port-depcheck.sh a try...with VLC, see following. Very different results from the prior version. As I've said, I'm not a C/C++ developer--the prior version reported a bunch of false positives due to "over-linking"? In layman's terms, what's that? Craig $ port-depcheck.sh VLC Finding MacPorts libraries that VLC links against... /opt/local/Library/Frameworks/BGHUDAppKit.framework/Versions/A/BGHUDAppKit is provided by: BGHUDAppKit /opt/local/lib/libFLAC.8.dylib is provided by: flac /opt/local/lib/libSDL-1.2.0.dylib is provided by: libsdl /opt/local/lib/libSDL_image-1.2.0.dylib is provided by: libsdl_image /opt/local/lib/libX11.6.dylib is provided by: xorg-libX11 /opt/local/lib/libXau.6.dylib is provided by: xorg-libXau /opt/local/lib/libXdmcp.6.dylib is provided by: xorg-libXdmcp /opt/local/lib/libXext.6.dylib is provided by: xorg-libXext /opt/local/lib/libXrandr.2.dylib is provided by: xorg-libXrandr /opt/local/lib/libXrender.1.dylib is provided by: xrender /opt/local/lib/liba52.0.dylib is provided by: a52dec /opt/local/lib/libass.4.dylib is provided by: libass /opt/local/lib/libavahi-client.3.dylib is provided by: avahi /opt/local/lib/libavahi-common.3.dylib is provided by: avahi /opt/local/lib/libavcodec.55.dylib is provided by: ffmpeg /opt/local/lib/libavformat.55.dylib is provided by: ffmpeg /opt/local/lib/libavutil.52.dylib is provided by: ffmpeg /opt/local/lib/libbluray.1.dylib is provided by: libbluray /opt/local/lib/libbz2.1.0.dylib is provided by: bzip2 /opt/local/lib/libcddb.2.dylib is provided by: libcddb /opt/local/lib/libcrypto.1.0.0.dylib is provided by: openssl /opt/local/lib/libdc1394.22.dylib is provided by: libdc1394 /opt/local/lib/libdca.0.dylib is provided by: libdca /opt/local/lib/libdirac_decoder.0.dylib is provided by: dirac /opt/local/lib/libdirac_encoder.0.dylib is provided by: dirac /opt/local/lib/libdvdnav.4.dylib is provided by: libdvdnav /opt/local/lib/libdvdread.4.dylib is provided by: libdvdread /opt/local/lib/libenca.0.dylib is provided by: enca /opt/local/lib/libexpat.1.dylib is provided by: expat /opt/local/lib/libfaad.2.dylib is provided by: faad2 /opt/local/lib/libfontconfig.1.dylib is provided by: fontconfig /opt/local/lib/libfreetype.6.dylib is provided by: freetype /opt/local/lib/libfribidi.0.dylib is provided by: fribidi /opt/local/lib/libgcrypt.11.dylib is provided by: libgcrypt /opt/local/lib/libgmp.10.dylib is provided by: gmp /opt/local/lib/libgnutls.28.dylib is provided by: gnutls /opt/local/lib/libgpg-error.0.dylib is provided by: libgpg-error /opt/local/lib/libhogweed.2.dylib is provided by: nettle /opt/local/lib/libiconv.2.dylib is provided by: libiconv /opt/local/lib/libidn.11.dylib is provided by: libidn /opt/local/lib/libintl.8.dylib is provided by: gettext /opt/local/lib/libixml.2.dylib is provided by: libupnp /opt/local/lib/libjpeg.9.dylib is provided by: jpeg /opt/local/lib/liblua.dylib is provided by: lua /opt/local/lib/liblzma.5.dylib is provided by: xz /opt/local/lib/libmad.0.dylib is provided by: libmad /opt/local/lib/libmodplug.1.dylib is provided by: libmodplug /opt/local/lib/libmp3lame.0.dylib is provided by: lame /opt/local/lib/libmpcdec.5.dylib is provided by: libmpcdec /opt/local/lib/libmpeg2.0.dylib is provided by: libmpeg2 /opt/local/lib/libncurses.5.dylib is provided by: ncurses /opt/local/lib/libnettle.4.dylib is provided by: nettle /opt/local/lib/libogg.0.dylib is provided by: libogg /opt/local/lib/libopenjpeg.1.dylib is provided by: openjpeg15 /opt/local/lib/libopus.0.dylib is provided by: libopus /opt/local/lib/liborc-0.4.0.dylib is provided by: orc /opt/local/lib/libp11-kit.0.dylib is provided by: p11-kit /opt/local/lib/libpng15.15.dylib is provided by: libpng /opt/local/lib/libpostproc.52.dylib is provided by: ffmpeg /opt/local/lib/libsamplerate.0.dylib is provided by: libsamplerate /opt/local/lib/libschroedinger-1.0.0.dylib is provided by: schroedinger /opt/local/lib/libspeex.1.dylib is provided by: speex /opt/local/lib/libspeexdsp.1.dylib is provided by: speex /opt/local/lib/libssh2.1.dylib is provided by: libssh2 /opt/local/lib/libssl.1.0.0.dylib is provided by: openssl /opt/local/lib/libswscale.2.dylib is provided by: ffmpeg /opt/local/lib/libtag.1.dylib is provided by: taglib /opt/local/lib/libtheoradec.1.dylib is provided by: libtheora /opt/local/lib/libtheoraenc.1.dylib is provided by: libtheora /opt/local/lib/libthreadutil.2.dylib is provided by: libupnp /opt/local/lib/libtiff.5.dylib is provided by: tiff /opt/local/lib/libtwolame.0.dylib is provided by: twolame /opt/local/lib/libupnp.3.dylib is provided by: libupnp /opt/local/lib/libusb-1.0.0.dylib is provided by: libusb /opt/local/lib/libvlc.5.dylib is provided by: VLC /opt/local/lib/libvlccore.7.dylib is provided by: VLC /opt/local/lib/libvorbis.0.dylib is provided by: libvorbis /opt/local/lib/libvorbisenc.2.dylib is provided by: libvorbis /opt/local/lib/libx264.136.dylib is provided by: x264 /opt/local/lib/libxcb.1.dylib is pr
Re: [114687] trunk/dports/_resources/port1.0/group/github-1.0.tcl
On Dec 13, 2013, at 18:34, Ryan Schmidt wrote:
> Ports want to change worksrcdir, for example to build in a subdirectory of
> the distfile. However, ports using the github portgroup and its ability to
> fetch a tarball generated from a github tag, which is what we’re talking
> about here, have zero reason to change the distname, so I think using that
> variable is a good idea.
After “sudo port extract”ing all ports that use the github portgroup, I’m
convinced this change is ok. The few ports that aren’t extracting are failing
for other reasons, like checksum mismatches. Committed the change to use
${workpath}/${distname} in r114702.
The only problem this change (and the previous changes already) caused are that
they match the github.author and github.project case-sensitively. This is good,
but github’s web server seems to transparently handle case mismatches. So we
had a couple ports specifying the case incorrectly, which resulted in extract
failures; I’ve fixed these. (It’s also possible that the developers did a case
rename on their github projects after we added the ports.)
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: sandbox prevents cmake executing /bin/ps
porttrace.tcl should have the sandbox exceptions http://trac.macports.org/browser/trunk/base/src/port1.0/porttrace.tcl#L42 Bradley Giesbrecht wrote: Setting "sandbox_enable no" in macports.conf allows the following cmake line to succeed during the configure phase: EXECUTE_PROCESS(COMMAND ps -ef OUTPUT_QUIET ERROR_QUIET RESULT_VARIABLE result) What is the best way to deal with this, is there a way to add /bin/ps to the sandbox env? Regards, Bradley Giesbrecht (pixilla) ___ 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
sandbox prevents cmake executing /bin/ps
Setting "sandbox_enable no" in macports.conf allows the following cmake line to succeed during the configure phase: EXECUTE_PROCESS(COMMAND ps -ef OUTPUT_QUIET ERROR_QUIET RESULT_VARIABLE result) What is the best way to deal with this, is there a way to add /bin/ps to the sandbox env? Regards, Bradley Giesbrecht (pixilla) ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [114687] trunk/dports/_resources/port1.0/group/github-1.0.tcl
ryandes...@macports.org writes:
> On Dec 13, 2013, at 18:31, Sean Farley wrote:
>
>>
>> ryandes...@macports.org writes:
>>
>>> On Dec 13, 2013, at 16:49, s...@macports.org wrote:
>>>
Revision
114687
Author
s...@macports.org
Date
2013-12-13 14:49:52 -0800 (Fri, 13 Dec 2013)
Log Message
github-1.0: use worksrpath variable when renaming folder; fixes #41797
Modified Paths
• trunk/dports/_resources/port1.0/group/github-1.0.tcl
Diff
Modified: trunk/dports/_resources/port1.0/group/github-1.0.tcl (114686 =>
114687)
--- trunk/dports/_resources/port1.0/group/github-1.0.tcl 2013-12-13
22:30:27 UTC (rev 114686)
+++ trunk/dports/_resources/port1.0/group/github-1.0.tcl 2013-12-13
22:49:52 UTC (rev 114687)
@@ -87,7 +87,7 @@
[llength [glob -nocomplain ${workpath}/*]] > 0} {
if {[file exists [glob
${workpath}/${github.author}-${github.project}-*]] && \
[file isdirectory [glob
${workpath}/${github.author}-${github.project}-*]]} {
-move [glob
${workpath}/${github.author}-${github.project}-*]
${workpath}/${name}-${version}
+move [glob
${workpath}/${github.author}-${github.project}-*] ${worksrcpath}
>>>
>>> I had mentioned on the mailing list that it would be nice to *not* use
>>> worksrcpath here, so that we could finally fix the bug which prevented
>>> ports using the github portgroup from being able to use the worksrcpath
>>> variable effectively.
>>>
>>> https://lists.macosforge.org/pipermail/macports-dev/2013-December/025456.html
>>>
>>> I had suggested using “${distname}” instead. Markus went with
>>> "${workpath}/${name}-${version}”; I’m not sure why.
>>
>> Ok, I must have missed that. It seems that this needs some refactoring /
>> abstraction so that another port group can change worksrcpath (or
>> distname) and not affect ports that use worksrcpath in their portfile. I
>> don't really care how it's solved as long as it doesn't break
>> compatibility.
>
> I forgot distname doesn’t begin with workpath, so my real suggestion is to
> use ${workpath}/${distname}. I’m now testing whether this will work. Looks
> good so far.
>
> Ports want to change worksrcdir, for example to build in a subdirectory of
> the distfile. However, ports using the github portgroup and its ability to
> fetch a tarball generated from a github tag, which is what we’re talking
> about here, have zero reason to change the distname, so I think using that
> variable is a good idea.
Ok, that makes sense. Hopefully, it'll work out.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [114687] trunk/dports/_resources/port1.0/group/github-1.0.tcl
On Dec 13, 2013, at 18:31, Sean Farley wrote:
>
> ryandes...@macports.org writes:
>
>> On Dec 13, 2013, at 16:49, s...@macports.org wrote:
>>
>>> Revision
>>> 114687
>>> Author
>>> s...@macports.org
>>> Date
>>> 2013-12-13 14:49:52 -0800 (Fri, 13 Dec 2013)
>>> Log Message
>>>
>>> github-1.0: use worksrpath variable when renaming folder; fixes #41797
>>> Modified Paths
>>>
>>> • trunk/dports/_resources/port1.0/group/github-1.0.tcl
>>> Diff
>>>
>>> Modified: trunk/dports/_resources/port1.0/group/github-1.0.tcl (114686 =>
>>> 114687)
>>>
>>> --- trunk/dports/_resources/port1.0/group/github-1.0.tcl2013-12-13
>>> 22:30:27 UTC (rev 114686)
>>> +++ trunk/dports/_resources/port1.0/group/github-1.0.tcl2013-12-13
>>> 22:49:52 UTC (rev 114687)
>>>
>>> @@ -87,7 +87,7 @@
>>>
>>> [llength [glob -nocomplain ${workpath}/*]] > 0} {
>>>
>>> if {[file exists [glob
>>> ${workpath}/${github.author}-${github.project}-*]] && \
>>>
>>> [file isdirectory [glob
>>> ${workpath}/${github.author}-${github.project}-*]]} {
>>>
>>> -move [glob
>>> ${workpath}/${github.author}-${github.project}-*]
>>> ${workpath}/${name}-${version}
>>>
>>> +move [glob
>>> ${workpath}/${github.author}-${github.project}-*] ${worksrcpath}
>>
>> I had mentioned on the mailing list that it would be nice to *not* use
>> worksrcpath here, so that we could finally fix the bug which prevented ports
>> using the github portgroup from being able to use the worksrcpath variable
>> effectively.
>>
>> https://lists.macosforge.org/pipermail/macports-dev/2013-December/025456.html
>>
>> I had suggested using “${distname}” instead. Markus went with
>> "${workpath}/${name}-${version}”; I’m not sure why.
>
> Ok, I must have missed that. It seems that this needs some refactoring /
> abstraction so that another port group can change worksrcpath (or
> distname) and not affect ports that use worksrcpath in their portfile. I
> don't really care how it's solved as long as it doesn't break
> compatibility.
I forgot distname doesn’t begin with workpath, so my real suggestion is to use
${workpath}/${distname}. I’m now testing whether this will work. Looks good so
far.
Ports want to change worksrcdir, for example to build in a subdirectory of the
distfile. However, ports using the github portgroup and its ability to fetch a
tarball generated from a github tag, which is what we’re talking about here,
have zero reason to change the distname, so I think using that variable is a
good idea.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [114687] trunk/dports/_resources/port1.0/group/github-1.0.tcl
ryandes...@macports.org writes:
> On Dec 13, 2013, at 16:49, s...@macports.org wrote:
>
>> Revision
>> 114687
>> Author
>> s...@macports.org
>> Date
>> 2013-12-13 14:49:52 -0800 (Fri, 13 Dec 2013)
>> Log Message
>>
>> github-1.0: use worksrpath variable when renaming folder; fixes #41797
>> Modified Paths
>>
>> • trunk/dports/_resources/port1.0/group/github-1.0.tcl
>> Diff
>>
>> Modified: trunk/dports/_resources/port1.0/group/github-1.0.tcl (114686 =>
>> 114687)
>>
>> --- trunk/dports/_resources/port1.0/group/github-1.0.tcl 2013-12-13
>> 22:30:27 UTC (rev 114686)
>> +++ trunk/dports/_resources/port1.0/group/github-1.0.tcl 2013-12-13
>> 22:49:52 UTC (rev 114687)
>>
>> @@ -87,7 +87,7 @@
>>
>> [llength [glob -nocomplain ${workpath}/*]] > 0} {
>>
>> if {[file exists [glob
>> ${workpath}/${github.author}-${github.project}-*]] && \
>>
>> [file isdirectory [glob
>> ${workpath}/${github.author}-${github.project}-*]]} {
>>
>> -move [glob
>> ${workpath}/${github.author}-${github.project}-*]
>> ${workpath}/${name}-${version}
>>
>> +move [glob
>> ${workpath}/${github.author}-${github.project}-*] ${worksrcpath}
>
> I had mentioned on the mailing list that it would be nice to *not* use
> worksrcpath here, so that we could finally fix the bug which prevented ports
> using the github portgroup from being able to use the worksrcpath variable
> effectively.
>
> https://lists.macosforge.org/pipermail/macports-dev/2013-December/025456.html
>
> I had suggested using “${distname}” instead. Markus went with
> "${workpath}/${name}-${version}”; I’m not sure why.
Ok, I must have missed that. It seems that this needs some refactoring /
abstraction so that another port group can change worksrcpath (or
distname) and not affect ports that use worksrcpath in their portfile. I
don't really care how it's solved as long as it doesn't break
compatibility.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
mysql55: sh: /bin/ps: Operation not permitted
Is this a problem or a red herring?
Is sandboxing possibly preventing access to /bin/ps?
CMakeLists.txt:
...
IF(NOT FIND_PROC)
# SysV style
EXECUTE_PROCESS(COMMAND ps -ef OUTPUT_QUIET ERROR_QUIET RESULT_VARIABLE
result)
MESSAGE(FATAL_ERROR "MACPORTS: SysV style result='${result}'")
...
Result:
...
sh: /bin/ps: Operation not permitted
sh: /bin/ps: Operation not permitted
CMake Error at scripts/CMakeLists.txt:126 (MESSAGE):
MACPORTS: SysV style result='Operation not permitted'
...
Regards,
Bradley Giesbrecht (pixilla)
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [114687] trunk/dports/_resources/port1.0/group/github-1.0.tcl
On Dec 13, 2013, at 16:49, s...@macports.org wrote:
> Revision
> 114687
> Author
> s...@macports.org
> Date
> 2013-12-13 14:49:52 -0800 (Fri, 13 Dec 2013)
> Log Message
>
> github-1.0: use worksrpath variable when renaming folder; fixes #41797
> Modified Paths
>
> • trunk/dports/_resources/port1.0/group/github-1.0.tcl
> Diff
>
> Modified: trunk/dports/_resources/port1.0/group/github-1.0.tcl (114686 =>
> 114687)
>
> --- trunk/dports/_resources/port1.0/group/github-1.0.tcl 2013-12-13
> 22:30:27 UTC (rev 114686)
> +++ trunk/dports/_resources/port1.0/group/github-1.0.tcl 2013-12-13
> 22:49:52 UTC (rev 114687)
>
> @@ -87,7 +87,7 @@
>
> [llength [glob -nocomplain ${workpath}/*]] > 0} {
>
> if {[file exists [glob
> ${workpath}/${github.author}-${github.project}-*]] && \
>
> [file isdirectory [glob
> ${workpath}/${github.author}-${github.project}-*]]} {
>
> -move [glob ${workpath}/${github.author}-${github.project}-*]
> ${workpath}/${name}-${version}
>
> +move [glob ${workpath}/${github.author}-${github.project}-*]
> ${worksrcpath}
I had mentioned on the mailing list that it would be nice to *not* use
worksrcpath here, so that we could finally fix the bug which prevented ports
using the github portgroup from being able to use the worksrcpath variable
effectively.
https://lists.macosforge.org/pipermail/macports-dev/2013-December/025456.html
I had suggested using “${distname}” instead. Markus went with
"${workpath}/${name}-${version}”; I’m not sure why.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [114457] trunk/dports/python/py-setuptools/Portfile
On Dec 9, 2013, at 00:46, j...@macports.org wrote:
> Revision
> 114457
> Author
> j...@macports.org
> Date
> 2013-12-08 22:46:47 -0800 (Sun, 08 Dec 2013)
> Log Message
>
> py-setuptools: update to 2.0 for python 2.6+
> Modified Paths
>
> • trunk/dports/python/py-setuptools/Portfile
> -if {${name} ne ${subport}} {
> +if {$subport ne $name} {
The previous change to this line was mine in r114324. My commit message said
“use eq and ne when comparing ${subport} instead of == and !=” but in fact in
this port (and others) I made three changes:
1. changed ==/!= to eq/ne
2. put curly braces around the variable names
3. flipped the order of the variables
I assume because you reverted two of those changes that you disagree with them.
I know we should refrain from making stylistic changes to other people’s ports
without asking them first, and I assume the fact that I made them to your port
anyway annoyed you, and I’m sorry about that. Let me explain why I made these
changes.
Part of the de facto MacPorts programming style, in portfiles anyway, has been
to always use curly braces around variable names. As you know that’s not
required in all cases, but it increases legibility and decreases cognitive load
to always use the same variable syntax. I consider it a best practice. In many
of the python ports for some reason this had not been done in the line that
checks name against subport, though it is being done in most other lines, such
as when you use ${version}:
> +if {${python.version} <= 25} {
> +version 1.4.2
> +distnamesetuptools-${version}
So when I went through all the python ports a few days ago to switch the string
comparisons, since I was already touching that line, I took the opportunity to
also add the curly braces, both for consistency with other ports and for
consistency within each port.
I also wanted to make the order of the variables consistent, and I happened to
choose name first, subport second, because that’s the order I’ve used in my
ports.
In a later commit, when I adjusted the string comparisons for e.g.
${os.platform}, in some cases I flipped the order as well. In many cases I had
previously written e.g.
if {“darwin” == ${os.platform}}
I started writing comparisons this way in portfiles based on a habit I had from
other programming languages wherein, when comparing a variable to a value, you
write the value first and the variable second (“if (5 == x)”), rather than the
other way around (“if (x == 5)”), to avoid accidentally assigning the value to
the variable if you inadvertently omit one of the equals signs (“if (x = 5)”).
But since in Tcl the syntax for assigning a variable is different from the
syntax for accessing a variable there was never any danger of this anyway so I
wanted to begin removing this mental error from portfiles too.
I thought about filing tickets for these changes beforehand, but it would have
been more work and I didn’t think there would be any objection. And I feared
that filing a ticket and waiting a few days to give everyone time to read it
would have led to some of the ports being updated for other reasons in the mean
time, possibly leading to conflicts with my changes and then more work to
resolve them.
So in summary, I apologize for making stylistic changes without prior
consultation; I like the changes I made and I think we should keep them; but if
we don’t want to keep them that’s ok too, I just wanted to make my reasons
known.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [114668] trunk/dports/security/KeePassX/Portfile
On Dec 13, 2013, at 11:25, ebori...@macports.org wrote:
> Revision
> 114668
> Author
> ebori...@macports.org
> Date
> 2013-12-13 09:25:04 -0800 (Fri, 13 Dec 2013)
> Log Message
>
> KeePassX: Build w/clang and c++11 on Mavericks
> Modified Paths
>
> • trunk/dports/security/KeePassX/Portfile
> -# Build fails with clang: unsupported -stack-protector-buffer-size=4
> -# (even though clang -help lists option)
> -compiler.blacklist clang
> -
>
> configure.cmd cmake
>
> configure.pre_args -DCMAKE_INSTALL_PREFIX=${applications_dir} \
>
> -DZLIB_ROOT=${prefix}
>
> configure.args ${qt_cmake_defines} ../${distname}
>
>
>
> +platform darwin {
> +if {${os.major} < 13} {
> +# Build fails with clang: unsupported -stack-protector-buffer-size=4
> +# (even though clang -help lists option)
> +compiler.blacklist clang
This is probably wrong; you should probably base the blacklisting of clang on
its version, not on the OS version. Use the compiler_blacklist_versions
portgroup. Also list any affected MacPorts clang ports.
> +} else {
> +revision3
> +configure.pre_args-append -DWITH_CXX11=On
> +}
> +}
This could be wrong too. The ability to compile with C++11 with clang is tied
to using the libc++ library. That’s the default as of Mavericks, but users
running trunk on earlier OS versions could have indicated they want to use it
too, by editing cxx_stdlib in macports.conf and rebuilding all ports.
Conceivably, users on Mavericks might have even changed the setting to use
libstdc++ instead, and would thus not support C++11. So you should base this
not on the OS version but on the value of configure.cxx_stdlib, if it’s defined.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
