Practical Solutions for Real-Life Programming

Home Arturius Errata Resources Test Programs
Articles Compilers Libraries Site Map Tools
Site Map: /Arturius/index.html Visit The Imperfect C++ Website!

Arturius

"Merlin was nervous upon a duel with Arturius"

What is Arturius?

As I describe in Appendix C of Imperfect C++, the Arturius project came about as a requirement I had to subject sources to compilation by a number of different compilers. (This is because keeping the STLSoft libraries compatible with over 30 compilers would be an otherwise unmanageable task.) Thus was Arturius born.

But what is Arturius? Well, simply, it's a compiler multiplexer. You issue a command-line (as shown in the screenshot below) to arcc, as you would to a given single compiler and the file actually gets compiled by a suite of compilers, whichever ones you have configured Arturius to recognise. In the screenshot below, it's compiling arf.cpp, the main implementation file for arf, one of the Arturius tools. As you can see, the command to arcc stipulates seven compilers to which to dispatch compilation. Not stipulating any compilers will result in all registered compilers being used. -x is shorthand for the arcc option --exception-handling=on. --announce-tools causes the output lines to be interspersed with the Tool: <tool-name> labels. All the other parts of the command-line are recognised standard options for compile-only, preprocessor symbol definitions and include directory specifications.

Sample Arturius output

As you can likely guess from the output, I've developed the rewrite of Arturius in Intel and GCC, since they are compiling cleanly. But this screenshot plainly demonstrates the power of Arturius: the Borland compiler has caught an unused variable; Borland and Visual C++ have caught a reference conversion error on lines 380 and 381; and two of the Digital Mars configurations (8.40, beta + STLport) register different aspects of the same error.

This is exactly what Arturius is good for. It's been my experience that all compilers catch particular errors/warnings that others miss, so getting your code compiled by a variety of compilers provides much better coverage.

Good news and bad

Do you want the good news first, or the bad news? I prefer to go for bad first, in order to finish on a happy note, so that'll be our approach today. (Don't worry, there's much more good news than bad.)

Bad News

Despite my having said in the book that this CD would contain the rewrite (version 2) of my Arturius compiler multiplexer tool, it doesn't. The reason for this is pretty simple: it's not ready. Let me digress ...

I've been using what I now call Arturius Version 1 for some years, and it works very well. However, its utility to me (and the specifics of my development environment) did not mask its less appealing characteristics:

  • It had evolved markedly from its original intentions, so was not what one might call "well-designed"
  • It was not very customisable, as a lot of assumptions regarding my operating environment had crept in
  • It was pretty brittle, and did not report failures adequately
  • Neither its interface nor its implementation were particularly discoverable.
  • It didn't have any "higher functionality", such as plugging into Integrated Development and Debugging Environments (IDDEs), impersonating other compilers, etc.
  • It had no documentation, neither user nor design.

Furthermore, the code itself was a pretty appaling mess, especially in light of the (hopefully) good advice I've given in the book. In reviewing its implementation as of several months ago, there was just no way I was going to show you version 1: a rewrite was necessary. I said in Appendix C that in the 2-3 months between the book being completed and the CD being ready I would be able to effect a worthy rewrite. Well, so much for the naivety of a first-time author. Little did I realise the amount of work you have to do on your book - editing cycles, marketing, etc. - after its been written, and by the time I started on the Arturius rewrite I had only three weeks. Although I've done the rewrite, and have now got a working tool - as you can see from the screenshot above - it's had less than a week of testing, is compilable/buildable only with Intel C++ compiler, and has not been ported to Linux.

I figure I might lose the interest of 10% of you for not having it on the CD as promised, but that I most certainly would lose 50% of you if it was present but of low quality. And those 10% who would not download would be lost anyway if it was low quality, so there was really nothing to gain saving face. Imperfect Practitioners don't care about saving face; just about quality work, and I intend to provide you with a high quality, well-tested and ported tool that should be available by the time you're reading this.

So fear not. You have not been duped. Arturius is not vapourware. As I write this - on the last day of the CD preparation - I've just built the unit-test programs for all STLSoft sub-projects with more than a dozen different compilers, and all it took was typing one command. So, to the good news ...

Good news:

The good news is this: It's eight weeks from now until Imperfect C++ hits the book stores. In this time I will be able to complete the Win32 version and may also have the Linux version ready, all available via the Imperfect C++ website (http://imperfectcplusplus.com/) and the Arturius website (http://arturius.org/). On reading this, you should visit the Arturius website, and download the latest version. But also keep up-to-date with the changes, as I expect Arturius to mature, and increase its feature set, throughout 2004-2005.

The features/components that I intend Arturius to have are listed below. Those marked with * are already implemented in a pre-release form:

  • arcc*. A command-line tool that can compile source file(s) by a customisable suite of registered compilers, and present their collective output in a standard form
  • Compiler Option Filters*. The architecture supports filters to translate the canonical arcc command-line into compiler-specific forms. Filters may be defined as internal rules, as dynamic library plug-ins, as separate executable programs, or as Perl, Python or Ruby scripts.
  • Output Filters*. The architecture supports filters to translate the compiler-specific output messages - which vary widely between compilers - into a common-format. Filters may be defined as dynamic library plug-ins, as separate executable programs, or as Perl, Python or Ruby scripts. The ones I've written so far output in the Digital Mars/Intel/Visual C++ format

      <filename>(<line#>): <error message>

    but you'll be able to write filters to produce any output format you wish.
  • Arturius Option Filters. The architecture will support filters to translate compiler-specific command-line forms into the canonical arcc form. Filters will be able to be defined as internal rules, as dynamic library plug-ins, as separate executable programs, or as Perl, Python or Ruby scripts. This functionality will be combined with a command-line driver, such that you'll be able to replace a given compiler in your makefiles / build systems and get the benefit of compilation with a suite of different compilers.
  • Plug-Ins. I intend to provide plug-ins to Visual Studio (hopefully both Visual Studio 98 and .NET (200x)), such that one will be able to compile with a suite of compilers to catch all those bugs that Visual C++ - even the excellent v7.1 - misses. Once these plug-ins are developed, other people will be able to develop analogous plug-ins for their IDDEs of choice.
  • Linking. The current version of Arturius only supports compilation. I plan to provide functionality such that one can designate a primary compiler whose output will be used to build a target executable, and the rest will compile-only.
  • More sophisticated environment handling. The current version of Arturius reads environment for compilers from a single configuration file. I plan to allow an intelligent merging of environment information built up from the project-specific configuration files, user/system environment, in addition to the current compiler environment configuration files.
  • Automatic installation/configuration tools. I've created some simple Ruby scripts that can generate a default set of configuration/filter files for a given compiler. I plan to do much more with this, such as a tool that will scan your hard drive(s) to find all well-known compilers, and automatically build up compiler configurations for you to edit, saving installation/configuration effort.

So that's the state of play. By the time you read this the first 3-4 items on the list will be available, and perhaps some of the later items also.




Valid XHTML 1.0! Imperfect C++ content copyright Addison-Wesley | Additional content copyright Synesis Software Pty Ltd and Greg Peet
Website designed by Greg Peet. Thanks Greg!