[Mono-dev] mini-OS patches.
cr88192 at hotmail.com
Thu Jan 29 15:12:21 EST 2009
----- Original Message -----
From: "Paolo Molaro" <lupus at ximian.com>
To: <mono-devel-list at lists.ximian.com>
Sent: Friday, January 30, 2009 3:34 AM
Subject: Re: [Mono-dev] mini-OS patches.
> On 01/28/09 Miguel de Icaza wrote:
>> The current patch splits out the OS-specific functionality into
>> three files mini-darwin.c, mini-posix.c and mini-windows.c, these mostly
>> deal with setting up exceptions today.
> This looks fine to me. I wouldn't bother with the configure changes,
> though and just always add all the files to the build and protect the
> contents with the appropriate #ifdef.
> When committing, this should likely be done with a svn copy, so that the
> history of the changes is mostly preserved.
yeah, this seems like a good idea (saves some on needing to take into
account platform specific files, let the preprocessor deal with it...).
an example of similar was in some places in my project (particularly the
"BGBDY" library, which deals with the core of the typesystem, object system,
..) many places are wrapped with #ifdef's so that the library can be built
without necessarily depending on my assembler (although, removing the
assembler removes a fair amount of functionality as well, such as preventing
autogenerating wrapper thunks and stubs for native calls, ...).
but, alas, I am given a slight worry, as my assembler uses NASM-style
syntax, and I am left wondering if to be more proper it would also need to
support GAS-style syntax, but in the past I have not much liked GAS syntax
(ugly, ...), but it is what is produced by GCC, ... oh well, there are more
mostly I think the issue would be one of a different parser and an
opcode-rename table (most of the internals should not care too much, since
the parser was originally a textual wrapper for a procedurally-driven
assembler anyways...). I just liked the textual approach much more (much
less bulky to produce, nice puts or printf-like interface, ...).
> lupus at debian.org debian/rules
> lupus at ximian.com Monkeys do it better
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
More information about the Mono-devel-list