[1.36.0] High priority compilers for this release?
Changes I'd like to see include: * Add Microsoft VC++ 9.0. This is now the most current version. * Drop Microsoft VC++ 7.1. Supporting two versions (9.0 and 8.0) is about all we can afford. * Drop the Intel compiler on Windows. Not enough people seem to care about this compiler/platform. Other suggestions? In proposing additions, please remember that each added compiler costs us resources such as developer's time, and that our regression report processing system is easy to overload. Also, we won't accept a new platform unless someone is willing to run *daily* regression tests for it. --Beman
On Thu, Apr 3, 2008 at 3:48 PM, Beman Dawes <bdawes@acm.org> wrote:
Changes I'd like to see include:
* Add Microsoft VC++ 9.0. This is now the most current version. * Drop Microsoft VC++ 7.1. Supporting two versions (9.0 and 8.0) is about all we can afford. * Drop the Intel compiler on Windows. Not enough people seem to care about this compiler/platform.
Other suggestions?
gcc-4.3? -- gpd
Giovanni Piero Deretta wrote:
On Thu, Apr 3, 2008 at 3:48 PM, Beman Dawes <bdawes@acm.org> wrote:
Changes I'd like to see include:
* Add Microsoft VC++ 9.0. This is now the most current version. * Drop Microsoft VC++ 7.1. Supporting two versions (9.0 and 8.0) is about all we can afford. * Drop the Intel compiler on Windows. Not enough people seem to care about this compiler/platform.
Other suggestions?
gcc-4.3?
Yes. Specifically the current release, 4.3.0. In general, we want to always be targeting the current release for a compiler, as of at the start of our release cycle. --Beman
On Apr 3, 2008, at 9:48 AM, Beman Dawes wrote:
Changes I'd like to see include:
* Add Microsoft VC++ 9.0. This is now the most current version. * Drop Microsoft VC++ 7.1. Supporting two versions (9.0 and 8.0) is about all we can afford. * Drop the Intel compiler on Windows. Not enough people seem to care about this compiler/platform.
Other suggestions?
Add GCC 4.3.0. - Doug
Doug Gregor wrote:
On Apr 3, 2008, at 9:48 AM, Beman Dawes wrote:
Changes I'd like to see include:
* Add Microsoft VC++ 9.0. This is now the most current version. * Drop Microsoft VC++ 7.1. Supporting two versions (9.0 and 8.0) is about all we can afford. * Drop the Intel compiler on Windows. Not enough people seem to care about this compiler/platform.
Other suggestions?
Add GCC 4.3.0.
Yes. --Beman
Doug Gregor <dgregor@osl.iu.edu> writes: | On Apr 3, 2008, at 9:48 AM, Beman Dawes wrote:
Changes I'd like to see include:
* Add Microsoft VC++ 9.0. This is now the most current version. * Drop Microsoft VC++ 7.1. Supporting two versions (9.0 and 8.0) is about all we can afford. * Drop the Intel compiler on Windows. Not enough people seem to care about this compiler/platform.
Other suggestions?
| Add GCC 4.3.0. I would really like to see that targeted for 1.35.1. (Unless you really, really speed up releases...) -- Lgb
Lars Gullik "Bjønnes" wrote:
Add GCC 4.3.0.
I would really like to see that targeted for 1.35.1.
(Unless you really, really speed up releases...)
What's the issue with gcc-4.3 and Boost-1.35? I admit I haven't built/tested everything with that compiler, but my experiments so far have found no issues. John.
John Maddock <john <at> johnmaddock.co.uk> writes:
Lars Gullik "Bjønnes" wrote:
Add GCC 4.3.0.
I would really like to see that targeted for 1.35.1.
(Unless you really, really speed up releases...)
What's the issue with gcc-4.3 and Boost-1.35? I admit I haven't built/tested everything with that compiler, but my experiments so far have found no issues.
Theres a few GCC 4.3 tickets open in the tracker, several of which are just about adding missing includes.
On Apr 4, 2008, at 3:52 AM, John Maddock wrote:
Lars Gullik "Bjønnes" wrote:
Add GCC 4.3.0.
I would really like to see that targeted for 1.35.1.
(Unless you really, really speed up releases...)
What's the issue with gcc-4.3 and Boost-1.35? I admit I haven't built/tested everything with that compiler, but my experiments so far have found no issues.
The other issue is that it would be great to test gcc-4.3 in C++0x mode (-std=gnu++0x) as well as C++98 mode. Then we can start taking advantage of some of the 0x features. - Doug
On Fri, 04 Apr 2008 08:52:21 +0100, John Maddock wrote:
Lars Gullik "Bjønnes" wrote:
Add GCC 4.3.0.
I would really like to see that targeted for 1.35.1.
(Unless you really, really speed up releases...)
What's the issue with gcc-4.3 and Boost-1.35? I admit I haven't built/tested everything with that compiler, but my experiments so far have found no issues.
most issues are related to gcc's strict implementation of the c++ standard ... see http://tim.klingt.org/git?p=boost.git;a=summary for my private git tree, which contains the gcc-4.3 fixes for the parts of boost, that i need in my application ... best, tim -- tim@klingt.org http://tim.klingt.org art is short - life is long Jack Kerouac
Beman Dawes <bdawes <at> acm.org> writes:
Changes I'd like to see include:
* Drop the Intel compiler on Windows. Not enough people seem to care about this compiler/platform.
Whaa?? I would suggest that ICL 10.1 should be supported. It is probably the most conformant (and the best optimizing) compiler out there. Irritatingly, 10.0 had introduced many regressions over 9.1, but with 10.1 things appear to be back on track. Mind you, to get the best optimizations, some esoteric flags have to be used; also, by default the optimizer is set to favour speed at the cost of floating point accuracy. I have played around a bit with optimization settings, and can post the options I use to build boost components (since bjam does not include aggressive optimization settings), if someone would find it useful. Anyhow, fwitw, I strongly favour keeping ICL support - even if it is not used much owing to not being free, it would function an examplar to other vendors. Amit
Amit wrote:
Beman Dawes <bdawes <at> acm.org> writes:
Changes I'd like to see include:
* Drop the Intel compiler on Windows. Not enough people seem to care about this compiler/platform.
Whaa?? I would suggest that ICL 10.1 should be supported. It is probably the most conformant (and the best optimizing) compiler out there. Irritatingly, 10.0 had introduced many regressions over 9.1, but with 10.1 things appear to be back on track.
Mind you, to get the best optimizations, some esoteric flags have to be used; also, by default the optimizer is set to favour speed at the cost of floating point accuracy. I have played around a bit with optimization settings, and can post the options I use to build boost components (since bjam does not include aggressive optimization settings), if someone would find it useful.
Anyhow, fwitw, I strongly favour keeping ICL support - even if it is not used much owing to not being free, it would function an examplar to other vendors.
I'm inclined to agree to that: Intel have been extremely responsive in the past in responding to compiler issues relating to Boost, and given the level of conformance offered by this compiler, does it really soak up that much time to officially support it? Incidently, it's good to have at least one EDG based front end in our official support list, even if it does emulate the MSVC bugs ;-) John.
John Maddock wrote:
Amit wrote:
Beman Dawes <bdawes <at> acm.org> writes:
Changes I'd like to see include:
* Drop the Intel compiler on Windows. Not enough people seem to care about this compiler/platform. Whaa?? I would suggest that ICL 10.1 should be supported. It is probably the most conformant (and the best optimizing) compiler out there. Irritatingly, 10.0 had introduced many regressions over 9.1, but with 10.1 things appear to be back on track.
Mind you, to get the best optimizations, some esoteric flags have to be used; also, by default the optimizer is set to favour speed at the cost of floating point accuracy. I have played around a bit with optimization settings, and can post the options I use to build boost components (since bjam does not include aggressive optimization settings), if someone would find it useful.
Anyhow, fwitw, I strongly favour keeping ICL support - even if it is not used much owing to not being free, it would function an examplar to other vendors.
I'm inclined to agree to that: Intel have been extremely responsive in the past in responding to compiler issues relating to Boost, and given the level of conformance offered by this compiler, does it really soak up that much time to officially support it? Incidently, it's good to have at least one EDG based front end in our official support list, even if it does emulate the MSVC bugs ;-)
Would you like to volunteer for testing and followup:-? --Beman
Beman Dawes wrote:
I'm inclined to agree to that: Intel have been extremely responsive in the past in responding to compiler issues relating to Boost, and given the level of conformance offered by this compiler, does it really soak up that much time to officially support it? Incidently, it's good to have at least one EDG based front end in our official support list, even if it does emulate the MSVC bugs ;-)
Would you like to volunteer for testing and followup:-?
OK I walked into that I guess ! :-) Yes OK, forward all Intel-Win32 issues to me and I'll try and look into them. What I can't easily do is run the full regression tests on my laptop :-( John.
Amit wrote:
Beman Dawes <bdawes <at> acm.org> writes:
Changes I'd like to see include:
* Drop the Intel compiler on Windows. Not enough people seem to care about this compiler/platform.
Whaa?? I would suggest that ICL 10.1 should be supported. It is probably the most conformant (and the best optimizing) compiler out there. Irritatingly, 10.0 had introduced many regressions over 9.1, but with 10.1 things appear to be back on track.
Mind you, to get the best optimizations, some esoteric flags have to be used; also, by default the optimizer is set to favour speed at the cost of floating point accuracy. I have played around a bit with optimization settings, and can post the options I use to build boost components (since bjam does not include aggressive optimization settings), if someone would find it useful.
Anyhow, fwitw, I strongly favour keeping ICL support - even if it is not used much owing to not being free, it would function an examplar to other vendors.
We would need a volunteer or volunteers to (1) do the testing, and (2) work with Intel and Boost developers to ensure that bugs get fixed. Sean Huang has been testing the trunk, and I've been testing the release branch. I really want to turn the release branch testing over to someone else, and find someone else to pester Intel and/or Boost developers when things break. So we basically need an Intel/Windows volunteer. --Beman
Beman Dawes <bdawes <at> acm.org> writes:
We would need a volunteer or volunteers to (1) do the testing, and (2) work with Intel and Boost developers to ensure that bugs get fixed.
Sean Huang has been testing the trunk, and I've been testing the release branch. I really want to turn the release branch testing over to someone else, and find someone else to pester Intel and/or Boost developers when things break.
So we basically need an Intel/Windows volunteer.
I can't really volunteer for nightly testing as I only have access to the compiler at my employer's workplace. But can volunteer to investigate specific issues, get clarifications from Intel etc. Is there not a third way though: platforms lacking active volunteers need not be constantly supported, but when a new release is imminent, casual volunteers (like myself) be roped in to test the release to iron out any minor issues, or if there are major problems, to at least figure out a subset of boost that would work on these platforms? Best, Amit
Beman Dawes wrote:
Changes I'd like to see include:
* Drop Microsoft VC++ 7.1. Supporting two versions (9.0 and 8.0) is about all we can afford.
I'd like to kindly ask to continue supporting VC 7.1 at least for a release or two. This compiler is still rather popular and is quite capable to compile modern C++.
On Thu, Apr 3, 2008 at 11:57 AM, Andrey Semashev <andysem@mail.ru> wrote:
Beman Dawes wrote:
Changes I'd like to see include:
* Drop Microsoft VC++ 7.1. Supporting two versions (9.0 and 8.0) is about all we can afford.
I'd like to kindly ask to continue supporting VC 7.1 at least for a release or two. This compiler is still rather popular and is quite capable to compile modern C++.
I'll second that request. We are still using 7.1 and 8.0 here, with no plans (yet) to move to 9.0 this year. --Michael Fawcett
On Thu, Apr 3, 2008 at 12:57 PM, Andrey Semashev <andysem@mail.ru> wrote:
Beman Dawes wrote:
Changes I'd like to see include:
* Drop Microsoft VC++ 7.1. Supporting two versions (9.0 and 8.0) is about all we can afford.
I'd like to kindly ask to continue supporting VC 7.1 at least for a release or two. This compiler is still rather popular and is quite capable to compile modern C++.
Me too. There isn't even much difference from MSVC 7.1 and the new 9.0. Most people don't find compelling to upgrade just to get NRVO basically. Thanks, -- Felipe Magno de Almeida
On Thu, Apr 3, 2008 at 3:42 PM, Felipe Magno de Almeida <felipe.m.almeida@gmail.com> wrote:
On Thu, Apr 3, 2008 at 12:57 PM, Andrey Semashev <andysem@mail.ru> wrote:
Beman Dawes wrote:
Changes I'd like to see include:
* Drop Microsoft VC++ 7.1. Supporting two versions (9.0 and 8.0) is about all we can afford.
I'd like to kindly ask to continue supporting VC 7.1 at least for a release or two. This compiler is still rather popular and is quite capable to compile modern C++.
Me too. There isn't even much difference from MSVC 7.1 and the new 9.0. Most people don't find compelling to upgrade just to get NRVO basically.
Sorry to reply to myself, but I only second this request *if* there's a regular regression tester to this platform. If there's enough testing, I don't see why we should drop support for it. Regards, -- Felipe Magno de Almeida
Felipe Magno de Almeida wrote:
On Thu, Apr 3, 2008 at 3:42 PM, Felipe Magno de Almeida <felipe.m.almeida@gmail.com> wrote:
On Thu, Apr 3, 2008 at 12:57 PM, Andrey Semashev <andysem@mail.ru> wrote:
Beman Dawes wrote:
Changes I'd like to see include:
* Drop Microsoft VC++ 7.1. Supporting two versions (9.0 and 8.0) is about all we can afford.
I'd like to kindly ask to continue supporting VC 7.1 at least for a release or two. This compiler is still rather popular and is quite capable to compile modern C++.
Me too. There isn't even much difference from MSVC 7.1 and the new 9.0. Most people don't find compelling to upgrade just to get NRVO basically.
Sorry to reply to myself, but I only second this request *if* there's a regular regression tester to this platform. If there's enough testing, I don't see why we should drop support for it.
Testing is the issue. We need reliable *nightly* testing on both trunk and release to seriously target a compiler, and we just haven't been getting that for 7.1. Rene and others did a lot of work during the last release cycle to make testing more reliable and easier to run. So if someone wants to contribute to Boost, running regression tests is easier than ever. --Beman
On Thu, Apr 3, 2008 at 5:03 PM, Beman Dawes <bdawes@acm.org> wrote:
[snip]
Testing is the issue. We need reliable *nightly* testing on both trunk and release to seriously target a compiler, and we just haven't been getting that for 7.1.
Rene and others did a lot of work during the last release cycle to make testing more reliable and easier to run. So if someone wants to contribute to Boost, running regression tests is easier than ever.
I have resources to test one platform. Though I would like to see 7.1 as being a supported platform, I can't say it is worthwhile for me to test it (we are porting everything to 9.0). But would gladly contribute with testing MSVC 9.0 on x64. As long as parallel builds work reliably. I can offer some hours per day of a core 2 quad 2.4GHz with 8GB RAM on vista x64.
--Beman
Thanks Beman, -- Felipe Magno de Almeida
Andrey Semashev wrote:
Beman Dawes wrote:
Changes I'd like to see include:
* Drop Microsoft VC++ 7.1. Supporting two versions (9.0 and 8.0) is about all we can afford.
I'd like to kindly ask to continue supporting VC 7.1 at least for a release or two. This compiler is still rather popular and is quite capable to compile modern C++.
I would also like to see continued support for VC++ 7.1 since that is the compiler that I use. I'm willing to do testing on this platform (if the computer I have available for testing can do them quickly enough). I looked at the directions for running tests: http://www.boost.org/development/running_regression_tests.html Is there anything else I need to do (e.g. registering my runner ID) before I run the tests? Thanks, David
David Walthall wrote:
I looked at the directions for running tests: http://www.boost.org/development/running_regression_tests.html Is there anything else I need to do (e.g. registering my runner ID) before I run the tests?
No, there's no registering. About the only suggestion I have is to recommend you set up a user-config.jam. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org (msn) - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail
Beman Dawes <bdawes <at> acm.org> writes:
Changes I'd like to see include:
* Add Microsoft VC++ 9.0. This is now the most current version. * Drop Microsoft VC++ 7.1. Supporting two versions (9.0 and 8.0) is about all we can afford. * Drop the Intel compiler on Windows. Not enough people seem to care about this compiler/platform.
Other suggestions?
In proposing additions, please remember that each added compiler costs us resources such as developer's time, and that our regression report processing system is easy to overload. Also, we won't accept a new platform unless someone is willing to run *daily* regression tests for it.
I'd like to bring the following idea for discussion: Besides mainstream platforms, additional, more exotic platforms can be provisionally included into the supported set *provided that* they are associated to a volunteer *platform champion*. A platform champion will * Make sure there's a daily regression test for the platform (either run by her or some other party). * Continuously scans the platform-specific regressions and trac tickets in every Boost library, studies them and proposes tried patches. For a reasonably conformant compiler, this is actually not as hard to do as it might sound, as many fixes (in my experience) are very local in nature and can be fixed without having any deep knowledge of the code being fixed. I've done my share of fixing for MSVC 6.0 and can attest this. The point is that in fixing platform-specific glitches it is way more valuable to have someone with knowledge of and access to the platform than someone with knowledge of the lib itself. * Is available for answering question on the platform and try tests and stuff on demand. If the champion resigns or is not able to keep a high quality level on the platform, the platform is dropped. Does this make sense? Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
From: Joaquin M Lopez Munoz
Beman Dawes <bdawes <at> acm.org> writes:
In proposing additions, please remember that each added compiler costs us resources such as developer's time, and that our regression report processing system is easy to overload. Also, we won't accept a new platform unless someone is willing to run *daily* regression tests for it.
I'd like to bring the following idea for discussion: Besides mainstream platforms, additional, more exotic platforms can be provisionally included into the supported set *provided that* they are associated to a volunteer *platform champion*. A platform champion will [snip - "ensure the platform works"]
If the champion resigns or is not able to keep a high quality level on the platform, the platform is dropped.
Does this make sense?
It sounds like an absolutely /excellent/ plan to me. Apart from anything else, it formalizes what somebody needs to do in order to get their favourite platform supported. -- Martin Bonner Senior Software Engineer/Team Leader PI SHURLOK LTD Telephone: +44 1223 441434 / 203894 (direct) Fax: +44 1223 203999 Email: martin.bonner@pi-shurlok.com www.pi-shurlok.com disclaimer
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Joaquin M Lopez Munoz Sent: Thursday, April 03, 2008 12:42 PM To: boost@lists.boost.org Subject: Re: [boost] [1.36.0] High priority compilers for this release?
<CLIP>
I'd like to bring the following idea for discussion: Besides mainstream platforms, additional, more exotic platforms can be provisionally included into the supported set *provided that* they are associated to a volunteer *platform champion*. A platform champion will
* Make sure there's a daily regression test for the platform (either run by her or some other party). * Continuously scans the platform-specific regressions and trac tickets in every Boost library, studies them and proposes tried patches. For a reasonably conformant compiler, this is actually not as hard to do as it might sound, as many fixes (in my experience) are very local in nature and can be fixed without having any deep knowledge of the code being fixed. I've done my share of fixing for MSVC 6.0 and can attest this. The point is that in fixing platform-specific glitches it is way more valuable to have someone with knowledge of and access to the platform than someone with knowledge of the lib itself. * Is available for answering question on the platform and try tests and stuff on demand.
If the champion resigns or is not able to keep a high quality level on the platform, the platform is dropped.
Does this make sense?
Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
Even for the mainstream there are a huge number of combinations of supporting tools/libraries (e.g. MPI, python, etc) and compilers (e.g. gcc, msvc, etc). Each of these has some number of release versions, each could have different build options (e.g. debug vs optimized or shared vs static vs both), as well as boost itself which has quite a few of its own build options. This is, of course, way too much to test exhaustively but the set of configurations that are actually used is probably still huge. To make a dent in that kind of test set an enormous amount of computation is needed. An approach that looks interesting is seti@home. The basic idea is to set up a BOINC project for boost build testing and distribute the test load across anybody who wants to contribute cycles. The "dataset" that is being processed could consist of the entire toolchain (gcc + libs + boost + etc) for the open source pieces. The project should probably maintain an entire internal toolchain so that is doesn't rely on much more than the kernel version and network access from a client system. Commercial compilers and such couldn't be downloaded so there would need to be a project configuration mechanism to allow a particular user to say whether he has any of those compilers installed and their version. The project could for instance cache builds of supporting items (e.g. gcc) so that it wouldn't have to rebuild them for each test. All of the test results would be reported back to the boost site and aggregated into a master test results matrix. All of this could be done either nightly or continuously. The nice thing about this is that a given user doesn't need to understand the build process in order to contribute resources to it. This low entry barrier would allow participation by users who would otherwise balk at the amount of commitment needed. Having said all of this, I have never looked into actually setting up a BOINC project. Does anybody have insight into whether this is a sane thing to try? If it would work then prototyping this would make a nice GSOC project. --glenn
Loïc Joly wrote:
Beman Dawes a écrit :
Changes I'd like to see include:
* Add Microsoft VC++ 9.0. This is now the most current version.
I think adding a version of VC++9.0 with microsoft optional TR1 implementation would also be quite interresting.
Yes, and at least one of our 9.0 testers has it installed. But I'm uncertain if we need to do anything specific about it, particularly as the TR1 pack is still in beta IIRC. --Beman
Beman Dawes <bdawes <at> acm.org> writes:
I think adding a version of VC++9.0 with microsoft optional TR1 implementation would also be quite interresting.
Yes, and at least one of our 9.0 testers has it installed. But I'm uncertain if we need to do anything specific about it, particularly as the TR1 pack is still in beta IIRC.
I've been running the tests with the TR1 pack installed. The Boost.TR1 config has already been updated to use the MS TR1 is present, so i dont think theres anything else to do? I'm told that TR1 support is going to be included in VC9 SP1. It sounds like thats going to show up in the not too distant future, but i dont know it will be before the Boost 1.36 release.
Beman Dawes <bdawes <at> acm.org> writes:
Yes, and at least one of our 9.0 testers has it installed. But I'm uncertain if we need to do anything specific about it, particularly as the TR1 pack is still in beta IIRC.
f.y.i, Microsoft have just release the final version of the TR1 pack: http://blogs.msdn.com/vcblog/archive/2008/04/07/visual-c-2008-feature-pack-r... I'll install this later and run the regression tests with it. Thanks, Richard Webb
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Richard Webb Sent: 07 April 2008 14:26 To: boost@lists.boost.org Subject: Re: [boost] [1.36.0] High priority compilers for this release?
f.y.i, Microsoft have just release the final version of the TR1 pack: http://blogs.msdn.com/vcblog/archive/2008/04/07/visual-c-2008-f eature-pack-released.aspx
I'll install this later and run the regression tests with it.
Please report your experience here - I am sure lots of people will be thinking about this and wondering what to do. Paul --- Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB +44 1539561830 & SMS, Mobile +44 7714 330204 & SMS pbristow@hetp.u-net.com
Paul A Bristow <pbristow <at> hetp.u-net.com> writes:
Please report your experience here - I am sure lots of people will be thinking
about this and wondering what
to do.
The test results are now up @ http://beta.boost.org/development/tests/trunk/developer/summary.html under the RW_WinXP_VC runner. It looks like the jrp tests have the TR1 pack installed as well.
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Loïc Joly Sent: 03 April 2008 20:19 To: boost@lists.boost.org Subject: Re: [boost] [1.36.0] High priority compilers for this release?
Beman Dawes a écrit :
Changes I'd like to see include:
* Add Microsoft VC++ 9.0. This is now the most current version.
I think adding a version of VC++9.0 with microsoft optional TR1 implementation would also be quite interresting. -- Loïc Joly
I second this - many people will want to know if the MS TR1 and Boost TR1 play together nicely: if they squabble, it will cause trouble deep in the engine room and bring the hapless users to a grinding halt. Paul --- Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB +44 1539561830 & SMS, Mobile +44 7714 330204 & SMS pbristow@hetp.u-net.com
Beman Dawes wrote:
* Add Microsoft VC++ 9.0. This is now the most current version. * Drop Microsoft VC++ 7.1. Supporting two versions (9.0 and 8.0) is about all we can afford. * Drop the Intel compiler on Windows. Not enough people seem to care about this compiler/platform.
Has anybody asked microsoft or intel if they can supply and maintain a testing machine? Best Regards, Johan -- View this message in context: http://www.nabble.com/-1.36.0--High-priority-compilers-for-this-release--tp1... Sent from the Boost - Dev mailing list archive at Nabble.com.
participants (20)
-
Amit -
Andrey Semashev -
Beman Dawes -
David Walthall -
Doug Gregor -
Douglas Gregor -
Felipe Magno de Almeida -
Giovanni Piero Deretta -
Joaquin M Lopez Munoz -
Johan Torp -
John Maddock -
larsbj＠gullik.net -
Loïc Joly -
Martin Bonner -
Michael Fawcett -
Paul A Bristow -
Rene Rivera -
Richard Webb -
Schrader, Glenn -
Tim Blechmann