Re: [Boost-build] Call of interest

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

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

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

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.

Yes

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

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

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