[cells-devel] Portacello

[Kenny Tilton]

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