use proto build on mac and linux

[dsyme]

The build.sh was not correctly using a proto build on macOS and Linux.

This means PRs like #6325 were failing because the FSharp.Core.UnitTests must be built with an updated compiler.

The commit has been cherry picked into #6325 - if the mac and linux builds there start to pass then it shows that it's worked

[dsyme]

Although this is green it is not yet working, the proto compiler is still not being used and #6325 is still failing. Working on it.

[brettfo]

See above comments.

[dsyme]

I don't believe this is needed because DisableCompilerRedirection is true

[dsyme]

@brettfo I've been having a hell of a time with this one. I think it's ok now, I just managed to complete a build.

(I'm only working on it because it blocks my other work, and a lot of my F# vNext PRs are failing because we don't use the proto build on Linux/macOS and they require it.)

[dsyme]

Cool, well, things going better now, at least on Linux and macOS

@brettfo the problem was MSBuild node reuse when different MSBuild executions load different FSharp.Build.dll. I disabled node reuse in build.sh as a result (it's disabled for CI anyway)

[dsyme]

@KevinRansom @brettfo OK, fixed another problem. I had a one character error fcs instead of fsc here

I have to say, the .NET Core execution of tests under tests\fsharp is fantastically, brutally complicated. It's a complete mishmash on top of the existing mishmash. Among other things we do this

• compile the F# test project which then
• creates a project file dynamically in temporary directory
• uses baroque MSBuild XML to refer to Directory.Build.targets under visualfsharp\tests
• implicitly load targets and properties further up the tree
• loads a build DLL whose location is specified by very hidden MSBuild specifications
  and so on and so on.

I had to stare at MSBuild /v:diag output for ages to spot the one character error

After this experience I'm really tempted to suggest we junk all of the build infrastructure under tests\fsharp for .NET Core and start again with a set of .NET Core projects that exercise the different test.fsx and so on. It's just impossibly complicated as it stands.

[dsyme]

@brettfo THis is finally ready. I reverted things to contain only the changes needed for bootstrapping

[KevinRansom]

@brettfo, is this still needed?

[dsyme]

I'm pretty certain this is still needed

[dsyme]

The one remaining question about how to get this "node_reuse" thing specified correctly.

[dsyme]

@brettfo Could you re-review and approve this? I think I updated it as needed removing the verbosity flag changes. Among other things the lack of bootstrap on Linux and OSX is now hitting #6634

[dsyme]

@brettfo Could you re-review and approve this? I think I updated it as needed removing the verbosity flag changes. Among other things the lack of bootstrap on Linux and OSX is now hitting #6634

[dsyme]

@brettfo ping :)

[brettfo]

@dsyme I've been messing a bit with our build, can you either rebase or merge master in again just to make sure this has everything? Otherwise I'm satisfied.

[dsyme]

Error in SourceBuild_Linux

/home/vsts/work/1/s/.packages/microsoft.sourcelink.common/1.0.0-beta2-18618-05/build/InitializeSourceControlInformation.targets(7,81): error MSB4022: The result "" of evaluating the value "$(_MicrosoftSourceLinkCommonAssemblyFile)" of the "AssemblyFile" attribute in element <UsingTask> is not valid. [/home/vsts/work/1/s/src/fsharp/fsi/fsi.fsproj]

[dsyme]

Dodgy test:

Tests.LanguageService.QuickInfo.UsingProjectSystem.TypeProvider.XmlDocAttribute.Type.Comment

[dsyme]

@brettfo I believe you still need to mark this as approved

@KevinRansom I can't see how the CI failures are related to the PR, though I suppose they might be - is CI running clean for us reliably?

[cartermp]

@dsyme I get some issues with timeouts on downloading packages from time to time, but I don't have any reason to suspect CI not running cleanly as per my own recent PRs.

[dsyme]

@brettfo I don't understand the failure in SourceBuild_Linux - this is some new thing

/home/vsts/work/1/s/.packages/microsoft.sourcelink.common/1.0.0-beta2-18618-05/build/InitializeSourceControlInformation.targets(7,81): error MSB4022: The result "" of evaluating the value "$(_MicrosoftSourceLinkCommonAssemblyFile)" of the "AssemblyFile" attribute in element <UsingTask> is not valid. [/home/vsts/work/1/s/src/fsharp/fsi/fsi.fsproj]

It's something to do with the order of loading properties etc. for the Microsoft.SourceLink.Common package, but the process by which that is loaded is entirely obscure to me.

I can't work out why this would

1. only affect the source build
2. not affect fsc.fsproj

changes addressed, see #6380 (comment)

[dsyme]

OK this is green, I'll merge this now.

@brettfo I resolved your review since the changes you wanted have been addressed