Testing -fno-rtti builds (was: [function] function_base.hpp:220: error: cannot use typeid with -fno-rtti)
On Thu, Jan 8, 2009 at 9:21 AM, Doug Gregor <doug.gregor@gmail.com> wrote:
On Wed, Jan 7, 2009 at 5:33 PM, Steven Watanabe <watanabesj@gmail.com> wrote:
Emil Dotchevski wrote:
Does boost::function not support -fno-rtti by design (linux/gcc 4.1.3)?
target, target_type, and contains require typeid. I suppose that in principle these could be disabled.
Yes, it's possible, and I'd certainly accept a patch that did so.
Someone correct me if I'm doing it wrong, but for example the RTTI-less and typeid-less configurations of Boost Exception, the library I'm maintaining, are tested only by me on my own computer, and I'm only testing them with MSVC and a single version of linux/gcc. Shouldn't the automatic trunk/release tests handle these, as well as other supported configurations? I guess what I'm saying is, I can make a patch to make boost::function work without RTTI, but I'm certainly not up to running those tests too. :) -- Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
On Thu, Jan 8, 2009 at 10:10 AM, Emil Dotchevski <emildotchevski@gmail.com> wrote:
On Thu, Jan 8, 2009 at 9:21 AM, Doug Gregor <doug.gregor@gmail.com> wrote:
On Wed, Jan 7, 2009 at 5:33 PM, Steven Watanabe <watanabesj@gmail.com> wrote:
Emil Dotchevski wrote:
Does boost::function not support -fno-rtti by design (linux/gcc 4.1.3)?
target, target_type, and contains require typeid. I suppose that in principle these could be disabled.
Yes, it's possible, and I'd certainly accept a patch that did so.
Someone correct me if I'm doing it wrong, but for example the RTTI-less and typeid-less configurations of Boost Exception, the library I'm maintaining, are tested only by me on my own computer, and I'm only testing them with MSVC and a single version of linux/gcc. Shouldn't the automatic trunk/release tests handle these, as well as other supported configurations?
I guess what I'm saying is, I can make a patch to make boost::function work without RTTI, but I'm certainly not up to running those tests too. :)
I'm sure you can teach bjam to build a test using the appropriate extra flags for each compiler, but I don't recall how to do so. Then we could put that test in with the rest of Boost.Function's tests. - Doug
On Thu, Jan 8, 2009 at 10:17 AM, Doug Gregor <doug.gregor@gmail.com> wrote:
On Thu, Jan 8, 2009 at 10:10 AM, Emil Dotchevski <emildotchevski@gmail.com> wrote:
On Thu, Jan 8, 2009 at 9:21 AM, Doug Gregor <doug.gregor@gmail.com> wrote:
On Wed, Jan 7, 2009 at 5:33 PM, Steven Watanabe <watanabesj@gmail.com> wrote:
Emil Dotchevski wrote:
Does boost::function not support -fno-rtti by design (linux/gcc 4.1.3)?
target, target_type, and contains require typeid. I suppose that in principle these could be disabled.
Yes, it's possible, and I'd certainly accept a patch that did so.
Someone correct me if I'm doing it wrong, but for example the RTTI-less and typeid-less configurations of Boost Exception, the library I'm maintaining, are tested only by me on my own computer, and I'm only testing them with MSVC and a single version of linux/gcc. Shouldn't the automatic trunk/release tests handle these, as well as other supported configurations?
I guess what I'm saying is, I can make a patch to make boost::function work without RTTI, but I'm certainly not up to running those tests too. :)
I'm sure you can teach bjam to build a test using the appropriate extra flags for each compiler, but I don't recall how to do so. Then we could put that test in with the rest of Boost.Function's tests.
Yes that's how I do it :) but I do not want to be running -fno-rtti tests for boost::function on a regular basis. Also consider that disabling RTTI comes in two flavors, since on MSVC static typeid is available even when RTTI is disabled. This ought to be part of all Boost testing, provided that the Boost community cares about -fno-rtti (I can say this the other way around too, if we're not testing the no-RTTI configuration of Boost, then we don't care about that configuration.) Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
On Thu, Jan 8, 2009 at 10:33 AM, Emil Dotchevski <emildotchevski@gmail.com> wrote:
On Thu, Jan 8, 2009 at 10:17 AM, Doug Gregor <doug.gregor@gmail.com> wrote:
On Thu, Jan 8, 2009 at 10:10 AM, Emil Dotchevski <emildotchevski@gmail.com> wrote:
On Thu, Jan 8, 2009 at 9:21 AM, Doug Gregor <doug.gregor@gmail.com> wrote:
On Wed, Jan 7, 2009 at 5:33 PM, Steven Watanabe <watanabesj@gmail.com> wrote:
Emil Dotchevski wrote:
Does boost::function not support -fno-rtti by design (linux/gcc 4.1.3)?
target, target_type, and contains require typeid. I suppose that in principle these could be disabled.
Yes, it's possible, and I'd certainly accept a patch that did so.
Someone correct me if I'm doing it wrong, but for example the RTTI-less and typeid-less configurations of Boost Exception, the library I'm maintaining, are tested only by me on my own computer, and I'm only testing them with MSVC and a single version of linux/gcc. Shouldn't the automatic trunk/release tests handle these, as well as other supported configurations?
I guess what I'm saying is, I can make a patch to make boost::function work without RTTI, but I'm certainly not up to running those tests too. :)
I'm sure you can teach bjam to build a test using the appropriate extra flags for each compiler, but I don't recall how to do so. Then we could put that test in with the rest of Boost.Function's tests.
Yes that's how I do it :) but I do not want to be running -fno-rtti tests for boost::function on a regular basis. Also consider that disabling RTTI comes in two flavors, since on MSVC static typeid is available even when RTTI is disabled.
This ought to be part of all Boost testing, provided that the Boost community cares about -fno-rtti (I can say this the other way around too, if we're not testing the no-RTTI configuration of Boost, then we don't care about that configuration.)
You can specify that RTTI be turned off for a single test, so that we can test boost::function with -fno-rtti even when the test runner typically has RTTI enabled. - Doug
Emil Dotchevski wrote:
This ought to be part of all Boost testing, provided that the Boost community cares about -fno-rtti (I can say this the other way around too, if we're not testing the no-RTTI configuration of Boost, then we don't care about that configuration.)
In reality, the total number of build combinations far exceeds anyone's ability to test them all. Possible attributes are wchar exits or not rtti exists or not dynamic vs static C++ runtime dynamic vs static library version debug vs release optimisations platform supports throw or not version of STL being used (stlport, built in or ?) I'm sure there a lot more. However you look at it, the number of possible combinations is too large to test them all a head of time. What is really needed is a way for customers (whoops users) a) install the system b) run the tests on the libraries he plans to use with the attributes/options he wants. a) is addressed via the bjam install. b) b could be addressed just be upgrading the documentation on how to do this. My prefered method of doing this is described in the library status/test description. I don't know if there is anyway to find this through the boost documention page. Users should be encourged to run the tests when they install and report any issues. This should be part of the installation procedure. Robert Ramey
On Thu, Jan 8, 2009 at 11:15 AM, Robert Ramey <ramey@rrsd.com> wrote:
Users should be encourged to run the tests when they install and report any issues. This should be part of the installation procedure.
That's a good idea provided that the tests run automatically (allowing an opt-out.) The problem I suppose is that most users simply download the binaries. The mostly header-only nature of Boost also encourages this behavior. I don't blame them, it isn't trivial to get the build up and running. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
Emil Dotchevski wrote:
On Thu, Jan 8, 2009 at 11:15 AM, Robert Ramey <ramey@rrsd.com> wrote:
Users should be encourged to run the tests when they install and report any issues. This should be part of the installation procedure.
That's a good idea provided that the tests run automatically (allowing an opt-out.)
I would be a little less insistent - Just upgrading the documentation to suggest that running the tests/demos is a normal part of every software installation and boost is no exception.
The problem I suppose is that most users simply download the binaries. The mostly header-only nature of Boost also encourages this behavior. I don't blame them, it isn't trivial to get the build up and running.
This is indeed the main obstacle. Thinking about this a little more - maybe it's not so bad. My personal procedure for dealing with boost is exemplified with the library_test shell script/bat files and library_test executable which are already part of boost. I realize that they ar not widely used (if at all) by anyone other than myself - but I think they should be. These are very "thin" scripts and one executable. When I run this script from within any lib/<library name>/test, the following happens. a) bjam is invoked for the tests in the library. b) following bjam rules, all dependent libraries are built c) the libraries tests are run. d) a browsable html test results table is built in the lib/<library name>/test directory. I would like to see this developed into the "officially suggested" boost way of doing things. This would have the following advantages: a) build would be faster for those only using a few libraries. Currently, the build time is constantly increasing since boost itself is constantanly getting bigger. That is, the current build doesn't scale. b) Tests would be automatically run in the users environment. Only those tests relevant to the particular user would actually be run. c) It leverages on current boost procedures - i.e. bjam. d) I would help move boost in the direction of "a collection of orthogonal libraries" rather than "a collection of interdependent libraries". Boost is and should be the former, but the tools (monilithic giant build, install and test, monilithic documentation build, etc. suggest the latter. Robert Ramey
participants (3)
-
Doug Gregor -
Emil Dotchevski -
Robert Ramey