New uuid extension in amalgamation

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

New uuid extension in amalgamation

Dominique Devienne
Hi. Looks like 3.31 (congrats on the release) does not include that
small extension in the amalgamation. Could it please? Uuids are fairly
common in many schemas, so native support "by default" would
standardize support for them in the SQLite ecosystem. Thanks, --DD

PS: And we'd be able to retire our own functions, which are
inconveniently not available from the SQLite shell unless explicitly
loaded from our custom extension lib.
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: New uuid extension in amalgamation

Warren Young
On Jan 23, 2020, at 5:45 AM, Dominique Devienne <[hidden email]> 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
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users