Thank you very much, @R4N. I performed some necessary adjustments, and documented how to use GRDB+SQLCipher with SPM (with a fork, as last discussed at #1827 (comment).

I saw the PoC branch that you mentioned in #1827 (comment). The documentation for forkers is simpler here, though. Since we'll want a GRDBSQLCipher target anyway, when traits can be used, I just defined it, waiting for forkers to uncomment it in Package.swift. And I could revert your bd954c6 on the way.

@R4N, I'm not sure I understand the reason for this portion of your document:

var cSettings: [CSetting] = [
    .define("NDEBUG", to: nil),
    .define("SQLCIPHER_CRYPTO_CC", to: nil),
    .define("SQLITE_HAS_CODEC", to: nil),
    .define("SQLITE_TEMP_STORE", to: "2"),
    .define("SQLITE_THREADSAFE", to: "1"),
    .define("SQLITE_EXTRA_INIT", to: "sqlcipher_extra_init"),
    .define("SQLITE_EXTRA_SHUTDOWN", to: "sqlcipher_extra_shutdown"),
    .define("SQLITE_ENABLE_FTS5", to: nil),
    .define("SQLITE_ENABLE_SNAPSHOT", to: nil)
]

It might be due to the amalgamation building. I'm not sure it is necessary with the technique proposed in this pull request, based on https://github.com/sqlcipher/SQLCipher.swift.

@groue

Great! Your adjustments look good to me.

It might be due to the amalgamation building. I'm not sure it is necessary with the technique proposed in this pull request, based on https://github.com/sqlcipher/SQLCipher.swift.

Yes, exactly. That documentation is an example for forkers who are using the amalgamation to include customization beyond what the official SQLCipher package provides and won't be required when using the official SQLCipher package in this pull request. Those cSettings line up with our SQLCipher community documentation for source integration here: https://www.zetetic.net/sqlcipher/sqlcipher-apple-community/#source-integration

I tested your latest changes using a project consuming a local GRDB package and commenting/uncommenting the appropriate sections of Package.swift. The official SQLCipher dependency was pulled in, the correct cipherVersion was reported, and the database was properly encrypted.

I also tested what a fork might look like for swift-sqlcipher using the same sample project consuming the local GRDB package. These were the necessary adjustments:

1. Switch the dependencies.append to reference swift-sqlcipher instead:

dependencies.append(.package(url: "https://github.com/skiptools/swift-sqlcipher", from: "1.7.1"))

2. Leave GRDBSQLCipher target and GRDBSQLCipher dependency in GRDB dependencies block commented out (shim passthrough is already defined in swift-sqlcipher)
3. Remove import GRDBSQLCipher from Database.swift

The swift-sqlcipher dependency was properly included, the correct cipherVersion was reported, and the database was properly encrypted.

I've adjusted the sqlcipher-fork-poc branch (example of custom SQLCipher amalgamation inclusion for other non-official forkers) along with the SQLCipherCustomFork.md example documentation to remove including the GRDBSQLCipher functions internally.

This is looking solid for supporting a GRDB + SQLCipher fork with a minimal diff while providing the flexibility to allow drop-in replacements of the SQLCipher dependency for forkers who require additional customizations.

Thank you for your excellent feedback @R4N 🙂 All right, let's merge this!

Good news: this is working great for my source build of SQLCipher. All but one of the tests are passing for each of macOS, iOS, Linux, Android, and Windows with a fairly minimal changeset (most of which I will be upstreaming).

So are we happy with this fork-friendly approach? I know it isn't ideal to have a bunch of forks floating around, but since it solved both my issues and @R4N's, it might be the best we can accomplish for the time being. And if in the future Xcode/SwiftPM advance sufficiently to make the forks unnecessary, we could plan to merge it all back upstream.

Thank you @marcprux, your support and checks are very much welcome!

I'm aware forking is not ideal, but it is a good step, and a good resting place. After all of this is merged on the main branch I'll update a few related discussions in order to guide users to the new recommended approach.

We'll then be able to think about the next steps, or even just wait a few years until Xcode and SPM catch up with the needs of libraries such as GRDB. Our recent work has exposed quite clearly the blockers. Apple people of good will are welcome here.

Our recent work has exposed quite clearly the blockers.

The blockers were discovered one after one in the GRBD+SQLCipher saga.

Apple people of good will are welcome here.

I personally do not plan to open any feedback about Xcode. Not any feature request/bug report about SPM. Not any discussion in the Swift Forums.

That is because I did my part of the job, and because the amount of needed work on the tooling goes beyond a mere batch of improvements. It requires intent, and a plan.

The "good will" I mention is the awareness of the blockers, a will to help GRDB, an ability to actually help, and direct contact. Lighter involvement is unlikely to raise my attention.

Glad to hear these upstream changes are working well. Should I make a separate Pull Request to include the SQLCipherCustomFork.md documentation?

This should satisfy the first step as mentioned in the previous PR: #1827 (comment)

Once this is merged into master, I think we can work on the second step:

The second step would be "GRDB+SQLCipher is officially supported at [some url]"

Let us know if you would prefer to host the official fork under your username of if you'd rather have us host it under the SQLCipher org's GitHub.

Hi @R4N!

Should I make a separate Pull Request to include the SQLCipherCustomFork.md documentation?

This is very useful documentation, and yes I'll warmly welcome a pull request that describes this alternative way to use SQLCipher :-)

Will you please wait until the next release, and things are settled? The document will have to be amended in order to reflect the last state of GRDB documentation anyway.

Once this is merged into master, I think we can work on the second step:

We'll talk about it!

⛵ Thanks @R4N, I just shipped v7.10.0 :-)

https://hachyderm.io/@groue/116075269263911686

@groue

Now that the v7.10.0 release is out there, users are starting to look towards the recommended path for using GRDB+SQLCipher SPM. We're happy to create a fork under the SQLCipher organization account and add you as a maintainer as discussed previously. This would achieve the following benefits:

• Having a central fork repository where users could get up and running quickly without having to create their own fork
• Avoid requiring each consumer to fork the repository resulting in duplicate forks with the same content
• Ensure the central fork repository is up to date as GRDB releases new versions
• Take some of the burden of support for GitHub issues/pull requests off of the core GRDB repo for issues related specifically to SQLCipher

Users who have custom requirements beyond the scope of the standard SQLCipher package could still create custom forks using the steps in the CustomSQLCipherBuilds documentation.

Let us know if you have any feedback on this approach. Thanks!

I'm not sure a merged pull request is the best place to discuss this topic. I recommend opening a dedicated discussion. A list of benefits is interesting, but I will also appreciate an exploration of the downsides of the suggested approach, with a focus on the end users. Please do not assume any outcome of the discussion until it has been sufficiently explored.