subject:"Re\: Чем плох рекурсивный make\?"

Dmitry E. Oboukhov - debian-russian@lists.debian.org @ Wed, 1 Oct 2008
18:44:55 +0400:

VW понимаешь в чем дело, в том что если бы make догадывалось об этом то ей
VW пришлось бы перестать быть универсальным инструментом (вон выше по ветке
VW собирают PDF например, а какой там DEBUG) и стала бы
VW узкоспециализированным. а это неправильно.

VW Дебуга там нет, но вообще-то pdftex-у в командную строку тоже много чего
VW интересного запихать можно. Во всяких bras и makepp эта задача решена
VW посредством запоминания того, какой именно командой данный target
VW пересобирался последний раз. И если текущая команда получается другая,
VW target считается устаревшим.
DEO ну так я говорю, значит просто надо DEBUG поставить в зависимости
DEO и далее проблема станет решенной

Надо _сложно_ поставить в зависимости DEBUG. Иначе оно будет
пересобирать всё каждый раз. Подозреваю, что сделать это можно, но
вплотную еще не думал. Есть шанс, что и не получится.

--
Artem Chuprina
RFC2822: ran{}ran.pp.ru Jabber: [EMAIL PROTECTED]

А вы поподробнее, поподробнее. А заодно и быстрее будет...

--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Чем плох рекурсивный make?

Dmitry E. Oboukhov - debian-russian@lists.debian.org @ Thu, 2 Oct 2008
11:10:51 +0400:

AC Примерно с той же, блин, целью сделан и configure. Непонятно
AC только, нафига он генерирует развесистый мейкфайл вместо тупого
AC sh-скрипта - все равно в половине случаев от того make там один
AC вред.
DEO не почему, configure перезапускаем только когда меняется что-то в
DEO количестве исходников скажем итп а сама отладка работает на make

DEO то есть поправил файл - make, поправил - make, добавил - configure -
DEO make
DEO итп

Там правка правке рознь. Добавил #include - уже вынь да положь configure.

AC На самом деле, естественно, не такая и задумана, а проще забить, чем
AC вылечить.
DEO лечение предполагает либо экстракт депендсов из авторского makefile,
DEO либо дубликат их во внешнем, либо правку авторского.

DEO первый пункт в каком-то *make удобно реализован? только так чтобы сборка
DEO не становилась узкоспециализированной

Насколько я знаю, задача добычи зависимостей из makefile как минимум
весьма сложна. Подозреваю, что неразрешима.

AC Что для данного применения плохо, но приемлемо. Для целей
AC разработки же - скорее неприемлемо.
DEO для целей разработки есть авторский makefile :)

Я и есть автор. Переделанная цитата из известного анекдота.

DEO то есть если ты вызываешь внешний make, то это надо рассматривать как 1
DEO единичное действие.
DEO а если ты хочешь чтобы часть действий одного была и в другом это уже
DEO получается ты хочешь 1 make использовать как библиотеку к другому

DEO тут конечно получаются костыли и подпорки... что делать?

Менять make на альтернативу, в которой при дизайне это учтено.

--
Artem Chuprina
RFC2822: ran{}ran.pp.ru Jabber: [EMAIL PROTECTED]

--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Чем плох рекурсивный make?

Dmitry E. Oboukhov - debian-russian@lists.debian.org @ Thu, 2 Oct 2008
12:11:21 +0400:

AC понимаешь в чем дело, в том что если бы make догадывалось об этом то ей
AC пришлось бы перестать быть универсальным инструментом (вон выше по
ветке
AC собирают PDF например, а какой там DEBUG) и стала бы
AC узкоспециализированным. а это неправильно.

AC Дебуга там нет, но вообще-то pdftex-у в командную строку тоже много чего
AC интересного запихать можно. Во всяких bras и makepp эта задача решена
AC посредством запоминания того, какой именно командой данный target
AC пересобирался последний раз. И если текущая команда получается другая,
AC target считается устаревшим.
AC ну так я говорю, значит просто надо DEBUG поставить в зависимости
AC и далее проблема станет решенной

AC Надо _сложно_ поставить в зависимости DEBUG. Иначе оно будет
AC пересобирать всё каждый раз. Подозреваю, что сделать это можно, но
AC вплотную еще не думал. Есть шанс, что и не получится.

DEO а мое решение сложно?

А это не решение.

DEO то есть пишем в Makefile

DEO DEBUG ?= 0 # кстати не помню ?= это GNUmake или вообще make? хез

DEO ...

DEO debug_depends:
DEO test -e $@ || echo $(DEBUG) $@
DEO test `cat [EMAIL PROTECTED] = $(DEBUG) || echo $(DEBUG) $@

DEO и дальше ставим зависимость от debug_depends

DEO то есть получится что make его перезаписывать будет только при смене
DEO переменных

DEO и соответственно в зависимости:

DEO %.o: %.c debug_depends

Начнем с того, что make его вообще перезаписывать не будет. Он его
запишет один раз, и все.

Ты б хоть проверил свое решение, прежде чем предлагать. Ладно б
требовалось подобрать к нему хитрую последовательность команд, чтобы
увидеть, что не работает, а то ведь тупее некуда - make да make
DEBUG=1...

--
Artem Chuprina
RFC2822: ran{}ran.pp.ru Jabber: [EMAIL PROTECTED]

The effort of using machines to mimic the human mind has always struck
me as rather silly. I would rather use them to mimic something better
-- Edsger Dijkstra

--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Чем плох рекурсивный make?

Dmitry E. Oboukhov - debian-russian@lists.debian.org @ Thu, 2 Oct 2008
12:53:16 +0400:

AC Там правка правке рознь. Добавил #include - уже вынь да положь configure.
DEO смотря какой include :)

DEO если на себя же (свой проект) то да :)

Ну, этого уже достаточно. Т.е. какие именно операции редактирования
могут обойтись без configure, а какие нет - определяется уже совсем не
так просто...

DEO а если на тот что в /usr лежит, то запуск configure можно в долгий
DEO ящик откладывать :)

Если на тот, что в /usr, то надо, вообще говоря, немедленно править
configure.in, а не просто запускать configure...

AC первый пункт в каком-то *make удобно реализован? только так чтобы сборка
AC не становилась узкоспециализированной

AC Насколько я знаю, задача добычи зависимостей из makefile как минимум
AC весьма сложна. Подозреваю, что неразрешима.
DEO подозреваю что разрешима
DEO поскольку make эти зависимости строит, то есть можно ее допатчить чтобы
DEO она их выводила в удобоваримом виде (она и сейчас умеет их вывести, но
DEO рекурсивные ревызовы сейчас она не умеет)

Скажем так, для этого придется провести сборку. На самом деле, да. dry
run выдает ненадежный результат.

AC Что для данного применения плохо, но приемлемо. Для целей
AC разработки же - скорее неприемлемо.
AC для целей разработки есть авторский makefile :)

AC Я и есть автор. Переделанная цитата из известного анекдота.
DEO когда ты автор сделать depends.mk тебе труда не составит

В нетривиальном случае - еще как составит. Реально, да. Но труда много.

--
Artem Chuprina
RFC2822: ran{}ran.pp.ru Jabber: [EMAIL PROTECTED]

Вот .NET и Mono - это современные технологии. В смысле - сырые и глюкавые.
Victor Wagner в [EMAIL PROTECTED]

--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Чем плох рекурсивный make?

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)  $@

 AC и дальше ставим зависимость от debug_depends

 AC то есть получится что make его перезаписывать будет только при смене
 AC переменных

 AC и соответственно в зависимости:

 AC %.o: %.c debug_depends

 AC Начнем с того, что make его вообще перезаписывать не будет.  Он его
 AC запишет один раз, и все.

 DEO а ну да и правда, надо это в shell выносить, либо в цель .PHONY, которая
 DEO всегда будет выполняться:

 DEO DEBUG ?= 0

 DEO DEBUG_FILE  = tmp/debug

 DEO SRC = test.pl
 DEO TARGET  = tmp/$(SRC)


 DEO all: debug_dep $(TARGET)
 DEO $(DEBUG_FILE): debug_dep

 DEO $(TARGET): $(DEBUG_FILE) $(SRC)
 DEO cat $(SRC)  $(TARGET)

 DEO debug_dep: 
 DEO @test -e $(DEBUG_FILE) || echo $(DEBUG)  $(DEBUG_FILE)
 DEO @test `cat $(DEBUG_FILE)` = $(DEBUG) || echo $(DEBUG)  
$(DEBUG_FILE)


 DEO .PHONY: debug_dep

 DEO и работает:

 DEO apache:[~]$ make DEBUG=0
 DEO apache:[~]$ make DEBUG=0
 DEO apache:[~]$ make DEBUG=1
 DEO cat test.pl  tmp/test.pl
 DEO apache:[~]$ make DEBUG=1
 DEO apache:[~]$ make DEBUG=0
 DEO cat test.pl  tmp/test.pl
 DEO apache:[~]$ make DEBUG=0


 DEO правда не пишет про то что цель не требует выполнения команд, 
 DEO потому что реально команды выполняет.

 DEO если хочется совсем уж короткой работы то так:

 DEO DEBUG ?= 0

 DEO DEBUG_FILE  = tmp/debug

 DEO SRC = test.pl
 DEO TARGET  = tmp/$(SRC)


 DEO $(shell \
 DEO test -e $(DEBUG_FILE) || echo $(DEBUG)  $(DEBUG_FILE); \
 DEO test `cat $(DEBUG_FILE)` = $(DEBUG) || echo $(DEBUG)  
$(DEBUG_FILE) \
 DEO );

 DEO all: $(TARGET)

 DEO $(TARGET): $(DEBUG_FILE) $(SRC)
 DEO cat $(SRC)  $(TARGET)


 DEO и работа:

 DEO apache:[~]$ make DEBUG=1
 DEO make: Цель `all' не требует выполнения команд.
 DEO apache:[~]$ make DEBUG=1
 DEO make: Цель `all' не требует выполнения команд.
 DEO apache:[~]$ make DEBUG=0
 DEO cat test.pl  tmp/test.pl
 DEO apache:[~]$ make DEBUG=0
 DEO make: Цель `all' не требует выполнения команд.
 DEO apache:[~]$ make DEBUG=0
 DEO make: Цель `all' не требует выполнения команд.
 DEO apache:[~]$ make DEBUG=1
 DEO cat test.pl  tmp/test.pl
 DEO apache:[~]$ make DEBUG=1
 DEO make: Цель `all' не требует выполнения команд.
 DEO apache:[~]$ make DEBUG=1
 DEO make: Цель `all' не требует выполнения команд.

 AC Ты б хоть проверил свое решение, прежде чем предлагать.
 DEO да, я собственно шеллскрипт (идею) предлагал, а так сорри
 DEO  действительно не проверил :(
 DEO а так вот в вышеприведенном именно этот скрипт и работает :)

Ну, это лучше, да.  Причем мне, честно говоря, сходу даже было
непонятно, почему работает первое решение...  Пришлось гонять make -d и
разбираться.

А теперь вот так вот для каждой переменной, которую можно указать
мейкфайлу, и у каждой цели, на сборку которой эта переменная влияет...
И пару раз ошибиться...

Нет, все-таки такие вещи должен отслеживать сам инструмент...

-- 
Artem Chuprina
RFC2822: ran{}ran.pp.ru Jabber: [EMAIL PROTECTED]

Как в notepad тексты редактировать? Руками каждую букву набирать, что ли?
(c)vitus


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Чем плох рекурсивный make?

Dmitry E. Oboukhov - debian-russian@lists.debian.org @ Thu, 2 Oct 2008
18:10:28 +0400:

AC Ну, это лучше, да. Причем мне, честно говоря, сходу даже было
AC непонятно, почему работает первое решение... Пришлось гонять make -d и
AC разбираться.

AC А теперь вот так вот для каждой переменной, которую можно указать
AC мейкфайлу, и у каждой цели, на сборку которой эта переменная влияет...
AC И пару раз ошибиться...

AC Нет, все-таки такие вещи должен отслеживать сам инструмент...

DEO если учесть что данная задача как правило редкая (обычно debug
DEO включается в чем-то вроде configure),

У админа или мейнтейнера пакета. Разработчику оно надо гораздо чаще.

И нет там никакого configure.

Кроме того, там отнюдь не только debug. Там еще и текущая платформа до
кучи (ага, автор makepp в курсе, что бывает такая схема разработки и
тестирования...)

DEO то если сам инструмент будет пересобирать проект в зависимости от
DEO смены переменных, то он рискует начать пересобирать его от простой
DEO правки makefile в местах независящих от каких-либо переменных. я
DEO не знаю как он должен работать чтобы 1. услужливость не переходила
DEO в навязчивость с которой придется бороться 2. без внешних файлов в
DEO которых хранить состояние предыдущей сборки

Условие без внешних файлов не ставится. Пусть с внешними, если ему
так удобно. makepp вон удобно. Хочется без геморроя и провокации
ошибок разработчика.

--
Artem Chuprina
RFC2822: ran{}ran.pp.ru Jabber: [EMAIL PROTECTED]

Кто первый встал, того и грабли
Д. Белявский

--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Чем плох рекурсивный make?

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 in a makefile.

  То есть это соглашение. Можно конечно догадываться почему
  оно такое, но скорее всего просто по привычке.

 DEO в таком разрезе shell на порядок более рекурсивный
 DEO ибо любой пайп - рекурсия, любой инклюд - рекурсия итп

 DEO в общем от рекурсии тут только одно название

Рекурсия - это одно из базовых понятий CS.  Она везде.  Но понимаешь, от
того, что она везде, она не перестает быть рекурсией...

-- 
Artem Chuprina
RFC2822: ran{}ran.pp.ru Jabber: [EMAIL PROTECTED]

Мне еще спать под рутом (С)энта


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Чем плох рекурсивный make?

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 сквозь логику можно, но трудно

AC install-stamp:
AC dh_testdir
AC dh_testroot
AC make -C build-siminstall DESTDIR=$(TMP_DIR)/sim
AC make -C build-sim-qt install DESTDIR=$(TMP_DIR)/sim-qt

AC Если это не рекурсия, то кто тогда рекурсия?

AC рекурсия это
AC debian/rules пара-переменных цель

AC Это - рекурсивный вызов makefile. А речь идет про рекурсивный вызов make.
DEO гы, берем например /usr/bin там скриптов наверное треть
DEO куча из них перевызввает друг друга (например docbook2html пока дойдешь
DEO до ELF'а поседеешь :))

DEO и что их кто-то называет рекурсивными? нет

Называют.

DEO чем отличается вызов make из make от выозва скажем gcc?

DEO ничем
DEO в случае make собирается цель
DEO в случае gcc собирается цель

make, напомню, в отличие от gcc, вызывают не только чтобы собрать цель,
но и чтобы _пере_собрать ее. С минимальными затратами. Он именно для
этого придуман, иначе он был бы нафиг не нужен, шелловский скрипт,
начинающийся с set -e, того же результата достигает куда проще и с куда
меньшими возможностями ошибок.

Он, конечно, _заодно_ позволяет и собрать цель, но это, прямо скажем, не
основное его назначение, а именно что побочный эффект. Так вот,
рекурсивный вызов make ломает его основную функциональность. Побочную,
правда, сохраняет.

Кстати, грабель подобного типа в дебиановских пакетах мне попадалось.
Я, правда, заранее знаю, что они там есть... Но, в частности, мне
попадался пакет, который не собирался с первой попытки, а собирался
только со второй... Причем стараниями мейнтейнера, а не автора
апстрима...

DEO в первом случае можно опциями влиять на получаемый результат
DEO во втором случае можно опциями влиять на получаемый результат

DEO как хотите но я категорически против называния вызова стороннего
DEO Make рекурсивным.

Хорошо, специально для тебя. Running make from make considered
harmful. В info make именно это называется recursive, но чего не
сделаешь для хорошего человека...

AC вызов внешних make - это не рекурсия, это тоже самое что и вызов
AC внешнего компилятора.

AC Нет. Домашнее упражнение: найти принципиальную разницу. Хинт:
AC внимательно осознать цели и задачи make.
DEO нет принципиальной разницы

DEO вызов make с другим makefile в данном случае - лишь один из видов
DEO компиляторов:
DEO цель собирает
DEO код ошибки возвращает

Я недаром указал, что приведенное место - пример того, почему harmful.
Ты потрудись подумать, что там harmful. Для человека, как бы типа
ответственного за корректную сборку пакетов, это очень нелишнее
знание...

--
Artem Chuprina
RFC2822: ran{}ran.pp.ru Jabber: [EMAIL PROTECTED]

Юзер упорствует в хождении по граблям. Образовавшиеся шишки он считает
трудовыми мозолями. (С)энта

--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Чем плох рекурсивный make?

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 вызывают для того, чтобы сделать новый .o _вместо_ старого. Он про
старый вообще не думает, он его молча затирает. make - думает. Если
это не отличие, то ты не в курсе, зачем нужен make.

AC С минимальными затратами. Он именно для
AC этого придуман, иначе он был бы нафиг не нужен, шелловский скрипт,
AC начинающийся с set -e, того же результата достигает куда проще и с куда
AC меньшими возможностями ошибок.
DEO каждая тулза для чего-то задумана
DEO шелл - для простоты склейки работы разных утилит
DEO make - для простоты сборки

make как раз усложняет сборку по сравнению с тупым шелловским скриптом.
Но удешевляет ее за счет этого.

AC Он, конечно, _заодно_ позволяет и собрать цель, но это, прямо
AC скажем, не основное его назначение, а именно что побочный эффект.
AC Так вот, рекурсивный вызов make ломает его основную
AC функциональность. Побочную, правда, сохраняет.
DEO вызов внешнего make - нерекурсивный
DEO и ничего не ломает

Ты не подумал о том, о чем я тебя просил подумать? Или подумал, но не
понял?

AC Кстати, грабель подобного типа в дебиановских пакетах мне попадалось.
AC Я, правда, заранее знаю, что они там есть... Но, в частности, мне
AC попадался пакет, который не собирался с первой попытки, а собирался
AC только со второй... Причем стараниями мейнтейнера, а не автора
AC апстрима...
DEO а сколько пакетов собираются с первой попытки но не собираются со
DEO второй...

Это как раз существенно более типичная иллюстрация к recursive make
considered harmful. Но в натуре, как правило вот ровно к этому.

--
Artem Chuprina
RFC2822: ran{}ran.pp.ru Jabber: [EMAIL PROTECTED]

--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Чем плох рекурсивный make?

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 вызывают для того, чтобы сделать новый .o _вместо_ старого. Он про
AC старый вообще не думает, он его молча затирает. make - думает.
DEO и что с того что думает? мы что будем различия строить на том о чем
DEO думает какая-то программа во время работы?
DEO они каждая думает о своем.

DEO ладно хорошо другой пример:
DEO есть у нас makefile из которого вызывается другой makefile, но
DEO предположим не с программой make а с программой ?make

DEO рекурсия есть или рекурсии нет?

depends. Если ?make - это скрипт, выполняющий rm -f $1, то нет.

AC Если это не отличие, то ты не в курсе, зачем нужен make.
DEO он нужен чтобы собирать цели, а уже собранные игнорировать.

Отнюдь не игнорировать.

AC make как раз усложняет сборку по сравнению с тупым шелловским скриптом.
AC Но удешевляет ее за счет этого.
DEO смотря что считать простотой,
DEO а так и то и другое - фактически скрипты

Шелловский скрипт unconditional сборки проекта проще соответствующего
мейкфайла. Потому что надо описать только команды сборки, а на
зависимости можно забить.

AC вызов внешнего make - нерекурсивный
AC и ничего не ломает

AC Ты не подумал о том, о чем я тебя просил подумать? Или подумал, но не
AC понял?
DEO см пример выше когда make вызывает какой-то другой make :D

Ясно. Не понял. Объяснить?

AC а сколько пакетов собираются с первой попытки но не собираются со
AC второй...

AC Это как раз существенно более типичная иллюстрация к recursive make
AC considered harmful. Но в натуре, как правило вот ровно к этому.
DEO хармфул тут в голове макепейсателя а не в самом маке

Скажем так, избежать этих грабель при рекурсивном вызове make гораздо
труднее, чем в заменителях, которые об этой проблеме в курсе. Для того,
чтобы их избежать, надо о них помнить. И в результате все равно
получишь лишние действия.

У make, впрочем, есть и еще одна проблема. Она уже не имеет отношения к
рекурсивному вызову, но ноги ее растут примерно из той же весьма куцей
модели зависимостей, которую он реализует. Ее тоже можно обойти, но это
ВЕСЬМА нетривиально, и разумеется, НИКАК не поддерживается встроенными
правилами (т.е. встроенными пользоваться при этом нельзя). Называется
она разные аргументы командной строки.

--
Artem Chuprina
RFC2822: ran{}ran.pp.ru Jabber: [EMAIL PROTECTED]

If it's there and you can see it---it's real
If it's not there and you can see it---it's virtual
If it's there and you can't see it---it's transparent
If it's not there and you can't see it---you erased it!
IBM poster explaining virtual memory, circa 1978

--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Чем плох рекурсивный make?

 AC make как раз усложняет сборку по сравнению с тупым шелловским скриптом.
 AC Но удешевляет ее за счет этого.

 Шелловский скрипт unconditional сборки проекта проще соответствующего
 мейкфайла.
Нет. Смотри ниже.

  Потому что надо описать только команды сборки, а на
 зависимости можно забить.
В правильных make-ах не нужно писать ни правила сборки, ни
зависимости.  Первое не нужно делать в BSD make-е, второе (для разных
ЯП) по-моему делают все новомодные заменители, включая AFAIK cmake. Не
знаю, как у него с пунктом первым.

В правильном makefile-е нужно указать всего-лишь ЧТО строим и ИЗ ЧЕГО.
Остальное его забота, включая зависимости, правила сборки и
кроссборки, инсталляции и прочее.

Вывод: _правильный_ make - на порядок проще unconditional shell скрипта.

-- 
Best regards, Aleksey Cheusov.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Чем плох рекурсивный make?

  У make, впрочем, есть и еще одна проблема.  Она уже не имеет отношения к
  рекурсивному вызову, но ноги ее растут примерно из той же весьма куцей
  модели зависимостей, которую он реализует.

 Несмотря на то, что абзацу объяснения было отведено аж 6 неполных строк,
 я так и не понял, о чём речь...

http://www.gnu.org/software/make/manual/make.html#Automatic-Prerequisites

Это костыль. Исходная проблема в том, что зависимости в make-ах
строятся только на уровне файлов, без анализа содержимого этих файлов
и учета семантики этого самого содержимого.

То есть исходный make - универсальный инструмент, но применительно к
сборке программ на конкретном языке, мягко говоря возникают некоторые
неудобства.

-- 
Best regards, Aleksey Cheusov.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Чем плох рекурсивный make?

Dmitry E. Oboukhov - debian-russian@lists.debian.org @ Wed, 1 Oct 2008
16:35:22 +0400:

AC gcc вызывают для того, чтобы сделать новый .o _вместо_ старого. Он про
AC старый вообще не думает, он его молча затирает. make - думает.
AC и что с того что думает? мы что будем различия строить на том о чем
AC думает какая-то программа во время работы?
AC они каждая думает о своем.

AC ладно хорошо другой пример:
AC есть у нас makefile из которого вызывается другой makefile, но
AC предположим не с программой make а с программой ?make

AC рекурсия есть или рекурсии нет?

AC depends.
DEO именно depends, о чем и говорю

DEO и соответственно make на другой makefile точно такой же depends,
DEO отличается от предыдущего depends одной буквой в названии

A Если ?make - это скрипт, выполняющий rm -f $1, то нет.
DEO а это почему это? может у него задача стоит rm -f $1? (типичный make
DEO clean)

Блин. Ты хочешь доказать мне, что можно придумать пример, где
рекурсивный вызов make не составляет проблем? Не вопрос, я и сам могу.

Вопрос в том, что в типичном случае проблемы будут. А в том, где не
будет, использование make - это из пушек по воробьям.

Или тебе настолько не нравится слово рекурсивный, что ты не можешь
найти в себе сил выяснить, что оно значит в контексте обсуждаемой фразы
из четырех английских слов?

AC Если это не отличие, то ты не в курсе, зачем нужен make.
AC он нужен чтобы собирать цели, а уже собранные игнорировать.

AC Отнюдь не игнорировать.
DEO именно игнорировать, поскольку они уже собраны

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

AC Шелловский скрипт unconditional сборки проекта проще соответствующего
AC мейкфайла. Потому что надо описать только команды сборки, а на
AC зависимости можно забить.
DEO если ты на зависимости забьешь то у тебя не соберется

Соберется. Я две строчки местами поменяю (несколько раз), и соберется.

DEO а и shell'овским скриптом тоже можно смотреть на даты файлов и
DEO сравнивать их.
DEO разницы тут ровно столько что в одном языке одно действие сделать проще
DEO чем в другом

Ты слово unconditional не смог прочесть или найти в словаре?

AC Ясно. Не понял. Объяснить?
DEO попробуй :)

Объясняю. Берем (для примера урезанный, существенное сохранено) вариант
того самого debian/rules, который тебе вроде как нравился.

install:configure install-stamp
install-stamp:
make -C .. install DESTDIR=debian/tmp
touch $@

Выполнили один раз. Результат, допустим, не понравился.

Изменяем проект (допустим, накладываем патч). Даже, допустим, собираем
результат. Там же, в проекте. Запускаем debian/rules install, дабы
заново собрать пакет (на самом деле, естественно, запускаем binary, а
оно позовет install - там это будет в еще два шага, я их не привел).
Вопрос. Какая версия будет в пакете в результате?

Для особо невнимательных сразу ответ. Старая. В смысле - та, которая
была, а не обновленная. Оно просто не попытается ничего инсталлировать.

Почему? Да потому что ему неоткуда знать, что там что-то изменилось.
Оно видит только, что есть файл install-stamp, а раз он есть, делать
ничего не надо.

То есть этот debian/rules - система _однократной_ сборки. В том смысле,
что гарантирует корректный результат только если сборка - первая. Может
быть, первая после debian/rules clean, а может, и только после
распаковки, этого я не проверял.

Можно его изменить так, чтобы он гарантированно каждый раз собирал
свежую версию. Но - фактически ценой отказа от функциональности make по
анализу что надо собирать, а что - нет. При этом make для этой задачи
становится overkill'ом и потенциальным источником ошибок (где-то что-то
забыл почистить - и привет...)

AC Это как раз существенно более типичная иллюстрация к recursive make
AC considered harmful. Но в натуре, как правило вот ровно к этому.
AC хармфул тут в голове макепейсателя а не в самом маке

AC Скажем так, избежать этих грабель при рекурсивном вызове make гораздо
AC труднее,
DEO вызов внешнего make - нерекурсивный

Терминология используется не твоя, а авторов make. Dixi.

DEO и грабли начинаются только там где два процесса пытаются работать с
DEO одним ресурсом, обычный IPC

DEO это в любом языке эти грабли есть где есть возможность создания
DEO процессов и воздействия их друг на друга.

DEO если например
DEO makefile1 собирает либу1
DEO makefile2 собирает либу2
DEO makefile3 собирает либу1 и либу2 в пакет, вызывая makefile2 makefile1
DEO то это нормально

Нет. Вон выше пример разжеван в деталях. Ровно такая ситуация, даже
без либы2.

Вернее, нет. Если makefile3 делает не make -f makefile1, а include
makefile1, то все нормально. Но если при этом они в разных директориях,
как в случае с debian/rules, то makefile1 надо писать очень специально,
сразу с расчетом на эту конструкцию. У меня есть один такой, да...

Re: Чем плох рекурсивный make?

Eugene V. Lyubimkin - debian-russian@lists.debian.org @ Wed, 01 Oct 2008
15:45:33 +0300:

EVL Несмотря на то, что абзацу объяснения было отведено аж 6 неполных
EVL строк, я так и не понял, о чём речь...

А это не было объяснение. Объяснение гораздо короче. При
последовательном (не обязательно подряд) выполнении команд, допустим,

make
make DEBUG=1

make не догадывается, что пересобрать с отладочными дефайнами надо не
только те файлы, которые менялись, а вообще все.

--
Artem Chuprina
RFC2822: ran{}ran.pp.ru Jabber: [EMAIL PROTECTED]

Обновление Windows изменило интуитивно ясный интерфейс Вашего компьютера.
Загрузите обновление интуиции с сайта Microsoft.
(С)энта

--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Чем плох рекурсивный make?

Aleksey Cheusov - debian-russian@lists.debian.org @ Wed, 01 Oct 2008 15:57:49
+0300:

AC make как раз усложняет сборку по сравнению с тупым шелловским скриптом.
AC Но удешевляет ее за счет этого.

Шелловский скрипт unconditional сборки проекта проще соответствующего
мейкфайла.
AC Нет. Смотри ниже.

Потому что надо описать только команды сборки, а на
зависимости можно забить.
AC В правильных make-ах не нужно писать ни правила сборки, ни
AC зависимости. Первое не нужно делать в BSD make-е, второе (для разных
AC ЯП) по-моему делают все новомодные заменители, включая AFAIK cmake. Не
AC знаю, как у него с пунктом первым.

AC В правильном makefile-е нужно указать всего-лишь ЧТО строим и ИЗ ЧЕГО.
AC Остальное его забота, включая зависимости, правила сборки и
AC кроссборки, инсталляции и прочее.

AC Вывод: _правильный_ make - на порядок проще unconditional shell скрипта.

Там, где не нужно писать - нужно include тот файл, где это уже
написано. Ты приводил пример, собственно. Так вот. Ты должен быть в
курсе, что sh тоже так умеет...

--
Artem Chuprina
RFC2822: ran{}ran.pp.ru Jabber: [EMAIL PROTECTED]

Parentheses? What parentheses? I haven't noticed any parentheses
since my first month of Lisp programming. I like to ask people who
complain about parentheses in Lisp if they are bothered by all the
spaces between words in a newspaper...
-- Kenny Tilton

--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Чем плох рекурсивный make?


 AC Вывод: _правильный_ make - на порядок проще unconditional shell скрипта.

 Там, где не нужно писать - нужно include тот файл, где это уже
 написано.  Ты приводил пример, собственно.  Так вот.  Ты должен быть
 в курсе, что sh тоже так умеет...

Ах так. Ну хорошо. Тогда такой вывод:
правильный Makefile настолько же прост, как и
правильный unconditional shell script.

Но шел скрипт таки unconditional, и поэтому он все равно хуже ;-)
А ежели он не unconditional, но это уже не shell,
а make написанный на shell.

У меня даже есть утила для этого  -- paexec :-)
pamake получится сразу distributed, от рождения.

-- 
Best regards, Aleksey Cheusov.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Чем плох рекурсивный make?

  http://www.gnu.org/software/make/manual/make.html#Automatic-Prerequisites
  
  Это костыль. Исходная проблема в том, что зависимости в make-ах
  строятся только на уровне файлов, без анализа содержимого этих файлов
  и учета семантики этого самого содержимого.
  
  То есть исходный make - универсальный инструмент, но применительно к
  сборке программ на конкретном языке, мягко говоря возникают некоторые
  неудобства.
  
 А, теперь понял. Да - это действительно проблема.

Это одна из центральных проблем, которую исправляют практически все
новомодные заменители make-а. Плагинами под конкретные ЯП.

-- 
Best regards, Aleksey Cheusov.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Чем плох рекурсивный make?

Dmitry E. Oboukhov - debian-russian@lists.debian.org @ Wed, 1 Oct 2008
18:17:20 +0400:

AC Блин. Ты хочешь доказать мне, что можно придумать пример, где
AC рекурсивный вызов make не составляет проблем? Не вопрос, я и сам могу.

AC Вопрос в том, что в типичном случае проблемы будут. А в том, где не
AC будет, использование make - это из пушек по воробьям.

AC Или тебе настолько не нравится слово рекурсивный, что ты не можешь
AC найти в себе сил выяснить, что оно значит в контексте обсуждаемой фразы
AC из четырех английских слов?

DEO [*] я вижу что описываемые проблемы растут не из кривости или
DEO рекурсивности make а из неправильного применения инструмента.

Можно сказать и так. Только тогда во всей идее .deb он применяется
неправильно, во-вторых, а во-первых, ты пробовал его применить
правильно? Я пробовал. Можно. Но с ТАКИМ геморроем...

AC Шелловский скрипт unconditional сборки проекта проще соответствующего
AC мейкфайла. Потому что надо описать только команды сборки, а на
AC зависимости можно забить.
AC если ты на зависимости забьешь то у тебя не соберется

AC Соберется. Я две строчки местами поменяю (несколько раз), и соберется.
DEO ну так ты удовлетворишь зависимости этими двумя строчками потому и
DEO соберется

Именно. Но я это сделаю один раз. Более того, я это сделаю сразу, при
первом написании скрипта. В _моем_ скрипте их переставлять не
придется.

AC а и shell'овским скриптом тоже можно смотреть на даты файлов и
AC сравнивать их.
AC разницы тут ровно столько что в одном языке одно действие сделать проще
AC чем в другом

AC Ты слово unconditional не смог прочесть или найти в словаре?
DEO и что это слово? (*)

И то, что если механизм проверки условия пересборки выключить, то make
становится скорее источником ошибок, чем удобным инструментом.

AC Объясняю. Берем (для примера урезанный, существенное сохранено) вариант
AC того самого debian/rules, который тебе вроде как нравился.

AC install: configure install-stamp
AC install-stamp:
AC make -C .. install DESTDIR=debian/tmp
AC touch $@

AC Выполнили один раз. Результат, допустим, не понравился.

AC Изменяем проект (допустим, накладываем патч). Даже, допустим, собираем
AC результат. Там же, в проекте. Запускаем debian/rules install, дабы
AC заново собрать пакет (на самом деле, естественно, запускаем binary, а
AC оно позовет install - там это будет в еще два шага, я их не привел).
AC Вопрос. Какая версия будет в пакете в результате?
DEO здесь как видно не собирался никто сделать повторную сборку ибо не нужна

В модели pbuilder - не нужна, он каждый раз все удаляет нах. Но
непонятно тогда, зачем там make. Внимание. Почему - понятно.
Непонятно, зачем.

Примерно с той же, блин, целью сделан и configure. Непонятно только,
нафига он генерирует развесистый мейкфайл вместо тупого sh-скрипта - все
равно в половине случаев от того make там один вред.

DEO понадобится - configure вынесется в отдельную цель и будет результат
DEO всегда правильный

Там вынесено. Ты туда загляни. Те же яйца, почти дословно.

DEO а наложение патчей на собственно make'ы, да потребует сделать
DEO clean, но эту проблему можно будет решить поставив зависимость на
DEO сам Makefile.

DEO где проблема-то? в том что решалась одна задача, а захотелось
DEO решить попутно и другую? так давай ее впишем в ТЗ и решим?
DEO добавится пара целей и депендсов и ничего не изменится :)

Давай ты мне продемонстрируешь ее решение? Я, видишь ли, пробовал...

AC Для особо невнимательных сразу ответ. Старая. В смысле - та, которая
AC была, а не обновленная. Оно просто не попытается ничего инсталлировать.

AC Почему? Да потому что ему неоткуда знать, что там что-то изменилось.
AC Оно видит только, что есть файл install-stamp, а раз он есть, делать
AC ничего не надо.
DEO ну да, это ведь такая работа и задумана.

Если ты полагаешь, что такая и задумана - я могу тебе показать проблему
и внутри debian/rules. Этот конкретный написан так, что они там и без
рекурсивного вызова make есть.

На самом деле, естественно, не такая и задумана, а проще забить, чем
вылечить. Что для данного применения плохо, но приемлемо. Для целей
разработки же - скорее неприемлемо.

AC Можно его изменить так, чтобы он гарантированно каждый раз собирал
AC свежую версию.
DEO смотри, если мы не делаем configure, а делаем

DEO make
DEO изменили что-то
DEO make
DEO изменили что-то
DEO make

DEO то оно ж в исходной (авторской) системе сборки отлично итеративно
DEO собирает/линкует только изменения.

DEO то есть поменяв зависимость (что типично для языка make) с install-stamp
DEO на собираемые бинарники мы решим и ту задачу что тебе нужна (она была
DEO просто не нужна в рамках этого make)

Ты попробуй. Покажи решение. Я тебе продемонстрирую, если сам не
сообразишь по дороге, где в нем проблема.

DEO смотри, авторский make собирает N бинарников и M либ

DEO в debian/rules мы вместо того чтобы ставить N+M зависимостей,
DEO нарисовали один

Re: Чем плох рекурсивный make?

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]

Психология - это наука о плохих контактах (С)энта


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Чем плох рекурсивный make?

2008-09-30 Пенетрантность Boris Popov

30 сентября 2008 г. 16:08 пользователь Artem Chuprina [EMAIL PROTECTED] 
написал:
 Boris Popov - Russian Debian List  @ Tue, 30 Sep 2008 16:03:38 +0400:

  BP Чем плох рекурсивный make?

 Тебя на гугле забанили?  Ключевая фраза для поиска в рассылке появлялась
 неоднократно.

В двух словах, пожалуйста?



-- 
Boris Popov

Re: Чем плох рекурсивный make?

Boris Popov - debian-russian@lists.debian.org  @ Tue, 30 Sep 2008 16:15:03 
+0400:

   BP Чем плох рекурсивный make?
 
  Тебя на гугле забанили?  Ключевая фраза для поиска в рассылке появлялась
  неоднократно.

 BP В двух словах, пожалуйста?

Теряется информация.

-- 
Artem Chuprina
RFC2822: ran{}ran.pp.ru Jabber: [EMAIL PROTECTED]

Praemonitus premunitus


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Чем плох рекурсивный make?

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 сквозь логику можно, но трудно

install-stamp:
dh_testdir
dh_testroot
make -C build-siminstall DESTDIR=$(TMP_DIR)/sim
make -C build-sim-qt install DESTDIR=$(TMP_DIR)/sim-qt

Если это не рекурсия, то кто тогда рекурсия?

Или у него еще и своя рекурсия была, и ты решил, что раз ее убрали, то
больше ее не осталось?

-- 
Artem Chuprina
RFC2822: ran{}ran.pp.ru Jabber: [EMAIL PROTECTED]

Will write code that writes code that writes code that writes code for 
money.
 -- on comp.lang.lisp


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Чем плох рекурсивный make?

Dmitry E. Oboukhov - debian-russian@lists.debian.org  @ Tue, 30 Sep 2008 
16:44:27 +0400:

 BP Тебя на гугле забанили?  Ключевая фраза для поиска в рассылке появлялась
 BP неоднократно.

 BP В двух словах, пожалуйста?
 DEO он не может, он специалист по безопасности а им не пристало

Поздравляю соврамши.

-- 
Artem Chuprina
RFC2822: ran{}ran.pp.ru Jabber: [EMAIL PROTECTED]

ожидания по умолчанию приводят к обломам по определению.
 -- http://apraxina.livejournal.com/301026.html


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Чем плох рекурсивный make?