Re: [boost] Boost 1.45 compile error
(bringing in boost dev...) This sounds bad. Can anybody confirm? -- Eric Niebler BoostPro Computing http://www.boostpro.com On 11/19/2010 4:35 PM, gast128 wrote:
Hello all,
just tried out Boost 1.45 on VStudio 2003 but I got a compile error by only including type_traits:
#include <boost/type_traits.hpp>
int main() { return 0; }
C:\Work Sdk\boost_1_45_0\boost\typeof\msvc\typeof_impl.hpp(160) : error C2027: use of undefined type '<Unknown>' C:\Work Sdk\boost_1_45_0\boost\typeof\msvc\typeof_impl.hpp(143) : see declaration of '<Unknown>' C:\Work Sdk\boost_1_45_0\boost\typeof\msvc\typeof_impl.hpp(160) : see reference to class template instantiation '<Unknown>' being compiled C:\Work Sdk\boost_1_45_0\boost\type_traits\common_type.hpp(121) : see reference to class template instantiation '<Unknown>' being compiled C:\Work Sdk\boost_1_45_0\boost\type_traits\common_type.hpp(123) : see reference to class template instantiation 'boost::type_traits_detail::common_type_2<T,U>' being compiled C:\Work Sdk\boost_1_45_0\boost\typeof\msvc\typeof_impl.hpp(160) : error C2146: syntax error : missing ';' before identifier 'wrapped_type' C:\Work Sdk\boost_1_45_0\boost\typeof\msvc\typeof_impl.hpp(160) : error C2501: '<Unknown>' : missing storage-class or type specifiers C:\Work Sdk\boost_1_45_0\boost\typeof\msvc\typeof_impl.hpp(161) : error C2653: 'wrapped_type' : is not a class or namespace name
afaik it seems located on 121 in 'boost/type_traits/coomon_type.hpp'
Anyone can help?
On 11/19/2010 9:14 PM, Eric Niebler wrote:
(bringing in boost dev...)
This sounds bad. Can anybody confirm?
The tests already confirm it <http://tinyurl.com/24lpbq4>. -- -- 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
On 11/19/2010 10:29 PM, Rene Rivera wrote:
On 11/19/2010 9:14 PM, Eric Niebler wrote:
(bringing in boost dev...)
This sounds bad. Can anybody confirm?
The tests already confirm it <http://tinyurl.com/24lpbq4>.
Crap. Might I suggest we pull the release and reissue as a point release after this is fixed? Adding back the missing context:
just tried out Boost 1.45 on VStudio 2003 but I got a compile error by only including type_traits:
#include <boost/type_traits.hpp>
int main() { return 0; }
-- Eric Niebler BoostPro Computing http://www.boostpro.com
This sounds bad. Can anybody confirm?
The tests already confirm it <http://tinyurl.com/24lpbq4>.
Crap. Might I suggest we pull the release and reissue as a point release after this is fixed?
Adding back the missing context:
Is this type_traits specific, or should boost.typeof work on that platform... I'm sure it used to? BTW there are a *lot* of failures with VC7.1 relating to this. John.
On 11/20/2010 7:25 AM, John Maddock wrote:
This sounds bad. Can anybody confirm?
The tests already confirm it <http://tinyurl.com/24lpbq4>.
Crap. Might I suggest we pull the release and reissue as a point release after this is fixed?
Adding back the missing context:
Is this type_traits specific, or should boost.typeof work on that platform... I'm sure it used to?
I don't know. Is common_type the only trait to use boost.typeof? If so, can we just comment out the #include of common_type.hpp in type_traits.hpp as a stop-gap?
BTW there are a *lot* of failures with VC7.1 relating to this.
By "this" do you mean the type_traits error or the boost.typeof failure? -- Eric Niebler BoostPro Computing http://www.boostpro.com
Message du 20/11/10 14:52 De : "Eric Niebler" A : boost@lists.boost.org Copie à : Objet : Re: [boost] Boost 1.45 compile error
On 11/20/2010 7:25 AM, John Maddock wrote:
This sounds bad. Can anybody confirm?
The tests already confirm it .
Crap. Might I suggest we pull the release and reissue as a point release after this is fixed?
Adding back the missing context:
Is this type_traits specific, or should boost.typeof work on that platform... I'm sure it used to?
I don't know. Is common_type the only trait to use boost.typeof? If so, can we just comment out the #include of common_type.hpp in type_traits.hpp as a stop-gap?
BTW there are a *lot* of failures with VC7.1 relating to this.
Most of the failures if not all are due to the includion of common_type.hpp.
By "this" do you mean the type_traits error or the boost.typeof failure?
As Boost.Typeof is Ok with this compiler we can not say yet that the problem is with Boost.Typeof. Surprisingly the same compiler in trunk works "daw-msvc71 rev 66640 Fri, 19 02:00:37 +0000i msvc- 7.1" daw-msvc71 rev 66641 Fri, 19 Nov 2010 09:00:32 +0000i fails on release.
From my part we can comment the #inlcude for common_type from the type_traits.hpp file. Applications that want to use common_type can include for the moment.
Best, Vicente
2010/11/20 Vicente BOTET <vicente.botet@wanadoo.fr>
Message du 20/11/10 14:52 De : "Eric Niebler" A : boost@lists.boost.org Copie à : Objet : Re: [boost] Boost 1.45 compile error
On 11/20/2010 7:25 AM, John Maddock wrote:
This sounds bad. Can anybody confirm?
The tests already confirm it .
Crap. Might I suggest we pull the release and reissue as a point release after this is fixed?
Adding back the missing context:
Is this type_traits specific, or should boost.typeof work on that platform... I'm sure it used to?
I don't know. Is common_type the only trait to use boost.typeof? If so, can we just comment out the #include of common_type.hpp in type_traits.hpp as a stop-gap?
BTW there are a *lot* of failures with VC7.1 relating to this.
Most of the failures if not all are due to the includion of common_type.hpp.
By "this" do you mean the type_traits error or the boost.typeof failure?
As Boost.Typeof is Ok with this compiler we can not say yet that the problem is with Boost.Typeof. Surprisingly the same compiler in trunk works "daw-msvc71 rev 66640 Fri, 19 02:00:37 +0000i msvc- 7.1"
daw-msvc71 rev 66641 Fri, 19 Nov 2010 09:00:32 +0000i fails on release.
From my part we can comment the #inlcude for common_type from the type_traits.hpp file. Applications that want to use common_type can include for the moment.
I will install Visual Studio 2003 ASAP and try to see if there is something obviously wrong with boost.typeof for this compiler. Regards Peder
Best, Vicente _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
The culprit is in line 156 in boost/typeof/msvc/typeof_impl.hpp # if BOOST_WORKAROUND(BOOST_MSVC,==1310) This entire if branch should be removed. A minimal fix for this release is to change from 1310 to some other arbitrary non-version number. I have no idea why the typeof regression tests does not pick up this error. Regards Peder 2010/11/20 Peder Holt <peder.holt@gmail.com>
2010/11/20 Vicente BOTET <vicente.botet@wanadoo.fr>
Message du 20/11/10 14:52
De : "Eric Niebler" A : boost@lists.boost.org Copie à : Objet : Re: [boost] Boost 1.45 compile error
On 11/20/2010 7:25 AM, John Maddock wrote:
> This sounds bad. Can anybody confirm?
The tests already confirm it .
Crap. Might I suggest we pull the release and reissue as a point release after this is fixed?
Adding back the missing context:
Is this type_traits specific, or should boost.typeof work on that platform... I'm sure it used to?
I don't know. Is common_type the only trait to use boost.typeof? If so, can we just comment out the #include of common_type.hpp in type_traits.hpp as a stop-gap?
BTW there are a *lot* of failures with VC7.1 relating to this.
Most of the failures if not all are due to the includion of common_type.hpp.
By "this" do you mean the type_traits error or the boost.typeof failure?
As Boost.Typeof is Ok with this compiler we can not say yet that the problem is with Boost.Typeof. Surprisingly the same compiler in trunk works "daw-msvc71 rev 66640 Fri, 19 02:00:37 +0000i msvc- 7.1"
daw-msvc71 rev 66641 Fri, 19 Nov 2010 09:00:32 +0000i fails on release.
From my part we can comment the #inlcude for common_type from the type_traits.hpp file. Applications that want to use common_type can include for the moment.
I will install Visual Studio 2003 ASAP and try to see if there is something obviously wrong with boost.typeof for this compiler.
Regards Peder
Best, Vicente _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
This problem has been fixed on the trunk version for a while, but I haven't managed to integrated this to the release branch. Sorry about that. Regards Peder 2010/11/20 Peder Holt <peder.holt@gmail.com>
The culprit is in line 156 in boost/typeof/msvc/typeof_impl.hpp # if BOOST_WORKAROUND(BOOST_MSVC,==1310) This entire if branch should be removed. A minimal fix for this release is to change from 1310 to some other arbitrary non-version number. I have no idea why the typeof regression tests does not pick up this error.
Regards Peder
2010/11/20 Peder Holt <peder.holt@gmail.com>
2010/11/20 Vicente BOTET <vicente.botet@wanadoo.fr>
Message du 20/11/10 14:52
De : "Eric Niebler" A : boost@lists.boost.org Copie à : Objet : Re: [boost] Boost 1.45 compile error
On 11/20/2010 7:25 AM, John Maddock wrote:
>> This sounds bad. Can anybody confirm? > > The tests already confirm it .
Crap. Might I suggest we pull the release and reissue as a point release after this is fixed?
Adding back the missing context:
Is this type_traits specific, or should boost.typeof work on that platform... I'm sure it used to?
I don't know. Is common_type the only trait to use boost.typeof? If so, can we just comment out the #include of common_type.hpp in type_traits.hpp as a stop-gap?
BTW there are a *lot* of failures with VC7.1 relating to this.
Most of the failures if not all are due to the includion of common_type.hpp.
By "this" do you mean the type_traits error or the boost.typeof failure?
As Boost.Typeof is Ok with this compiler we can not say yet that the problem is with Boost.Typeof. Surprisingly the same compiler in trunk works "daw-msvc71 rev 66640 Fri, 19 02:00:37 +0000i msvc- 7.1"
daw-msvc71 rev 66641 Fri, 19 Nov 2010 09:00:32 +0000i fails on release.
From my part we can comment the #inlcude for common_type from the type_traits.hpp file. Applications that want to use common_type can include for the moment.
I will install Visual Studio 2003 ASAP and try to see if there is something obviously wrong with boost.typeof for this compiler.
Regards Peder
Best, Vicente _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
I have just fixed the typeof problem on the release branch. (I've also verified that it makes the common_type regression go away without causing additional failures for either the typeof or type_traits libraries.) I know it's not our policy to issue point releases, but totally breaking a major header (boost/type_traits.hpp) for a primary test compiler (msvc-7.1) seems like a good reason to make an exception. Does anybody feel otherwise? The changelist containing the fix is 66662. I suggest we wait for tests to cycle and issue 1.45.1 asap. Thoughts? Eric On 11/20/2010 12:41 PM, Peder Holt wrote:
This problem has been fixed on the trunk version for a while, but I haven't managed to integrated this to the release branch. Sorry about that.
Regards Peder
2010/11/20 Peder Holt <peder.holt@gmail.com>
The culprit is in line 156 in boost/typeof/msvc/typeof_impl.hpp # if BOOST_WORKAROUND(BOOST_MSVC,==1310) This entire if branch should be removed. A minimal fix for this release is to change from 1310 to some other arbitrary non-version number. I have no idea why the typeof regression tests does not pick up this error.
Regards Peder
2010/11/20 Peder Holt <peder.holt@gmail.com>
2010/11/20 Vicente BOTET <vicente.botet@wanadoo.fr>
Message du 20/11/10 14:52
De : "Eric Niebler" A : boost@lists.boost.org Copie à : Objet : Re: [boost] Boost 1.45 compile error
On 11/20/2010 7:25 AM, John Maddock wrote:
>>> This sounds bad. Can anybody confirm? >> >> The tests already confirm it . > > Crap. Might I suggest we pull the release and reissue as a point release > after this is fixed? > > Adding back the missing context:
Is this type_traits specific, or should boost.typeof work on that platform... I'm sure it used to?
I don't know. Is common_type the only trait to use boost.typeof? If so, can we just comment out the #include of common_type.hpp in type_traits.hpp as a stop-gap?
BTW there are a *lot* of failures with VC7.1 relating to this.
Most of the failures if not all are due to the includion of common_type.hpp.
By "this" do you mean the type_traits error or the boost.typeof failure?
As Boost.Typeof is Ok with this compiler we can not say yet that the problem is with Boost.Typeof. Surprisingly the same compiler in trunk works "daw-msvc71 rev 66640 Fri, 19 02:00:37 +0000i msvc- 7.1"
daw-msvc71 rev 66641 Fri, 19 Nov 2010 09:00:32 +0000i fails on release.
From my part we can comment the #inlcude for common_type from the type_traits.hpp file. Applications that want to use common_type can include for the moment.
I will install Visual Studio 2003 ASAP and try to see if there is something obviously wrong with boost.typeof for this compiler.
Regards Peder
Best, Vicente _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- Eric Niebler BoostPro Computing http://www.boostpro.com
Eric Niebler wrote:
I have just fixed the typeof problem on the release branch. (I've also verified that it makes the common_type regression go away without causing additional failures for either the typeof or type_traits libraries.)
I know it's not our policy to issue point releases, but totally breaking a major header (boost/type_traits.hpp) for a primary test compiler (msvc-7.1) seems like a good reason to make an exception. Does anybody feel otherwise?
Since msvc-7.1 doesn't appear in the test matrix for the release version I don't see how it can be considered a primary test compiler. Robert Ramey
At Sun, 21 Nov 2010 14:27:46 -0800, Robert Ramey wrote:
Eric Niebler wrote:
I have just fixed the typeof problem on the release branch. (I've also verified that it makes the common_type regression go away without causing additional failures for either the typeof or type_traits libraries.)
I know it's not our policy to issue point releases, but totally breaking a major header (boost/type_traits.hpp) for a primary test compiler (msvc-7.1) seems like a good reason to make an exception. Does anybody feel otherwise?
Since msvc-7.1 doesn't appear in the test matrix for the release version I don't see how it can be considered a primary test compiler.
+1 Now, maybe the answer is "we messed up by not noticing that our tester upgraded to vc-8" or something. But either way, the release managers have to decide if this is important enough to issue a point release. VC-7.1 _is_ getting a bit long in the tooth at this point... -- Dave Abrahams BoostPro Computing http://www.boostpro.com
On 11/21/2010 5:34 PM, David Abrahams wrote:
At Sun, 21 Nov 2010 14:27:46 -0800, Robert Ramey wrote:
Eric Niebler wrote:
I have just fixed the typeof problem on the release branch. (I've also verified that it makes the common_type regression go away without causing additional failures for either the typeof or type_traits libraries.)
I know it's not our policy to issue point releases, but totally breaking a major header (boost/type_traits.hpp) for a primary test compiler (msvc-7.1) seems like a good reason to make an exception. Does anybody feel otherwise?
Since msvc-7.1 doesn't appear in the test matrix for the release version I don't see how it can be considered a primary test compiler.
+1
Now, maybe the answer is "we messed up by not noticing that our tester upgraded to vc-8" or something. But either way, the release managers have to decide if this is important enough to issue a point release. VC-7.1 _is_ getting a bit long in the tooth at this point...
Our release notes for 1.45 (http://www.boost.org/users/news/version_1_45_0) list msvc-7.1 as a primary tested compiler. If we're going to drop msvc-7.1, it should be because it's old and nobody's using it, not because we f'ed up and released something we shouldn't have. The mere fact that someone noticed that it's broken the SAME day we released 1.45 suggests to me that people still care about this compiler. -- Eric Niebler BoostPro Computing http://www.boostpro.com
Eric Niebler <eric@boostpro.com> writes:
The mere fact that someone noticed that it's broken the SAME day we released 1.45 suggests to me that people still care about this compiler.
+1. One of my clients still uses MSVC 7.1 for one of their products. They don't appear to have any plans of upgrading the compiler, but are relatively happy to update the used libraries (such as boost). Anthony -- Author of C++ Concurrency in Action http://www.stdthread.co.uk/book/ just::thread C++0x thread library http://www.stdthread.co.uk Just Software Solutions Ltd http://www.justsoftwaresolutions.co.uk 15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK. Company No. 5478976
On Sun, Nov 21, 2010 at 5:34 PM, David Abrahams <dave@boostpro.com> wrote:
At Sun, 21 Nov 2010 14:27:46 -0800, Robert Ramey wrote:
Eric Niebler wrote:
I have just fixed the typeof problem on the release branch. (I've also verified that it makes the common_type regression go away without causing additional failures for either the typeof or type_traits libraries.)
I know it's not our policy to issue point releases, but totally breaking a major header (boost/type_traits.hpp) for a primary test compiler (msvc-7.1) seems like a good reason to make an exception. Does anybody feel otherwise?
Since msvc-7.1 doesn't appear in the test matrix for the release version I don't see how it can be considered a primary test compiler.
+1
Now, maybe the answer is "we messed up by not noticing that our tester upgraded to vc-8" or something. But either way, the release managers have to decide if this is important enough to issue a point release. VC-7.1 _is_ getting a bit long in the tooth at this point...
The current situation is a total mess in that the release managers have no practical control over who tests which branch with what compiler. We need a pool of available platforms, and a mechanism controlled by the release managers to parcel out tests to the available platforms.The only tests that mechanism will run are release platform tests on the release branch. Then there needs to be a different interface that a developer uses for test-on-demand of his/her Git repository. Then the GIT push or pull mechanisms can be used to move code into the main Boost release repository only when it is already passing tests. The distinction between trunk and release goes away. --Beman
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/25/2010 7:53 PM, Beman Dawes wrote:
On Sun, Nov 21, 2010 at 5:34 PM, David Abrahams <dave@boostpro.com> wrote:
At Sun, 21 Nov 2010 14:27:46 -0800, Robert Ramey wrote:
Eric Niebler wrote:
I have just fixed the typeof problem on the release branch. (I've also verified that it makes the common_type regression go away without causing additional failures for either the typeof or type_traits libraries.)
I know it's not our policy to issue point releases, but totally breaking a major header (boost/type_traits.hpp) for a primary test compiler (msvc-7.1) seems like a good reason to make an exception. Does anybody feel otherwise?
Since msvc-7.1 doesn't appear in the test matrix for the release version I don't see how it can be considered a primary test compiler.
+1
Now, maybe the answer is "we messed up by not noticing that our tester upgraded to vc-8" or something. But either way, the release managers have to decide if this is important enough to issue a point release. VC-7.1 _is_ getting a bit long in the tooth at this point...
The current situation is a total mess in that the release managers have no practical control over who tests which branch with what compiler. We need a pool of available platforms, and a mechanism controlled by the release managers to parcel out tests to the available platforms.The only tests that mechanism will run are release platform tests on the release branch. Then there needs to be a different interface that a developer uses for test-on-demand of his/her Git repository. Then the GIT push or pull mechanisms can be used to move code into the main Boost release repository only when it is already passing tests. The distinction between trunk and release goes away.
Beman, what about the issue at hand of issuing a point release to fix the msvc-7.1 regression? - -- Eric Niebler BoostPro Computing http://www.boostpro.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJM8Cn5AAoJEAeJsEDfjLbXLDcIAI1liZRtoCVkS5xdzjjOMWrT 4vNQUc1IFYU0TZwrcv+ZsItzjf/WgVIOPv9jAHUowV3fVtXvh2DGcLRdPSymulGg U1XV2X1xrONTH9Jso6sWXdVHe10uQaI3jTkO1o8fBoP++iy5G+1r1flpMb4XIQdP xIRF1PKcg4u1XaX41AAzgb4isv8RG2lFQLspIL2im/R8iH4DBpzuxQhofBlJ1baf /6RuiPfd9kNTov2hdAhMTYuG96nNsLskjScCcQE5HZAMX7o7NBMcuP38bvoAKVhQ CCt1humg8GGKyuF1nYzXK4v0ALW3EoK72TDIS6Xt39oAYJr4o4LaEWHYVtLFCH8= =TcRI -----END PGP SIGNATURE-----
Beman Dawes wrote:
On Sun, Nov 21, 2010 at 5:34 PM, David Abrahams <dave@boostpro.com> wrote:
At Sun, 21 Nov 2010 14:27:46 -0800, Robert Ramey wrote:
Eric Niebler wrote:
I have just fixed the typeof problem on the release branch. (I've also verified that it makes the common_type regression go away without causing additional failures for either the typeof or type_traits libraries.)
I know it's not our policy to issue point releases, but totally breaking a major header (boost/type_traits.hpp) for a primary test compiler (msvc-7.1) seems like a good reason to make an exception. Does anybody feel otherwise?
Since msvc-7.1 doesn't appear in the test matrix for the release version I don't see how it can be considered a primary test compiler.
+1
Now, maybe the answer is "we messed up by not noticing that our tester upgraded to vc-8" or something. But either way, the release managers have to decide if this is important enough to issue a point release. VC-7.1 _is_ getting a bit long in the tooth at this point...
The current situation is a total mess in that the release managers have no practical control over who tests which branch with what compiler. We need a pool of available platforms, and a mechanism controlled by the release managers to parcel out tests to the available platforms.The only tests that mechanism will run are release platform tests on the release branch. Then there needs to be a different interface that a developer uses for test-on-demand of his/her Git repository. Then the GIT push or pull mechanisms can be used to move code into the main Boost release repository only when it is already passing tests. The distinction between trunk and release goes away.
I don't think so. You're replacing release and trunk branches in a same repository, with one release branch, and N work-in-progress branches in different repositories, which makes the whole situation less manageable, not more. (For example, you might want to drop into boost IRC channel and count the number of people who complain about 10 git clones of Boost, in various degree of deadness). - Volodya
On 21 November 2010 22:27, Robert Ramey <ramey@rrsd.com> wrote:
Eric Niebler wrote:
I have just fixed the typeof problem on the release branch. (I've also verified that it makes the common_type regression go away without causing additional failures for either the typeof or type_traits libraries.)
I know it's not our policy to issue point releases, but totally breaking a major header (boost/type_traits.hpp) for a primary test compiler (msvc-7.1) seems like a good reason to make an exception. Does anybody feel otherwise?
Since msvc-7.1 doesn't appear in the test matrix for the release version I don't see how it can be considered a primary test compiler.
That list is based on the test compilers. There's a 7.1 release tester: http://www.boost.org/development/tests/release/daw-msvc71.html Daniel
At Sun, 21 Nov 2010 23:44:33 +0000, Daniel James wrote:
I know it's not our policy to issue point releases, but totally breaking a major header (boost/type_traits.hpp) for a primary test compiler (msvc-7.1) seems like a good reason to make an exception. Does anybody feel otherwise?
Since msvc-7.1 doesn't appear in the test matrix for the release version I don't see how it can be considered a primary test compiler.
That list is based on the test compilers. There's a 7.1 release tester:
http://www.boost.org/development/tests/release/daw-msvc71.html
I'm sorry, I don't understand the distinction you're making here. Could you explain? Thanks, -- Dave Abrahams BoostPro Computing http://www.boostpro.com
On 22 November 2010 00:23, David Abrahams <dave@boostpro.com> wrote:
At Sun, 21 Nov 2010 23:44:33 +0000, Daniel James wrote:
Since msvc-7.1 doesn't appear in the test matrix for the release version I don't see how it can be considered a primary test compiler.
That list is based on the test compilers. There's a 7.1 release tester:
http://www.boost.org/development/tests/release/daw-msvc71.html
I'm sorry, I don't understand the distinction you're making here. Could you explain?
I'm not making any distinction. The release branch is tested with Visual C++ 7.1. That's why it's listed as a primary test compiler. Daniel
At Mon, 22 Nov 2010 19:45:50 +0000, Daniel James wrote:
On 22 November 2010 00:23, David Abrahams <dave@boostpro.com> wrote:
At Sun, 21 Nov 2010 23:44:33 +0000, Daniel James wrote:
Since msvc-7.1 doesn't appear in the test matrix for the release version I don't see how it can be considered a primary test compiler.
That list is based on the test compilers. There's a 7.1 release tester:
http://www.boost.org/development/tests/release/daw-msvc71.html
I'm sorry, I don't understand the distinction you're making here. Could you explain?
I'm not making any distinction. The release branch is tested with Visual C++ 7.1. That's why it's listed as a primary test compiler.
Sorry, let me re-ask. Can you explain what "that list is based on the test compilers" means? Specifically: * what list? * what does "based on" mean? Are you just trying to say "that is a list of the test compilers," or is it something more nuanced? * what do you mean by "test compilers?" Compilers actually used for testing? Something else? This may just be my literal brain failing to grasp the obvious (it happens), but I'd appreciate it if you could spell it out for me. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
On 22 November 2010 20:21, David Abrahams <dave@boostpro.com> wrote:
Sorry, let me re-ask. Can you explain what "that list is based on the test compilers" means? Specifically:
* what list?
The list at the bottom of the release notes, in the 'Compilers Tested' section.
* what does "based on" mean? Are you just trying to say "that is a list of the test compilers," or is it something more nuanced?
The 'primary test compilers' are usually the stable releases of compilers which have been tested against the release branch. Clang is missing from the list because the compilers used were built from clang's trunk (this can be seen in the output from the 'config_info' test), so there are possible differences from the released version. We've also excluded compilers released during the release cycle, which haven't received sufficient testing. Compilers that weren't considered suitable, or are used for testing trunk are listed as 'additional test compilers'. We've never had formal rules - this is based on past decisions. I've got into the habit of compiling the list a little while before the beta, and then check for changes before the release. I sometimes exclude compilers which don't seem to be regularly running (it's not very scientific).
* what do you mean by "test compilers?" Compilers actually used for testing?
Yes. Daniel
Daniel James wrote:
On 22 November 2010 00:23, David Abrahams <dave@boostpro.com> wrote:
At Sun, 21 Nov 2010 23:44:33 +0000, Daniel James wrote:
Since msvc-7.1 doesn't appear in the test matrix for the release version I don't see how it can be considered a primary test compiler.
That list is based on the test compilers. There's a 7.1 release tester:
http://www.boost.org/development/tests/release/daw-msvc71.html
I'm sorry, I don't understand the distinction you're making here. Could you explain?
I'm not making any distinction. The release branch is tested with Visual C++ 7.1. That's why it's listed as a primary test compiler.
Looking at http://www.boost.org/development/tests/release/developer/summary.html I see the column for msvc 7.1 is in there now - but it wasn't in there last time I checked - a couple of days ago. Actually columns drop in and out all the time. Robert Ramey
I have just fixed the typeof problem on the release branch. (I've also verified that it makes the common_type regression go away without causing additional failures for either the typeof or type_traits libraries.)
I know it's not our policy to issue point releases, but totally breaking a major header (boost/type_traits.hpp) for a primary test compiler (msvc-7.1) seems like a good reason to make an exception. Does anybody feel otherwise?
The changelist containing the fix is 66662. I suggest we wait for tests to cycle and issue 1.45.1 asap.
Could we merge the patch for the Spirit issue (https://svn.boost.org/trac/boost/ticket/4871) to the release branch for this as well? Regards Hartmut --------------- http://boost-spirit.com
Thoughts?
Eric
On 11/20/2010 12:41 PM, Peder Holt wrote:
This problem has been fixed on the trunk version for a while, but I haven't managed to integrated this to the release branch. Sorry about that.
Regards Peder
2010/11/20 Peder Holt <peder.holt@gmail.com>
The culprit is in line 156 in boost/typeof/msvc/typeof_impl.hpp # if BOOST_WORKAROUND(BOOST_MSVC,==1310) This entire if branch should be removed. A minimal fix for this release is to change from 1310 to some other arbitrary non-version number. I have no idea why the typeof regression tests does not pick up this error.
Regards Peder
2010/11/20 Peder Holt <peder.holt@gmail.com>
2010/11/20 Vicente BOTET <vicente.botet@wanadoo.fr>
Message du 20/11/10 14:52
De : "Eric Niebler" A : boost@lists.boost.org Copie à : Objet : Re: [boost] Boost 1.45 compile error
On 11/20/2010 7:25 AM, John Maddock wrote: >>>> This sounds bad. Can anybody confirm? >>> >>> The tests already confirm it . >> >> Crap. Might I suggest we pull the release and reissue as a point release >> after this is fixed? >> >> Adding back the missing context: > > Is this type_traits specific, or should boost.typeof work on that > platform... I'm sure it used to?
I don't know. Is common_type the only trait to use boost.typeof? If so, can we just comment out the #include of common_type.hpp in type_traits.hpp as a stop-gap?
> BTW there are a *lot* of failures with VC7.1 relating to this.
Most of the failures if not all are due to the includion of common_type.hpp.
By "this" do you mean the type_traits error or the boost.typeof failure?
As Boost.Typeof is Ok with this compiler we can not say yet that the problem is with Boost.Typeof. Surprisingly the same compiler in trunk works "daw-msvc71 rev 66640 Fri, 19 02:00:37 +0000i msvc- 7.1"
daw-msvc71 rev 66641 Fri, 19 Nov 2010 09:00:32 +0000i fails on
release.
From my part we can comment the #inlcude for common_type from the type_traits.hpp file. Applications that want to use common_type can include for the moment.
I will install Visual Studio 2003 ASAP and try to see if there is something obviously wrong with boost.typeof for this compiler.
Regards Peder
Best, Vicente _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- Eric Niebler BoostPro Computing http://www.boostpro.com _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On 11/21/2010 5:29 PM, Hartmut Kaiser wrote:
Could we merge the patch for the Spirit issue (https://svn.boost.org/trac/boost/ticket/4871) to the release branch for this as well?
It's still not a showstopper, so I would think no. -- Eric Niebler BoostPro Computing http://www.boostpro.com
On Monday, November 22, 2010 00:51:27 Eric Niebler wrote:
I have just fixed the typeof problem on the release branch. (I've also verified that it makes the common_type regression go away without causing additional failures for either the typeof or type_traits libraries.)
I know it's not our policy to issue point releases, but totally breaking a major header (boost/type_traits.hpp) for a primary test compiler (msvc-7.1) seems like a good reason to make an exception. Does anybody feel otherwise?
The changelist containing the fix is 66662. I suggest we wait for tests to cycle and issue 1.45.1 asap.
I'd volunteer to try packaging 1.45.1, if that will help. - Volodya
Message du 20/11/10 04:17 De : "Eric Niebler" A : boost-users@lists.boost.org, "Boost mailing list" Copie à : Objet : Re: [boost] Boost 1.45 compile error
(bringing in boost dev...)
This sounds bad. Can anybody confirm?
-- Eric Niebler BoostPro Computing http://www.boostpro.com
On 11/19/2010 4:35 PM, gast128 wrote:
Hello all,
just tried out Boost 1.45 on VStudio 2003 but I got a compile error by only including type_traits:
#include
int main() { return 0; }
C:\Work Sdk\boost_1_45_0\boost\typeof\msvc\typeof_impl.hpp(160) : error C2027: use of undefined type '' C:\Work Sdk\boost_1_45_0\boost\typeof\msvc\typeof_impl.hpp(143) : see declaration of '' C:\Work Sdk\boost_1_45_0\boost\typeof\msvc\typeof_impl.hpp(160) : see reference to class template instantiation '' being compiled C:\Work Sdk\boost_1_45_0\boost\type_traits\common_type.hpp(121) : see reference to class template instantiation '' being compiled C:\Work Sdk\boost_1_45_0\boost\type_traits\common_type.hpp(123) : see reference to class template instantiation 'boost::type_traits_detail::common_type_2' being compiled C:\Work Sdk\boost_1_45_0\boost\typeof\msvc\typeof_impl.hpp(160) : error C2146: syntax error : missing ';' before identifier 'wrapped_type' C:\Work Sdk\boost_1_45_0\boost\typeof\msvc\typeof_impl.hpp(160) : error C2501: '' : missing storage-class or type specifiers C:\Work Sdk\boost_1_45_0\boost\typeof\msvc\typeof_impl.hpp(161) : error C2653: 'wrapped_type' : is not a class or namespace name
afaik it seems located on 121 in 'boost/type_traits/coomon_type.hpp'
Anyone can help?
Hi, I didn't make any tests with MSVC V7.1. If typeof don't works for this compiler maybe we can force BOOST_COMMON_TYPE_DONT_USE_TYPEOF and swithc to the emmulation that don't uses TYPEOF. #if MSVC 7.1 #define BOOST_COMMON_TYPE_DONT_USE_TYPEOF #endif Unfortunately I have no access to my Boost environement as my hard disk is broken. John, can you check this? Best, Vicente
On Fri, Nov 19, 2010 at 10:14 PM, Eric Niebler <eric@boostpro.com> wrote:
(bringing in boost dev...)
This sounds bad. Can anybody confirm?
-- Eric Niebler BoostPro Computing http://www.boostpro.com
On 11/19/2010 4:35 PM, gast128 wrote:
Hello all,
just tried out Boost 1.45 on VStudio 2003 but I got a compile error by only including type_traits:
#include <boost/type_traits.hpp>
int main() { return 0; }
What version of VC++ does that correspond to? VC++ 7.1 is being tested on both trunk and release, and passing on both. --Beman
participants (12)
-
Anthony Williams -
Beman Dawes -
Daniel James -
David Abrahams -
Eric Niebler -
Hartmut Kaiser -
John Maddock -
Peder Holt -
Rene Rivera -
Robert Ramey -
Vicente BOTET -
Vladimir Prus