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

Build ARM64 in main windows build job #38997

Merged
merged 26 commits into from Jan 8, 2022
Merged

Build ARM64 in main windows build job #38997

merged 26 commits into from Jan 8, 2022

Conversation

HaoK
Copy link
Member

@HaoK HaoK commented Dec 13, 2021

No description provided.

@HaoK
Copy link
Member Author

HaoK commented Dec 13, 2021

@dotnet/aspnet-build surprisingly this got as far as running tests, looks like the test x64 job is trying to run the arm64 tests as well, do you guys have any suggestions on what the best way for me to skip those tests in our windows x64 job?

@HaoK
Copy link
Member Author

HaoK commented Dec 14, 2021

/azp run

@azure-pipelines
Copy link

Azure Pipelines successfully started running 3 pipeline(s).

@HaoK
Copy link
Member Author

HaoK commented Dec 16, 2021

Well this is green and building now, so at least that's good, @dougbu so this is basically a continuation of #30680 which you had a fair bit of back and forth with Sourabh, before I start bringing some more of those changes forward (specifically the installer stuff), did the issues around a separate windows native build step get resolved, i.e.

Another possibility is to build the Windows native assets once in a separate job that all other Windows jobs depend on. That would take some care to upload all the relevant files to an AzDO artifact, download them, and place the files where managed projects and the installer builds expect them. Might get messy but would lengthen the build only slightly (for the job startup delay plus the download / file placement work).

Do we still need to do any major job surgery?

@dougbu
Copy link
Member

dougbu commented Dec 16, 2021

Do we still need to do any major job surgery?

I am not sure. Depends on how the bits are laid out when publishing the relevant tests. See our Teams conversation about possibilities and the need to see how the existing IIS tests work on Windows x64.

eng/build.ps1 Outdated Show resolved Hide resolved
eng/Build.props Show resolved Hide resolved
eng/Build.props Show resolved Hide resolved
eng/build.ps1 Outdated Show resolved Hide resolved
eng/scripts/vs.16.buildtools.json Outdated Show resolved Hide resolved
eng/targets/Cpp.Common.props Show resolved Hide resolved
@dougbu
Copy link
Member

dougbu commented Jan 4, 2022

@dougbu how much will your crossgen2 change mitigate that?

I don't know yet because I haven't experimented enough. Suspect it will slightly lengthen a single "All SharedFx" job, eliminating the new Build ARM64 job in the middle of our longest job in official builds. Is the new job responsible for a significant portion of the "10-15 minutes" you mentioned❔

@HaoK HaoK changed the title [WIP] ANCM: Build ARM64 in main windows build job Build ARM64 in main windows build job Jan 6, 2022
@HaoK HaoK marked this pull request as ready for review January 6, 2022 22:22
@Tratcher Tratcher removed their request for review January 6, 2022 22:26
@@ -23,6 +23,12 @@
<?define ProgramFilesFolder = ProgramFilesFolder ?>
<?define SystemFolder = SystemFolder ?>
<?define PlatformValue = Intel ?>
<?elseif $(var.Platform) ~= "arm64" ?>
Copy link
Member

Choose a reason for hiding this comment

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

Why ~= here as opposed to = above?

Copy link
Member Author

Choose a reason for hiding this comment

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

I think the difference is only case insensitive, I can switch it to equals to be consistent if you prefer, we seem to be inconsistent with ARM64/arm64 more than the other platforms though

@@ -43,26 +51,13 @@
<PropertyGroup Label="Configuration">
<VCToolsVersion />
</PropertyGroup>
<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Debug|Win32'" Label="Configuration">
<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Debug|Win32' OR '$(Configuration)|$(Platform)'=='Debug|x64' OR '$(Configuration)|$(Platform)'=='Debug|ARM64' OR '$(Configuration)|$(Platform)'=='Debug|Any CPU'" Label="Configuration">
Copy link
Member

Choose a reason for hiding this comment

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

What platforms are you rejecting here (i.e. could you just check Configuration = Debug?)

Copy link
Member Author

Choose a reason for hiding this comment

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

Do we have a regular ARM (not 64) bit platform that we build still? I believe that's the only one that's still split out from the main windows job on CI too

</Link>
</ItemDefinitionGroup>
<ItemDefinitionGroup Condition="'$(Configuration)|$(Platform)'=='Release|x64' OR '$(Configuration)|$(Platform)'=='Release|Any CPU'">
<ItemDefinitionGroup Condition="'$(Configuration)|$(Platform)'=='Release|Win32' OR '$(Configuration)|$(Platform)'=='Release|x64' OR '$(Configuration)|$(Platform)'=='Release|ARM64' OR '$(Configuration)|$(Platform)'=='Release|Any CPU'">
Copy link
Member

Choose a reason for hiding this comment

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

Thanks for removing the duplication here. We should probably do that in more of these proj files at some point (not required in this PR :))

<ClCompile>
<PrecompiledHeader>NotUsing</PrecompiledHeader>
<Optimization>Disabled</Optimization>
<PreprocessorDefinitions>X64;_DEBUG;_CONSOLE;%(PreprocessorDefinitions)</PreprocessorDefinitions>
Copy link
Member

Choose a reason for hiding this comment

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

Can you please confirm whether X64 is the right define to use for ARM64?

Copy link
Member Author

Choose a reason for hiding this comment

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

Will do, I'm guessing this should be arm64, but will address in a follow up PR

@@ -45,6 +45,7 @@
<ProjectReference Include="..\CustomAction\aspnetcoreCA.vcxproj">
<Name>aspnetcoreCA</Name>
<SetPlatform Condition="'$(Platform)' == 'x86'">Platform=Win32</SetPlatform>
<SetPlatform Condition="'$(Platform)' == 'arm64'">Platform=ARM64</SetPlatform>
Copy link
Member

Choose a reason for hiding this comment

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

Curious, why isn't this needed for x64?

Copy link
Member Author

Choose a reason for hiding this comment

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

Just guessing that x64 is the default perhaps, will leave this unresolved to follow up on this later

@adityamandaleeka
Copy link
Member

Left some comments, but this looks good otherwise as a first cut at getting ARM64 enabled in our builds. Thanks @HaoK!

@HaoK HaoK enabled auto-merge (squash) January 7, 2022 23:05
@HaoK HaoK merged commit c8c1700 into main Jan 8, 2022
@HaoK HaoK deleted the haok/arm branch January 8, 2022 00:15
@ghost ghost added this to the 7.0-preview1 milestone Jan 8, 2022
@amcasey amcasey added area-networking Includes servers, yarp, json patch, bedrock, websockets, http client factory, and http abstractions and removed area-runtime labels Jun 6, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-networking Includes servers, yarp, json patch, bedrock, websockets, http client factory, and http abstractions
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants