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

[dev innerloop] build runtime tests without CoreCLR #58266

Open
6 of 9 tasks
lambdageek opened this issue Aug 27, 2021 · 12 comments
Open
6 of 9 tasks

[dev innerloop] build runtime tests without CoreCLR #58266

lambdageek opened this issue Aug 27, 2021 · 12 comments
Labels
area-Infrastructure Bottom Up Work Not part of a theme, epic, or user story enhancement Product code improvement that does NOT require public API changes/additions tracking This issue is tracking the completion of other related issues. wishlist Issue we would like to prioritize, but we can't commit we will get to it yet
Milestone

Comments

@lambdageek
Copy link
Member

lambdageek commented Aug 27, 2021

Make it possible to build and run the tests using Mono, without building all of CoreCLR. In principle the runtime tests infrastructure only needs corerun (and ilasm - but I think that can already be built from a separate subset)

@dotnet-issue-labeler dotnet-issue-labeler bot added area-Infrastructure-coreclr untriaged New issue has not been triaged by the area owner labels Aug 27, 2021
@ghost
Copy link

ghost commented Aug 27, 2021

Tagging subscribers to this area: @hoyosjs
See info in area-owners.md if you want to be subscribed.

Issue Details

Make it possible to build and run the tests using Mono, without building all of CoreCLR. In principle the runtime tests infrastructure only needs corerun

  • Build tests against each RuntimeFlavor's System.Private.CoreLib (PR: Don't build ReferenceSystemPrivateCoreLib tests with Mono #58232)
  • Build corerun without building coreclr
    • Maybe move it to src/native/hosts/
  • build the Tests/Core_Root directory layout directly from artifacts/bin/mono, without a separate mono patching step

Stretch goal:

  • For mobile and WASM don't depend on corerun at all
Author: lambdageek
Assignees: -
Labels:

area-Infrastructure-coreclr, untriaged

Milestone: -

@lambdageek lambdageek added area-Infrastructure Bottom Up Work Not part of a theme, epic, or user story enhancement Product code improvement that does NOT require public API changes/additions tracking This issue is tracking the completion of other related issues. and removed area-Infrastructure-coreclr labels Aug 27, 2021
@ghost
Copy link

ghost commented Aug 27, 2021

Tagging subscribers to this area: @dotnet/runtime-infrastructure
See info in area-owners.md if you want to be subscribed.

Issue Details

Make it possible to build and run the tests using Mono, without building all of CoreCLR. In principle the runtime tests infrastructure only needs corerun

  • Build tests against each RuntimeFlavor's System.Private.CoreLib (PR: Don't build ReferenceSystemPrivateCoreLib tests with Mono #58232)
  • Build corerun without building coreclr
    • Maybe move it to src/native/hosts/
  • build the Tests/Core_Root directory layout directly from artifacts/bin/mono, without a separate mono patching step

Stretch goal:

  • For mobile and WASM don't depend on corerun at all
Author: lambdageek
Assignees: -
Labels:

enhancement, area-Infrastructure, untriaged, tracking, Bottom Up Work

Milestone: -

@lambdageek lambdageek added the wishlist Issue we would like to prioritize, but we can't commit we will get to it yet label Aug 27, 2021
@lambdageek
Copy link
Member Author

This could also benefit the CI pipelines although actually cleaning up the CI dependencies could be done separately after the initial work of just teasing apart the build dependencies is completed.

@am11
Copy link
Member

am11 commented Aug 27, 2021

@lambdageek, a side question (in case you know it offhand 🙂), do we have any direct dev innerloop script for mono that {re}builds 'just' the native components and entirely skips .NET SDK / MSBuild? e.g. in case of non-mono subsets, we can use:

OSName=banana
OSArch=apricotarch
ROOTFS_DIR=/crossrootfs/$OSArch
export ROOTFS_DIR

# coreclr
/runtime/src/coreclr/build-runtime.sh -skipgenerateversion -skipmanaged -nopgooptimize \
    -os $OSName -cross -$OSArch

# libraries/native
/runtime/src/libraries/Native/build-native.sh -skipgenerateversion -skipmanaged -os $OSName \
    -cross -$OSArch

# corehost (dotnet(1) etc.) is currently a bit mouthful
/runtime/src/native/corehost/build.sh -skipmanaged -skipgenerateversion -os $OSName -cross -$OSArch \
    -policyver 0.0.1-dev -fxrver 0.0.1-dev -hostver 0.0.1-dev -apphostver 0.0.1-dev \
    -commithash $(git -C /runtime rev-parse HEAD)

(these are also useful to build stage 0 on new platforms natively, where .NET SDK is not yet available and crossbuild is not yet configured)

@lambdageek
Copy link
Member Author

@lambdageek, a side question (in case you know it offhand 🙂), do we have any direct dev innerloop script for mono that {re}builds 'just' the native components and entirely skips .NET SDK / MSBuild?

I think @vargaz just runs cmake directly. I don't think we have any scripts to simplify it.

lambdageek added a commit that referenced this issue Aug 30, 2021
New tests that extend the System.Private.CoreLib API should add to the ref assemblies in src/libraries and the tests themselves should be library tests.

Updated the workflow doc: the Clr.Native subset is all that is need if we're interested in testing Mono.

Contributes to #58266

* [tests] Use RuntimeFlavor to build ReferenceSystemPrivateCoreLib tests

   When building tests that reference System.Private.CoreLib, use the one from the specified RuntimeFlavor (or fall back to coreclr if it's unset - although src/tests/build.sh sets it always)

* Update docs: We only need to build the Clr.Native subset if we're interested in testing Mono.

* flavor the pipelines to build the runtime-specific System.Private.CoreLib for the runtime tests.

* Don't build ReferenceSystemPrivateCoreLib tests with Mono

   We should avoid adding new ReferenceSystemPrivateCoreLib tests
@ViktorHofer ViktorHofer added this to the 7.0.0 milestone Sep 3, 2021
@ViktorHofer ViktorHofer removed the untriaged New issue has not been triaged by the area owner label Sep 3, 2021
@marek-safar
Copy link
Contributor

@trylek is this something you are looking into?

@trylek
Copy link
Member

trylek commented Dec 8, 2021

Not directly right now - the test refactoring we're working on with Jeremy might simplify overall testing infrastructure including Mono though. For this particular change, yesterday I reviewed Nathan's PR 62500 (see link above) that seems to be contributing to the efforts tracked by this issue.

@lambdageek
Copy link
Member Author

For mobile and WASM don't depend on corerun at all

@naricc I think this is incidentally fixed by #62652, right? Or are there still some coreclr artifacts that are used by the mobile runtime testing CI legs?

@naricc
Copy link
Contributor

naricc commented Dec 14, 2021

@lambdageek Wasm never depended on coreclr in the first place, since it was using the global-build-job.yml. I don't think android and iOS did either, but I am looking at the runtime templates and it is hard to make out. But yes, if they did it should be fixed now.

It probably makes sense to move all mono runs to use global-build-job.

@lambdageek
Copy link
Member Author

It probably makes sense to move all mono runs to use global-build-job.

I don't know any of the consequences of that, but it sounds good, and if you think it's a good idea, go for it. 😁

@safern
Copy link
Member

safern commented Dec 14, 2021

It probably makes sense to move all mono runs to use global-build-job.

We have #45521 to track that work.

@SamMonoRT SamMonoRT modified the milestones: 7.0.0, 8.0.0 Aug 10, 2022
@SamMonoRT
Copy link
Member

@naricc -- Assigning this to you and moving to 8.0.0 I believe the 3 remaining items are related to your open PR.

@SamMonoRT SamMonoRT assigned jandupej and unassigned naricc Mar 13, 2023
@jandupej jandupej modified the milestones: 8.0.0, Future May 19, 2023
@SamMonoRT SamMonoRT assigned fanyang-mono and unassigned jandupej Oct 25, 2023
@fanyang-mono fanyang-mono removed their assignment Jul 26, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-Infrastructure Bottom Up Work Not part of a theme, epic, or user story enhancement Product code improvement that does NOT require public API changes/additions tracking This issue is tracking the completion of other related issues. wishlist Issue we would like to prioritize, but we can't commit we will get to it yet
Projects
Status: No status
Development

No branches or pull requests

10 participants