@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:
Are there any restrictions on what changes can be made to this repo's build? (Would you prefer the file layout to stay as-is, or may we move them around?)
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.).
I'd like to set up a build of the linker (and cecil, @jbevain ) that uses a normal SDK project (<Project Sdk="Microsoft.NET.Sdk">) and supported mechanisms for publishing for different Target Frameworks. This means setting the TargetFramework independently of the configuration, and using only Debug/Release configurations. Is this a change you'd like me to pipe through the mono build as well, or should it be kept in a separate project file? It looks like it has been attempted for cecil at least in https://github.com/jbevain/cecil/pull/442 and https://github.com/jbevain/cecil/pull/527. @jbevain, it would be wonderful to get your opinion on this.
@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.).
<Project Sdk="Microsoft.NET.Sdk">
) and supported mechanisms for publishing for different Target Frameworks. This means setting the TargetFramework independently of the configuration, and using only Debug/Release configurations. Is this a change you'd like me to pipe through the mono build as well, or should it be kept in a separate project file? It looks like it has been attempted for cecil at least in https://github.com/jbevain/cecil/pull/442 and https://github.com/jbevain/cecil/pull/527. @jbevain, it would be wonderful to get your opinion on this.