Subject: Re: [Boost-build] Call of interest
From: Konstantin Litvinenko (to.darkangel_at_[hidden])
Date: 2009-05-27 04:44:52
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. My way is to provide as much as possible
Hammer's components to IDE in a such a way that all Hammer's stuff stay
>> 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.
> Thanks. I'll surely have a close look, and not only on tests, soonish.
I am really glad to here that from you ;)
> 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
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.
> It does not seem like the above name is good for integration with
> outside world.
For the first look is it :) I need more precise analytics and use cases
>Do you expect rename to happen during installation?
Yes. I think some use cases will require to have custom naming schema's
or something else, but I hope that such cases will be 0.001% of all.
Distributing libraries as prebuilt or in sources using that naming
schema will not have any problem with outside word integration, IMO.
Correct me if I am wrong. I am really interesting in comprehensive look
on this problem.
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