Какую систему сборки вы предпочитаете?

Для себя - сижу пробую meson. Вроде бы пока отторжения не вызывает. Может только пока.

уже тот факт что он на питоне должен вызывать отторжение.

Но это же куча писанины. И как в make сделать адекватное сообщение о нехватке библиотеки?

сообщение о нехватке библиотеки выдает линкер, а не make.

но можно сделать так же, как делают всякие автотулсы — дергать pkg-config предварительно.

GNU Autoconf! GNU Automake! ну Libtool опционально для особых любителей

Makefile

this. Не без недостатков, но все остальное вообще швах: либо привязано к конкретной платформе/языку, либо NIH прет изо всех щелей, либо просто сделано хипстерами для хипстеров «лишь бы не по-человечески». Make же относительно прост, достаточно удобен, ничем не ограничивает полет фантазии и, черт побери, делает одну вещь, но делает хорошо, не пытаясь кроме разруливателя зависимостей быть до кучи менеджером пакетов, системой контроля версий, кэширующим сервером и бог знает чем еще.

Субъективно по ощущениям: дурацкий питоновский кодинг-стайл meson-а меньшая боль по сравнению со странноватым cmake (в частности и с его недоlisp-ом).
Если отвлечься от питона, то meson довольно простая система, работу вроде как выполняет (как минимум, мне пока не встретилось задачи, которую не описать), и даже, на удивление, шустро.

Понимаю. Если не ошибаюсь в cmake есть такая возможность. Мой вопрос был скорее о том, можно ли на голом make сделать так же, без лишнего геморроя.

Понимаю. Если не ошибаюсь в cmake есть такая возможность.

cmake - это просто генератор makefiles (который — сюрприз! — выполняются черщз make)

Мой вопрос был скорее о том, можно ли на голом make сделать так же, без лишнего геморроя.

смотря что подразумевать под лишним геморроем и голым make.

cmake - это просто генератор makefiles

Не только. https://cmake.org/cmake/help/v3.10/manual/cmake-generators.7.html
Мне показалась удобной возможность cmake https://cmake.org/cmake/help/v3.10/manual/cmake-packages.7.html
Если я правильно понимаю, то наличие нужных библиотек, заголовочных файлов итп, cmake проверит до генерации файла сборки или я ошибаюсь?

Интересная вещь. Только я не понял как менять дефолтные флаги компилятора для --buildtype debug и release. Единственное что я нагуглил, оказалось предупреждение и совет: дефолтные флаги могут меняться со временем (пользователь, видимо, не имеет на то прав, только разработчики) потому лучше использовать plain и определять все флаги вручную. Это не фатально, но как-то недружелюбно, что ли. Может дело, что он ещё в бете.

Меня очень привлекает этот вариант своей доступностью для пользователя. Помню ещё как пользователь (без минимальных знаний в программировании) имел дело с этой системой, понравилась в первую очередь доступными сообщениями о нехватке чего-либо, ну и есть по умолчанию, наверное, в любом дистрибутиве. Только вот сходу не удалось найти какой туториал или доступных примеров для начинающих. Также беспокоит отказ таких проектов как GNOME и GTK+ от тулзов в пользу мезона.

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

http://www.gnu.org/software/autoconf/manual/autoconf.html

https://autotools.io/index.html

Не только.

но в том числе.

и да, поиск библиотек делается самим cmake. но ничто не мешает делать это из makefiles.

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

кстати, странно, что не упомянули Kbuild, написанный целиком на makefile.

уже тот факт что он на питоне должен вызывать отторжение.

а почему?

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

кодинг-стайл meson-а меньшая боль по сравнению со странноватым cmake (в частности и с его недоlisp-ом).
со странноватым

да у cmake наркоманский синтаксис

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

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

кстати тоже использую premake, годная вещь

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

ЯННП, люди которые проголосовали за makefile, вы все сами руками пишите? Вообще ССЗБ что ли?

Вообще ССЗБ

Почему?

вы все сами руками пишите?

А ты код программы которую нужно собрать тоже генерируешь автоматически?

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

даже если руки кодеров прямые?

судя по всем прогам на питоне, с которыми мне приходилось сталкиваться, руки у всех питоно-кодеров не вполне прямые...

ЯННП, люди которые проголосовали за makefile, вы все сами руками пишите? Вообще ССЗБ что ли?

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

А ты код программы которую нужно собрать тоже генерируешь автоматически?

Если это какой-нибудь api-wrapper, то да. Причем каким-нибудь питон скриптом.

билчерерразруливатель комбайн

cmake

fixed

Я просто держу директорию которая выглядит вот так:

build
src
lib
premake.lua

и копирую ее когда надо.

нет проекта такой сложности который нельзя описать в Makefile

так я себе и представлял лозунг эталонного ССЗБ

для автоматизации разных задач

каких таких задач кроме сборки проекта?

и так'и что же по ваш'ему не так с cmake?

А что тогда мусье скажет про ghc --make? А ведь разницы между «build в IDE» и этим не так уж и много (для пользователя).

Уже вторая страница, а никто так ещё и не сказал, что Makefile - как бы не система сборки сама по себе, «сборка» им является лишь частным случаем использования.

То ли дело лисп на мейке написать! https://github.com/shinh/makelisp

https://autotools.io/index.html

Каждый раз, когда начинаю читать эту книгу, заканчиваю фейспалмом на перепутанных host и target.

Да тут дело даже скорее не в предпочтениях. приходится иметь дело с: maven, sbt, cabal/stack, Makefile (autotools), cmake, gradle.

Любых

понял, возьму на вооружение

https://github.com/shinh/makelisp

ахахах зачёт ::)

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

Вспоминаются cmake туториалы которые писали аутисты для инопланетян

каких таких задач кроме сборки проекта?

запуск тестов, деплой, локализация, и т.п.

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

и так'и что же по ваш'ему не так с cmake?

прочитать тред не судьба?

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

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

Еще с доисторических времен исповедую простое правило: не использовать в именах файлов и каталогов что-либо, отличное от [a-zA-Z0-9_-.] , ибо как и где оно аукнется - пес его знает. Впрочем, в последнее время все-таки ослабил это требование по отношению к некритичным данным - фото котиков, аудиозаписи котиков и видео котиков вполне неплохо хранятся и в путях с пробелами. А вот для каких-то проектов - все по старинке.

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

иногда даже задачи другой билд-системы можно автоматизировать через make. например, у меня есть makefile который дергает gradle и adb, + ряд других вещей, для работы над андроидным проектом.

писать «make» проще чем «gradlew --daemon -p app assembleRelease»

Не разработчик, но make отличный инструмент чтобы интегрировать вещи вроде Terraform, Ansible, и т.д.

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

))) Походу, мсье джавист, не иначе :)

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

MSBuild

Прочитал, но что-то ничего особо аргументированного не нашел.

))) Походу, мсье джавист, не иначе :)

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

Прочитал, но что-то ничего особо аргументированного не нашел.

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

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

А в остальном что?

Каждый раз, когда начинаю читать эту книгу, заканчиваю фейспалмом на перепутанных host и target.

береги лицо, Сеня (с) ))

который типа закрывает брешь.

Вспомнил ещё несколько наркоманских приколов CMake, с которыми сталкивался лично.

1. В Qt-проектах если cpp-файлы и хедеры лежат в разных директориях то бишь, к примеру, src/ для .cpp и include/ для .h, то кодогенератор MOC просто не запускается.

Решение костылём: свалить всё в одну директорию или напихать заголовочные файлы в add_executable()

Посты на ЛОРе с этой проблемой:
Как сделать из Qt pro проекта CMake? (комментарий)
Cmake Qt 5.6 undefined reference to vtable (комментарий)

2. Использование кастомных линкёров, вроде того же gold или тех, что имеются в Embedded-тулчейнах.

Раньше переменная CMAKE_C_COMPILER определяла не только компилятор, но и линковщик. Переменной для задания своего линкёра тупо не было.

Решение было костылём: лезть в дебри CMake и использовать всякие хаки, вроде переменной CMAKE_C_LINK_EXECUTABLE со всей строкой линковки, которую нужно было оборачивать скриптом-прокладкой, потому что параметры были захардкожены и передавались только для GCC-совместимых линковщиков.

Не знаю, изменилась ли ситуация сейчас, но такая наркомания это последствия ущербного проектирования. У CMake есть много вещей на которые можно ткнуть пальцем и сказать «это должно быть проще/лучше/понятнее». И это только то, что сразу вспомнилось. Там куча подводных камней в любом направлении, если твоя задача чуть-чуть выходит за рамки описанных в документации примеров использования.

1. В Qt-проектах если cpp-файлы и хедеры лежат в разных директориях то бишь, к примеру, src/ для .cpp и include/ для .h, то кодогенератор MOC просто не запускается.

И патч до сих пор никто не принёс?

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

По-моему, линкер до сих пор инферится из пути, указанного в CMAKE_C_COMPILER (пусть даже с префиксом).