Merged
Conversation
…to travis-coreclr
Contributor
Author
|
@vasily-kirichenko We were missing a Artifacts should be under Debug |
Contributor
Author
|
We're no longer green on Travis: |
Contributor
Author
|
Travis is green again see "travis" branch here https://travis-ci.org/dsyme/visualfsharp/branches |
Contributor
Contributor
Author
|
@forki Mostly the LKG going. But using FSharp.Compiler.Tools has also uncovered a few problems, especially on Mono (executable bits not set, using F# Interactive scripts on Mono causes codegen failures for some variations on |
Contributor
Author
|
@forki See fsharp/fsharp#639 and fsharp/fsharp#638 |
nosami
pushed a commit
to xamarin/visualfsharp
that referenced
this pull request
Jan 26, 2022
This enables a build of this repo using Mono.
- Use FSharp.Compiler.Tools nuget package as LKG (like fsharp/fsharp)
- Update init-tools.cmd and init-tools.sh to be the latest from the .NET Core repos.
- There are a bunch of simplifications and extra checking in FSharpSource,targets
- Some of the key signing logic has Mono-compat implementations
- Removed use of tuple structs from the compiler code (this was done when initially updating the LKG. I eventually updated the LKG to one that actually supports tuple structs, but the uses of the feature aren't needed in the compiler code, so I'll remove them in any case)
- Adjust CustomCopyLocal and remove subst.exe. We can work out how to implement a copy-and-substitute at a later point.
- Project files on Mono need to use
<FSharpSourcesRoot>$(MSBuildProjectDirectory)\..\..</FSharpSourcesRoot>
instead of
<FSharpSourcesRoot>..\..</FSharpSourcesRoot>
CoreCLR bits are not built on Mono though the PR includes some preliminary changes in that direction.
We do some things differently on Linux/Mono:
- UseMicroBuild is off
- UseSourceLink is off
- UseGatherBinaries is off
- AddVsSdkAttributesToSomeCoreComponents is off
The define CROSS_PLATFORM_COMPILER is set when building for Mono to workaround a couple of limitations in Mono. The code is written in a way so that it is valid to set it on Windows too, but we don't CI that.
One odd de-capitalization change was needed in init-tools.sh to use microsoft.dotnet.buildtools instead of Microsoft.DotNet.BuildTools since the Linux package gets the former name
See dotnet#1703
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.

This enables a build of this repo using Mono. Initially I've been testing using Travis - we should move to .Jenkins, perhaps as part of this PR.
init-tools.cmdandinit-tools.shto be the latest from the .NET Core repos.subst.exe. We can work out how to implement a copy-and-substitute at a later point.instead of
We do some things differently on Linux/Mono:
One odd de-capitalization change was needed in
init-tools.shto usemicrosoft.dotnet.buildtoolsinstead ofMicrosoft.DotNet.BuildToolssince the Linux package gets the former name