Should a developer define the SQLITE_ENABLE_USER_EXTENSION def, they would be responsible for defining an init function and providing it at link time.

Isn't this basically what SQLITE_EXTRA_INIT provides? The builder of sqlite3.o provides a function name with -DSQLITE_EXTRA_INIT=foo and must define/link in int foo(const char *). The function is always passed a NULL pointer - i'm not sure what the idea behind the string argument was.

Similarly, there's a shutdown counterpart. From sqlite3.c:

#ifdef SQLITE_EXTRA_SHUTDOWN
    void SQLITE_EXTRA_SHUTDOWN(void);
    SQLITE_EXTRA_SHUTDOWN();
#endif

That's not quite the same as your proposal, in that the function signature differs, but the EXTRA_INIT routine could install auto-extensions, which might(?) resolve your timing issues with installing auto-extensions.

Edit: of course, that approach would leave you subject to client code clearing the list of auto-extensions, so wouldn't be as bullet-proof as your proposal.

Isn't this basically what SQLITE_EXTRA_INIT provides?

Interesting. I wasn't aware of this, and yes, it provides about 90% of what I want... it would be perfect except for, as you pointed out, code that clears auto-extensions. I also like how it allows me to define the function name. Thank you for pointing it out.

I still think my idea is worth consideration, but I might look into using this to refactor some of our code.

I just saw check-in 423e77277a from Stephan that is almost exactly what is needed.

The only thing missing is a change to "makefile.in" and "main.mk" to include the user-extension in the amalgamation.

Stephan, could you add that, please?

The only thing missing is a change to "makefile.in" and "main.mk" to include the user-extension in the amalgamation.

In order to link in custom content you'd need to set that new flag when building sqlite3.c and link in your custom files. Those aren't things the canonical build files will do for you.

Or perhaps i'm misunderstanding what you're asking for?

(Note, also, that that change is preliminary. Whether or not that feature will get merged to trunk is as yet undetermined.)

Yes, a minor misunderstanding.

What I always do in builds on Linux and Termux is adding my extension as source into the amalgamation by adding it after the line $(TOP)/ext/misc/stmt.c in "makefile.in" (line 353 in trunk) and "main.mk" (line 231 in trunk).

I figured it was experimental and would not make it into 3.44 - but one can hope...

I meant 3.43 - don't want to sound to pessimistic...

I just noticed check-in fe7365254d adding this to trunk.

Unfortunately that is still missing the changes to makefile.in and main.mk that would add the extension to the amalgamation.

Could this be added?

Unfortunately that is still missing the changes to makefile.in and main.mk that would add the extension to the amalgamation.

i haven't forgotten about looking into that, but it's not on my very-near-term TODO list.

Could this be added?

If you're looking to have the literal names of your files injected into the resulting Makefile, you're probably out of luck. That would require edits to the GNU autotools scripts, and we avoid changing those unless absolutely necessary. We're limited to POSIX-make functionality for the top-level build, so cannot look for files to add at build-time via make features.

What we can easily do is add something like:

# Makefile.in:
...
SRC += \
  $(TOP)/ext/misc/stmt.c
SRC += $(EXTRA_SRC)
# main.mk:
...
SRC += \
  $(TOP)/ext/misc/stmt.c
SRC += $(EXTRA_SRC)

We'd have to convince Richard, but it seems like a potentially nice thing to have and is trivial to add.

Yes.

That is exactly what I mean.

If you could convince Richard that would be great.

That is exactly what I mean.

My apologies for having let this fall through the cracks, but it's now checked in:

$ make sqlite3.c EXTRA_SRC="my.c my-other.c"

will create sqlite3.c with the given list of EXTRA_SRC files appended to it.

I'd like to propose an idea that allows third-party extensions to be statically built into SQLite without code modifications to SQLite or third-party packages that use it.

Jay, the current trunk has your request feature: -DSQLITE_EXTRA_AUTOEXT=funcname and you must then link in funcname with the signature of an auto-extension.

(The makefile part of the request, from the responses, is still TODO.)

Browsing the source, it looks like the secret hidden parameters (pzErrMsg, pThunk) for extensions added with sqlite3_auto_extension() aren't supplied if the init function is on the builtin list. Someone wanting to make an existing extension may need to take that into account.