March 2007 - macports-dev - lists.macosforge.org

cairo-devel is ancient/broken
by Mark Duling 26 Mar '07

26 Mar '07

cairo-devel is ancient, broken, and looks unnceccesary now. The tarball is fetched from ~/pkern. Can it be deleted? Mark

3 6

MacPorts roadmap & new milestones
by Juan Manuel Palacios 25 Mar '07

25 Mar '07

Evening everyone! Thanks to the kind help provided by Elias Pipping, our new project roadmap is up at: http://trac.macports.org/projects/macports/roadmap For those of you who actively use it, the major changes you'll notice are that the "Available Ports" milestone has been deleted (tickets belonging to it reassigned according to the new guidelines referenced below) and four new ones have been added: "Port Bugs", "Port Enhancements", "Port Updates" and "Needs developer review". The guidelines to use them all will be shortly up at: http://trac.macports.org/projects/macports/wiki/TracTicketing [1] Needless to say, these wont be Godly mandates, but I would still like to request that all those of you with Wiki edit privileges wishing to give your feedback & input on them run by me any edits you might want to make to that document (Elias and I just spent several hours cleaning up the old roadmap, so we can tell you that dealing with so many tickets gets a bit tiring a bit too quickly, and therefore we would like to avoid ambiguous instructions as much as possible!). Regards to all and thanks again to Elias! -jmpp [1] Out of date with respect to the new layout as of this posting, g'me some time to work on the document and bring it up to speed, I'm beat right now! I am nevertheless still sending this message *now* (with an old document in place) because I fear some might get confused with the new and missing milestones and no information what-so-ever on the changes.

1 0

Always add -L${prefix}/lib, -I${prefix}/include?
by Ryan Schmidt 25 Mar '07

25 Mar '07

Many ports have had to add -L{$prefix}/lib to the LDFLAGS and -I$ {prefix}/include to the CFLAGS. Wouldn't it be much easier if the MacPorts infrastructure would add that to the LDFLAGS and CFLAGS generally for all ports? Could that hurt anything? I would think the same should apply to CPPFLAGS and/or CXXFLAGS, not that I have yet understood why there are two variables for C++ code or what the difference is between them.

3 9

Re: [22998] trunk/dports/lang
by Randall Wood 25 Mar '07

25 Mar '07

You may wish to recreate a iovm port along the lines the last revision of the abiword2 port (http://trac.macports.org/projects/macports/browser/trunk/dports/gnome/abiwo…) where the port was revised to replace itself when upgraded with the new port. This would allow us to implement a seamless upgrade process to the new port name so that users of the iovm port will get updates to the Io port. -- Randall Wood rhwood(a)mac.com "The ball is round. The game lasts ninety minutes. The rest is theory..." On Wednesday, March 21, 2007, at 11:07AM, <source_changes(a)macosforge.org> wrote: >Revision: 22998 > http://trac.macosforge.org/projects/macports/changeset/22998 >Author: pipping(a)macports.org >Date: 2007-03-21 08:02:38 -0700 (Wed, 21 Mar 2007) > >Log Message: >----------- > * move io to Io > >Added Paths: >----------- > trunk/dports/lang/Io/ > trunk/dports/lang/Io/Portfile > >Removed Paths: >------------- > trunk/dports/lang/Io/Portfile > trunk/dports/lang/io/ > >Copied: trunk/dports/lang/Io (from rev 22996, trunk/dports/lang/io) > >Deleted: trunk/dports/lang/Io/Portfile >=================================================================== >--- trunk/dports/lang/io/Portfile 2007-03-21 14:56:35 UTC (rev 22996) >+++ trunk/dports/lang/Io/Portfile 2007-03-21 15:02:38 UTC (rev 22998) >@@ -1,39 +0,0 @@ >-# $Id$ >- >-PortSystem 1.0 >- >-name iovm >-version 2005-02-22 >-categories lang >-platforms darwin >-maintainers nomaintainer(a)macports.org >-description Io is small prototype-based programming language >-long_description Io is small prototype-based programming language. The \ >- ideas in Io are mostly inspired by Smalltalk (all values are \ >- objects), Self, NewtonScript and Act1 (prototype-based \ >- differential inheritance, actors and futures for concurrency), \ >- LISP (code is a runtime inspectable/modifiable tree) and Lua \ >- (small, embeddable). >- >-homepage http://www.iolanguage.com/ >-master_sites http://io.urbanape.com/release/ \ >- http://www.sigusr1.org/~steve/ >-distname IoVM-${version} >-checksums md5 a9d733490adf941daf11486a9183c958 >- >-extract.post_args "| tar -xf - --exclude '_old'" >- >-patch { >- cd ${worksrcpath} >- reinplace "s|/usr/local|\$(DESTDIR)${prefix}|g" IoVM/Makefile \ >- Makefiles/IoDesktop/Makefile Makefiles/IoServer/Makefile \ >- Makefiles/IoVM/Makefile >-} >- >-post-destroot { >- xinstall -m 755 -d ${destroot}${prefix}/share/doc >- file delete -force ${destroot}${prefix}/lib >- file copy ${worksrcpath}/IoVM/_include ${destroot}${prefix}/include/iovm >- file copy ${worksrcpath}/IoVM/_libs ${destroot}${prefix}/lib >- file copy ${worksrcpath}/IoVM/_docs ${destroot}${prefix}/share/doc/${name} >-} > >Copied: trunk/dports/lang/Io/Portfile (from rev 22997, trunk/dports/lang/io/Portfile) >=================================================================== >--- trunk/dports/lang/Io/Portfile (rev 0) >+++ trunk/dports/lang/Io/Portfile 2007-03-21 15:02:38 UTC (rev 22998) >@@ -0,0 +1,39 @@ >+# $Id$ >+ >+PortSystem 1.0 >+ >+name io >+version 2005-02-22 >+categories lang >+platforms darwin >+maintainers nomaintainer(a)macports.org >+description Io is small prototype-based programming language >+long_description \ >+ Io is small prototype-based programming language. The ideas in Io are \ >+ mostly inspired by Smalltalk (all values are objects), Self, \ >+ NewtonScript and Act1 (prototype-based differential inheritance, actors \ >+ and futures for concurrency), LISP (code is a runtime inspectable / \ >+ modifiable tree) and Lua (small, embeddable). >+ >+homepage http://www.iolanguage.com/ >+master_sites http://io.urbanape.com/release/ \ >+ http://www.sigusr1.org/~steve/ >+distname IoVM-${version} >+checksums md5 a9d733490adf941daf11486a9183c958 >+ >+extract.post_args "| tar -xf - --exclude '_old'" >+ >+patch { >+ cd ${worksrcpath} >+ reinplace "s|/usr/local|\$(DESTDIR)${prefix}|g" IoVM/Makefile \ >+ Makefiles/IoDesktop/Makefile Makefiles/IoServer/Makefile \ >+ Makefiles/IoVM/Makefile >+} >+ >+post-destroot { >+ xinstall -m 755 -d ${destroot}${prefix}/share/doc >+ file delete -force ${destroot}${prefix}/lib >+ file copy ${worksrcpath}/IoVM/_include ${destroot}${prefix}/include/iovm >+ file copy ${worksrcpath}/IoVM/_libs ${destroot}${prefix}/lib >+ file copy ${worksrcpath}/IoVM/_docs ${destroot}${prefix}/share/doc/${name} >+} > >

2 1

port should not complain about +universal, CFLAGS/LDFLAGS, configure.universal_cflags-append/configure.universal_ldflags-append
by Ryan Schmidt 25 Mar '07

25 Mar '07

When installing gettext +universal, port warns me that it might not work because the port already overrides CFLAGS or LDFLAGS: $ sudo port install gettext +universal Warning: This port already overrides CFLAGS or LDFLAGS. The universal variant may break it. ---> Extracting gettext ---> Applying patches to gettext ---> Configuring gettext ---> Building gettext with target all ---> Staging gettext into destroot ---> Installing gettext 0.16.1_0+universal ---> Activating gettext 0.16.1_0+universal $ However, this is not a problem here because the gettext port deals with the situation: if {[llength [info commands configure.universal_ldflags-append]] > 0} { configure.universal_ldflags-append -L$prefix/lib configure.universal_cflags-append -I$prefix/include -no-cpp-precomp } else { variant universal { return -code error "You need to be running MacPorts 1.4.0 or higher to \ use this variant (universal)." } } port should not print that warning if configure.universal_cflags- append or .universal_ldflags-append are used.

4 8

Re: [22768] trunk/base
by Juan Manuel Palacios 24 Mar '07

24 Mar '07

On Mar 23, 2007, at 3:00 PM, Kevin Ballard wrote: > It probably should. I didn't think of that. Feel free to fix it. Fixed in r23083 and merged to 1.4 in r23084. > > I assume clean removes the other configure-generated files, yes? > The clean target cleans build products, distclean calls clean and then removes autoconf generated files (I followed that rule in the registry1.0's Makefile). -jmpp

1 0

gdl-0.9pre4_1
by Takeshi Enomoto 24 Mar '07

24 Mar '07

Hello all, I updated the portfile for GNU Data Language. * resolved the conflict with antlr by renaming libantlr.a to libantlr_gdl.a. * added a variant proj that enable map projection. <http://trac.macosforge.org/projects/macports/ticket/11612> Please take a look and commit this if it is good. Takeshi

1 0

nco-3.1.9_1
by Takeshi Enomoto 24 Mar '07

24 Mar '07

I revised nco-3.1.9 to enable ncap2 variants back. <http://trac.macosforge.org/projects/macports/ticket/11611> Please review this fix and commit. BTW, the cause of the failure is case sensitivity (there are Ncap2.hh and ncap2.hh in the same directory). I moved ncap2.hh to ncap.hh and reinplace'd #include <ncap2.hh> then extracted Ncap2.hh. I wonder if there is a better way or standard solution. Thanks. Takeshi

1 0

Re: Can so commit?
by Elias Pipping 24 Mar '07

24 Mar '07

done and done.[1][2] [1] http://trac.macports.org/projects/macports/changeset/23057 [2] http://trac.macports.org/projects/macports/changeset/23058 Regards, Elias Pipping On Mar 24, 2007, at 2:46 AM, Rolf Würdemann wrote: > Hi ;) > > I've submitted new versions of > > gwyddion (2.5, Ticket #11545, > http://trac.macports.org/projects/macports/ticket/11545) > > and > > qucs (0.0.11, Ticket #11608, > http://trac.macports.org/projects/macports/ticket/11608) > > (The directory files can now get deleted (svn rm files) > > may someone commit? ;) > > reg's > > Rolf > -- > Security is an illusion - Datasecurity twice > Rolf Würdemann - private: rowue(a)digitalis.org - office: > rowue(a)crew-gmbh.de > GnuPG fingerprint: 7383 348F 67D1 CD27 C90F DDD0 86A3 31B6 67F0 D02F > > > > _______________________________________________ > macports-users mailing list > macports-users(a)lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo/macports-users

1 0

Proposal: select tool for python, gcc, swi-prolog, etc.
by Weissmann Markus 23 Mar '07

23 Mar '07

Hi all, here is a proposal to solve the "I don't like the program X to be called Y" problem. This problem normally looks like: A prefers Python 2.4 to be called when "python" is executed, while B prefers Python 2.5 in this case. Meanwhile C complains that for a silly python script a while python installation is compiled on his poor G3 ibook when there is Apple's python which would work just fine. I already saw the same pattern for gcc, coreutils, gnutar, sed, swi- prolog, etc. To overcome this, we should install tools much like Apple's "gcc_select" which own the executables (e. g. ${prefix}/bin/python) and perhaps stuff like their manpages (e. g. ${prefix}/share/man/man1/ python.1.gz). They will carry the generic name as portname (e. g. Python). When their script is called, they take the version number (or special name - swi-prolog vs. swi-prolog-lite), check if the special files (e. g. ${prefix}/bin/python2.5 and ${prefix}/share/man/ man1/python25.1.gz) are there and then switch it's symlinks to the version specified. In the default case, they would point to Apple's version of the tool - if available. It is also possible to switch to that version: $> python -V Python 2.3.5 $> python_select 2.4 $> python -V Python 2.4.3 $> python_select 2.5 Python 2.5 is not installed! $> port install python25 $> pythjon_select 2.5 Python is now Python 2.5 Python 2.5 $> python_select apple $> python -V Python 2.3.5 It would be nice if we wouldn't just create multiple tools for all of our applications (gcc, python, etc.) but rather find the common pattern here. These tools should be installable as normal ports and not be part of the base port system. As an implementation idea: Perhaps creating a generic "select" tool that reads a config file depending on the executables name. The config file would have the possible interpreters/compilers/.. and their respective files to symlink to. I'm currently out of time, so if someone would like to implement this, please shout out loud, so we can find a place to develop this. Perhaps this could even be a small to medium task for GSoC? cheers, -Markus PS: This would of course mean, that calling ${prefix}/bin/python will execute in some random interpreter! Please, if your port relies on a specific version of e. g. Python, please specify this _explicitely_ (call e. g. ${prefix}/bin/python2.4). --- Markus W. Weissmann http://www.mweissmann.de/

2 1