[31500] trunk/base/src/port

[Randall Wood]

On 26 Nov 2007, at 09:54, James Berry wrote:

> Hi Randall,
>
> On Nov 26, 2007, at 1:40 AM, Randall Wood wrote:
>
>> Is there a good reason not to do this in the MacPorts API?
>
> I'm happy to have any thoughts on the approach. I tend to think  
> this is in the "API" layer, since it's implemented as a target. So  
> in other words, it's on parr with clean, lint, trace, activate, etc.

If its a target implemented by calling "mportexec foo [un]load" then  
I'm happy. I guess I'm not as familiar with the code as I thought I  
was, but I don't see where or how something using the MacPorts API  
(base/src/macports1.0) gets the port API.

> But I'm clearly missing the intent behind your words. How do you  
> think it should be implemented, and why?

Looking at the MacPorts API, I just don't see where the port API  
comes into play. I guess I'm just confused.

> James
>
>
>>
>>
>> On 26 Nov 2007, at 00:47, jberry at macports.org wrote:
>>
>>> Revision 31500 Author jberry at macports.org Date 2007-11-25  
>>> 21:47:26 -0800 (Sun, 25 Nov 2007) Log Message Initial support for  
>>> port load and port unload actions. These actions call invoke  
>>> launchctl to load or unload the startupitem.plist for the  
>>> specified port(s). Modified Paths
>>> trunk/base/src/port/port.tcl
>>> trunk/base/src/port1.0/Makefile
>>> trunk/base/src/port1.0/port.tcl
>>> trunk/base/src/port1.0/portdestroot.tcl
>>> trunk/base/src/port1.0/portstartupitem.tcl
>>> Added Paths
>>> trunk/base/src/port1.0/portload.tcl
>>> trunk/base/src/port1.0/portunload.tcl
>>>
>



Randall Wood
rhwood at mac.com
http://shyramblings.blogspot.com

"The rules are simple: The ball is round. The game lasts 90 minutes.  
All the
rest is just philosophy."