= SQLite =


'''Status:''' Exploratory

SQLite was originally designed to be an embedded database for on-board guided missile destroyers, for the US Navy ''The Definitive Guide to Sqlite By Michael Owens''.  Unlike many database program, SQLite is designed to be an itegral part of the embedded system. SQLite doesn't use interprocess communication, which makes it much faster than a database system that does.
=  Porting SQLite to RTEMS  =

This is a very rough first stab at porting SQLite to RTEMS.  It's designed to help a developer that might be interested in designing the [http://www.rtems.org/wiki/index.php/RTEMS_DBKit RTEMS_DBKit]... 

''Note: there is room to port a stable release...''

I also used the [http://www.rtems.com/wiki/index.php/RTEMS_Add-On_Packages RTEMS Addon Packages] to get the necessary configurations to build on rtems.
=  Development Repository Editon SQLite  =


To build SQLite from the development repository, you need TCL and fossil. TCL is part of the SQLite build system, while fossil is another version control system.

 ~$ sudo apt-get install tcl8.5 fossil

SQLite uses fossil for their development branch, so if you use their development branch, you have some steps to go through:

First, check out a "fossil" which is a single file with all the information

 ~/rtems-addon-packages$ fossil clone http://www.sqlite.org/cgi/src/dir trunk.fossil

Second, make and navigate into an sqlite directory:

 ~/rtems-addon-packages$ mkdir sqlite
 ~/rtems-addon-packages$ cd sqlite

Third, open the fossil file

 ~/rtems-addon-packages/sqlite$ fossil open ../trunk.fossil

Fourth, archive the sqlite folder (so you have an old copy to fall back on)...
 ~/rtems-addon-packages/sqlite$ cd ..
 ~/rtems-addon-packages$ tar -acf sqlite.fossil.tar.bz2 sqlite

DO NOT close the fossil file! It will remove manifest.uuid and not compile!
=  Makefile.sqlite  =


Just figured out how to get SQLite to compile!
First, the sqlite command shell executable may NOT be necessary, which bypasses the need to figure out how to implement popen and pclose.  To NOT build the command shell executable, I looked at the Makefile, and built the non sqlite3 make targets.  Namely, lib_intall, and the sqlite3.h.

To avoid sys/mman.h dependency, I looked for sys/mman.h

 $ grep -r "sys\/mman.h" rtems-addon-packages/sqlite

and found that defining SQLITE_OMIT_WAL would eliminate the mmap/munmap dependency.

I copied the Makefile below into rtems-addon-packages/RTEMS_Makefiles/Makefile.sqlite
{{{
#
# Configure/build/install the sqlite library
# -DSQLITE_OMIT_WAL removes mman dependency
# -DSQLITE_ENABLE_COLUMN_METADATA taken from sqlite/mkso.sh
# --disable-largefile makes a library for a 32-bit target on a 64-bit host
# --disable-amalgamation keeps the source code in separate files for the build
# copy the public header to the include directory
# finally, install the library

include ../RTEMS_Makefiles/Makefile.common

all:
	CFLAGS='-DSQLITE_OMIT_WAL=1 DSQLITE_ENABLE_COLUMN_METADATA=1'
	../sqlite/configure \
		--prefix=$(exec_prefix) \
		--build=i686-linux-gnu \
		--host=i386-rtems4.11 \
		--disable-largefile \
		--enable-cross-thread-connections \
		--disable-tcl \
		--disable-readline \
		--disable-amalgamation \
		--libdir=$(exec_prefix)/$(RTEMS_BSP)/lib \
		--includedir=$(exec_prefix)/$(RTEMS_BSP)/lib/include
	make sqlite3.h libsqlite3.la
	cp sqlite3.h $(exec_prefix)/$(RTEMS_BSP)/lib/include
	make lib_install
}}}

Another option is to comment out all the references to handle pipes in sqlite/src/shell.c then, make && make install.
=  rtems-addon-packages/network-demos/Makefiles  =


When adding commands to a shell from a legacy library:
# Link the library to EVERY application using the shell
# Write a script to tear down and rebuild the kit, and use it at every small change

 rtems-addon-packages/network-demos$ nano doit.sh

 make clean
 make
 qemu ...

Linking libraries (please see OpenLDAP on rtems.org)
=  Testing Ideas  =

# Link the SQLite library using a Makefile.
# Use [http://www.sqlite.org/cintro.html An Introduction To The SQLite C/C++ Interface] as a guideline for the test.
So the idea would be to:
# Open the database
# Prepare the SQL statement for processing
# "Step" through the results, in this case, an insert (or make table?) would be awesome!
# Some simple column statement
# Finalize (delete) the prepared statement
# Close the connection.
So, a test would look like:
 /* SQL Test */
/* Database initialization */
 printk("Opening the Database\n");
 sqlite3_open(filename, &ppDb, flags, &zVfs);
 
 printk("Preparing the SQL Statement\n");
 sqlite3_prepare_v2(&db, &zSql, nByte, &ppStmt, &pzTail);

 printk("Stepping through the Results\n");
 sqlite3_step(&ppStmt);

 printk("Counting the number of columns...");
 nCols = sqlite3_column_count(&ppStmt);
 printk("and the number of columns is %d\n", nCols);

 printk("Deleting the SQL Statement\n");
 sqlite3_finalize(&ppStmt);
 
 printk("Closing the Database");
 sqlite3_close(&ppDb);
=  Next Steps  =

# Write an SQLite demo
# Work on other database programs in the RTEMS_DBKit
=  End of Report  =

I'm truly amazed that SQLite had configurations that removed the multiprocessing, and memory mapping requirements!
=  = References ==