renamed the F# launch scripts to avoid a name collision with the Scala fast offline compiler, fsc
Merge pull request #10 from killerswan/master

renamed the F# launch scripts to avoid a name collision with the Scala fast offline compiler
Modified build options so assemblies are compiled with optimizations on.
F# source merge of r67146 from http://fsharppowerpack.codeplex.com/ plus fixes for mono

Original merge courtesy of Mohamed Suhaib Fahad <mohamedsuhaiba@live.in>
fix up resolution of assembly references
Merge pull request #17 from kongo2002/reference_fix

fix up resolution of assembly references
Add an autogen.sh file to have a more expectable build system
Merge pull request #19 from knocte/add_autogen

Add an autogen.sh file to have a more expectable build system
Changed --debug flag to 'pdbonly'
configure.ac: require Mono 2.9

The README file was still kind of confusing in the Requirements section,
because:
a) It stated "mono trunk" instead of "mono master", as svn->git migration
happened already a while ago.
b) It mentioned a specific commit in mono instead of simply the lowest
Mono version that included this commit.

Looking at the commit, that fixes bug BNC#641146, it is dated on
September 2010 and went to the master branch:
https://bugzilla.novell.com/show_bug.cgi?id=641146

On August 2012, master branch gets labeled from "2.8.1" to "2.9":
http://lists.ximian.com/mailman/private/mono-patches/2010-October/178421.html

So we can safely assume that any Mono version equal or higher than
Mono 2.9 contains this fix. (The fix was backported too to the 2-8
branch but I still don't know which of the 2.8.x series included it;
at least I know it is not 2.8.1 as that is the version that the
reporter of the bug had.)
Merge pull request #21 from knocte/proper-mono-dep-check

configure.ac: require Mono 2.9
Merge pull request #20 from jack-pappas/master

Compile F# compiler, core libraries with optimizations enabled
targets.make: fix generation of Microsoft.FSharp.targets

This file was ending up installed as is, without the substitution
required to adjust some values such as {BuildSuffix}. As a
consequence, the file could not be used and xbuild would give an
error when trying to find the dll specified.

The values to use forsubst.exe were taken from FSharpSource.targets
file, which has a <Target> to call it, and was not being used
because xbuild is not (and cannot be, I suppose) used when compiling
with Mono due to bootstrapping issues.
install: add symlinks to MS.FSharp.targets to make xbuild happy

By default, F# projects created in VisualStudio 2010 reference a
targets file which in Unix systems should be located in a path like
/usr/lib/mono/Microsoft F#/v4.0 (if prefix is /usr). For this to
work a symlink is required from each target profile.

This issue was reported in
http://stackoverflow.com/questions/7829805/xbuild-and-f-vs2010-project

And this fix removes the need for the first workaround mentioned in
http://xtzgzorex.wordpress.com/2011/01/08/f-and-xbuild-debian/
install: add symlinks for assemblies in /Microsoft F#/ dir too

And this fix removes the need for the second workaround mentioned in
http://xtzgzorex.wordpress.com/2011/01/08/f-and-xbuild-debian/
install: put a symlink as well in the 4.5 profile prefix

Without this symlink in place from the 4.5 profile folder to
4.0's fsc.exe, xbuild gives an error because it is somehow
looking for it in the 4.5 profile (that should be investigated
but for now this workaround does the trick smartly enough).
Merge pull request #22 from knocte/master

Fix makefiles to symlink and generate things properly to keep xbuild happy
mkdir before creating symlinks (knocte's recent mistake)
Merge pull request #23 from antonydenyer/master

mkdir before creating symlinks (knocte's recent mistake) 
install: symlink libs too from 4.5 to 4.0

This commit was incomplete because it only linked
executables, not libraries:

https://github.com/fsharp/fsharp/commit/5cc6d40e05736d03db3ace213f6137d47c67186f