aqua/radassist/Portfile: system "[command patch] < \"$ {workpath}/patch-darwinports\""
Yeah, that's awful. It would take a bit of work to fix. It looks like a large number of non-MacPorts paths are hardcoded into this project, and the patchfile combined with a reinplace and this system command are trying to replace them with the correct MacPorts prefix.
Aside from the fact that the radassist port has a really badly generated patchfile ("diff -ur ../radassist-0.9.6rc3.orig/10.3- desktop-negative.T ./10.3-desktop-negative.T" -- sorry to whoever wrote it, but yuck!), it's easy to fix; I just used grep and sed to pull out the names of the files that get patched and fed those as arguments to the reinplace command: <snip> patchfiles patch-darwinports post-patch { reinplace "s|@PREFIX@|${prefix}|g" \ 10.2-desktop-negative.T \ <...etc... /> } </snip> Perhaps whoever wrote it wasn't aware of patchfiles at the time (it seems like it was available, given the post-patch usage), but it really wasn't that painful. I can submit a ticket to get it fixed, if you like, but it would probably be worth updating the port to the current version while we're at it, as it's 18 months out of date.
devel/curlhandle/Portfile: system "[command build]"
It looks like it's calling build a second time to build a second item ("Tester").
devel/libsdl-framework/Portfile: system "[command build]"
It looks like it's using Xcode to build the target "Framework", then build again with the target "All". Can the xcode portgroup help here?
net/nefu/Portfile: system "[command build]"
It seems to build once in the main directory, then build again in the subdirectory "TDK".
textproc/gpsbabel/Portfile: system "[command build]"
Not sure exactly what's going on but it seems to be doing a lot of Xcode trickery too. xcode portgroup again?
Looking at the xcode portgroup, it supports the setting of multiple build targets by building each in order, just like setting multiple targets for the standard make build command does. Unlike make, though the xcodebuild(1) manpage seems to suggest that it supports build either only one target (via -target) or all targets defined in the project (via -alltargets), so it seems that the xcode portgroup will be required. That should take care of libsdl-framework and gpsbabel. As far as I can tell, however, work on base to allow for executing $ {build} in multiple directories would probably be necessary to deal with curlhandle and nefu, as well as with the dovecot-sieve plugin that I've been trying to write a port for. I haven't looked at the other two, but the dovecot-sieve source has been written on the premise that it will be extracted in a directory _adjacent_ to the main dovecot sources (i.e. ${blah}/dovecot-${version} and ${blah}/ dovecot-sieve-${version}), _and_ that that it will be build against the main dovecot sources _in the places in which the object files will be emitted by default in the dovecot build directory_. It seems like an awful lot of hacking on the Makefiles (which I'm not comfortable about doing just yet) would be needed to get dovecot- sieve to work without using [command build], either as a variant or as a separate port. If anyone can think of a nicer way of fixing the latter than by base allowing for the running of ${build} in multiple directories, I'm all ears (or eyes), but I can't see a better way of doing it. Kind regards, Maun Suang -- Boey Maun Suang (Boey is my surname) Mobile: +61 403 855 677 Email: boeyms@fastmail.fm