Чем собираете нативный код?

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

Весь код живед в огромном svn репозитории, которым без sparse-checkout пользоваться не реально, там адовое количество C, C++, Java, python кода, ВСЕ внешние зависимости, etc. тулза для сборки таких проектов нафиг никому не сдалась.

sbt еще, если пишу код на scala.

Хотя тут и maven хорош.

CMake + Ninja

mk
Странно, что его нет.

Ничего странного. О нём, как и об остальном Plan 9, разработанным отцами UNIX как замена архитектурно устаревшему (ещё в 80-х!) UNIX, знают только очень немногие и ещё меньше людей этим интересуются.

// Я думаю вбросить эту тему в толксы, но надо ещё думать как это правильно подать, да и есть ли вообще в этом смысл.

«системя»?

И да, я собирал нативный код из-под Gradle, вроде живой :-) На самом деле это не на столько редкий случай на Android.

Как раз родной C++-плагин для грейдла в Андроиде есть редкий случай. Сейчас андроидовский грейдл использует CMake+ninja для сборки C++-кода и делает это криво.

Что в Makefile программы указано, тем и собираю.

Сейчас андроидовский грейдл использует CMake+ninja для сборки C++-кода и делает это криво.

Большинство проектов до сих пор используют Gradle + ndk-build, хоть он и deprecated. А ndk-build это по сути обычные Makefile'ы.

неспешно переезжаю с autotools на Meson/Ninja

Что за бред? autotools и прочие cmake не собирают нативный код, а генерят те же makefile, ninja и тд.

cabal и stack %)

P.S. Приятно, что cmake таки выстесняет autohell. Надеюсь, скоро мы от этого дерьма избавимся окончательно.

Я там выше уже отписал на подобный вопрос. По этому двумя тезисами:

1. Кому интересно, какой «бекенд» ты используешь, если пользуешься CMake?
2. Хочешь сделать хорошо — сделай сам.

Меня поразило насколько популярен QMake. Он ведь довольно специализирован. Впрочем, не откажется собрать не-Qt код.

С другой стороны удивило, что QBS (Qbs?) набрал так мало.

Кому интересно, какой «бекенд» ты используешь, если пользуешься CMake

Ninja значительно быстрее собирает, чем «Unix Makefiles» и тем более, чем nmake, или студийные хрени. Поэтому если cmake, то всегда cmake -G Ninja.

Ninja значительно быстрее собирает,

Субьективно подтверждаю, однако интересно, как они это делают. Ведь львиная доля в этом деле принадлежит компилятору.

qbs слишком молодой. Да и дока у него - дно.

В сети появился код Opera 12. Даже начало собиралось, но было лень разбираться с зависимостями.

gyp нет в голосовании. Он довольно популярен в узких кругах. Особенно у тех работает со сборками/форками chromium. Гугл еще не до конца перешел на ng.

+ тем, кто собирает стандартным способом аддоны для nodejs/nw.js, тоже рекомендуется пользоваться немного модифицированным gyp.

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

+ gyp очень плохо документирован. Шаг вправо, шаг влево - лезь в исходники разбираться в киллометрах питонячего кода. Правда с новой гугловой системой сборки ng все еще хуже.

GNU Make

Mingw-w64

Mingw-w64

то есть mingw32-make.exe

P.S. Приятно, что cmake таки выстесняет autohell. Надеюсь, скоро мы от этого дерьма избавимся окончательно.

А пожешь объяснить, в чем приятность? cmake — это autohell №2 со своим обезьяньим языком вместо bash-а.

А пожешь объяснить, в чем приятность?

1. CMake проверяет корректность скриптов сборки. Autoconf мне много раз выдавал некорректный configure из-за пробела или переноса строки не в том месте.

2. CMake обратно совместим сам с собой. Autoconf часто ломается, из-за чего приходится иметь несколько версий в системе.

3. CMake намного быстрее. У меня в большинстве проектов с autoconf на выполнение configure уходит гораздо больше времени чем на собственно сборку кода. С CMake такой проблемы нет.

4. Сраный m4 уже достал, его надо закопать. Ещё бы awk взяли, блин.

со своим обезьяньим языком вместо bash-а.

В том-то и суть, что bash и m4 - обезьяньи недоязычки.

В том-то и суть, что bash и m4 - обезьяньи недоязычки.

Понятно, субъективизм.

Кстати, а как ты живешь с тем, что в cmake

1. нет аналога --enable/disable-shared/static
2. невозможно посмотреть возможные опции конфигурации, если начальный запуск cmake не пройдет — поди угадай, как называется опция, что тебе мешает
3. нет устоявшейся практики распространения find-скриптов для библиотек: один впихивает внутрь абсолютные пути всего, с чем он линковался; другой городит find_package/find_library внутри своих скриптов (что временами приводит к веселым ситуациям «либа собрана с libfoo-a.b.x, а бинарник, использующий ее с libfoo-x.y.z»); третий вообще не парится и оставляет насладиться find_library пользователям своей библиотеки
4. тупо врубает -DNDEBUG на release-сборках, что не всегда хорошо (многие, кстати, даже не подозревают, что их assert-ы в релизе не уберегут от катастрофы)
5. ни при каких случаях не включает -Wall, отчего многие, кстати, ловят приветы различной степени упоротости в runtime.
6. не предоставляет кросскомпиляторного способа управления уровнями оптимизации (где мой -Og???), уровнем предупреждений и флагами кодогенерации (вкл/выкл sse, avx и прочее)
7. с учетом двух предыдущих пунктов имеет неудоный способ передачи кастомных параметров компиляции (сравни CFLAGS/CXXFLAGS/LDFLAGS и CMAKE_C_COMPILER_FLAGS/CMAKE_CXX_COMPILER_FLAGS/EXE_LINKER_меня_уже_задолбало_писать_эти_длинные_имена)
8. не умеет в uninstall
9. cpack кладет с высокой колокольни на CMAKE_INSTALL_PREFIX и элементарно получается пакет с префиксом /usr/local, который ставится в /usr
10. вычисление зависимостей не умеет в условные директивы и можно попасть в ситуацию, когда твой cmake-проект не будет компилироваться из-за ненужного отсутствующего хидера.

Список можно продолжить, но это самое вопиющее. В autohell-е эти грабли либо проще обходить, либо их вовсе нет.

Да и unix мир гораздо лучше дружит с autohell-ом: легче собрать пакеты системными средствами, каждый админ знает волшебные ./configure --help и ./configure --prefix=/opt/foo.

И это я еще не коснулся custom build rules, которые в GNU make делаются слету, а в cmake нужно посношаться и в итоге останешься с носом компромиссным полувариантом.

Понятно, субъективизм.

Ну, раз тебе всё понятно...

не умеет в uninstall

Я не припомню чтобы кто-то в здравом уме это пользовал в автолулзах.

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

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

CMakeCache.txt (ccmake или GUI вполне себе показывают).

имеет неудоный способ передачи кастомных параметров компиляции

https://cmake.org/cmake/help/v3.8/command/add_compile_options.html#command:ad... Не оно? (там еще target_compile_options)

cpack кладет с высокой колокольни на CMAKE_INSTALL_PREFIX и элементарно получается пакет с префиксом /usr/local, который ставится в /usr

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

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

О каких зависимостях речь? find_package? Там оно умеет ровно настолько, насколько автор соотв. скрипта позаботился.

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

CMakeCache.txt (ccmake или GUI вполне себе показывают).

Дочитай до конца — ccmake ничего тебе не покажет, пока не будет завершен хотя бы один успешный запуск cmake. А читать лапшу в CMakeLists.txt удовольствие на уровне чтения сгенерированного configure

О каких зависимостях речь? find_package?

О build time dependencies. Собственно, это единственная задача, с которой cmake хоть как-то справляется. Альтернатива для make будет занимать порядка 30-40 строк.

на работе у нас вообще своя система сборки написанная на C#

Вы не Unreal Engine случайно пишете?

Дочитай до конца — ccmake ничего тебе не покажет, пока не будет завершен хотя бы один успешный запуск cmake.

Как это не покажет? Даже если генерация мейкфайлов (для бекенда) не удалась — CMakeCache.txt будет сгенерирован а GUI/TUI покажет недостающие и новые значения (которые отмечены как «cache»). Конечно внутренние переменные оно не сохраняет (ибо для того они и внутренние). Но внутренние переменные вычисляются каждый раз при запуске cmake (в отличии от cache). https://cmake.org/cmake/help/v3.8/command/set.html

А читать лапшу в CMakeLists.txt удовольствие на уровне чтения сгенерированного configure

Да, язык/синтаксис наркоманский, но CMakeLists.txt пишется вручную, т.е. степень читаемости зависит от автора. Пренебрежение «ай, всего лишь скрипт сборки» крайне ошибочно.

Почти, но мимо

Лор не торт. Всего один коммент про bazel на второй странице.

Продай его, штоле, а то первовзгляд на сайт как бы говорит, что это унылый клон Make с непонятными граблями унутре.

Это тот, который до сих пор в бете?

scons, meson build

cargo (если речь идет о нативном коде, а не только C и C++)

так практически все генерируют же Makefile в итоге. Зачем тогда тут пункт GNU Make вообще, если он к другому уровню относится?

Он не относится.

Просто «практически все» фейлят осилить хотя бы половины возможностей Make.

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

А про Buck вообще никто не вспомнил.

У меня своя система сборки на основе GNU Make. Проект разбит на модули, в каждом модуле свой make-файл, который делает static-library. У проекта есть головной make-файл, где указываются используемые модули. Этот make-файл компонует полученные static-library в итоговый бинарник. Работает под Linux и под Windows. Потом это дело легко открыть Eclipse'ом. Удобно.

В другом проекте использовался Scons.

в каждом модуле свой make-файл

Буду краток.

Нажимаю F5.
Не ожидал, что есть какие-то ещё варианты ответа. Кто все эти люди?

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

Cargo.

только freepascal только хардкор

dmd