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

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

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

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

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

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

Я не то спрашивал.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Минусы:

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

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

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

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

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

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

Плюсы:

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

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

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

mingw

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ну и если будут вопросы или затруднения, не стеснйся спрашивать на http://industriousone.com/forums/premake или http://lorcode.org/forum/viewforum.php?f=35

Windows

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

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

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

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

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

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

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

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

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

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

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

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

Спасибо!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

С++ там очень сильно хромает.

например?

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

Ну-ну...

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

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

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

например?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Чем GCC?

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

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

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

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

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

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

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

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

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

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

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

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

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