[docs] Re: Literate programming for Makefiles

Oleg A. Paraschenko olpa на xmlhack.ru
Вт Ноя 4 17:14:34 MSK 2003


  Привет!

On Tue, 4 Nov 2003 16:36:26 +0300
Vitaly Ostanin <vyt на vzljot.ru> wrote:

> On Tue, 4 Nov 2003 15:59:55 +0300
> "Oleg A. Paraschenko" <olpa на xmlhack.ru> wrote:
> 
> >   Привет!
> > 
> >   Идея, конечно, во всём этом есть, но я бы посоветовал
> >   отказаться от "описательного программирования" для Makefiles.
> > 
> > --
> > 
> >   При разработке ПО, кроме основного процесса, есть
> >   поддерживающие процессы (разработка ПО vs использование CVS,
> >   написание документации vs использование CMS для неё и т.д.). 
> >   Я обычно стараюсь придерживаться следующего подхода. Основная
> >   ветка должна быть вылизана, всё, что мешает -- должно быть
> >   уничтожено, кривости -- переделаны. Но любые попытки доводить
> >   до блеска поддерживающие процессы должны пресекаться.
> >   Работает -- и ладно. Такая своеобразная "бритва Оккама" для
> >   проектов.
> 
> До блеска ещё далеко, и он не самоцель. Цель litprog -
> поддерживаемость кода и док в актуальном состоянии. Это важно для
> любых процессов, в том числе и вспомогательных.
> 
> >   В данном случае, основной процесс -- это написание
> >   документации. Написание make-файлов -- поддерживающий процесс
> >   и должен быть сведён к минимуму. Описательное
> >   программирование (ОП) будет поддерживающим процессом
> >   поддерживающего процесса. А учитывая, что ОП тоже надо
> >   довести до логического завершения, то намечается
> >   поддерживающий процесс поддерживающего процесса
> >   поддерживающего процесса. Это не дело.
> 
> ОП уже работает и серьёзно меняться не будет. Да, неплохо бы
> доку по litprog, но её не будет - достаточно статей Уолша (и
> Кнута, кстати) на эту тему и простых примеров разметки.
> 
> Я специально не выкладывал litprog в cvs до получения готовых
> результатов.
> 
> Я понял аргумент про рекурсивный идеализм, но это не тот случай
> :)

  Самый что ни на есть. За то время, которое мы уже потратили на Makefiles, можно было написать k док и сделать m скриншотов, а также улучшить passivetex.

> 
> > --
> > 
> > Какая документация нужна на make? Думаю, примерно такая:
> > 
> > * для технического писателя (того, кто будет всё это
> > использовать);* для разработчика make-файлов, высокоуровневая
> > -- понять, что к чему;* для разработчика make-файлов,
> > низкоуровневая -- детали.
> > 
> > Вытаскивание Makefile, хотя бы и с комментариями, не является
> > ни одним из этих типов.
> 
> Не понял.

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

> 
> > --
> > 
> > Предположим, что некто хочет добавить что-то в Makefile, но не
> > хочет разбираться в сущностях (literate programming). Сможет ли
> > он сделать это? Может быть и да, но я бы забил.
> 
> Сможет, добавив это что-то в Makefile и прислав в рассылку
> уведомление об этом. Если два тега нашего litprog - <alt:doc/> и
> <alt:code/> - требуют осознания ;), я добавлю описание в
> Makefile.litprog самостоятельно.
> 
> Кстати, подразумевается, что автор Makefile для DocBook имеет
> представление о DocBook хотя бы в пределах <para/>.

  Вот это как раз хуже всего. Потому что незнакомый с DocBook человек будет писать <para/> и не мучиться, а знакомый -- начнёт задумываться, а есть ли <alt:make-target/>, <alt:make-variable/> и т.д, а кому-то это захочется сделать.

> 
> > --
> > 
> > А как настроить подстветку синтаксиса в моём любимом vim?
> 
> Научить :) Я ничего не знаю про vim - в emacs я переключаю режимы
> редактирования - makefile-mode/nxml-mode.

  Что переключать можно, это понятно. Интересует одновременная подсветка. Как когда php в html -- рассвечивается и то, и другое.

> 
> Кстати, прототипы я делал так: писал Makefile, отлаживал, и
> переносил в Makefile.litprog с описанием.

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

> 
> > --
> > 
> > Тем не менее, идея правильная. Более того, у меня есть
> > комментарии, которые я бы не прочь вставить как в сам
> > make-файл, так и в документацию. Но, может быть, проще? В стиле
> > javadoc?
> 
> Есть разные подходы в litprog (насколько я неправильно понял :)):
> 
> 1.
> Прямое использование источника litprog в качестве кода (javadoc).
> 
> 2.
> Прямое использование источника litprog в качестве док (DocBook
> TDG).
> 
> 3. 
> Предварительная обработка источника litprog и для кода, и для док
> (то, что сейчас в ветке "make2" cvs docs).
> 
> Есть ещё вариант прямого использования litprog сразу и для док, и
> для кода, но он годится только для XML-языков, из которых пока
> есть только XSLT. И этот вариант не позволяет варьировать видом
> документации, например, вставлять код в виде листингов.
> 
> Так вот, javadoc (TeX, LaTeX, html и т.п.) в качестве исходного
> формата для разметки документации я обсуждать не буду.

  А зря. В данном случае наворачивать не стоит.

> 
> А вот 1. был бы удобен, но не представляю его на практике.
> 
> > ...
> > # non-doc comment
> > ## <para>... comment for docs ...</para>
> 
> А как отсюда выдирать теги?

Примерно так (не проверил):

echo '<makedoc>'
cat Makefile | grep '^##' | sed '/s/^## /'
echo '</makedoc>'

> 
> PS Прошу остальных участников docs@ тоже высказываться. Мы с
> Олегом уже и лично общались :)
> 
> <skipped/>
> 
> -- 
> Regards, Vyt
> mailto:  vyt на vzljot.ru
> JID:     vyt на vzljot.ru


-- 
Олег



Подробная информация о списке рассылки docs