The latest CDT offering has just been released. Today CDT is generally acknowledged as the de-facto C/C++ IDE in the industry. The extensive code navigation features are amongst the highlights that the framework has to offer. Not wanting to rest on their laurels, work is already well underway on the next release, CDT 6.1. In a recent blog article, CDT lead Doug Shaefer highlights that there will be a big focus on fixing up the scanner discovery mechanism.
Scanner discovery mechanism is the feature in CDT that supports code navigation by automatically discovering build information such as include paths and build macros. The build information is normally retrieved in one of two ways. The first involves running a fixed gcc command to query the known include paths and macros. The second way involves parsing the build output to identify relevant build information.
This is a great feature that enhances code navigation, and in particular creates a very good start up impression. It means users can navigate to code libraries even before they build a project. In our experience this has been a very desirable thing, particularly when our clients provide specialist libraries such as peripheral driver code. Scanner discovery means their customers can easily navigate the code and link to header files to browse the api for the peripherals. However, as it stands today the scanner discovery mechanism is both architecturally flawed and buggy. We have spent significant time fixing it up for clients in order to give the desired experience. However, there’s only so many times we can patch it up before wanting to help fix it up once and for all.
As a result we will be working with the CDT team to help fix scanner discovery for the next release. In fact we will be part of the ‘rag-tag group’ Doug refers to in his blog. The first step was to have an initial kick-off meeting, followed by all capturing the problem and trying to define the architecture. This has been done using the CDT wiki. While one or two CDT committers have put down details of what the high-level architecture should be, we have added our thoughts on the specific issues we have seen with the implementation and low-level architecture based on our experiences.
The next step will be the interesting one as we work out how best to proceed. In the meantime, Kichwa Coders will also be working on some low-hanging fruit by working on scanner-related bug fixes such as using variables in dialog boxes. All in all, it will be an interesting experience working on a relatively far-reaching feature with several other developers spread out across the globe, yet ultimately very rewarding to be part of fixing up this key feature of the CDT. In particular for us, it means yet another feature our clients can take for granted and keep focusing on their core competences.