Boost logo

Boost-Build :

Subject: Re: [Boost-build] Use BB to generate visual studio projects?
From: Phillip Seaver (phil_at_[hidden])
Date: 2010-04-19 12:19:57


On 4/19/10 11:29 AM, Christian Holmquist wrote:
> On 17 April 2010 02:42, Vladimir Prus <ghost_at_[hidden]
> <mailto:ghost_at_[hidden]>> wrote:
>
> Konstantin Litvinenko wrote:
>
> Christian Holmquist пишет:
>
> Has anyone done any work on such a thing, to generate a vc
> project file
> that corresponds to what actually gets built from a
> Jamfile, would it
> even be possible?
>
>
> As I know there is no such thing and no one working on it.
> I think it is possible to do such generator for BB, but some
> time ago I was not able to develop it, due to lack of
> understanding of overall design. Even now, when I build
> BB-like clone in pure C++ and know how design works, I doubt
> to be able to write MSVC project generator for BB. May be when
> PythonBB will arrive somebody write one...
>
> Any ideas on where to start if I wanted to hack on such a
> thing? I'm not
> too familiar with BB, but I'd be willing to study it a bit
> if you think
> there's a solution within reach =)
>
>
> If you *really* need MSVC project files than CMake may be
> alternative.
> Or you may to try my project Hammer - its very close to BBv2
> syntax/design and capable to produce MSVC 2005 project files.
> If you interested email me :).
>
>
> It seems to me that a better approach would be to create
> Boost.Build add-in for
> Visual Studio, so that you can actually interact with Boost.Build
> project
> description, as opposed to just building things.
>
>
> One of the reasons for using the IDE, is that it's significantly
> faster to compile with. Running bjam on a project (even with only one
> .cpp test file) which depends on a couple of compiled boost libs
> (serialization, thread, system), takes very, very long time. I'm
> probably doing something wrong, and I actually wonder how people work
> with bjam in practice. To me, it spends too much time in dependency
> analysis.
> Another reason for the IDE to know about all my files involved, is to
> allow other crucial tools such as Incredibuild and Visual Assist to do
> their work. Without them, my efficiency is about zero nowadays.

I have been creating "makefile projects" for each of my libraries and
programs -- they build by calling bjam, like "bjam
-j$(NUMBER_OF_PROCESSORS) msvc-8.0 debug" ("NUMBER_OF_PROCESSORS" is an
environment variable defined by XP, and the other parts are there so it
always uses the matching compiler for the project file). It's slower
than a VS build would be, but it's much more reliable than our old
system of makefiles and VS projects.

Visual Assist is a very useful product -- it definitely increases my
productivity. I also added the files (and include paths, if necessary)
to the makefile projects. Then I just add each used project to the
solution for the executable, and VA works very well.

> Here's what would be optimal to me
> 1) BB always contains the 'master' project, there are no visible
> vcproj files in the SCM.
> 2) When about to work on some project, generate the vcproj files for
> that project, and optionally for all projects (that needs compilation)
> it depends on.
> 3) When done, submit cpp, hpp and jam files, and throw away the vcproj
> files.
>
> (I looked briefly at CMake btw, but it didn't look anyway near as
> compact as BB)
>
> / Christian

Yeah, something like that would be very useful to me, too. It would
make one of my co-workers stop complaining about the build time, for one
thing. :-)

I suspect it's just not worth it to most people who know enough to do
it. They'd probably rather work on features that would be useful to
everyone, like the python port and the configuration stuff. I've been
wanting to try to do something, but I've been too busy. Maybe I'll see
if I can get my boss to let me work on it a little bit each day...

Phillip


Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk