STATIC/SHARED/MODULE in add_library override BUILD_SHARED_LIBS, which in turn seems to default to false. Therefore I think it may be a bad idea to hardcode add_library(... SHARED ...) in CMakeLists.txt files in general. We may want to instead use some wrapper function in dist.cmake that will select either shared or static based on a global user preference. Sometimes both are even wanted, which sometimes complicates things.

Also note that some toolchains (e.g. sdcc -- sdcc.sourceforge.net) don't support building shared libraries, so it will force STATIC regardless, as this cmake warning shows: "ADD_LIBRARY for library foo is used with the SHARED option, but the target platform supports only STATIC libraries. Building it STATIC instead. This may lead to problems."

The above concerns C libraries in general. Statically linking modules for any language we support (e.g. Lua) is a separate question. Probably we would want some mechanism to package.preload them in linit.c (note: the 5.2 version handles this more correctly). I'm thinking the compilation order would be this: (1) build a vanilla interpreter without modules, (2) build static libraries of modules, and (3) build another interpreter using #2. Step #3 can be repeated any number of times (as different variants) for various combinations of #2, and you may iterate back-and-forth between #2 and #3. Related possibilities include compiling source modules to C libraries via bin2c for linking in #3 as a single file, like various bundling utilities have done, so this overlaps those efforts. Anyway, I don't see obstacles here provided each static library publishes the package names of its modules and the symbol names of its registration functions in some standard way (actually you can probably infer the latter from the former, and the former are already in the CMakeLists.txt).