Remove bash dependency from init-compiler

[am11]

Also fixes shell check warnings in System.Globalization.Native/local_build.sh.

Upstream PR: dotnet/arcade#11359

[ghost]

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

Issue Details

---

Also fixes shell check warnings in System.Globalization.Native/local_build.sh.

Upstream PR: dotnet/arcade#11359

Author:	am11
Assignees:	-
Labels:	area-System.Globalization, community-contribution
Milestone:	-

[ghost]

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

Issue Details

---

Also fixes shell check warnings in System.Globalization.Native/local_build.sh.

Upstream PR: dotnet/arcade#11359

Author:	am11
Assignees:	-
Labels:	area-Infrastructure, community-contribution
Milestone:	-

[am11]

cc @jkotas, @akoeplinger
This is in preparation for including init-compiler.sh to NativeAOT package: #77245 (comment). Some OS (e.g. Alpine Linux) don't have bash preinstalled, and we aren't using many bash features besides two usages of bash arrays, so it's simple to replace them and drop the dependency from this standalone script.

[jkotas]

This is in preparation for including init-compiler.sh to NativeAOT package

I am not sure whether it is a good idea to include init-compiler.sh in the NativeAOT package. I see this script as specific to the .NET runtime internal build infrastructure setup. It is why it lives in Arcade repo. As a rule, bits that live in Arcade repo should be only used by .NET runtime internal build infrastructure. They should not ship as part of the product.

The current native AOT plan is: You have to have version-less tools installed. If you do not have version-less tools installed, you have to set CppCompilerAndLinker to point to the tools that you want to use.

[am11]

As a rule, bits that live in Arcade repo should be only used by .NET runtime internal build infrastructure.

We moved this script to arcade to avoid duplicating the code: #59018 (it is already included in Microsoft.DotNet.CMake.Sdk).

This is a freestanding script to locate compiler on the system. It works for all supported build environments (it does not look for prerequisite beyond a few compiler toolchain components, mainly the driver; clang or gcc).

you have to set CppCompilerAndLinker to point to the tools that you want to use.

I was experimenting (for a follow up PR) with keeping that experience. If user specified e.g. CppCompilerAndLinker=clang-15 or there is clang or gcc found in PATH, then we will not invoke the script. Without setting CppCompilerAndLinker or when there is no clang or gcc in PATH, we will invoke this script to find the best available versioned compiler found in PATH (descending order of their versions).

[jkotas]

it is already included in Microsoft.DotNet.CMake.Sdk

This nuget package is not a shipping nuget package. It is not on nuget.org. It is for internal .NET build infrastructure use only.

[am11]

This nuget package is not a shipping nuget package. It is not on nuget.org. It is for internal .NET build infrastructure use only.

Right, my point was the only reason it's moved to arcade was to avoid maintaining two copies of same script, that locates versioned compiler in PATH.

[akoeplinger]

It would still mean we're essentially signing up for shipping init-compiler.sh officially (even if it's just for this opt-in static ICU linking feature from local_build.sh).

That said, maybe that's the right choice given we need to hardcode clang version numbers which are specific to our build environment e.g. like this today:

runtime/src/coreclr/tools/aot/crossgen2/crossgen2.csproj

Lines 34 to 35 in f4b715f

	<CppCompilerAndLinkerCondition="'$(TargetArchitecture)' != '$(BuildArchitecture)' and '$(HostOS)' == 'linux' and '$(RuntimeIdentifier)' == 'linux-musl-arm64'">clang-15</CppCompilerAndLinker>
	<CppCompilerAndLinkerCondition="'$(TargetArchitecture)' != '$(BuildArchitecture)' and '$(HostOS)' == 'linux' and '$(RuntimeIdentifier)' != 'linux-musl-arm64'">clang-9</CppCompilerAndLinker>

[jkotas]

That said, maybe that's the right choice given we need to hardcode clang version numbers which are specific to our build environment e.g. like this today:

We can call init-compiler.sh from our build environment to fix these hardcoded version numbers. It is not necessary to ship init-compiler.sh for that.

[am11]

Removed hard-coded versions in favor of similar target used in mono and DNNE test projs.

[akoeplinger]

looking at the whole PR again, maybe it'd be better to not use this property name at all and go with what we use in the NativeExports.csproj:

 <PropertyGroup>
<NativeCompiler>$(Compiler)</NativeCompiler>
<NativeCompiler Condition="'$(NativeCompiler)' == ''">clang</NativeCompiler>
</PropertyGroup>

that'd also support overriding via the $(Compiler) property.

[am11]

Compiler == CppCompilerAndLinker here, see eng/build.sh

[akoeplinger]

omg, so many abstractions 😄

[am11]

:)

I am all for replacing CppCompilerAndLinker and CppLinker in favor of NativeCompiler as property name, but I think some consumers are relying on CppCompilerAndLinker.

[am11]

Failures are unrelated and known: #79843 (mono llvmfullaot), #79439 (win-x64) and #79569 (browser-wasm).