You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucenenet.apache.org by Eric Nicholson <en...@gmail.com> on 2009/10/13 17:24:19 UTC
CLS Compliance and Compiler Warnings
I apologize if this has been asked already, but is there any effort underway
or interest in getting Lucene.NET to compile as a CLS-Compliant assembly?
What about reducing or eliminating the compiler warnings? I know both of
these would make my build environment a little saner. Looking at the code
it looks like there is not much involved in getting it to compile clean. I
noticed a few things in particular:
* unused variables - warning
* protected internal fields with different case than a public property or
class - non-cls compliant
* public consts that start with underscore - non-cls compliant
Is there some reason the code needs to stay exactly the way it is (like
maintaining parity with the Java project)? It seems like a pretty small
amount of work, I'd be happy to submit a patch if anyone thinks it would be
helpful.
Best Regards,
Eric Nicholson
Re: CLS Compliance and Compiler Warnings
Posted by Eric Nicholson <en...@gmail.com>.
Sounds totally reasonable. Thanks George!
On Wed, Oct 14, 2009 at 9:17 PM, George Aroush <ge...@aroush.net> wrote:
> We can clean those up, once we archive a port status such that we can port
> patches over vs. a whole release. This is because a whole release port
> depends heavily on deltas between releases. Thus, any extra code changes
> will make a whole port harder.
>
> -- George
>
> -----Original Message-----
> From: Eric Nicholson [mailto:enicholson@gmail.com]
> Sent: Tuesday, October 13, 2009 11:24 AM
> To: lucene-net-dev@incubator.apache.org
> Subject: CLS Compliance and Compiler Warnings
>
> I apologize if this has been asked already, but is there any effort
> underway
> or interest in getting Lucene.NET to compile as a CLS-Compliant assembly?
> What about reducing or eliminating the compiler warnings? I know both of
> these would make my build environment a little saner. Looking at the code
> it looks like there is not much involved in getting it to compile clean. I
> noticed a few things in particular:
>
> * unused variables - warning
> * protected internal fields with different case than a public property or
> class - non-cls compliant
> * public consts that start with underscore - non-cls compliant
>
> Is there some reason the code needs to stay exactly the way it is (like
> maintaining parity with the Java project)? It seems like a pretty small
> amount of work, I'd be happy to submit a patch if anyone thinks it would be
> helpful.
>
> Best Regards,
> Eric Nicholson
>
>
RE: CLS Compliance and Compiler Warnings
Posted by George Aroush <ge...@aroush.net>.
We can clean those up, once we archive a port status such that we can port
patches over vs. a whole release. This is because a whole release port
depends heavily on deltas between releases. Thus, any extra code changes
will make a whole port harder.
-- George
-----Original Message-----
From: Eric Nicholson [mailto:enicholson@gmail.com]
Sent: Tuesday, October 13, 2009 11:24 AM
To: lucene-net-dev@incubator.apache.org
Subject: CLS Compliance and Compiler Warnings
I apologize if this has been asked already, but is there any effort underway
or interest in getting Lucene.NET to compile as a CLS-Compliant assembly?
What about reducing or eliminating the compiler warnings? I know both of
these would make my build environment a little saner. Looking at the code
it looks like there is not much involved in getting it to compile clean. I
noticed a few things in particular:
* unused variables - warning
* protected internal fields with different case than a public property or
class - non-cls compliant
* public consts that start with underscore - non-cls compliant
Is there some reason the code needs to stay exactly the way it is (like
maintaining parity with the Java project)? It seems like a pretty small
amount of work, I'd be happy to submit a patch if anyone thinks it would be
helpful.
Best Regards,
Eric Nicholson