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

Re: Replacement for cd
by Rainer Müller 03 Oct '07

03 Oct '07

Kevin Ballard wrote: > Since the cd command has been removed from trunk, perhaps another > command could be added to fill in the void? I'm proposing a command that > acts like cd but takes a block and executes the block within the given > directory, then restores the old working directory before continuing on. Is this really necessary? All calls could be done using absolute paths. And prefixing with ${destroot}${prefix} or ${worksrcdir} is not that long. I don't think there should be too much complexity on commands in Portfiles. Rainer

1 0

Re: Replacement for cd
by Yves de Champlain 03 Oct '07

03 Oct '07

Le 07-10-02 à 18:23, Kevin Ballard a écrit : > Since the cd command has been removed from trunk, perhaps another > command could be added to fill in the void? I'm proposing a command > that acts like cd but takes a block and executes the block within > the given directory, then restores the old working directory before > continuing on. > > Any thoughts? Please or thanks, maybe both ! yves

1 0

Port update for qt4-mac
by Michael Wild 03 Oct '07

03 Oct '07

Hi I submitted an updated Portfile for qt4-mac version 4.3.1. For the details see http://trac.macports.org/projects/macports/ticket/12846 Quite a lot changed, so please have a close look at it. Regards Michael

1 0

Split Trunk
by Anders F Björklund 03 Oct '07

03 Oct '07

For MacPorts 1.6.0, I think you should split the "dports" trunk in two, "trunk" and "release", just as done with the "base". There is just too much port breakage with running the latest developer version on the user machines, IMHO. It also needs a cooler name... Such as "Evolution", as in: I'm running the latest MacPorts Evolution. :-) --anders

7 13

Replacement for cd
by Kevin Ballard 02 Oct '07

02 Oct '07

Since the cd command has been removed from trunk, perhaps another command could be added to fill in the void? I'm proposing a command that acts like cd but takes a block and executes the block within the given directory, then restores the old working directory before continuing on. Any thoughts? -- Kevin Ballard http://kevin.sb.org eridius(a)macports.org http://www.tildesoft.com

1 0

compiler selection
by Michael Wild 02 Oct '07

02 Oct '07

Hi all I wonder what the policy/methodology is concerning compiler selection. I perused the MacPorts guide but couldn't find anything. Am I right in the assumption that MacPorts automatically comes with its own gcc compiler suite and requires it to be present (I think I read something like that somewhere in the FAQ)? If so, on which one can I rely to be there? gcc32, gcc40/1/2 or apple-gcc40? just because the executable have all different names... My problem actually is that a port which I'm preparing requires gfortran which doesn't come with Apple's system gcc but is in port:gcc42. I could simply do "configure.fc ${prefix}/bin/gfortran-mp-4.2, but what if someone has another gcc installed? I could depends_build on gcc42 but if a gcc suite is required by MacPorts anyways I wouldn't like to impose something which might install another compiler suite unnecessarily. So, currently I do a hacky set gfortran [lindex [lsort -decreasing [glob \ -type f "${prefix}/bin/gfortran*"]] 0] configure.fc ${gfortran} and hope to get the compiler with the highest version number. For my installation this works, but I'm quite unhappy with it. Does anyone know a better solution to that problem? Thanks for the help Michael

4 5

Trac ticket Cc list should be changeable by anybody
by Ryan Schmidt 02 Oct '07

02 Oct '07

Apparently our Trac install doesn't allow just anybody to add themselves to a ticket's Cc list. I think it should. Can we change it?

2 1

Re: [29593] trunk/www (install.php)
by Anders F Björklund 02 Oct '07

02 Oct '07

> Log Message > * Rename the getmp.php page to a better suited install.php, update > references; > * Provide extra information in the new install.php, which I believe > should be > somewhat merged with the new guide efforts (next to be discussed on > macports-dev@). > > Modified Paths > • trunk/www/includes/header.inc > • trunk/www/index.php > > Added Paths > • trunk/www/install.php > > Removed Paths > • trunk/www/getmp.php The System Requirements of MacPorts needs to be explained better on this page. (it also needs a Don't Panic button in nice friendly letters up at the top :) ) It needs to say what versions of Mac OS X that Panther and Tiger represent... Probably "Mac OS X 10.3.9" and "Mac OS X 10.4.10" to make sure they're updated. Additionally it needs to mention Jaguar and earlier, as well as (Open)Darwin OS ? Something like "previously it also supported older versions", or "now unsupported" BTW: The binary packages for FreeBSD and Fedora are operational, so I might add those as part of the "experimental support" for those two operating system platforms... Both the BSD Makefile and RPM Specfile are rather small, so they could probably go in the "portmgr" directory directly - instead of being a separate download. Should work OK with FreeBSD 6.2 and Fedora Core 5+ / Red Hat Enterprise Linux 5, as well as with the FreeBSD "CURRENT" and Fedora "Rawhide" development versions. --anders

2 1

Heads up: MacOSForge machine reorganizations
by James Berry 02 Oct '07

02 Oct '07

This is just a general heads up that the wonderful folks at macosforge are doing some machine migrations (more power for the masses...) in the coming days and weeks. They, and we, will try to minimize any service interruptions for MacPorts, but please be aware that this is afoot, and that there may be some temporary interrupts to mail, web, trac, svn, etc... If critical services are down, and you're not sure what's going on, you might try our irc channel, where up to date information (or perhaps flat-out speculation) will be available ;) James

1 0

smoothing leopard
by Paul Phillips 01 Oct '07

01 Oct '07

Leopard is supposed to come out this month (for real this time) and there are many ports that don't build - a lot more than there are bug reports. Maybe it's not a big priority but if it's of interest I have a leopard test system and can gather data on what doesn't build and why. If there is a consensus to let leopard settle further before worrying about it, then I don't want to clutter trac with bug reports. Is there a clear delineation between what should be considered an upstream bug and what should be addressed in macports? Sometimes it's obvious but not always. -- Paul Phillips | These are the climbs that apply men's soles. Vivid | Empiricist | pull his pi pal! |----------* http://www.improving.org/paulp/ *----------

2 1