GNOME Bugzilla – Bug 622071
[importer] Allow native modules in gjs.so
Last modified: 2010-06-23 03:02:38 UTC
Allow native modules to be registered inside gjs.so. This will be used by a few modules like sys (needs argv) and byteArray (exports internal api to gi)
Created attachment 164075 [details] [review] [importer] Allow native modules in gjs.so
Review of attachment 164075 [details] [review]: I'm missing a bit of more context of what this patch actually does. Where's the code using this new feature? ::: gjs/importer.c @@ +565,3 @@ } + if (import_native_file(context, obj, name, NULL)) { + /* First try importing an internal module like byteArray */ What is this actually doing? How does that actually end up importing an internal module? For instance, what would be the 'name' arg value in that case? ::: gjs/native.c @@ +96,3 @@ { GjsNativeFlags *flags_p) + GModule *gmodule = NULL; How's this related to this patch? Fix this in a separate patch?
import_native_file() with a file name to NULL will assume that the type is already registered (present in internal import hash tables) instead of calling g_module_open on a shared library. The GModule change is necessary, since when we pass in NULL there's no longer a GModule* around, we need to test for that below. I just realized that we could call g_module_open on the fly on ourselves (eg NULL) instead of assuming that the module is registered, but that requires that we pass in -module and -rdynamic to the linker, I think.
Oh, ok, I missed the obvious part where byteArray is built into gjs in the patch in bug 571000. Ok, but where is importer used with filename null?
Ok, I got a bit confused initially because this patch adds a feature but adds no code using it. Managed to understand it when I read the patches on bug 571000. I'd like to see a more comment explicit comment on why/when filename might be null. Looks good otherwise.
Attachment 164075 [details] pushed as 7045f3f - [importer] Allow native modules in gjs.so