JoshPettus wrote:At the time I had tried replacing it with strdup but i guess there was something else I had to do, or rewrite it
Well, strndup limits the length of the duplicated string to a value given to it as second argument. So strndup(x, strlen(x)) should become strdup(x). It absolutely made no sense to limit the length to a value that is first determined with strlen() from the string itself. Because this is what strdup() already does internally, to determine how much memory it needs to make the copy.
I guess I meant to use <>. I have no idea why it works as I certainly didn't put it in the current directory. Perhaps GCC is just taking pitty on me.
Well, just to be sure, try if it works with <> as well. Then I will put that in the official version.
I just realized when 4.7.3 comes out and ~~/ works, I'd like to get rid of all relative directories. So Id like to switch:
manProc's
system("%s ./man.command", appData.sysOpen);
to
system("%s ~~/../Resources/bin/man.command", appData.sysOpen);
and
infoProc's
system("%s ./info.command", appData.sysOpen);
to
system("%s ~~/../Resources/info.command", appData.sysOpen);
Well, this just displaces the problem, because ~~/ doesn't work by magic. (Not even ~/ works by OS support; XBoard has to peek in the password file to figure out what full path name of the home directory of the user with the current UID is.) The ~~/ patch I have now in master works by replacing ~~ by the value of the symbol DATADIR, which is defined in the command line of the compiler by -DDATADIR='"$(datadir)/games/xboard"', where $(datadir) is a system-dependent path supplied by the configure process.
This mechanism doesn't really meet the needs of the OSX App, where the path is not known at compile time, but depends on where the user installed the App. Because you already set the current directory to that install path in your launch script, the current directory is actually exactly what you want (and thus relative paths are a good solution).
It would probably be good to rethink the way all these platform-dependent things are handled. I am not even sure that options like -openCommand are a good idea, or whether it would be better to rely on #defines in platform-specific headers (like gtk/xboard.h vs xaw/xboard.h). Options can be changed without the need to recompile, but it is not likely that this would ever be needed after install. So in practice the xboard.conf file that comes with the install would determine the setting, and in a binary package would have to be set to the value needed in the platform for which the package is intended. This could be done through hand-editing of the xboard.conf by the maintainer of the package. With #defined symbols in header files it would depend on which header files are included in the build, which would be determined by a ./configure option like --with-xaw. It seems, however, that an OSX-Macports build would use the same files as the Linux GTK build, as the differences are minor, and can be handled conveniently with a few #ifdeffed code sections. This offers the opportunity to put #defines in those segments, but might lead to messy code and cumbersome adaptation if we start supporting even more platforms that share the source files.
Finally the platform-dependent details could be specified through -D... compiler options in the Makefile. As the Makefile is generated by ./configure, this is the easiest way to automatically control their settings. ./configure is supposed to be able to determine the platform it runs on, and details about it, like what 'open' command it supports. Ideally you should be able to download the source tar ball of a new release. type
./configure
make osx-app
and the Mac App package would result. This means of course that all launch scripts and other package components specific to OSX should be part of the source distro, and the Makefile must be aware of their existence and how/where they should be installed.
I agree, that would be ideal. However due to the complexities of bundling with gtk, it could be rather tricky. Gtk-osx-bundler should do this properly, but I haven't gotten it to work, i doubt if it has been tested on macports very well. I hope it doesn't need a jhbuild setup as that just doesn't setup properly on my computer either. It also conflicts with macports, and I need gcc to compile xboard. Apple's Clang has issues.
OK, but keep in mind that 'make' is an extremely powerful tool, and that everything you do by hand by typing commands can in principle be specified in the Makefile to be executed on "make TARGET". Where it would then be smart enough to understand which files are derived from which others, and only execute the commands that were needed to (re-)create the files that were missing or obsolete.
Perhaps you are right, I'm sure it would be a lot of work, and I have no experience with it. But it would have to copy GTK's resources from the main install into the Xboard.app/Contents/Resources/ and somehow set it up appropriately within the bundle, as well as copy any other libs, and then compile xboard against those libs with @executable_path/../Resources/lib, which the OS understands for libraries. And then it can copy xboard's resources into the bundle. If we can setup gtk-osx-bundler correctly then we would have a way for make to do all that.
I don't know if you can fix it but there is one more instability with gtk, but it's easily avoidable. If you accidently resize the board till it's nothing it will instantly crash xboard. Divide by zero perhaps? Is there anyway we can keep it from getting that small?
