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

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

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

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

Чукча не читатель, только комментатор?
Здесь я говорил о cmake и там я мог удалять кэш и перезапускать конфигурацию, не меняя флагов и он пересобирал только то, что зависело от новой конфигурации.

muon вроде содержит только подмножество meson.

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

Тебя ждет еще множество открытий в жизни.

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

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

А знаете почему? Потому что для определения изменений он считает хеши вместо временных меток.

Cmake + ninja, и ничего не нужно выдумывать.

Указываю новые CFLAGS, CXXFLAGS, запускаю meson setup –reconfigure с новым buildtype, запускаю ninja, И НИЧЕГО НЕ ПЕРЕСОБИРАЕТСЯ!!! Только линковка запускается повторно! Для чего нужна билдсистема, которая не может отреагировать на изменение конфигурации?

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

Мезон в этом плане ничем не отличается от маке, цмаке и т.п.

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

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

Цирк.

Так причём тут meson? Он новые флаги прописал? Если прописал, то это ninja должен пересобирать.

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

Юникс-вей не про это
…
Ты описал что угодно, но только не unix-way :D

https://en.wikipedia.org/w/index.php?title=Unix_philosophy&oldid=1291775239#Origin:

The Unix philosophy is documented by Doug McIlroy in the Bell System Technical Journal from 1978:

• Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new «features» [emphasis mine]

Т.о., мы не расширяем make возможностью собирать отдельно от сырцов, а создаём для этого другой инструмент. (Более общий, который позволит не только писать артефакты сборки в отдельное дерево каталогов, но ещё, например, загружаться с RO-корнем, но иметь возможность писать логи и т.п. Или хранить систему в RO-чипе, а конфиги — в RW.)

В тему тут будет и другая формулировка:

• Write programs that do one thing and do it well
• Write programs to work together

Программы делают одну вещь: make оркестрирует сборку, оверлейные ФС комбинируют деревья каталогов. И они могут работать вместе.

Он про одну единственную вещь, «не делай сложно, если на то нет веских причин»

KISS это очень общий, неспецифичный принцип

Ну, да. Так как прям от первоисточника, то молчу.

в других языках люди от нечего делать библиотеки делают, а в c/cpp от того же самого сборки рисуют.

Да, он много чего не собирает.
Но для примитивных проектов годится.

Не думаю, что там проблема во временных метках, видимо waf не пытается переиспользовать кэш при вызове configure в отличие от meson и cmake

Это всё костыли от манагеров. Система сборки не справилась со своей задачей, значит обернём её в другую, поместив в тепличные условия. Фэтпаки кстати - такой же костыль.

ты это разрабам mesa скажи...

… (конфигурация может занимать больше времени, чем сама сборка) …

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

… часть сгенерированных файлов должна лежать в директории с исходниками.

это единственная проблема autotools если не требуется сборка в windows

Чем это лучше autotools

Кстати, недавно увидел https://github.com/radareorg/acr.

ACR tries to replace autoconf functionality generating a full-compatible ‘configure’ script (runtime flags). But using shell-script instead of m4. This means that ACR is faster, smaller and easy to use.

Не пробовал. :)

При изменении параметров компилятора надо вызывать meson setup --wipe. Параметры компилятора не входят в список отслеживаемых изменений. Meson просто не знает какие флаги на что влияют. Некоторые пользователи не хотят, чтобы всё автоматически пересобиралось при обновлении версии компилятора.

Цирк

Вот уж точно. Еще и месон поливают кто во что горазд. Хотя его единственный минус это питон. Это лор, че.

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

Чтобы солдат программист не делал, лишь бы задолбался.

позорище как список файлов-исходников

А что в нем позорного? Иметь список того из чего собирается проект - это хорошо.

исходники он сам найдёт

Что-то сама идея поиска исходников не выглядит привлекательной. Потому что вообще любой поиск всегда может найти что-нибудь не то. Явное указание всегда лучше если есть такая возможность. Бывает ведь и такая штука как кросскомпиляция когда проект собирается не на той системе где он будет работать. Например сборка на x86 под arm.

Используй оверлейные ФС

Ну на своей машине допустим можно. А как быть другим людям которые захотят собрать ваши исходники? У них в системе может не быть включенной возможности использования оверлейных ФС.

Ну соберут в одном каталоге с исходниками, эта возможность никуда не девается

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

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

make or gfto

зависит от автора configure.ac, проще говоря от того количество проверок флагов, хедеров, функций и т.п. что он укажет

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

А что в нем позорного?

То, что это прямое признание - "я не читал мануала".

Иметь список того из чего собирается проект - это хорошо.

Нет, это позорище полное. Неуд и на пересдачу.

Что-то сама идея поиска исходников не выглядит привлекательной. Потому что вообще любой поиск всегда может найти что-нибудь не то.

Для безграмотного идиота, в глаза не видевшего мануал по мейку - да.

Чтобы идея начала выглядеть привлекательно, надо, наконец, прочитать мануал.

Явное указание всегда лучше если есть такая возможность.

Конечно лучше. Главное - указывать то, что надо, а не список *.c / *.cpp файлов.

Бывает ведь и такая штука как кросскомпиляция

Каких только штук не бывает, и все они, что характерно, делаются через make на раз-два.

… авторы configure.ac пихают какой-то единый шаблон, в древние времена написанный и минимально подправленный ими …

и да и нет, базовый configure.ac, как правило, создаётся посредством запуска autoscan который включает ряд проверок в результирующий файл, потом автор может/должен поправить его под свои требования

… проверка которых актуальна для сборки на совсем древних системах где эти исходники всё равно не соберутся …

откуда это извесно ?

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

пример cmake, это не говорит о том что все такие и что такое бывает только в cmake ;), https://github.com/warmcat/libwebsockets - при сборке с OpenSSL всегда запускается генерация сертификатов https://github.com/warmcat/libwebsockets/blob/main/lib/tls/CMakeLists.txt#L445 , оно наверное не плохо, в случае cross-compile пытаются использовать не хостовый openssl, оно наверное можно «хакнуть» систему, но узнаёшь ты об этом уже значительно позже конфигурирования

Конечно лучше. Главное - указывать то, что надо, а не список *.c / *.cpp файлов.

как Вы предлагаете решать вопрос условной сборки если некий функционал опционален и включается через параметр конфигурирования или проверки ? далеко не весь подобный функционал можно/нужноделать через ifdef, часто он находится вотдельных файлах, linux как достаточно наглядный пример

как Вы предлагаете решать вопрос условной сборки

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

Всегда ваш К.О.

А что в нем позорного?

То, что это прямое признание - «я не читал мануала».

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

Главное - указывать то, что надо, а не список *.c / *.cpp файлов.

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

Каких только штук не бывает, и все они, что характерно, делаются через make на раз-два.

Вот тут согласен. Хотя и не «на раз-два» но таки сделать с помощью make можно,да.

откуда это извесно ?

Да хотябы из readme в котором автор написал что это для относительно современного линукса,а не какого-нибудь bsd из 90х годов.

Если проект собирается из сишных файлов - то почему нет?

См. выше.

Хотя и не «на раз-два»

Именно что на "раз-два". Для этого, конечно, надо прекратить бороться с системой, пытаясь превратить make-файл в bash-скрипт, и начать ею пользоваться, как задумано, а не как "ну это же bash, только синтаксис другой".

Он там создает список объектных файлов вместо списка файлов с исходниками. Что противоречит лично моему чувству технической эстетики. Ибо объектные файлы - это «промежуточный продукт» сборки. Их имена второстепенны. А там еще и вместе с именем каталога build они записаны. Некрасиво. Ладно бы еще этот список объектников автоматически генерировался из заданного списка исходников.

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

начать ею пользоваться, как задумано

Задумано увы далеко не всегда удачно. Как минимум потому что полвека назад когда задумывали - небыло такого разнообразия требований к системе сборки и всё было намного проще.

Вот в качестве примера общеизвестный среди программистов под микроконтроллеры AVR шаблон мэйкфайла,который используется в большим количестве разных проектов(моих тоже): https://alexkaltsas.files.wordpress.com/2012/03/makefile.pdf Его модифицируют по мелочи под собственные надобности, но основа остается. И список исходников там задается в переменной CSRC. Вот вариант того же мэйкфайла прямо тут на ЛОРе: размер бинарников avr-gcc

Я хотел сослаться на свой подправленный вариант но хостинг для временного хранения файлов 0x0.st вдруг начал выдавать invalid user agent для curl и я не знаю какой он хочет.

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

У гомосеков трушных пацанов не стоит на красивых девчонок на cmake.

Что противоречит лично моему чувству технической эстетики.

Твоё чувство эстетического этого самого противоречит формальной логике инструмента make. Не используй его - сделай себе (и окружающим) одолжение.

среди программистов под микроконтроллеры

Следующий!

Чо, бомбануло? 😁

Бывает...

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

Твоё чувство эстетического этого самого противоречит формальной логике инструмента make

Не факт. Я привел пример шаблона мэйкфала,написанного куда более авторитетными людьми чем я. Там тоже есть список файлов с исходниками. Также я читал статью «Эффективное использование GNU Make» https://www.opennet.ru/docs/RUS/gnumake/
(раньше и на ЛОРе лежала но сейчас ссылка на нее выдает 404) И там в примерах тоже список файлов именно с исходниками:

source_files := Editor.cpp  TextLine.cpp 

Так что мне кажется что ваши высказывания несколько категоричны и противоречат «первоисточникам».

А вот пример где в мэйкфайле был бы вручную создаваемый список объектых файлов - мне не попадался.

Не используй его

Хорошо, предложите пожалуйста чем бы вы заменили приведенный мной пример мэйкфайла для сборки кода под микроконтроллеры. Я и сам от него не в восторге из-за «многословности» - но уж что есть.

среди программистов под микроконтроллеры

Следующий!

То есть вы считаете что программирование под микроконтроллеры это и не программирование вовсе? И не нуждается в хороших инструментах? Или как понимать ваше высказывание?

и пистон у меня в системе выпилен

Для такого есть muon.

Но одну причину существования долбанного meson я всё же назову. Почти все остальные сборочные системы ещё ужаснее, чем сабж.

По синтаксису мне понравился Bazel, но работать я его так и не заставил (я явно чего-то недозадал в файле проекта, но чего именно, так и не понял, bazel вместо чёткого сообщения об ошибке валит стектрейс, скорее всего, в кровавом энтерпрайзе с готовыми шаблонами на все случаи жизни это не проблема, но я не кровавый энтерпрайз, поэтому ниасилил). cmake и не только она – это специализированный скриптовый язык «а давайте мы используем это для сборки». И так далее.

Хочу сборочную систему с декларативным строгим синтаксисом, чтоб на любую очепятку типа «SOURSES» реагировала вылетом с указанием на ошибку. Чтобы если в крайнем случае если понадобится что-то нестандартное-императивное, оно размещалось в специальной секции unsafe :), а для 90% проектов хватало стандартных объявлений (типа список исходников, список заголовочников, тип проекта, имя цели и др.) в синтаксисе, похожем на сам Си. Чтобы была написана на чистом Си и собиралась любым компилятором с поддержкой C99 или новее. Джва года жду, в общем :) Мечтать, как известно, не вредно, вредно не мечтать, вот. :)

вот я про него я и узнала сегодня. точнее, когда-то давно (и я даже нашла старую версию в сорцах) я про него уже узнавала. но он был ещё маленький, недопиленный и не работал. потом я про него забыла, а его тем временем всё-таки пилили. сейчас он работает (ну, почти). осталось неправильная генерация имён библиотек: типа, библиотека libname.so.1.2.3.4, на которую есть линк libbname.so.1. а тут вроде в генерируемых файлах название библиотеки указано верное и soname libname.so.1, но генерится libname.so.1, а линк не создаётся. пока не разобралась, почему. но это уже мелочи, это я найду и пофикшу, если что.

По синтаксису мне понравился Bazel

Осталось попробовать их же GN: https://gn.googlesource.com/gn. :)
Язык: https://gn.googlesource.com/gn/+/main/docs/language.md.
Там внизу и про Bazel (ранее Blaze) немного есть.

Чтобы была написана на чистом Си и собиралась любым компилятором с поддержкой C99 или новее.

Это про Premake. :)

qbs с интересными концептами и декларативностью, пользуюсь им пока, но мне не нравится его «JS'нутость».

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

Также я читал статью «Эффективное использование GNU Make»
А вот пример где в мэйкфайле был бы вручную создаваемый список объектых файлов - мне не попадался.
Так что мне кажется что ваши высказывания несколько категоричны и противоречат «первоисточникам».

Вот именно в этом и заключается "проблема make" - наглухо забаненные в интернете люди копипастят кривые реализации друг у друга и брутфорсят незнакомый язык программирования.

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

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

Да, про tup я уже пару раз писал:

• Подготовка к 40-летию проекта GNU (комментарий)
• CMake 3.28 (комментарий)

Он ещё проще, чем make. Но это надо аж статью писать. :)

Давай начнём с простого. Как в make передать и использовать путь с пробелами?