Какую систему сборки вы используете в своих проектах?

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

тащемта он описывал либы/хедеры/опции + итоговые Makefile's +
тестовые poc для требуемых либ = версия, результаты вызовов комбинаций требуемых функций, тест целевой системы по размерам int/float/double etc.
ну и я не против тащемта наколенного баш(Makefile)-скриптинга, если тенденция и видение позволяют ;-) - правда, говнецом-с, попахивает-с, извиняюс-с

Кто он? И что он описывал?

Если нужно из кучи TeXов книжку собрать, то какие либы нужны и баш-скриптинг? Баш-то не везде есть, кстати.

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

Кстати советую провести такой эксперимент. Взять openssl и собрать его стандартной системой сборки. Потом взять какой-нибудь проект с гитхаба, в котором вокруг этой либы запилили cmake (тысячи их), и сравнить скорость и удобство.

autotools, automake, autoconf, autogen
тащемта они.
и с их помощью собираются ~30/40% компонентов любого дистрибутива.
boot-into-[rust|go|java|scheme|erlang] пока ещё не показали

Кажется мы о разном. Диалог глухих.

и с их помощью собираются ~30/40% компонентов любого дистрибутива.

К счастью этот процент падает: https://gms.tf/the-rise-of-meson.html.

бинарная эквивалентность? при идентичных параметрах?

Имеется в виду это?

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

А Nix может любой пакет отбилдить до совпадения хешей (собственно он только так и билдит), при этом без разницы какая система сборки у этого компонента, хоть написанные руками bash скрипты.

наследник, рад что QB для каждого пакета возможен;)

Все

• make Мои скромные нужны покрывает на 142%

В конце опроса победит make, уверен на 142%. Если нет, не буду ходить на лор месяц, а то весь испереживаюсь от негодования.

platform.io, redo

cmake+make или cmake+VisualStudioSolution (т.е. если делаю кроссплатформ, то делаю свои симейки так чтобы они генерили нативное решние для VisualStudio).

А Ninja (который с определенной версии Смейка стал юзаться по умолчанию - отключаю, и всегда заставляю cmake работать с make, я конечно знаю о плюсах в скорости сборки у Нинзя, но мне это как ни странно менее приоритетно чем более красивый(читай привычный) вывод сборки от make)

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

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

Я обычный домашний пользователь и ничего не использую из этого)

make, CMake+Ninja, но иногда и tup.

Малопопулярная утилита, а жаль.

Держи: parallel jobs

Можно ещё так:

cmake SRC_DIR -G Ninja
ninja -j N_OF_THREADS

Можно ещё в самом CMakeLists прописать при желании.

P. S. У ninja сократили вывод до минимума и убрали цветную подсветку, дабы небыло лишних задержек во время сборки, он выводит только важные сообщения. И у него вроде есть опции уровня verbosity.

даже упорно погуглив я не нашел как наложить ограничение

Позор какой. А ninja --help ты не догадался посмотреть? Или предположить что ключ такой же как у make?

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

ну я использую Bazel, спрашивай свои ответы

Ты им яву собираешь?

C++ и немного питона

Осилил make ом собирать драйвер для вай фай адаптера. Собственно это не мой проект(может форкнуть его и добавить туда реадме с интрукцией?) но при обновлении ядра нужно повторно это делать.
Имею ли я право гордо написать что использую Make!?

Нет, не проголосовал.

Лего

Странный вопрос. Как будто новые проекты каждый месяц создают, и всегда дают выбрать систему сборки на свой вкус.

У meson есть прикольная фича subprojects, когда можно взять чужой проект гитовым сабмодулем и практически не меняя его импортировать таргеты в единое дерево сборки (т.е. без всяких install и FindSomething). cmake так ещё не научили?

make (выпиливаю, в качестве интерпретатора kati для всего, кроме ядра), CMake (тоже уже выпиливаю), Meson (постепенно перехожу на этот вариант), ну и, конечно, всё это подпёрто скриптами на POSIX Shell.

странный вопрос, если честно. Рекурсивность - одно из основных свойств всех систем сборки, add_subdirectory в cmake было с начала времен.

add_subdirectory для внешнего проекта редко работает как хочется, т.к. нет не добавляет нового пространства имён.

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

Проект на meson тоже должен быть, разумеется?

Нет, в новых версиях пишут, что можно и cmake:

https://mesonbuild.com/CMake-module.html#cmake-subprojects

Но такую комбинацию пока не пробовал.

Где stack/cabal?

Пока вас здесь трое.

Разумеется cargo. Тратить своё время на C/C++ в наше время жуткая глупость, свободное время для своих проектов слишком ограничено.

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

Надо всё в один файл писать, сборка - зло

Чего только не наподключают в проект, лишь бы STL не использовать.

Ты знал, ты знал!!!

Мои скромные нужны покрывает на 142%

Нужды кроссплатформенные или *nix-only?

Make с самописными Makefile, MSBuild.

Нужды локалхостные :)) А так, с локалхоста где есть make и его друзья можно собрать чво надо как надо :D с pkg-config вообще ляпота. Ну под прости хоспади венду собрать могу. Так что не *nix-only. Хотя сборка это фигня. Тут уже гораздо важнее как код написан, а написан он в 99.999999% случаев под аля POSIX ибо нутыпонял.