Re: Introspection: mapping system-wide repository IDs to files

["Gustavo J. A. M. Carneiro" <gjc inescporto pt>]

  Some more thoughts and a patch at
http://bugzilla.gnome.org/show_bug.cgi?id=313268

  Cheers.

On Mon, 2005-08-01 at 22:40 +0100, Gustavo J. A. M. Carneiro wrote:
>   Hello,
> 
>   I was looking at the following TODO item in the gobject-introspection
> module:
> 
> Repository
> ----------
> [...]
> - Think about a system-wide repository mapping namespace ids to
>   libraries/metadata files
> 
>   From my point of view, to get introspection stuff moving forward this
> needs to be addressed first, so I'd like to have a go at this.
> 
>   First let me try to enumerate some goals:
> 
>     API requirements:
> 	- We need a function to return a repository corresponding to a
> namespace ID;
> 
> 	- The above function should also dlopen (or g_module_open) the
> corresponding shared library;  If the girepo library doesn't do this,
> the bindings will have to do it in a ad-hoc fashion, so it's better to
> do it here, I think.
> 
> 	- I would be interesting to have a function to list available metadata
> namespace IDs, but I think this is not really essential;
> 
>     Misc. requirements:
> 
> 	- It should be possible to simply drop a metadata file into a
> directory, or one of a set of directories, to make it available to the
> repository system.  Why? Because it makes the job of makefile writers
> and packagers so much easier.
> 
> 	- Mapping namespace IDs should not require opening any metadata files.
> This means that the namespace IDs should be encoded in the file name.
> Why?  To avoid the overhead of opening all the metadata files available
> in the system.
> 
> 	- The repository system should lookup multiple directories, following a
> PATH-like environment variable, plus a couple of system-wide defaults
> (eg. /usr/... and /usr/local/...).  Why?  Since the user already can
> tweak the library search path, for local installations (eg. jhbuild), he
> should be allowed to tweak the metadata path accordingly, otherwise he
> gets inconsistent metadata for library.
> 
> 	- The metadata file should be opened in shared read-only mmap mode, to
> reduce the overhead.  I think glib already has a mmap API..
> 
>     Proposal:
>        API:
> 	- void g_irepository_load_namespace (GIRepository *repo, const gchar
> *namespace);
> 	
>        File mapping:
> 	- I propose that metadata file names are simply g_strdup_printf("%
> s.gimeta", namespace), although I don't care much about this particular
> extension, it's just an example;
> 
> 	- For search path, we have to consider at the same time how are we
> going to find the shared libraries corresponding to each metadata file.
> I'm unsure about two alternatives:
> 
> 	    a) We could decide to keep metadata files always in the same
> directories as their corresponding shared libraries, like libtool .la
> files; I know they are architecture-independent (I think), but it's very
> convenient to easily find the shared libraries.
> 
> 	    b) The alternative is to record into the metadata files themselves
> the full path to their corresponding shared libraries.  But this would
> make the metadata files actually architecture-dependent, so we might as
> well revert to the simpler approach a).
> 
> 	Even in apprach a), although the compiler and linker already know
> pretty well how to find shared libraries, in linux at least, since we
> want portability I think we'll need our own environment variable to let
> us agument the search path.  The search path could contain the hardcoded
> path to where libgobject is installed, plus a variable like
> GIREPOPATH=/foo:/bar.
> 
>   I'd love to hear some comments, or even alternative suggestions, to
> get this stuff moving again.
> 
>   Regards.
> 
-- 
Gustavo J. A. M. Carneiro
<gjc inescporto pt> <gustavo users sourceforge net>
The universe is always one step beyond logic