New CMake generator using Code::Blocks' internal build system

[Benjamin Eikel]

Dear Code::Blocks community,

I am working on a new generator for CMake that creates a native Code::Blocks project (see the discussion "Using the internal Code::Blocks builder" on cmake-developers). In CMake, there exists already a generator for Code::Blocks, but this generates a Makefile and a Code::Blocks project using that Makefile. My new generator is already able to generate project files for simple CMake projects and build them using the internal build system of Code::Blocks.
Currently, I have the problem that I cannot start Code::Blocks without a graphical user interface. Every time I invoke Code::Blocks with a build target, it opens a console window showing the build output. I have found no way to suppress the window. I also found an old thread stating that there is no possibility to disable the GUI. Maybe the situation has improved in the last years. Is there a command-line-only invocation possible now?

[MortenMacFly]

I am working on a new generator for CMake that creates a native Code::Blocks project (see the discussion "Using the internal Code::Blocks builder"

I was in contact with the author of the other builder - nice to hear that you decide to go for it! Its way better than the Makefile based one (although it was working fine for me). [OT: Send greetings to Alex - I know him quite well... ;-)]

I also found an old thread stating that there is no possibility to disable the GUI. Maybe the situation has improved in the last years. Is there a command-line-only invocation possible now?

We do have a batch build option, which uses minimal UI (see here: http://svn.berlios.de/wsvn/codeblocks/trunk/src/batch_build_core for an example how to use it). However, even the tiny batch windows uses UI.

We have plans for a non-UI version of the builder and there is a working branch of Code::Blocks w/o UI here: http://svn.berlios.de/wsvn/codeblocks/branches/codeblocks_console
It is sync'd with trunk from time to time, but its not something many people use. But as I said: It works, but is not something "ready" yet.

however, this should be of no concern for the project builder, because the project file won't be affected by whether the IDE uses UI or not.

Why are you asking? Why do you need a non-UI builder?

[MortenMacFly]

...edit: I just read the thread you posted - I guess I know why you are asking, because of this:
> This is more or less necessary so cmake can run its test suite to verify
> the generator works correctly.
Right?

Well, the batch window closes automatically at end (which is actually an option) and returns an error code which you can use for verification of a successful build. So if the need is just to run a C::B build process externally with feedback, this is possible. If you insist it shall not have any UI (i.e. for console build server) - only with the branch. But for my understanding for cmake the first one applies...

Maybe Alex can make a statement here... AFAIK he is even member of this forum... or was at least...

[Benjamin Eikel]

...edit: I just read the thread you posted - I guess I know why you are asking, because of this:
> This is more or less necessary so cmake can run its test suite to verify
> the generator works correctly.
Right?

Right, this is one reason. For example, on the testing server you will not have any possibility to run applications that need a GUI.

Furthermore, CMake runs many tests in its configurations phase (e.g. checking if the compiler works correctly). Projects can add further tests (e.g. checking if a library contains a given symbol, if a header can be used for compilation). Most of these tests generate a project using the current generator (in my case the new Code::Blocks generator). Then the project is build to execute the test (in my case, a Code::Blocks window pops up and closes after a short while). This makes the whole process quite slow and annoying.

Maybe I will check out the console-only branch you mentioned.

[MortenMacFly]

Furthermore, CMake runs many tests in its configurations phase (e.g. checking if the compiler works correctly). Projects can add further tests (e.g. checking if a library contains a given symbol, if a header can be used for compilation). Most of these tests generate a project using the current generator (in my case the new Code::Blocks generator). Then the project is build to execute the test (in my case, a Code::Blocks window pops up and closes after a short while). This makes the whole process quite slow and annoying.

OK - but this sounds like an IDE is required to have a non-UI build process to make it into Cmake?! That would be new to me. I understand having a non-UI build its a "nice to have" thing, but it shouldn't be a requirement. I think there are plenty of IDE's around that do not support that. How do you handle the very common and famous Eclipse IDE for example? (I know Cmake supports it, too.) And was it really different at the time you did the C::B Makefile based generator?

So... Do you need this feature only temporarily for developing the generator and drive your (Cmake) tests, or is this really a hard requirement on the IDE? For the first case, the mentioned branch should be just fine (maybe Jens can do another merge before), but for the latter...

[Benjamin Eikel]

OK - but this sounds like an IDE is required to have a non-UI build process to make it into Cmake?! That would be new to me. I understand having a non-UI build its a "nice to have" thing, but it shouldn't be a requirement. I think there are plenty of IDE's around that do not support that. How do you handle the very common and famous Eclipse IDE for example? (I know Cmake supports it, too.) And was it really different at the time you did the C::B Makefile based generator?

The old C::B Makefile generator as well as the Eclipse generator use the Makefiles to do the build. Therefore, you can call "make" instead of using the IDE. The generated project files are more or less an extra on top of the Makefile. Because I want to get rid of the Makefile, I cannot use this approach.

[jens]

[...]
the mentioned branch should be just fine (maybe Jens can do another merge before)
[...]

I will see what I can do.
Merging is not as easy as it would like it to be (too many other merges [debugger-branch and trunk]).

[jens]

[...]
the mentioned branch should be just fine (maybe Jens can do another merge before)
[...]

I will see what I can do.
Merging is not as easy as it would like it to be (too many other merges [debugger-branch and trunk]).

Merging the branches was imposiible, nuch too much merge conflicts.

I created a new (local) branch and recreated the console-branch which is now (at the moment) a real child of trunk (might break again if xml-branch is merged).
I will try to do the merges more often, so it will not divert as much as it was.

@MortenMacFly and other devs:
should I create a complete new branch on the server (e.g. cb_headless) or should I delete the old one and recreate it (with the same name) from my new local branch ?

[MortenMacFly]

should I delete the old one and recreate it (with the same name) from my new local branch ?

Go for that, even deleted branches are still accessible afterwards.

[jens]

The recreated console-branch should work with wx2.8 and wx2.9, using project-files or automake-system.

The changes are (as before) linux only.

[Benjamin Eikel]

Thank you for your efforts. I will try out the "codeblocks_console" branch as soon as possible and report back.

[Benjamin Eikel]

I was able to retrieve and build Code::Blocks from the codeblocks_console branch. I have a problem now. When running codeblocks_con to build the project, I get the following error message:

Code: [Select]

codeblocks_con --build --target=Debug MyProject.cbp
Scanning for plugins in /home/benjamin/.codeblocks/share/codeblocks/plugins
Loaded 0 plugins
Scanning for plugins in /usr/lib/codeblocks/plugins
Loaded 0 plugins

Error:
Deactivating the compiler plugin is most unwise.
When using codeblocks instead, it works. How do I activate the compiler plugin?

[oBFusCATed]

How many versions of C::B do you have installed?
Generally when testing things it is a good idea to use the --prefix option of the configure script.
Personally I do this for all software I don't install using a package manager (--prefix=/home/myname/software/softname).

[jens]

What exact steps did you do for compiling ?
Where is libcon_compiler.so located ?

[MortenMacFly]

The recreated console-branch should work with wx2.8 and wx2.9, using project-files or automake-system.

Great work, Jens.

[Benjamin Eikel]

I edited the install rules in debian/, executed ./bootstrap, and dpkg-buildpackage -b -uc -us, which worked without problems. Afterward, I installed the generated Debian packages. The file is located in /usr/lib/codeblocks/plugins/libcon_compiler.so.

When doing strace codeblocks_con --build --target=Debug MyProject.cbp, it shows the following:

Code: [Select]

⋮
stat("/usr/lib/codeblocks/plugins/libcodecompletion.so", {st_mode=S_IFREG|0644, st_size=1041040, ...}) = 0
stat("/usr/lib/codeblocks/plugins/libcon_compiler.so", {st_mode=S_IFREG|0644, st_size=1018192, ...}) = 0
stat("/home/benjamin/.codeblocks/share/codeblocks/plugins/con_compiler.zip", 0x7fff01890960) = -1 ENOENT (No such file or directory)
stat("/home/benjamin/.codeblocks/share/codeblocks/con_compiler.zip", 0x7fff01890960) = -1 ENOENT (No such file or directory)
stat("/usr/lib/codeblocks/plugins/con_compiler.zip", 0x7fff01890960) = -1 ENOENT (No such file or directory)
stat("/usr/share/codeblocks/con_compiler.zip", 0x7fff01890960) = -1 ENOENT (No such file or directory)
write(2, "Plugin resource not found: libco"..., 46Plugin resource not found: libcon_compiler.zip) = 46
write(2, "\n", 1
)                       = 1
getdents(3, /* 0 entries */, 32768)     = 0
write(1, "Loaded 0 plugins\n", 17Loaded 0 plugins
)      = 17
⋮


[jens]

None of the packaging files are fixed (yet).
Did you also edit codeblocks-common.install, so con_compiler.zip gets installed with the package ?

[Benjamin Eikel]

None of the packaging files are fixed (yet).

Yes, I saw that. I started to add files that I thought I would need.

Did you also edit codeblocks-common.install, so con_compiler.zip gets installed with the package ?

You are right, I forgot this one. Sorry for the inconvenience caused.

Now, the error with the missing plugin file is gone. But I have run into the next one. Somehow there seems to be an endless loop.

Code: [Select]

#0  0x00007ffff4e54f95 in __getdents (fd=<optimized out>, buf=0x2950d48 "\241$\001", nbytes=32768) at ../sysdeps/unix/sysv/linux/getdents.c:105
#1  0x00007ffff4e54972 in __readdir (dirp=0x2950d20) at ../sysdeps/unix/readdir.c:66
#2  0x00007ffff5dcd106 in wxDirData::Read(wxString*) () from /usr/lib/x86_64-linux-gnu/libwx_baseu-2.8.so.0
#3  0x00007ffff5dd2055 in wxMimeTypesManagerImpl::LoadKDEAppsFilesFromDir(wxString const&) () from /usr/lib/x86_64-linux-gnu/libwx_baseu-2.8.so.0
#4  0x00007ffff5dd2135 in wxMimeTypesManagerImpl::LoadKDEAppsFilesFromDir(wxString const&) () from /usr/lib/x86_64-linux-gnu/libwx_baseu-2.8.so.0
#5  0x00007ffff5dd2135 in wxMimeTypesManagerImpl::LoadKDEAppsFilesFromDir(wxString const&) () from /usr/lib/x86_64-linux-gnu/libwx_baseu-2.8.so.0
#6  0x00007ffff5dd2135 in wxMimeTypesManagerImpl::LoadKDEAppsFilesFromDir(wxString const&) () from /usr/lib/x86_64-linux-gnu/libwx_baseu-2.8.so.0
⋮
#1012 0x00007ffff5dd2135 in wxMimeTypesManagerImpl::LoadKDEAppsFilesFromDir(wxString const&) () from /usr/lib/x86_64-linux-gnu/libwx_baseu-2.8.so.0
#1013 0x00007ffff5dd2135 in wxMimeTypesManagerImpl::LoadKDEAppsFilesFromDir(wxString const&) () from /usr/lib/x86_64-linux-gnu/libwx_baseu-2.8.so.0
#1014 0x00007ffff5dd2135 in wxMimeTypesManagerImpl::LoadKDEAppsFilesFromDir(wxString const&) () from /usr/lib/x86_64-linux-gnu/libwx_baseu-2.8.so.0
#1015 0x00007ffff5dd2135 in wxMimeTypesManagerImpl::LoadKDEAppsFilesFromDir(wxString const&) () from /usr/lib/x86_64-linux-gnu/libwx_baseu-2.8.so.0
#1016 0x00007ffff5dd2135 in wxMimeTypesManagerImpl::LoadKDEAppsFilesFromDir(wxString const&) () from /usr/lib/x86_64-linux-gnu/libwx_baseu-2.8.so.0
#1017 0x00007ffff5dd9370 in wxMimeTypesManagerImpl::Initialize(int, wxString const&) () from /usr/lib/x86_64-linux-gnu/libwx_baseu-2.8.so.0
#1018 0x00007ffff5dd9884 in wxMimeTypesManagerImpl::InitIfNeeded() () from /usr/lib/x86_64-linux-gnu/libwx_baseu-2.8.so.0
#1019 0x00007ffff5dd9f15 in wxMimeTypesManagerImpl::GetFileTypeFromExtension(wxString const&) () from /usr/lib/x86_64-linux-gnu/libwx_baseu-2.8.so.0
#1020 0x00007ffff5da1cf8 in wxMimeTypesManager::GetFileTypeFromExtension(wxString const&) () from /usr/lib/x86_64-linux-gnu/libwx_baseu-2.8.so.0
#1021 0x00007ffff5d8a330 in wxFileSystemHandler::GetMimeTypeFromExt(wxString const&) () from /usr/lib/x86_64-linux-gnu/libwx_baseu-2.8.so.0
#1022 0x00007ffff5d8bec0 in wxLocalFSHandler::OpenFile(wxFileSystem&, wxString const&) () from /usr/lib/x86_64-linux-gnu/libwx_baseu-2.8.so.0
#1023 0x00007ffff5d8afc0 in wxFileSystem::OpenFile(wxString const&, int) () from /usr/lib/x86_64-linux-gnu/libwx_baseu-2.8.so.0
#1024 0x00007ffff5d8f3b3 in wxArchiveFSHandler::OpenFile(wxFileSystem&, wxString const&) () from /usr/lib/x86_64-linux-gnu/libwx_baseu-2.8.so.0
#1025 0x00007ffff5d8afc0 in wxFileSystem::OpenFile(wxString const&, int) () from /usr/lib/x86_64-linux-gnu/libwx_baseu-2.8.so.0
#1026 0x00007ffff7af7402 in PluginManager::ReadManifestFile ([email protected]=0x6cc260, pluginFilename=..., pluginName=..., [email protected]=0x0) at pluginmanager_base.cpp:249
#1027 0x00007ffff7afae0c in PluginManager::ScanForPlugins (this=0x6cc260, path=...) at pluginmanager_base.cpp:500
#1028 0x000000000040887f in CodeBlocksApp::BatchJob ([email protected]=0x65c610) at app.cpp:926
#1029 0x000000000040a6f0 in CodeBlocksApp::OnInit (this=0x65c610) at app.cpp:705
#1030 0x00007ffff5d924d4 in wxEntry(int&, wchar_t**) () from /usr/lib/x86_64-linux-gnu/libwx_baseu-2.8.so.0
#1031 0x0000000000407072 in main (argc=4, argv=<optimized out>) at app.cpp:297

I will have a deeper look into it in the next days. Maybe I am missing some debugging symbols.

Thank you very much for your help and your quick answers.

[jens]

I just committed some changes to the console-branch.
Now the plugin libs are build in a seperate directory for headless C::B.
This is done to be able to integrate some of the contrib-plugins (e.g. cppcheck) without to use hacks to find the console-plugins amongst the gui-plugins.

I also fixed the automake-system therefore and added a flag (--disable-gui) to configure, that disables the gui part. It is now possible to create just the headless version. Default is to create both.

I also fixed the debian- and rpm-based package files to create codeblocks-headless (and codeblocks-headless-common on debian) packages.

You should be able to build the debian packages without any tweaking.

[Benjamin Eikel]

The packages build without problems. Thank you very much. I still had no time to look into the issue I stated in my last post.

[Benjamin Eikel]

The Debian packages from the branch install the plugins into "/usr/lib/codeblocks/plugins". Is that correct? During startup, Code::Blocks tries to find them in "/usr/share/codeblocks/plugins".

[jens]

The libs should be in in /usr/lib/codeblocks/plugins and the appropriate zip-files (which contain at least the manifest-file) should be installed in /usr/share/codeblocks (for the non-gui-stuff it's codeblocks_con instead of codeblocks (currently just libcompiler.so and compiler.zip.

[Benjamin Eikel]

Hmmm, I have to following files there:

Code: [Select]

$ ls /usr/lib/codeblocks_con/plugins/
libcompiler.so
$ ls /usr/lib/codeblocks/plugins/
libabbreviations.so   libcb_koders.so       libcompiler.so            libDoxyBlocks.so    libFileManager.so        liblib_finder.so        libRegExTestbed.so    libtodo.so
libastyle.so          libCccc.so            libcopystrings.so         libdragscroll.so    libheaderfixup.so        libMouseSap.so          libReopenEditor.so    libToolsPlus.so
libautosave.so        libclasswizard.so     libCppCheck.so            libEditorConfig.so  libhelp_plugin.so        libNassiShneiderman.so  libscriptedwizard.so  libValgrind.so
libAutoVersioning.so  libcodecompletion.so  libCscope.so              libEditorTweaks.so  libHexEditor.so          libopenfileslist.so     libSpellChecker.so    libwxSmithAui.so
libBrowseTracker.so   libcodesnippets.so    libdebugger.so            libenvvars.so       libIncrementalSearch.so  libProfiler.so          libSymTab.so          libwxsmithcontribitems.so
libbyogames.so        libcodestat.so        libdefaultmimehandler.so  libexporter.so      libkeybinder.so          libprojectsimporter.so  libThreadSearch.so    libwxsmith.so
$ ls /usr/share/codeblocks_con/
compiler.zip  scripts
$ ls /usr/share/codeblocks
abbreviations.zip   cb_koders.zip       compiler.zip            DoxyBlocks.zip    FileManager.zip  IncrementalSearch.zip  MouseSap.zip          ReopenEditor.zip    start_here.zip    ToolsPlus.zip
astyle.zip          Cccc.zip            copystrings.zip         dragscroll.zip    headerfixup.zip  keybinder.zip          NassiShneiderman.zip  resources.zip       SymTab.zip        Valgrind.zip
autosave.zip        classwizard.zip     CppCheck.zip            EditorConfig.zip  help_plugin.zip  lexers                 openfileslist.zip     scriptedwizard.zip  templates         wxSmithAui.zip
AutoVersioning.zip  codecompletion.zip  Cscope.zip              EditorTweaks.zip  HexEditor.zip    lib_finder             Profiler.zip          scripts             ThreadSearch.zip  wxsmithcontribitems.zip
BrowseTracker.zip   codesnippets.zip    debugger.zip            envvars.zip       icons            lib_finder.zip         projectsimporter.zip  SpellChecker        tips.txt          wxsmith.zip
byogames.zip        codestat.zip        defaultmimehandler.zip  exporter.zip      images           manager_resources.zip  RegExTestbed.zip      SpellChecker.zip    todo.zip
But when starting the GUI with codeblocks, the Plugins -> Manage plugins... dialog is empty. There are no plugins. I am not able to create any projects (new project dialog is empty, too). I already tried to merge the Subversion trunk (no changes for me there) and to delete my ~/.codeblocks folder.
After startup, the Code::Blocks tool view shows:

Code: [Select]

...
Loading lexer_vhdl
Loading lexer_postscript
Configured 0 tools
Scanning for plugins in /home/benjamin/.codeblocks/share/codeblocks/plugins
Loaded 0 plugins
Scanning for plugins in /usr/share/codeblocks/plugins
Running startup script
Script plugin registered: Find Broken Files plugin
Script/function 'edit_startup_script.script' registered under menu '&Settings/-Edit startup script'
The path "/usr/share/codeblocks/plugins" does not exist. Is that perhaps a problem because of the Debian packages? Should I try to compile and use it directly without the packaging in between?

[jens]

i will look into it.

The plugins-folder below share/codeblocks should not exist (I wrote it from memory, sorry).

[jens]

The issue should be fixed now.

[Benjamin Eikel]

Thank you for fixing it.

I have now compiled Code::Blocks against the debug version of the wxBase library (from Debian package libwxbase2.8-dbg). This makes debug symbols available. I first looked into the issues I reported some posts ago (with many wxMimeTypesManagerImpl::LoadKDEAppsFilesFromDir calls in stack trace). It showed that the program went into the directory "/home/benjamin/.local/share/applications/wine/Programme/Drakensang", which contained files with special characters. It then tried to append an empty directory name, which resulted in

Code: [Select]

#7  0x00007ffff5a8755f in wxOnAssert (szFile=0x7ffff5b592e8 L"../src/common/filename.cpp", nLine=1618, szFunc=0x7ffff5b59e00 "IsValidDirComponent", szCond=0x7ffff5b592a8 L"wxAssertFailure",
    szMsg=0x7ffff5b59980 L"empty directory passed to wxFileName::InsertDir()") at ../src/common/appbase.cpp:711
#8  0x00007ffff5ab9f01 in wxFileName::IsValidDirComponent (dir=...) at ../src/common/filename.cpp:1618
#9  0x00007ffff5aba04a in wxFileName::AppendDir (this=0x7fffffffca60, dir=...) at ../src/common/filename.cpp:1639
#10 0x00007ffff5b1e608 in wxMimeTypesManagerImpl::LoadKDEAppsFilesFromDir (this=0x7096d0, dirname=...) at ../src/unix/mimetype.cpp:1088
with the debug libraries. To solve this problem, I simply removed the "wine" directory.

Now I have run in the next problem:

Code: [Select]

Program received signal SIGTRAP, Trace/breakpoint trap.
0x00007ffff57d6efb in raise (sig=<optimized out>) at ../nptl/sysdeps/unix/sysv/linux/pt-raise.c:41
41      ../nptl/sysdeps/unix/sysv/linux/pt-raise.c: Datei oder Verzeichnis nicht gefunden.
(gdb) bt
#0  0x00007ffff57d6efb in raise (sig=<optimized out>) at ../nptl/sysdeps/unix/sysv/linux/pt-raise.c:41
#1  0x00007ffff5a87479 in wxTrap () at ../src/common/appbase.cpp:674
#2  0x00007ffff5a8775a in DoShowAssertDialog (msg=...) at ../src/common/appbase.cpp:766
#3  0x00007ffff5a87017 in wxAppTraitsBase::ShowAssertDialog (this=0x65e970, msgOriginal=...) at ../src/common/appbase.cpp:557
#4  0x00007ffff5a86f03 in wxConsoleAppTraitsBase::ShowAssertDialog (this=0x65e970, msg=...) at ../src/common/appbase.cpp:507
#5  0x00007ffff5a878fa in ShowAssertDialog (szFile=0x7fffede2a858 L"/usr/include/wx-2.8/wx/string.h", nLine=796, szFunc=0x6fd818 L"Last", szCond=0x7fffede2c4c8 L"!empty()", szMsg=0x7fffede2c450 L"wxString: index out of bounds",
    traits=0x65e970) at ../src/common/appbase.cpp:836
#6  0x00007ffff5a86dbd in wxAppConsole::OnAssertFailure (this=0x65b740, file=0x7fffede2a858 L"/usr/include/wx-2.8/wx/string.h", line=796, func=0x6fd818 L"Last", cond=0x7fffede2c4c8 L"!empty()",
    msg=0x7fffede2c450 L"wxString: index out of bounds") at ../src/common/appbase.cpp:445
#7  0x00007ffff5a8755f in wxOnAssert (szFile=0x7fffede2a858 L"/usr/include/wx-2.8/wx/string.h", nLine=796, szFunc=0x7fffede30cb8 "Last", szCond=0x7fffede2c4c8 L"!empty()", szMsg=0x7fffede2c450 L"wxString: index out of bounds")
    at ../src/common/appbase.cpp:711
#8  0x00007fffedd9806b in Last (this=0x7fffffffd9a0) at /usr/include/wx-2.8/wx/string.h:796
#9  CompilerGCC::SetupEnvironment ([email protected]=0x768800) at ../compilergcc.cpp:797
#10 0x00007fffedd98a86 in CompilerGCC::SwitchCompiler ([email protected]=0x768800, id=...) at ../compilergcc.cpp:934
#11 0x00007fffedd98b39 in CompilerGCC::CheckProject ([email protected]=0x768800) at ../compilergcc.cpp:981
#12 0x00007fffedd99392 in CompilerGCC::DoRecreateTargetMenu ([email protected]=0x768800) at ../compilergcc.cpp:1445
#13 0x00007fffedd9964d in CompilerGCC::UpdateProjectTargets (this=0x768800, project=0xdb9740) at ../compilergcc.cpp:1575
#14 0x00007ffff7aef240 in Manager::ProcessEvent (this=<optimized out>, event=...) at manager.cpp:192
#15 0x00007ffff7b0a37b in ProjectManager::SetProject ([email protected]=0xf38bc0, [email protected]=0xdb9740, [email protected]=true) at projectmanager.cpp:531
#16 0x00007ffff7b0a840 in ProjectManager::LoadProject (this=0xf38bc0, filename=..., activateIt=true) at projectmanager.cpp:837
#17 0x00000000004083ed in CodeBlocksApp::BatchJob ([email protected]=0x65b740) at app.cpp:950
#18 0x0000000000409cf9 in CodeBlocksApp::OnInit (this=0x65b740) at app.cpp:710
#19 0x00007ffff5ac7ee6 in wxEntry ([email protected]: 4, argv=0x64a3a0) at ../src/common/init.cpp:432
#20 0x00007ffff5ac7fdd in wxEntry ([email protected]: 4, argv=0x7fffffffe0e8) at ../src/common/init.cpp:460
#21 0x0000000000406a02 in main (argc=4, argv=<optimized out>) at app.cpp:297
(gdb) sel 9
(gdb) frame
#9  CompilerGCC::SetupEnvironment ([email protected]=0x768800) at ../compilergcc.cpp:797
797         while ( (masterPath.Last() == '\\') || (masterPath.Last() == '/') )
(gdb) print masterPath
$1 = {<wxStringBase> = {static npos = 18446744073709551615, m_pchData = 0x7ffff5b6dcf8 L""}, <No data fields>}
(gdb) sel 11
(gdb) frame
#11 0x00007fffedd98b39 in CompilerGCC::CheckProject ([email protected]=0x768800) at ../compilergcc.cpp:981
981             SwitchCompiler(m_pProject->GetCompilerID());
(gdb) print m_pProject->GetCompilerID()
$2 = (const wxString &) @0xdb9900: {<wxStringBase> = {static npos = 18446744073709551615, m_pchData = 0x7127e8 L"gcc"}, <No data fields>}
I can look deeper into it. Do you have a spontaneous idea?

[jens]

Can you try this patch:

Code: [Select]

Index: src/plugins/compilergcc/compilergcc.cpp
===================================================================
--- src/plugins/compilergcc/compilergcc.cpp
+++ src/plugins/compilergcc/compilergcc.cpp
@@ -794,7 +794,8 @@
     // Get configured masterpath, expand macros and remove trailing seperators
     wxString masterPath = compiler->GetMasterPath();
     Manager::Get()->GetMacrosManager()->ReplaceMacros(masterPath);
-    while ( (masterPath.Last() == '\\') || (masterPath.Last() == '/') )
+    while ( !masterPath.IsEmpty() &&
+           ((masterPath.Last() == '\\') || (masterPath.Last() == '/') ))
         masterPath.RemoveLast();
 
     // Compile new PATH list...

EDIT:

patch updated (should be more robust)

[Benjamin Eikel]

The old as well as your current patch work for me. Thanks for fixing that so fast. I am now able to build my project with codeblocks_con.

[MortenMacFly]

patch updated (should be more robust)

I think this can be applied in trunk, too.

[jens]

patch updated (should be more robust)

I think this can be applied in trunk, too.

There are several other places where we use RemovLast(), they all might be dangerous.
I'm not absolutely sure. whether this is a wxWidgets issue, or not.

If it is a wxWidgets problem, I will file a bug-report.