Do I need to explicitly add libraries for 4.3.1 I don't need for 4.2.0? I get linking errors for wstring (lots of undefined references to std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >).
As with previous 4.3 builds, minor modifications were necessary in the C::B sources.
As with previous 4.3 builds, minor modifications were necessary in the C::B sources.
Are they significant modifications?
Index: src/CodeBlocks.cbp
===================================================================
--- src/CodeBlocks.cbp (revision 5083)
+++ src/CodeBlocks.cbp (working copy)
@@ -384,7 +384,6 @@
<Option type="3" />
<Option compiler="gcc" />
<Compiler>
- <Add option="-include sdk.h" />
<Add option="-DBUILDING_PLUGIN" />
<Add directory="include" />
<Add directory="include\scripting\include" />
Index: src/include/projectloader_hooks.h
===================================================================
--- src/include/projectloader_hooks.h (revision 5106)
+++ src/include/projectloader_hooks.h (working copy)
@@ -40,7 +40,7 @@
* The isLoading argument is true if your hook is called when the project is being loaded,
* and false when the project is saved.
*/
- template<class T> class DLLIMPORT HookFunctor : public HookFunctorBase
+ template<class T> class HookFunctor : public HookFunctorBase
{
public:
typedef void (T::*Func)(cbProject*, TiXmlElement*, bool);
Index: src/include/editor_hooks.h
===================================================================
--- src/include/editor_hooks.h (revision 5106)
+++ src/include/editor_hooks.h (working copy)
@@ -40,7 +40,7 @@
* The isLoading argument is true if your hook is called when the project is being loaded,
* and false when the project is saved.
*/
- template<class T> class DLLIMPORT HookFunctor : public HookFunctorBase
+ template<class T> class HookFunctor : public HookFunctorBase
{
public:
typedef void (T::*Func)(cbEditor*, wxScintillaEvent&);
Are they significant modifications?They are one-liner workarounds for GCC bugs, and are required in order to build C::B. I would not classify them as significant.
Here's three that had to be done a month ago; I have not tried it since then.It hasn't changed; this is exactly what was necessary.
any reason why we would not apply this already today ?
Index: src/plugins/contrib/help_plugin/help_common.cpp
===================================================================
--- src/plugins/contrib/help_plugin/help_common.cpp (revision 5202)
+++ src/plugins/contrib/help_plugin/help_common.cpp (working copy)
@@ -12,6 +12,7 @@
#include <wx/intl.h>
#include <wx/dynarray.h>
#include <wx/textfile.h>
+#include <algorithm>
using std::find;
Index: src/plugins/contrib/help_plugin/MANFrame.cpp
===================================================================
--- src/plugins/contrib/help_plugin/MANFrame.cpp (revision 5202)
+++ src/plugins/contrib/help_plugin/MANFrame.cpp (working copy)
@@ -10,6 +10,10 @@
#include "MANFrame.h"
#include "man2html.h"
+#include <sdk.h>
+#ifndef CB_PRECOMP
+ #include "globals.h" // cbC2U
+#endif
#include <wx/sizer.h>
#include <wx/dir.h>
#include <wx/sstream.h>
@@ -20,10 +24,6 @@
#include <bzlib.h>
#include <zlib.h>
-#ifndef CB_PRECOMP
- #include "globals.h" // cbC2U
-#endif
-
namespace
{
int butSearchID = wxNewId();
Index: src/include/projectloader_hooks.h
===================================================================
--- src/include/projectloader_hooks.h (revision 5202)
+++ src/include/projectloader_hooks.h (working copy)
@@ -40,7 +40,7 @@
* The isLoading argument is true if your hook is called when the project is being loaded,
* and false when the project is saved.
*/
- template<class T> class DLLIMPORT HookFunctor : public HookFunctorBase
+ template<class T> class HookFunctor : public HookFunctorBase
{
public:
typedef void (T::*Func)(cbProject*, TiXmlElement*, bool);
Index: src/include/editor_hooks.h
===================================================================
--- src/include/editor_hooks.h (revision 5202)
+++ src/include/editor_hooks.h (working copy)
@@ -40,7 +40,7 @@
* The isLoading argument is true if your hook is called when the project is being loaded,
* and false when the project is saved.
*/
- template<class T> class DLLIMPORT HookFunctor : public HookFunctorBase
+ template<class T> class HookFunctor : public HookFunctorBase
{
public:
typedef void (T::*Func)(cbEditor*, wxScintillaEvent&);
#include "sdk.h"
#ifndef CB_PRECOMP
#include headers from the sdk.h we actually need
#endif
#include all other headers we need who are not in sdk.h
-include file--> so not the same behavior as a regular include --> makes things just more complicated and less consistent
Process file as if #include "file" appeared as the first line of the primary source file. However, the first directory searched for file is the preprocessor's working directory instead of the directory containing the main source file. If not found there, it is searched for in the remainder of the #include "..." search chain as normal.
4) darn pch : they are the cause of 99% of our builds being broken [in the sense of doesn't build], and this is once more related in this use case with pch (sdk.h)They're the cause of making the build 12-15 times faster too, however. And honestly, I don't think it is really the fault of precompiled headers, rather we're probably just not using them right. sdk.h, sdk-common.h, sdk-precomp.h #ifdef BLAH ... nobody understands what to use at what time, and what's valid at which time anyway :)
5) now every file is forced to work with the pch, no choice if you have a simple file that nearly needs anything from the sdk.hWhich should be perfectly alright, though. Using the whole precompiled SDK header is much more efficient than including 1-2 "small" headers such as wxString that are not precompiled.
They're the cause of making the build 12-15 times faster too, however.I know, but not really in CB, it slows down the build. Mainly because our sdk was not that stable, mostly because our sdk does not exist out of interfaces, but contains state (even in the worst possible form (public and protected members). But yes, I agree, it can provide speed-up (explained more or less in my quote below).
Which should be perfectly alright, though. Using the whole precompiled SDK header is much more efficient than including 1-2 "small" headers such as wxString that are not precompiled.Dangerous and maybe the few includes that were really needed in a file might have a faster compilation. There's a threshold, but what it the amount of headers to include to use either approach ?
4. pch's
Consider that several implementation files (so does not apply for headers), include all the time a nearly identical set of headers (for example we have 10 source files, and all of them include header files A, B and C) then the include statement of those 3 headers can be put in a separate header and the 10 sources include that special header. It is obvious this is in conflict with the third rule of good inclusions. And suppose we have 5 files which all of them include headers A and B, maybe those can also include that special header then, although they get one header to many in the end, so we are in conflict with the second rule. On the other hand (if there are no special ifdefs in the header, so not the guards) several compilers can "pre"-compile this special header and immediately copy in the result of this compilation in the eventual compilation of the sources, it is obvious by doing this once, instead for all those sources, a speed-up in the compilation process is achieved. So that's the (big) benefit of pch's. But it very easy to see the golden rules get violated and this might lead to code of lesser quality. And how about when you are reading the code on paper, hmmm nice we include a special header, well let's hope it includes everything we need.
Not all compilers support pch's, so if you write code (like the sources from CodeBlocks, wxWidgets) that should compile with different compilers, or different version of compilers, then you need to do it both ways. Then we can serve both parties, the fans of the pch's and we are obliged to do it also the "clean" way since otherwise it will not compile. That is, in the case of no pch support those special headers turn up to be no-ops. And they should, otherwise it is very hard for maintenance (what if a certain header get's kicked out of the pch -> woops : compile errors) and otherwise all those nice rules are violated just for nothing (because there's no speed-up, only things get slower, because several sources will be including stuff they didn't need). Most of the time the files included in a pch are headers that don't change that much like, headers from an sdk/api : CodeBlocks sdk, wx api, windows api. Note that because of such a bottleneck, if one of the headers in the pch change all files dependent on the pch need to recompile (even thoug in the end it might have been because of a header in the list they didn't need). So use pch's wisely and make sure you always program at the same time according to the golden rules.
This brings us to a first template on how to do inclusions for the CodeBlocks sources.CodeIt is obvious that this requires maintenance over time depending on what is added/removed from pch. Headers can move to/from the #else part to/from the part outside the #ifdef#else#endif construct. As we code, we should always check the list of headers in the pch.#ifdef PCH_MODE
#include our pch
#else
#include headers from the pch we actually need
#endif
#include all other headers we need who are not in the list
CodeBlocks sources use 2 pch's : the CodeBlocks sdk and the wx sdk, where the CodeBlocks sdk pch will take care of the wx sdk pch.
The fact that pch's are used is defined on the project level, the projects of the CodeBlock sources specify they will use pch's. However since certain compilers don't support pch's, the specification on the project level needs to be overruled and turned off. One could also remove the setting from the project files by hand when using those non-pch compilers, but it is a common practice to have it turned off by means of a header file that checks which compiler is being used and if needed turn off the setting (normally a preprocessor define is used for this purpose). The object oriented approach would be to have a dedicated file doing the check and overrule and then our template would look something like this :Code#include use_pch_check // so this one could undef the PCH_MODE
#ifdef PCH_MODE
#include our pch
#else
#include headers from the pch we actually need
#endif
#include all other headers we need who are not in the list
Although less object oriented (1 responsibility in 1 place and the other way around), but often used is that the pch itself does the check. From the things discussed above, good practice (our golden rules) requires the pch to look something like this :
a_pch_template.hCode// check on the compiler (or other settings) if we need to #undef PCH_MODE
// if it is not undef-ed we include our list of headers
#ifdef PCH_MODE
// here comes our list with headers we include in the pch
#endif // PCH_MODE
Then our template needs to look like this :Code#include our pch
#ifndef PCH_MODE
#include headers from the pch we actually need
#endif
#include all other headers we need who are not in the list
When Code::Blocks is using precompiled headers it will automatically also turn on the usage of precompiled headers on wxWidgets. The preprocessor defines activating the precompiled headers are :
- CB_PRECOMP (for Code::Blocks sdk headers)
- WX_PRECOMP (for wxWidgets headers)
the pch checking/overruling headers are :
- sdk.h (Code::Blocks)
- wxprec.h (wxWidgets)
Since Code::Blocks drives also the pch mode of wxWidgets we can just focus on the CB_PRECOMP/sdk.h .
As a result our header/include template becomes :Code#include "sdk.h"
#ifndef CB_PRECOMP
#include headers from the sdk.h we actually need
#endif
#include all other headers we need who are not in sdk.h
Although wxprec.h already has a list of headers included in the precompilation, Code::Blocks has created an extra list of wx headers to use in the precompilation list. This extra list together with the Code::Blocks headers can be found in sdk_precomp.h (this one is included from the sdk.h). Note as far as the wx headers are concerned there's some overlap in the official wx list and the Code::Blocks-wx list.
by the way, after discussing with the 'Don' we would remove that "-include sdk.h" option in the cbp file. So CB will build with TDM-GCC gcc 4.3.2 out of the box then. :-)
GCC 4.3.2 TDM-2 (the second 4.3.2-based TDM release) is now available. Binary packages are provided as drop-in replacements for the MinGW (http://www.mingw.org/) project's official gcc packages.I've got a question. In your description of bundled installer I see that you use mingw-runtime 3.14. Why you don't use latest (3.15.1) version? Is there some critical bugs or incompatibilities? Or it is just incorrect description and indeed you packaged 3.15.1?
...
Cheers,
John E. / TDM
I've got a question. In your description of bundled installer I see that you use mingw-runtime 3.14. Why you don't use latest (3.15.1) version? Is there some critical bugs or incompatibilities? Or it is just incorrect description and indeed you packaged 3.15.1?
hi, TDragon.
I find that in the wiki page:
http://wiki.codeblocks.org/index.php?title=Debugging_with_Code::Blocks
The GDB doesn't support set breakpoints in a constructor. I tested in your package, It's true :(.
I'm not sure if this limitation is removed yet? Thanks.
Hi, I have found that the mingw GDB 6.8.3 version is support setting breaking point in the class constructors.I have made a mistake, see the above message. :D
So, I have download these files from:
http://www.esnips.com/doc/a9e03a9e-7a36-4357-9093-09d0188825f9/gdb-6.8-3-MinGW
and I copy the gdb.exe and gdbserver.exe to my Mingw/bin folder. When a message box prompt that a file named " iconv.dll" is need to run gdb.exe.
So, I searched on Google, and find one from
ftp://ftp.gnupg.org/gcrypt/binary/libiconv-1.9.1.dll.zip
Now, the GDB can step into the constructor of a class. :D.
You should update the OP in this thread. :D, because TDM 4.3.3 is released.
You should update the OP in this thread. :D, because TDM 4.3.3 is released.
I haven't yet built wxWidgets or Code::Blocks with it.
By the way, the hex editor reveals strings in all executables built with the TDM suite which look suspiciously like asserts to me, such as "ret->size == sizeof(__cygming_shared) && "GCClib shared data size mismatch". I don't know if those are present in exes built with the official MinGW too (not been using them for a year).Yes, they are asserts. They are part of the exceptions-from-DLLs mechanism in libgcc, and are basically the only choice for ending your program in a quasi-helpful manner if the mechanism fails. They are in the official MinGW as well: "w32_sharedptr->size == sizeof(W32_EH_SHARED)".
They don't go away if I define NDEBUG though. On the other hand, why should they... if the compiler is built in debug mode, then the compiler should contain these asserts, but wouldn't place them in the executable, would it... :)
Any idea what that is and how to get rid of? It's not like it really hurts anything, but it puzzles me.