Комментарии 39
Собственно раскидать файлы по целевой системе не проблема — куча мануалов есть. Но при чём тут Qt?
Есть другая, более интересная проблема: приложение на Qt требует библиотек, часто той версии, на которой собрана.
Пусть будут целевые системы Ubuntu 10.04, WIndows 7, Windows XP, пусть на Ubuntu Qt 4.6, на Windows вообще ничего, а приложение собирается под Qt 4.8 — как быть?
Есть другая, более интересная проблема: приложение на Qt требует библиотек, часто той версии, на которой собрана.
Пусть будут целевые системы Ubuntu 10.04, WIndows 7, Windows XP, пусть на Ubuntu Qt 4.6, на Windows вообще ничего, а приложение собирается под Qt 4.8 — как быть?
Qt при том, что это единственный кроссплатформенный фреймворк, который нативно выглядит и быстро развивается. Вариантов не много, либо тащить библиотеки с собой, либо линковать статически.
О достоинствах Qt я не спорю.
Ладно, если тащить библиотеки с собой, как заставить приложение использовать «принесённую» библиотеку, а не установленную в системе?
Ладно, если тащить библиотеки с собой, как заставить приложение использовать «принесённую» библиотеку, а не установленную в системе?
Я одно время написал скрипт, который идёт по зашитым путям до shared либ и меняет их с абсолютных на относительные, например делает ссылку на lib/QtCore, а затем ещё и копирует в эту папку сам бинарь QtCore.
Автор говорит про macdeployqt, я думаю, эта утилита делает то же самое при создании бандла.
Автор говорит про macdeployqt, я думаю, эта утилита делает то же самое при создании бандла.
Линковать статически, если есть такая возможность. Тогда библиотека войдет в состав бинарника.
Думал об этом. Попробовать надо.
Просто библиотек много — сеть, БД, генераторы отчётов всякие, по мелочи там… короче вручную переносить набирается библиотек что-то около 100мб.
Просто библиотек много — сеть, БД, генераторы отчётов всякие, по мелочи там… короче вручную переносить набирается библиотек что-то около 100мб.
Ну, это ваш путь – либо тащить с собой, либо брать те, что есть в системе. При распространении программы как deb и rpm пакеты, есть возможность указать зависимость от библиотек определенных версий. Есть команды, которые умеют устанавливать пакет и автоматически резолвить зависимости, устанавливая нужные библиотеки нужных версий (для deb-пакетов, например, gdebi).
Есть команды, которые умеют устанавливать пакет и автоматически резолвить зависимости
Угу, и это неплохо так ломает пол-системы, точнее весь Qt-софт, работающий на старых версиях :) Сталкивался.
Сейчас выхожу из ситуации путём сборки на разных версиях Qt, и распространяю бинари по пользователям.
На Windows-машины — ручками, кучу библиотек под XP, + другая куча под 7, + бинари так же ручками какой-кому…
насколько я помню, если приложение использует вебкит, то не получиться статически собрать
Если мы сами задаём пути для установки приложения и библиотек, задачу можно тривиально решить аж двумя путями:
- Java-way. Вместо запуска исполняемого файла прописываем ярлык на написанный и установленный нами скрипт, прописывающий LD_LIBRARY_PATH перед запуском.
- Unix-way. Специально для решения этой проблемы есть такая волшебная штука, как RPath. Хорошая, годная поддержка сборки с RPath из коробки есть, например, в CMake (искать по слову «rpath»).
Хм… Первый путь неплох, спасибо.
К слову, тот же CMake (через инструментарий CPack) точно умеет делать при сборке продукта DEB, RPM и инсталляторы под Windows на основе NSIS. Про Mac OS X не скажу, надеюсь, прокомментирует кто-нибудь знакомый со сборкой CMake под OS X на практике.
DEB и RPM мы долгое время делали именно штатными средствами CMake, так что (при отсутствии высоких требований к дополнительным функциям пакетного менеджера) вполне могу советовать ознакомиться.
DEB и RPM мы долгое время делали именно штатными средствами CMake, так что (при отсутствии высоких требований к дополнительным функциям пакетного менеджера) вполне могу советовать ознакомиться.
К слову, Java умеет и второй вариант — CLASSPATH можно прописать в манифесте jar-файла.
как заставить приложение использовать «принесённую» библиотеку, а не установленную в системеТупо расположить в папке с исполняемым файлом? На счет Линукса не уверен, но в винде в первую очередь там библиотеки будут искаться.
Год назад понадобилось написать что–то кросс–платформенное на Qt5, и чтобы были и DEB и RPM сборки, но это оказалось (мне, новичку разработки под Linux) не совсем тривиальной задачей, в отличие от проектов на Qt4. Когда разобрался, персонал экспериенс запостил на qt-project'овскую вики. На английском, но может кому пригодится…
Автор как-то незаслуженно пропустил готовые решения, позволяющие делать кроссплатформенные дистрибутивы. В прошлом проекте использовали InstallBuilder, например. Хотя справедливости ради надо отметить, что с ростом сложности проекта появляется все больше отдельного кода установки под разные платформы.
А он бесплатный? На каких условиях?
В разделе меню сайта Features о Qt-разработчиках говорится отдельно:
А цена Enterprise версии составляет $9 995 (странно, почему не 9 999?).
BitRock has partnered with Qt Software® (formerly Trolltech®) to bring you InstallBuilder for Qt®, the first crossplatform packaging tool specifically for Qt developers. InstallBuilder for Qt includes robust functionality that makes it easy to build complex installers without writing a single line of Java code. With InstallBuilder for Qt you can:
- Generate installers for all supported platforms from one project file, on one machine.
- Build installers using either the GUI development environment or by directly editing a human-friendly XML file that can easily be integrated into your automated build process and version control system.
- Integrate with the underlying desktop environment and package management systems.
- Create start menu shortcuts on Windows systems, KDE/Gnome desktop shortcuts and register with the RPM system on Linux.
А цена Enterprise версии составляет $9 995 (странно, почему не 9 999?).
Не хватает FreeBSD port/package
Спасибо, интересная статья!
Мы в mega.co.nz используем Open Build Service для создания пакетов под основные Linux дистрибутивы. Отличная вещь, на Хабре было пару статей о том как установить и настроить.
Мы в mega.co.nz используем Open Build Service для создания пакетов под основные Linux дистрибутивы. Отличная вещь, на Хабре было пару статей о том как установить и настроить.
Спасибо Вам за статью. Скажите, а как Вы планируете решать вопрос обновления ПО? Рассматривая эту проблему для Windows лично мне больше всего понравилось, как это реализовано у платного продукта Advanced Installer. В Mac OS X видимо на себя эту задачу берет AppStore, а в Linux?
Было бы здорово, если осветить этот вопрос в кроссплатформенном контексте. Конечно интересует вариант, когда приложение переодически самостоятельно проверяет наличие обновлений и выдает сообщение о новой версии с возможностью установить установить его «в один клик».
P.S. а если еще попробовать все это реализовать в системе интеграции (наподобии jenkins etc).
Было бы здорово, если осветить этот вопрос в кроссплатформенном контексте. Конечно интересует вариант, когда приложение переодически самостоятельно проверяет наличие обновлений и выдает сообщение о новой версии с возможностью установить установить его «в один клик».
P.S. а если еще попробовать все это реализовать в системе интеграции (наподобии jenkins etc).
В Линуксе обновление штатно производится средствами управления пакетами в репозиториях дистрибутива (например, в убунте — apt-get). Собственно, больше всего проблем в Windows, потому что там нет стандартизированных средств управления приложениями (магазинов, репозиториев софта), и каждый глумится, как может.
Но ведь apt-get требует root прав? И сначала нужно будет выполнить apt-get update, потом apt-get upgrade (и все это из консоли)?
Получается, что в Linux для обновления только unix-way (если можно так сказать)?
Получается, что в Linux для обновления только unix-way (если можно так сказать)?
Менеджер обновлений сам периодически проверяет обновления для всех репозиториев, и все программы обновляются скопом. Для стороннего ПО минус в том, что кроме пакета придется поднимать еще и репозитории.
Спасибо *ушел читать «Ubuntu for dummies»*
Поднять репозиторий — это не минус, а скорее плюс.
Хочу дополнить — как правило, при этом система запрашивает пароль пользователя, а не рута. Так что и рутовый пароль постоянно вводить тоже не надо.
А по поводу репозиториев — если «стороннее ПО» opensource, можно договориться с разработчиками дистрибутива, и они добавят ПО в свой репозиторий, а так же проследят, чтобы не было конфликтов с другими пакетами, и были все нужные библиотеки.
А по поводу репозиториев — если «стороннее ПО» opensource, можно договориться с разработчиками дистрибутива, и они добавят ПО в свой репозиторий, а так же проследят, чтобы не было конфликтов с другими пакетами, и были все нужные библиотеки.
apt-get требует root прав. То, что для их получения sudo по‐умолчанию спрашивает пароль пользователя — это фишка sudo. Про пароль root в этой ветке до вас не говорил никто, только про права.
Кстати, с разработчиками дистрибутива можно договариваться и для freeware, и даже для платных продуктов. Во всяком случае, я в основном дереве portage (Gentoo) видел все три варианта: тут есть Opera (старая), chrome, nero, пачка игрушек. Но, боюсь, что договориться будет сложнее (разве что вы подпишетесь на самостоятельную поддержку пакета) или невозможно по идеологическим причинам (для дистрибутивов вроде gNewSense).
Кстати, с разработчиками дистрибутива можно договариваться и для freeware, и даже для платных продуктов. Во всяком случае, я в основном дереве portage (Gentoo) видел все три варианта: тут есть Opera (старая), chrome, nero, пачка игрушек. Но, боюсь, что договориться будет сложнее (разве что вы подпишетесь на самостоятельную поддержку пакета) или невозможно по идеологическим причинам (для дистрибутивов вроде gNewSense).
Сейчас наш органайзер запрашивает информацию об обновлениях с сервера, и, при необходимости, выдает ссылку на страницу со списком изменений и кнопкой скачать. Автообновление для Windows делается тривиально, но придется повелосипедить. Если на OS X ставить стороннюю программу не через App Store, то в общем тоже не сложно, делай внутри своего бандла что хочешь. Под линукс штатное обновление будет работать только если подключен репозиторий, а это дополнительные заморочки, по крайней мере на первом этапе. Чтобы обойти нехватку прав можно либо написать демона, который будет в автозапуске от рута, и передавать ему команды, скажем через D-Bus. Еще один вариант — хранить бинарник в домашнем каталоге, а в /usr/bin просто линк на него.
— комментарий перенесен --
Без обид конечно, но я думаю, что под линукс надо распространять сурцы, если это возможно. А под конкретный дистр уже сами пользователи соберут, как им надо.
PS мейнтейню istodo в archlinux
PPS К слову, для меня, как для одного из мейнтейнеров арча, наличие исходников приложения является довольно значимым фактором для переноса пакета в офф.репы.
PS мейнтейню istodo в archlinux
PPS К слову, для меня, как для одного из мейнтейнеров арча, наличие исходников приложения является довольно значимым фактором для переноса пакета в офф.репы.
Советую еще обратить внимание на Ruby gem fpm: github.com/jordansissel/fpm
Умеет собирать, в том числе, deb, rpm, tar и pkg и конвертировать одно в другое. Сборщик deb там реализован свой, а для rpm такой реализации нет, поэтому всё равно нужно будет устанавливать rpmbuild.
Умеет собирать, в том числе, deb, rpm, tar и pkg и конвертировать одно в другое. Сборщик deb там реализован свой, а для rpm такой реализации нет, поэтому всё равно нужно будет устанавливать rpmbuild.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Кроссплатформенное приложение на Qt: Распространение