[Mono-list] (MacOSX) Requesting porting guide clarifications

[Miguel de Icaza]

> 1. Re: The current guidelines
> Am I correct in assuming that I don't need to mess with the PPC arch
> implementation? I know this is currently underway for PPC based Linux
> distros, but I'm assuming the CLI bytecode to native code should map 1:1
> irregardless. I'm also proceeding under the assumption that porting the JIT
> is not really a concern at the moment, and that I should focus on making
> sure the interpreter works first and foremost.

Yes, this is correct.  Most of the low-level PPC work has been now
completed by Radek Doulik now.  The areas that might need work are at
the Unix porting level, and they could encompass some of these:

	* Threads, but we believe Jeff's work on Solaris should have
	  taken care of most of the portability issues.

	* Signal handling (we need information about the signal, and how
	  to modify registers after we catch a signal for example, and 
	  to unwind the stack).  This might be different in Linux than 
	  the Mac OS X. 

You might want to look at a "beginners guide" to Mono here:

	http://mono.baselabs.com

> 2. Specifying platform specific behavior in the code
> There have been a few problems that I fixed by using macros. Is that cool?
> Apple has defined "__APPLE__" in it's headers, so I've been using that to
> single out OS X platform fixes. Is this cool? Would it be more appropriate
> to define a macro specific to the Mono build to tag OS X behavior? Or, is
> this totally wrong?

This works, but we would surely like to look at what you are ifdefing
out.  Sometimes the best way to port is to "probe" for the capability,
rather than the vendor.  If you probe for the capability, you can also
simplify the life of other people porting to other systems, but most
importantly, if your vendor revisits its interface and decides to
add/remove features in the future, recompiling Mono will take advantage
of these features.

Example: Linux used to use BSD ptys, but as time passed Linux moved to
SystemV like ptys.  By probing for the libc support for this, you can
evolve with the operating system, while still supporting older versions
of the system.

> 3. License issues
> Is there anything that I need to specify in the patches (in comments or a
> separate file) for license compatibility with the main project? (LGPL/GPL?)

For the compiler and runtime engine:

    If your patch is small, there are no requirements.  If you are
    contributing a larger patch, we do require copyright assignment on
    the changes (I can mail you the copyright assignment form).  If you
    are contributing a large sub-system to Mono, we recommend that you
    keep the copyright.
    
For the class libraries:

    You only need to agree to license your code under the MIT X11
    license.
    
> My immediate goal is just to get the current build to build working
> executables, but I would like to eventually provide both: 1) a patch that
> builds a proper OS X framework, and 2) an installer to install said
> framework.

We should aim at integrating your patches into the main code base, so we
have a single source code that works on all systems.  I do not know what
the installer is that you mention, but that would be nice to have if it
makes the lives of OS X hackers easier.

Miguel