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

Creating a runtime pack artifacts directory in the libraries build #34662

Merged
merged 27 commits into from
Apr 16, 2020

Conversation

mdh1418
Copy link
Member

@mdh1418 mdh1418 commented Apr 7, 2020

This PR looks to create a runtime package in the artifacts/bin directory through the libraries build process for the purpose testing the mobile apps (iOS and Android).

The desired directory hierarchy is as follows

- lib-runtime-packs
    - data
    - runtimes
       - <RID>
          - lib
             - <netcoreapp5.0>
          - native
             - include
             - cross

@ghost
Copy link

ghost commented Apr 7, 2020

Tagging @ViktorHofer as an area owner

@mdh1418 mdh1418 requested a review from steveisok April 7, 2020 22:48
@steveisok steveisok changed the title [WIP] Creating Testing Package for mobile apps [WIP] Creating a runtime pack artifacts directory in the libraries build Apr 7, 2020
@steveisok
Copy link
Member

https://github.com/dotnet/runtime/blob/c8e70b38302b5e8e9f176b2cce7e75ed5c0e86af/src/libraries/Directory.Build.props#L315-L317

We should follow this model and set something like:

<BinPlaceTestRuntimePack Condition="'$(BuildTargetFramework)' == '$(NetCoreAppCurrent)' and '$(TargetOS)' == 'iOS'">true</BinPlaceTestRuntimePack>

@steveisok steveisok force-pushed the mdhwang/create_package_testing_folder branch from b17e35d to c3ba797 Compare April 10, 2020 19:50
src/libraries/Directory.Build.props Outdated Show resolved Hide resolved
src/libraries/Directory.Build.props Outdated Show resolved Hide resolved
src/libraries/Directory.Build.props Outdated Show resolved Hide resolved
src/libraries/Directory.Build.targets Show resolved Hide resolved
src/libraries/Native/native-binplace.proj Outdated Show resolved Hide resolved
src/libraries/pretest.proj Show resolved Hide resolved
@steveisok steveisok changed the title [WIP] Creating a runtime pack artifacts directory in the libraries build Creating a runtime pack artifacts directory in the libraries build Apr 13, 2020
@steveisok steveisok requested review from dagood and a team April 13, 2020 16:11
src/libraries/Directory.Build.props Outdated Show resolved Hide resolved
src/libraries/Native/native-binplace.proj Outdated Show resolved Hide resolved
src/libraries/pretest.proj Outdated Show resolved Hide resolved
src/libraries/pretest.proj Outdated Show resolved Hide resolved
src/libraries/restore/runtime/runtime.depproj Outdated Show resolved Hide resolved
@@ -2,6 +2,8 @@

<PropertyGroup>
<TraversalGlobalProperties>BuildAllProjects=true</TraversalGlobalProperties>
<NETCoreAppFrameworkIdentifier>.NETCoreApp</NETCoreAppFrameworkIdentifier>
<SharedFrameworkName>Microsoft.NETCore.App</SharedFrameworkName>
Copy link
Member

Choose a reason for hiding this comment

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

Share values with installer project tree? (Move to common ancestor?)

Copy link
Member Author

Choose a reason for hiding this comment

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

Where would be a good place to place these properties in <runtimeroot>/src/Directory.Build.props?
Is it a significant impact to performance/organization to move it up? I'm not familiar enough to know now if those properties have a chance of changing or differing between the directories in <runtimeroot>/src. If they were to differ later would it be better to have each specify their own properties?

Copy link
Member

Choose a reason for hiding this comment

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

It might not be worth it. My knee-jerk reaction is that duplicating code is what needs justification rather than reusing it, so just a quick suggestion.

Copy link
Member

Choose a reason for hiding this comment

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

Let's open an issue for this. Consolidate all places in props and targets where we use Microsoft.NETCore.App to a single shared property.

@mdh1418 mdh1418 force-pushed the mdhwang/create_package_testing_folder branch from 86833e0 to 3cafc0f Compare April 13, 2020 20:19
@mdh1418 mdh1418 force-pushed the mdhwang/create_package_testing_folder branch from 3ea474a to 0c650a3 Compare April 14, 2020 18:16
src/libraries/Native/native-binplace.proj Outdated Show resolved Hide resolved
src/libraries/Native/native-binplace.proj Outdated Show resolved Hide resolved
@@ -73,6 +70,20 @@
<Exec Command="chmod +x $(TestHostRootPath)%(DotnetExe.Filename)%(DotnetExe.Extension)" Condition="'$(TargetOS)' != 'Windows_NT' and '$(OS)' != 'Windows_NT'"/>
</Target>

<Target Name="SetupRuntimePackNative"
Copy link
Member

Choose a reason for hiding this comment

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

Given this target is specific to Mono should we include Mono in the target name?

Copy link
Member

Choose a reason for hiding this comment

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

there are going to be some differences with desktop mono, so I'd like to address them in a separate PR.

Copy link
Member

Choose a reason for hiding this comment

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

Do you have an issue tracking this work we can reference here?

Copy link
Member

Choose a reason for hiding this comment

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

@mdh1418 mdh1418 force-pushed the mdhwang/create_package_testing_folder branch from 5920234 to fe67b95 Compare April 15, 2020 15:10

<PropertyGroup>
<TraversalGlobalProperties>BuildAllProjects=true</TraversalGlobalProperties>
<NETCoreAppFrameworkIdentifier>$(NETCoreAppFrameworkIdentifier)</NETCoreAppFrameworkIdentifier>
Copy link
Member

Choose a reason for hiding this comment

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

Where is that property NETCoreAppFrameworkIdentifier defined in libraries? I don't see it anywhere. I was suggesting to use TargetFrameworkIdentifier which should contain the right value here but I might be wrong (if this project doesn't have a target framework set).

Copy link
Member

Choose a reason for hiding this comment

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

I would move the already defined property in installer into Configurations.props: https://github.com/dotnet/runtime/blob/master/eng/Configurations.props#L25 as it then will be available here as well.

Copy link
Member Author

Choose a reason for hiding this comment

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

Ah, I also didn't find it in libraries, but I saw that it was used in
<FrameworkListRootAttributes Include="TargetFrameworkIdentifier" Value="$(NETCoreAppFrameworkIdentifier)" />
and I accidentally picked the wrong one. changing to TargetFrameworkIdentifier

@mdh1418 mdh1418 force-pushed the mdhwang/create_package_testing_folder branch from 9dcf2f4 to ba6d021 Compare April 15, 2020 17:43
@@ -1,7 +1,11 @@
<Project Sdk="Microsoft.Build.Traversal">
<Import Project="Sdk.props" Sdk="Microsoft.DotNet.Build.Tasks.SharedFramework.Sdk" />
<Import Project="Sdk.targets" Sdk="Microsoft.DotNet.Build.Tasks.SharedFramework.Sdk" />
Copy link
Member

Choose a reason for hiding this comment

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

The targets are usually imported at the end of the file.

Copy link
Member

@safern safern left a comment

Choose a reason for hiding this comment

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

LGTM.

I left an additional comment. The Sdk.targets in pretest.proj should be imported at the end.

Also, let's open an issue to consolidate Microsoft.NETCore.App usage in our props and targets to share the same property.

I think it is worth opening an issue to cleanup the TargetOS == iOS or ... conditions to use TargetsMobile == true.

@@ -94,4 +91,7 @@
TargetFilePrefixes="ref/;runtimes/"
RootAttributes="@(FrameworkListRootAttributes)" />
</Target>

<Import Project="Sdk.props" Sdk="Microsoft.DotNet.Build.Tasks.SharedFramework.Sdk" />
Copy link
Member

Choose a reason for hiding this comment

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

The props go at the top of the file, the targets at the end 😄

Copy link
Member Author

Choose a reason for hiding this comment

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

ohh oops, thanks!

@mdh1418 mdh1418 force-pushed the mdhwang/create_package_testing_folder branch from 405b950 to 0d46895 Compare April 15, 2020 20:52
@steveisok steveisok merged commit c991d9b into dotnet:master Apr 16, 2020
@steveisok
Copy link
Member

The 2 remaining lanes seem stuck. All the lanes that this change impacts have passed, so merging.

@jaredpar
Copy link
Member

@steveisok

The 2 remaining lanes seem stuck.

This should not be a reason for merging. This should be a reason to ping the infra team to look into the issue.

In the last few days we've had a series of PRs merged without full validation. We're also running at 0% passing in CI. These are completely related items.

@akoeplinger
Copy link
Member

@jaredpar there was already a Teams thread going on about this and https://github.com/dotnet/core-eng/issues/9630 is tracking it.

@mdh1418 mdh1418 deleted the mdhwang/create_package_testing_folder branch April 17, 2020 15:37
@ghost ghost locked as resolved and limited conversation to collaborators Dec 9, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants