|
11 | 11 | * [Design Documentation](#design-documentation) |
12 | 12 | * [Further Reading](#further-reading) |
13 | 13 |
|
14 | | -The Native AOT toolchain can be currently built for Linux (x64/arm64), macOS (x64) and Windows (x64/arm64). |
| 14 | +The Native AOT toolchain can be currently built for Linux (x64/arm32/arm64), macOS (x64/arm64) and Windows (x86/x64/arm64). |
15 | 15 |
|
16 | 16 | ## Building |
17 | 17 |
|
18 | 18 | 1. [Install pre-requisites](/docs/workflow/README.md#build-requirements) |
19 | | -1. Run `build[.cmd|.sh] clr.aot+libs -rc [Debug|Release]` from the repo root to build binaries for local development. This will build individual components, but not the NuGet packages and builds much faster. |
| 19 | +1. Run `build[.cmd|.sh] clr.aot+libs -rc [Debug|Checked|Release] -lc Release` from the repo root to build binaries for local development. This will build individual components, but not the NuGet packages and builds much faster. The `-rc` parameters specifies build configuration of the runtime, AOT compiler, and corelib, `-lc` specifies the configuration of the rest of BCL libraries. The repo and test infra generally assumes BCL libraries are compiled as Release and you're unlikely to need Debug. |
| 20 | + |
| 21 | +Once you build the repo, you can use the produced binaries in one of four ways specified below ("Using built binaries", "Building packages", "Convenience Visual Studio "repro" project", "Running tests"). |
20 | 22 |
|
21 | 23 | ### Using built binaries |
22 | 24 |
|
| 25 | +In this workflow, you have a project file that you want to `dotnet publish`, but you want to use your own build of the compiler/runtime/framework. You need to be using a daily build of the .NET SDK downloaded from the dotnet/sdk repo. It's typically enough to just download the daily build ZIP file, unpack it, and make sure the unpacked directory is the first thing in your PATH. Don't forget to add a NuGet.config as specified by the dotnet/sdk repo- you'll hit restore issues otherwise. |
| 26 | + |
| 27 | +The native AOT MSBuild targets allow overriding the paths to compiler/runtime/framework with the compiler/runtime/framework you just built. This requires that the SDK you're using is not too far from the runtime repo you just built. They sometimes get out of sync, if that happens you need to use the "Building packages" workflow below (you'll see issues such as missing members/types in assemblies, incorrect command line arguments passed to the compiler, and linking failures). |
| 28 | + |
23 | 29 | The paths to major components can be overridden using `IlcToolsPath`, `IlcSdkPath`, `IlcFrameworkPath`, `IlcFrameworkNativePath` and `IlcMibcPath` properties for `dotnet publish`. For example, `/p:IlcToolsPath=<repo root>\artifacts\bin\coreclr\windows.x64.Debug\ilc` can be used to override the compiler with a local debug build for troubleshooting or quick iterations. |
24 | 30 |
|
25 | 31 | ### Building packages |
@@ -65,6 +71,8 @@ Typical workflow for working on the compiler: |
65 | 71 | * Set Application arguments in the project Debug options to the response file that was generated by regular native aot publishing of your test project, e.g. `@obj\Release\net8.0\win-x64\native\HelloWorld.ilc.rsp` |
66 | 72 | * Build & run using **F5** |
67 | 73 |
|
| 74 | +NOTE: this requires that you globally install the same .NET SDK version as the one that is used to build the repo. You can avoid this requirement by launching Visual Studio through the build.cmd script at the root of the repo. `build.cmd -vs src\coreclr\tools\aot\ilc.sln` opens the ILC solution, `build.cmd -vs nativeaot` opens the native AOT solution. |
| 75 | + |
68 | 76 | ## Convenience Visual Studio "repro" project |
69 | 77 |
|
70 | 78 | Typical native AOT runtime developer scenario workflow is to native AOT compile a short piece of C# and run it. The repo contains helper projects that make debugging the AOT compiler and the runtime easier. |
|
0 commit comments