1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
|
Instructions for importing a new release of SQLite from sqlite.org.
First, you need to be on Linux.
# Determine the versions of the release you want and the release we currently
# have. (See the VERSION file to determine which release we currently have.)
# You may wish to consult http://www.sqlite.org/changes.html to find out what
# changes have been made in each release.
# Set some variables to remember the versions, e.g.:
BASE=3.6.1
LATEST=3.6.18
# Get to the src/third_party directory in your Chromium client:
cd src/third_party
# Download the .tar.gz files for the releases:
# (If the URL changes you might need to find the new one.)
wget http://www.sqlite.org/sqlite-$BASE.tar.gz
wget http://www.sqlite.org/sqlite-$LATEST.tar.gz
# Extract the vanilla current and desired versions:
tar xzf sqlite-$BASE.tar.gz
tar xzf sqlite-$LATEST.tar.gz
# Use kdiff3 to merge the changes:
kdiff3 -m sqlite-$BASE sqlite-$LATEST sqlite
# Resolve any conflicts. Figure out if we've got everything we should
# have (see below), or if we can omit any changes we no longer need.
# Change to the sqlite directory:
cd sqlite
# Run the google_generate_preprocessed.sh script:
./google_generate_preprocessed.sh
# Find a sucker. Send review.
# TODO(shess) Describe an appropriate comment style. Seems like it
# should at least include the SQLite version number.
--------------------------------------------
For reference, all of our local patches are also kept as .patch files in the
sqlite directory. Here is a list of the patches, in the order they should be
applied to a vanilla SQLite (of the version we currently have) to get, in
principle, exactly what is checked in:
misc.patch
preload-cache.patch
safe-tolower.patch
sqlite-poison.patch
So, e.g. you could do this to apply all our patches to vanilla SQLite:
cd sqlite-$LATEST
patch -p0 < ../sqlite/misc.patch
patch -p0 < ../sqlite/preload-cache.patch
patch -p0 < ../sqlite/safe-tolower.patch
patch -p0 < ../sqlite/sqlite-poison.patch
This will only be the case if all changes we make also update the corresponding
patch files. Therefore please remember to do that whenever you make a change!
Descriptions of the changes we've made can be found at the bottom of this file.
--------------------------------------------
How to run the SQLite tests for the Chromium version of SQLite on Linux.
cd src/third_party/sqlite
mkdir build
cd build
make -f ../Makefile.linux-gcc testfixture
make -f ../Makefile.linux-gcc test > /tmp/test.log
egrep -v 'Ok$' /tmp/test.log
# When run on a locally-mounted disk, my output ends with:
# 0 errors out of 57887 tests
Scott Hess <shess@google.com>, December 11, 2007
--------------------------------------------
As of Sep 15, 2009, these are our changes from sqlite_vendor:
- fts2.c disables fts2_tokenizer().
- sqlite3Poison() in src/btree.c.
- BEGIN defaults to BEGIN IMMEDIATE in parse.y.
- Tweak to SQLITE_EXTENSION_INIT* in sqlite3ext.h.
- That implied a change in src/test_autoext.c for testing.
- Added fts.test and fts1.test in tests, modified quick.test.
- src/os_symbian.cc.
- Modifications to Makefile.linux-gcc and main.mk for compiling
SQLite tests.
- Compile warning (cast to void* for sqlite3_free) fixed in func.c.
- Avoid using tolower() in fts code which causes problem in some locales, see:
safe-tolower.patch
http://crbug.com/15261
http://www.sqlite.org/src/tktview/991789d9f3136a0460dc83a33e815c1aa9757c26
Changes from Chrome:
- I marked all changes I made with "evanm", so you can find them with
"grep evanm *".
- Most files include sqlite3ext.h with SQLITE_CORE #defined, but two don't:
fts2_tokenizer.c and icu.c. Without this #define, the calls in
fts2_tokenizer.c try to go through some pointer to the sqlite API instead
of calling the functions directly (to work as a loadable module), but then
crash (because the other files never initialize that loadable module
support). As a hack I #defined it in these files, but it'd be nice to
figure out what really ought to happen here (perhaps this file is new and
hasn't been tested to verify it works right). Update: Seems this is an
issue we get because we're using fts2 instead of fts3.
- shell_icu_win.c and shell_icu_linux.c are Chrome-specific files used to load
our ICU data. shell.c has been modifed to call into these files.
- fts2_icu.c has a critical bug. U8_NEXT is used over a UTF-16 string. It's
rep$ by U16_NEXT (jungshik)
- Added a new function sqlite3Preload we use to prime the database cache. It
allows much faster performance by reading the file in one contiguous
operation rather than bringing it in organically, which involves a lot of
seeking. This change also required sqlite3PcacheGetCachesize to be compiled
even outside SQLITE_TEST.
- Added a new function chromium_sqlite3_initialize_win_sqlite3_file()
at the end of os_win.c. It allows the Windows-specific Chromium VFS
to reuse most of the win32 SQLite VFS.
- Added a new function initUnixFile() and made fillInUnixFile()
non-static in os_unix.c. It allows the Linux-specific Chromium VFS
to reuse most of the unix SQLite VFS.
|
