Re: [XBoard-devel] new developer release out

[h . g . muller]

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 <address@hidden> 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, <address@hidden> 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.
>>>
>>>
>>>
>>>
>>
>