Re: [swarm-hackers] Old autoconf build process is broken in current trunk

[Scott Christley]

On Nov 24, 2009, at 9:38 PM, Bill Northcott wrote:

> On 25/11/2009, at 4:07 PM, Scott Christley wrote:
> > On Nov 24, 2009, at 9:00 PM, Bill Northcott wrote:
> >
> > > Does the openstep option alter the runtime or just the GUI?
> >
> > It should just alter the GUI, on Linux the openstep option uses  
> > gnustep and that uses the GNU objc runtime.
>
> Just a thought, but I believe MacOS gnustep uses the Apple runtime,  
> but doubt anyone uses it.

Well not gnustep exactly, but some of the down stream dev and user  
libraries which are part of gnustep, can be compiled against Cocoa,  
essentially they are like any other openstep compatible program.



> > > It seems to me that the runtime should be chosen automagically  
> > > onthe basis of the host.
> > Yeah, except I didn't want to trump your Mac work, which as I  
> > understand uses the GNU runtime right now.
>
> Don't mind me.  The GNU runtime is busted on the Mac because of lack  
> of compiler support.  Clang-LLVM won't support it, Apple gcc had the  
> code stripped out some while back and the FSF gcc does not support - 
> arch and other Apple stuff.  Even the Apple/FSF hybrid cobbled up by  
> Simon Urbanek barfs on nested functions.  I would be very happy to  
> see the modified Swarm runtime put out of its misery.

I suppose the question is how useful is using the tcl/tk GUI on Mac.   
I guess it offers the ability for old Swarm apps to run on Mac.


> > > Does the current code always use the host/gcc runtime. Can we  
> > > ditch the old Swarm modified runtime?
> >
> > Actually tcl/tk on Linux uses the Swarm modified runtime.  The  
> > reason for this is to access the "mframe" stuff.  This is needed  
> > for openstep because it has its own mframe code.
>
> Expletive deleted.  I thought we had murdered mframe.  Can we not  
> use use blocks to replace that functionality?

No, mframe is different from blocks, blocks are more like nested  
functions as I understand them.


> I could never quite see where mframe got used.  My old MacOS build  
> using libffi did not need it for call forwarding, and it seems to me  
> that both Apple and GNU runtimes do call forwarding without needing  
> it.  Marcus was always muttering stuff about if being needed for  
> Java, but I never got my head around this.
>
> How does it come into Tcl/Tk?  I thought we were using a C API for  
> this, which would mean no foreign function calls.

It is not used by tcl/tk per se.  FCall.m references it.  It is  
related to Java and right now the openstep versions of Swarm don't use  
Java, so the issue hasn't come up.  With openstep, we can just use  
NSInvocation in its place (and in reality NSInvocation has something  
like mframe inside of it).  It is needed whenever you want to make a  
dynamic method invocation, i.e. where you don't know the target,  
method, and/or argument types until runtime.

Scott