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: [EMAIL PROTECTED]
_______________________________________________
macports-dev mailing list
[EMAIL PROTECTED]
http://lists.macosforge.org/mailman/listinfo/macports-dev
