Module search mess

[Owen Taylor <otaylor redhat com>]

In http://bugzilla.gnome.org/show_bug.cgi?id=68474

Matthias writes:

    there are 4 kinds of modules which are loaded by gtk apps:

    gtk modules are searched in
    ${libdir}/gtk-2.0/modules/$gtk-version 
    ${libdir}/gtk-2.0/modules

    gtk im modules are searched in 
    ${libdir}/gtk-2.0/immodules/$gtk-version 

    gdk-pixbuf loaders are searched in 
    ${libdir}/gtk-2.0/$gtk-version/loaders

    [ Pixbuf loaders aren't really an issue since the set isn't extensible,
      we'll ignore this for the rest of the discussion  - owt ] 

    theme engines are searched in 
    ${libdir}/gtk-2.0/$gtk-version/engines
    $HOME/.gtk-2.0/$gtk-version/engines

    Shouldn't this be made more consistent ?

    a) always use the $prefix/$type/$version order of subdirectories
    b) always fall back to $prefix/$type
    c) always fall back to a $HOME location after trying a system location

Of course, this isn't the end of the disimiliarities:

    * Any locations in GTK_MODULE_PATH are searched before
      the locations listed above for modules. For these
      directories, we search first in $dir/$VERSION then
      $dir.

   * The module_path directive can be used to specify additional
     directories to search for _engines_ (not modules) before
     the directories listed above. For these directories,
     we search only in $dir.
 
   * The GTK_IM_MODULE_PATH environment variable can be used
     to specify directories that _replace_ the above directories;
     if GTK_IM_MODULE_PATH is not speicifed, the im_module_path
     RC file directive specifies directories that _replace_ the above
     directories.

Confused yet?

There is also the question of ABI-specific directories (Bug 51833).

I'd like to go with the following simple algorithm: 

 Set:

 path = $GTK_PATH ${libdir}/gtk-2.0 $HOME/.gtk-2.0
 binver = Oldest version that has backwards and forward binary compatibility
          with the current GTK+ version 
 host = host architecture (i686-pc-gnu-linux or whatever)

 To search for a module of type "$type" (type is 'engines', 'immodules',
 or 'modules')
   
 Do:

 for a in ($path)
   for b in ("$binver/","")
     for c in ("$host/","")
       look in "${a}${b}${c}/$type"

Questions:

 * Do we need some way of making the path _not_ include the standard
   locations at the end? 

 * Is removing support from the "module_path" and "im_module_path" directives
   from RC files OK? We could add a single path directive, but there
   are various complications:

    - The set of RC files parsed will be different for different 
      displays for multihead
    - RC files can be parsed at any point in program execution,
      if the module path changes the modules loaded won't correspond
      to the path any more.

 * Is having to put your modules in subdirs of the path corresponding
   to the type OK?

Regards,
                                        Owen