Boost C++ Libraries: Ticket #2597: Boost fails to build when long doubles not supported

attachment set

anonymous — Wed, 17 Dec 2008 06:09:15 GMT

attachment → add-disable-long-double.patch

status changed

John Maddock — Wed, 17 Dec 2008 10:38:28 GMT

status new → assigned

Well, this is the way of doing it automatically! Or at least the best we can achieve with current the Boost.Build :-(

An alternative would be to add a <build>no property to the has_long_double.cpp compile test for platforms which are known to have no long double support. Then you wouldn't see the failure, but you would still see a lot of targets skipped - rightly so IMO since part of the library can't be built there should be at least some user warning?

Would this be acceptable, and is there a way to detect the debian version within Boost.Build?

Thanks, John.

smr@… — Fri, 19 Dec 2008 02:44:05 GMT

Replying to johnmaddock:

Well, this is the way of doing it automatically! Or at least the best we can achieve with current the Boost.Build :-(

I've opened a discussion about this on boost-build; c.f. http://lists.boost.org/boost-build/2008/12/20974.php

An alternative would be to add a <build>no property to the has_long_double.cpp compile test for platforms which are known to have no long double support. Then you wouldn't see the failure, but you would still see a lot of targets skipped - rightly so IMO since part of the library can't be built there should be at least some user warning?

I agree that a warning is warranted.

Would this be acceptable, and is there a way to detect the debian version within Boost.Build?

I don't know. I guess if you can run some kind of command for this, maybe try running "cc -c has_long_double_support.cpp" and test for existence of has_long_double_support.o?

anonymous — Fri, 19 Dec 2008 09:46:17 GMT

I don't know. I guess if you can run some kind of command for this, maybe try running "cc -c has_long_double_support.cpp" and test for existence of has_long_double_support.o?

Unfortunately that wouldn't work: we couldn't be sure that the compiler we are *actually* building with was the one in the path. We might also be building with more than one compiler :-(

We could the output from uname and that's probably about it...

John.

status changed; resolution set

John Maddock — Wed, 24 Dec 2008 11:20:32 GMT

status assigned → closed
resolution → fixed

(In [50378]) Simplified version of patch in #2597. Fixes #2597.