Build a shared library and install headers

[satta]

I am curious why luau does not build a common shared library so one can package/update it separately from whatever project uses it? That's how it's done in the reference Lua and LuaJIT. Luau seems to only build static archives and hence needs to be linked statically. Any idea why -- is that by design or did the use case just not come up?

I'm looking to package Luau for Debian and only shipping static libraries is kind of frowned upon, since that would mean that an update of the library would need rebuilds of everything that depends on it if there are only static libraries.

I (and maybe others as well) would prefer to have a clear, installed set of library and headers (maybe also pkgconfig info etc) that would make Luau as a library immediately usable as most developers would expect it, with the least amount of surprise.

[zeux]

This mostly just didn't come up. All production applications that use Luau so far ship with statically linked library I believe.

A couple things to know off the top of my head:

• Luau currently doesn't have a completely set ABI for VM. Our API should be source-level stable by now, but we occasionally make changes that break ABI while preserving API via macros for example. I am not sure what that does to SONAMEs et al for packaging; this doesn't happen often but it does happen, and we don't really want to use major version of the actual releases to indicate ABI level compatibility.
• I briefly tried to do shared library builds out of curiosity a few months ago and we had issues around CodeGen component integration, in that it wasn't possible to compile Luau.VM and Luau.CodeGen as separate shared libraries because CodeGen relied on a host of internal symbols that VM defined but didn't officially export. fyi @vegorov-rbx - I was thinking about either moving NativeState to VM and exposing that through a separate function (eg lnative.cpp/h) that we export, or about exporting all functions CodeGen relies on but we'd need a way to actually test that the exports are complete in that case. We could also technically export all internal functions although that doesn't feel great either.