[Freeciv-Dev] Re: Keepig Xconq and Freeciv syncronized.

[Stan Shebs <shebs@xxxxxxxxxxxxxxxxx>]

Erik Sigra wrote:
> 
> torsdagen den 22 februari 2001 08:29 skrev Stan Shebs:
> > For instance, a common random number generator is probably a waste of
> > time, because Xconq and Freeciv both have requirements on consistency
> > and read/write behavior.  Satisfying those will likely need more code
> > than the few lines that actually implement the RNG.
> 
> I still don't understad what special random number generation needs
> Freeciv/Xconq don't share with each other.

In Xconq it's possible to supply the random number on the command line
(useful for reproducing errors), and so there is a clipper to make sure
the seed is within a particular range.  I don't know if that would be
good or bad for Freeciv.  Xconq's default seeding process (call time() )
is contained within the RNG, which Freeciv calls time() elsewhere.
These could be made to work the same way, but it's more than a little
work to adjust the callers.

It's not that it couldn't be done, it's that the benefit seems small
compared to the effort.

> > But one could imagine a libnamegen.a being installed in /usr/lib.
> 
> We don't have to go as far as creating common libraries in /usr/lib if we
> don't want to. It would be a great convenience just to be able to copy code
> between the programs and expect it to work with minimal modification.

This is such a rare situation that I'm not sure it's worth putting
a lot of effort into supporting.  It's like being able to copy bits
of emacs into vi, or bits of the Linux kernel into FreeBSD.  In GNU,
where everything is nominally part of a single grand system, we've
set up libiberty as a common home for things shared by GCC and GDB,
and yet it's pretty small, because things like memory management are
too different to be sharable, and proposals to merge things generally
erupt into furious debate over the "right way".  (As GDB maintainer,
I've had to participate in a few of those, heh-heh.)

> The obstacles are for example:
> * Random number generation.
> * Memory allocation. (I was able to just replace xmalloc with fc_malloc and
>   it seems to work. If thoose would have had the same name, I wouldn't even
>   have had to do that.)
> * The macros DEBUGGING/DEBUG (Can't you agree on one of them?)
> * Logging. Both programs should have a function to call with a log level and
>   a string. They should have the same name, but do different things,
>   depending on the user interface.

Xconq has had a full-blown Mac version for some years, and the Mac is
different enough that you have to be more careful about abstracting
access to system facilities and the filesystem.  Would Freeciv developers
be willing to make the necessary changes?

> * How function headers look, for example:

Aha, and now we come to the question of style.  Xconq has a particular
style that it's used for 14 years, and it's about twice the size
of Freeciv.  So I could use that to say that any shared code ought
to conform to Xconq's style.  But based on what I've seen, I doubt
many Freeciv developers will want to include any code that's in a
foreign style.  Similarly for Xconq.  I'm willing to have foreign
styles, for instance Xconq's copy of obstack code is left in the GNU
style, but that's because I don't ever need to look at it.  For me,
the Freeciv style is quite difficult to read, and it's harder
to debug (in "if (foo()) bar = w * x + z;" there is no way for GDB
to set a breakpoint on the assignment only).

So you find yourself in the unenviable position of arguing that
existing programs should change their agreed-upon styles.  If you
can get them to do that, your talents are wasted here; you should
be heading down to the Middle East. :-)

> One way to not scare them off is to make them feel familiar with how the code
> looks. If they recognize function names and infrastructure from for example
> Freeciv, they can get started easier. Some may feel reluctant to learn a
> whole new set of infrastructure.

Perhaps, but in 20 years of working with open source (going back to
when people posted it as articles to net.sources!), I can't think of
a single case where anybody got interested in working on a program
just because it had changed its internal structure or style to be more
familiar.  People work on programs because they're interested in what
the program does, and because they can understand it well enough to
make changes that work.

Stan