Dmitry E. Oboukhov - debian-russian@lists.debian.org @ Wed, 1 Oct 2008
18:44:55 +0400:
VW понимаешь в чем дело, в том что если бы make догадывалось об этом то ей
VW пришлось бы перестать быть универсальным инструментом (вон выше по ветке
VW собирают PDF например, а какой там DEBUG) и стала
Dmitry E. Oboukhov - debian-russian@lists.debian.org @ Thu, 2 Oct 2008
11:10:51 +0400:
AC Примерно с той же, блин, целью сделан и configure. Непонятно
AC только, нафига он генерирует развесистый мейкфайл вместо тупого
AC sh-скрипта - все равно в половине случаев от того make там один
AC
Dmitry E. Oboukhov - debian-russian@lists.debian.org @ Thu, 2 Oct 2008
12:11:21 +0400:
AC понимаешь в чем дело, в том что если бы make догадывалось об этом то ей
AC пришлось бы перестать быть универсальным инструментом (вон выше по
ветке
AC собирают PDF например, а какой там DEBUG) и стала
Dmitry E. Oboukhov - debian-russian@lists.debian.org @ Thu, 2 Oct 2008
12:53:16 +0400:
AC Там правка правке рознь. Добавил #include - уже вынь да положь configure.
DEO смотря какой include :)
DEO если на себя же (свой проект) то да :)
Ну, этого уже достаточно. Т.е. какие именно операции
Dmitry E. Oboukhov - debian-russian@lists.debian.org @ Thu, 2 Oct 2008
17:15:32 +0400:
AC DEBUG ?= 0 # кстати не помню ?= это GNUmake или вообще make? хез
AC ...
AC debug_depends:
AC test -e $@ || echo $(DEBUG) $@
AC test `cat [EMAIL PROTECTED] = $(DEBUG) || echo $(DEBUG) $@
Dmitry E. Oboukhov - debian-russian@lists.debian.org @ Thu, 2 Oct 2008
18:10:28 +0400:
AC Ну, это лучше, да. Причем мне, честно говоря, сходу даже было
AC непонятно, почему работает первое решение... Пришлось гонять make -d и
AC разбираться.
AC А теперь вот так вот для каждой
Dmitry E. Oboukhov - debian-russian@lists.debian.org @ Tue, 30 Sep 2008
21:41:30 +0400:
Отпуск конечно оправдывает нежелание читать
документацию, но не до такой же степени...
Цитата:
http://localhost/doc/make-doc/make_5.html#SEC67
Recursive use of make means using make as a command
Dmitry E. Oboukhov - debian-russian@lists.debian.org @ Tue, 30 Sep 2008
20:16:13 +0400:
AC PS: недавно вот sim'овский debian/rules перекроили выкинули
AC рекурсию, получился изящщненький такой rules на полтора экрана
AC размером, а был экранов на 7-8 да еще и с рекурсией продраться
AC
Dmitry E. Oboukhov - debian-russian@lists.debian.org @ Wed, 1 Oct 2008
12:24:24 +0400:
AC make, напомню, в отличие от gcc, вызывают не только чтобы собрать цель,
AC но и чтобы _пере_собрать ее.
DEO gcc вызывают не только для того чтобы собрать .o, но и пересобрать .o
DEO нет отличий
gcc
Dmitry E. Oboukhov - debian-russian@lists.debian.org @ Wed, 1 Oct 2008
15:59:50 +0400:
AC make, напомню, в отличие от gcc, вызывают не только чтобы собрать цель,
AC но и чтобы _пере_собрать ее.
AC gcc вызывают не только для того чтобы собрать .o, но и пересобрать .o
AC нет отличий
AC gcc
AC make как раз усложняет сборку по сравнению с тупым шелловским скриптом.
AC Но удешевляет ее за счет этого.
Шелловский скрипт unconditional сборки проекта проще соответствующего
мейкфайла.
Нет. Смотри ниже.
Потому что надо описать только команды сборки, а на
зависимости можно забить.
В
У make, впрочем, есть и еще одна проблема. Она уже не имеет отношения к
рекурсивному вызову, но ноги ее растут примерно из той же весьма куцей
модели зависимостей, которую он реализует.
Несмотря на то, что абзацу объяснения было отведено аж 6 неполных строк,
я так и не понял, о чём
Dmitry E. Oboukhov - debian-russian@lists.debian.org @ Wed, 1 Oct 2008
16:35:22 +0400:
AC gcc вызывают для того, чтобы сделать новый .o _вместо_ старого. Он про
AC старый вообще не думает, он его молча затирает. make - думает.
AC и что с того что думает? мы что будем различия строить на
Eugene V. Lyubimkin - debian-russian@lists.debian.org @ Wed, 01 Oct 2008
15:45:33 +0300:
У make, впрочем, есть и еще одна проблема. Она уже не имеет отношения к
рекурсивному вызову, но ноги ее растут примерно из той же весьма куцей
модели зависимостей, которую он реализует. Ее тоже
Aleksey Cheusov - debian-russian@lists.debian.org @ Wed, 01 Oct 2008 15:57:49
+0300:
AC make как раз усложняет сборку по сравнению с тупым шелловским скриптом.
AC Но удешевляет ее за счет этого.
Шелловский скрипт unconditional сборки проекта проще соответствующего
мейкфайла.
AC Нет.
AC Вывод: _правильный_ make - на порядок проще unconditional shell скрипта.
Там, где не нужно писать - нужно include тот файл, где это уже
написано. Ты приводил пример, собственно. Так вот. Ты должен быть
в курсе, что sh тоже так умеет...
Ах так. Ну хорошо. Тогда такой вывод:
правильный
http://www.gnu.org/software/make/manual/make.html#Automatic-Prerequisites
Это костыль. Исходная проблема в том, что зависимости в make-ах
строятся только на уровне файлов, без анализа содержимого этих файлов
и учета семантики этого самого содержимого.
То есть исходный make -
Dmitry E. Oboukhov - debian-russian@lists.debian.org @ Wed, 1 Oct 2008
18:17:20 +0400:
AC Блин. Ты хочешь доказать мне, что можно придумать пример, где
AC рекурсивный вызов make не составляет проблем? Не вопрос, я и сам могу.
AC Вопрос в том, что в типичном случае проблемы будут. А в
Boris Popov - Russian Debian List @ Tue, 30 Sep 2008 16:03:38 +0400:
BP Чем плох рекурсивный make?
Тебя на гугле забанили? Ключевая фраза для поиска в рассылке появлялась
неоднократно.
--
Artem Chuprina
RFC2822: ran{}ran.pp.ru Jabber: [EMAIL PROTECTED]
Психология - это наука о плохих
30 сентября 2008 г. 16:08 пользователь Artem Chuprina [EMAIL PROTECTED]
написал:
Boris Popov - Russian Debian List @ Tue, 30 Sep 2008 16:03:38 +0400:
BP Чем плох рекурсивный make?
Тебя на гугле забанили? Ключевая фраза для поиска в рассылке появлялась
неоднократно.
В двух словах
Добрый день!
Чем плох рекурсивный make?
С уважением,
--
Boris Popov
Boris Popov - debian-russian@lists.debian.org @ Tue, 30 Sep 2008 16:15:03
+0400:
BP Чем плох рекурсивный make?
Тебя на гугле забанили? Ключевая фраза для поиска в рассылке появлялась
неоднократно.
BP В двух словах, пожалуйста?
Теряется информация.
--
Artem Chuprina
RFC2822: ran
Dmitry E. Oboukhov - debian-russian@lists.debian.org @ Tue, 30 Sep 2008
16:10:22 +0400:
DEO PS: недавно вот sim'овский debian/rules перекроили выкинули
DEO рекурсию, получился изящщненький такой rules на полтора экрана
DEO размером, а был экранов на 7-8 да еще и с рекурсией продраться
DEO
Dmitry E. Oboukhov - debian-russian@lists.debian.org @ Tue, 30 Sep 2008
16:44:27 +0400:
BP Тебя на гугле забанили? Ключевая фраза для поиска в рассылке появлялась
BP неоднократно.
BP В двух словах, пожалуйста?
DEO он не может, он специалист по безопасности а им не пристало
Поздравляю
Dmitry E. Oboukhov - debian-russian@lists.debian.org @ Tue, 30 Sep 2008
16:50:39 +0400:
AC PS: недавно вот sim'овский debian/rules перекроили выкинули
AC рекурсию, получился изящщненький такой rules на полтора экрана
AC размером, а был экранов на 7-8 да еще и с рекурсией продраться
AC
Dmitry E. Oboukhov [EMAIL PROTECTED] wrote:
BP В двух словах, пожалуйста?
он не может, он специалист по безопасности а им не пристало
Собственно что не пристало?
--
Only one 0_o
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
и везде где я встречал рекурсию в Make - от выбрасывания ее становилось
только лаконичнее.
Посмотри, как делают ненавистные тобой бздюки.
ОЧЕНЬ лаконично и очень красиво IMHO.
MK скрипты натурально рулят. Как подход по крайней мере точно.
--
Best regards, Aleksey Cheusov.
--
To
On Tue, 30 Sep 2008, Dmitry E. Oboukhov wrote:
AC Это - рекурсивный вызов makefile. А речь идет про рекурсивный вызов make.
гы, берем например /usr/bin там скриптов наверное треть
куча из них перевызввает друг друга (например docbook2html пока дойдешь
до ELF'а поседеешь :))
и что их кто-то
On Tue, 30 Sep 2008, Dmitry E. Oboukhov wrote:
в таком разрезе shell на порядок более рекурсивный
ибо любой пайп - рекурсия, любой инклюд - рекурсия итп
Возможно, но только с точки зрения системы, а внутри
интерпретатора рекурсия нечто иное. Кстати с точки
зрения системы второе
29 matches
Mail list logo
