Replacing OSGroup with TargetOS for coreclr, libraries and installer (d…

…otnet#32833)

* Remove OSGroup from coreclr and corefx

* remove from installer

* fixing coreclr tests

* Some documentation changes

Co-Authored-By: Viktor Hofer <[email protected]>

* moving buildos calculation to config.props

* BuildOS -> TargetOS

* remove osgroup suffix

* removing comment and correcting typo

* dotnet msbuild -> dotnet build at relevant places in docs

* moving more properties to configuration.props

* refactoring properties

* moving TargetArchitecture property to loveBuildd.Targets

* adding configuration.props to signing

* Fix installer build

* BuildOS -> Target os and removing slash

Co-authored-by: Viktor Hofer <[email protected]>

docs/coding-guidelines/interop-guidelines.md

@@ -120,21 +120,10 @@ internal static partial class Interop // contents of Common\src\Interop\Windows\
 ```
 
 ### Build System
-When building dotnet/runtime, we use the "OSGroup" property to control what target platform we are building for. The valid values for this property are Windows_NT (which is the default value from MSBuild when running on Windows), Linux and OSX.
-
-The build system sets a few MSBuild properties, depending on the OSGroup setting:
-
-* TargetsWindows
-* TargetsLinux
-* TargetsOSX
-* TargetsUnix
-
-TargetsUnix is true for both OSX and Linux builds and can be used to include code that can be used on both Linux and OSX (e.g. it is written against a POSIX API that is present on both platforms).
-
-You should not test the value of the OSGroup property directly, instead use one of the values above.
+When building dotnet/runtime, we use the "TargetOS" property to control what target platform we are building for. The valid values for this property are Windows_NT (which is the default value from MSBuild when running on Windows), Linux and OSX.
 
 #### Project Files
-Whenever possible, a single .csproj should be used per assembly, spanning all target platforms, e.g. System.Console.csproj includes conditional entries for when targeting Windows vs when targeting Linux. A property can be passed to dotnet build to control which flavor is built, e.g. `dotnet build /p:OSGroup=OSX System.Console.csproj`.
+Whenever possible, a single .csproj should be used per assembly, spanning all target platforms, e.g. System.Console.csproj includes conditional entries for when targeting Windows vs when targeting Linux. A property can be passed to dotnet build to control which flavor is built, e.g. `dotnet build /p:TargetOS=OSX System.Console.csproj`.
 
 ### Constants
 - Wherever possible, constants should be defined as "const". Only if the data type doesn't support this (e.g. IntPtr) should they instead be static readonly fields.

docs/coding-guidelines/project-guidelines.md

@@ -6,7 +6,7 @@ once before you can iterate and work on a given library project.
 
 - Setup tools (currently done in restore in build.cmd/sh)
 - Restore external dependencies
- - CoreCLR - Copy to `bin\runtime\$(BuildTargetFramework)-$(OSGroup)-$(Configuration)-$(ArchGroup)`
+ - CoreCLR - Copy to `bin\runtime\$(BuildTargetFramework)-$(TargetOS)-$(Configuration)-$(ArchGroup)`
  - Netstandard Library - Copy to `bin\ref\netstandard2.0`
  - NetFx targeting pack - Copy to `bin\ref\net472`
 - Build targeting pack
@@ -29,7 +29,7 @@ Below is a list of all the various options we pivot the project builds on:
 The following are the properties associated with each build pivot
 
 - `$(BuildTargetFramework) -> netstandard2.1 | netcoreapp5.0 | net472`
-- `$(OSGroup) -> Windows | Linux | OSX | FreeBSD | [defaults to running OS when empty]`
+- `$(TargetOS) -> Windows | Linux | OSX | FreeBSD | [defaults to running OS when empty]`
 - `$(Configuration) -> Release | [defaults to Debug when empty]`
 - `$(ArchGroup) - x86 | x64 | arm | arm64 | [defaults to x64 when empty]`
 - `$(RuntimeOS) - win7 | osx10.10 | ubuntu.14.04 | [any other RID OS+version] | [defaults to running OS when empty]` See [RIDs](https://github.com/dotnet/runtime/tree/master/src/libraries/pkg/Microsoft.NETCore.Platforms) for more info.
@@ -45,7 +45,7 @@ Each project will define a set of supported TargetFrameworks
 <PropertyGroup>
 ```
 
-- `$(BuildSettings) -> $(BuildTargetFramework)[-$(OSGroup)][-$(Configuration)][-$(ArchGroup)]`
+- `$(BuildSettings) -> $(BuildTargetFramework)[-$(TargetOS)][-$(Configuration)][-$(ArchGroup)]`
  - Note this property should be file path safe and thus can be used in file names or directories that need to a unique path for a project configuration.
  - The only required Build Settings value is the `$(BuildTargetFramework)` the others are optional.
 
@@ -79,18 +79,18 @@ When we have a project that has a `netstandard2.0` target framework that means t
 
 ## Options for building
 
-A full or individual project build is centered around BuildTargetFramework, OSGroup, Configuration and ArchGroup.
+A full or individual project build is centered around BuildTargetFramework, TargetOS, Configuration and ArchGroup.
 
-1. `$(BuildTargetFramework), $(OSGroup), $(Configuration), $(ArchGroup)` can individually be passed in to change the default values.
-2. If nothing is passed to the build then we will default value of these properties from the environment. Example: `netcoreapp5.0-[OSGroup Running On]-Debug-x64`.
+1. `$(BuildTargetFramework), $(TargetOS), $(Configuration), $(ArchGroup)` can individually be passed in to change the default values.
+2. If nothing is passed to the build then we will default value of these properties from the environment. Example: `netcoreapp5.0-[TargetOS Running On]-Debug-x64`.
 3. While Building an individual project from the VS, we build the project for all latest netcoreapp target frameworks.
 
 We also have `RuntimeOS` which can be passed to customize the specific OS and version needed for native package builds as well as package restoration. If not passed it will default based on the OS you are running on.
 
 Any of the mentioned properties can be set via `/p:<Property>=<Value>` at the command line. When building using our run tool or any of the wrapper scripts around it (i.e. build.cmd) a number of these properties have aliases which make them easier to pass (run build.cmd/sh -? for the aliases).
 
 ## Selecting the correct BuildSettings
-When building an individual project the `BuildTargetFramework` and `OSGroup` will be used to select the closest matching TargetFramework listed in the projects `TargetFrameworks` property. The rules used to select the targetFramework will consider compatible target frameworks and OS fallbacks.
+When building an individual project the `BuildTargetFramework` and `TargetOS` will be used to select the closest matching TargetFramework listed in the projects `TargetFrameworks` property. The rules used to select the targetFramework will consider compatible target frameworks and OS fallbacks.
 
 ## Supported full build settings
 - .NET Core latest on current OS (default) -> `$(NetCoreAppCurrent)-[RunningOS]`
@@ -130,7 +130,7 @@ The output for the src product build will be a flat runtime folder into the foll
 `bin\runtime\$(BuildSettings)`
 
 Note: The `BuildSettings` is a global property and not the project setting because we need all projects to output to the same runtime directory no matter which compatible target framework we select and build the project with. 
-```<BuildSettings>$(BuildTargetFramework)-$(OSGroup)-(Configuration)-(ArchGroup)</BuildSettings>``` 
+```<BuildSettings>$(BuildTargetFramework)-$(TargetOS)-(Configuration)-(ArchGroup)</BuildSettings>``` 
 
 ## pkg
 In the pkg directory for the library there should be only **one** `.pkgproj` for the primary package for the library. If the library has platform-specific implementations those should be split into platform specific projects in a subfolder for each platform. (see [Package projects](./package-projects.md))
@@ -171,7 +171,7 @@ Each source file should use the following guidelines
 - The source code file should be named `<class>.cs` and should be placed in a directory structure that matches its namespace relative to its project directory. Ex. `System\IO\Stream.cs`
 - Larger nested classes should be factored out into their own source files using a partial class and the file name should be `<class>.<nested class>.cs`.
 - Classes that are forked based on BuildSettings should have file names `<class>.<BuildSettings>.cs`.
- - Where `<BuildSettings>` is one of `$(OSGroup)`, `$(TargetFramework)`, `$(Configuration)`, or `$(Platform)`, matching exactly by case to ensure consistency.
+ - Where `<BuildSettings>` is one of `$(TargetOS)`, `$(TargetFramework)`, `$(Configuration)`, or `$(Platform)`, matching exactly by case to ensure consistency.
 - Classes that are forked based on a feature set should have file names `<class>.<feature>.cs`.
  - Where `<feature>` is the name of something that causes a fork in code that isn't a single configuration. Examples:
   - `.CoreCLR.cs` - implementation specific to CoreCLR runtime
@@ -181,6 +181,6 @@ Each source file should use the following guidelines
 ## Define naming convention
 
 As mentioned in [Conventions for forked code](#conventions-for-forked-code) `#ifdef`ing the code is the last resort as it makes code harder to maintain overtime. If we do need to use `#ifdef`'s we should use the following conventions:
-- Defines based on conventions should be one of `$(OSGroup)`, `$(TargetFramework)`, `$(Configuration)`, or `$(Platform)`, matching exactly by case to ensure consistency.
+- Defines based on conventions should be one of `$(TargetOS)`, `$(TargetFramework)`, `$(Configuration)`, or `$(Platform)`, matching exactly by case to ensure consistency.
  - Examples: `<DefineConstants>$(DefineConstants);net46</DefineConstants>`
 - Defines based on convention should match the pattern `FEATURE_<feature name>`. These can unique to a given library project or potentially shared (via name) across multiple projects.

docs/workflow/building/coreclr/cross-building.md

@@ -99,7 +99,7 @@ Cross compiling CoreCLR
 
     ~/runtime/ $ ROOTFS_DIR=/home/arm ./build.sh arm debug verbose cross
 
-As usual, the resulting binaries will be found in `artifacts/bin/coreclr/BuildOS.BuildArch.BuildType/`
+As usual, the resulting binaries will be found in `artifacts/bin/coreclr/TargetOS.BuildArch.BuildType/`
 
 Cross compiling CoreCLR for Other VFP configurations
 ----------------------------------------------------------
@@ -137,7 +137,7 @@ To build System.Private.CoreLib for Linux, run the following command:
     lgs@ubuntu ~/git/coreclr/ $ build.sh arm debug verbose
 ```
 
-The output is at artifacts/Product/<BuildOS>.arm.Debug/System.Private.CoreLib.dll.
+The output is at artifacts/Product/<TargetOS>.arm.Debug/System.Private.CoreLib.dll.
 
 ```
     lgs@ubuntu ~/git/coreclr/ $ file ./artifacts/Product/Linux.arm.Debug/System.Private.CoreLib.dll

docs/workflow/building/libraries/README.md

@@ -72,10 +72,10 @@ The above commands will give you libraries in "debug" configuration (the default
 
 The libraries build has two logical components, the native build which produces the "shims" (which provide a stable interface between the OS and managed code) and the managed build which produces the MSIL code and NuGet packages that make up Libraries. The commands above will build both.
 
-The build settings (BuildTargetFramework, OSGroup, Configuration, Architecture) are generally defaulted based on where you are building (i.e. which OS or which architecture) but we have a few shortcuts for the individual properties that can be passed to the build scripts:
+The build settings (BuildTargetFramework, TargetOS, Configuration, Architecture) are generally defaulted based on where you are building (i.e. which OS or which architecture) but we have a few shortcuts for the individual properties that can be passed to the build scripts:
 
 - `-framework|-f` identifies the target framework for the build. Possible values include `netcoreapp5.0` (currently the latest .NET Core version) or `net472`. (msbuild property `BuildTargetFramework`)
-- `-os` identifies the OS for the build. It defaults to the OS you are running on but possible values include `Windows_NT`, `Unix`, `Linux`, or `OSX`. (msbuild property `OSGroup`)
+- `-os` identifies the OS for the build. It defaults to the OS you are running on but possible values include `Windows_NT`, `Unix`, `Linux`, or `OSX`. (msbuild property `TargetOS`)
 - `-configuration|-c Debug|Release` controls the optimization level the compilers use for the build. It defaults to `Debug`. (msbuild property `Configuration`)
 - `-arch` identifies the architecture for the build. It defaults to `x64` but possible values include `x64`, `x86`, `arm`, or `arm64`. (msbuild property `ArchGroup`)
 
@@ -160,7 +160,7 @@ Under the `src` directory is a set of directories, each of which represents a pa
 
 For example the `src\libraries\System.Diagnostics.DiagnosticSource` directory holds the source code for the System.Diagnostics.DiagnosticSource.dll assembly.
 
-You can build the DLL for System.Diagnostics.DiagnosticSource.dll by going to the `src\libraries\System.Diagnostics.DiagnosticsSource\src` directory and typing `dotnet build`. The DLL ends up in `artifacts\bin\AnyOS.AnyCPU.Debug\System.Diagnostics.DiagnosticSource` as well as `artifacts\bin\runtime\[$(BuildTargetFramework)-$(OSGroup)-$(Configuration)-$(ArchGroup)]`.
+You can build the DLL for System.Diagnostics.DiagnosticSource.dll by going to the `src\libraries\System.Diagnostics.DiagnosticsSource\src` directory and typing `dotnet build`. The DLL ends up in `artifacts\bin\AnyOS.AnyCPU.Debug\System.Diagnostics.DiagnosticSource` as well as `artifacts\bin\runtime\[$(BuildTargetFramework)-$(TargetOS)-$(Configuration)-$(ArchGroup)]`.
 
 You can build the tests for System.Diagnostics.DiagnosticSource.dll by going to
 `src\libraries\System.Diagnostics.DiagnosticSource\tests` and typing `dotnet build`.
@@ -173,7 +173,7 @@ For libraries that have multiple target frameworks the target frameworks will be
 
 - Build project for Linux for .NET Core
 ```
-dotnet build System.Net.NetworkInformation.csproj /p:OSGroup=Linux
+dotnet build System.Net.NetworkInformation.csproj /p:TargetOS=Linux
 ```
 
 - Build Release version of library

docs/workflow/building/libraries/cross-building.md

@@ -56,7 +56,7 @@ And with:
 
     $ ROOTFS_DIR=/mnt/corefx-cross/arm ./src/Native/build-native.sh debug arm verbose cross
 
-As usual the generated binaries will be found in `artifacts/bin/BuildOS.BuildArch.BuildType/native` as following:
+As usual the generated binaries will be found in `artifacts/bin/TargetOS.BuildArch.BuildType/native` as following:
 
     $ ls -al ./artifacts/bin/Linux.arm.Debug/native
     total 988
@@ -85,7 +85,7 @@ You can also build just managed code with:
 
     $ ./build.sh --arch arm /p:BuildNative=false
 
-The output is at `artifacts/bin/[BuildSettings]` where `BuildSettings` looks something like `netcoreapp5.0-<OSGroup>-Debug-<Architecture>`. Ex: `artifacts/bin/netcoreapp5.0-Linux-Debug-x64`. For more details on the build configurations see [project-guidelines](/docs/coding-guidelines/project-guidelines.md)
+The output is at `artifacts/bin/[BuildSettings]` where `BuildSettings` looks something like `netcoreapp5.0-<TargetOS>-Debug-<Architecture>`. Ex: `artifacts/bin/netcoreapp5.0-Linux-Debug-x64`. For more details on the build configurations see [project-guidelines](/docs/coding-guidelines/project-guidelines.md)
 
 Building corefx for Linux ARM Emulator
 =======================================

docs/workflow/building/libraries/freebsd-instructions.md

@@ -79,7 +79,7 @@ index 81b8c7b..bb26868 100644
 @@ -5,6 +5,7 @@
      <BuildArguments>$(Platform) $(Configuration) skiptests</BuildArguments>
      <BuildArguments Condition="'$(SkipDisablePgo)' != 'true'">$(BuildArguments) -nopgooptimize</BuildArguments>
-     <BuildArguments Condition="'$(OSGroup)' != 'Windows_NT'">$(BuildArguments) msbuildonunsupportedplatform</BuildArguments>
+     <BuildArguments Condition="'$(TargetOS)' != 'Windows_NT'">$(BuildArguments) msbuildonunsupportedplatform</BuildArguments>
 +    <BuildArguments Condition="'$(TargetOS)' == 'FreeBSD'">$(BuildArguments) -clang6.0</BuildArguments>
      <BuildArguments Condition="'$(UseSystemLibraries)' == 'true'">$(BuildArguments) cmakeargs -DCLR_CMAKE_USE_SYSTEM_LIBUNWIND=TRUE</BuildArguments>
      <BuildArguments Condition="$(Platform.Contains('arm'))">$(BuildArguments) skipnuget cross -skiprestore cmakeargs -DFEATURE_GDBJIT=TRUE</BuildArguments>
@@ -235,7 +235,7 @@ This has two parts. We need to build managed bits on supported OS. For example o
 git clone https://github.com/dotnet/corefx
 cd corefx
 git checkout d47cae744ddfb625db8e391cecb261e4c3d7bb1c
-./build.sh -c Release /p:osgroup=FreeBSD
+./build.sh -c Release -os FreeBSD
 ```
 
 on FreeBSD we need to build native bits:
@@ -275,4 +275,3 @@ if missing add following section to `Microsoft.NETCore.App.deps.json`
             "fileVersion": "4.0.0.0"
           },
 ```
-

docs/workflow/testing/coreclr/testing.md

@@ -33,7 +33,7 @@ Note:  CoreCLR must be built prior to building an individual test. See the first
     * It is possible to explicitly run only the native test build with `build-test.sh/cmd skipmanaged`
 * Managed Test: Invoke `dotnet build` on the project directly. `dotnet` can be the `dotnet.sh` or `dotnet.cmd` script in the repo root.
 ```
-<runtime-repo-root>/dotnet.sh msbuild <runtime-repo-root>/src/coreclr/tests/src/JIT/CodegenBringupTests/Array1_d.csproj /p:__BuildType=Release
+<runtime-repo-root>/dotnet.sh build <runtime-repo-root>/src/coreclr/tests/src/JIT/CodegenBringupTests/Array1_d.csproj /p:__BuildType=Release
 ```
 
 ## Additional Documents

docs/workflow/testing/coreclr/unix-test-instructions.md

@@ -28,12 +28,12 @@ Please note that this builds the Priority 0 tests. To build priority 1:
 
 During development there are many instances where building an individual test is fast and necessary. All of the necessary tools to build are under `coreclr`. It is possible to use `~/runtime/dotnet.sh msbuild` as you would normally use MSBuild with a few caveats.
 
-**!! Note !! -- Passing /p:__BuildOS=[OSX|Linux] is required.**
+**!! Note !! -- Passing /p:__TargetOS=[OSX|Linux] is required.**
 
 ## Building an Individual Test
 
 ```
-/path/to/runtime/dotnet.sh msbuild src/coreclr/tests/src/path-to-proj-file /p:__BuildOS=<BuildOS> /p:__BuildType=<BuildType>
+/path/to/runtime/dotnet.sh msbuild src/coreclr/tests/src/path-to-proj-file /p:__TargetOS=<TargetOS> /p:__BuildType=<BuildType>
 ```
 
 ## Running Tests

docs/workflow/testing/libraries/filtering-tests.md

@@ -26,13 +26,13 @@ Use this attribute on test methods to specify that this test may only be run on
 
 **[Available Test Platforms](https://github.com/dotnet/arcade/blob/master/src/Microsoft.DotNet.XUnitExtensions/src/TestPlatforms.cs)**
 
-When running tests by building a test project, tests that don't apply to the `OSGroup` are not run. For example, to run Linux-specific tests on a Linux box, use the following command line:
+When running tests by building a test project, tests that don't apply to the `TargetOS` are not run. For example, to run Linux-specific tests on a Linux box, use the following command line:
 ```sh
-dotnet build <csproj_file> /t:Test /p:OSGroup=Linux
+dotnet build <csproj_file> /t:Test /p:TargetOS=Linux
 ```
 To run all Linux-compatible tests that are failing:
 ```sh
-dotnet build <csproj_file> /t:Test /p:OSGroup=Linux /p:WithCategories=failing
+dotnet build <csproj_file> /t:Test /p:TargetOS=Linux /p:WithCategories=failing
 ```
 
 #### ActiveIssueAttribute
@@ -148,9 +148,9 @@ _**A few common examples with the above attributes:**_
 
 - Run all tests acceptable on Windows that are not failing:
 ```cmd
-dotnet build <csproj_file> /t:Test /p:OSGroup=Windows_NT
+dotnet build <csproj_file> /t:Test /p:TargetOS=Windows_NT
 ```
 - Run all outer loop tests acceptable on OS X that are currently associated with active issues:
 ```sh
-dotnet build <csproj_file> /t:Test /p:OSGroup=OSX /p:WithCategories="OuterLoop;failing""
+dotnet build <csproj_file> /t:Test /p:TargetOS=OSX /p:WithCategories="OuterLoop;failing""
 ```