New project layout, Carthage, SPM [WIP]

[fulldecent]

This is an ambitious PR that changes the project layout and closes most open issues. Please help by playing with the proposed code and contributing code fixes or test cases of things that are broken.

How can I play with this PR?

• Clone and cd into the directory
• Run some stuff you need to run for any Ruby project:
  • gem install bundler
  • bundle install
• Run the included test suite:
  • rake
  • Note: this uses the latest released version of CocoaPods to run this template (retrieved with Bundler)
• Try it for real:
  • cd ~/Desktop
  • pod lib create --verbose --template-url='file:///PATH/TO/pod-template' NewPod
  • Note: this uses your INSTALLED VERSION of pod to run this template

---

PR Status

Wording:

• pod-template -- this project
• template -- a model that can have things changed
• vendored -- a chosen template with variable substitutions and other updates applied and ready for making an iOS framework

pod-template progress:

• Make vendoring work
• Set up testing with rake/rspec to validate the vendoring process (fixes Create a full test #79)
• Set up Travis CI
• Update variable substitution process, remove unused code

baseline template progress: (new feature)

• Move all files common to Swift and Objective-C into a "baseline" template
• Update to latest gitignore
• Supports Swift Package Manager format (fixes Update project layout for Swift Package Manager #157)

swift template progress:

• Create a hello world example (this is a change), it actually does something
• Remove FDChessboardView and my name from project, use variable substitution
• Remove XCode warnings (fixes Recommended project settings #131)
• Has "hello world"-level functionality

objective-c template progress: [HELP REQUESTED]

• Translate the current Swift template into Objective-C

other blockers:

PLEASE HELP REVIEW AND ADD BLOCKERS HERE

• Confirm each set of options works [HELP REQUESTED]

[fulldecent]

Please assist me in getting this merged into develop quickly. This is a big change (but strictly speaking does not break API) -- and it will help if others can commit to develop and open PRs against this progress so far.

THEN I can make a separate PR from develop to master to discuss all blockers and anything that might be broken.

Thank you!

[fulldecent]

@orta May I please have a clean working slate for this work?

Merging this #179 into develop gives me the extra problem that f539662 is currently breaking.

Could this instead be merged into a new branch. Or better, can the enable_code_coverage feature be removed from develop.

To clarify the problem:

1. The enable_code_coverage is running inside a post install hook in the example project podfile
2. In the old project layout, the Podfile was at the top level, and the tests and example live together
3. In the new project layout, the Podfile is inside the example which is subordinated, and the tests are top level

Therefore this feature is not compatible with the new project layout. Or, more likely I am not understanding things.

[fulldecent]

Also, just because I have nowhere better to discuss this, could the vanilla-xcodebuild branch please be deleted.

[orta]

Sure, what commit ref do you want the branch off?

[fulldecent]

Please branch off master and then this PR is ready to be immediately merged into that new branch.

[orta]

Develop is based off master, should be 👍

[fulldecent]

Right now there are a couple extra commits in develop that are incompatible with this branch. Please advise

[orta]

I'm not really sure what the commits or the merge conflicts are, I assume these are PRs that came in while this was WIP? If they seem useful take the code, if they don't drop them, given this is mostly a re-write it's fine to rethink

[fulldecent]

OK, I just did a git merge --strategy ours upstream/develop. This is ready to merge to develop!

[orta]

Awesome!

[orta]

awesome

[fulldecent]

Thank you! Discussion continued at #183