To build and install the FSharp.Core for mono 2.1 use make do-2-1 make install-2-1 Suppress some irrelevant warnings in the installation process
The mono F# 2.0 build built an extra copy of FSharp.Compiler.dll, fsc.exe, fsi.exe under mono/lib/2.0. These were to give the option to run the compiler and F# interactive running under .NET 2.0, accessed by "fsharpc2" and "fsharpi2" For F# 3.0 these are no longer needed - like Microsoft releases of F# we only need one compiler, running on the mono .NET 4.0 profile. This compiler is used for compiling .NET 2.0, .NET 4.0, Silverlight, Portable, Android etc. code. There is nothing special about .NET 2.0 that needs its own copy of the compiler. So the commands "fsharpc2" and "fsharpi2" have been removed from the mono F# 3.0 build. The commit also includes some other changes to reduce build times, like running fsyacc, flex etc. only once rather than twice.
We are building optimised binaries with --optimize and /debug:pdbonly, the results should be placed in "release" not "debug"
Builds are breaking needlessly on OSX, just remove the PKG_CHECK_MODULES for now.
… fail Exceptions can escape the incremental builder when the wong FSharp.Core is referenced. This just leaves a comment marking the place where this can happen
… client The /resident server is being spawned with mono even if mono-when is being used for the calling fsc.exe. This change makes the /resident switch also benefit from SGEN when it is being used. Will ask on the mono list if there is a better way of detecting if mono-sgen is being used (or even just finding the exact path to the mono being used to run the program)
… installations) We do this aclocal call because it seems to be needed on some Mac installations to enable autoreconf to run. But if the paths don't exist we get an error. So just discard the error.
Optionally build FSharp.Core for Mono profile 2.1. make do-2-1 builds libs/debug/2.1/FSharp.Core which (fingers crossed!) should be enough or MonoAndroid and MonoTouch, though the restrictions on generics on those platforms will be a problem. Only works for Mac with MonoAndroid installed right now but only because the path to the 2.1 profile mscorlib.dll is hardwired Also, only build one copy of proto (the one for .NET 4.0) to reduce build times
This gives a 50% compiler speedup so greatly reduces build time SGEN appears stable enough to do this, at least on the mac.
The /resident switch on the F# compiler was not working because an error was escaping the compiler. "errrorRecoveryNoRange" must be "stopProcessingErrorRecovery". Also move the implementation of the /resident switch to fscmain.fs I checked with @dsyme over IM that these change were ok.
… build This speeds up builds a bit (and we don't normally connect a debugger during the build)
F# 3.0 uses version number 188.8.131.52 for FSharp.Core (184.108.40.206 for the Mono-for-.NET-2.0 profile). This would break binary compat for assemblies that expect to bind to FSharp.Core 220.127.116.11. This means we need to install a global policy redirect DLL for FSharp.Core 18.104.22.168 --> FSharp.Core 22.214.171.124 FSharp.Core 126.96.36.199 --> FSharp.Core 188.8.131.52 For example, the existing MonoDevelop binding DLL for F# expects to bind to FSharp.Core 184.108.40.206. Also, "make do-4-0" no longer makes the proto compiler, you need a "make all" or "make proto" for that
The XBuild targets file gets installed into the place(s) expected for standard F# project files. For F# 2.0 project files this is .../Microsoft F#/v4.0/Microsoft.FSharp.targets For F# 3.0 project files this is .../Microsoft SDKs/F#/3.0/Framework/v4.0/Microsoft.FSharp.targets