Thanks,
It's okay, I'll just create another lgpl library subclassing NSTask  and link 
to it.
Banlu

----- Original message -----
> 
> On 7 Mar 2011, at 16:04, Banlu Kemiyatorn wrote:
> 
> > On Mon, Mar 7, 2011 at 10:42 PM, Richard Frith-Macdonald
> > <rich...@tiptree.demon.co.uk> wrote:
> > > Depending on what you are trying to do, you might redirect other
> > > decriptors to one of those, or you might try using named pipes to
> > > communicate between processes.
> > 
> > I want to write to any predefined descriptor on target process and
> > think it would be nice if some extension GNUstep APIs allows this.
> > Could it fork and dup the child pipes to predefined descriptor number?
> > What would be a proper extension APIs for this?
> 
> I don't like to be negative about things when people want to contribute
> code but the GNUstep policy is strongly to be Apple compatible ...
> 
> For the core libraries themselves, that means we are actively (if
> slowly) trying to remove old extension code.   In gnustep-base that
> generally means moving extensions out of base itsself and into the base
> additions library.   So the obvious thing to do would be to implement any
> extension as something in the base additions library ... but the point
> of that library is to be built under OSX with the Apple
> compiler/runtime/Foundation, and enable code running on OSX to make use
> of our additions.   That means that code in the base additions library
> needs to work both when built with gnustep-base on *any* platform, and
> when built with Apple Foundation.   So an extension to NSTask there would
> also need to function as an extension to Apple's NSTask class ... which
> may be really difficult.
> 
> In practice, this might mean moving almost the whole NSTask
> implementation into the additions library so that with OSX Foundation,
> you would actually replace Apple's implementation of NSTask with the
> GNUstep one. This would be a good thing (we already have an NSTask
> extension we need to get out of the base library), but may be more work
> than you want to get involved in.
> 
> 

_______________________________________________
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Reply via email to