[Mono-devel-list] Native code in mcs & Mono.Posix

[Miguel de Icaza]

Hello,

> I have discovered there is now more native code in the mcs directory
> structure - in particular in Mono.Posix. This causes me problems because I
> use different platforms and different compilers (not gcc) and the make files
> aren't configurable enough to cope (at least at the moment). Given that mono
> & configure is already setup to cope with all this platform dependency I am
> wondering why this code is in mcs and not mono? Should it be moved? And
> indeed should some of the Mono.Posix stuff really be InternalCall? Or does
> this mean the makefiles need fixing to cope? (Note I have not looked at the
> mbuild stuff recently discussed but I'm currently concerned about building
> right now).

Mono.Posix is not very important, it has a few helper routines here and
there, and I just tried to update it to actually have the kind of things
we had talked about supporting there.

So you can safely ignore this library if it is causing problems for now.

The reason for the code to live in mcs, is that the C code that is
compiled needs to know about the values defined in the C# world.  So the
solution is to use a C# program with attributes, and from this we
generate the C code that gets compiled.

There are a couple of options to fix this, some more gross than others:

	* Move the Mono.Posix assembly code into mono.

	  This would mean that the mono/ compilation process would need
	  a working C# compiler, which is not a problem, since we ship
	  binaries on it already in the mono/runtime directory.

	  That way we could use libtool.

	* Keep the code in mcs, but generate the map.c and map.h files
	  into $(topdir)/../mono/monoposix/ directory.

	  This would add a crossed dependency between the two modules.
	  To make our life simpler, we could check in the generated
	  files into CVS, so the only person that has this issue is the
	  maintainer of the code.

	* Remove the support for the shared library until we find a
	  reasonable thing to do.

	* Move the new C runtime code into a new module, "c-helpers",
	  and put the Cairo and Posix stuff there.

These are all quite ugly solutions, I tried to have something
kind-of-clean, but I did not have in mind those doing cross-compilation
when I did it.

A longer term option *might be* to use Peter's build software.

Miguel