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

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

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

вылезай из криокамеры, такой софт уже давно есть

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

lol

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

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

вылезай из криокамеры, такой софт уже давно есть

...и этот софт для Си++ называется...? Кроме biicode.

Meson.

Ага.. Много++

Кстати, wrapdb.mesonbuild.com

а вообще очевиндо, что задачу можно решить силами Autoconf, Automake и GNU Make

А чем biicode как пример для C++ не подходит?
А чем (кроме того что не cmake) не подходят уже упомянутые тут gradle и maven, которые отлично работают с кодом на C++?

силами Autoconf, Automake и GNU Make

Wget же забыл! Да и если гулять, то GNU Coreutils пачкой.

А чем biicode как пример для C++ не подходит?

Он подходит. Просто и он сам стремный, и CMake у него под капотом стремный.

gradle и maven

Эти не подходят требованием Java.

Блин, если бы Guile интегрировали в GNU Make хоть 10 лет назад :/

силами Autoconf, Automake и GNU Make

Wget же забыл!

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

Вообще мое мнение такое: это не C++ такой особенный и его сложно собирать и поэтому под него распространенной и общепризнанной системы сборки нет, а наоборот - из-за того что под него нет системы сборки его сложно собирать и настраивать проект выкачивая вручную и собирая зависимости. Как только хоть одна такая система наберет популярность другие народятся как грибы (как пример - maven-овские репозитории в java стандарт де-факто и все новые системы сборки в первую очередь начинают поддерживать этот формат репозитория и автогенерацию pom.xml, иначе их никто просто не будет использовать).

Сырцы всех используемых библиоте

Почему всех? Вдруг аффтар какой-нибудь из них принципиально не признавал системы контроля версий

Он подходит.

ну значит я прав.

Эти не подходят требованием Java.

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

Блин, если бы Guile интегрировали в GNU Make хоть 10 лет назад :/

а ему свой рантайм не нужен? (это в контексте отметания из-за требования java)

Вообще мое мнение такое: это не C++ такой особенный и его сложно собирать и поэтому под него распространенной и общепризнанной системы сборки нет, а наоборот - из-за того что под него нет системы сборки его сложно собирать и настраивать

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

Как только хоть одна такая система наберет популярность другие народятся как грибы

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

все C++ программисты так выпячивают свою илитарность

Если это в мою сторону, то мимо.

Блин, если бы Guile интегрировали в GNU Make хоть 10 лет назад :/

а ему свой рантайм не нужен?

Он интегрирован в Make.

Сырцы всех используемых библиоте

Почему всех?

Because we can.

Вдруг аффтар какой-нибудь из них принципиально не признавал системы контроля версий

И почему гипотетического Стиви должно интересовать мнение этого несчастного?

И почему гипотетического Стиви должно интересовать мнение этого несчастного?

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

Например, Lua вот так и распростряняется, в виде архивов, аффтары утверждают, что системой контроля версий пользуются, но показывать свою репу никому не хотят

И почему гипотетического Стиви должно интересовать мнение этого несчастного?

Не, ну Стиви конечно может запихнуть его код в свой репозиторий и качать его оттуда

Для целей Стиви этого более чем достаточно.

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

Хм. А о vendor branch ты, надо полагать, не слышал?

Есть ещё такой параметр, как время инкрементальной пересборки после изменения одного файла.

что мешает вместо Unix Makefiles по-дефолту, задать генерацию для ninja (-G Ninja), да настроить ccache ?

Это про git? Так им все пользуются.

в одной крупной новосибирской компании (>500 человек, офис в Новосибирском Технопарке) мобильное подразделение перебрасывало файлы своего самописного фреймворка в zip-ках через скайп :) А если кто-то дописал во фреймворк что-то новое, тимлид ловил куски кода через скайп и мерджил их вручную, а потом всем рассылал новую зипку. Работа со своим кодом была еще печальней. Так что «все» это несколько оптимистично :))

Ну а git pull origin ну очень сложно набрать, в тысячи раз труднее чем make install.

настроить это всё трудно. Немного другие примеры: легко пользоваться apt-get install package, но только два с половиной землекопа умеют делать свои собственные пакеты, а уж выложить их в официальные репозитории убунты - вообще труба. Или еще более отдаленный пример: очень сложно но вполне возможно пользоваться линуксом через PuTTY (более известное как «пердолиться с консолью»), но практически невозможно поставить линукс на свой компьютер.

У Maven есть плюс в том, что вообще любой приличный проект есть в репозиториях Maven в бинарном виде. Если его там нету, значит проект - говно и ненужен. Это позволяет людям вообще не задумываться по поводу сборки пакетов, некоторые серьезно думают что пакеты им посылает Боженька лично. В Maven можно развернуть свой репозиторий (всякие артифактори и нексусы) либо написать свой за один вечер и батон колбасы, но никто этой фичей не пользуется, потому что всё уже просто работает.

А тут ты предлагаешь обернуть все зависимости в гит-репозитории. Не всё же лежит в гите. А теперь представь, сколько человек знают о гите что-нибудь кроме git pull. Примерно три с половиной землекопа.А,например, сколько было просрано тем, что люди не читают README в корне проекта (в котором написано - сделайте git submodule update и поправьте конфиги).

Поставить гитлаб - уже сложно, потому что требует как минимум знаний линукса, а запатчить гитлаб - требует знаний ынтерпрайзного руби-стека. Чтобы написать поверх гитлаба обёртку, которая будет тянуть в себя внешние зависимости, а потом изображать из себя Maven Central - нужно быть очень крутым разработчиком. Например, нужно быть мной или тобой. А для обычного похаэшника это звучит как фантастика, натурально.

Я хочу надежную систему для Полных Дегенератов. Которая соберет проект во что бы то ни стало, даже если знания погромиста в отношении системы, инфраструктуры и языка стремятся к абсолютному нулю. Ты пишешь make install, и система всё делает за тебя.

У maven, например, с этим есть проблемы. Потому что для сборки типичного проекта нужно скачать зипки с maven, ant, scala, groovy..., установить Java, и потом добавить их в PATH. Многие даже не знают, что такое PATH. И посмотри на количество тем на Лоре про людей, которые не могут установить Java на свой компьютер. Мои погромисты в «одной крупной новосибирской компании» добавляли зипки в PATH и устанавливали Eclipse в течение двух дней (нет, я не совсем понимаю, как можно достичь такой низкой производительности - но они смогли). Так что даже Maven не является панацеей.

Так вот в миру C++ для них уже сборка проекта превращается в полный ад. Особенно под Линуксом, с которым надо пердолиться в консоли вместо нормальных гуёв. Со всяким мерзким гитом, который надо изучать.

Да, у меня лютый дикий адовый баттхерт, поэтому я высрал эту стену текста :(

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

Есть мнение, что реализовать поддержку системы сборки на основе нормального динамического языка в IDE гораздо сложнее, чем поддержку систем сборок с «декларативными» описаниями в XML/JSON/YAML или систем сборок с собственным динамическим говноязычком (вроде CMake или различных вариаций на тему Jam-а).

Посему у проектов вроде SCons нет шансов.

Я хочу надежную систему для Полных Дегенератов.

Вот и непонятно, кто именно полный дегенерат: тот, кто не может освоить сборку проекта для C++ или же тот, кто хочет найти «надежную систему для Полных Дегенератов» в мире C++...

похоже, проще при появлении свободного времени, сделать клон Maven, вначале только для Windows+MSVS. Благо что там делать не rocket science, нужно просто насрать на ненужные фетиши (настоящую кроссплатформенность, поддержку лигаси итп), билдить всё под три компилятора и три ОСи в самых современных версиях, только под x86_64, и паковать пакеты в linux-like стиле. За год можно поднасрать пакетной базы. Возможно, что-нибудь можно будет спиздить из Gentoo Prefix. Как-то так.

Для Windows и MSVS уже есть NuGet. Может и делать ничего не придется.

Тем более, что его, по слухам, пытаются и в Linux тянуть.

не читай, детка. в чём твоя проблема?

подпускать Полных Дегенератов к C++ - очень плохая идея )

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

в одной крупной новосибирской компании

Это в которую со своим стулом приходить работать надо? :)

мдя. помню, когда-то давно мне потребовалось сделать их нашего проекта пакетник (служба поддержки попросила) под редхат. у меня ушло минут 30 на чтение документации и ещё минут тридцать на то, чтобы сделать из кучи библиотек пакет. никакой магии там нет, всё элементарно, дистрибутивы предоставляют полную документацию и кучу утилит для подготовки скелета и сборки пакета без каких-либо особых мозговых усилий.
освоение гита - это вообще задача для детсада. и любой пользователь Линюкса так или иначе является администратором. иначе он просто лох, который зачем-то поставил себе систему, которую он не понимает. и какой смысл тогда вообще ставить Линюкс, если человек не способен осилить настройку пары демонов, по готовым хэлпам в сети? чем плоха консоль? так можно вообще до маразма скатиться. давайте сделаем систему, чтобы каждая домохозяйка могла собрать пакет из сорцов на С++ и выложить его на хостинг. ненуачо?
судя по обсуждению, некоторые хотят магический тулкит, который будет за них всё делать. я по своему опыту скажу, что это нереально. а главное, не нужно. разработка на С/C++ - дело небыстрое. и плакать, что компилируется «долго», просто абсурдно. потому что код пишется ещё дольше и никто не мешает компилировать крупные проекты в бэкграунде на сборочных серверах.
и вот, кстати, когда мы принимали на работу работу новых программистов, то давали им консольку в ssh и предлагали написать тестовое задание. если человек не в силах работать в консоли - он автоматом считается неосилятором и лузером и проваливает тестовый период. потому что в реальной жизни работа в консоли занимает бОльшую часть времени, так как на серверах или встроенных девайсах никто гуй не ставит и программист должен отражать реальность, а не витать в облаках. программист также должен быть админом, отчасти. знать, как настроить сеть, установить и настроить демоны, как быстро поднять виртуалки и пробросить для них туннели. это основы. если он не может этого сделать, то нахрен он нужен? приставлять к каждому няньку нереально. так что знания программиста должны быть достаточны для самостоятельной работы с системой.
я считаю, что надо идти не навстречу дебилам, а исключать появление дебилов в рядах программитов.

плюсую всеми конечностями )

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

Ну и причем здесь CMake?

Большинство пользователей CMake вообще работают по принципу копи-пасты, не особо разбираясь в самом инструменте. А многие, полагаю, даже не видят CMakeLists.txt в глаза, т.к. за них все делает IDE. Если бы кому-нибудь из них довелось в синтаксисе CMake описывать особенность сборки под какой-нибудь уникальной конфигурацией, стона и плача было бы на весь Интернет :)

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

int main()
{
  auto c = compiler_factory(compiler::local, platform_factory(platform::local));
  auto l = linker_factory(compiler::local);
  auto d = download_factory("http://linux.org.ru/download/my_sources_v1.345.7");
  auto g = dvcs_factory(dvcs::git, "128def");
  
  
  std::list <std::shared_ptr <Source>> l = {d->get(), g->checkout()};
  auto objects = c->compile(l.beginn(), l.end(), compiler::release);
  auto binary = l->link(objects, linker::release, boost::asio::hujazio);
  binary->deploy(deploy::everywhere);
  return EXIT_SUCCESS;
}

для сплюса ничего менее уродливого не выйдет.

ещё verbose, и в try catch забыл завернуть.

ну и

if (binary->unit_tests != EXIT_SUCCESS) throw std::string("a vot shtanga!");

ну, что неосиляторы плачут, то не вина CMake'а :)
ну, не могут некоторые осилить кресты, ну что ж теперь? я постоянно вижу на форумах вопросы о «программировании на Qt», причём вопрошающие иногда вообще ничего не знают о С++. они в Qt Creator'е лепят формы и пытаются наугад что-то нагородить в коде. я на собеседованиях при приёме на работу периодически вижу непонимание того, что такое компилятор, линкер и вообще, для некоторых код превращается в бинарник каким-то неведомым магическим образом. и это всё ширится и распространяется. и потом приходится править тонны говнокода. или выкидывать целые модули и переписывать. потому что переписать бывает проще, чем исправить. я не хочу видеть неосиляторов на работе. их не должно быть среди профессионалов. пусть лучше программистов будет меньше в десять раз, но чтобы они были вменяемыми и понимали, что делают.

То, что CMake удобнее обычного Make, это не удивительно. Особенно с учетом того, что этих самых Make со своими тараканами целая куча. Раньше вообще каждый поставщик компилятора снабжал свое поделие собственным вариантом Make.

Удивительно другое: что популярность получает именно CMake. Сложно представить себе более ублюдочный синтаксис описания проектов. Невозможно простить качество документации, размещенной на родном сайте. Такое впечатление, что главная цель разработчиков CMake — продавать книжку о своем поделии.

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

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

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

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

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

Т.е. разработчики SCons или Boost.Jam могут написать нормальную документацию, а разработчики CMake не могут. Ну пусть так.

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

https://github.com/ignatenkobrain/meson_wrap_example

чтобы получить какую-нибудь зависимость, например zlib - достаточно написать wraptool install zlib. Она подтянется с http://wrapdb.mesonbuild.com.

Там пока мало wrap'ов, но всё впереди. Надо только попросить =)

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

поэтому нужно использовать autotools на баше ?)

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

Ну да, вручную компилировать все зависимости - это так весело, а главное, полезно для саморазвития! А авторы apt-get с их build-dep вообще велосипедостроители, каких свет не видывал!

А что же господин понилюб вместо cmake юзает? Automake&Autoconf, которые по своей уродливости конфиг sendmail обогнали?