[Mono-devel-list] Native code in mcs & Mono.Posix
lupus at ximian.com
Thu Jan 8 09:20:52 EST 2004
On 01/07/04 Miguel de Icaza wrote:
> 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.
I think the cairo helper lib should go in it's own separate cvs module
with a propor autotools setup: we could add it inside the mono
module as well, but only if the cairo source is added as well (we
don't need to inflict the cairo API instabilities on everyone).
Note that this can be done with a cvs virtual module as well.
The posix stuff is different, IMHO: I don't see the need to use
a library to export a few constants and a couple of simple macros.
It would be much better both performance-wise and complexity-wise to
redo that stuff in managed code (the managed code can be generated with
a C program, of course). I would also not do the constant remapping of
the values: exposing the constants as properties or readonly static
variables is a better way to do it, but that's a separate issue.
So, for Mono.Posix the helper shared lib should be dropped completely.
lupus at debian.org debian/rules
lupus at ximian.com Monkeys do it better
More information about the Mono-devel-list