Gratuitous reconfigures and rebuilds

[Nathanael Nerode <neroden at twcny dot rr dot com>]

Loren said:
>related issue?  When a gratuitous reconfiguration occurs for other
>reasons (e.g. libf2c and gcc reconfigure themselves daily, probably
>due to gcc/version.c being touched; perhaps that root issue should be
>addressed instead), some subdirs recompile everything (libf2c/libjava)

Ohhhhh. :-(  That root issue.  I would *love* to address that issue.  
There is code in top level configure.in to pass something horrifying 
known as --with-gcc-version-trigger=${srcdir}/gcc/version.c

config.status in the Makefiles for gcc and libf2c depends on this 
gcc_version_trigger, which is gcc/version.c.

In other words, they reconfigure themselves daily because they have 
specific code to do so, and have for a long time.

I haven't touched that code.  I'd love to, since it seems mildly insane 
to me, but I haven't wanted to mess with it, since I don't know what 
it's doing there in the first place.

If someone could tell me *why* config.status for libf2c and gcc depend 
on gcc/version.c, I could try to get rid of that dependence.

If it really does depend :-(, but it doesn't *usually* cause a real 
change to the Makefile, there's an overly clever way to deal with 
it, which is to use move-if-change on the subdirectory Makefiles.  This 
means changing all the subdirectory configures to produce Makefile.tmp,
or changing the top level to invoke Makefile.copy, so that there's 
something to copy from and something to copy to.

>multiple makes to reveal it.  I should think that top-level gmake
>should be "stable".  I.e. If I run it once and it does work, it should
>to all work available.  If I run it again without touching anything,
>it should never have new work to do.

Make should always be stable in this manner, quite right.

The instability you see is due to the 'serialization dependencies' 
for subconfigures; these aren't real dependencies.  
Once libf2c decides it has to rebuild itself, the 
top level decides that all the subdirs which are supposed to be configured 
after it have to be reconfigured.  But the top level doesn't know this 
until after libf2c has rebuilt its Makefile in the libf2c subdirectory, 
so it doesn't figure it out during the same Make invocation.

This is solvable in several ways:
1. Remove the serialization dependencies.  With GNU make, the top level 
is currently .NOTPARALLEL anyway.
2. Specify the serialization dependencies using GNU make's new feature, 
'order dependencies', but only if a sufficiently recent GNU make is 
detected by top level configure; if an older version is detected, use 
.NOTPARALLEL; if neither is supported, just leave 'em out.  I rather 
like this solution, but it's slow and involved.
3. Phonify the serialization dependencies.  This makes the serialization 
dependencies not actually work, of course, since 'make' is free to 
reorder dependencies as it likes.
4. Just fix the problem with libf2c.
5. Use move-if-change on all the subdir Makefiles, as mentioned earlier.  
I don't like this due to its messiness.