Commit Graph

12 Commits

Author SHA1 Message Date
Yasuhiro Matsumoto 953b2322bf
bump sqlite 3.23.0
closes #545
2018-04-04 22:48:19 +09:00
Yasuhiro Matsumoto a9601262ce bump sqlite 3.22.0
closes #526
2018-02-07 19:47:10 +09:00
Yasuhiro Matsumoto e5a5361164 upgrade SQLite3 amalgamation code 2017-11-18 00:25:05 +09:00
Yasuhiro Matsumoto 95df624454 upgrade to sqlite-amalgamation-3170000 2017-02-16 15:59:24 +09:00
Yasuhiro Matsumoto ca5e381972 upgrade amalgamation code 2016-11-11 09:01:23 +09:00
Christian Brauner f6e7921d24
actually link to <sqlite3.h> when -tags libsqlite3
Building with -tags libsqlite3 used the sqlite3.h from the system but the go
compiler will compile all *.{c,h} files in the same direcory:

	"When the Go tool sees that one or more Go files use the special import
	"C", it will look for other non-Go files in the directory and compile
	them as part of the Go package. Any .c, .s, or .S files will be compiled
	with the C compiler." (https://golang.org/cmd/cgo/)

So if users actually want to link against the system sqlite3 we should make
sqlite3-binding.* a noop.

Signed-off-by: Christian Brauner <christian.brauner@canonical.com>
2016-10-28 10:28:17 +02:00
Yasuhiro Matsumoto ee996d6946 use amalgamation 3.14.0 2016-08-11 01:47:31 +09:00
Yasuhiro Matsumoto 297d6f8d2d update amalgamation code 2016-08-11 01:15:52 +09:00
Steffen 5505c7c92e upgrade sqlite amalgamation to 3.12.2 2016-05-14 11:53:28 +02:00
David Bariod 3a5555302e Move sqlite3 amalgation files a directory up.
The purpose is to ease the use of vendoring files like godep.
The C sqlite3 files have been added a go compilation conditional flag
Fix #293
2016-04-02 12:48:26 +02:00
Yasuhiro Matsumoto ee9da4840d hack to use libsqlite3
$ go build -tags "libsqlite3 windows"
2015-06-12 13:26:42 +09:00
Stéphane Graber 3d6c6f9345 Rename sqlite3.{c,h} to sqlite3-binding.{c,h}
This fixes the problem where when building with gccgo, sqlite3.c is
overwritten, leading to a build failure.

An alternative would have been to move sqlite3*.{c,h} to a subdirectory,
but that seems to confuse the linker a fair bit and would just swap one
implementation-dependent issue for another.

Closes #20

Signed-off-by: Stéphane Graber <stgraber@ubuntu.com>
2015-03-11 16:19:50 -04:00