если у вас есть ccache он будет использован, у меня чуть место в $HOME не кончилось

Добавь compression = true в ~/.ccache/ccache.conf. Ну и ограничение по общему размеру кеша тоже стоит добавить.

Побрюзжу

В общем, уже сейчас, для того, чтобы иметь хорошие шансы собрать/пропатчить рандомный проект на C или C++, надо знать кучу систем сборки: autotools, cmake, meson, qmake, scons. Особняком стоят обычные мейкфайлы: обычно они используются в качестве промежуточного продукта, но мне попадались и проекты (в т.ч. довольно известные), использующие GNU make напрямую. У большинства перечисленного при этом в хлам наркоманский синтаксис и слабый контроль правильности. (Хотя на meson я ещё надеюсь, возможно, потому, что толком ещё не тыкал его.)

В то же время в объектном Паскале (Delphi, fpc), который тут многие проФФесионалы обсирают, для мелких и средних проектов система сборки как отдельная сущность вообще не нужна. Ибо в языке есть встроенная модульность, и файл проекта совмещён с главным модулем. Решение спорное, вероятно, не всегда подходящее, но простое как топор и ПРОСТО работает.

А ведь могли бы прикрутить, допустим, в качестве приложения к стандартам C и C++ описание стандартного декларативного формата файла проекта сборочной системы, позволяющее стандартные вещи описывать предельно лаконично, со строгим контролем. А тяжёлые случаи выносить в какую-нибудь секцию unsafe со cmake-подобным синтаксисом...

Всё правильно сделал. Не на CMake (тот же самый autotools, только в профиль) же переходить.

autotools

Выкидывают.

qmake, scons

Не встречал.

cmake, meson

Эти да.

для мелких и средних проектов система сборки как отдельная сущность вообще не нужна

И как сторонние библиотеки подключаются? А то так и на С не нужна.

в объектном Паскале

Как там будет выглядеть поиск сторонней либы по нескольким путям с фоллбэком на другую либу?

Старые инструменты постепенно устаревают и выходят из использования, это нормально. Зоопарк CPU и операционных систем очень сильно сократился, а значит нет больше нужды вызывать на каждый чих проверки того, имеется ли в libc функция atoi() или нет. Далее – новые системы решают проблему многопоточной сборки, там где фейлит привычная всем утилита make, которая в многопоточном режиме собирает медленнее чем тот же ninja, который писался в те времена, когда CPU стали многоядерными и умеет адекватно распределять нагрузку.

Да и сам синтаксис Makefile – это полная и неочевидная хрень, со всякими закорючками типа .PHONY %: % $^ $@, значения которых не ясны по первому взгляду. Про принудительную завязку на табы я вообще молчу. Про то, что make это наспех сделанная утилита, костыль мира UNIX-like, который лень было написать адекватно, знает, наверное, каждый.

Так что чем больше сборочных утилит будут отказываться от генерации Makefile’ов, тем быстрее это недоразумение канет в Лету.

unsafe со cmake-подобным синтаксисом…

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

Вроде f(ARG1 x ARG2 y ARG3 z) вместо привычного всем f( x, y, z ) или регистронезависимости из винды.

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

Nix же. Операционку на нём уже сделали, система сборки на очереди.

регистронезависимости из винды

Вот именно из-за этого ты и хэйтишь cmake?

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

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

Не встречал.

scons я в опенсорсе тоже встречал всего один или два раза. Но попадалось. А qmake до сих пор довольно популярна в кутешных проектах. Хотя есть тенденция к постепенной её замене на cmake — но по правде говоря, синтаксис у qmake гораздо лаконичнее, чем у cmake.

со всякими закорючками типа .PHONY %: % $^ $@, значения которых не ясны по первому взгляду

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

В то же время в объектном Паскале (Delphi, fpc), который тут многие проФФесионалы обсирают, для мелких и средних проектов система сборки как отдельная сущность вообще не нужна. Ибо в языке есть встроенная модульность, и файл проекта совмещён с главным модулем. Решение спорное, вероятно, не всегда подходящее, но простое как топор и ПРОСТО работает.

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

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

Основная причина того, что CMake ущербен это его отвратительная работа по поиску библиотек/зависимостей:

За что так не любят cmake? (комментарий)

На говнистый и убогий наркоманский синтаксис DSL’а в CMake’а, можно забить. Но когда твой проект наполняется крапом в виде кривых и полурабочих CMake-модулей, это вызывает лишь отвращение к этой сборочной системе. В итоге весь интернет и GitHub пестрит криво сделанными модулями на каждую зависимость и библиотеку. Одни из них не могут нормально в Windows, другие (лол!) в Linux, третьи – не знают, что существует macOS, Android, iOS.

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

По сборке мне думается, что нелохо бы зашло нечто вроде пролога,

Make уже есть

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

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

Да и сам синтаксис Makefile – это полная и неочевидная хрень, со всякими закорючками типа .PHONY %: % $^ $@,

любой синтаксис - неочевидная хрень для человека, который его не знает

Как там будет выглядеть поиск сторонней либы по нескольким путям с фоллбэком на другую либу?

Перед компиляцией запускается скрипт, который делает то же самое, что cmake, scons, и так далее. Результаты обычно пихаются в *.inc и подключаются во все файлы, прям как сишные заголовки.

Перед компиляцией запускается скрипт, который делает то же самое, что cmake, scons, и так далее.

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

Так оно везде так, вроде. Разница только в том, что разрабы cmake, во-первых, захотели сделать по-нормальному, а во-вторых, уже поняли, что это не прокатит. А в meson как с этим дела?

Cmake и пр. сами ничего не делают, им сказать надо что(и в некоторых случаях, как) делать. Каким образом некоторый скрипт сможет узнать, что я предполагал использовать символ X из библиотеки Y, мне неведомо

Сделать по-нормальному это сделать хотя бы community-driven репозиторий, где можно было бы брать эти модули (написанные и проверенные компетентными людьми) для различных библиотек и не думать о том, заработает ли модуль написанный тобой (или взятый из интернета) на Android или Windows.

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

Так оно везде так, вроде.

Такой наркомании, которая появилась в CMake, после того как они перестали принимать адекватно написанные модули и переложили это дело на пользователей: https://github.com/Kitware/CMake/pull/152 нет ни в одной сборочной системе.

А в meson как с этим дела?

https://mesonbuild.com/Dependencies.html

Основная причина того, что CMake ущербен это его отвратительная работа по поиску библиотек/зависимостей

Честно говоря, я не понимаю, почему описание поиска SDL должно занимать больше одной строчки.
Алгоритм принятия решений собирается из пяти сторон:
- создатель софта;
- создатель используемой софтом либы;
- сборщик базовой системы;
- создатель системы сбора софта;
- конечный сборщик софта, который получил продукты от четырех вышеупомянутых сторон, и думает, как теперь это все собирать.

Построение CMake позволяет принять во внимание мнение от силы трех стороны: создателя системы сборки, создателя софта, конечного сборщика. Собрать все необходимые условия от всех сторон воедино практически нереально ни с помощью CMake, ни Makefile, ни принятых ныне приемов работы со SCons.
Когда они просты и стандартны - все в порядке, когда что-то становится сложным и нестандартным - все бегут к разрабам и просят «примите во внимание... учтите вот это». А разрабы что? А разрабы не всемогущие, к ним прибегает чел, который не может собрать софт на Minix - они должны теперь под него систему прогибать. То есть, как бы они должны сделать супер-пупер сложный алгоритм сборки, который в том числе проверяет atoi(), которая будет учитывать особенности всех систем, и своевременно обновляться под их изменения, да еще систему тестов желательно разработать, чтобы обратную совместимость поддерживать, а то вдруг два анона решат собрать древний софт.
А вы бы осилили?

community-driven репозиторий

Тут одно из двух:

• необходимость сопровождения поделок, которые были приняты(community же), но используются тремя с половиной анонимусами(а времени отнимают кучу). Поэтому сейчас с дистрибутиным наполнением происходит то, что происходит
• pure community-driven - github и прочие уже есть. В один проект не собрано, разве что

Приемлемых альтернатив-то не видно, я вот о чём

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

Благодаря тому, что нет нормального репозитория с модулями CMake – теперь поиск различных SDL-библиотек занимает сотни строк: https://github.com/Kitware/CMake/pull/152/files Ибо эти файлики ты должен тянуть теперь сам, или надеятся на то, что разработчик библиотеки не забьёт на CMake. А он, конечно же, забьёт.

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

По сборке мне думается, что нелохо бы зашло нечто вроде пролога,

Make уже есть

Не вижу декларативности-функциональности. Тупо на секции разделен, не более того.

Не вижу декларативности-функциональности

А зря. Это почти пролог под другим названием

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

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

А версию gcc тоже необязательно - я же хорошо знаю свою версию. И ядро у меня не будет какой-то старой версии - зачем проверять? И бинарники у меня все либо в /usr/bin, либо в /usr/local/bin, зачем их еще где-то и искать?... и так далее, и в итоге получается, что кому-то густо, а кому-то - пусто.

И бинарники у меня все либо в /usr/bin, либо в /usr/local/bin, зачем их еще где-то и искать?

Если они у тебя где-то в другом месте, для этого есть переменная окружения PATH

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

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

Был бы у этого мезона аналог cmake external projects, можно было бы с crapmake уже наконец свалить

The dependency detector works with all libraries that provide a pkg-config file

+$project-config. То же самое, по сути. То есть они пока не поняли, что это не взлетит. Интересно, сколько упорствовать будут

Если они у тебя где-то в другом месте, для этого есть переменная окружения PATH

У переменной PATH больше функций, чем просто служить путем поиска компилятора для твоего единственного проекта. К слову, в CMake я лично видел, как для подобных целей переменную временно изменяют, потом вызывают сборку, и ставят обратно. Не PATH, но подобную.

необходимость сопровождения поделок, которые были приняты(community же), но используются тремя с половиной анонимусами(а времени отнимают кучу). Поэтому сейчас с дистрибутиным наполнением происходит то, что происходит

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

pure community-driven - github и прочие уже есть

Я вижу:

1. FindSDL2_mixer.cmake
2. FindSDL2_mixer.cmake
3. FindSDL2_mixer.cmake
4. FindSDL2_mixer.cmake
5. FindSDL2_mixer.cmake

Тысячи их и все разной степени упоротости. Какой из этой помойки правильный и рабочий?

В один проект не собрано, разве что

В том-то и цимес. Идиоты из Kitware даже до инициативы по созданию community-driven репозитория CMake-модулей не могли додуматься.

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

нравятся подобные извращения

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

В табах нет ничего плохого, но завязка на ТАБЫ и ошибки при использовании пробелов (напрочь отбитые и неинтуитивные типа Missing separator: 16) – это плохо. Все мы натыкались на ситуации, когда этот чёртов Makefile переставал работать после внесения правок, из-за того, что редактор, где он редактировался, не знал о такой ахинеи и «особенностях» этого языка описания.

любой синтаксис - неочевидная хрень для человека, который его не знает

Создатели make экономили на буквах? Раз такое дело, могли бы вообще аналог Brainfuck’а взять, чего уж там. И всех остальных обзывать неосиляторами.

У переменной PATH больше функций, чем просто служить путем поиска компилятора для твоего единственного проекта.

Есть ещё переменные CC и CXX, а у бинарников компиляторов есть префиксы (arch-vendor-os) и суффиксы с версией

К слову, в CMake я лично видел, как для подобных целей переменную временно изменяют, потом вызывают сборку, и ставят обратно. Не PATH, но подобную.

и что в этом плохого

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

Это пока конкретно про это не зашла речь. Где-то тут даже были негодования по поводу выкидывания пакетов из стандартных реп. Кстати, сомневаюсь, что ты используешь подход «установка либ ПМ-ом дистрибутива». Нужные библиотеки всегда в репу тащатся. И внезапно модуль из дистрибутива системы сборки не заработает с новой версией библиотеки(он о ней просто не знает). Подход «разработчик библиотеки пишет config-файл» выглядит единственно верным.

Тысячи их и все разной степени упоротости

В этом и беда community-driven, взгляды слишком разнятся

Создатели make экономили на буквах?

Очень может быть. Телетайпы, первые юниксы, все дела

Нужные библиотеки всегда в репу тащатся. И внезапно модуль из дистрибутива системы сборки не заработает с новой версией библиотеки(он о ней просто не знает).

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

Подход «разработчик библиотеки пишет config-файл» выглядит единственно верным.

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

В этом и беда community-driven, взгляды слишком разняться

Linux как-то живёт с этим, цветёт и пахнет, не забывай об этом.

В плане систем сборки перспективно выглядит build2 (не путать с бустовым b2).

Но на дворе у нас 2019, а все телетайпы в музеях.

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

И тут возникает закономерный вопрос: а к чему системе сборки это промежуточное звено вообще нужно?

Мало того, что оно тормозит саму сборку, так ещё и не умеет нормально параллелиться.

P.S. в подходе генерации Makefile’ов, можно привести прямую аналогию с подходом костылей и всяческих извращений из вебни вроде минификации скриптов и компиляции в JavaScript.

Языки (JavaScript, разметки Makefile), которые создавались для редактирования руками, теперь используются для того, чтобы быть своеобразным исполняемым «байткодом». Почему? Потому что интерпретатор говно и кривой, а заменить его низзя. Это ли не грандиозное извращение и костыль? В этом UNIX-мирок полный подобных велосипедов можно сравнить со современной вебнёй.

Хотя, в вебне эту проблему хотя бы начали решать с помощью WebAssembly, ну а в UNIX-like появились новые и более адекватные как системы сборки, так и генераторы, которые обходят проблемы, связанные с Makefile’ами. Прогресс, однако.

Адекватная поддержка версионирования

Вот, кстати, не хватает этого во многих местах. Те же библиотеки в системе - версия там, конечно, есть, но только у shared objects, а под виндой и того не дождёшься

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

Ну это же проблемы разработчиков, а не cmake-а. А криво и .pc написать никто не мешает. Что до linux-а, сразу вспомнились systemd-срачи(и до сих пор ведь идут, хотя размах уже не тот). Цветение цветением, но тоже не всё гладко

И тут возникает закономерный вопрос: а к чему системе сборки это промежуточное звено вообще нужно?

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

хотя не, это я про ./configure :)

а к чему системе сборки это промежуточное звено вообще нужно?

Чтобы создавать стандартизованный Makefile, понимающий стандартные цели и ожидаемым образом их исполняющий

Ну это же проблемы разработчиков, а не cmake-а.

Я просто хочу сделать в каком-нибудь абстрактном CMake что-то вроде:

use_modules(/path/to/community-driven-cmake-modules-collection)

find_package(SDL_mixer >= 2.0.0 REQURED)

А не извращаться с их написанием в неочевидном синтаксисе и не тянуть каку в рот рандомные модули из интернета себе в проект.

А криво и .pc написать никто не мешает.

Да вот прямо недавно было: Статическая линковка myapp+libcurl+libssl

CMake FindModules, pkg-config *.pc files, Android *.mk files, libtool *.la? files – какую ещё гадость и дрянь должны знать разработчики библиотек? Появится новая и популярная система сборки и они должны будут её поддерживать? А если их ещё двадцать появится? Может быть разработчики из Kitware оплачивают написание всяких FindModules и включение их в кодовую базу библиотеки? Я о таком не слышал.

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

хотя не, это я про ./configure :)

Вот в том-то и цимес, что autools’ы генерируют bash-простыню, которая генерирует Makefile свой для каждого случая.

Чтобы создавать стандартизованный Makefile, понимающий стандартные цели и ожидаемым образом их исполняющий

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

https://github.com/GodFox/magx_kernel_xpixl/pull/1/commits/5ca246809be3d726ad1447716868e86858318943

P.S. подобных ошибок бы не было, если бы ./configurе был вещью в себе и строил внутреннее представление под самого себя без учёта того, что синтаксис языка сборочной утилиты внезапно могут поменять и нигде не сообщить.