We add an explicit "buildtime_bindgen" to the "session" feature, rather
than just relying on the transitive "session" -> "preupdate_hook" ->
"buildtime_bindgen", to proof against possible future changes.
This just using them in patterns without a catchall. I left things alone
that seem very unlikely to change (`Value`, `ValueRef`, `DatabaseName`,
etc...). This might help reduce the number of breaking changes we need
(rusqlite is still pre-1.0 so it doesn't really matter that much, but
breaking changes complicate the story around when we can cut releases).
This is essentially to get a release out that contains `in_gecko` so
that this library can be used in firefox.
Note: This had temporarially been 0.18.0, but as noted in
https://github.com/jgallagher/rusqlite/pull/619#discussion_r370435032
there isn't an actual need for this, as it isn't a breaking change.
By releasing it as 0.17.2, we can still link rusqlite 0.21 against it,
which lets us avoid needing to cut a release of rusqlite just for a
gecko-specific linkage flag (I imagine there are a few more rusqlite
features we'd want for the next release).
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)
