renaming/deleting sources doesn't invalidate link

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

renaming/deleting sources doesn't invalidate link

Matthew Herrmann-2
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?

--

Matthew Herrmann
[hidden email]
Vice President, Software Architecture
Zomojo Pty Ltd

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build
Reply | Threaded
Open this post in threaded view
|

Re: renaming/deleting sources doesn't invalidate link

Vladimir Prus
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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build
Reply | Threaded
Open this post in threaded view
|

Re: renaming/deleting sources doesn't invalidate link

Matthew Herrmann-2
In reply to this post by Matthew Herrmann-2
> 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
>

Hi Volodya,

Thanks for that. I'll write it up (hopefully today). For the performance, I
guess running it turned on and off on a reasonably large build tree would be
a sufficient test. I'll have a think about some other safe optimisations that
may be possible too.

Best Regards,
Matthew
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build