Re: [Boost-build] Call of interest

Subject: Re: [Boost-build] Call of interest
From: Vladimir Prus (ghost_at_[hidden])
Date: 2009-05-28 11:21:27

On Wednesday 27 May 2009 12:44:52 Konstantin Litvinenko wrote:
> Vladimir Prus пишет:
> 
> > 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.
> 
>     If you write:
> 	
> 	exe a :
> 
>    IDE, having exe rule AST can understand that after ':' should be some 
> sources and may suggest some local files. Than, if you type '/' after 
> ':' than IDE can walk over known global targets and suggest something. 
> Without AST it is impossible to decide how to help user after she type 
> ':'. That is on the one side. On the other side to suggest a 
> feature/target IDE must know previous registered/declared 
> features/targets. It is overkill to have half of build system rewritten 
> inside IDE to solve that task. 

Well, if a build system is a library, then IDE can use that library to
grab necessary information. But anyway, I see what you are aiming at.

> >>   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.
> 
>     If Jam has that feature then its implementable. So why stick with 
> Jam only because Jam has it? Yes, it is require implement/test that 
> functionality. But I don't scare by that - I will do it and will have 
> that feature along with those Jam don't have.

I don't claim that this feature is extra hard to implement and you won't
ever implement it. All I am saying is that until that feature is available,
we won't be able to consider using your build engine for boost.build. While
that's not your primary purpose, that would be handy.

> > 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.
> 
> Yes

How hard would it be to make Hammer compute MD5 signature of a.cpp
content and use *that* to decide if update is necessary.

> 
> > 2. If the command to generate a.o changes, while a.cpp itself does
> > not?
> 
> In most cases Yes, but that because it is now relay on MD5 hash of 
> sources and build request.  If it changes than rebuild. This behavior eat 
> HDD space considerably because each such build have separated build 
> directory names as MD5. I leave this problem for future.

OK.

- Volodya