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

Ситуация смешна.

makefile:

SUBDIRS = 
SUBDIRS += ./a
SUBDIRS += ./b

all:
    for subdir in $(SUBDIRS); do echo ===== building $$subdir =====;$(MAKE) -C $$subdir all; done

результат:

for subdir in  ./a ./b; do echo ===== building $subdir =====;C:/Programs/UNIX_U~1/make.EXE -C $subdir all; done
===== building ./a =====
make.EXE[1]: Entering directory `C:/tmp'
for subdir in  ./a ./b; do echo ===== building $subdir =====;C:/Programs/UNIX_U~1/make.EXE -C $subdir all; done
===== building ./a =====
make.EXE[1]: Entering directory `C:/tmp'
for subdir in  ./a ./b; do echo ===== building $subdir =====;C:/Programs/UNIX_U~1/make.EXE -C $subdir all; done
===== building ./a =====
make.EXE[1]: Entering directory `C:/tmp'
for subdir in  ./a ./b; do echo ===== building $subdir =====;C:/Programs/UNIX_U~1/make.EXE -C $subdir all; done

и так до бесконечности. Вызов "вручную" make -C ./a работает. Эффект проявляется на двух компах, на двух других все работает. make на всех компах одинаковый, от WinAVR. make от yagarto ведет себя также. Винда ХР.

GNU Make 3.81

Copyright © 2006 Free Software Foundation, Inc.

This is free software; see the source for copying conditions.

There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A

PARTICULAR PURPOSE.

 

This program built for i386-pc-mingw32

Что я мог поломать?

[AHTOXA 18]

Ситуация смешна.

 

А у меня вчера перестал нормально вызываться rar из makefile...

Пишу

rars    =\
    src\*.c src\*.h makefile

archive:
    @echo *** archiving...
    @$(archiver) a -r -inul -agyy-mm-dd,hh-nn-ss $(bak_dir)\$(program_name)_.rar $(rars)
    @echo *** done!

 

- архивирует только makefile. При вызове с той же командной строкой руками - архивирует всё...

 

Ваш вариант у меня совсем не заработал - у меня выкинут шелл. Вот так - получилось:

SUBDIRS =
SUBDIRS += ".\a"
SUBDIRS += ".\b"

all:
    a.bat $(SUBDIRS)

 

где a.bat:

for %%f in  (%1 %2 %3) do @make -C %%f all

 

Это конечно не дело, но хоть работает:-)

[amw 0]

Ситуация смешна.

makefile:

SUBDIRS = 
SUBDIRS += ./a
SUBDIRS += ./b

all:
    for subdir in $(SUBDIRS); do echo ===== building $$subdir =====;$(MAKE) -C $$subdir all; done

А если так:

SUBDIRS = 
SUBDIRS += ./a
SUBDIRS += ./b

all: $(SUBDIRS)

$(foreach f, $(SUBDIRS), $(f)):
    @echo "===== building $@ ====="
    @$(MAKE) -C $@ all

.PHONY: all $(SUBDIRS)

PS: Ваш вариант у меня работает на Linux.

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

А если так:

так работает.

теперь пытаюсь понять, как аналогично добавить цель clean.

Но хотелось победить исходный - слишком много файлов переписывать.

PS: Ваш вариант у меня работает на Linux.

И у меня работает на двух машинах с виндой. А на двух не работает. Пока только пришло в голову, что на машинах, где не работает, процы AMD, а где работает - Интел, но я не верю, что причина может быть в этом. Надо будет внимательне посмотреть, какие версии sh стоят на этих машинах.

[amw 0]

так работает.

теперь пытаюсь понять, как аналогично добавить цель clean.

 

SUBDIRS = 
SUBDIRS += ./a
SUBDIRS += ./b

CLEANS = $(foreach f, $(SUBDIRS), clean-$(f))

all: $(SUBDIRS)

$(foreach f, $(SUBDIRS), $(f)):
    @echo "$(SUBDIRS)"
    @echo "===== building $@ ====="
    @$(MAKE) -C $@ all

clean: $(CLEANS)

$(foreach f, $(CLEANS), $(f)):
    @echo "$(lastword $(subst -, , $@))"
    $(MAKE) -C $(lastword $(subst -, , $@)) clean

.PHONY: all $(SUBDIRS) clean $(CLEANS)

В выражении

$(lastword $(subst -, , $@))

ОДИН ПРОБЕЛ между запятыми.

 

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

К стати, а echo используется откуда? Из Windows или из чего у Вас там юниксовое (cygwin, mingw).

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

Ну это слишком сложно... лишних 6 строчек вместо одной. Не, "это не наш метод" (с).

 

Хм, кое-что проясняется.

Кстати, а echo используется откуда? Из Windows или из чего у Вас там юниксовое (cygwin, mingw).

Вот эта фраза натолкнула на исследования. Запускается гнутый echo, но даже выкидывая его результат не меняется.

 

Попробовал на еще одной машине (проц интел). Поскольку там никаких гнутых инструментов не стоит, то скопировал в папку с makefile программы make.exe, sh.exe, echo.exe, библиотеку msys-1.0.dll. Получил тот же эффект - циклится до бесконечности. Запустил с той же флешки на своем компе (где все работало) - тоже циклится. Начал убирать по одному файлу. Выяснил такую закономерность:

 

make.exe, sh.exe, msys-1.0.dll лежат в одной папке - работает неправильно.

make.exe + msys-1.0.dll лежат в одной папке, sh.exe в другой - работает неправильно.

 

make.exe лежит в одной папке, sh.exe + msys-1.0.dll в другой - все работает.

make.exe в одной папке, sh.exe в другой, msys-1.0.dll в третьей - все работает.

добавлено:

make.exe + msys-1.0.dll лежат в одной папке, sh.exe + msys-1.0.dll в другой - все работает.

 

 

О как... теперь понятно, почему на двух машинах работало - там make.exe лежал в отдельной папке, которая указана в path до папки WinAVR/utils/bin

 

Осталось выяснить, чем вызвано такое странное поведение - какими-то еще установленными программами или это бага mingw. Учитывая, что на "чистой" машине поведение было неадекватным - скорее всего бага.

 

версия sh.exe:

GNU bash, version 2.04.0(1)-release (i686-pc-msys)

Copyright 1999 Free Software Foundation, Inc.

 

кто-нибудь из пользователей WinAVR может повторить эксперимент? Для этого надо приведенный makefile из поста №1 (восстановив табулятор перед for) положить в одну папку с make.exe, sh.exe и msys-1.0.dll и запустить make

 

P.S. за кавычки спасибо, учту.

[amw 0]

make.exe, sh.exe, msys-1.0.dll лежат в одной папке - работает неправильно.

make.exe + msys-1.0.dll лежат в одной папке, sh.exe в другой - работает неправильно.

 

make.exe лежит в одной папке, sh.exe + msys-1.0.dll в другой - все работает.

make.exe в одной папке, sh.exe в другой, msys-1.0.dll в третьей - все работает.

добавлено:

make.exe + msys-1.0.dll лежат в одной папке, sh.exe + msys-1.0.dll в другой - все работает.

О как... теперь понятно, почему на двух машинах работало - там make.exe лежал в отдельной папке, которая указана в path до папки WinAVR/utils/bin

 

Осталось выяснить, чем вызвано такое странное поведение - какими-то еще установленными программами или это бага mingw. Учитывая, что на "чистой" машине поведение было неадекватным - скорее всего бага.

По моему тут имеет значение порядок каталогов в PATH и, соответственно, порядок поиска нужных программ в cmd.exe. На сколько я понимаю, текущий каталог проверяется последним.

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

По моему тут имеет значение порядок каталогов в PATH и, соответственно, порядок поиска нужных программ в cmd.exe.

Программы одни и те же, эффект проявляется в зависимости от их взаимного расположения в разных папках (на которые указывает PATH).

[amw 0]

Программы одни и те же, эффект проявляется в зависимости от их взаимного расположения в разных папках (на которые указывает PATH).

А порядок каталогов в PATH имеет значение?

В пердидущем тесте какая нибудь программа находилась в текущем каталоге? И если да, то был ли в PATH текущий каталог?

 

В принципе, проблема решена, но на всякий случай, если есть желание проверить.

[AHTOXA 18]

В пердидущем тесте какая нибудь программа находилась в текущем каталоге? И если да, то был ли в PATH текущий каталог?

 

В винде поиск сначала выполняется в текущем каталоге.

 

А я так и не разобрался, что с моим Rar-ом:-)

Выкрутился так:

archive:
    @echo "--- archiving..."
    @cmd /C "start $(archiver) a -agyy-mm-dd,hh-nn-ss $(bak_dir)\$(program_name)_.rar $(rars)"
    @echo "--- done!"

 

Так - работает. Чудеса с этими мейками и шеллами в виндах, вечно что-то не так:-)

 

кто-нибудь из пользователей WinAVR может повторить эксперимент?

 

Попробовал. Это хуже любого вируса! :-)

 

 

Это только самая голова, и их было немеряно:-)))

Я ещё отошёл покурить, думал что остановил сей процесс... Пришёл, а тут... Еле отбился:-)

 

Это вариант когда всё в одной папке.

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

В пердидущем тесте какая нибудь программа находилась в текущем каталоге? И если да, то был ли в PATH текущий каталог?

Поиск идет сначала в текущем каталоге. Эффект не зависит от того, находятся файлы в текущем каталоне или в каталогах, куда указывает path. Т.е. он наблюдается если все три в текущем каталоге, если все три в одном каталоге, доступном через path, если sh в текущем а make+msys в другом (доступном через path), если sh в другом а make+ msys в текущем, или если make+msys в одном доступном через path а sh в другом(тоже доступном через path). От порядка каталогов в path не зависит.

[amw 0]

Поиск идет сначала в текущем каталоге. Эффект не зависит от того, находятся файлы в текущем каталоне или в каталогах, куда указывает path. Т.е. он наблюдается если все три в текущем каталоге, если все три в одном каталоге, доступном через path, если sh в текущем а make+msys в другом (доступном через path), если sh в другом а make+ msys в текущем, или если make+msys в одном доступном через path а sh в другом(тоже доступном через path). От порядка каталогов в path не зависит.

Ну может и правда баг.

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

Ну может и правда баг.

Мда. Поставил msys, там все работает нормально. Полез читать доку по винавру на предмет - кому отправлять баг-репорт

[ReAl 0]

Мда. Поставил msys, там все работает нормально. Полез читать доку по винавру на предмет - кому отправлять баг-репорт

А, ну да. Потому у меня и работает :)

Я давно стараюсь держать MSYS первым по путям.

Достаточно скреститься make.exe и sh.exe, sed.exe, mkdir.exe из "разноватых" сборок - сразу с очень большой вероятностю грабли. Но вот чтобы грабли лезли из "комплектного" набора - это впервые нарываюсь.

 

Хм... (Core2Quad, XP Pro sp2)

сделал батник

path %AVRGCC%\utils\bin
make

Т.е. в нём уже пути такие, что он может вызвать make.exe/sh.exe/echo.exe только из одного комплекта и брать msys-1.0.dll из него же.

Так, а AVRGCC у меня сейчас показывает на C:\WinAVR, который сейчас есть линком (ntfs junction point) на C:\WinAVR-20071221

Короче, то, что полетело у FAR-а в окне я еле законтрол-Цечил.

make пытается войти не в подкаталог ./a, а в текущий каталог, вызывается опять с тем же makefile и побежали.

===== building ./a =====
make[20]: Entering directory `F:/temp/1'
for subdir in  ./a ./b; do echo ===== building $subdir =====;c:/WinAVR/utils/bin/make -C $subdir all
; done

 

Поскольку ничего, кроме WinAVR-овских исполняемых файлов не принимало участие - косяк в них или в их взаимодействии с XP (но с MSYS-овскими-то нормально!).

 

Почему при перемещении msys-1.0.dll из C:\WinAVR\utils\bin в текущий каталог make уже начинает входить куда надо

===== building ./a =====
make[1]: Entering directory `F:/temp/1/a'
echo "building all"
make[1]: Leaving directory `F:/temp/1/a'

- непонятно.

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

Короче, то, что полетело у FAR-а в окне я еле законтрол-Цечил.

Ну значит точно баг.

 

Нет в жизни счастья. "не понос, так золотуха".

 

mkdir -p ./a/b ./a/c

mkdir из WinAVR:

mkdir (fileutils) 4.1
Written by David MacKenzie.

Copyright (C) 2001 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[.]
|
+--A
    |
    +-B
    |
    +-C

mkdir из msys:

mkdir (GNU coreutils) 5.97
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software.  You may redistribute copies of it under the terms of
the GNU General Public License <http://www.gnu.org/licenses/gpl.html>.
There is NO WARRANTY, to the extent permitted by law.

Written by David MacKenzie.
[.]
|
+--A
    |
    +-A
    | |
    | +-C
    |
    +-B

Я опять делаю что-то неправильно?