skip making archives for inner loop

[baronfel]

cc @joeloff

Before:

>./build.cmd
...
  redist succeeded (130.0s) → artifacts\bin\redist\Debug\net10.0\redist.dll

Build succeeded in 205.3s

After:

>./build.cmd
...
  redist succeeded (10.9s) → artifacts\bin\redist\Debug\net10.0\redist.dll

Build succeeded in 52.1s

[Copilot]

Copilot wasn't able to review any files in this pull request.

Files not reviewed (1)

• src/Layout/redist/targets/Directory.Build.targets: Language not supported

[baronfel]

@ViktorHofer looks like this change breaks the VMR - can you advise on the best way to skip this step for local builds? It's kinda ridiculous to have almost 4 minute cycle times for simple changes.

[ViktorHofer]

From what I see in a binlog (sdk official build: win-x64), generating the archives only takes 10-15s depending on the machine:

I'm not sure where you got those numbers from. Windows or Unix?

It's kinda ridiculous to have almost 4 minute cycle times for simple changes.

I assume you are referring to an incremental sdk build? That time can be reduced by declaring inputs & outputs on a bunch of targets in redist.csproj. I.e. the GenerateArchives target would benefit from that.

[baronfel]

@ViktorHofer Terminal Logger was my primary guide here - this is mid-build:

I usually sit on this target for a few minutes. Here's the final time from a binlog:

That time can be reduced by declaring inputs & outputs on a bunch of targets in redist.csproj

Yeah, of course you're right here. But that's harder than just turning things off :) Might be necessary to not break the VMR build though :-/ Is there a way that normal VMR build could trigger this even if dev inner-loop doesn't?

[ViktorHofer]

Thanks for sharing more details. I'm surprised to see such long zip times. Could Defender be interfering there?

I don't think we should turn this target off, even in local builds. It produces the primary output of the sdk repo. I would rather invest in better Inputs and Outputs and investigation onto why the zip invocation takes that long on your machine.

[ViktorHofer]

Here are the times from a fresh build on my Windows (Surface Laptop Studio) machine:

Twelve seconds to compress the redist directory make sense to me.

[baronfel]

Are you on a devdrive there? I suspect that could be a big part of my problems.

[ViktorHofer]

No. On a normal NTFS drive but the folder excluded from Defender scanning.

[ViktorHofer]

Btw I filed #48070 to track adding incremental build support to redist.csproj.