Qt+Xcode = ?

lexa - 26/Мар/2012 18:42

Делаем так:

qmake -spec macx-xcode somefile.pro
Дальше напускаем туда (на получившийся pbproj) Xcode 4.2, Xcode с грохотом падает. Ну то есть известная проблема, как выясняется, но ведь ей минимум полгода?

Качаю Xcode 3.2 (4гига однако, еще где-то час).

Чтобы два раза не вставать. Я правильно понимаю, что если я соберу некий варез как 64-битный, то он не будет работать на Intel Macs с Core Solo (т.е. на очень старых Mac Mini) ну и естественно на PPC. А на всех остальных - будет, независимо от битности ОС, верно?

Comments

dmarck (not verified) - 26/Мар/2012 18:47

Сколь я понимаю, MacOSX использует Symbol Versioning, так что работать будет начиная с той версии MacOSX, для которой подходят все используемые библиотеки, плюс все более поздние.

64-битные библиотеки точно есть в Lion Leopard, а вот есть ли в Tiger, не помню.

lexa - 26/Мар/2012 18:49

Ну вот Xcode 4.3 (на другой машине) мне накачал миллиард всяких SDK для 10.5, 10.6 и так далее (а 10.4, честное слово, меня не волнует).

Подозреваю, он умеет собрать под точно указанную платформу.

motto (not verified) - 26/Мар/2012 19:50

в макосе нет "битности ОС"
там "есть" "битность ядра", независимо от которой твой варез вроде бы должен работать

кроме старых макмини (не только соло, но и "коре НЕ 2 дуо" вылетает очень немного старых макбуков

mblsha (not verified) - 27/Мар/2012 10:58

Надо собирать Universal / Fat Binary с 32-битным и 64-битным кодом внутри. Компилятор / линковщик понимает ключики "-arch 386 -arch x86_64". Указывать их надо оба одновременно, или в настройках проекта Xcode можно выбрать нужные архитектуры. Еще нужно не забыть про MACOSX_DEPLOYMENT_TARGET оно отвечает за минимальную версию ОС под которой программа будет запускаться. Тоже можно установить в настройках проекта.

lexa - 27/Мар/2012 11:12

Это то я прочитал уже.

Но. Вот есть Qt 4.8.0, которая раздается в 64-битном виде

Ну то есть понятно, можно пересобрать, под виндой я даже пересобирал раньше (потом бросил). Но вот динамические библиотеки - они тоже бывают дуальной архитекруты?

Начну с 64 бит, а там посмотрим.

mblsha (not verified) - 27/Мар/2012 11:20

Динамические и статические библиотеки тоже бывают несколькоархитектурными. При желании вполне можно одновременно сделать i386, x86_64, ppc и ppc64 :-)

lexa - 27/Мар/2012 11:40

А все-таки x86_x64 будет ли работать на старом МакМини (процессор 64-bit capable, графика - интел).

А то вот стращают, что с интеловской графикой отдельная засада...

J0hn - 28/Мар/2012 04:53

CMAKE_OSX_ARCHITECTURES=ppc;i386;ppc64;x86_64

Не используете CMake (http://blog.lexa.ru/2010/11/11/libraw_0112.html#comment-13606) ? почему?

Зачем XCode, только для сборки?
Если именно как IDE - посмотрите QTCreator - http://blog.lexa.ru/2011/07/17/linux_vs_freebsd.html#comment-18893 .

Мой варез собирается CMake'ом на Windows/Linux/MacOS без проблем. Причём там есть и QT проекты.

lexa - 28/Мар/2012 08:57

CMake не использую потому что он какой-то совершенно безумный. То есть на Linux/итп в любом случае нужен configure (да и просто вменяемый Makefile мне несложно написать). А на других платформах от Cmake какое-то сплошное огорчение. Помню, пытался clang/llvm собрать под виндой и если с llvm получилось, то на clang оказалось проще забить.

По первой строчке - это означает, что мне нужно пересобрать Qt с таким же набором архитектур, правильно? Бинарный Qt 4.8 - только x86_64 вроде бы....
Тогда я пока потерплю, а дальше будет видно.

J0hn - 28/Мар/2012 09:09

То есть на Linux/итп в любом случае нужен configure (да и просто вменяемый Makefile мне несложно написать)

Зачем configure?

А на других платформах от Cmake какое-то сплошное огорчение. Помню, пытался clang/llvm собрать под виндой и если с llvm получилось, то на clang оказалось проще забить.

Вам просто такие случаи попадались, поэтому и впечатление такое сложилось.
Там скорей всего проблема в настройках CMakelists.txt этих проектов или в исходниках, а не в самом CMake.
Например я как-то пробовал собрать один проект под Windows, который на нём не тестировался. CMake отработал нормально, но в паре мест пришлось подправить CMakelists.txt, в паре - исходники, просто проект совсем не тестировался. Но это же не проблема самого CMake
Свой же CMake проект поддерживать в здоровом состоянии не трудно.
Я за последние несколько лет максимум где-то один раз создавал проект VS'ом. Мне намного легче CMake использовать.

По первой строчке - это означает, что мне нужно пересобрать Qt с таким же набором архитектур

Это зависит от того как он у вас используется - если статически/динамически линкуется, то да - нужны те же архитектуры.

lexa - 28/Мар/2012 10:13

configure затем, что просят трудящиеся. Сам я просто Makefile использую и счастлив. Это на Unix.
А на Windows - Qmake. Тоже тот еще подарочек, но в сравнении с CMake понравился куда больше (в частности тем, что создаваемые им VS-проекты - независимы от абсолютных путей).

J0hn - 28/Мар/2012 11:00

configure затем, что просят трудящиеся. Сам я просто Makefile использую и счастлив. Это на Unix.
а чем CMake не configure? сделайте configure который вызывает CMake.
или он не на всех машинах есть, и добавить в зависимость его нельзя?

А на Windows - Qmake. Тоже тот еще подарочек, но в сравнении с CMake понравился куда больше (в частности тем, что создаваемые им VS-проекты - независимы от абсолютных путей).

Наверное, то что они абсолютные вписывается в общую концепцию - так как они генерируются в зависимости от системы, её настроек. это как configure.
Для проектов CMake не принято передавать сгенерированные файлы. Аргумент про заказчика, который хочет именно проект студии, и не хочет научится его генерировать через CMake не убедительный - наши заказчики не жужат - мы им картинки даём.

lexa - 28/Мар/2012 11:18

Cmake конечно не везде есть, конечно добавлять его в зависимости - грешно, configure под Linux почти обязателен.

Я же сужу с практической точки зрения:
- сделал ./configure - поток вопросов "а как мне собрать и поставить LibRaw на такой-то системе" упал почти до нуля (вот недавно про андроид было, но там проблема с shared lib versioning, оказалось там не все как у людей)
- положил в комплект проекты для Visual Studio 2008 - и этот поток вопросов ("как мне собрать под виндой мое приложение с вашей DLL") - упал до нуля.

При этом, во втором случае, мне проекты были нужны независимые от путей на диске - и Qmake мне их сделала.

Отчего я пребываю в полном незнакомстве с Cmake и очень рад, что могу что-то не знать

J0hn - 28/Мар/2012 15:46

А QMake вам dmg для MacOSX сделает? а nsis скрипт?
(может и сделает, я действительно не знаю)

lexa - 28/Мар/2012 16:11

dmg - сделает (сам охренел!).
Причем правильный, Frameworks скопирует и все такое. Правда мне нужно туда еще нагадить всячески, поэтому в реальной жизни смысла нет.

Тоже и с NSIS (я побоялся им пользоваться, но это другой вопрос) - чтобы сделался полноценный инсталлятор, нужно помудохаться (подписи там всякие, генерация актуального мануала вордом). Ну то есть можно и это поручить cmake, но работы то столько же.

J0hn - 28/Мар/2012 17:17

ну да, я в dmg тоже всякого напихал,
даже фоновую картинку папки настроил(там где перетаскивать надо, в смысле типа инсталляция) - там она совсем по-идиотски задаётся.

тут экономия получается когда вы делаете и nsis и dmg и rpm и т.п- часть параметров конечно нужно всё-равно задавать для каждого типа, но большая часть инфы между ними разделяется.

lexa - 28/Мар/2012 17:23

Не-не, общего там - имя сделанного исполняемого файла. Ну может еще имя файла README и Copyright.Больше вообще ничего похожего. Рантайм класть разный (и по разному).