Cobra Forums

I'm thinking that we are probably not going to put much effort into supporting codegen for .Net versions prior to Net 4.0 now, yes?

i.e if we want to target a .Net2.0 system say using the Net2.0 compiler, we would have to revert cobra -> C# codegen to use only those constructs supported by .Net 2.0 rather than the newer .Net4.0 ones.

Would this indicate suppressing/removing the cobra compile option -native-compiler ( for CLR at least) ?

Unless someone speaks up that pre-4.0 .NET is important, I don't see the point of supporting it.

No, we would not get rid of -native-compiler:foo for a couple reasons:

(1) It's a general purpose tool that lets you control which C# compiler Cobra will invoke.

(2) It's how we boosted Cobra from CLR 2 to CLR 4 and it could/will be used for that purpose again in the future (CLR5, etc.)

(3) iOS/iPhone development requires it:

Code: Select all

-native-compiler:/Developer/MonoTouch/usr/bin/smcs


from "iPhone"

Is there a reason you ask?

OK needed for
- later Frameworks
- platform variants

But what of native-compiler pointing backwards?

i.e. (Assuming have revved cobra to use (codegen) to some Net4.0 features)
What do you anticipate happening when you do this?

Code: Select all

-native-compiler:/WINDOWS/Microsoft.NET/Framework/v2.0/csc.exe


i.e downrev to an earlier Framework/compiler that doesnt handle .Net4.0 constructs (or libs).
Just let it run and (maybe/probably) fail C# compilation (depending on exactly what constructs your cobra code used)
or detect down Frameworking compiler and suppress it


Theres another complication I'm just getting a handle on (looking at ticket:330)
Net4.0 needs ref an additional dll (System.Core) that earlier revs did not (supports additional Net4.0 stuff like HashSet<of T>)
(csc 4.0 detects use of classes from this dll (or just the use of Net4.0 framework) and auto adds a ref to it - presumably? Cobra currently does not so we get weird unexpected errors).
Its a little onerous to expect a developer to know/work out they need specify an extra ref explicitly when using (some) Net4.0 specific classes so cobra should do-the-right-thing
If we make cobra always add this ref itself (presuming Net4.0 or greater) designating an earlier compiler version/framework will fail when the
dll is looked for...
(Its a different variant of the above issue)..

I asked about earlier Framework support to determine whether could ignore it and just always include use of extra dll ( in which case also probably need some suppression on -native-compiler to (at min) preclude back pointing) or continue to provide alternative codegen for supporting earlier frameworks (if so why use new Net4.0 facilities at all?) and be a lot more active about detecting Net4.0 or later use or do something else YTBD.

I'm in favor of the 'no-earlier-framework rev' position but it requires more choking down on -native-compiler (at least)
perhaps minimally try and detect back pointing compilers and emit a compiler warning (??)

OTOH maybe its acceptable to just do the compile and have the resulting .exe throw a BadImageFormatException
(either due mismatched compiler and .Net runtime (clr-profile) or mismatched .exe and Cobra runtime (4.0 built).

With fix for ticket:330 cant build with embedded cobra runtime (-ert) to anything prior to 4.0 it since uses HashSet<of T>.

-native-compiler is an advanced feature that most Cobra devs will never even use. And when they do, it will be for specific situations like iOS. I don't think we need to add any error checking to it. We can always add it later if we see that's a problem.

Re: System.Core.dll, Cobra already auto-refs mscorlib.dll and System.dll. I see no reason why System.Core.dll shouldn't be added as part of bumping the min requirement of Cobra to CLR 4.

Me neither - see patch on ticket:330

FWIW I'm really liking the optional and named parameter capability in cobra....
simplifies/removes overloads massively.
ticket:325 and ticket:326

Patch on 325 applied. This is a nice feature. Thanks.

I think I've almost got the named parameter capability sorted.
I just need to generate a few more tests - named parameters alone and in conjunction with optional params
Easier now that optional param code is in the source tree.
Thx.