-
Notifications
You must be signed in to change notification settings - Fork 839
Update mono props: support OSX and more .NET Framework versions #6181
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
A potential solve for dotnet#6180 that uses msbuild built-ins to determine the target OS and pivots off of that to set the FrameworkPathOverride. I included a `MonoRoot` property to allow for easy integration into the build process that fsharp/fsharp uses, which allows for a 'floating' mono root.
KevinRansom
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for this, looks good.
|
@brettfo, can you run your eyes over this pls Thanks Kevin |
|
If we add this I'd like a test leg to ensure it continues to work. I'm not positive, but I think the Linux VMs for our CI server have mono installed. Can you add the following to jobs:
- job: Linux
pool:
vmImage: ubuntu-16.04
timeoutInMinutes: 90
strategy:
- maxParallel: 2
+ maxParallel: 3
matrix:
dotnet_sdk:
_command: make
_args: Configuration=release
+ mono:
+ _command: xbuild # or `mono` or however you invoke this
+ _args: fsharp.proj # this might contain too many projects to work on mono
- # disabled until it can be properly fixed
release_fcs:
_command: ./fcs/build.sh
_args: Build
steps:
... |
|
It'd be good to add a |
|
There should be a hosted macOS (the CLI uses one) but I'm not sure how to hook it up |
6399980 to
449a702
Compare
… build the compiler for .net framework using mono
|
Ok, I found the vm identifier for the macOS runner on VSTS, I've added a matching set of jobs for that OS, and added a job that does a .net-framework build of some part of the repository at all to verify the FrameworkPathOverride changes (as well as fighting with case-sensitivity at least 10 times). Now to just iterate on that to get the build green. |
|
Actually, per @KevinRansom's comments on another thread, I think I'll remove the 'build-netframework-anything' job for now because it's going to require additional work and may conflict with upcoming build system changes that @brettfo has. So given that, I think adding the macOS runner and having it run the same jobs as the linux runner is an acceptable next step for this. |
this required additional build work that may conflict with upcoming work, so we'll just settle for building the existing components on macos at all in CI
|
The failed build was a nuget download error on linux. What do? |
|
This! |
|
I don't know what this single test failure is on the windows FCS tests, and it hasn't failed before. This is mildly irritating. |
|
The FCS tests are very flaky, so sometimes it just takes a while 😕 |
|
Glory be, they are green! |
|
Thanks for this Kevin |
A potential solve for #6180 that uses msbuild built-ins to determine the target OS and pivots off of that to set the FrameworkPathOverride. I included a
MonoRootproperty to allow for easy integration into the build process that fsharp/fsharp uses, which allows for a 'floating' mono root.Testing this locally on my OSX laptop seems to have the intended effect: for all TFMs below I can pivot to the correct -api folders, and supplying a
MonoRootvia MSBuild parameter influences the search paths as expected.