[Mono-dev] mini-OS patches.

BGB 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.
> Thanks!

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 
pressing issues...

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
> -- 
> -----------------------------------------------------------------
> 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
> http://lists.ximian.com/mailman/listinfo/mono-devel-list

More information about the Mono-devel-list mailing list