On Jun 5, 2018, at 2:24 PM, Roger Binns <rog...@rogerbinns.com> wrote: > > For example to exclude virtual tables from SQLite, you can't just add a > compile time option and be done. You have to regenerate from the > grammar (so it is no longer valid SQL syntax and no longer has calls to > virtual table relevant functions). And then you almost certainly want > to use the tool to make the amalgamation from the updated grammar. And > then you need to make sure your Makefile or equivalent passes in the > omit flag too.
All right, so include a clone of the SQLite Fossil repository in your application tree instead of the amalgamation and write a script to do all of this as part of the build process. That is, make the existence of sqlite3.c dependent on a successful run of this script. You can find many open source projects built this way, most often seen when the top-level configure script calls a dependency’s configure script, then the top-level Makefile calls the dependency’s Makefile at a time determined by the top-level’s declared deps. >> Contrast a language like JavaScript, where you can ship a program that has >> calls to functions that don’t exist, and as long as you continue to not call >> those functions, the JS VM won’t balk. > > You can do lazy runtime linking in some operating systems …leaving out platforms where it doesn’t work. I believe macOS and iOS are that way, for instance. Of the platforms I’ve used, the only one I’m sure allows it is Linux, and I believe I’m remembering that because of all the times it’s masked problems that showed up when I went to port some bit of software to another platform. > But in any event JS code is not distributed how you think. Ah, so? What I actually think is that one of my primary development products is based on jQuery UI, which in turn leads me to think I know how JS code is distributed in general, and how jQuery UI is distributed specifically. :) One of the options you have when using jQuery UI’s custom distributions is to include the necessary modules in your project’s tree unminified and unmerged so that you can do your own local merging and minification. Which I do. If you then mistakenly leave out a needed module, you get mysterious run-time failures. (Ask me how I know.) “Do I need focusable.js? Hmmm, I guess I’d better just try all of the UI functions and see if I get complaints in the JS error console, because the nonexistent static linker sure isn’t going to tell me!” I’ve even seen such run-time failures happen with calls that are *internal* to the merged and minified artifact because some bit of dynamic JS was being sufficiently clever that the tools couldn’t see that there was an unresolved call. >> 2. There are ways around this with C, > > My point is that it isn't. You cannot add / remove defines to the > amalgamation to omit most features. Heck if you try it just won't > compile. More work has to be done. The mailing list archives have many > messages where people tried a few compile flags and it didn't work. Yes, I’ve run into such situations several times myself. Every time it’s happened to me, I just drop the now-problematic OMIT option(s) and move on. The most recent such regression (?) for me was finding that shell.c wouldn’t build to a usable SQLite CLI binary with -DSQLITE_OMIT_AUTOINIT because it is now depending on autoinit. Thus the need for curated collections of build options, since a jQuery UI like tool that assumes the options are all orthogonal would frequently produce unbuildable output. _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
