???
Жирным выделил особо непонятный момент.
Навскидку никто тип грабель не подскажет?

Вот сборочный участок makefile:


Хотя сомневаюсь, что в нем дело. Точнее, уверен, что не в нем.

Есть предположение, что свежеустановленный цыгвин запускает свой make.exe вместо нужного. Только вот почему ж он такой кривой...
##
Не подтвердилось, с другим то же самое.


##
Внезапное развитие событий.
Залочил цыгвин (переобозвал папку на cygwin_) - всё заработало.
Ну и каким образом он мешается?
И почему вчера (до перезагрузки) всё работало?

Насколько понимаю, он свой sh подставляет вместо системного шелла. Как - в упор не понимаю.

Да, так и есть.
Переобозвал sh.exe в sh_ - всё по-старому, нормально работает.

Каким образом sh включается вместо обычного shell - без понятия.

Сообщение отредактировал MrYuran - May 27 2011, 06:33

Всё дело в обратных слешах:

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

Это я все понимаю. Не понимаю другого: как sh перехватывает обработку команды из досовского шелла?

Его make вызывает, при чём тут досовский шелл?

Так, секундочку... С чего бы вдруг?
Да и раньше, без цыгвина, sh нигде не было, а всё работало.
Что-то не то...

Так он устроен



Ещё раз:
Если make находит sh, то может использовать его. Если не находит - обходится без.

Интересная штука GCC!
Неисчерпаемая, как атом

Перевести всё на sh наверно мысль дельная, будет универсальность и кроссплатформенность.
Надо подумать.

Ну а навскидку, какие там ещё подводные грабли, чтобы три раза не спрашивать?

Это не GCC, это make, он как бы сбоку

Грабли - сейчас уже и не вспомню. Помню, что на

sh реагировал весьма своеобразно (раскрывал "shell patterns"). Заменил "***" на "---".
И что-то с rar-ом никак не уживался, этот sh. Сначала я вышел из положения монструозной конструкцией

, а потом и вовсе перешёл на 7z.

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


Надо вообще этот make фтопку. Есть более приятные инструменты для этих целей. Я использую уже года 4 или 5 SCons. Питоновый скрипт, по сути. Там можно делать всё - от написания билдеров (функций сборки) до всяких вспомогательных действий типа обработки строк, работы с файлами - словом всё, что доступно полноценному языку программирования. И особенно приятно, что открыв скрипт сборки через полгода без всяких проблем читаешь и правишь код. На make же постоянно приходилось лезть в доку, чтобы вспомнить, что обозначают закорючки типа $< или $@. Да остальной синтаксис через подстановки $(...) не добавляет радости. Птичий язык. Привычка, конечно, многое решает, но за достаточно много лет использования make никогда не испытывал удовольствия от работы с ним. Приобретённый опыт, конечно, помогает по жизни (вот щас c Qt ковыряюсь, пока в рамках его оболочки и организации проектов, там на make основано), но очень рад, что в основном этот этап уже позади.

Я тоже исключал. А теперь вроде как изучил особенности, и стало всё предсказуемым Всё-таки sh изрядно расширяет функциональность make.

Смотрел немного на него. Вроде заманчиво... Но это, по сути, учить ещё один язык, нужно тратить время и усилия. Пока не складывается.
Есть какая-нибудь ссылка на "быстрый старт"?

При наличии сконса эта функциональность присутствует нативно и на гораздо более высоком уровне.

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


Хм, специальной ссылки не знаю. Я по документации шёл. Она вполне понятна. Главное - ухватить основную идею. Главное отличие от make там в том, что make основан на правилах: пользователь задаёт правила (явные и неявные), и утилита на основе этих правил строит зависимости. В этом есть определённая гибкость и мощь, но и система эта сложнее для понимания и прогнозирования действий.

В SCons идеология иная: там на уровне скрипта (языка Python) как бы задаётся план действий. Т.е. прямо (путём назначения целей и вызова функций в процессе выполнения скрипта SConstruct - аналог makefile) строится типа списка запланированных действий, которые по окончании прогона SConstruct запускаются на выполнение. Соответственно, весь маршрут линеен и на виду, на любом этапе (которые явные) можно что-то добавить, убрать, откорректировать.

Надо отметить, что в целом SCons - это не аналог make, а скорее аналог связки automake+make, т.е. он автоматом "знает" что запускать по какой платформой и т.п. Но мне такой функционал не был нужен, мне надо было средство - аналог make + удобный набор возможностей по обработке текстовых строк, сопутствующей арифметике, работе с файлами и директориями и т.д. И чтобы всё это было гуманно по отношению к пользователю, т.ч. чтобы после энмесячного перерыва можно было открыть исходник скрипта и спокойно чего читать/редактировать, не обращаясь к документации в качестве справочника. Поэтому я там первым делом удалил весь набор встроенных билдеров (функций сборки) и добавил свои.

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

А где взять? Я бы тоже попробовал.
Тем более что пришлось записаться в ряды извращенцев и запускать MSPGCC из-под VS, со всеми сопутствующими издержками типа перекодировки потока вывода ошибок через sed

dxp, спасибо за сконс! Я как-то интересовался им ранее, но, видимо, тогда еще не дорос.

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


тут

Вот кое-что с хабра...