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
Enable source-build with arcade #126
Enable source-build with arcade #126
Conversation
This enables 'source-build', which makes it easier to build the entire shipping .NET SDK from source. This is the first and second step of arcade-powered-source-build: https://github.com/dotnet/source-build/blob/master/Documentation/planning/arcade-powered-source-build/README.md See dotnet/sourcelink#692 for a similar PR, that this is based on. Aside from arcade-specific changes, it also makes all `.sh` files executable to make this build under Linux/macOS. The rename from LICENSE to LICENSE.txt is a workaround for NuGet/Home#7601.
AfterTargets="PrepareInnerSourceBuildRepoRoot"> | ||
|
||
<ItemGroup> | ||
<SourceBuildPatchFile Include="$(RepositoryEngineeringDir)source-build-patches\*.patch" /> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
RepositoryEngineeringDir
refers to the original/outer repo. This can break badly, right? Is there something that that points to the eng
dir of the inner repo?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can't think of anything that would happen differently depending on whether this uses the files in the outer repo in the inner repo. The outer and inner repo are always the same source code. The PrepareInnerSourceBuildRepoRoot
target only executes in the context of the outer repo, so the patches will always be there.
I think there is a quirk where if the outer repo has some unstaged file additions, they don't transfer over properly into the inner repo. (This is based on git stash
behavior.) But that's just dev workflow, which isn't a priority for ArPow right now--and it's easy to just stage the files to work around this. (Edit: Filed dotnet/source-build#2047 to make this more visible, though, now that I'm thinking about it.)
There wouldn't be any harm in adding a prop in dotnet/arcade to refer to the inner eng dir, though: https://github.com/dotnet/arcade/blob/e4ab5cb034f0c40b4a52a5952b20809daaa2f39b/src/Microsoft.DotNet.Arcade.Sdk/tools/SourceBuild/SourceBuildArcade.targets#L19-L20
Not quite yet, @crummel is on it: dotnet/source-build#2028. |
I'll review this tomorrow morning, CET time. |
This enables 'source-build', which makes it easier to build the entire shipping .NET SDK from source.
This is the first and second step of arcade-powered-source-build: https://github.com/dotnet/source-build/blob/master/Documentation/planning/arcade-powered-source-build/README.md
See dotnet/sourcelink#692 for a similar PR, that this is based on.
Aside from arcade-specific changes, it also makes all
.sh
files executable to make this build under Linux/macOS.The rename from
LICENSE
toLICENSE.txt
is a workaround for NuGet/Home#7601.