How can I determine if a function is available?

[Ryan Schmidt]

On Apr 10, 2007, at 08:20, Daniel J. Luke wrote:

> On Apr 10, 2007, at 2:48 AM, Ryan Schmidt wrote:
>
>> If I do that, how can I avoid each port (php5-apache2, php5- 
>> fastcgi, etc.) having to download the php5 source again?
>
> By setting distname and dist_subdir
>
> (like the apr port used to do to share the apache2 distfile:
>
> http://trac.macports.org/projects/macports/browser/trunk/dports/ 
> devel/apr/Portfile?rev=5083
>
> )

Thanks for that! I was sure I had seen that somewhere before, I just  
couldn't quite remember where.


>> I'm not sure that making separate ports is the best strategy. The  
>> FastCGI version of PHP is not a separate software package. Rather,  
>> it's just one of the many ways in which PHP can be installed. It's  
>> a variation, a variant. And it seems most logical that it be  
>> implemented in MacPorts in that way, as a variant.
>
> of course, the downside of variants is that nothing can depend on  
> them being there (which is why, for instance, the various  
> subversion bindings ports are not implemented as variants, even  
> though the current setup requires lots of extra build time which is  
> otherwise unnecessary).

So wouldn't we most accurately call that a deficiency in base that  
should be corrected, rather than bastardizing the portfiles to work  
around the deficiency? :)


>> Isn't there a way in tcl to detect if a certain function exists?
>
> I'm not sure if there is ... I would have to look it up.
>
> ... but even if there was, the point Landon was trying to make (I  
> think) was that that was private/internal API that ports shouldn't  
> be using. If there's really no good way to do what needs to be done  
> some other way with the portfile, then we should enhance base/ to  
> provide hooks for it instead of using command_exec.
>
>> I note, by the way, that there are several other ports already  
>> using the "command" command, which will break when MacPorts 1.5  
>> (or whatever version) is released which removes the "command"  
>> command:
>>
>> dports $ grep '\[command' */*/Portfile
>> aqua/radassist/Portfile:        system "[command patch] < \"$ 
>> {workpath}/patch-darwinports\""
>> devel/curlhandle/Portfile:      system "[command build]"
>> devel/libsdl-framework/Portfile:           system "[command build]"
>> net/nefu/Portfile:      system "[command build]"
>> textproc/gpsbabel/Portfile:                     system "[command  
>> build]"
>
> These should probably be fixed.

First problem is that the only one of those ports that has a  
maintainer is gpsbabel. Does anyone care about the other ports?  
Someone who cares will have to be the one to fix them.

Let me take a quick look at why they're using this syntax:

>> 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.

>> 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?