Re: [boost] Re: como toolset failures

From: JOAQUIN LOPEZ MU?Z (joaquin_at_[hidden])
Date: 2005-04-23 15:35:07

----- Mensaje original -----
De: Bronek Kozicki <brok_at_[hidden]>
Fecha: Sábado, Abril 23, 2005 9:50 pm
Asunto: Re: [boost] Re: como toolset failures

> Rene Rivera wrote:
> 
> > Is this specific files?
> > 
> > I ask because there's already a facility in the como-win32 
> toolset for 
> > removing the --a option by specifying that certain files with 
> > <no-warn>file.cpp
> 
> I'd say that this problem seems to cripple most test results. But 
> not 
> all. The flag you mention should be set for all files that 
> directly or 
> indirectly include any of Windows headers. Which I suppose is 
> rather 
> large set of files. Maybe it would be good to temporarily (for one 
> or 
> two days) remove --a globally and then see results; my computer is 
> running tests continously. This would give some idea how many 
> errors 
> might be due to Windows headers included in strict mode. Obviously 
> this 
> will not resolve all problems ;)  as como does not support DLLs, 
> which 
> also means that boost.thread won't work anyway.
> 
> 

Before you do that, let me comment on this: the situation
is probably not as bad as it seems --many libs are actually
completely Windows-unaware and its associated tests fail
only because they use Boost.Test, which internally includes
some Windows headers. These libs are:

algorithm/minmax
algorithm/string
assign
crc
disjoint_sets
format
functional/hash
io
iostreams
lambda
logic (tribool)
math
multi_array
multi_index
numeric/conversion
numeric/interval
pool
property_map
ptr_container
random
range
regex
serialization
tokenizer
tuple
variant

So, if we fix the problem with Boost.Test we'll get a much
higher success rate. In its turn, the problem with Boost.Test
seems to lie in that it includes (directly or indirectly, I don't
know) the file boost/detail/interlocked.hpp, which fails as
shown in http://tinyurl.com/73vvo.

So I'd say fixing boost/detail/interlocked.hpp would drastically
lower the failure count and would give us a much clearer view
of where we really are wrt to Comeau support. Just my 2c.

Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo