[python] DSW project fails to link
Hi, When compiling Boost.Python using the *.dsw visual studio project file in the boost/libs/python/build directory, the project fails to link. Note that I've converted this project to a Visual Studio 9 project. Below are the linker errors: 1>Linking... 1> Creating library .\../bin-stage/boost_python_debug.lib and object .\../bin-stage/boost_python_debug.exp 1>function.obj : error LNK2001: unresolved external symbol "char * boost::python::objects::detail::cpp_signature_tag" (?cpp_signature_tag@ detail@objects@python@boost@@3PADA) 1>function.obj : error LNK2001: unresolved external symbol "char * boost::python::objects::detail::py_signature_tag" (?py_signature_tag@ detail@objects@python@boost@@3PADA) 1>function.obj : error LNK2019: unresolved external symbol "public: static class boost::python::list __cdecl boost::python::objects::function_doc_signature_generator::function_doc_signatures(struct boost::python::objects::function const *)" (?function_doc_signatures@ function_doc_signature_generator@objects@python@boost@@SA?AVlist@34@ PBUfunction@234@@Z) referenced in function _function_get_doc 1>../bin-stage/boost_python_debug.dll : fatal error LNK1120: 3 unresolved externals 1>Build Time 0:00 1>boost_python - 4 error(s), 0 warning(s)
On Thu, Mar 27, 2008 at 4:04 PM, Robert Dailey <rcdailey@gmail.com> wrote:
Hi,
When compiling Boost.Python using the *.dsw visual studio project file in the boost/libs/python/build directory, the project fails to link. Note that I've converted this project to a Visual Studio 9 project. Below are the linker errors:
1>Linking... 1> Creating library .\../bin-stage/boost_python_debug.lib and object .\../bin-stage/boost_python_debug.exp 1>function.obj : error LNK2001: unresolved external symbol "char * boost::python::objects::detail::cpp_signature_tag" (?cpp_signature_tag@ detail@objects@python@boost@@3PADA) 1>function.obj : error LNK2001: unresolved external symbol "char * boost::python::objects::detail::py_signature_tag" (?py_signature_tag@ detail@objects@python@boost@@3PADA) 1>function.obj : error LNK2019: unresolved external symbol "public: static class boost::python::list __cdecl boost::python::objects::function_doc_signature_generator::function_doc_signatures(struct boost::python::objects::function const *)" (?function_doc_signatures@ function_doc_signature_generator@objects@python@boost@@SA?AVlist@34@ PBUfunction@234@@Z) referenced in function _function_get_doc 1>../bin-stage/boost_python_debug.dll : fatal error LNK1120: 3 unresolved externals 1>Build Time 0:00 1>boost_python - 4 error(s), 0 warning(s)
Well I just figured out the problem, I should have found this before I posted, but at least it can be fixed in the repository now: Simply add "boost\libs\python\src\object\function_doc_signature.cpp" to the Visual Studio project. I would also like to suggest at this time that you upgrade the project to a VS9 project if possible!
Robert Dailey wrote:
On Thu, Mar 27, 2008 at 4:04 PM, Robert Dailey <rcdailey@gmail.com> wrote:
Hi,
When compiling Boost.Python using the *.dsw visual studio project file in the boost/libs/python/build directory, the project fails to link. Note that I've converted this project to a Visual Studio 9 project. Below are the linker errors:
1>Linking...
<znipp>
Well I just figured out the problem, I should have found this before I posted, but at least it can be fixed in the repository now:
Simply add "boost\libs\python\src\object\function_doc_signature.cpp" to the Visual Studio project. I would also like to suggest at this time that you upgrade the project to a VS9 project if possible!
Would you like to take over maintenance of this VS project? The maintainer dropped out of sight, and I am inclined to remove it from the next release if someone doesn't pick up the maintenance responsibilities.
On Thu, Mar 27, 2008 at 5:24 PM, David Abrahams <dave@boost-consulting.com> wrote:
On Thu, Mar 27, 2008 at 4:04 PM, Robert Dailey <rcdailey@gmail.com> wrote:
Hi,
When compiling Boost.Python using the *.dsw visual studio project file in the boost/libs/python/build directory, the project fails to link. Note
Robert Dailey wrote: that
I've converted this project to a Visual Studio 9 project. Below are the linker errors:
1>Linking...
<znipp>
Well I just figured out the problem, I should have found this before I posted, but at least it can be fixed in the repository now:
Simply add "boost\libs\python\src\object\function_doc_signature.cpp" to
the
Visual Studio project. I would also like to suggest at this time that you upgrade the project to a VS9 project if possible!
Would you like to take over maintenance of this VS project? The maintainer dropped out of sight, and I am inclined to remove it from the next release if someone doesn't pick up the maintenance responsibilities.
I would love to do it, however I am wondering what responsibilities are we talking about here. If it is in regards to keeping files up-to-date in the project (e.g. adding files when new files are made, removing files when files are deleted), that sounds simple enough. Would you expect me to run test builds in the Visual Studio project every now and then to ensure it still compiles? (I would probably do this anyhow; it's an obvious requirement). One of the major problems I would try to solve is automating the process of the Visual Studio project locating the python include directory as well as the python library directory, since as of right now anyone using the visual studio project for Boost.Python is required to modify a bunch of project settings before they can even begin to compile it (which entirely defeats the purpose of the VS project in the first place, as one would expect it to require LESS steps than the bjam build process, not MORE). Another issue is the fact that Python, by default, does not come with a debug distribution of their libraries, so that's yet another dependency that prevents the Visual Studio project from being fully automated and convenient. Anyway, these are all problems I would want to solve if I were in control of it, but yet again these are all subject to what boost requires (Some of the problems above are seemingly unsolvable, given the fact that the python installation directory is ultimately dynamic). I do find it odd that Boost.Python is the only boost component I see that even has a visual studio project. If you could provide me some details on the job proposal I would be more inclined to accept :) On the other hand, I would have no problems with you eliminating the VS project too. You see, the only reason I am using it now is because a library I'm using depends on the Boost.Python libs being built in that specific fashion. If it had not existed in the first place things would have been a lot more convenient and consistent (we'd be using the bjam versions), as the library I'm using would have obviously not had the option to use the visual studio project.
on Thu Mar 27 2008, "Robert Dailey" <rcdailey-AT-gmail.com> wrote:
On Thu, Mar 27, 2008 at 5:24 PM, David Abrahams <dave@boost-consulting.com> wrote:
On Thu, Mar 27, 2008 at 4:04 PM, Robert Dailey <rcdailey@gmail.com> wrote:
Hi,
When compiling Boost.Python using the *.dsw visual studio project file in the boost/libs/python/build directory, the project fails to link. Note
Robert Dailey wrote: that
I've converted this project to a Visual Studio 9 project. Below are the linker errors:
1>Linking...
<znipp>
Well I just figured out the problem, I should have found this before I posted, but at least it can be fixed in the repository now:
Simply add "boost\libs\python\src\object\function_doc_signature.cpp" to
the
Visual Studio project. I would also like to suggest at this time that you upgrade the project to a VS9 project if possible!
Would you like to take over maintenance of this VS project? The maintainer dropped out of sight, and I am inclined to remove it from the next release if someone doesn't pick up the maintenance responsibilities.
I would love to do it, however I am wondering what responsibilities are we talking about here. If it is in regards to keeping files up-to-date in the project (e.g. adding files when new files are made, removing files when files are deleted), that sounds simple enough.
Whatever it takes to keep the project working.
Would you expect me to run test builds in the Visual Studio project every now and then to ensure it still compiles? (I would probably do this anyhow; it's an obvious requirement).
Again, whatever it takes to keep the project working ;-)
One of the major problems I would try to solve is automating the process of the Visual Studio project locating the python include directory as well as the python library directory, since as of right now anyone using the visual studio project for Boost.Python is required to modify a bunch of project settings before they can even begin to compile it (which entirely defeats the purpose of the VS project in the first place, as one would expect it to require LESS steps than the bjam build process, not MORE). Another issue is the fact that Python, by default, does not come with a debug distribution of their libraries, so that's yet another dependency that prevents the Visual Studio project from being fully automated and convenient.
You can get a debug build from ActiveState.
Anyway, these are all problems I would want to solve if I were in control of it, but yet again these are all subject to what boost requires (Some of the problems above are seemingly unsolvable, given the fact that the python installation directory is ultimately dynamic). I do find it odd that Boost.Python is the only boost component I see that even has a visual studio project.
If you could provide me some details on the job proposal I would be more inclined to accept :)
Really, I haven't had too many requirements. It sounds like you're willing to take more responsibility for the VS project than anyone else has in the past, so that's enough for me.
On the other hand, I would have no problems with you eliminating the VS project too. You see, the only reason I am using it now is because a library I'm using depends on the Boost.Python libs being built in that specific fashion. If it had not existed in the first place things would have been a lot more convenient and consistent (we'd be using the bjam versions), as the library I'm using would have obviously not had the option to use the visual studio project.
Well, it's totally up to you, then. Either someone picks up maintenance, or I'll remove it. :-) Beman, I hope it's not too late to remove this unmaintained VS project from 1.35 if we decide to do that. -- Dave Abrahams Boost Consulting http://boost-consulting.com
On Thu, Mar 27, 2008 at 7:20 PM, David Abrahams <dave@boost-consulting.com> wrote:
on Thu Mar 27 2008, "Robert Dailey" <rcdailey-AT-gmail.com> wrote:
On Thu, Mar 27, 2008 at 5:24 PM, David Abrahams < dave@boost-consulting.com> wrote:
I would love to do it, however I am wondering what responsibilities are we talking about here. If it is in regards to keeping files up-to-date in the project (e.g. adding files when new files are made, removing files when files are deleted), that sounds simple enough.
Whatever it takes to keep the project working.
Would you expect me to run test builds in the Visual Studio project every now and then to ensure it still compiles? (I would probably do this anyhow; it's an obvious requirement).
Again, whatever it takes to keep the project working ;-)
One of the major problems I would try to solve is automating the process of the Visual Studio project locating the python include directory as well as the python library directory, since as of right now anyone using the visual studio project for Boost.Python is required to modify a bunch of project settings before they can even begin to compile it (which entirely defeats the purpose of the VS project in the first place, as one would expect it to require LESS steps than the bjam build process, not MORE). Another issue is the fact that Python, by default, does not come with a debug distribution of their libraries, so that's yet another dependency that prevents the Visual Studio project from being fully automated and convenient.
You can get a debug build from ActiveState.
Anyway, these are all problems I would want to solve if I were in control of it, but yet again these are all subject to what boost requires (Some of the problems above are seemingly unsolvable, given the fact that the python installation directory is ultimately dynamic). I do find it odd that Boost.Python is the only boost component I see that even has a visual studio project.
If you could provide me some details on the job proposal I would be more inclined to accept :)
Really, I haven't had too many requirements. It sounds like you're willing to take more responsibility for the VS project than anyone else has in the past, so that's enough for me.
On the other hand, I would have no problems with you eliminating the VS project too. You see, the only reason I am using it now is because a library I'm using depends on the Boost.Python libs being built in that specific fashion. If it had not existed in the first place things would have been a lot more convenient and consistent (we'd be using the bjam versions), as the library I'm using would have obviously not had the option to use the visual studio project.
Well, it's totally up to you, then. Either someone picks up maintenance, or I'll remove it. :-)
Beman, I hope it's not too late to remove this unmaintained VS project from 1.35 if we decide to do that.
I think the only reason I would take up this responsibility right now is because the fact that I would be contributing to such a large, popular, and fantastic library. The thought alone is really motivating! However, I wouldn't want that to be the only reason. I would want what I'm working on to be useful to the community. Right now, we have 2 build processes for Boost.Python, which is unacceptable IMHO (it's one of those things that makes maintenance a nightmare). There's no reason to not use the output from bjam when you're getting that output anyway for free just by building the other libraries. So, unless someone really wants the VS project to stay alive (besides me), then I think it is better off for management purposes for it to just die. However, if you decide *not* to remove it for some reason in the future and you need someone to maintain it, count me in! Again, the only reason why I don't care so much at the moment is because it is practically redundant in regards to what bjam already does. Keep in touch, however, if you need me to work on it.
participants (2)
-
David Abrahams -
Robert Dailey