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.