Subject: Re: [Boost-build] Call of interest
From: Vladimir Prus (ghost_at_[hidden])
Date: 2009-05-27 03:27:29
On Wednesday 27 May 2009 10:56:36 Konstantin Litvinenko wrote:
> Vladimir Prus Ð¿Ð¸ÑÐµÑ:
> >> clean and precise error messages from build system.
> > Can you show example error messages from your system?
> :) I expect that question. By design I want to do the follow: 1) Parse
> to tokens 2) Build AST 3) build backend representation. Because I
> concentrate on backend, frontend print error messages as bad as BBv2 do
> :), may be even worser :(. But this is due I have no time to do all
> these stages in a right way. Having clean frontend/backend separation
> and custom parser make it possible to lift up error message quality to
> what every program language have. I decide to go away from using Python,
> Lua or any other script languages only for one simple reason - I want
> to features, targets and others primary build concepts and players to be
> first class citizen in a language. Having this and clean and easy AST
> allow building precise IDE support for Hammer scripts. Make it possible
> to build tools for precise rewriting, formating, analyzing Hammer's
> scripts and whole build tree. Custom language with own parser will give
> much more possibilities to enhance/extend such a tool. Yes, thats
> require more manpower and knowledge to be done, but in a long time
> perspective IMO its right investment.
I see. So, you mean that in Boost.Build, something like:
exe a :
Is merely a function call as far as Boost.Jam language is concerned, so
even if AST is exposed to IDE, it will be hard to do anything sensible with
that, like auto-completion? I actually though that Boost.Build IDE integration
should be at level of targets, not syntax.
> >> * 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 build system by self. Project generation is only one of it
> ability. I develop mostly in Visual Studio with help of syntax
> highlighting, code navigation and others features that makes my life
> much easy. Being build system by self Hammer respect other users and
> give them ability to work in they usual environment. In that sens it
> like CMake - write one script and generate others if you need. But
> Hammer doesn't support autotool/autoconf headers/libraries discovering.
> For now I have strong opinion that software can be written in a way that
> doesn't require all these checks. Build system should help write such a
> software, but this help should be as little as possible. May be I am
> wrong, but now that my position.
> > 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?
> This one I don't have :( But thinking about a problem.
This is pretty much the only thing in Boost.Jam engine that I find important
should we ever want to use a different one.
> > Does it have unit tests?
> Yes, it does. The quality is not perfect, but it does. The main problem
> that I don't like huge number of cpp files - one test in one file. I
> packet all tests in one set. But IDE doesn't have a way to run easy only
> one Boost.Test when I need to debug. I think I should do something with
> You can browse test at
Thanks. I'll surely have a close look, and not only on tests, soonish.
> Can it be easily modified to support signatures
> > (both for file content and for the updating commands)?
> This one I can't understand :(
I mean, if a.o was produced from a.cpp, will a.o be rebuild if:
1. a.cpp time changes, while content does not.
2. If the command to generate a.o changes, while a.cpp itself does
> May be asking about that.... Hammer output for dll/so/lib is tagged by
> MD5 calculated from target sources and build request. This is unique
> identify different builds and prevent from dll hell. Yes, looking on
> can scary anybody, but this the only way I have found to resolve all
> build problems forever. By looking on that file name you can't tell what
> compiler was used, is it linked with shared runtime or static and so on.
> But you don't need to known that in %99.99 of cases. But when you
> really need it one can write a tool that print all information about the
> way a library was build. This is subject to discuss, but I spend a lot
> of time in thinking about that problem and I think that is the solution.
It does not seem like the above name is good for integration with
outside world. Do you expect rename to happen during installation?
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