Developer forums (C::B DEVELOPMENT STRICTLY!) > Development

SVN -- plugin problems on OS X [solved]

(1/1)

obijohn:
I followed the instructions here for building c::b, which worked fine, although I skipped making the app Bundle since I will just be running c::b from the Terminal. Okay, on to the plugin issues.

The first problem is that the plugins were compiled and installed to /usr/local/lib/codeblocks/plugins (I used /usr/local as the default prefix) whereas c::b expects them to be in /usr/local/share/codeblocks. As a quick fix, I simply copied the files to that location. Now c::b does find them and (tries to) load and activate them.

The next problem is that several of the default plugins cause c::b to crash during plugin activation. The only ones that worked for me were: astyle, autosave, projectsimporter, and scriptedwizard. Classwizard is unique in that it will work by itself but not if the other 4 that work are loaded, so I assume there is some kind of conflict going on there.

Some of the contrib plugins don't compile, but wxsmith did. However, it's one of those that crashes c::b.

If anyone is working with c::b SVN on OS X, I could use some pointers.

afb:

--- Quote from: obijohn on March 12, 2009, 10:19:51 pm ---The first problem is that the plugins were compiled and installed to /usr/local/lib/codeblocks/plugins (I used /usr/local as the default prefix) whereas c::b expects them to be in /usr/local/share/codeblocks. As a quick fix, I simply copied the files to that location. Now c::b does find them and (tries to) load and activate them.

--- End quote ---

I did this as well (moved the files) for the bundle, it should be fixed in code eventually.


--- Code: (src/sdk/configmanager.cpp) ---    if (data_path_global.IsEmpty())
    {
        if(platform::windows)
            ConfigManager::data_path_global = app_path + _T("/share/codeblocks");
        else if(platform::macosx)
            ConfigManager::data_path_global = res_path + _T("/share/codeblocks");
        else
            ConfigManager::data_path_global = wxStandardPathsBase::Get().GetDataDir();
    }
#ifdef CB_AUTOCONF
    if (plugin_path_global.IsEmpty())
    {
       if(platform::windows || platform::macosx)
          ConfigManager::plugin_path_global = data_path_global;
       else
          ConfigManager::plugin_path_global = wxStandardPathsBase::Get().GetPluginsDir() + _T("/plugins");
    }
#endif

--- End code ---

Apparently the second location will now be CodeBlocks.app/Contents/PlugIns/plugins


No idea about the broken plugins, though.

obijohn:
I found the problem I was having with the plugins (besides the incorrect directory issue already mentioned), and I'll report on it here in case anyone comes across the same issue with the plugins crashing on activation. When following the build instructions on the wiki, I skipped the wxWidgets section because I had previous built and installed wxMac. In looking back over the c::b wiki page, I noticed that there were quite a few configure flags used when building wxMac, and I'm pretty sure I didn't use most of them. Some of them are enabled by default and don't need to be specified (it doesn't hurt though), but I think the main issue was not using --enable-monolithic and --enable-unicode. I rebuilt wxMac with the flags specified and then rebuilt c::b, and now the plugins work.

It's interesting to me that the main c::b application itself would run fine before and it was the plugins causing the problems. Anyway, issue resolved.

Navigation

[0] Message Index