Prep for public release to CocoaPods

[mikemee]

@stephencelis, as discussed, here is a branch with a proposed update to become the first "public" cocoapod version.

Summary of changes:

• Remove SQLiteCipher (for now, per Move SQLCipher support into separate repo #311)
• rebuilt clean from "New Project" with Xcode 7.2 (it removed some cruft required by older Xcode releases & hopefully also fixes some lingering build issues)
• fix build glitches with Carthage (e.g. Build fails when the project path contains whitespaces #202)
• fix build glitches with CocoaPods (e.g. Umbrella header SQLite.h not found in module.modulemap #230)
• separate build targets from test targets with @testable import (added in Swift 2.0)
• make sqlite3 a Swift system module so import SQLite3 works in .swift files (looking ahead, this is how the swift package manager will do it)
• becomes an Xcode Project instead of Workspace
• folder structure rearranged to correspond to an Xcode "New Project" layout

Known CocoaPod hassles:

• I couldn't convince it to generate its own module.modulemap file, so one is included
• has spurious warnings about a missing include: Umbrella header for module 'SQLite' does not include header 'fts3_tokenizer.h (all tests, including tokenizer, run fine)
• pod lib lint does not work to validate the pod, but pod spec lint is fine (per pod lib lint doesn't respect preserve_paths? CocoaPods/CocoaPods#4607) (Note: does not currently pass either as it needs a branch, but it did pass in testing on my repo with the url modified).

Next Steps

If this PR is accepted, the following should be done to make CocoaPods and Carthage happy:

• tag the commit in master with '0.9.0'
• push to CocoaPods per: https://guides.cocoapods.org/making/getting-setup-with-trunk.html

Trying this PR now

I encourage others to try this PR. Because it's on a branch, it is a trivial change to your existing files (or manually as before):

Carthage Cartfile:

github "stephencelis/SQLite.swift" "publicpod"

CocoaPod Podfile:

use_frameworks!

pod 'SQLite.swift',
  git: 'https://github.com/stephencelis/SQLite.swift.git', :branch => 'publicpod'

After this

• The cleaned up build should make it trivial to add TV support (Need TV OS Support #272) (very tempted to just add it now...)
• Create a new repo that builds on this to restore SQLiteCipher via https://github.com/sqlcipher/sqlcipher

Other TODOs

• Remove SQLCipher references and installation instructions from README, Documentation

[stephencelis]

Good change. Prepares us for swiftpm compatibility 👍

[mikemee]

Thx :) I can't take full credit. This just seemed to be the norm in similar projects I viewed for comparison when I did "new project", so I copy pasted. Plus I've removed more than a few .DS_Store files over time.

[stephencelis]

This is great! Thanks for all the work you put into it! I left a few comments/questions, but I think this is really close to being ready.

[stephencelis]

This'll need to get rebased (given #317). Once you think things are ready, give me a nod, I'll take a final look and merge!

[stephencelis]

(Oh, and as far as a separate SQLiteCipher.swift project goes, should I create a repo and add you?)

[mikemee]

Rebase is done. @testable done. deployment target added to podspec.

Working on the other items. (Trying private for fts3_tokenizer.h just to see... so far Xcode happy, but still need to test Carthage (likely fine since Xcode is) and of course CocoaPods to be sure).

Re SQLiteCipher - sure. Can't promise anything, but I do like to see things through... :)

[stephencelis]

Yeah, I think the other repo at least needs to work very basically since people depend on SQLCipher in their projects. Let me see if I can get something basic working against this branch.

I also just noticed that SQLCipher installation instructions are still in the README/Documentation on this branch; we should remove/update them before merging.

[mikemee]

Private for fts3_tokenizer.h still generates the same warning, so I'll leave it as is (project), unless you have strong feelings about it.

Will fix the readme/documentation re SQLCipher

Re the module map. I just realized that even if I fix it via a magic script for Cocoa, it's still "wrong" for Swift Package Manager / current Xcode style file in SQLite3/module.modulemap, i.e.:

module SQLite3 [system] {
    header "/usr/include/sqlite3.h"
    link "sqlite3"
    export *
}

And I don't know any simple way of changing that, hmm, except, I suppose by setting up multiple files, then changing the Swift Include file path in Xcode... all of which seems more messy for a problem that will go away with Swift Package Manager soon enough anyway (I hope!)

I.e. these are all identical on my machine:

/usr/include/sqlite3.h 
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/usr/include/sqlite3.h
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS.sdk/usr/include/sqlite3.h 
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator.sdk/usr/include/sqlite3.h

Given that all these files are identical anyway, I propose sticking with the original checkin and not complicating the CocoaPod build further.

But I'll accept whatever you prefer ... it's your project (though I'm not excited to hack the script I will admit! ;)

[stephencelis]

💯