User forums > General (but related to Code::Blocks)
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:
--- Quote from: paulvdh on March 25, 2018, 02:01:38 pm ---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.
--- End quote ---
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.
--- Quote from: paulvdh on March 25, 2018, 02:01:38 pm ---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 ???
--- End quote ---
This is used to find the make executable and to provide some form of code completion.
--- Quote from: paulvdh on March 25, 2018, 02:01:38 pm ---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.
--- End quote ---
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...
--- Quote from: paulvdh on March 25, 2018, 02:01:38 pm ---In the project wizard there could have been a selection for makefile (& scons & cmake &...) based projects.
--- End quote ---
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:
--- Quote --- 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.
--- End quote ---
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:
--- Quote from: paulvdh on March 26, 2018, 02:04:43 pm ---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.
--- End quote ---
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.
--- Quote ---If C::B could startup in < 1s to edit a simple text file...
--- End quote ---
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.
Navigation
[0] Message Index
[#] Next page
Go to full version