Re: [DotGNU]implementing non ECMA features into pnetlib

[David Sugar]

Ah, so you meant ECMA_COMPAT as a "strict" define.  Hmm...you are correct, 
there is no easy way to have multiple build options, and each option does 
have some uglyness and difficulty to maintain.  However, there would be great 
value for potential embedded developers missing from other implementations if 
we can strip the library down in well defined ways.

On Saturday 27 July 2002 05:52 pm, Rhys Weatherley wrote:
> David Sugar wrote:
> > However, offering my own opinion, I am not sure I like the #ifdef
> > ECMA_COMPAT, as that should, after all, be the default :).  Or maybe I
> > misunderstood what you meant there...
>
> #if ECMA_COMPAT basically turns off all of the .NET
> Framework features.  This isn't as simple as deleting
> classes, as there are many classes in ECMA that have
> more methods in the .NET Framework, or which depend
> upon .NET Framework classes indirectly.
>
> It would be nice to have separate directories for
> "ECMA bits here and .NET extensions there".  It just
> isn't possible.
>
> Having said that, the #if ECMA_COMPAT is becoming a bit
> of a pain to manage, and makes it difficult to slice
> the library along other lines.  e.g. building a library
> with a particular stripped-down feature set.
>
> I'm still scratching my head on library slicing a bit.
> There are two options that I can see:
>
> 1. Add more #if's to the code for REFLECTION, REMOTING,
>    EXTENDED_NUMERICS, etc.  The result is likely to
>    degenerate towards spaghetti.
> 2. Come up with an attribute tagging system, where
>    classes and methods are tagged with the feature name.
>    Then the linker can be made to exclude classes and
>    methods that don't have the required tags.
>
> Both of these are annoying to implement and keep up to
> date.  Any other suggestions?
>
> Cheers,
>
> Rhys.