On May 1, 2008, at 11:33 AM, Garth Corral wrote: > > On May 1, 2008, at 10:57 AM, pgeorges wrote: >> Garth Corral a écrit : >>> Hi all, >>> >>> Work that needs to be done: >>> 1.) Clean up the patch to catch and problems regressions on windows/ >>> unix. I'm sure there are nits in there as I have not extensively >>> tested it on OS X nor unix (I don't have a windows box on which to >>> test). >>> >>> >> Hi, >> >> After clean up and tests you can send the changes to me so I will >> try >> to find issues with other platforms. > Sure, no problem. I should have something in the next day or two.
Okay, I have a patch that is in reasonable shape with the menu changes I described. I've tested it on both OS X and Unix/X, but not extensively; I have not tested it at all on windows. It applies cleanly to the head of the cvs trunk as of a few minutes ago. At one point it applied cleanly to 3.6.23 but that is no longer the case. In addition to the menu changes, there are a couple of small changes around scidShareDir to accommodate installation of an application bundle in an arbitrary location; scidShareDir was set to a static value of /usr/local/share/scid in the configure script. I have changed it for unix only to be set at runtime to a share/scid directory where share is a sibling of the directory in which the scid excutable resides. The net effect of this is that if this is installed in /usr/local/bin as is assumed now, then the share dir will be /usr/local/share/scid as it is now. If on the other hand it is installed elsewhere but the structure remains the same, /opt/local (darwinports) or /usr/sw (fink) for example, then it should still work. This is needed to have an application bundle that is standalone and can be installed anywhere. On that note, there are also a few changes in Makefile.conf.darwin to accomodate this further, though there is still much work needed in the makefiles. I wish that i didn't have to segregate the makefile changes and add to the proliferation of makefiles, but the configuration system isn't general enough to support a single makefile in its current state. The makefile changes include: A scid_app target which depends on scid_all and will build an application bundle inside a ./dist directory. This is a double- clickable app that (in theory) can be installed anywhere. This is NOT a universal binary. Building a universal binary is a bit involved on the command line, so until I can get around to working this out, a separate app is needed for intel and ppc. A scid_dmg target which depends on scid_app and will build a dmg file containing only the newly built Scid.app. I used a non-existant $ (SCID_VERSION) macro in this target so until I can get around getting configure to do something with this, it would need to be invoked like so: make SCID_VERSION=3.6.xx scid_dmg This should produce a Scid-3.6.xx-powerpc.dmg (or i386 on intel, of course) The menu/makefile patch isn't enough to build an application bundle, there's also an icon file (scid.icns) that I created from the original, and a plist file (Info.plist) that need to be part of the bundle. I've included these plus an extra patch for crafty-21.6 in a tarball that can be grabbed from http://www.abode.com/scid/scid-2008050503-osx-menus.tar.bz2 This brings up another topic. The scid_app target does not try to build any engines nor include them in the bundle. I'm not quite sure of the right thing to do here. On one hand, I like to install and manage my engines independently, on the other hand I can see the value in having an all-in-one package. One problem for an application bundle, though, is that there these things are unlikely to ever be on someone's path so would require special configuration in the engines window. If any mac users want to try this out they can (SEE NOTES BELOW FIRST): cd <somewhere> curl -O http://www.abode.com/scid/scid-2008050503-osx-menus.tar.bz2 cvs -d :pserver:[EMAIL PROTECTED]:/cvsroot/scid2 co - d scid scid2 # be sure you've logged in tar xjvf scid-2008050503-osx-menus.tar.bz2 cd scid patch -p0 < scid-2008050503-osx-menus.patch mv Makefile.conf.darwin Makefile.conf # Yuck ./configure make scid_app That's it. There should be a ./dist/Scid.app. Double click in the finder and try it out (See notes first). There are definitely residual issues due to the difference in deployment but it's a start. There are no engines in this bundle. If you want to install them you should be able to just make all_engines and make install_engines to install them in /usr/local as before. I've not tried this. If folks would like them in the bundle I'll need to think about the best way to do that. Notes: If you have saved options in ~/.scid it is possible that the application bundle will complain about various paths (books, bases) depending on where those were set and whether the directories are still around. It might be a good idea to save that stuff off somewhere first anyway, in case something goes horribly wrong. If you have another tcl/tk on your path ahead of the system's, the ./ configure step will likely get the wrong info and you may need to hand edit the resulting Makefile. Neither crafty 21.6 nor phalanx build out of the box on OS X (crafty does on ppc only). Both are easy fixes. The fix for phalanx is in the darwin makefile but crafy required trivial changes to the crafty source. The crafty changes are in a separate included patch but I don't know the project's preferred approach for managing third party source. If you are expecting this to magically transform scid into a beautiful Mac app, forget it; this is Tk implemented on top of native widgets. Like all such toolkits, it will look better in some areas and worse in others. It is what it is. Notes for Pascal: In theory there should be no changes required to build on unix (and hopefully windows). Now that I've modified tcl/config.tcl.conf such that the one and only configuration variable in it is gone, the configure script has nothing to do there but it is hardcoded in there that it should do text replacement. I've left this alone. tcl/tools/graphs.tcl still contains all windows line endings as the only change from it's prior version. I ignored whitespace changes when I made the patch so it should apply cleanly but I wouldn't check it in with the line endings that way (assuming one was inclined to check it in at all). Thanks for listening, Garth ------------------------------------------------------------------------- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone _______________________________________________ Scid-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/scid-users
