Re: [Boost-build] Call of interest

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.

OK.
 
> > 
> > Do you have a custom build engine (the thing that decides what has to
> > be rebuilt, and what not).
> 
> Yes

OK.

>   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 
> it....
> You can browse test at
> http://apps.sourceforge.net/trac/buildhammer/browser/hammer/core/trunc/test

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
not?

> 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
> 
> boost.program_options-1.36.0-1e83e9bc7c03898215686e15b2b3efdd.lib
> 
> 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?

- Volodya