Skip to content
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

Apply source-build patches #58727

Merged
merged 17 commits into from
Mar 15, 2022
Merged

Apply source-build patches #58727

merged 17 commits into from
Mar 15, 2022

Conversation

lbussell
Copy link
Contributor

@lbussell lbussell commented Jan 7, 2022

See dotnet/source-build#2708. The source-build team is making an effort to upstream all of our patches.

Summary of changes:

  • Disable apphost build of 'csi', 'vbi' for source-build to avoid including prebuilt packages
  • Condition some package references out of Tools.props to avoid including prebuilt packages

@tmat
Copy link
Member

tmat commented Jan 9, 2022

Build a specific subset of projects using a new solution file to avoid including non-open-source references.

Why is this needed? We already set <ExcludeFromSourceBuild>true</ExcludeFromSourceBuild> in projects that should be excluded.

@sharwell
Copy link
Member

sharwell commented Jan 10, 2022

Build a specific subset of projects using a new solution file to avoid including non-open-source references.

Why is this needed? We already set <ExcludeFromSourceBuild>true</ExcludeFromSourceBuild> in projects that should be excluded.

This was a red flag to me as well. We should ideally use one approach or the other. I have no issue with either approach, as long as we either drop the other approach or include a new build validation step that verifies the two are consistent (i.e. the set of projects marked <ExcludeFromSourceBuild> is guaranteed to be the same set of projects in the solution filter).

If we use a solution filter, it should be relocated to the eng subdirectory.

Comment on lines 14 to 15
<InnerBuildArgs Condition="'$(DotNetBuildFromSource)' != 'true'">$(InnerBuildArgs) /p:Projects="$(InnerSourceBuildRepoRoot)\Roslyn.sln"</InnerBuildArgs>
<InnerBuildArgs Condition="'$(DotNetBuildFromSource)' == 'true'">$(InnerBuildArgs) /p:Projects="$(InnerSourceBuildRepoRoot)\Roslyn.SourceBuild.slnf"</InnerBuildArgs>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

😕 Why would SourceBuild.props be included in non-sourcebuild builds? Can we just make the <Target> element itself conditional?

@@ -1,6 +1,6 @@
<Project>

<ItemGroup>
<ItemGroup Condition="'$(DotNetBuildFromSource)' != 'true'">
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

❓ Why is Tools.props being included in sourcebuild? Can we exclude the file through some other means?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@@ -28,4 +28,10 @@

<PackageReference Include="Microsoft.CodeAnalysis.Common" Version="$(SourceGeneratorMicrosoftCodeAnalysisVersion)" PrivateAssets="all" Condition="'$(TargetFramework)' == 'netstandard2.0'" />
</ItemGroup>
<ItemGroup Condition="'$(DotNetBuildFromSource)' == 'true'">
<PackageReference Include="System.Collections.Immutable" Version="$(RefOnlySystemCollectionsImmutableVersion)" PrivateAssets="all" Condition="'$(TargetFramework)' == 'netstandard2.0'" />
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

❓ Why isn't this implicit via the Microsoft.CodeAnalysis.Common reference above?

@@ -28,4 +28,10 @@

<PackageReference Include="Microsoft.CodeAnalysis.Common" Version="$(SourceGeneratorMicrosoftCodeAnalysisVersion)" PrivateAssets="all" Condition="'$(TargetFramework)' == 'netstandard2.0'" />
</ItemGroup>
<ItemGroup Condition="'$(DotNetBuildFromSource)' == 'true'">
<PackageReference Include="System.Collections.Immutable" Version="$(RefOnlySystemCollectionsImmutableVersion)" PrivateAssets="all" Condition="'$(TargetFramework)' == 'netstandard2.0'" />
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Consider restructuring this as a <Choose> element to avoid needing the same condition on each <PackageReference>

@lbussell
Copy link
Contributor Author

Why is this needed? We already set <ExcludeFromSourceBuild>true</ExcludeFromSourceBuild> in projects that should be excluded.

See #57342 for a better description of why <ExcludeFromSourceBulid/> doesn't work for projects depending on the Windows Desktop SDK.

I can look into getting rid of the <ExcludeFromSourceBuild>true</ExcludeFromSourceBuild> in project files if the solution filter is what we need to use long term.

@tmat
Copy link
Member

tmat commented Jan 10, 2022

Would it be possible for source build to create an empty WindowsDesktop SDK package and build against that?

@MichaelSimons
Copy link
Member

Would it be possible for source build to create an empty WindowsDesktop SDK package and build against that?

This was mentioned in dotnet/installer#12500 (comment). Using a solution filter is a maintainability concern so avoiding them is preferable. On the other hand, avoiding the SDK reference in the first place is preferable if possible IMO as it is more obvious to what the behavior is instead of injecting an empty SDK during source-build.

@tmat
Copy link
Member

tmat commented Jan 10, 2022

avoiding the SDK reference in the first place is preferable if possible IMO as it is more obvious to what the behavior is instead of injecting an empty SDK during source-build.

I don't see a problem with injecting SDK that itself can specify ExcludeFromSourceBulid = true.
The benefit of the SDK excluding itself from source build is a centralized solution. No need to update all repos, maintain separate lists of projects and having two mechanisms for source build exclusion. Besides if we decided in future to include the SDK in source build it could be done by swapping the fake one with the real one.

@crummel
Copy link
Contributor

crummel commented Jan 11, 2022

Would it be possible for source build to create an empty WindowsDesktop SDK package and build against that?

I'm a bit concerned that a fake WindowsDesktop SDK could escape to the final source-built SDK output and cause problems for users trying to create a project with it. I think this would be worth following up on but the solution filter seems like the most straightforward way to avoid any potential issues for a fix right now.

@tmat
Copy link
Member

tmat commented Jan 11, 2022

the solution filter seems like the most straightforward way to avoid any potential issues for a fix right now.

Sure, but it adds debt. I'd prefer solution that does not add debt.

@lbussell
Copy link
Contributor Author

@tmat @sharwell for now we will take the solution filter change out of this PR and tackle the problem (probably with a different approach) in another PR.

eng/Versions.props Outdated Show resolved Hide resolved
@333fred
Copy link
Member

333fred commented Jan 20, 2022

Looks like BuildBoss will need to be updated: https://github.com/dotnet/roslyn/blob/main/src/Tools/BuildBoss/ProjectCheckerUtil.cs#L144

@lbussell
Copy link
Contributor Author

Looks like BuildBoss will need to be updated:

Is this something I need to do?

@333fred
Copy link
Member

333fred commented Jan 21, 2022

Is this something I need to do?

Yes, or the correctness build leg will not pass.

lbussell and others added 5 commits January 24, 2022 15:58
Pull request for applying this patch: dotnet#57159
Creating an apphost for a netcoreapp3.1 project uses the apphost pack as a
prebuilt. Stopping these projects from creating the apphost removes the prebuilt
for source-build.

See: dotnet#57233

PR: dotnet#57306
Some projects use Microsoft.NET.Sdk.WindowsDesktop sdk
which cannot be built using a boostrapped source-build
sdk, since WindowsDesktop is not supported.  These cannot
be ignored using ExcludeFromSourceBuild because the project
still needs to be loaded and the sdk cannot be found.

See dotnet#57342
@lbussell
Copy link
Contributor Author

@333fred, @sharwell do I need to make any other changes for this to be merged?

I have also solved the Windows Desktop SDK issue in source build without needing to change anything in Roslyn, so the solution filter approach is no longer necessary.

Comment on lines 266 to 276
<!--
SourceBuild will requires that all dependencies also be source buildable. We are referencing a
version of MSBuild that is not SourceBuild compatible, which makes our build incompatible. Since we only
use these dependencies as reference assemblies, we can opt them out of this behavior by having their
version variable be prefixed with `RefOnly`. This will allow us to reference these libraries and remain
Source Build compatible.
-->
<RefOnlyMicrosoftBuildVersion>$(RefOnlyMicrosoftBuildPackagesVersion)</RefOnlyMicrosoftBuildVersion>
<RefOnlyMicrosoftBuildFrameworkVersion>$(RefOnlyMicrosoftBuildPackagesVersion)</RefOnlyMicrosoftBuildFrameworkVersion>
<RefOnlyMicrosoftBuildRuntimeVersion>$(RefOnlyMicrosoftBuildPackagesVersion)</RefOnlyMicrosoftBuildRuntimeVersion>
<RefOnlyMicrosoftBuildTasksCoreVersion>$(RefOnlyMicrosoftBuildPackagesVersion)</RefOnlyMicrosoftBuildTasksCoreVersion>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

❔ Is there a reason this needs to move to the bottom of the file?

Comment on lines 277 to 280
<SourceBuildLiftedSystemCollectionsImmutableVersion Condition="'$(SourceBuildLiftedSystemCollectionsImmutableVersion)' == ''">$(SystemCollectionsImmutableVersion)</SourceBuildLiftedSystemCollectionsImmutableVersion>
<SourceBuildLiftedSystemReflectionMetadataVersion Condition="'$(SourceBuildLiftedSystemReflectionMetadataVersion)' == ''">$(SystemReflectionMetadataVersion)</SourceBuildLiftedSystemReflectionMetadataVersion>
<SourceBuildLiftedSystemRuntimeCompilerServicesUnsafeVersion Condition="'$(SourceBuildLiftedSystemRuntimeCompilerServicesUnsafeVersion)' == ''">$(SystemRuntimeCompilerServicesUnsafeVersion)</SourceBuildLiftedSystemRuntimeCompilerServicesUnsafeVersion>
<SourceBuildLiftedSystemTextEncodingCodePagesVersion Condition="'$(SourceBuildLiftedSystemTextEncodingCodePagesVersion)' == ''">$(SystemTextEncodingCodePagesVersion)</SourceBuildLiftedSystemTextEncodingCodePagesVersion>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

❓ What is SourceBuildLifted prefix? Why do none of the existing naming approaches work? A comment should be added for future readers.

Comment on lines 28 to 33
<ItemGroup Condition="'$(DotNetBuildFromSource)' == 'true'">
<PackageReference Include="System.Collections.Immutable" Version="$(SourceBuildLiftedSystemCollectionsImmutableVersion)" PrivateAssets="all" />
<PackageReference Include="System.Reflection.Metadata" Version="$(SourceBuildLiftedSystemReflectionMetadataVersion)" PrivateAssets="all" />
<PackageReference Include="System.Runtime.CompilerServices.Unsafe" Version="$(SourceBuildLiftedSystemRuntimeCompilerServicesUnsafeVersion)" PrivateAssets="all" />
<PackageReference Include="System.Text.Encoding.CodePages" Version="$(SourceBuildLiftedSystemTextEncodingCodePagesVersion)" PrivateAssets="all" />
</ItemGroup>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

❔ Why do these need to be explicit? Aren't they inherited from Microsoft.CodeAnalysis.Common?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The packages are inherited from Microsoft.CodeAnalysis.Common. However, roslyn builds before runtime in the source-build tarball, so we don't have access to the "current" versions of the packages to build against. The SourceBuildLifted- versions point to the previously source-built versions of the packages (i.e. the last build's output) so that we don't try to restore versions of these packages we don't have. That is also why the RefOnly- prefix is not applicable here.

I have just realized that a better solution for this might be to add the packages to SBRP, so I will get working on that and hopefully this change won't be necessary.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have added the necessary packages to SBRP and verified that the changes to CSharpSyntaxGenerator.csproj will no longer be necessary in the context of a full source-build tarball build and bootstrap. I also reverted those changes in this PR.

@lbussell
Copy link
Contributor Author

As far as I can tell these CI failures are consistent with the main branch. @333fred, @sharwell I'd like to get this merged soon.

@333fred 333fred enabled auto-merge (squash) March 10, 2022 19:18
@333fred
Copy link
Member

333fred commented Mar 10, 2022

/azp run roslyn-integration-ci

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@333fred
Copy link
Member

333fred commented Mar 10, 2022

/azp run roslyn-integration-corehost

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@333fred 333fred disabled auto-merge March 15, 2022 16:18
@333fred
Copy link
Member

333fred commented Mar 15, 2022

@sharwell I'm going ahead and overriding the one failing integration test.

@333fred 333fred merged commit 41e91ea into dotnet:main Mar 15, 2022
@ghost ghost added this to the Next milestone Mar 15, 2022
@allisonchou allisonchou modified the milestones: Next, 17.2.P3 Mar 28, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants