Re: [Boost-build] v2 Python toolset doesn't faithfully reproduce v1

From: David Abrahams (dave_at_[hidden])
Date: 2006-09-12 20:49:32

David Abrahams <dave_at_[hidden]> writes:

> Vladimir Prus <ghost_at_[hidden]> writes:
>
>> On Tuesday 22 August 2006 15:21, you wrote:
>>> Vladimir Prus <ghost_at_[hidden]> writes:
>>> > On Thursday 13 July 2006 02:44, David Abrahams wrote:
>>> >> I also note this:
>>> >>
>>> >>     # NOTES:
>>> >>     # - V1 had logic to force intel to use gcc's runtime.
>>> >>     #   Note sure why that was needed, with icc 8.0 extensions
>>> >>     #   built with intel are loaded by python without problems.
>>> >>
>>> >> Has the version of Python also been built with Intel?  If so you won't
>>> >> see any problems, as the following v1 comment indicates:
>>> >>
>>> >>   # Normally on Linux, Python is built with GCC.  A "poor QOI choice"
>>> >>   # in the implementation of the intel tools prevents the use of
>>> >>   # intel-linked shared libs by a GCC-built executable unless they
>>> >>   # have been told to use the GCC runtime.  This rule adds the
>>> >>   # requisite flags to the compile and link lines.
>>> >
>>> > Sorry for continuing being dense, but I can't find any outstanding
>>> > failures in Python tests on intel-9.0 (Martin Wille V2). So:
>>> >
>>> >   - is this problem fixed in 9.0
>>>
>>> I don't know.
>>>
>>> >   - is there any test that would have caught this problem and that I can
>>> > run with intel 8.0 to check?
>>>
>>> I don't know.
>>>
>>> It may be (in fact it's likely) that Intel and GCC once had slight ABI
>>> differences but have since converged.
>>
>> So, do you think it would be wise not to spend time on addressing a problem 
>> that does not show up in regression tests, and for which it's not know how to 
>> make Boost.Python fail?
>
> yes.

Now that I look at explicit-failures-markup.xml, I'm reconsidering.

Aleksey checked in an "expected failure" mark for each and every test
with intel-7.1-linux and intel-8.0-linux.  The note says:

                The library is <a
                href="http://article.gmane.org/gmane.comp.lib.boost.devel/110420">known
                to work</a> in this configuration. The failures are
                due to configuration issues of the particular testing
                environment these tests have been run in. The
                regression runners and library developers are aware of
                the problem and plan to fix it for the next release.

I don't know which developers Aleksey meant when he said they are
"aware of the problem and plan to fix it for the next release," but I
think we need to determine what those failures were and what the
planned fixes were to be, and almost certainly we need to get this
markup out of the XML file, because it's just masking problems.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com