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 ()

В чем профит от использования premake вместо cmake?

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

В чем профит от использования premake вместо cmake?

  • Синтаксис проекта проще для написания, понимания и поддержки. Проект описывается декларативно, а не императивно
  • Вопреки распространенному заблуждению, CMake - плохо расширяемая система. Макро-язык приводит к написанию трудночитаемого коду в случае даже таких простых действий, как операции над строками, а доступ к внутренним структурам данных вообще не предоставляется. В случае с Premake и проект, и система сборки написаны на одном языке общего назначения (Lua), поэтому в пределах проекта можно определять новые декларативные API, добавлять поддержку инструментов сборки, и даже менять поведение Premake, если это требуется.
  • Более прозрачная и удобная поддержка кросс-компиляции
  • Количество и названия конфигураций неограничены (в CMake их только 4: Debug, Release, DebugWithRelInfo, MinSizeRel)
  • Пользователь может конфигруировать сборку используя параметры командной строки (как в autotools), к которым доступна справка. Никаких -DMYPROJECT_MY_LONG_VARIABLE
  • Генерируемые файлы проектов и Makefile'ы по умолчанию переносимы, т.е. могут распространяться
  • Система сборки компилируется в один исполняемый файл - ее можно даже распространять вместе с проектом (если требуется конфигурация на стороне пользователя)
  • Генерируемые makefile'ы удобочитаемы и лаконичны. При этом код, отвечающий за генерацию, прозрачен и может быть легко адаптирован под требуемые задачи. Например, мне без особого труда удалось написать патч, позволяющий генерировать Kbuild'ы (особые makefile'ы модулей ядра Linux), что не представляется возможным при использовании CMake.
annulen ★★★★★ ()
Ответ на: комментарий от annulen

Синтаксис проекта проще для написания, понимания и поддержки. Проект описывается декларативно, а не императивно

А что, в cmakе разве императивно? Впервые об этом слышу.

Вопреки распространенному заблуждению, CMake - плохо расширяемая система.

4.2

Более прозрачная и удобная поддержка кросс-компиляции

Чем это достигается?

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

А аналог ccmake там есть?

Генерируемые файлы проектов и Makefile'ы по умолчанию переносимы, т.е. могут распространяться

Да, сферический плюс в вакууме. Только зачем тогда нужен premake?

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

Т.е. монолитная система без возможности доустановки модулей. Я правильно понял?

Генерируемые makefile'ы удобочитаемы и лаконичны. При этом код, отвечающий за генерацию, прозрачен и может быть легко адаптирован под требуемые задачи. Например, мне без особого труда удалось написать патч, позволяющий генерировать Kbuild'ы (особые makefile'ы модулей ядра Linux), что не представляется возможным при использовании CMake.

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

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

А что, в cmakе разве императивно? Впервые об этом слышу.

В CMake результат выполнения вызова «функции» часто зависит от предыдущих вызовов и/или установки глобальных переменных

А аналог ccmake там есть?

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

Да, сферический плюс в вакууме. Только зачем тогда нужен premake?

Сгенерить мейкфайлы для всех ОСей сразу. Сам Premake поддерживает также генерацию проектов для разных IDE, но Qt на текущем этапе с ними работать не будет.

Т.е. монолитная система без возможности доустановки модулей. Я правильно понял?

Модули, как и в Lua, грузятся с помощью require.

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

Вопрос вкуса, но на мой взгляд (и я далеко не одинок) нетривиальные мейкфайлы трудны для понимания и поддержки. Lua - крайне простой язык.

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

но ведь тогда не получится использовать lua!

Чувак, я действительно проперся от Lua, но *после* знакомства с Premake :)

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

4.2

4.2 на твое 4.2. Попробуй в CMake получить, например, список сорсов для данной цели по ее названию.

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

Зато у cmake еще есть CTest, CPack и CDash :)

И, разрешите, парочку вопросов.

Сколько типов выхлопа для разных компиляторов/платформ умеет ваш premake?

Сколько библиотек (аналог FindOpenGL , FindCuda в cmake) умеет ваш premake из коробки?

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

В CMake результат выполнения вызова «функции» часто зависит от предыдущих вызовов и/или установки глобальных переменных

А что, в premake не зависит? Там нет переменных?

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

Понятно. А вот «нормальность» сия относительная.

Сгенерить мейкфайлы для всех ОСей сразу. Сам Premake поддерживает также генерацию проектов для разных IDE, но Qt на текущем этапе с ними работать не будет.

Но зачем?

Модули, как и в Lua, грузятся с помощью require.

Да, а при чём тут тогда «один бинарник»?

Вопрос вкуса, но на мой взгляд (и я далеко не одинок) нетривиальные мейкфайлы трудны для понимания и поддержки. Lua - крайне простой язык.

Тогда непонятно, при чём тут «удобочитаемость», раз ты в них даже заглядывать не хочешь? На кой тебе оно?

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

4.2 на твое 4.2. Попробуй в CMake получить, например, список сорсов для данной цели по ее названию.

Зачем? Чтобы получить тот же самый список сорцов, что я ей только что передал? Так он и так есть. А вот наличие поддержки pkg-config в сабжевой системе сборки я не заметил. Может плохо смотрел?

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

Объявляешь тулчейн, указываешь путь к компилятору и флаги. Все.

А флаги, я так понимаю, жёстко забиты что ли?

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

Зато у cmake еще есть CTest, CPack и CDash

Есть такое. По первым двум пунктам догоним, насчет CDash не знаю.

Сколько типов выхлопа для разных компиляторов/платформ умеет ваш premake?

Типы выхлопа: GNU make, MSVS 2002-2010, Xcode 3-4, Code::Blocks, CodeLite, SharpDevelop, MonoDevelop. В разработке bsdmake, nmake, ninja.

Платформы (из коробки): десктоп (Windows, Linux, Mac OS X, *BSD, Haiku), PS3, Xbox 360, Wii. Можно легко задать свой тулченй, хоть для эмбеддед, хоть для NaCl.

Сколько библиотек (аналог FindOpenGL , FindCuda в cmake) умеет ваш premake из коробки?

В данный момент, Premake ориентирован больше на разработчика, чем на применение конечным пользователем, соответственно, и задачи немного другие: не «найти абы что где-нибудь», а «взять откуда я показал». Что, естественно, не мешает использовать pkg-config и подобные инструменты в проектном файле для подстановки параметров. Можно и Find-модуль от CMake загрузить, если хочется, хотя такие модули пишутся с пол-пинка.

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

А вот наличие поддержки pkg-config в сабжевой системе сборки я не заметил

Есть функция os.outputof(), можно запросить выхлоп любой внешней программы.

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

А флаги, я так понимаю, жёстко забиты что ли?

Как захочешь: хочешь - жестко, хочешь - в параметры вынеси, хочешь - в переменные среды.

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

А что, в premake не зависит? Там нет переменных?

Есть, но основной API декларативен. Выставляешь поля в любом порядке, а дальше они обрабатываются. Пример: http://industriousone.com/sample-script

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

Тогда непонятно, при чём тут «удобочитаемость», раз ты в них даже заглядывать не хочешь? На кой тебе оно?

Для отладки же

Да, а при чём тут тогда «один бинарник»?

Если не используешь дополнительных модулей, будет один. В любом случае, не надо ничего устанавливать в систему.

Но зачем?

Чтобы юзер мог просто собрать, не скачивая никаких систем сборок

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

Спасибо!

Интересный проект, удачи вам :)

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

Чтобы получить тот же самый список сорцов, что я ей только что передал?

Например, чтобы добавить кодогенерацию, тебе придется писать уродливый FOREACH с захардкоженными переменными, а в Premake, например, можно вынести в отдельный модуль «действие» для всех объявленных проектов, которое сможет пройти по всем файлам (или другим свойствам проекта), поменять, что надо, а потом передать генератору ме

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

Интересный проект, удачи вам :)

Опа, первый позитивный комментарий :) Спасибо за поддержку.

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

Есть функция os.outputof(), можно запросить выхлоп любой внешней программы.

В cmake тоже есть. Только вот толк от этого, если всё руками потом делать?

Как захочешь: хочешь - жестко, хочешь - в параметры вынеси, хочешь - в переменные среды.

Речь идёт про стандартные методы. А велосипед можно и на питоне написать.

Есть, но основной API декларативен. Выставляешь поля в любом порядке, а дальше они обрабатываются.

И? В чём тогда профит?

Для отладки же

Отладки чего? Программы или сабжевого поделия?

Если не используешь дополнительных модулей, будет один. В любом случае, не надо ничего устанавливать в систему.

В смысле не надо? Интерпретатор lua разве не требуется? Или ты предлагаешь его с собой таскать? Да, кстати, с документацией всё очень плохо.

Чтобы юзер мог просто собрать, не скачивая никаких систем сборок

См. вопрос выше.

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

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

Приведи пример что ли.

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

Только вот толк от этого, если всё руками потом делать?

Поддержка планируется в следующих выпусках.

И? В чём тогда профит?

Простота и наглядность.

В смысле не надо? Интерпретатор lua разве не требуется? Или ты предлагаешь его с собой таскать?

Интерпретатор Lua - это примерноо 200 К. Распространяемые сборки его включают.

Да, кстати, с документацией всё очень плохо.

Это с учетом http://industriousone.com/scripting-premake или без?

Отладки чего? Программы или сабжевого поделия?

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

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

Приведи пример что ли.

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

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

Попробуй в CMake получить, например, список сорсов для данной цели по ее названию.

Но зачем это может понадобится ?

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

Но зачем это может понадобится ?

Для расширения возможностей системы сборки (см. выше)

annulen ★★★★★ ()

классно. мне нравится, спасибо!

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

Поддержка планируется в следующих выпусках.

Ну хоть один чёткий ответ.

Простота и наглядность.

Это не аргумент.

Интерпретатор Lua - это примерноо 200 К. Распространяемые сборки его включают.

Так он что, ещё и бинарный? Да, кстати не понятно, зачем система сборки в готовых сборках. Может имелся ввиду тарболл, т.е. архив с исходниками?

Это с учетом http://industriousone.com/scripting-premake или без?

С учётом. Как организуется сборка, какие файлы тащить вместе с исходниками совершенно непонятно.

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

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

Смотрел там и тут. Ты уж ткни пальцем, что тебя так напугало.

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

Так он что, ещё и бинарный?

Есть код, есть бинарники. Лицензия BSD.

Может имелся ввиду тарболл, т.е. архив с исходниками?

Он самый.

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

Вариант 1: Генерируешь мейкфайлы / проекты, распространяешь тарболл с ними (как в самом Premake, например). В этом случае можешь хоть вообще ничего кроме сорсов не включать

Вариант 2: Добавляешь в тарболл главный файл premake4.lua и все, что он инклудит / реквайрит (в простых случая все можно объявить в одном файле)

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

Ты уж ткни пальцем, что тебя так напугало.

Куча стремного кода на 1.5k строках. При этом даже новый QT4_AUTOMOC не будет работать, если ему явно не дадут список файлов.

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

Вариант 1

Негодный. Не будем даже рассматривать.

Вариант 2 Добавляешь в тарболл главный файл premake4.lua и все, что он инклудит / реквайрит (в простых случая все можно объявить в одном файле)

А premake4.lua кто будет исполнять?

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

А premake4.lua кто будет исполнять?

Бинарник premake4, приложенный к тарболлу или скачанный / установленный из репов пользователем.

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

Куча стремного кода на 1.5k строках.

Не аргумент. Я могу сказать тоже самое про premake. Попробуй доказать обратное без использования таких вот субъективных слов, вроде «кривой», «стрёмный», «страшный».

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

Не будем даже рассматривать.

Многие пользователи Premake с тобой не согласятся, хотя они в основном виндоводы

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

Бинарник premake4, приложенный к тарболлу или скачанный / установленный из репов пользователем.

Понятно. В этом плане преимуществ перед cmake не наблюдается.

anonymous ()

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

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

Многие пользователи Premake с тобой не согласятся, хотя они в основном виндоводы

Я думаю, сборщики пакетов под тот же debian очень удивятся такому феерическому дилетантству.

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

В этом плане преимуществ перед cmake не наблюдается.

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

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

приведи пример для чего это внезапно может понадобится? для сборки цели ты задаешь необходимые файлы => ты уже их знаешь.

кроме того не нашёл примеров применения premake кроме как для сборки проекта на qt4, а могу я им собрать проект для gtk, gtk3, efl, wxwidgets, etc ?

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

Попробуй доказать обратное без использования таких вот субъективных слов, вроде «кривой», «стрёмный», «страшный».

А зачем? Время решит. И да, м моей точки зрения язык CMake тоже уеби^Wстрашен.

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

Я думаю, сборщики пакетов под тот же debian очень удивятся такому феерическому дилетантству.

Сборка без использования внешних утилит - это теперь дилетанство?

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

Был ли проведен проводили детальный анализ существующих систем сборки, их сильных и слабых сторон? Прошли ли результаты вашего анализа публичное обсуждение (так, чтобы ценители той или иной системы сборки могли указать на изъяны анализа)? http://en.wikipedia.org/wiki/List_of_build_automation_software

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

И да, м моей точки зрения язык CMake тоже уеби^Wстрашен.

В любом случае это DSL (имхо переросший свою изначальную концепцию), а Lua - язык общего назначения.

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

Сборка без использования внешних утилит - это теперь дилетанство?

Нет. Наличие Makefile-в с уже забитыми флагами сборки и линковки.

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

Был ли проведен проводили детальный анализ существующих систем сборки, их сильных и слабых сторон? Прошли ли результаты вашего анализа публичное обсуждение (так, чтобы ценители той или иной системы сборки могли указать на изъяны анализа)?

Я проводил анализ с точки зрения удобства для разработки продукта компании, в которой работаю (проект на Qt, сейчас используется qmake, миграция на CMake не принесла бы ничего хорошего). Я не писал ничего с нуля, Premake существует достаточно давно и стабильно развивается, а я всего лишь добавляю в него недостающие возможности. Ну и мы с вами не на научной конференции :)

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

Наличие Makefile-в с уже забитыми флагами сборки и линковки.

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

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

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

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

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

wxwidgets - http://wiki.wxwidgets.org/Premake4. Про остальные не в курсе, но запилить при желании не труднее (думаю, существенно проще), чем Qt.

для сборки цели ты задаешь необходимые файлы => ты уже их знаешь.

Модульность. Ты создаешь проект, определяешь его «свойства» (декларативно), затем добавляешь плагин, который добавляет, например, правила кодогенерации. Можешь хоть C++ с m4-препроцесором организовать, если хочется.

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