Назовите хотя бы одну причину существования долбанного meson...

Да напиши Makefile и не парься. Все эти мезоны и ниндзи только для неосиляторов make-а. Проблема сборки проектов решена 50 лет назад, не надо ничего выдумывать.

У мейкфайла куча проблем вроде отсутствия штатной возможности собирать в отдельном каталоге (да, это делается костылями вроде замены выхлопа зависимостей от gcc через awk, но это уже не возможности самого make)
Нормальные билдсистемы есть, например waf, и даже cmake не имеет таких проблем. Но мне не понятно, зачем этот перизобретённый на питхоне autotools, если оба не могут адекватно отслеживать конфигурацию. И это не в каком-то восянском проекте, а прямо в mesa.

Держи штатную возможность собирать в отдельном каталоге без костылей:

build/%.o: %.c
  $(CC) $(CFLAGS) -c -o $@ $<

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

софтину, которая будет эти говноконфиги в Makefile’ы переделывать

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

эта «велосипедная билдсистема», детка, я думаю была ещё до того, как ты родился. это вообще стандарт.

а вот месон надо убирать к хренам, это факт.

Я имею ввиду ту, которую ты (надеюсь в шутку) собралась писать.

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

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

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

И оно не будет пересобирать файлы при изменении зависимых хидеров. Знаем, проходили

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

Будет, см. главу "4.14 Generating Prerequisites Automatically " в руководстве GNU make, а также флаги -MD и прочие из этого семейства в руководстве GCC. Если опишешь подробней, что у тебя за проблема и зачем тебе потребовался awk, попробуем разобраться. А пока вот тебе вывод на подумать.

% cc -c -o build/main.o src/main.c -MMD

% cat build/main.d
build/main.o: src/main.c src/main.h

Чего тебе не хватает?

Единственный смысл существования meson/cmake/прочее в том что они сами находят пути до зависимостей, в зависимости от хоста сборки. Если тебе это не нужно просто выкинь мезон и напиши мейк файл руками. Хотя смотря что у тебя за проект, если внешний и он уже обвешан мезоном, то сочувствую, ну пересобери тогда всё с нуля очистив кеш =)

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

Я тоже не понимаю нахрена нужен дебильный мезон когда есть симейк и мейк в зависимости от ситуации

Покумекав я припоминаю надобность awk лет 20 назад, когда я что-то подобное делал. Кажется тогда нужно было генерировать .d файлы отдельным шагом сборки и не хватало флагов, поэтому - да, надо было что-то менять, скорей через sed, но не суть. Мне лень заниматься цифровой археологией, как бы то ни было, сегодня gcc предоставляет удобные опции, которые просто из коробки прекрасно взаимодействуют с gnu make, требуя добавления буквально пары флагов и пары строк.

В любом случае это мелочь, даже если бы тебе и надо было добавлять этот самый awk. Это вообще не то, о чём стоит переживать, имхо.

Тоже не понимаю, зачем нужен meson. Ведь есть bazel.

Це шо?

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

И оно не будет

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

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

Да нет, многие пользуются. В РФ, он в Касперском по самые гланды ЕМНИП.

Ты пользуешься и рекомендуешь?

Не. Я просто троллирую ретроградов с их убогим make, который без гнутых расширений никому не всрался уже лет 20.

А так, meson вполне удобен. Мне нравится. Гораздо лучше автолулзов и даже cmake.

Только им кроме гугла кажется никто не пользуется.

Это полуофицильная сборочная система freedesktop’а. Mesa и всякий weston уже давно на ней.

По поводу скрипта на мейке: вообще то при самописном мейкфайле есть иллюзорная вероятность что он не пересоберётся при изменении хедера

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

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

На один флаг и на одну строчку.

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

Я про это и написал, только с намёком что часто (но не всегда конечно) системы сборки вообще избыточны и не нужны как класс для проекта, как раз по причине наличия pkg-config :)

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

А вот щас обидно было :(

Мне что-то не получилось подружить -MD с вилдкардом и subst. android ndk тоже использовал sed или awk для автоподмены путей в .d файлах.
Может быть, не заметил какой-то нужный флаг, но вот пример с sed на SO:
https://stackoverflow.com/a/24129675

У меня примерно так:

objects := build/main.o build/bla.o

build/app: $(objects)
  $(CC) -o $@ $^

build/%.o: src/%.c
  $(CC) $(CFLAGS) -MMD -c -o $@ $<

-include $(objects:%.o=%.d)

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

Может быть, не заметил какой-то нужный флаг,

Самый нужный "флаг" называется VPATH. При правильном его (и всего мейка) использовании ты вообще прекращаешь страдать такой хернёй как переписывание путей (не говоря уж о таком позорище как список файлов-исходников).

список файлов-исходников то получается из wildcard. А как VPATH тут поможет?

Кто не умеет программировать на существующих языках - выдумывает свой язык.

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

И отдельным пунктом специальной олимпиады - менеджеры пакетов

список файлов-исходников то получается

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

А как VPATH тут поможет?

RTFM и узнаешь, как с его помощью делать out of source tree build.

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

Про юникс-вей слышал? Используй оверлейные ФС чтобы читать сырцы с одного места, а писать результаты сборки в другое.

Самый нужный «флаг» называется VPATH. При правильном его (и всего мейка) использовании ты вообще прекращаешь страдать такой хернёй как переписывание путей (не говоря уж о таком позорище как список файлов-исходников).

Зачем писать так загадочно, пусто и надменно? Не судьба написать просто, «в VPATH можно указать каталоги где make будет искать файлы зависимости для целей»? Всё, это простая как палка вещь, нет надо повыёживаться :D

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

Да ладно тебе чё так строго то? Вся суть мейка вот

если_этот_файл_старее : чем_вот_этот_список_файлов
    сделать вот это

Где чем_вот_этот_список_файлов может быть и файлом и целью со своими файлами.

Всьюо! Опять же всё просто и это самое главное, а все приколюхи сверху, это просто нахлобучки, которые удобны, но далеко не обязательны. Не вижу повода ругаться :)

https://github.com/andrei-drexler/ironwail

Там сделано отслеживание заголовков

Про юникс-вей слышал? Используй оверлейные ФС чтобы читать сырцы с одного места, а писать результаты сборки в другое.

Юникс-вей не про это. Он про одну единственную вещь, «не делай сложно, если на то нет веских причин», а из этого уже вытекают простые истины, делать что-то одно, пусть оно будет маленьким, пусть оно будет попроще, пусть оно и так далее. И ему не надо следовать, как закону, к нему нужно стремиться там где это возможно, в переводе unix-way пишется так «не переусложняй» и всё, это банальная прописная истина. Где-то ты не можешь себе позволить сделать что-то просто, а где то можешь.

Ты описал что угодно, но только не unix-way :D
Ты не упросил, а усложнил. Сделал гибче и удобнее, но сложнее. Это не плохо и не хорошо, а просто другое.

CC=... CXX=... CFLAGS=... CXXFLAGS=... meson setup --wipe.

/thread

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

Причина существования Meson в простой возможности описания сборки проектов на C/C++ без прибивания к конкретному компилятору или ОС, с поддержкой указания зависимостей, а также с полноценной поддержкой инкрементальной сборки.

Голый Makefile так не умеет.

А cmake не умеет? А waf не умеет? А autotools не умеет? Мне кажется, даже скунс это должен уметь

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

и даже cmake не имеет таких проблем

Имеет аналогичные проблемы кеширования окружения:

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

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

Как по-вашему система сборки должна отслеживать конфигурацию изменения компилятора? Система сборки не знает назначение всех флагов компилятора и последствий что надо пересобирать после их изменения. Так что при изменении компилятора надо всё заново собирать.

Основная проблема Meson в том, что он на убогом Пистоне сделан. Впрочем, реимплементация Muon именно это и исправила.

Всяко лучше Autotools на убогом Perl, M4 и Shell.

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

При изменении флагов компилятора, которые были бы переданы при компиляции объект должен быть пересобран. meson этого не делает. Или, что ещё хуже, пересобирает его со старыми флагами.

Для cmake я уже привык помимо перезапуска cmake удалять CMakeCache.txt. Тогда cmake начинает действовать максимально логично. И нет, он не пересобирает всё подряд, а действительно сравнивает то, что было подано на вход компилятору - если флаги совпали, цель не трогается. waf здесь идёт дальше, и вместо тупой проверки времени изменения хранит чексуммы входов и выходов каждой стадии. Чуть медленнее (заметно разве что на Эльбрусах), зато надёжно.
Какой файл надо удалить meson, чтобы он заработал адекватно?

Алё, друже, если ты меняешь флаги компиляции, разумно пересобрать ВЕСЬ проект а не его часть. Чистишь build/* и погнал заново.

Как ты надеешься получить что-то рабочее на выходе, если все собрано коряво у тебя!!!

если флаги совпали, цель не трогается.

А с чего им совпадать, если ты их поменял.

а что «обидно»? ты же не пишешь ненужный софт?

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

да ты просто сделал мой день(ночь)!

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

две чашки хорошего винтажного шена за это.