On Jan 23, 2020, at 5:45 AM, Dominique Devienne <ddevie...@gmail.com> wrote:
> 
> Hi. Looks like 3.31 (congrats on the release) does not include that
> small extension in the amalgamation. Could it please?

It’s easy to fix: 

1. Get the SQLite source proper (https://sqlite.org/src/)

2. Add “uuid.c” to the loop currently beginning on line 293 in 
tool/mksqlite3c.tcl. I suggest adding it down at the end where the rest of the 
extensions are listed.

3. Add “ext/misc/uuid.c” to the SRC macro in Makefile.in.

4. “make”

Now you have a sqlite3.c with the local changes you prefer.

Here’s a patch to do it with either the current tip-of-trunk or with the 
current “release” tagged version:


Index: Makefile.in
==================================================================
--- Makefile.in
+++ Makefile.in
@@ -362,10 +362,11 @@
 SRC += \
   $(TOP)/ext/rbu/sqlite3rbu.h \
   $(TOP)/ext/rbu/sqlite3rbu.c
 SRC += \
   $(TOP)/ext/misc/json1.c \
+  $(TOP)/ext/misc/uuid.c \
   $(TOP)/ext/misc/stmt.c
 
 # Generated source code files
 #
 SRC += \

Index: tool/mksqlite3c.tcl
==================================================================
--- tool/mksqlite3c.tcl
+++ tool/mksqlite3c.tcl
@@ -401,10 +401,11 @@
    dbstat.c
    dbpage.c
    sqlite3session.c
    fts5.c
    stmt.c
+   uuid.c
 } {
   copy_file tsrc/$file
 }
 
 # Synthesize an alternative sqlite3_sourceid() implementation that




The neat thing about this method is that a local patch like this can survive 
subsequent upstream changes as long as upstream doesn’t modify the code near 
these locations: just say “fossil update release” to upgrade to each subsequent 
release version, and as long as Fossil doesn’t complain about a merge conflict, 
the new release should build with your local change without complaint.



Speaking of build errors, though, I get this when doing the above on macOS 
10.14:


sqlite3.c:228541:9: warning: implicitly declaring library function 'isxdigit' 
with type 'int (int)' [-Wimplicit-function-declaration]
    if( isxdigit(zStr[0]) && isxdigit(zStr[1]) ){
        ^
sqlite3.c:228541:9: note: include the header <ctype.h> or explicitly provide a 
declaration for ‘isxdigit'


It’s complaining about the call to isxdigit() in sqlite3UuidStrToBlob() within 
the uuid.c file.  Above that in the source file, there *is* an #include for 
<ctype.h>, but in the built amalgamation, it’s commented out.  It looks like 
the amalgamation build process is somehow “intelligently” deciding that this 
file doesn’t really need to be included.

There is an include for this header higher up that looks like it could be 
pressed into service:

#if !defined(SQLITE_ASCII) || \
    (defined(SQLITE_ENABLE_FTS3) && defined(SQLITE_AMALGAMATION))
# include <ctype.h>
#endif

I’m out of SQLite-fu to work out how to adjust the build system to do the right 
thing here, short of brute force.
_______________________________________________
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Reply via email to