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

Update for Player 2.0.4
by Regis Vincent 05 May '07

05 May '07

hi, Player 2.0.4 has been released yesterday I have submit a path to the Portfile to keep it up to date, can you someone commit it, please ! thanks. Ticket 11906: http://trac.macports.org/projects/macports/ticket/11906

1 0

Re: [24808] trunk/dports/gnome/libgtop/Portfile
by Ryan Schmidt 05 May '07

05 May '07

On May 4, 2007, at 19:48, source_changes(a)macosforge.org wrote: > Revision: 24808 > http://trac.macosforge.org/projects/macports/changeset/24808 > Author: rhwood(a)macports.org > Date: 2007-05-04 17:48:21 -0700 (Fri, 04 May 2007) > > Log Message: > ----------- > Clean configuration settings per ticket:11664 > > Modified Paths: > -------------- > trunk/dports/gnome/libgtop/Portfile > > Modified: trunk/dports/gnome/libgtop/Portfile > =================================================================== > --- trunk/dports/gnome/libgtop/Portfile 2007-05-05 00:46:49 UTC > (rev 24807) > +++ trunk/dports/gnome/libgtop/Portfile 2007-05-05 00:48:21 UTC > (rev 24808) > @@ -18,5 +18,4 @@ > use_bzip2 yes > configure.args --mandir=${prefix}/share/man --infodir=${prefix}/ > share/info \ > --disable-static > -configure.env CPPFLAGS="-L${prefix}/lib -I${prefix}/include" \ > - CFLAGS="-no-cpp-precomp -lintl" > +configure.cflags-append -lintl Randall, I see you making these changes to many ports. Your log message only refers to ticket #11664 but you're also removing -no-cpp- precomp which isn't mentioned in that ticket. What's -no-cpp-precomp for, why was it in all those ports before, and why is it ok to remove it now? Thanks.

1 0

dependency options in portfiles
by Glen Whitney 05 May '07

05 May '07

Dear MacPorts folks, Portfiles currently have three dependency options: depends_build, depends_run, and depends_lib. However, the correspondence between these options and the processing phases (I guess "targets" in the internal terminology of the MacPorts base code) is weak: depends_build does record the dependencies that are necessary for the build target, but there is no run target or lib target, rather the following rich collection of targets: main, unarchive, fetch, checksum, extract, patch, configure, build, test, destroot, archive, install, activate (and port understands the relationship among these with the requires/provides attributes of the targets). Currently, depends_run corresponds to the destroot phase (but conceptually it seems like it should either correspond to test or activate, from the name) and depends_lib corresponds to configure. In any case, it's clearly natural to classify dependencies by the phase at which they kick in; and conversely, various other of the above phases could quite reasonably have dependencies specific to them. For example, if a package is released with a spiffy new compression algorithm which is not yet universally available, the extract step for that package could depend on the port of the decompressor for that algorithm. Or the real backstory here: I'm trying to create Portfiles which capture the current gtk+osx build process, which I have gotten to work manually all the way up to Gnucash, but which I never want to have to do by hand again. Currently one needs to extract the cairo development head by git for this all to work. I would therefore like the fetch phase to depend on the git port, but currently there's no way to specify any dependency for fetch. So the following proposal seems like it would be a big win to me. Each target should have an optional depends attribute, i.e. configure.depends port:libiconv #typical case now or fetch.depends port:git_core #my case or activate.depends port:ghostview #e.g., previewer is never used until active pkg is invoked by user, but this is our Last Chance Before MacPorts executes any target, it would ensure that all of the dependencies for that target (and the targets it requires, i.e. the earlier build phases) are activated. From looking at the code, there are a number of places where the list of targets is reiterated in order to figure out whether to compute dependencies, which depends options to look at, etc. It seems to me that this change would actually end up simplifying the code noticeably and remove a number of these anti-modular lists of targets in the code, easing any potential addition of future targets. Of course, for backwards compatibility, depends_lib, depends_build, and depends_run would remain as (deprecated) aliases of configure.depends, build.depends, and destroot.depends. (How do I implement that aliasing? I'm not experienced with Tcl.) What do people think? I'm happy to write and submit a patch to make this change if the new functionality stands a high likelihood of being accepted. From reading the code, and writing the patch for a -y "dry run" option (submitted to ticket #11892, which may be of independent interest), I do not think that it will be that hard. Thanks for your thoughts, Glen

1 0

python2.5 has wrong value for distutils.sysconfig.get_config_var("PYTHON")
by David Glasser 04 May '07

04 May '07

[oops, wasn't on mailing list the first time I tried to send this] Currently, MacPorts installs python2.4 as /opt/local/bin/python and Python 2.5 only as python2.5. However, the Python 2.5 install doesn't know this; in its makefile (which ends up installed as /opt/local/lib/python2.5/config/makefile), it still believes that PYTHON= python$(EXE) which means that distutils.sysconfig.get_config_var("PYTHON") returns "python" instead of "python2.5", which means that python programs that rely on this config var to be able to run python from the command line run the wrong version of python. Can we fix the build process so that python 2.5 is configured with PYTHON=python2.5, instead of tricking it into thinking it is called python and just deleting python in the post-destroot? --dave -- David Glasser | glasser(a)mit.edu | http://www.davidglasser.net/ -- David Glasser | glasser(a)mit.edu | http://www.davidglasser.net/

3 5

Stellarium Port
by Salvatore Domenick Desiano 04 May '07

04 May '07

Paul and I just had a talk about the Stellarium port. The port was once useful when there were no binaries available for OSX, but now the project is releasing DMG's on a regular basis. Not only that, there is some undocumented voodoo for building on OSX/Intel, which we don't have in our portfile. As maintainer of the port, I recommend that we remove it from our port tree. Objections? As a person who keeps forgetting to get his commit bit set, can somebody do the deed? I can file a bug if that person prefers. Thank you. -- Sal smile -------------- Salvatore Domenick Desiano Doctoral Candidate Robotics Institute Carnegie Mellon University

2 2

Mutt-devel problem, maybe headers-cache
by Sbranzo 03 May '07

03 May '07

Maybe someone could help me with mutt-devel. After forcing portindex update I was trying to port upgrade mutt-devel but: sudo port upgrade outdated Password: ---> Building mutt-devel with target all Error: Target com.apple.build returned: shell command " cd "/opt/local/var/db/dports/build/_opt_local_var_db_dports_sources_rsync.rsync.darwinports.org_dpupdate_dports_mail_mutt-devel/work/mutt-1.5.15" && make all " returned error 2 Command output: ( echo '#include "config.h"'; echo '#include "mutt.h"'; ) \ | gcc -E -DPKGDATADIR=\"/opt/local/share/mutt\" -DSYSCONFDIR=\"/opt/local/etc\" -DBINDIR=\"/opt/local/bin\" -DMUTTLOCALEDIR=\"/opt/local/share/locale\" -DHAVE_CONFIG_H=1 -I. -I. -I. -I. -I. -I./imap -Iintl -I/opt/local/include/db4 -I/opt/local/include -I/opt/local/include/db44 -I/opt/local/include -I./intl - | ./hcachever.sh hcversion.h ERROR: no MD5 tool found <built-in>:0: fatal error: when writing output to : Broken pipe compilation terminated. make: *** [hcversion.h] Error 1 This is the current installed version: $ port installed mutt-devel The following ports are currently installed: mutt-devel @1.5.14_1+db4+headercache+imap+pop (active) Maybe I'm overlooking something trivial. Thanks, Gufo

2 3

Re: [24526] trunk/dports/lang/gcc42/Portfile
by Juan Manuel Palacios 03 May '07

03 May '07

Hey Markus! On Apr 27, 2007, at 11:30 AM, source_changes(a)macosforge.org wrote: > Revision > 24526 > Author > mww(a)macports.org > Date > 2007-04-27 08:30:45 -0700 (Fri, 27 Apr 2007) > Log Message > > version (prerelease) 4.2.0-20070316, change program suffix to "-mp-$ > {major}" Nice going with this rename, in sync with my dp2mp-move branch ;-) Will we see this move in other gcc ports, like gcc41, even though they're no longer current? I figure some users might still have a need for them, and will probably be confused by the deprecated "dp" prefix. Maybe we should get a message out to all port maintainers who use any incarnation of [dD]arwin[pP]orts in their installations to move to the new naming.... /me thinks... -jmpp

3 3

Job control in tcsh 6.15.00
by Salvatore Domenick Desiano 02 May '07

02 May '07

Anybody else having trouble with job control in the current version of tcsh? I just upgraded from 6.13, and I can no longer suspend or interrupt programs. -- Sal smile. -------------- Salvatore Domenick Desiano Doctoral Candidate Robotics Institute Carnegie Mellon University

1 0

Fixed-width font in commit mails?
by Ryan Schmidt 02 May '07

02 May '07

Could a fixed-width font be used in the diff section of the commit mails? That would help columns to align properly.

4 9

Let's add variant descriptions
by Ryan Schmidt 02 May '07

02 May '07

How hard would it be to let variants have descriptions? I think the time has come for that feature to be implemented. Sometimes the single word or abbreviation comprising the variant name just really isn't enough information for the user to fully understand what the variant does. I have been trying to add descriptions to my ports' variants, in the comments in the portfile, but I would like to be able to display these to the user. I see two necessary steps: 1) Allow some (optional!) syntax within the variant to specify a description, like variant macplus { description Emulate a Macintosh Plus with 4 MB RAM and 6 drives ... } or variant macplus { variant_description Emulate a Macintosh Plus with 4 MB RAM and 6 drives ... } 2) Modify the display of "port info" to show the variant description, like $ port info minivmac minivmac 2.8.2, Revision 1, emulators/minivmac http://minivmac.sourceforge.net/ Mini vMac is a Macintosh emulator. It emulates the earliest Macs, from the original Mac 128K (built 1984-85) to the Mac SE (1987-1990). The default is to emulate a Mac Plus (1986-1990); this is also the best-tested and therefore recommended emulation. To use Mini vMac, you need a ROM file from the type of machine you're emulating. Mac ROMs are copyrighted by Apple, so you must extract the ROM from a real physical Mac that you own. Use the CopyROM program for this, which you can download from the Mini vMac web site (More > Extras). Variants: universal: Build a universal binary mac128k: Emulate a Macintosh with 128K RAM and 2 drives mac512k: Emulate a Macintosh 512K with 512K RAM and 2 drives mac512ke: Emulate a Macintosh 512Ke with 512K RAM and 6 drives macplus: Emulate a Macintosh Plus with 4 MB RAM and 6 drives macse: Emulate a Macintosh SE with 4 MB RAM and 6 drives Maintainers: ryandesign(a)macports.org Variants that have no description (i.e. all variants currently) would show up just like that, but with just the variant name and no colon afterward: Variants: universal mac128k etc. Note that I think the automatic platform variants like macosx and darwin_8 should not appear at all in port info. Comments?

3 4