Complete.Org: Mailing Lists: Archives: freeciv-dev: February 2001:
[Freeciv-Dev] Re: Keepig Xconq and Freeciv syncronized.
Home

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

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: freeciv-dev@xxxxxxxxxxx
Subject: [Freeciv-Dev] Re: Keepig Xconq and Freeciv syncronized.
From: Vasco Alexandre Da Silva Costa <vasc@xxxxxxxxxxxxxx>
Date: Thu, 22 Feb 2001 21:53:49 +0000 (WET)

On Thu, 22 Feb 2001, Stan Shebs wrote:

> Erik Sigra wrote:
> > 
> > torsdagen den 22 februari 2001 08:29 skrev Stan Shebs:
> > 
> > I still don't understad what special random number generation needs
> > Freeciv/Xconq don't share with each other.
> 
> It's not that it couldn't be done, it's that the benefit seems small
> compared to the effort.

Yes i agree.  The number of Lines Of Code (LOC) saved isn't worth 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.)

IMHO things like that can be shared but is it worth it?  Such things
should be in something akin to the C library.  I'm not counting weird
stuff here.

> 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?

We're making a Mac port anyway.  But i doubt it will be for classic Mac
though.

> > * 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. :-)

Yes agreeing on a coding style after the projects have grown to such size
is nearly impossible.  And not everyone likes the same style.  I for one
don't like the freeciv coding style but i use it (well now i do) because
it's the standard style used in the freeciv distribution.  Once you choose
a style for a project and it gets a certain size the worst thing you can
do is break style with each file or something.  It's very confusing.
BTW i don't like GNU style either.  I prefer berkeley style with
indentation level 2.

Also Freeciv uses K&R style so that if you showed there shouldn't happen
in the code.  The code Sigra ripped from XConq however seem to have some
stuff like that :-)

> > 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.

I agree.  But IMO certain parts of the XConq code *are* obscure.  I'm not
saying Freeciv hasn't got it's obscure bits but i'm really having a hard
time with understading the code of your quick & dirty Lisp parser.

But you didn't mean that anyone else used it so i can see your point.

---
Vasco Alexandre da Silva Costa @ Instituto Superior Tecnico, Lisboa




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