[RTEMS Project] #3927: tclsh required to build sqlite -- makes all BSP bsets fail

[RTEMS trac]

#3927: tclsh required to build sqlite -- makes all BSP bsets fail
---------------------------+--------------------------
 Reporter:  Joel Sherrill  |       Owner:  Chris Johns
     Type:  defect         |      Status:  assigned
 Priority:  normal         |   Milestone:  5.1
Component:  tool/rsb       |     Version:
 Severity:  normal         |  Resolution:
 Keywords:                 |  Blocked By:
 Blocking:                 |
---------------------------+--------------------------

Comment (by Joel Sherrill):

 Advice from Jonathan Brandmeyer
 (https://lists.rtems.org/pipermail/devel/2020-April/058905.html).

 ----
 We just copied the amalgamation's single .c and .h file into our
 repository and built it as a single object into our application.  So the
 following recommendations come only from an amateur reading of the sources
 on current rtems-source-builder master.

 3.8.8 is pretty old.  I'd just jump straight to 3.30.1, the current
 release.

 Instead of downloading the sqlite-src zip, download sqlite-amalgamation or
 sqlite-autoconf and use that as a base.  I think the bset's configuration
 invocation is OK, except that I would set different CFLAGS as described in
 the next couple of paragraphs.  See also
 https://sqlite.org/amalgamation.html

 By default, the SQLite write-ahead-log relies on mmap to share some of its
 index structures between multiple processes.  It looks like the current
 RTEMS bset disables the WAL entirely.  Using the WAL gives much better
 performance than the rollback journal for write-intensive use cases.  We
 used SQLite to reliably buffer up and stitch together segments of our
 field software update process, which fits the WAL very well.  We set
 `-DSQLITE_MAX_MMAP_SIZE=0 -DSQLITE_DEFAULT_LOCKING_MODE=1` at compile time
 to avoid mmap's use since RTEMS has neither a VMM nor multiple address
 spaces.  It is still up to the application to choose either the WAL or the
 rollback journal.  See also https://sqlite.org/wal.html#noshm

 We also added -DSQLITE_ENABLE_MEMSYS5 to our build, and used it to give
 SQLite its own memory spaces to operate on distinct from the rest of our
 application.  We explicitly provided it with its own MEMSYS5 heap, page
 cache, and lookaside pools.  RTEMS just needs to add the correct compile-
 time option to support this functionality.  It is still up to the
 application to configure and monitor those memory pools at runtime.  See
 also https://sqlite.org/malloc.html

 ----

--
Ticket URL: <http://devel.rtems.org/ticket/3927#comment:1>
RTEMS Project <http://www.rtems.org/>
RTEMS Project