Как прописать путь к файлу?, IAR AVR Опции

[fmdost]

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

Сообщение отредактировал Т.Достоевский - Oct 16 2007, 23:01

[Непомнящий Евген...]

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

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

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

[Николай Z]

Чтобы пути были относительно проекта, можно использовать $PROJ_DIR$, примерно так:
..\$PROJ_DIR$\ОбщиеФайлы\
Только что проверил, в #include "" работает и полный и относительный путь. Слэши не забыли проэкранировать?

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

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

$PROJ_DIR$\
$PROJ_DIR$\..\..\include

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

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

..\..\STR91xlibrary - каталог библиотеки 91x_lib. - имя этого каталога может быть любым...

|
|
examples - это каталог c примерами - имя каталога неважно
|...|
|...|
|...Uart0_Timer_Interrupt - это каталог с проектом... - имя каталога неважно
|.......|
|......... Вот тут лежит проект для IAR (файл) *.eww
|......... тут же *.c и *.h файлы этого проекта
|
include - каталог на который указывает вторая строчка моего примера - тут имя важно!!!...
|.......|
|......... тут лежат требуемые для проекта include-файлы *.h
|
.. другие каталоги и файлы в каталоге STR91xlibrary

Сообщение отредактировал Николай Z - Nov 4 2007, 18:32

[IgorKossak]

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

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

[Николай Z]

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

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

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

Сообщение отредактировал Николай Z - Nov 6 2007, 08:33

[IgorKossak]

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

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

[Николай Z]

Проверьте как минимум стандартный 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 - тому подтверждение..

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

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

Сообщение отредактировал Николай Z - Nov 6 2007, 18:29

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

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

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

[Николай Z]

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

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

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

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

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

Сообщение отредактировал Николай Z - Nov 6 2007, 21:18

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

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

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

а вот поправку IgorKossak - я не принял на основании прямой проверки на примере стандартного проекта FreeRTOS - о чем ему и написал.

Идея FreeRTOS замечательная, а вот написан он левой ногой. Поэтому вместо явного указания пути к файлу относительно корня проекта там все инклюды указаны без путей и как костыль все пути добавлены в список поиска. Т.е. конечно, FreeRTOS без этой строчки не собирается, но это не значит, что такую тактику надо слепо копировать.

[Николай Z]

"Теория суха мой друг,
А древо жизни вечно зеленеет..."

Так читал. То, что он пишет - мне понятно. И сам использую:
#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, который в силу неизвестных нам обстоятельств - стал промышленным стандартом и наказанием программистов.... Наверное из-за всех наших предыдущих грехов от момента появления первого компьютера, на котором программировала еще легендарная Ада Лавлейс...

Сообщение отредактировал Николай Z - Nov 6 2007, 23:43

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

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

Если будем считать наукой стандарт, это устроит нас обоих? В части #include стандарт согласен с K&R, или наоборот. Если имя файла указать в кавычках - он будет искаться относительно той директории, в которой находится включивший файл, потом (если включен через второй-третий) относительно тех директорий, в которых располагаются эти файлы и так далее пока не дойдет до компилируемого .с, и если и в этой папке не найдет - будет искать в директориях компилятора. Если же файл указан в угловых скобках, то он сразу ищется _только_ в директориях компилятора. Когда вы указываете Additional Include dirs вы добавляете их в список директорий компилятора. Так что зря вы на уважаемых людей (K&R)...

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

Я согласен с таким подходом. Но пока не вижу, в чем поведение IAR отличается от указанного в стандарте?

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

Согласен, объясняете вы правильно. Теперь смотрите на свою картинку: Вот тут лежит проект для IAR (файл) *.eww тут же *.c и *.h файлы этого проекта Вот тут и закралась неоднозначность. Для этих файлов инклюды будут искаться. А для файлов (в вашем случае ОС), которые лежат в совсем отдельной папке - нет. Нарушена древовидная структура проекта. Консенсус.

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

Я бы не стал его так категорично хаять, как вы. Как оказалось - он честно выполняет то, что предписано стандартом. Ну а если человек использует его методом Монте-Карло (научного тыка), то тогда конечно, "особенности реализации".

Что же до проекта FreeRTOS - то я не стал бы так категорично его хаять как Вы...

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

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

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

[Николай Z]

Если будем считать наукой стандарт, это устроит нас обоих?

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

Теперь смотрите на свою картинку: Вот тут лежит проект для IAR (файл) *.eww тут же *.c и *.h файлы этого проекта Вот тут и закралась неоднозначность. Для этих файлов инклюды будут искаться. А для файлов (в вашем случае ОС), которые лежат в совсем отдельной папке - нет. Нарушена древовидная структура проекта. Консенсус.

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

Я бы не стал его так категорично хаять, как вы. Как оказалось - он честно выполняет то, что предписано стандартом. Ну а если человек использует его методом Монте-Карло (научного тыка), то тогда конечно, "особенности реализации".

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

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

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

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

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

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

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

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