1. If we make any progess on porting Cello off win32 I will apply for a separate Cello project here on common-lisp.net. In the meantime, non-Cellists might want to switch to digest mode since I would like (for a week?) to use this list for porting traffic so everyone sees it. I will be a porter (and OSX LispworksTrial) myself, and three others have requested and been sent zips. Speaking of which...

2. Doh! Non-win32 users will need to build .SOs for everything including FTGL. I completely forgot that I had written a few C routines so Lisp could deal with FTGL, which is C++. The source for that will follow as soon as I find it. :)

3. I have started on an effort to carve Cello up cleanly so one can build with just the GLUT and OpenGL and pull in FTGL and ImageMagick as optional add-ons. If any porter would prefer an approach in which they tackle one hurdle at a time, they might want to wait until this afternoon when I hope to get the thing carved up.

4. I will also set things up so a build can be done with the absolute minimum of OpenGL FFI bindings. Part of what is going on here and in #3 is to shrink Cello enough that it will run on the trial version of Lispworks and maybe someday ACL (I think after Cells gets hacked in ways I have planned.)

5. GLUT is a big issue. For one, any GLUT means callbacks from C into Lisp, set up by Lisp calling the GLUT library to identify the callbacks and then give control to Glut. That means the cmucl/sbcl crowd needs recent work on cmucl and sbcl to add that capability. I believe there are two such patches, one by Thomas. Hopefully you all can deal with the cmucl/sbcl lists to work out that issue.

Second, Freeglut has me worried. It hogs the CPU insanely on win32. soon enough I'll go see why and work out a fix, but this is not confidence-inspiring. nor is the bug report I sent in going completely ignored. :) well, at least we have the source. But the reason we use FG instead of Mark Kilgard's original is that that closes down the Lisp IDE when you close any glut window. Not good. There are two fixes.

One is to set an option (see notes below) /not/ to exit to the OS when a window closes. That is how the existing code works because FG was not working (strike three?) when I used the alternative: do not give control to glut by calling glutMainLoop, just periodically call glutCheckLoop (some glut hacks) or (glutMainLoopEvent (I think)) in Freeglut. I see the Aqua glut (my target) on OS X has a glutCheckLoop, and hopefully theirs works, so if you are doing an OS X port I recommend (a) the Aqua glut (not the X11 Glut) and glutCheckLoop. The source has some old polling code commented out--look for glutMainLoopEvent in window.lisp.

6. OK, here are the notes I have sent out before:

I thought of a couple of things, and will merge them in with the other notes so as to have everything in one place. btw, tomorrow I plan to rip out as much as possible so as to get this thing running again under Lispworks trial, then see if I can do a port to OS X myself.

Install notes:

- email Qs at first sign of trouble, don't wait till you are stuck. Even if it turns out in the end to be some typo, i would rather err on that side than have you banging your head for hours on something I could sort out quickly

- to build: if you are on win32 using ACL just use the Cloucell.lpr project. everyone else can use ASDF with some aggravation: find "build.lisp" in the cello directory. That shows the order in which things are to be loaded, and you get to tweak the directory lists to correspond to where you ended up installing. (there are hardcoded paths in the source as well you'll need to hunt down and amend.) Now for the aggravation: my defsystems are derived from the LPRs I use under Allegro. That project manager is smart enough to load things in order whether or not dependencies are made explicit. Not ASDF. So an incremental build will often fail because ASDF first compiles any changed file, at which point only explicit dependencies will have been loaded. I have a 3ghz laptop, so I just change the force-load parameter to t if I get an error I recognize to be related to all this.

- once you have a clean build, the test function is: (starter)

- you need some dynamic load libraries (win32 dlls I use are included) and to change the paths hardcoded into the app. I use "/dev/lib" and I have already been warned that /dev is a system directory on Unix. The runtime libraries you will need are:

GL (OpenGL, that is)

Freeglut or any Glut that accepts the option to exit on window close. In window.lisp, function glutw-create, look for:

(glut-set-option GLUT_ACTION_ON_WINDOW_CLOSE GLUT_ACTION_GLUTMAINLOOP_RETURNS)

You might have to change that if your glut works diff.

FTGL -- should be painless; the developer is an OS X guy

ImageMagick (possibly GraphicsMagick would be compatible)

The source you will need to get is UFFI (tho I could send it to you if necessary). an ASDF.lisp is included. To build using ASDF, oen build.lisp in the cello subdirectory and evaluate forms in the order shown. Note that they will have to be adjusted to yyour directory structure.

kenny