[Boost-build] Call of interest

Subject: [Boost-build] Call of interest
From: Konstantin Litvinenko (to.darkangel_at_[hidden])
Date: 2009-05-26 16:16:41

Hi All!

        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.
        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 :);

* 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.
        I write all this because I need help. And I post here because that is a 
place where all BBv2 users and designers can be found. I hope my project 
will be interesting to them.
        I think that such a tool is really need in c/c++ world. It can make 
library development and library users really happy. No more debates 
'header only vs non header only'. No more 'how to/I can't build 
boost.regex' and so on. C++ is really suffer from good libs and good 
libs suffer from cooperation between each others. In Linux world you can 
download tar.gz unpack and do ./configure && make && make install. But 
what about Windows? There is no single and easy way to use, say libxml2.

        I have registered project on sourceforge.net at

https://sourceforge.net/projects/buildhammer

and put Windows binary installation in Download section. The project has 
mailing list that can be reached at gmane.org, group name

gmane.comp.programming.tools.hammer.user

or you can write directly to me.

Thanks for your time.