The auto-generated bindgen layout tests are architecture dependent and
cause breakage on 32-bit platforms at least.
Note that this does not yet remove the layout tests from
bindgen-bindings/bindgen_*.rs -- i'm not sure how those are generated.
Addresses: #722
SecurityFoundation.framework is an unrelated macOS framework which does not directly provide cryptography functions. This framework also doesn't exist on iOS, which breaks linking This commit changes to link against Security.framework instead, as noted in the SQLCipher docs [1].
[1] https://www.zetetic.net/blog/2013/6/27/sqlcipher-220-release.html
Enables compiling bundled sources with different flags.
Env variable name modeled after LIBSQLITE3_SYS_BUNDLING.
May want to println!("cargo:warning=...") instead of panicking.
Cargo itself changes the PATH.
So `libsqlite3-sys` is always rebuilt on Windows platform.
To avoid this, we ignore PATH change.
If the PATH has been modified in such a way that a different SQLite library is found,
you will have to also modify SQLITE3_LIB_DIR to make cargo rebuild `libsqlite3-sys`
Fix#435.
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)
