Re: [Boost-build] renaming/deleting sources doesn't invalidate link

From: Vladimir Prus (ghost_at_[hidden])
Date: 2006-03-30 23:51:58

On Thursday 30 March 2006 10:35, Matthew Herrmann wrote:
> Hi,
>
> I've noticed that removing a source file doesn't invalidate the link step
> when using 'globbed' sources.
>
> I understand that this is because the build "model" is the current Jamfile,
> so the system loses all knowledge of previous sources after files are
> moved: since all .o files are up-to-date, it reasons that the linked
> executable must be up-to-date too. This is not true if the dependencies
> going into the link have changed, however.
>
> I could see this being solved by the following:
>
> - the generator takes in a bunch of .o files and produces a .a and a .parm
> file.
> - gcc is invoked with a bunch of command-line options, including all the
> files to link.
> - the .parm file simply contains the command-line options used to produce
> the main target (lib or exe).
> - when doing an up-to-date check of a target, if the command-line that
> would be evoked to produce a target does not match the contents of the
> .parm file, delete both files and invalidate the target. Do not simply look
> at the target file's timestamp.
>
> Generalising this, #defines could then also be handled safely since these
> changes would then be reflected in the parameters to the compiler. Further,
> any changes to jamfile link/compile parameters would automatically trigger
> a rebuild of the necessary components.
>
> Is such an approach possible? Should I write this up into a ticket for
> boost build?

Hi Matthew,
this is a known issue and approach such you suggested by you should fix this. 
There are details to be worked out, however. For example, the performance 
side of this should be evaluated, we probably need to implement this in bjam 
core to avoid expensive string manupulation in intepreted language. Another 
issue is that if you install binaries somewhere, you don't want to write any 
'.parm' files, so they should be stored elsewhere.

I should note that SCons is supposed to compute 'build signatures', which is 
roughly the same that you propose. On the other hand, SCons is known to have 
performance problems which might be related to that feature, or might be not 
related. 

In any case, some performance checking for this feature would be desirable.

And to asnwer your question: yes, adding ticket would be great.

- Volodya

-- 
Vladimir Prus
http://vladimir_prus.blogspot.com
Boost.Build V2: http://boost.org/boost-build2