How can I determine if a function is available?

[Paul Guyot]

On Apr 14, 2007, at 6:16 AM, Ryan Schmidt wrote:

> On Apr 13, 2007, at 08:49, Daniel J. Luke wrote:
>
>> On Apr 12, 2007, at 10:37 PM, Boey Maun Suang wrote:
>>
>>> 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.
>>
>> Instead of [command build] you could do what the build command  
>> would be doing...
>>
>> ie, system "cd whatever/ && make"
>>
>> It's not ideal (and probably base/ should be enhanced to have  
>> hooks so you don't have to do that sort of thing), but it doesn't  
>> involve using internal API.
>
> How would such hooks differ from the private API that's already in  
> place? Since the private API already seems to work, adding a public  
> wrapper around it should be very easy, shouldn't it?

Basically, this private API changed some times ago, and it's no  
longer available, the semantics has changed to support a cleaner way  
to handle environment variables. And I'm even considering making that  
even more clean by pushing environment variables setting down to  
execve, which will have the advantage of being thread safe (the old  
implementation broke with some ports and the new implementation is  
not thread safe).

In 1.4, the process was:
command generate a string in the format "VAR=value VAR2=value  
command", and this is passed to system.

In 1.4.1+, the process will be:
command_exec changes the environment and then calls the command via  
system.

And in the future, the process might be:
command_exec passes the environment and the command to system which  
calls execve with a modified environment array.

To get back to the discussion, having public APIs (described in  
portfile(7) man page) allow us to make changes to the base/ code to  
improve or fix things. If there is a need for a public APIs we don't  
have yet, it can be satisfied.

Paul