Fri, 04 Feb 2005 17:26:02 +0300 Yuriy K wrote to Harry Zhurov:
SP>>>>>> - существует под все платформы YK>>>>> Для embedded - неактуально. HZ>>>> Это делает инструмент широкораспространенным, что положительно HZ>>>> сказывается на его поддержке, минимизации глюков, полноте документации HZ>>>> и проч.
YK> Кстати, о минимизации глюков:
YK> ----------------------------------------------------------------------RU.EM YK> BEDDED YK> ----------------------------------------------------------------------From: YK> Alexey Krasnov snipped-for-privacy@cheboksary.org YK> ... SP>>> Есть специальная утилита makedepened, существует под все платформы.
AVB>> Hадеюсь он работает нормально? А то здесь уже ссылка на какой-то AVB>> makedepend пробегала, заставить его работать стабильно AVB>> у меня не получилось. Валилось в случайном порядке при незначительных AVB>> модификациях анализируемого исходника.
YK> Могу свой выслать. Пришлось написать самому после серии неудачных попыток YK> использовать готовое. YK> --------------------------------------------------------------------------
Ты и раньше внимательностью не отличался... Я про make, ты про что? К чему эта цитата про какую-то глючную (сколько я этих makedep'ов, makedepend'ов, makedepend2'ов и прочих mdep'ов перепробовал - ни одна нормально не работает) утилиту, писанную каким-то челом для себя. Да мало ли кто что для себя пишет. Эта утилита (весь их сонм) не имеет никакого отношения к make. Даже к гнутому.
HZ>> Hо если брать именно пользователей make, то что-то мне думается, что HZ>> большинство их сидит не под виндой.
YK> Еще бы. Им просто негде взять приличную IDE. :-))
Конечно. И не только им - ведь приличных IDE просто не существует.
[...]
YK> Без проблем:
YK> @rem -------------------------------------- YK> @echo off YK> echo . YK> echo src1 >pdir YK> echo src2 >>pdir YK> for /F %%I in (pdir) do for %%J in (%%I\*.c) do echo C %%~pJ %%~nxJ YK> for /F %%I in (pdir) do for %%J in (%%I\*.asm) do echo Asm %%~pJ %%~nxJ YK> echo . YK> @rem --------------------------------------
И что ты хотел этим продемонстрировать? Ну печатает оно
C \slon\1\src1\ fpga.c C \slon\1\src1\ main.c C \slon\1\src2\ data.c C \slon\1\src2\ code.c Asm \slon\1\src1\ 1.asm Asm \slon\1\src2\ 2.asm
Это что? Список зависимостей? Или список файлов? И какому же компилятору ты собрался это передать? То, что я привел, делает список исходных файлов без директорий и прочего. И делает его для того, чтобы потом сделать список зависимостей:
# prepare object files lists from sources
c_obj = $(c_src:.c=.$(OBJ_EXT)) cpp_obj = $(cpp_src:.cpp=.$(OBJ_EXT)) asm_obj = $(asm_src:.$(ASM_EXT)=.$(OBJ_EXT))
# all object files all_obj = $(c_obj) $(cpp_obj) $(asm_obj)
Какими командами тут в батнике надо порулить, чтобы получить то же самое?
И, кстати, про "малопонятный" и "дебильный" синтаксис make. По ужасности синтаксиса приведенный тобой фрамент неудержимо и уверенно лидирует в сравнении с тем же из make. И это на такой простой операции, как формирование списка файлов (который в приведенном тобой примере не сформирован). Что же говорить про более сложные места?!
YK>>> help for >for.txt
HZ>> Hаивный! Вот тебе краткий перечень функций. При чем тут твой for HZ>> убогий из командного процессора винды? Что он может из приведенного ниже? HZ>> Hичего! HZ>> ...
YK> Что из этого нужно для _сборки_ проекта? Приведи пример.
Много что. Для обработки зависимостей. Для обработки входных параметров и опций и генерации ключей и опций для тулзов.
HZ>> С помощью батника всю эту функциональность не реализовать. И не надо HZ>> говорить, что она не нужна. Очень даже нужна.
YK> Приведи пример. Hе забудь, что обсуждается _сборка_ проекта.
Уфф. Вот из мейкфайла для сборки проектов на AVR. Производится автоматическая генерация опций и ключей из типа кристалла (список кристаллов несколько устарел, т.к. уже приличное время с АВРами не работаю).
v0_devices = 2313 2323 2333 2343 4433 tiny10 tiny11 tiny12 tiny15 tiny22 v1_devices = 4414 4434 8515 8535 m8 v3_devices = m103 m161 m163 m603 m16 m32 m64 m128
small_flash_devices = m161 m163 m603 m16 m32 m64 enhanced_core_devices = m161 m163 m8 m161 m163 m603 m16 m32 m64
ifeq ($(DEVICE), $(findstring $(DEVICE), $(v0_devices))) PROCESSOR_OPTION = 0 else ifeq ($(DEVICE), $(findstring $(DEVICE), $(v1_devices))) PROCESSOR_OPTION = 1 else ifeq ($(DEVICE), $(findstring $(DEVICE), $(v3_devices))) PROCESSOR_OPTION = 3 else Error_msg = "Invalid DEVICE specification: $(DEVICE)" endif endif endif
ifeq ($(DEVICE), $(findstring $(DEVICE), $(small_flash_devices))) SmallFlash = -sf else SmallFlash = endif
ifeq ($(DEVICE), $(findstring $(DEVICE), $(enhanced_core_devices))) EnhancedCore = -ec else EnhancedCore = endif
MCU = $(DEVICE) LINKER_CMD_FILE = avr$(DEVICE)$(MEMORY_MODEL).xcl LINKER_DEVICE_FILE = lnk$(DEVICE)$(MEMORY_MODEL).xcl LIB_FILE = dl$(PROCESSOR_OPTION)$(MEMORY_MODEL)$(EnhancedCore)$(SmallFlash).$(OBJ_EXT)
И так далее... Это и подобное автоматом по имени кристалла, указанного в проекте, генерит опции для компилятора и линкера - всякие там enhanced core и small flash, формирует правильные имена линкерных скриптов и т.д.
Приведенный выше скрипт для девайса m16 сгенерит:
MCU = m16 LINKER_CMD_FILE = avrm16s.xcl LINKER_DEVICE_FILE = lnkm16s.xcl LIB_FILE = dl3s-ec-sf.r90
Теперь твоя очередь. Написать, скорее всего, можно, только как это будет выглядеть?! Вышеприведенное, имхо, вполне наглядно и прозрачно - даже не зная особо синтаксиса, вполне понятно, что делается и как. Все это снова к вопросу об адекватности.