XML с декларативным описанием зависимостей

По-моему, это жесть.

P.S. Подписался.

Нет.

Тут проскакивала на форуме тема про http://mesonbuild.com/index.html

сборка через что-нибудь адекватное типа cmake

/0

навскидку (просто смотри сам что тебе понравится больше): premake, tup, gyp, boost.build, bakefile

а если нравится maven - бери gradle, там есть gradle c++

Лорчую вопрос. Интересует нечто, вроде новомодного cargo, чтобы и цепляться к репам на определённый коммит, и повторяемость сборки из коробки.

Portage из Gentoo

Это почему это? CMake исключительно годен.

Нужно crystax спросить, он с этой темой разбирался для своего NDK. Вроде ничего путного не нашел и стал делать что-то свое.

Очень хвалят на кровавом ынтырпрайзе тот же gradele и мавен.

Однако, как по мне, cmake + build bot должно хватить любому.

Если не хватает, значит пора заняться декомпозицией.

Сейчас модно тащить всё из хромиума. Но тоже подпишусь.

Если бы я был тем самым анонимусом-улыбакой, я бы сейчас поржал :-)

Нужна система для сборки с зависимостями для C++

А может ненужна?

В других технологиях есть альтернативы:

Очевидно потому, что альтернативные либы никто не опакечивает, а так я всё что мне нужно было для сборки ставил через apt-get. И да, с cmake'ом я практически весь день воевал, а qmake за часок накатать смог. При том, что опыта ни в том ни в другом у меня не было.

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

Хотелось бы что-то Maven-like: XML с декларативным описанием зависимостей (исходников и бинарников) и описанием настроек сборки.

Google GYP, отчасти экспериментальный Qt qbs, очень ограниченный вариант — cbp из CodeBlocks, ну а в идеале надо бы кому-то аналог MSBuild из проекта Mono научить собирать плюсовые проекты в том числе для линукса.

- зависимости должны лежать в интернете

Git submodule, сабмодульный репозиторий с предсобранными зависимостями для проекта kokoko можно назвать kokoko-sdk или kokoko-buildenv

- сборка через что-нибудь адекватное типа cmake

Ну cmake-то сам через make работает

удобная настройка выхлопа под разные дистрибутивы (на лине - использование системных либ, на шиндовсе и маке - «всё своё тащу с собой»)

Это можно путями поиска библиотек задавать, т.е. в винде и маке добавляется через -L опцию компилятора путь к сабмодульному хранилищу бинарных зависимостей (kokoko-sdk, kokoko-buildenv, и так далее)

- очень желательна искоробочная работа с гитхабом

Вообще не понимаю, в чём смысл; на билдсервере можно и какие-нибудь питоновские скрипты задействовать с вызовом команды git через subprocess.check_call(); на клиенте будет неприятно из IDE например каждый раз ждать ещё ответа сети при инкрементальной сборке.

Это почему это? CMake исключительно годен.

Даёшь libcmake и интеграцию в IDE, пока этого нет — Cmake непригоден для продакшна и используется в продакшне исключительно за неимением лучших альтернатив.

Ты хочешь что ли сделать эдакую генту, но без генты? Нафига?

Он хочет Gentoo GNU/Windows и Gentoo GNU/Darwin.

Мастдайку уже давным-давно пора закопать, а к пользующимся ею относиться как к какому-то недоразумению природы!

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

Google GYP

И его преемник GN

для кроссплатформы я юзаю boost build v2. синтаксис специфический, хотя и вполне логичный, и документация довольно объёмная. но там реально можно практически всё, что только можно вообразить. а если чего не хватает - можно легко прикрутить. например, для закачки из svn, которой в искоробочном варианте нет, готовый скрипт в интернетах был, его легко подключить в проект. хотя я просто качаю сорцы в подкаталоги башевским скриптом и собираю их потом.
плюсы: в boost build в одном файле можно прописать кучу вариантов для разных платформ и разных компиляторов. есть зависимости как вниз, так и вверх. можно, например, прописать инклюды в той библиотеке, которая их экспортирует, чтобы не тащить их во все зависимые проекты и они сами будут подтягиваться, с путями и т.д. если не пожалеть времени и разобраться с синтаксисом, то довольно удобно. в общем, команда разработчиков boost делала это для себя, чтобы собирать сам boost. меня эта система сборки устраивает вполне.

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

Очень странно, что пока еще никто не упомянул biicode — кроссплатформенный менеджер зависимостей для C++, в качестве системы сборки в котором CMake.

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

Я на одном проекте scons использовал. Вполне себе годно и не так тормознуто как cmake, скачивать умеет.

нет там ничего

и это показатель что как бы rip

CMake говно, но для любителей поверх него есть еще один слой говна - biicode: https://www.biicode.com/

Документация там есть, бабло они просят за т.н. private blocks, которые кроме вас никому не видны (так же поступает и github с приватными репами).

Какие плюсы дает — хз, не пользуюсь ни biicode, ни CMake. Но давно ли CMake стал кроссплатформенным менеджером зависимостей для C++?

Всё это слишком сложно для рядового программиста или админа. Уровень сложности прямо на порядок больше, чем в «накидал названий зависимостей в XMLку, и всё само как-то магически заработало». Я конечно понимаю, что Крестопоклонники привыкли пердолиться с такими проблемами, но у меня похапэшники производят говноигры, написуя код склеиванием готовых библиотек с помощью копипасты со stackoverflow, а сейчас нужно переходить на C++ с Unreal Engine, и я боюсь что всё что сложнее «make install» в корне проекта, будет для них реальным кошмаром. Нужно сделать, чтобы работал привычный вокрфлоу (написание кода склеиванием готового кода). Если подключение зависимостей (и поддержка их в обновлённом состоянии) составляет проблему, то это проблема.

у меня похапэшники производят говноигры, написуя код склеиванием готовых библиотек с помощью копипасты со stackoverflow, а сейчас нужно переходить на C++ с Unreal Engine

Похапешникам на Си++? Стиви, система сборки - это отнюдь не главная твоя проблема %)

непригоден для продакшна
используется в продакшне исключительно за неимением лучших альтернатив

Лол.

и интеграцию в IDE

Какую?

похапэшники

нужно переходить на C++ с Unreal Engine

Лол. Оставьте PHP-макак в покое, пусть дальше тусуются в своей песочнице. Иначе рискуете распугать ошибками компилятора в шаблонах, например. В итоге не будет у вас ни PHP'шников, ни игры на Unreal Engine.

Не скупитесь и купите в компанию крестобога.

Хотя бы автокомплит по модулям и проверку синтаксиса.

CMake говно

Почему? Ну и какой твой выбор?

CMake говно

Почему?

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

Ну и какой твой выбор?

GNU Make. Но да, у меня специфические условия работы.

понятно. они пропихивают свою централизованную систему хранения инфы о библиотеках. но по сути ничего особого не предлагают, кроме интеграции с несколькими конкретными IDE и небольшой автоматизации построения скриптов.
«менеджер» - какое-то нехорошее слово. СMake - просто сборщик. надстройка над make, чтобы было удобнее. в нём можно собирать большие проекты, в которых много библиотек и разных зависимостей.

динамически типизированный к тому же

Это да, но в остальном не сказал бы, что он так ужасен. GNU Make - не замена (в общем случае).

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

scons использовал
не так тормознуто как cmake

как то аж прям толсто

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

Боюсь, вы не видите главного.

«менеджер» - какое-то нехорошее слово.

Ну вот RubyGems — это менеджер пакетов или где? Команда gem install позволяет установить вам тот gem, который вам нужен + все его зависимости. Или обновить до какой-то версии. И т.д.

Ничего подобного в мире C++ не существует на данный момент. biicode пытаются это исправить, причем сделать это действительно кроссплатформенно.

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

Знатокам Хашкеля

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

но у меня похапэшники производят говноигры, написуя код склеиванием готовых библиотек с помощью копипасты со stackoverflow, а сейчас нужно переходить на C++ с Unreal Engine

Будет фейл, инфа 146%.

biicode - это проприетарщина, причем платная? Ненужно же

динамически типизированный к тому же

Это да, но в остальном не сказал бы, что он так ужасен

endif(condition) в роли endif, set(имя переменной значение) - это не песец как он есть? Такое впечатление, что разрабы специально делали говно.

GNU Make - не замена (в общем случае).

Нет ничего, что нельзя было бы заменить на GNU make и немного шелл-скриптов %)

не надо максимализма

Утверждение «CMake - упоротое говно» - не максимализм. Максимализмом было бы сказать «CMake - никому не нужное упоротое говно». Но я понимаю, что он кому-то нужен и полезен.

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

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

а?

не надо максимализма. будто GNU Make с его аллергией на пробелы весь из себя белый и пушистый. было б оно надо - давно бы избавились от маразматического формата с табами

это ж классика олдскульного юникса, при чём тут GNU Make, это для любого варианта Make базовая фича синтаксиса

Самый смак, что они ещё регистронезависимым сделали. Частично, лол. В итоге везде то set(), то SET(), то Set().

С большой буквы или с маленькой?

Язык CMake обладает частичной регистронезависимостью. Имена команд нечувствительны к регистру (IF(), If(), if() и iF() – одно и то же), в то время как имена свойств и переменных – чувствительны. В связи с регистронезависимостью имен команд возникает вопрос, как правильнее писать – с большой буквы, с маленькой или полностью заглавными буквами. Разные авторы пишут по-разному (в документации CMake имена команд пишутся полностью строчными буквами, а во многих файлах CMake, написанных самими разработчиками – заглавными). Лично я пишу имена команд с маленькой буквы, и буду следовать этому принципу в статьях данной серии.

scons вообще-то тормознутый, сильно (не знаю, может cmake и тормознее, но у меня от него были другие ощущения в свое время)

Если вас так тошнит от проприетарщины, то вычеркните из своего списка «MSVS-Windows».

У biicode открытый клиент и бесплатное использование для OpenSource проектов.

Мне самому biicode не нравится, поэтому им не пользуюсь. Но вовсе не из-за догматов «проприетарщины».