Re: [boost] [python] DSW project fails to link

From: Robert Dailey (rcdailey_at_[hidden])
Date: 2008-03-27 18:55:45

On Thu, Mar 27, 2008 at 5:24 PM, David Abrahams <dave_at_[hidden]>
wrote:

> Robert Dailey wrote:
> > On Thu, Mar 27, 2008 at 4:04 PM, Robert Dailey <rcdailey_at_[hidden]>
> 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.

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.