Add links to docs #68211
Add links to docs #68211
Conversation
That hopefully simplify path for brave person willing to add new target
ghost
added
the
community-contribution
|
Tagging subscribers to this area: @dotnet/area-infrastructure-libraries Issue DetailsThat hopefully simplify path for brave person willing to add new target
|
|
Thank you. |
| @@ -27,7 +27,7 @@ The compiler also has a mode where each managed assembly can be compiled into a | |||
| - [NOT PORTED OVER YET] The build will place the toolchain packages at `artifacts\packages\[Debug|Release]\Shipping`. To publish your project using these packages: | |||
| - [NOT PORTED OVER YET] Add the package directory to your `nuget.config` file. For example, replace `dotnet-experimental` line in `samples\HelloWorld\nuget.config` with `<add key="local" value="C:\runtimelab\artifacts\packages\Debug\Shipping" />` | |||
| - [NOT PORTED OVER YET] Run `dotnet publish --packages pkg -r [win-x64|linux-x64|osx-64] -c [Debug|Release]` to publish your project. `--packages pkg` option restores the package into a local directory that is easy to cleanup once you are done. It avoids polluting the global nuget cache with your locally built dev package. | |||
| - The component that writes out object files (objwriter.dll/libobjwriter.so/libobjwriter.dylib) is based on LLVM and doesn't build in the runtime repo. It gets published as a NuGet package out of the dotnet/llvm-project repo (branch objwriter/12.x). If you're working on ObjWriter or bringing up a new platform that doesn't have ObjWriter packages yet, as additional pre-requiresites you need to build objwriter out of that repo and replace the file in the output. | |||
| - The component that writes out object files (objwriter.dll/libobjwriter.so/libobjwriter.dylib) is based on LLVM and doesn't build in the runtime repo. It gets published as a NuGet package out of the [dotnet/llvm-project](https://github.com/dotnet/llvm-project) repo (branch [objwriter/12.x](https://github.com/dotnet/llvm-project/tree/objwriter/12.x)). If you're working on ObjWriter or bringing up a new platform that doesn't have ObjWriter packages yet, as additional pre-requiresites you need to build objwriter out of that repo and replace the file in the output. | |||
There was a problem hiding this comment.
as additional pre-requiresites you need to build objwriter out of that repo and replace the file in the output.
FWIW, replacing files in all the right places is overwhelming, and after spending enough time playing trial and error with msbuild verbose logs, it still didn't work for me (i.e. nuget cache was hit or wrong bin folder got picked up during one of the build/pack step and ended up testing the wrong binary). Not an msbuild expert ™️ so I might have missed something if it is supposed to just work that way (with reasonable number of steps). 😅
To unblock myself, I ended up with somewhat of a hammer solution, i.e. clear all kinds of local package caches, add local folder in nuget.config etc. using the following zsh script (~/projects/customaot.sh) on osx-arm64 (which takes about 15 minutes on M1 mac to build the whole toolchain E2E and compile a simple hello world app with that custom built toolchain):
#!/usr/bin/env zsh
set +e
# ~/update-daily-dotnet7.sh
alias dotnet7=~/.dotnet7/dotnet
# Created a hello world app with dotnet7 new console -o ~/projects/naot1, with
# NuGet.config containing .NET 7 preview sources.
#
# Next:
# 1. in ~/projects/runtime:
# * ./NuGet.config: add this line (with your username) after <clear /> line:
# <add key="foo" value="/Users/am11/projects/llvm-project/artifacts/packages/Release/Shipping" />
# * ./eng/Version.Details.xml: change version in
# <Dependency Name="runtime.osx.11.0-arm64.Microsoft.NETCore.Runtime.ObjWriter"...
# line to 1.0.0-dev
# * ./eng/Versions.props: change version in
# <runtimeosx110arm64MicrosoftNETCoreRuntimeObjWriterVersion>...
# line to 1.0.0-dev
dotnet7 nuget locals all --clear # clear *all* nuget caches
~/projects/llvm-project/build.sh --restore --build --pack --arch arm64 --configuration Release
# 2. in ~/projects/nativeaot1:
# * ./NuGet.config: add this line key:
# <add key="foo" value="/Users/am11/projects/runtime/artifacts/packages/Release/Shipping" />
# * ./naot.csproj: update ILCompiler package version to 7.0.0-dev
cd ~/projects/runtime
rm -rf artifacts
./build.sh -c Release # I know we can handpick the subsets, but .. for reasons ..
# I gave up and ended up building all the default subsets
cd ../naot1 # existing hello-world app with reference to ILCompiler 7.0.0-dev package
rm -rf obj bin
dotnet7 nuget locals all --clear # clear again, so there is no doubt that no cache was hit
# verbosityArg="-v:diag"
dotnet7 publish --use-current-runtime $verbosityArg | tee dumpI am sure there are ways to optimize it (i.e. by replacing files as the doc is suggesting). If you know how, please share. It will be a huge time saver.
cc @adamsitnik, this is how I opened the door. For #68257 you would probably only need step 2. from the script (if you are not building custom objwriter; in addition to custom ilc). 🙂
There was a problem hiding this comment.
I usually just go to Nuget cache (%localappdata%\NuGet\Cache) and nuke runtime.win-x86.Microsoft.NETCore.Runtime.ObjWriter folder and that's it. Much faster then cleanup all nuget cache. Otherwsie exact same steps.
About publishing of application.
You probably want dotnet7 publish --packages pkg and nuke pkg folder instead of your whole Nuget cache. should be slightly faster.
There was a problem hiding this comment.
If / when clearing cache for specific packages is supported NuGet/Home#5713, it would make my life easier. I remember searching the harddisk and deleting objwriter package from more than one location, for some reason it still didn't work (but I didn't spent more time with it to confirm had I missed something).
That hopefully simplify path for brave person willing to add new target
ghost
locked as resolved and limited conversation to collaborators
That hopefully simplify path for brave person willing to add new target