对于即将推出的项目,计划将在Windows和Linux上编译的现有C ++代码移植到MacOS(leopard)。该软件是命令行应用程序,但可能会计划GUI前端。 MacOS使用g ++编译器。通过使用与Linux相同的编译器,似乎不存在任何问题,但始终存在。
港口期间是否有任何建议或问题需要注意?
答案 0 :(得分:8)
你的应用程序是否有GUI,以及哪一个(native / Qt / Gtk +)?
如果没有,需要注意的问题(与Linux相比)主要在动态链接区域。 OS X使用'-dylib'和'-bundle',实际上有两种动态库(运行时可加载和正常运行)。 Linux只有一种(共享),并且在此方面更宽松。
如果你的应用有GUI,你需要使用Objective-C在Cocoa中重新编写整个内容。这意味着您将成为一种新的语言。有些人(比如MS)使用过Carbon(C ++ API),但它正在逐步淘汰。我不建议新项目。
你最好的运气是使用Qt或Gtk +。几天前(重新)宣布了一个原生的Gtk +端口(见Imendio)。
P.S。 OS X当然也运行X11二进制文件,但是将其推送给任何客户可能是一条艰难的道路。他们已经习惯了Aqua界面,并且很有效率。考虑X11只是一个非常短期的解决方案。
p.p.s。 OS X附带的开源插件库的数量有限,他们的版本可能缺乏。在Linux中,您可以轻松地要求用户安装“libxxx v.y.y”,在OS X中有多种打包方法(fink,macports),而对于商业工具,所需的库应该包含在应用程序中。 OS X为此提供了“应用程序包”和“框架”(本地副本,使应用程序自给自足)。 Linux没有这样的概念。这对你的构建系统也有很大的影响;也许你想为所有平台尝试类似SCons的东西?
答案 1 :(得分:1)
您无需将所有内容重新编码为Objective-C。 C ++和Objective-C有一个奇怪的混蛋,它允许你使用Objective-C中的C ++代码,因此你可以智能地分离C ++中的模型代码和Objective-C中的视图/控制器代码。要使用Objective-C,只需使用.mm而不是.m来填充源代码文件,即使在同一行上也可以混合大多数合法的C ++和Objective-C语法。
答案 2 :(得分:0)
我们还没有移植到MacOS,但是已经从Linux移植到各种Unix,主要的工作区域是安装和启动系统,因此期望将大部分工作放在那里(鉴于已有的已经存在)在Linux和Windows之间移植。)
答案 3 :(得分:0)
Macintosh(macosx)本质上是FreeBSD(虽然它已被调整)。 Linux和FreeBSD之间的系统编程存在一些差异。主要是各种系统调用之间存在这些差异......因此,这对您的影响将取决于您的应用程序正在执行的操作以及您在执行期间执行的操作系统调用类型。