Re: [Ekiga-devel-list] HEAD has issues...

[Julien PUYDT <jpuydt free fr>]

Craig Southeren a écrit :
> On Sun, 10 Sep 2006 11:33:44 +0200
> Julien PUYDT <jpuydt free fr> wrote:
>
> > Julien PUYDT a écrit :> Julien PUYDT a écrit :>> Craig Southeren a écrit :>>>>> It could be the plugin code looking for plugins, if the PWLIBPLUGINDIR>>> environment variable is set weirdly>> I think it's the plugin code> > Here it is, from src/ptlib/common/pluginmgr.cxx :> > PStringArray PPluginManager::GetPluginDirs()> {>    PString env = ::getenv(ENV_PWLIB_PLUGIN_DIR);>    if (env == NULL) {>      // env = P_DEFAULT_PLUGIN_DIR;>      PString execDir = PProcess::Current().GetFile();>      PINDEX sepLoc = execDir.FindLast(PDIR_SEPARATOR);>      if(sepLoc != P_MAX_INDEX){>          execDir = execDir.Left(sepLoc);>      }>      env = execDir + DIR_SEP + P_DEFAULT_PLUGIN_DIR;>    }> >    // split into directories on correct seperator>    return env.Tokenise(DIR_SEP, TRUE);> }
> > What it should do is :- get the env variable ;- if it's set, use that ;- if it isn't :   - build a list from :     - the P_DEFAULT_PLUGIN_DIR, which *MUST* be a single absolute directory path ;     - a more local directory, which will be found from the home dir on unix-likes, and from the exec dir on win32 (but won't be all of that dir -- probably some env = homedir + DIR_SEP + ".pwlib" + DIR_SEP + "plugins"!)
> > Would that fly ?
>
> I don't see any benefit in restricting P_DEFAULT_PLUGIN_DIR to be a
> single path - why can't it be a list of paths?

Good question. Hmmm... I would say it should be a single path because 
it's hardcoded, and hence should point to the default plugin location 
when pwlib is installed. All other paths (home directory, user-defined 
locations) are more dynamic and hence can't be hardcoded.

> Here is what the current code does:
>
> a) If PWLIBPLUGINDIR is set, set the plugin search path to this value
> and go to step d)
>
> b) Get the directory containing the executable and put that into the
> plugin search path

This is bad on non-win32.

> c) Append the value of P_DEFAULT_PLUGIN_DIR to the search path

This appending looks wrong.

> d) Assume the plugin search path is a list of directories and search
> each directory recursively.
>
> The differences between Unix and Windows are:
>
> - The seperator between path elements is ":" on Unix and ";" on Windows

DIR_SEP is nice to handle that.

> - The default value for P_DEFAULT_PLUGIN_DIR is "C:\PWLIB_PLUGINS" on
> Windows and ".:/usr/lib/pwlib: on Unix
>
> The easiest way to search a user-specific search path for plugins is to
> ask the user to set the PWLIBPLUGINDIR variable to $(HOME)/pwlib_plugins.
> However, I guess we can add parsing to this code so that we can specify
> "~/pwlib_plugins" or some such, where "~" corresponds to the users home
> directory.

The easiest for us. Most users are unable to set an environment 
variable. And remember that on unix, setting PWLIBPLUGINDIR in a shell, 
makes it available only in that shell!

We should check if freedesktop.org has a specification for such things 
(it has one for configuration options), as it's probably the sanest 
thing to use on unix-like systems.

> I agree that removing "." from the default plugin path for Unix is
> probably a good idea as users often run programs in a directories that
> have large sub-trees. It was removed from the Windows default value for
> that very reason.

Then I would say : let's remove it from cvs right now, as a quick fix to 
the issue, while we get to think about a sane replacement for that scheme.

You mentioned writing new code for plugin searching (which seemed to 
have something to do with the H.263 plugin) ; could you be more specific?

Snark