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.

Sign up for GitHub

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

Jump to bottom

Broke ability to use RuntimeFlavor in local builds #23800

Closed
jaredpar opened this issue Jan 31, 2020 · 2 comments
Closed

Broke ability to use RuntimeFlavor in local builds #23800

jaredpar opened this issue Jan 31, 2020 · 2 comments
Assignees
@jaredpar
Labels
area-Infrastructure

Comments

@jaredpar
Copy link
Member

Execute the following command:

.\build.cmd /p:RuntimeFlavor=Mono

Will lead to the following error:

P:\runtime\eng\liveBuilds.targets(91,5): error : The CoreCLR artifacts path does not exist 'P:\runtime\artifacts\bin\coreclr\Windows_NT.x64.netcoreapp5.0-Windows_NT-Debug'. The CoreCLR subset category must be built before building this project. [P:\runtime\src\libraries\System.Reflection.Primitives\src\System.Reflection.Primitives.csproj]

There are two issues at hand here that need to be addressed:

  1. The runtime configuration logic in our build files is not properly accounting for times when $(Configuration) is set but $(ConfigurationGroup) is not.
  2. There are still places in the build logic that do not properly condition grabbing runtime files based on the chosen runtime

This was a regression introduced with #2093. That means we have the following chain of sadness: PR #1934 leads to runtime config breaks leads to #2093 which leads to this.
@jaredpar jaredpar self-assigned this Jan 31, 2020
jaredpar added a commit that referenced this issue Jan 31, 2020
@jaredpar
Account for missing ConfigurationGroup
adf63e0 
Our logic for setting the CoreCLR and Mono runtime configurations didn't
properly account for cases where only `$(Configuration)` was passed down
as a build property. It expects that both `$(Configuration)` and
`$(ConfigurationGroup)` are passed down as a pair.

This change guards against us accidentially setting the runtime
configuration to the current library definition of configuration which
is more like a target framework than Debug or Release.

Related to #23800
jaredpar added a commit that referenced this issue Jan 31, 2020
@jaredpar
Fix handling of missing ConfigurationGroup property (#24077)
8f0d191 
* Account for missing ConfigurationGroup

Our logic for setting the CoreCLR and Mono runtime configurations didn't
properly account for cases where only `$(Configuration)` was passed down
as a build property. It expects that both `$(Configuration)` and
`$(ConfigurationGroup)` are passed down as a pair.

This change guards against us accidentially setting the runtime
configuration to the current library definition of configuration which
is more like a target framework than Debug or Release.

Related to #23800

* Test for missing ConfigurationGroup
@akoeplinger
Copy link
Member

Is there still something to be done after #24077? seems to be working here.

@jaredpar
Copy link
Member Author

jaredpar commented Feb 3, 2020

@akoeplinger

I was keeping it open for the second part of the issue

There are still places in the build logic that do not properly condition grabbing runtime files based on the chosen runtime

That's a separate issue. Can track separately.

@jaredpar jaredpar closed this as completed Feb 3, 2020
@ghost ghost locked as resolved and limited conversation to collaborators Dec 10, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees

@jaredpar jaredpar

Labels
area-Infrastructure
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@jaredpar @akoeplinger