Oops, I meant to say that the web site implies Pango can work without GTK. But I don't know how true that is in practice with libraries that are packaged for Linux.
On Sun, Mar 13, 2016 at 4:24 PM, Tim Mann <[email protected]> wrote: > You can make the .o file dependent on the Makefile itself, or on whatever > file sets the compiler and linker options. Most people don't do that > because it ends up recompiling everything too often. > > Pango's web site claims it can work without Cairo. How true that is in > practice with libraries that packaged for Linux, I don't know. > > http://www.pango.org/ > > > On Sun, Mar 13, 2016 at 4:04 PM, <[email protected]> wrote: > >> Op Zo, 13 maart, 2016 11:27 pm schreef Arun Persaud: >> > >> > Could be because of the recent change in configure.ax? Before we always >> > had GTK on, even if Xaw was chosen, so perhaps some more variables were >> > set. Would have to look at it more closely, so this is just a guess. >> > >> >> Well, I expect it is an intrinsic limitation of the make process. It is >> just nor smart enough to understand that when you make a change to >> compiler or linker options, that also .c files that have not been changed >> need to be recompiled. >> >> > >> > If we are not using cairo in the X version, we probably should move it >> > the cairo call to gtk. >> > >> >> The Xaw version also depends on cairo for drawing, but it is cairopango >> that causes the problem. I guess pango is something specific for GTK and >> its fonts. The intention was that Xaw would use it too. So far drawing the >> board has always been exactly the same in Xaw and GTK, and I don't see why >> it should be different. It has nothing to do with the widget set, it just >> draws on an intenal memory bitmap. But the problem was that the normalway >> of rendering text on the board (for the coordinates) did only work for >> simple ascii, and not for arbitrary UTF8 text. (So no Japanese kanji...) >> This is how I ended up with pango. >> >> But apparently pango is only available with GTK. I have no idea how I >> could render kanji with cairo in the Xaw version then. So the proposed >> change would remove this feature from the Xaw version. >> >> > >> > Guess the etc stuff is not a problem... I just started xboard (just to >> > see if it runs from the tar-ball) and got the pieceImageDirectory >> warning. >> > I was just wondering, if it is worthwhile to add something, so >> > that xboard knows if we run a non-installed version and perhaps looks >> for >> > missing items in the source directory... assuming it was started from >> the >> > source directory. That way you might be able to run a test-version >> without >> > installing it, which could be nice for developing? >> >> Well, even during developing hardly anything ever changes in the files >> that need to be installed. (Adding new piece images is one of the >> exceptions, and I hardly ever do that.) So normally I indeed do not >> install, and just run ./xboard in the tar ball. In the rare case I add new >> components that need to be installed typing "sudo make install" is hardly >> taxing. >> >> A real problem was that new versions keep using the (non-installed) user >> settings file of the previously run version. This used to crash an older >> version after running a newer one that had more persistent options. But >> making encounter of an unrecognized option in a settings file no longer a >> fatal error (skipping to the next line is an acceptable recovery method) >> made that bearable. Switching between Xaw and GTK builds was a problem >> because they used totally different values for the same font options. >> (X-fonts look like "*-*-*-*-*-helvetica-*-*-*", while GTK fonts looke like >> "Sans Normal".) Seeing each other's font settings caused crashing. So I >> built in some code to recognize font settings of the type that would cause >> a crash, and ignore those. That means you lose your font settings when >> running the other build. But when I want to avoid that I simply run as >> "xboard -ini foo", which redirects saving to foo, so that the original >> user settings file is protected from change. Or I immediately switch of >> "save settings on exit" after startup. >> >> H.G. >> >> >> >
