[trunk/math] Building fails.
Continuing with building at the root for trunk... The math library fails to build for my on MacOSX with Xcode (3.1-beta7) with this error: darwin.compile.c++ bin.v2/libs/math/build/has_long_double_support.test/darwin-4.0.1/release/architecture-combined/macosx-version-min-10.3/macosx-version-10.5/threading-multi/has_long_double_support.o libs/math/build/has_long_double_support.cpp:5:2: error: #error "long double support not enabled" lipo: can't figure out the architecture type of: /var/tmp//ccouTTrW.out "/Developer/Xcode-3.1-beta7/usr/bin/g++-4.0" -ftemplate-depth-128 -O3 -finline-functions -Wno-inline -Wall -fPIC -mmacosx-version-min=10.3 -dynamic -no-cpp-precomp -gdwarf-2 -Wno-long-double -isysroot /Developer/Xcode-3.1-beta7/SDKs/MacOSX10.5.sdk -arch i386 -arch ppc -DBOOST_ALL_NO_LIB=1 -DNDEBUG -I"." -c -o "bin.v2/libs/math/build/has_long_double_support.test/darwin-4.0.1/release/architecture-combined/macosx-version-min-10.3/macosx-version-10.5/threading-multi/has_long_double_support.o" "libs/math/build/has_long_double_support.cpp" The problem is that the Jamfile for the math lib is doing a compile test. That seems like a bad idea to me if there's no purpose other than to just do the test. So, is there a good reason for doing that test during build? PS. It makes it a PITA to test building Boost before merging to release with such things going on! -- -- 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
Rene Rivera wrote:
The problem is that the Jamfile for the math lib is doing a compile test. That seems like a bad idea to me if there's no purpose other than to just do the test.
So, is there a good reason for doing that test during build?
One of the three libraries built in that Jamfile won't build on Darwin (because of no long double support for that platform in Boost.Math), the test is there to suppress building of that library in that case - without it you'll get thousands of pages of meaningless compiler errors which won't be much use to the user :-( Any better suggestions? BTW I basically copied the code from what the serialisation library does when there's no wchar_t support.
PS. It makes it a PITA to test building Boost before merging to release with such things going on!
How so? Not trying to awkward... just to understand the issues, John.
----- Original Message ----- From: "John Maddock" <john@johnmaddock.co.uk> To: <boost@lists.boost.org> Sent: Saturday, June 28, 2008 10:09 AM Subject: Re: [boost] [trunk/math] Building fails.
Rene Rivera wrote:
The problem is that the Jamfile for the math lib is doing a compile test. That seems like a bad idea to me if there's no purpose other than to just do the test.
So, is there a good reason for doing that test during build?
One of the three libraries built in that Jamfile won't build on Darwin (because of no long double support for that platform in Boost.Math), the test is there to suppress building of that library in that case - without it you'll get thousands of pages of meaningless compiler errors which won't be much use to the user :-(
The same applies to cygwin gcc 3.4.6 and many others gcc.compile.c++ bin.v2\libs\math\build\has_long_double_support.test\gcc-3.4.4\debug\target-os-cygwin\threadapi-pthread\threading-multi\has_long_double_support.o libs\math\build\has_long_double_support.cpp:5:2: #error "long double support not enabled" Maybe the error message could be more explicit. The message let think that we can enable long double, but if I have understood this is just not available on some compilers/platforms. Best Vicente
vicente.botet wrote:
Maybe the error message could be more explicit. The message let think that we can enable long double, but if I have understood this is just not available on some compilers/platforms.
Right, how about: "long double support is not supported by Boost.Math on this Plaform: the long double version of the TR1 library will not be built." John.
----- Original Message ----- From: "John Maddock" <john@johnmaddock.co.uk> To: <boost@lists.boost.org> Sent: Saturday, June 28, 2008 1:10 PM Subject: Re: [boost] [trunk/math] Building fails.
vicente.botet wrote:
Maybe the error message could be more explicit. The message let think that we can enable long double, but if I have understood this is just not available on some compilers/platforms.
Right, how about: "long double support is not supported by Boost.Math on this Plaform: the long double version of the TR1 library will not be built."
It seams quite explict to me. Vicente
John Maddock wrote:
Rene Rivera wrote:
The problem is that the Jamfile for the math lib is doing a compile test. That seems like a bad idea to me if there's no purpose other than to just do the test.
So, is there a good reason for doing that test during build?
One of the three libraries built in that Jamfile won't build on Darwin (because of no long double support for that platform in Boost.Math), the test is there to suppress building of that library in that case - without it you'll get thousands of pages of meaningless compiler errors which won't be much use to the user :-(
Any better suggestions? BTW I basically copied the code from what the serialisation library does when there's no wchar_t support.
Hm, I'll have to think some more about that.
PS. It makes it a PITA to test building Boost before merging to release with such things going on!
How so? Not trying to awkward... just to understand the issues,
Initially just because I didn't know if it was a problem I introduced, since I was working on making build changes. Hence I spent a good number of minutes trying to figure out the ultimate programmer question "Did *I* break something?". It means that each time I do the top level build I'll have to take careful note if it's the failing test or something I did. And as you know humans aren't very good at doing careful repetitive tasks. So it's a PITA since it means more time I have to spend thinking about the output, and less about what I'm trying to fix. -- -- 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
Rene Rivera wrote:
How so? Not trying to awkward... just to understand the issues,
Initially just because I didn't know if it was a problem I introduced, since I was working on making build changes. Hence I spent a good number of minutes trying to figure out the ultimate programmer question "Did *I* break something?". It means that each time I do the top level build I'll have to take careful note if it's the failing test or something I did. And as you know humans aren't very good at doing careful repetitive tasks. So it's a PITA since it means more time I have to spend thinking about the output, and less about what I'm trying to fix.
Nod, understood. If we could make the output silent, or use something other than the testing framework that would be better I guess. But I don't know enough about BBv2 to do that or even to know if it's possible :-( John.
participants (3)
-
John Maddock -
Rene Rivera -
vicente.botet