Re: GtkModule fixes
- From: Tim Janik <timj gtk org>
- To: Owen Taylor <otaylor redhat com>
- Cc: Gtk+ Developers <gtk-devel-list gnome org>
- Subject: Re: GtkModule fixes
- Date: Tue, 28 Aug 2001 19:37:49 +0200 (CEST)
On 28 Aug 2001, Owen Taylor wrote:
> Tim Janik <timj gtk org> writes:
> > if we'd want to, in this case, have GLE install itself into
> > /opt/lib/gtk-2.0/GTK_MAJOR.GTK_MINOR.(GTK_MICRO - GTK_BINARY_AGE)/modules
> > it probably needs a way to tell the instaleld gtk to look into that
> > directory for modules as well.
> > i don't think we invented a new problem here however, how are such things
> > handled with compliance to fsstnd for other packages? say xmms with
> > all the add-on modules that can be installed?
> Well, the fssstnd is unlikely to say anything about this ... it's
> really about where system vendors should put things. And system
> vendors will put things in the standard location.
> I think a path environment variable works fine ... the only question
> is how you handle versioning. Is it:
well, this sucks majorly if you need it for invocation of every gtk program.
instead, something like:
is probably a better idea, gtk_main() can parse that if it needs to load modules,
and modules should add/remove their paths to/from that file upon (de-)installation.
the remaining question is how to get them to sanely update that file, do we
want another gtk-conf-modulepath executable script that has --add and --remove
> And then we look into GTK_MAJOR.GTK_MINOR.(GTK_MICRO - GTK_BINARY_AGE)/modules
> inside each path element? This would require a pkg-config variable
> for GTK_MAJOR.GTK_MINOR.(GTK_MICRO - GTK_BINARY_AGE).
> I wonder if we should turn things around and use:
> /opt/lib/gtk-2.0/modules/GTK_MAJOR.GTK_MINOR.(GTK_MICRO - GTK_BINARY_AGE)
yes, that's more usual actually.
> instead ... the intermediate location for the version is rather odd
> for a path.
] [Thread Prev