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

Но тем не менее отсутствует в твоём Makefile, который должен работать пусть даже исключительно на конкретном локалхосте. Завтра поменяется:

$(CC) -o $@ -c $<

на

$(CC) -Dfoo -o $@ -c $<

и объектники не пересоберутся или пересоберутся частично, что ещё хуже.

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

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

С того, что оно не работает и все генераторы cmake генерируют разные Makefile для каждой ОС.

Вот как мне в Makefile подключить фреймворк на макоси, но при этом чтобы эта задача/команда пропускалась на других ОС?

В CMake всё хорошо с инкрементальной сборкой.

Шта? У меня есть жирный проект (не мой), в котором 100500 зависимостей и cmake каждый раз их все проверяет на изменения, что занимает 100500 лет. При этом параллельно работает cargo, который делает это мгновенно.

cmake каждый раз их все проверяет

CMake делает одноразовую проверку на этапе генерации, чтобы удалить цели, для которых изменился хеш правила сборки. Всё остальное время работает только ассемблер сборки (make, ninja), причём последний делает это максимально быстрым способом, потому что зависимости хранятся и подгружаются в бинарном виде.

Про какой «каждый раз» идёт речь?

Каждый раз как я делаю build.

То-есть вызов ninja? Попробуй сделать time ninja -vn (dry run), можно будет увидеть реальные команды, которые ninja посчитал нужным выполнить. Если там обнаружится что-то ненужное, то ищите ошибку с зависимостями у себя в CMake-скрипте.

К примеру, у меня есть проект на 3500 целей, проверка зависимостей между ними занимает 0.1 секунды на SSD и 0.25 секунд на HDD.

При чём тут ninja? У меня вообще JOM.

К примеру, у меня есть проект на 3500 целей, проверка зависимостей между ними занимает 0.1 секунды на SSD и 0.25 секунд на HDD.

Я про 3rdparty либы, который сорцами лежат в дереве проекта. Их проверка (уже собранных) занимает порядка 15сек.

Насколько я понимаю, jom это тот же make, только в профиль, откуда и могут быть тормоза. Что мешает переключиться на ninja? Продолжая свой предыдущий пример, у меня проверка зависимостей между теми же 3500 целями на make занимает 50 секунд на HDD. Разница в 200 раз говорит сама за себя. Опять же, стоит средствами jom/ninja проверить не выполняются ли паразитные команды, чтобы понять, проблема в инкрементальной сборке, в jom или в чём-либо ещё.

Вот блин, раскусили :(

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

+1. Но начинать придётся с другого: таковой репозитарий невозможен без соглашений об именовании либ (а именно, reverse domain names; нынешний юниксовый ад не прокатит). Ну и если сравнивать с maven-овскими репами, в сявых/плюсявых пакетах потребуется ещё хранить информацию о поддерживаемых ОС и компиляторах.

Какие вопросы я пропустил?

Самые важные вопросы были заданы здесь: Conan, пакетные менеджеры в С++ (комментарий)

Вообще мне с закрытым ртом сложно отвечать.

Что-то незаметно.

Не вижу смысла в IDE.

Вы не видите. Я тоже не вижу. А вот миллионы пользователей IDE (QtCreator, CodeBlocks, KDevelop, CLion, VisualStudio) плевать хотели на наше мнение.

На самом деле, они не хотят видеть cmake.

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

И, по большому счету, лучше уж иметь CMake, который устраивает 80% разработчиков, чем 100500 разнородных инструментиков, каждый из которых интересен только 5-10% программистов.

Я юзаю bazel.io как совмещенную систему сборки и менеджер пакетов.

Пакеты приходится «писать» самому (на деле это BUILD-файл с инструкциями, как это собирать, и ссылка на git-коммит/тэг репозитория). Геморройно (особенно когда всякие config.h генерятся), но возможно.

Все герметично, можно хоть бинарники gcc скачивать из репозитория и собирать ими. Никаких «собирать devtoolset-6 с boost из epel».

Можно пример hello world?

Удобная штука

Использую этот Conan. Нравится. Основной смыл - кросплатформеный (Windows\Linux) единый доступ к упакованным библиотекам. Упаковываем библиотеки сами. Довольно неплохо интегрируется с CMake (в пакеты вложены свои FindName.cmake скрипты). Примеры наших исходников пакетов тут: https://github.com/odant/

Я тоже когда-то интересовался, дочитал до момента:

include(${CMAKE_BINARY_DIR}/conanbuildinfo.cmake)
conan_basic_setup()

После чего закрыл и забыл.

А if отменили уже? А обертку сделать из которой запустится оригинальный CMakelists.txt, нЭ?

Лучше так: https://github.com/conan-io/cmake-conan CMake знает как проект собирается (Debug\Release, x86\x86_64 и т.д.), вот пусть он и запускает Conan с нужными параметрами.

Завязать сборку на доступность github - прекрасная идея.

Мимо)) На гитхабе оно лежит только потому, что там из коробки есть Travis и Appveyor (ну не допили еще свои build-сервера). Так то в офисе свои сервера с SVN и Conan.

Я не знаю, где у вас что, но вижу, что скрипт по твоей ссылке зависит от github. Leftpad strikes again.

Что мешает его в проект положить? Можно даже гитовым сабмодулем.

Что мешает его в проект положить?

«Его» - это conan? Ничего не мешает. Можно и conan-сервер локально развернуть. Но пойнт в том, что кто-то (большинство?) просто вкорячат твой скрипт в проект и завяжутся на github.

У нас так делать не будут. Предлагаю решать проблемы по мере их поступления. И да, apt/yum тоже в интернет ходят))

Самые важные вопросы были заданы здесь: Conan, пакетные менеджеры в С++ (комментарий)

Моё дело озвучить проблему, а выводы каждый для себя сделает сам. В моих глазах Конан это полумера. Для своих небольших проектов я решил остановиться на использовании традиционного пакетного менеджера ОС, доставка кода через git/repo, управление зависимостями с помощью CMake/ExternalProject. Для более крупных проектов я бы обратил внимание на Bitbake.

А if отменили уже?

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

А обертку сделать из которой запустится оригинальный CMakelists.txt, нЭ?

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

на использовании традиционного пакетного менеджера ОС

На Windows этого нет.

с помощью CMake/ExternalProject

Очистка директории сборки потянет пересборку зависимостей. А это долго. Да еще на каждой машине заново повторятся будет.

На Windows этого нет.

К сожалению, да. Приходится ставить руками набор python/cmake/ninja/mingw/git и так далее. Кстати, как Конан это решает на Windows?

Очистка директории сборки потянет пересборку зависимостей

Доставка кода у меня через git/repo. А CMake только для связывания их зависимостями.

Кстати, как Конан это решает на Windows?

Python ставить ручками придется (ибо на нем Conan и написан). А вот CMake/Ninja и т.д. может притащить на конкретную машину разработчика уже можно готовыми бинарниками и в PATH путь к ним дописать: http://docs.conan.io/en/latest/devtools/create_installer_packages.html

У меня таким образом perl и nasm подтягиваются при сборке openssl под Windows

Доставка кода у меня через git/repo

Сборка зависимостей из исходников? Хочется уже собранные бинарники (своими ручками) библиотек подключать к проекту. Conan позволяет это делать одинаково и на Linux, и на Windows.

В целом, описано тут: https://docs.bazel.build/versions/master/external.html

./configure оборачивается в genrule, но в BUILD-файле нужно заранее прописать, какие файлы он сгенерирует и список исходников, которые нужно компилировать (можно через glob).

Моё дело озвучить проблему

Ну вот поэтому ваше мнение именно там, откуда вы его извлекли. Поскольку для развития C++ экосистемы оно не приносит никакой пользы. Скорее наоборот.

Сборка зависимостей из исходников?

Да, для небольших проектов это не вызывает проблемы. Даже лучше — позволяет создать воспроизводимую сборку из доверенных источников. К примеру, в repo/bitbake можно задать SHA1-сумму репозитория Git как ревизию проекта, что гарантирует его целостность. А что есть в Конане для проверки источника?

Если речь про бинарные пакеты, то вопрос доверия закрывается установкой своего сервера (+https).

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

Rust, по сравнению с C++ — УГ