Author Topic: Error building codeblocks 7860  (Read 17714 times)

Offline Totoxa

  • Multiple posting newcomer
  • *
  • Posts: 31
Error building codeblocks 7860
« on: February 27, 2012, 07:26:54 pm »
building codeblocks 7860 with codeblocks(svn 7785) in ubuntu 10.04 i get this error:

Code
main.cpp                In member function ‘void MainFrame::OnFileSaveAll(wxCommandEvent&)’
main.cpp    2694    error: ‘class ConfigManager’ has no member named ‘Flush’

and i dont know how to solve it, help please

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9614
Re: Error building codeblocks 7860
« Reply #1 on: February 27, 2012, 08:10:27 pm »
and i dont know how to solve it, help please
Do a re-build, as stated in the SVN logs. Even better: Do a clean check-out before. At minimum, delete the PCH (*.gch) files.
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: http://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: http://wiki.codeblocks.org/index.php?title=FAQ

Offline Totoxa

  • Multiple posting newcomer
  • *
  • Posts: 31
Re: Error building codeblocks 7860
« Reply #2 on: February 28, 2012, 01:57:59 am »
Thanks!, deleting the *.gch files worked for me

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13234
    • Travis build status
Re: Error building codeblocks 7860
« Reply #3 on: February 28, 2012, 08:11:46 am »
Morten: Can we make C::B delete the .gch files automatically, when the user executes clean or rebuild?
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9614
Re: Error building codeblocks 7860
« Reply #4 on: February 28, 2012, 08:44:10 am »
Morten: Can we make C::B delete the .gch files automatically, when the user executes clean or rebuild?
In both cases they already should be cleaned automatically. The error IMHO occurs because people don't clean or re-build, they just do a build.
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: http://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: http://wiki.codeblocks.org/index.php?title=FAQ

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13234
    • Travis build status
Re: Error building codeblocks 7860
« Reply #5 on: February 28, 2012, 10:12:42 am »
In both cases they already should be cleaned automatically. The error IMHO occurs because people don't clean or re-build, they just do a build.
But then, why C::B is dumb or not smart enough to regenerate the gch files, when a dependant header changes?
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline killerbot

  • Administrator
  • Lives here!
  • *****
  • Posts: 5280
Re: Error building codeblocks 7860
« Reply #6 on: February 28, 2012, 11:02:24 am »
you could have known I would write this ;-)

Can we just stop using precompiled headers all together ?

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13234
    • Travis build status
Re: Error building codeblocks 7860
« Reply #7 on: February 28, 2012, 11:55:53 am »
Can we just stop using precompiled headers all together ?
+1 :)
I hate it, when I change something in cbplugin.h and then I have to wait a full recompile...
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9614
Re: Error building codeblocks 7860
« Reply #8 on: February 28, 2012, 05:21:33 pm »
Can we just stop using precompiled headers all together ?
+1 :)
Are you aware that in that case compiling the whole C::B workspace takes roughly twice (if not even more!) the time? We introduced PCH for a good reason. A better thing would be to create a pre-build step that deletes the gch files every time the SDK or C::B main app is compiled. Tat would do it, too but still speed-up the later compile steps.

Still my favourite is to fix the actual error (if any) - however, I usually don't have this trouble. But I also don't know what is different, except the platform (Windows / Linux).
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: http://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: http://wiki.codeblocks.org/index.php?title=FAQ

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13234
    • Travis build status
Re: Error building codeblocks 7860
« Reply #9 on: February 28, 2012, 05:48:25 pm »
Morten:
Yes, if we just disable the pre-compiled headers and leave all the includes the way they are it will be slower. Because every file includes every file from the SDK, no mater if it needs it or not.
Also as far as I've read about pre-compiled headers, there should be used only for external libs, not for internal stuff, because they cause the pains I'm having.

Removing the PCH should be involving process and will take a lot of effort.

p.s. the full build (full as a build with all plugins, bootstrapping and make install phaze)  on linux without pre-compiled headers using autotools takes around 10 minutes. I've not tried what is the time with pch. I'll do a test later and will report my findings.

Still my favourite is to fix the actual error (if any) - however, I usually don't have this trouble. But I also don't know what is different, except the platform (Windows / Linux).
This is another matter and it is unrelated to the disabling of pch.
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline jens

  • Administrator
  • Lives here!
  • *****
  • Posts: 7255
Re: Error building codeblocks 7860
« Reply #10 on: February 28, 2012, 06:14:34 pm »
Morten:
Yes, if we just disable the pre-compiled headers and leave all the includes the way they are it will be slower. Because every file includes every file from the SDK, no mater if it needs it or not.
Also as far as I've read about pre-compiled headers, there should be used only for external libs, not for internal stuff, because they cause the pains I'm having.

Removing the PCH should be involving process and will take a lot of effort.

p.s. the full build (full as a build with all plugins, bootstrapping and make install phaze)  on linux without pre-compiled headers using autotools takes around 10 minutes. I've not tried what is the time with pch. I'll do a test later and will report my findings.
Are you sure it's without pch's ?
By default the automake-system uses pch's (not autotools in general, but our configuration).

Still my favourite is to fix the actual error (if any) - however, I usually don't have this trouble. But I also don't know what is different, except the platform (Windows / Linux).
This is another matter and it is unrelated to the disabling of pch.
I think whatr Morten wants to say, is to fix the bug, that leads to the problems with pch's.
And that is not unrelated to disabling them in general.

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13234
    • Travis build status
Re: Error building codeblocks 7860
« Reply #11 on: February 28, 2012, 06:29:17 pm »
Are you sure it's without pch's ?
By default the automake-system uses pch's (not autotools in general, but our configuration).
I'm always building with --disable-pch which is documented as disabling pchs, also it breaks when the pch build is broken.

I think whatr Morten wants to say, is to fix the bug, that leads to the problems with pch's.
I know and I agree that the bug should be fixed. As I'm the one who started this discussion. :)

And that is not unrelated to disabling them in general.
It is :)
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9614
Re: Error building codeblocks 7860
« Reply #12 on: February 28, 2012, 06:35:55 pm »
Still my favourite is to fix the actual error (if any) - however, I usually don't have this trouble. But I also don't know what is different, except the platform (Windows / Linux).
This is another matter and it is unrelated to the disabling of pch.
I think whatr Morten wants to say, is to fix the bug, that leads to the problems with pch's.
And that is not unrelated to disabling them in general.
Yes, that's what I meant - find the reason why it doesn't work an fix it. However, as it seems to depend on the platform it may not be our fault at all, but the compiler used could be another reason. And the fact that I can hardly reproduce on Windows makes me believe so.

In fact what we do is plain right: If the header file is set to be compiled first (which is is due to the weight) and it has changed (which we figure out by its date and dependencies) it will be re-compiled. The rest is done by the compiler.

Reasons why it does not work maybe:
1.) The date is wrong
2.) The dependencies are calculated wrong
3.) The compiler pre-compiles wrong
4.) (for me most likely) when we start build processes in parallel we don't consider a special handling for PCHs. Consider you start 3 build processes, where the first two are the PCH's and the next one is already part of the SDK.

However, if 4.) is true it should always work in a second trial.
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: http://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: http://wiki.codeblocks.org/index.php?title=FAQ

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9614
Re: Error building codeblocks 7860
« Reply #13 on: February 28, 2012, 06:36:42 pm »
I'm always building with --disable-pch which is documented as disabling pchs, also it breaks when the pch build is broken.
Yes, and I guess I know why that is - I'll commit a fix I had prepared for that... gimme some time...

UPDATE: Done.
« Last Edit: February 28, 2012, 06:39:17 pm by MortenMacFly »
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: http://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: http://wiki.codeblocks.org/index.php?title=FAQ

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13234
    • Travis build status
Re: Error building codeblocks 7860
« Reply #14 on: February 28, 2012, 08:32:01 pm »
Some benchmarks:
Code
no pch all plugins

real    6m3.471s
user    17m28.232s
sys     1m4.067s

with pch all plugins
real    5m29.323s
user    15m29.386s
sys     1m4.443s

no pch core only
real    2m16.697s
user    6m47.092s
sys     0m22.004s

with pch core only
real    1m55.610s
user    5m17.441s
sys     0m21.784s
Linux, make -j5, gcc 4.5.3 core2quad 6600 @ 3.2 ghz.
I don't see what is the benefit of pch. I see only pain...
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9614
Re: Error building codeblocks 7860
« Reply #15 on: February 28, 2012, 10:08:00 pm »
Linux, make -j5, gcc 4.5.3 core2quad 6600 @ 3.2 ghz.
LOL - you shouldn't use a high-speed PC, but one with a standard CPU config and (more interesting) standard HDD, no RAID, no SSD no large cache, nothing like that.
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: http://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: http://wiki.codeblocks.org/index.php?title=FAQ

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13234
    • Travis build status
Re: Error building codeblocks 7860
« Reply #16 on: February 28, 2012, 10:53:27 pm »
This is on a standard hard disk, no ssd, no other optimizations, 4 gb of ram.
The q6600 should be pretty low spec by today's standards, it is a cpu released at the end of 2006 ( http://en.wikipedia.org/wiki/Kentsfield_%28microprocessor%29 )
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9614
Re: Error building codeblocks 7860
« Reply #17 on: February 29, 2012, 07:07:04 am »
This is on a standard hard disk, no ssd, no other optimizations, 4 gb of ram.
...but -j 5 then?

However, I'd like to state another thing: If you want to compile w/o PCH you can always do that by #defining NOPCH for the build process. That's the common procedure for both: the "WX" PCH and our own "C::B" PCH concept. Maybe you should simply always do that. :-)


BTW: There is another reason that it might be not as performance as it ought to be;: Simply because not all files are correctly setup for the PCH usage. (In fact a lot are not.)
« Last Edit: February 29, 2012, 07:09:14 am by MortenMacFly »
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: http://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: http://wiki.codeblocks.org/index.php?title=FAQ

Offline killerbot

  • Administrator
  • Lives here!
  • *****
  • Posts: 5280
Re: Error building codeblocks 7860
« Reply #18 on: February 29, 2012, 07:14:06 am »
that's another reason to abandon it, I would say. IF still a whole bunch of files are still not correctly setup, we should be honest after all those years and say we just don't know how to do it, or we just keep on failing to do it right.
Time to surrender and move on ;-)

PS : and then we won't need Tim's patches anymore because one again it didn't build without pch, because someone didn't correctly add include files, because automagically it was compiling due to pch.

just my personal view on the matter.

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5341
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: Error building codeblocks 7860
« Reply #19 on: February 29, 2012, 08:24:14 am »
Morten: Can we make C::B delete the .gch files automatically, when the user executes clean or rebuild?
In both cases they already should be cleaned automatically. The error IMHO occurs because people don't clean or re-build, they just do a build.

I click the "clean" button, but I found that ".o" files were deleted by C::B. But unfortunately, the PCH files still exist. They are:
cb_trunk\src\include\sdk_precomp.h.gch
and
cb_trunk\src\include\sdk.h.gch
So, my question is: can we delete those .gch files when we press the "clean" button?


EDIT:
Oh, it looks like now the pch files were put seperatedly by wx28 project(under .objs\include) and wx29 project(under .objs29\include).

EDIT2
Ok, I see the change in 2012-02-15
Code
 src/CodeBlocks.cbp |   19 +++----------------
 1 files changed, 3 insertions(+), 16 deletions(-)

diff --git a/src/CodeBlocks.cbp b/src/CodeBlocks.cbp
index 4457729..75e069f 100644
--- a/src/CodeBlocks.cbp
+++ b/src/CodeBlocks.cbp
@@ -2,8 +2,7 @@
 <CodeBlocks_project_file>
  <FileVersion major="1" minor="6" />
  <Project>
- <Option title="Code::Blocks" />
- <Option pch_mode="2" />
+ <Option title="Code::Blocks wx2.8.x" />
  <Option default_target="src" />
  <Option compiler="gcc" />
  <Build>

So, we have change the pch generate mode (output directory). PCH deleting should work OK.
« Last Edit: February 29, 2012, 09:14:50 am by ollydbg »
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9614
Re: Error building codeblocks 7860
« Reply #20 on: February 29, 2012, 09:18:24 am »
Oh, it looks like now the pch files were put seperatedly by wx28 project(under .objs\include) and wx29 project(under .objs29\include).
True, I did that because otherwise they conflict. But thats another interesting issue: You guys might have an old PCH file which is used first due to the include order... So it might not work because of this.

we should be honest after all those years and say we just don't know how to do it, or we just keep on failing to do it right.
Well, we know how. And after all, the NON-PCH compilation (I mean with NOPCH switch, that's different from simply disabling PCH!) will be helpful to detect missing includes. Keep in mind that no matter what we do - wx will do and use PCH unless we declare NOPCH at the compile time. So even if we disable our PCH, the patches won't stop unless we do it properly in the first place.

The rules are plain simple:
PCH file:
- include all rarely changing header files
- do the PCH macro vodoo (we have that already)
Header:
- If you access or define an object, include the header
- If you use pointers/references, use forward decl
- Put headers you need to include into such a section if they are part of your PCH file:
Code
#ifndef USE_PCH
  #include <wx/dialog.h>
#endif
- Include headers you need to include that are not part of your PCH file as normal
Implementation:
- include the PCH file first
- same thing for headers needed as in the header file.

I do it that way in my own projects and i works flawlessly for ages! Of course, whenever I change code and use new classes, I need to check the above rules.

But (nevermind) if we decide to get rid of this because these rules are too hard - go ahead.

Here comes a simple small class:
Header:
Code
#ifndef USE_PCH
  #include <wx/dialog.h> // is in wx_pch.h!
#endif

#include <wx/busyinfo.h> // NOT in wx_pch.h and used as object

class MyClass; // forward decsl due to pointer usage

class MyDlg: public wxDialog
{
  MyDlg() { ; };
  void Func(MyClass* c); // used as pointer
  wxBusyInfo bi; // used as object
}
Implementation:
Code
#include <wx_pch.h> // our PCH file, may include the WX PCH file (if needed)

#include "MyDlg.h"

#ifndef USE_PCH
  #include "MyClass.h" // is in wx_pch.h, but now used as object / accessed
#endif

#include "MyOhterClass.h" // NOT in wx_pch.h and used as object

void MyDlg::Func(MyClass* c)
{
  MyOtherClass moc;
  c->DoSomething(moc);
}

...that's basically it (if I didn't forget something... ;-)).
« Last Edit: February 29, 2012, 09:24:38 am by MortenMacFly »
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: http://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: http://wiki.codeblocks.org/index.php?title=FAQ

Offline jens

  • Administrator
  • Lives here!
  • *****
  • Posts: 7255
Re: Error building codeblocks 7860
« Reply #21 on: February 29, 2012, 09:30:23 am »
I don't think not doing things, because we did not do it correctly in some places is the way we should go.
Otherwise we should stop developping software, because there will always be errors.

We should find issues and remove them, nad we should keep the possibility to do it in another way ( like NOPCH does).

What I can say, is that without pch's it's much slower (no exact measurements) here on my laptop with Core2Duo, 2x2GHz and 3.3 GB usable Ram.
Another option to speed up things is the use of ccache (what I do here).

One thing I will change in the near futire,  is the place where the pch's are created by the utomake system.
At the momenbt they are created in the headers directory, even if C::B is created from a special build-folder.
This wil conflict, if the same sources are used for wx2.8 and wx2.9 or for automake and build with C::B !

This might need some changes to the include-directories used in the Makefile.am's .
I will do it as soon as possible.

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5341
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: Error building codeblocks 7860
« Reply #22 on: March 04, 2012, 06:34:47 am »
1, I copy morten's sample code in a section in wiki: 6 Header file include and Precompiled header rule

2, I like PCH, because it compiles much faster. So, please don't remove this feature in C::B. :)

PS: It looks like we have two big PCH files, both of them is about 100M( gcc 4.6, windowsXP), can we use only one? The most different is that they have some different #define macros.
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13234
    • Travis build status
Re: Error building codeblocks 7860
« Reply #23 on: March 04, 2012, 08:15:34 am »
What happens if we just use the pch provided by wxwidgets or use a pch with all the external things in it?
How do I test the speed difference.
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline killerbot

  • Administrator
  • Lives here!
  • *****
  • Posts: 5280
Re: Error building codeblocks 7860
« Reply #24 on: March 04, 2012, 08:46:46 am »
include rules. this reminds on something I wrote 3-4 years ago, but I forgot to publish. At that time Yiannis had prove read it.

It is still in the scratch pad section, have a look here : http://forums.codeblocks.org/index.php/topic,3321.0.html


Offline jens

  • Administrator
  • Lives here!
  • *****
  • Posts: 7255
Re: Error building codeblocks 7860
« Reply #25 on: March 04, 2012, 09:39:42 am »
include rules. this reminds on something I wrote 3-4 years ago, but I forgot to publish. At that time Yiannis had prove read it.

It is still in the scratch pad section, have a look here : http://forums.codeblocks.org/index.php/topic,3321.0.html


@ollydbg:
You just added the link to the wiki, but it's not visible for normal users, because it's in the dev's subforum, that can not be accessed by normal users.
You should ither add a hint or remove the link.

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5341
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: Error building codeblocks 7860
« Reply #26 on: March 04, 2012, 09:42:27 am »
include rules. this reminds on something I wrote 3-4 years ago, but I forgot to publish. At that time Yiannis had prove read it.

It is still in the scratch pad section, have a look here : http://forums.codeblocks.org/index.php/topic,3321.0.html


@ollydbg:
You just added the link to the wiki, but it's not visible for normal users, because it's in the dev's subforum, that can not be accessed by normal users.
You should ither add a hint or remove the link.

Ok, I will update it, and put it in a user guide wiki page. (I thought that killerbot's guide rule was only for devs, but I'm wrong, sorry)
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9614
Re: Error building codeblocks 7860
« Reply #27 on: March 04, 2012, 10:57:39 am »
PS: It looks like we have two big PCH files, both of them is about 100M( gcc 4.6, windowsXP), can we use only one? The most different is that they have some different #define macros.
One if for the core, the other for plugins to include. They basically differ in the #defines used for creating them. It has to be like that in out case because one time the PCH file is used for the core and the other time for plugins.
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: http://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: http://wiki.codeblocks.org/index.php?title=FAQ

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9614
Re: Error building codeblocks 7860
« Reply #28 on: March 04, 2012, 10:59:08 am »
It is still in the scratch pad section, have a look here : http://forums.codeblocks.org/index.php/topic,3321.0.html
I read through it - that pretty much explains it very clear. We should put this to the WiKi, too.
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: http://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: http://wiki.codeblocks.org/index.php?title=FAQ

Offline killerbot

  • Administrator
  • Lives here!
  • *****
  • Posts: 5280
Re: Error building codeblocks 7860
« Reply #29 on: March 04, 2012, 12:13:15 pm »
yes; for the moement only devs subsection. The plan was to publish it on wiki and forum; but as we see I postponed it a bit too much.

I reread it myself this morning, and noticed several typos. I will fix the typos this evening.

And will make work of the example I was mentioning.

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5341
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: Error building codeblocks 7860
« Reply #30 on: March 05, 2012, 02:20:20 am »
I'm not sure where I can put killerbot's post.
User documentation - CodeBlocks does not have such page. :), although it has a PCH page.
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13234
    • Travis build status
Re: Error building codeblocks 7860
« Reply #31 on: March 05, 2012, 02:24:36 am »
You can make a subpage of this one - http://wiki.codeblocks.org/index.php?title=Coding_style
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline killerbot

  • Administrator
  • Lives here!
  • *****
  • Posts: 5280
Re: Error building codeblocks 7860
« Reply #32 on: March 05, 2012, 09:12:02 am »
have done a reread and removed a whole bunch of typos on the scratchpad posting.
So now it becomes interesting to copy it towards the wiki.