Re: [boost] Re: Testing with various compilers [was operators.hpp ...]

From: Beman Dawes (beman_at_[hidden])
Date: 2000-06-18 19:21:30

At 04:38 PM 6/18/2000 -0400, David Abrahams wrote:

 >From: "Beman Dawes" <beman_at_[hidden]>
 >
 >
 >> I have written the first draft of a GNU bash script to test compilers
 >> against the boost libraries.  It automatically generates an HTML
 >> table.  For a very tentative example, see
 >> http://www.egroups.com/files/boost/Members+Only/compiler_status.htm
 >
 >Beman,
 >
 >There is no bash shell for the Mac. I'd be happy to rewrite the script in
 >Python, which is supported on all platforms I know of. Does this make any
 >sense?

Well, I'm not terribly happy with the bash script; too many 
idiosyncrasies.  So I'll send you the script and you can give it a try in 
Python.

 >> I could use some help with these compilers:
 >>
 >>    GNU GCC 2.95.2
 >
 >I can test this one.

What I really want is the correct command line to call it with.  And what 
standard library to use.  Once the script stabilizes, it would be great if 
you could run it on a Mac with as many compilers as you have access to.

 >>    Metrowerks Codewarrior 5.3

Ditto for Codewarrior.  I still have 5.3 loaded, but haven't tried it yet 
because I would rather someone just sent me the command line options so I 
don't have to blunder around for an hour trying to figure them out.

 >I am a CW beta tester, so my installations here (Mac and NT) have already
 >been upgraded to a beta of the next version. I would be happy to test 
with
 >that implementation, if Howard thinks it would be OK. I am not sure MW
 >would
 >like me to reveal details of the beta, but I could perhaps post code 
tweaks
 >that will prevent us from having to revise the library code when the next
 >version of CW is released...
 >
 >>    Borland C++Builder 4
 >>    Borland C++ 5.5
 >>
 >> The second question for each compiler is what standard library to test
 >> with?  For VC++ I am testing both the vendor's library and STLport, 
since
 >> both are widely used with that compiler.  I need advise on the others;
 >> Metrowerks for example supplies an excellent library so I'm not sure if 

 >it
 >> is worth testing  that compiler with STLport.  I'm always confused by
 >> library choices for the GNU compiler in particular.
 >
 >The MW lib is indeed excellent, but many (?) people still use STLport 
with
 >CW in order to reduce platform dependencies. But if you decide to test 
with
 >STLport, there is the question of which version you are testing with. The
 >latest release version lags way behind the latest beta (in that it relies 

 >on
 >the underlying "native" lib implementation for iostream support), but 
some
 >people aren't comfortable using anything marked beta (not me, I'm a
 >bleeding-edge kinda guy). This is just as relevant for other compilers.

Well, let's start with the released compiler and released library.  Once we 
get the script working for that, it is really easy to add variations.

 >GCC 2.95.2 is supported by the lib it was released with (way
 >non-conformant,
 >and buggy in places), and various others. In the SGI family it looks like
 >only the STLport is supporting this particular version of the compiler
 >(SGI's version supports GCC 2.8/egcs 1.1.2 according to docs). The 
release
 >version of the STLport uses gcc's outdated native iostream support, 
meaning
 >for example that there is no <sstream>. The beta version of the STLport
 >(derived from the SGI "experimental" iostreams library) is a full
 >implementation of the library, and supplies a very useful debugging mode
 >which supplies range and iterator validity checking. I know that 
somewhere
 >there exists a GNU effort to build a library based on the SGI library 
with
 >yet another string/iostream (?) implementation, but I've been unable to
 >find
 >it.
 >
 >> Third question for each compiler is how do you tell if a compilation 
has
 >> errors?  For VC++ I am grepping the output for "error" for lack of a
 >better
 >> way.
 >
 >Emacs has a list of regular expressions called
 >compilation-error-regexp-alist, which seems to work pretty reliably and
 >looks like it's already been tuned for lots of compilers. I've appended 
its
 >default definition to this message.

Thanks!  That should be a help.

--Beman