Re: [Boost-build] [BULK] Re: Sharing is caring: Visual Studio ->bjam

From: Johan Nilsson (r.johan.nilsson_at_[hidden])
Date: 2006-06-15 05:39:41

Sohail Somani wrote:
>> -----Original Message-----
>> From: boost-build-bounces_at_[hidden]
>> [mailto:boost-build-bounces_at_[hidden]] On Behalf Of
>> Johan Nilsson
>> Sent: Wednesday, June 14, 2006 6:34 AM
>> To: boost-build_at_[hidden]
>> Subject: [BULK] Re: [Boost-build] Sharing is caring: Visual
>> Studio -> bjam
>> Importance: Low
>>
>> Sohail Somani wrote:
>>> Hi,
>>>
>>> Would anyone care to share their experiences on replacing Visual
>>> Studio
>>> with bjam for a medium sized project? Maybe what you appreciate or
>>> miss?
>>> I have my pros column already :)
>>
>> There are many pros for using bjam, but one of the reasons I
>> still use
>> redundant VC projects is recompilation speeds.
>>
>> // Johan
>>
>> P.S. The bjam IDE isn't so hot either ;-)
>
> Really? You find bjam recompilation to be slower than Visual Studio?

Yes. For a rather smallish solution (library + test project), a debug 
recompilation (including running of tests) after touching one of the library 
source files took 5 seconds in VS and 15 seconds using bjam. I know this is 
largely dependent on project settings, but this is for the typical settings 
I use.

For full rebuilds (ckean followed by build), bjam were faster (largely 
thanks to parallel building):

bjam: 1:43
bjam -j4: 0:42
VS.NET 2005: 2:05

Note: I did not use precompiled headers in the VC projects.
Note: VS.NET 2005 does support parallel builds, but only to a certain extent 
(different projects are assigned to different CPUs).

>
> By the way, its not so difficult to set up VS.NET to use bjam as the
> build tool. You have to use a makefile project setting.

I know, but that's not the issue. Apart from the speed issue, I also like 
the way I only have to click enter to get to the failing test case after the 
integrated tests are complete. But that's like comparing apples and oranges 
as bjam is not an IDE.

If recompilation speeds were as quick using bjam as in native VS projects, 
I'd probably only use makefile projects (with an exception for small 
projects with no portability requirements).

The bjamd idea mentioned in another post would probably be a great 
addition - monitoring the dependencies for changes. Adds complexity though.

>
> The only reason I would use the redundant Visual Studio projects is
> for
> the guess and click interface, mainly to easily navigate the project
> files... Would be much easier if they allowed you to recursively add
> folders, but of course no one wants to do that.

Folders within folders, solutions within solutions - it's supported under 
VS.NET 2005.

// Johan