Re: [Freeciv-Dev] patch: remove config.h from shared.h

[David Pfitzner <dwp@xxxxxxxxxxxxxx>]

David Pfitzner wrote:

> Now that we no longer support non-configure make methods, we 
> don't need to duplicate the version info in shared.h as well 
> as in configure.in (and generated into config.h).
> 
> This patch takes out the duplicates in shared.h, and also
> makes some changes so that we don't need to include config.h 
> in shared.h.  This will mean much less will need to be 
> re-compiled if you do a re-configure which changes config.h
> 
> I suggest that in future if people want to revive the non-configure
> make methods (not that I'm encouraging such), such methods should 
> provide their own config.h (eg, to be hand-edited), and we should 
> include config.h unconditionally (as I've done in this patch, 
> instead of with #ifdef HAVE_CONFIG_H, as we do now).

However, I'm having second thoughts about this.  Well, I would
still like it, but I'm not sure if everyone else would :-7

Specifically, there has been talk about Makefiles for a native 
Win32 port, where we can't use configure because it needs a 
unixy environment (eg a Bourne shell, for starters).

So in that case, we don't gain much from having the version
details only in configure.in/config.h, since we would have to
duplicate them somewhere else anyway.  So maybe they should just
stay duplicated in shared.h.  And maybe we should still include
config.h only if defined(HAVE_CONFIG_H).  Or maybe not...

Now, personally, my priority is to develop freeciv for Unix/X.
But where feasible I don't mind accommodating those who want
to port freeciv to obscure platforms, if it doesn't inconvenience
things too much overall.

So, possibilities as I see them:

1.  Stay with the current system, where we only include config.h
when HAVE_CONFIG_H, and duplicate the version info in shared.h
One concern I have with this is that for the configure-related
stuff its easiest when coding if one can always assume we have 
config.h, and its harder to have reasonable things happen if 
config.h is not there.  But maybe this is a problem for the person 
doing a port to a non-configure-able platform, and so not my 
problem...  OTOH if the code and #ifdefs get too icky, that could 
be a general problem.

1a. In the above case, I would still actually like to separate
out the version stuff in shared.h into a new version.h, so
that shared.h doesn't need to include config.h, thus reducing
the amount of re-compiling when config.h is changed.  (Only
a few files would need version.h, compared to shared.h)

2. Go with the changes as described in the commented email above:
remove config.h and version info from shared.h, and include config.h
unconditionally.  In this case the handling of different make methods
would be as described above: such methods should supply their own
config.h, either with everything hardwired (eg, a generic win32 
config.h suitable for all win32 systems?) or to be user-edited.
This would involve duplicating the version info into the separate
config.h template, which seems a bit messy.  But it would have the
advantage that the code can always assume the existince of config.h
and related defines.

2a, like 2 but have a version.h which defines fallbacks if the
versions are not defined in config.h...  May be better in a 
transitional case if config.h.win32 is provided separately.

Hmm, I just looked at glib, and it basically does (2), with a
makefile.msc which has a rule for config.h like:
config.h: config.h.win32
        copy config.h.win32 config.h
(and CFLAGS with -DHAVE_CONFIG_H)

Yet another possibility would be to unconditionally 
#include <fc_config.h>, which checks HAVE_CONFIG_H and/or 
NATIVE_WIN32 (or whatever) and does something sensible...
But thats rather non-standard.

Hmm, my head hurts :-/

-- David