After I presented at IBM Innovate last year I was pinged several times on the usage of RTC for C/C++ development and the question, “does it really work?” I must admit I had a very similar reaction the first time I looked at RTC three years ago. What a great idea! A tool that would help me do what I wanted (visibility and configurable workflow) rather than trying to work in someone else’s vision of workflow. Not being a Java developer means some work ahead, but I knew Eclipse and was confident that it was possible.
So can RTC be used for C/C++ development? The answer is a definitive yes. While using RTC with C is not a shrink-wrapped solution from jazz.net, it is not difficult to implement. Following are some simple steps and basic constraints to enable C/C++ development in a RTC installation.
Let’s first start off with why RTC is suitable and valuable to C/C++ developers. The primary reason I like the RTC environment is that it makes good software engineering practices easier to execute. Practices such as modularity, composability, measurable quality, continuous builds, and agile planning are equally important no matter what implementation technology you are using. Those simple concepts are all independent of language, but the mechanisms/transports can be different from language to language. It is these mechanism variances that must be deployed to be successful with C/C++.
The most apparent issue with using RTC with C/C++ development is the shipped IDE. It is quite noticeable that the default client for RTC is Java. However, after doing a tour of RTC you quickly realize that RTC is not bound to a particular language environment, but rather to the facilities in Eclipse. This is the needed opportunity for leveraging the vibrant Eclipse community for the development language plug-ins. The good news for C/C++ developers is that the Eclipse CDT has matured over the last 7 years and is a very competent development environment. If you are using gcc, or gcc derivative, you will be successful (mingw or cygwin if you are on Windows) . Just hit the CDT update site from your RTC client and you will now have the facilities you expected to do C/C++ development.
If you are not using gcc, all is not lost. The prevalence of Eclipse as the foundation of many custom IDEs means that your primary IDE may already be available as an Eclipse plug-in. Contact your toolchain provider to determine their compliance. If they provide an Eclipse update site, simply point your RTC client to that update site and you are off just like your CDT counterparts. If they don’t have an update site but they do have an Eclipse IDE, then you still have the option of installing RTC. While in previous releases you were encouraged to use the IBM Update Manager, you also have the option of using the old “dropins” approach (This has been done from previous 2.0 releases by simply “redeploying” the links, jazz, emf, gef directories from an RTC client installation into your C IDE and doing a forced restart) , or in the recent p2 repository for the RTC plugins is available. My preferred path is the p2 repository, but your results may vary. Every toolchain integration is slightly different, so be patient and use the techniques and forums available in the Eclipse community. With the collection of approaches I’ve always been able to get to a successful integration.
If none of the options describe your situation (and you are not using Visual Studio which has its own plug-in) you are in a challenging spot. While you can use the base CDT to do your editing and you can receive some value, there are two things that you are going to miss. First, is the error parser for identifying build errors when you perform a make build. This is a console parser that grabs the output of a build and marks files and the problem list with the errors and warnings . The second element is the debugger integration. By default the CDT is enabled by the gnu tools (gcc, gdb, …) to provide this functionality. If your tools are derivatives you might get some support, but you and your tool vendors are likely going to have to do some investment to make your developers happy. These are must have capabilities to deploy RTC and perform C/C++ development. The trend is to move to Eclipse support for most all tools, if you do not have this support communicate the importance to your vendor.
Once you have an IDE that supports your development language, compiler, and debugger you are most of the way there. The other aspect of critical concern is the modularity and composability of your source. This contributes to the collaboration patterns (language independent) and the build procedures (language and tool dependent). For C/C++ developers the most successful pattern is to align the natural modularity of the code base (static library, dynamic library, executable) to RTC components. The collaboration patterns for this source are most likely tied to your organizational structure of teams so this can be mapped to an RTC stream. By simply combining these components into a single stream (Multiple streams are very valuable, but are complexities that can be deferred until the project complexities grow) you have your first RTC project for developing systems in C/C++. This is by far the simplest solution and drivers such as reuse, product variance, and large organizations may drive different patterns so there is no standard answer, but RTC is flexible to meet your needs.
Once you have your source organized the final step is to build your binaries in a structured, repeatable, and automated fashion. The objective is to have the developer initiated local builds and server side build engines to be able to perform the same function. This is critical for developers to have confidence in the tools and results locally and within the RTC reports. For a long time the C/C++ domain has been dominated by gnu makefiles as the specification language of building software. At this point there is little reason to change. This becomes especially true as you leverage the capabilities in the Eclipse client. The Eclipse CDT includes automatic builds and customizable targets to initiate builds. These capabilities simply reinforce the behavior that when I use the CDT, I should use make. At first glance there is a conflict with RTC because the Build Engines are dedicated to ANT.
In reality there is no real conflict and make and ANT can be used to compliment each other. First of all you are not forced to use ANT. You can implement build engines very quickly via the “command line” engine and simply spawn a “make” event in a command line shell. The process is trivial if all you are attempting to do is a “smoke test” on your build where only success or failure status of the build matters. You can even use such mechanisms to support other tools beyond make such as static analysis, metrics generation, unit test execution, or document generation. While this is a good first step, we all step beyond this quickly since only pass and fail can be determined and limited reporting can be performed beyond basic logging.
This is the motivation to take the next step to ANT. By taking this step you can wrap the make process with pre and post elements to enhance your build process with setup, reporting, and publishing. Consider now that specific tasks and contexts can be instituted prior to the build, a make build initiated unit tests evaluated successfully, documentation created, files packaged and posted, and download links created in your build report. While make is still the primary tool for the source build, ANT can be used to manage the entirety of the process and provide communication to the build event where it excels. This is the power of bringing these two capabilities together.
Once you’ve accomplished these steps you have a powerful development environment that works for your C/C++ developers and empowers the organization to deliver successful projects using the visibility and planning tools in RTC. While it does take a little bit of focused effort to augment RTC to work for C/C++ development teams, the value is available for those willing to invest. If your organization is in need of visibility and agility while developing C/C++ you should consider the capability that RTC presents.