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

From: Robert Dailey (rcdailey_at_[hidden])
Date: 2008-03-27 20:33:54

On Thu, Mar 27, 2008 at 7:20 PM, David Abrahams <dave_at_[hidden]>
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_at_[hidden]>
> > 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.