Complete.Org: Mailing Lists: Archives: freeciv-dev: July 1999:
[Freeciv-Dev] tentative 1.8.1
Home

[Freeciv-Dev] tentative 1.8.1

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: freeciv-dev@xxxxxxxxxxx
Subject: [Freeciv-Dev] tentative 1.8.1
From: David Pfitzner <dwp@xxxxxxxxxxxxxx>
Date: Fri, 9 Jul 1999 00:36:43 +1000 (EST)

Things that make you go D'oh...

I was about to release 1.8.1, when I realized a subtle problem
with the release tarball...  I think I have made a successful
fix, but there should probably be some other testing/opinions
before we make a wide release. 

Currently, freeciv-1.8.1.tar.gz (soon .bz2) (with my fix) 
is in incoming on ftp.freeciv.org 
(ftp://ftp.freeciv.org/pub/freeciv/incoming/)
with an accompanying file freeciv-1.8.1.WARNING
that specifies that its currently for developers only.

Could people please test that release tarball (note the problem
does _not_ occur in CVS, only the release tar) and/or read the 
description of the problem/fix below.  If everything is ok,
we can then release wider, else we can replace that with 1.8.2
as soon as we get a better fix.

The problem:

The release tarball is made with "make dist", a target
generated by automake, which makes sure everything goes in
the tarball which should, and _only_ that which should.  It
also massages the Makefile.in files, so that C header dependencies
are included there, so that the user does not need to use gcc/gmake.

Now, the dependecies put in the Makefile.in are those calculated
when the maintainer compiled the sources using gcc/gmake.
The problem is that those dependencies depend on whether the 
maintainer, before doing "make dist", had configured for Xaw 
or Gtk! :-(

A partial solution is for the maintainer to compile both ways 
(Xaw and Gtk+) in turn, before doing the "make dist", and then 
"make dist" will pull in the right dependencies in the separate
gui directories. _Except_, this doesn't work for the .c files 
in freeciv/client, which depend on some headers in _either_ 
gui-xaw or gui-gtk.

So in some ways its a rare problem, in that it only affects
users who compile, then edit the sources, then re-compile.
Also, in principle (and probably in practice) those non-gui
files in client/ should not depend on any gui-differences
in the header files in the gui-foo directories, and thus 
it mostly doesn't matter on which ones they depend.  Unless
one started editing them...

(Actually, this suggests a real fix: the headers should be
split more systematically into gui and non-gui dependent parts, 
such that the non-gui parts go in include/, and gui parts
in the gui subdirs, and files in client only include headers
from include/, and not the subdirs.  This should also fix some
other structural problems with the current headers and 
gui-dependent function prototypes.)

My solution:

I've hand-edited the client/Makefile.in which was produced
by "make dist", so that the gui-xaw and/or gui-gtk components
in the depedencies were all replaced by $(gui_sources)
(which is set earlier in the makefile to @gui_sources@
and expands to either gui-xaw or gui-gtk depending on
which was configured).  (I also made all the client/*.c 
files depend on ../config.h, though now I'm not sure that
was necessary.)

I think this should do the job, and should be work with
all make's etc.  (Tested on Linux gcc/gmake, and Solaris
cc/make.)

Regards,
-- David














[Prev in Thread] Current Thread [Next in Thread]