Changes to SQLiteData to make it compile on Linux

[thinkpractice]

Hi all,

Like we were discussing on Slack, I forked a version of SQLiteData to make it build on Linux, see here. @stephencelis asked me to move the discussion here.

The package itself compiles, but I had to bump the swift version to 6.2.3. I have to investigate if this is a SQLiteData specific issue, or something related to GRDB. Will look into this later.

To make GRDB compile on Linux, I had to disable all WAL related features as they are not available in the standard libsqlite-dev that is provided by the Linux package managers. I also had to write some Linux specific code, especially related to the absence of some functions in Foundation on non-Apple platforms. Also some initializers have different signatures. These changes have landed in GRDB version 7.10.0. This is the version I used to get SQLiteData compile on Linux.

I'd like to start fixing the unit tests of SQLiteData now to fix the Linux build completely. Which branch should I fork for that, main?

I also would like to know if it would be worth creating a version of SQLiteData/GRDB where WAL is enabled. For this, we would need to create a custom build of libsqlite-dev and also of GRDB and then of course also of SQLiteData. What advantages would this have? And would you be interested in adding such a custom build? If so, I will start discussing this over at the GRDB repo, where these changes need to be made first.

kind regards,

Tim

[pratikrath126]

Great work on the Linux port @thinkpractice! Dealing with Foundation differences and GRDB dependencies on non-Apple platforms is always a bit of a puzzle.

Regarding WAL, it definitely helps with concurrency in some high-load scenarios, but for a first pass, getting the core unit tests green on the standard system sqlite is a huge win. Usually, for projects like this, forking from is the safest bet unless there's a specific development branch active. Looking forward to seeing that PR!

[stephencelis]

@thinkpractice Thanks for looking into this! If the main blocker is missing #if canImport(CloudKit) for the sync engine, we're totally up for a PR! We would have been notified of this regression had CI been on for Linux, but we disabled it when GRDB had an incompatible release:

sqlite-data/.github/workflows/ci.yml

Lines 56 to 72 in 65502ac

	# NB: GRDB 7.6.1 does not currently build on Linux.
	# linux:
	# name: Linux
	# strategy:
	# matrix:
	# swift:
	# - '6.1'
	# runs-on: ubuntu-latest
	# container: swift:${{ matrix.swift }}
	# steps:
	# - uses: actions/checkout@v4
	# - name: Install Build Dependencies
	# run: |
	# apt-get update
	# apt-get install -y libsqlite3-dev
	# - name: Build
	# run: swift build

You could try bringing back CI to validate these changes in a PR and we would be grateful to help push things forward!

[thinkpractice]

@stephencelis yeah indeed, but actually most of these #if canImport(CloudKit) statements were missing in the unit tests, if I recall correctly. Hope I have some time next week to look into it and create a PR. Would it be ok to fork the main branch then, or do you have another preference?

[stephencelis]

Yup! We use the main branch for development.