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

Для любителей есть станции попроще. Термопро, конечно, охота, но все-таки дороговато :)

Ну, их-то стоимость сравнима со стоимостью компа средней паршивости :) А термопро – это как топовая машина.

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

О, кстати, про

CFLAGS

и ccflags-y. Поясните, если не сложно, нафейхоа это все? Например, в драйвере nvidia-390xx перешли на этот ccflags-y.

CONFIG_FEATURE_X транслируется с помощью ccflags-$(CONFIG_FEATURE_X) в зависимости от выбора в ccflags-y или ccflags-n.

А дальше подробности и примеры смотрим в Linux Kernel Makefiles

--- 3.7 Compilation flags
		...
		ccflags-y			:= -Os -D_LINUX -DBUILDING_ACPICA
		ccflags-$(CONFIG_ACPI_DEBUG)	+= -DACPI_DEBUG_OUTPUT

При ccflags-n созданное значение будет дальше проигнорировано, а при ccflags-y добавлено к общему списку опций.

Спасибо.

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

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

А стихи надо в pdf и название в метаданные,потом по ним можно и индексатор какой-нибудь запустить,типа например линуксового https://www.recoll.org Файл с русскими буквами в имени не факт что получится разместить на какой-нибудь «флибусте» или еще каком литературном сайте. А уж с спецсимволами - точно не получится.

Файл с русскими буквами в имени не факт что получится разместить на какой-нибудь «флибусте» или еще каком литературном сайте. А уж с спецсимволами - точно не получится.

Опять же, есть utf-8 и экранирование. Все эти ограничения - искуственные и пережитки прошлого.
Если символы принятые международно (всё-таки связанные с математикой шрифты должны присутствовать, мы не в эпоху КОИ-8 живём), либо содержимое является спецефичным для языка (литература, народная культура) - то utf-8 имеет место быть.
Когда-то конечно приходилось важные файлы оставлять в латинице из-за ограничений DOS и старых FAT на случай, если востанавливать данные придётся в них. Сейчас ограничение на языки в файлах - скорее баг или особенность легаси.
Что же касается ЯП (который должен быть понятен всем) - как минимум ничего плохого нет если эти символы будут в комментариях.
Что касается же идентификаторов - то лучше этого избежать банально из-за сложности набора. Фактически это усложнит работу с кодом для большинства. Даже для пользователей emacs, которым придётся пользоваться вставкой символов. Не говоря уже о рандомном редакторе, в котором проще всего будет скопировать символ.

• Make не поддерживает пробелы в путях.
• Пишем рекомендации, чтобы не использовать пробелы в путях.
• Как следствие, почти никакой софт для разработки не тестируется на корректную работу с пробелами в путях.
• Пишем еще больше рекомендации, чтобы не использовать пробелы в путях.

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

Хотя если подумать, под это слово больше подходит то, что я описал в пунктах выше. =)

Традиции субъективны и имеют свойство меняться со временем. А баги в софте объективны: что-то либо работает, либо нет.

И помним: «640 килобайт хватит всем».

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

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

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

Согласен. Да, у идентификаторов проблем две:

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

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

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

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

(а еще там в репе батники для винды и скрипты на питоне - специально для некоторых, бгг)

Сейчас ограничение на языки в файлах - скорее баг или особенность легаси.

Или правила хорошего тона. Примерно как правило в присутствии иностранцев говорить на языке которые понятен всем присутствующим.

utf-8 имеет место быть.

С ним тоже не всё так просто. Дело в том,что некоторые символы вида «буква с крышкой» могут быть записаны как единый символ или как буква отдельно и крышка отдельно. И разные ОС имеют разное мнение о том как писать имена файлов. Например у мака и виндов мнения отличаются. В результате визуально идентичные имена файлов созданные в разных ОС окажутся на самом деле разными. Это не говоря о вообще наличии в юникоде большого числа визуально похожих символов,что может выйти боком не только в именах файлов но и в идентификаторах переменных в исходниках.

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

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

Что касается же идентификаторов - то лучше этого избежать банально из-за сложности набора.

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

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

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

Традиции субъективны и имеют свойство меняться со временем.

Сомневаюсь что в сколько-нибудь цивилизованном обществе в обозримом будущем исчезнет традиция вежливого и корректного поведения.

А баги в софте объективны: что-то либо работает, либо нет.

Хорошо, допустим софт протестировали на корректность обработки пробелов, дописали в него нужный код и он перестал на пробелах спотыкаться. А потом найдется тот,кто захочется вставить в имя файла символ новой строки чтобы именовать написанные лесенкой стихи. (Отдельный вопрос - почему их вообще надо было так записывать,но это к Маяковскому,а его уже не спросишь). Опять тестируем софт,опять дописываем. А потом найдется еще один оригинал который захочет вставить в имя файла эмодзи. Опять тестируем,опять дописываем. И так далее чуть ли не до бесконечности. В юникоде много чего есть экзотического - объединенные символы, символы смены направления ввода и так далее.Бесполезная работа делается,код пухнет, основная полезная функциональность софта ничуть не меняется. И всё ради таких вот оригиналов, желающих «самовыразиться».

«Оригинальность - уловка людей дурного тона» - приписывается Л.Толстому.

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

Хорошо бы - с примерами уже собранного и аргументами почему именно Ruby или Lua.

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

Как выше верно было замечено, на современном железе небольшой проект будет быстро собран даже простым build.sh. А большие сложные проекты всё равно весьма часто собираются не мейком,а чем-нибудь более хитрым. Так что использование make для сборки - это в значительной степени просто традиция.

И так далее чуть ли не до бесконечности.

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

На make некоторые вещие в плане работы с символами вообще сделать нельзя.

На sh возможно, но через специальные заклинания.

На tcl не нужны заклинания, там абсолютно предсказуемая и простая как палка схема парсинга данных.

И наконец мы переходим к языкам типа Ruby, JS или Lua, где работа со строками еще более универсальная и беспроблемная.

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

Это всё имеет значение только при выводе на экран или при правке текста. Ничем таким скрипты для сборки не занимаются. Там достаточно обычной побайтовой обработки.

В этом суть utf8, что он пригоден к обработке как массив байт.

с примерами

https://gittup.org/tup/ex_lua_examples.html

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

Исключения из этого правила существуют.

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

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

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

Это всё имеет значение только при выводе на экран или при правке текста. Ничем таким скрипты для сборки не занимаются.

Проблема визуальной идентичности разных символов всё равно остается. Будете недоумевать почему не компилируется какой-нибудь файл хотя вы его вписали в сборочный скрипт. А окажется что в имени файла буквы с другими кодами. Тоже самое с public символами в объектном файле - линкер выдает unresolved хотя вы нужный символ видите глазами. А он на самом деле не такой,только отличия глазами не видно пока не попытаетесь рассмотреть его как массив байтов.

Я намеренно упомянул содержимое связанное с культурой носителей языка (под культурой разумеется так же подразумеваются какие-либо арты, литература и т.д. То есть содержимое, адресованное носителям языка. В комментариях же только международно принятые символы (лямбда и дельта тут как раз меример того, что может быть в комментариях, но нежелательно в идентификаторах)

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

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

Проблема визуальной идентичности разных символов всё равно остается. Будете недоумевать почему не компилируется какой-нибудь файл хотя вы его вписали в сборочный скрипт. А окажется что в имени файла буквы с другими кодами.

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

И помним: «640 килобайт хватит всем».

И ведь хватало в течении полутора десятков лет.

А в линуксе ограничение на длину имени файла 255 байтов.

А в Си длина идентификатора 31 байт.

И тоже никто не возмущается.

И ведь хватало в течении полутора десятков лет.

Каких полутора десятков лет? В ту эпоху каждый год платформы устаревали.

Это сейчас халява - можно 10 лет сидеть на 16 гигах и не испытывать необходимости апгрейда.

А в линуксе ограничение на длину имени файла 255 байтов.

Время от времени налетаю на это ограничение. Мешает.

А в Си длина идентификатора 31 байт.

vadim@aquila:/tmp/1$ cat 1.c 
int main()
{
    int a0123456789012345678901234567890123456789 = 42;
    return a0123456789012345678901234567890123456789;
}
vadim@aquila:/tmp/1$ gcc 1.c && ./a.out 
Status: 42
vadim@aquila:/tmp/1$ 

И тоже никто не возмущается.

Никто - это кто конкретно?

Хорошо бы - с примерами уже собранного и аргументами почему именно Ruby или Lua.

Да тут примеры особо и не нужны. Захардкоженный символ TAB уже является отборной шизой. Смешнее было только у QMake где захардкодили 1TBS стиль расставления фигурных скобок и при форматировании их в Allman стиль скрипт сборки .pro ломается с неочевидными ошибками.

Наличие 10-видов нелогичных какерских закорючек $@, $?, $^, $< значения которых постоянно забываются и костыли в виде .PHONY тоже слабо располагают к продуманности и удобности инструмента. Встроенными функциями пользоваться неудобно, ветвления тоже адовые. А вот тема с +=, !=, ?= у make довольно интересная и вполне логичная. На том же CMake подобная логика требует такой убогой анальщины, что Makefile потом вспоминается добрым словом.

почему именно … Lua.

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

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

кто-то по глупости закоммиттил файл с русской с вместо c.

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

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

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

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

Литературные произведения обычно сохраняются в форматах, где предусмотрено наличие метаданных (fb2,pdf,epub) - и русскоязычному юникоду место именно там. А в названии - в крайнем случае транслит. Посмотрите как это например на Флибусте сделано. И файлы оттуда без проблем загружаются на планшеты,телефоны, и всякие прочие электронные книгочиталки,порой весьма экзотические.

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

Что за ретроградское мышление?

Баги и недоделки в софте надо править, а не подстраивать под них людей. Что для чего предназначено: инструменты для человека или человек для инструментов?

А давайте еще зафиксируем отсчёт лет навечно в 20-х годах, а то в 2038-м что-нибудь поломается.

А в названии - в крайнем случае транслит.

К чему полумеры, давайте рутубовские индентификаторы видео использовать как имена файлов! efbddc56a5b2d403bfb0bec1327ebe0f!

Мы для чего технологии развиваем вообще?

Жесть, конечно. Там в реальности ИИ уже умеют решать многоступенчатые задачи с корректировкой собственных ошибок в процессе, пока на ЛОРе продолжают с неймингом файлов воевать.

Каких полутора десятков лет?

MS DOS вышел в начале 80х и активно использовался до середины 90х.

Время от времени налетаю на это ограничение. Мешает.

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

А в Си длина идентификатора 31 байт.

Это по стандарту ANSI так. Какие ограничения в конкретных версиях компиляторов - надо в документации искать. Причем ограничение для внешних (public) символов определяет еще и линкером и форматом объектных файлов. Как правило оно меньше чем для символов внутри функций.

И тоже никто не возмущается.

Никто - это кто конкретно?

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

Что за ретроградское мышление?

Не ретроградское,а традиционалистское. Традиции и правила хорошего тона - это чаще хорошо чем плохо.

Что для чего предназначено: инструменты для человека или человек для инструментов?

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

К чему полумеры, давайте рутубовские индентификаторы видео использовать как имена файлов! efbddc56a5b2d403bfb0bec1327ebe0f!

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

Кстати, сталкивался с тем,что при переписывании даже файлов с латинскими именами с линукса (ext4) на флэшку (fat32) попадались файлы которые на fat32 затирали друг друга,хотя в линуксе их имена воспринимались как разные. Было это при переносе большой кучи скачанных из интернета mp3-файлов с достаточно «развесистыми» именами. Причем линуксовая утилита для «кондиционирования» имен файлов ( https://github.com/dharple/detox ) эти потенциально проблемные имена не отлавливала.

Мне что-то не получилось подружить -MD с вилдкардом и subst. android ndk тоже использовал sed или awk для автоподмены путей в .d файлах.

А я вот с теплотой вспоминаю старую сборочную систему проектов Android NDK на Makefile Engine. Похожая используется у libopencm3 и DevKitArm (GBA, DS). Просто. Логично. Понятно. Удобно.

Подобные системы «Makefile’ов на стероидах» позволяют гибко управлять различными аппаратными особенностями платформ. К примеру, в Android NDK было сделано так, что при наличии в имени файла ARM-постфикса source.c.arm он компилируется с -marm вместо -mthumb, аналогично Makefile Engines для GBA файлы с постфиксом source.c.iwram помещали скомпилированный код внутрь быстрой IWRAM вместо RAM, а source.c.arm7 давал возможность запуска кода на втором ARM7-сопроцессоре вместо основного камня.

С переходом Android NDK на CMake эта гибкость и логичность Makefile Engines улетучилась, а проекты начали использовать вот такие вот убогие костыли из-за ограниченности CMake перед классическими Makefile.

Стало:

https://github.com/libsdl-org/SDL/blob/d7939abf42de34fff409f5e7c4b77ace79dff4de/CMakeLists.txt#L1322-L1333

Было:

https://github.com/libsdl-org/SDL/blob/d7939abf42de34fff409f5e7c4b77ace79dff4de/Android.mk#L25-L26

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

Ну у тебя то же самое в итоге.

$(OBJECTS) : $(OBJ_DIR)/%.o: $(SRC_DIR)/%.c | $(OBJ_DIR)
	$(COMPILE)

...

$(DEBUGOBJ) : $(DBG_DIR)/%.o: $(SRC_DIR)/%.c | $(DBG_DIR)
	$(COMPILE)

В общем случае конфигураций может быть произвольное количество. К примеру у меня сейчас 2 * 3 конфигураций. Файлы бывают не только .c, ещё, например, .S. И получится длинная однотипная простыня.

мы же все равно ничего им не собираем, да?

Почему же? Собираем.

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

Da vy i translitom pisat’ mojete, a to vdrug u kogo net kyrillicy ili yego soft tol’ko latinicy podderjivaet.

А стихи надо в pdf

А pdf нужно как-то называть. Таким образом задача сведена к предыдущей.

Файл с русскими буквами в имени не факт что получится разместить

Ну, раньше и правда была проблема с тем, что все программы американские, а американцы часто забывают о существовании мира вне США и что бывают другие языки кроме американского. Но это самое раньше — это 70-е – 80-е года прошлого века. Окститесь. С тех пор пол века уже прошло.

А если не получается, можно обратиться к психологу (это не стыдно!) и проработать фидошные травмы от ненастроенной буквы «Н».

А уж с спецсимволами - точно не получится.

1 Блаже́н муж, и́же не и́де на сове́т нечести́вых и на пути́ гре́шных не ста, и на седа́лищи губи́телей не се́де, 
2 но в зако́не Госпо́дни во́ля eго́, и в зако́не Его́ поучи́тся день и нощь. 
3 И бу́дет я́ко дре́во насажде́нное при исхо́дищих вод, е́же плод свой даст во вре́мя свое́, и лист eго́ не отпаде́т, и вся, ели́ка а́ще твори́т, успе́ет. 
4 Не та́ко нечести́вии, не та́ко, но я́ко прах, eго́же возмета́ет ветр от лица́ земли́. 
5 Сего́ ра́ди не воскре́снут нечести́вии на суд, ниже́ гре́шницы в сове́т пра́ведных. 
6 Я́ко весть Госпо́дь путь пра́ведных, и путь нечести́вых поги́бнет.

Главная проблема ИТ — пользователи фекалофаги, из-за которых у разработчиков отсутствует мотивация делать хорошо и правильно. Не надо пользоваться программами, которые не умеют работать с корректными файловыми именами. Завести issue в bugtracker и отойти, пока не поправят.

банально из-за сложности набора.

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

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

А можно пример? Вы меня заинтересовали, это что это такое может быть (спецпрограммы для железячников-электронщиков?), что в 2025-м году (спустя 37 лет от появления юникода) не умет отображать нелатинские символы?

Опять тестируем,опять дописываем.

Как сказал Ленин: «Было бы ошибкой думать». Вот и не надо думать, предполагать как бы пользователь мог называть файлы, какие символы иметь в виду и что бы это значило. Имя файла — нуль-терминированная строка не больше N байт. Нужно взять стандартную (в вашем языке) библиотеку для работы с юникодом и обрабатывать файловые имена как есть.

А в названии - в крайнем случае транслит

Домашнее задание. Перечислить все способы каким пользователи могут назвать файл с книгой Достоевского: «Бесы».

Ну у тебя то же самое в итоге.

Эм, нет.

Т.е. дублируем правила для каждой конфигурации.

Нет, дублируется дерево целей, правила вынесены в переменные отдельно:

COMPILE = $(CC) -o $@ -c $< $(CFLAGS)
LINK = $(CC) -o $@ $^ $(LDFLAGS)

Особого смысла в этом нет, но ты просил именно это.

В общем случае конфигураций может быть произвольное количество.

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

Накостылить-то, конечно, можно, но тогда придётся грести против течения и обходить встроенную логику makeа - надо запрещать in-source build, форсить сборку из отдельной директории и придётся ручками настраивать каждую:

SRC_DIR := ./src

CC := gcc

CFLAGS :=
CFLAGS += -p
CFLAGS += -std=gnu99
CFLAGS += -Wall
CFLAGS += -Wformat=2
CFLAGS += -Wextra
CFLAGS += -Werror

LDFLAGS :=

COMPILE = $(CC) -o $@ -c $< $(CFLAGS)
LINK = $(CC) -o $@ $^ $(LDFLAGS)

PWD := $(dir $(realpath $(lastword $(MAKEFILE_LIST))))
ifeq ($(PWD),$(CURDIR)/)
$(error 'In source tree build is not supported. Run out ouf source tree')
endif

VPATH := $(PWD)

EXTRAFLAGS != cat cflags.txt

.SUFFIXES:
.ONESHELL:

.PHONY : all
all: 

OBJECTS :=
OBJECTS +=  main.o
OBJECTS +=  test.o

$(OBJECTS) : cflags.txt
$(OBJECTS) : %.o: $(SRC_DIR)/%.c
	$(COMPILE)

program : CFLAGS += $(EXTRAFLAGS)
program : $(OBJECTS)
	$(LINK)


all: program

.PHONY : clean
clean:
	rm -f program
	rm -f $(OBJECTS)

$ make
GNUmakefile:30: *** 'In source tree build is not supported. Run out ouf source tree'.  Stop.
$ mkdir debug
$ cd debug/
debug$ cat > cflags.txt
-ggdb -O0
debug$ make -f ../GNUmakefile 
gcc -o main.o -c /tmp/make/src/main.c -p -std=gnu99 -Wall -Wformat=2 -Wextra -Werror -ggdb -O0
gcc -o test.o -c /tmp/make/src/test.c -p -std=gnu99 -Wall -Wformat=2 -Wextra -Werror -ggdb -O0
gcc -o program main.o test.o 
debug$ cd ..
$ mkdir release
$ cd release/
release$ cat > cflags.txt
-O2
release$ make -f ../GNUmakefile 
gcc -o main.o -c /tmp/make/src/main.c -p -std=gnu99 -Wall -Wformat=2 -Wextra -Werror -O2
gcc -o test.o -c /tmp/make/src/test.c -p -std=gnu99 -Wall -Wformat=2 -Wextra -Werror -O2
gcc -o program main.o test.o 
release$ echo -n '-Wno-unused-parameter' >> cflags.txt
release$ make -f ../GNUmakefile 
gcc -o main.o -c /tmp/make/src/main.c -p -std=gnu99 -Wall -Wformat=2 -Wextra -Werror -O2 -Wno-unused-parameter
gcc -o test.o -c /tmp/make/src/test.c -p -std=gnu99 -Wall -Wformat=2 -Wextra -Werror -O2 -Wno-unused-parameter
gcc -o program main.o test.o 
release$

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

Вобщем - Флибуста названия файлов транслитом давно и успешно использует, жалоб у них на форуме не видно.

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

строка не больше N байт

Но ведь это тоже ограничение! Почему N,а не M? Ужас-ужас! Срочно его убрать и позволить юзерам пихать в имя файла весь текст «войны и мира».

Вроде как для транслита есть какой-то однозначный стандарт

Есть. И не один причём.

файлы с символами эмодзи в именах.

Отчего нет? Корректно написанная программа должна это поддерживать. Причём автоматически.

Но ведь это тоже ограничение!

Вы не понимаете, это другое. Тут ограничение в файловой системе. А предыдущие — в вашей голове.

И не один причём.

Я про тот что сейчас является актуальным и используется в частности в загранпаспортах,ну и в прочих случаях когда русские имена-фамилии надо транслитерировать в официальных документах. Раньше (90е) был другой,на основе французской транслитерации. Там много лишних букв добавлялось и никто кроме французов правильно прочитать не мог(не говоря про написать).

файлы с символами эмодзи в именах.

Отчего нет? Корректно написанная программа должна это поддерживать.

Вопрос не в том как это будет поддерживать программа,а в том как с этим будут работать ЛЮДИ к которым такие файлы попадут. И какими словами они будут поминать приславшего.

Тут ограничение в файловой системе.

Кто посмел ограничить вашу свободу самовыражения в именах файлов? Срочно отменить! 640кб - это тоже ограничение,в подсистеме памяти.

А предыдущие — в вашей голове.

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

как с этим будут работать ЛЮДИ к которым такие файлы попадут

И какое же это отношения к программе? Здесь у меня больше вопросов к тем, кто это в хрюникод протащил...

И какое же это отношения к программе?

Это имеет отношения к общей технической культуре. Ну типа как шурупы молотком не забивать,хотя это и быстрее чем их закручивать. Или если угодно можно провести аналогию с техникой безопасности - зачем на станках разные щитки,ограждения,блокировки - они же «свободу ограничивают» и мешаются. Вот также и в софте хорошо бы иметь средства техники безопасности против неадекватных действий пользователя,внезапно возжелавшего сделать что-нибудь слишком странное и потенциально способное привести к глюкам. А то мы повторяем что под рутом сидеть нельзя и опасаемся rm -rf / хотя это уже сто лет как не сработает(защиту в rm добавили). А создать файл с стрёмными символами - типа нормально. Хотя много где защиты от последствий этого нет,в том числе (и в первую очередь) во всяком проприетарном закрытом софте,который изготовитель править не будет потому что деньги уже получил,а пользователь не может потому что нет исходиков. Зимой пришлось подключать диагностический софт к двигателю Honda на аэролодке. Мотор достаточно старой разработки,софт тоже. Из путя с пробелом (Program files) не запускается, логи в пусть с пробелами не пишет. Да и вообще посмотрите форумы автодиагностов - они там регулярно обсуждают какой правильный «устаревший» ноут взять и как на него тот или иной специфический софт поставить чтобы работал. Часто не работает на «русских» версиях виндов.

Да, можно выпендриться и назвать файл как-нибудь необычно. Типа вон как строчку стихов с переносом строки предлагали в имя файла с этими стихами засунуть. Но будут ли люди за благодарны за подобный креатив? Я всё-таки думаю что нет. Тем более что файлы нередко переносятся на флэшках,а там традиционно fat32,и куда более жесткие ограничения чем в линуксе. Я уже упоминал про два mp3 файла которые в линуксе на ext4 разные,а на флэшке один другого перезаписывают. Надо бы победить лень и их найти в архивах и сюда в качестве примера имена вставить…

Здесь у меня больше вопросов к тем, кто это в хрюникод протащил…

И это тоже:( Если оно где-нибудь в вебе на страницах сайтов - то и не мешает никому. Ну не отображается какое-нибудь эмодзи или выглядит не так - и хрен с ним,это лишь украшательство. А вот если «выглядит не так» будет в имени файла или в имени переменной в исходнике - это уже создаст проблему. Относится к любым символам,не только эмодзи. И про проблемы «буква с крышкой» против «буква отдельно,крышка отдельно» я тоже уже упоминал. Русские Ёё и Йй под это попадают - привет любителям «ёфицирования».

rm -rf / хотя это уже сто лет как не сработает(защиту в rm добавили)

Что за бред? Всё отлично работает. Просто запускать надо от рута. И команда не так выглядела, а вот так: rm -rf /*

Что за бред?

Ну я же не из головы это придумал,а прочитал когда-то в новостях что в rm добавили защиту. Возможно что не везде. Сам не проверял конечно. В мане который в комплекте Дебиана 11 есть два вот таких ключика:

--no-preserve-root
    do not treat '/' specially

--preserve-root[=all]
    do not remove '/' (default); with 'all', reject any command 
    line argument on a separate device from its parent

Ты зря так уверенно ссылаешься на защиту rm и --preserve-root, потому что ты попросту обсуждаешь не классическую команду на удаление всех файлов корня, а вариант с удалением корня как каталога. Я же написал, что её надо выполнять со звёздочкой. Объяснять почему нужна звёздочка? Классический патч Бармина пишется именно со звёздочкой в конце. Именно так он и работает. Упоминание о нём в таком виде есть в различных Вики. И она выполняется без каких-либо предупреждений и без необходимости снимать защиту — если ты root, начнётся полное удаление всех файлов в корне, кроме тех, что недоступны по правам или смонтированы как read-only. И от того, что сам / просто как папку не удалишь (а а всё содержимое внутри него — пожалуйста), легче не будет. Никакой реальной защитой это не является. Так что приводить это в качестве аргумента к тому, что «не стоит бояться» — просто нелепо.

обсуждают какой правильный «устаревший» ноут взять и как на него тот или иной специфический софт поставить чтобы работал

Вот из-за таких мнений, как у тебя такое и происходит.

Я уже упоминал про два mp3 файла которые в линуксе на ext4 разные,а на флэшке один другого перезаписывают. Надо бы победить лень и их найти в архивах и сюда в качестве примера имена вставить…

На 95% уверен, что это разный регистр, а юникотики тут не причём, как и национальные символы

Если оно где-нибудь в вебе на страницах сайтов - то и не мешает никому

Можно было и каким-то тегом сделать. Зачем оно в юникоде всё-таки неясно

буква отдельно,крышка отдельно

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

Я про тот что сейчас является актуальным

Вот, можете ознакомиться со списком актуальных стандартов: https://www.translit.site/ru/type/passport. Актуальным для русского языка является русский алфавит. Насчёт транслитерации в гос. организациях ещё может и есть какое-то единообразие, хотя не уверен, а вот уж частные лица будут транслитерировать как Бог на душу положит. Уже хотя бы потому, что стандарт для загранов, мягко выражаясь, нехорош. Например, имя «Виктория» он велит записывать как «Viktoriia».

как с этим будут работать ЛЮДИ к которым такие файлы попадут.

Так же, как и с любыми другими файлами.

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

Так они удобные, если пользоваться повсеместно распространёнными современными программами. И это вы своими нелепыми ограничениями пытаетесь причинить неудобства другим людям. Стыдно!

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