Boost logo

Boost-Build :

Subject: Re: [Boost-build] Call of interest
From: Vladimir Prus (vladimir_at_[hidden])
Date: 2009-05-27 00:46:36


Konstantin Litvinenko wrote:

> Hi All!

Hi Konstantin,

thanks for sharing these with us!
 
> First of all I want to say thank you for so great build tool - Boost
> Build v2. I went all path from BBv1 to BBv2 and using BBv2 all the time.
> The concept on witch BBv2 relays is really rocks! But... There is
> always but... 1) Jam language is strange beast and all BBv2 code base is
> hard to understand and extend in the way I was needed; 2) Speed. It is
> terrible on huge projects. My current projects each consists of 30-50
> sub-projects. It takes 30 second for no-op build on my Core2Duo. It is
> too much for edit/compile/run/debug cycles.
> So I decide to start my own project that would be based on BBv2
> concepts but be much faster than BBv2. I decided to write it on c++
> because my goal was fast edit/compile cycles and I don't know Python :).
> For that time I knew about BBv2 Python Port and 'rewrite Jam in C++'
> projects. Both was rejected because they doesn't solve one of my goal -
> clean and precise error messages from build system.

Can you show example error messages from your system?

> It takes huge amount of time to produce something usable, but now I
> think Hammer, as I call it, is more or less ready to go in the wild.
> Here is main highlights:
>
> * build script syntax very close to Jam, but without any control flow
> statements. Only declarative rules. No variable declaration;
>
> * borrowed exe, obj, lib and others target declaration. Undistinguished
> from BBv2 declarations;
>
> * borrowed project hierarchy concept from BBv2. Requirements and usage
> requirements propagates down to sub-projects in filesystem;
>
> * different usage requirement propagation behavior - apply only to
> direct dependencies;
>
> * public and internal sources - with new usage requirement this allows
> to mix different library version in build the without conflicts
> lib a : /boost/thread/<version>1.36.0 ;
> lib b : @a /boost/thread/<version>1.39.0 ;
> will compile and run on Windows. On Unix this is problematic because
> of ld machinery. But in c++0x with inlined namespaces this problem will
> gone;
>
> * builtin SCM support. I design Hammer to be able to fetch all needed
> projects from SCM in single build shot. You may start with only one
> hamfile(named as good old jamfile :) ) and do 'hammer /hammer/driver -i'
> - this will fetch all projects that needed for building hammer driver
> from the svn repository - about 40 modularized boost libraries,
> libantlr3c and hammer sources. Now it can work with svn only;
>
> * Hammer can generate Visual Studio 2005 projects and solution files.
> There is no limits in IDE projects generation, just no one write nothing
> else :);

So, is your system generating build description for other underlying tools?
>From the description above I gather that "no", but then I am not sure
what generated IDE projects contain/do.

> * Hammer is really fast. On the same project no-op build:
> BBv2 - 30 seconds
> Hammer - less than a second
> With huge amount of headers and sources it may take more time, but
> theoretically and practically its solvable problem;
>
> For now Hammer code base is full of hack/bugs/memleaks and all others
> nongood things. It has conceptually broken frontend because I made it
> just to somehow push the work further to have working prototype. But
> backend is more or less stable and clean. For now it can be easily build
> on Windows. It can work only with msvc-8.0 toolset. I has successfully
> build it on Linux and soon provide some rpm to play with it.

Do you have a custom build engine (the thing that decides what has to
be rebuilt, and what not). Is that engine capable of rescanning
header dependencies in a file that is itself generated during build process?
Does it have unit tests? Can it be easily modified to support signatures
(both for file content and for the updating commands)?

Thanks,
Volodya


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