views:

559

answers:

4

For a upcoming project, there are plans to port the existing C++ code that compiles on Windows and Linux to the MacOS(leopard). The software is command line application, but a GUI front end might be planned. The MacOS uses the g++ compiler. By having the same compiler as Linux, it does not seem like there would be any issues, but there always are.

Are there any recommendations or problems to watch out for during the port?

A: 

We haven't been porting to MacOS, but have been porting to various Unixes from Linux, the main work area has been the installation, and startup systems, so expect to put most of the work there (given your existing is already portable between Linux and Windows).

Douglas Leeder
+7  A: 

Does your app have a GUI, and which one (native / Qt / Gtk+)?

If not, the issues to watch out for (compared to Linux) are mainly in the dynamic linkage area. OS X uses '-dylib' and '-bundle' and in fact has two kinds of dynamic libraries (runtime loadable and the normal ones). Linux has only one kind (-shared), and is looser on this anyways.

If your app has a GUI, you'll need to recode the whole thing in Cocoa, using Objective-C. Meaning you'll be into a new language as well. Some people (like MS) have used Carbon (C++ API), but it's being phased out. I wouldn't recommend that to new projects.

Your best luck is using Qt or Gtk+. A native Gtk+ port has been (re)announced just some days ago (see Imendio).

p.s. OS X does of course run X11 binaries, too, but pushing that to any of your customers might be a hard road. They're used to Aqua interface, and productive with that. Consider X11 only a very short term solution.

p.p.s. The number of open source addon libs coming with OS X is limited, and their versions might lack behind. Whereas in Linux you can easily require users to have 'libxxx v.y.y' installed, in OS X there are multiple packaging approaches (fink, macports) and for a commercial tool the required libraries are expected to be contained in the application. OS X offers 'application bundles' and 'frameworks' for this (local copies, making the application self-sufficient). Linux does not have such a concept. This will have a great effect on your build system as well; maybe you'll want to try something like SCons for all platforms?

akauppi
Why not keep the core code in C++ and rewrite the GUI code in Objective-C?
Ferruccio
Yes, that is actually the way to go. My "you'll have to code the whole thing in Cocoa" was exaggerating.
akauppi
A: 

Macintosh (macosx) is essentially FreeBSD under the hood (though it has been tweaked). There are some differences in systems programming between Linux and FreeBSD. Primarily these differences exist between the various system calls... so how much this affects you will be determined by what your application is doing and what kind of OS system calls you are making during execution.

ceretullis
+1  A: 

You don't need to recode everything to Objective-C. There's a strange bastardization of C++ and Objective-C that will allow you to use C++ code from Objective-C, so you could intelligently split up the model code in C++ and view/controller code in Objective-C. To use Objective-C, just suffix your source code files with .mm instead of .m, and you can intermix most legal C++ and Objective-C syntax even on the same line.