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