Author Topic: CodeBlocks sucks  (Read 35893 times)

Offline bcc32x

  • Multiple posting newcomer
  • *
  • Posts: 18
CodeBlocks sucks
« on: October 03, 2018, 07:01:24 pm »
I don't want to use strong words, but it sucked hard. Your Project Build Option is a disaster, very very stupid and poor engineered (broken by design). Many many hours I spent on the Net just to see other people with the same problem as me but none solved because they gave up on you and try something other. I don't care if you ban me or shut me up by delete this thread, I'm already used with totalitarian and censorship in my country. But your developers are too arrogant,  unacceptable. You don't realize your position on the IDE market, you think you're the best!

My Problem in details, it's my last post, don't ask me provide logs or something else because it's too obvious and reproducible:

1.The project build option is broken by design. Just change the build option many times (search directory, linker setting...) and save properly for the sake of the child target (Debug and Release) not updated, causing unnecessary and nonsense errors. They're not syncing, when you change the global you expect the child to change accordingly, it does not!

And it's very hard to use a dll on this IDE. I've successfully used this dll with DevC++. Sadly, DevC++ is dead, this stupid IDE the only alternative for me lightweight enough for my old machine. Five hours, finally I given up and write this post.

The dll is a Delphi compile dll with header I wrote by hand. Imagine: LibTest.dll and LibTest.h. It's imposible to specify your linker setting to add the dll, rather I've to follow mingw.org's tutorial to use dlltool to create a .def file and produce a .a file (LibTest.a and LibTest.def). When properly add LibTest.a to linker and add appropriate search directory path (it's too stupid, all the LibTest.* already in the project root directory!, why I've to add my current working project dir to search dir? why it's not default searched?) the same stupid error a appears everytime: ld something: can't find -lLibTest.a. Ironically, when I copied the same command line of gcc and g++ to cmd.exe it's worked right!!!

2. Why you continue to build and distribute CodeBlocks with the broken and discontinued TDM-GCC? I don't understand, MingGW-64 is up and much more updated. When using your shipped GCC 5.1.0 it failed to compile my code, both a sample Win32++ project and, uhm, std::to_string is not a member of... Ironically, DevC++'s TDM-GCC 4.9.2 and latest MingW64 all compiled fine!!!

3. Is this IDE dead? The main page codeblocks.org down continuously, very rarely I can access it and read post on this forums, I did search, searched very well indeed, but can't find the solution because your IDE is indeed broken, it makes a very simple task become complicated.

4. Please remove support for ancient compiler like Borland 5 but rather support Borland 10! Drop VC2003 but support VC2015. It's the way any sane human would do. It's very simple to add because you already have the template, but you didn't. The same answer "add it yourself", I hate it, if I can do it, I will not ask. I'm the type of people if I can do it, I will contribute back.

5. Why do you offer a Windows version but keeps Linux in mind? The f*ckin SpellChecker plugin which I disabled everytime I launch a new profile of CodeBlocks expect path separator to be / but not \ so it's keep complains missing dictionary.

6. Please update your project template. It sucks. Why make thing confused? Dynamic Link Library (C++ only!!!), Shared Library (where is my dll.h but only main.c?) and Static Library (dll.h ?), too much, too confused.

7. Code suggestion way better than DevC++ but it has a very annoyed bug, it randomly stopped working after sometime. The only way to restore it is delete %AppData%CodeBlocks and re-setup every thing (compiler option, debuggers, editor...) again.

Offline raynebc

  • Almost regular
  • **
  • Posts: 217
Re: CodeBlocks sucks
« Reply #1 on: October 03, 2018, 07:44:57 pm »
I switched to Code::Blocks because DevC++ became so broken it was practically unusable, we're talking constant program crashes.  C::B has some faults, but it is quite stable and I rarely have any issues with it that are more than minor annoyances.

Offline killerbot

  • Administrator
  • Lives here!
  • *****
  • Posts: 5491
Re: CodeBlocks sucks
« Reply #2 on: October 03, 2018, 10:00:31 pm »
as for 1, can you give steps to reproduce ?

as for 2 : we are going to step up to a new compiler, though we do not consider ourselves as compiler distributors

as for 3 : forum to me always accessible, main page I don't visit that much off course.

as for 4 : the old borland stuff is in there from the past, and hasn't been removed, since it still works, question is, is anybody still using that, probably, but in very low numbers for sure. As for the newer versions, no idea, I gave up on borland the moment c++11 came, are they up to par with that or even c++14/17, I have no idea, if they are not, and the compiler is not free, I would not spend time on it.

as for 5 : this should be fixed, wx should provide this abstraction of the path separator for us

as for 6 : please make your suggestions how you would define each template

as for 7 : this is a hard job, we need to wrap around things like clan for that, just simple parsing can not do the job anymore


Please elaborate on "Your Project Build Option is a disaster, very very stupid and poor engineered (broken by design)", because this sentence is f*** useless, it does not say what is wrong. This is generic blabla bullshit from your side. It is the same as the world sucks, ok great, but what do you want to be fixed ? Should we launch a nuclear rocket so the world explodes and the problem is solved by design. Should I hire a "gun for hire" to shoot complaining people, because when they are all dead no more complaints and we consider then there are no complaints that all is perfect? If you give specific information on what is broken, or certain flows that could be improved or are flawed, then we have something to work on.


And we do not consider ourselves to be the best, we are very aware we are a little niche player, and in certain use cases we are very well suited compared to bigger bloated systems.

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: CodeBlocks sucks
« Reply #3 on: October 03, 2018, 11:08:54 pm »
3. The site/forum problem are relatively new and local problem starting with today the problem should be fixed.
(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 raynebc

  • Almost regular
  • **
  • Posts: 217
Re: CodeBlocks sucks
« Reply #4 on: October 04, 2018, 12:37:34 am »
Forum load times are better for me at least during the last couple visits.

Offline bcc32x

  • Multiple posting newcomer
  • *
  • Posts: 18
Re: CodeBlocks sucks
« Reply #5 on: October 04, 2018, 03:55:28 am »
as for 1, can you give steps to reproduce ?

as for 2 : we are going to step up to a new compiler, though we do not consider ourselves as compiler distributors

as for 3 : forum to me always accessible, main page I don't visit that much off course.

as for 4 : the old borland stuff is in there from the past, and hasn't been removed, since it still works, question is, is anybody still using that, probably, but in very low numbers for sure. As for the newer versions, no idea, I gave up on borland the moment c++11 came, are they up to par with that or even c++14/17, I have no idea, if they are not, and the compiler is not free, I would not spend time on it.

as for 5 : this should be fixed, wx should provide this abstraction of the path separator for us

as for 6 : please make your suggestions how you would define each template

as for 7 : this is a hard job, we need to wrap around things like clan for that, just simple parsing can not do the job anymore


Please elaborate on "Your Project Build Option is a disaster, very very stupid and poor engineered (broken by design)", because this sentence is f*** useless, it does not say what is wrong. This is generic blabla bullshit from your side. It is the same as the world sucks, ok great, but what do you want to be fixed ? Should we launch a nuclear rocket so the world explodes and the problem is solved by design. Should I hire a "gun for hire" to shoot complaining people, because when they are all dead no more complaints and we consider then there are no complaints that all is perfect? If you give specific information on what is broken, or certain flows that could be improved or are flawed, then we have something to work on.


And we do not consider ourselves to be the best, we are very aware we are a little niche player, and in certain use cases we are very well suited compared to bigger bloated systems.

1. latter post please, it's long.

2. thanks, I like you more than mr. obfuscated who told me "do it yourself".

3. I'm on South East Asia, your whole domain codeblocks.org and it child reported by issitedownrightnow almost constantly down, many time down for more than 7 days, I can only access it a very short time a day like 1 hours but later revisit it down again, make me thing, is this site DDoS-ed?

4. borland launched a clang based compiler long time ago to keep pace with c++ stardard, there are two compiler: bcc32c which keep the old bcc32 syntax, bcc32x which use clang syntax (indeed gcc like syntax). it's very easy for you to update borland 5 template to borland 10.1 which embarcadero freely distribute here: https://www.embarcadero.com/free-tools/ccompiler (require sign up but it's completely free). the only difference causing much problem is borland gave up there brcc32 resource compiler in favor of microsoft rc.exe shipped instead. and microsoft distribute visual studio build tool 2017 (vc2017 compiler) for free.

5. good to hear that.

6. remove what unneccesary, what the hell you do with Java Application template when later it ask for GCC compiler and can't even detect JDK? You should copy netbeans behavior deactivate by default any template the user properly doesn't use and keep only standard Console, Dll, Win32GUI (deactivate all the QT*, WX*...). if the user want, he can easily activate what he need. About Dll, use only DLL template with option in the project option to specify whether it is dynamic or static, support a standard dll with dll.c (or dll.cpp) and dll.h (don't forget this header), dll was intended to write using C then linked by other, why the hell Dynamic Link Library template is C++?

My sentence is not useless, there really problem of out-of-sync between your global project build option and it child Debug and Release, it's very easy to reproduce, you change search directory or liker setting of the global, the first time it sync-ed to the child, the second or third or *th time it doesn't, you have to go the each child and change again, very time consuming: like, you remove a dir from search dir to point to new dir, the child still keep old dir so compiler started errors. it's really broken, I like DevC++ makefile based than your xml based, in my opion xml is evil, I'm plain text fan. and I've visit your dev forum sector and if I not remember wrong, some one actually regret about the decision to use xml based build. To test my word, you just download Win32++ and modifiy some of it sample provided in codeblocks .cbp project with multi compiler and multi target: Debug Borland, Release MingW, Debug VC2003.... and you will see the pain of using your system. I'm never lie.

Offline bcc32x

  • Multiple posting newcomer
  • *
  • Posts: 18
Re: CodeBlocks sucks
« Reply #6 on: October 04, 2018, 07:43:24 am »
1. I can reproduce the problem with my toy dll written in free pascal, not only the delphi dll I used.

LibTest.pas

Code
library LibTest;

{$mode objfpc}{$H+}

uses
  SysUtils, ctypes;

function DoubleIt(InParam: cint32): cint32; cdecl;
begin
  Result:= InParam * 2;
end;

exports
  DoubleIt;

end.

LibTest.h

Code
// too lazy to write header guard so let it is

#include <stdint.h>

int32_t __cdecl DoubleIt(int32_t InParam);
main.c

Code
// copy from DevC++ project (successfully build and run) so expect the same for C::B but it isn't

#include <stdio.h>
#include <stdlib.h>
#include "LibTest.h"

/* run this program using the console pauser or add your own getch, system("pause") or input loop */

int main(int argc, char *argv[]) {
printf("Double Of %d : %d\n", 3, DoubleIt(3));
system("PAUSE");
return 0;
}

All the file are in project root folder: C:\LibTest (LibTest is the C::B project).
Add current project root folder C:\LibTest to Search Directory (Compiler and Linker)
(WTF? Why I've to add it to search dir, isn't it obviously must be searched by default?)
Can't add LibTest.dll from Linker setting but choose All file to add it anyway, failed: can't find LibTest.dll!
Follow mingw.org tutorial to create .a file:

dlltool -z LibTest.def --export-all-symbol LibTest.dll

dlltool -d LibTest.def -l LibTest.a

Follow someone on this forum to add this .def file to linker, either by choose All file like as the dll or other linker option (also on this forum, not bookmarked so don't have the link and don't care to search again because too tired)

Failed: can't find LibTest.def!

Add the LibTest.a file to linker (accepted), expect anything to be right but again: failed, can't find LibTest.a!

Either absolute path or relative path the result still failed.

I even try to add all the file to project itself but still not find LibTest!!!

WTF! Does this IDE blind or too stupid to see the file I wonder?

With DevC++, I simple add the header to project and the dll to linker and it's all.

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: CodeBlocks sucks
« Reply #7 on: October 04, 2018, 08:11:01 am »
2. thanks, I like you more than mr. obfuscated who told me "do it yourself".
What have I told you?

3. I'm on South East Asia, your whole domain codeblocks.org and it child reported by issitedownrightnow almost constantly down, many time down for more than 7 days, I can only access it a very short time a day like 1 hours but later revisit it down again, make me thing, is this site DDoS-ed?
You have to contact your service provider to see why it is blocking codeblock.org. Just keep in mind that the site had problems for the last one-two weeks. If the complains are from this period, then it was a global problem. It was an exception, not the rule. The problem should be fixed and everything should be back to normal.
(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 bcc32x

  • Multiple posting newcomer
  • *
  • Posts: 18
Re: CodeBlocks sucks
« Reply #8 on: October 04, 2018, 09:25:54 am »
2. thanks, I like you more than mr. obfuscated who told me "do it yourself".
What have I told you?

3. I'm on South East Asia, your whole domain codeblocks.org and it child reported by issitedownrightnow almost constantly down, many time down for more than 7 days, I can only access it a very short time a day like 1 hours but later revisit it down again, make me thing, is this site DDoS-ed?
You have to contact your service provider to see why it is blocking codeblock.org. Just keep in mind that the site had problems for the last one-two weeks. If the complains are from this period, then it was a global problem. It was an exception, not the rule. The problem should be fixed and everything should be back to normal.

You told me study the xml based build file of C::B and add new update compiler myself.

The site codeblocks.org fairly stable now. My provider didn't block it. This is the global problem. But don't blame me. How can I check info about this project? I visit it sourceforge.net repo their's no ticket about it. I myself think it's ddos-ed or major infrastructure upgrade (unlikely because no new version in repo).

Offline BlueHazzard

  • Developer
  • Lives here!
  • *****
  • Posts: 3353
Re: CodeBlocks sucks
« Reply #9 on: October 04, 2018, 09:28:48 am »
OK, now i play the persona non grata and tell you that we need a build log to find the error. You have to understand that without build log we can not tell what you are doing and we can not tell you what is going on. Only by describing you let out information only a build log can tell.

Quote
All the file are in project root folder: C:\LibTest (LibTest is the C::B project).
Then add a "." in Project->Build options->Select your project on the left->Search paths->Compiler
and Project->Build options->Select your project on the left->Search paths->Linker
And the compiler will search in your project folder.

Quote
(WTF? Why I've to add it to search dir, isn't it obviously must be searched by default?)
That is your opinion. Mine is an other. For example in java it takes automatically some predefined files from some folder and i needed like 100h to find out why it always took the wrong file. It simply had an build in automatic search algorithm. This annoyed me like hell. Better the user has to tell where to search. So he always knows what is going on.
Also if you use different libraries for Debug and release they can not be in the project root folder. All in all it is complex, and codeblocks goes the non idiot proof way and lets the user decide what to do.
You can create a project template where the project folder is added by default: Create a your basic hello world project like you want it. Then File->Save as template. The next time you can use this as base with File->New->Project->User templates
Again: Codeblocks goes the way that a user can decide by itself how to do things...

Quote
Can't add LibTest.dll from Linker setting but choose All file to add it anyway, failed: can't find LibTest.dll!
What is the exact error? There you have to differentiate:
1)  The compiler can not find the file per se? Fix the search path in the Project->Build->options->Select the project name on the left from the tree->Search direcotries->Linker
2)  The compiler can find the file but can not read it (this error is not easy to find, because the compiler tells you only about undefined reference). To find this error you have to add the "-v" option to the linker settings in Project->Build options->Select the project name on the left->Linker settings->additional options. The rebuild and look at the build log. The compiler will then tell you that the provided .dll is not usable. To fix this you have to got the dllool way as you described.
But without build log it is difficult to investigate.

Quote
dlltool -z LibTest.def --export-all-symbol LibTest.dll

dlltool -d LibTest.def -l LibTest.a

Follow someone on this forum to add this .def file to linker, either by choose All file like as the dll or other linker option (also on this forum, not bookmarked so don't have the link and don't care to search again because too tired)

Failed: can't find LibTest.def!

Add the LibTest.a file to linker (accepted), expect anything to be right but again: failed, can't find LibTest.a!
About this, you have to know that this is a mingw thing. Nothing to do with codeblocks. Also it is a language c/c++ thing. You can not mix different compiler and languages and think this is easy to handle... Every language uses different name mangling, different file formats for libraries, different call conventions ecc...

Quote
I even try to add all the file to project itself but still not find LibTest!!!
WTF! Does this IDE blind or too stupid to see the file I wonder?
The IDE does not complain, the compiler complains...

Quote
I like DevC++ makefile based than your xml based, in my opion xml is evil, I'm plain text fan.
then go the makefile route:
Project->Properties->Project settings->This is a custom Makefile
Now codeblocks will ignore all things and use the Makefile you provide to generate the binary. Note: No compiler settings are used, you have to write everything in your makefile by hand. Codeblocsk simply calls
Code
make -f Makefile TARGETNAME
nothing more, nothing less. You have to add the source files by hand to the Makefile. You can set up how codeblocks calls the makefile (for example don't add the target ecc..)

Quote
My sentence is not useless, there really problem of out-of-sync between your global project build option and it child Debug and Release, it's very easy to reproduce, you change search directory or liker setting of the global, the first time it sync-ed to the child, the second or third or *th time it doesn't, you have to go the each child and change again, very time consuming: like, you remove a dir from search dir to point to new dir, the child still keep old dir so compiler started errors.
I use codeblocks on a daily basis and never encountered this. Codeblocks uses basically this hierarchy to set paths and compiler options:
Code
Global compiler settings->Project settings->Target settings
But you can change this behavior in Project->Build options->Select the target name in the left tree control->Compiler settings->policy:
Quote
Append target options to project options
is the default, but there are many more policies..
Generally you add the search directories only at project level. This propagates to target level. Normally you won't change the global compiler settings...

The only thing i know that does not get updated and what annoys me a lot is the back tick cache. So if you use something like this in your build options
Quote
´wx-config --libs´
You have to restart codeblocks if something changes...

Codeblocks has it bugs and its flaws and we try everyday to fix them if a user reports errors. But it is not a easy to use software and it does not intend to be. You are using a build system you have to learn, like make files or cmake. In addition you want to mix different compilers and languages, what adds complexity on top. This is not a codeblocks thing but a compiler thing.
You posted 3 messages in this forum (as far as i can see):
1) The obligatory "i am human"
2) The question for adding the borland compiler
3) This rant.
If you would have asked for help sooner and provide build logs we would be able to help you and keep the fustration level low...

Offline bcc32x

  • Multiple posting newcomer
  • *
  • Posts: 18
Re: CodeBlocks sucks
« Reply #10 on: October 04, 2018, 09:58:02 am »
^ Too long, I've read all but I'm too tired to reply in details. I'm very sick now. Perhaps I would try C::B when you release a new major version, not now. I uninstalled it.

My problem is not compiler or linker because if I copy the full command like of, gcc, g++ to terminal and it run fine (miraculously). Only inside C::B it has problem, this is C::B error, don't blame the compiler.

About the compiler, your shipped compiler can't compile normally Win32++ sample source, despite it's all TDM-based but DevC++ TDM 4.9.2 works fine, your 5.1.0 fails.

I've to use latest 8.1.0 mingw64 with win32 thread and sjlj exeption handling to make the source compilable under C::B. At first it give me trouble about cc1plusplus crash then I realized since version 8 gcc default to c++11, I've to add std=c++98 and it worked fine. Again, miraculously with DevC++ the same compiler the same sample code without any tuning it compiled fine despite giving many warning because incompatible between c++98 and c++11. This made me to think, C::B hates me :(

The dll I used is written in delphi (very old before embarcadero empire now mircofocus aquirerd) then I ported to Lazarus Free Pascal. FPC and GCC use the same binutils and their objects file are compatible, event dwarf debug info fpc fully supported.

It is my purpose to code mainly in my language delphi and done the least on C/C++ side so I use a dll. My app is console based. About Win32++, I just played with it but don't use it, I prefer RAD tool of Lazarus than writing resource file myself.

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: CodeBlocks sucks
« Reply #11 on: October 04, 2018, 12:16:04 pm »
You told me study the xml based build file of C::B and add new update compiler myself.
Probably I've told you this about the Borland's compiler, but here you're complaining that we're shipping TDM's MinGW and you don't need to do any editing to install any other MinGW!!! You just need to setup the toolchain paths using the provided UI.

If you want to get the Borland's compliers working in C::B you should provide patches. Or you should find someone who is interested in doing the patches for you.
This is how open source works.
(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 oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: CodeBlocks sucks
« Reply #12 on: October 04, 2018, 12:18:36 pm »
^ Too long, I've read all but I'm too tired to reply in details. I'm very sick now. Perhaps I would try C::B when you release a new major version, not now. I uninstalled it.
Well done you've wasted the time of multiple people, I guess you've achieved your goal.
(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 bcc32x

  • Multiple posting newcomer
  • *
  • Posts: 18
Re: CodeBlocks sucks
« Reply #13 on: October 04, 2018, 01:26:03 pm »
You told me study the xml based build file of C::B and add new update compiler myself.
Probably I've told you this about the Borland's compiler, but here you're complaining that we're shipping TDM's MinGW and you don't need to do any editing to install any other MinGW!!! You just need to setup the toolchain paths using the provided UI.

If you want to get the Borland's compliers working in C::B you should provide patches. Or you should find someone who is interested in doing the patches for you.
This is how open source works.
If I want you to add a branch new all new all different compiler... but, I asked the developers (many, not just you) if they can update the Borland 5.5 template to support Borland 10. The work is trivial, replace bcc32.exe with bcc32c.exe and add rc.exe from Visual Studio template to replace brcc32.exe because Borland abandoned brcc32.exe. If I can do myself, well, I hate xml, I'll not ask. I ask for someone willing to help me, I don't ask you, stop telling me to "do my own patch".

I complain your default shipped TDM-GCC because it's broken and like you said, it's too easy to add another MinGW why you don't bundle the new MinGW already? Indeed it's not fast like you said, you've to provide the MinGW installation dir and remove all of the mingw32- prefix to only left gcc, g++ not mingw32-gcc or mingw32-g++. It takes time. You've to do this everytime you open a new profile of C::B or install new C::B on other mates' machines. It's a very unnecessary step and inconvenient.

Offline bcc32x

  • Multiple posting newcomer
  • *
  • Posts: 18
Re: CodeBlocks sucks
« Reply #14 on: October 04, 2018, 01:36:25 pm »
^ Too long, I've read all but I'm too tired to reply in details. I'm very sick now. Perhaps I would try C::B when you release a new major version, not now. I uninstalled it.
Well done you've wasted the time of multiple people, I guess you've achieved your goal.

What is my goal, huh? Making people to think me as bad guy or troller, spammer pleased you? I hope you pleased.
The time I post the snippet above to reproduce the problem, I already removed C::B, how could I give you build log?
It's very straight forward. Download freepascal compiler and type fpc LibTest.pas then you've the dll, I provided step by step what I do.
Don't ask me to download again, reinstall C::B again just to see the same error again.
You think only your time is precious?
It has wasted me more then 10 hours search over the net because I don't want to ask on this forum. I didn't talk with any other devs but only you. I dislike you from the first sight and I don't want to talk with you. You don't have to please me or anyone, do it your way, but I've the right to say I don't like you and I want to avoid you!