Проект mesa3d перешёл на сборочную систему meson

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

Ограниченость языка делает крайне трудным создание универсальной реализации поиска модулей. Поиск модулей должен учитывать особенности расположения файлов конкретного дистра, при этом сверху каждая либа должна задавать собственный правила расположения своих файлов (просто потому что они не стандартизированы). Тебе уже нужно две стороны мирить между собой, а рамками голого языка CMake делать это - боль и страдание. Там уж проще запускать внешнюю тулзу, которая будет настроена для продвинутого поиска, а сам CMake должен только передавать ей параметры поиска и обрабатывать выходные данные.

В общем, уже сейчас, для того, чтобы иметь хорошие шансы собрать/пропатчить рандомный проект на C или C++

А что, писать INSTALL файл в корне уже не модно? Какая разница, какая сборочница у проекта.

Не все же являются мейнтейнерами дистров, нафиг это всё знать. Хотя о чем это я, мейнтейнеры то обычно и не знают нифига, кроме своего CoC

Они понаделали костылей для поиска пакетов, но это костыли, а не полноценный пакетный менеджер.

Они их понаделали, потому что нет полноценного обобщённого инструмента для поиска пакетов. В каждой ОС свои погремушки, в некоторых их вообще нету от слова совсем.
А в Линуксе так ещё и от дистрибутива к дистрибутиву разнятся.

Ну так-то и pkg-config есть и возможность его использовать в CMake. Но опять же и его не все используют. И приходится опять городить костыли в зависимости от ОС или дистрибутива.

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

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

Да ни так чтобы уж и много:

 # equery g =dev-util/meson-0.49.2
 * Searching for meson0.49.2 in dev-util ...

 * dependency graph for dev-util/meson-0.49.2
 `--  dev-util/meson-0.49.2  amd64 
   `--  dev-python/setuptools-40.6.3  (dev-python/setuptools) amd64  [python_targets_python3_5(-)? python_targets_python3_6(-)? python_targets_python3_7(-)? -python_single_target_python3_5(-) -python_single_target_python3_6(-) -python_single_target_python3_7(-)]
   `--  dev-libs/glib-2.58.3  (dev-libs/glib) amd64 
   `--  dev-libs/gobject-introspection-1.56.1  (dev-libs/gobject-introspection) amd64 
   `--  dev-util/ninja-1.8.2  (dev-util/ninja) amd64 
   `--  dev-vcs/git-2.21.0  (dev-vcs/git) amd64 
   `--  virtual/pkgconfig-1  (virtual/pkgconfig) amd64 
   `--  dev-lang/python-3.5.5  (dev-lang/python) amd64 
   `--  dev-lang/python-3.6.5  (dev-lang/python) amd64 
   `--  dev-lang/python-3.7.3  (dev-lang/python) [~amd64 keyword] 
   `--  dev-lang/python-exec-2.4.6  (>=dev-lang/python-exec-2) amd64  [python_targets_python3_5(-)? python_targets_python3_6(-)? python_targets_python3_7(-)? -python_single_target_python3_5(-) -python_single_target_python3_6(-) -python_single_target_python3_7(-)]
[ dev-util/meson-0.49.2 stats: packages (11), max depth (1) ]

Оно же хочет черта лысого и еще горку того-не-знаю-чего сверху

$ urpmq --requires meson
meson: ninja
meson: python(abi)[== 3.5]
meson: python3-setuptools

А вот у меня как раз модулей питонятины нужной версии и не хватает. И простым способом эта проблема не решается, т.к. зависимости. А еще сам мезон нужен довольно свежий, а он требует относительно свежего gcc.
При использовании autotools можно было собирать мезу с python2 и не париться.

А еще сам мезон нужен довольно свежий

Да даже в дебиане стейбле есть 0.49 (правда, в бэкпортах). И в росу 2016 с ейным gcc 5.5 сегодня прилетел 0.49.2. Проблема разве в каком редхате/слес/убунту лтс есть, но там нафига распоследняя меса?

они не обязаны лично тебе гарантировать сборку

Чёт кукаретингом завоняло, но ладно. И чо?

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

Давайте, скажите мне

Не, все же сформулируй нормально свою мысль, это я ниасилил

Последний абзац же. Нужна система сборки, которая сможет организовать софт на произвольном компе на фоне наличия нескольких принципиально разных источников этого софта и нескольких ветвей зависимостей онного. В *никсах издревле уже был налажен отдельный корень /usr/local, например, можно расширить эту фичу. Чтобы связать зоопарк - ввести какие-нибудь гибкие хард/симлинки, модификацию PATH, LD_LIBRARY_PATH. С инклудами вообще быть проблем не должно, потому что системы сборки обычно предоставляют возможность сколько угодно источников добавлять.
Каждая версия некоего рядового диструбутива собирается целиком и является единой логической единицей, потом можно оставить ее в корне, как некую базу, средство загрузки и fallback вариант.
Я вдохновлен примерами stack/pip/docker, но изоляция - это плохой выход. Должна быть интеграция, но ограниченая и управляемая. Разные версии библиотеки ставятся на одну систему, но по мере необходимости используются те, которые нужны, а не все сразу кучей мешая друг другу.
Nix и Guix чем-то мне напоминают описываемое - хз, почему не взлетели, и насколько они подходят под мое описание. Там не все гладко, как то знаменитые пути к пакетам
https://nixos.org/nix/about.html
«/nix/store/b6gvzjyb2pg0kjfwrjmg1vfhh54ad73z-firefox-33.1/»
Критика за бородатый год: https://lists.debian.org/debian-devel/2008/12/msg01027.html
Там же упоминается, что у дебиана уже есть умные системы определения зависимостей, правда, они все равно не помогают держать на одной машине зоопарк.

А что, писать INSTALL файл в корне уже не модно? Какая разница, какая сборочница у проекта

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

Они их понаделали, потому что нет полноценного обобщённого инструмента для поиска пакетов. В каждой ОС свои погремушки, в некоторых их вообще нету от слова совсем.

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

Ну так-то и pkg-config есть и возможность его использовать в CMake

Это скорее ограниченный унифицированный доступ к пакетным менеджерам. А на мс вижуал студие нету pkg-config, например.

Пока с этим сосут все системы сборки что работают с c/c++.

Так-то конечно в той же жабке и ржавом эту проблему решают, но вот с сишечкой и плюсами почему-то за столько лет никак не решат.

Конечно нет.
Под виндой вообще ничего нормального из инструментов нет.
Есть вижуалстудия ну и недавнопоявившийся vcpkg с боку-припёку.

давайте же найдем, из-за кого у меня софт не собирается

Ну этого во многих местах в достатке

Нужна система сборки, которая сможет организовать софт ...

Если я верно понял(а это не факт, под конец для голова не особо хорошо соображает), ты хочешь некоторую общую схему, в которой не придётся рыскать по куче путей в попытке найти нечто - достаточно будет посмотреть в одно единственное место. Т. е. стандарты навроде hfs. Ну не знаю... На мой взгляд, не взлетит. Как не взлетел тот же hfs(на самом деле как бы взлетел, но как бы и нет - толку от этого не слишком много). Системы слишком разные, обобщить их, наверное, не получиться

HFS? Может FHS? Как бы именно его я и критикивал, потому что модель единой корзины, куда сваливаются все файлы, не есть приемлима.
Грубо говоря, неплохо было бы сделать возможность вынести часть дерева пакетов в /usr/local15, в котором скомпилировать /usr/local15/local7, /usr/local15/local8 и /usr/local15/local9, а потом иметь возможность избирательно промоутить кусок иерархии из /usr/local15/local9 в /usr.
Соответственно, классическая проблема «у меня не собирается $softname из-за того, что в дистре $libname неправильной версии» или «мне нужно создать выделенное пространство для разработки» решается созданием нового пространства в /usr/local16, степень изолированности которого определяется какими-нибудь переменными окружения.
Правда, здесь возникает проблема «юзер хочет обновить софт в базовом дереве». Хз что с этим делать, например, делать резервную копию старого дерева для отката, и пересобирать/копировать новую ветку для новых зависимостей.