Closed wmathurin closed 8 years ago
:+1:
Have we tested this? Stock FMDB depends on sqlite3. Are there going to be symbol clashes when we effectively go against both?
Also, FMDB is the spec that has to compile against DSQLITE_HAS_CODEC
. That was the whole reason for splitting it out: the default FMDB spec does not set it.
My recommendation would be to keep our FMDB spec, but swap out the vendored library for a dependency on SQLCipher/fts
.
You are probably right, I'll make the change.
Another question I have with regards to re-establishing our dependency on the SQLCipher spec: is there reason to have renewed faith that the spec won't simply fall into disrepair again? There's an argument for keeping our own version of SQLCipher, so that we can keep it maintained.
But I suppose we can (re-)cross that bridge when we get to it.
Switching one way or the other is easy. I suggest we don't call our subspec fmdb so that one doesn't end up picking up the stock fmdb by having the sources in the wrong order. How about SalesforceFMDB?
The problem with renaming the spec is that it filters all the way through to the header paths, with implications on non-modular header imports et al. So far I haven't been able to find the way to effectively "rename" the target internally to differentiate it from the named spec.
Ah ok, I'll keep the name then and make sure to have our specs repo source first in all the templates.
How does it look now?
Looks good. I do like the idea of renaming the spec, if we can find a way. I wonder if spec.module_name
(here) would do the trick in the pod spec?
I think it should (https://guides.cocoapods.org/syntax/podspec.html#module_name)
I can't get it to work as SalesforceFMDB with module_name - so I'll leave it as FMDB for now
Sounds good. We can look into further. :+1:
:+1: