The new integral_promotion.hpp doesn't compile with the old EDG238-based MIPSpro 7.3.1 compiler (SGI, IRIX). This breaks our Boost.Python build. However, with the simple patch below the build is OK again. I'd love to maintain the MIPSpro Boost.Python build, but it is not worth serious work. Therefore the patch is simply #ifdef'ing out the two promotion header files for this specific platform. Are there any objections against this approach? Thanks! Ralf Index: type_traits.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/type_traits.hpp,v retrieving revision 1.16 diff -u -r1.16 type_traits.hpp --- type_traits.hpp 22 May 2006 21:02:59 -0000 1.16 +++ type_traits.hpp 26 May 2006 22:45:51 -0000 @@ -71,8 +71,10 @@ #include "boost/type_traits/function_traits.hpp" #include "boost/type_traits/aligned_storage.hpp" #include "boost/type_traits/floating_point_promotion.hpp" +#if !(defined(__sgi) && defined(__EDG_VERSION__) && (__EDG_VERSION__ == 238)) #include "boost/type_traits/integral_promotion.hpp" #include "boost/type_traits/promote.hpp" +#endif #include "boost/type_traits/ice.hpp" For the records, this is the error: cc-3313 CC: ERROR File = boost/boost/type_traits/integral_promotion.hpp, Line = 158 The expression must have arithmetic or enum type. BOOST_STATIC_CONSTANT(int, value = sizeof(promoted_index_tester(+testee)) ); ^ I've reduced it to: template<int N> struct sized_type_for_promotion { typedef char (&type)[N]; }; sized_type_for_promotion<1> ::type promoted_index_tester(int); sized_type_for_promotion<2> ::type promoted_index_tester(unsigned int); sized_type_for_promotion<3> ::type promoted_index_tester(long); sized_type_for_promotion<4> ::type promoted_index_tester(unsigned long); template<class T> struct promoted_index { static T testee; static const int value = sizeof(promoted_index_tester(+testee)); }; __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
"Ralf W. Grosse-Kunstleve" <rwgk@yahoo.com> writes:
The new integral_promotion.hpp doesn't compile with the old EDG238-based MIPSpro 7.3.1 compiler (SGI, IRIX). This breaks our Boost.Python build. However, with the simple patch below the build is OK again. I'd love to maintain the MIPSpro Boost.Python build, but it is not worth serious work. Therefore the patch is simply #ifdef'ing out the two promotion header files for this specific platform. Are there any objections against this approach?
Ideally nothing in Boost.Python should be including type_traits.hpp; we should be using the fine-grained headers instead. -- Dave Abrahams Boost Consulting www.boost-consulting.com
--- David Abrahams <dave@boost-consulting.com> wrote:
"Ralf W. Grosse-Kunstleve" <rwgk@yahoo.com> writes:
The new integral_promotion.hpp doesn't compile with the old EDG238-based MIPSpro 7.3.1 compiler (SGI, IRIX). This breaks our Boost.Python build. However, with the simple patch below the build is OK again. I'd love to maintain the MIPSpro Boost.Python build, but it is not worth serious work. Therefore the patch is simply #ifdef'ing out the two promotion header files for this specific platform. Are there any objections against this approach?
Ideally nothing in Boost.Python should be including type_traits.hpp; we should be using the fine-grained headers instead.
libs/python/src/object/inheritance.cpp includes boost/graph/adjacency_list.hpp which after a few levels of indirection winds up including boost/detail/numeric_traits.hpp which eventually includes boost/type_traits.hpp Making this more fine-grained seems like a real project to me, mainly because there are too many people to talk to. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Ralf W. Grosse-Kunstleve wrote:
I've reduced it to:
template<int N> struct sized_type_for_promotion { typedef char (&type)[N]; };
sized_type_for_promotion<1> ::type promoted_index_tester(int); sized_type_for_promotion<2> ::type promoted_index_tester(unsigned int); sized_type_for_promotion<3> ::type promoted_index_tester(long); sized_type_for_promotion<4> ::type promoted_index_tester(unsigned long);
May be it doesn't like sized_type_for_promotion? Could you try this approach: char (&promoted_index_tester(int)) [1]; char (&promoted_index_tester(unsigned int)) [2]; char (&promoted_index_tester(long)) [3]; char (&promoted_index_tester(unsigned long))[4]; ? You only need to activate another branch of #if !defined(BOOST_MSVC) The patch is attached. -- Alexander Nasonov Project Manager http://www.akmosoft.com
--- Alexander Nasonov <alnsn@yandex.ru> wrote:
Ralf W. Grosse-Kunstleve wrote:
I've reduced it to:
template<int N> struct sized_type_for_promotion { typedef char (&type)[N]; };
sized_type_for_promotion<1> ::type promoted_index_tester(int); sized_type_for_promotion<2> ::type promoted_index_tester(unsigned int); sized_type_for_promotion<3> ::type promoted_index_tester(long); sized_type_for_promotion<4> ::type promoted_index_tester(unsigned long);
May be it doesn't like sized_type_for_promotion?
Could you try this approach:
char (&promoted_index_tester(int)) [1]; char (&promoted_index_tester(unsigned int)) [2]; char (&promoted_index_tester(long)) [3]; char (&promoted_index_tester(unsigned long))[4];
?
Thanks for the suggestions! Unfortunately it doesn't work (same error message).
You only need to activate another branch of #if !defined(BOOST_MSVC) The patch is attached.
I tried this too and it also doesn't work. Please don't spend any time on this. Only crystallographers are crazy enough to still use the old SGI's, and in crystallography we may be the only people crazy enough to use boost. :) If there are objections against my simple workaround I'll just maintain the patch locally until SGI is completely dead, no big deal. Cheers, Ralf __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Ralf W. Grosse-Kunstleve wrote:
The new integral_promotion.hpp doesn't compile with the old EDG238-based MIPSpro 7.3.1 compiler (SGI, IRIX). This breaks our Boost.Python build. However, with the simple patch below the build is OK again. I'd love to maintain the MIPSpro Boost.Python build, but it is not worth serious work. Therefore the patch is simply #ifdef'ing out the two promotion header files for this specific platform. Are there any objections against this approach?
That looks sensible to me, go ahead and commit if you want to, John.
Ralf W. Grosse-Kunstleve wrote:
The new integral_promotion.hpp doesn't compile with the old EDG238-based MIPSpro 7.3.1 compiler (SGI, IRIX). This breaks our Boost.Python build. However, with the simple patch below the build is OK again. I'd love to maintain the MIPSpro Boost.Python build, but it is not worth serious work. Therefore the patch is simply #ifdef'ing out the two promotion header files for this specific platform. Are there any objections against this approach?
That looks sensible to me, go ahead and commit if you want to as I don't see it can possibly do any harm? John.
--- John Maddock <john@johnmaddock.co.uk> wrote:
Ralf W. Grosse-Kunstleve wrote:
The new integral_promotion.hpp doesn't compile with the old EDG238-based MIPSpro 7.3.1 compiler (SGI, IRIX). This breaks our Boost.Python build. However, with the simple patch below the build is OK again. I'd love to maintain the MIPSpro Boost.Python build, but it is not worth serious work. Therefore the patch is simply #ifdef'ing out the two promotion header files for this specific platform. Are there any objections against this approach?
That looks sensible to me, go ahead and commit if you want to as I don't see it can possibly do any harm?
Thanks John! I did extensive testing internally and was going to commit, but... https://sourceforge.net/tracker/index.php?func=detail&aid=1495972&group_id=1&atid=200001 cvs diff: failed to create lock directory for `/cvsroot/boost/boost/boost' (/cvsroot/boost/boost/boost/#cvs.lock): Permission denied cvs diff: failed to obtain dir lock in repository `/cvsroot/boost/boost/boost' cvs [diff aborted]: read lock failed - giving up I am very sorry if this was my fault (although I think it is a bad trap). Do others have the same problem? Ralf __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
participants (4)
-
Alexander Nasonov -
David Abrahams -
John Maddock -
Ralf W. Grosse-Kunstleve