How to help with building F# for the CoreCLR

[KevinRansom]

Okay now that we have a branch that builds the coreclr version of F# I think it is time that the load can be shared. @ctaggart @rojepp have both made a great start. It's probably going to be more useful if we agree what needs to be done and then work on each item to completion.

These are the most immediate items on our agenda. That means they are the items we believe need to be completed successfully for us to get to the end point which is an OSS project that builds a platform independent F# compiler and REPL that runs on Windows/Mac and Linux.

This list is nowhere near complete feel free to open issues with suggestions about what needs to be done, and in what order. I guess we will manage it, in a similar way to how we managed the F# 4.0 work. It should be noted that PR's not related to this work are still very welcome and will be gratefully received.

Status Page: https://github.com/Microsoft/visualfsharp/wiki/F%23-for-CoreCLR---Status

About Tooling:

We aim to conforms to the latest development tools standards of the DotNet Foundation OSS projects. (Please note: that F# is associated with the F# Foundation http://www.fsharp.org and not the .NET Foundation).
In general we prefer solutions based on the tools selected by the Roslyn, NetFX and CoreCLR teams. The benefit of aligning with those teams, is that we can leverage their team resources, staff, contributors and learnings. It is our preference that where the .NetCore, .NetFX and Roslyn team have picked a tool, we don't use an alternate tool that does a similar Job.

About DNX:

DNX is a packaging of the CoreCLR. When Roslyn Compiler ships it too will be a packaging of the CoreCLR as will the F# Compiler. At any one moment in time, we may all ship with different versions of the CoreCLR and the various managed assemblies that comprise it. We will not bind the F# compiler to a particular packaging, we will pick which versions of all of the dependencies that we use. If we download specific versions of DNX or Roslyn it will be a point in time fix to a specific need.

In order to ensure that the F# compiler is compatible with a specific build of DNX we need to have some test cases that verify that the F# compiler does the right thing W.R.T. DNX.

Things to do:

1. Add Unix testing to CI (currently App Veyor)
   • Note: Roslyn and NetFX and CoreCLR use Jenkins, the advantage to us of this is we have a lab of MACS wired up for Jenkins testing.
   • However, the F# community uses other tools, in this case we would consider a non-jenkins alternative.
2. Add FSLEX and FS YACC to OSS build, make them build.
   • port FSLEx and FSYacc to CoreCLR
3. Make a project to build a Nuget package for the current LKG.
   • update the build to use the LKG from Nuget.
4. Make a project to build a Nuget v3.0 FSharp.Core package, for all profiles that we currently support including coreclr.
5. Update the OSS build to use project.json to express FSharp.core project dependencies for all flavours of fsharp.core that we currently build.
6. Port the OSS build to use the CoreClr version of MSBUILD.
7. Merge master changes into update coreclr branch.
8. Port the Nunit tests to XUnit 2.0. (XUnit is what Roslyn and .NetCore use).
9. Make a Nuget LKG package based on the CoreCLR compiler.
10. Make Visual Studio and Xamarin F# templates use Nuget version of FSharp.Core.
11. Make a Nuget package for the coreclr version of the fsharp compiler.
    • Supports 64 bit Windows/Linux/MAC.
    • Supports 32 bit Windows/Linux/MAC.
12. Make Visual Studio templates and a VSIX that build using the coreclr.
13. Clean up Cambridge (fsharp) test suite, identify cross-platform issues (if any).
    • Refactor cross-platform issues out of suite, design a platform specific test strategy.
    • Port Cambridge suite test cases to XUnit 2.0.
14. Clean up QA suite (fsharpqa), identify cross-platform issues (if any).
    • Refactor cross-platform issues out of suite, design a platform specific test strategy.
    • Port QA suite test cases to XUnit 2.0.
15. Add Support for Cross-Platform portable PDBs.
16. Design a compiler/assembly resolution interface. Current compiler/FSI have a blended resolution strategy.
    • Implement a file system resolver
    • Implement a nuget resolver
17. Add back to the Compiler support for managed resources / Native Resources
18. Enable FSI on CoreCLR
19. Design TypeProvider interface to support compiler reified types. Makes it easier for TP authors to reason about what types are available to the generated code.
20. Design implement a lighter ref-emit replacement for generative TP's
21. Debian packaging for compiler / FSI deployment
22. DNX F# test cases, create a set of test cases to ensure that the F# compiler can generate DNX compatible apps.
    This is just a start at the list, I'm sure there are many thousands of items I left off, feel free to start issues discussing the omissions.

There will be a status page where the list of items and status of them will be kept up to date and progress is recorded similar to how we did F# 4.0.

* Status: https://github.com/Microsoft/visualfsharp/wiki/F%23-for-CoreCLR---Status*

Thanks

Kevin

[Alxandr]

I feel I should comment here, because it seems to me that there are some misunderstandings about what DNX is/how it works. Either that, or I'm completely reading some of your post wrong, which is entirely possible.

DNX is a packaging of the CoreCLR

This is simply not true. DNX has nothing to do with the CoreCLR. The CoreCLR is simply a possible target for DNX apps, much like the CoreCLR will eventually be a possible target for F# apps.

DNX F# test cases, create a set of test cases to ensure that the F# compiler can generate DNX compatible apps.

DNX (like any .NET app) runs on a CLR. Depending on what CLR you are currently using, it can load different assemblies. The 3 supported CLRs that DNX can run on is the Microsoft .NET CLR (the full CLR), Mono and CoreCLR. If you're running on the full CLR, any assembly that it can load, can be used in your DNX app (meaning basically anything that's ever written in F# that doesn't target Xamarin mobile). Also, F# already works just fine with DNX (https://github.com/fsprojects/fsharp-dnx), as long as you're running on either Mono or the full CLR. I'm not saying there isn't work to be done here (in memory compilation support for once), but some of these points are confusing, and some of them I'm either reading wrong, or they are just plain wrong.

[KevinRansom]

Excellent, thanks for the clarification.

[enricosada]

@KevinRansom i can help with 13 and 14 ( Cambridge (fsharp) and QA suite (fsharpqa) test suite ).

Your points:

• identify cross-platform issues (if any)
• Refactor cross-platform issues out of suite, design a platform specific test strategy.

We tried before to identify a common test strategy, is lot of work and we need to change both test and test runner. Is a big step, let's improve incrementally.

I think we can:

1. convert perl/bat runners to nunit/xunit runner (with nunit is ready in an old pr)
2. no need to change tests, continue to run fsc/fsi as external process, is easier and continue to work the multiple combinations of test suites

Let's use #90 , upgrate to nunit 3.0, add coreclr and fix xplat. That's easier because all process like csc.exe are started by a function, so only one point for fix xplat issues.

After this first step (fsharp+fsharpqa working without changing test code), we can convert each test as unit/integration test, because is easier to see what combination are run and what the test does (bat files and perl runner is complex)

[isaacabraham]

I can only add my +1 to moving from perl/bat to nunit/xunit - it's currently a blocker to getting more contributors to the platform. I know that @latkin has suggested that there is a lot more to be done than just this, but I feel that just moving over to e.g. nunit - even though the tests in the fullness of time might end up being rewritten - would be a really good first step.

[enricosada]

@KevinRansom instead of a wiki page, can you add a milestone coreclr with the issues? is easier to track the status than a readonly wiki ( the wiki is really bad because because we cannot update it or help, is not public ). Less work for you, easier to track

a question, with OSS build you mean visualfsharp repo?

[enricosada]

last two stuff, rly, sorry

Can we have a chat with the ms team and all the contributors who want help? is easier to boostrap, discuss and choose a single strategy /cc @NumberByColors @KevinRansom ( sigh @latkin we miss you ).

Some todo (for example 1 ci, 3 nuget for lkg, 4, 5 fsharp.core nuget, 11, 21) is already done in openfsharp repo, it's easier to leverage work already done there.
Also easier to get contribution from community, maybe that mean to coordinate a bit, but you get lot of work done for free.

it would be really sad to see two different FSharp.Core nuget package, created with two different build script etc.

With coreclr you need to cleanup your internal build server anyway, so let's improve the infrastructure (build/test) this time.

[KevinRansom]

@enricosada Okay I re-opened #90. If there is any additional work you want to do on it, feel free to. Let me know when you believe it's in a good shape to pull.

Can we get more eyes on this PR, since it's a big one, I will probably not get a chance to look at it in detail until the weekend.

I am conflicted about whether to do this in master, coreclr or it's own branch. Please make a proposal.

[Alxandr]

FYI; last I checked, xunit supports CoreCLR (dnxcore), NUnit did not (might have changed since though). At least, the DNX team uses XUnit to test DNX and the new ASP.NET 5 libs.

[forki]

@Alxandr discussion about that is in #690

[KevinRansom]

@enricosada we will try to organize a stand-up skype call It will be at 10:00 am some morning of the week probably Monday. 10:00 am because it's really hard for me to get up earlier, and the Europeans which constitutes many of the community are still awake.

It won't be next week, because of the MVP summit. If it works out we can try to do it regularly.

Kevin

[Alxandr]

@KevinRansom If you want someone who have a good amount of experience with DNX and F# integration with it I'm generally available. Just FYI. However, wrt what needs to be done to get F# working on the CoreCLR I'm afraid I won't be too much of help.

[enricosada]

@KevinRansom awesome, really thx.
10 am in redmon timezone ( 17:00 GMT ) right? that's ok for me, maybe a bit later is ok too (for me at least, dunno if people is ok in europe timezone with evening vs work hours).

@Alxandr dnx is a good part of the coreclr experience, thx for your work!

[forki]

I just took a brief look into the coreclr branch. I wonder how things are planned in regards of the project.lock.json files. It seems in the coreclr branch these files are commited.
This probably ensures that versions get locked down and everyone is building the same thing. Unfortunately the files are really really big. The one in the tests\fsharp folder is 6820 lines. And the will be a hotspot for merge conflicts if people start to upgrade packages.
Maybe this is only a small issue for the compilr projects, but "normal F#" projects with many dependenies will have a very hard time.

Ok course we could opt-out and add project.json.lock files to gitignore. But then we don't pin transitive dependencies any more (in project.json we only have top-level dependencies). If I understand the process correctly this basically means it will install whatever transitive dependency version fits at the time of resolution. So different checkouts (CI, coworker, release) may getting different versions of the transitive dependencies.

Is there already some discusion about this in the F# space? I know there is aspnet/dnx#2332 but it's totally unclear to me when and if things are changing.

[ctaggart]

Yes, project.json.lock is not meant to be committed to the repository and should be in .gitignore. That means that there isn't a good way to pin the resolved dependencies yet with the project.json approaches. If you can build the project.json.lock with paket restore, that would be great. :)
Also related: fsprojects/Paket#736

[forki]

Are the project.json files needed here in this repo? Or only the project.json.lock?
I tried to remove the project.json to test this and then nuget fails to restore packages.
So I committed the packages folder and disabled the explicit restore in FSharp.source.target (\.nuget\NuGet.exe restore .\tests\fsharp\project.json -PackagesDirectory packages -ConfigFile .\.nuget\NuGet.Config)

But I still get

(It's complaing about missing System.Runtime.dll)

then I thought I can add the project.json files again and remove the dependencies block and see what happens. But still the same error. so it seems the nuget restore part from project.json is still needed. and it would always overwrite the project.json.lock (so even if we commit the lock file we get random versions of transitive dependencies?).

[enricosada]

@KevinRansom two stuff

some issue can be developed inside master branch (like portablepdb, cleaup tests) because are usefull (can be merged later in coreclr branch)

The real priority i think is the build server (enable roslyn jenkins and appveyor) because outside ms is difficult to know if the branch is green (and we can clone and start contribute) or is a problem in my machine or the code does not compile. If i see the build server, i can clone the repo at the latest working commit

Also we should run like roslyn two build of same coreclr branch, one with net40, one with coreclr.
So we know if a change break net40 (we get problems later in the merge anyway).
Maybe we can also merge the coreclr inside master a bit earlier, instead like last time a long running fsharp4 branch, it's easier to see smaller pr and use a build parameter

[dsyme]

Where's the guide for building the coreclr branch? I looked in these places and didn't see the build instructions:

• https://github.com/Microsoft/visualfsharp/wiki/How-to-help-with-the-CoreClr-port-of-Visual-F%23
• https://github.com/Microsoft/visualfsharp/wiki/F%23-for-CoreCLR---Status

plus the DEVGUIDE.md in the coreclr branch

thanks

[dsyme]

I think we can close this now?