### Прошу оценить черновой вариант черновика текста про Make.
### Вкратце о том что за текст: текст пишется для манги (хотя его очень
### много и будет скорее текст с иллюстрациями), что бы потом
### опубликоваться в местном журнале.
### ВНИМАНИЕ, я в системах сборок не совем хорошо разбираюсь (лучше даже
### сказать "совсем не хорошо"), однако от этого интереснее писать
### сюжет. Из заметных проблем невооружённом глазом:
### 1. Грамматика и лексика. Не самое интересное
### 2. Слишком много говорит только Катя
### 3. Ошибки в терминах. Вот тут действительно нужна помощь, причём
### серьёзная))
Катя := самый прошаренный программист в отделе
Маша := стажёр, мало что умеет
Время суток := 22:49
TODO
Написать про компилируемые языки
Написать про декларативность
СТРАНИЦА 1. Проблема.
Маша: =почти рыдая= да как же настроить этот systemd то, боже, какая
ерунда от красношапки.
Катя: =заглядывая в кабинет и махая рукой на прощание= Давай, салага, до
встречи.
Катя: =ухмыляясь= Падажжи, я знаю это выражение лица... Думаешь в
полночь точно-точно соберёшь?
Маша: =в растерянности= Н-ну, пару раз выходило, хха-хаха.
Катя: =с озорной улыбкой= О разработке с использованием *cборочных
систем*, я полагаю, тебе толком ничего не известно. Так?
Маша: =с покорным видом= Н-ничего, госпожа. Внемлю вашим словам.
СТРАНИЦА 2. Объяснение ручного развёртывания.
Катя: =размахивая руками перед схемой ОС + в очках (может быть нет)=
Смари, это плюс-минус то, где происходят основные баталии при
развёрстке -- системное окружение. Ты, как я могу судить,
используешь доисторическую модель развёртывания: просто руками
пишешь те же команды в консоль, что и писала у себя, когда
собирала проект. *Это не плохо*. Ты учишься, и понимать что-там
твроится "под капотом" очень важно. Ну и, как я часто повторяю,
использовать технологии необходимо из потребностей. Иногда
достаточно в `README` описать вкратце что почем и усё.
Катя: Что бы понять *возможные* проблемы такого подхода, давай разберём
конкретные примеры.
СТРАНИЦА 3. Случай
Катя: Итак, представь, что тебе нужно сделать скворечник (ну или
кормушку для белочек). Как бы ты их делала? Изначально ты имеешь
лишь материалы и инструменты. Черкани на листочке самые важные
моменты.
Маша: =секунд десять смотрит в потолок, а потом начинает писать=
Как-то так:
1. Сделать из фанеры открытую коробку
2. Спилить края
3. Приколотить на это место крышку
4. Вырезать дупло
5. Прибить длинную палку к задней части
Катя: Отлично, теперь опиши как бы ты готовила омлет. Предположим, что
все приборы и ингредиенты уже перед тобой.
Маша: Эээ!? Н-ну.. =сразу начала писать=
Ну, в самом простом случае.
1. Поставила бы плитку разогреваться
2. На неё положила бы сковородку
3. На сковородку налила бы масла
4. Пока оно там всё нагревается, разбила бы яйца в миску и
размешала бы их с молоком
5. Посолила бы содержимое
6. После того как сковородка разогрелась, вылила размешанное
содержимое миски туда
7. Осталось бы только перевернуть где-то через минуты 2-3
8. После этого через минуты 3 уже можно кушать
Катя: =стрелка на Катю "не умеет готовить"= Обычно как-то проще
выходит. Но не важно. Важно то, что связывает описанные тобой
последовательности действий, нацеленные на конкретный результат. С
твоего позволения я озвучу закономерности:
1. Перед тем как начать что-то делать, *необходимо убедиться* в том, что
всё необходимое есть. Иначе придётся прервать выполнение алгоритма,
что бы вернуться к нему только тогда, когда необходимое сырье или
инструмент будут на месте.
2. Любую деятельность можно свести к определённой *последовательности
действий* по-проще. Постройка скворечника это манипулирование пилой
и фанерой. Изготовление омлета: орудование яйцами и сковородкой.
3. Шаги *связаны* между собой. То, что является результатом одного шага,
являетя исходным пунктом другого шага. Приколотить крышу к
скворечнику не получится пока не обрежешь края, ровно как и вкусно
не приготовишь ничего если налить масло только в самом конце.
Маша: Р-разумно.
Катя: Ещё как разумно, дорогуша! Помимо всего прочего, сковородку
нужно мыть, а оплики после работы с деревом подметать. А ещё...
омлет надо собственно скушать, а в скоречник насыпать семок и
приколотить к дереву. Это я не просила оговаривать, так что просто
имей ввиду.
СТРАНИЦА 4. Configure
Катя: Как правило информация о том, какие нужны ингредиенты и как (и
чем) их нужно обрабатывать, находится в сборнице рецептов, а если
говорим про скворечник, то про него вся информация тоже находится
в каком-то справочнике. Но как быть если мы хотим, что бы человек
у себя собрал необходимую программу, "приготовил" её?
Катя: Перед тем, как перейти к переносу концпепции кулинарных рецептов
в мир разработки программ, следует оговорить то, чем отличается
любое руководство (ладно, не любое, но большинство) из реальной
жизни от описания сборки программы из исходных текстов.
Катя: Во-первых, в поваренных книгах не упоминается как достать нужные
ингредиенты. К примеру, что бы получить перед собой яйца для
омлета ты можешь купить их в магазине или взять у кур (если ты
счастливая обладательница курятника). Что бы получить доски и
инструменты ты можешь, следуя похожей логике, как купить их, так и
вытащить со склада. Или вообще одолжить. Такие вещи находятся вне
~юрисдикции~ справочной информации, однако имеют важное значение при
сборке программы. И именно для этого существует скрипт ./configure
в корне проекта, запуск которого способен подготавливать исходные
файлы программы для запуска на конкретной системе, которая может в
значительной степени отличаться от той, в которой изначально
разрабатывалась программа.
Катя: Всё сказанное может звучать несколько абстрактно, если нос не
высовывать за пределы той системы, в которой пишешь программу,
однако в дикой природе существует великое множество подходов для
того, что ты привыкла делать определённым способом. Думаю, ты уже
поняла это, когда отключала SELinux и искала что там нужно
прописать, что бы найти в центоси именно то, что без всяких
манипуляций лежит в репозитории дебьяна? Хахахаха! Ну да ладно,
чуть позже опять вернёмся к отличиям.
СТРАНИЦА Х. Makefile на практике
Катя: Давай же взглянем на сердце мейк файла, на *make build*. В первую
очередь хочется отметить, что make файл состоит из *целей* (target),
которые ты хочешь достичь. Типичная цель выглядит как-то так:
#+begin_example
# ЦЕЛЬ : СРЕДСТВА
<Что получим в итоге>: <Какая-нибудь цель> <А может быть файл>
# ЧТО ДЕЛАТЬ ЧТО БЫ ИЗ СРЕДСТВ ДОСТИЧЬ ЦЕЛИ
<команда #1>
...
<команда #n>
#+end_example
Катя: Вместо миллиона объяснений, просто посмотри на мэйкфайл для
приготовки омлета:
#+begin_example
build: жижа-из-яиц-с-молоком разогретая-сковородка-с-маслом
вылить жижа-из-яиц-с-молоком на разогретая-сковородка-с-маслом
посолить
ждать 3 минуты
перевернуть
ждать 2 минуты
положить омлет на тарелку
жижа-из-яиц-с-молоком:
вывалить содержимое 4-х яиц в тарелочку
налить в тарелку молока
размешать содержимое тарелки
разогретая-сковородка-с-маслом:
налить масла на сковородку
разогреть сковородку
clean:
помыть сковородку
помыть тарелку
убрать ингридиенты обратно
install:
достать вилку
скушать омлет
#+end_example
Катя: Заметь, что полученный вариант оказался намного более
*декларативным*. Декларативность это замечательное свойство
большинства качественных систем конфигурации описывать тектом то,
каково должно быть состояние системы после выполнения самой этой
конфигурации. По мере твоего профессионального роста ты не раз
убедишься, что работать с декларатиными системами куда проще. Быть
можешь, когда-нибудь у меня будет время рассказать тебе про GNU
Guix. Ну а так, помимо конфигураций, декларативное описание так же
используется для запросов к базе данных. В противовес
декларативному существует *императивных подход*, который ты
продемонстрировала на примере списка действий на листочке. Пока
можешь думать о декларативном подходе как о начальнике, который
просит отчёт к обеду, и о императивном подходе как о своей любимой
госпоже, которая за обед в столовой покажет как его быстро
накопипастить так, что этот козёл ничего не заметил.
Катя: Так же у систем сборки есть ещё один плюс, который в современном
мире, к счастью или к сожалению вопрос довольно спорный, чаще
ставит новичков в тупик. А именно -- пропуск некоторых таргетов,
если make решил, что они уже сделаны и переделывать их не
надо. Обычно данная фишка относится к компилируемым языкам, где
каждый модуль может собираться часами или где важна
последовательность сборки модулей, но... это вроде настолько
древняя проблема, что скорее всего ты сможешь встретиться с ней
только в старых проектах на Си.
Катя: Ну и, возвращаясь к теме про отличия с рецептами, напоследок
хочу отметить, что рецепт пирога не говорит как его тебе класть в
рот и как именно протирать стол после готовки, а вот в make-файле
это всё лучше описать. Процесс поедания, как ты уже успела понять,
это "установка" (*make install*), а "очистка" (*make clean*) это... ну
и так понятно. В цели "установка" нужно, как правило, поместить
все необходимые файлы в корень системы, а очистка нужна что бы
удалить временные файлы, созданные во время сборки. Ничего
сверхестественного.
СТРАНИЦА 6. BASH
Маша: Звучит так, как будто кто-то решил переизобрести Bash. Я конечно
в нём не прямо мастер, но, по-момему, ничего не мешает просто то
же самое написать в скрипте.
Катя: Да, так и делают новчики, уставшие вводить все команды ручками
и, в целом, если они это делают на переносимом языке, таком как
bash, всё хорошо, однако они не могут представить себе сколько
мелочей им нужно учесть при написании такого скрипта, который бы
по фишкам мог соперничать с авто-сгенерированным make
файлом. Кроме того, bash хоть и есть на каждой кофеварке,
создавался не совсем для этого. Make это уже стандарт в своей
нише. Любой опытный разработчик ожидает увидеть в корне проекта,
помимо README и LICENSE, файл Makefile.
СТРАНИЦА 7. Сборочная система GNU
Катя: Вот так вот, тихо и незаметно, мы очень широкими мазками описали
систему сборки GNU. Давай подытожим, шоле: Если мы хотим собрать
программу, которую прежде мы получили в какой-то директории, нам
нужно:
1. *Приспособить* исходных текст программы под свою систему через
запуск скрипта ./configure в корне проекта.
2. *Собрать* программу в этой директории через make build.
3. *Установить* программу в систему, что бы она была дотупна не только
из директории, где была собрана, через make install
Катя: Make представляет собой удобную абстракцию, понятную многим
разработчикам и не только тем, кто пишет код! При помощи make
собирают всё что угодно и автоматизируют свою повседневные заботы,
помимо сборки проектов, огромное количество людей, хотя, к
сожалению, некоторые make'a боятся. Плюс ко всему некоторые
проекты и вовсе его не используют, а предпочитают свои средства,
как, например, целый зоопарк решений для nodejs, так что
количество людей, понимающих как собираются по-настоящеу крупные
проекты, всё меньше меньше. (автор один из них, тока вы никому)
Страница последняя. Le Finale
Маша: =Глядит вопросительно= Н-ну и что мне с этим всем делать...?
Катя: =уходя= *info make && *info autoconf*, then
# Спасибо за внимание!