How can I determine if a function is available?

[Boey Maun Suang]

>>> 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 at fastmail.fm