LINUX.ORG.RU

Cтек для разработки Qt-приложений с использованием Premake

 , , ,


0

3

Сегодня я опубликовал релизы трех компонентов для разработки Qt-приложений с использованием системы сборки Premake:

qt-support.lua 1.0

Это аддон для Premake, позволяющий использовать Qt в Premake-проектах. Qt-специфичная кодогенерация осуществляется автоматически - просто добавьте все исходники, заголовки, *.ui, *.qrc. и *.ts-файлы в список files!

Поведение qt-support.lua практически полностью совпадает с поведением qmake, позволяя практически безболезненно осуществлять миграцию. В отличие от qmake, по умолчанию генерируемые мейкфайлы переносимы, т.е. вы можете распространять их вместе с исходным кодом вашего приложения.

Документация

Ограничения

  • Требуются патчи для Premake (см. релиз ниже)
  • Поддерживается только GNU make
  • На Mac OS X поддерживается только конфигурация Qt в виде фреймворков
  • Следующие модули Qt пока не поддерживаются: ActiveQt, QtDBus, QtDesigner, Phonon

Загрузки

Файл включен в состав дистрибутивов Premake 4.4-qt-beta1


Premake 4.4-qt-beta1

Это неофициальный релиз Premake, содержащий патчи, необходимые для работы qt-support.lua

Загрузки (пакеты включают qt-support.lua)


PremakeProjectManager 0.2

Это плагин для среды разработки Qt Creator, добавляющий нативную поддержку проектов premake4.lua. Просто откройте в Qt Creator файл premake4.lua с конфигурацией вашего проекта, и вы сможете работать с его файлами, а так же компилировать и отлаживать проект! Плагин работает с Qt Creator 2.3.x и 2.4.0 (в составе Qt SDK или отдельно от него); более старые версии и master не поддерживаются.

Новое в версии 0.2

  • Поддержка ОС Windows
  • Поддержка Qt-проектов
  • Генерируемые файлы скрыты по умолчанию
  • Работает выбор тулчейна
  • Работает парсинг выдачи компилятора
  • Поддержка Qt Creator 2.4
  • Удалена поддержка Qt Creator 2.2

Загрузки

Буду рад выслушать конструктивные пожелания и предложения по программам и документации.

Форум Premake на Лоркоде

>>> Подробности

★★★★★

Проверено: DoctorSinus ()

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

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

Он известен и лежит во встроенной переменной _PREMAKE_COMMAND

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

Все легко переопределяется установкой переменных make.

Всё что? Тесты сборки, отключение модулей, к которым нет хидеров, установка define-в зависимости от архитектуры и т.д.? Тогда тем более не понятно, зачем нужен premake. Честно, я всегда думал, что этим система сборки должна заниматься, а не криворукий пользователь.

anonymous ()

с использованием системы сборки Premake:

Зачем этот мазохизм?

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

Ну и мы с вами не на научной конференции :)

А научность здесь ни при чем. Если игнорировать опыт предшественников, то гарантированно наступишь на истоптанные грабли. Зачем еще один уродец в дополнение к десяткам существующих?

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

Зачем еще один уродец в дополнение к десяткам существующих?

Premake очень просто устроен внутри, и его очень легко расширять без добавления каких-либо костылей в основной код. На мой взгляд, у Premake очень хорошая комбинацияя KISS-устройства и удобства использования.

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

Если игнорировать опыт предшественников, то гарантированно наступишь на истоптанные грабли.

Я его не игнорирую, а стараюсь всяечки учитывать. Даже autotools изучаю, хоть и не приходилось с ним работать.

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

отключение модулей, к которым нет хидеров

В данный момент это out of scope. Софт должен собираться со всеми возможностями, предусмотренными заданной конфигурацией.

установка define-в зависимости от архитектуры и т.д.?

А вот это не трудно, задай DEFINES и все. Если ты про стандартные варианты типа x86 vs x86_64, то даже проще: make config=release32 или make config=release64

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

Нет тула, кроме автотула, и Столлман пророк его. А как хвалили CMake! Autotools - наше всё. На типовых задачах удобен, и при необходимости позволяет хоть наизнанку вывернуться.

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

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

Не дружит с MSVC, для некоторых задача это фатально. Вряд ли когда-нибудь будет поддерживать ninja, так как прибит гвоздями к GNU make.

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

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

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

Путь к системе сборки и пути сторонних либ никак не связаны.

Опять не понял. Речь идёт о библиотеках, про которые premake должен знать. Не всегда они находятся в стандартных местах. Плюс ещё дефолтный набор флагов. Вот захочу я, скажем, линковать с -Wl,--no-unused. Или мне их каждый раз указывать, или прописать в конфиги, как это делается в cmake.

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

Речь идёт о библиотеках, про которые premake должен знать.

В общем случае вариант 1 тут сливает, в частных (когда инфу можно запросить из мейкфайла через qmake, pkg-config и т.п.) все решается. В следующих релизах планируется поддержка autotools как одного из вариантов выхлопа.

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

В данный момент это out of scope. Софт должен собираться со всеми возможностями, предусмотренными заданной конфигурацией.

гентушники тебя побьют.

А вот это не трудно, задай DEFINES и все. Если ты про стандартные варианты типа x86 vs x86_64, то даже проще: make config=release32 или make config=release64

Речь идёт про автоопределение. Запустил я, скажем, на x86_64 и система сборки сама узнала, что у меня за система и выставила нужные флаги. Или, скажем, нашёлся хидер программы libABC вместо libADC и с помощью define-ов подключился нужный код.

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

гентушники тебя побьют.

придется написать eclass, чтобы не побили :)

Речь идёт про автоопределение. Запустил я, скажем, на x86_64 и система сборки сама узнала, что у меня за система и выставила нужные флаги. Или, скажем, нашёлся хидер программы libABC вместо libADC и с помощью define-ов подключился нужный код.

В файле проекта такие проверки организовать довольно просто, при этом, естественно, потребуется наличие premake4 на целевой системе. Да, как у CMake.

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

В общем случае вариант 1 тут сливает, в частных (когда инфу можно запросить из мейкфайла через qmake, pkg-config и т.п.) все решается. В следующих релизах планируется поддержка autotools как одного из вариантов выхлопа.

Каков в нём смысл? Если тащить с собой autotools, то проще им вообще всё собирать. configure.ac и Makefile.am имеют тривиальный синтаксис. Да и с кроссплатформенностью лучше. ./configure отработает везде, где есть sh.

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

Каков в нём смысл?

См. мои аргументы выше.

1)меня не устраивает autotools в качестве основного инструмента разработки (для однократной сборки на стороне пользователя сойдет, но не более)

2)не дружит с MSVC, плохо дружит с виндой в целом

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

меня не устраивает autotools в качестве основного инструмента разработки (для однократной сборки на стороне пользователя сойдет, но не более)

Тогда зачем ты его хочешь поддерживать? Делай всё средствами premake. Тем более сам же говорил, что скрипты на LUA простые.

не дружит с MSVC, плохо дружит с виндой в целом

mingw/cygwin/msys + vim. Ни каких проблем. Вообще.

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

В файле проекта такие проверки организовать довольно просто, при этом, естественно, потребуется наличие premake4 на целевой системе. Да, как у CMake.

Ясно. Ладно, подведу итог сего разговора.

Минусы:

1. Как и в cmake, наличие premake при сборке на целевой платформе является необходимым.

2. Отсутствует функционал по части поддержки pkg-config и многих других необходимых вещей.

3. Необходимость изучать LUA.

4. Проект к применению не готов, а имеет исключительно академический интерес.

5. До конца не ясна ситуация с автоматическим поиском библиотек, тестовых сборок и т.д.

6. Бедновата документация, если сравнить с тем же cmake.

Плюсы:

1. Заявлен более простой синтаксис.

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

Тогда зачем ты его хочешь поддерживать?

wxWidgets его хотят, мб перейдут с bakefile к нам.

mingw

MinGW != MSVC, они разные, у каждого свои достоинства и недостатки

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

Проект к применению не готов, а имеет исключительно академический интерес.

Ну почему же, я его применяю, и в очень даже практических целях. Правда для разработки проприетарного ПО.

Остальное справедливо.

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

Черт, а я баш поверх навесил для кросс-комплияции:)

но надо сказать, у меня файл, который генерила premake в студии не работал вообще. Пришлось генерить файл для 10 студии, затем конвертировалкой перевести в файл студии 6.

Кстати меня интересует сборка у конечного пользователя, особенно поиск зависимостей, как он сделан?

Когда я искал систему сборки «для себя» понял, что все эти autotools и cmake просто неосиляемы в рамках пяти минут. autotools форменный ппц, нагромождение шелла. cmake - какой-то синтаксис вообще свой придумали. С premake разобрался что к чему за полчаса, теперь использую во всех проектах:) Благо к луа отношусь хорошо. Если он будет нормально генерить проектные файлы, читаемые в любой системе - можно распространять проект без самого premake, очень удобно. Главное вот интересует чтобы конечному пользователю выдавались не ошибки компиляции, а каких библиотек не хватает, а то когда мне такие сырцы попались я минут 20 пытался понять почему он не собирается - оказалось нет хедеров, и при этом ни слова мне не сообщалось.

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

но надо сказать, у меня файл, который генерила premake в студии не работал вообще. Пришлось генерить файл для 10 студии, затем конвертировалкой перевести в файл студии 6.

пример в студию^Wбагтрекер :) Это давно было? Нужна была именно 6-ая студия? (в Premake 4 ее выпилили, ибо древность)

Главное вот интересует чтобы конечному пользователю выдавались не ошибки компиляции, а каких библиотек не хватает, а то когда мне такие сырцы попались я минут 20 пытался понять почему он не собирается - оказалось нет хедеров, и при этом ни слова мне не сообщалось.

К сожалению, сейчас об этом должен заботиться тот, кто пишет проектный файл.

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

пример в студию^Wбагтрекер :) Это давно было? Нужна была именно 6-ая студия? (в Premake 4 ее выпилили, ибо древность)

Да, достаточно давно, я тогда пытался собрать движок под винду, тогда ещё неосилил кросскомпилятор (и не мог никак найти .lib библиотеки именно для gcc, так как использовались редкости вроде devil и physfs). Сейчас от зависимостей избавился, а devil юзаю через ffi, то есть оно вообще не коннектится к сишному коду, только к луа.

К сожалению, сейчас об этом должен заботиться тот, кто пишет проектный файл.

Пока у меня мало зависимостей, но хочется чтобы на будущее возможность присутствовала. Ведь я же составляю массив libs, на его основе в принципе можно генерить мейк файл в котором будут производиться все поиски через тот же pkg-config.

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

Пока у меня мало зависимостей, но хочется чтобы на будущее возможность присутствовала. Ведь я же составляю массив libs, на его основе в принципе можно генерить мейк файл в котором будут производиться все поиски через тот же pkg-config.

На версию 4.5 запланирована поддержка usage'ей (usage - это тот же project, но для внешнего проекта; сейчас они уже есть, но не документированы, API может измениться). Постараюсь сделать для 4.5 импорт usage'ей из внешних источников (pkg-config, реестр Windows, find-модуль, проект собираемой сторонней системой сборки из тарболла, и т.п.)

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

Windows

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

В этом плане лично для меня, линуксоида, процесс сборки чего-то в винде превращается в муки, так что теперь я поставил кросс-комплиятор и пусть все поделия майкрософта идут лесом.

Нужна была именно 6-ая студия? (в Premake 4 ее выпилили, ибо древность)

Кстати да. Когда-то я её ненавидел, но после того как увидел какой лютый песец выпускает майкрософт дальше, я понял что шестая студия ещё ничего. Так что лучше б чтобы была - вдруг кому приспичит собрать, а под рукой не окажется толстого интернета чтобы скачать 10-гигабайтную студию 2010.

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

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

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

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

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

В этом плане лично для меня, линуксоида, процесс сборки чего-то в винде превращается в муки, так что теперь я поставил кросс-комплиятор и пусть все поделия майкрософта идут лесом.

Вариант, но не для всех. Студия-таки генерирует качественные бинарники, а некоторым нравится и как IDE.

Так что лучше б чтобы была - вдруг кому приспичит собрать, а под рукой не окажется толстого интернета чтобы скачать 10-гигабайтную студию 2010.

Есть патч, но официально не поддерживается. И все-таки лучше, чтобы не было, С++ там очень сильно хромает.

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

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

Спасибо!

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

Вариант, но не для всех. Студия-таки генерирует качественные бинарники, а некоторым нравится и как IDE.

В чем это заключается? gcc уже не в моде?

Есть патч, но официально не поддерживается. И все-таки лучше, чтобы не было, С++ там очень сильно хромает.

Там и си хромает. Причём хромота си тянется аж до 2010 года, сравнивал - ниччего не поменялось. особенно бесит то что объявлять переменные внутри функции нельзя, просто бред, какая разница где её объявили. Я когда полностью валидный по gcc код засунул в винду - получил 100500 ошибок вот такого плана. Комментарии // и то не поддерживает:)

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

В чем это заключается? gcc уже не в моде?

В производительности собранного приложения, в размере бинарников.

Там и си хромает.

Это да, для С под винду наверное лучше MinGW (кроме платного Интеловского) ничего нет.

собенно бесит то что объявлять переменные внутри функции нельзя, просто бред, какая разница где её объявили.

Это вроде из С99, а студия его не поддерживает (типа С-сообщество под виндой маленькое, чтобы доказать обратное, активнее трясите девелоперов студии в их бложике, и все такое).

Я когда полностью валидный по gcc код засунул в винду - получил 100500 ошибок вот такого плана.

Надо было у GCC задавать -std=с89, или осознанно использовать C99, забив на студию.

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

В производительности собранного приложения, в размере бинарников.

Размер согласен, а по тестам читал что cc винды по многим параметрам даже сливает. Хотя принципиально сам не проверял, версия для винды делаетс ялишь чтобы видоюзеры отстали.

Надо было у GCC задавать -std=с89, или осознанно использовать C99, забив на студию.

Ну вот поэтому я и забыл на все студии поставив кросс. распространяться всё равно будет в бинарном виде, а чем оно собрано конечного пользователя волнует в самую последнюю очередь. С99 мне нравится по определению больше, так как повышает наглядность .

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

конфигуратор тормознут из-за шелла и бессмысленных тестов

Ну-ну...

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

А по жизни всё несколько сложнее:

checking for library containing dgettext... none required
checking for library containing dlopen... -ldl
checking for library containing gethostbyname... none required
checking for library containing connect... none required
checking for library containing pthread_create... -lpthread
checking for library containing openpty... -lutil
checking for library containing libiconv_open... no
checking for library containing dgettext... none required
checking for library containing dlopen... none required
checking for library containing gethostbyname... -lnsl
checking for library containing connect... -lsocket
checking for library containing pthread_create... none required
checking for library containing openpty... no
checking for library containing libiconv_open... -liconv
r2d2 ()
Ответ на: комментарий от r2d2

Тесты бессмысленны, если вы сидите в одной системе.

Когда я разрабатывая ПО, я обычно сижу в одной системе, по кранйей мере в течение длительного промежутка времени. Поэтому меня не устраивает autotools в качестве первичного инструмента разработки.

annulen ★★★★★ ()

Опять школьники от безделья велосипедами занимаются. В колхоз бы вас на картошку или на завод к станку, глядишь и вылетела бы вся дурь из головы.

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

Так что лучше б чтобы была - вдруг кому приспичит собрать, а под рукой не окажется толстого интернета чтобы скачать 10-гигабайтную студию 2010.

А преобразование кода в недо-С++, поддерживаемый Visual C++ 6 кто проводить будет? Да и VS2010 весит отнюдь не 10G, а 727M (Exress версия).

пусть все поделия майкрософта идут лесом.

До тех пор пока не потредуется библиотека mingw не поддерживающая, ZeroC Ice, например.

Begemoth ★★★★★ ()

Отлично! Хоть Qt и не нужен, Premake — одна из лучших систем сборки.

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

Да и VS2010 весит отнюдь не 10G, а 727M (Exress версия).

Во-первых, экспресс не так кошерно, во-вторых, после установки получается много гигов даже если ставить компоненты сильно выборочно. Ставится эпично, у меня было 3 или 4 перезагрузки.

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

Причём хромота си тянется аж до 2010 года, сравнивал - ниччего не поменялось

Microsoft не выпускает компилятор С.

собенно бесит то что объявлять переменные внутри функции нельзя, просто бред, какая разница где её объявили

На подмножестве же С++ писать религия запрещает?

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

Microsoft не выпускает компилятор С.

Тем не менее, сишные файлы компилируются именно как С, а не С++, значит ...

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

Куча проблем с шаблонами. Ты не сможешь собрать ни свежий буст, ни свежий Qt.

насчет буста не скажу, но Qt4.8 собирается

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

Во-первых, экспресс не так кошерно,

Чем GCC?

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

1. Претензия была в том, что надо вытянуть 10G из инета.

2. Любая современная платформа для С++ занимает много места, Студия это не только компилятор, но и библиотеки.

Ставится эпично, у меня было 3 или 4 перезагрузки.

На 7 поставилась без единой перезагрузки.

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

насчет буста не скажу,

буст всегда был очень требователен к компилятору, официально он поддерживает VC++ начиная с 8.0.

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

Опять непонятны функции системы сборки. makefile можно один раз руками написать. Тем более, если он «лаконичный и удобочитаемый». Может проще освоить его синтаксис, чем какой-то там LUA?

Синтаксис makefile «уж очень как, совсем» плох. В качестве примера посмотри Kconfig из ядра или buildroot. Чтобы разобраться в этих хитросплетениях надо немало поломать голову, не говоря уже о правке или дописывании. Lua в этом смысле ощутимо более удобен.

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

Тем не менее, сишные файлы компилируются именно как С, а не С++, значит ...

Конечно, С89 не является строгим подмножеством С++, это разумно для повышения совместимости, но разве кто-то заставляет жрать кактус и писать на С?

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

разве кто-то заставляет жрать кактус и писать на С?

На вкус и цвет все кактусы разные, некоторые (не я) считают, что С++ хуже жуется.

annulen ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.