Pull to refresh

Comments 49

Её давно пора выкинуть! :)
Да дело даже не в самой винде. мы пользуемся билд-машинами… а они под винду не очень работают

правда есть другая проблема… там еще коло 3 библиотек надосбирать
Ну соль того же билдбота как раз в том, чтобы собирать платформонезависимо. Какие билд машины используете? Посмотрите на организацию сборщика у ScummVM (это отличный пример действительно кроссплатформенного приложения)
мы с помощью биттема (точно не помню, как он завется — у нас админ делает)

дело в том, что нам надо еще и буст
Вроде особых проблем нет, да и не должно быть. Посмотрите в сторону BuildBot'a, к примеру, возможно, решит какие-то проблемы с виндой.
как бы проблем нет — билдится
я тут подумал, что переход на линух с винды невозможен хотя бы потому, что надо тестировать компилируемость кода
Поясните, пожалуйста, зачем? Тестировать под wine будете?
Преследовалось несколько целей. Самая главная из них — централизованная сборка, т.е. кросс-компиляция позволяет нам выделить одну машину (в нашем случае linux-сервер с OpenSuse), на которой осуществляется сборка приложения под все поддерживаемые операционные системы. Таким образом мы избавляемся от гетерогенности, и поддержка процесса сборки упрощается. Тестировать безусловно необходимо в Windows, после сборки приложение тестируется в родных системах.

Представьте — я разработчик и работаю в среде Ubuntu, я меняю что-то в исходных кодах. Теперь мне нужно проверить не сломалась ли при этом приложение в Windows, я просто кросс-компилирую, вместо того что бы держать еще одну полностью настроенную win-машину только для компиляции. Быстрее и удобнее. К слову можно делать кросс-компиляцию из win в nix, естественно.
Хм, насчет сервера кросскомпиляции я с вам соглашусь. Но как насчет идентичности окружения сборки и его влияния на получившийся бинарник? Есть ли какие-нибудь подводные камни?
Думаю есть как и везде. Например версия mingw компилятора из репозитория постоянно отстает от актуальной (не знаю уж насколько это критично). Не могу больше ничего плохого сказать, пока проблем не возникало (уже 4 месяца пользуюсь этой схемой компиляции). Могу предположить что могут быть проблемы если Вы захотите использовать какой-то специфичный функционал Windows, который не поддерживается mingw.
В Генте наоборот, самый последний компилятор в minGW, который опережает по версии тот, что идет в windows SDK.
Если захочется специфичный функционал Виндовс использовать, ну например win7 superbar, то проблемы и с обычным minGW почти нерешаемые возникнут(((
Я пробовал. Подводных камней никаких, в общем-то окружение идентичное — тот же самый ming32, и кстати есть возможность заюзать mingw64 и собирать под win64. А еще приятный бонус: компилятор и Qtшные утилиты навроде moc'а работают из Линукса процентов на 50 быстрее.
ну да — а протестировать работу можно и в виртуалке. Вот чтоб компилить в виртуалке — это надо маньяком быть.
Пользуясь случаем, хочу спросить:
Я начинающий программист на QT. При компиляции и запуске получившегося exe-файла, у меня выскакивает системная ошибка о требовании библиотек. Когда я кидаю в папку с exe-шником необходимые dll-файлы, приложение запускается нормально.
ВОПРОС: Неужели придется таскать за exe-шником эти все примерно 130 Мб библиотек?
Не 130 а ~10 в полной комплектации. И таки да, придется.
Добавлю еще, что как Вы возможно заметили есть библиотеки с постфиксом «d», эти библиотеки нужны для режима отладки, и таскать их с собой не надо, они как раз и составляют большую часть от тех 130 мб ;)
Можете использовать dependencywalker (http://www.dependencywalker.com/), что бы понять какие библиотеки Вам нужны.
Частой практикой является статическая линковка под Windows. Т.о. еще и сама Qt должна быть собрана с ключом -static.
Тогда можно забыть о лицензии своего кода, отличной от LGPL.
Позвольте, а как же Opera (старых версий) и Skype? :)
значит они купили Qt
Библиотека, о которой Вы говорите, называется «Qt». А «QT» — это общепринятая аббревиатура для QuickTime.
Кстати, строго аналогичным образом (но чуть сложнее) создается среда для кросскомпиляции под Симбиан. Работает этот зверек ну раз в 10 быстрее, чем родной SDK, запущенный из под Виндовса.
А Вы не знаете, с чем связана такая медленная работа виндового SDK? А то это ужасно напрягает. Сборка элементарного проекта занимает весьма ощутимое время.
По моим ощущениям тут виноват
1) Крайне тормозной перл
2) Какая-то ерунда с порождением процессов в Винде
3) Эта гадость начинает обсчитывать зачем-то все зависимости для сборки у каждого файла, в то время как в Линуксе она просто берет и пытается собрать.
4) windows SDK однопоточен!
Про многопоточность винды на примере прикручвания нитей к sbcl можете узнать много интересного в блоге широко известного в узких кругах dmitry_vk: dmitry-vk.livejournal.com/tag/win32
Раньше я так делал. Как сейчас, не в курсе.
Я и сейчас так делаю. Возможно это медленнее компилирует, чем описываемый здесь способ, но при установке меньше заморочек.
> Компилятор gcc/g++ 4.4.3 (поставляется вместе с Ubuntu)
На сколько я помню — не в ходит в базовый дистрибутив, а так же ставится с репозитория. Просто его привычно ставим при первой же необходимости.
неужеле в убунту нет способа по проще?
и зачем ставить родное сдк?
в федоре: yum install mingw32-qt mingw32-qt-qmake
Сорри, продолжаю, для запуска:
1. qmake
2. moc
3. uic
4. idc
При юзании системных qmake,moc, etc могут быть грабли, я бы рекомендовал скачать сырцы Qt для нужной платформы и сделать
configure -platform linux-g++ -xplatform нужная спека
После чего руками собрать qmake, moc,uic, и т.д. Остальное уже можно не собирать, а взять из Windows или Symbian SDK.
Вообще, для любых приложений процесс кросскомпиляции (относится как к win-nix, так и к nix-win) сводится к следующему:
1. Компиляция mingw (набор из компилятора, сборщика, ассемблера и прочих низкоуровневых утилит) с вашей платформы на целевую.
2. Компиляция всех зависимостей (ВСЕ библиотеки, включая популярные iconv, gettext, zlib, ...) под целевую платформу.
3. Компиляция самого приложения под целевую платформу.

GNU-тые утилиты и приложения использующие automake и autoconf, позволяют легко сконфигурировать исходники для кросскомпиляции путем задания скрипту ./configure ключей build и target. В самом запущенном случае придется лезть в Makfile'ы и править кое-что ручками.
Пункт 2 сложен, но позволяет получить приложение, в котором вы определяете все параметры сборки, включая static, поддержку nls и прочие.
>GNU-тые утилиты и приложения использующие automake и autoconf, позволяют легко сконфигурировать исходники для кросскомпиляции путем задания скрипту ./configure ключей build и target. В самом запущенном случае придется лезть в Makfile'ы и править кое-что ручками.

В половине случаев гнутый autohell какой-то мрак генерит вместо makefile'ов
Так ведь для конфигурирования и компиляции autohell (не слышал такого варианта, спасибо — повеселили) и не нужен. С ними мучаются разработчики, а клиенту остается лишь наковырять в консоли нужный configure и все…

К примеру для кросскомпиляции с 32 разрядной винды в 64-разрядную будет как-то так: ./configure --target=x86_64-w64-mingw32 --host=i686-pc-mingw32 при том, что minw для 64 разрядной платформы собран и лежит в нужном месте.
Знаю я, что в идеале так, а вот в реальности берет и не собирается((( Я так замаялся в свое время в Генте пытаться кросскомпилить libpurple и так и не смог справиться
Остается еще вопрос как при кроссплатформенной сборке собрать инсталлятор. Будут ли NSIS или Inno Setup нормально работать под wine?
Nsis 100% нормально работает под wine, мы как раз им собираем установщик для win версии. Главное кодировку nsi файла соблюсти (CP1251) и все будет хорошо.
Большое Вам спасибо за статью. За что люблю Хабр, вот только озадачишься какой-нибудь темой, как какой-нибудь добрый человек, вроде Вас, напишет статью и все разжует все :)
Почему QT Creator не компилирует приложения под Ubuntu? Просит компилятор. Как ему его дать?
Qt Creator не является компилятором. Под какой системой ты его запускаешь? Если тоже под Ubuntu, то установи g++.
А после установки g++ как прописать его в настройках QT Creator? ОС — Ubuntu.
Теоретически должен сам подхватить. Если нет, смотри в терминале пути к программам и вписывай.

Например, вот так можно посмотреть пути к g++ и make:
cblp@helium:~$ which g++
/usr/bin/g++
cblp@helium:~$ which make
/usr/bin/make
либо скомпилировать их с помощью кросс-компиляции из исходников (что, как мне кажется, будет очень не просто)


Ух сколько я потратил на это времени… но собрал, но без phonon'а, к сожалению. Мда, в самом деле — не просто. Потом в справочной системе прочитал, что phonon под mingw не собирается. Windows SDK ему подавай.

Only those users with full accounts are able to leave comments. Log in, please.