Don't store built artifacts in the repository

[russss]

Dealing with multiple pull requests is rather a pain at the moment because pretty much all PRs include unmergeable changes to the agg-kicad.[lib|pro] files.

It would be much easier to deal with this stuff if these generated files weren't stored in the repo. Here's one way this could be done fairly easily:

• Alter the build scripts so that the generated libraries live in a separate directory tree.
• Either:
  • Manually tag a release periodically after merging PRs, or,
  • Make the travis script automatically tag a new release when a build succeeds on master.
• Set up travis so tag builds are uploaded as GitHub releases

This means that the generated libraries can be downloaded as .zip files (which is probably more convenient for most users), and those who are working off the git tree won't be constantly plagued with merge conflicts.

[adamgreig]

I'm not sure what the best way to deal with this is. Almost all of my own use cases, and many others I know about, have agg-kicad as a git submodule in their own repository, which makes it easy to keep up-to-date, but then they only use that submodule for the agg.pretty directory and agg-kicad.lib top level library that contains every part.

In addition to being annoying because those build artifacts change, a lot of users want some of the library parts (ICs etc) without others (the agg-kicad R, C, L, and power symbols). So there was some thought to having separate build artifacts for different collections.

I wonder if another repository that only contains up-to-date build artifacts is the way to go, automatically maintained by Travis?

[HarkonenBade]

Yeah, I'd suspect that the best way to handle it is with one repo (say agg-kicad-src) that contains all the current code and yaml and a second repo (say agg-kicad) that contains only the built artifacts and is only ever pushed to by a travis script that runs on new commits to the master of the src repo.

[seppestas]

I think using a second repo or maybe an orphaned brach to store the build results sounds like a good idea. This would also make it a bit easier / cleaner to include the build artifacts as a submodule.