[Scummvm-devel] Adding support for selecting a 'pluginpath' on the command line?

[John Willis]

Hi Max,

> You could simply put the equivalent of
>  #define PLUGIN_DIRECTORY "../plugins"
> somewhere, e.g. in configure add a -D for it to DEFINES..

Hmmm, in 'over' thinking this I had missed the really simple solution ;).
 
> I would recommend doing that in any case, so that it works even if the
user
> (hypothetically) tried to start the game from the command line and did not
> specify the custom plugin path...
> 
> Anyway, I also don't see any harm in allowing to override the pluginpath
> from the command line just like the savepath, extrapath, etc. It's a
trivial
> change, too (though, since it is an *untested* feature addition, I'd be a
bit
> reluctant to add it to the 1.2.x branch).

Fine with me, I'll 'define' around it in branch and look at adding the
command line support to trunk.
 
> While we are at it, this is what FilePluginProvider::getPlugins()
currently
> does:
> 
>   pluginDirs.push_back(Common::FSNode("."));
>   pluginDirs.push_back(Common::FSNode("plugins"));
>   addCustomDirectories(pluginDirs);	// <- virtual method, default impl
> adds PLUGIN_DIRECTORY if set
>   if ("pluginpath" config entry specified)
>     pluginDirs.push_back(Common::FSNode(pluginsPath));
> 
> Ho-hum. That might be a bit of an overkill, esp. since some targets are
> sensitive to needlessly searching many directories. How about we replace
> this by a single
> 
>   addPluginSearchDirs(pluginDirs)
> 
> which by default just adds PLUGIN_DIRECTORY (if specified), and then
> "pluginpath". Also, add
>   ConfMan.registerDefault("pluginpath", "plugins");
> 
> This way we search less directories by default (which is faster and safer
> anyway), allow backends to fully customize where we search, if at all, and
> the code is cleaner and simpler ;).

Hmmm, that actually seems VERY sensible; it also matches up with the
behaviour of things like addSysArchivesToSearchSet so would seem a lot more
logical from the porters point of view. 

Also, it's not going to be a bad idea to have this in place when we commit
the enhanced plugin support to trunk and a whole lot more devices get the
options to use the plugins (and no doubt will bring about quirks in pathing
etc.). I guess the only question is do you want to do it or shall I?

Cheers,

John