LINUX.ORG.RU

Как готовить кроссплатформенность в GTK

 ,


0

6

Доброй ночи, ЛОР.

Ну начать с того, какую систему сборки использовать, например. Вот в Qt, если без претензий, я могу пользоваться qmake, с ней хорошо всё интегрировано, IDE и все модули. Если с претензиями - можно залезть в cmake. В двух словах: имея Qt SDK, я могу разрабатывать свой проект под линуксом, а потом быстренько сделать сборку под винду, не просиживая в ней слишком много и не затаскивая туда половину линуксового юзерспейса. С макосью чуть похуже, там для работы Qt надо ещё XCode из эппловского магазина поставить. Но больше, вроде, загонов нет.

А как бы аналогичный процесс организовать, если писать на Си с применением GTK, ну и при необходимости, других Gnome-библиотек? Требования те же - пишу под линуксом, потом собираю под виндой, желательно без боли и страданий (ну или с минимумом оных).

Посмотрел я на несколько известных GTKшных проектов. Посмотрел в первую очередь на предмет того, как их собирать под виндой. (Понятно, что в линуксе проблем будет меньше всего.)

Gnumeric - судя по исходникам, используется, Autotools. На сайте в разделе Download висит гордая надпись «We do not currently release or distribute Windows binaries». Тем не менее, в интернетах болтаются какие-то сборки гнумерика под винду, но качать их и рекомендовать знакомым виндузятникам после этого реально страшно: непонятно, кто и как их собирал.

AbiWord - снова Autotools. В документации (docs/build/BUILD.TXT) описано несколько способов сборки, причём под первым номером идёт «Diving make using MSYS and MINGW». Но я не понял, как оно работает, там же сразу в лоб предлагается запускать make, а Makefile где?

HomeBank - ну вы поняли, да. Снова Autotools, и в файлике INSTALL обычные формулировки про ./configure; make; make install. Тем не менее, сборки под винду на офсайте имеются.

Пожалуй, самая содержательная информация оказалась в исходниках GIMP. Тут тебе и инструкция по кросскомпиляции с mingw64. и манифест для Visual Studio...

Здесь анонимус наверняка спросит: а собственно, какое отношение система сборки имеет к GUI-библиотеке? Да формально, конечно, никакого. Только должны же быть какие-то best practice в виде набора не то, что бы связанных, но хотя бы проверенно не конфликтующих с собой инструментов. Ну например: ни в одном из проектов, на которые я посмотрел, не используется cmake. Это случайность или закономерность? Допускаю, что у меня выборка нерепрезентативная.

Далее: если уж при написании GTK-программ путь джедая - это autotools, есть ли какая-нибудь IDE, облегчающая с ними работу? Ну не так, как Qt Creator с qmake, допустим, ну хотя бы частично? Тот же вопрос, кстати, и к cmake относится. Там, конечно, синтаксис попроще, чем у Autotools, но всё же...

Наконец, я припоминаю, что в старых книжках по GTK рекомендовали применять Glade. Да и сейчас на хабре по нему можно найти статьи. Но насколько я понимаю, это не полноценная IDE с поддержкой Си-проекта, а именно средство визуальной разработки UI, т.е. это аналог, скорее, Qt Designer, чем Qt Creator?..

★★★★★
Ответ на: комментарий от hobbit

MSYS2 сегодня наиболее актуальный, используется даже в Git for Windows. Вот, посмотри, как им собирается Emacs-w64, например.

https://sourceforge.net/p/emacsbinw64/wiki/Build guideline for MSYS2-MinGW-w6...

Без всякой Cygwin'овой херни. Собственно, примерно так же, как и на GNU/Linux'ах.

EXL ★★★★★ ()
Ответ на: комментарий от Iron_Bug

И ещё такой пример, про который я забыл в ОП написать.

Допустим, мне надо подключить к программе БД. В сложном (но вполне жизненном) случае - обеспечить поддержку разных БД, чтобы например, клиент-серверный вариант работал с PostgreSQL, а локальный - с SQLite. В Qt я могу такое провернуть, добавив в проект модуль QtSql ( и я так реально делал, работало).

А если я пишу программу с GTK, мне придётся подключать низкоуровневые библиотеки для соответствующей СУБД (libpq-dev или libsqlite3-dev) и если нужна универсальность, нагородить над ними самописный враппер из трёх классов? Ну классов-то нагородить не проблема (правда, на это уйдёт время, и я не уверен, что продукт будет такой же вылизанный, как у троллей).

Опять же под линуксом подключить дополнительные библиотеки не проблема - поставить dev-пакеты и добавить в проект ключиков -l. А что в винде? Там, надеюсь, не придётся хотя бы прописывать в проекте абсолютные пути к библиотекам? Или CMake это за меня решит?

И есть ли GTK-совместимые решения для отображения информации из БД, сравнимые по искоробочности с QSqlQueryModel + QTableView?

Строго говоря, эти вопросы (кроме последнего) опять-таки к GTK прямого отношения не имеет. Просто в Qt это решается тупо добавлением в проект указания на модуль QtSql и включением в дистрибутив драйверов СУБД. Причём файл проекта одинаково выглядит и для линукса, и для винды. (Про OS X врать не буду - под ней я собирал только два кутешных проекта, и ни в одном из них БД не использовались.) Вот и хочется сравнить трудоёмкость и элегантность...

hobbit ★★★★★ ()
Последнее исправление: hobbit (всего исправлений: 1)
Ответ на: комментарий от hobbit

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

что касается баз, я не знаю универсального и тем более кроссплатформенного интерфейса для разных баз. но можно погуглить. наверняка этим вопросом уже кто-то озадачивался. в венде свой огород с базами. там ODBC есть и к ней драйверы прикручиваются. но можно и напрямую библиотеки цеплять. там интерфейс довольно универсален.

на кроссплатформу, конечно, затраты будут. и ifdef'ы будут в коде. и некоторые отдельные файлы для разных систем придётся писать и всё такое. задаром кросплатформа не бывает. ну или только ценой подключения жирных библиотек типа Qt.

ещё лучше сразу провентилировать вопрос с i18n, если планируется. помнится, что раньше с юникодом был гемор в MinGW. как сейчас - не знаю. но если нужно - то лучше сразу проверить, чтобы потом не наступить на грабли.

Iron_Bug ★★★ ()
Ответ на: комментарий от Harald

а чем Cygwin плох?

https://sourceforge.net/p/msys2/wiki/How does MSYS2 differ from Cygwin/

TL;DR: если POSIX не нужен, куда удобнее использовать инструмент, который заточен именно для сборки и имеет нормальный пакетный менеджер (pacman), а не setup.exe с галочками. К тому же в CMake есть генератор MSYS Makefiles.

EXL ★★★★★ ()
Ответ на: комментарий от Iron_Bug

в венде свой огород с базами. там ODBC есть и к ней драйверы прикручиваются.

Это мысль, вообще-то. Даже в линуксах есть некий unixODBC, правда, не знаю, насколько он с точки зрения программиста унифицирован с «обычным» виндовым ODBC. И припоминаю забавный случай: когда я в 2001 (!) году ездил на семинар по случаю выхода Kylix, их спросили: а для БД под линуксом у вас unixODBC используется? Ответ был - «так unixODBC же давно мёртв». Прошло 15 лет, Kylix давно мёртв, а в unixODBC до сих пор какое-то шевеление наблюдается (багфиксы в прошлом году были).

Ну и подозреваю, что деплой приложений будет не совсем незаметный для пользователя, ибо в винде ODBC, помнится, настраивался руками в панели управления.

задаром кросплатформа не бывает. ну или только ценой подключения жирных библиотек типа Qt.

А в чём у Qt жирнота-то? Если QML не тащить и всё делать на виджетах - добавляется несколько so/DLL, не более того. Можно и статически собрать, кстати.

hobbit ★★★★★ ()
Ответ на: комментарий от hobbit

И есть ли GTK-совместимые решения для отображения информации из БД, сравнимые по искоробочности с QSqlQueryModel + QTableView?

нет. даже близкого к искоробочности ничего нет. (но, вероятно, есть какие-то гномо-специфичные компоненты)

waker ★★★★★ ()
Последнее исправление: waker (всего исправлений: 1)

Ну например: ни в одном из проектов, на которые я посмотрел, не используется cmake.

GTK, как и autotools — GNU. единая экосистема.

помимо этого, хотя я не возьмусь судить, каков сейчас cmake (не сталкивался с ним уже несколько лет), но раньше у него было плоховато с портабельностью, кросс-компиляцией, и даже собрать набор взаимозависимых библиотек/программ в префикс, отличающийся от /usr, далеко не всегда получалось.

waker ★★★★★ ()
Ответ на: комментарий от Iron_Bug

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

хехе, значит не один я заметил.

что касается баз, я не знаю универсального и тем более кроссплатформенного интерфейса для разных баз. но можно погуглить. наверняка этим вопросом уже кто-то озадачивался.

да никто не озадачивается этим. щас для этой задачи веб и электрон везде.

waker ★★★★★ ()
Ответ на: комментарий от Iron_Bug

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

Че, правда? CMAKE_MODULE_PATH геморно прописать?

Stil ★★★★★ ()
Ответ на: комментарий от Stil

Че, правда? CMAKE_MODULE_PATH геморно прописать?

если верить документации, эта переменная указывает где искать модули самого cmake ($PREFIX/lib/cmake). по-моему ты либо не понял в чем суть проблемы, либо «слышал звон, да не знаю где он».

waker ★★★★★ ()
Ответ на: комментарий от hobbit

я не использую Qt, но насчёт сборки её в статике не уверена. похоже, что последние версии-таки в статике уже не собираются. по крайней мере из слежения за темами на кроссплатформенном форуме я так поняла. либо это как-то очень нетривиально, потому что никто этим не занимается.

Iron_Bug ★★★ ()
Ответ на: комментарий от Iron_Bug

Всё прекрасно собирается как static так и shared (за исключением модуля qtwebkit, который только shared):

http://mxe.cc/build-matrix.html

либо это как-то очень нетривиально, потому что никто этим не занимается.

Как это никто не занимается? MXE для того и нужен чтобы не изобретать велосипед по кросс-сборке библиотек, а воспользоваться уже готовыми результатами (которые включают необходимые патчи) от сообщества.

anonymous ()
Ответ на: комментарий от waker

В цитируемом сообщении, речь шла о поиске библиотек.

Ты собираешь и устанавливает какую-нибудь либу в /opt. Потом ты запускаешь cmake с доп. переменной CMAKE_MODULE_PATH=/opt, и твоя кастом-либа прекрасно находится и цепляется. Так понятно?

Stil ★★★★★ ()
Ответ на: комментарий от Iron_Bug

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

0_0 А задать PATH/INCLUDE/... сложно? Их вполне достаточно. На крайний случай есть CMAKE_PREFIX_PATH and Co.

На HPC кластерах считай что все пакеты не в стандартных местах разложены. Тупое задание базовых переменных и проблем не возникало.

Под оффтоп не раз собирал пачки библиотек. В каких-то ситуациях было проще сделать dir > CMakeLists.txt. И никогда они не лежали в «стандартном месте».

AlexVR ★★★★★ ()
Ответ на: комментарий от EXL

MSYS2 рулит! Там полно готовых пакетов (qt-any искаропки), да и пересобрать для небольших проектов - не проблема (gtk - относительно небольшой проект). Насчет IDE к MSYS2 - засада. Вроде задача должна быть несложной: взять любимый IDE (Eclipse, qtcreator и тд) и прикрутить MSYS2совский туллчейн(mingw). Но эти IDE обычно понимают MSYS без двоечки. Например, qtcreator мне не удалось сходу настроить на C:\msys64\mingw64\bin, только на C:\msys64\usr\bin. Дебагер заработал, типа как дизассемблер, дальше не стал ковырять, вернулся к hexchatовскому gtk2 девпаку.

anonymous ()
Ответ на: комментарий от hobbit

тоже потыкал, без успеха. Если биться до победы, то конечно за qtcreator. Там вроде среда работает, но сорс код дебагер видит код из дизассемблера. Наверное это не сложно сказать ему (gdb) где исходники лежат, не осилил пока что...

anonymous ()
Ответ на: комментарий от hobbit

детально не сравнивал, поэтому могу только свое скромное мнение. За MSVS - родной современный рантайм - пишут, что они его серьезно перетряхивают последнее время. Сам компилятор тоже крут, среда опять же - супер, вкусняшки (плагины и дополнения в IDE).... хотя qtcreator имеет все необходимое для счастья, я согласен. Сами гномовцы похоже тоже учитывают это и неофициально, но настойчиво поддерживают MSVC. Hexchat-gtk2 меня пока устраивает (забавно, что майнтейнер его, Арнав Синг, вроде в MS работает...). Пересобрать MSYS2 под msvcrt140 наверное не проблема, но.. как обычно, лень, дела и тд... Тем более, что вся виндовая гну - связана. Будем ждать когда цыгвин, вайн и msys2 перейдут на VS2015...хотя прогресс msys2 делает выбор уже не так однозначным...

anonymous ()

используй meson. там кросс-платформенность (для сборки) из коробки.

glade — дизайнер интерфейсов (но тебе нужно его собрать из гита, чтобы получить самые новые фичи).

i_gnatenko_brain ★★★★ ()
Ответ на: комментарий от anonymous

За MSVS - родной современный рантайм - пишут, что они его серьезно перетряхивают последнее время.

Ну это понятно, что родной. Но вот есть что-нибудь, чего у MinGW конкретно не хватает по сравнению с родным? У меня, в общем-то, претензия одна - MinGW под виндой собирает ощутимо медленнее, чем оригинальный gcc под линуксом. Причём, похоже, что тупит не столько сам компилятор, сколько make при просчёте зависимостей. MSVS с теми же исходниками не пробовал, но интерес есть. Других недостатков не замечал.

Будем ждать когда цыгвин, вайн и msys2 перейдут на VS2015...

Ну этим-то как раз есть резон оставаться на MinGW, чтобы было как можно меньше зависимостей от продуктов MS. Может быть, ещё ReactOS взлетит, и тогда эта независимость будет ещё более актуальной (хотя чем дальше, тем меньше надежд, что она взлетит).

А какой-нибудь конечный прикладной проект вроде моего собрать - почему бы и не попробовать...

hobbit ★★★★★ ()
Ответ на: комментарий от hobbit

это и есть рантайм: printf, fstat, fopen и тд.. MS последнее время оптимизирует msvcrt140+ (вроде бы, я не ковырялся там), а мингвшники юзают рантайм от vc6...а сам код gtk - это вестимо просто вызовы win32api, ну или в Qt, там где то еще DirectX в итоге дергается. и очевидные соображения по соотношению сил опенсорса и флагманского продукта MS - Visual Studio -> Qt поставляется в двух вариантах, с виндовым рантаймом и с гнутым.

По поводу ReactOS - не знаю. но по моему скромному мнению, тут тот же принцип работает, ось выбирает юзер. Юзер похоже останется на виндах, если только MS сама не распугает всех своими плитками...

anonymous ()

Что культи, что говнотыки — суть сорта одного и того же говна. Не надо их использовать. Не мучай людей!

Кстати, на чистом опенгле наверняка будет более надежной кроссплатформенность, т.к. mesa есть и под ARM, и под MIPS и наверняка под кучу других платформ. Чего не скажешь о чем-нибудь жирном.

В любом случае кроссплатформенность на низком уровне — это жесть! Куча ифдефов, разное поведение для разных архитектур... Я сам до сих пор одну вещь никак не перенесу на ARM, чтобы можно было телескопом рулить с одноплатника, встроенного в прибор, а не тащить туда огроменную хренотень.

anonymous ()
Ответ на: комментарий от anonymous

Кстати, на чистом опенгле наверняка будет более надежной кроссплатформенность, т.к. mesa есть и под ARM, и под MIPS и наверняка под кучу других платформ. Чего не скажешь о чем-нибудь жирном.

Во-первых, совсем чистым openGL всё равно не обойдёшься. Мой друг, например, делал на openGL движок JFF. В результате он затащил туда SDL - для всякой вроде бы мелочёвки, но которую замучаешься делать руками. Ну например, у него движок был построен на системе плагинов, а в SDL есть кроссплатформенная надстройка над dlopen()/LoadLibrary() (первое, что в голову пришло, не единственное). Это примерно то, что ты писал про кучу ифдефов - вот он решил не городить свою кучу ифдефов, а взять готовую.

А во-вторых, вон, в openGL тоже ломают API, современные версии, как я могу судить, тоже сильно изменились, и не факт, что в лучшую сторону. Сам с нуля на нём не писал (только чужой код правил по мелочи), но если я всё правильно понял, на openGL первой версии можно было гораздо более высокоуровнево работать.

Ну и финальная ломка - вон, уже Vulkan выпускают вместо openGL вообще...

hobbit ★★★★★ ()
Последнее исправление: hobbit (всего исправлений: 1)
Ответ на: комментарий от hobbit

о вкусах не спорят конечно. если кому не нравятся стандартные виджет-тулкиты и хочется видеть сильно кастомизированные окна - его дело. только будут ли пользователи рады, что им предложат вместо любимых ими списков и кнопок, какие то марсианские виджеты, как в игрушках? десктоп ведь используется для работы, а не для развлечения в основном. И да, конечно, основное различие gtk и Qt на низком уровне, что Qt через ангулар(если я правильно помню) юзает DirectX/OpenGL API. Это меня как раз и заставило выбрать gtk. Не уверен, что я оказался прав, но сейчас уже поздно думать, надо ждать нового проекта, где можно будет попробовать Qt...

anonymous ()
Ответ на: комментарий от hobbit

SDL же во всех линуксах одинаков, разве не так? Вот тебе и кроссплатформенность!

Или ты о мастдайке, а не о разных архитектурах?

Если второе, то нафига тебе это говно? Ты еще под гей-ось попиши... Не надо дурью маяться!

anonymous ()

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

Что мешает кросскомпильнуть под линуксом и получить виндовые бинарники? Под windows тебе все равно придется mingw ставить — проще уж одним кросс-компилятором обойтись.

kawaii_neko ★★★ ()
Ответ на: комментарий от anonymous

Или ты о мастдайке, а не о разных архитектурах?

Я и про первое, и про второе :)

Если второе, то нафига тебе это говно?

Мне, положим, оно не очень нужно, а вот людям пригодится.

Я в прошлой теме объяснял, почему я хочу писать именно кроссплатформенную программу (в том числе под винду и макось, да), а не linux-only. И там, кстати, ещё можно комментировать, если не согласен :)

hobbit ★★★★★ ()
Ответ на: комментарий от anonymous

Это меня как раз и заставило выбрать gtk. Не уверен, что я оказался прав, но сейчас уже поздно думать

Ну вот мне уже тоже поздно думать, я для текущего опенсорсного проекта выбрал Qt (давно выбрал, задолго до этой темы). GTK можно было бы попробовать на следующем, но если этот проект будет таким, как я планирую, там потребуется работать с БД, а в этом плане - см. комментарий waker-а.

hobbit ★★★★★ ()
Ответ на: комментарий от hobbit

да, согласен, хотелось бы чтобы все библиотеки уже были собраны и оттестированы в любимом тулчейне, как это делает MS в своих SDK. но если этого нету, а уходить на дотнет или джаву - вера не позволяет, можно попробовать пожить с MSYS2. я на gtk-hexchat только благодаря ребятам(Чен Вей Фан и Арнав Синг). большие проекты типа gimp или inkscape, судя по всему живут под mingw. В Qt сообществе тоже есть мейнстрим (какой нибудь QGis, если говорить про графику мне близкую, про базы данных не знаю), можно смотреть что они выбирают, и в их фарватере рулить вперед.

anonymous ()