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

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

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

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

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

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

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

4.2

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

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

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

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

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

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

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

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

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

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

Может проще освоить его синтаксис, чем какой-то там LUA?

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

www.linux.org.ru/search.jsp?q=lua&oldQ=&range=ALL&interval=ALL&am...

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

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

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

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

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

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

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

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

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

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

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

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

4.2

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

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

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

http://industriousone.com/topic/newplatform

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

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

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

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

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

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

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

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

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

Но зачем?

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

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

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

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

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

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

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

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

Зато у 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 загрузить, если хочется, хотя такие модули пишутся с пол-пинка.

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

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

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

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

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

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

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

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

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

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

Но зачем?

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

Спасибо!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

http://industriousone.com/topic/newplatform

iscrosscompiler=true сходу очень порадовало.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Он самый.

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

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

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

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

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

Вариант 1

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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