Skip to content

Instantly share code, notes, and snippets.

@eerhardt

eerhardt/options.md

Last active March 19, 2018 21:05
Show Gist options
  • Save eerhardt/89b076f37d539c5fc8d6ac0732e67815 to your computer and use it in GitHub Desktop.
Save eerhardt/89b076f37d539c5fc8d6ac0732e67815 to your computer and use it in GitHub Desktop.
Download ZIP
Build Options
Raw
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)
@mmitche
Copy link

mmitche commented Mar 19, 2018

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment