-
Notifications
You must be signed in to change notification settings - Fork 5k
Reference leaf's src from test project #42826
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
Conversation
f90d65d
to
d296160
Compare
Tagging subscribers to this area: @safern, @ViktorHofer |
3406ed7
to
2459897
Compare
src/libraries/Microsoft.CSharp/tests/Microsoft.CSharp.Tests.csproj
Outdated
Show resolved
Hide resolved
src/libraries/System.Diagnostics.Debug/tests/System.Diagnostics.Debug.Tests.csproj
Show resolved
Hide resolved
src/libraries/System.Diagnostics.Debug/tests/System.Diagnostics.Debug.Tests.csproj
Outdated
Show resolved
Hide resolved
8a9c530
to
982ba10
Compare
982ba10
to
c219229
Compare
/azp run runtime |
Azure Pipelines successfully started running 1 pipeline(s). |
@ericstj the PR is ready, do you have some more feedback? We already have the problem that we need to keep src and test project's targetframeworks in sync, today. We could either add validation for that or think of better ways to reference src from test that would not involve these additional test builds. |
See my comment in the issue. I think we're making these references very special already, it doesn't hurt to make them a bit more special. Were you able to look into incremental build for tests and make sure that no changes to src/ref still result in a reasonably fast inner-loop build for tests? I would think that "reasonable" here means we aren't doubling the time to build a test project when there are no changes to the src/ref. |
@@ -2,7 +2,7 @@ | |||
<PropertyGroup> | |||
<AllowUnsafeBlocks>true</AllowUnsafeBlocks> | |||
<StringResourcesPath>../../src/Resources/Strings.resx</StringResourcesPath> | |||
<TargetFrameworks>$(NetCoreAppCurrent)</TargetFrameworks> | |||
<TargetFrameworks>$(NetCoreAppCurrent)-Windows_NT;$(NetCoreAppCurrent)-Linux;$(NetCoreAppCurrent)-Browser;$(NetCoreAppCurrent)-OSX;$(NetCoreAppCurrent)-iOS;$(NetCoreAppCurrent)-tvOS;$(NetCoreAppCurrent)-FreeBSD</TargetFrameworks> | |||
<IgnoreForCI Condition="'$(TargetOS)' == 'Browser'">true</IgnoreForCI> |
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.
@ericstj with what we discussed, how would I express that Browser
is not compatible when using NetCoreAppCurrent
? In such cases I think I would still need to mimic the the src's configurations and remove Browser.
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.
This thing wasn't compiling for Browser before, I would expect that condition to work the same way.
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.
Why do you think this project wasn't compiling for Browser before locally?
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.
Because TargetFrameworks was $(NetCoreAppCurrent)
not $(NetCoreAppCurrent)-Browser
so this would build during the browser vertical, but compile for $(NetCoreAppCurrent)
not $(NetCoreAppCurrent)-Browser
. I'm missing what changes here would require us to target $(NetCoreAppCurrent)-Browser
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.
What I'm trying to achieve here is to avoid the unnecessary Browser build completely and remove the IgnoreForCI
proeprty but I can't express that with $(NetCoreAppCurrent)
as the TFM as that is compatible with Browser.
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.
jep, from above:
In such cases I think I would still need to mimic the the src's configurations and remove Browser.
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.
Can you use a placeholder TargetFramework? $(NetCoreAppCurrent);_$(NetCoreAppCurrent)-Browser
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.
No, we removed the concept and implementation of placeholders in the configuration system as it caused issues during restore and because it wasn't necessary anymore with ProjectReferences in OOBs.
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 see, then an exclusion?
runtime/src/libraries/tests.proj
Line 109 in 40b8e3d
<ItemGroup Condition="'$(TargetOS)' == 'Browser' and '$(RunDisabledWasmTests)' != 'true'"> |
IMHO we should try to minimize the way we disable tests. My preference would be some indication in the source, so that we get reporting over the number of tests that are disabled and still test what happens when code that uses the type is JIT'ed.
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 see, then an exclusion?
We use project exclusions for temporary issues only... Similar to ActiveIssue in code. This doesn't solve exactly what I was asking for, which is a mechanism to not compile the Browser configuration at all which would still happen when you invoke the project directly.
Should this be part of the monthly rollout and/or be accompanied with some docs that tell folks how to speed up the build if they don’t change src/ref? |
Merging this as part of the monthly rollout shouldn't be necessary. There isn't a change that requires developers to change their workflow. Developers won't need to manually rebuild the source project anymore but that doesn't mean that the existing process wouldn't work anymore. On my 2 core notebook I didn't notice any perf hit as most inbox projects don't use P2Ps yet and hence there aren't any transitive P2Ps (not even the ref project as that's only referenced if it isn't built yet). When/If we go down the rabbit hole and use P2Ps everywhere, we should definitely document the |
I see I hadn't realized that we didn't always rebuild ref. Makes sense. I'm OK with this. |
Build is failing with:
|
<Private>false</Private> | ||
<ReferenceOutputAssembly Condition="!$(NetCoreAppLibraryNoReference.Contains('%(Filename);')) and | ||
'%(ProjectReference.SkipUseReferenceAssembly)' != 'true'">false</ReferenceOutputAssembly> | ||
<ReferringTargetFramework Condition="'$(TargetFrameworkSuffix)' == ''">$(TargetFramework)-$(TargetOS)</ReferringTargetFramework> |
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.
This isn't handling the case when referencing project is a less specific RID than referenced. Nor does it handle the case where TFM is less specific (though we may not use this any more).
<ReferringTargetFramework Condition="'$(TargetFrameworkSuffix)' == ''">$(TargetFramework)-$(TargetOS)</ReferringTargetFramework> | |
<ReferringTargetFramework>$(BuildTargetFramework)-$(TargetOS)</ReferringTargetFramework> |
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.
Nor does it handle the case where TFM is less specific (though we may not use this any more).
Right, we don't care about that anymore as test projects targeting ie .NETStandard aren't supported.
This isn't handling the case when referencing project is a less specific RID than referenced.
Right, but tbh I don't understand your proposal below. BuildTargetFramework
is the same as TargetFramework
if the project is invoked individually (outside of a root build).
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.
This isn't handling the case when referencing project is a less specific RID than referenced.
I thought about this a bit more and I'm unsure how we would make this ever work. I'm ok with supporting a rid-less TargetFramework
for the sake of less configurations but I can't get my head around how we would support less specific RIDs without loosing the ability in test projects to not support some configurations.
Maybe we should chat about this offline as this confuses me... In the meantime I adjusted the two affected test projects for the sake of getting this in.
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.
Binplacing will still make the right decision. The purpose of the project reference here is just to make a convenient build. That convenient build shouldn't really be chosen based on the test's configuration, but what the vertical build would have put in the test runtime, which is decided by the things I suggested.
I have absolutely no idea why this is failing on Browser and iOS :( cc @akoeplinger |
For System.Runtime.Tests in Browser I can see this:
Probably System.Collections is no longer referenced? |
Fixes #42815
Unblocks #42814