new modules and how to host or publish them

[coreyapowell]

I want to know if and how it's practical for people to publish "stock" quickjs modules. I've looked at the projects using quickjs-ng, but they're not publishing sock modules for use with the module loader. They're suites. They seem to be replacing qjs if I understand. I would just like to host simple stock modules for the module loader, and maybe some example code of the stock QuickJS system so that everyday users might could find use for these tools. QJSC looks like an entire suite if there were actual libraries to use, similar to LLVM.

For instance: I have a socket module that I have working with Bellard's version. That's exactly how I found this group, because you've gotten the DLL code working. But before that, I had 2 options. I can load the .so file in linux, but code also works if I tack it onto the end of quicks-libc.c. I have to add the module_init typedef and call my module_init in qjs.c, but this ultimately required modifying 3 source files. I don't want to put that on github! That was just to understand his macros and verify the code. Next I had the .so working, and I have written script to manually take his files and links them for my needs, and I can get an .so file of my own. I'm just now getting your examples to build. It didn't work the same way with Bellard's version; I'm just now getting your build system to make the examples (with the -D option in CMAKE) . Right now I have to manually handle my building, and my linking, and I'm realizing that there needs to be a default "build my module" cmake file for all of these environments or something. So far I'm just manually calling the different linkers, but I have to tack onto your system and trap the output to know what those link commands are supposed to be. That's what I've had to do with Bellard's, and now it's changed. It's not that intuitive.

I'm not just asking how to make my build script in this post. I can get it to build at my house. I'm asking if there's a clean way of doing this than maintaining multiple build environments (that might not work together). If a simple javascript programmer with some idea of c wants to own and use a module, is there a set of non-intrusive instructions for the lay person? If I want to host some example code and a simple module, to load externally, for the average user, how much instruction and build maintenance is required? Is your project at the "install path and include library" status? Like the standard GNU libraries? Or is this a niche market for hardcore C programmers who embed this in their own products? I'm just looking to make life simple and accessible.

Also, and this could be a separate discussion, but the module loader code is in quickjs-libc, along with the std and os modules. When I link against the qjs library, my module (.dll or .so) is quite large! If I understand, it contains .std and .os. That's why I opted to build one big library, but that method would still requires editing the source code or something; my module is no longer in a path to load. I only need the quickjs.c, not the qjs.c ... right? Is it not feasible for os and std modules to be separated from the loader and the core? I'm just wondering if seasoned users have better solutions on their end, or if I'm misssing the point somewhere? I was linking all of Bellard's .o files into one library or one dll, and I was able to embed, and that freed a lot of the size. If I understand this correctly, we're not just linking to the import and export functions of the dynamic library, we're embedding the static core into each module? My module doesn't execute it's own javascript core, does it? Or does it just carry a duplicate core around?

[bnoordhuis]

quickjs is primarily a library intended for consumption by downstream projects. qjs is more of an afterthought, a toy shell; it's not the primary product. The common case is you a) build quickjs and your project with cmake or meson, or b) drop quickjs-amalgam.c + quickjs.h (and optionally: quickjs-libc.h) in your project.

Publishing modules: it sounds like the .so loader is what you want. If you don't want to depend on quickjs-libc, the loader is literally nothing more than this:

union { void *p; JSModule (*f)(JSContext *, const char *); } u;
void *h = dlopen("foo.so", RTLD_NOW|RTLD_LOCAL); // error handling elided
u.p = dlsym(h, "js_init_module");
u.f(ctx, "foo"); // name of module

We could theoretically break that out into a separate module but, as it performs I/O, it conceptually belongs in quickjs-libc. Breaking it out also wouldn't help other downstream users because they either use quickjs-libc, or they do something much fancier and bespoke.

[coreyapowell]

I think you've answered my questions.
I don't know why I was thinking the QJS executable provided its own link tables to the client. Before I've worked with WSH COMSs that both ends (the script host and the component servers) provide a Dll; those both use an interface to poll for names and type properties and fill in a VTable. So my module calls the functions like JS_NewInt32, and they get their linkage from the library. Well that library has to be current and maintained? To work between different compile setups? That's sort of where COM has a complex framework of multiple versions so that programmers have announced any differences to their controls and registered them. Thats where my questions are fuzzy, because I'm wondering if there's any mechanism besides compiling all the modules together with the library.
I am thinking, I would at least want a Cmake example, and that gets into how the end user would compile their QuickJS library. It just seems like a "stock" module would be a chunk of includable code and that's it. It's an FFI, it's not a ClassFactory, and it's Open Source.