> Thanks for your feedback. I've checked out the current CVS, and am taking a
> preliminary look at what's been done, what needs work, what's flat-out
> broken, etc. on the Mac. As I'm doing this, two problems have arrisen:
[Problem number 1 of reading porting documentation]
I am not sure that I would rely on the documentation for the
"port" since there really isn't all that much to go on last
I looked. Really here your best bet is the list, and the
Abi folk themselves. Eric, Paul and Jeff have all taken
turns holding my hand as I've been working on getting the
BeOS port up to speed and it has been much appreciated.
Here is a breif view of porting from my perspective with
the BeOS port, which was similar in style to the unix
port, though the windowing system and gui environment
are worlds apart at times.
1) Check out the source ... which you already have done.
Make sure that you do your best while working on the
framework to do nightly updates since things often change
quickly ... though the guys are pretty good about giving
heads up notice and log messages to the list.
2) Get a basic framework in place for the entire system
by building up the mac tree components until they differ
from their peer platforms (beos/unix/win) as little as
possible. Then once all that is in place, go through and
pretty much empty all of the classes so that all you
really have are headers and empty classes.
At this point you should be able to compile and build
the project into nothing. But it is a good nothing.
You might have to add something to the main, otherwise
most of your code is optimised away =;-)
I think that this is more or less where John Brewer
stopped. He had compiling, non-linking code.
3) Start walking your way through the program starting
at main() and following the path of execution from the
other platforms ... filling in code as you go. Easiest
to leave out the code for installing the menus, toolbars,
statusbars and rulers ... just pretend that they don't
exist and create a window ([X]AP_Mac_App/Frame*
initialize, _create*) with one empty document drawing
area inside of it. This will mean that you will have
to get familiar with the App and Frame classes.
4) Once you have that up and running, for instant
gratification, fill in the Graphics class functions
and then invoke the program with a filename. If
all is right with the world you should get a glimpse
of your first document.
5) Start going back and filling in missing components.
Essentially up until this point you haven't touched
the event tree (abi/src/af/ev) (menu, toolbars, key and
mouse bindings) tree much, only added a few things
to the utility tree (abi/src/af/util) and have emptied
out most of the cross application classes (abi/src/af/xap)
except for the Frame class.
Five easy steps ... I'm still on step 5 so I can't tell
you what comes afterwards =;-)
[How to build/compile]
I think that John had built a project that could be
used with MW. Just for fun I tried this on BeOS when
I first started the port. I used a script to go through
and essentially add everything to the project file that
was either under a BeOS directory (beos) or was cross
platforms (xp). I suspect that that would be the easiest
thing for you to do as well. Just write an apple script
routine that will recursively descend a certain mountpoint
adding all of the .cpp/.c files it encounters. Then
you will likely have to manually add the libpng/zlib and
expat code yourself, lucky for me BeOS supports Makefiles,
so I never really bothered continuing with the project
file. I would stick with the project files though, there
is a place for them in the cvs tree and if that is
what makes sense on a Mac. Just make sure to add the
applescript that you use to do all of the updating
to the cvs tree so that others can use it when they
come along four months from now.
Thomas