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

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

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

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

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

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

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

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

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

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

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

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


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

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


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

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

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

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

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

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

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

Но почему разные мейки ведут себя по разному? Мой мейкфайл чудесно обрабатывается 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"...

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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



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


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

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




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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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