Get quick announcements through the RSS feed http://www.codeblocks.org/nightly/CodeBlock_RSS.xml
Before you use a nightly make sure you understand how it works (http://forums.next.codeblocks.org/index.php/topic,3232.0.html).
A link to the unicode windows wxWidget dll(s) for Code::Blocks : http://sourceforge.net/projects/codeblocks/files/Binaries/Nightlies/Prerequisites/wxmsw31u_gcc_cb_wx311_gcc510-TDM.7z
The 03 November 2018 build is out.
- Windows :
http://sourceforge.net/projects/codeblocks/files/Binaries/Nightlies/2018/CB_20181103_rev11508_win64.7z
- Linux :
none
The current SDK version is : 1.36.0
Resolved Fixed:
- updated Doxygen scripts for generating SDK and other docs
- DragScroll - Fix to right mouse click in project window. see http://forums.next.codeblocks.org/index.php/topic,22863.new.html#new
- CodeBlocks Fix crash in GotoFile::BuildContent(74) m_ResultList->SetIterator(iterator); else crash in m_handler.Init()
- BrowseTracker fix crash in JumpTracker when CB Editor is nullptr. Thanks BlueHazzard
Regressions/Confirmed/Annoying/Common bugs:
we will try to build the next nightly with a new compiler :
MinGW-W64:
Version : 8.1.0
Architecture : x86_64
Threads : posix
Exception : seh
Build Revision : 0
Dear Code::Blocks Developer.
Could you please post the tool-chain configuration for MinGW-W64
in the 64 bit version as well as in the 32 bit version.
I tried to do it by my self some. But for some reasons I can start my binary only from Code::Blocks but not as an independent application. I assume that I have chosen the wrong build-executables.
I tried it out on a Win 10 machine.
Best regards,
Eckard Klotz.
Can you please describe the problem with more details?
Quote from: oBFusCATed on November 04, 2018, 12:50:53 PM
Can you please describe the problem with more details?
I think he's just asking what compiler we used >> @killerbot, could you post the link / version / flavour to the one used for the nightlies so far? I even think it is posted somewhere...
at the moment we still use : http://tdm-gcc.tdragon.net/
I think I use the TDM64 bundle.
His problem sounds more like he simply forgot to add all the required MinGW DLLs to the application directory. Applications compiled with standard MinGW require a bunch of DLLs to run, basically almost all DLLs you can find in its bin directory, you can check the exact dependencies with your favorite dependency checker.
Dear All.
Thanks for your replies.
I have already downloaded MinGW 8.1.0 from http://mingw-w64.org (http://mingw-w64.org) and installed the 64 bit version as well as the 32 bit version. For my development I prefer the 32 bit version since timing problems occure more drastically.
My initial interest was to get to know what binaries I have to choose as tool-chain executables:
- Do I have to use the binaries with the names traditionally provided by Code::Blocks?
- Or Do I have to use the binaries with names like i686-w64-mingw32-c++?
- both sets seem to be available.
In my first experiment I have chosen the
i686-w64-mingw32-c++ binaries. With this I was able to build and run the Code::Blocks
Hello World project but not my project-sources https://sourceforge.net/projects/moritz/?source=directory (https://sourceforge.net/projects/moritz/?source=directory).
But thanks to Sodev, since I have now an idea why. I was able to start my application from Code::Blocks but not without Code::Blocks as before with a tdm-build. I assume now that Code::Blocks is already running the necessary DLLs and that's why it was possible to start my application from it with the run-button.
Is there a documentation existing that describes what additional DLLs or a-files have to be added?
Best regards,
Eckard.
Dear Developers
I have one additional but different topic:
Today I build Code::Blocks by my self from the latest sources (SVN revision 11509). Due to our company fire-wall I was not able to update a sandbox from source-forge as I do it at home. Thus I created at source-forge a snapshot from your SVN archive.
Unfortunately this snapshot contains no revision-information and thus the build shows the revision-number 0 (zero).
Is it possible to change this manually?
Best Regards,
Eckard.
Quote
[...] revision-information [...} shows the revision-number 0 (zero). Is it possible to change this manually?
The way I clone/update might be of help for you. I do it with a Makefile which resides a directory above local trunk
and automates the steps described in the wiki (quite convenient when you do this weekly for wxWidgets, codeblocks, cppcheck etc).
Way more primitive like e.g. cmake but that keeps it simple. The relevant lines are:
.PHONY: clone update updateChangelog
clone:
svn checkout svn://svn.code.sf.net/p/codeblocks/code/trunk
update:
(cd trunk && svn update)
updateChangelog:
(cd trunk && ./updateChangeLog.sh && ./update_revision.sh)
Executing thes steps manually or via make you can e.g. create at home a new snapshot including revision, zip it and transfer it to the other machine.
If you can not go this way, please have a look into ./update_revision.sh. Until now, I had no need to examine this script myself. At the end, I have a file Changelog and a file revision.m4 containing e.g.:
m4_define([SVN_REV], 11509)
m4_define([SVN_REVISION], 17.12svn11509)
m4_define([SVN_DATE], 2018-11-04 02:49:39)
@eckard_klotz
QuoteUnfortunately this snapshot contains no revision-information and thus the build shows the revision-number 0 (zero).
Is it possible to change this manually?
To avoid making manual changes, simply install 'subversion' or 'git' on your machine.
Won't help if you only have a source tarball and no working copy ;)
Dear All.
Installing SVN or GIT is no option I on my company computer since our firewall ia not allowing the connection to an external archive.
But finally I found a solution:
- There is a header-file ".....\trunk\src\include\autorevision.h" defines the necessary information.
- Thus I edited its content to substitute the SVN based script.
Best regards,
Eckard.
Hi,
on my Win7 PC, CodeBlocks rev 11508 is not responding a few seconds (20 to 30) after starting and it's consistent. It was working fine with rev 11499.
See attached report.
Other details: When starting, it indicating "wxSmitPlot.dll" plugin is missing and about 20 to 30 seconds after that C:B stops responding.
If I try to start again, there is a wxWidgets Debug Alert showing up (see 2nd attachment).
Win7-64 bit Professional, i7-4790 (SP1)
svn build rev 11508 (2018-10-27 18:36:32) gcc 5.1.0 Windows/unicode - 64 bit
@damorin: What happens if you disable the file manager plugin? Does the slowdown go away?
HI,
I was able to disable it quickly enough before it's stall and now it's working fine.
Thanks
The below from the Code::Blocks console when firing this CB nightly on a Win10 machine. Is there anything to worry about, since the message text is prompted in red?
Quote
Manager failed to load XRC resource 'C:\...\portables\CB_20181103\share\codeblocks\Cccc.zip'.
Manager failed to load XRC resource 'C:\...\portables\CB_20181103\share\codeblocks\CppCheck.zip'.
Manager failed to load XRC resource 'C:\...\portables\CB_20181103\share\codeblocks\Cscope.zip'.
Manager failed to load XRC resource 'C:\...\portables\CB_20181103\share\codeblocks\DoxyBlocks.zip'.
Manager failed to load XRC resource 'C:\...\portables\CB_20181103\share\codeblocks\EditorConfig.zip'.
Manager failed to load XRC resource 'C:\...\portables\CB_20181103\share\codeblocks\headerfixup.zip'.
Manager failed to load XRC resource 'C:\...\portables\CB_20181103\share\codeblocks\ThreadSearch.zip'.
Manager failed to load XRC resource 'C:\...\portables\CB_20181103\share\codeblocks\ToolsPlus.zip'.
Manager failed to load XRC resource 'C:\...\portables\CB_20181103\share\codeblocks\wxSmithAui.zip'.
Some plugins don't need XRC resources. Probably the manager should be less verbose, or remark that it is normal behaviour.
I guess, I should fix this, because people are worried by these messages and they don't do a search before posting, so forum post pile up...
Good idea. It is that the manager can raise an error window as well. I have a self-built version here which does that regularly when starting CB which is annoying. Especially, when it is neither an error nor a failure. So I am pretty much with you to fix that. Thanks!
Quote from: Miguel Gimenez on November 13, 2018, 07:09:07 PM
Some plugins don't need XRC resources. Probably the manager should be less verbose, or remark that it is normal behaviour.
I suggest not defining cb_debug while building CB and the message should go away.
Edit: If the devs want I can create a patch that splits the header that causes the message into something called like cb_assert.h and allow the plugins to define the value of cb_debug instead of the core application.
This would be able to keep the warning for the plugins that need XRC file.
Tim S.
And then the bugs would be hidden... and wxDEBUG/ASSERT is causing the problem not cbDEBUG...