OSX Xboard 4.7.2 .app

[JoshPettus]

Any news on whats going on? Is there going to be 4.7.3-1 or something to fix these issues?

[JoshPettus]

I'm a tad confused. Isn't ~~/ suppose to point to the directory where the xboard executable is for osx? (I presume this would be the */Xboard.app/Contents/MacOS folder) I set the sysconf dir to ~~/../Resources/etc but that didn't seem to work to find the xboard.conf. (a simple relative directory won't work because we want the working directory to be the default home directory) Also as a test, I went in to the board menu and put this to find the default pieces:
~~/../Resources/share/xboard/textures/default

and no dice.
Perhapse I'm wrong about what
gtkosx_application_get_bundle_path() returns

I also tried, in case it was pointing to the app Root directory (wherever that is)
~~/Resources/share/xboard/textures/default
~~/Contents/Resources/share/xboard/textures/default
which yielded no results. Is there a way we can see what that function returns?

[hgm]

Well, this is easy to check: just insert a line

printf("path ='%s'\n", dataDir);

after the calling of get_bundle_path, and look what XBoard prints in the terminal window from which you start it.

But there might be another problem. The code I added expands the ~~/ at the moment the value of a filename option is processed. Not at the moment when a file is accessed. And SYSCONFDIR only occurs as part of the ini-file name, which again is used as static initialization of an internal XBoard variable. It is never parsed by the option parser. So probably the ~~/ is completely ineffective in SYSCONFDIR. I would have to move the expansion to the point where the file is opened.

[JoshPettus]

Ok. It points to the app bundle (*/Xboard.app) like I half expected, but when I put in
~~/Contents/Resources/share/xboard/textures/default
it doesn't find the -pid

I guess this is due to the problem you mentioned.

[EDIT]
Oh it does work when I launch the bin with -pid ~~/Contents/Resources/share/xboard/textures/default
but not when I type that into the View->Board Menu

[hgm]

Indeed, the dialog entries are also not parsed like command lines, but directly assigned to the internal variables they control. I am not sure we wood need it in the dialogs. Most people would browse to the file anyway, so it is more relevant where the file-browser starts.

[JoshPettus]

You're probably right, as long as it can read and be set in the .conf file, we should be good.

[hgm]

I pushed a new version to hgm.nubati.net (master) that should now refer the settings file relative to the bundle path.

[JoshPettus]

ok great! I had actually gotten my hands on a Macosx10.5.sdk so I'll be trying to see if i can push support for intel macs that use that. I'm not convinced macports will let me, but we will see.

On that note tell arun that we need to make a change in configure.ac

Code: Select all

dnl| add some libs for OS X
  *-apple-* )
    AC_MSG_WARN([Apple support is experimental, please report any problems to bug-xboard@gnu.org])
    AC_PATH_PROG(SW_VERS, sw_vers)
    if test "x$SW_VERS" != "x"; then
      AC_MSG_CHECKING(Mac OS X version)
      MACOSX_VERSION=`$SW_VERS -productVersion`
      AC_MSG_RESULT([$MACOSX_VERSION])
    fi
    case "$MACOSX_VERSION" in
      10.0*|10.1|10.1.*|10.2*|10.3*|10.4*|10.5*|10.6*)
      FRONTEND_LIBS= "$FRONTEND_LIBS -lgtkmacintegration -headerpad_max_install_names mmacosx-version-min=10.6 -isysroot /Developer/SDKs/MacOSX10.6.sdk"
        ;;
      *)
      FRONTEND_LIBS = "$FRONTEND_LIBS -lgtkmacintegration -headerpad_max_install_names"
        ;;
    esac

  ;;
esac

should be just

Code: Select all

dnl| add some libs for OS X
  *-apple-* )
    AC_MSG_WARN([Apple support is experimental, please report any problems to bug-xboard@gnu.org])
    AC_PATH_PROG(SW_VERS, sw_vers)
    if test "x$SW_VERS" != "x"; then
      AC_MSG_CHECKING(Mac OS X version)
      MACOSX_VERSION=`$SW_VERS -productVersion`
      AC_MSG_RESULT([$MACOSX_VERSION])
    fi
    case "$MACOSX_VERSION" in
      *)
      FRONTEND_LIBS = "$FRONTEND_LIBS -lgtkmacintegration -headerpad_max_install_names"
        ;;
    esac

  ;;
esac

As I said before
the point of the 10.6 stuff is for people who have an os later then 10.6, maybe 10.9, who happen to have the 10.6sdk (hard to get these days as xcode got rid of it long ago) and want to set it to compile for that earlier system. Therefor, it's up to the builder to set those flags themselves according to their needs. Maybe they want to build it for 10.7.

People with 10.6 don't need to set the minimum os to 10.6 and use the 10.6 sdk as that's the system it's building on.

And people with earlier then 10.6 don't want it as: A) they don't have the sdk and B) it wont run on their system in the end.

---------------

I have a 10.4 Power Pc G5 here at home. It needs a new keyboard, but I should try and build xboard on it one of these days. not a lot of PowerPC users but I should give it a shot.

[JoshPettus]

lol, it's -mmacosx-min-version=10.6. It was missing a "-" anyway.

[JoshPettus]

Also don't forget the man fix in gtk/xboard.c

Code: Select all

char buf[MSG_SIZ];
snprintf(buf, MSG_SIZ, "%s ./man.command", appData.sysOpen);
system(buf); 

-------

And one more thing, (Sorry to give you so much reading. :\).
I tried compiling the new branch and got this
from args.h

Code: Select all

./args.h: In function 'ParseSettingsFile':
./args.h:914:23: error: expected ')' before string constant
  MySearchPath(DATADIR "/themes/conf", name, fullname); // also look in standard place
                       ^
./args.h:914:23: error: too few arguments to function 'MySearchPath'
In file included from gtk/xboard.c:166:0:
./usystem.h:73:6: note: declared here
 int  MySearchPath P((char *installDir, char *name, char *fullname));
      ^