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

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

Хотя я и не видел buildroot, GNU make няшен чуть менее, чем полностью.

Аватарка зачёт

GNU make няшен чуть менее, чем полностью.

Гну/бсд/вотевер мейк - всего лишь начинка для автотулзов!

Гну/бсд/вотевер мейк - всего лишь начинка для автотулзов!

Автотулзы - это попытка сделать из убогих бсд/вотевер мэйков хоть какое-то подобие сияющего и совершенного GNU Make.

Спокойно! Это была отчасти шутка.

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

каким образом это достигается, если пути к инклудникам и библиотекам везде разные ?

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

А компилятор как выбирать? Оно может сгенерить проект для студии так, чтобы компилятором был icc ?

каким образом это достигается, если пути к инклудникам и библиотекам везде разные ?

Стандартные бибилотеки всегда в /usr/include и /usr/lib. В случае с Qt эффект достигается через qmake -query c сохранением в переменной мейкфайла. В случае с другими зависимостями фокус не пройдет.

А компилятор как выбирать?

Опция --tool

Оно может сгенерить проект для студии так, чтобы компилятором был icc ?

К сожалению, нет.

Зачем так сложно? В cmake это делается так

add_wtf_source(source test1.wtf test2.wtf ...)
....
add_executable(wtf-executable ${source})

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

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

Действие осуществляется при добавлении файла => беспросветная императивщина. С Premake я могу написать сколько угодно блоков files { ... } и excludes { ... }, а потом обойти только те файлы, которые были добавлены в проект и не были исключены.

То есть как минимум для pkg-config'а и для винды это не работает.

pkg-config можно заюзать как wx-config в примере по ссылке

http://industriousone.com/buildoptions

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

После «тотального» сравнения с cmake становится более или менее понятно, что из себя представляет Premake. НО а что можете сказать на счет Premake vs (Scons/Waf) ?

Ты можешь обойти или оно само неявно обойдет? Если ты сам обходишь, то это тоже императивщина.

scons не умеет файлы проектов, поэтому сразу фтопку

А для GTK+ есть что-нибудь такое?

Scons - тормоз, это знает каждый школьник. Premake работает очень быстро.

По сравнению с Waf, Premake отличается более простым и читаемым декларативным синтакисом, который не напоминает своим видом код.

По сравнению с обоими:

1) не требует установки питона (интерпретатор Lua слинкован с бинарником Premake)

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

Если ты сам обходишь, то это тоже императивщина.

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

А для GTK+ есть что-нибудь такое?

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

Для Cmake есть экспериментальная версия с lua http://www.cmake.org/Wiki/CMake:Experiments_With_Lua

С точки зрения синтаксиса мне тоже казалось, что CMake страшен. Но с точки зрения практики Cmake работает сегодня и очень хорошо. Использую постоянно на протяжении более 2 лет для сборки под Windows,Linux/x86,Linux/ARM.

С другой стороны есть системы, которые не поддерживают C++ в достаточной мере, чтобы собрать CMake. А Lua на них работает! Lua вообще прорыв с точки зрения величины рантайма и мощности языка.

Но то, что сейчас у вас есть это как SCons - он тоже блистал в свое время, но сдал позиции отчасти потом, что требовал жирный питон, но главное на мой взгляд было то, что там не было из коробки всего, что есть в CMake. Поэтому для удачного развития проекта нужно поддерживать, то что уже есть в CMake.

А кто развивает продукт? И кем он поддерживается? Кто им известный пользуется?

Для Cmake есть экспериментальная версия с lua

Давно протухла. Да и идея немного бредовая: сначала кое-как реализовать часть Lua на С++ в своем коде, а затем прикрутить интерпретатор сверху.

А кто развивает продукт?

Jason Perkins, Liam Devine и я. Также поступает множество патчей от пользователей.

Кто им известный пользуется?

Skype, Bullet, ODE, некоторые другие проекты, связанные с геймдевом (как СПО, так и проприетарные).

Идея-то может и протухла, но вот есть большой проект и тупо не охота перелопачивать его в один день на Premake (тем более не понимая перспектив premake). Было бы круто взять проект на Cmake сконвертировать в Premake на этапе сборки. А другие части уже допиливать на lua. Или какие-то части на луа, а а для пользователей (программистов в данном случае) оставить базовый синтаксис CMake. Я просто хочу спросить насколько такая идея интересна? Или она только меня посещает?)) Просто у меня есть платформа (как я писал), на которой Cmake не работает, а lua вполне. И мне приходится только ради нее постоянно дописывать makefile. Хотелось бы плавный переход на Lua, но не отрываясь от mainstream, где CMake пока главный.

Интересно, что же это за волшебная платформа и почему нельзя для неё с[кросс]компилировать (скажем, даже статически) cmake?

С можно, а С крест крест незя. А не секрет и очень популярная в узких кругах: QNX4

кастани меня, пожалуйста, если анон научит тебя с++ на этом...

www.scons.org

What makes SCons better?

• ...
• Built-in support for Microsoft Visual Studio .NET and past Visual Studio versions, including generation of .dsp, .dsw, .sln and .vcproj files.
• ...

Это не то ?

Это не то ?

Самое то (лично проверял),- Reset сказочник еще тот.

Scons - тормоз, это знает каждый школьник. Premake работает очень быстро.

Неосилятор обнаружен.

Извините, что отвечаю на несколько постов сразу.

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

В CMake есть `CMAKE_CONFIGURATION_TYPES`, а перечисленные конфигурации - лишь по умолчанию, удобства ради.

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

На здоровье: `get_target_property(MY_TARGET_SOURCES MyTarget SOURCES)`

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

Плюс в CMake даже версии Qt для разных конфигураций не установишь.

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

Ну и к тому же трешовые мейкфайлы от CMake работают гораздо медленнее (отчасти из-за вызовов cmake изнутри)

Что поделать, во имя переносимости. Подождём, когда в ваших, в отличие от CMake, «переносимых Makefile'ах», вдруг потребуется во время сборки создать директорию. И насчёт «гораздо», таки приведите цифры.

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

Пример CMake кода из моего проекта (названия чего бы то ни было изменены, если что):

MY_PROJECT(Program1 GUI_APP
    SOLUTION_FOLDER
        GUI
    INSTALL_TO
        bin
    DEPENDS
        Library1
        Library2
    EXTERNAL_DEPENDS
        boost
        qt
        zip
    EXTERNAL_DEPENDS_USE_CURL
        curl
    EXTERNAL_DEPENDS_DUMPING_WITH_BREAKPAD
        breakpad
    EXTERNAL_DEPENDS_APPLE
        "-framework ApplicationServices"
        "-framework Cocoa"
        "-framework CoreFoundation"
        "-framework CoreServices"
    EXTERNAL_DEPENDS_WIN32
        rpcrt4
        mpr
)

MY_SOURCE_GROUP(NONE
    SOURCES
        main.cpp
    SOURCES_WIN32
        Program1.rc
    HEADERS_WIN32
        resource.h
)

MY_SOURCE_GROUP("Models"
    SOURCES
        Models/Model1.cpp
    HEADERS
        Models/Model1.h
)

MY_SOURCE_GROUP("Forms"
    UI_FILES
        Forms/Form1.ui
)

MY_PROJECT_END()

Магия? Нет, CMake.

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

Слив защитан.

Могу ещё многое прокомментировать, но думаю вы поняли.

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

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

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

В мусорку такую систему.

Могу ещё многое прокомментировать, но думаю вы поняли.

Хороший, годный ответ.

Стандартные бибилотеки всегда в /usr/include и /usr/lib

Открой глаза, линюксойд.

В моей системе большинство библиотек в /usr/pkg/lib и /usr/pkg/include соответственно

А для GTK+ есть что-нибудь такое?

GTK+ такие костыли не нужны. Генерация всякого барахла там нужна только для кастомного маршаллинга, а это обычно довольно редко бывает нужно.

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

С другой стороны, возможно, я не осознал Дао make.

Открой глаза, линюксойд. В моей системе большинство библиотек в /usr/pkg/lib и /usr/pkg/include соответственно

Пардон, имел в виду, что в дефолтных путях поиска компилятора

Думаю так сделать можно, надо смотреть документацию по FindQt

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

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

Есть такое

Магия? Нет, CMake.

Эти функции есть в каком-то стандартном модуле? А *кодить* на недоязыке, чтобы сделать из CMake конфетку, у меня желания нет.

Что поделать, во имя переносимости. Подождём, когда в ваших, в отличие от CMake, «переносимых Makefile'ах», вдруг потребуется во время сборки создать директорию.

Директории без проблем создаются

CMAKE_CONFIGURATION_TYPES

Был не прав, извиняюсь

Ну и к тому же трешовые мейкфайлы от CMake работают гораздо медленнее (отчасти из-за вызовов cmake изнутри)

Что поделать, во имя переносимости.

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

Идея-то может и протухла

Идея может и ничего, но реализацию давно забросили.

но вот есть большой проект и тупо не охота перелопачивать его в один день на Premake

Б-же упаси, я к этому не призываю.

Было бы круто взять проект на Cmake сконвертировать в Premake на этапе сборки.

Есть другой вариант - можно выделить конфигурационный код без вызовов типа add_executable (т.е. код, который может выполняться с cmake -P) в отдельный .cmake модуль, и импортировать выходные значения переменных в Premake-проект с помощью вот этого кода

http://industriousone.com/topic/cmake-integration

Хотелось бы плавный переход на Lua, но не отрываясь от mainstream, где CMake пока главный.

Это смотря где мейнстрим, у нас в конторе, например, qmake.

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

Не только друг друга, но еще и cmake. Broken design мешает, очевидно.

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

Идея очень даже интересна. У меня была мысль реализовать базовый набор функций CMake на Lua средствами Premake.

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

Что поделаешь, c'est la vie. Однако у SCons и сейчас есть своя аудитория, как и у Premake есть своя.

Бла-бла-бла... то же самое слышал про waff в своё время слышали. Уж по мне, так по сравнением с сабжем даже waff не кажется такой дурацкой идеей.

В мусорку такую систему.

Сказал юзер, никогда не разрабатывавший софт. Я угадал?

так как прибит гвоздями к GNU make

Безграмотность.

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

Fail.

Бла-бла-бла... то же самое слышал про waff в своё время слышали. Уж по мне, так по сравнением с сабжем даже waff не кажется такой дурацкой идеей.

Во-первых, с одной f, во-вторых, в целом идеология сходна, но Premake, в отличие от waf, это meta build system. Кто-то считает это недостатком, для меня это преимущество.

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