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