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)
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.
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.
* If SQLITE3_LIB_DIR is present in the environment, we use that.
* If SQLITE3_LIB_DIR is not present, we try to use pkg-config.
* If SQLITE3_LIB_DIR is not present and pkg-config fails, we fall back
to /usr/lib (if it exists).
