Существует специфический «эффект Makefile», напоминающий такие феномены как карго-культы, нормализация отклонений, «нечитабельный язык» и т.д. В этой статье я берусь утверждать, что Makefile — явление того же порядка, с той оговоркой, что он немного отличается от вышеперечисленных феноменов. Makefile не является по сути своей неэффективным или плохим и сказывается на результатах проектирования лишь в некоторых ситуациях.
Не могу подобрать идеального названия для этого явления, так что буду называть его просто «эффект Makefile». Эффект Makefile не назовёшь однозначно порочным — просто нужно иметь его в виду при проектировании инструментов и систем.
Суть эффекта Makefile сводится к следующему:
Если некоторый инструмент достигает определённого уровня сложности, или работа с ним строится слишком непривычно, то этот инструмент не запускают с чистого листа, а копируют и вставляют по образцу уже имеющихся готовых и хорошо зарекомендовавших себя конфигураций, после чего слегка адаптируют под новую ситуацию.
На это падки технари всех мастей, независимо от их навыков и уровня профессионализма, и в качестве наиболее красноречивого примера такого рода можно привести работу с Make:
Требуется выполнить (понятную в общих чертах) задачу. Ранее вы уже решали очень похожую или даже идентичную задачу.
Make (или другой инструмент, которому присущ такой эффект) считается верным или «наилучшим» из себе подобных (учитывая практическую целесообразность, зависимости пути, пр.) для решения данной задачи.
Инженер не пишет новый Makefile, а копирует более ранний (зачастую очень большой и переусложнённый) Makefile из ранее решённой задачи, после чего адаптирует этот материал до тех пор, пока он не станет работать в новом контексте. Мне доводилось слышать, как некоторые технари получали Makefile «в наследство» т.e., эти Makefile они брали у своих начальников, преподавателей и т.д. В результате складывается так, что и эти «предковые» Makefile также с незапамятных времён передавались из поколения в поколение с косметическими изменениями.
Make — просто пример, а не универсалия. Складываются разные профессиональные группы, члены которых осваивают разные инструменты. Есть и более обширное наблюдение: существуют целые классы инструментов/систем, (более) подверженных этому эффекту и (относительно) менее подверженные.
При некотором приближении это просто отличный (даже идеальный) инженерный механизм реагирования с точки зрения проектирования: зачастую наиболее рационально применить известный рабочий вариант. (Теоретически) так мы снижаем риск привнести в код баги, поскольку большая часть сделанного остаётся без изменений.
Но именно с точки зрения проектирования это выдаёт ущербность инструмента. Она может заключаться в том, как инструмент устроен или как применяется, но суть такова: инструмент (система) слишком сложны или раздражают, чтобы использовать их с нуля. Пользователь избегает применять инструмент с каждой задачей заново, а раз за разом копирует известное хорошее решение, в котором со временем накапливаются изменения.
Как только вы заметите этот эффект, вы также убедитесь, что он встречается повсюду. Кроме Make:
Конфигурации CI/CD (непрерывной интеграции и доставки) в таких инструментах как GitHub Actions и GitLab CI/CD, где пользователь копирует лохматую YAML-разметку из последней работавшей конфигурации и доводит её до ума, пока она снова не заработает (зачастую её для этого требуется не раз перезапустить);
Конфигурации линтеров и инструментов форматирования, где из проекта в проект копируется базовый набор правил, которые затем ужесточаются или смягчаются в зависимости от конкретных условий;
Сборочные системы как таковые, которые во всех нетривиальных деталях начинают напоминать предковую сборочную систему.
Важно ли это?
Зачастую, пожалуй, нет. Но я думаю, что об этой проблеме стоит задумываться, в особенности при проектировании инструментов и систем:
Инструменты и системы, в которых проявляется такой паттерн, часто оставляют желать лучшего в области поддержки при диагностике или отладке. Пользователю приходится раз за разом гонять инструмент (то и дело с длительными задержками), по крупицам выуживая информацию. Представьте себе конфигурации CI/CD, где всё скопировано и вставлено, и отладку такого конвейера приходится делать «в стиле дампа». При этом работа идёт по сети через промежуточный уровень, опосредующий оркестрацию VM. Смешно же!
Инструменты, в которых проявляется такой паттерн, зачастую не располагают к ознакомлению с собой: найдутся считанные спецы, которые настолько хорошо разбираются в инструменте, что способны его сконфигурировать. Все остальные будут просто копировать, а их знаний хватит ровно на то, чтобы точечно поменять настройки. Иногда это неизбежно, но не всегда. Графы зависимостей по определению сложны, как и описываемые ими сборочные системы. Но что стоит выучить разницу между $< и $^ в Make?
Инструменты, в которых проявляется такой паттерн не располагают к безопасному использованию: для обеспечения безопасности обычно требуется глубоко понимать, почему некоторое поведение устроено так, а не иначе. В системах, подверженных эффекту Makefile, также зачастую наблюдается спутанность между кодом и данными (или, в более общем случае, любая передача сигналов внутри полосы ), в основном потому, что рабочие решения не всегда безопасны. Вспомните, например, об инъекции шаблона в GitHub Actions.
В целом, я думаю, что в хорошо спроектированных инструментах (и системах) такой эффект должен минимизироваться. Наверное, это сложно обеспечить всегда, но вот о чём я задумываюсь при проектировании нового инструмента:
Должен ли он быть конфигурируемым?
-
Нужен ли ему собственный синтаксис?
Отсюда следует: может ли он заимствовать знакомый синтаксис или идиомы из других инструментов или CLI?
Распространяется ли мой подход к работе с этим инструментом через копипаст? Если да, то насколько вероятно, что другие захотят повторить за мной?
Сложные инструменты — это необходимость и, можно даже сказать, неизбежность. Но, если эффект Makefile проявляется в простом приложении, это подсказывает, что данный инструмент переусложнён для решаемой им задачи.
Комментарии (212)
JBFW
12.01.2025 06:50Ну вот, командную строку уже ниасилили теперь для простых задач требуется Гуй.
Теперь ниасилили Makefile - нужен новый инструмент (наверное, снова Гуй в виде ide)
А есть ещё языки программирования: там сложнааа... )
(не, идея вроде бы: не стоит тупо копировать то чего не понимаешь, но читается оно именно так: сложнааа, очень сложнааа)
rukhi7
12.01.2025 06:50Ну вот, командную строку уже ниасилили теперь для простых задач требуется Гуй.
вроде как логичным продолжением после того как не осилили командную строку являются перфокарты. Похоже настало время вспоминать что это такое.
mayorovp
12.01.2025 06:50Проблема не столько в том, что условный Makefile "ниасилили", сколько в том, что всех задолбало "осиливать" его каждый раз когда тот понадобится.
checkpoint
12.01.2025 06:50Всех это кого именно ? Или Вы о себе во множественном числе ?
В моём окружении у разработчиков проблем с Makefile-ами нет, а если и бывают - я помогу их быстро решить. В более-менее серьезных командах (даже очень небольших) всегда должен быть человек специализирующийся на интсрументарии, который знает все поднаготные Make, CMake, shell-а, компиляторов, интерпретаторов и используемых библиотек. Если Вы одни в поле воин, ну тогда нечего плакаться - судьба у Вас такая. Изучайте в том числе Make, и
GoogleChatGPT в помощь.PS: Если понимать общую концепцию, то у Makefile-а синтаксис тривиальный. Проблему могут создавать встроенные функциях коих достаточно много и запомнить их параметры сложно. Но для этого есть референсный мануал.
PPS: Автор оригинальной статьи скорее всего даже не догадывается, что есть BSD Make и GNU Make и синтаксис у них несколько отличается. ;)
mayorovp
12.01.2025 06:50Проблемы не в синтаксисе. Проблемы в том, что для достижения нормальной сборки начинать разрабатывать новый Makefile приходится аж со сбора требований и с архитектуры. Инструмент, который должен был помогать собирать проект, становится отдельным проектом.
checkpoint
12.01.2025 06:50Инструмент, который должен был помогать собирать проект, становится отдельным проектом.
Но это такой очень маленький проект "выходного дня". Даже для самых сложных задач. А для тех, кто не осилил всегда есть CMake или autogen/automake.
mayorovp
12.01.2025 06:50То есть я ещё и выходные должен тратить на это? Ради чего? Просто ради того, чтобы меня не называли "не осилившим"?
Как по мне, так это и есть показатель, что кто-то не осилил сделать нормальную систему сборки. А я лучше воспользуюсь плодами трудов тех, кто таки осилил.
JBFW
12.01.2025 06:50Makefile не для вас, он для make
Удобен он лишь тем что потом достаточно написать "make" и оно всё магическим образом соберется, без скачивания и установки XXXProject v.12.7 в которой создавали и без которой "файл проекта" теперь не открыть.А написать его можно с помощью ЧатаГПТ, обьяснив на пальцах "чо надо".
Есть некоторое количество файлов написанных на С. Требуется написать такой Makefile, с помощью которого можно скомпилировать программу, с использованием кросс-компилятора для архитектуры ARM64 под Linux, подключив дополнительно библиотеку blamblamblam, расположенную на диске в каталоге /usr/lib/gdetotam/
# Имя выходного файла TARGET = program # Кросс-компилятор для ARM64 CC = aarch64-linux-gnu-gcc # Флаги компиляции CFLAGS = -Wall -O2 # Флаги линковки LDFLAGS = -L/usr/lib/gdetotam -lblamblamblam # Путь к заголовочным файлам INCLUDES = -I/usr/lib/gdetotam/include # Файлы исходного кода SRC = $(wildcard *.c) # Файлы объектных файлов OBJ = $(SRC:.c=.o) # Правило по умолчанию all: $(TARGET) # Сборка программы $(TARGET): $(OBJ) $(CC) $(OBJ) -o $@ $(LDFLAGS) # Компиляция исходных файлов в объектные %.o: %.c $(CC) $(CFLAGS) $(INCLUDES) -c $< -o $@ # Очистка временных файлов clean: rm -f $(OBJ) $(TARGET)checkpoint
12.01.2025 06:50А этот ваш ChatGPT различает табуляцию и пробел ?
PS: Красивый Makefile. Совершенно не понятно что в нём может быть непонятного.
randomsimplenumber
12.01.2025 06:50Красивый Makefile
IRL всё значительно хуже.
Совершенно не понятно что в нём может быть непонятного
Точно как С, что там может быть непонятно, простой язык же ;)
Ну, можно занырнуть в Linux kernel, или исходники андроида, там будет много строк на make, ещё больше на С, и рассказать как там все просто и понятно ;)
checkpoint
12.01.2025 06:50Ну, можно занырнуть в Linux kernel, или исходники андроида, там будет много строк на make,
Комплект Makefile-ов для сборки ядра Linux, за исключением самого первого, генерируется утилитой script/kbuild из отдельных текстовичков Kconfig с описанием опций конкретного драйвера/модуля. Эти сгенерированные Makefile-ы не предназначены для обслуживания человеком. Главный Makefile вполне читаем и там комментариев описывающих логику сборки больше чем кода.
ещё больше на С, и рассказать как там все просто и понятно ;)
Си действительно очень простой и понятный язык программирования, а чтение исходников ядра Linux я рекомендую изучающим Си для ознакомления с тем как надо писать код и как его оформлять. Также рекомендую потренироваться в написании драйверов для Linux - это не сложно.
mayorovp
12.01.2025 06:50Удобен он лишь тем что потом достаточно написать "make" и оно всё магическим образом соберется, без скачивания и установки XXXProject v.12.7 в которой создавали
Как будто сам make не надо скачивать и ставить. И ещё про компилятор надо не забыть.
А написать его можно с помощью ЧатаГПТ, обьяснив на пальцах "чо надо".
Так ведь именно про это статья - что предпочтительным способом написания файла является получение готового от кого-то другого.
Если вы с этим согласны, то с чем вы вообще спорите?
mayorovp
12.01.2025 06:50О, вы тут пример Makefile добавили. Покритикую-ка я его.
Почему у вас недописана инкрементальная сборка? Где указание от каких заголовочных файлов какие объектные зависят?
Лучше уж вообще без инкрементальной сборки, чем с необходимостью вручную делать clean после каждого изменения заголовочных файлов.
nixtonixto
12.01.2025 06:50А написать его можно с помощью ЧатаГПТ, обьяснив на пальцах "чо надо"
Вот только сам ChatGPT не пишет код, а компилирует его из образцов кода, на которых его обучали. А это - "эффект makefile" во всей красе.
Uporoty
12.01.2025 06:50Теперь ниасилили Makefile - нужен новый инструмент
Makefile действительно переусложнен и, скажем так, специфичен. Его ниасилили еще когда он только появился, и именно поэтому уже четыре десятка лет мало кто в здравом уме пишет мейкфайлы ручками - их обычно генерируют генераторами из чего-то более понятного и удобного типа CMake, Meson, QMake, Gyp, или, прости господи, Autotools и т.д.
Точно так же как никто в здравом уме без какой-то серьезной надобности не пишет весь софт целиком на ассемблере сразу в машинных инструкциях, а используют для этого более высокоуровневые языки, которые транслируются в машинные инструкции.
Нет, конечно, всегда есть деды, которые в свое время всрали сотни часов в изучение какого-нибудь инструмента типа того же Makefile до мелочей, а потом смотрят как на говно на всех, кто не хочет в этом копаться, а вместо этого предпочитает тратить свое время более эффективно и с большей пользой - но таким людям обычно кроме знания этого инструмента и гордиться-то нечем, поэтому нет и смысла слушать их бурчание.
Keeper11
12.01.2025 06:50мало кто в здравом уме пишет мейкфайлы ручками
А я писáл.
checkpoint
12.01.2025 06:50Боюсь признаться, но я пишу по сей день. Для всех своих проектов. Хотя конечно "эффект Makefile-а" меня не обошел. ;)
aabzel
12.01.2025 06:50Нечего тут бояться признаваться. Лучше make все равно ничего не придумали.
mayorovp
12.01.2025 06:50А как же msbuild?
aabzel
12.01.2025 06:50Предлагаю сравнить все системы сборки в этом реестре
https://docs.google.com/spreadsheets/d/1sS_DRmcFsuV8FMstx81pxCvWkNQDU8Z-N1TuSI39m_c/edit?gid=0#gid=0Пусть каждый впишет строчку про свою любимую систему сборки.
Kahelman
12.01.2025 06:50Я пишу. Практически для всех своих проектов. На разных языках использую make для сборки. Более того когда надо что-то боле. Неё нетривиальное сделать с скриптами - оформляю их в makefile. По крайней мере когда я вижу в проекте makefile я знаю как его скомпилировать и могу легко посмотреть что с ним делать. Сей час расплодили для каждого фреймворка свою систему сборки - полный треш. Больше время уходит на ее изучение чем на саму работу
aabzel
12.01.2025 06:50мало кто в здравом уме пишет мейкфайлы ручками -
я пишу make скрипты руками. Вообще без проблем.
Uporoty
12.01.2025 06:50Я кажется помню ту ветку комментариев, где выяснилось, что вы пишите мейкфайлы ручками потому что ниасилили прочитать документацию CMake и сделали вывод что он неработоспособный :-D что-то там с проверкой на истинность условия было, что было описано в документации, но вместо этого вы сделали так, как вам казалось что оно должно работать, а потом ругались, что оно не работает так как вам надо :)
опять же - насколько я помню, вы под эмбеддед пишете. там структура проекта настолько примитивная в большинстве случаев, что там пойдет и мейк, и даже баш-портянка без особых проблем. но это довольно специфичный случай в целом.
aabzel
12.01.2025 06:50CMake или GNU Make?
СMake (Сross-platform Make) был разработан для кросс-платформенности. Переводя на кухонный язык, это чтобы одну и ту же программу можно было собирать в разнообразных операционных системах Windows, Linux, MacOS, FreeBSD. Если же Вы все в своей организации работаете только в Windows 10, то вам CMake нужен как собаке бензобак. Да.. Именно так.. Вам много проще будет самим писать GNU Make скрипты, раз нужна только сборка по клику на *.bat файл.
Потом, если вы до этого никогда не писали никаких скриптов сборки, то сразу кидаться писать CMake пожалуй тоже нет резона. Дело в том, что CMake это даже не система сборки, а надстройка над всеми возможными системами сборки: Ninja, Make и проч. Как AutoTools. СMake, в зависимости от опций командной строки, сам генерирует скрипты сборки. СMake - это всего лишь кодогенератор. И вам будет с непривычки будет архи сложно разобраться с огромным калейдоскопом разнообразных и новых для себя расширений файлов: *.сmake, СMakeList.txt. *.c.in *.mk и прочие. CMake очень навороченная и переизбыточная система.
Если у вас цель просто собирать код дергая скрипы в Jenkins, то лучше сосредоточиться на GNU Make. Тогда у вас в репозитории фактически будут только три типа файлов для версионного контроля: *.c *.h и *.mk файлы. Easy!
СMake же - это очень навороченная утилита и там много избыточного функционала. Много того, что вам никогда даже не пригодится. В случае выбора CMake вам, например, придется помимо ошибок компилятора чинить ещё ошибки отработки CMake скриптов, которые по логу порой даже понять трудно, потом чинить ошибки GNU Make, потом чинить ошибки компилятора, чинить ошибки компоновщика. Ещё CMake перед сборкой занимается тестированием компилятора. В результате долго отрабатывает скрипт. CMake работает в два прогона. Да и сами скрипты сборки make которые выращивает CMake получаются очень грязными. С душком.... Да они работают, но читать их человеку просто не-ре-аль-но....
Лучше, быстрее и надежнее просто ликвидировать лишнюю стадию отработки CMake скриптов и просто самим взять и написать лаконичные скрипты сборки GNU Make. С точки зрения DevOps результат будет абсолютно тем же: сборка из скрипта, по клику. А раз так, то зачем платить больше? Не надо слишком сильно увлекаться FrameWork(о) строительством.
В GNU Make есть всё, что нужно для полноценной автоматизации: топологическая сортировка целей, регулярные выражения, выявление не поменявшихся файлов, функции, операторы. На GNU Make решаются 99,99% всех задач по DevOps(у).
Uporoty
12.01.2025 06:50Язык Си был разработан для кросс-платформенности. Переводя на кухонный язык, это чтобы одну и ту же программу можно было собирать в разнообразных операционных системах и разных процессорных архитектурах. Если же Вы все в своей организации работаете только в одной системе или пишете для одного процессора, то вам Си нужен как собаке бензобак. Да.. Именно так.. Вам много проще будет самим писать машинные инструкции сразу на ассемблере.
Потом, если вы до этого никогда не писали на высокоуровневых языках, то сразу кидаться писать на Си пожалуй тоже нет резона. GCC и Clang - это всего лишь компиляторы. И вам будет с непривычки будет архи сложно разобраться с огромным калейдоскопом разнообразных и новых для себя расширений файлов: .c, .h, .obj, и прочие. Си очень навороченный и переизбыточный язык в сравнении с ассемблером.
Если у вас цель просто программировать, то лучше сосредоточиться на ассемблере. Тогда у вас в репозитории фактически будут только один тип файлов для версионного контроля: *.asm. Easy!
Си же - это очень навороченный язык в сравнении с ассемблером и там много избыточного функционала. Много того, что вам никогда даже не пригодится. В случае выбора Си вам, например, придется помимо логических ошибок в программе, чинить ещё ошибки препроцессора, ошибки парсера, которые по логу порой даже понять трудно, потом чинить ошибки линкера. Ещё в Си перед сборкой работает препроцессор. В результате долго отрабатывает компиляция. Си работает в 7 прогонов! Да и сами машинные инструкции сборки кода на Си которые выращивает GCC или Clang получаются очень грязными. С душком.... Да они работают, но читать их человеку просто не-ре-аль-но....
Лучше, быстрее и надежнее просто ликвидировать лишнюю стадию компиляции Си-кода и просто самим взять и написать лаконичный код на ассемблере. С точки зрения DevOps результат будет абсолютно тем же: сборка по клику. А раз так, то зачем платить больше? Не надо слишком сильно увлекаться FrameWork(о) строительством.
В ассемблере есть всё, что нужно для полноценной автоматизации: машинные инструкции, регистры, метки. На ассемблере решаются 99,99% всех задач по разработке.
nuclight
12.01.2025 06:50Только этот сарказм не соответствует действительности (ладно бы еще про С++, но просто Си - это кроссплатформенный ассемблер и есть). В отличие от кучи реальных проблем в CMake (да, и блоата тоже), из-за которых начали появляться альтернативные системы сборки еще и еще.
Uporoty
12.01.2025 06:50Соответствует ровно настолько же, насколько соответствуют действительности набросы комментатора выше про системы сборки :D
В Си тоже есть реальные проблемы, из-за которых начали появляться всякие там Rust'ы.
Но никому в здравом уме не пришло в голову из-за этого пересаживаться обратно на ассемблер, даже для не-кроссплатформенных проектов.Точно так же как из-за проблем с CMake начали придумывать другие системы сборки, но не стали снова повсеместно писать вручную мейкфайлы.
Целиком и полностью идеальных инструментов, напомню, в мире вообще не существует, недостатки можно найти у чего угодно. Но это не повод вообще принципиально не использовать ничего кроме самого первого и самого старого (у которого недостатков ничуть не меньше).aabzel
12.01.2025 06:50В Си тоже есть реальные проблемы . недостатки можно найти у чего угодно.
Это какие ещё такие проблемы есть в Си?
rukhi7
12.01.2025 06:50мне одна доподлино известна: если у вас есть функция для которой обязательно надо вызвать двойника (антипод), например Lock-Unlock, в Си надо вручную отследить все выходы из области видимости, проблема решилась в С++, компилятор умеет.
nuclight
12.01.2025 06:50Нет, не "ровно настолько же". Разница принципиальна. Название логической ошибки сами найдете.
Точно так же как из-за проблем с CMake начали придумывать другие системы сборки, но не стали снова повсеместно писать вручную мейкфайлы.
А вполне могло оказаться, что зря. Что надо было не затыкать дыры в "новом" решении, а попробовать откатиться и начать заново. Сейчас секрет открою: вообще-то, CMake был не заменой Make - он был заменой autotools. Который родился в совсем другой среде зоопарка платформ, давно неактуальной, то есть можно было пробовать делать снова "просто" make. И попытки, кстати, были, например mk-configure.
rukhi7
12.01.2025 06:50Лучше, быстрее и надежнее просто ликвидировать лишнюю стадию компиляции Си-кода и просто самим взять и написать лаконичный код на ассемблере.
вот это вы конечно загнули!
Я когда-то 20+ лет назад писал для 8-ми битных МК на ассемблере полную прошивку (-и), когда я наконец нашел С-компилятор для тех микроконтроллеров моему счастью и восторгу не было предела - я это поэтому очень хорошо помню, счастье нельзя забыть. Я думаю нет более широкого шага в повышении так называемого уровня языка програмирования чем от ассемблера к, даже самым первым, версиям плейн-Си при полном сохранении функциональности вплоть до того что в Си можно использовать встроенный ассемблер, можно проверять сгенерированный ассемблер, можно управлять памятью круче чем в ассемблере еще до этапа компиляции!
Uporoty
12.01.2025 06:50вот это вы конечно загнули!
я ничего не загибал, я всего лишь применил логику комментатора выше к языкам программирования :)
NeoCode
12.01.2025 06:50Дело не в GUI. Я никогда толком не пользовался make-файлами и потому у меня глаз незамыленный. Прочитал первую попавшуюся статью на Хабре - в целом все понятно, но это же сплошной антипаттерн. Какой-то текстовый ассемблер или что-то типа того. Общая область видимости, глобальные и магические переменные, все недостатки bash-скриптов (строки не в кавычках и прочее)... Словно бы из мира современных языков тебя окунули в какой-то FORTRAN/ALGOL/COBOL. Неудивительно что люди в этом не хотят разбираться и относятся как к какому-то древнему legacy, которое "как-то работает и ладно".
При этом еще большой вопрос, а нужен ли именно такой подход для сборки проектов. Мне больше нравится подход не make-файлов, а файлов проекта: есть некий "файл проекта" на базе стандартного структурного формата (json, xml...), который содержит в отдельных секциях список всех исходников, опции компиляции, информацию о целях сборки, информацию о конфигурациях (Debug, Release и т.п.). Все остальное решает компилятор. В редких случаях, когда какой-то конкретный файл нужно собрать с особыми опциями, или вызвать внешнюю программу, к файлу добавляется информация PreBuild/PostBuild. Преимуществ у такого подхода масса: иерархическая структурированность, пригодность для автоматического изменения, в т.ч. с помощью GUI (это же структурный формат для которого есть масса парсеров), использование в качестве файла ассоциированного с IDE (щелкаешь по нему и проект загружается в IDE, с деревом исходников, со всеми настройками).
mayorovp
12.01.2025 06:50А в каких языках файлом проекта заведует компилятор? Обычно же за него отвечает сборочная система - прямой конкурент томе же make.
vadimr
12.01.2025 06:50Например, Ada, Pascal, Lisp, отчасти современный Fortran. По сути, сборочная система – это результат отсутствия или ущербности поддержки модульности в языке.
mayorovp
12.01.2025 06:50А где на Паскале отдельный файл проекта, в том смысле в котором этот термин упомянут в комментарии выше?
Если вы про .dpr - то это всего лишь переименованный .pas, он содержит точку входа в программу, а вовсе не настройки параметров сборки.
vadimr
12.01.2025 06:50Мой пойнт как раз в том, что отдельный файл проекта – это суррогат, вызванный недостаточностью выразительных средств языка программирования.
В Паскале всё, что надо, делается через uses и псевдокомментарии.
Согласен, что мой комментарий был немного не по существу Вашего.
inkelyad
12.01.2025 06:50Мой пойнт как раз в том, что отдельный файл проекта – это суррогат, вызванный недостаточностью выразительных средств языка программирования.
Проект в общем случае может быть на нескольких языках. И не только программирования. Можно еще PDF-ки/html-ки документации из исходников собирать.
vadimr
12.01.2025 06:50Можно. Но нужно ли универсальный инструмент тащить в решение частной задачи, где его универсальность в 99.999% случаев не потребуется, и все будут копировать конкретное частное решение, как описано в статье?
mayorovp
12.01.2025 06:50Нужно. Просто этот инструмент тоже должен иметь достаточно фич, позволяющих избегать "эффекта Makefile".
vadimr
12.01.2025 06:50Давайте тогда разберёмся по сути. Я утверждаю, что сама по себе система сборки для гомогенного, т.е. одноязыкового проекта (например, на каком-нибудь C/C++) – плохое решение, так как одна и та же информация о зависимостях кодируется в двух разных местах совершенно различными способами. Один раз зависимость модулей почти явно (с помощью #include *) или совсем неявно предполагается самим текстом программы в файлах .c, а второй раз записывается в Makefile. Зачем это нужно? Низачем, просто так получилось.
---
* хотя заметим, что #include "file.h" формально в семантике языка никак не связано с зависимостью от "file.c". Но вас поколотят коллеги, если вы будете их называть по-разному.
artptr86
12.01.2025 06:50Сейчас это больше мешает, в том числе и автоматизации сборки, но такой уж дизайн этих языков
inkelyad
12.01.2025 06:50а второй раз записывается в Makefile
Ну, в нормально ситуации все-таки не записывается. Туда записывается директива вида "возьми то, что там компилятор насчет зависимостей выдал после анализа исходников".
inkelyad
12.01.2025 06:50А компилятор откуда знает, где брать исходники?
Руками или из того же Makefile вызвали, натравив 'ну вот это собираем'.
inkelyad
12.01.2025 06:50Ну так про то и речь.
Не понимаю возражения. Аргумент был 'что два раза/в два места записываем'. Ну так вот - два раза не записываем.
А что именно собирать в конкретном запуске надо - ту бибилотеку или эту утилиту - все равно чему-то сказать нужно.
vadimr
12.01.2025 06:50Один раз мы в программе на Си записываем функциональную зависимость функции main() от функции myfunc(). Второй раз мы в программе на Си записываем модульную зависимость файла main.c от файла myfunc.h. И в третий раз мы в Makefile записываем ту же самую по сути модульную зависимость файла main.o от файла myfunc.o (или main.c от myfunc.c, или обе).
Хотя по общепринятой прагматике (но не семантике) языка Си, если уж мы подтянули myfunc.h в main, то и соответствующий объектный код тоже за этим потянется. Как в uses в Паскале, только uses работает автоматически, а тут надо писать какой-то Makefile руками (или более высокоуровневой системой сбоки).
inkelyad
12.01.2025 06:50ретий раз мы в Makefile записываем ту же самую по сути модульную зависимость файла main.o от файла myfunc.o (или main.c от myfunc.c, или обе).
Вот этой части нет. В Makefile (в той части, что руками пишется, а на автоматическую нам все равно) прописано две строки:
1) натрави компилятор на исходники, что тут у нас есть2) втяни получившиеся зависимости для дальнейшего использования.
Ну а остальное - приблизительно во всех языках так. Большинство имеют тот или иной аналог "используй функцию x из библиотеки/модуля y" прежде чем x можно будет в коде вызвать.
vadimr
12.01.2025 06:50натрави компилятор на исходники, что тут у нас есть
Что вы подразумеваете в данном контексте под термином "исходники"? Компилятор Си обрабатывает строго те файлы, которые он получил на вход. Поэтому вам так или иначе придётся иметь в Makefile список этих файлов .c. Если вы не скажете компилятору в строке его вызова, что есть такой файл myfunc.c, то он об этом никогда и не узнает. Руками вы пропишете эти файлы в Makefile, или же с помощью сборщика более высокого уровня – не играет роли. Всё равно это информация, которая автоматически не экстрагируется из текста программы на Си, хотя фактически она там прописана в несколько другой форме (так сказать, эзоповым языком).
Сравните с поведением того же Delphi.
inkelyad
12.01.2025 06:50Поэтому вам так или иначе придётся иметь в Makefile список этих файлов .c
Список файлов - будет. Обычно просто в виде маски *.c
А зависимостей - о том, что если изменился файл abcd.h то нужно перекомпилировать abcd.c и asdf.c -- этого не будет. Точнее, будет в автоматически сгенерированном компилятором файле зависимостей, который в Makefile втянется.
Нет, можно конечно и руками, но это мазохизм.
Аргумент был именно про зависимости (выделение мое) "Один раз зависимость модулей почти явно (с помощью #include *) или совсем неявно предполагается самим текстом программы в файлах .c, а второй раз записывается в Makefile". И вот он (про повторное включени информации "x зависит от y и поэтому подлежит перекомпиляции при изменении y") - не очень верен.
mayorovp
12.01.2025 06:50Давайте тогда разберёмся по сути. Я утверждаю, что сама по себе система сборки для гомогенного, т.е. одноязыкового проекта (например, на каком-нибудь C/C++) – плохое решение, так как одна и та же информация о зависимостях кодируется в двух разных местах совершенно различными способами.
Любая разумная система сборки не требует кодировать зависимости второй раз, точка. Даже в make этого можно избежать, если постараться.
Хорошая же система сборки ещё и делает это минимальными усилиями, избегая "эффекта Makefile".
vadimr
12.01.2025 06:50Приведите какой-нибудь пример.
Просто, допустим, на гитхабе какой-нибудь проект на Си, в котором информация о зависимостях не дублируется.
mayorovp
12.01.2025 06:50Искать долго и муторно (я ж на Си сам не пишу уже давно). Но такие проекты я совершенно точно видел.
inkelyad
12.01.2025 06:50в котором информация о зависимостях не дублируется.
Способ, в общем, в документации описан. И да, оно порядком страшное, с этим придется согласится.
vadimr
12.01.2025 06:50Способ – это хорошо, только на практике всё не так просто по целому ряду причин. Поэтому я всё-таки жду практических примеров.
inkelyad
12.01.2025 06:50Поэтому я всё-таки жду практических примеров.
Ну например
Насколько я могу судить, никаких явных прописываний для сотен *.cc файлов, от чего они там зависят - нет.
А использование способа из документации - есть, если судить по строке 7 из common.mk
inkelyad
12.01.2025 06:50Ага, как же.
И где там зависимости прописанные руками? Про то что список исходников придется указать - я и не отрицал. К тому же оно не Makefile.
vadimr
12.01.2025 06:50Так список исходников – это и есть список зависимостей для исполняемого файла. Один раз эти модули прописываются в #include в виде .h, а второй раз – в этом списке в виде .cc (хотя это только прагматически одно и то же). О чём я и пишу.
А Makefile просто строится из этого cmake.
Я ж писал, сравните с Delphi или с другими языками/трансляторами, поддерживающими модульность. Там компилятору передаётся просто исходный файл главной программы, и он там уже сам ищет всё остальное, пользуясь только текстом программы и окружением.
inkelyad
12.01.2025 06:50Смотрим сюда. Тут, в зависимости от сконфигурированного бакенда в список исходников добавляется либо src/simutrans/sys/simsys_w.cc либо src/simutrans/sys/simsys_s2.cc
В которых есть одинаковая по сигнатуреbool dr_set_screen_scale(sint16 scale_percent) {Как Deilphi или паскаль будет выбирать, какой из вариантов в данном варианте компиляции использовать, если где-то не указан список, какой-именно брать?
vadimr
12.01.2025 06:50Просто будет ifdef в исходном тексте программы, в том же самом uses:
uses {$ifdef gdi} simsys_w {$else} simsys_s2 {$endif};Это "где-то" - это сам исходный текст на Паскале и есть.
inkelyad
12.01.2025 06:50Просто будет ifdef в исходном тексте программы, в том же самом uses:
Мне неочевидна большая эстетичность выбора варианта имплементации прямо внутри кода против указывания в коде
'#include "sys/simsys.h"' а выбора варианта имплементации - во внешнем конфиге.
vadimr
12.01.2025 06:50Вопрос тут не в эстетичности, а в дублировании.
А с точки зрения эстетичности, лучше динамический язык использовать, можно будет нужный вариант подгружать прямо на ходу по ходу исполнения программы.
BuddhaSugata
12.01.2025 06:50если проект это какое-то конечное готовое решение, то конечно можно и не использовать стороннюю систему для сборки. однако, тогда чаще всего его и собирать надо будет один раз - там система сборки не нужна, в принципе.
если же проект, напротив, имеет какое-то будущее потенциальное развитие, что почти автоматически подразумевает в том числе различные компиляции, то лучше использовать универсальные инструменты сразу, даже если это предполагает некоторое задвоение структуры. иначе через некоторое время вы встанете перед фактом необходимости переделывать всю систему, потому что вдруг для новых применений проект должен включать негомогенный кусок.
и заранее оценить разницу трудозатрат между задвоением в первом варианте и переделкой во втором - сложно, конечно, но я думаю шансы, что вы возненавидите вселенную больше раз во втором варианте выше.
vadimr
12.01.2025 06:50Когда (и если) у вас появится негомогенный кусок, то полная система сборки для этого тоже не нужна. Нужно будет сшить две части между собой, для чего, как правило, достаточно нескольких команд в скрипте bash.
Ваш аргумент сыграет только в том случае, когда многочисленные куски кода на разных языках будут перемешаны между собой, что архитектурно будет представлять собой кошмар в силу других обстоятельств.
inkelyad
12.01.2025 06:50Нужно будет сшить две части между собой, для чего, как правило, достаточно нескольких команд в скрипте bash.
make нужен чтобы не делать лишнюю работу и для готовой реализации инкрементной сборки.
Например у меня есть некие (большие) датасеты data1, data2. Они пропускаются через препроцессоры(работает дооолго и написана черт знает на чем и не мной) и из них генерируются уже исходный код, который потом компилируется.
В Makefile можно написать условное
code1.c: data1 foo data1 > code1.c code2.c: data2 bar data1 > code2.c #Дальше правила для сборки всех *.cТеперь, когда я меняю data1 (прилетает новая версия из VC) -- у меня обработка data2, генерации code2, его компиляция - запускаться не будет.
Такое можно сделать и на чистом шелл, но, прямо скажем, понятнее и проще не будет. И чем развеситей путь обработки (data3 из data1 и data2, data4 из data3 и еще какого-нибудь внешнего data5) -- тем печальней ручное отслеживание что-после-чего-делать-и-надо-ли.
vadimr
12.01.2025 06:50Это разумный сценарий, но согласитесь, что ради такой экзотической ситуации вряд ли нужно затеивать сыр-бор с компиляцией через внешнюю сборку каждой программы.
На самом деле make возник ровно потому, что в те времена о модульности ещё не думали, и компилятор Си (как и Паскаля того времени, впрочем) ничего подобного встроенными средствами не поддерживал. Потом модульную компиляцию придумали в UCSD для Паскаля, и оттуда она пошла дальше в Turbo Pascal, Delphi, а по другой ветке – в Аду и поздний Фортран. Но в C/C++ эта удобная вещь до сих пор пробивается с трудом просто по причинам совместимости с легаси.
Кстати, ещё по поводу вашего эстетического критерия: например, компилятор Intel Fortran умеет смотреть во включаемые файлы во время компиляции включающего и оптимизировать их совместно. При внешней сборке такое невозможно.
nuclight
12.01.2025 06:50ситуации вряд ли нужно затеивать сыр-бор с компиляцией через внешнюю сборку каждой программы.
Что здесь подразумевается под внешней сборкой? К моменту возникновения make модульность уже придумали, можно было бы втащить, но академики решили пойти путем универсальности, и сделали make не только для компиляции, а для чего угодно. И его действительно применяли в те годы так для чего угодно - например, когда книги писали, вовсе не код.
vadimr
12.01.2025 06:50Что здесь подразумевается под внешней сборкой?
Сборку программы внешними по отношению к языку программирования и его транслятору средствами.
На самом деле представления о прагматике языков программирования развивались постепенно. В Алголе-60, например, ввод-вывод ещё не был частью языка. Так же и с модулями. На момент написания make мейнстримом были Фортран IV и PL/I, где применялась ручная раздельная трансляция, а загрузочный модуль обычно компоновался из объектных непосредственно указанием параметров вызова компоновщика в ОС.
nuclight
12.01.2025 06:50Сборку программы внешними по отношению к языку программирования и его транслятору средствами.
Вот я тоже так подумал и не понял - как это? Ведь будет вызван таки родной транслятор языка программирования - а что же еще?!
vadimr
12.01.2025 06:50Транслятор в данном случае только создаёт объектный файл из исходного, но не управляет самим процессом сборки. И в связи с этим и описание процесса сборки является внешним по отношению к языку программирования.
А в модульных языках программирования сам язык включает описание сборки программы из модулей, а транслятор, соответственно, её и выполняет в ходе трансляции.
checkpoint
12.01.2025 06:50Словно бы из мира современных языков тебя окунули в какой-то FORTRAN/ALGOL/COBOL. Неудивительно что люди в этом не хотят разбираться и относятся как к какому-то древнему legacy, которое "как-то работает и ладно".
Раскрою секрет Полишинеля. Оригинальный make писали люди плотно сидящие на LISP-е, отсюда и весь его синтаксис. Для них рекурсивно вложенные конструкции, бесконечное число скобок и отсутствие кавычек является нормой. И кстати, кто это придумал строки заключать в кавычки, что это за глупость и бездарная трата ресурсов ? ;)
nuclight
12.01.2025 06:50Да ну прям, он же совершенно не похож на Лисп. Это shell-переросток, и нет там бесконечного числа скобок.
JBFW
12.01.2025 06:50Просто не надо усложнять. Сдуру можно и ... сломать.
А вот "файл проекта" - это не компилятор решает, а та среда, которая его понимает и выполняет.
Причем в разных версиях этой среды файл может и не заработать.Проблема тут на самом деле вообще в другом: вот так работает себе программист в своем любимом IDE, пишет свои "файлы проектов", у него всё хорошо, работа работается, деньги капают, все ОК.
А потом возникает необходимость вернуться к старому проекту 5-летней давности, и возможно уже не ему, а сменщику - и тут начинается пляска с бубном, потому что в версии 3.434.2 поломали совместимость с версией 2.344.555, и теперь нужно найти конвертер форматов файлов проектов, который шел с версией 3.0, но ее уже нет...NeoCode
12.01.2025 06:50Проблема в том что "файл проекта" в существующих языках не является частью стандарта языка. Хотя казалось бы, почему не стандартизировать? Тогда заодно решилась бы и проблема совмесимости между разными компиляторами и IDE. Файл-то один, стандартный, работай в любой ОС, с любым компилятором и из любой IDE.
nuclight
12.01.2025 06:50Ну это просто какой-то гимн неосиляторству - "не хочу учиться, хочу IDE". И на Алгол с Коболом оно, кстати, вот совсем не похоже - Алгол предок Паскаля, Кобол похож на SQL. Более того, для того, чтобы быть нормальным профессионалом в ЛЮБОЙ отрасли, нужно знать её историю (желательно пройти сжато во время обучения), подобно принципу тождества филогенеза и онтогенеза в биологии - и для IT это те самые сильно повлиявшие на отрасль языки из прошлого (Фортран с Коболом, кстати, даже и живы в настоящем).
Впрочем, и не видевший их человек, но который имеет профильное образование, то есть как минимум дискретную математику (графы) и хотя бы азы теории компиляции, легко въедет что в шелл-скрипты, что в make. А остальные будут подменять словом "современные" словом "к чему привычно лично мне" - нет, почему вот этот подход из IDE не лучше, тут на Хабре уже объяснялось (в комментах есть ссылка на статью про сборку скриптами).
mayorovp
12.01.2025 06:50Только вот непонятно какое отношение статья про сборку скриптами имеет к разнице между командами
make buildиdotnet build, и почему те, кто пользуется второй, "неасилили" make.
DarthVictor
12.01.2025 06:50Если инструмент для простых задач требуется ОСИЛИВАТЬ, то либо инструмент выбран не по задаче, либо создатели инструмента сами НЕ ОСИЛИЛИ написание инструментов.
Rive
12.01.2025 06:50Напоминает промпты для генерации ИИ-изображений, которые могут оставаться неизменными даже на профильных конкурсах, пока за них не обещают начать банить.
askv
12.01.2025 06:50А мне это напомнило юридическую сферу: «дайте рыбу договора» (устава, нормативного документа, и т.д.). Последствия бывают печальными. Для каждого сложного инструмента должен быть специалист соответствующего профиля и уровня. Для того, чтобы решить, можно ли обойтись более простым инструментом, тоже должна быть соответствующая квалификация. Но проблема неквалифицированных людей в том, что они чаще всего не осознают границы своей компетентности.
ToSHiC
12.01.2025 06:50Я не очень понял вашу аналогию с рыбой договора. Если мне надо сделать типовое действие (купить машину, например) - почему плохо использовать шаблон?
Если действие между юрлицами - то примером может быть подписание договора о неразглашении между двумя контрагентами. Вы считаете, что тут тоже нельзя использовать шаблон, и всегда надо привлекать дорогих юристов?
unclejocker
12.01.2025 06:50Я думаю имеется в виду, что могут дать "рыбу" с зашитым обязательством принести первенца в жертву богу-крокодилу. Приходится внимательно изучать что дали и без профильных знаний (или хотя бы насмотренности) что то может проскочить.
askv
12.01.2025 06:50Даже прочтение договора не всегда помогает оценить все последствия, т.к. помимо договора есть ещё закон и обычаи делового оборота.
mayorovp
12.01.2025 06:50Плохо то, что вам нужно использовать чей-то шаблон чтобы сделать типовое действие.
randomsimplenumber
12.01.2025 06:50Кому то типовое действие, кто-то его совершает пару раз в году.
ramyalexis
12.01.2025 06:50Но в общем по стране с единым пространством законов и кодексов это же типовое действие?
randomsimplenumber
12.01.2025 06:50В общем да. А в частном случае нет Вы, например, завещание как часто составляете? А нотариус их ежедневно вычитывает.
vadimr
12.01.2025 06:50Рыба договора – это не совсем прямой аналог, так как она отчасти представляет собой внешнюю зависимость. Делая одинаковые договоры, вы опираетесь на уже существующую юридическую практику по таким договорам. Если же вы перепишете договор с нуля, то вам и вашему контрагенту придётся с нуля полностью переоценивать его значение.
aragaer
12.01.2025 06:50На моем опыте это обычно сопровождается словами "я программист на языке <вставить название языка>, а изучать документацию make я не хочу". Кроме Makefile это же распространялось на shell-скрипты, причем местами даже "какую-то ты тут странную конструкцию написал, почему это у тебя if без скобок? Сделай как привычно"
Дело даже не в том, что синтаксис мэйкфайла слишком сложный. Он воспринимается как ненужное усложнение, которое идет в довесок к и без того уже сложной работе программиста. Примеры с промптами и "рыбой договора" вроде бы подтверждают эту идею.
nerudo
12.01.2025 06:50Проблема в редком использовании инструмента. Даже если ты когда-то его изучал, что-то однократно сделал и год потом не пользовался - все забудется. Следовательно, нужно либо каждый раз тратить кучу времени на непрофильную задачу, либо соблазниться реиспользованием древней магии без понимания деталей. Ну еще один путь - нанять отдельного специалиста, который будет профи именно в этом вопросе.
AlexanderY
12.01.2025 06:50Я, в какой-то момент, стал писать для себя документацию в readme. Как раз, чтобы через год не вспоминать все детали, а просто прочитать пару абзацев собственных мыслей и сразу всё вспомнить. Очень помогает, рекомендую.
nerudo
12.01.2025 06:50Я тоже, но помогает далеко не всегда. То, что кажется очевидным и не требующим пояснений здесь и сейчас, спустя некоторое время сильно затуманивается. А выбрать заранее что затуманится, чтобы не писать все - затруднительно...
rukhi7
12.01.2025 06:50Насколько я понял суть в статье в том что людям свойственно НЕ читать инструкцию если что-то можно попробовать запустить с уже имеющейся (скопированной) конфигурацией. То есть русский авось он на самом деле не русский а международный авось! Инструкции читать никому не хочется.
Оказывается надежда на то что мы сейчас скопируем сюда оттуда и оттуда и оно авось заработает, разбираться не с чем не надо - свойственна людям не зависимо от национальности. Интересная мысль!
dyadyaSerezha
12.01.2025 06:50Смысл статьи вижу только тогда, когда copy-paste используется без понимания, что именно ты потом модифицируешь и как это вообще работает. В остальном же это абсолютно правильная и вездесущая практика не только в инструментах сборки, а вообще везде в программировании.
Пример. Чел работает в группе над большим мнонолетним проектом и вдруг ему надо написать новуюю утилиту, которая парсит некие входные параметры запуска (CLI). Варианты: парсить целиком с нуля или использовать стандартную библиотеку в проекте (для любого языка есть такие библиотеки). Далее, варианты для библиотеки: читать доки и писать все самому или посмотреть любую другую прогу в проекте (в инете) с этой юиюлиоткеуой и сделать нужный copy-paste, модифицировав его нужным образом. Вариант "я и так помню, как парсить входные CLI параметры с помощью этой стандартной библиотеки" в 99% случаев не катит, потому что писать такие пироги в большой проекте нужно в лучшем случае раз в год, в скорее всего гораздо реже или вообще никогда
Итак, что выберет любой нормальный программист? Самый последний вариант с copy-paste, естественно, и это абсолютно правильно. А если есть доступ к нужному ИИ, он ещё и попытается сгенерить код для парсинга именно его параметров CLI с использованием их библиотеки и только слегка модифицировать код при необходимости.
Ещё раз, это абсолютно нормальная и верная тактика вообще везде в инженерии.
rukhi7
12.01.2025 06:50большим мнонолетним проектом и вдруг ему надо написать новуюю утилиту, которая парсит некие входные параметры запуска (CLI)
я бы для начала сосредоточился на том откуда берется это сказочное "вдруг". А оно берется как раз оттого что эти "входные параметры запуска" копируются (или даже лепятся-наворачиваются) в проекте как получится в виде заплаток, в виде костылей лишь бы оно продолжало хоть как то работать. И в один прекрасный момент случается такой вдруг что какой то начальник проснулся, например, и обнаружил что половина функциональности работает через зад или вообще не работает при определенных вполне естественных условиях, а работает только если стоять в очень не удобной позе. Ну и тогда принимается "сбалансированное" решение не привести эти параметры и способ их использования в порядок (это же многолетний проект!), а навернуть еще "простенький" парсер на эти параметры, а после парсера фильтр, а после фильтра,... что там у нас после фильтра обычно?
Как то так.
Самое грустное что это действительно абсолютно нормальная и верная (тут я очень не уверен) тактика вообще везде в инженерии.
dyadyaSerezha
12.01.2025 06:50Да нет же. Это не уникальный проект по разработке компилятора Java, например, а классический корпоративный большой проект с десятками приложений, почти все из которых когда-то были начаты с нуля другими или вообще сначала сгенерированы через IDE (сам каркас приложения). И вот вдруг надо написать CLI-утилиту по экпорту данных во внешнюю для проекта систему (классическая интеграция). Таких примеров куча, но для конкретного проекта это очень редкое событие и никто не вспомнит сам, как именно парсить параметры, особенно если они не позиционные, не обязательные и могут иметь структуру (типа "ключ=значение"). Тут copy-paste сам бог велел.
aamonster
12.01.2025 06:50Ну так-то в программировании от copy-paste стараются уйти – вынос общего кода в функции, агрегация, наследование...
dyadyaSerezha
12.01.2025 06:50Блин, ну как и куда вынести разбор параметров, если это вообще отдельная программа?
Да и в реальных корпоративных программах половина кода, это модифицированная копи-паста.
sukharichev
12.01.2025 06:50О да, есть такой эффект. У админов это особенно ярко проявляется в конфиге squid proxy, где поколения и поколения копипастят порт для протокола gopher. Так и хочется сказать: на кой ты это делаешь, этот протокол умер раньше, чем ты родился, прекрати!
randomsimplenumber
12.01.2025 06:50прекрати
Работает - не трогай (бурчит по админски).
В далёких 200х, когда me конфигурировал squid, методом копипасты конечно же, не было уже там никаких gopher. Кто-то нашел архив старинных конференций Fido и разбудил древнее зло?
Uporoty
12.01.2025 06:50Работает - не трогай (бурчит по админски).
В этом случае это очень опасный подход.
Включение какого-нибудь ненужного сервиса или протокола как минимум повышает риск эксплуатации уязвимости в этом сервисе или реализации протокола злоумышленниками. Особенно когда его порт точно также забыли закрыть на фаерволе из-за бездумного копипаста существующих портянок.
sukharichev
12.01.2025 06:50Да там этот гофер везде:
https://www.google.com/search?q=squid.conf+gopher&oq=squid.conf+&gs_lcrp=EgZjaHJvbWUqCAgAEEUYJxg7MggIABBFGCcYOzIGCAEQRRg7MgcIAhAAGIAEMgcIAxAAGIAEMgcIBBAAGIAEMgcIBRAAGIAEMgYIBhBFGDwyBggHEEUYPdIBCDQ0NTVqMGo3qAIIsAIB&sourceid=chrome&ie=UTF-8
причем в 2021 (!) в сквиде нашли уязвимость, связанную с его обработкой, так что это идиотское упоминание его в safe_ports не просто тупизна, а усугубляет уязвимость :)
https://github.com/squid-cache/squid/security/advisories/GHSA-f5cp-6rh3-284w
Его надо не просто убирать из safe_ports а еще бы и пересобирать сквида без поддержки.
checkpoint
12.01.2025 06:50Ждем разоблачителей "эффекта httpd.conf", "эффекта sendmail.cf", "эффекта C/C++" и, как это не парадоксально - "эффекта Python". Кто-то может написать программу на Python с нуля без единой библиотеки и без копипасты ? ;)
nuclight
12.01.2025 06:50А что, неужели уровень "программистов на Питоне" упал уже настолько, что они с нуля уже не в состоянии?
inkelyad
12.01.2025 06:50"эффекта sendmail.cf"
А было бы неплохо нормальную статью(или ссылку, если есть). Потому что эффект "язык конфигурирования стремиться стать Тьюринг-полным языком программирования" - еще как реален.
Особенно в виде "нам нужен Универсальный Описыватель Всего Сущего - а то на нормальном языке бизнес-действия трудно и дорого делать(программисты дорогие), а с этим описавателем - можно быстренько добавить пару строк в базу данных - и готово".
checkpoint
12.01.2025 06:50sendmail.cf это вообще притча во языцех.
"Универсальным Описателем Всего Сущего" является LISP. В мире LISP-а такой проблемы вообще не существует, там и программ, и данные, и конфиг к ней - это код на LISP-е.
Аналогично в Perl5 - конфиг можно представлять программой на этом же языке и подгружать оператором
eval { do $filename; }. В остальных языка программирования приходится придумывать отдельный язык для описания конфига. В последние годы сообщество программистов сходится во мнении, что для этой цели хорошо подходит JSON и YAML. Но мне нравится Perl. :)artptr86
12.01.2025 06:50Тогда почему лисперы изобрели мейкфайлы, а не сделали систему сборки на лиспе с конфигами/скриптами на S-выражениях?
vadimr
12.01.2025 06:50В лиспе система сборки является частью лиспа.
artptr86
12.01.2025 06:50Так речь не про лисп, а про сборщик для C/C++ в частности
vadimr
12.01.2025 06:50Это часть общего вопроса о том, зачем вообще существуют языки C/C++, если есть Лисп.
Если бы средний программист бы бы в состоянии и в настроении монстрячить файлы сборки на лиспе, зачем ему вообще было бы писать какой-то ещё другой код в c/cpp?
artptr86
12.01.2025 06:50Так монстрячат же файлы сборки на Automake, CMake, Meson и других не очень тривиальных «языках» (подразумеваю тут сочетание синтаксиса и семантики).
checkpoint
12.01.2025 06:50Потому, что LISP стремительно умирал, а C/C++ набирал обороты. Очевидно же, что для сборки программ на Си держать LISP машину (даже в виде интерпретатора) не целесообразно.
Хотя в современном мире такая зависимость мало кого удивила бы. Вот недавно столкнулся с тем, что OpenLane написаный на Python использует конфигуратор который написан на Python с использованием wasmtime, а сам wasmtime написан на Rust. Чтобы собрать всё это говно мне пришлось сначала установить Rust тулчейн, разобраться с cargo, собрать wasmtime и уже после этого запустить OpenLane. Бред полнейший! Но все при деле. :)
artptr86
12.01.2025 06:50Но ведь синтаксис мейкфайлов тоже не сишный. Вот и в make вполне уместилась бы лисп-машина вместо интерпретатора мейк-правил поверх шелла.
checkpoint
12.01.2025 06:50Не берусь утверждать, но не удивлюсь что внутри make как раз таки своя LISP-подобная виртуальная машина. Во всяком случае автор у make, GCC и emacs один и тот же - товарищ Столлман. :)
artptr86
12.01.2025 06:50Make была создана Стюартом Фельдманом (Stuart Feldman) в апреле 1976 года в Bell Labs.
Кстати он был фортранистом, а не лиспером.
checkpoint
12.01.2025 06:50Того make-а уже давно нет. Современный make это GNU Make написанный Столлманном и сотоварищами в 1980-х и впитавший все их "профессиональные деформации". Изредка встречается BSD Make (FreeBSD) и на нём тоже лежит отпечаток LISP-а.
artptr86
12.01.2025 06:50В любом случае они стали переписывать оригинальный Make с обратной совместимостью, а не стали делать с нуля новую «правильную» систему сборки на основе S-выражений.
nuclight
12.01.2025 06:50Сижу на FreeBSD и ни разу не видел в нашем make ничего похожего на Лисп. Наоборот, там императивные конструкции вида
.директива ...
обычные строки мейка
.конец
например.for v in ${PROG_VARS:O:u} .if empty(${PROG_OVERRIDE_VARS:M$v}) .if defined(${v}.${PROG}) $v += ${${v}.${PROG}} .elif defined(${v}_${PROG}) $v += ${${v}_${PROG}} .endif .else .if defined(${v}.${PROG}) $v = ${${v}.${PROG}} .elif defined(${v}_${PROG}) $v = ${${v}_${PROG}} .endif $v ?= .endif .endforcheckpoint
12.01.2025 06:50.директива
...обычные строки мейка
.конец
Так это только верхушка айсберга, "предварительные ласки" так сказать. А есть еще набор правил сборки.
Разумеется в Makefile-е нет прямого синтаксиса LISP-а. LISPсисты принесли в него идею рекурсивно вложенных правил и эвалуацию правил и переменных в момент применения (Вы же в курсе чем отличается присваивание '=' от ':=' ?). А также идею встроенных функций как лямбда-вычислений. И я не говорю, что это плохо, просто поясняю откуда это взялось и почему программистам которым никогда не приходилось сталкиваться с такими языками Makefile кажется чудовищно сложным.
nuclight
12.01.2025 06:50В курсе, но не нахожу "рекурсивно вложенными правилами" - какая ж рекурсия, если там граф? И встроенные функции как лямбды... ээ, что? Покажите мне их в оригинальном/BSD Make. И даже в GNU Make функции именованы и не сказать что бы всегда без сайд-эффектов...
То есть, одного лишь "в момент применения" не нахожу достаточным для похожести на Лисп - ведь в шеллскриптах-переростках тоже баловались (и продолжают) с eval для отложенного применения.
Вот Tcl действительно развитие шелла в сторону Лиспа.
nuclight
12.01.2025 06:50Вообще-то нет. У Столлмана только, простите за каламбур, ремэйк в виде GNU Make, спустя более чем десятилетие после оригинального.
vadimr
12.01.2025 06:50По тем временам, когда был написан make, интерпретатор лиспа был большой и тяжёлой программой (в особенности из-за работы сборщика мусора при малом объёме памяти у тогдашних компьютеров). Даже emacs из-за этого не целиком написан на лиспе.
У Apple II сам-то по себе компилятор Си требовал для работы сменять в дисководе три диска по очереди, если я правильно помню.
Сейчас, конечно, выдумывать новый язык ради сборки не имеет никакого смысла. Но кого когда это останавливало?
artptr86
12.01.2025 06:50Смысл как всегда — уменьшение количества рутины: когда стало невмоготу писать на чистом Make, изобрели Autoconf/Automake; когда стало невмоготу писать под Autoconf/Automake, изобрели CMake, SCons, Meson, QMake и т.д.
rukhi7
12.01.2025 06:50так вот и с Make-ом также! Проблема-то обычно не в Make-е, а в куче тулзов которые он вызывает, конфигурирует и вообще бог знает чего с ними делает и чего туда напихали. Например запустить Python чтобы он сгенерировал Rust который генерирует Python который генерирует XML, JSON, которые нужны из С++, которые надо проверить через XSLT, ...
checkpoint
12.01.2025 06:50Так за такие дела надо руки программистам отрывать по самую задницу и make в этом не виновен. Люди с клавиатурой совершенно потеряли берега. Вообще, я заметил, что у программиста до определенного возраста есть такое психическое расстройство - чем больше технологий и фреймворков он освоил, тем непреодолимей у него жаление затолкать их все в один проект, пусть даже через систему сборки. С возрастом это проходит. Вот только не понятно что делать пользователям его творения, когда вся эта лапша начинает рассыпаться из-за непрерывных изменений в зависимостях.
А еще к такому эффекту приводит попытка сделать быстро и избавиться от проблемы (закрыть тикет). Ведь, как тут мне уже сказали, за написание Makefile-а денег не платять. И с проникновением ChatGPT эта проблема разрастется до невиданных масштабов.
Uporoty
12.01.2025 06:50С возрастом это проходит
Как раз наоборот, с возрастом приходит понимание, что для каждой задачи нужно использовать намиболее подходящие и эффективные для этой задачи инструменты, а не пытаться упорно забивать гвозди микроскопом потому что так привычнее и лишь бы не дай бог не добавить ещё одну зависимость.
victor_1212
12.01.2025 06:50попытка сделать быстро ...
точнее необходимость, примерно с середины 90х разработка sw и fw стали вообще определяющими факторами в конкуренции, большая часть инженеров в us - sw engineers, конкуренция приводит к тому что. реально хватает время только на самые приоритетные вещи, если makefile позволяет сделать сборку этого достаточно, надо успеть раньше других выйти на рынок, хорошо это или плохо, но более-менее работает, остальное дело привычки, которая как известно вторая натура :)
nuclight
12.01.2025 06:50Плохо это, конечно. Основная причина копроэкономики. Не из-за makefile, конечно (они просто симптом), а из-за этого сования этого подхода менеджерами везде.
victor_1212
12.01.2025 06:50вообще при нормальной организации по технике должен быть другой руководитель, типа project leader, менеджер может спросить "почему" например ту или иную OS или IC решили использовать, т.к. на сроки и стоимость проекта влияет, ему обязаны объяснить, но не более, это просто не его дело про makefiles рассуждать, в us обычно это строго разделено, может в faang такое и случается, не знаю, но там где работал подобного не видел, дело менеджера это обеспечение работы ресурсами и контроль сроков
rukhi7
12.01.2025 06:50чем больше технологий и фреймворков он освоил, тем непреодолимей у него жаление затолкать их все в один проект, пусть даже через систему сборки.
по моим наблюдениям как раз наоборот, тот кто не в состоянии освоить какой-то инструмент-фреймворк (свой первый) просто начинает рассказывать что инструмент плохой и начинает осваивать следующий с тем же результатом и с тем же переходом далее. Тот кто что-то действительно освоил и действительно научился получать результат тому скакать никуда не надо.
Uporoty
12.01.2025 06:50тот кто не в состоянии освоить какой-то инструмент-фреймворк ... просто начинает рассказывать что инструмент плохой
...и поэтому не надо использовать никаких новых инструментов, надо продолжать использовать старые, как деды завещали, пусть даже они плохо подходят для очередной задачи.
rukhi7
12.01.2025 06:50нет я не про это, я про то что зоопарк не надо устраивать из инструментов. Раз мы говорим что тот инструмент плохой, а этот лучше, так будьте добры и последовательны переводите ВСЮ ОДНОТИПНУЮ работу на новый инструмент.
Uporoty
12.01.2025 06:50ну так речь как раз о том, что даже в одном проекте может быть много разнотипной работы. бэкенд, фронтенд, мобилки, IoT, сборка, интеграционное тестирование, CI/CD автоматизация, подготовка датасетов, и т.д.
Да и с однотипной работой может оказаться так, что проект начали делать одним инструментом, это оказался не очень удачный выбор, либо с тех пор появилось что-то что подходит гораздо лучше - только из-за этого выбрасывать старый код и переписывать все полностью с нуля, естественно, никто не будет, но в новых компонентах продолжать мучаться используя неподходящие инструменты смысла нет.
rukhi7
12.01.2025 06:50появилось что-то что подходит гораздо лучше - только из-за этого выбрасывать старый код и переписывать все полностью с нуля
тут как посмотреть, с одной стороны не хочется переписывать старый код, а с другой стороны придется заниматься сопровождением и держать в голове две разные системы-концепции. А если потом на это все какую-то общую функцию накатить, а унификации внутри нет? Вот так вот монстры и получаются.
Но я согласен в моменте это скользкий вопрос.
nuclight
12.01.2025 06:50Так десятый закон Гринспуна или всё-таки под каждую задачу лучше подходящий инструмент? (нет, "зоопарк" не оправдание)
rukhi7
12.01.2025 06:50в этом отношении очень показательно, мне кажется, всеобщее восхищение инструментами Командной Строки и отказ от инструментов с визуальным интерфейсом. Прям вот стремление к всему новому и современному бьет ключом, скоро на самые современные перфокарты перейдут и будут восхищаться как это здорово.
или всё-таки под каждую задачу лучше подходящий инструмент?
эта опечатка по Фрейду :) ? Может не под каждую задачу, а под каждый тип задачи?
aabzel
12.01.2025 06:50....стремление к всему новому и современному бьет ключом .....отказ от инструментов с визуальным интерфейсом.
Потом от таких "новаторов" я часто слышал мнение, что в
embedded программировании в принципе не может быть никакого DevOps(а)
Якобы вот есть GUI(ня) в IAR и там надо много мышкой водить.
"Ты же не станешь ставить шаговые двигатели для сдвигания курсора мышки чтобы тыкать в GUI-не" и т. п.
Поэтому всё дальше делаем вручную.
Мышкой.
И ходим с протезами на запястье.
victor_1212
12.01.2025 06:50про embedded sw обобщать супер трудно, типа как в анекдоте про слона которого группа слепых пытается описать, по многим причинам, во-первых системы разной стоимости и важности в диапазоне 5-6 порядков, во-вторых самые интересные вообще для обсуждений закрыты, ada тоже для embedded в основном была создана
rukhi7
12.01.2025 06:50я работал с англоязычным коллегой и у нас была супер навороченная embedded IDE для кастомных систем на кристале - АРМ интегрированный с цифровыми спутниковыми приемниками (4 штуки) с которых мегабайты трафика в секунду приходили. Так для отладки этот коллега нашел тулзу которая записывает движения мышью и нажатия, при этом тулза запоминает по картинке кнопки, галочки,... - куда нажимать (анализирует картинку!), в принципе тоже можно было скрипты написать и делать то же самое скриптами, но кто будет оплачивать такую работу по написанию тулзов. Вот там действительно страшная IDE была, там несколько уровней периферии визуально конфигурировались, дело в том что если бы это было НЕ визуально то разобраться с этими уровнями мне кажется было бы вообще не реально, визуально ты хоть можешь видеть какой-то граф пройденных-доступных зависимостей, в виде линейного текста ограниченного экраном это не реально представить и обозревать и соответственно ориентироваться в этом.
rukhi7
12.01.2025 06:50Потом от таких "новаторов" я часто слышал мнение
от меня вы же такого не слышали, а получается что это вы меня обзываете " таким "новатором" " :), а эта роль ругательная и меня расстраивает что вы ее ко мне применили :) !
Я, наоборот, всех уверяю что в любом программировании (не только в embedded) визуальная среда не помеха DevOps-у. Тут как раз это не зоопарк инструментов, а для каждого ТИПа задачи свой инструмент, вы же не будете дебагом заниматься на тулзах DevOps-а!
Вот и здесь вас спрашивали:
Вы правда думаете, что msbuild из скрипта не запустить?
Так и в любом IDE проект (компиляция, линковка, и что угодно) из скриптов запускается! Если ваши новаторы этого не знают- не умеют, чьи это проблемы? Может это потому что вы IDE сами не цените и новаторов соответствующих подбираете которые тоже сначала не ценят, а потом, когда оценят, разобраться до конца не могут?
Кстати в нормальных IDE без мышки одной клавиатурой вполне можно обходиться, при наличии навыков.
nuclight
12.01.2025 06:50Это "всеобщее восхищение", оно сейчас с нами в одной комнате? Я скорее про [ув]еб-технологии восхищение наблюдаю, чем желание изучать командную строку и её утилиты (да, make из их числа).
Прям вот стремление к всему новому и современному бьет ключом
А Фрейда впору привлекать вот сюда. "Новее" не значит "лучше".
aabzel
12.01.2025 06:50Да.
Пуговицы и очки придумали в средневековье. Однако ими продолжают пользоваться
Так же и с make.
rukhi7
12.01.2025 06:50чем желание изучать командную строку и её утилиты (да, make из их числа).
когда вы изучите все утилиты командной строки вы можете внезапно выяснить что вам придется перейти работать в другой Шел с совсем другим набором утилит этой новой оболочки, и куда же вы денете все что вы вызубрили до этого, интересно, в таком случае?
А еще вы можете обнаружить что разные утилиты могут выполнять одни и те же функции. И наверно чтобы не забыть все утилиты вам придется применять по возможности как можно больше видов этих утилит в своем проекте, а хорошо ли это для проекта? Я боюсь что не хорошо. Кстати, вот мы и выяснили откуда берется зоопарк утилит в проектах, получается от желания изучить как можно больше утилит командной строки.
nuclight
12.01.2025 06:50>зубрить
>не забытьВаши проблемы вот отсюда. Нормальному инженеру незачем зубрить и постоянно применять побольше - ему достаточно помнить о существовании + описании смысла инструмента, а дальше при нужден он смотрит в справочник (manual-страницы по утилитам). Соответственно и на отличающихся платформах (а не шеллах) проблемы тоже нет.
nuclight
12.01.2025 06:50Сами деды почему-то вполне себе переходят на новые инструменты, когда те заслуживают того.
mayorovp
12.01.2025 06:50Пока что они тут в комментариях проповедуют, что ни одна сборочная утилита кроме make не может быть вызвана из скрипта. А такие утверждения - явный признак того, что на другие инструменты смотреть даже не пытались.
nuclight
12.01.2025 06:50Глупость какая. Вполне возможно, что пытались, увидели, что хуже. Идите да каждого из этих "они" спросите.
mayorovp
12.01.2025 06:50Если бы пытались и увидели что хуже - то так бы и писали. Но я вижу совсем другие аргументы.
Uporoty
12.01.2025 06:50значит это не деды.
деды же про любой инструмент не задумываясь говорят что он "не заслуживает", даже вообще ни грамма не разбираясь в том, что он из себя представляет и какую проблему решает.Uporoty
12.01.2025 06:50"дед" - это не про возраст, а про состояние мозга.
можно и в 30 быть дедом, а можно и в 70 не быть.
nuclight
12.01.2025 06:50Еще одна глупость. "Дедом" называют любого, кто типа осмеливается иметь мнение, отличающееся от модно-молодежного. Меня в мои 35+ называли дедом в чатах. Однако я вполне себе беру новые инструменты, если те лучше.
Uporoty
12.01.2025 06:50Аналогично в Perl5 - конфиг можно представлять программой на этом же языке и подгружать оператором eval { do $filename; }. В остальных языка программирования приходится придумывать отдельный язык для описания конфига
Такое же можно сделать в JavaScript и PHP, Perl тут не единственный.
checkpoint
12.01.2025 06:50Скажу более, даже в Python это возможно. Но не дай Вам Бог задать такой вопрос на StackExchang/Overflow - фекалии полетят в Вашу сторону бурным потоком. ;)
nerudo
12.01.2025 06:50Знаю промышленный софт, который так и пишет свой конфиг в файл .py в формате "dut.write(0x0, 0x0)". Очень удобно - определяешь write() и загружаешь в том виде, что нужно... И пусть эти умники с SO попробуют что-то сказать против флагмана микроэлектроники!
nuclight
12.01.2025 06:50А чего не попробовать сказать? Давайте вспомним иски против флагманов автомобилестроения, когда там оказались 11 тыщ глобальных переменных.
DikSoft
12.01.2025 06:50Описание частной проблемки глобальной беды мира Linux: отсутствие стандартов.
Все правила для текстовых конфигов софта пишутся авторами софта - свободными художниками, исходя из собственных представлений о прекрасном. Каждый придумывает собственный синтаксис. А с недавних пор ещё и формат. См. YAML и его вариации.
Когда меня окончательно задолбало вникать в картину мира каждого такого творца, на выручку пришёл MS Copilot, всякую конфигскую шнягу он освоил весьма неплохо.
inkelyad
12.01.2025 06:50Описание частной проблемки глобальной беды мира Linux: отсутствие стандартов.
При чем тут Linux и текстовые файлы. Оно сильно много где так. Пример - пробуем найти единый стандарт описания тарифных планов и разных скидочных предложений. Оно вроде как конфиг же, конфигурирующий поведение. Пусть и в базе данных частенько лежит.
DikSoft
12.01.2025 06:50При чем тут Linux и текстовые файлы.
Потому что это наиболее яркий и массовый пример полного беспредела в конфигах?
nuclight
12.01.2025 06:50Где беспредел-то? Распространенных вариаций "языка" конфигов будет, наверное, лишь чуть больше десятка, внутри же они будут отличаться только именами директив/переменных/etc. конкретной программы. В общем, никакой проблемы для грамотного технаря освоить очередной микро-язык никогда не было и не должно быть.
checkpoint
12.01.2025 06:50До прихода Linux-овых неофитов в мире Unix всё было ровно и гладко, был стандарт - autogen/configure. Конфиги строго в текстовых файлах. Но молодым и горячим это не понравилось и тут понеслось... появились CMake, qmake, imake, ninja, ant, gradle и еще тысяча страшных слов.
artptr86
12.01.2025 06:50Разве в перечисленных системах сборки конфиги не текстовые?
checkpoint
12.01.2025 06:50Текстовые, только синтаксис у них весьма разный. Под текстовым конфигом я имел в виду строки вида "aaa = bbb".
artptr86
12.01.2025 06:50Строго говоря, тогда и синтаксис Make не является исключительно набором присваиваний.
DikSoft
12.01.2025 06:50Совершенно верно. Это именно классический Linux-конфиг, куда валится всё, что автору захотелось, присвоения, условия, директивы, иногда логика.
Это общая болезнь линуксоидов. Всё в своём уникальном авторском формате. Чем автор себя считает гениальнее, тем более оригинален синтаксис и правила деления на логические разделы и форматы.
Самый больной бардак IMHO нынче в конфигурировании сетевого стека. Тут даже не только в зависимости от Debian/Red Hat, но ещё и от версии к версии всё с ног на голову переворачивается.
Совместимость, поддержка предыдущих версий, стандартные расширения файлов / их расположение? - Не слышали. И не хотим слышать! Мы художники, мы так видим.
checkpoint
12.01.2025 06:50Про сетевой стек в Linux-е полностью согласен, там дошли до того что начали выдумывать свои концепии и под них перестраивать стэк. А вот на счет текстового конфига в духе "переменная = значение" с резделами вида "[раздел]" это зело верное решение. Но беда в том, что от этого в Linux уже давно отказались - куда не глянь, везде свой синтаксис для конфига. Это одна из причин по которой многие старички возвращаются на *BSD.
artptr86
12.01.2025 06:50А система сборки на ini-файлах (а точнее, использующей формат TOML) есть только для Rust.
mayorovp
12.01.2025 06:50TOML всё-таки куда удобнее простых ini файлов, пусть и похож на них
nuclight
12.01.2025 06:50Ну уж нет, этому мутанту не следовало рождаться вовсе. Или конфиг настолько прост, что подходят простые ini, или уж берите сразу нормальный структурированный формат, а этот метис только зря зависимости ставит и времени на изучение требует.
mayorovp
12.01.2025 06:50А чем TOML не нормальный структурированный формат?
Уж получше JSON, который без нормального редактора для конфигов вообще не пригоден, и YAML, который на длинных конфигах теряет контекст.
nuclight
12.01.2025 06:50Ну а чем этот очередной NIH-велосипед лучше нормальных структурированных языков конфигов от, например, irssi, nginx или libucl? Вот эти [parent.child] сразу воняют жутким костылём из REGEDIT4 винды 95, только там это хотя бы было осмысленно из-за незасимости применения "секций" (можно отрезать часть файла), а здесь потеря визуальной структуры на ровном месте.
mayorovp
12.01.2025 06:50Ну, например, тем что это не велосипед, а готовый инструмент, который можно много где применять. Со своей спецификацией, реализациями под разные языки, поддержкой в редакторах и т.п.
Тут как раз язык конфигов nginx предстаёт велосипедом, потому что используется ровно в одной программе.
а здесь потеря визуальной структуры на ровном месте.
Визуальная структура и так теряется каждый раз, как в конфиге оказывается больше строк чем помещается на экран. Регулярные повторения путей до корня, как по мне, как раз позволяют её восстановить.
Ну и отрезание части файла в конфигах тоже не редкость. Типичное явление - два уровня конфига, к примеру значения по умолчанию и пользовательские настройки. Или системный и пользовательский конфиги. Или глобальный конфиг и конфиг окружения. Во всех этих случаях возможности TOML позволяют держать второй из конфигов в очень компактной форме.
nuclight
12.01.2025 06:50А причем тут конкретно Linux? Так абсолютно везде, где нет BDSM-ограничений, например, каких-то энтерпрайзов (да и те разные стандарты вполне любят). Вот вспоминаю конфиги Fido-софта в 90-е - DOS, никаких линуксов, и тоже кто во что горазд.
Совместимость, поддержка предыдущих версий, стандартные расширения файлов / их расположение? - Не слышали. И не хотим слышать!
А, ну вот это конкретно про Linux, да =)
Мы художники, мы так видим.
Как будто что-то плохое.
nuclight
12.01.2025 06:50А что, конфиги апача или сквида уже не текстовые? Бинарные конфиги до сих пор весьма редки на *nix.
jar_ohty
12.01.2025 06:50Я б это назвал "эффектом нитковдевателя". Помните такой девайс в комплекте иголок? У него на рукоятке иногда изображена узнаваемая голова Афины, но часто это непонятная крокозябра. А все потому что эту самую голову Афины мастера, делавшие нитковдеватели в допромышленные времена, копировали с некоего предыдущего экземпляра, и после ряда итераций картинка потеряла сходство не только с Афиной, но и вообще с женской головой. И вот эта крокозябра, наряду с возрожденным оригиналом стала уже стандартом для промышленных нитковдевателей.
nuclight
12.01.2025 06:50Как он выглядит-то, с головой (и без головы-то никогда не видел и не пользовался)? Поиск гугла только этот коммент и выдает)
dkfbm
12.01.2025 06:50Вот этой претензии вообще не понял:
Конфигурации линтеров и инструментов форматирования, где из проекта в проект копируется базовый набор правил
Это естественно. В компании должны быть стандарты форматирования кода и применяемых правил статического анализа, которые от проекта вообще никак не зависят.
Да и в целом использование наработанных шаблонов - это нормальная практика, каждый раз тратить время на написание таких вещей с нуля было бы глупо.
aabzel
12.01.2025 06:50Ждём разоблачительного текста " эффект GUI -IDE".
aabzel
12.01.2025 06:50Хотя текст " эффект GUI -IDE" уже есть
Почему Сборка с Помощью GUI-IDE это Тупиковый Путь
https://habr.com/ru/articles/794206/
aabzel
12.01.2025 06:50Во зумеры какие попёрли!
А? MakeFile прочитать не способные .
Они думали , что программирование- это просто.
Шли бы лучше в курьеры. Раз азбуку освоить не в состоянии.
rukhi7
12.01.2025 06:50А? MakeFile прочитать не способные .
ну вот вам makefile, для примера:
https://github.com/LibreOffice/core/blob/master/Repository.mk
расскажете на пару абзацев что там заскриптовано, раз уж вам достаточно просто прочитать? Только учтите это только один makefile из системы makefile-лов в этом репозитории (внутри дерева каталогов) - надо рассказать про эту систему, а не про то какие переменные там определены. Если что я сам до конца еще не разобрался, вы мне можете очень сильно помочь.
Интересно сколько времени надо чтобы прочитать несколько тысяч строк скрипта?
вот еще можно почитать на досуге на 4000 строчек чтения:
https://github.com/LibreOffice/core/blob/master/RepositoryExternal.mk
Я кстати сомневаюсь что тут применим какой то термин типа makefile-эффект, потому что скопировать это чтобы переиспользовать вряд ли возможно.
mayorovp
12.01.2025 06:50Термин тут тоже применим, потому что почти наверняка "дочерние" мейкфайлы копировались внутри репозитория несколько раз.
Kahelman
12.01.2025 06:50Вы не с того конца читаете. Надо начинать с «главного» Makefile -a это импортируемый файл и напрямую его вызвать нельзя - отсутствуют цели.
Кстати написан достаточно аккуратно. И структурировано. Учитывая размер проекта и кросс платформенность вообще шедевр. Посмотрел бы я как вы такого уровня проект на новомодных YAML/json сделаете. От одних отступов/скобок в глазах будет рябить.
Drakosh
Подумалось о мутациях и отборе генетическим алгоритмом. В результате спонтанных мутаций выживают самые лучшие? Гибкие? Популярные? Примеры кода, которые потом мутируют и размножаются в другие проекты, чтобы скрещиваться с другими примерами кода. В результате остаются только некоторые "выжившие".