Системы сборки

Пользователей не так уж мало, просто они в основном сидят тихо и пилят свои корпоративные форки :)

Ну будут и дальше пилить судя по количеству открытых pull-request'ов.

ant / xbuild наше фсио.

О! Живой контрибьютер premake'а. Скажи мне, почему поддержка Qt в premake добавлялась изменением в коде приложения, а не в скрптоте? Неужели там так грустно с расширяемостью?

Скажите к какому выводу вы здесь пришли?

например, в /src все исходники, в /include все заголовки, хочу бинарники складывать в /bin (возможно отделив debug от release).

Я почти такую схему использую.

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

Так делать не надо. Случайно положишь какой-нибудь 1.c во вложенную поддиректорию и испортишь сборку, а потом часы потратишь на поиск проблем. Лучше явно указывать файлы.

Хотя способ засасывания всех файлов рекурсивно в cmake есть. А линковки через libastral с нужными библиотеками, естественно, нет.

К тому что жизнь — говно. Как обычно.

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

обычно храню в CMAKE_CURRENT_BINARY_DIR

А где ещё и в каких случаях? Не в ${CMAKE_CURRENT_SOURCE_DIR} же их хранить, всё его содержимое - в VCS, а сгенерированным файлам там не место.

${CMAKE_BINARY_DIR}/generated

Скажите к какому выводу вы здесь пришли?

Выводов несколько. Во-первых CMake'ом тоже можно пользоваться. Спасибо Reset'у за разъяснения. Да, конечно CMakeLists.txt выглядит жутковато, но есть много проектов на нем и всегда можно непонятное посмотреть.

Во-вторых, у premake и CMake, как мне кажется, более правильный подход по сравнению с qbs, scons и пр. В том смысле что люди не делают замену обычному мейку, а прикручивают к нему простой интерфейс.

Субъективно мне premake нравится больше. Пока посижу на обоих.

К тому что жизнь — говно. Как обычно.

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

Самая гибкая система сборки - та, у которой конфиг является программой на каком-либо скриптовом языке, ибо в этом случае можно реализовать сборку с абсолютно любой логикой. Примером реализации такого подхода является SCons (там используется Python) - его я и выбрал для всех своих проектов и пока не пожалел ни разу.

Да-да. Щаз. Если конфигурация системы хоть немного отличается от той на которой сидит девелопер, то начинается реальный бред. Именно поэтому вместо того чтобы использовать CMake findXXX ребята из Kitware тупо кладут все third-party исходники в дерево VTK с соответствующими CMakeLists для них.

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

В тоже время мне часто приходится собирать софт с большим списком зависимостей под разные системы, от линуксов и BSD до мобильников, и только, я подчёркиваю - ТОЛЬКО cmake способен без модификаций, костылей и кучи условий под каждую платформу все их найти и собрать приложение из коробки.

Раскажи это программерам с гугла, которые андроид со всеми библиотеками и програмами собирают с помощью make.

У андроида по определению нет внешних библиотек. И, опять таки, то что кто-то где-то что-то собирает не с помощью cmake - ни разу не аргумент против последнего.

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

Чистая правда. Можно сразу взять и написать систему сборки с нуля - будет гибко что хоть тресни. SCons, кстати, так и делает - я бы даже системой сборки его не назвал - скорее, фреймворком для написания системы сборки на питоне. В итоге всё приходится писать руками, в этот убогий фреймворк только путается под ногами. Главное, никакой автоматизации и абстракции от платформы он не предоставляет и любой более-менее сложный SConstruct/cript сосотоит из проверок на разные системы чуть более чем полность.

Вот, для примера - полюбуйтесь: https://github.com/yazug/gpsd/blob/master/SConstruct

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

Самая гибкая система сборки - та, у которой конфиг является программой на каком-либо скриптовом языке

Даром не нужна такая гибкость.

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

У андроида по определению нет внешних библиотек. И, опять таки, то что кто-то где-то что-то собирает не с помощью cmake - ни разу не аргумент против последнего.

И наоборот, если что-то собирается с CMake, то это не разу не аргумент, что все там удобно.

Не знаю что такое kitware и vtk

Kitware - это контора, которая CMake пилит, в частности, для сборки VTK.

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

Я правильно понимаю что в kitware сидят идиоты и пилят VTK и CMake? А еще эти идиоты включили сорсы других идиотов включая TclTk, hdf5, png, tiff и тд до zlib. Вот http://vtk.org/gitweb полюбуйтесь на придурков.

Самая гибкая система сборки - та, у которой конфиг является программой на каком-либо скриптовом языке...

Ну кому-то Python нравится, а кто и bash+gmake предпочитает. Вопрос не в том что это можно сделать, а насколько легко.

Аналогов cmake для С++ нет, всё остальное - убогое говно.

fix

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

Кстати да, «декларативные зависимости» это ж самый смак.

Офигеть, у premake'a нет мультипроцессорной компиляции на релиза в VS. Куда патч слать?

Всем спасибо. Если кому интересно, после двух дней игрищ с параллельными CMake/premake остановился пока на premake. Он легкий, шустрый и правится/расширяется очень просто. Единственное я так и не понял кому слать патчи. Ау, annulen!

А искать всякие хитрые библиотеки, разработчики которых не додумались включить rc-файл, premake умеет?

Образец рабочего кода для premake кинуть можешь?

А искать всякие хитрые библиотеки, разработчики которых не додумались включить rc-файл, premake умеет?

Я, честно говоря, не знаю что такое rc-файл. А что конкретно ты имеешь ввиду под словом искать? Посмотреть есть ли *.h *.so там или там?

Как я понял искать в смысле CMake он не умеет. По крайней мере 4.х. В пятой вроде как научат. Ну или сделают общую обертку для поисковых скриптов.

Сейчас научить не проблема. Думаю будет полный кошерный супер-пупер кросс-платформенный поиск чего-либо выглядеть примерно одинаково что в CMake что в premake, например:

https://github.com/Itseez/opencv/blob/master/cmake/OpenCVFindIPP.cmake

Образец рабочего кода для premake кинуть можешь?

Завтра с работы скину свой велосипедный поиск IPP, если интересно.

Я, честно говоря, не знаю что такое rc-файл

Тьфу, извиняюсь: очепятался. pc-файл, для pkg-config'а.

А что конкретно ты имеешь ввиду под словом искать?

Вернуть нужные CFLAGS и LIBS, например — чтобы скомпилировать получилось.

Вернуть нужные CFLAGS и LIBS, например — чтобы скомпилировать получилось.

Например так:

http://industriousone.com/topic/pkg-config

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

да, там можно например тупо cmd-команду забить (есть plugins вроде)... по типу gcc blah.c -o blah, наверное... но тогда обо всех плюсах можно забить.

какбэ команда может быть либо задана через проперти (типа -Dcompiler=gcc), либо через профили, которые в свою очередь могут активироваться, к примеру, типом ОС. т.е. мавен сам выберет, вызывать gcc или cl в зависимости от используемой ОС, но для этого надо все это сначала один раз написать в pom-файл (который потом можно инклюдить в нужные тебе проекты).

Образец рабочего кода для premake кинуть можешь?

Лови исходники:

http://pastebin.com/MTG8yiEy http://pastebin.com/GykMUyXi http://pastebin.com/6dipgXpi

и выхлоп:

http://pastebin.com/XqEhE6Kz

Работает на mac/lin/win.

Кошмар! cmake проще.

files { «*.c» }

Мне кажется, что так делать не есть хорошо. Лучше перечислять файлы для избежания ошибок.

Мне кажется, что так делать не есть хорошо. Лучше перечислять файлы для избежания ошибок.

Почему? Каких ошибок можно избежать?

Читай выше http://www.linux.org.ru/forum/development/8742804/page2?lastmod=1358889701564#comment-8747334 (комментарий)

Ну может быть. Хотя это мне кажется довольно надуманной проблемой, поскольку git status все расскажет. Если нет, то git clean спасет точно.

Скажи мне, почему поддержка Qt в premake добавлялась изменением в коде приложения, а не в скрптоте?

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

Кстати, сам premake - то же по сути «скриптота» :)

Офигеть, у premake'a нет мультипроцессорной компиляции на релиза в VS.

Емнип, эта возможность есть не у всех версий. В любом случае, можно указывать свои buildoptions.

Куда патч слать?

https://bitbucket.org/premake/premake-dev/pull-requests

На стабильную ветку (4.4):

https://bitbucket.org/premake/premake-stable/pull-requests

Я по будням редко читаю ЛОР, так как сильно отвлекает от работы :)

Если есть неприязнь к hg, можно сделать пулл-реквест на https://github.com/annulen/premake, но это не официальный способ (т.е. после ревью мне придется руками отправить его в битбакет)

Будем ждать premake 5. Очень рассчитываю что получится что-то годное. В принципе меня бы и cmake устроил если бы не ужасный язык, которым он оперирует.

Клево. Спасибо.

Емнип, эта возможность есть не у всех версий. В любом случае, можно указывать свои buildoptions.

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

Еще мне например не нравится то что если в solution указать location, потом include директорию с проектом без location, то пути не будут относительно solution. Я только не знаю это баг или фича?

Еще мне например не нравится то что если в solution указать location, потом include директорию с проектом без location, то пути не будут относительно solution.

location отвечает только за каталог, в котором генерятся проект/мейкфайл, а пути задаются относительно premake4.lua

Наверно я плохо объяснил. Вот есть ./premake4.lua в нем я объявляю solution и говорю location «build», потом include «src». Есть ./src/premake4.lua, в котором project «foo» и все описание для foo. В результате получится ./build и ./src/build. Так вот последнего мне не надо. Решений тут несколько: либо в ./src/premake4.lua Сказать location "../build", либо руками прибить к абсолютному пути с solution. Я предлагаю запилить в ядро условие если в project нет location, то класть в тот location, что будет у solution.

Вопрос: это баг или фича, и куда сабмиттить в 4.4 или 5?

А, теперь понял. Это фича, но спорная, дискуссия здесь:

http://industriousone.com/topic/should-location-propagate-projects

За Сконс надо жесточайше карать.

Я фокнул https://bitbucket.org/premake/premake-dev Он сам себя не может собрать через gmake. Я что-то делаю не так или это нормально?

У меня собирает

https://bitbucket.org/yups/premake-dev/commits/25c730ab36e1be85f474b5e5b5825d8e

см src/actions/make/make_cpp.lua

в src/host/os_getversion.c просто косметика