Да, это то, что нам нужно. Если не QUIET (см. rhead в parse.c), то буфер с собранной командой печатается. Осталось пририсовать нужный нам префикс (см. bio(2):
Твой ответ тронул мою душу, так что и я отвечу на твой запрос.
описать аналогичную процедуру, но для GNU Make в среде GNU/Linux
Буду говорить лишь про Debian GNU/Linux.
$ apt-get source make # получаем исходники
$ cd make-dfsg-3.82/ # Переходим к ним
$ ls # оглядываемся и понимаем что скорее всего нам нужен job.c
$ $EDITOR job.c
В файле ищем функцию «start*» или «run*». Находим start_job_command. Просматриваем код функции на наличие вывода сообщения. Находим комментарий
/* Print out the command. If silent, we call `message' with null so it
$ dpkg-buildpackage # собираем пакет
$ dpkg -i ../make_3.82-1_i386.deb # и устанавливаем. На этом шаге нужен root
И получаем то же самое что и у тебя.
Жаль, конечно, что в GNU не принято такие проблемы решать редактированием исходников (да и какой смысл, все равно в этом болоте ничего не найдешь).
Действительно не принято решать такие проблемы редактированием исходников, но это из-за малой пригодности пакетных менеджеров к такому поведению и всё большей ориентации на пользователей-не-кодеров. А болото, хоть и есть из-за оглядки на переносимость, но зачастую оно достаточно маленькое и быстро разбирается руками.
Откуда ты знаешь, что именно зависит от этого патча?
То есть ты хочешь сказать, что ТС нужен префикс не для более удобного просмотра глазами, а для того, чтобы потом по префиксу грепать вывод make? Тогда ТС явно что-то делает не правильно.
Даже, в общем, я могу представить, что я бы пару раз в жизни чем-то таким занялся.
Но все-таки в мелочах есть неприятности — src(1) из Plan 9 отправит меня именно к исходникам, из которых получился нынешний бинарник, а в Debian, насколько я понимаю, если через полгода я захочу выяснить, какой дебил добавил печать @ перед строчкой рецепта и сделаю apt-get source, то получу «исходный» исходный код, без моих изменений, что несколько менее удобно, но, очевидно, обходимо (наверное, можно ведь и source-пакет как-то собрать вместо со сборкой бинарного).
Безусловно, в общем, что все это можно сделать и не только в Plan 9, и, может быть, даже с известными преимуществами, но вот кажется, что небольшие изменения вроде доступного по умолчанию исходного кода позволили бы пользоваться GNU с гораздо большим комфортом. (Мой прежний тезис про сравнительную развесистость кода, впрочем, остается в силе).
В ТЗ я не обнаружил ничего похожего на требования «портабельности». Да и что в данном случае такое требование может означать? Переносимость на другую машину? На другую систему?
Если речь идет про невозможность поделиться столь важным улучшением с остальным миром, то есть ведь теперь git pull requests, которые в Plan 9 появились немного раньше и по-другому называются:
% patch/create mk-recipeprefix anonymous@lor /sys/src/cmd/mk/run.c
Make mk(1) prefix each recipe line reported with '@ ' for better visibility.
^d
Теперь любой желающий может воспользоваться плодами моего труда, сказав
Вообще очень полезно было бы составить словарик всяких идиом в разных системах, но не низкого уровня (как заменить с помощью sed(1) отсутствующий в Plan 9 head(1)), а более высокого — как выполнить ту или иную системную операцию, причем с объяснениями, что происходит.
Во-первых, польза от него будет непосредственной — особенно если там будет столбец про Debian, а то у меня просто руки опускаются всякий раз, когда нужно сделать что-то совершенно очевидное, и надо гуглить непонятно что, копипастя потом непонятные магические строчки. Естественно, можно почитать руководство, но как правило это плохое решение как по временным затратам (обычно необходимость что-то сделать не в «своей» системе возникает не в самое свободное время), так и из-за того, что оное руководство все, как правило, написано в терминологии, принятой в описываемой системе, и эти-то культурные различия как правило и есть самое неприятное.
Речь о том, что это улучшение есть только на твоей машине и работает корректно только для твоего mkfile (остальные не требовали этой принудительной фичи).
git
В 9front есть hg: http://man.aiju.de/1/hg --- А так да, с исходниками всё очень удобно сделано.
А во-вторых, конечно, это просто вызывает у меня огромный культурологический интерес — посмотреть, как всякие повседневные вещи делают люди с разными инструментами. Как правило, из такого можно извлечь много пользы и для себя, даже если с другими системами столкнуться не придется.
Речь о том, что это улучшение есть только на твоей машине
Нет, я показал, как его опубликовать (будет в каталоге патчей)
и работает корректно только для твоего mkfile (остальные не требовали этой принудительной фичи).
Так как это чисто эстетическое украшательство, то «корректность» его вовсе не определена. На других mkfile, очевидно, все будет работать точно так же, как и на моем.
Есть. Но пока основным механизмом распространения является replica, sources и, в частности, patch. Хотя я не очень слежу за 9front. Может, оно уже и обновляется через hg?
На других mkfile, очевидно, все будет работать точно так же, как и на моем.
Хотя там это совершенно и не планировалось. В этом-то и проблема. --- А главное то, что там есть terminus и dejavu, так что глазам больше не нужно кровоточить от жуткой lucida, что была раньше. И да, ссылок: http://code.google.com/p/ports2plan9/ (у них там работы по портированию Netsurf?) http://code.google.com/p/nix-os/