Expand the build infrastructure support

[tannergooding]

The build infrastructure for ImageSharp is rather limited today and doesn't always follow best practices.

It would be ideal if this could be updated to have cross-platform build scripts, rely on things like Directory.Build.props/targets for centralizing build metadata, and generally be updated to do things like work with long paths, with paths that have spaces in the name, and where the working directory is not the repo root.

[tannergooding]

@JimBobSquarePants, I know I had discussed this with you briefly at the MVP summit; but if I were to provide some fixes here; would you prefer it incrementally or in one big PR?

[tannergooding]

Would you also prefer it in a PR or with a layout of changes discussed here first?

[JimBobSquarePants]

Hey @tannergooding

Yeah this would be great! Looking forward to seeing what will change.

I think the best bet would be a layout of changes here and everything in a big fat PR. That way we can avoid any interim complexity in the build process.

[tannergooding]

I think there a couple potential options here:

1. Take a dependency on a "build toolchain" like dotnet/arcade. This is what Roslyn, CoreFX, and other repositories are currently using. CoreCLR and other dotnet repositories are planning on moving to it as well.
2. You could go with a smaller more customized approach and rewrite your own infrastructure to how you need.

The process overall would be fairly similar for both, mostly just differing in whether you have code props/targets locally or if you are directing those same props/targets to the dotnet/arcade NuGet package.

The primary recommendations I have are:

1. Use Directory.Build.props and Directory.Build.targets to share common project properties/targets/etc. This also makes it easy to bring down shared toolset packages or analyzers.
2. Rewrite the build scripts to have both sh and cmd versions (the cmd version forwards to ps1). This also needs to handle common issues like paths that have a space in their name, pulling down build dependencies, or triggering the scripts from any folder (not just the repo root). It should also provide a consistent interface across all platforms/architectures (so you can easily move between Linux, Windows, OSX, etc).

I've been going with the second option (customized approach) in my own projects as I find it easier to understand/reason about and find it I can't be caught in surprise by changes that arcade makes for dotnet which might not be applicable to me. The drawback, is I'm responsible for my own infrastructure and bringing functionality on-board as needed.

You can see an example of my current infrastructure here: https://github.com/terrafx/terrafx. It isprimarily centered around easy "inner loop" scripts in the repo root that forward to the real build scripts in the scripts folder. There is then the root Directory.Build.props/targets which defines core properties like language version, packing options, NuGet restore sources, and the Roslyn Compiler Toolset to depend on. The sources and tests folders then have their own Directory.Build.props/targets (which import the root ones) and define things specific to them. These include the testing dependencies, InternalsVisibleTo support, and build output subdirectories (which I find make it easier to locate things in my artifacts folder).

[JimBobSquarePants]

Lots of great ideas and info here, thanks!

I'm undecided.... I appreciate the risks involved in taking on Arcade but I also believe that any breaking changes will most likely have well documented resolution.

[tannergooding]

Let me know when you have made a decision and I'm happy to get the PR up for whichever you prefer.

[JimBobSquarePants]

Let’s go with Arcade, that way we can copy MS when something changes. Thanks, really appreciate this! 😄

[antonfirsov]

Does the underlying CI infrastructure matter, when considering the options? Currently we are stuck with AppVeyor+Travis, but we are planning to migrate to Azure Pipelines in the future.

[tannergooding]

Does the underlying CI infrastructure matter, when considering the options? Currently we are stuck with AppVeyor+Travis, but we are planning to migrate to Azure Pipelines in the future.

It shouldn't. The majority of it is controlled via centralized build scripts that CI is configured to call.

[antonfirsov]

Arcade sounds fine to me.

[tannergooding]

Ok, so I had been working on getting the arcade support working but the arcade team has indicated that it is only intended for Microsoft owned repos. This is partially because it has some explicit support for some internal tooling (like MicroBuild) but also because it is believed that most of the core functionality (such as localization, versioning, source linking, etc) should be part of the .NET SDK instead and bugs should be logged against .NET SDK, MSBuild, and NuGet when that functionality is missing.

I'm still happy to help rev the infrastructure, but unfortunately, it looks like dotnet/arcade is not going to be a viable (or at least not supported) path forward.

[JimBobSquarePants]

Thanks for investigating; we can live with that, plan B it is! 😄