赞
踩
SQLite是ANSI-C的源代码。在使用之前必须要编译成机器码。这篇文章是用于各种编译SQLite方法的指南。
这篇文章不包含编译SQLite的每个步骤的反馈,那样可能会困难因为每种开发场景都不同。所以这篇文章描述和阐述了编译Sqlite的原则。典型的编译命令已经作为例子提供了,以期望应用开发者能够使用这些例子作为完成他们自己定制的编译过程的的一个指南。换句话说,这篇文章提供了想法和见解,而不是交钥匙的解决方法。
融合VS单独源文件
Sqlite是由超过一百个c源码文件以及众多的目录下的脚本构建的。Sqlite的实现是纯粹的ANSI-C,但是许多C语言源代码文件是由辅助的C程序生成或者转换来的,并且AWK,SED和TCL脚本会融合到完成的sqlite库中。对Sqlite构建需要的C程序和转换和创建C语言源码是一个复杂的过程。
为了简化这些,sqlite也通过一个预打包的合并后的源码文件:sqlite3.c。这个合并文件是一个ANSI-C源码实现整个SQLite库的唯一文件。合并后的文件更容易处理。所有的东西都包含在这一个文件里,所以很容易进入一个更大的C或者C++程序的源码树。所有的代码生成和转换步骤都已经实现了,因此没有辅助的C程序需要去配置和变异,也没有脚本需要去运行。并且,因此所有哭都包含在一个翻译单元,编译器可以做更多高级的优化从而提升5%到10%的性能。因为这些原因,融合后的源码文件sqlite3.c对所有程序来讲都是值得推荐的。
推荐所有的应用程序使用融合文件。
直接从单独的源码文件中构建sqlite当然可以,但是并不推荐。对一些特殊的应用程序,可能需要修改构建程序去处理使用那些从网站上下载的预构建的源码文件不能完成的情况。对于这些情况,推荐构建和使用一个定制过的合并文件。换句话说,即使一个工程需要以单独的源码文件构建sqlite,仍然推荐使用一个融合后的源码文件作为一个中间步骤。
编译命令行接口(CLI)
构建命令行接口需要三个源码文件:
sqlite3.c:Sqlite融合的源码文件
sqlite3.h:匹配sqlite3.c以及定义sqlite的c语言接口的头文件
shell.c:命令行接口程序本身。这个c源码文件包含一个main()的例程和每轮循环的用户输入的提示符并将输入传给sqlite数据库引擎用于处理。
所有的上述源码的三个文件都被包含在下载页面的amalgamation tarball中。
为了构建CLI,简单的将这三个文件放置在相同的目录下然后一起编译他们。用MSVC:
cl shell.c sqlite3.c -Fesqlite3.exe
在unix系统上(或者在windows上用cygwin或者mingw+msys)典型的命令会有些像这样:
gcc shell.c sqlite3.c -lpthread -ldl
为了SQLite线程安全,需要pthreads库。但是因为CLI是一个单线程的,我们可以指示SQLite构建一个非线程安全的库并因此护绿pthreads库:
gcc -DSQLITE_THREADSAFE=0 shell.c sqlite3.c -ldl
-ldl库是在支持动态装载时需要,例如sqlite3_load_extension() 接口和load_extension() SQL function。如果这些特性都不要求,那么我们也可以使用SQLITE_OMIT_LOAD_EXTENSION编译时间选项忽略他们。
gcc -DSQLITE_THREADSAFE=0 -DSQLITE_OMIT_LOAD_EXTENSION shell.c sqlite3.c
有人可能想要提供其他的编译时间选项(compile-time options),例如SQLITE_ENABLE_FTS3去全文本搜索或者SQLITE_ENABLE_RTREE用于R*树搜索引擎扩展。而有人将正常指定一些编译优化开关。(预编译的CLI可以从选择sqlite网站上使用“-Os”下载下来)有无数种可能的变数在这里。
关键点在这里:构建CLI需要编译一起两个C语言文件。shell.c文件包含入口的定义和用户输入的loop,而sqlite融合文件sqlite3.c包含完整的sqlite库的实现。
编译TCL接口
sqlite的tcl接口是一个小的模块被添加到一般的融合文件中。结果是一个新的融合后的源码文件,称之为“tclsqlite3.c”。这个源码文件是生成一个可以使用TCL load命令去加载到一个标准的tclsh或者wish中,或者随着sqlite构建成功生成一个单独唯一的tclsh的共享库所需要的。一个tcl的融合的副本被包含在下载页的TEA tarball中作为一个文件。
为了生成一个Linux上的sqlite的TCL-loadable库,下面的命令需要满足:
gcc -o libtclsqlite3.so -shared tclsqlite3.c -lpthread -ldl -ltcl
不幸的是构建Mac OS X 和 Windows的共享库并不是如此简单。对于这些平台最好使用包含在TEA tarball中的configure脚本和makefile.
为了生成一个单独的tclsh,可以用于sqlite静态链接,使用如下的编译器调用:
gcc -DTCLSH=1 tclsqlite3.c -ltcl -lpthread -ldl -lz -lm
这里的技巧是-DTCLSH=1选项。sqlite的TCL接口模块包含一个main的过程,用于初始化一个TCL解释器并在以-DTCLSH=1编译后进入到一个命令行loop。上述命令可以工作在Linux和Mac OS X,虽然有时可能需要依赖于平台调整库选项以及编译的TCL的哪一个版本。
构建融合文件
下载页提供的sqlite融合文件的版本对大多数用户来说是足够的。然而,一些工程可能想要或者需要构建他们自己的融合文件。一个常见的构建一个定制的融合文件的理由是为了使用特定的compile-time options来定制sqlite库。回想sqlite融合文件中包含了许多C代码由辅助程序和脚本生成。许多的编译时间选项影响这一成圣代码而且必须在融合文件组装前提供给代码生成器。这一系列必须传给代码生成器的编译时间相关的选项会使得sqlite的发布版本各不相同,但是在写这边文章的时候,代码生成器需要知道的这组选项包括:
为了构建一个定制的融合文件,先下载原始的独立源码文件到一个unix或者类unix开发平台。确定获取的原始源码文件不是“预编译过的源文件”。任何人都可以通过到下载页或者直接从configuration management system.获取完整的一套原始源码文件。
假设sqlite源码树被存在一个名为“sqlite”的目录下。计划构建一个平行目录下的名为“bld”的融合文件。首先通过运行sqlite源码树种的configure脚本运行或者通过制作一份源码树顶层的的makfile模板的一份,来构建一个合适的makefile.然后手动编辑这个Makfile去包含需要的编译时间相关的选项。最终运行:
make sqlite3.c
在windows上使用MSVC:
nmake /f Makefile.msc sqlite3.c
sqlite3.c的make target会自动构造一般的“sqlite3.c”合并的源码文件,以及它的头文件“sqlite3.h”,和包含TCL接口的融合源码文件“tclsqlite3.c”。之后,需要的文件可以被拷贝到文件目录下然后根据上述勾勒的过程编译。
构建一个windows的动态链接库DLL
为了在windows构建一个sqlite的dll使用,首先获取对应的融合过的源码文件,sqlit3.c和sqlite.h。这些可以从SQLite website上下载或者和上述告知的一样去定制生成。
使用工作目录下的源码文件,一个dll可以在msvc中使用如下命令生成:
cl sqlite3.c -link -dll -out:sqlite3.dll
上述命令需要运行在msvc的MSVC Native Tools Command Prompt.如何你已经在机器上安装了msvc,你可能有多个版本的这种命令提示符,针对于x86和x64的自带构建的,或者交叉编译到ARM的。依赖要求的DLL去使用对应合适的命令提示符工具。
如果使用MinGW编译器,命令是这样的:
gcc -shared sqlite3.c -o sqlite3.dll
注意MinGW只生成32位的dll。另有一个分开的MinGW64工程可以用来生成64位的dll。可以推断其命令行语法是类似的。需要注意的是最近的MSVC的版本生成的DLLs可能不能工作到WinXP或者更早版本的windows上。因此为了最大限度的兼容你的生成的dll,推荐MinGW。一个好的经验法则是使用MinGW去生成32位的dlls,使用msvc去生成64位的dlls。
在大部分情况下,你会想要去哦去提供编译时间相关的选项的基本的命令来调整你的程序。通常使用的编译时间相关的选项包括:
-Os - Optimize for size. Make the DLL as small as possible.
-O2 - Optimize for speed. This will make the DLL larger by unrolling loops and inlining functions.
-DSQLITE_ENABLE_FTS4 - Include the full-text search engine code in SQLite.
-DSQLITE_ENABLE_RTREE - Include the R-Tree extension.
-DSQLITE_ENABLE_COLUMN_METADATA - This enables some extra APIs that are required by some common systems, including Ruby-on-Rails.
原文如下:
http://sqlite.org/howtocompile.html
SQLite is ANSI-C source code. It must be compiled into machine code before it is useful. This article is a guide to the various ways of compiling SQLite.
This article does not contain a step-by-step recipe for compiling SQLite. That would be difficult since each development situation is different. Rather, this article describes and illustrates the principals behind the compilation of SQLite. Typical compilation commands are provided as examples with the expectation that application developers can use these examples as guidance for developing their own custom compilation procedures. In other words, this article provides ideas and insights, not turnkey solutions.
SQLite is built from over one hundred files of C code and script spread across multiple directories. The implementation of SQLite is pure ANSI-C, but many of the C-language source code files are either generated or transformed by auxiliary C programs and AWK, SED, and TCL scripts prior to being incorporated into the finished SQLite library. Building the necessary C programs and transforming and/or creating the C-language source code for SQLite is a complex process.
To simplify matters, SQLite is also available as a pre-packaged amalgamation source code file: sqlite3.c. The amalgamation is a single file of ANSI-C code that implements the entire SQLite library. The amalgamation is much easier to deal with. Everything is contained within a single code file, so it is easy to drop into the source tree of a larger C or C++ program. All the code generation and transformation steps have already been carried out so there are no auxiliary C programs to configure and compile and no scripts to run. And, because the entire library is contained in a single translation unit, compilers are able to do more advanced optimizations resulting in a 5% to 10% performance improvement. For these reasons, the amalgamation source file ("sqlite3.c") is recommended for all applications.
The use of the amalgamation is recommended for all applications.
Building SQLite directly from individual source code files is certainly possible, but it is not recommended. For some specialized applications, it might be necessary to modify the build process in ways that cannot be done using just the prebuilt amalgamation source file downloaded from the website. For those situations, it is recommended that a customized amalgamation be built (as describedbelow) and used. In other words, even if a project requires building SQLite beginning with individual source files, it is still recommended that an amalgamation source file be used as an intermediate step.
A build of the command-line interface requires three source files:
All three of the above source files are contained in the amalgamation tarball available on the download page.
To build the CLI, simply put these three files in the same directory and compile them together. Using MSVC:
cl shell.c sqlite3.c -Fesqlite3.exe
On unix systems (or on Windows using cygwin or mingw+msys) the command typically looks something like this:
gcc shell.c sqlite3.c -lpthread -ldl
The pthreads library is needed to make SQLite threadsafe. But since the CLI is single threaded, we could instruct SQLite to build in a non-threadsafe mode and thereby omit the pthreads library:
gcc -DSQLITE_THREADSAFE=0 shell.c sqlite3.c -ldl
The -ldl library is needed to support dynamic loading, the sqlite3_load_extension() interface and theload_extension() SQL function. If these features are not required, then they can be omitted usingSQLITE_OMIT_LOAD_EXTENSION compile-time option:
gcc -DSQLITE_THREADSAFE=0 -DSQLITE_OMIT_LOAD_EXTENSION shell.c sqlite3.c
One might want to provide other compile-time options such as SQLITE_ENABLE_FTS3 for full-text search orSQLITE_ENABLE_RTREEfor the R*Tree search engine extension. And one would normally to specify some compiler optimization switches too. (The precompiled CLI available for download from the SQLite website uses "-Os".) There are countless possible variations here.
The key point is this: Building the CLI consists of compiling together two C-language files. Theshell.c file contains the definition of the entry point and the user input loop and the SQLite amalgamationsqlite3.c contains the complete implementation of the SQLite library.
The TCL interface for SQLite is a small module that is added into the regular amalgamation. The result is a new amalgamated source file called "tclsqlite3.c". This single source file is all that is needed to generate a shared library that can be loaded into a standard tclsh or wish using the TCL load command, or to generate a standalone tclsh that comes with SQLite built in. A copy of the tcl amalgamation is included on thedownload page as a file in theTEA tarball.
To generate a TCL-loadable library for SQLite on Linux, the following command will suffice:
gcc -o libtclsqlite3.so -shared tclsqlite3.c -lpthread -ldl -ltcl
Building shared libraries for Mac OS X and Windows is not nearly so simple, unfortunately. For those platforms it is best to use the configure script and makefile that is included with theTEA tarball.
To generate a standalone tclsh that is statically linked with SQLite, use this compiler invocation:
gcc -DTCLSH=1 tclsqlite3.c -ltcl -lpthread -ldl -lz -lm
The trick here is the -DTCLSH=1 option. The TCL interface module for SQLite includes amain() procedure that initializes a TCL interpreter and enters a command-line loop when it is compiled with -DTCLSH=1. The command above works on both Linux and Mac OS X, though one may need to adjust the library options depending on the platform and which version of TCL one is linking against.
The versions of the SQLite amalgamation that are supplied on the download page are normally adequate for most users. However, some projects may want or need to build their own amalgamations. A common reason for building a custom amalgamation is in order to use certaincompile-time options to customize the SQLite library. Recall that the SQLite amalgamation contains a lot of C-code that is generated by auxiliary programs and scripts. Many of the compile-time options effect this generated code and must be supplied to the code generators before the amalgamation is assembled. The set of compile-time options that must be passed into the code generators can vary from one release of SQLite to the next, but at the time of this writing (circa SQLite 3.6.20, 2009-11-04) the set of options that must be known by the code generators includes:
To build a custom amalgamation, first download the original individual source files onto a unix or unix-like development platform. Be sure to get the original source files not the "preprocessed source files". One can obtain the complete set of original source files either from the download page or directly from the configuration management system.
Suppose the SQLite source tree is stored in a directory named "sqlite". Plan to construct the amalgamation in a parallel directory named (for example) "bld". First construct an appropriate Makefile by either running the configure script at the top of the SQLite source tree, or by making a copy of one of the template Makefiles at the top of the source tree. Then hand edit this Makefile to include the desired compile-time options. Finally run:
make sqlite3.c
Or on Windows with MSVC:
nmake /f Makefile.msc sqlite3.c
The "sqlite3.c" make target will automatically construct the regular "sqlite3.c" amalgamation source file, its header file "sqlite3.h", and the "tclsqlite3.c" amalgamation source file that includes the TCL interface. Afterwards, the needed files can be copied into project directories and compiled according to the procedures outlined above.
To build a DLL of SQLite for use in Windows, first acquire the appropriate amalgamated source code files, sqlite3.c and sqlite3.h. These can either be downloaded from theSQLite website or custom generated from sources as shown above.
With source code files in the working directory, a DLL can be generated using MSVC with the following command:
cl sqlite3.c -link -dll -out:sqlite3.dll
The above command should be run from the MSVC Native Tools Command Prompt. If you have MSVC installed on your machine, you probably have multiple versions of this Command Prompt, for native builds for x86 and x64, and possibly also for cross-compiling to ARM. Use the appropriate Command Prompt depending on the desired DLL.
If using the MinGW compiler, the command-line is this:
gcc -shared sqlite3.c -o sqlite3.dll
Note that MinGW generates 32-bit DLLs only. There is a separate MinGW64 project that can be used to generate 64-bit DLLs. Presumably the command-line syntax is similar. Also note that recent versions of MSVC generate DLLs that will not work on WinXP and earlier versions of Windows. So for maximum compatibility of your generated DLL, MinGW is recommended. A good rule-of-thumb is to generate 32-bit DLLs using MinGW and 64-bit DLLs using MSVC.
In most cases, you will want to supplement the basic commands above with compile-time options appropriate for your application. Commonly used compile-time options include:
-Os - Optimize for size. Make the DLL as small as possible.
-O2 - Optimize for speed. This will make the DLL larger by unrolling loops and inlining functions.
-DSQLITE_ENABLE_FTS4 - Include the full-text search engine code in SQLite.
-DSQLITE_ENABLE_RTREE - Include the R-Tree extension.
-DSQLITE_ENABLE_COLUMN_METADATA - This enables some extra APIs that are required by some common systems, including Ruby-on-Rails.
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。