В предстоящем проекте есть планы перенести существующий код C++, который компилируется в Windows и Linux, на MacOS (леопард). Программное обеспечение представляет собой приложение командной строки, но может быть запланирован интерфейс с графическим интерфейсом. MacOS использует компилятор g ++. Имея тот же компилятор, что и Linux, не похоже, что возникнут какие-либо проблемы, но они всегда есть.
Есть ли какие-либо рекомендации или проблемы, на которые следует обратить внимание во время порта?





Мы не портировали на MacOS, но портировали на различные Unix из Linux, основной рабочей областью были системы установки и запуска, поэтому рассчитывайте перенести большую часть работы на них (учитывая, что ваш существующий уже переносится между Linux и Windows).
У вашего приложения есть графический интерфейс и какой (родной / Qt / Gtk +)?
Если нет, то проблемы, которых следует остерегаться (по сравнению с Linux), в основном связаны с динамической компоновкой. OS X использует -dylib и -bundle и фактически имеет два типа динамических библиотек (загружаемые во время выполнения и обычные). В Linux есть только один вид (-shared), и в любом случае он более свободен.
Если ваше приложение имеет графический интерфейс, вам нужно будет перекодировать все это в Какао, используя Objective-C. Это означает, что вам тоже понравится новый язык. Некоторые люди (например, MS) использовали Carbon (C++ API), но его использование постепенно прекращается. Я бы не рекомендовал это для новых проектов.
Вам больше всего повезет с использованием Qt или Gtk +. Собственный порт Gtk + был (повторно) объявлен несколько дней назад (см. Имендио).
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 для всех платформ?
Да, это действительно правильный путь. Мое «вам придется все кодировать в какао» было преувеличением.
Macintosh (macosx) - это, по сути, FreeBSD под капотом (хотя она была изменена). Есть некоторые различия в системном программировании между Linux и FreeBSD. В первую очередь эти различия существуют между различными системными вызовами ... поэтому то, насколько это влияет на вас, будет зависеть от того, что делает ваше приложение, и от того, какие системные вызовы ОС вы делаете во время выполнения.
Вам не нужно перекодировать все в Objective-C. Существует странная ублюдка C++ и Objective-C, которая позволит вам использовать код C++ из Objective-C, чтобы вы могли разумно разделить код модели на C++ и код представления / контроллера в Objective-C. Чтобы использовать Objective-C, просто добавьте к файлам исходного кода суффикса .mm вместо .m, и вы сможете смешивать наиболее допустимый синтаксис C++ и Objective-C даже в одной строке.
Почему бы не сохранить основной код на C++ и переписать код GUI на Objective-C?