Boost logo

Boost :

From: David Abrahams (dave_at_[hidden])
Date: 2008-03-27 20:20:25


on Thu Mar 27 2008, "Robert Dailey" <rcdailey-AT-gmail.com> wrote:

> 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.

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

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk