We've been hitting the default `MAX_VARIABLE_NUMBER` and
`MAX_EXPR_DEPTH` with quite basic tests here in Prisma. I was able to
run the tests by using the Arch Linux packaged libsqlite3, but when
turning on the bundled version I was able to get my test to crash with
this test project:
https://github.com/pimeys/sqlite_parameter_test
Now taking a look how Arch Linux builds sqlite, I was able to find two
flags fixing the issue:
https://git.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/sqlite#n35
I think it would be safe to include them in rusqlite.
This is useful because currently, when using `rusqlite` in a Cargo
workspace with one crate that uses `sqlcipher` and another that uses
`bundled`, a build error will be triggered by an unqualified `cargo
build` (as cargo will use the union of all features enabled by crates in
the workspace).
Instead of panicing, this just emits a warning, before (mostly) ignoring
that the `bundled` feature was specified. Note: in this configuration,
we still use our bundled bindings, to avoid changing `rusqlite` to
handle this edge case (hence 'mostly').
When built as a static library, sqlite (or sqlcipher) doesn't carry
additional link dependencies with it, and the libsqlite3-sys rlib
doesn't pick them up either. A dependent crate attempting to link
against rusqlite then has to specify these additional link commands,
and even then they need to be specified before the libsqlite3-sys
rlib is specified on the command line.
Fix this by attempting to use pkg-config when the
(SQLITE3|SQLCIPHER)_LIB_DIR is specified, since these builds produce
the pkg-config link dependency information, and the pkg_config crate
can automatically generate the correct link commands using that.
(Additionally, since (SQLITE3|SQLCIPHER)_STATIC is already defined,
or not, the --static flag will be correctly configured for pkg_config)
Currently `libsqlite3-sys` is the first result for both the "database"
keyword, and the "Database interfaces" category. This makes sense, as it
is a dependency of both Diesel and rusqlite. However, this library is
not intended to be used directly. While it can technically be called a
database interface, FFI is clearly the category that applies more than
anything else. Someone browsing this keyword or category is likely
looking for a Rust library they can use, not a C one.
This also required adjusting the fixup inserting `SQLITE_DETERMINISTIC` into the
bindings if it was missing. Now that `bindgen` uses the `quote` crate for code
generation, instead of `syntex`, we can't rely on the output being formatted (it
only is formatted if there is a usable `rustfmt` on the `$PATH`). Even better
than this `contains` tweak would be switching to regexps or something.
Despite that formatting hiccup, newer `bindgen` releases are more reliable due
to many bug fixes, and also build in approximately half the time that older
`bindgen` versions do.
This minor version includes some internal rearranging of constants that
should not affect the public interface, and additions to the build
system that allow the use of vcpkg on Windows.
Recent versions of bindgen use `std::os::raw` over `libc`, but currently
`libsqlite3-sys` is overriding that. `std::os::raw` is a subset of
`libc` that exports only the relevant type definitions, but not any
functions which require additional linking. This enables
`libsqlite3-sys` to be more easily used on targets that may not have a
libc available (presumably sqlite itself would have been compiled with
musl in that case)
See comment in libsqlite3-sys/build.rs for details - adding this flag is
harmless if it's not present in the header, and not having it can break
builds against older SQLite versions.
