gmcs version #define

View: New views
3 Messages — Rating Filter:   Alert me  

gmcs version #define

by Stephen A. :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

According to the documentation, gmcs #defines the __MonoCS__ constant
when compiling C# code. However, it doesn't seem to provide a constant
that identifies the compiler version.

My use case: I have added a workaround to avoid some code which causes
gmcs 2.0-2.4 to choke. Since this specific issue has been reported as
fixed in the 2.6 branch, I would like to disable the workaround for
newer versions of the compiler.

Unless I have missed something obvious, this doesn't seem to be possible
right now, at least not in an automated fashion.

Does this sound like a reasonable feature? Would it be possible to add a
constant like "#define __MonoVersion__ 260" in some future version?
(where 260 is gmcs 2.6.0, 281 is gmcs 2.8.1, etc)

_______________________________________________
Mono-devel-list mailing list
Mono-devel-list@...
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: gmcs version #define

by Jonathan Pryor :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

On Wed, 2009-11-11 at 17:22 +0200, Stefanos A. wrote:
> According to the documentation, gmcs #defines the __MonoCS__ constant
> when compiling C# code. However, it doesn't seem to provide a constant
> that identifies the compiler version.
...
> Does this sound like a reasonable feature? Would it be possible to add a
> constant like "#define __MonoVersion__ 260" in some future version?
> (where 260 is gmcs 2.6.0, 281 is gmcs 2.8.1, etc)

The problem here is that C# #defines can't have values, so you can't do
`#define __MonoVersion__ 260`.  Instead, you would need to have a
"family" of #defines with the version encoded in the name, e.g.
__MonoCS_200__, __MonoCS_220__, __MonoCS_240__, etc., and I'm not sure
that would be very useful (as you couldn't have `#if __MonoCS__ > 260`
blocks, but instead `#if __MonoCS_260__ && !__MonoCS_240__` or
something, which relies on answering this: should gmcs 2.6 define *both*
__MonoCS_260__ AND __MonoCS_240__, or just __MonoCS_260__?).

My gut feeling is that this can't actually be solved easily within C#
source; you'd instead need to move the logic into e.g. make(1), and use
`#if BNC_XXXXXX` [0] in your source, and in your Makefile add
-d:BNC_XXXXXX if `mcs --version` is a known bad version.

 - Jon

[0] Why BNC_XXXXXX?  Bugzilla.Novell.Com with XXXXXX as the bugzilla ID
number.  Replace BNC with the appropriate bugzilla abbreviation, as
appropriate.  Great fun, and lets you know when you can stop using the
#define. :-)


_______________________________________________
Mono-devel-list mailing list
Mono-devel-list@...
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: gmcs version #define

by Stephen A. :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Στις 11-11-2009, ημέρα Τετ, και ώρα 11:22 -0500, ο/η Jonathan Pryor
έγραψε:

> On Wed, 2009-11-11 at 17:22 +0200, Stefanos A. wrote:
> > According to the documentation, gmcs #defines the __MonoCS__ constant
> > when compiling C# code. However, it doesn't seem to provide a constant
> > that identifies the compiler version.
> ...
> > Does this sound like a reasonable feature? Would it be possible to add a
> > constant like "#define __MonoVersion__ 260" in some future version?
> > (where 260 is gmcs 2.6.0, 281 is gmcs 2.8.1, etc)
>
> The problem here is that C# #defines can't have values, so you can't do
> `#define __MonoVersion__ 260`.  Instead, you would need to have a
> "family" of #defines with the version encoded in the name, e.g.
> __MonoCS_200__, __MonoCS_220__, __MonoCS_240__, etc., and I'm not sure
> that would be very useful (as you couldn't have `#if __MonoCS__ > 260`
> blocks, but instead `#if __MonoCS_260__ && !__MonoCS_240__` or
> something, which relies on answering this: should gmcs 2.6 define *both*
> __MonoCS_260__ AND __MonoCS_240__, or just __MonoCS_260__?).

I admit didn't know that C# #defines can't have values. I'm rather
surprised but  I guess should have checked the C# specs first.

In this case, introducing version defines will likely cause more trouble
than it's worth.

> My gut feeling is that this can't actually be solved easily within C#
> source; you'd instead need to move the logic into e.g. make(1), and use
> `#if BNC_XXXXXX` [0] in your source, and in your Makefile add
> -d:BNC_XXXXXX if `mcs --version` is a known bad version.

Makes sense. I'll try to work out the details for the current
msbuild/xbuild build environment (the main sticking point is keeping the
solution cross-platform).

Thanks!

>
>  - Jon
>
> [0] Why BNC_XXXXXX?  Bugzilla.Novell.Com with XXXXXX as the bugzilla ID
> number.  Replace BNC with the appropriate bugzilla abbreviation, as
> appropriate.  Great fun, and lets you know when you can stop using the
> #define. :-)
>
>


_______________________________________________
Mono-devel-list mailing list
Mono-devel-list@...
http://lists.ximian.com/mailman/listinfo/mono-devel-list