Skip to content

Use RID-layout for OS configurations in libraries #32451

Closed

Description

@ViktorHofer

We should switch to the well defined RID system away from our current defined OS configurations. This allows us to share the OS configuration matrix with installer and have just one central point where this is defined.

See

<Choose>
<When Condition="$(OutputRid.StartsWith('win'))">
<PropertyGroup>
<TargetsWindows>true</TargetsWindows>
</PropertyGroup>
</When>
<When Condition="$(OutputRid.StartsWith('osx'))">
<PropertyGroup>
<TargetsOSX>true</TargetsOSX>
<TargetsUnix>true</TargetsUnix>
</PropertyGroup>
</When>
<When Condition="$(OutputRid.StartsWith('debian'))">
<PropertyGroup>
<TargetsDebian>true</TargetsDebian>
<TargetsLinux>true</TargetsLinux>
<TargetsUnix>true</TargetsUnix>
</PropertyGroup>
</When>
<When Condition="$(OutputRid.StartsWith('ubuntu'))">
<PropertyGroup>
<TargetsUbuntu>true</TargetsUbuntu>
<TargetsLinux>true</TargetsLinux>
<TargetsUnix>true</TargetsUnix>
</PropertyGroup>
</When>
<When Condition="$(OutputRid.StartsWith('linuxmint'))">
<PropertyGroup>
<TargetsLinuxMint>true</TargetsLinuxMint>
<TargetsLinux>true</TargetsLinux>
<TargetsUnix>true</TargetsUnix>
</PropertyGroup>
</When>
<When Condition="$(OutputRid.StartsWith('rhel'))">
<PropertyGroup>
<TargetsRhel>true</TargetsRhel>
<TargetsLinux>true</TargetsLinux>
<TargetsUnix>true</TargetsUnix>
</PropertyGroup>
</When>
<When Condition="$(OutputRid.StartsWith('centos'))">
<PropertyGroup>
<TargetsCentos>true</TargetsCentos>
<TargetsLinux>true</TargetsLinux>
<TargetsUnix>true</TargetsUnix>
</PropertyGroup>
</When>
<When Condition="$(OutputRid.StartsWith('opensuse'))">
<PropertyGroup>
<TargetsOpensuse>true</TargetsOpensuse>
<TargetsLinux>true</TargetsLinux>
<TargetsUnix>true</TargetsUnix>
</PropertyGroup>
</When>
<When Condition="$(OutputRid.StartsWith('fedora'))">
<PropertyGroup>
<TargetsFedora>true</TargetsFedora>
<TargetsLinux>true</TargetsLinux>
<TargetsUnix>true</TargetsUnix>
</PropertyGroup>
</When>
<When Condition="$(OutputRid.StartsWith('oracle'))">
<PropertyGroup>
<TargetsOracle>true</TargetsOracle>
<TargetsLinux>true</TargetsLinux>
<TargetsUnix>true</TargetsUnix>
</PropertyGroup>
</When>
<When Condition="$(OutputRid.StartsWith('sles'))">
<PropertyGroup>
<TargetsSles>true</TargetsSles>
<TargetsLinux>true</TargetsLinux>
<TargetsUnix>true</TargetsUnix>
</PropertyGroup>
</When>
<Otherwise>
<PropertyGroup>
<TargetsLinux>true</TargetsLinux>
<TargetsUnix>true</TargetsUnix>
</PropertyGroup>
</Otherwise>
</Choose>
for how this is currently implemented in installers.

cc @Anipik @ericstj

Activity

  1. added this to the 5.0 milestone on Feb 18, 2020
  2. ericstj commented on Feb 18, 2020

    @ericstj
    Member

    Yep, @Anipik and I talked about this and agreed this would be good, to avoid the custom runtime.json. We didn't do it in initial pass because it would churn all the projects. Now is a good time to do it.

  3. removed
    untriagedNew issue has not been triaged by the area owner
    on Feb 18, 2020
  4. Anipik commented on May 27, 2020

    @Anipik
    Contributor

    Things that need to get done here. Taken from @jkotas comment #33315 (comment)

    • Changes that affect developer workflow should be synchronized using Infrastructure - Rollout (April 2020) #33821
    • For anything that gets renamed to use RIDs, make it follow RIDs 100%: i.e.: Debug\win-x64 instead of win.x64.Debug, linux-arm instead linux_arm, etc.
    • Renaming of the build output directories to use RIDs sounds reasonable. I agree with Eric that the .NET SDK uses RID based directory names, and so it sounds reasonable for consistency.
    • Can this be broken into multiple changes? E.g. Would it make sense to rename the output directories as the step 1, without changing the other stuff? Or can the renames in the CI config be separate change?
    • The non-RID names are used in number of places, and we won't be able to change all of them and achive 100% consistency. I do not think it makes sense to try to change as much as possible to use RID OS names. I think we should rather strike the right ballance, e.g. switch to use RIDs where there is a clear prior art (e.g. where the .NET SDK is using them) and leave the rest alone. For example, I do not think it makes sense to be changing the CMakeFiles to use RID OS names.
  5. ViktorHofer commented on Jun 9, 2020

    @ViktorHofer
    MemberAuthor

    @Anipik sounds like we can make incremental progress. Do you want to work on this and if yes, can you break down the necessary changes into individual tasks with a rough estimation? Would like to better understand the size of this task.

  6. Anipik commented on Jun 30, 2020

    @Anipik
    Contributor

    The Benefits vs cost scenario is not that great for this issue, so we put it on hold. But u can summarize the steps in detail

  7. modified the milestones: 5.0.0, Future on Jul 9, 2020
  8. removed their assignment
    on Nov 10, 2021
  9. ghost added
    in-prThere is an active PR which will close this issue when it is merged
    on Dec 30, 2022
  10. ghost removed
    in-prThere is an active PR which will close this issue when it is merged
    on Jan 2, 2023
  11. added a commit that references this issue on Jan 11, 2023
  12. ghost locked as resolved and limited conversation to collaborators on Feb 2, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions