Giving some feedback: Why I quit using Codeblocks.

[paulvdh]

Recently I switched from Mint 17 to Debian Buster and also had to re-install the programs I use.
I used Qt Creator on Mint for some hobby level code development for AVR's and other uC's, but because that is a bit of a nuisance to install (not in the package manager, fiddling with websites & downloads etc) I decided to give codeblocks another try.

The experience for me was not pleasant and in the meantime I've uninstalled codeblocks and I am back to QtCreator. I thought I'd give some feedback as of why I stopped using codeblocks again. Last time I used codeblocks was in 2015.

First there is the project name strangeness. When creating a "new" project codeblocks insists in making a new project in a new (or existing) directory with the same name as the project name. Somehow this don't fit in my brain and I always end up with an extra directory level when using the "project wizard". Quite annoying, but I can work around it by manually moving / renaming some files.

Then there is the project configuration. I like it very much that a codeblocks project is a human readable / editable xml file. What I don't like is that it seems impossible to do simple things in codeblocks in a simple way. I have quite a lot of existing projects which are based on makefiles. After a bit of struggling (in a sea of options) I found the button to point codeblocks to my makefile and set the checkbox for "this is an external makefile".
My projects run just fine from the commandline and I just want codeblocs to save the source files and then spit out some simple commands like "make all", "make program", "make clean". I could not get codeblocs to do this for the "compile" and "run" buttons.
I had some vague memories of getting this to work, back in 2015, so I revived an old codebocks project file from that time and modified it for this other project. (tnx to Xml). That way I finally got it to work. Back then it also was quite a struggle. After some more experiments I discovered that codeblocks insists on selecting some compiler which is hidden 3 levels deep in one of the menu's. Even after you have told it to use an external makefile it insists on using the inernal settings
This made me loose the last shred of confidence in what codeblocks does to my source code to make a binary and I gave up and uninstalled codeblocks.

Trying to read the documentation was also fruitless. I got redirected to some ancient pdf from codeblocs 10.xx.
Found some references of some internal scripting language and being able to call external tools, but that all seems overly complicated to make codeblocks just spit out a "make all".

There are multiple ways in which this could have been handled and worked flawlessly in a few minutes.
In the project wizard there could have been a selection for makefile (& scons & cmake &...) based projects.
Codeblocks could (and should in my opinion) have the smarts that if a makefile is part of a codeblocks project that it should USE that makefile. Period, no checkbox needed two or three levels deep in a menu that does not even work.

In the menu for selecting the compiler there could easily have been an option for make (&scons, etc) based projects.
Graying out all the unused tabs and menus which are unnecassary for makefile based projects would have been a big help for me. Why is it even possible to select a compiler if an external makefile is used???

For a lot of (especially for Open Source) projects it is mandatory that they are buildable from the commandline (and scripts). Partly also because an IDE is a quite personal experience (Each has it's unique mix of usability(= good) and complexity(= bad) ) and a makefile enables each person of a group to use their own favourite IDE to work on a project.

While reading some codeblocks documentation I read a reference of  codeblocs being able to generate makefiles, but that was apparently abandoned because there was too much complexitiy and the makefiles did not work good enough.
But even an 80% working makefile would be quite usefull. If codeblocks can spit out a makefile which has the compiler options set and a list of the source files to compile & link, together with some basic rules and targets, then a little bit of human touch to finalize the makefile is not such a big deal.

Codeblocks does a lot of things quite right and I like those, but the things that do not work properly / intuitively caused too much irritation and that is why I uninstalled it.

[oBFusCATed]

First there is the project name strangeness. When creating a "new" project codeblocks insists in making a new project in a new (or existing) directory with the same name as the project name. Somehow this don't fit in my brain and I always end up with an extra directory level when using the "project wizard". Quite annoying, but I can work around it by manually moving / renaming some files.

After you've selected the project name you can edit the output file names or folder.
So it is only annoying that you have to delete it every time.
I've thought of adding a checkbox to allow this to be disabled, but I've never went to do it.

After some more experiments I discovered that codeblocks insists on selecting some compiler which is hidden 3 levels deep in one of the menu's. Even after you have told it to use an external makefile it insists on using the inernal settings

This is used to find the make executable and to provide some form of code completion.

This made me loose the last shred of confidence in what codeblocks does to my source code to make a binary and I gave up and uninstalled codeblocks.

C::B does nothing to your  source code. It is not a compiler, but an ide. It just runs what you've told it to run...

In the project wizard there could have been a selection for makefile (& scons & cmake &...) based projects.

Cmake has special generators for codeblocks and they work relatively fine. (there is a lot that needs to be improved, but they are usable)
Csons is dead...

Thanks for sharing feedback...

[oBFusCATed]

Btw have you seen these two:
http://wiki.codeblocks.org/index.php/Codeblocks_with_scons
http://wiki.codeblocks.org/index.php/Code::Blocks_and_Makefiles

[paulvdh]

As I said before, I went back to QtCrator.
I am also just giving feedback from a standpoint of a new CodeBlocks user wit little to no experience with this IDE.

C::B does a whole lot more than "nothing" with source files. As an IDE it invokes a compiler with a whole lot of configurable options to make object files, and seeing on the command line output that the compiler / options are nowhere near what's in my makefile does not generate a warm fuzy feeling in my belly.

From your point of view I can understand that makefiles do not have a high priority. I myself actually quite dislike makefiles with a horrible syntax which should have been obsolete long ago, but makefiles are still an important part of code development.
I think that there is quite a group of people with a working makefile based project, which have become curious to try out C::B and want to compile an existing project and for that group it is not a nice and easy exprerience.

C::B has been around for years and there is obviously a lot of good in it and a tremendous development effort.
But still, when I try to use C::B, I find a lot of rough edges which make me suspect that the UI is trying to hide a lot of uglyness which should not have been there in the first place. I assume that you are lacking the manpower to make this product as good as you wish.
As an unsuspecting user back in 2015 I lost a few days worth of work because of the "symbolic link" issue (Which is now apparently fixed in the latest version).

But when I read this:

Once you have used a makefile, attempts to compile anything without a makefile result in a number of warnings. The only way I have found of solving this is to reinstall CB. If you need both perhaps it is possible to install 2 versions of CB.

then my first reacton is: WTF kind of crappy @#$%^& is this?

When evaluating a new product there are a few things I look out for.
First of course the functionality. C:B has an enourmous amount of functionality. No complaint whatsovever in that direction.
Then there is the absence of very big or annoying bugs. The score here is very low for me. It caused me to abandon C::B for another IDE back in 2015, and after finding the same annoyances in 2018 made me switch back to QtC and gave me the motivation to give this feedback.

Platformio uses scons, and it has quite an intriguing mix of capabilites.
With Platformio I was able to pull some compilers from the internet (AVR, Espressiv, STM32), compile some source code ( "arduino" and "mbed" platforms) and put the binaries into a uC without even trying hard or putting a real effort in it. It all "just works". I was very impressed by that. Unfortunately I do not very much like the "arduino" nor the "mbed" fameworks so I'm in dubio wether to proceed with platformio, but it left a pleasant feeling in my gut. C::B did not do that, it mostly surfaced old forgotton irritations.

I think C::B wil be a lot smoother experience (especically to beginners) if you can spare some development time for smoothing out the wrinkles for beginners who use it for the first time. This is mostly probably small stuff such as the project name selection, making makefiles "just work" and updating documentation (pdf from version 10 ).

Texts like: [quoteLast Updated on Wednesday, 26 August 2015 15:28 ][/quote] on http://www.codeblocks.org/ (in 2018-03-26) also seem an indicatation for a serious lack of manpower from the developer / maintenance side.

C::B has plenty to offer for experienced developers, and once you are experienced with C::B you probably are familiar with it's quircks (Every IDE has them), but I think these quircks scare away a lot of niewbies, and among lots of newbies you can possibly find a few new developers vor C::B itself.

Another thing I noticed is that C::B loads a lot of different "build systems" for different compilers at startup. Long startup times (especially on old computer) are a big trun off for IDE's such as Eclipse & Netbeans. Startup times can be much improved for C::B if it only loads what is needed and when it is needed.
If C::B could startup in < 1s to edit a simple text file I would be very tempted to use it for simple text editing and from there it is more tempting to also use it for code editing.
If C::B needs a few extra seconds for configuration purposes for the first compile / link cycle after startup that is not such a big deal. This probably is quite a lot of work for developers to implement but quite attractive for anyone seeking a responsive IDE.

[oBFusCATed]

C::B does a whole lot more than "nothing" with source files. As an IDE it invokes a compiler with a whole lot of configurable options to make object files, and seeing on the command line output that the compiler / options are nowhere near what's in my makefile does not generate a warm fuzy feeling in my belly.

When using makefile projects C::B will invoke only make (or the executable specified in the options). If you see different options, then you're not using make or your make is using strange environment. But I guess this doesn't matter, because you won't try to investigate what is going wrong.

If C::B could startup in < 1s to edit a simple text file...

This is annoying, but requires quite a lot of effort to improved.
I find that wx3.x builds load quite a lot faster than wx2.8...

BTW: Also you're wrong about our userbase - most of the users are first time programmers. They use Code::Blocks because this is what they have installed in school. And very few of them are capable or willing to submit patches to the project.

[paulvdh]

If you are interested in me generating some debug info I can re-install the C::B 16.xx version which comes with my package manager (Debian Buster). It's a fairly clean install of a new os, but I re-mounted my old /home HDD on the same place.

From memory:
The compiler output window generated all the wrong command line options which were clearly comming from internal settings, even though the "use Makefile" checkbox was Checked.
I got C::B to spit out a "make all" after I revived an old C::B project file from < 2015.
In that project file I saw a reference to an "AVR compiler".
When changing the compiler in the menu to another compiler, C::B could not compile anymore.
(Compiler not found message).
After changing it back to "AVR compiler" It used my makefile again.

Yet another confusion:
When replying to a post, the order of all posts in this tread swap around.

[BlueHazzard]

Yet another confusion:
When replying to a post, the order of all posts in this tread swap around.

makes sense.... you reply to the last post, not to the first, so you can read it fast. Not everything is confusing sometimes it is also convenience...
https://xkcd.com/1172/

I have created a ticket for one point of your critique, that i think is really point.
https://sourceforge.net/p/codeblocks/tickets/652/
With the ticket it won't get lost, and if the devs are ok to support it, i will "find" some "time" to implement it, after i have done all the other todos (many related to uC as it seems to be your main purpose)

[stahta01]

Yet another confusion:
When replying to a post, the order of all posts in this tread swap around.

makes sense.... you reply to the last post, not to the first, so you can read it fast. Not everything is confusing sometimes it is also convenience...
https://xkcd.com/1172/

I have created a ticket for one point of your critique, that i think is really point.
https://sourceforge.net/p/codeblocks/tickets/652/
With the ticket it won't get lost, and if the devs are ok to support it, i will "find" some "time" to implement it, after i have done all the other todos (many related to uC as it seems to be your main purpose)

That is a good idea for a change. I will see what items make sense to me to gray out when using a custom makefile.
I will be looking at only the compiler plugin [project/target] settings as things to gray out or not gray out.

Edit: All of the settings went away that I thought needed grayed out under Project Compiler settings; including some that I thought should not go away. So, I am confused on what to do.

Tim S.

[stahta01]

I just realized the problem is in the global compiler settings.

I think the solution should consider have a compiler used only for makefiles.

Tim S.

[oBFusCATed]

stahta01: What do you mean?

[BlueHazzard]

Edit: All of the settings went away that I thought needed grayed out under Project Compiler settings; including some that I thought should not go away. So, I am confused on what to do.

i really don't want to clutter this topic, and we probably should open a new topic for discussion, but i was talking about the settings:
Project->Settings->project settings->Object names generation (is not grayed out, but should be)
Project->Settings->Build targets->Output filename (should be grayed out)
ecc...
Project->Build options->Compiler settings->Compiler flags (should be grayed out)
Project->Build options->Compiler settings->Other compiler options (should be grayed out)
ecc...

I just realized the problem is in the global compiler settings.

I think the solution should consider have a compiler used only for makefiles.

I don't understand what you are talking about? If a custom make file is used EVERY setting of compiler executable (linker and so) on SHOULD be ignored. Only the "make" program should work.... Can you elaborate more? Am i on the wrong path here?

[stahta01]

Edit: All of the settings went away that I thought needed grayed out under Project Compiler settings; including some that I thought should not go away. So, I am confused on what to do.

i really don't want to clutter this topic, and we probably should open a new topic for discussion, but i was talking about the settings:
Project->Settings->project settings->Object names generation (is not grayed out, but should be)
Project->Settings->Build targets->Output filename (should be grayed out)
ecc...
Project->Build options->Compiler settings->Compiler flags (should be grayed out)
Project->Build options->Compiler settings->Other compiler options (should be grayed out)
ecc...

I just realized the problem is in the global compiler settings.

I think the solution should consider have a compiler used only for makefiles.

I don't understand what you are talking about? If a custom make file is used EVERY setting of compiler executable (linker and so) on SHOULD be ignored. Only the "make" program should work.... Can you elaborate more? Am i on the wrong path here?

http://forums.codeblocks.org/index.php/topic,22529.0.html

Tim S.

[Krice]

For a lot of (especially for Open Source) projects it is mandatory that they are buildable from the commandline (and scripts).

In IDE the project is the "makefile". Makefile is another way to tell how to build the project, but it's quite shady and outdated way to be honest. You should be able to compile the project within the IDE, why else use it in the first place? Why not use a text editor for code and write a makefile for the project if it's what you need? Or you can also write the code in IDE and then just write a makefile for the project and run it from command line.

[BlueHazzard]

Just a quick follow up for people who find this thread by google and wonder how you can make codeblocks to execute different targets with makefiles...

Codeblocks by default calls the makefile like this:
/PATH/TO/MAKE/SET/BY/COMPILER/OPTIONS/FOR/THIS/PROJECT/makebinary TARGET_NAME

So if your environment is like this:
1) AVR gcc (with bin utils and make and whatever) installed in /bin/avr/gcc and the base for your makefile project is the avr gcc compiler
2) Your project has two targets one is called "build" the other is called "program"

Now if you build (Build->Build) the target "build" codeblocks calls

Code

/bin/avr/gcc/make -f makefile build 

If you build (Build->Build) the target "program" codeblocks calls

Code

/bin/avr/gcc/make -f makefile program 

You can modify the behaviour in Project->Build options->Make commands