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