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

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

На мой взгляд, у CMake весьма хреновая документация.

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

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

Я считаю, что я достаточно хорошо знаком с CMake. Может быть я не постиг какого-то дзена, но я не считаю его подход и синатксис оптимальными.

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

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

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

Это не супер-язык, это просто язык общего назначения. У CMake DSL, со всеми вытекающими недостатками.

Виноват, с одной f, развелось тут билд-систем аки грязи... и, таки, расскажите нам о том, что это за новое определение «meta» билд-система и чем оно отличается от не-«meta»? Это какбэ намек на то, что оно есть месиво декларативного DSL и процедурного кода?

CMake --- это «meta»? autotools --- это «meta»?

CMake --- это «meta»? autotools --- это «meta»?

Да, в том смысле что они генерируют входные файлы для make, а не вызывают компилятор сами.

Это какбэ намек на то, что оно есть месиво декларативного DSL и процедурного кода?

Ни в коем случае. Это же не автотулз.

Я считаю, что я достаточно хорошо знаком с CMake. Может быть я не постиг какого-то дзена, но я не считаю его подход и синатксис оптимальными.

Примеры, которые были приведены, чтобы показать как CMake сливает, были, однако, помножены на нуль.

P.S. Синтаксис у CMake отвратительный, как все самопальные синтаксисы, развивающиеся стихийно по принципу «это не новый язык, это я трали-вали навалять», а потом обрастающие черти-чем.

Синтаксис у CMake отвратительный, как все самопальные синтаксисы, развивающиеся стихийно по принципу «это не новый язык, это я трали-вали навалять», а потом обрастающие черти-чем.

Вот это главный недостаток, спасибо за формулировку.

Точно так же тенденцию «обрастать черти-чем» имеют и CMake-проекты.

Ни в коем случае. Это же не автотулз.

А причем тут вообще autotools?! Где там декларативный DSL?

Где там декларативный DSL?

Makefile.am же.

А никакого декларативного DSL в Premake нет, это просто Lua.

Это не какой-то особый язык, а несколько «расширенный» синтаксис Make, который не является ни DSL, ни декларативным, хотя схож с.

который не является ни DSL, ни декларативным

O rly? По-моему и DSL (ну не общего назначения же), и декларативный (по крайней мере «классический» функционал)

Я угадал?

Нет, но даю тебе ещё одну попытку.

вы все анонимусы на одно лицо, но кажется вы первые начали с вопросов чем оно лучше смаке и автор честно ответил... ИМХО: если Премэйк устраивает атора а в Смаке он не смог разобраться это проблема смака( возможно не техническая а в позиционировании) я пока вижу что премэйк более гибок. ибо сделать из премэйка смак можно а наоборот нет. такчто пока автор не призывает декомпилировать смаке на каждом компьютере он чист перед инквизицией!

ЗЫЫ в системах сборки не разбираюсь мимо проходил метаанализ провёл.

интересный проект, желаю развития и успехов
пока создавал premake4.lua для своего тестового проектика - естественно допускал ошибки, а вот реакция на них была сложна к пониманию - она подобна ошибке при компиляции шаблонов - знаю что где то ошибка, но понять не легко или невозможно )
попробую позже интеграцию с qtcreator (надо собрать PremakeProjectManager)

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

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

Пробежался глазами по странице проекта и комментариям автора здесь. Как уже многие заметили, ближайший конкурент Premake — CMake. Исходя из своего опыта попробую покритиковать, дабы найти истину.

Количество и названия конфигураций неограничены (в CMake их только 4: Debug, Release, DebugWithRelInfo, MinSizeRel)

1. Может мне показалось, но вы заблуждаетесь в том, что есть конфигурация в CMake. Это называется директория сборки (везде в документации она фигурирует как directory). В пределах директории сборки существует свой кеш с параметрами (плюс интерактивные редакторы — ccmake, cmake-gui). CMAKE_BUILD_TYPE = Debug, Release и прочие — всего лишь один из параметров конфигурации, в реальном проекте их десятки. И да, опционально здесь же выбирается версия Qt, которую использовать в текущей конфигурации.

2. Поиск зависимостей сборки. Это must have фича, которую сложно переоценить. Если в системе отсутствует необходимый пакет А, то CMake скажет про это вам на этапе конфигурации читабельным сообщением. Если флаг REQUIRED был опущен в find_package(), то может просто выдать предупреждение.

3. Кеш целей для инкрементальной сборки в CMake — это вообще killer фича. К примеру, вы делаете git fetch, а в новой версии скрипта сборки, выкачанного из удалённого репозитория, добавлена опция:

--- add_custom_command(OUTPUT generated_file.txt COMMAND generate_my_file "Foo")
+++ add_custom_command(OUTPUT generated_file.txt COMMAND generate_my_file "Bar")

Так вот, CMake обнаружит, что параметр команды для генерации generated_file.txt изменился и запустит перегенерацию этого и только этого файла при следующем запуске make. Никаких массовых чисток и пересборок проекта с нуля и головной боли, что половина проекта случайно была собрана с одними параметрами, а половина — с другими. В qmake такая проблема сплошь и рядом, а как с этим в Premake?

4. В CMake заложены отличные идеи, но местами хромает реализация. Главное, что на данный момент меня коробит в CMake — это древний синтаксис, с ужасными if()/endif() и foreach() без break(). Было бы отлично, если бы CMake в следующей версии перешёл так же на Lua, благо реализовать это относительно просто. Второй критичный для меня момент — генерирование Makefile-based проектов под IDE: MSVC, QtCreator, Eclipse, etc. Заметьте — именно корректных Makefile-проектов, удобных для редактирования и отладки, но чтобы про этом система сборки оставалась доступна с консоли.

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

И мне надо будет под N embedded-платформ * M конфигураций клиентов вручную конфигурировать набор переменных. Опять шелловые обертки и танцы с бубнами.

Поиск зависимостей сборки. Это must have фича, которую сложно переоценить.

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

В qmake такая проблема сплошь и рядом, а как с этим в Premake?

Пока никак.

Было бы отлично, если бы CMake в следующей версии перешёл так же на Lua, благо реализовать это относительно просто.

Проект был, да почему-то загнулся. Наверное, не так просто.

Второй критичный для меня момент — генерирование Makefile-based проектов под IDE: MSVC, QtCreator, Eclipse, etc

Не понимаю, чем Makefile-based проект для криейтора может быть удобней нативной поддержки открытия premake4.lua

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

И мне надо будет под N embedded-платформ * M конфигураций клиентов вручную конфигурировать набор переменных. Опять шелловые обертки и танцы с бубнами.

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

Второй критичный для меня момент — генерирование Makefile-based проектов под IDE: MSVC, QtCreator, Eclipse, etc

Не понимаю, чем Makefile-based проект для криейтора может быть удобней нативной поддержки открытия premake4.lua

Спустя много времени программирования в разнородных средах я начал ценить совместимость систем сборки и независимость от различных IDE. Максимум, что должны делать IDE — брать список исходников и опции сборки для правильного разбора исходного текста. Сама сборка же должна быть через командную строку с последующим разбором выхлопа компилятора. Вот именно тема генерирования подобных Makefile-проектов для различных IDE в CMake не раскрыт. Будет время — допишу сам.

Некоторый ОТ:

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

А ccache не спасает в таких ситуациях?

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

С premake это вполне реализуемо. Есть дефолтные настройки платформы, есть дефолтные настройки конфигурации, можно задать их для группы конфигураций или платформ, а можно для каждого пересечения персонально. Можно вынести некоторые параметры сборки в отдельный конфигурационный файл (пример из жизни: список платформ, для каждой указан тулчейн и собранные версии Qt, затем в конфигурациях указать, какая версия кому нужна)

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

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

А ccache не спасает в таких ситуациях?

Я догадываюсь, что эта проблема решается только на уровне системы сборки. Дело в том, что make может ориентироваться пересобирать ли цель только по времени последнего изменения файла зависимости и файла цели. А была изменена только команда сборки в самом Makefile — при запуске make неизвестно что именно было изменено в Makeflie. CMake же хранит эту историю команд в файле CMakeRuleHashes.txt и обнаружив изменение удаляет файл цели. Это, к слову, частично отвечает на вопрос зачем нужна куча левых файлов в директории сборки, для тех, кто верит, что можно обойтись одним голым Makefile в директории с исходниками.

Есть дефолтные настройки платформы, есть дефолтные настройки конфигурации, можно задать их для группы конфигураций или платформ, а можно для каждого пересечения персонально.

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

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

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

Был у нас один проект на MSVC, который использовал генерацию проектов студии через qmake. После обновления файлов из репозитория (а количество файлов было огромно, солюшен состоял из множества проектов) при начале сборки Студия кричала благим матом, что проекты были изменены и выдавала на каждый проект диалог перезагрузить ли его. Передать ощущения клацания по кнопке «Да» несколько десятков раз подряд за день сложно, это нужно было прочувствовать. Самые смышлёные закрывали предварительно Студию перед этой операцией, а менее удачливые выгружали процесс из памяти. Когда я перевёл проект на Makefile-based эта проблема исчезла сама собой.

И да, скудность Makefile-проектов обусловлена в основном скудностью самой IDE. К примеру, QtCreator и Eclipse справляются с Makefile-проектами на ура. Единственное, чего реально не хватает — отслеживание изменений в параметрах конфигурации на лету (defines + include directories) и здесь в CMake, к сожалению, прокол. Как я понимаю, в других системах сборки дела так же печальны.

Мне кажется, в premake нужно добавить ещё две цели: autotools и cmake. Это вполне возможно сделать, махом закроет все вопросы по части поиска пакетов. Эдакий мегакостыль для существующих систем сбоки, от которых меня отпугивает вырвиглазный синтаксис, все сетуют на поиск зависимостей - но это же клиентская фича.

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

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

Пользователь в моем случае вообще не причем. Все конфигурации собираются на билдсервере и включаются в прошивки девайсов.

Мне кажется, в premake нужно добавить ещё две цели: autotools и cmake.

autotools - возможно: 1)есть реквест; 2)это чертовски традиционная штука, которой умеет пользоваться каждый юниксоид.

cmake - думаю, это чересчур. Франкенштейн какой-то получится.

Для начала автотулса будет достаточно, а cmake можно для тех кому захочется на него перейти (а может даже наоборот: перейти с cmake на premake).

Если такая фича будет - она станет киллером, и ананимусы уймутся.

Все конфигурации собираются на билдсервере и включаются в прошивки девайсов.

Вот-вот, я тоже про это подумал. Подобные серверы, с которыми я сталкивался (Bamboo, Jenkins) — эдакая вещь в себе. Для сборок нескольких конфигураций там создаются собственные скрипты с настраиваимыми руками опциями. Никто не знает на каком этапе добавится ещё одна конфигурация со своими параметрами, но скрипт сборки проекта об этом знать не должен. Вполне может оказаться, что сборка версии под Windows должна использовать MSVC и кросскомпиляция здесь не поможет. В этом случает в ход идёт тяжёлая артиллерия в виде ферм сборок, перекладывать такую объёмную задачу на систему сборки, призванную быть кроссплатформенной на локальном хосте — лезть в чужую область задач.

Никто не знает на каком этапе добавится ещё одна конфигурация со своими параметрами, но скрипт сборки проекта об этом знать не должен.

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

Вполне может оказаться, что сборка версии под Windows должна использовать MSVC и кросскомпиляция здесь не поможет

А для этого нужна генерация sln/vcproj. Тоже один из видов конфигураций, кстати.

перекладывать такую объёмную задачу на систему сборки, призванную быть кроссплатформенной на локальном хосте — лезть в чужую область задач

А черт его знает, посмотрю как дело пойдет. По-моему, не безнадежно, и уж лучше, чем скриптовый ад над qmake :)

Если такая фича будет - она станет киллером, и ананимусы уймутся.

Тэг: «убийца айфона^W» :)

К примеру, QtCreator и Eclipse справляются с Makefile-проектами на ура.

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

Единственное, чего реально не хватает — отслеживание изменений в параметрах конфигурации на лету (defines + include directories) и здесь в CMake, к сожалению, прокол.

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

хотел бы пожелать успехов вашему проекту!

и пару вопросов(прошу прощения, если кто-то их уже успел задать, а я читал крайне невнимательно)

1. в cmake постоянно возникает боль, когда появляется желание добавить в проект PCH, для этого было написано много кода под студию, xcode, и для gcc в общем. как это реализовано в premake? и насколько это переносимо, т.е. если я добавил PCH все ли генераторы мейков/проектов его саппортят?

2. кастомные таргеты. т.е. разнообразные пре-билд операции, вызов скриптов на этапе сборки, есть ли такое и насколько оно переносимо?

3. если большой проект завязан на использование cmake-овского configure и поиск функций, файлов, проверку кусков кода на компилируемость, проверку поддерживаемых опций компилятора и т.п. есть ли какие-либо рекомендации по мигрированию проекта на premake? иногда крайне сложно написать многоэтажный ifdef просто чтоб узнать есть ли у нас какая-нибудь isatty или _isatty (это я так к примеру, может и не сложно:) ), а проще дёрнуть один макрос cmake и не беспокоиться

по поводу расширяемости, да согласен с premake всё проще, у cmake куча ньюансов, и тулчены тоже не всегда спасают, плюс не всегда и могут спасти, на пример premake на сколько я знаю умеет делать .vcproj я нативной поддержкой x360 и ps3 для cmake верх это либо делать через тулчейн мейкфайлы лмбо плодить кастом_комманд накаждый файл (поправьте меня если я ошибаюсь, самому интересно есть ли иные способы). накатать поддержку сего в cmake самому ... ну такое себе занятие имхо сорцы там оставляют желать лучшего. с premake всё проще, пробовал делать генерацию андроид мейкфайлов, был коекакой успех .. к сожалению не допилил, может быть бы предложил как фичу :)

так что лично от меня, если в premake будет(ну или есть) PCH, add_custom_command, configure_file - перехожу :)

хотел бы пожелать успехов вашему проекту!

спасибо!

в cmake постоянно возникает боль, когда появляется желание добавить в проект PCH, для этого было написано много кода под студию, xcode, и для gcc в общем. как это реализовано в premake? и насколько это переносимо, т.е. если я добавил PCH все ли генераторы мейков/проектов его саппортят?

Для этого используется функция pchheader[1], которая поддерживается всеми доступными генераторами. Вообще, любая фича поддерживается всеми генераторами, если в документации не оговорено обратное.

кастомные таргеты. т.е. разнообразные пре-билд операции, вызов скриптов на этапе сборки, есть ли такое и насколько оно переносимо?

Есть несколько вариантов:

1. Использовать prebuildcommands, prelinkcommands, postbuildcommands.Эти команды в общем случае платформенно-зависимы (см. документацию), однако в текущей версии (ветка stable или релиз представленный в данной новости) присутствует переменная _PREMAKE_COMMAND, с помощью которой можно делать вот так:

prebuildcommands { _PREMAKE_COMMAND .. " myaction" }

см. также [2,3,4]. Это позволяет использовать произвольный код на Lua в качестве этапа сборки вместо команд шелла. В моем форке наложен патч, позволяющий экшнам зависеть друг от друга, т.е myaction в примере может запускать целую цепочку действий, определенных независимо друг от друга.

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

3. К сожалению, добавлять «настоящие» (с заданным именем и зависимостями) кастомные тагреты кросс-платформенным способом пока нельзя, однако их поддержка запланирована.

если большой проект завязан на использование cmake-овского configure и поиск функций, файлов, проверку кусков кода на компилируемость, проверку поддерживаемых опций компилятора и т.п. есть ли какие-либо рекомендации по мигрированию проекта на premake?

Во-первых, изначально premake не создавался, чтобы быть заменой configure, адаптация сборки под систему пользователя в общем случае ложится на разработчика сборочного проекта. Тем не менее, есть набор функций, позволяющих искать зависимости в системе (например, os.pathsearch, os.findlib). В будущем я планирую расширить возможности premake в этом направлении.

Рекомендаций по миграции с cmake пока не будет, так как лично меня сейчас больше беспокоит миграция с qmake :)

isatty или _isatty

Юзай позиксовые варианты и не парься, что в msdn написано deprecated. Вряд ли они решатся когда-нибудь их убрать ;)

configure_file

Встроенного решения нет, зато есть мощные Lua-препроцессоры [напр,5,6], позволяющие втыкать в файлы любые вычисляемы Lua-конструкции. Добавляешь такой скрипт в свой проект (require filename.lua) и используешь наздоровье :)

Будут вопросы - обращайся на форум [7 или 8], помогу. Можно и с @--[[lua code here]]@ запилить, если что :)

[1] http://industriousone.com/pchheader

[2] http://industriousone.com/newaction

[3] http://industriousone.com/create-new-action

[4] http://industriousone.com/topic/executing-lua-function-prebuildpostbuildpreli...

[5] http://lua-users.org/wiki/SimpleLuaPreprocessor

[6] http://lua-users.org/wiki/SlightlyLessSimpleLuaPreprocessor

[7] http://industriousone.com/forums/premake

[8] http://lorcode.org/forum/viewforum.php?f=35

Я вот тут подумал и решил, что можно попробовать скрестить cmake и premake одним изд вух способов (или даже обоими):

1) premake как фронт-енд к cmake (декларативное описание проекта от premake + генераторы cmake на выходе) - будет удобно для тех, кто основательно подсел на cmake в своей инфраструктуре

2) выполнять внешний cmake-код из premake-проектов, используя сам cmake (вместо [1], только не ограничмваясь возможностями cmake -P) и использовать генераторы premake на выходе

[1] http://industriousone.com/topic/cmake-integration

выполнять внешний cmake-код из premake-проектов, используя сам cmake

...или тупо взять парсер из kdevelop

Думаю, что мне было бы удобно только сгенерить на основе проекта premake autotools - ибо стандарт, чтобы на любой юникс-системе проект можно было собрать без лишних зависимостей и костылей. А cmake не у всех пользователей стоит изначально, да и ./configure & make & make install все знают как отче наш.

А сейчас я так понял там что-то вроде обёртки над cmake на луа?

В идеале было бы круто, если бы пакеты разыскивались на основе переменной libs в premake: я туда затолкал все свои либы, и некоторые из них (SDL в частности) не установлены на многих системах по умолчанию.

cmake не у всех пользователей стоит изначально, да и ./configure & make & make install все знают как отче наш.

Согласен. Хотя для этого не обязательно генерить именно автотулзовый конфигуратор, но так будет проще всего. Жалко что autoconf нельзя использовать самостоятельно :(

А сейчас я так понял там что-то вроде обёртки над cmake на луа?

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

В идеале было бы круто, если бы пакеты разыскивались на основе переменной libs в premake: я туда затолкал все свои либы, и некоторые из них (SDL в частности) не установлены на многих системах по умолчанию.

uses { «SDL», «whatever-you-want», «etc» }

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

package.links = {«SDL», «SDLmain», «GL»}

А отсюда например, оно может брать? По сути полторы зависимости. Может какую небольшую базу данных составить lib библиотека => package?

package.links

ээ, в premake4 такого безобразия уже нет:

project "myproj"
  kind "ConsoleApp"
  language "C++"
  links { "SDL", "SDLmain", "GL" }
  ...

Разница uses и links в том, что links не предполагает добавления includedirs и прочего.

На луа не похоже уже:)

Быстро апи меняется: это буквально несколько месяцев назад писалось.

Быстро апи меняется: это буквально несколько месяцев назад писалось.

premake 4.0 вышел 31.01.2009, с тех пор никто API не ломал.

На луа не похоже уже:)

Считай, что это такая своеобразная ООП-система для Lua, специально заточенная под потребности конфигурации проектов.

http://premake.sourceforge.net/configurations

А это что тогда?

Открываем первую страницу: http://premake.sourceforge.net/

Читаем: «A new version is available! Premake 4.0 is now available at our new website. This page describes Premake 3.7, the last release in the 3.x series». И ссылка. "