Re: [109789] trunk/dports/devel/log4cplus/Portfile
On 20/08/2013, at 18:02 , Ryan Schmidt ryandes...@macports.org wrote:
On Aug 19, 2013, at 22:56, d...@macports.org wrote:
Revision: 109789
https://trac.macports.org/changeset/109789
Author: d...@macports.org
Date: 2013-08-19 20:56:50 -0700 (Mon, 19 Aug 2013)
Log Message:
---
Upgrade to 1.1.1, build using macports libtool to support libc++, add
cplusplus11 variant (closes #38879)
Modified Paths:
--
trunk/dports/devel/log4cplus/Portfile
Modified: trunk/dports/devel/log4cplus/Portfile
===
--- trunk/dports/devel/log4cplus/Portfile2013-08-20 03:30:24 UTC (rev
109788)
+++ trunk/dports/devel/log4cplus/Portfile2013-08-20 03:56:50 UTC (rev
109789)
@@ -4,7 +4,7 @@
PortSystem 1.0
namelog4cplus
-version 1.0.4.1
+version 1.1.1
categories devel
maintainers randomhacks.net:macports
description Logging library for C++
@@ -16,6 +16,14 @@
master_sitessourceforge
use_xz yes
-checksums md5 306f758596f3a78cbe21a41e2362bac2 \
-sha1 cffac9b8c6f7b7c2f6e19a029403b2f844aaf5fc \
-rmd160 962ec0a49af0d345ce452799a2395cbe7eda3868
+checksums md5 e7844ba5c18073d9936e14def184d60a \
+sha18b8223cc7840f78c28a4deb2a819b86dc18ea2ad \
+rmd160 1a54c794eedec881fceb00f36d80d840f4f00355
+
+# macports libtool allows linking against libc++, the libtool in the
distribution may not
+depends_build port:libtool
+build.args LIBTOOL=${prefix}/bin/glibtool
+
+variant cplusplus11 description {build with c++11 support} {
+configure.cxxflags-append -std=c++11
+}
Why add this variant -- what kind of user needs/wants this?
Sorry, I'm a bit late seeing this email. The reason for this variant is simple:
* log4cplus will use c++11 features if you compile it as c++11, else it will
not.
* those features are desirable, so any developer who is writing in c++11 and
linking against log4cplus would prefer to use such a version.
derek.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [105373] trunk/dports/lang/perl5.12
Hi Josh,
* Background
- I am currently building (in a separate tree) various ports linked against
libc++ rather than libstdc++. I am doing this by altering the
portconfigure.tcl to add eg -stdlib=libc++ to configure.ldflags.
* Before this change, when perl is built it redefines ld as
env MACOSX_DEPLOYMENT_TARGET =10.3 ${ld}
* There was already an existing patch which alters this command for darwin 9/10
to set MACOSX_DEPLOYMENT_TARGET properly. I've simply extended it to darwin
11/12.
* I can't tell you the exact error without rebuilding, but without this patch
the link fails on Lion saying something like ... You're on 10.3, I can't
support libc++ on 10.3, go away
derek.
On 19/04/2013, at 10:27 PM, Joshua Root wrote:
Revision: 105373
https://trac.macports.org/changeset/105373
Author: dh at macports.org
Date: 2013-04-18 23:14:37 -0700 (Thu, 18 Apr 2013)
Log Message:
---
Correctly set MACOSX_DEVELOPMENT_TARGET on darwin versions 11 and 12 for
perl5.12
Modified Paths:
--
trunk/dports/lang/perl5.12/Portfile
trunk/dports/lang/perl5.12/files/patch-hints_darwin.sh.diff
Modified: trunk/dports/lang/perl5.12/Portfile
===
--- trunk/dports/lang/perl5.12/Portfile 2013-04-19 01:00:48 UTC (rev
105372)
+++ trunk/dports/lang/perl5.12/Portfile 2013-04-19 06:14:37 UTC (rev
105373)
@@ -5,7 +5,7 @@
nameperl5.12
version 5.12.4
-revision1
+revision2
set branch [join [lrange [split ${version} .] 0 1] .]
categories lang
license {Artistic-1 GPL}
Modified: trunk/dports/lang/perl5.12/files/patch-hints_darwin.sh.diff
===
--- trunk/dports/lang/perl5.12/files/patch-hints_darwin.sh.diff
2013-04-19 01:00:48 UTC (rev 105372)
+++ trunk/dports/lang/perl5.12/files/patch-hints_darwin.sh.diff
2013-04-19 06:14:37 UTC (rev 105373)
@@ -8,7 +8,7 @@
so='dylib';
dlext='bundle';
usedl='define';
-@@ -172,6 +171,20 @@ case $osvers in
+@@ -172,6 +171,34 @@ case $osvers in
ldflags=${ldflags} -flat_namespace
lddlflags=${ldflags} -bundle -undefined suppress
;;
@@ -26,6 +26,20 @@
+ *) ld=env MACOSX_DEPLOYMENT_TARGET=10.6 ${ld} ;;
+ esac
+ ;;
++11.*)
++ lddlflags=${ldflags} -bundle -undefined dynamic_lookup
++ case $ld in
++ *MACOSX_DEVELOPMENT_TARGET*) ;;
++ *) ld=env MACOSX_DEPLOYMENT_TARGET=10.7 ${ld} ;;
++ esac
++ ;;
++12.*)
++ lddlflags=${ldflags} -bundle -undefined dynamic_lookup
++ case $ld in
++ *MACOSX_DEVELOPMENT_TARGET*) ;;
++ *) ld=env MACOSX_DEPLOYMENT_TARGET=10.8 ${ld} ;;
++ esac
++ ;;
*)
lddlflags=${ldflags} -bundle -undefined dynamic_lookup
case $ld in
What problem does this fix? Base always sets MACOSX_DEPLOYMENT_TARGET
when running any command; why isn't that enough?
- Josh
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Macports 1.8.0 deletes /opt symlink
* I have /opt as a symlink pointing to another disk. * Having just upgrade to Macports 1.8.0 I've discovered that port is very keen on destroying this /opt symlink whenever it upgrades ports. * This ticket has more details: http://trac.macports.org/ticket/21297. Any clues? derek. ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: Macports 1.8.0 deletes /opt symlink
And replying to myself I see this is already noted in ticket: https://trac.macports.org/ticket/21082 so ignore my question ... On 11/09/2009, at 2:59 PM, Derek Harland wrote: * I have /opt as a symlink pointing to another disk. * Having just upgrade to Macports 1.8.0 I've discovered that port is very keen on destroying this /opt symlink whenever it upgrades ports. * This ticket has more details: http://trac.macports.org/ticket/ 21297. Any clues? derek. ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: [MacPorts] #14342: python25 drops modules by default, but python25 doesn't (js)
On 11/03/2008, at 4:21 AM, Rainer Müller wrote: Derek Harland wrote: I'm not sure I particularly like this proposed change. As I understand it, you explicitly want to *downgrade* the functionality of python24 to make it more like python25, by for example, removing hashlib and zlib. I cannot understand the logic of this. This can only conceivably break python24 installations. Even if all existing py-* ports are altered to bring in extra required dependencies, peoples (and institutions) own proprietary code that previously assumed the existence of these standard libraries will break. And that will annoy them greatly. I don't care about software outside of MacPorts. The user is responsible him-/herself to install the appropriate dependencies for it. From my point of view, I can certainly agree that users are responsible for doing so upon *installation* of python. A typical user is going to install macports python and then whatever other external modules they require. They are then conceivably going to write their own tools, scripts and applications using this python environment they have developed for themselves. The proposal is now that they will run port upgrade and in fact receive a veritable downgrade of the environment they have crafted. Their own code will crash and possibly inexplicably to them (it ran fine the other day ...) And for what reason will a downgrade be pushed out to all users? Because there is an inconsistency in the disabled modules. Does it really matter that much? Why are you proposing to explicitly *downgrade* python24, instead of *upgrading* python25? The disabled_modules was chosen wisely as Markus and Boyd explained earlier in this thread. I don't see a reason to change python25 again. My point was more that the problem is X contains more functionality than Y and the proposed solution is downgrade X so it looks like Y. In reality I think there is little benefit in changing either of python24 or python25. I also do not buy into the inference that's been made in this thread in the past that more people must be using python25 than python24. For institutions with large proprietary codebases (eg financial companies), shifting python versions *is* a costly business that is not worth the often negligible benefit. I would suggest that many are still running more code off 2.4 than 2.5 (companies I have been involved with have moved from 1.5-20-2.2- 2.4-2.6). I'm not suggesting many such companies run code on OSX, but mine certainly is. Wouldn't it be the responsibility of their sysadmins to test new releases and do upgrades only if it works? It would be their job to install new py-* dependencies if needed. But this is the point. It can be a struggle to prove that a large developed code base will work across a big number shift in python version (2.4-2.5). Is the expectation now that users should be proving all incremental updates of their python24 installation in case there's been an upstream downgrade in functionality? Its inevitable that at times macports will need to break its users codebases. But to break them over a relatively trivial matter like this seems overdone. des ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: [MacPorts] #14342: python25 drops modules by default, but python25 doesn't (js)
On 11/03/2008, at 3:43 AM, js wrote: Hi Derek, Thanks for your feedback. My intention was to make python24 and python25 looks the same as possible, not to downgrade python24. I thoguht I would be confused if I upgraded python port from 2.4 to 2.5 and found that I cannot import zlib anymore. Yes, that may be confusing. But it seems that your solution is to make everyone that runs a port upgrade python24 discover they don't have zlib anymore. Thats all I'm pointing out. It also presumably involves you running through every py-* port and discovering whether they depend on zlib etc (at least I hope it does) To lower this risk, I could resign python24 port to separate some of its standard modules and add them as dependencies, but I doubt you would like this idea. I'm fine with that as it won't break existing installations. But it doesn't solve your original gripe ... that people can install python24 and have zlib, and then install python25 and not have zlib. [Which I'm not sure is that great an issue] des. ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: [MacPorts] #14342: python25 drops modules by default, but python25 doesn't (js)
On 8/03/2008, at 8:06 AM, [EMAIL PROTECTED] wrote: Date: Sat, 8 Mar 2008 00:22:42 +0900 From: js [EMAIL PROTECTED] Subject: Re: [MacPorts] #14342: python25 drops modules by default,but python25 doesn't To: Markus Weissmann [EMAIL PROTECTED] Cc: MacPorts Developers macports-dev@lists.macosforge.org Apparently more people like this change. I'll get back to trac ticket and start working on this. I'm not sure I particularly like this proposed change. As I understand it, you explicitly want to *downgrade* the functionality of python24 to make it more like python25, by for example, removing hashlib and zlib. I cannot understand the logic of this. This can only conceivably break python24 installations. Even if all existing py-* ports are altered to bring in extra required dependencies, peoples (and institutions) own proprietary code that previously assumed the existence of these standard libraries will break. And that will annoy them greatly. Why are you proposing to explicitly *downgrade* python24, instead of *upgrading* python25? I also do not buy into the inference that's been made in this thread in the past that more people must be using python25 than python24. For institutions with large proprietary codebases (eg financial companies), shifting python versions *is* a costly business that is not worth the often negligible benefit. I would suggest that many are still running more code off 2.4 than 2.5 (companies I have been involved with have moved from 1.5-20-2.2-2.4-2.6). I'm not suggesting many such companies run code on OSX, but mine certainly is. derek. ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Tickets awaiting commit: 14259, 14260, 14261, 14316
Is there any hope of someone committing these tickets? They all relate to python and are new ports or upgrades to ports that are currently nomaintainer. I don't have a commit bit or I would do it myself instead of bothering you guys! derek. ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Can tickets 14259, 14260, 14261, 14316 be committed?
Hi I have a few tickets waiting for commit 14259 Upgrade of py-logilab-common 14260 New port: py-logilab-astng 14261 Upgrade of py-lint 14316 Upgrade of py-epydoc Would someone be able to commit them for me? des. ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
New port submission: py-memcached
* My first port submission :-) * Port submitted under ticket #12987. des. ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
