[Freeciv-Dev] spurious modifications of config.h (PR#222)

[David Pfitzner <dwp@xxxxxxxxxxxxxx>]

(For cvs version Sun Jan  2 10:19:15 UTC 2000.)

I was seeing some strange compliation behaviour, with lots of 
unnecessary re-compilations, and wondered if it was some wierd 
y2k bug in configure or make, but it turned out to be a 
garden-variety bug...

The problem occurs if eg the configure script has changed 
(eg, from 'cvs up') and you do a make without manually re-running
configure.  In this case the make will re-run configure for you
(with command-line params from previous invocation etc) so that 
everything should be ok.  But it does it in a special way, using 
configure with '--no-create --no-recursion' at the top level, and 
then eg
  cd .. \
  && CONFIG_FILES=ai/Makefile CONFIG_HEADERS= /bin/sh ./config.status
at lower levels to generate updated Makefiles in each dir.
(Why I don't know, would have to ask automake gurus.)

The problem is that each time config.status is run from lower 
level directories a line 
   #undef HAVE_SYS_UIO_H
is appended to config.h, so that multiple duplicate lines of
this build up (and incidently are wrong, since I do have sys/uio.h), 
but worse, the timestamp on config.h is updated, so re-running make 
will have to re-compile everything which depends on config.h.  

This line in config.h is due to the line
    AC_OUTPUT_COMMANDS([echo "#undef HAVE_SYS_UIO_H" >> config.h])
in configure.in, which it appears is only intended to fix brokeness 
on BeOS.  But apparently autoconf actually just puts all 
AC_OUTPUT_COMMANDS() into configure, and they run unconditionally 
every time config.status is run.  (This is similar to a previous 
problem (now fixed) with adjusting po/Makefile to notice Q_() 
qualifier.)

A temporarly fix would be to get rid of that line in configure.in;
I'm not sure what a correct fix which does the right thing on
BeOS would be.

-- David