The error seems to disappear if I hand-edit the Makefile, to add -I/usr/include/pango-1.0
to AM_CPPFLAGS Op Ma, 14 maart, 2016 12:26 am schreef Tim Mann: > 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. >>> >>> >>> >>> >> >
