RFC: Support for future compilers in base
I'd like to update base trunk such that future versions of clang, dragonegg, and gcc just work, so we don't need to wait for newer versions of base to depend on newer compilers. I've taken a first pass at portconfigure.tcl and here is a patch. Comments? Concerns? future-compilers.patch Description: Binary data ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: RFC: Support for future compilers in base
On Feb 15, 2013, at 3:10 AM, Jeremy Huddleston Sequoia jerem...@macports.org wrote: I'd like to update base trunk such that future versions of clang, dragonegg, and gcc just work, so we don't need to wait for newer versions of base to depend on newer compilers. I've taken a first pass at portconfigure.tcl and here is a patch. Comments? Concerns? Unless I'm not seeing it, I think you need to add a mechanism to prevent garbage input like configure.compiler macports-gcc-3.14 Currently that would just match the default case in the configure_start switch, but I guess now you'll have to check for the (nonexistent) gcc314 port? vq ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: RFC: Support for future compilers in base
On Feb 15, 2013, at 12:51 AM, Lawrence Velázquez lar...@macports.org wrote: On Feb 15, 2013, at 3:10 AM, Jeremy Huddleston Sequoia jerem...@macports.org wrote: I'd like to update base trunk such that future versions of clang, dragonegg, and gcc just work, so we don't need to wait for newer versions of base to depend on newer compilers. I've taken a first pass at portconfigure.tcl and here is a patch. Comments? Concerns? Unless I'm not seeing it, I think you need to add a mechanism to prevent garbage input like configure.compiler macports-gcc-3.14 Currently that would just match the default case in the configure_start switch, but I guess now you'll have to check for the (nonexistent) gcc314 port? That is the entire point of this patch. macports-gcc-3.14 is perfectly valid and should result in a dependency on gcc314. Of course the developer would then see a lint error about an unknown port just like they would see if they added 'depends_build port:gcc314' to the Portfile. --Jeremy ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: RFC: Support for future compilers in base
On 2013-02-15 09:10, Jeremy Huddleston Sequoia wrote:
I'd like to update base trunk such that future versions of clang, dragonegg,
and gcc just work, so we don't need to wait for newer versions of base to
depend on newer compilers.
I've taken a first pass at portconfigure.tcl and here is a patch. Comments?
Concerns?
Fine with me.
This change makes sense as the features supported by the gcc and clang
compilers shipped in ports are almost homogenous at the moment; in the
past there were differences as not all gcc4* shipped gfortran or gcj.
However, I don't expect the situation to change in the near future.
One minor stylistic comment, when using regexp and you don't care about
the whole match, it's convention in the Tcl community to use - as
variable name:
regexp {macports-clang-(.*)\.(.*)} ${configure.compiler} - major minor
Rainer
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: new port submission
I'm interrested in testing ccnx, would be nice to have the ports committed... ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
apply patch request for couchdb-devel ticket #37641
I have an update patch for couchdb-devel that I'd like to have applied. Ticket #37641. Could somebody with some familiarity with couchdb take a look and give me some feedback on it or apply it? Thanks! -Jeff smime.p7s Description: S/MIME cryptographic signature ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Fatal install error for dbus policykit using debug only
Hello all, I hope this message isn't a duplicate. I tried sending this to the list earlier but I never saw it show up so I'm sending again. I was installing a port with dependencies on dbus policykit using the flags -vd. dbus was failing with: Error: org.macports.install for port dbus returned: launchctl: Couldn't stat(/System/Library/LaunchDaemons/com.apple.DirectoryServicesLocal.plist): No such file or directory nothing found to load Looks like it is related to the dsc command. http://support.apple.com/kb/HT4749 But I found the error did not occur if I omitted the -vd and the install completed. Same thing with policykit, and possibly others since I stopped using debug. Does anyone know why using debug would cause this problem? Mark ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Fatal install error for dbus policykit using debug only
At 8:36 AM -0800 2/15/13, Mark Duling wrote: Hello all, I hope this message isn't a duplicate. I tried sending this to the list earlier but I never saw it show up so I'm sending again. I was installing a port with dependencies on dbus policykit using the flags -vd. dbus was failing with: Error: org.macports.install for port dbus returned: launchctl: Couldn't stat(/System/Library/LaunchDaemons/com.apple.DirectoryServicesLocal.plist): No such file or directory nothing found to load Looks like it is related to the dsc command. http://support.apple.com/kb/HT4749http://support.apple.com/kb/HT4749 But I found the error did not occur if I omitted the -vd and the install completed. Same thing with policykit, and possibly others since I stopped using debug. Does anyone know why using debug would cause this problem? Can't help with your problem, but it is likely that gmail is the reason you can't see you posting. It 'hides' the message since it recognizes it as something you sent. Craig ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: RFC: Support for future compilers in base
Rainer Müller writes: On 2013-02-15 09:10, Jeremy Huddleston Sequoia wrote: I'd like to update base trunk such that future versions of clang, dragonegg, and gcc just work, so we don't need to wait for newer versions of base to depend on newer compilers. I've taken a first pass at portconfigure.tcl and here is a patch. Comments? Concerns? Fine with me. This change makes sense as the features supported by the gcc and clang compilers shipped in ports are almost homogenous at the moment; in the past there were differences as not all gcc4* shipped gfortran or gcj. However, I don't expect the situation to change in the near future. Clang doesn't provide fortran but all gcc ports do. How is that almost homogenous? That's a huge difference when building mpi-dependent ports. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: RFC: Support for future compilers in base
On Feb 15, 2013, at 12:18 PM, Sean Farley s...@macports.org wrote: Rainer Müller writes: On 2013-02-15 09:10, Jeremy Huddleston Sequoia wrote: I'd like to update base trunk such that future versions of clang, dragonegg, and gcc just work, so we don't need to wait for newer versions of base to depend on newer compilers. I've taken a first pass at portconfigure.tcl and here is a patch. Comments? Concerns? Fine with me. This change makes sense as the features supported by the gcc and clang compilers shipped in ports are almost homogenous at the moment; in the past there were differences as not all gcc4* shipped gfortran or gcj. However, I don't expect the situation to change in the near future. Clang doesn't provide fortran but all gcc ports do. How is that almost homogenous? Did you actually look at the patch? It doesn't treat clang the same as it does gcc. It treats all gcc versions the same as all other gcc versions; it treats all clang versions the same as all other clang versions; and it treats all dragonegg versions the same as it treats all other dragonegg versions... That's a huge difference when building mpi-dependent ports. Which is not really affected by this… smime.p7s Description: S/MIME cryptographic signature ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: RFC: Support for future compilers in base
On 2013-02-15 21:18, Sean Farley wrote: Rainer Müller writes: This change makes sense as the features supported by the gcc and clang compilers shipped in ports are almost homogenous at the moment; in the past there were differences as not all gcc4* shipped gfortran or gcj. However, I don't expect the situation to change in the near future. Clang doesn't provide fortran but all gcc ports do. How is that almost homogenous? That's a huge difference when building mpi-dependent ports. What I meant is that all gcc4* ports provide one set of compilers and all clang* ports provide another set of compilers. In the past, this was not always the case and some of the gcc* ports had additional +fortran +java variants since some of them failed to build. Rainer ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: RFC: Support for future compilers in base
Jeremy Huddleston Sequoia writes: On Feb 15, 2013, at 12:18 PM, Sean Farley s...@macports.org wrote: Rainer Müller writes: On 2013-02-15 09:10, Jeremy Huddleston Sequoia wrote: I'd like to update base trunk such that future versions of clang, dragonegg, and gcc just work, so we don't need to wait for newer versions of base to depend on newer compilers. I've taken a first pass at portconfigure.tcl and here is a patch. Comments? Concerns? Fine with me. This change makes sense as the features supported by the gcc and clang compilers shipped in ports are almost homogenous at the moment; in the past there were differences as not all gcc4* shipped gfortran or gcj. However, I don't expect the situation to change in the near future. Clang doesn't provide fortran but all gcc ports do. How is that almost homogenous? Did you actually look at the patch? It doesn't treat clang the same as it does gcc. It treats all gcc versions the same as all other gcc versions; it treats all clang versions the same as all other clang versions; and it treats all dragonegg versions the same as it treats all other dragonegg versions... To be honest, Jeremy, the patch is a bad hack, at best. It relies on the compiler name and does horrible regex matching. What if there's a new compiler that comes out? For example, let's say Intel releases a free version for the mac or maybe the Open64 compiler gets a complete port to the mac? Those would still require an update to base. What about making this a port group? Or maybe making this a better system of object-oriented-ness (as much as would be allowed in Tcl)? That's a huge difference when building mpi-dependent ports. Which is not really affected by this… Sure, your patch doesn't make it worse but it also does nothing to alleviate the burden of having a port with a fortran + mpi requirement. This seems like a good opportunity to address these issues. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: RFC: Support for future compilers in base
On Feb 15, 2013, at 4:10 AM, Jeremy Huddleston Sequoia jerem...@macports.org wrote: That is the entire point of this patch. macports-gcc-3.14 is perfectly valid and should result in a dependency on gcc314. Of course the developer would then see a lint error about an unknown port just like they would see if they added 'depends_build port:gcc314' to the Portfile. Oh, I see. So the developer would just get the unknown port error instead of getting Invalid value for configure.compiler: macports-gcc-3.14 during configure. Makes sense. No point in checking for the port if MacPorts does that already . vq ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: RFC: Support for future compilers in base
On Feb 15, 2013, at 1:06 PM, Sean Farley s...@macports.org wrote: Jeremy Huddleston Sequoia writes: On Feb 15, 2013, at 12:18 PM, Sean Farley s...@macports.org wrote: Rainer Müller writes: On 2013-02-15 09:10, Jeremy Huddleston Sequoia wrote: I'd like to update base trunk such that future versions of clang, dragonegg, and gcc just work, so we don't need to wait for newer versions of base to depend on newer compilers. I've taken a first pass at portconfigure.tcl and here is a patch. Comments? Concerns? Fine with me. This change makes sense as the features supported by the gcc and clang compilers shipped in ports are almost homogenous at the moment; in the past there were differences as not all gcc4* shipped gfortran or gcj. However, I don't expect the situation to change in the near future. Clang doesn't provide fortran but all gcc ports do. How is that almost homogenous? Did you actually look at the patch? It doesn't treat clang the same as it does gcc. It treats all gcc versions the same as all other gcc versions; it treats all clang versions the same as all other clang versions; and it treats all dragonegg versions the same as it treats all other dragonegg versions... To be honest, Jeremy, the patch is a bad hack, at best. It relies on the compiler name and does horrible regex matching. Yes, and how is that any worse than what is being done already? What if there's a new compiler that comes out? For example, let's say Intel releases a free version for the mac or maybe the Open64 compiler gets a complete port to the mac? Those would still require an update to base. Yes is would. This patch is not designed to address *THAT* issue. It is designed to address gcc49, gcc410, gcc50, dragonegg-3.[456], clang-3.[456], etc. That's all I care about addressing for now. If you have an idea for making this even better in the future, be my guest =) What about making this a port group? Or maybe making this a better system of object-oriented-ness (as much as would be allowed in Tcl)? I hate tcl, and it hates me. If you want to do something like that, please do so, but I'm very limited in what *I* can do based on how much time I (don't) want to devote to tcl. I'm just trying to make the situation incrementally better than it is now, so I don't need to remember to cherry pick support clang-3.4 into the base 2.2 branch like we did 3.2 and 3.3 into the base 2.1 branch. That's a huge difference when building mpi-dependent ports. Which is not really affected by this… Sure, your patch doesn't make it worse but it also does nothing to alleviate the burden of having a port with a fortran + mpi requirement. This seems like a good opportunity to address these issues. Be my guest. I don't use fortran, so so I don't really know about that particular issue. Do you have a ticket filed? Problems don't get fixed unless someone cares about fixing the problem ;) --Jeremy smime.p7s Description: S/MIME cryptographic signature ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [103128] trunk/dports/python/py-html2text/Portfile
On Feb 15, 2013, at 15:03, s...@macports.org wrote:
Revision: 103128
https://trac.macports.org/changeset/103128
Author: s...@macports.org
Date: 2013-02-15 13:03:59 -0800 (Fri, 15 Feb 2013)
Log Message:
---
py-html2text: add missing py-distribute dependency; fixes #37964
Modified Paths:
--
trunk/dports/python/py-html2text/Portfile
+depends_lib-append port:py${python.version}-distribute
Is it really a library dependency? Isn't distribute usually only used at build
time?
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [103124] trunk/dports/devel/mercurial/Portfile
On Feb 15, 2013, at 15:03, s...@macports.org wrote:
Revision: 103124
https://trac.macports.org/changeset/103124
Author: s...@macports.org
Date: 2013-02-15 13:03:30 -0800 (Fri, 15 Feb 2013)
Log Message:
---
mercurial-devel: update to newest changeset
Modified Paths:
--
trunk/dports/devel/mercurial/Portfile
Modified: trunk/dports/devel/mercurial/Portfile
===
--- trunk/dports/devel/mercurial/Portfile 2013-02-15 21:03:24 UTC (rev
103123)
+++ trunk/dports/devel/mercurial/Portfile 2013-02-15 21:03:30 UTC (rev
103124)
@@ -37,14 +37,15 @@
conflicts mercurial-devel
subport mercurial-devel {
-bitbucket.setup mirror mercurial-crew e71c2ff93167
+bitbucket.setup mirror mercurial-crew af4387d8d1c7
namemercurial-devel
version 2.5.0.99
+revision1
Is this still 2.5.0.99? The main port is at 2.5.1 already.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [103079] users/cal/base-sqlite-portindex/src/port1.0/portmain.tcl
On Feb 13, 2013, at 04:03, c...@macports.org wrote: Revision: 103079 https://trac.macports.org/changeset/103079 Author: c...@macports.org Date: 2013-02-13 02:03:48 -0800 (Wed, 13 Feb 2013) Log Message: --- portmain: define option procs without space at the end Why? We've been putting a space before the backslash everywhere else, except when that results in badness (i.e. in notes). Modified: users/cal/base-sqlite-portindex/src/port1.0/portmain.tcl === --- users/cal/base-sqlite-portindex/src/port1.0/portmain.tcl 2013-02-13 09:46:30 UTC (rev 103078) +++ users/cal/base-sqlite-portindex/src/port1.0/portmain.tcl 2013-02-13 10:03:48 UTC (rev 103079) @@ -47,17 +47,17 @@ set_ui_prefix # define options -options prefix name version revision epoch long_description description \ -homepage notes provides replaced_by worksrcdir filesdir distname \ -portdbpath libpath distpath sources_conf os.platform os.subplatform \ -os.version os.major os.arch os.endian install.user install.group \ -macosx_deployment_target universal_variant os.universal_supported \ -installs_libs copy_log_files compiler.cpath compiler.library_path \ +options prefix name version revision epoch long_description description\ +homepage notes provides replaced_by worksrcdir filesdir distname\ +portdbpath libpath distpath sources_conf os.platform os.subplatform\ +os.version os.major os.arch os.endian install.user install.group\ +macosx_deployment_target universal_variant os.universal_supported\ +installs_libs copy_log_files compiler.cpath compiler.library_path\ add_users altprefix # and options that behave like sets -options -setsemantics \ -categories maintainers license conflicts platforms \ -default_variants supported_archs depends_skip_archcheck \ +options -setsemantics\ +categories maintainers license conflicts platforms\ +default_variants supported_archs depends_skip_archcheck\ license_noconflict ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [103053] trunk/dports/net/zabbix2/Portfile
On Feb 12, 2013, at 12:18, ebori...@macports.org wrote:
Revision: 103053
https://trac.macports.org/changeset/103053
Author: ebori...@macports.org
Date: 2013-02-12 10:18:33 -0800 (Tue, 12 Feb 2013)
Log Message:
---
zabbix2: Update dependency.
Modified Paths:
--
trunk/dports/net/zabbix2/Portfile
Modified: trunk/dports/net/zabbix2/Portfile
===
--- trunk/dports/net/zabbix2/Portfile 2013-02-12 17:47:59 UTC (rev 103052)
+++ trunk/dports/net/zabbix2/Portfile 2013-02-12 18:18:33 UTC (rev 103053)
@@ -73,7 +73,7 @@
startupitem.stop${prefix}/share/zabbix/zabbix_server.init stop
array set DBLIST {
-mysql5 {MySQL 5.xpath:bin/mysql_config5:mysql5 \
+mysql5 {MySQL 5.xpath:bin/mysql_config5:mysql5-server
\
mysql=${prefix}/lib/mysql5/bin/mysql_config}
pgsql81 {PostgreSQL 8.1.x port:postgresql81 \
pgsql=${prefix}/lib/postgresql81/bin/pg_config}
Why does zabbix2 now require a local mysql server? Isn't it sufficient for that
server to be running on a different computer? For comparison, you're not
requiring a postgresql server (i.e. you're depending on postgresql81 up there,
not postgresql81-server).
Also, the mysql5 port is being replaced soon hopefully. Please offer variants
for all the new mysql ports (mysql51, mysql55, mariadb, percona) in addition to
the old one (mysql5).
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: RFC: Support for future compilers in base
On Feb 15, 2013, at 02:10, Jeremy Huddleston Sequoia wrote:
I'd like to update base trunk such that future versions of clang, dragonegg,
and gcc just work, so we don't need to wait for newer versions of base to
depend on newer compilers.
That's a great idea! Thanks.
I've taken a first pass at portconfigure.tcl and here is a patch. Comments?
Concerns?
I have not tried it but I read it and it looks good to me. I say commit it,
with the change Rainer pointed out:
On Feb 15, 2013, at 03:58, Rainer Müller wrote:
One minor stylistic comment, when using regexp and you don't care about
the whole match, it's convention in the Tcl community to use - as
variable name:
regexp {macports-clang-(.*)\.(.*)} ${configure.compiler} - major minor
+1
I also get the distinct feeling these could be simplified:
+if {[string first macports-gcc $compiler] == 0 ||
+[string first dragonegg- $compiler] == 0} {
+return no
+} else {
+return yes
}
Can't this be:
return [string first macports-gcc $compiler] == 0 ||
[string first dragonegg- $compiler] == 0
+proc portconfigure::compiler_is_port {compiler} {
+if {[portconfigure::compiler_port_name ${compiler}] == } {
+return no
+} else {
+return yes
+}
+}
Can't this be:
proc portconfigure::compiler_is_port {compiler} {
return [portconfigure::compiler_port_name ${compiler}] ==
}
I haven't actually tested this code but I'm sure a language like Tcl must
support such a construct. But if you want to commit it as you sent it (but with
Rainer's change) we can always refine it later.
On Feb 15, 2013, at 15:06, Sean Farley wrote:
To be honest, Jeremy, the patch is a bad hack, at best. It relies on the
compiler name and does horrible regex matching. What if there's a new
compiler that comes out? For example, let's say Intel releases a free
version for the mac or maybe the Open64 compiler gets a complete port to
the mac? Those would still require an update to base.
The patch is good; it both simplifies and future-proofs what we have in base
now. Obviously we cannot predict what new compilers might be released in the
future, and we'll have to handle those then, if we want to make those compilers
easily accessible to ports then. Of course nothing prevents ports from manually
setting configure.cc et al to any compiler they choose.
What about making this a port group?
-1, it's an improvement of / refinement of what's already in base, and it
should stay in base.
Or maybe making this a better
system of object-oriented-ness (as much as would be allowed in Tcl)?
-1, AFAIK we don't use object-oriented Tcl much (at all?) in base today; no
need to introduce yet more complexity.
On Feb 15, 2013, at 15:29, Jeremy Huddleston Sequoia wrote:
I hate tcl, and it hates me. If you want to do something like that, please
do so, but I'm very limited in what *I* can do based on how much time I
(don't) want to devote to tcl.
Sorry. :) I kind of like Tcl in a weird way. Feel free to send me your Tcl
questions or frustrations.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [103123] trunk/dports/mail/offlineimap/Portfile
On Feb 15, 2013, at 15:03, s...@macports.org wrote:
Revision: 103123
https://trac.macports.org/changeset/103123
Author: s...@macports.org
Date: 2013-02-15 13:03:24 -0800 (Fri, 15 Feb 2013)
Log Message:
---
offlineimap: update repo url to official account
Modified Paths:
--
trunk/dports/mail/offlineimap/Portfile
Modified: trunk/dports/mail/offlineimap/Portfile
===
--- trunk/dports/mail/offlineimap/Portfile2013-02-15 21:03:15 UTC (rev
103122)
+++ trunk/dports/mail/offlineimap/Portfile2013-02-15 21:03:24 UTC (rev
103123)
@@ -5,7 +5,7 @@
PortGroup github 1.0
PortGroup python 1.0
-github.setupspaetz offlineimap 6.5.4 v
+github.setupOfflineIMAP offlineimap 6.5.4 v
categories mail python
platforms darwin
license GPL-2+
@@ -49,7 +49,7 @@
conflicts offlineimap-devel
subport offlineimap-devel {
-github.setupspaetz offlineimap a73b4b34652e
+github.setupOfflineIMAP offlineimap a73b4b34652e
nameofflineimap-devel
version 6.5.4.99
Now the checksums don't match:
$ sudo port checksum offlineimap-devel
--- Fetching distfiles for offlineimap-devel
--- Attempting to fetch offlineimap-a73b4b34652e.tar.gz from
https://github.com/OfflineIMAP/offlineimap/tarball/a73b4b34652e
--- Verifying checksum(s) for offlineimap-devel
Error: Checksum (rmd160) mismatch for offlineimap-a73b4b34652e.tar.gz
Error: Checksum (sha256) mismatch for offlineimap-a73b4b34652e.tar.gz
Error: org.macports.checksum for port offlineimap-devel returned: Unable to
verify file checksums
Please see the log file for port offlineimap-devel for details:
/opt/local/var/macports/logs/_Users_rschmidt_macports_dports_mail_offlineimap/offlineimap-devel/main.log
To report a bug, follow the instructions in the guide:
http://guide.macports.org/#project.tickets
Error: Processing of port offlineimap-devel failed
$
This was basically a stealth update and should have been saved for an occasion
when the version would be increased anyway, or should have been handled as per
the recipe:
https://trac.macports.org/wiki/PortfileRecipes#stealth-updates
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [103118] trunk/dports/devel
On Feb 15, 2013, at 11:05, and.dam...@macports.org wrote:
Revision: 103118
https://trac.macports.org/changeset/103118
Author: and.dam...@macports.org
Date: 2013-02-15 09:05:11 -0800 (Fri, 15 Feb 2013)
Log Message:
---
new port: ninka, source code license identification tool
Added: trunk/dports/devel/ninka/Portfile
+depends_lib bin:/bin/perl:perl5.12
This should be bin:perl:perl5 (the perl5.12 port does not provide a binary
called perl; the perl5 port does (at least until #29763 is resolved)).
+post-patch {
+reinplace s|%%PREFIX%%|${prefix}/share/${name}| ${worksrcpath}/ninka.pl
+}
That's weird; based on the placeholder's name, you'd think %%PREFIX%% would
be replaced with only ${prefix}.
+destroot {
+xinstall -m 755 ${worksrcpath}/ninka.pl ${destroot}/${prefix}/bin/ninka
There should not be a / before ${prefix}.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: RFC: Support for future compilers in base
On Feb 15, 2013, at 5:11 PM, Ryan Schmidt ryandes...@macports.org wrote:
+if {[string first macports-gcc $compiler] == 0 ||
+[string first dragonegg- $compiler] == 0} {
+return no
+} else {
+return yes
}
Can't this be:
return [string first macports-gcc $compiler] == 0 ||
[string first dragonegg- $compiler] == 0
+proc portconfigure::compiler_is_port {compiler} {
+if {[portconfigure::compiler_port_name ${compiler}] == } {
+return no
+} else {
+return yes
+}
+}
Can't this be:
proc portconfigure::compiler_is_port {compiler} {
return [portconfigure::compiler_port_name ${compiler}] ==
}
I think you have the logic backwards. Both of those expressions would have to
be negated before returning the result. Jeremy's original if statements return
no when the conditionals evaluate to true.
vq
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: RFC: Support for future compilers in base
On Feb 15, 2013, at 16:30, Lawrence Velázquez wrote:
On Feb 15, 2013, at 5:11 PM, Ryan Schmidt wrote:
+if {[string first macports-gcc $compiler] == 0 ||
+[string first dragonegg- $compiler] == 0} {
+return no
+} else {
+return yes
}
Can't this be:
return [string first macports-gcc $compiler] == 0 ||
[string first dragonegg- $compiler] == 0
+proc portconfigure::compiler_is_port {compiler} {
+if {[portconfigure::compiler_port_name ${compiler}] == } {
+return no
+} else {
+return yes
+}
+}
Can't this be:
proc portconfigure::compiler_is_port {compiler} {
return [portconfigure::compiler_port_name ${compiler}] ==
}
I think you have the logic backwards. Both of those expressions would have to
be negated before returning the result. Jeremy's original if statements
return no when the conditionals evaluate to true.
Absolutely right. Let's try that again:
On Feb 15, 2013, at 02:10, Jeremy Huddleston Sequoia wrote:
+if {[string first macports-gcc $compiler] == 0 ||
+[string first dragonegg- $compiler] == 0} {
+return no
+} else {
+return yes
}
Can't this be:
return [string first macports-gcc $compiler] != 0
[string first dragonegg- $compiler] != 0
+proc portconfigure::compiler_is_port {compiler} {
+if {[portconfigure::compiler_port_name ${compiler}] == } {
+return no
+} else {
+return yes
+}
+}
Can't this be:
proc portconfigure::compiler_is_port {compiler} {
return [portconfigure::compiler_port_name ${compiler}] !=
}
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: RFC: Support for future compilers in base
On Feb 15, 2013, at 3:10 AM, Jeremy Huddleston Sequoia jerem...@macports.org
wrote:
I'd like to update base trunk such that future versions of clang, dragonegg,
and gcc just work, so we don't need to wait for newer versions of base to
depend on newer compilers.
I've taken a first pass at portconfigure.tcl and here is a patch. Comments?
Concerns?
Shouldn't the second string first expression be looking for
macports-dragonegg?
+if {[string first macports-gcc $compiler] == 0 ||
+[string first dragonegg- $compiler] == 0} {
+return no
+} else {
+return yes
vq
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [103021] trunk/dports/net/tlswrap/Portfile
On Feb 11, 2013, at 23:17, take...@macports.org wrote:
Revision: 103021
https://trac.macports.org/changeset/103021
Author: take...@macports.org
Date: 2013-02-11 21:17:38 -0800 (Mon, 11 Feb 2013)
Log Message:
---
tlswrap: updated homepage. added license and livecheck.
Modified Paths:
--
trunk/dports/net/tlswrap/Portfile
+post-destroot {
+xinstall -d -m 755 ${destroot}${prefix}/share/${name}
+xinstall -d -m 755 ${destroot}${prefix}/share/${name}/doc
xinstall creates intermediate directories for you. 755 is the default mode for
directories.
Documentation should go in ${prefix}/share/doc/${name}. See man porthier or
https://trac.macports.org/wiki/PortfileRecipes#doc
+foreach f {COPYING ChangeLog README} {
+copy ${worksrcpath}/${f} ${destroot}${prefix}/share/${name}/doc
+}
You can do this in a single xinstall invocation; no need for a loop.
xinstall -m 644 -W ${worksrcpath} COPYING ChangeLog README
${destroot}${prefix}/share/doc/${name}
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Detect opportunistic linking and unnecessary dependencies
It would be great if MacPorts would automatically detect dependency problems when installing ports. For example, if a port links with a library but does not declare a dependency on it, I'd love to see a warning: Warning: /opt/local/bin/foo links with /opt/local/lib/libbar.dylib but port foo does not declare a library dependency on port bar Conversely, how about a warning when a library dependency is declared but that port is not actually linked with: Warning: none of the files installed by port foo link with any of the libraries installed by library dependency bar This is more problematic to implement because some ports open libraries via dlopen (i.e. wine), and things like python modules don't link with the other modules they depend on either. But on the other hand it's also important to have this check, because I really want to be able to easily find all the ports to which we've added unnecessary library dependencies over the years due to the glibtool overlinking problem that we've now corrected in base. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
