You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@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 Update solution to the new project system jbevain/cecil#442 and Migrate new sdk jbevain/cecil#527. @jbevain, it would be wonderful to get your opinion on this.
The text was updated successfully, but these errors were encountered:
This organizes the source and test projects as follows:
- source projects go in `src/project/projectfile.csproj`
- test projects go in `test/project/projectfile.csproj`
The uniform layout of projects is part of the arcade onboarding (see #452).
This organizes the source and test projects as follows:
- source projects go in `src/project/projectfile.csproj`
- test projects go in `test/project/projectfile.csproj`
The uniform layout of projects is part of the arcade onboarding (see dotnet/linker#452).
Commit migrated from dotnet/linker@fa9ccbd
@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 Update solution to the new project system jbevain/cecil#442 and Migrate new sdk jbevain/cecil#527. @jbevain, it would be wonderful to get your opinion on this.The text was updated successfully, but these errors were encountered: