Suggestion: Binary packages for debian, RPM, Windows about fsharp HOT 44 CLOSED

maybe stupid question, but how can I build the compiler on windows/.NET?

from fsharp.

· cd src

· msbuild fsharp-proto-build.proj /p:TargetFramework=cli\4.0

· ngen install ..\Proto\cli\4.0\bin\fsc-proto.exe

· msbuild fsharp-library-build.proj /p:TargetFramework=cli\4.0 /p:Configuration=Release

· msbuild fsharp-compiler-build.proj /p:TargetFramework=cli\4.0 /p:Configuration=Release

From: Steffen Forkmann [mailto:[email protected]]
Sent: Monday, October 29, 2012 8:17 PM
To: fsharp/fsharp
Subject: Re: [fsharp] Suggestion: Binary packages for debian, RPM, Windows (#32)

maybe stupid question, but how can I build the compiler on windows/.NET?

—
Reply to this email directly or view it on GitHub #32 (comment) .

https://github.com/notifications/beacon/PEbBlxxMpehCX8Coxftko_pVNyVb6kZRiY6Z6FvG1t3U-DhGYJn3DddSBo-oPKeb.gif

from fsharp.

This should be captured in a batch file and mentioned in the readme. Can you do this?
Is there a way to detect the msbuild path?

from fsharp.

Can't we use FAKE for this kind of stuff?

from fsharp.

;-)

yes we could, but this introduces a circular dependency and most of the important stuff is already in the *proj files, so that may be overkill.

from fsharp.

I meant for the full generation of executables too :). I'm not sure about the detection of msbuild path, any ideas on that?

from fsharp.

I will revisit how FAKE does this. At the moment I can't remember anything about this ;-)

from fsharp.

I added notes to the README, see 252a345

You can just use

msbuild fsharp-build.proj

or

xbuild fsharp-build.proj

This makes binaries in Debug/... and Release/... with /p:Configuration=Release

That's not enough for a package build, so the "official" linux build still uses make. In particular yhere is logic in src/fsharp/targets.make to place down the biaries in exact Mono installation configuration, in lib/mono/2.0, lib/mono/4.0, the targets file, the FSharp.Core.sigdata/optdata etc., plus the Makefile also build the policy.* projects which create the binding redirect DLLs for FSharp.Core to forward everything to 2.3.0.0 (on .NET 2.0) and 4.3.0.0 (on .NET 4.0)

-- ben

from fsharp.

@fahadsuhaib I tried your script in 3b5f447 but I get:

Build started 30.10.2012 08:48:36.
Project "C:\Code\fsharp\src\fsharp-proto-build.proj" on node 1 (default targets
).
Project "C:\Code\fsharp\src\fsharp-proto-build.proj" (1) is building "C:\Code\f
sharp\src\fsharp\FSharp.Build-proto\FSharp.Build-proto.fsproj" (2) on node 1 (B
uild target(s)).
C:\Code\fsharp\lib\bootstrap\2.0\FSharp.SRGen.targets(29,5): error MSB4062: The
"FsSrGen" task could not be loaded from the assembly C:\Code\fsharp\lib\bootst
rap\2.0\FSharp.SRGen.Build.Tasks.dll. Die Datei oder Assembly "FSharp.Core, Ver
sion=2.0.50726.900, Culture=neutral, PublicKeyToken=a19089b1c74d0809" oder eine
Abhängigkeit davon wurde nicht gefunden. Das System kann die angegebene Datei
nicht finden. Confirm that the declaration is correct, that the ass
embly and all its dependencies are available, and that the task contains a publ
ic class that implements Microsoft.Build.Framework.ITask. [C:\Code\fsharp\src\f
sharp\FSharp.Build-proto\FSharp.Build-proto.fsproj]

from fsharp.

Having still the same error.

from fsharp.

so you tried this?

gacutil /i lib\bootstrap\2.0\FSharp.Core.dll

from fsharp.

No I did not. But I don't like this solution and can't believe this is the right way.
And on the CI server I probably don't have the rights to do this.

from fsharp.

think this is now fixed, see ab54604

i tested with xbuild after removing FSharp.Core 2:0:50726:900 from the gac

from fsharp.

you are right. one step further:

C:\Code\fsharp\lib\bootstrap\4.0\Microsoft.FSharp.targets(61,3): error MSB4062:
The "CreateFSharpManifestResourceName" task could not be loaded from the assem
bly C:\Code\fsharp\lib\bootstrap\4.0\FSharp.Build.dll. Die Datei oder Assembly
"FSharp.Build, Version=4.3.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3
a" oder eine Abhängigkeit davon wurde nicht gefunden. Fehler bei der Validierun
g des starken Namens. (Ausnahme von HRESULT: 0x8013141A) Confirm that the declaration is correct, that the assembly and all its dependencies are a
vailable, and that the task contains a public class that implements Microsoft.B
uild.Framework.ITask. [C:\Code\fsharp\src\fsharp\FSharp.Build-proto\FSharp.Buil
d-proto.fsproj]

from fsharp.

Can you try replacing the FSharp.Core.dll in that directory with the strong-name-and-not-delay-signed one from Microsoft?

It is a problem that we can't only build a strong-name-and-delay-signed FSharp.Core.dll. If we ever start adding to the functionality in FSharp.Core.dll or bug fixing on it we may have to switch to a different strong name.

Alternatively we would add a skip-strong-name-verification entry for FSharp.Core. I don't kno if you can do that on the build server.

from fsharp.

nope. doesn't seem to work

from fsharp.

ok the problem is FSharp.Build is not strong-name signed, not FSharp.Core. Mono doesn't care about that, windows .NET is fussy

This will need work. We need to build a properly strong-named FSharp.Build. I'm working on that.

(this repo has not normally been compiled on Windows, hence the problems)

from fsharp.

There's a (probably partial) fix for this here. 77657ed

Though I haven't tested the end-to-end build on windows, will do that tomorrow.

from fsharp.

Ben you're going absolutely in the right direction. But it seems there is always a next problem:

C:\Code\fsharp\lib\bootstrap\2.0\FSharp.PowerPack.targets(33,3): error MSB4062:
The "FsLex" task could not be loaded from the assembly C:\Code\fsharp\lib\boot
strap\2.0\FSharp.PowerPack.Build.Tasks.dll. Die Datei oder Assembly "FSharp.Cor
e, Version=2.0.50726.900, Culture=neutral, PublicKeyToken=a19089b1c74d0809" ode
r eine Abhängigkeit davon wurde nicht gefunden. Das System kann die angegebene
Datei nicht finden. Confirm that the declaration is correct, that t
he assembly and all its dependencies are available, and that the task contains
a public class that implements Microsoft.Build.Framework.ITask. [C:\Code\fsharp
\src\fsharp\FSharp.Compiler-proto\FSharp.Compiler-proto.fsproj]

from fsharp.

Just a note, I tried to build the source from codeplex and it ran without any issues. The major difference from that to this one is we have pre-compiled dlls available under “lkg” which are signed too. The proto compiler uses this and then the final F# compiler will use the proto to build.

For the gacutil thing, we could tell msbuild to refer to a particular path,

MSBUILD.EXE <solution/projectname> /p:"ReferencePath=<Path1;Path2;Path3>"

I haven’t tested it yet, but hopefully this should make the build files to pick from the custom build location.

from fsharp.

love the mix of german and english in thet error mssage

from fsharp.

sorry ben, that german part is just: "dependency not found" and "file not found"

from fsharp.

ok recent commits to fsharp/fsharp should have this sorted, see https://github.com/fsharp/fsharp/commits/master

The repo now builds for me on windows and mac, using
cd src
msbuild fsharp-build.proj

on windows. The binraries produced are not a "good" set of binaries for inclusion in Mono because of some strong name signing and some installation/policy DLLs are not built. But it should be good enough for CI. The build on window should not require any visual studio bits installed but have not verified that

from fsharp.

@forki understood it, just lol - microsoft's locaclization needs a bit of work

from fsharp.

This builds the protocompiler successfully on my machine, but the release folder is empty.

BTW: I added http://teamcity.codebetter.com/viewType.html?tab=buildTypeStatusDiv&buildTypeId=bt817 in order o see this on the CI server, but there is a different error.

from fsharp.

builds into Debug. Add
/p:Configuration=Release

for release

from fsharp.

The CI build is using an installed F# 2.0 compiler (I suppose VS2012 is on the machine?)

C:\Program Files (x86)\Microsoft F#\v4.0\fsc.exe

the FSharp.Buld.dll task should be pointing to the F# 3.0 compiler. I'll take a look at the compiler location logic the FSharp.Build.dll uses

from fsharp.

ok, compiler location probing logic updated and bootstrap FSharp.Build replaced, new build in progress here:

http://teamcity.codebetter.com/viewLog.html?buildId=54517&buildTypeId=bt817&tab=buildLog

from fsharp.

We had a crashing build on the mono build server (a core dump in the proto ompiler), I turned off SGEN on the mono build on the build server and it now gets through

http://teamcity.codebetter.com/viewLog.html?buildId=54514&tab=buildResultsDiv&buildTypeId=bt814

Its still on by default in the repository, we should keep an eye on it

from fsharp.

Nice the windows build seems to work on the CI server.
On my local system I still get:

"C:\code\fsharp\src\fsharp-build.proj" (default target) (1) ->
"C:\code\fsharp\src\fsharp-library-build.proj" (Build target) (6) ->
"C:\code\fsharp\src\fsharp\FSharp.Core\FSharp.Core.fsproj" (Build target) (7) -

(CoreCompile target) ->
C:\code\fsharp\lib\bootstrap\4.0\Microsoft.FSharp.targets(149,9): error MSB60
04: The specified task executable location "......\Proto\net40\bin\fsc-proto.
exe" is invalid. [C:\code\fsharp\src\fsharp\FSharp.Core\FSharp.Core.fsproj]

That's really not much information.

from fsharp.

can you run the usual diagnostics

msbuild fsharp-build.proj /t:Clean
msbuild fsharp-build.proj /v:d

from fsharp.

Upvote, I'd definitely consider using F# for my apps if I didn't have to depend on Visual F#.

from fsharp.

I added a NET 2.0 build on the CI server. Unfortunately it's red. http://teamcity.codebetter.com/viewType.html?buildTypeId=bt827&tab=buildTypeStatusDiv

I would like to have a .NET 2.0 version of fsi to bundle it with FAKE.

from fsharp.

Can I ask - why do you need a .NET 2.0 version? The build now assumes that fsharpc and fsharpi run with .NET 4.0

from fsharp.

I'd like to support a FAKE version which still runs on .NET 2.0. That's all.

from fsharp.

The repo should now build on Windows using Mono 3.0.1

cd src
xbuild.exe fsharp-proto-build.proj
xbuild.exe fsharp-library-build.proj
xbuild.exe fsharp-compiler-build.proj

mono.exe ..\Debug\net4.0\bin\fsc.exe
mono.exe ..\Debug\net4.0\bin\fsi.exe

It has been tested with both Mono + VS installed. It hasn't been tested with only Mono installed....

from fsharp.

Just tried to use msbuild fsharp-build.proj but fsc-proto.exe crashes with the following:

Unhandled Exception: System.IO.FileNotFoundException: Could not load f
   ile or assembly 'FSharp.Core, Version=4.3.0.0, Culture=neutral, Public
   KeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cann
   ot find the file specified.
      at Microsoft.FSharp.Compiler.CommandLineMain.main(String[] argv)```

from fsharp.

When compiling with the Mono 3.0.2 binaries on Windows, I get an out of memory crash, too. Can we get Windows binaries?

from fsharp.

Any news on the RPMs?

from fsharp.

I also think an Osx version should be packaged up too, yes it ends up in mono but the version may not be current.

from fsharp.

I'm trying to create a RPM package, and I'm getting 'configure: error: "You need mono 2.9"'; but I have 3.2.3 - should I go around that by just removing that check?

from fsharp.

I normally just add the full prefix to the gac, you could do that though.

from fsharp.

I think it's that I haven't built my mono RPM with pkg-config though...

from fsharp.

Closing this - there are now Debian packages available, and there are other issues ttracking the need for Windows packages for the open edition of F#

from fsharp.