Ошибка в вычислениях адресов у GCC ?

Hi Alexey, hope you are having a nice day!

AB>> á ÏÎ ÎÅ ÕÍÅÅÔ, ÓÌÕÞÁÊÎÏ, ÚÁ×ÉÓÉÍÏÓÔÉ × ÁÓÓÅÍÂÌÅÒÎÙÈ ÆÁÊÌÁÈ AB>> ÎÁÈÏÄÉÔØ? AB> makedepend ÐÁÒÓÉÔ ÆÁÊÌ ËÁË cpp. é ÅÓÌÉ ÁÓÓÅÍÂÌÅÒÎÙÊ ÔÅËÓÔ AB> ÏÂÒÁÂÁÔÙ×ÁÅÔÓÑ cpp (ËÁË ÐÒÉÎÑÔÏ × gcc), ÔÏ ÏÎ ÂÕÄÅÔ ÏÂÒÁÂÁÔÙ×ÁÔØ AB> ÚÁ×ÉÓÉÍÏÓÔÉ.

AB> ôÏÌØËÏ Ñ ÎÅ ÉÓÐÏÌØÚÕÀ makedepend. õ ÍÅÎÑ Ó ÎÉÍ ËÁËÉÅ-ÔÏ ÐÒÏÂÌÅÍÙ ÂÙÌÉ. AB> ÷ÍÅÓÔÏ ÎÅÇÏ Ñ ÉÓÐÏÌØÚÕÀÀ gcc -M

WBR, AVB

Hi Sergey, hope you are having a nice day!

SP> Есть man. Поищи в инете mdepsrc.zip, makedepend.tgz и т.п. ... SP> Там как правило и дока бывает.

Hашел. Правда было легче сразу искать makedepend.1, т.к. тот файл, что лежит в этих архивах моим гзипом не распаковывается.

SP> Попробуй варианты:

SP> ... -o:o -f- >out.d SP> ... -o.o -fout.d

С этим разобрался. А вот список путей (-Ipath) понимать не хочет. Возможно из-за виндового формата (\ разделитель). Это лечится?

WBR, AVB

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

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

Fri, 04 Feb 2005 16:17:03 +0300 Sergei Tuchinski wrote to Harry Zhurov:

YK>>> help for >for.txt YK>>> WinNT и выше.

HZ>> Hаивный! Вот тебе краткий перечень функций. При чем тут твой for HZ>> убогий из HZ>> командного процессора винды? Что он может из приведенного ниже? Hичего!

HZ>> $(subst from, to, text)

ST> [..] ST> никто не мешает в батниках пользоваться утилитами системы, начиная от ST> банальных потоковых фильтров, типа grep и т.п., и заканчивая всякими ST> скриптовыми языками (тот же perl, скажем). собственно говоря, ты же тоже из ST> мейка привлекаешь внешние утилиты, для создания списка зависимостей, ST> например?вообще, по-моему, выбор инструмента - это больше вопрос привычки ST> (следствие воспитания), чем чего-бы то ни было другого

Если ты посмотришь выше по дискуссии на эту тему, то увидишь там:

========= begin ============== YK> Приведи пример задачи, которую нельзя решить батником.

Речь не столько о том, можно или нет, сколько об адекватности выбранного средства. Тем же батником ты можешь вызывать самописную утилиту, которая тебе обработает весь текст как надо. Только в случае make это не требуется. Пример: задаю директории, где лежат сорцы (из реального проекта): ========= end ================

Подчеркиваю, речь идет в первую очередь об адекватности средства. А реализовать можно массой способов. И то, что make самый распростаненный, указывает на его адекватность.

Hello, Yuriy! You wrote to Alexander Derazhne on Sun, 06 Feb 2005 01:09:21 +0300:

YK>>> Какие есть преимущеста у make перед bat _кроме_ обработки YK>>> зависимостей. YK>>> Hа всякий случай еще раз: _кроме_ обработки зависимостей.

YK>>> Сможешь привести еще хоть одно преимущество?

AD>> Автоматическое прерывание сборки при ошибке - без явного AD>> анализа errorlevel руками.

YK> Я не уверен, является ли это преимуществом. Предпочитаю смотреть YK> весь список ошибок.

У него есть ключик - не останавливаться после ошибок. Но _обычно_ длинная серия ошибок является наведенной, т.е. одна реальная ошибка влечёт за собой кучу других, которые исчезают после исправления первой. Впрочем, это касается в основном результатов компиляции одного файла, эти ошибки будут видны в любом случае. А ошибки в нескольких файлах часто связаны с ошибкой в общем хидере или с их зависимостью друг от друга.

With best regards, Alexander Derazhne

SP>> ... -o:o -f- >out.d SP>> ... -o.o -fout.d

AVB> С этим разобрался. А вот список путей (-Ipath) понимать не хочет. AVB> Возможно из-за виндового формата (\ разделитель). Это лечится?

У меня вроде все понял. Win ME. Если надо, стуки мне завтра в аську или по email, вышлю свой вариант маке-файла с использоваением makedepend

Sun Feb 06 2005 12:50, Harry Zhurov wrote to Yuriy K:

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 YK>> %%~nxJ for /F %%I in (pdir) do for %%J in (%%I\*.asm) do echo Asm YK>> %%~pJ %%~nxJ echo . YK>> @rem --------------------------------------

HZ> И что ты хотел этим продемонстрировать? Hу печатает оно

HZ> C \slon\1\src1\ fpga.c HZ> C \slon\1\src1\ main.c HZ> C \slon\1\src2\ data.c HZ> C \slon\1\src2\ code.c HZ> Asm \slon\1\src1\ 1.asm HZ> Asm \slon\1\src2\ 2.asm

HZ> Это что?

Это показывает, что цикл выполняется для каждого файла.

HZ> Список зависимостей? Или список файлов? И какому же HZ> компилятору ты собрался это передать?

ОК, будем разжевывать.

Вместо "echo С"/"echo Asm" ставится "call c.bat"/"call asm.bat" в которых вызывается компилятор С/Асм со всеми необходимыми опциями. Для _каждого_ файла из всех директорий проекта, как и требовалось. Путь и имя файла передаются как параметры батника.

Объектные файлы складываются в отдельную директорию для объектных файлов. потом при помощи link.bat:

echo # ----------------------------------- >files.lkf echo # files added by link.bat: >>files.lkf echo # >>files.lkf for %%I in (obj\*.o) do echo %%I >>files.lkf echo # ----------------------------------- >>files.lkf

создается список объектных файлов для передачи линкеру.

HZ> То, что я привел, делает список HZ> исходных файлов без директорий и прочего. И делает его для того, чтобы HZ> потом сделать список зависимостей:

HZ> # prepare object files lists from sources

HZ> c_obj = $(c_src:.c=.$(OBJ_EXT)) HZ> cpp_obj = $(cpp_src:.cpp=.$(OBJ_EXT)) HZ> asm_obj = $(asm_src:.$(ASM_EXT)=.$(OBJ_EXT))

HZ> # all object files HZ> all_obj = $(c_obj) $(cpp_obj) $(asm_obj)

HZ> Какими командами тут в батнике надо порулить, чтобы получить то же HZ> самое?

echo src1 >pdir echo src2 >>pdir del c_obj del asm_obj del all_obj for /F %%I in (pdir) do for %%J in (%%I\*.c) do echo %%~nJ.o >> c_obj for /F %%I in (pdir) do for %%J in (%%I\*.asm) do echo %%~nJ.o >> asm_obj copy /b c_obj + asm_obj all_obj

HZ>>> С помощью батника всю эту функциональность не реализовать. И не HZ>>> надо говорить, что она не нужна. Очень даже нужна.

YK>> Приведи пример. Hе забудь, что обсуждается _сборка_ проекта.

HZ> Уфф. Вот из мейкфайла для сборки проектов на AVR. Производится HZ> автоматическая генерация опций и ключей из типа кристалла (список HZ> кристаллов несколько устарел, т.к. уже приличное время с АВРами не HZ> работаю).

HZ> v0_devices = 2313 2323 2333 2343 4433 tiny10 tiny11 tiny12 tiny15 tiny22 HZ> v1_devices = 4414 4434 8515 8535 m8 HZ> v3_devices = m103 m161 m163 m603 m16 m32 m64 m128

HZ> small_flash_devices = m161 m163 m603 m16 m32 m64 HZ> enhanced_core_devices = m161 m163 m8 m161 m163 m603 m16 m32 m64

HZ> ifeq ($(DEVICE), $(findstring $(DEVICE), $(v0_devices))) HZ> PROCESSOR_OPTION = 0 HZ> else HZ> ifeq ($(DEVICE), $(findstring $(DEVICE), $(v1_devices))) HZ> PROCESSOR_OPTION = 1 HZ> else HZ> ifeq ($(DEVICE), $(findstring $(DEVICE), $(v3_devices))) HZ> PROCESSOR_OPTION = 3 HZ> else HZ> Error_msg = "Invalid DEVICE specification: $(DEVICE)" HZ> endif HZ> endif HZ> endif

HZ> ifeq ($(DEVICE), $(findstring $(DEVICE), $(small_flash_devices))) HZ> SmallFlash = -sf HZ> else HZ> SmallFlash = HZ> endif

HZ> ifeq ($(DEVICE), $(findstring $(DEVICE), $(enhanced_core_devices))) HZ> EnhancedCore = -ec HZ> else HZ> EnhancedCore = HZ> endif

HZ> MCU = $(DEVICE) HZ> LINKER_CMD_FILE = avr$(DEVICE)$(MEMORY_MODEL).xcl HZ> LINKER_DEVICE_FILE = lnk$(DEVICE)$(MEMORY_MODEL).xcl HZ> LIB_FILE = HZ> dl$(PROCESSOR_OPTION)$(MEMORY_MODEL)$(EnhancedCore)$(SmallFlash).$(OBJ_EX HZ> T)

HZ> И так далее... Это и подобное автоматом по имени кристалла, HZ> указанного в проекте, генерит опции для компилятора и линкера - всякие HZ> там enhanced core и small flash, формирует правильные имена линкерных HZ> скриптов и т.д.

HZ> Приведенный выше скрипт для девайса m16 сгенерит:

HZ> MCU = m16 HZ> LINKER_CMD_FILE = avrm16s.xcl HZ> LINKER_DEVICE_FILE = lnkm16s.xcl HZ> LIB_FILE = dl3s-ec-sf.r90

HZ> Теперь твоя очередь. Hаписать, скорее всего, можно, только как это HZ> будет выглядеть?! Вышеприведенное, имхо, вполне наглядно и прозрачно - HZ> даже не зная особо синтаксиса, вполне понятно, что делается и как. Все HZ> это снова к вопросу об адекватности.

_Такое_ я писать просто не буду. Бессмысленная трата времени.

Линкерные файлы зависят не только от девайса, но и от проекта, поэтому для каждого проекта (точнее железа) пишется линкерный файл. Свой. Уникальный. Даже в случае использования IDE для компиляции. По той простой причине, например, что в проекте есть бутлоадер.

Hовое железо разрабатывается несколько дольше, чем два дня, поэтому написать для него один раз линкерный файл и проверить/настроить параметры компилятора проблемы не составляет. Для десятка проектов это займет меньше времени, чем отладка твоего мейкфайла.

Кстати, где в твоем мейке указан объем внешнего ОЗУ для 8515/m128?

WBR, Yuriy

Sun Feb 06 2005 08:57, Andy Mozzhevilov wrote to Yuriy K:

AD>>> Автоматическое прерывание сборки при ошибке - без явного анализа AD>>> errorlevel руками.

YK>> Я не уверен, является ли это преимуществом. Предпочитаю смотреть весь YK>> список ошибок.

AM> в маке можно и не прерывать при желании, указывая "-" перед вызовом AM> компилятора.

То же самое делается в батнике анализом errorlevel. Маке делает так же.

AM> Hу а вообще, да, маке - он на то и маке, чтобы делать именно AM> маке проека вместо build all. Это его основное назначение.

C этим никто и не спорил. :-))

WBR, Yuriy

YK>>> Hеактуально для "build all" AK>> Полная пересборка наших проектов (mega128, >200 файлов) MP> А как можно в этих 200 файлах разбиратся, что в каком? А зачем???

MP> Hу положим в одном MP> исходнике, пусть он хоть мег, есть функция поиск текста. Есть такая чудная утилитка grep. Даже шла (вместе с make) в комплекте с борландовскими C-компиляторами и даже у борладовской досовской IDE она была где-то в меню прописана.

У меня (ну вот, опять сказал "у меня", сейчас опять прибежит кто-то, кому больше нечего сказать кроме "так мож тебе памятник поставить" :-) под MS DOS в редакторе Qedit (позже он же назывался Jedit) был на макрос на ShiftF9

#f9 MacroBegin MarkWord Copy EditFile '$.$' Return Quit GSave Dos 'grep>$.$ -n ' Paste ' *.c* *.h*' Pause Return Return HorizontalWindow '$.$' Return

Он брал слово под курсором и вызывал grep для поиска его во всех исходниках каталога, выдачу grep (имена файлов, за ними номера строк и сами строки с этим словом) перенаправлял в файл и открывал этот файл в новом окне. И ещё был макрос, который хватал слово под курсором и открывл файл с таким именем - это уже для хождения по выдаче grep. И это было под MS DOS в редакторе в 30KB размером! (пожатом pklite). Сейчас-то нормальный программистский редактор должен уметь гораздо больше!

Сейчас работаю с MED, так у него ещё проще - есть section browser, показывающий список "секций" файлов проекта с указанием имени файла (полного, с каталогом), номера строки и позволяющий туда перейти. По горячей клавише можно перейти в нужный файл на определение секции, на имени которой сейчас стоит курсор, потом вернуться назад. Вид секции задаётся, поэтому для AHDL у меня секциями объявлены constant, define и subdesign. Для ассемблера, скажем, секциями можно объявить хоть и метки. Для C/C++ у него встроенный парсер секций, который их делит на define, typedef/классы, функции. И это "простенький" редактор, инсталляшка которого занимает полтора мегабайта, "толстые" "IDE" типа slikedit-a или eclipse явно умеют гораздо больше. Да даже простой поиск текста в MED может быть в текущем файле, в открытых и выделенных файлах, во всех открытых файлах, в файлах проекта и в любом указанном каталоге [с подкаталогами]. Так что поиск - не аргумент, и я не пойму, зачем держать всё в одном мегабайтном файле? (кроме желание на полную катушку использовать умение, скажем, IAR C оптимизировать размер за счёт выделения похожих мест в подпрограммы) Я уже не говорю про библиотеки в исходниках, которые разделяются между разными проектами.

MP> И вот еще - изменил я скажем 1 файл и хочу пересобрать. Откуда make MP> знает, что MP> я изменил именно этот файл? Усложним задачу - я изменил 10 файлов и хочу MP> пересобрать проект, как make выделит 10 из 190?

Ещё более усложним задачу, изменили один .h или там .inc файл, который включается в 10 файлов из 190 файлов проекта.

Нам нужен foo.obj Смотрим по заданным зависимостям, от кого он зависит - от foo.c и от moo.h (который включается в foo.c). Сверяем даты модификации foo.obj и всех файлов, от которых он зависит. Если foo.obj свежее всех, то ничего не делаем. Иначе перекомпилируем его.

И так 190 раз, но только для 10 файлов будет вызвана перекомпиляция.

На самом деле может быть ещё сложнее, скажем, тот же moo.h может генерироваться из какого-то другого файла. *Например*, один сферический конь в вакууме пишет программу на C для встроенного микропроцессора, а его коллега пишет на Delphi для персоналки. Обмен по COM-порту, есть формат пакета, константы типов пакетов. Из заголовочного файла дельфийского сферического коня каким-нибудь awk-ом генерируется заголовочный файл для сишного сферического коня - чтобы не надеяться на память и ручной перенос. Зависимости будут foo.c -> moo.h -> moo.inc и даты будут сверяться сначала для moo.h и moo.inc, потом для foo.c и moo.h.

wbr, p.s. дадада, это всё можно сделать батником. Только начиная с какого-то объёма через makefile это сделать

DO> А в нескольких такой функции нет? Hу grep запусти, если редактор многофайловый DO> поиск не поддерживает. Хотя на фига для мелкого восьмиразрядного контроллера DO> плодить такое количество файлов я тоже не понимаю, но видимо привычка DO> такая. "Кому как удобнее". Кому-то удобнее весь проект держать в одном файле. У меня и для меги8, а не 128 - запросто может десяток файлов набежать. А мне удобно иметь файл 7seg.h, в котором расписаны битовые маски для 7-сегментного индикатора для цифр и букв (ну там SEGS_b SEGS_C SEGS_c SEGS_O SEGS_o SEGS_P SEGS_r и т.п.) один на все проекты, на всех платах. Для конкретной платки с клавиатурой, индикатором и RS232 разделять между всеми проектами на этой платке её "видеобиос" (два файла, .c и .h) и отдельно её "COM-биос" (ещё два файла, но не во всех проектах нужен). Отдельно лежат crc16.c и crc16.h, мне удобно включать эти файлы и в проект на AVR, и в управляющую dll-ку для WIN32. С той же целью (пихать и в .hex и в .dll) в отдельном файле packets.h лежит описание формата пакета и константы типов пакетов - общие для всех систем, обменивающихся по этому протоколу. Отдельно лежит eunit.h - коды и расшифровка полей для пакета команды для конкретной системы, работающей через этот протокол. И вот ЕЩЁ НЕ НАЧАТ конкретный проект, а уже в дереве каталогов проекта лежат девять библиотечных файлов, врочем, компилируются из них только три, но общее число таки девять. И объединять их в два-три больших я особого смысла не вижу. Ну можно было оба "биоса" объединить в один файл и дать UART-ную часть под условную компиляцию. Непринципиально.

Hello, Andy Mozzhevilov !

А вот не факт. Я в зависимости от ситуации и настроения пользуюсь и make и bat и ide.

С уважением, Дима Орлов.

Hello, Aleksandr Konosevich !

Точнее поносевичей.

С уважением, Дима Орлов.

SP>> ... -o:o -f- >out.d SP>> ... -o.o -fout.d

AB> С этим разобрался. А вот список путей (-Ipath) понимать не хочет. AB> Возможно из-за виндового формата (\ разделитель). Это AB> лечится? А говорить ему пути с прямыми слешами не пробовал? Виндовый рар понимает их, скажем, такое отработает

rar a ../foo dir1/subdir1/*.*

а раз уж софтина привыкла к прямым - что её мучить?

wbr,

Hello, Oleksandr!

Вcк Фев 06 2005, Oleksandr Redchuk писал к Maxim Polyanskiy по поводу "Re: Ошибка в вычислениях адресов у GCC ?." MP>> А как можно в этих 200 файлах разбиратся, что в каком? OR> А зачем??? Элементарно - для поддержки проекта. Я тут блуждал в 20 файлах - плюнул, скомпилил их и дизассемблировал в АСМ, быстро по листингу обозвал все процедуры и переменные и так на душе сразу полегчало. Все без проблем находится в одном исходнике размером меньше в 4 раза чем было и понятнее в 5 раз. MP>> Hу положим в одном исходнике, пусть он хоть мег, есть функция поиск MP>> текста. OR> Есть такая чудная утилитка grep. Даже шла (вместе с make) в комплекте OR> с борландовскими C-компиляторами и даже у борладовской досовской IDE OR> она была где-то в меню прописана. OR> У меня (ну вот, опять сказал "у меня", сейчас опять прибежит кто-то, OR> кому больше нечего сказать кроме "так мож тебе памятник поставить" :-) OR> под MS DOS в редакторе Qedit (позже он же назывался Jedit) был на OR> макрос на ShiftF9 Был у меня qedit году в 93-м вроде. Hу то был дос - тяжелое детство, редакторы типа ncedit которые с файлами больше 100к криво работали. Там то хоть было оправдание этому. OR> Он брал слово под курсором и вызывал grep для поиска его во всех OR> исходниках каталога, выдачу grep (имена файлов, за ними номера строк и OR> сами строки с этим словом) перенаправлял в файл и открывал этот файл в OR> новом окне. Криво и неудобно. OR> И ещё был макрос, который хватал слово под курсором и открывл файл с OR> таким именем - это уже для хождения по выдаче grep. А я тогда искал входы в процедуры через ctrl+f в том-же qedit в исходнике максимум из 3 файлов и не знал про существование таких заморочек ;) OR> Так что поиск - не аргумент, и я не пойму, зачем держать всё в одном OR> мегабайтном файле? (кроме желание на полную катушку использовать OR> умение, скажем, IAR C оптимизировать размер за счёт выделения OR> похожих мест в подпрограммы) Hе знаю - привычно как-то. Я всю осмысленную инфо держу всегда в одном файле, выношу только то, что не желательно видеть и не желательно повредить случайным удалением строки (массивы данных, типа фонтов или кода чужого проца, или картинки фентифлюшки, итп). OR> Смотрим по заданным зависимостям, от кого он зависит - от foo.c и от OR> moo.h (который включается в foo.c). OR> Сверяем даты модификации foo.obj и всех файлов, от которых он OR> зависит. Если foo.obj свежее всех, то ничего не делаем. Иначе OR> перекомпилируем его. OR> И так 190 раз, но только для 10 файлов будет вызвана перекомпиляция. Я почему-то не уверен что все это радикально ускорит работу.

Среднепаршивый проект собирается весь за секунды, а на изучение синтаксиса make для создания правильных файлов в целом можно не один день жизни потратить. Выгода сомнительна. Лучше купить лишний жирный процессор винт побыстрее и памяти побольше ;)

Опять-же я точно знаю, что у меня это может глючить. У меня часы t-mail синхронизирует и бывают глюки (не у меня) в результате которых время может на час туда-сюда ходить, предположим, что это случится при работе с проектом, в результате, что-то не будет пересобрано, и программа зашитая в контроллер не будет работать как надо - я потрачу лишнее время не зная истинной причины глюка, а это уже называется головняки. OR> *Hапример*, один сферический конь в вакууме пишет программу на C для OR> встроенного микропроцессора, а его коллега пишет на Delphi для OR> персоналки. Обмен по COM-порту, есть формат пакета, константы типов OR> пакетов. Из заголовочного файла дельфийского сферического коня OR> каким-нибудь awk-ом генерируется заголовочный файл для сишного OR> сферического коня - чтобы не надеяться на память и ручной перенос. OR> Зависимости будут foo.c -> moo.h -> moo.inc и даты будут сверяться OR> сначала для moo.h и moo.inc, потом для foo.c и moo.h. Вот геморой. Я сферический конь - сейчас в одно рыло пишу софт работающий с

И все-же в системе с PIC16 проще все иметь в одном единственном *.ASM файле и собирать его в MPASM одной строчкой в BAT. Та-же фигня с MASM. Какие нибудь дельфисты вообще все из IDE собирают и не жужжат, короче куча людей прекрасно обходится без MAKE.

OR> /* Oleksandr Redchuk, Brovary, Ukraine */ WBR! Maxim Polyanskiy.

Приветствую Вас, Aleksandr!

Однажды 06 Фев 05 в 12:35, Aleksandr Konosevich писал(а) к Vitaliy Romaschenko...

AK>>> ЗЫ "Радение за чистоту pядов" паpаллельно с испpажнением под AK>>> себя - чесслово, сие не укладывается в моей голове ... ;) AK>

VR>> Уважаемый хочет услышать ответ на это письмо? AK>

AK> Уважаемый будет вполне доволен, ежели тема не будет пpодолжена и мы AK> тихо pазбpедёмся по своим углам, бо "засиpанцев" тут, как вижу, и так AK> хватает. AK>

AK> ЗЫ Хотя если тебе по вкусу шоу вpоде "Оpлов vs Шепелев" - можешь AK> пpодолжать ;)

За кого будешь игpать? :) Ладно, действительно мусоpа много. Hо свое мнение я уже высказывал. В этой эхе флейм довольно миpно pассасывается и все идут пить (чай).

С уважением, Виталий.

... -|O|-

Dmitry, ты ещё здесь сидишь?

Среда Февраль 02 2005 21:06, Dmitry Ponyatov wrote to George Shepelev:

DP>> если не можешь прочитать/написать Makefile -- как DP>> программист ты не существуешь. GS>> О, круто! Даже представить трудно, сколько людей внезапно стали GS>> "непрограммистами" ;))) DP> а они ими были ?

Да.

DP> в случае если кодер не может разобраться в структуре простого DP> Makefile, написанного руками (я же не предлагаю лезть в автогенеренный DP> для толстенного проекта) -- нужно думать о смене профессии

Программист не обязан быть именно кодером. Сюрприз? ;)

Георгий

Здравствуйте.

YK>>> Hеактуально для "build all" AK>> Полная пересборка наших проектов (mega128, >200 файлов) MP> А как можно в этих 200 файлах разбиратся, что в каком?

Лехко.

MP> Hу положим в одном исходнике, пусть он хоть мег, есть функция MP> поиск текста. Если это совсем левые библиотеки не требующие MP> лазанья в них - то почему их 200 штук?

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

MP> И вот еще - изменил я скажем 1 файл и хочу пересобрать. Откуда MP> make знает, что я изменил именно этот файл? Усложним задачу - я MP> изменил 10 файлов и хочу пересобрать проект, как make выделит 10 MP> из 190?

По дате модификации файлов. Ты что, с Луны свалился ?

Здравствуйте.

AVB>>> у меня не получилось. Валилось в случайном порядке при AVB>>> незначительных модификациях анализируемого исходника. AK>> Могу свой выслать. Пришлось написать самому после серии неудачных AK>> попыток использовать готовое.

AVB> А он не умеет, случайно, зависимости в ассемблерных файлах находить?

я его для проектов на IAR C использую, а там используется Си-препроцессор и для ассемблерных файлов ;)

Здравствуйте.

SP> Он у тебя и дефайны обрабатывать умеет ?

Зачем ?