OSX Xboard 4.7.2 .app

[JoshPettus]

Hello

I managed to create an xboard.app for OSX using xboard gtk and OSX's native quartz.

it saves it's conf file in the normal xboard place
~/.xboard.rc

http://www.open-aurec.com/wbforum/viewt ... 19&t=52964

[trojanfoe]

You should sign the app, so OS X will open it by default.

Also (under Mavericks GM seed) when invoked:

Error: first chess program (fairymax) exit unexpectedly,

Note: piece-description file '/Applications/Xboard/Engines/Fairymax/data/fmax.ini' not found.

That's almost certainly because I didn't install the app into /Applications and you have made assumptions about where the App is installed (not sure how you managed to develop it successfully with such assumptions). If you cannot make your app know its own bundle path then you have many problems on the road ahead.

[zullil]

You should sign the app, so OS X will open it by default.

Also (under Mavericks GM seed) when invoked:

Error: first chess program (fairymax) exit unexpectedly,

Note: piece-description file '/Applications/Xboard/Engines/Fairymax/data/fmax.ini' not found.

That's almost certainly because I didn't install the app into /Applications and you have made assumptions about where the App is installed (not sure how you managed to develop it successfully with such assumptions). If you cannot make your app know its own bundle path then you have many problems on the road ahead.

My understanding is that Joshua is not a professional software developer. He has worked for some time to provide this community with a native OS X port of Xboard, one that frees users from needing to rely on XQuartz or X11. So perhaps it's understandable if he made a few mistakes.

I found the tone of your post rather unpleasant. But perhaps that's my problem. Since you seem to know a bit about development under OS X, maybe you could offer Joshua some assistance, without snarky comments like "If you cannot make your app know its own bundle path then you have many problems on the road ahead."

[hgm]

This is a problem in the Fairy-Max engine. The source code of this by default assumes it will find the ini file in its own directory, but this can be overruled by defining INI_FILE externally with a compiler option. The Makefile that is supplied with the fairymax source package does specify such overruling, to the place that is standard for Debian Linux. And even that can be overruled by setting an environment variable INI_F with the make.

Basically there are two ways to do it: the Linux philosophy, where all binaries go into one folder, and their data files go into a completely different, but standard part of the file system tree, and the (old?) Windows philosophy, where all files associated with an app go into the same folder, which you then could put pretty much anywhere.

The use of /Applications/XBoard/Engines/Fairymax/data suggests that you are adopting the Windows philosophy here, and indeed people are trying to install elsewhere. In this case it would be better to specify the ini file not as an absolute path, as the Linux Makefile does, but relative to the engine binary. I.e. use INI_F=data/fmax.ini . XBoard should invoke Fairy-Max with an -fd command to specify the directory of its binary. (In Linux this is pointless, as the directory would always be something like /usr/games, and the engine could find nothing there that it needed. So in Linux only non-compliant engines would need an -fd option with them.) If you want to distribute XBoard and Fairy-Max in one bundle, you should also use the relative pathname to specify the engine directory (-fd Engines/Fairymax or -fd ../Engines/Fairymax, depending on what the default current directory would be when invoking XBoard), which you probably already do (or it would not even have been able to find the Fairy-Max executable when installing in a non-standard place).

(Btw, there is little need to put the fmax.ini file in a separate 'data' directory in a binary distribution; in the source package this was mainly done to provide easy copying of the data files to where they have to go on 'make install'. In the WinBoard binary distribution I simply put fmax.ini in the same folder as fmax.exe.)

[JoshPettus]

You should sign the app, so OS X will open it by default.

I cannot unless I purchase a license, which is not going to happen. There plenty of apps out there that aren't code signed and unlikely to be do so in the near future. It's a simple right click, select "Open," and allow and then you never have to deal with it again. Or change your preferences to allow everything.

Also (under Mavericks GM seed) when invoked:

Error: first chess program (fairymax) exit unexpectedly,

Note: piece-description file '/Applications/Xboard/Engines/Fairymax/data/fmax.ini' not found.

Thank-you, that was my mistake as I had forgotten how I had compiled fairymax. I had thought I had used a relative directory, and was just copying from my previous xboard install. That's an easy fix though. Thanks for pointing it out

That's almost certainly because I didn't install the app into /Applications and you have made assumptions about where the App is installed (not sure how you managed to develop it successfully with such assumptions). If you cannot make your app know its own bundle path then you have many problems on the road ahead.

Well for starter's, I am no programer. I studied music composition in college. If someone with more skill, ability is willing to do what I have done, they are more then welcome to do it. But so far no one has ever come out of the woodwork to even try. I'm just exploring the possibility.

[JoshPettus]

@ H.G.M

Thanks for your help but unfortunately I am inexplicably having difficulty setting a relative path. I have tried

cc -O2 -s -DINI_FILE=\"data/fmax.ini\" fairymax.c -o fairymax
or
cc -O2 -s -DINI_FILE=\"./data/fmax.ini\" fairymax.c -o fairymax
or
cc -O2 -s -DINI_FILE=\"./fmax.ini\" fairymax.c -o fairymax
or
cc -O2 -s -DINI_FILE=\".\" fairymax.c -o fairymax

In any case fairymax can't find its .ini file. Absolute paths work fine, but as you noted that's not what I need.

[hgm]

This must happen because for the default engine, XBoard does not assume a default directory. In Linux this is not needed, because the engine is in a directory that is in the search path.

I guess the solution is to use the master settings file to specify the directory of the default engine: put an -fd Fairymax (or ../Fairymax) in the xboard.conf somewhere (and I guess also a -sd). The problem is that when people would start XBoard from the command line with a command like

xboard -fcp crafty

then Crafty would run in the Fairy-Max directory, and make its log files there, rather than in '.'. I don't know if OSX people would run from the command-line very much, though.

This would require some rethinking of how XBoard handles the default engine.

[JoshPettus]

Oh i didn't even try to plug it into xboard. I was trying to launch the engine directly via the command line and got the errors. If it doesn't work there i fail to see how it could suddenly work in xboard. Is there something else I should be using instead of "." to signify the executable's own directory?


Once fariymax knows where it's .ini is, xboard will work just fine. It does recognize the fd being "." which is what I compiled it as, editing the xboard.h before compile, because fairymax is in the same directory embeded inside the app.

[hgm]

Well, '.' means the directory where you are when giving the command.
If ./fairymax would start Fairy_max, then it should be OK if from that point "cat ./data/fmax.ini" would show you the contents of the ini file, and INI_FILE would have been set to ./data/fmax.ini (or, equivalently data/fmax.ini).

That does not mean that XBoard could run it without an -fd command pointing it to that directory, however. Because you might have started XBoard from another directory.

[JoshPettus]

Ahh, your right, of course!

Thanks, well I'll have a fixed app up in a few minutes then
But you're right, there could be some issues. But given the current setting I doubt it would come up. I'm trying to make it to avoid command line (hence pre-configured ics launch scripts) and when they use the menu to select an engine on their system it will be an absolute directory.