I see that the implementation of type_id is chock full of special code. There appears to be so much difference between how compilers handle stuff (the shared lib problem documented in the header is especially disturbing). However, this does not seem to be isolated just to using Boost.Python, so is it possible to have it moved somewhere else more common, like boost/type_id.hpp or something similar which makes it more widely available? Thanks!
Jody Hagins wrote:
I see that the implementation of type_id is chock full of special code. There appears to be so much difference between how compilers handle stuff (the shared lib problem documented in the header is especially disturbing).
However, this does not seem to be isolated just to using Boost.Python, so is it possible to have it moved somewhere else more common, like boost/type_id.hpp or something similar which makes it more widely available?
The way these things are handled is as follows: if another Boost library wants to use facilities that are an implementation detail of an existing Boost library, they are moved into boost/detail by the author of the former library. If someone wants to make the functionality available to users, that person moves it into namespace boost, documents it, and writes tests. Then the library goes through a fast-track review process. I'm happy to have either of those things happen to that code, but I'm not volunteering to do any of the work ;-) -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
On Sat, 15 Jan 2005 16:50:07 -0500 David Abrahams <dave@boost-consulting.com> wrote:
The way these things are handled is as follows: if another Boost library wants to use facilities that are an implementation detail of an existing Boost library, they are moved into boost/detail by the author of the former library. If someone wants to make the functionality available to users, that person moves it into namespace boost, documents it, and writes tests. Then the library goes through a fast-track review process.
I'm happy to have either of those things happen to that code, but I'm not volunteering to do any of the work ;-)
OK, in some spare moments, I am making an attempt. However, I seem to have run into many minor issues. The first is that I can not reproduce your documented problems with comparisons being wrong from shared libraries. My compiler triggers the workaround. However, when I explicitly remove the workaround, my tests still pass. Do you have any tests that demonstrate this is broken behavior? Here is what I have tried... namespace shlibdetail { extern boost::type_info int_; extern boost::type_info get_int_(); extern boost::type_info * get_int_ptr(); } void test_shlib() { boost::type_info int_ = boost::type_id<int>(); BOOST_CHECK(int_ == shlibdetail::int_); BOOST_CHECK(int_ == shlibdetail::get_int_()); BOOST_CHECK(int_ == *shlibdetail::get_int_ptr()); } where the code for the shlib is... #include "boost/type_id.hpp" namespace shlibdetail { boost::type_info int_ = boost::type_id<int>(); boost::type_info get_int_() { return boost::type_id<int>(); } boost::type_info const * get_int_ptr() { static boost::type_info * ptr; if (ptr == 0) { ptr = new boost::type_info(boost::type_id<int>()); } return ptr; } } // end detail namespace
Jody Hagins <jody-boost-011304@atdesk.com> writes:
On Sat, 15 Jan 2005 16:50:07 -0500 David Abrahams <dave@boost-consulting.com> wrote:
The way these things are handled is as follows: if another Boost library wants to use facilities that are an implementation detail of an existing Boost library, they are moved into boost/detail by the author of the former library. If someone wants to make the functionality available to users, that person moves it into namespace boost, documents it, and writes tests. Then the library goes through a fast-track review process.
I'm happy to have either of those things happen to that code, but I'm not volunteering to do any of the work ;-)
OK, in some spare moments, I am making an attempt. However, I seem to have run into many minor issues.
The first is that I can not reproduce your documented problems with comparisons being wrong from shared libraries. My compiler triggers the workaround. However, when I explicitly remove the workaround, my tests still pass.
Do you have any tests that demonstrate this is broken behavior?
You may need to reproduce the scenario that occurs in Boost.Python. Two shared C++ libraries (extension modules) are loaded by the application with dlopen. Each of these libraries links dynamically in the ordinary way to the same C++ library (Boost.Python). You can reproduce the problem by running bjam try in libs/python/test -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
You may need to reproduce the scenario that occurs in Boost.Python. Two shared C++ libraries (extension modules) are loaded by the application with dlopen. Each of these libraries links dynamically in the ordinary way to the same C++ library (Boost.Python).
You can reproduce the problem by running
bjam try
in
libs/python/test I am sorry, Dave. However, I can not get it to build (probably because I do not understand anything about jam). When I try to build out of
On Thu, 20 Jan 2005 14:57:25 -0500 David Abrahams <dave@boost-consulting.com> wrote: that directory, I get all kinds of errors. Here is how I build from the root... cd ${BOOST_ROOT} bjam -sTOOLS=gcc --builddir=/home/jody/src/boost/bin --stagedir=/home/jody/src/boost/bin --with-python-root=/usr stage and this builds everything and puts it into the stage directory (and then I used that directory as the place to keep the libs). However, if I try to execute the same command in the lower directory... cd ${BOOST_ROOT}/libs/python/test bjam -sTOOLS=gcc --builddir=/home/jody/src/Borg/HEAD/boost/bin --with-python-root=/usr try I get the following errors... --------------------------------------------------------------------- skipping Boost.Python library build due to missing or incorrect configuration couldn't find Python.h in "/usr/local/include/python2.2" You can configure the location of your python installation by setting: PYTHON_ROOT - currently "/usr/local" PYTHON_VERSION - The 2-part python Major.Minor version number (e.g. "2.2", NOT "2.2.1") - currently "2.2" The following are automatically configured from PYTHON_ROOT if not otherwise set: PYTHON_LIB_PATH - path to Python library object; currently "/usr/local/lib/python2.2/config" PYTHON_INCLUDES - path to Python #include directories; currently "/usr/local/include/python2.2" --------------------------------------------------------------------- don't know how to make try ...found 1 target... ...can't find 1 target...
On Thu, 20 Jan 2005 19:30:49 -0500 Jody Hagins <jody-boost-011304@atdesk.com> wrote:
I am sorry, Dave. However, I can not get it to build (probably because I do not understand anything about jam). When I try to build out of that directory, I get all kinds of errors. Here is how I build from the root...
While I would like to know more details so that I can build in subdirs, I have now been able to duplicate the "problem" on my compiler (which is "supposed" to be broken). Thanks!
Jody Hagins <jody-boost-011304@atdesk.com> writes:
I am sorry, Dave. However, I can not get it to build (probably because I do not understand anything about jam). When I try to build out of that directory, I get all kinds of errors. Here is how I build from the root...
cd ${BOOST_ROOT} bjam -sTOOLS=gcc --builddir=/home/jody/src/boost/bin --stagedir=/home/jody/src/boost/bin --with-python-root=/usr stage
and this builds everything and puts it into the stage directory (and then I used that directory as the place to keep the libs).
However, if I try to execute the same command in the lower directory...
cd ${BOOST_ROOT}/libs/python/test bjam -sTOOLS=gcc --builddir=/home/jody/src/Borg/HEAD/boost/bin --with-python-root=/usr try
I get the following errors...
--with-python-root only works from the Boost root directory when you build for installation. Follow the instructions at http://www.boost.org/libs/python/building.html or given explicitly in the error message below for configuration.
--------------------------------------------------------------------- skipping Boost.Python library build due to missing or incorrect configuration
couldn't find Python.h in "/usr/local/include/python2.2"
You can configure the location of your python installation by setting: PYTHON_ROOT - currently "/usr/local" PYTHON_VERSION - The 2-part python Major.Minor version number (e.g. "2.2", NOT "2.2.1") - currently "2.2"
The following are automatically configured from PYTHON_ROOT if not otherwise set:
PYTHON_LIB_PATH - path to Python library object; currently "/usr/local/lib/python2.2/config" PYTHON_INCLUDES - path to Python #include directories; currently "/usr/local/include/python2.2" ---------------------------------------------------------------------
-- Dave Abrahams Boost Consulting www.boost-consulting.com
On Sat, 15 Jan 2005 16:50:07 -0500 David Abrahams <dave@boost-consulting.com> wrote:
The way these things are handled is as follows: if another Boost library wants to use facilities that are an implementation detail of an existing Boost library, they are moved into boost/detail by the author of the former library. If someone wants to make the functionality available to users, that person moves it into namespace boost, documents it, and writes tests. Then the library goes through a fast-track review process.
I have done this, but there is a compilation unit, to do the "pretty" printing. Thus, I see several options, and would like some input. Currently, there is no Boost.Utility compiled library, but I think the type_id stuff fits into Utility better than anything else. It does not seem to be its own library since it is providing utility access and workaround for the typeid facility. If there were a libutility, then I'd just add it there... Also, Dave suggested that it be moved into a detail namespace, but I think it is useful as a general library, not an implementaion detail (which I believe is the purpose of the detail namespace). So, I'd like to have it available as boost::type_id. 1. Move the code that is currently compiled into a library into a .hpp file, thus preventing the need for a compiled library. 2. Start a "utility" library, with this as the first entry. 3. Start a "catchall/common" library, with this as the first entry. 4. Provide a separate "type_id" library with this one entry. In the process of writing the tests for the type_id code, I had to do some shared library work. Since there is nothing in boost for this already, I also wrote a DLL library (which I think *should* be it's own library -- though it does not require an explicit compiled library -- it is all in headers). Would the DLL library be on the same fast-track for type_id, or would we need to first wait for the DLL to get type_id done? FWIW, everyone should try to go through something small like this, if for no other reason than to appreciate the vast amount of effort involved in the entire process... especially learning the build environment, getting code to work on non-conforming compilers, and writing reasonable tests. Even so, when I present the modified code, I have issues myself to raise (as if that were not obvious by now ;-). Anyway, thanks to everyone for much patience, and very little scorn...
Jody Hagins <jody-boost-011304@atdesk.com> writes:
Currently, there is no Boost.Utility compiled library, but I think the type_id stuff fits into Utility better than anything else. It does not seem to be its own library since it is providing utility access and workaround for the typeid facility. If there were a libutility, then I'd just add it there...
I don't think we should be glomming any new stuff into utility, and we definitely shouldn't build a monolithic library for all the utility code. I believe typeid makes sense as a separate library.
Also, Dave suggested that it be moved into a detail namespace, but I think it is useful as a general library, not an implementaion detail (which I believe is the purpose of the detail namespace). So, I'd like to have it available as boost::type_id.
1. Move the code that is currently compiled into a library into a .hpp file, thus preventing the need for a compiled library. 2. Start a "utility" library, with this as the first entry. 3. Start a "catchall/common" library, with this as the first entry. 4. Provide a separate "type_id" library with this one entry.
#4 sounds good to me.
In the process of writing the tests for the type_id code, I had to do some shared library work. Since there is nothing in boost for this already, I also wrote a DLL library (which I think *should* be it's own library -- though it does not require an explicit compiled library -- it is all in headers). Would the DLL library be on the same fast-track for type_id, or would we need to first wait for the DLL to get type_id done?
Technically, DLL would have to remain a not-officially-documented implementation detail of typeid DLL is separately fast-track reviewed, unless we are somehow going to fast-track review them together.
FWIW, everyone should try to go through something small like this, if for no other reason than to appreciate the vast amount of effort involved in the entire process... especially learning the build environment, getting code to work on non-conforming compilers, and writing reasonable tests. Even so, when I present the modified code, I have issues myself to raise (as if that were not obvious by now ;-). Anyway, thanks to everyone for much patience, and very little scorn...
i'm-from-new-jersey-we-like-sweet-corn-ly y'rs, -- Dave Abrahams Boost Consulting www.boost-consulting.com
participants (2)
-
David Abrahams -
Jody Hagins