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)
