Зачем мейку шелл?, И почему он не видит 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?

[S.R.]

Попробуй запускать как make --win32
М.б. поможет... По крайней мере мне с кленовским gnu-arm помогло.

[AHTOXA]

Не, не работает. Пишет "--win32 no longer supported".

[Инноватор]

Попробуйте использовать майкрософтовский nmake вместо make'a.

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

[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:)

[Сергей Борщ]

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

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

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

Тот, который у вас в комплекте прошлогоднего mspgcc - из комплекта cygwin. Соответственно и работает он, предполагая наличие cygwin. Начиная с июня этого года mspgcc собирается при помощи mingw, и теперь он дружит с утилитами из комплекта mingw. Этот комплект содержит и make и sh. Сами утилиты в последний комплект mspgcc (20080603) не включены. Вы можете скачать их отдельно с sourceforge и поставить один комплект на все пакеты. Будете иметь самую свежую версию этих утилит.

[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 скрипт. Никому из них баш не понадобился...

[Сергей Борщ]

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

Подколол, подколол Ну простите виндового пользователя, для которого что bash, что ash, что csh, что sh - все на одно лицо. Во встречавшихся мне линуксах по умолчанию стоял bash, sh - ссылка на него. В MSYS sh.exe тоже представляется как bash.

[dxp]

Такая обширная дискуссия по такому вроде бы простому вопросу, имхо, косвенно указывает, что возможно есть повод и причина поглядеть на более другие средства. Меня make уже давно перестал устраивать (собственно, с самого начала не вызывал восторга, но тогда не видел альтернативы), и некоторое время назад я успешно переполз на SCons (http://www.scons.org/), чего и вам желаю. Снимается не только эта проблема с шеллом, но и куча других сопутствующих.

Прошу прощения за офтопик.

[alx2]

Подколол, подколол Ну простите виндового пользователя, для которого что bash, что ash, что csh, что sh - все на одно лицо.

И не думал подкалывать. Я действительно понял фразу "возможности bash" как использование фичей, присущих именно bash и никому другому.

некоторое время назад я успешно переполз на SCons (http://www.scons.org/), чего и вам желаю. Снимается не только эта проблема с шеллом, но и куча других сопутствующих.

Спасибо за рекомендацию, будет время и настроение - посмотрю. А, возвращаясь ближе к топику, каким образом снимается проблема с шеллом? Там гвоздями забито использование своего встроенного шелла? Можно в двух словах об этом моменте?

Сообщение отредактировал alx2 - Jul 3 2008, 10:19

[Непомнящий Евген...]

А, возвращаясь ближе к топику, каким образом снимается проблема с шеллом? Там гвоздями забито использование своего встроенного шелла? Можно в двух словах об этом моменте?

Там вместо шелла можно использовать язык Питон и его стандартную библиотеку. А она большей частью кроссплатформенная.
Поэтому в шелле обычно просто нет необходимости. Если же автор scons-скрипта решит использовать системный шелл - будут те же проблемы.

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

[AHTOXA]

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

Я про свои личные makefile:)

Вы можете скачать их отдельно с sourceforge и поставить один комплект на все пакеты. Будете иметь самую свежую версию этих утилит.

А в каком конкретно пакете там sh?

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

Ну я же писал. Это мои makefile-ы, и проблема в том, что разные версии make обрабатывают их по разному. Одни обходятся без sh, а другие - ищут sh.

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

Какую документацию? man make? Не понимаете вы, линуксоиды, нас, бедных виндузятников Окей, попробую SHELL, спасибо.

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

Дык, уже, all included, как говорится

некоторое время назад я успешно переполз на SCons (http://www.scons.org/), чего и вам желаю.

А как же куча старых проектов?
И ещё такой вопрос: можно ли при использовании scons сесть за любой компьютер, воткнуть флешку и, ничего не инсталлируя, что-то поредактировать и покомпилировать? Как в этом смысле питон?

[Непомнящий Евген...]

И ещё такой вопрос: можно ли при использовании scons сесть за любой компьютер, воткнуть флешку и, ничего не инсталлируя, что-то поредактировать и покомпилировать? Как в этом смысле питон?

Можно. Единственное батник запуска scons-а придется несколько допилить. Сейчас он предполагает, что python.exe в path сидит.
Но обычно в скрипте все ж таки задействуются некоторые переменные окружения - например путь к компилятору\линкеру...

[Сергей Борщ]

А в каком конкретно пакете там sh?

Наверное в bash-3.1-MSYS-1.0.11-1.tar.bz2. Ну или поставить msysCORE-1.0.11-2007.01.19-1.tar.bz2 - в нем все. И прописать path на него. Во избежание конфликтов остальные версии утилит (из WinAVR, mspgcc) удалить.

[alx2]

Какую документацию? man make? Не понимаете вы, линуксоиды, нас, бедных виндузятников

Ась? Где линуксоиды? =8-( )
Если это ко мне, то "Ви меня с кем-то путаете" © Линуксами не пользуюсь.

А по делу - документация лежит на сайте GNU. Вот: http://www.gnu.org/software/make/manual/

[AHTOXA]

Наверное в bash-3.1-MSYS-1.0.11-1.tar.bz2. Ну или поставить msysCORE-1.0.11-2007.01.19-1.tar.bz2 - в нем все.

Спасибо, я проглядел:-) Почему-то думал что оно в binutils...

Ась? Где линуксоиды? =8-( )
Если это ко мне, то "Ви меня с кем-то путаете" © Линуксами не пользуюсь.

Пардоньте;-)

А по делу - документация лежит на сайте GNU. Вот: http://www.gnu.org/software/make/manual/

Спасибо! Она у меня оказывается даже есть на винте, возможно даже я её читал:-)

[dxp]

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

Что за "нужные версии питона" и "нужные версии библиотек"? Ставится питон (дистриб 10 мег), ставится сконс. Все. Всех делов на пять минут.

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

[Непомнящий Евген...]

Что за "нужные версии питона" и "нужные версии библиотек"? Ставится питон (дистриб 10 мег), ставится сконс. Все. Всех делов на пять минут.

Ну сконс совместим только с конкретными версиями питона (с новыми и старыми могут быть проблемы). С текущей официальной 2.5 он совместим.
Кроме того сконс и сам меняется. Если скрипты простые - это скорее всего непринципиально, однако если в скриптах использовать какие-то "потроха" scons-библиотеки, то возможно придется брать ту же версию сконса, что и при написании скрипта. А та версия могла (к примеру) не работать с питоном 2.5...

[dxp]

Ну сконс совместим только с конкретными версиями питона (с новыми и старыми могут быть проблемы). С текущей официальной 2.5 он совместим.

Удивительные вещи говорите. Что там может быть несовместимо? Питон, как и любая приличная программа, пишется в режиме обратной совместимости - т.е. все старые программы и скрипты должны работать. И так оно и есть. Обратной стороной этого момента является то, что постепенно язык обрастает устаревшими средствами, которые в нем остаются только для совместимости. Все средства языка четко документированы, все предсказуемо.

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

Кроме того сконс и сам меняется. Если скрипты простые - это скорее всего непринципиально, однако если в скриптах использовать какие-то "потроха" scons-библиотеки, то возможно придется брать ту же версию сконса, что и при написании скрипта. А та версия могла (к примеру) не работать с питоном 2.5...

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

Личный опыт: сидел на питоне 2.4, потом на 2.4.2, потом на 2.4.4, сейчас 2.5. Сконсов тоже с полдюжины штук версий поменял, ни разу никаких проблем не возникло из-за совместимости. И не только со сконсом, но и с пачкой других библиотек.

[Непомнящий Евген...]

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

Ну так я это самое и имею в виду. Каждая версия scons может работать с некоторым диапазоном версий питона. Что касается обратной совместимости, то например, питон 3.0 сделали несовместимым с 2.xx.

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

зы Отклонились мы конечно от темы мейка и шелла