Build CoreCLR support on Unix

[KevinRansom]

It would be very useful if it was possible to build at least the non-vs specific portions of Visual FSharp Tools for CoreCLR and/or Mono on Linux and Mac.

[brodyberg]

+1

Definitely important and very likely low-hanging fruit for an interested Unix user.

[enricosada]

build with xbuild on mono is easy but useless

we should align visualfsharp with the open fsharp repo ( see #262 ) the linux/mac build work and is maintained by community. Not add another different build system pls

roadmap to cross plat mean choose:

• a test runner, nunit?
• a build script
  • windows = bat + linux makefile is ok
  • fake (make invoke fake) is better
• an orchestrator ( like fake? ) to run task, like run tests, etc

but the same, not two different implementation in each repo

there are some small differences like:

• directory lkg vs lib
• directory .nuget vs FSharp.Core.Nuget.nuget
• etc, see Align openfsharp and visualfsharp #262

we can add conditional, but is worth it? easier to choose a name and modify visualfsharp or openfsharp

just diff the two repo (now is easier, i removed white space noise ) and summarized the difference in #262
some are features, like fsc --gccerrors , can be merged later

i can help, but need visualfsharp team and openfsharp ( @dsyme ? ) to discuss about it and choose, i dont want to waste time

[forki]

there is also discussion about alignment with FCS in #334 which already uses FAKE.

[latkin]

The Open Edition repo has a stable build/test/package story for mono already. It's not clear to me why we need to duplicate that here? Microsoft/Visual F# is not investing long-term in mono as the .NET xplat story.

CoreCLR/.NET Core is the future for .NET xplat, and the future of F# xplat at least as sponsored by Microsoft. I think that's where this repo should start moving. So yes, *nix build is pure win, but on coreclr (mono is already covered well by open edition).

[KevinRansom]

@enricosada I have a few questions about your response.

1. what do you mean "useless"? Does it not work? Do the built binaries not work?
2. As it current stands there is no way to ensure that submissions to visualfsharp tools will not break the mono version of the compiler. With a mono build and test suite we can set up a mono based ci to ensure that contributions to the visual fsharp tools compiler work on mono. Do you really believe that has no value?

[enricosada]

There is already a working supported mono version.
We need only to align the two repo (first the xplat stuff, the new features can wait).
Add makefile and xbuild target is useless if compile but not work, a false positive. The problem is not a compile time, is at runtime

1. mono/xbuild api is ok, so build is usually not a problem (minor thins like SymWrapper, xbuild workaround, etc).

At runtime mono has some differences:

• implementation, like string ordinal ( like this fix on test suite )
• not supported or bugs ( see the if runningOnMono )
• xplat (dir separator, permission, etc)

You can check if a build is ready only with test ( for that i tried to add #90 to make the test suite run xplat, next is fsharpqa ) and manual testing. linux vs macosx is another issue.

1. i think xplat is usefull, ci too ( i added travis to openfsharp repo ).
   But work on mono is openfsharp repo. This mean:
2. build ( mono version )
3. run ( test suite e manual test )
4. packaging ( fsc need the find the right bcl )
5. people who use it, find regression (fsharp bug, mono regression) and fix it.

I am actively trying to align repo, when done the build is free, and visualfsharp can merge back fix for openfsharp repo.

For .net core ihmo is a good idea is to start now with openfsharp repo, so all xplat stuff is ready (test suite, build, etc). Btw news on .net core support?

[cartermp]

Closing in favor of #2854 as it is far more comprehensive.