[Freeciv-Dev] Re2: Re: (PR#16688) v2.0.8: patch + bug report

["ThMO" <thmo-13@xxxxxx>]

<URL: http://bugs.freeciv.org/Ticket/Display.html?id=16688 >

Hello Jason and others listening,

first of all, THX for responding.

> > · bugs related to compiling:
> > ============================
> >
> > 1.)  variable macro arguments:
> [...]
> What systems can't use gcc3 that use gcc2?  Varargs is a C99 standard
> and should be supported by all modern compilers.

I always get asked this kind of question and I'm really getting tired
to answer it for long, but just let me answer in short.
There are *several good* reasons why some people still do use some
older systems.
OTOH while looking at the variable macro arguments (keeping in mind,
that this older gcc supported those many years before some ISO commitee
sucker got a wet dream) those are used only for typing laziness, which
could easily be done using some handy vi-macros, which means they could
easily be avoided...
But surely I'm able to patch those handful header files.

> > 2.)  configure using a *real* bourne shell:
> > The configure script uses some constructs, namely == for checking
> > equality, which isn't understood by an older bourne shell (the C-like
> > equality operators have been added by POSIX lately, but the single =
> > sign works even on a brand new POSIX-like bourne shell).
> > My change for requesting /bin/bash is just a hack to let it work.
> > (IMHO even /bin/ksh might work, but I haven't tested that)
> 
> I don't know much about shell scripting.  Do you have a patch for this?

You wouldn't benefit from a patch against configure, since it's autogene=
rated by autoconf (or autofuck, as I'm used to call it ;-).

> > 3.)  unrespected CFLAGS:
> > One thing I really hate is the fact, some configure script *ignores*
> > my CFLAGS settings - configure does honor my CC settings, but overrides
> > CFLAGS with it's own compilation flags - it's really painful to hand-edit
> > all Makefiles before compiling, only to get *my* flags used.
> 
> Add CFLAGS to the make line.  In my .bashrc I have
> 
> alias make="nice -n 15 make CFLAGS=\"-g -O0 -Wall -Werror -Wcast-align
> -Wmissing-prototypes -Wmissing-declarations\""

Absolutely wrong!
Please, go and read the configure standards!
Aliasing the make command like above is really a bad thing.
If this works for you, then that's O.K., but don't expect others using
this bad style.
The configure standards clearly says, that your default compiler settings
are to be used, if the user haven't specified some CFLAGS during the
configure stage.  But if the user gave configure some CFLAGS, then those
need to be used and *not* your default settings.
Overriding the CFLAGS for a *single* compilation step via `make' will be
O.K. for e.g. testing something, but not for the general compilation step.
SO the rules are clear: if CFLAGS and/or CC settings are set while confi=
guring this package, those settings are mandatory to be used and nothing
else - only if those aren't set, your default options are O.K.

> > A word to append some warning flags: it's O.K. to append those flags:
> >   -Wall -Wpointer-arith -Wcast-qual -Wcast-align -Winline
> > (-Wcast-qual isn't appended by configure, but I'm using this warning
> >  option frequently)
> > but it is *not* O.K. to append the following:
> >   -Wmissing-prototypes -Wmissing-declarations
> [...]
> AFAIR the extra flags are only added if --enable-debug is given.

I always compile packages without debugging support enable; in your case
giving the `--enable-debug=no' option.
Most configure scripts don't append warning options at all, if the user
has given some CFLAGS while configuring; others provide some configure
options in order to let the user decide the amount of warnings enable,
like `--enable-warnings={none,some,all}' or something like that.
IMHO you should understand, that the user configuring some package for
his systems knows best, what options are good for a compilation run,
which might be very different from your system/compiler used.
And exactly that's the case, why the configure standards cleary says,
that the user-given settings have higher priorities than the defaults
used, if none are given.

> > 4.)  Xaw[3d]: Freeciv.h -> resource.c:
> > Personally I would prefer a configure option, to omit including the
> > app-defaults inside the client, as I always do install the app-default
> > file in order to customize it, that way reducing the size of the
> > client from 820k -> 680k ...
> 
> If that's the case it shouldn't be a configure option - it should just
> always be done that way.  I have no objection to it.

Well, nowadays with all those widget libraries ignoring the X way of
doing things (like gtk, gtk2, qt, etc.pp.), many people don't know any
longer, where application default files need to be placed, so for those
people it's absolutely O.K. to compile-in the full defaults...
So IMHO a configure option might be the best solution, but YMMV here.

> > 5.)  compiling against libXaw3d:
> > Many "problems" arise, because the false set of header files are used
> > for compiling, since the headers do differ from Xaw - for that, I always
> > do the following before starting the compilation:
> >   cd client/gui-xaw
> >   mkdir X11
> >   cd X11
> >   ln -s /usr/X11R6/include/X11/Xaw3d Xaw
> > By using -I. this will ensure, that the correct header files be included.
> > This step could be done by configure...
> 
> I haven't compiled with xaw3d in a long long time.  Can you provide a
> patch to fix its compilation?

You should notice here, that many (if not all) linux distributors don't
install the Xaw3d-specific header files, so generally setting things up
like I do won't work on other systems...

> > · bugs related to running:
> > ==========================
> >
> > 6.)  NLS using -lintl and -liconv:
> > Since the data files are in utf-8 format, I'm using the following ENV:
> >   LANG=de
> >   FREECIV_LOCAL_ENCODING=iso-8859-1
> >   FREECIV_INTERNAL_ENCODING=iso-8859-1
> >   FREECIV_DATA_ENCODING=utf-8
> 
> There should be no need to set the encoding environment variables; they
> are intended for debugging use.  Freeciv is supposed to detect the
> correct values all the time.  If you run into a problem with the regular
> detection you can try fiddling with them but you should also report it
> as a bug.

Sorry, but that's wrong, since the "correct values" for my system is
iso-latin-1, while the data files are in utf-8.
For english people things doesn't matter, since they only use the 7-bit
ascii characters, which need no conversion in either case.  For european
people things look different, like the Germans or the French, which uses
more or less the characters in the extended ascii section.
-> Without specifying the encodings like above, things won't work as
one would expect, naturally.
So it's *not* a bug setting the above, IMHO.

> > This will lead to messages like `coudn't convert from utf-8 to latin1'
> > *several* times.  I've tracked down the problem, since I'm using the
> > german translations, that an already converted word like `Königin' will
> > get converted a second time from utf-8 to latin-1, which will force this
> > error.  The reason for that is, that -lintl already uses -liconv, if it
> > is present, which is the reason, why the gettext package needs to be
> > compiled a 2nd time, since -liconv may use -lintl, unless --disable-nls
> > has been given.
> 
> Gettext is told to use the internal encoding for its output (of course
> libintl uses iconv to convert to this encoding).  It is possible there
> are some places in the code where such a string is treated as a data
> encoding string, and therefore converted again.  If you can trigger a
> crash (add an abort call to the error message in fcintl.c) and get a
> backtrace we can track down such erronous flow.

The program doesn't crash, it only states (correctly), that the last
(up to 128 messages) string couldn't be converted in the servers log
window...

> [...]
> > In order to solve the problem, the configure script needs to check, if
> > libintl already has been linked against libiconv, so the second iconv()
> > call could be avoided in that case.
> 
> We assume libintl is linked against libiconv.  If it doesn't, then
> libintl is broken.  I suppose we could check for that and fail the
> configure but I hope that would never happen.

Hmm, this statements makes me wondering...
This needs to be clarified a little bit longer:
· libintl is *not* broken, if it isn't linked against libiconv
  considering this case on a naked system:
  · 1st compile libintl
  · 2nd compile libiconv using --disable-nls
  -> both are installed and usable, but libintl isn't linked against
     libiconv, which is not a bug...
· if you *assume* that libintl is linked against libiconv, the you haven't
  tested the cases or (which I think you've checked it) you only checked
  things with a resulting charset of utf-8
· here you will not see any problems, since every charset will correctly
  be converted to utf-8 and for eg.g. using gtk2, this is the charset used
  by that widget, so you already have things in utf-8 and no other con=
  version has to take place
· but things look a little bit different, if the data files are in utf-8
  and the resulting charset is iso-8859-1:
  · you do have to output some message, which needs to be translated
  · the translation *already* converts (as libintl is linked against
    libiconv) the yet translated message from utf-8 to iso-8859-1
  · a 2nd iconv() call inside fciconv.c will fail
    (the reason for this is, that you can convert *everything* to utf-8,
     but not the other way round, e.g.
     iso-8859-1 -> utf-8 -> (again) utf-8 a.s.o.)
· the bug here is a logical one inside fciconv.c, which won't show up,
  if your destination charset is utf-8
· you can safely cross-check this yourself by doing the following:
  · configure freeciv using `--with-included-gettext'
  · setup the above environment and look
  · now do the following:
    · cd intl
    · make clean
    · vi `egrep -l ICONV *.[ch]`
      place an #undef HAVE_ICONV inside those files (3 I guess) after all
      header files included
    · cd ..
    · make
  · if you run the game with the exact same settings above, you'll notice,
    that everything runs *without* a single error message
  => the bug is a logical bug inside fciconv.c, which unconditionally
     converts each message from utf-8 to iso-8859-1, *but* while trans=
     lating the utf-8 messages to a foreign language, they will get already
     converted to iso-8859-1 by libintl via linked-in libiconv, unless
     libintl has not be linked against libiconv...
· this means there are several cases, which need to be handled differently:
  · if libintl is linked against libiconv *and* the message need to be
    translated
    -> translation already converts to the target charset
  · if libintl is linked against libiconv and the message need *not* be
    translated
    -> an explicit iconv() call is necessary
  · if libintl is *not* linked against libiconv *and* the message need to
    be translated
    -> translation *and* a iconv() call is necessary
  · if libintl is *not* linked against libiconv and the message need *not*
    be translated
    -> an explicit iconv() call is necessary
Hopefully the above explanations enlight the things?

> [...]
> HOWEVER, one thing I just remembered is that for the server, the
> internal encoding is defined to be equal to the data encoding.  This
> could cause problems if you try to override things using environment
> variables.  Try setting the encodings separately for server and client
> and see if that helps.

If that's the case, then I must call this a bug, which should be fixed
inside the server...
BTW, didn't you said some lines above, that those ENVs are only for
debugging purposes...?  ;-)

> > 7.)  server options:
> > Starting the server like that:
> >   ./civserver -s svdir -f game
> > should load the file `./svdir/game.sav[.gz]', but it doesn't - instead
> > it must be called
> >   ./civserver -s svdir -f svdir/game.sav[.gz]
> > By contrast - saving a game inside the server with `save blubber' will
> > correctly save it as `svdir/blubber.sav[.gz]'.
> > This behaviour should be equal on the command line, which means, the
> > load operations needs to be held pending, until all parameters has been
> > processed in order to get a potential directory path for save-games.
> 
> The -s command-line parameter does not affect the interpretation of the
> -f savegame name.  I don't think this is a bug.

Then this should be clarified inside the man-page.

> > 9.)  client menu `view other server options':
> > This option does nothing...  Is that the correct behaviour?
> > BTW, I'm using the Xaw3d client, as it looks *much* better than the
> > gtk v1 client, especially wehn it comes to the technology help.
> > And hopefully you'll not consider dropping the Xaw3d client from this
> > package, since I'm not going to install gtk v2 ?
> 
> This menu entry was removed some time ago when all server options were
> merged into one dialog.  I don't see it anywhere...but if you find it
> somewhere we should remove it.

The Xaw-client does list this option inside the first menu.

> > For novices it would surely be helpful, if the online-help (which is BTW
> > done *very* well!) could include some ``how-do-I-do-that'' messages,
> > like e.g.
> >   · build a city on another island (settlers need to be transported by
> >     a ship)
> >   · what to do, if people are starving in a city (I don't know)
> >   · I tried to build a bridge over the ocean to the next island, but
> >     that doesn't work, although I've researched building a bridge
> >     (I think, this could only be done over rivers on the same island?)
> >   · adding a notice, that it seems, that each city can have at most
> >     4 Handelsrouten (routes established by trucks for making more money)
> >   · etc.pp.
> 
> You mean a FAQ section?

No, not a FAQ section, since a FAQ needs to explain some more things e.g.
for compiling, which aren't of interest while playing.
What I mean is some sort of a HOWTO section, explaining some things happen=
ing while playing, which experienced players learned already, but which
aren't as obvious for novice players...

> > 11.)  downloadable handbooks for offline-viewing:
> > It would be great, if the handbooks could be downloaded for offline
> > viewing, since it could get expensive in order to view them online
> > through a dialup-line using a slow modem connection, since it's a pain
> > in the ass to fetch them using `wget', modify them and accordingly
> > fetch the additional pages, not retrieved by `wget', hand-modify them
> > and start over again, since they'll be generated by some php-scripts...
> 
> What handbooks are you talking about?  I think all documentation should
> just be included with the game.  However a lot has been added to the
> wiki that is not listed anywhere else.

I do mean the 3 handbooks called:
· server handbook
· client handbook
· game handbook
Especially the last is IMHO a valuable source of information to read before
starting to play the game.  I've found a very old german translation fpr
v1.13 or so, which could be downloaded for offline-viewing, which clarified
many things.

> > 12.)  comfortable context menues:
> > Especially for guys, like myself, playing this game for the first time,
> > it would be very helpful, if e.g. pressing the right (or the middle)
> > mouse button over e.g. a settler would open a menu with commands, this
> > unit can do, like building a city, building a road, etc.pp.
> > Although that might be difficult to implement?
> 
> Not that difficult.  I would like to do this but haven't gotten to it
> yet - some complain that popup menus are a "bad" interface, and another
> problem is all mouse buttons already do something.

Well, it could be added to the middle mouse button, as this popup menu
already displays some information about the unit - and the action menu
highlights only the actions, this unit can do now.
Maybe those valid actions could be appended below the information section
for quickly giving this unit some orders?

> > Finally I'd like to say a big THX for developing such a great game,
> > making me sad, that I haven't noticed this game earlier - in fact
> > it has only one drawback - it's very, very addictive...  ;-)
> 
> Thanks.

Actually it's much more addictive, as I know now, since the time is
running very quickly while playing, having only 2-3 hours left before
going to work for a sleep...  ;-)

BTW, there is one thing I would like to suggest: if some city has
finished building something, it would be very nice, if there could
be some option, which automatically pops up the city dialog, one after
another, in order to explicitly give orders, what to build next, since
it's very time-consuming, IMHO, to open this dialog explicitly via the
message window, as the cities mostly don't build the items, I would
like to be built then...

THX for listening.

CU Tom.
(Thomas M.Ott)
Germany