GNU make в windows, Проблемы и их решения Опции

[LessNik]

Добрый день!

gnu make не хочет понимать пути с пробелами. Как объяснить?

Код

CC = c:/Files/IAR Systems/Embedded Workbench 5.4 Evaluation/arm/bin/iccarm.exe          // почему-то понимает
INC1_PATH = ../../Common
INC2_PATH = ./Include
INC3_PATH = c:/Files/IAR Systems/Embedded Workbench 5.4 Evaluation/arm/INC             // не понимает

DLIB_CONFIG_FILE = c:/Files/IAR Systems/Embedded Workbench 5.4 Evaluation/arm/INC/DLib_Config_Normal.h

CC_OPT = -I. -I\""$(INC2_PATH)/\"" -I\""$(INC3_PATH)/\""

main.o: main.cpp
    @echo ------------------------ compiling $< ------------------------
    $(CC) main.cpp $(CC_OPT)

all: main.o

Выдаёт следующее:
/usr/bin/sh: c:/Files/IAR: No such file or directory
make: *** [main.o] Error 127

[AHTOXA]

Это не мейк дурит, а sh. Я так не нашёл нормального. Выкинул нафиг.
А имена возьмите в кавычки, и всё заработает.

[alx2]

Это не мейк дурит, а sh. Я так не нашёл нормального. Выкинул нафиг.

Это действительно шелл (о чем написано в сообщении об ошибке, которое надо было внимательно читать), а не мейк. Но шелл в данном случае вовсе не дурит, а ведет себя совершенно правильно. Ему передали такую команду:

Код

c:/Files/IAR Systems/Embedded Workbench 5.4 Evaluation/arm/bin/iccarm.exe main.cpp -I. -I\""./Include/"\" -I\""c:/Files/IAR Systems/Embedded Workbench 5.4 Evaluation/arm/INC/"\"

В этой команде первый ничем не экранированный пробел стоит после c:/Files/IAR. Поэтому c:/Files/IAR шелл трактует как имя команды, все остальное - как ее параметры.
Также замечу, что эту вызвавшую ошибку команду мейк выводит на экран, и ее тоже стоило внимательно прочитать - все стало бы ясно.

[AHTOXA]

Это действительно шелл (о чем написано в сообщении об ошибке, которое надо было внимательно читать), а не мейк. Но шелл в данном случае вовсе не дурит, а ведет себя совершенно правильно.

Согласен, в данном случае шелл ведёт себя правильно. Я просто выразил своё негативное к нему(шеллу) отношение (Под виндой конечно, думаю что в родной среде он хорош.)

[xemul]

Согласен, в данном случае шелл ведёт себя правильно. Я просто выразил своё негативное к нему(шеллу) отношение (Под виндой конечно, думаю что в родной среде он хорош.)

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

[AHTOXA]

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

Да. Да. Да! Поэтому я согласился, что в этом случае шелл ведёт себя правильно

А вот пример неправильного поведения (их у меня много):

кусок makefile:

Код

    target    = test1
...
       archiver    = Rar.exe
...
     rars    = $(src_dir)/*.c $(src_dir)/*.h $(prj_dir)/*.* $(base)/makefile $(base)/*.mpj
...
archive:
     @echo --- archiving...
     $(archiver) a -r -agyy-mm-dd,hh-nn-ss $(bak_dir)/$(target)_.rar $(rars)
     @echo --- done!

как это работает без шелла (удалил из пути):

Код

>make archive
--- archiving...
Rar.exe a -r -agyy-mm-dd,hh-nn-ss ./bak/test1_.rar ./src/*.c ./src/*.h ./prj/*.* ./makefile ./*.mpj

Creating archive ./bak/test1_09-06-04,21-33-44.rar

Adding    ./src/config.c                                              OK
Adding    ./src/main.c                                                OK
Adding    ./src/rs1.c                                                 OK
Adding    ./src/term\commands.c                                       OK
Adding    ./src/term\handlers.c                                       OK
Adding    ./src/term\vars.c                                           OK
Adding    ./src/config.h                                              OK
Adding    ./src/gpio.h                                                OK
Adding    ./src/rs1.h                                                 OK
Adding    ./src/term\commands.h                                       OK
Adding    ./src/term\handlers.h                                       OK
Adding    ./src/term\vars.h                                           OK
Adding    ./prj/stm32f10x_flash_md.ld                                 OK
Adding    ./makefile                                                  OK
Adding    ./test1.mpj                                                 OK
Done
--- done!

и с шеллом (вернул):

Код

>make archive
--- archiving...
Rar.exe a -r -agyy-mm-dd,hh-nn-ss ./bak/test1_.rar ./src/*.c ./src/*.h ./prj/*.* ./makefile ./*.mpj

Creating archive ./bak/test1_09-06-04,21-24-00.rar

Adding    ./src/config.c                                              OK
Adding    ./src/main.c                                                OK
Adding    ./src/rs1.c                                                 OK
Adding    ./src/config.h                                              OK
Adding    ./src/gpio.h                                                OK
Adding    ./src/rs1.h                                                 OK
Adding    ./prj/stm32f10x_flash_md.ld                                 OK
Adding    ./makefile                                                  OK
Adding    ./test1.mpj                                                 OK
Done
--- done!

Видите разницу? Под шеллом Rar не увидел папочки /src/term! Я живу себе в полной уверенности, что у меня всё занычено в архив, а не тут-то было. Вот такая вот засада
Поэтому я выкинул sh, и ничуть не жалею.

ЗЫ. Только не говорите, что это Rar виноват, потому что у меня много других примеров

[alx2]

Видите разницу?

А можно еще показать содержимое директория src (вывод ls -l src например)?

Под шеллом Rar не увидел папочки /src/term!

А должен был? Папочка src/term не подпадает ни под одну из указанных в командной строке масок (в "term" нет точки например)!

ЗЫ. Только не говорите, что это Rar виноват, потому что у меня много других примеров

Не буду. Он не виноват. В этом случае, похоже, виноват программист.

Но объясните мне тогда, зачем sh, вместо того, чтобы просто вызвать заказанную программу с заказанными аргументами, ещё и подменяет системные вызовы для этой программы? Я так понял, что не срабатывает рекурсивный поиск внутри самого Rar-а.

Почему Вы решили, что он не срабатывает? Насколько я вижу, у Вас в директории ./src/ есть файлы config.c, main.c и rs1.c. Правильно? Во вложенных в src директориях (том же term например) есть файлы с такими именами? Что-то мне подсказывает, что нет. Тогда какой рекурсии Вы ждете? При наличии файлов с одинаковыми именами рекурсия работает, я только что проверил. Причина разного поведения rar'а кроется в передаче ему при вызове разных аргументов, а вовсе не подмена каких-либо системных вызовов...

Возможно, проще будет формировать скриптом список файлов, подлежащих упаковке, и скармливать его rar'у.

ИМХО в данном случае проше изучить документацию на шелл и правильно им пользоваться. В частности, если программист не хочет, чтобы шелл выполнял подстановку имен файлов вместо содержащих "*" аргументов, он должен сообщить об этой шеллу, например заэкранировав звезду бэкслешем или взяв аргумент в одинарные кавычки...

А как быть с другими, которые я перечислил? Как, например, запустить cmd с параметрами?

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

если make вдруг решит запустить их без sh...

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

Сообщение отредактировал alx2 - Jun 5 2009, 11:17

[AHTOXA]

А можно еще показать содержимое директория src (вывод ls -l src например)?

Зачем? Вроде всё уже выяснили. Там исходники и подкаталог с исходниками (*.c и *.h)

А должен был? Папочка src/term не подпадает ни под одну из указанных в командной строке масок (в "term" нет точки например)!/quote]
Должен был. Ибо ключик -r для Rar требует рекурсивного обхода заданных путей. Без sh же всё срабатывает.

Не буду. Он не виноват. В этом случае, похоже, виноват программист.

Узнаю линупсоеда:-) Виноват может быть кто угодно, только не линупс:-) Вы бы почитали тред повнимательнее, ведь мы с ReAl-ом уже во всём разобрались.

Почему Вы решили, что он не срабатывает? Насколько я вижу, у Вас в директории ./src/ есть файлы config.c, main.c и rs1.c. Правильно? Во вложенных в src директориях (том же term например) есть файлы с такими именами? Что-то мне подсказывает, что нет. Тогда какой рекурсии Вы ждете? При наличии файлов с одинаковыми именами рекурсия работает, я только что проверил. Причина разного поведения rar'а кроется в передаче ему при вызове разных аргументов, а вовсе не подмена каких-либо системных вызовов...

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

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

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

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

А вот это интересно, спасибо, проверю.

[alx2]

Узнаю линупсоеда:-) Виноват может быть кто угодно, только не линупс:-) Вы бы почитали тред повнимательнее, ведь мы с ReAl-ом уже во всём разобрались.

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

Какие нарекания?

К сожалению, сейчас уже вряд ли вспомню. Одной из проблем, насколько мне помнится, было очень уж сильное ограничение на длину командной строки. Коллега сталкивался с невозможностью сделать "echo ...список файлов... >listfile".

И много чего нельзя сделать иначе чем через него. И в том, что sh не хочет запускать cmd, а вижу признаки заговора линупсоедов:-) А слеш там обратный, чем он мешает sh?

Ой, извините, я уже ничего не понимаю. Просто каша какая-то - все в одну кучу свалено! Как это "sh не хочет запускать cmd"? Кто вообще спрашивает его желание? Что нормальному шеллу в командной строке указывают, то он и выполняет. При чем тут линуксоеды? Каким боком шеллу мешает обратный слеш? Прошу прощения, но я ничего не могу на это ответить. Я не сталкивался ни с проблемой сделать что-либо без использования cmd, ни с отказом шелла что-либо запускать, ни с помехами от бэкслешей.

Впрочем, по поводу использования внутренних команд cmd.exe - вот фрагмент Makefile'а моего коллеги:

Код

COPY = cmd /C copy

file2.bin: file1.bin
      $(COPY) file1.bin file2.bin

[AHTOXA]

Вы обознались. Я линукс не ем, и вообще им не пользуюсь. И даже слова такого тут не произносил.

Да не суть. Главное, что не виндузоид

В том, что программист не прочитал документацию на используемую программу, и не знал, что звезда для шелла имеет специальное значение, виноват уж точно не линукс...

Хм. Я совершенно не собирался использовать sh, он сам как-то затесался...

К сожалению, сейчас уже вряд ли вспомню. Одной из проблем, насколько мне помнится, было очень уж сильное ограничение на длину командной строки. Коллега сталкивался с невозможностью сделать "echo ...список файлов... >listfile".

Это, имхо, очень устаревшие сведения.

Ой, извините, я уже ничего не понимаю. Просто каша какая-то - все в одну кучу свалено! Как это "sh не хочет запускать cmd"? Кто вообще спрашивает его желание? Что нормальному шеллу в командной строке указывают, то он и выполняет.

Вот именно. А этот - самовольничает. В сообщении №13 я привёл пример моей попытки вызова cmd.

При чем тут линуксоеды? Каким боком шеллу мешает обратный слеш? Прошу прощения, но я ничего не могу на это ответить. Я не сталкивался ни с проблемой сделать что-либо без использования cmd, ни с отказом шелла что-либо запускать, ни с помехами от бэкслешей.

Это потому, что вы работаете не под виндой. То есть, извините, берётесь судить о том, чего не пробовали. Я уверен, что вы отлично знаете, как устроен sh, но под виндой у него есть некоторые особенности. И именно о них я и веду речь.

Впрочем, по поводу использования внутренних команд cmd.exe - вот фрагмент Makefile'а моего коллеги:

Код

COPY = cmd /C copy
file2.bin: file1.bin
       $(COPY) file1.bin file2.bin

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