dotnet / linker

388 stars 127 forks source link

Use arcade to build linker #452

Closed sbomer closed 5 years ago

sbomer commented 5 years ago

@marek-safar We would like the linker to participate in .NET Core product construction using https://github.com/dotnet/arcade. I'm hoping to do the work in a way that benefits mono as well as the dotnet product construction, and am looking for input on how to best accomplish that.

The arcade infrastructure uses wrapper scripts that download a bootstrap dotnet sdk and use its nuget/msbuild to restore and build a solution in the repo root. It has some conventions around directory structure, package dependencies, flowing dependencies between repos, etc. To what extent are you interested in reusing arcade infrastructure for the monolinker.exe (as opposed to illink and ILLink.Tasks) build? It seems there are options like:

I also noticed that https://github.com/mono/mono has a submodule dependency on mono/linker. It looks like there are dependencies on the source files in https://github.com/mono/mono/blob/master/mcs/tools/linker/monolinker.exe.sources and https://github.com/mono/mono/blob/master/mcs/tools/linker-analyzer/illinkanalyzer.exe.sources. Similarly for cecil at https://github.com/mono/mono/blob/c5b88ec4f323f2bdb7c7d0a595ece28dae66579c/mcs/class/Mono.Cecil/Mono.Cecil.dll.sources. I'm not familiar with the mono project's build.

I'd also like to use this as an opportunity to look into simplifying the configurations we use to build illink (and possibly monolinker). Currently, Mono.Linker/illink_Debug depends on Mono.Cecil/netstandard_Debug. The .NET SDK doesn't support configuration-specific dependencies, so we have hacks in place that explicitly inject the configuration into Mono.Linker and its dependencies. The workaround isn't so bad, but it gets worse every time we add another project (Mono.Cecil.Pdb/Mdb, an ILLink.Tasks.Tests project, etc.).

sbomer commented 5 years ago

This has been completed in linked PRs.