Enable DeterministicSourcePaths.

[tmds]

Contributes to dotnet/source-build#4011.

@MichaelSimons @ViktorHofer ptal.

cc @omajid

[tmds]

Regressed in #115.

Actually, it did not regress there. Each project had <DeterministicBuildOptOut>true</DeterministicBuildOptOut> set before that PR.

[mthalman]

Is this intended to completely fix dotnet/source-build#4011 or just contribute to fixing it? Because the original post of that issue is referring to System.Collections.dll which would be unaffected by these changes.

[tmds]

Is this intended to completely fix dotnet/source-build#4011 or just contribute to fixing it? Because the original post of that issue is referring to System.Collections.dll which would be unaffected by these changes.

That was the intention, but indeed it does not fix all issues.

runtime seems to be producing both dlls with and without the pathmapping.

I'll take a look at what is going on there.

[tmds]

I'll take a look at what is going on there.

I took a look and wrote up an issue in runtime repo with some findings: dotnet/runtime#99594.

[tmds]

Based on my builds, this has the desired effect of masking the build server vmr path.

This should be good to merge.

[mthalman]

I don't think these changes are necessary. This configuration is already done at the root level: https://github.com/dotnet/dotnet/blob/8c1aeea68e7274f210d9eb210f2451444013d214/repo-projects/Directory.Build.props#L147-L148

This flows into the build of source-build-externals and, from there, into the builds of the submodules it contains. I've verified this in the binlog.

[tmds]

I don't think these changes are necessary.

As a minimum, we need to remove the <EnvironmentVariables Include="DeterministicSourcePaths=false" />.

If we don't need to add an EnvironmentVariables here for DeterministicSourcePaths, then that probably applies also to other envvars being set in the file?

[mthalman]

I don't think these changes are necessary.

As a minimum, we need to remove the <EnvironmentVariables Include="DeterministicSourcePaths=false" />.

If we don't need to add an EnvironmentVariables here for DeterministicSourcePaths, then that probably applies also to other envvars being set in the file?

I guess the difference would be in whether the variables are necessary for a standalone build of source-build-externals (not in the context of the VMR). Do you see it being necessary to support deterministic paths for a standalone build of source-build-externals? If so, then your original changes are good.

[ViktorHofer]

FWIW @MichaelSimons mentioned the following in #115 which changed the default:

Removed the DeterministicBuildOptOutProperty as every repo was specifying it except netcorecli-fsc which from my assessment doesn't matter since that repo has no binaries in the resulting package. If it did, it likely needs this property set.

[tmds]

I guess the difference would be in whether the variables are necessary for a standalone build of source-build-externals (not in the context of the VMR). Do you see it being necessary to support deterministic paths for a standalone build of source-build-externals? If so, then your original changes are good.

I only care about when this gets built as part of the VMR. I would assume this is true for the other envvars set in the file as well.

I'll remove the DeterministicSourcePaths envvars.

[ViktorHofer]

Why would we want to enable deterministic source paths only inside the VMR? What's the technical reason for that? I would assume that we want to keep the diff between the repo and the VMR build as small as possible.

[tmds]

I also prefer to keep the build difference minimal.

I understood @mthalman's feedback to mean he would prefer to leave the lines out, so I've applied that change.

I'll revert it.

[ViktorHofer]

This commit introduced the opt-out switch: 4303e22

I noticed that it was initially only set for a few projects and only two of those still exist: application-insights.proj and newtonsoft-json.proj. The other projects probably only had this switch because the project file was being copied.

Please test that with your change those two projects still have the correct sourcelink information set (in addition to the deterministic source paths). My guess is that the opt-out switch isn't necessary anymore as the task that got added with the above commit which adds sourcelink metadata, doesn't exist anymore: https://github.com/search?q=repo%3Adotnet%2Fdotnet%20WriteSourceRepoProperties&type=code

Unfortunately the commit message doesn't provide much information and I can't find the underlying PR. @MichaelSimons would you know?

[mthalman]

Here's the original PR: dotnet/source-build#1168. Unfortunately there's not a description.

[MichaelSimons]

@MichaelSimons would you know?

This predates my time on source-build. Your assessment seems logical to me.

[tmds]

I noticed that it was initially only set for a few projects and only two of those still exist: application-insights.proj and newtonsoft-json.proj. The other projects probably only had this switch because the project file was being copied.
Please test that with your change those two projects still have the correct sourcelink information set

Why do these two projects need special handling?

I assume that without special handling, https://github.com/dotnet/dotnet is the source root for the whole build, which would be the simplest option.