Author Topic: New CMake generator using Code::Blocks' internal build system  (Read 30672 times)

Offline Benjamin Eikel

  • Multiple posting newcomer
  • *
  • Posts: 12
Re: New CMake generator using Code::Blocks' internal build system
« Reply #15 on: September 25, 2012, 09:55:44 pm »
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

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


Offline Jenna

  • Administrator
  • Lives here!
  • *****
  • Posts: 7255
Re: New CMake generator using Code::Blocks' internal build system
« Reply #16 on: September 25, 2012, 10:06:18 pm »
None of the packaging files are fixed (yet).
Did you also edit codeblocks-common.install, so con_compiler.zip gets installed with the package ?

Offline Benjamin Eikel

  • Multiple posting newcomer
  • *
  • Posts: 12
Re: New CMake generator using Code::Blocks' internal build system
« Reply #17 on: September 25, 2012, 10:34:40 pm »
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
#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 (this=this@entry=0x6cc260, pluginFilename=..., pluginName=..., infoOut=infoOut@entry=0x0) at pluginmanager_base.cpp:249
#1027 0x00007ffff7afae0c in PluginManager::ScanForPlugins (this=0x6cc260, path=...) at pluginmanager_base.cpp:500
#1028 0x000000000040887f in CodeBlocksApp::BatchJob (this=this@entry=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.

Offline Jenna

  • Administrator
  • Lives here!
  • *****
  • Posts: 7255
Re: New CMake generator using Code::Blocks' internal build system
« Reply #18 on: September 27, 2012, 11:52:06 pm »
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.

Offline Benjamin Eikel

  • Multiple posting newcomer
  • *
  • Posts: 12
Re: New CMake generator using Code::Blocks' internal build system
« Reply #19 on: September 28, 2012, 08:27:04 am »
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.

Offline Benjamin Eikel

  • Multiple posting newcomer
  • *
  • Posts: 12
Re: New CMake generator using Code::Blocks' internal build system
« Reply #20 on: September 29, 2012, 04:56:46 pm »
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".

Offline Jenna

  • Administrator
  • Lives here!
  • *****
  • Posts: 7255
Re: New CMake generator using Code::Blocks' internal build system
« Reply #21 on: September 29, 2012, 05:40:46 pm »
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.

Offline Benjamin Eikel

  • Multiple posting newcomer
  • *
  • Posts: 12
Re: New CMake generator using Code::Blocks' internal build system
« Reply #22 on: September 29, 2012, 06:09:05 pm »
Hmmm, I have to following files there:
Code
$ 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
...
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?

Offline Jenna

  • Administrator
  • Lives here!
  • *****
  • Posts: 7255
Re: New CMake generator using Code::Blocks' internal build system
« Reply #23 on: September 29, 2012, 06:27:40 pm »
i will look into it.

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

Offline Jenna

  • Administrator
  • Lives here!
  • *****
  • Posts: 7255
Re: New CMake generator using Code::Blocks' internal build system
« Reply #24 on: September 29, 2012, 08:59:22 pm »
The issue should be fixed now.

Offline Benjamin Eikel

  • Multiple posting newcomer
  • *
  • Posts: 12
Re: New CMake generator using Code::Blocks' internal build system
« Reply #25 on: October 01, 2012, 08:53:56 pm »
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
#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
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 (this=this@entry=0x768800) at ../compilergcc.cpp:797
#10 0x00007fffedd98a86 in CompilerGCC::SwitchCompiler (this=this@entry=0x768800, id=...) at ../compilergcc.cpp:934
#11 0x00007fffedd98b39 in CompilerGCC::CheckProject (this=this@entry=0x768800) at ../compilergcc.cpp:981
#12 0x00007fffedd99392 in CompilerGCC::DoRecreateTargetMenu (this=this@entry=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 (this=this@entry=0xf38bc0, project=project@entry=0xdb9740, refresh=refresh@entry=true) at projectmanager.cpp:531
#16 0x00007ffff7b0a840 in ProjectManager::LoadProject (this=0xf38bc0, filename=..., activateIt=true) at projectmanager.cpp:837
#17 0x00000000004083ed in CodeBlocksApp::BatchJob (this=this@entry=0x65b740) at app.cpp:950
#18 0x0000000000409cf9 in CodeBlocksApp::OnInit (this=0x65b740) at app.cpp:710
#19 0x00007ffff5ac7ee6 in wxEntry (argc=@0x7ffff5dd9cb0: 4, argv=0x64a3a0) at ../src/common/init.cpp:432
#20 0x00007ffff5ac7fdd in wxEntry (argc=@0x7fffffffdffc: 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 (this=this@entry=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 (this=this@entry=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?

Offline Jenna

  • Administrator
  • Lives here!
  • *****
  • Posts: 7255
Re: New CMake generator using Code::Blocks' internal build system
« Reply #26 on: October 01, 2012, 10:13:55 pm »
Can you try this patch:

Code
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)
« Last Edit: October 02, 2012, 11:24:25 am by jens »

Offline Benjamin Eikel

  • Multiple posting newcomer
  • *
  • Posts: 12
Re: New CMake generator using Code::Blocks' internal build system
« Reply #27 on: October 03, 2012, 01:35:19 pm »
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.

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9694
Re: New CMake generator using Code::Blocks' internal build system
« Reply #28 on: October 03, 2012, 03:29:34 pm »
patch updated (should be more robust)
I think this can be applied in trunk, too.
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: https://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: https://wiki.codeblocks.org/index.php?title=FAQ

Offline Jenna

  • Administrator
  • Lives here!
  • *****
  • Posts: 7255
Re: New CMake generator using Code::Blocks' internal build system
« Reply #29 on: October 03, 2012, 04:15:13 pm »
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.