[Freeciv] Re: how do i find out about the techs, units, terrain types etc.? (was: Question ?)

[Reinier Post <rp@xxxxxxxxxx>]

> > P.S.  Note to David: maybe it's time to update the techtree program to use 
> > the new ruleset format?  ;-)
> 
> Yeah, I've been meaning to do so ... :-7

I have the same problem with sav2ppm, the program that generates the
bitmaps on http://civserver.freeciv.org/

> One issue I've been concerned about is how (and how much) to share 
> code from Freeciv, for parsing the ruleset files etc.  (Freeciv and 
> techtree are both under GPL, so no problem there, just issues of 
> programming convenience etc.)
>
> The current (old) techtree program uses quite a few source files 
> copied from Freeciv, edited to remove some extraneous parts.  
> This is convenient in that it makes techtree independent and easy 
> to build etc, but becomes tedious when things change.

Indeed ...
 
> One option would be to make some (minor) changes to Freeciv, 
> such as moving ruleset.c from server/ to common/ (doesn't use
> any other server stuff, so straightforward); then techtree could
> require that freeciv be built, and link to freeciv's libcivcommon.a
> (similar to what civworld did?)  This does still involve fairly
> tight dependence between techtree and freeciv, such that would
> typically have to use specific versions with each other.

sav2ppm has to solve the same problem: it must read and process
savefiles.  What it does is use a new util/ subdir; in order to
use the code in server/, it creates a libcivserver.a and links against it.
It still has to use its own main.c, which is a modified civserver.c.

I agree the ruleset code and savegame processing should be in common/:
civclients may not need them, but utility programs do and they are
not servers.  Also, it think server/civserver.c should be split so
utility programs could reuse as much of its code as possible, but
I'm not sure how to split.

> Another appealing option would be to decouple the ruleset-specific
> information handling from the "graph generation" parts of techtree.
> Eg, a "preprocessor" which reads and parses ruleset files, and 
> outputs a single easy-to-parse file of the tech nodes, their
> connections, and the text information which goes with them.
> Of course the issue of parsing/reading rulesets is then just 
> pushed to the preprocessor, but a fun (not necessarily practical)
> idea might be to try to do this part in, eg, perl...

This would not resolve the issue of how to keep the utility in
synch with the civserver code.  Unless civserver itself is made
to depend on Perl, which is probably a bad idea.

-- 
Reinier Post