Pack MIBC files

[psfinaki]

Fixes: #12636
Fixes: #13328

Part one of implementing PGO in F# - this copying the restores MIBC files to the resulting NuGet packages.

The result looks like this:

[github-actions]

✅ No release notes required

[psfinaki]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 2 pipeline(s).

[vzarytovskii]

Gonna block it to not forget to review on Monday

[KevinRansom]

We need to deploy all of the packages to the SDK. Size is not that big a deal.

[vzarytovskii]

I pushed a fix which

1. Produces compiler package packed with profiles
   
2. Applies it to proto.

All things are in place, thing left to do:

1. Make sure it really applies r2r when building proto fsc
2. When new artifacts arrive to dotnet/sdk, do the same there.

[vzarytovskii]

There are issues with locking files. I suggest to copy initially to two different paths - mibc and mibc_proto or something. And apply to proto from mibc_proto, and copy to nuget from the other one.

[vzarytovskii]

Fixed (probably) fixed one part, I believe you'll figure out how to retry and or not lock it.

[psfinaki]

Fixed (probably) fixed one part, I believe you'll figure out how to retry and or not lock it.

Sure let me try something.

[vzarytovskii]

After restore, it seems that files are getting locked:

Directory.Build.targets(28,5): error MSB3026: (NETCORE_ENGINEERING_TELEMETRY=Build) Could not copy "D:\a\_work\1\s\.packages\optimization.windows_nt-x86.mibc.runtime\1.0.0-prerelease.23614.4\data\DotNet_FSharp.mibc" to "D:\a\_work\1\s\artifacts\\mibc\optimization.windows_nt-arm64.mibc.runtime\DotNet_FSharp.mibc". Beginning retry 1 in 1000ms. The process cannot access the file 'D:\a\_work\1\s\artifacts\\mibc\optimization.windows_nt-arm64.mibc.runtime\DotNet_FSharp.mibc' because it is being used by another process. 

Maybe @baronfel and/or @rainersigwald have some advise here?

[vzarytovskii]

Well, worst case scenario, we can just slap Retries="1000" on Copy and hope that nuget (or whatever holds those files after restore) will release them.

[rainersigwald]

Putting this in Directory.Build.targets means it'll run in every individual project, and it's copying to the same location in all of them.

You just want this once/build, right? But "in any way the build could be triggered" is why you're putting it in D.b.targets?

[vzarytovskii]

Putting this in Directory.Build.targets means it'll run in every individual project, and it's copying to the same location in all of them.

That's a good point, I haven't thought about it 🤦

You just want this once/build, right? But "in any way the build could be triggered" is why you're putting it in D.b.targets?

Yep, pretty much, we want it to happen once, no matter what we're building.

[rainersigwald]

In that case what I'd do is this:

1. Create a new .targets file that does only this copy stuff.
2. Change the D.B.targets target to do an <MSBuild task call to that new file/target, with RemoveProperties="TargetFramework" (and maybe passing along some paths that Arcade/common.targets derives for you)

Then the MSBuild engine will deduplicate the request and do the copy operation only once.

[vzarytovskii]

In that case what I'd do is this:

1. Create a new .targets file that does only this copy stuff.
2. Change the D.B.targets target to do an <MSBuild task call to that new file/target, with RemoveProperties="TargetFramework" (and maybe passing along some paths that Arcade/common.targets derives for you)

Then the MSBuild engine will deduplicate the request and do the copy operation only once.

Ooh, nice, thanks a tonne, Rainer, will try it out tomorrow!

[psfinaki]

@KevinRansom@vzarytovskii this is finally green! 🍾

[psfinaki]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 2 pipeline(s).

[psfinaki]

🍾 🍾 🍾