[Mono-osx] Xcode Plug-in
andreas.faerber at web.de
Sun Oct 15 15:34:18 EDT 2006
> 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
> "[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!
More information about the Mono-osx