Experimental Physics and
Industrial Control System

Benjamin Franksen <[email protected]> · Fri, 15 Dec 2006 13:49:14 +0100

On Friday 15 December 2006 00:54, Andrew Johnson wrote:
> 5. If someone changes the value of a variable in configure/RELEASE
> from one support application to an *earlier* build of the same
> support application, Make won't be able to tell that it needs to do a
> rebuild since all of the dependencies are still older than the target
> file. 
> 6. Actually, as long as the support application versions were 
> all built before the target last was, you can switch the pointer in
> the RELEASE file as much as you like without causing the target to be
> recompiled.

Sure. I'd say the situation here is similar to changing a Makefile which 
usually requires a complete rebuild because dependencies might have 
been changed. Hmm, after experimenting a bit I see that the EPICS build 
system seems to handle changes in Makefiles quite well. If I remove a 
library, the target gets rebuilt. Cool.

The consistent thing to do would be to make every target depend on 
configure/RELEASE. Thus, if configure/RELEASE changes we regard 
everything as out of date, effectively forcing a 'make distclean'. This 
is of course a pessimistic approach (or rather 'conservative') since we 
might get away with re-building only stuff that depends on those 
definitions that actually changed. However, changes to 
configure/RELEASE probably a lot less often than changes in a dependent 
module itself, especially during development of the latter.

I'm not sure how to implement this in the make rules, though. Any ides?

Perhaps this could be an optional feature?

> If you do rebuild a dependent library as you already found that it
> does actually cause the target to be re-linked.  However as I
> described above Make can't protect you from switching between two
> older support apps, which is why we put that advice in the RELEASE
> file.
>
> If you know that no RELEASE file changes have occurred you can omit
> the "make distclean uninstall" and a simple make from the top level
> may do the right thing, but as you know, we don't currently list
> external .h or .dbd files in the .depends file.  I don't know what
> the cost of adding all these would be on a 'do nothing' build, but I
> expect there would be some negative effect.

I very much doubt it will be noticeable.

It more or less amounts to removing line 148 from 
configure/tools/mkmf.pl. It is used for header files /and/ dbd files, 
as I just found out.

(BTW: mkmf.pl contains a bug: in line 143 file name matches are 
restricted to [\w\.\/]* instead it should be .* otherwise for instance 
'include <x-y.h>' doesn't create a dependency on the header file x-y.h 
(and it really doesn't, I double-checked it this time)).

Cheers
Ben
-- 
To the functional programmer's eye a loop is just a degenerate
form of linear recursion written in an adhoc special syntax.

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System