Build Options

options.md

Build Options

Option 1a:

• Linux-x64
  • build/publish native assets
• OSX-x64
  • build/publish native assets
• Win-x64
  • build/publish native assets

Join

• Copy all native assets locally
• Build managed
• Package managed + native into .nupkg

Option 1b:

• Linux-x64
  • build/publish native assets
• OSX-x64
  • build/publish native assets
• Win-x64
  • build/publish native assets
• Win
  • build/publish managed assets

Join

• Copy all managed and native assets locally
• Package managed + native into .nupkg

Option 2:

• Linux-x64
  • publish native assets
• OSX-x64
  • publish native assets

Join

• Copy all native assets locally
• Build managed + Win-x64 native
• Package managed + native into .nupkg

Thoughts

I like Option 1

• It is consistent, no 'special' leg gets native + managed assets built
• It scales when other Windows legs are brought online (win-x86, win-arm)

I vote for 1a as well. It requires we only ever have one managed flavor that we care to package (EG: we don't start pivoting at the build level across a managed TFM or some feature flag or something) but I think that's a safe assumption.

One stipulation I have is that packaging portion of the build is independently runnable. It can rely on locally built binaries but it should not be tightly coupled to the managed build (eg as an afterbuild step in a csproj or something). IOW, I want to be able to do build -managed -skipPackaging then build -packages

You should also consider where signing fits in.

I like either 1a or 1b. I do like the fact that 1b's join is implicitly the package step in itself. If you do 1a, I would separate out the build of managed assets into a discrete step, so that it is simply an optimization that the managed asset build and package step happened on the same machine.