Op Zo, 13 maart, 2016 7:12 pm schreef Arun Persaud: > Known issues: > * I tried configuring with --with-Xaw, but that version did not compile > (I got a cairo error).
It seems that pangocairo.h is not available under Xaw. All other errors follow from that, and they are all in the routine DrawUnicode, which is used to draw text on piece images on the board (intended for inscribing kanji on blank Shogi tiles). Rendering non-X-fonts on the board never seemed to cause a problem for the board cooordinates, so this comes as a surprise. It is weird that I did not get this problem before. I guess the autotools stuff is not clever enough to find this dependency. Only draw.c uses the pango stuff, and it is supposed to be front-end-independent. So after building the GTK version, there will be a draw.o, and reconfiguring for an Xaw build will then happily use that. The Xaw version I built that way immediately segfaults at startup, however. When I remove all *.o files first, I get the compile errors in draw.c. But I did build Xaw versions very recently that ran without problems using the draw.o from the GTK build. (And the DrawUnicode stuff is from early last year.) Perhaps that was just a coincidence. I don't understand how it could segfault, though; DrawUnicode should never be used when not running with an -inscriptions option. So it could be that the segfault is due to something entirely different. If the use of pango is really restricted to GTK, I guess the solution should be to move it from draw.c to gtk/xoptions.c, and put a dummy in xaw/xoptions.c. > * I'm also getting a few compiler warnings about unused variables, which > we could clean up. > * When starting the compiled version without installing > it, xboard might get confused since it will probably load an old init file > from /etc... I'm wondering if we can/should detect that xboard is not > installed in the install directory defined in the Makefile (or perhaps > just check if we are running from the same directory as the source is in, > e.g. test for xboard.h the init file and the svg pieces) and in that case > just use the etc file and pieces from the source directory? We could pop > up a message saying "development version detected" or something like this. > I > think this could make testing easier. > I am not sure what problem we are trying to solve here. Old /etc/xboard.conf files will always be understood by later XBoard versions. Apart from redirecting the reading and saving of settings to a user-specific file (~/.xboardrc), what they contain is usually completely ignored, as it will be overruled by the settings in the user-settings file. This will be the one of the old version, no matter whether a new /etc/xboard.conf was installed. Unless that xboard.conf would redirect to another user settings file (like ~/.xboard490rc). But we intentionally let it read the old user settings files, so that a user would not lose his settings on upgrading XBoard. Not installing is ill adviced anyway. If you had no XBoard before, you won't have any pieces. In 4.9.0 new piece types have been added, so even if you had 4.8.0 installed before, you will still get the Error popup each time you start that default pieces are missing, and that you should define a pieceImageDirectory.
