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

Как в make передать и использовать путь с пробелами?

Так же как в операционной системе 70-ого года выпуска - через жопу.

Быстро ты сдался.

Я даже не начинал.

Всегда бы так))

А ты разве проигрываешь в битвах со своими соломенными чучелами? Тяжёлая у тебя жизнь.

Зачем ты пришёл что-то писать о своём куколдизме и требовать его принятия другими? Да ладно принятия - ты стал требовать от них самих участвовать. У тебя там всё нормально вообще?

Зачем тебе в проекте файлы которые в проекте не участвуют?

Нет, не единственная. После переконфигврации часто начинает пересобираться куча всего лишнего, но не то что надо. Возможно конечно это неправильный Makefile.am/configure.ac, но это были «образцовые» проекты вроде gcc или binutils

CMake

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

Понятно что индустрии нужно утилизировать тонны питон-макак и это чисто отмыв бабла и попытка нагадить, но всё же. Ну иди пиши смаке на пистоне - кто вам мешает?

К тому же я так скажу. В смаке особенно «актуальном» есть что-то похожее на билд-систему. Правда наличие её я не понимаю, но в любом случае. А вот месон это же просто адхок-мусор. Там что не конфигурация то набор какой-то типичной баш-лапши. Чем это лучше мейкфайлов решительно непонятно. Хотя там ситуация получше даже. Ну и не забываем что то дефолтные решения.

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

Т.е это так задумано? А как завайпить только то, что связано с c/c++?

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

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

У меня обратный опыт. Софт со старым configure не собирается для RISC-V без регенерации.

Прелесть автолулзов в том что ты скачал проект, сконфигуренный каким-нибудь 2.61, а у тебя в системе 2.64 - и все, ни черта не работает и сыплет ошибками. Больше того, в одной версии надо экранировать какие-то там переменные, а в другой это ошибка.

Г - ГНУ

и это как раз нужное мне подмножество: С и С++. других у меня нет.

это не так. ошибки будут, если там ну оооочень древняя версия и разность версий automake большая. а так, autoreconf -fi обычнго решает все вопросы, https://www.gnu.org/software/automake/manual/html_node/Upgrading.html

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

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

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

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

Может config.guess какой поправить надо? Там есть проблема с неизвестными таргетами

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

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

Это не мезон, это все сишнокрестовые сборщики. Пиши на жабе

Я не уверен что meson его переиспользует, но вот реализация кэша у CMake это прям что-то очень плохое.

Для чего нужна билдсистема

Для поисков фатальных недостатков в CMake

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

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

В перспективе его заменяют на meson или CMake. meson мне тоже не нравится - это какой-то кастрированный CMake.

P.S. Был ещё какой-то проект, конвертировавший autotools проект в Makefile и убирающий всю не нужную скриптуху.

Разумеется речь не идёт о том, чтобы configure.ac не предоставлять. Речь идёт о том, что в релизные тарболы складывается скрипт, который уже сам говорит, что ему не хватает.
В этом плане у autotools из относительных альтернатив только waf, который будучи самодостаточным (при наличии питухона) скриптом может проверить все необходимые фичи в тулчейне и сообщить, что не так. Причём параллельно в отличие от autotools, который сейчас становыится бутылочным горлышком из-за последовательных проверок. Но даже waf не выход т.к есть ненавистники питухона
meson же при существовании waf кажется каким-то полумером

Был ещё какой-то проект, конвертировавший autotools проект в Makefile и убирающий всю не нужную скриптуху.

ffmpeg чтоль?

ffmpeg чтоль?

Нет, что-то такое появилось после случая с вируснёй в xz, но найти не могу.

ну так там много скриптов и все они что-то проверяют. там могут быть скрипты M4, написанные юзером, например. а также стандартные скрипты проверок, которые вызываются из configure. и когда они что-то не находят, они сообщают об этом.

расковыряла код. это не баг, а фича.

оказывается, при вызове samurai (samu) ему не надо скармливать targets all. при указании all он нихрена не заходит в подкаталоги и ничего там не собирает. надо просто его тупо натравлять на файл, который создал muon - build.ninja и не передавать ему никаких больше параметров. тогда он всё собирает в подкаталогах. такая странная хрень. в общем, вызовы отличаются от meson + ninja.

но в тестируемом пакете (libva) были Makefile'ы в подкаталогах. они какбэ отдельно от месоновских конфигов вообще.

буду продолжать вести наблюдения. это пока только один сложный пакет был собран с тулзами muon + samurai. тулзы в целом работают, но, возможно, нужно будет некоторое допиливание структуры сборки Void для работы с ними. да, если кому-то нужно сборку на Void Linux с muon + samurai, самих пакетов и подключение их в систему xbps-src - могу выложить патчи. у меня маленько другая сборка xbps, но скрипты сборки в master там не менялись, я проверила.

да, там ещё есть мелкая проблема: в код muon защиты ворнинги gcc для сборки c warning_level=everything. а они зависят от версии gcc и более старые версии будут ругаться, что нет такой опции командной строки. там по идее надо делать патчи в зависимости от версии gcc или украшать код ifdef'ами.

Вы слишком категоричны в своих высказываниях. Я специально привел в пример шаблон мэйкфайла который написан достаточно авторитетными людьми,а не какой-то васянский с гитхаба или стэковерфлоу. Да и книга Игнатова тоже весьма известна и авторитетна. Так что спорите вы не со мной,а с известными людьми. Если утверждаете что они все не правы - приводите хотябы конкретные аргументы. Пока что оба примера мэйкфайлов по вашим ссылкам слишком примитивны чтобы можно было использовать их в качестве шаблонов для создания мэйкфайлов в сколько-нибудь существенных проектах. Да, в одном примере отсутствует список исходников и сказано что их можно опустить,типа make сам найдет. Вот только авторы настоящих «больших» мэйкфайлов обычно предпочитают список исходников НЕ опускать. А уж они «осилили букварь» лучше чем я.

Как в make передать и использовать путь с пробелами?

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

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

Такого объёма "аргумента к авторитету" на единицу текста я давненько не видел.

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

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

Ну, собственно ЧТД.

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

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

Пиши на жабе

Или на Аде. Там система сборки является частью компилятора.

да, если кому-то нужно сборку на Void Linux с muon + samurai, самих пакетов и подключение их в систему xbps-src - могу выложить патчи. у меня маленько другая сборка xbps, но скрипты сборки в master там не менялись, я проверила.

Было бы здорово. У меня на одной из машин установлен Void Linux.

в каком смысле «система сборки является частью компилятора»? я просто хочу понять, что это за неведомая фигня, когда компилятор вдруг является ещё и системой сборки.

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

ща приведу это всё в порядок, выложу на свой сервер и сюда кину ссылку.

Такого объёма «аргумента к авторитету» на единицу текста я давненько не видел.

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

у тебя у самого нет ни малейшего понимания, зачем это сделано

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

попробуй сначала убедится, что ты хотя бы понимаешь предмет.

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

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

в каком смысле «система сборки является частью компилятора»?

Ну вот там есть такая штука - gnatmake. Она и компилятор,собственно gnat,вызывает, и с «интерфейсными файлами пакетов» работает (это из терминологии гната),определяя что от чего зависит. Это то чем я сам когда-то пользовался. Написания какого-то отдельного аналога мэйкфайла оно не требует, нужную информацию берет из исходников и «полуфабрикатов», образуемых компилятором,тех самых файлов с суффиксом *.i или *.ali

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

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

Я дал тебе ссылку на букварь, который ты не осилил до сих пор. Каких ещё "аргументов" ты ждёшь? Прочитай главу "за маму", прочитай главу "за папу" чтоле?

вы продолжаете переходить на личности

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

Вот и приходится обсуждать тебя.

Хорошо, давайте обсудим меня. Я не являюсь в настоящее время профессиональным программистом, последние полтора десятка лет занимаюсь программированием как любитель. Я вижу в примерах мэйкфайлов использование списка исходников. Не в одном, в многих совершенно разных. И не «от васяна»,а от людей более авторитетных. И тут появляетесь вы и утверждатете что список исходников нафиг не нужен просто потому что вы так сказали. При том что по вашей же ссылке на документацию сказано что список исходников МОЖЕТ быть опущен,в этом случае make будет искать их сам. Разницу между «может» и «должен» понимаете? При этом в многочисленных примерах «больших» мэйкфайлов список исходников НЕ опускают. Опущен он оказался только в очень простом (так и написано - simple) мэйкфайле. Наверно авторитетные профессионалы лучше знают как писать мэйкфайлы? Поэтому им я верю больше чем вам. Тем более что букварям как раз не противоречит.

Ну и еще одна ссылка:

https://rus-linux.net/nlib.php?name=/MyLDP/algol/gnu_make/gnu_make_3-79_russian_manual.html#SEC125

И там тоже есть список исходников - переменные SRC1,SRC2,SRC3

Если что - это перевод,один из авторов оригинала сам Столлман.

Каких ещё «аргументов» ты ждёшь?

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

патч с системой сборки muon + samurai для Void Linux. вместо meson + ninja.

для использования сборки с muon просто заменить buid_style=meson на build_style=muon в собираемом пакете.

файлы с патчем для сommon/build-styles и c пакетом muon (он немного проапгрейджен по сравнению с master и в него включен встроенный samurai)

https://git.ironbug.org/void-linux-pckgs/plain/xbps_patches/xbps_add_muon_bui...

https://git.ironbug.org/void-linux-pckgs/plain/muon/template

З.Ы. пофиксила патч. туда попал мусор от сборки для старой машины :)

Я не являюсь в настоящее время профессиональным программистом,

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

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

Потому что ты не способен прочитать мейкфайл, на который даёшь ссылку?

OBJ1 =  tar.o create.o extract.o buffer.o \
        getoldopt.o update.o gnu.o mangle.o
OBJ2 =  version.o list.o names.o diffarch.o \
        port.o wildmat.o getopt.o
OBJ3 =  getopt1.o regex.o getdate.o $(RTAPELIB)
OBJS =  $(OBJ1) $(OBJ2) $(OBJ3)
...
tar:    $(OBJS)
        $(CC) $(LDFLAGS) -o $@ $(OBJS) $(LIBS)

Специально для тебя там даже по-русски написано:

Обычной практикой при построении make-файлов является использование переменной с именем objects, OBJECTS, objs, OBJS, obj, или OBJ, которая содержит список всех объектных файлов программы. Мы могли бы определить подобную переменную с именем objects таким образом:

там тоже есть список исходников

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

Ты самым позорным образом привёл в доказательство "своей" (на самом-то деле чужой - но это уже детали) точки зрения прямой контр-аргумент, причём ровно из того букваря (с поправкой на перевод и протухшесть), на который я дал тебе ссылку.

Ты вообще ни в какое никогда им не являлся

Это правда, я учился на электронщика,а программирование у нас было так сказать обзорным курсом. Хотя это не помешало мне в 90е годы зарабатывать кодописательством сначала на десктопах,потом для микроконтроллеров в 00х.

там тоже есть список исходников

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

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

OBJ = $(SRC:.c=.o)

(хотя до того как я этот пример когда-то впервые увидел - был уверен что замена суффикса делается посредством patsubst)

если я протестирую это на многих пакетах и всё будет нормально работать, то можно даже отправить в апстрим Void, как вариант системы сборки. он не заменит месон для не C/C++ проектов, но для сборки C/C++ он работает на порядки быстрее, чем месон.

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

Makefile’ы можно писать очень по-разному

Так я-то это вижу,хотябы на примере вышеупомянутого файла для сборки проектов под AVR,которым достаточно регулярно пользуюсь и слегка допилил под свои надобности. Но вот ведь тут ругаются что это неправильный мэйкфайл. Я и пытался всего лишь добиться ответа на логичный вопрос «почему?». В ответ меня обвинили в непрофессионализме. Так я и не отрицаю что уже полтора десятка лет как программист-любитель (по аналогии с радиолюбителями:)

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

К сожалению может быть ситуация много хуже - соберут но неправильно. Вон там выше писали что изменение CFLAGS не отслеживается например.

В каком-то микроконтроллером проекте видел казус - там написали зависимость от … мэйкфайла. То есть если мэйкфайл изменился то пересобиралось всё. Учитывая что это МК и объем исходников по определению небольшой - решение не самое плохое. Например в частности потому что конкретная модель кристалла и тактовая частота задавались в мэйкфайле. Первое - нужно компилятору,второе - используется как передаваемый через командную строку компилятора дефайн для вычисления в исходниках всяких делителей,в таймерах например.

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

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

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

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

эээкхемм! я сделала ctrl-a ctrl-c в pdf'е, потом засунула это в редактор, ожидая увидеть тот же текст. но получила абсолютно нечитабельную смесь из отдельных кусков мейкфайла, который при таком незатейливом копировании порвало просто на британский флаг. мдя... я же говорила, что не надо мейкфайл пихать в pdf.

вспомнила, что когда-то собирала утильку pdftotext и она даже нашлась на машине. с флагом -raw она-таки пережевала pdf в (почти) нормальный текстовый файл. погляжу на досуге, что там «неправильно».