Don't store the absolute pathname of plugins in the configuration file,

just the basename like libPlugin_foo.dylib. Dolphin then loads the
plugins relative to the compiled-in plugins directory.

This means that you won't have to reselect the plugins when running 
different builds (in different directories) and is most obviously
beneficial on OS X where application bundles are not (should not) be
expected to stay in the place where they are first installed.

This is tested on OS X and Linux with local/global build options, but
not Windows. I don't anticipate any problems on Windows, but that OS
does have slightly different semantics with regard to path component
separators and file suffixes, so it's something to watch out for.


git-svn-id: https://dolphin-emu.googlecode.com/svn/trunk@5621 8ced0084-cf51-0410-be5f-012b33b47a6e

Source/Core/Core/Src/ConfigManager.cpp

@@ -182,13 +182,11 @@ void SConfig::LoadSettings()
 	IniFile ini;
 	ini.Load(File::GetUserPath(F_DOLPHINCONFIG_IDX));
 
-	std::string PluginsDir = File::GetPluginsDirectory();
-	
-	// Hard coded default
-	m_DefaultGFXPlugin = PluginsDir + DEFAULT_GFX_PLUGIN;
-	m_DefaultDSPPlugin = PluginsDir + DEFAULT_DSP_PLUGIN;
-	m_DefaultPADPlugin = PluginsDir + DEFAULT_PAD_PLUGIN;
-	m_DefaultWiiMotePlugin = PluginsDir + DEFAULT_WIIMOTE_PLUGIN;
+	// Hard coded defaults
+	m_DefaultGFXPlugin = DEFAULT_GFX_PLUGIN;
+	m_DefaultDSPPlugin = DEFAULT_DSP_PLUGIN;
+	m_DefaultPADPlugin = DEFAULT_PAD_PLUGIN;
+	m_DefaultWiiMotePlugin = DEFAULT_WIIMOTE_PLUGIN;
 
 	// General
 	{