[Mono-osx] Xcode Plug-in

[Andreas Färber]

Hi,

> I've also been playing with Susan's wonderful Xcode plug-in. Ken
> didn't seem to have much luck with it on his G4 iMac, but I've only
> run in to a few problems on my 12" PB (1GHz G4, 10.4.8, Mono 1.1.18,
> Xcode 2.4).
>
> 1. Compiling the default Hello-World! app results in the following
> error:
> "[Session started at 2006-10-15 16:51:51 +0100.]
>
> Unhandled Exception: System.TypeInitializationException: An exception
> was thrown by the type initializer for System.Console --->
> System.NullReferenceException: Object reference not set to an
> instance of an object
>    at System.TermInfoDriver.Init () [0x00000]
>    at System.ConsoleDriver.Init () [0x00000]
>    at System.Console..cctor () [0x00000] --- End of inner exception
> stack trace ---
>
>    at <0x00000> <unknown method>
>    at InstallTest.InstallTest.Main () [0x00000]
>    at InstallTest.InstallTest.Main () [0x00000]
> 
> InstallTest has exited with status 1."
>
> By setting the .NET version flag to V1 in the Build tab of the Target
> Info inspector window I got the expected output:
> "[Session started at 2006-10-15 16:54:05 +0100.]
> Goodbye, Forever!
>
> InstallTest has exited with status 0."
>
> What is interesting though is that if you run the V2 compiled program
> from Terminal (or WidgetTerm) it works perfectly. After some poking
> around in the project file, plug-in code and various templates I
> can't see what's going wrong. Could it be a bug in GMCS/Mono on PPC
> or in Xcode on PPC with regards to Xcode's Pseudo Terminal?

The release notes of Mono 1.1.18 mention some bugs related to Console  
2.0 redirection were fixed. Maybe you tested this on an earlier  
release or there are some more left - could be something else though...


> Frankly I'm really impressed with the work Susan has put into this
> plug-in as it does seem to work reasonably well most of the time.
> When I get my new Macbook Pro (sometime in the next week) I'll try
> comparing Intel/PPC in the (probably vain) hope that it might
> illuminate some of the odd behaviour on PPC. I spent most of the
> summer working in Objective-C and Cocoa, though I would not claim to
> be any kind of expert, so I should be able to track down at least
> some of the bugs. Of course my doing this shouldn't stop the more
> experienced programmers out there from having a go.

I've been working towards the same goal of an Xcode plug-in, but  
using a different approach:
I've found out that you can specify an Objective-C class derived from  
PBXLSPlugin as NSPrincipalClass (where LS might or might not stand  
for launch system) and override its "+(void)pluginDidLoad:(NSBundle*) 
bundle" class method (there are no public header files for this  
class, so I've simply declared the interface with only the relevant  
method in my code before I use it). In the pluginDidLoad: method one  
can embed the Mono runtime and load or execute an assembly included  
in the bundle before all the .*spec files are read. Then in the  
managed code (e.g. Main method for executable) one can register the  
classes specified in the .*spec files, with the code being in C# (or  
whatever you prefer).
I'm happily using my managed plugin on PowerPC, and we're in the  
process of resolving the remaining obstacles for embedding to work on  
Intel as well (Robert just published a patch on Mono-list). That way  
development is not limited to those too knowledgeable about Objective- 
C and Cocoa libraries and the complete Mono library can be used, for  
example System.Text.RegularExpressions for output parsing.

I haven't tested Susan's plug-in yet, but mine is based around the  
core arguments of [g]mcs that I needed the most, allowing executable  
and library assemblies as product, multiple source files as compiler  
input and referenced libraries as linker input. I'd like to support  
multiple programming languages, so I'll be looking into using al as  
alternative linker to [g]mcs - someone on Mono-list once mentioned  
Visual Studio compiling that way - but I haven't tested what happens  
to assembly-level attributes using that approach.

Me, too, I've been unable to make executing Executables work in  
Xcode, which probably is related to all examples and unofficial docs  
being targetted at native-compiling languages - Java appears to be  
implemented using some differing way, possibly hardcoded into Xcode  
itself: The "built-in" .*spec files, that I have otherwise found very  
helpful, have not specified javac, jar etc. and for Java applications  
there's a key IsJava=YES, which is not too helpful for Mono... ;-)


As a side note for anyone interested, an alternative way for  
embedding Mono within a loadable bundle is to write a native library  
and within the library's initialization routine spawn a pthread that  
does the embedding as soon as the initialization is finished. Only  
the timing can be problematic as the regular bundle processing by its  
host's thread will continue in parallel (in the case of Xcode: .*spec  
file reading and checking for existence of the specified classes),  
but it's a nice way to look around what "secret" Objective-C classes  
and methods are around!

Andreas