[1.34.0] Required platforms
Hi, Here is the final list of required platforms I could come up with given our current testing resources. borland-5_8_2 cw-9.4 vc-6_5 vc-6_5-stlport vc-7_0 vc-7_1-stlport msvc-7.1 msvc-8.0 mingw-3_4_2 mingw-3_4_5 gcc-3.3.6 gcc-3.4.4 gcc-3.2.3_linux gcc-3.3.6_linux gcc-3.4.5_linux gcc-3.4.5_linux gcc-4.0.3_linux gcc-4.1.0_linux gcc-3.4.5_linux_x86_64 gcc-4.1.0_linux_x86_64 gcc-3_4_4_tru64 gcc-4_0_3_tru64 gcc-3.4.3_sunos darwin-4.0.1 qcc-3.3.5_cpp qcc-3.3.5_gpp intel-win-9.1 intel-linux-9.0 hp_cxx-71_006_tru64 sun-5.8 Please tell me if you think there are serious omissions or something should not be on the list. Please note that a library maintainer may always decide to mark the more esoteric platforms (for any suitable definition for 'more esoteric') as expected failures. As John had mentioned earlier the toolset names have changed so you might have to fix up old expected failures. Thanks for your help Thomas Release Manager -- Thomas Witt witt@acm.org
Thomas Witt wrote:
As John had mentioned earlier the toolset names have changed so you might have to fix up old expected failures.
Ok, I'm going to officially whine about this -- every single build I have to spend time fixing expected failures just because the toolset is renamed. When toolset names change it needs to be the responsibility of the name changer to update the expected failures... Jeff
Jeff Garland wrote:
Thomas Witt wrote:
As John had mentioned earlier the toolset names have changed so you might have to fix up old expected failures.
Ok, I'm going to officially whine about this -- every single build I have to spend time fixing expected failures just because the toolset is renamed. When toolset names change it needs to be the responsibility of the name changer to update the expected failures...
We all got forced to change the names by switching to v2. Regards, m Send instant messages to your online friends http://au.messenger.yahoo.com
Jeff Garland wrote:
Thomas Witt wrote:
As John had mentioned earlier the toolset names have changed so you might have to fix up old expected failures.
Ok, I'm going to officially whine about this -- every single build I have to spend time fixing expected failures just because the toolset is renamed. When toolset names change it needs to be the responsibility of the name changer to update the expected failures...
Hi guys, should I assume previous CodeWarrior version are definitely not supported? If so, we could simplify a lot the code for BOOST_WORKAROUND. --Gennaro.
On Fri, 02 Jun 2006 16:52:41 -0700, Jeff Garland <jeff@crystalclearsoftware.com> wrote:
Thomas Witt wrote:
As John had mentioned earlier the toolset names have changed so you might have to fix up old expected failures.
Ok, I'm going to officially whine about this -- every single build I have to spend time fixing expected failures just because the toolset is renamed. When toolset names change it needs to be the responsibility of the name changer to update the expected failures...
Hi guys, should I assume that previous CodeWarrior versions are definitely unsupported? If so, we could simplify a lot the code for BOOST_WORKAROUND. --Gennaro. -- Genny.
Gennaro Prota wrote:
On Fri, 02 Jun 2006 16:52:41 -0700, Jeff Garland <jeff@crystalclearsoftware.com> wrote:
Thomas Witt wrote:
As John had mentioned earlier the toolset names have changed so you might have to fix up old expected failures. Ok, I'm going to officially whine about this -- every single build I have to spend time fixing expected failures just because the toolset is renamed. When toolset names change it needs to be the responsibility of the name changer to update the expected failures...
Hi guys,
should I assume that previous CodeWarrior versions are definitely unsupported? If so, we could simplify a lot the code for BOOST_WORKAROUND.
This is up to the individual library author. Personally I think throwing out support just for the sake of getting rid of BOOST_WORKAROUND is a bad idea. The story is different if you have to make changes to the code anyway. That being said the RC_1_34_0 branch is definitely closed for changes like this. Thomas -- Thomas Witt witt@acm.org
On Mon, 05 Jun 2006 09:24:58 -0700, Thomas Witt <witt@acm.org> wrote:
Gennaro Prota wrote:
[...]
Hi guys,
should I assume that previous CodeWarrior versions are definitely unsupported? If so, we could simplify a lot the code for BOOST_WORKAROUND.
This is up to the individual library author. Personally I think throwing out support just for the sake of getting rid of BOOST_WORKAROUND is a bad idea. The story is different if you have to make changes to the code anyway.
That being said the RC_1_34_0 branch is definitely closed for changes like this.
There was a misunderstanding :) I didn't mean to eliminate usages of BOOST_WORKAROUND. Just to simplify *its* implementation (see workaround.hpp). --Gennaro.
Gennaro, Gennaro Prota wrote:
On Mon, 05 Jun 2006 09:24:58 -0700, Thomas Witt <witt@acm.org> wrote:
There was a misunderstanding :) I didn't mean to eliminate usages of BOOST_WORKAROUND. Just to simplify *its* implementation (see workaround.hpp).
In my opinion we should be *very* conservative when removing compiler support from core infrastructure. If you do this you basically make a decision for other developers. Or to phrase it less friendly you are cutting them off from any sensible way to support that platform going forward. Thomas -- Thomas Witt witt@acm.org
----- Original Message ----- From: "Thomas Witt" <witt@acm.org>
Please tell me if you think there are serious omissions or something should not be on the list. Please note that a library maintainer may always decide to mark the more esoteric platforms (for any suitable definition for 'more esoteric') as expected failures.
It would be nice to officially support 64-bit windows (msvc-8.0_x86_64 and intel-win-9.1_x86_64?). Sean
----- Original Message ----- From: "Thomas Witt" <witt@acm.org>
Please tell me if you think there are serious omissions or something should not be on the list. Please note that a library maintainer may always decide to mark the more esoteric platforms (for any suitable definition for 'more esoteric') as expected failures.
It would be very nice to officially support 64-bit windows (msvc-8.0_x86_64 and intel-win-9.1_x86_64?). Sean
Sean Huang wrote:
----- Original Message ----- From: "Thomas Witt" <witt@acm.org>
Please tell me if you think there are serious omissions or something should not be on the list. Please note that a library maintainer may always decide to mark the more esoteric platforms (for any suitable definition for 'more esoteric') as expected failures.
It would be very nice to officially support 64-bit windows (msvc-8.0_x86_64 and intel-win-9.1_x86_64?).
If you want to see these platforms supported then please consider contributing a test system. We don't support platforms unless someone runs the regressions. AFAICS we don't have anyone running regressions on these. Jeff
Jeff Garland wrote:
If you want to see these platforms supported then please consider contributing a test system.
Out of curiousity (don't have 64-bit Windows), how exactly does this work? Could I, in theory, have a largely idle computer at my home running regression tests? Sebastian Redl
Sebastian Redl wrote:
Jeff Garland wrote:
If you want to see these platforms supported then please consider contributing a test system.
Out of curiousity (don't have 64-bit Windows), how exactly does this work? Could I, in theory, have a largely idle computer at my home running regression tests?
Yep. There's some test tools to download and setup. If you are interested you can subscribe and discuss the details on the boost-testing list. Jeff
----- Original Message ----- From: "Jeff Garland" <jeff@crystalclearsoftware.com>
It would be very nice to officially support 64-bit windows (msvc-8.0_x86_64 and intel-win-9.1_x86_64?).
If you want to see these platforms supported then please consider contributing a test system. We don't support platforms unless someone runs the regressions. AFAICS we don't have anyone running regressions on these.
Absolutely, I'll see what I can get. Sean
Gennadiy Rozental wrote:
"Thomas Witt" <witt@acm.org> wrote in message news:4480CBDF.3080105@acm.org...
Hi,
Here is the final list of required platforms I could come up with given our current testing resources.
[...]
sun-5.8
Does Boost.Test works for this platform?
I think it does but I should be able to confirm this in the next couple of days as my Solaris 10 / sun-5.8 box is almost back up and running again. Regards, Timo
Thomas, Is it too late to add msvc-8.0_64 (native 64 bit compiler), msvc-8.0_x86_64 (cross-compiler), and intel-win-9.1_x86_64 (intel 9.1 cross-compiler) to the required platforms now we have the tests running daily? Thanks, Sean ----- Original Message ----- From: "Thomas Witt" <witt@acm.org> To: <boost@lists.boost.org>; <boost-testing@lists.boost.org> Sent: Friday, June 02, 2006 7:38 PM Subject: [boost] [1.34.0] Required platforms
Please tell me if you think there are serious omissions or something should not be on the list. Please note that a library maintainer may always decide to mark the more esoteric platforms (for any suitable definition for 'more esoteric') as expected failures.
As John had mentioned earlier the toolset names have changed so you might have to fix up old expected failures.
Thanks for your help
Thomas
participants (8)
-
Gennadiy Rozental -
Gennaro Prota -
Jeff Garland -
Martin Wille -
Sean Huang -
Sebastian Redl -
Thomas Witt -
Timo Geusch