реклама на сайте
подробности

 
 
4 страниц V   1 2 3 > »   
Reply to this topicStart new topic
> Как прописать путь к файлу?, IAR AVR
fmdost
сообщение Oct 16 2007, 22:38
Сообщение #1


Местный
***

Группа: Свой
Сообщений: 479
Регистрация: 8-05-07
Из: г. Ставрополь. Северный Кавказ. Россия
Пользователь №: 27 606



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

Сообщение отредактировал Т.Достоевский - Oct 16 2007, 23:01
Go to the top of the page
 
+Quote Post
dxp
сообщение Oct 17 2007, 02:49
Сообщение #2


Adept
******

Группа: Свой
Сообщений: 3 469
Регистрация: 6-12-04
Из: Novosibirsk
Пользователь №: 1 343



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


--------------------
«Отыщи всему начало, и ты многое поймёшь» К. Прутков
Go to the top of the page
 
+Quote Post
fmdost
сообщение Oct 17 2007, 03:59
Сообщение #3


Местный
***

Группа: Свой
Сообщений: 479
Регистрация: 8-05-07
Из: г. Ставрополь. Северный Кавказ. Россия
Пользователь №: 27 606



Цитата(dxp @ Oct 17 2007, 06:49) *
Для того, чтобы компилятор находил заголовочные файлы, находящиеся не в той же директории, что и исходные, нужно указать ему путь к ним. Для этого служит ключ командной строки -I. Указать можно, также, и в опциях оболочки - вкладка там есть для этого в опциях компилятора, где можно прописать пути. По умолчанию там прописаны пути к системным заголовкам (которые идут в составе пакета). Добавьте там свой путь и все. Подробности в документации, там все есть, хотя что-то принципиально новое к уже сказанному там вряд ли найдется.

Спасибо. Не знал что можно добавлять. Только не понял почему ему не понравился полный путь?
Go to the top of the page
 
+Quote Post
Непомнящий Евген...
сообщение Oct 17 2007, 04:05
Сообщение #4


Знающий
****

Группа: Свой
Сообщений: 771
Регистрация: 16-07-07
Из: Волгодонск
Пользователь №: 29 153



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

Цитата(Т.Достоевский @ Oct 17 2007, 07:59) *
Спасибо. Не знал что можно добавлять. Только не понял почему ему не понравился полный путь?


Только что проверил, в #include "" работает и полный и относительный путь. Слэши не забыли проэкранировать?
Go to the top of the page
 
+Quote Post
rezident
сообщение Oct 17 2007, 06:07
Сообщение #5


Гуру
******

Группа: Свой
Сообщений: 10 920
Регистрация: 5-04-05
Пользователь №: 3 882



Я в своих проектах использую относительные пути. Вот здесь я уже приводил пример. А вот здесь приводил пример используемой мной структуры каталогов для проектов. Подобную структуру (вкупе с относительными путями) довольно удобно использовать при переносе проектов в любое другое место.
Go to the top of the page
 
+Quote Post
alexander55
сообщение Oct 17 2007, 06:43
Сообщение #6


Бывалый
*****

Группа: Свой
Сообщений: 1 584
Регистрация: 7-08-07
Пользователь №: 29 615



Цитата(rezident @ Oct 17 2007, 10:07) *
Я в своих проектах использую относительные пути. Вот здесь я уже приводил пример. А вот здесь приводил пример используемой мной структуры каталогов для проектов. Подобную структуру (вкупе с относительными путями) довольно удобно использовать при переносе проектов в любое другое место.

Чувствуется системный подход. a14.gif
Go to the top of the page
 
+Quote Post
Dog Pawlowa
сообщение Oct 17 2007, 07:24
Сообщение #7


Гуру
******

Группа: Свой
Сообщений: 2 702
Регистрация: 14-07-06
Пользователь №: 18 823



Цитата(rezident @ Oct 17 2007, 09:07) *
Я в своих проектах использую относительные пути. Вот здесь я уже приводил пример. А вот здесь приводил пример используемой мной структуры каталогов для проектов. Подобную структуру (вкупе с относительными путями) довольно удобно использовать при переносе проектов в любое другое место.

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


--------------------
Уходя, оставьте свет...
Go to the top of the page
 
+Quote Post
rezident
сообщение Oct 17 2007, 07:41
Сообщение #8


Гуру
******

Группа: Свой
Сообщений: 10 920
Регистрация: 5-04-05
Пользователь №: 3 882



Цитата(Dog Pawlowa @ Oct 17 2007, 13:24) *
Как это сочетается с системой контроля версий?

Никак. Потому что не пользуюсь.
Go to the top of the page
 
+Quote Post
dxp
сообщение Oct 17 2007, 07:47
Сообщение #9


Adept
******

Группа: Свой
Сообщений: 3 469
Регистрация: 6-12-04
Из: Novosibirsk
Пользователь №: 1 343



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


--------------------
«Отыщи всему начало, и ты многое поймёшь» К. Прутков
Go to the top of the page
 
+Quote Post
Dog Pawlowa
сообщение Oct 17 2007, 07:53
Сообщение #10


Гуру
******

Группа: Свой
Сообщений: 2 702
Регистрация: 14-07-06
Пользователь №: 18 823



Цитата(dxp @ Oct 17 2007, 10:47) *
Встерчал такую огранизацию проектов - все из одного корня растет. И под контролем версий - вся структура помещается в репозиторий. Пользуются, другого не хотят.

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


--------------------
Уходя, оставьте свет...
Go to the top of the page
 
+Quote Post
dxp
сообщение Oct 17 2007, 08:00
Сообщение #11


Adept
******

Группа: Свой
Сообщений: 3 469
Регистрация: 6-12-04
Из: Novosibirsk
Пользователь №: 1 343



Цитата(Dog Pawlowa @ Oct 17 2007, 14:53) *
Тоже годится, но только для одной задачи - архивирования на века. smile.gif
А для оперативной работы с возможной отмоткой назад каждого проекта в отдельности - увы-увы...

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


--------------------
«Отыщи всему начало, и ты многое поймёшь» К. Прутков
Go to the top of the page
 
+Quote Post
Andy Mozzhevilov
сообщение Oct 17 2007, 08:20
Сообщение #12


Знающий
****

Группа: Свой
Сообщений: 877
Регистрация: 26-01-05
Из: Екатеринбург
Пользователь №: 2 206



Цитата(Dog Pawlowa @ Oct 17 2007, 13:53) *
Тоже годится, но только для одной задачи - архивирования на века. smile.gif
А для оперативной работы с возможной отмоткой назад каждого проекта в отдельности - увы-увы...

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


--------------------
Пасу котов...
Go to the top of the page
 
+Quote Post
Сергей Борщ
сообщение Oct 17 2007, 09:07
Сообщение #13


Гуру
******

Группа: Модераторы
Сообщений: 8 455
Регистрация: 15-05-06
Из: Рига, Латвия
Пользователь №: 17 095



Цитата(rezident @ Oct 17 2007, 09:07) *
А вот здесь приводил пример используемой мной структуры каталогов для проектов.
Тоже пользовался такой структурой, пока не выяснилось, что в одном проекте может быть два и больше процессоров разных семейств, а после этого выяснилось, что очень удобно в одном месте хранить и все исходники для процессоров, и сопутствующие писишиные программы с исходниками и схемы/разводки и документацию. Т.е.
Код
Project
    Doc
    Hardware
    Software
         Bootloader
         Firmware
         PC
         или
         Проц1
             Bootloader
             Firmware
             PC
         Проц2
             Bootloader
             Firmware
             PC
В таком виде оказалось очень удобно проекты и под контролем версий держать, и в .bat прописывать относительные пути к экзешникам, которые компилятся из писишных исходников и лежат в своих каталогах (достаточно под контролем версий держать только исходники). И при необходимости можно одной командой достать из репозитория весь проект на нужный момент времени. И общие для проекта файлы гармонично ложатся в общие каталоги (например Hardware.h кладется в "Проц1" и легко доступен из Bootloader и Firmware(#include "..\Hardware.h"), Hardware.h для второго проца в "Проц2", заголовочный файл для обмена по шине в Software и т.д.)


--------------------
На любой вопрос даю любой ответ
"Write code that is guaranteed to work, not code that doesn’t seem to break" (C++ FAQ)
Go to the top of the page
 
+Quote Post
Dog Pawlowa
сообщение Oct 17 2007, 09:58
Сообщение #14


Гуру
******

Группа: Свой
Сообщений: 2 702
Регистрация: 14-07-06
Пользователь №: 18 823



Цитата(Andy Mozzhevilov @ Oct 17 2007, 11:20) *
А в чем сложность, собственно?

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

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


--------------------
Уходя, оставьте свет...
Go to the top of the page
 
+Quote Post
Непомнящий Евген...
сообщение Oct 17 2007, 10:12
Сообщение #15


Знающий
****

Группа: Свой
Сообщений: 771
Регистрация: 16-07-07
Из: Волгодонск
Пользователь №: 29 153



Цитата(Dog Pawlowa @ Oct 17 2007, 13:58) *
Получается такая последовательность:
- общая часть 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)
Go to the top of the page
 
+Quote Post
rezident
сообщение Oct 17 2007, 10:23
Сообщение #16


Гуру
******

Группа: Свой
Сообщений: 10 920
Регистрация: 5-04-05
Пользователь №: 3 882



В корневых хидерах у меня находятся такие глобальные и немодифицируемые вещи как, например, типы переменных. А то, что как-то платформеннозависимо и/или подвергается модификации в проектах не должно находиться в корне. Например, если у вас определен адрес вызова глобальной функции, то в модифицируемых версиях извольте выкручиваться за счет каких-то дополнительных проверок внутри самой функции, а адрес вызова не трожьте! Как учил меня коллега, писавший операционки начиная с конца 80-х годов, в описании каждого модуля должен быть текстовый комментарий состояния его. Примерно что-то типа такого
1) не подлежит модификации,
2) модифицируемый только в исключительном случае,
3) утвержден для публикации,
4) подлежит утверждению,
5) в разработке,
6) альфа-версия.
И если проект ведет более, чем один программист, то данная концепция просто необходима. Система контроля версий это конечно хорошо, но согласованность при разработке в команде важнее.
P.S. конечно в проектах, которые выполняю единолично, я позволяю себе больше вольностей wink.gif
Go to the top of the page
 
+Quote Post
Andy Mozzhevilov
сообщение Oct 17 2007, 10:54
Сообщение #17


Знающий
****

Группа: Свой
Сообщений: 877
Регистрация: 26-01-05
Из: Екатеринбург
Пользователь №: 2 206



Цитата(Dog Pawlowa @ Oct 17 2007, 15:58) *
То ли я не умею готовить, но у меня вот эти две папки
|->_INC <-общие хидеры проектов
|->_SRC <-общие исходники проектов
не получаются статическими, они тоже изменяются. В реальной жизни то ошибка находится, то ли стремление улучшить проснется. 05.gif

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

В общем, может это уже и не в топик данной темы, но все же отвечаю.
Чтобы такого как у вас не случалось, общие части, которые могут быть использованы в разных проектах должны в каждом проекте иметь свои локальные копии, находящиеся под контролем системы 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".
Результат компиляции до байта совпадает. Конец найден, и виноватый тоже smile.gif




Цитата(rezident @ Oct 17 2007, 16:23) *
И если проект ведет более, чем один программист, то данная концепция просто необходима. Система контроля версий это конечно хорошо, но согласованность при разработке в команде важнее.
P.S. конечно в проектах, которые выполняю единолично, я позволяю себе больше вольностей wink.gif

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


--------------------
Пасу котов...
Go to the top of the page
 
+Quote Post
Dog Pawlowa
сообщение Oct 17 2007, 10:57
Сообщение #18


Гуру
******

Группа: Свой
Сообщений: 2 702
Регистрация: 14-07-06
Пользователь №: 18 823



Цитата(Andy Mozzhevilov @ Oct 17 2007, 13:27) *
Конец найден, и виноватый тоже smile.gif

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


--------------------
Уходя, оставьте свет...
Go to the top of the page
 
+Quote Post
Andy Mozzhevilov
сообщение Oct 17 2007, 11:04
Сообщение #19


Знающий
****

Группа: Свой
Сообщений: 877
Регистрация: 26-01-05
Из: Екатеринбург
Пользователь №: 2 206



Цитата(Dog Pawlowa @ Oct 17 2007, 16:57) *
Ну, с виноватыми обычно проблем не бывает smile.gif
Признаюсь, инструкцию по SVN курил "не в затяжку", пользуюсь очевидными функциями. Про такую комбинацию не думал.
Мне кажется, что могут быть проблемы, если отмотать версию в такой локальной копии common назад и случайно закоммитить. Но нужно подумать и попробовать. Спасибо.

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


--------------------
Пасу котов...
Go to the top of the page
 
+Quote Post
dxp
сообщение Oct 17 2007, 13:17
Сообщение #20


Adept
******

Группа: Свой
Сообщений: 3 469
Регистрация: 6-12-04
Из: Novosibirsk
Пользователь №: 1 343



Цитата(Andy Mozzhevilov @ Oct 17 2007, 18:04) *
Я пользуюсь на данный момент CVS, как оно реализуется в SVN не совсем представляю, поскольку доку по SVN меня несколько насильно заставили покурить некоторые присутвующие в том числе здесь товарищи smile.gif. И в данный момент она недокурена пока.

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

Цитата(Andy Mozzhevilov @ Oct 17 2007, 18:04) *
В CVS при извлечении по тэгу локальную версию закомитить будет нельзя, поскольку на ней будут так называемые липкие метки. Если нужно будет, допустим, выпустить релиз на основе именно этой комбинации исходников, ну типа исправить только тот небольшой баг, то тогда делается ветвь в проекте на основе текущей версии извлеченных исходных текстов и она уже комитится, но не мешает основному стволу разработки. При желании потом изменения можно внести на ствол.

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


--------------------
«Отыщи всему начало, и ты многое поймёшь» К. Прутков
Go to the top of the page
 
+Quote Post
fmdost
сообщение Oct 17 2007, 17:33
Сообщение #21


Местный
***

Группа: Свой
Сообщений: 479
Регистрация: 8-05-07
Из: г. Ставрополь. Северный Кавказ. Россия
Пользователь №: 27 606



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

Цитата(Непомнящий Евгений @ Oct 17 2007, 08:05) *
Чтобы пути были относительно проекта, можно использовать $PROJ_DIR$, примерно так:
..\$PROJ_DIR$\ОбщиеФайлы\
Только что проверил, в #include "" работает и полный и относительный путь. Слэши не забыли проэкранировать?

Беру путь из заголовка в окошке. Что значит "Слэши проэкранировать?"
Go to the top of the page
 
+Quote Post
Непомнящий Евген...
сообщение Oct 18 2007, 04:26
Сообщение #22


Знающий
****

Группа: Свой
Сообщений: 771
Регистрация: 16-07-07
Из: Волгодонск
Пользователь №: 29 153



Цитата(Т.Достоевский @ Oct 17 2007, 21:33) *
Беру путь из заголовка в окошке. Что значит "Слэши проэкранировать?"

#include "c:\\folder1\\folder2\\myFile.h"
#include "..\\..\\folder2\\myFile.h"
Go to the top of the page
 
+Quote Post
Nikola Kirov
сообщение Oct 18 2007, 16:22
Сообщение #23


Местный
***

Группа: Свой
Сообщений: 256
Регистрация: 4-11-04
Из: Болгария
Пользователь №: 1 050



Не нада екранироват smile.gif
Вот и пример из рабочего проекта
Код
#if IMPLEMENT_USART_LIB == 1
    #include ".\libs\Usart_2.c"
#endif

#if IMPLEMENT_SPP_LIB == 1
    #include ".\libs\SPP.c"
#endif

#if IMPLEMENT_EELOG_LIB == 1
    #include ".\libs\EElog.c"
#endif

#if  IMPLEMENT_DS1338_LIB == 1
    #include ".\libs\DS1338.c"
#endif

#if  IMPLEMENT_I2C_LIB == 1
    #include ".\libs\i2c.c"
#endif

#if  IMPLEMENT_I2C_SOFT_LIB == 1
    #include ".\libs\i2c_soft.c"
#endif

#if  IMPLEMENT_ADC_LIB == 1
    #include ".\libs\ADC_2.c"
#endif

#if  IMPLEMENT_I2CEEPROM_LIB == 1
    #include ".\libs\i2ceeprom.c"
#endif


А у меня ест вопрос. Возможно ли в сорс използовать переменньi окружения?
Не получается никак у меня.
Go to the top of the page
 
+Quote Post
zltigo
сообщение Oct 18 2007, 17:14
Сообщение #24


Гуру
******

Группа: Свой
Сообщений: 13 372
Регистрация: 27-11-04
Из: Riga, Latvia
Пользователь №: 1 244



Цитата(Nikola Kirov @ Oct 18 2007, 19:22) *
А у меня ест вопрос. Возможно ли в сорс използовать переменньi окружения?

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


--------------------
Feci, quod potui, faciant meliora potentes
Go to the top of the page
 
+Quote Post
Nikola Kirov
сообщение Oct 18 2007, 17:54
Сообщение #25


Местный
***

Группа: Свой
Сообщений: 256
Регистрация: 4-11-04
Из: Болгария
Пользователь №: 1 050



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

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

куда SOURCE_CODE_DIR переменная окружения. Но ето вообщем не работает в никаком компиляторе.
Но можно жит и без етого smile.gif
Go to the top of the page
 
+Quote Post
zltigo
сообщение Oct 18 2007, 22:23
Сообщение #26


Гуру
******

Группа: Свой
Сообщений: 13 372
Регистрация: 27-11-04
Из: Riga, Latvia
Пользователь №: 1 244



Цитата(Nikola Kirov @ Oct 18 2007, 20:54) *
Хотелос написат что то типа
#include "$SOURCE_CODE_DIR$\ARM\ATMEL\i2c.c"

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


--------------------
Feci, quod potui, faciant meliora potentes
Go to the top of the page
 
+Quote Post
Nikola Kirov
сообщение Oct 18 2007, 22:31
Сообщение #27


Местный
***

Группа: Свой
Сообщений: 256
Регистрация: 4-11-04
Из: Болгария
Пользователь №: 1 050



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

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

но #include "$SOURCE_CODE_DIR$\ARM\ATMEL\i2c.c" нравится болше smile.gifsmile.gifsmile.gif Но уви....
Go to the top of the page
 
+Quote Post
Andy Mozzhevilov
сообщение Oct 19 2007, 02:23
Сообщение #28


Знающий
****

Группа: Свой
Сообщений: 877
Регистрация: 26-01-05
Из: Екатеринбург
Пользователь №: 2 206



Цитата(Nikola Kirov @ Oct 19 2007, 04:31) *
Да ето и ползуюс.
Но делаю из опции проекта -> C/C++ Compiler -> Preprocessor -> Additional include directories

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

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


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


--------------------
Пасу котов...
Go to the top of the page
 
+Quote Post
Nikola Kirov
сообщение Oct 19 2007, 02:32
Сообщение #29


Местный
***

Группа: Свой
Сообщений: 256
Регистрация: 4-11-04
Из: Болгария
Пользователь №: 1 050



Но если окажется что в прописаньих через -I пути ест 2 фаил с ето имя,будет използоватся первъи из них кто компилер нашел. Для маленких проект ето не проблем но когда проект становится болшой и вероятност таких проблем возрастает.
Go to the top of the page
 
+Quote Post
Andy Mozzhevilov
сообщение Oct 19 2007, 02:54
Сообщение #30


Знающий
****

Группа: Свой
Сообщений: 877
Регистрация: 26-01-05
Из: Екатеринбург
Пользователь №: 2 206



Цитата(Nikola Kirov @ Oct 19 2007, 08:32) *
Но если окажется что в прописаньих через -I пути ест 2 фаил с ето имя,будет използоватся первъи из них кто компилер нашел. Для маленких проект ето не проблем но когда проект становится болшой и вероятност таких проблем возрастает.

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


--------------------
Пасу котов...
Go to the top of the page
 
+Quote Post
Непомнящий Евген...
сообщение Oct 19 2007, 04:05
Сообщение #31


Знающий
****

Группа: Свой
Сообщений: 771
Регистрация: 16-07-07
Из: Волгодонск
Пользователь №: 29 153



Цитата(Nikola Kirov @ Oct 18 2007, 20:22) *
Не нада екранироват smile.gif


Действительно, работает a14.gif Не знал...
Go to the top of the page
 
+Quote Post
zltigo
сообщение Oct 19 2007, 06:39
Сообщение #32


Гуру
******

Группа: Свой
Сообщений: 13 372
Регистрация: 27-11-04
Из: Riga, Latvia
Пользователь №: 1 244



Цитата(Andy Mozzhevilov @ Oct 19 2007, 05:23) *
Мне вот вообще больше нравится
#include "i2c.h"

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


--------------------
Feci, quod potui, faciant meliora potentes
Go to the top of the page
 
+Quote Post
Николай Z
сообщение Nov 4 2007, 18:25
Сообщение #33


Местный
***

Группа: Участник*
Сообщений: 418
Регистрация: 20-08-07
Пользователь №: 29 930



Цитата(Непомнящий Евгений @ Oct 17 2007, 07:05) *
Чтобы пути были относительно проекта, можно использовать $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
Go to the top of the page
 
+Quote Post
IgorKossak
сообщение Nov 5 2007, 15:08
Сообщение #34


Шаман
******

Группа: Модераторы
Сообщений: 3 064
Регистрация: 30-06-04
Из: Киев, Украина
Пользователь №: 221



Цитата(Николай Z @ Nov 4 2007, 20:25) *
Вышеприведенная запись заставляет искать include-файлы в:
1) Каталоге с самим проектом

В каталоге с проектом include-файлы ищутся по умолчанию и без записи $PROJ_DIR$\
Go to the top of the page
 
+Quote Post
Николай Z
сообщение Nov 6 2007, 08:29
Сообщение #35


Местный
***

Группа: Участник*
Сообщений: 418
Регистрация: 20-08-07
Пользователь №: 29 930



Цитата(IgorKossak @ Nov 5 2007, 18:08) *
В каталоге с проектом include-файлы ищутся по умолчанию и без записи $PROJ_DIR$\


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

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

Сообщение отредактировал Николай Z - Nov 6 2007, 08:33
Go to the top of the page
 
+Quote Post
IgorKossak
сообщение Nov 6 2007, 13:47
Сообщение #36


Шаман
******

Группа: Модераторы
Сообщений: 3 064
Регистрация: 30-06-04
Из: Киев, Украина
Пользователь №: 221



Цитата(Николай Z @ Nov 6 2007, 10:29) *
Вывод - ваше предположение - ошибочно как минимум на моей версии...

Проверьте как минимум стандартный tutorial от IAR и убедитесь в обратном.
Я, в свою очередь, имею несколько маленьких проектов, где все исходники и хедеры находятся в папке с проектом. НИКОГДА не снабжал свои проекты строкой $PROJ_DIR$\ (по началу просто не знал о ней). Все файлы видятся с любой версией продукта.
Дело может быть вот в чём, согласно старым добрым Кернигану и Ричи строки #include "file.h" ищут файлы в той же директории, что и исходный файл, строки #include <file.h> ищут файл в директории тулчейна.
Возможно, что Ваши исходники (в отличие от хедеров) лежат не в директории проекта.
Go to the top of the page
 
+Quote Post
Николай Z
сообщение Nov 6 2007, 18:24
Сообщение #37


Местный
***

Группа: Участник*
Сообщений: 418
Регистрация: 20-08-07
Пользователь №: 29 930



Цитата(IgorKossak @ Nov 6 2007, 16:47) *
Проверьте как минимум стандартный 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
Go to the top of the page
 
+Quote Post
Сергей Борщ
сообщение Nov 6 2007, 19:22
Сообщение #38


Гуру
******

Группа: Модераторы
Сообщений: 8 455
Регистрация: 15-05-06
Из: Рига, Латвия
Пользователь №: 17 095



Цитата(Николай Z @ Nov 6 2007, 20:24) *
В простейшем случае - она возможно и не нужна, но в случае развесистого дерева поддиректорий - частенько необходима
То есть вы полагаете, что достаточно указать корень, а все поддиректории "развесистого дерева" будут подключаться автоматически? sad.gif


--------------------
На любой вопрос даю любой ответ
"Write code that is guaranteed to work, not code that doesn’t seem to break" (C++ FAQ)
Go to the top of the page
 
+Quote Post
Николай Z
сообщение Nov 6 2007, 21:12
Сообщение #39


Местный
***

Группа: Участник*
Сообщений: 418
Регистрация: 20-08-07
Пользователь №: 29 930



Цитата(Сергей Борщ @ Nov 6 2007, 22:22) *
То есть вы полагаете, что достаточно указать корень, а все поддиректории "развесистого дерева" будут подключаться автоматически? sad.gif


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

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

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

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

Сообщение отредактировал Николай Z - Nov 6 2007, 21:18
Go to the top of the page
 
+Quote Post
Сергей Борщ
сообщение Nov 6 2007, 21:55
Сообщение #40


Гуру
******

Группа: Модераторы
Сообщений: 8 455
Регистрация: 15-05-06
Из: Рига, Латвия
Пользователь №: 17 095



Цитата(Николай Z @ Nov 6 2007, 23:12) *
А Вы бы прочитали внимательно все от начала и поправку от IgorKossak- и все было бы понятно...
Так читал. То, что он пишет - мне понятно. И сам использую:
#include <stdint.h> // искать в папке тулчейна
#include <avr/io.h> // искать в подпапке avr тулчейна
#include "Hardware.h" // лежит в той же папке, что и текущий .c
#include "./Radio/Modem.h" // лежит в поддиректории Radio относительно .с-файла, в котором эта строка.
И все работает согласно K&R.
Цитата(Николай Z @ Nov 6 2007, 23:12) *
а вот поправку IgorKossak - я не принял на основании прямой проверки на примере стандартного проекта FreeRTOS - о чем ему и написал.
Идея FreeRTOS замечательная, а вот написан он левой ногой. Поэтому вместо явного указания пути к файлу относительно корня проекта там все инклюды указаны без путей и как костыль все пути добавлены в список поиска. Т.е. конечно, FreeRTOS без этой строчки не собирается, но это не значит, что такую тактику надо слепо копировать.


--------------------
На любой вопрос даю любой ответ
"Write code that is guaranteed to work, not code that doesn’t seem to break" (C++ FAQ)
Go to the top of the page
 
+Quote Post
Николай Z
сообщение Nov 6 2007, 23:18
Сообщение #41


Местный
***

Группа: Участник*
Сообщений: 418
Регистрация: 20-08-07
Пользователь №: 29 930



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

Цитата(Сергей Борщ @ Nov 7 2007, 00:55) *
Так читал. То, что он пишет - мне понятно. И сам использую:
#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, который в силу неизвестных нам обстоятельств - стал промышленным стандартом и наказанием программистов.... Наверное из-за всех наших предыдущих грехов от момента появления первого компьютера, на котором программировала еще легендарная Ада Лавлейс... biggrin.gif

Сообщение отредактировал Николай Z - Nov 6 2007, 23:43
Go to the top of the page
 
+Quote Post
Сергей Борщ
сообщение Nov 7 2007, 02:01
Сообщение #42


Гуру
******

Группа: Модераторы
Сообщений: 8 455
Регистрация: 15-05-06
Из: Рига, Латвия
Пользователь №: 17 095



Цитата(Николай Z @ Nov 7 2007, 01:18) *
Мне тоже понятно его логика и она "по науке" - правильна, если Кернигана и Ричи - следует считать наукой...
Если будем считать наукой стандарт, это устроит нас обоих? В части #include стандарт согласен с K&R, или наоборот. Если имя файла указать в кавычках - он будет искаться относительно той директории, в которой находится включивший файл, потом (если включен через второй-третий) относительно тех директорий, в которых располагаются эти файлы и так далее пока не дойдет до компилируемого .с, и если и в этой папке не найдет - будет искать в директориях компилятора. Если же файл указан в угловых скобках, то он сразу ищется _только_ в директориях компилятора. Когда вы указываете Additional Include dirs вы добавляете их в список директорий компилятора. Так что зря вы на уважаемых людей (K&R)...
Цитата(Николай Z @ Nov 7 2007, 01:18) *
потому прежде чем ему отвечать я и проверил, что есть истина в контексте 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, который в силу неизвестных нам обстоятельств - стал промышленным стандартом и наказанием программистов....
Приводите аргументы. Я не знаю, какие науки _вы_ изучали, а мне язык С кажется устроенным весьма системно. И что-то не слышал про "наказание" от тех, кто им профессионально владеет. Возможно, вы пропустили науку, именуемую "изучение языка высокого уровня С"? smile.gif


--------------------
На любой вопрос даю любой ответ
"Write code that is guaranteed to work, not code that doesn’t seem to break" (C++ FAQ)
Go to the top of the page
 
+Quote Post
alexander55
сообщение Nov 7 2007, 06:48
Сообщение #43


Бывалый
*****

Группа: Свой
Сообщений: 1 584
Регистрация: 7-08-07
Пользователь №: 29 615



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

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

PS. Добавить нечего.
Go to the top of the page
 
+Quote Post
IgorKossak
сообщение Nov 7 2007, 08:05
Сообщение #44


Шаман
******

Группа: Модераторы
Сообщений: 3 064
Регистрация: 30-06-04
Из: Киев, Украина
Пользователь №: 221



Стиль составления структуры проектов может быть разный у разных программистов.
Для простейших проектов это хранение всех исходников с хедерами (их не более 10) в одной папке с файлами проекта.
Для сложных поектов это древовидная структура папок, которую представил alexander55 и которая применяется, скажем, в Linux и в очень многих проектах в сообществе Open Source.
На эту тему, в общем, спора не возникает, но вот в чём вопрос, зачем держать в корневой папке проекта .c и .h файлы, где по смыслу должны лежать лишь eww, ewp и некоторые служебные файлы среды? Ведь это разные сути.
Ведь это же крайне неудобно (опять же на мой взгляд) хотя бы с той точки зрения, что выделив исходники в отдельную папку их можно всей папкой скопировать и перенести в другой проект. С большими проектами я именно так и работаю, отсюда и моё недоумение тем, что же можно искать в папке $PROJ_DIR$\
В результате вышесказанного мои проекты выглядят примерно так:
Прикрепленное изображение
Go to the top of the page
 
+Quote Post
Николай Z
сообщение Nov 7 2007, 08:17
Сообщение #45


Местный
***

Группа: Участник*
Сообщений: 418
Регистрация: 20-08-07
Пользователь №: 29 930



Цитата(Сергей Борщ @ Nov 7 2007, 05:01) *
Если будем считать наукой стандарт, это устроит нас обоих?

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

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

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

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

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

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

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

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

Я же предпочитаю на самом деле не вести их, а использовать то, что имею в данный момент здесь и сейчас... Ну принят C в качестве промышленного стандарта - и ладно. Приходится его использовать в работе и знать его слабые места и стараться их избегать - вот и все.
Go to the top of the page
 
+Quote Post
IgorKossak
сообщение Nov 7 2007, 08:22
Сообщение #46


Шаман
******

Группа: Модераторы
Сообщений: 3 064
Регистрация: 30-06-04
Из: Киев, Украина
Пользователь №: 221



Господа, мы здесь не С обсуждаем, и тем более не нас скромных.
Давайте вспомним название темы.
Go to the top of the page
 
+Quote Post
Николай Z
сообщение Nov 7 2007, 08:24
Сообщение #47


Местный
***

Группа: Участник*
Сообщений: 418
Регистрация: 20-08-07
Пользователь №: 29 930



Цитата(IgorKossak @ Nov 7 2007, 11:05) *
Ведь это же крайне неудобно (опять же на мой взгляд) хотя бы с той точки зрения, что выделив исходники в отдельную папку их можно всей папкой скопировать и перенести в другой проект. С большими проектами я именно так и работаю, отсюда и моё недоумение тем, что же можно искать в папке $PROJ_DIR$\


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


Цитата(IgorKossak @ Nov 7 2007, 11:22) *
Господа, мы здесь не С обсуждаем, и тем более не нас скромных.
Давайте вспомним название темы.

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

Сообщение отредактировал Николай Z - Nov 7 2007, 08:27
Go to the top of the page
 
+Quote Post
IgorKossak
сообщение Nov 7 2007, 09:27
Сообщение #48


Шаман
******

Группа: Модераторы
Сообщений: 3 064
Регистрация: 30-06-04
Из: Киев, Украина
Пользователь №: 221



Цитата(Николай Z @ Nov 7 2007, 10:24) *
Ну вот сделали такой проект, что без прописанной $PROJ_DIR$\ не обойтись - тем сделали, что в корень сложили важный настроечный файл *.h ...
Что же теперь сделаешь? И даже более того - сами разрработчики видимо так же поступают часто иначе бы они в каждом примере не писали бы эту дирректорию в опциях проекта, которые поставляют вместе с компайлером.

А-а-а-а!!!
Ну так бы сразу и сказали, что проект чужой, а я уж было подумал, что Вы за такой подход агитируете cool.gif. Вынужден согласиться, что в примерах от IAR, во всяком случае для ARM, это встречается довольно часто.
Очевидно, и такой подход имеет право на жизнь, раз им кто-то пользуется, хоть мне это и кажется неудобным.
Go to the top of the page
 
+Quote Post
Николай Z
сообщение Nov 7 2007, 09:58
Сообщение #49


Местный
***

Группа: Участник*
Сообщений: 418
Регистрация: 20-08-07
Пользователь №: 29 930



Цитата(IgorKossak @ Nov 7 2007, 12:27) *
А-а-а-а!!!
Ну так бы сразу и сказали, что проект чужой, а я уж было подумал, что Вы за такой подход агитируете cool.gif. Вынужден согласиться, что в примерах от IAR, во всяком случае для ARM, это встречается довольно часто.
Очевидно, и такой подход имеет право на жизнь, раз им кто-то пользуется, хоть мне это и кажется неудобным.


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

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

Сообщение отредактировал Николай Z - Nov 7 2007, 10:02
Go to the top of the page
 
+Quote Post
fmdost
сообщение Nov 7 2007, 15:42
Сообщение #50


Местный
***

Группа: Свой
Сообщений: 479
Регистрация: 8-05-07
Из: г. Ставрополь. Северный Кавказ. Россия
Пользователь №: 27 606



Цитата(IgorKossak @ Nov 7 2007, 12:05) *
На эту тему, в общем, спора не возникает, но вот в чём вопрос, зачем держать в корневой папке проекта .c и .h файлы, где по смыслу должны лежать лишь eww, ewp и некоторые служебные файлы среды? Ведь это разные сути.

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

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

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

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

Сообщение отредактировал Т.Достоевский - Nov 7 2007, 15:50
Go to the top of the page
 
+Quote Post
Николай Z
сообщение Nov 7 2007, 15:57
Сообщение #51


Местный
***

Группа: Участник*
Сообщений: 418
Регистрация: 20-08-07
Пользователь №: 29 930



Цитата(Т.Достоевский @ Nov 7 2007, 18:42) *
Весь проэкт называется теплица, состоит из:
Обьектовый плк,
Центральный модуль,
Прорамма на пк.

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

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

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


Это.... типа.... оппа... А нельзя ли это перевести на нормальный русский технический язык Ваш вопрос?
А то как-то совершенно неясно что именно Вы желаете спросить.
Go to the top of the page
 
+Quote Post
IgorKossak
сообщение Nov 7 2007, 15:59
Сообщение #52


Шаман
******

Группа: Модераторы
Сообщений: 3 064
Регистрация: 30-06-04
Из: Киев, Украина
Пользователь №: 221



to Т.Достоевский
Был и у меня подобный случай.
В одном воркспейсе три проекта на три разные МК.
Для общих файлов имею привычку создавать папку Common, на которую и делаю ссылки из проектов примерно так:
Код
$PROJ_DIR$\..\Common\

Структура получается примерно такая:
Код
Proj1
    Src
    Proj1.ewp
Proj2
    Src
    Proj2.ewp
...
Common
Device.eww
Go to the top of the page
 
+Quote Post
fmdost
сообщение Nov 7 2007, 16:09
Сообщение #53


Местный
***

Группа: Свой
Сообщений: 479
Регистрация: 8-05-07
Из: г. Ставрополь. Северный Кавказ. Россия
Пользователь №: 27 606



Цитата(Николай Z @ Nov 7 2007, 19:57) *
Это.... типа.... оппа... А нельзя ли это перевести на нормальный русский технический язык Ваш вопрос?
А то как-то совершенно неясно что именно Вы желаете спросить.

Ответил зачем мне желательно помещать хидер в корень проэкта.
Ответ на вопрос "Как прописать путь к файлу" получил давно и в полной мере. Спасибо всем.


Цитата(IgorKossak @ Nov 7 2007, 19:59) *
to Т.Достоевский
Был и у меня подобный случай.
В одном воркспейсе три проекта на три разные МК.
Для общих файлов имею привычку создавать папку Common, на которую и делаю ссылки из проектов примерно так:
Код
$PROJ_DIR$\..\Common\

Структура получается примерно такая:
Код
Proj1
    Src
    Proj1.ewp
Proj2
    Src
    Proj2.ewp
...
Common
Device.eww

О! Теперь воркспейсы то-же так сделаю.
Go to the top of the page
 
+Quote Post
Николай Z
сообщение Nov 7 2007, 17:46
Сообщение #54


Местный
***

Группа: Участник*
Сообщений: 418
Регистрация: 20-08-07
Пользователь №: 29 930



Цитата(Т.Достоевский @ Nov 7 2007, 19:09) *
Ответил зачем мне желательно помещать хидер в корень проэкта.
Ответ на вопрос "Как прописать путь к файлу" получил давно и в полной мере. Спасибо всем.
О! Теперь воркспейсы то-же так сделаю.


Да не за что... Мне лично не жалко...
Вот только я что-то сомневаюсь, в том, что помещать больше одного проекта в один корень имеет хоть какой-то смысл.

Имеет смысл - завести общую директорию, куда сваливаете(возможно в тематические подиректории) - разные части разных наработок, а вот общую директорию для 2-3-4-х текущих проектов иметь - по-моему нецелесообразно. Просто жаль времени, которое потом тратится на растаскиваение кучи разных файлов при последующем сохранении завершенного проекта и дальнейшем его сопровождении...

Впрочем в этом деле каждый следует своим убеждениям и привычкам и пусть Вам в этом помогает Ваш собственный опыт. Чужие шишки как известно не болят... Для начала - всегда надо попробовать набить 2-3-4 штуки собственных biggrin.gif
Go to the top of the page
 
+Quote Post
IgorKossak
сообщение Nov 7 2007, 18:55
Сообщение #55


Шаман
******

Группа: Модераторы
Сообщений: 3 064
Регистрация: 30-06-04
Из: Киев, Украина
Пользователь №: 221



Николай Z, поясню в каом случае и почему я делаю именно так как показал.
Например, когда делается многопроцессорная плата и разные МК на ней связаны некоторым интерфейсом.
В этом случае изменение общей части должно повлечь за собой пересборку во всех связанных проектах. Для этого в IAR есть даже специальная команда Batch build..., которая действует в пределах воркспейса.
Разнородные же проекты, естественно нет смысла валить в кучу.
Go to the top of the page
 
+Quote Post
Николай Z
сообщение Nov 7 2007, 22:20
Сообщение #56


Местный
***

Группа: Участник*
Сообщений: 418
Регистрация: 20-08-07
Пользователь №: 29 930



Цитата(IgorKossak @ Nov 7 2007, 21:55) *
Николай Z, поясню в каом случае и почему я делаю именно так как показал.
Например, когда делается многопроцессорная плата и разные МК на ней связаны некоторым интерфейсом.
В этом случае изменение общей части должно повлечь за собой пересборку во всех связанных проектах. Для этого в IAR есть даже специальная команда Batch build..., которая действует в пределах воркспейса.
Разнородные же проекты, естественно нет смысла валить в кучу.


Ну так по-моему Ваши подпроекты вовсе не обязаны лежать для этого в одной директории?
Я этот вариант не проверял, но что-то мне подсказывает, что если они будут лежать в соседних поддиректориях - то вряд ли что-то поменяется?
Go to the top of the page
 
+Quote Post
IgorKossak
сообщение Nov 8 2007, 08:03
Сообщение #57


Шаман
******

Группа: Модераторы
Сообщений: 3 064
Регистрация: 30-06-04
Из: Киев, Украина
Пользователь №: 221



Цитата(Николай Z @ Nov 8 2007, 00:20) *
Ну так по-моему Ваши подпроекты вовсе не обязаны лежать для этого в одной директории?
Я этот вариант не проверял, но что-то мне подсказывает, что если они будут лежать в соседних поддиректориях - то вряд ли что-то поменяется?

А они и так соседние друг по отношению к другу. Обьединяет их лишь директория воркспейса, в которой помимо них есть всего один файл eww. Проекты связаны между собой относительными путями, возможностью пакетной сборки и замыслом.
По большому счёту диск D, где у меня всё лежит, тоже директория.
Go to the top of the page
 
+Quote Post
Николай Z
сообщение Nov 8 2007, 10:08
Сообщение #58


Местный
***

Группа: Участник*
Сообщений: 418
Регистрация: 20-08-07
Пользователь №: 29 930



Цитата(IgorKossak @ Nov 8 2007, 11:03) *
А они и так соседние друг по отношению к другу. Обьединяет их лишь директория воркспейса, в которой помимо них есть всего один файл eww. Проекты связаны между собой относительными путями, возможностью пакетной сборки и замыслом.
По большому счёту диск D, где у меня всё лежит, тоже директория.


Это логично.
Просто я сперва понял Вас так, что Ваши подпроекты лежат в одной дирректории.
А в таком варианте, который Вы обозначили - это на мой взгляд вполне логично.
Go to the top of the page
 
+Quote Post

4 страниц V   1 2 3 > » 
Reply to this topicStart new topic
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0

 


RSS Текстовая версия Сейчас: 24th July 2025 - 21:57
Рейтинг@Mail.ru


Страница сгенерированна за 0.01951 секунд с 7
ELECTRONIX ©2004-2016