Доброго времени суток Уважаемые.
Есть 2 проэкта с одним kommand_descript.h Пытаюсь поставить полный путь, в ответ получаю ругань.
Можно ли как в досе? Типа не весь путь а только переход из папки в папку. Правда напрочь забыл, как это в досе делается.
Желательно типа так:
с:\xx\xx\трагет_фолдер\проэкт1\ сдесь лежит весь проэкт1
с:\xx\xx\трагет_фолдер\проэкт2\ сдесь лежит весь проэкт2
с:\xx\xx\трагет_фолдер\общие_файлы\ сдеесь лежит kommand_descript.h
Сильно не пинайте. Спасибо!

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

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

Чтобы пути были относительно проекта, можно использовать $PROJ_DIR$, примерно так:
..\$PROJ_DIR$\ОбщиеФайлы\



Только что проверил, в #include "" работает и полный и относительный путь. Слэши не забыли проэкранировать?

Я в своих проектах использую относительные пути. Вот здесь я уже приводил пример. А вот здесь приводил пример используемой мной структуры каталогов для проектов. Подобную структуру (вкупе с относительными путями) довольно удобно использовать при переносе проектов в любое другое место.

Чувствуется системный подход.

Как это сочетается с системой контроля версий?

Никак. Потому что не пользуюсь.

Встерчал такую огранизацию проектов - все из одного корня растет. И под контролем версий - вся структура помещается в репозиторий. Пользуются, другого не хотят.

Тоже годится, но только для одной задачи - архивирования на века.
А для оперативной работы с возможной отмоткой назад каждого проекта в отдельности - увы-увы...

Тем не менее успешно работают, другого не хотят. Хотя по мне так это не удобственно - у меня проекты живут сами по себе, к общей структуре не привязаны. А общие вещи линкуются к ним через переменные окружения.

А в чем сложность, собственно?

Тоже пользовался такой структурой, пока не выяснилось, что в одном проекте может быть два и больше процессоров разных семейств, а после этого выяснилось, что очень удобно в одном месте хранить и все исходники для процессоров, и сопутствующие писишиные программы с исходниками и схемы/разводки и документацию. Т.е.В таком виде оказалось очень удобно проекты и под контролем версий держать, и в .bat прописывать относительные пути к экзешникам, которые компилятся из писишных исходников и лежат в своих каталогах (достаточно под контролем версий держать только исходники). И при необходимости можно одной командой достать из репозитория весь проект на нужный момент времени. И общие для проекта файлы гармонично ложатся в общие каталоги (например Hardware.h кладется в "Проц1" и легко доступен из Bootloader и Firmware(#include "..\Hardware.h"), Hardware.h для второго проца в "Проц2", заголовочный файл для обмена по шине в Software и т.д.)

То ли я не умею готовить, но у меня вот эти две папки
|->_INC <-общие хидеры проектов
|->_SRC <-общие исходники проектов
не получаются статическими, они тоже изменяются. В реальной жизни то ошибка находится, то ли стремление улучшить проснется.

Получается такая последовательность:
- общая часть ver 1
- проект A ver 1
- проект B ver 1
Произвели 100 устройств проекта A.
- корректировали общую часть ver 2
- корректировали проект 2
Произвели 100 устройств по проекту B.
Корректировали проект A ver 2.
Произвели 100 устройств проекта A
Пришла жалоба от клиента по ошибке в проекте A из первой партии.
Начинаем разбираться. Вернули версию проекта A на 1 - все правильно. Но результат компиляции другой, так как была изменена общая часть. Концов не осталось.

Ну когда вы метку создаете, надо делать это одновременно и на общую часть и на проект. Клиенту ушла версия 1. Общая часть правилась, проект В правился. Появилась версия 2 (общая часть + проект В). Жалоба на проект А. Восстанавливаем версию 1 (проект А версии 1 + общая часть версии 1)

В корневых хидерах у меня находятся такие глобальные и немодифицируемые вещи как, например, типы переменных. А то, что как-то платформеннозависимо и/или подвергается модификации в проектах не должно находиться в корне. Например, если у вас определен адрес вызова глобальной функции, то в модифицируемых версиях извольте выкручиваться за счет каких-то дополнительных проверок внутри самой функции, а адрес вызова не трожьте! Как учил меня коллега, писавший операционки начиная с конца 80-х годов, в описании каждого модуля должен быть текстовый комментарий состояния его. Примерно что-то типа такого
1) не подлежит модификации,
2) модифицируемый только в исключительном случае,
3) утвержден для публикации,
4) подлежит утверждению,
5) в разработке,
6) альфа-версия.
И если проект ведет более, чем один программист, то данная концепция просто необходима. Система контроля версий это конечно хорошо, но согласованность при разработке в команде важнее.
P.S. конечно в проектах, которые выполняю единолично, я позволяю себе больше вольностей

В общем, может это уже и не в топик данной темы, но все же отвечаю.
Чтобы такого как у вас не случалось, общие части, которые могут быть использованы в разных проектах должны в каждом проекте иметь свои локальные копии, находящиеся под контролем системы CVS (или подобной).
Именно система контроля версий и позволяет это сделать достаточно безболезненно, а вот если вы не пользуете систему контроля версий, тогда действительно синхронизировать общие исходники для разных проектов - тот еще гемор.
В этом случае будет примерно так:
- выпустили релиз проекта A ver 1 "А1" (с общей частью "common 1")
- выпустили релиз проекта В ver 1 "В1" (с общей частью "common 1")
"А1" и "В1" здесь надо воспринимать как тэги, однозначно идентифицирующие набор всех файлов проекта, как из common части, так и из файлов, относящихся исключительно к проекту.

Произвели 100 устройств проекта A, релиз "А1".

- корректировали общую часть на "common 2" в проекте В.
- выпустили релиз проекта В ver 2 "В2" (с общей частью "common 2")
Произвели 100 устройств по проекту B, релиз "В2".

- приступили к коррекции проекта "А", до кучи обновили common часть на "common 2".
- выпустили релиз проекта А ver 2 "А2" (с общей частью "common 2")
Произвели 100 устройств проекта A, релиз "А2".

Пришла жалоба от клиента по ошибке в проекте A с релизом "А1".
Начинаем разбираться. Извлекли версию проекта а по тэгу релиза "А1".
В локальной копии будут присутствовать исходники common версии "common 1".
Результат компиляции до байта совпадает. Конец найден, и виноватый тоже





Если проект ведет более чем один программист система контроля версий - суровая необходимость.
Иначе:
- Вася, ты менял исходник в таком то каталоге?
- Да, тебе кинуть?
- Конечно, еще месяц назад надо было.
- Да я же в отпуске был. Блин, сетевой каталог не открывается, давай флешку...

Ну, с виноватыми обычно проблем не бывает
Признаюсь, инструкцию по SVN курил "не в затяжку", пользуюсь очевидными функциями. Про такую комбинацию не думал.
Мне кажется, что могут быть проблемы, если отмотать версию в такой локальной копии common назад и случайно закоммитить. Но нужно подумать и попробовать. Спасибо.

Я пользуюсь на данный момент CVS, как оно реализуется в SVN не совсем представляю, поскольку доку по SVN меня несколько насильно заставили покурить некоторые присутвующие в том числе здесь товарищи . И в данный момент она недокурена пока.
В CVS при извлечении по тэгу локальную версию закомитить будет нельзя, поскольку на ней будут так называемые липкие метки. Если нужно будет, допустим, выпустить релиз на основе именно этой комбинации исходников, ну типа исправить только тот небольшой баг, то тогда делается ветвь в проекте на основе текущей версии извлеченных исходных текстов и она уже комитится, но не мешает основному стволу разработки. При желании потом изменения можно внести на ствол.

Вот и плохо! Но тебя раззи заставишь, если ты не хошь...


В Subversion принципиально это не отличается.

Спасибо за такое количество ответов!


Беру путь из заголовка в окошке. Что значит "Слэши проэкранировать?"

#include "c:\\folder1\\folder2\\myFile.h"
#include "..\\..\\folder2\\myFile.h"

Не нада екранироват
Вот и пример из рабочего проекта


А у меня ест вопрос. Возможно ли в сорс използовать переменньi окружения?
Не получается никак у меня.

Нет, конечно, но их можно и нужно использовать для передачи параметров компилятору через командную строку. Какие проблемы?

Нет проблем. Хотелос написат что то типа

#include "$SOURCE_CODE_DIR$\ARM\ATMEL\i2c.c"

куда SOURCE_CODE_DIR переменная окружения. Но ето вообщем не работает в никаком компиляторе.
Но можно жит и без етого

Компилятору в командную строчку что-то типа -I $SOURCE_CODE_DIR$
И все.

Да ето и ползуюс.
Но делаю из опции проекта -> C/C++ Compiler -> Preprocessor -> Additional include directories

ето включает их точно с -I.

но #include "$SOURCE_CODE_DIR$\ARM\ATMEL\i2c.c" нравится болше Но уви....

Мне вот вообще больше нравится
#include "i2c.h"
безотносительно того, где оно там закопано, в каких папках проекта.
Поэтому опция -I в этом отношении рулит.

Но если окажется что в прописаньих через -I пути ест 2 фаил с ето имя,будет използоватся первъи из них кто компилер нашел. Для маленких проект ето не проблем но когда проект становится болшой и вероятност таких проблем возрастает.

Это уже проблема организации структуры проетка.

Действительно, работает Не знал...

Причем 'полный' вариант, который Nikola Kirov предпочитает:
#include "./ARM/ATMEL/i2c.h"
Тоже возможен.

Вообще-то, если Вы говорите о закладке:
Workspace -> <Имя проекта>->Options->C/C++Compiler->Preprocessor

То там в Aditinal include directories:(one per line) путь к include файлам надо указывать без точек перед $POJ_DIR$.... Примерно вот так:


Вышеприведенная запись заставляет искать include-файлы в:
1) Каталоге с самим проектом
2) подняться на 2 вышележащих каталога, найти там директорию Include и поискать инклюдники в ней

Приведенный выше случай каталогов выглядит вот так:

В каталоге с проектом include-файлы ищутся по умолчанию и без записи $PROJ_DIR$\

Проверил Ваше утверждение и удалил верхнюю строку, где один только $PROJ_DIR$\ и получил сразу ненайденные *.h файлы, которые лежат в дирректории самого проекта...

Вывод - ваше предположение - ошибочно как минимум на моей версии...

Проверьте как минимум стандартный tutorial от IAR и убедитесь в обратном.
Я, в свою очередь, имею несколько маленьких проектов, где все исходники и хедеры находятся в папке с проектом. НИКОГДА не снабжал свои проекты строкой $PROJ_DIR$\ (по началу просто не знал о ней). Все файлы видятся с любой версией продукта.
Дело может быть вот в чём, согласно старым добрым Кернигану и Ричи строки #include "file.h" ищут файлы в той же директории, что и исходный файл, строки #include <file.h> ищут файл в директории тулчейна.
Возможно, что Ваши исходники (в отличие от хедеров) лежат не в директории проекта.

Дело в том, что исходники файлов и файл проекта лежат в разных директориях в общем случае - это ни Кернигану, ни Ричи не противоречит... Посмотрите например стандартный проект FreeRTOS. На нем все и проверялось. Проект и пара настроечных файлов лежать в корне - рядом с файлом RTOSDemo.eww в директории ARM9_STR91X_IAR, а исходные файлы в поддиректориях этого проекта - ниже по дереву. Как только убирается $PROJ_DIR$\ - так сразу настроечные файлы FreeRTOSConfig.h, лежащие рядом с RTOSDemo.eww - перестают находиться. Вы же говорите о других файлах - которые расположены в разных подиректориях проекта ниже корневой проекта. Совершенно нормальное положение для файлов любого достаточно большого проекта. И ни к тулчейну ни к исходныс *.c файлам с соответствующим им - упомянутый файл FreeRTOSConfig.h отношения не имеет...

Так что все-таки IAR не зря в свои примеры сам включает $PROJ_DIR$\ - я и взял указанный выше пример - прямо из его exemple-сов и хотя в нем все в одной подиректории - сами IAR-овцы вставили эту строку. В простейшем случае - она возможно и не нужна, но в случае развесистого дерева поддиректорий - частенько необходима и проект FreeRTOS - тому подтверждение..

Вот такие вот дела. Жизнь она просто чуть сложнее, чем Вам кажется. Если не все свалено в одну поддиректорию - то много еще чего придется указывать.

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

То есть вы полагаете, что достаточно указать корень, а все поддиректории "развесистого дерева" будут подключаться автоматически?

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

Это я пояснял IgorKossak зачем нужна самая первая строчка в описании путей, которая показывает на корневую директорию проета и не более того.

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

Т.е. ответ на Ваш вопрос - коль скоро Вы его задали такой: Нет я так не полагаю и не утверждал нигде этого - как раз должны быть указаны все необходимые для поиска *.h файлов поддиректории, поскольку компилятор по умолчанию (замечу по теории будет) будет их искать только в директории toolchain-а(или если хотите - в дирректории системных библиотек) и в поддиретории, где расположены текущие *.c файлы. Первые - системные *.h файлы задаются #include <имя.h>, а вторые немного иначе: #include "имя.h"
Полностью я способности IAR-компилятора не исследовал, а вот поправку IgorKossak - я не принял на основании прямой проверки на примере стандартного проекта FreeRTOS - о чем ему и написал.

Так читал. То, что он пишет - мне понятно. И сам использую:
#include <stdint.h> // искать в папке тулчейна
#include <avr/io.h> // искать в подпапке avr тулчейна
#include "Hardware.h" // лежит в той же папке, что и текущий .c
#include "./Radio/Modem.h" // лежит в поддиректории Radio относительно .с-файла, в котором эта строка.
И все работает согласно K&R.Идея FreeRTOS замечательная, а вот написан он левой ногой. Поэтому вместо явного указания пути к файлу относительно корня проекта там все инклюды указаны без путей и как костыль все пути добавлены в список поиска. Т.е. конечно, FreeRTOS без этой строчки не собирается, но это не значит, что такую тактику надо слепо копировать.

Мне тоже понятно его логика и она "по науке" - правильна, если Кернигана и Ричи - следует считать наукой...

Но мой подход - он от сохи... За длительное время использования разных компайлеров я хорошо выучил, что наука-наукой, а отклонения от нее есть сплошь и рядом - потому прежде чем ему отвечать я и проверил, что есть истина в контексте IAR, а что нет. И на основании этой проверки написал ему ответ - ибо практика и прямой эксперимент - есть критерий истинности любой науки..

Тем более что даже по науке - никто не обязывал компилятор искать основной конфигурационный файл в той директории, где собственно лежит файл проекта *.pww
Он обязан искать - к примеру - файл uart.h там где лежит uart.c c #include "uart.h" и рвно там же файл "bla-bla.h", если в файле uart.c есть #include "bla-bla.h", но никак не в дирректории с файлом *.pww или какой либо другой дирректории - пусть она даже и содержит другие файлы проекта, который в проекте FreeRTOS положен этажом выше...

У Вас в IAR - есть выбор - или указывать нужные Вам директории прямо в #include - как относительный путь к ним, либо относительный путь не указывать, но прямо указать в описанном выше мной поле положение директорий для includ-ов, что на мой взгляд - гораздо предпочтительнее в случае проектов типа FreeRTOS, иначе можно просто зшиться при перекрестных ссылках из одной поддиректории проекта в другую... Это в принципе - полезное расширение канонов от бракоделов Кернигана и Ричи...

В общем - всегда надо учитывать особенности реализации "оболочки дешевой" или в данносм случае среды разработки от IAR, которая далеко не самая гнусная из "оболочек дешевых" - есть примеры много гнуснее...

Что же до проекта FreeRTOS - то я не стал бы так категорично его хаять как Вы...
Досточно качественно он скроен. Во всяком случае - пока никаких существенных отклонений от заявленных параметров я в нем не обнаружил...
Запустился на нашей целевой плате с половины пинка... Легко поднялся TCP/IP на ethernet 10/100 и web-cервер...
С UArt-ами таймерами и обработкой прерываний ноль проблем, с запуском 1Гбит-ethernet - тоже... SNMP - тоже жив и хорошо себя чуствует... Остались только пара шагов на пару месяцев и изделие в первом приближении уже готово... А реально начали с ним бодаться - только во 2-й половине августа...
И целевая плата - это совсем не эволюшн-борд... И даже близко к ней не лежит...
======================================
PS: Почему Керниган и Ричи - бракоделы? Это просто - когда они разрабатывали язык С - во время учебы в аспирантуре и работали по совместительству(кажется в лаборатории Bell) - они явно пропустили науку именуемую у нас "теория грамматик и теория языков программирования" - в итоге ими был рожден весьма несистемно устроенный язык C, который в силу неизвестных нам обстоятельств - стал промышленным стандартом и наказанием программистов.... Наверное из-за всех наших предыдущих грехов от момента появления первого компьютера, на котором программировала еще легендарная Ада Лавлейс...

Если будем считать наукой стандарт, это устроит нас обоих? В части #include стандарт согласен с K&R, или наоборот. Если имя файла указать в кавычках - он будет искаться относительно той директории, в которой находится включивший файл, потом (если включен через второй-третий) относительно тех директорий, в которых располагаются эти файлы и так далее пока не дойдет до компилируемого .с, и если и в этой папке не найдет - будет искать в директориях компилятора. Если же файл указан в угловых скобках, то он сразу ищется _только_ в директориях компилятора. Когда вы указываете Additional Include dirs вы добавляете их в список директорий компилятора. Так что зря вы на уважаемых людей (K&R)...Я согласен с таким подходом. Но пока не вижу, в чем поведение IAR отличается от указанного в стандарте?
Согласен, объясняете вы правильно. Теперь смотрите на свою картинку: Вот тут лежит проект для IAR (файл) *.eww тут же *.c и *.h файлы этого проекта Вот тут и закралась неоднозначность. Для этих файлов инклюды будут искаться. А для файлов (в вашем случае ОС), которые лежат в совсем отдельной папке - нет. Нарушена древовидная структура проекта. Консенсус.
Я бы не стал его так категорично хаять, как вы. Как оказалось - он честно выполняет то, что предписано стандартом. Ну а если человек использует его методом Монте-Карло (научного тыка), то тогда конечно, "особенности реализации".

Я хаял не сам проект, а стиль, в котором написаны исходные коды. Структуру #include мы уже посмотрели. Посмотрите в опциях компилятора перечень подавленных варнингов. Писать так - хороший стиль? Эти варнинги убрать легко, но почему-то этого не делается. Обратите внимание, что задачи общаются с ОС, передавая объекты как void*. Компилятор лишен возможности контролировать соответствие типов. Вы можете взять указатель на char и передать его как семафор. Скомпилится молча, но будет ли работать? Непонятно зачем это сделано - чтобы скрыть от пользователя описания структур? Плюсов этого не видно, а минусы я перечислил.

Приводите аргументы. Я не знаю, какие науки _вы_ изучали, а мне язык С кажется устроенным весьма системно. И что-то не слышал про "наказание" от тех, кто им профессионально владеет. Возможно, вы пропустили науку, именуемую "изучение языка высокого уровня С"?

Выдержка из "Полного справочника по C++. 4 издание" автор Г. Шилдт.

Кавычки и угловые скобки, в которых указываются имена включаемых файлов, определяют способ их поиса на жестком диске. Если имя файла содержится в угловых скобках, он должен находиться в каталоге, указанном компилятором. Обычно это каталог INCLUDE, предназначенный для хранения всех заголовочных файлов. Если имя файла заключено в кавычки, как правило, его поиск выполняется в рабочем каталоге. Если файл не найден, поиск повторяется так, будто имя файла содержалось в угловых скобках.

PS. Добавить нечего.

Стиль составления структуры проектов может быть разный у разных программистов.
Для простейших проектов это хранение всех исходников с хедерами (их не более 10) в одной папке с файлами проекта.
Для сложных поектов это древовидная структура папок, которую представил alexander55 и которая применяется, скажем, в Linux и в очень многих проектах в сообществе Open Source.
На эту тему, в общем, спора не возникает, но вот в чём вопрос, зачем держать в корневой папке проекта .c и .h файлы, где по смыслу должны лежать лишь eww, ewp и некоторые служебные файлы среды? Ведь это разные сути.
Ведь это же крайне неудобно (опять же на мой взгляд) хотя бы с той точки зрения, что выделив исходники в отдельную папку их можно всей папкой скопировать и перенести в другой проект. С большими проектами я именно так и работаю, отсюда и моё недоумение тем, что же можно искать в папке $PROJ_DIR$\
В результате вышесказанного мои проекты выглядят примерно так:Нажмите для просмотра прикрепленного файла

"Согласен, объясняете вы правильно. " © - Ваш же...

Это претензия к разработчикам.. Но никакая наука им это не запрещает. И стандарт об этом по-моему ничего не предписывает. Хороший стиль Unix - наверное этому препячтствует - там обычно make-файл рядом с корневыми файлами проекта или в директориях ниже - но он как бы стиль, но не стандарт.


Я его и не хаял - я сказал, что он достаточно прилично написан... Я как раз сказал, что есть примеры много хуже - например оболочки VisualDSP, которую мне пришлось использовать для работы над TMS320C5402-5416 в свое время.
Т.е. считайте это моей похвалой в адрес реализации IAR, а "оболочка дешевая" - это если хотите мой взгляд на чрезмерную нынешнюю ориентированность разработчиков компиляторов на т.н. "графические среды" для разработки... Ведь собственно любой "экранный интерфейс" - это оболочка над собственно компилятором. Считайте это просто юмором и не заморачивайтесь...

А никто с этим и спорить не собирается - минусы тут есть... Но у кого их нет? Покажите мне хоть одного "идеального" разработчика -и я найду у него минимум 10 минусов - было бы желание...
В данном случае - минусы пересиливаются несомненными плюсами разработки и при желании легко снимаются без особенных трудов.

Я полагаю - это тема отдельного разговора, если об этом есть желание поговорить - тут все-таки немного другая тема...

Тем не менее могу назвать то, что обычно относят к недостаткам C, когда рассматривают его с точки зрения теории т.н. "системно построенных" языков.
Вот эти претензии:
1) Слабая типизация объектов... Пример тому - именно упомянутые Вами забитые warning-и... Вернее - это следствие слабой типизации.
2) Плохая "структуризация" программы, которая приводит к тому, что компилятор легко сбивается из-за простой забытой ";" , "," или "скобки" настолько, что даже не способен определить место ошибки... Это приводит к тому, что он диагностирует ошибку зачастую весьма далеко от места ее появления и Вам приходится просматривать в поиске этого места 3-4-5 или больше страниц текста.
3) Синтаксис провоцирующий написание весьма маловразумительных, но очень коротких выражений, кторые мало кто кроме самого автора способен понять за короткое время... Которые никак не повышают эффекитивность работы ни компилятора(сложно написанное и краткое - почти всегда компилируется хуже), ни эффективность работы человека пишушего или вынужденного разбираться в таком коде...

Я думаю - для ответа Вам названных и известных еще 20-ть лет назад недостатков C - более чем достаточно... Если нужно - то продолжение этого перечисления Вы легко найдете в соответствующих форумах где этих "религиозных дискуссий" тьма.

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

Господа, мы здесь не С обсуждаем, и тем более не нас скромных.
Давайте вспомним название темы.

Ну вот сделали такой проект, что без прописанной $PROJ_DIR$\ не обойтись - тем сделали, что в корень сложили важный настроечный файл *.h ...
Что же теперь сделаешь? И даже более того - сами разрработчики видимо так же поступают часто иначе бы они в каждом примере не писали бы эту дирректорию в опциях проекта, которые поставляют вместе с компайлером.
Самое интересное это то, что такой подход по-моему никаким стандартам не противоречит....
Или как минимум не противоречит обычной практике разработки проектов - для меня такое расположение файлов давно привычно - хоть и было когда-то странным и казалось неестественным.



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

А-а-а-а!!!
Ну так бы сразу и сказали, что проект чужой, а я уж было подумал, что Вы за такой подход агитируете . Вынужден согласиться, что в примерах от IAR, во всяком случае для ARM, это встречается довольно часто.
Очевидно, и такой подход имеет право на жизнь, раз им кто-то пользуется, хоть мне это и кажется неудобным.

Дык я же с этого и начал по-моему отвечать - и привел как раз объяснение так сказать на примере примера IAR... Возможно я этот факт не слишком ясно пояснил сразу конечно...

Ну и вообще, изначально это было возражение для Непомнящий Евгений - насчет того, что он перед $PROJ_DIR$\ поставил две точки - чего вообще говоря в IAR делать не нужно...

Весь проэкт называется теплица, состоит из:
Обьектовый плк,
Центральный модуль,
Прорамма на пк.

Центральный модуль в свою очередь состоит из меги 64 и 8 тиней работающих как 485 адаптеры

В komand_descriptions.h лежит; скорость, количество байт в посылках, адреса регистров плк итд.

Например поменял скорость 485, и поменялась сразу везде.
Адреса/биты регистров, могут напрямую использоваться Ц на пк.