In rev 3175, make version, no plugins are found:
Manager initialized
Scanning for lexers in /Users/bnilsson/Library/Application Support/codeblocks/share/codeblocks/lexers/...
Found 0 lexers
Scanning for lexers in /Users/bnilsson/Applications/CodeBlocks.app/Contents/Resources/share/codeblocks/lexers/...
Found 26 lexers
Configured 0 tools
Scanning for plugins in /Users/bnilsson/Library/Application Support/codeblocks/share/codeblocks/plugins...
Found 0 plugins
Scanning for plugins in /Users/bnilsson/Applications/CodeBlocks.app/Contents/Resources/share/codeblocks/plugins...
Found 0 plugins
Running startup script
Then I do
[Tiger:~/cb/trunk] bnilsson% ls /Users/bnilsson/Applications/CodeBlocks.app/Contents/Resources/share/codeblocks/plugins
libProfiler.la libcb_koders.so libdebugger.la libhelp_plugin.so
libProfiler.so libclasswizard.la libdebugger.so libkeybinder.la
libSymTab.la libclasswizard.so libdefaultmimehandler.la libkeybinder.so
libSymTab.so libcodecompletion.la libdefaultmimehandler.so liblib_finder.la
libastyle.la libcodecompletion.so libdragscroll.la liblib_finder.so
libastyle.so libcodesnippets.la libdragscroll.so libscriptedwizard.la
libautosave.la libcodesnippets.so libenvvars.la libscriptedwizard.so
libautosave.so libcodestat.la libenvvars.so libtodo.la
libbyogames.la libcodestat.so libexporter.la libtodo.so
libbyogames.so libcompiler.la libexporter.so libwxsmith.la
libcb_koders.la libcompiler.so libhelp_plugin.la libwxsmith.so
So they are there alright.
I am using symlinks from ~/bin, ~/lib and ~/share into ~/Applications/CodeBlocks.app/....
I have also used install_name_tool to change application and plugin references from the original to @executable_path:...
I have also tried "make clean" and rebuilt.
I have also tried to remove contents of ~/bin, ~/lib and ~/share and then "make install" again.
Any suggestions?
The paths look alright, but if I find something when I build the new nightlies I will post it.
PS: assuming that you mean rev 3275 ? :-)
Yes, sorry about that. 3275 it is.
I found the bug, pluginmanager.cpp has been patched with (the erroneous) .dylib again.
It went broke in revision r3261. (http://developer.berlios.de/patch/download.php?id=1622)
This is the portion that needs to be reversed (I will do this shortly):
Index: src/sdk/pluginmanager.cpp
===================================================================
--- src/sdk/pluginmanager.cpp (revision 3178)
+++ src/sdk/pluginmanager.cpp (working copy)
@@ -748,6 +748,8 @@
{
#ifdef __WXMSW__
#define PLUGINS_MASK _T("*.dll")
+#elif __WXMAC__
+ #define PLUGINS_MASK _T("*.dylib")
#else
#define PLUGINS_MASK _T("*.so")
#endif
@@ -769,6 +771,8 @@
// defaults
#ifdef __WXMSW__
bbplugins.Add(_T("compiler.dll"));
+ #elif __WXMAC__
+ bbplugins.Add(_T("libcompiler.dylib"));
#else
bbplugins.Add(_T("libcompiler.so"));
#endif
Index: src/src/compilersettingsdlg.cpp
===================================================================
--- src/src/compilersettingsdlg.cpp (revision 3176)
+++ src/src/compilersettingsdlg.cpp (working copy)
@@ -70,6 +70,8 @@
// defaults
#ifdef __WXMSW__
bbplugins.Add(_T("compiler.dll"));
+ #elif __WXMAC__
+ bbplugins.Add(_T("libcompiler.dylib"));
#else
bbplugins.Add(_T("libcompiler.so"));
#endif
@@ -241,6 +243,8 @@
#ifdef __WXMSW__
const wxString compiler = _T("compiler.dll");
+ #elif __WXMAC__
+ const wxString compiler = _T("libcompiler.dylib");
#else
const wxString compiler = _T("libcompiler.so");
#endif
The plugins should be .so on Mac too, while dynamic libs are .dylib.
Quote from: afb on November 26, 2006, 11:57:50 PM
I found the bug, pluginmanager.cpp has been patched with (the erroneous) .dylib again.
It went broke in revision r3261. (http://developer.berlios.de/patch/download.php?id=1622)
This is the portion that needs to be reversed (I will do this shortly):
Index: src/sdk/pluginmanager.cpp
===================================================================
--- src/sdk/pluginmanager.cpp (revision 3178)
+++ src/sdk/pluginmanager.cpp (working copy)
@@ -748,6 +748,8 @@
{
#ifdef __WXMSW__
#define PLUGINS_MASK _T("*.dll")
+#elif __WXMAC__
+ #define PLUGINS_MASK _T("*.dylib")
#else
#define PLUGINS_MASK _T("*.so")
#endif
@@ -769,6 +771,8 @@
// defaults
#ifdef __WXMSW__
bbplugins.Add(_T("compiler.dll"));
+ #elif __WXMAC__
+ bbplugins.Add(_T("libcompiler.dylib"));
#else
bbplugins.Add(_T("libcompiler.so"));
#endif
Index: src/src/compilersettingsdlg.cpp
===================================================================
--- src/src/compilersettingsdlg.cpp (revision 3176)
+++ src/src/compilersettingsdlg.cpp (working copy)
@@ -70,6 +70,8 @@
// defaults
#ifdef __WXMSW__
bbplugins.Add(_T("compiler.dll"));
+ #elif __WXMAC__
+ bbplugins.Add(_T("libcompiler.dylib"));
#else
bbplugins.Add(_T("libcompiler.so"));
#endif
@@ -241,6 +243,8 @@
#ifdef __WXMSW__
const wxString compiler = _T("compiler.dll");
+ #elif __WXMAC__
+ const wxString compiler = _T("libcompiler.dylib");
#else
const wxString compiler = _T("libcompiler.so");
#endif
The plugins should be .so on Mac too, while dynamic libs are .dylib.
Hi, this got introduced in rev.3261, but that incorrect part of the patch has been reverted in rev.3266.
Strange, I still see it in my rev 3275 ?
edit: Now gone for real in rev 3276...
http://svn.berlios.de/svnroot/repos/codeblocks/trunk/src/sdk/pluginmanager.cpp
Quote from: afb on November 27, 2006, 12:26:19 AM
Strange, I still see it in my rev 3275 ?
edit: Now gone for real in rev 3276...
http://svn.berlios.de/svnroot/repos/codeblocks/trunk/src/sdk/pluginmanager.cpp
Very strange, just check the diff between 3265 and 3266 http://svn.berlios.de/wsvn/codeblocks/?op=log&rev=0&sc=0&isdir=1
It does the same you did in 3276
(but also on compilersettingsdlg.cpp).
Either you did have an old revision (previous to 3266) before commiting, a conflicted source, or subversion is having problems with reverts? :?
EDIT:
I'm more inclined to think that this is a bug in subversion (or a change in respect how reverts are handled)
As you can see with the link above in the diff between 3265 and 3266 the change
is there.
But strangely enough, when you look at the raw file @3266 here (http://svn.berlios.de/wsvn/codeblocks/trunk/src/sdk/pluginmanager.cpp?op=file&rev=3266&sc=0) the change is
not there. (!)
Quote from: takeshi miya on November 27, 2006, 01:10:33 AM
I'm more inclined to think that this is a bug in subversion
I would agree. Anyway, hope this undead bug stays down.
Rev 3278 does work "out of the box" in the MacPorts build.