Зачем мейку шелл?, И почему он не видит echo? Опции

[AHTOXA]

Работаю под виндой. Частенько сталкиваюсь с таким явлением: при запуске make он пытается найти sh. Не находит и обламывается.
Почему у меня нету sh? Я не помню, что-то мне в нём когда-то не понравилось, или что-то в этом роде. То ли он слеши перепутывал, то ли находил каждый файл по нескольку раз, то ли ещё что-то. Короче, хотелось бы обойтись без него:-)
Когда это происходит с чужими мейкфайлами, где есть что-то типа if -f[]... , то всё понятно, это явная команда шелла. Но бывает что ругается на мои обычные мейк-файлы, в которых ничего подобного не используется!
Вот сегодня, скачал новый mspgcc, там make 3.81. Был 3.80. Так вот, новый ругается на следующую строчку:

Код

clean:
    @$(RM) $(elffile) $(hexfile) 2>nul

пишет

Код

make: /bin/sh: Command not found
make: *** [clean] Error 127

Если убрать перенаправление вывода, для этой строки шелл становится не нужен. Но затыкается на следующей:

Код

    @echo --- assembling $<...

Пишет что не найдена команда echo. Хорошо, пишу

Код

echo        := cmd /C echo
,далее
    @$(echo) --- assembling $<...

- упс, починилось:-) Но только до следующей строки:

Код

    @$(CC) $(aflags) -o $@ $<

Там опять не найден bin/sh... Тут я уже не знал что делать, вернул прошлый мейк, всё заработало. И, что самое интересное, тот же самый (по идее) make 3.81 из сборки klen-а - шелл не запускает.

Хотелось бы понять:

• в каких случаях мейк может запустить шелл?
• от чего это зависит?
• как с этим бороться?
• независим ли мейк от шелла?
• и почему в mspgcc не положили sh.exe?

[alx2]

Хотелось бы понять:

• в каких случаях мейк может запустить шелл?
• от чего это зависит?
• как с этим бороться?
• независим ли мейк от шелла?
• и почему в mspgcc не положили sh.exe?

Попробую ответить, хотя я так и не понял, о каком конкретно make идет речь.
Для чего make зарускает шелл - для выполнения указанной в Makefile команды. Это если ответить кратко. Если более развернуто, то дело в следующем. Что по идее должен сделать make для выполнения некой команды? Запустить шелл и передать ему эту самую команду. Это общий случай, который работает всегда. Почему не выполнить ее самому? А зачем, если уже есть шеллы, которые это прекрасно умеют? Зачем дублировать функционал шелла в make, если шелл можно просто вызвать?
Но часто команда, которую требуется выполнить, тривиальна, и заключается, в свою очередь, в запуске какой-то программы (исполняемого файла) с передачей ему аргументов, например:

Код

gcc -c -O2 file.c

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

В каких случаях make запускает шелл и от чего это зависит? Во всех отличных от тривиального случаях, как то перенаправление ввода/вывода, составные команды, условное выполнение, ветвление, циклы, встроенные команды шелла и т.п. Например:

Код

cd src/doc && make all
rm -f liba.a; ar cq liba.a $(OBJ)
for F in $(LIST); do somethung $F; done

Или вот приведенная тобой команда:

Код

@$(RM) $(elffile) $(hexfile) 2>nul

Тут перенаправление вывода.

По поводу второй твоей команды:

Код

@$(CC) $(aflags) -o $@ $<

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

Например простое добавление ";" в конце команды указывает GNU make на необходимость запуска шелла вместо прямого выполнения, чем часто пользуются именно чтобы заставить make не умничать и запускать шелл. Да и просто использование в командной строке (даже в имени файла) символов, обычно имеющих специальное значение для шелла (кавычки, обратные апострофы, знак доллара и т.п.) приводит к тому, что make на всякий пожарный запускает шелл. Даже пробел в имени директория (типа "Program Files"), говорят, может "напугать" make...

Как с этим бороться? А зачем бороться? Не проще взять нормальный шелл и пользоваться им?

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

Почему в mspgcc не положили шелл? Потому что это компилятор. Почему в комплекте компилятора должен идти шелл? Если мне нужен шелл, я возьму шелл. Если компилятор - возьму компилятор. Если make - возьму make. Зачем класть разные программы в один пакет? Это было бы странно. Тем более что шеллов много разных, одному нравится один, другому - другой...

[AHTOXA]

Попробую ответить, хотя я так и не понял, о каком конкретно make идет речь.

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

В каких случаях make запускает шелл и от чего это зависит? Во всех отличных от тривиального случаях, как то перенаправление ввода/вывода, составные команды, условное выполнение, ветвление, циклы, встроенные команды шелла и т.п.

Но почему разные мейки ведут себя по разному? Мой мейкфайл чудесно обрабатывается make 3.81 из WinAvr, и отказывается обрабатываться make 3.81 из mspgcc. Вроде и версия мейка одна и та же. А логика почему-то разнится.

Например:

Код

cd src/doc && make all
rm -f liba.a; ar cq liba.a $(OBJ)
for F in $(LIST); do somethung $F; done

Ну тут всё понятно, здесь без шелла никак.

Или вот приведенная тобой команда:

Код

@$(RM) $(elffile) $(hexfile) 2>nul

Тут перенаправление вывода.

Однако же с другими мейками работало!

Как с этим бороться? А зачем бороться? Не проще взять нормальный шелл и пользоваться им?

А где взять нормальный шелл? Что-то мне такой пока не встречался

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

Но наличие хоть какого-то шелла подразумевается? Хотя чего я спрашиваю, в линуксе-то шелл имеется непременно. Видимо это что-то настолько само собой разумеющееся, что никто при портировании мейка под винду даже об этом не задумался.

Почему в mspgcc не положили шелл? Потому что это компилятор. Почему в комплекте компилятора должен идти шелл?

Потому что в комплекте компилятора идёт мейк А мейк, как мы видим, без шелла не работает.

ЗЫ. В любом случае, большое спасибо за разъяснения.

[alx2]

Но почему разные мейки ведут себя по разному? Мой мейкфайл чудесно обрабатывается make 3.81 из WinAvr, и отказывается обрабатываться make 3.81 из mspgcc. Вроде и версия мейка одна и та же. А логика почему-то разнится.

GNU make - это отдельный продукт. Почему два make одной и той же версии ведут себя по-разному - не знаю. Возможно, их по-разному сконфигурировали при сборке (в смысле, скрипт configure пускали с разными опциями). А может на них вообще какие-то патчи накладывали...

А где взять нормальный шелл? Что-то мне такой пока не встречался

В моей системе он есть "из коробки". В винде - сложнее. Обычно под виндой рекомендуют использовать bash. Поищи в интернете, наверняка должен быть где-то уже собранный бинарник (если нет желания собирать самому).

Но наличие хоть какого-то шелла подразумевается? Хотя чего я спрашиваю, в линуксе-то шелл имеется непременно. Видимо это что-то настолько само собой разумеющееся, что никто при портировании мейка под винду даже об этом не задумался.

Так под виндой есть шелл (командный интерпретатор) - cmd.exe. В ресурските есть еще один - sh.exe. Другое дело, что их качество не на высоте. Смутно припоминаю (я виндой много лет уже не пользуюсь), что у одного из этих двух есть проблема с максимальной длиной строки. В смысле, очень маленького ее значения, порядка 1 кбайта.

Потому что в комплекте компилятора идёт мейк

Нет в (официальном) комплекте gcc make'а. Можешь скачать ftp://ftp.gnu.org/gnu/gcc/gcc-4.3.1/gcc-core-4.3.1.tar.bz2 и попробовать в нем найти make. Если какое-то третье лицо взяло GNU make, взяло gcc, положило их в один архив и выложило в интернете - это самодеятельность этого лица, не более. ИМХО это недостаточное основание говорить "в комплекте gcc идет make"...

[AHTOXA]

Возможно, их по-разному сконфигурировали при сборке (в смысле, скрипт configure пускали с разными опциями). А может на них вообще какие-то патчи накладывали...

Вот это меня и интересует. Как бы так сконфигурировать, чтоб без шелла обойтись:-)

Так под виндой есть шелл (командный интерпретатор) - cmd.exe. В ресурските есть еще один - sh.exe. Другое дело, что их качество не на высоте. Смутно припоминаю (я виндой много лет уже не пользуюсь), что у одного из этих двух есть проблема с максимальной длиной строки. В смысле, очень маленького ее значения, порядка 1 кбайта.

Согласен на cmd:) Но make ищет /bin/sh... Надо задать какую-то переменную окружения?

Нет в (официальном) комплекте gcc make'а.

Я говорил про mspgcc. Просто под винду стараются комплектовать пакеты так, чтобы работало "из коробки". Поэтому и mspgcc и WinAvr и WinArm - все идут с make & binutils. И поэтому у меня очень много разных make:)

[alx2]

Вот это меня и интересует. Как бы так сконфигурировать, чтоб без шелла обойтись:-)

ИМХО никак. Какого поведения хочется добиться? Что должен делать make, сконфигурированный для работы без шелла, когда он встречает команду, для выполнения которой нужен шелл? Сругаться и остановиться? Так он и так это делает, когда шелл не находит. А если может выполнить команду без шелла, он и так выполняет без шелла...

Согласен на cmd:) Но make ищет /bin/sh... Надо задать какую-то переменную окружения?

А документацию читать сейчас не модно? Да, установить переменную SHELL. Можно как переменную окружения, можно как переменную самого make хоть в Makefile, хоть в командной строке.

Я говорил про mspgcc. Просто под винду стараются комплектовать пакеты так, чтобы работало "из коробки". Поэтому и mspgcc и WinAvr и WinArm - все идут с make & binutils. И поэтому у меня очень много разных make:)

Вот за это я и не люблю комбайны (когда все в одном флаконе) - нафиг мне много разных make? А насчет winavr - это я, выходит, отстал от жизни. Когда я N лет назад интересовался (в RU.EMBEDDED), что такое winavr, мне ответили, что это avr-gcc под винду. А теперь в него и binutils (что еще логично), и make (что уже менее логично) запихнули... Скоро, наверное, редактор с отладчиком туда же сунут...

А смысл? Все равно makefile обычно пишется используя возможности bash. И скрипты configure пишутся тоже под него.

Хм. Меня как раз учили так не делать. Для написания скриптов - максимально POSIX-стандартный /bin/sh без нестандартных наворотов, дабы скрипт выполнился на (почти) любой системе. А навороты bash - это больше для интерактивного использования.

По поводу configure - не замечаю такого. Вот рядом стоит система, в ней установлено 206 пакетов, большинство из них используют configure скрипт. Никому из них баш не понадобился...