Re: [Jointtrack-devel] Mac OS X Port

[Shang M. <smu...@gm...>]

Jonathan,

Welcome to the project! You might be senior than any of us in the aspect =
of software engineering. Feel free to give advices. See my replies to =
your individual questions below:


----- Original Message -----=20
From: "Jonathan Merritt" <me...@un...>
To: <joi...@li...>
Cc: <ms...@us...>; <yam...@us...>
Sent: Thursday, November 08, 2007 8:36 PM
Subject: Mac OS X Port


> Hi Guys,
>=20
> I'm a post-doc in Marcus Pandy's lab (University of Melbourne), and =20
> I'm interested in creating an OS X port of JointTrack.  (I don't use =20
> JointTrack directly, but others in our lab may do soon.)  Initially, I =
=20
> am targeting an Intel-only build for OS X 10.5 (Leopard).
>=20
> The dependency situation under OS X is as follows:
>     - WxWidgets.  Version 2.8 is actually included with OS X!
>     - ICE.  Zero C provide OS X Intel headers and libraries.
>     - Boost.  Can compile if necessary (haven't checked if your usage  =

> is headers-only).

Right now only the boost string algorithm library is used - so header =
only. We probably will also use Boost serialization library for =
saving/loading project files.

>     - VTK.  Compiles.  (Should work - used by other OS X projects =20
> like OsiriX.)
>     - OpenCV.  OS X instructions here: =
http://opencvlibrary.sourceforge.net/Mac_OS_X_OpenCV_Port
>=20
> I have noticed that your code uses some Microsoft-specific functions =20
> (such as _access() to determine whether a file exists and can be =20
> opened).  In order to get an OS X build working, I will need to swap =20
> these out for cross-platform equivalents.
>=20
> I guess at this stage, I have a few questions:
>     - Is anyone currently working on OS X or Linux ports?  (i.e. am I  =

> duplicating any efforts?)

No.

>     - I plan to set up an XCode project to handle the build.  (XCode =20
> is the free-as-in-beer IDE that Apple provide as part of OS X.)  Is =20
> this OK?

That's OK. Apparently you know Mac much better than us. If that's the =
proper/most usual way to do it under OS X, just do it. That said, maybe =
CMake or other cross-platform tool would serve the job better.

>     - What is your policy on including OS X headers and libraries for  =

> the dependencies (ICE, Boost, VTK, OpenCV) in the JointTrack SVN =20
> repository?  Quite a few other projects (e.g. Blender and OsiriX) do =20
> this to make things easier on developers.

Not sure what you mean. Add header to the dependencies? Or add headers =
to JointTrack source files so that those dependencies work fine?

>     - Are there any major problems you can foresee with the porting =20
> task?

I'm not sure if the following is a problem:
VTK gave me much more pain than any other library. One particular =
problem is "wglMakeCurrent() failed" error (which is not entirely vtk's =
fault). On Windows, an openGL context can only be current to a single =
thread(i don't know if it's the same case on OS X or linux). =
vtkRenderWindowInteractor creates a thread by itself. Apparently in =
JointTrack we need access from other threads for many other tasks like =
change the display mode or switch to another image. In vtk there seems =
to be no easy way to let the interactor thread release its OpenGL =
context, so wglMakeCurrent() fails every time some operation is invoked =
in another thread. But it does not make much sense to derive a class =
from vtkRenderWindowInteractor because it actually has platform-specific =
subclasses called vtkWin32RenderWindowInteractor, etc. To get around the =
problem, I added vtkRenderWindow::IgnoreMakeCurrentOn/Off(), but =
inter-thread function call is needed when a redraw of the window is =
needed: I used SendMessage(WM_PAINT,...). To avoid platform specific =
call like SendMessage(), the only way I can think of is to indiviually =
derive classes from vtkWin32RenderWindowInteractor, =
vtkXRenderWindowInteractor ... in which case things like "#ifdef _WIN32" =
is still needed.

>=20
> Thanks,
>=20
> Jonathan Merritt.
>=20
> PS - I CC'd this to the project admins since I'm not sure whether =20
> you're using your SourceForge devel list.

Because you joined, we officially begin to use the mailing list at this =
moment!


Shang