The circumstances leading to the decision to use KAI's compiler for RunII C++ development have changed, but resources do not appear to be available to evaluate new C++ compilers, and their associated libraries, much less port code to them, at the current time.
Our initial decision to program to the ISO standard for C++ has been demonstrated to be a good one, since all of the compilers except Microsoft's have been trending in the general direction of standards compliance, just at different rates.
The biggest current trouble spots are:
The C++ portability project currently under development promises to insulate RunII code from compiler, and especially library differences. It is designed to decrease to nearly nothing as the various implementations become standards compliant. It should make RunII code portability between C++ compilers a reality in the two to four month timeframe.
C++ Development tools can be grouped into several categories: the compiler, the C++ libraries available with it, the runtime debuggers which can be used with it, tools for memory allocation debugging, and code browsers.
In a perfect world, we could pick the best tool from each of these categories, and have an excellent development environment. Unfortunately for all tools mentioned other than code browsers, incompatibilities between C++ compilers mean that the choice of compilers severely limits your choice of libraries, runtime debuggers and memory allocation debuggers.
So let us first consider the state of code browsers, and then proceed into the tangled web of other tools.
Currently the only code browsers in wide use at Fermilab are the "oobr" mode in Xemacs, and the "lxr" WWW-based browser, which are both Free Software. Other possible commercial solutions have so far proved both prohibitively expensive (especially for collaborating institutions) and not terribly inspiring in their behaviour and features.
We must then consider other tools in (ocaisionally overlapping) groups. We will start with the availble compilers, and work outwards.
For each of our major binary platforms we have several choices in compiler. The libraries and debugging tools usable with those compilers will be discussed with each one.
Unlike the situation a year ago, as of this writing, most of our vendors (except Microsoft) have versions of their compiler available which are mainly ISO C++ standards compliant. Unfortunately, other than SGI's latest 7.3 release, these new versions are not widely installed and available on Fermilab development systems, mainly due to delays in obtaining licenses for these new versions.
Note that, for Linux, the vendor compiler is the GNU compiler, discussed below.
For example, the latest Sun compilers have been out for several months now, but ScholarPak licensing for those compilers was only negotiated about 1.5 months ago, and distribution media has only been on site a week or two.
Tools available are generally:
The latest releases of the libraries for the vendor compilers are finally starting to be standards compliant. This is lagging the compiler compliance by several months. Most of the vendors don't seem to consider library variation from the standard a "serious" bug, rather they think about fixing it in the next release.
The vendors generally have at least a command-line debugger, and most of the vendors have some sort of proprietary GUI debugger.
The GNU gdb debugger works with most vendor C++ compilers, although correct name demangling is spotty.
Also the DDD GUI debugger front end works with most vendor command-line debuggers, as well as with gdb.
On most platforms we support, commercial packages like Purify are available for memory allocation debugging, and work with the vendor compilers. The notable exception is Linux, where Purify is not supported. Use of various debug-malloc type libraries has been suggested for these platforms, but a real evaluation of their usability has not been performed.
Tools available are generally:
The KAI compiler originally came with a version of gdb patched to understand their name-mangling scheme, (on platforms other than IRIX, where this didn't work, or at least not for N32 binaries) which in turn can be used with the DDD GUI debugger front-end to provide an adequate debugging environment.
Since that time, KAI has begun developing their own debugger, kdb, and dropped support for gdb. Their new debugger, while having an excellent theoretical feature list, is so bug-ridden as to be completely unusable. We have not received even a timeline for getting kdb bugs fixed.
In conversations, KAI representatives have expressed no interest in porting their name-mangling code forward to a more recent version of gdb that would support N32 binaries on IRIX, for example.
Investigation of the TotalView commercial debugger with KAI is under way, which includes good support for multiply threaded application debugging, which may be crucial for D0. A Linux version will avalible in a few months, we are a beta site. Future versions may also include a command-line debugger compatable with the DDD front-end, for folks who prefer an alternative user interface, but for the moment the current implementation on IRIX is signifigantly more stable than the KDB implementation.
Tools available are: