Carbide needs a rebuild option

     By and large, Carbide is the best IDE for Symbian development available today. Working on the shoulders of Eclipse, Nokia has spent considerable time and effort into customizing Carbide to a point where it makes Symbian development convenient for developers. Having said that, I should also point out that Nokia and Carbide both have a long way to go to provide as great an experience for Symbian development as, for instance, Apple and Xcode have for iPhone development.

     Under the hood, the Carbide camp has adopted what has become second nature for Unix and Linux developers: the “Keep It Simple, Stupid” (KISS) philosophy. Carbide heavily uses a tool-chain to perform a lot of different yet important tasks. That tool-chain includes interpreters such as Perl, compilers such as gcc, build configuration utilities such as make, powerful debuggers such as gdb, etc. When a project is built, or even cleaned, Carbide actively relies on this tool-chain to perform a set of very crucial tasks. And in the traditional Unix/Linux style, those disparate tools are linked together by the use of pipes. So, one tool performs one task that it is designed to do best, spewing its output to another tool to perform another task. This is a great philosophy to follow, I believe, because some of the best open source softwares are utilized. In other words, Carbide, among many other things, does two things in particular: it provides a polished, snazzy front-end that lives on top of powerful, command-line open source tools; and it links together a set of tools to make possible different things. If you have used Linux extensively or programmed on it, you will feel at home as this methodology is not uncommon there.

     Admittedly, I have a plethora of pet peeves with Carbide in general and Symbian development in particular. However, I have decided to gripe about one such annoyance that I have with Carbide. Carbide doesn’t have a “rebuild” option. Anyone reading this may think I am whining about a very trivial thing, but it isn’t trivial at all. Consider the fact that Carbide relies largely on piping together different command-line utilities to perform a disparate set of tasks, and presenting the results on the front-end. While Carbide does it mostly right, it falls short at many places when it comes to clearly showing what went on in the background, when, say, a project build fails due to errors. Building of a Symbian project can be divided into several parts, which Carbide abstracts under the “build” operation. These parts include, but are not limited to, compilation of resource files for UI elements, compilation of source files and linking of resulting object files, creation of binaries, packaging of binaries and resource files, creation of SIS files, signing of SIS files, etc. Carbide tries really hard to keep the user aware of anything that goes wrong at any of those steps during a project build. However, Carbide is not perfect, and as such leaves itself open to subtle problems that can become a cause of increased annoyance for the developer.

     Now, Carbide does have a “clean project” option, which is what I use before building a project every time. But I don’t know how many other developers do so — I did not use to routinely in the past, for example. If you are a Symbian developer, you must have been bitten at least once by the problem that arises from not cleaning your project before every build. Because the build process is divided into a number of different steps, with some steps producing concrete artifacts that are used by the following steps, there is a subtle, ugly problem lurking in there. Consider the step where resource files for the UI elements are built, and also the step where the package for the application/project is built. The latter has to incorporate all pertinent compiled resource files as well as binaries into one final package. And here lies the subtle problem: the tool that is used to create the package does not look at the previous steps to ensure that everything went ok. It can’t. All it does is that it looks into some directory for the presence of the compiled resource files and binaries it is looking for, picks them, and packages them up without thinking about whether the current build failed to produce any resource files or binaries, and that those that it picked are actually not from a previous, now out-dated build (which were left behind from the previous build because the build data wasn’t cleaned). This hideous problem surfaces when, after making adjustments in the UI elements and resource files, any compile time errors are introduced. Now, Carbide gets below par when it comes down to catching some of those errors. For example, for some hideous errors that crop up during resource compilation time, Carbide is only able to catch them when at the far end of the build process, the package manager fails to find compiled resource files because those didn’t compile from earlier. However, if there are older compiled resource files available, and an error is introduced in the resource files which precludes new resources from being built, those errors will be quietly lost because the package manager will quietly and happily pick up the old resource files (as it can’t tell which are new or old, or whether any of the steps that came before it actually passed). As a result, the developer will be left scratching their head for a long while, trying to figure out just why is it that their changes are not being picked up when they run their application. But, it could easily get worse than that.

     So, if you are a developer, and you are not in the habit of cleaning up your projects before compiling every time, you will one day or another get bitten by this hideous bug. And when you do, it will hurt for a long while before you are able to realize where it is hurting and band-aid it.

     This is the reason why I am in favor of Carbide having a “rebuild” option.

Advertisements