|
|
  |
Как прописать путь к файлу?, IAR AVR |
|
|
|
Oct 16 2007, 22:38
|

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

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

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

|
Для того, чтобы компилятор находил заголовочные файлы, находящиеся не в той же директории, что и исходные, нужно указать ему путь к ним. Для этого служит ключ командной строки -I. Указать можно, также, и в опциях оболочки - вкладка там есть для этого в опциях компилятора, где можно прописать пути. По умолчанию там прописаны пути к системным заголовкам (которые идут в составе пакета). Добавьте там свой путь и все. Подробности в документации, там все есть, хотя что-то принципиально новое к уже сказанному там вряд ли найдется.
--------------------
«Отыщи всему начало, и ты многое поймёшь» К. Прутков
|
|
|
|
|
Oct 17 2007, 03:59
|

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

|
Цитата(dxp @ Oct 17 2007, 06:49)  Для того, чтобы компилятор находил заголовочные файлы, находящиеся не в той же директории, что и исходные, нужно указать ему путь к ним. Для этого служит ключ командной строки -I. Указать можно, также, и в опциях оболочки - вкладка там есть для этого в опциях компилятора, где можно прописать пути. По умолчанию там прописаны пути к системным заголовкам (которые идут в составе пакета). Добавьте там свой путь и все. Подробности в документации, там все есть, хотя что-то принципиально новое к уже сказанному там вряд ли найдется. Спасибо. Не знал что можно добавлять. Только не понял почему ему не понравился полный путь?
|
|
|
|
|
Oct 17 2007, 04:05
|
Знающий
   
Группа: Свой
Сообщений: 771
Регистрация: 16-07-07
Из: Волгодонск
Пользователь №: 29 153

|
Чтобы пути были относительно проекта, можно использовать $PROJ_DIR$, примерно так: ..\$PROJ_DIR$\ОбщиеФайлы\ Цитата(Т.Достоевский @ Oct 17 2007, 07:59)  Спасибо. Не знал что можно добавлять. Только не понял почему ему не понравился полный путь? Только что проверил, в #include "" работает и полный и относительный путь. Слэши не забыли проэкранировать?
|
|
|
|
|
Oct 17 2007, 07:24
|
Гуру
     
Группа: Свой
Сообщений: 2 702
Регистрация: 14-07-06
Пользователь №: 18 823

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

Гуру
     
Группа: Модераторы
Сообщений: 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)
|
|
|
|
|
Oct 17 2007, 09:58
|
Гуру
     
Группа: Свой
Сообщений: 2 702
Регистрация: 14-07-06
Пользователь №: 18 823

|
Цитата(Andy Mozzhevilov @ Oct 17 2007, 11:20)  А в чем сложность, собственно? То ли я не умею готовить, но у меня вот эти две папки |->_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 - все правильно. Но результат компиляции другой, так как была изменена общая часть. Концов не осталось.
--------------------
Уходя, оставьте свет...
|
|
|
|
|
Oct 17 2007, 10:23
|
Гуру
     
Группа: Свой
Сообщений: 10 920
Регистрация: 5-04-05
Пользователь №: 3 882

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

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

|
Цитата(Dog Pawlowa @ Oct 17 2007, 15:58)  То ли я не умею готовить, но у меня вот эти две папки |->_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 - все правильно. Но результат компиляции другой, так как была изменена общая часть. Концов не осталось. В общем, может это уже и не в топик данной темы, но все же отвечаю. Чтобы такого как у вас не случалось, общие части, которые могут быть использованы в разных проектах должны в каждом проекте иметь свои локальные копии, находящиеся под контролем системы 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". Результат компиляции до байта совпадает. Конец найден, и виноватый тоже  Цитата(rezident @ Oct 17 2007, 16:23)  И если проект ведет более, чем один программист, то данная концепция просто необходима. Система контроля версий это конечно хорошо, но согласованность при разработке в команде важнее. P.S. конечно в проектах, которые выполняю единолично, я позволяю себе больше вольностей  Если проект ведет более чем один программист система контроля версий - суровая необходимость. Иначе: - Вася, ты менял исходник в таком то каталоге? - Да, тебе кинуть? - Конечно, еще месяц назад надо было. - Да я же в отпуске был. Блин, сетевой каталог не открывается, давай флешку...
--------------------
Пасу котов...
|
|
|
|
|
Oct 17 2007, 11:04
|

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

|
Цитата(Dog Pawlowa @ Oct 17 2007, 16:57)  Ну, с виноватыми обычно проблем не бывает Признаюсь, инструкцию по SVN курил "не в затяжку", пользуюсь очевидными функциями. Про такую комбинацию не думал. Мне кажется, что могут быть проблемы, если отмотать версию в такой локальной копии common назад и случайно закоммитить. Но нужно подумать и попробовать. Спасибо. Я пользуюсь на данный момент CVS, как оно реализуется в SVN не совсем представляю, поскольку доку по SVN меня несколько насильно заставили покурить некоторые присутвующие в том числе здесь товарищи  . И в данный момент она недокурена пока. В CVS при извлечении по тэгу локальную версию закомитить будет нельзя, поскольку на ней будут так называемые липкие метки. Если нужно будет, допустим, выпустить релиз на основе именно этой комбинации исходников, ну типа исправить только тот небольшой баг, то тогда делается ветвь в проекте на основе текущей версии извлеченных исходных текстов и она уже комитится, но не мешает основному стволу разработки. При желании потом изменения можно внести на ствол.
--------------------
Пасу котов...
|
|
|
|
|
Oct 17 2007, 13:17
|

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

|
Цитата(Andy Mozzhevilov @ Oct 17 2007, 18:04)  Я пользуюсь на данный момент CVS, как оно реализуется в SVN не совсем представляю, поскольку доку по SVN меня несколько насильно заставили покурить некоторые присутвующие в том числе здесь товарищи  . И в данный момент она недокурена пока. Вот и плохо!  Но тебя раззи заставишь, если ты не хошь... Цитата(Andy Mozzhevilov @ Oct 17 2007, 18:04)  В CVS при извлечении по тэгу локальную версию закомитить будет нельзя, поскольку на ней будут так называемые липкие метки. Если нужно будет, допустим, выпустить релиз на основе именно этой комбинации исходников, ну типа исправить только тот небольшой баг, то тогда делается ветвь в проекте на основе текущей версии извлеченных исходных текстов и она уже комитится, но не мешает основному стволу разработки. При желании потом изменения можно внести на ствол. В Subversion принципиально это не отличается.
--------------------
«Отыщи всему начало, и ты многое поймёшь» К. Прутков
|
|
|
|
|
Oct 17 2007, 17:33
|

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

|
Спасибо за такое количество ответов! Цитата(Непомнящий Евгений @ Oct 17 2007, 08:05)  Чтобы пути были относительно проекта, можно использовать $PROJ_DIR$, примерно так: ..\$PROJ_DIR$\ОбщиеФайлы\ Только что проверил, в #include "" работает и полный и относительный путь. Слэши не забыли проэкранировать? Беру путь из заголовка в окошке. Что значит "Слэши проэкранировать?"
|
|
|
|
|
Oct 18 2007, 04:26
|
Знающий
   
Группа: Свой
Сообщений: 771
Регистрация: 16-07-07
Из: Волгодонск
Пользователь №: 29 153

|
Цитата(Т.Достоевский @ Oct 17 2007, 21:33)  Беру путь из заголовка в окошке. Что значит "Слэши проэкранировать?" #include "c:\\folder1\\folder2\\myFile.h" #include "..\\..\\folder2\\myFile.h"
|
|
|
|
|
Oct 18 2007, 16:22
|
Местный
  
Группа: Свой
Сообщений: 256
Регистрация: 4-11-04
Из: Болгария
Пользователь №: 1 050

|
Не нада екранироват Вот и пример из рабочего проекта Код #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 окружения? Не получается никак у меня.
|
|
|
|
|
Oct 18 2007, 17:54
|
Местный
  
Группа: Свой
Сообщений: 256
Регистрация: 4-11-04
Из: Болгария
Пользователь №: 1 050

|
Нет проблем. Хотелос написат что то типа #include "$SOURCE_CODE_DIR$\ARM\ATMEL\i2c.c" куда SOURCE_CODE_DIR переменная окружения. Но ето вообщем не работает в никаком компиляторе. Но можно жит и без етого
|
|
|
|
|
Oct 18 2007, 22:31
|
Местный
  
Группа: Свой
Сообщений: 256
Регистрация: 4-11-04
Из: Болгария
Пользователь №: 1 050

|
Да ето и ползуюс. Но делаю из опции проекта -> C/C++ Compiler -> Preprocessor -> Additional include directories ето включает их точно с -I. но #include "$SOURCE_CODE_DIR$\ARM\ATMEL\i2c.c" нравится болше    Но уви....
|
|
|
|
|
Oct 19 2007, 02:23
|

Знающий
   
Группа: Свой
Сообщений: 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" нравится болше    Но уви.... Мне вот вообще больше нравится #include "i2c.h" безотносительно того, где оно там закопано, в каких папках проекта. Поэтому опция -I в этом отношении рулит.
--------------------
Пасу котов...
|
|
|
|
|
Oct 19 2007, 06:39
|

Гуру
     
Группа: Свой
Сообщений: 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
|
|
|
|
|
Nov 4 2007, 18:25
|
Местный
  
Группа: Участник*
Сообщений: 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
|
|
|
|
|
Nov 6 2007, 08:29
|
Местный
  
Группа: Участник*
Сообщений: 418
Регистрация: 20-08-07
Пользователь №: 29 930

|
Цитата(IgorKossak @ Nov 5 2007, 18:08)  В каталоге с проектом include-файлы ищутся по умолчанию и без записи $PROJ_DIR$\ Проверил Ваше утверждение и удалил верхнюю строку, где один только $PROJ_DIR$\ и получил сразу ненайденные *.h файлы, которые лежат в дирректории самого проекта... Вывод - ваше предположение - ошибочно как минимум на моей версии...
Сообщение отредактировал Николай Z - Nov 6 2007, 08:33
|
|
|
|
|
Nov 6 2007, 13:47
|

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

|
Цитата(Николай Z @ Nov 6 2007, 10:29)  Вывод - ваше предположение - ошибочно как минимум на моей версии... Проверьте как минимум стандартный tutorial от IAR и убедитесь в обратном. Я, в свою очередь, имею несколько маленьких проектов, где все исходники и хедеры находятся в папке с проектом. НИКОГДА не снабжал свои проекты строкой $PROJ_DIR$\ (по началу просто не знал о ней). Все файлы видятся с любой версией продукта. Дело может быть вот в чём, согласно старым добрым Кернигану и Ричи строки #include "file.h" ищут файлы в той же директории, что и исходный файл, строки #include <file.h> ищут файл в директории тулчейна. Возможно, что Ваши исходники (в отличие от хедеров) лежат не в директории проекта.
|
|
|
|
|
Nov 6 2007, 18:24
|
Местный
  
Группа: Участник*
Сообщений: 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
|
|
|
|
|
Nov 6 2007, 21:12
|
Местный
  
Группа: Участник*
Сообщений: 418
Регистрация: 20-08-07
Пользователь №: 29 930

|
Цитата(Сергей Борщ @ Nov 6 2007, 22:22)  То есть вы полагаете, что достаточно указать корень, а все поддиректории "развесистого дерева" будут подключаться автоматически?  А Вы бы прочитали внимательно все от начала и поправку от IgorKossak- и все было бы понятно... Это я пояснял IgorKossak зачем нужна самая первая строчка в описании путей, которая показывает на корневую директорию проета и не более того. Немного Выше - мой же пост где как раз и указана (в простейшем варианте одна - а в более сложном должно быть столько, сколько необходимо) другая поддиректория проекта - это чуть измененный пример от IAR, который поставляется в составе пакета. Т.е. ответ на Ваш вопрос - коль скоро Вы его задали такой: Нет я так не полагаю и не утверждал нигде этого - как раз должны быть указаны все необходимые для поиска *.h файлов поддиректории, поскольку компилятор по умолчанию (замечу по теории будет) будет их искать только в директории toolchain-а(или если хотите - в дирректории системных библиотек) и в поддиретории, где расположены текущие *.c файлы. Первые - системные *.h файлы задаются #include <имя.h>, а вторые немного иначе: #include "имя.h" Полностью я способности IAR-компилятора не исследовал, а вот поправку IgorKossak - я не принял на основании прямой проверки на примере стандартного проекта FreeRTOS - о чем ему и написал.
Сообщение отредактировал Николай Z - Nov 6 2007, 21:18
|
|
|
|
|
Nov 6 2007, 21:55
|

Гуру
     
Группа: Модераторы
Сообщений: 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)
|
|
|
|
|
Nov 6 2007, 23:18
|
Местный
  
Группа: Участник*
Сообщений: 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, который в силу неизвестных нам обстоятельств - стал промышленным стандартом и наказанием программистов.... Наверное из-за всех наших предыдущих грехов от момента появления первого компьютера, на котором программировала еще легендарная Ада Лавлейс...
Сообщение отредактировал Николай Z - Nov 6 2007, 23:43
|
|
|
|
|
Nov 7 2007, 02:01
|

Гуру
     
Группа: Модераторы
Сообщений: 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, который в силу неизвестных нам обстоятельств - стал промышленным стандартом и наказанием программистов.... Приводите аргументы. Я не знаю, какие науки _вы_ изучали, а мне язык С кажется устроенным весьма системно. И что-то не слышал про "наказание" от тех, кто им профессионально владеет. Возможно, вы пропустили науку, именуемую "изучение языка высокого уровня С"?
--------------------
На любой вопрос даю любой ответ"Write code that is guaranteed to work, not code that doesn’t seem to break" ( C++ FAQ)
|
|
|
|
|
Nov 7 2007, 06:48
|
Бывалый
    
Группа: Свой
Сообщений: 1 584
Регистрация: 7-08-07
Пользователь №: 29 615

|
Выдержка из "Полного справочника по C++. 4 издание" автор Г. Шилдт.
Кавычки и угловые скобки, в которых указываются имена включаемых файлов, определяют способ их поиса на жестком диске. Если имя файла содержится в угловых скобках, он должен находиться в каталоге, указанном компилятором. Обычно это каталог INCLUDE, предназначенный для хранения всех заголовочных файлов. Если имя файла заключено в кавычки, как правило, его поиск выполняется в рабочем каталоге. Если файл не найден, поиск повторяется так, будто имя файла содержалось в угловых скобках.
PS. Добавить нечего.
|
|
|
|
|
Nov 7 2007, 08:05
|

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

|
Стиль составления структуры проектов может быть разный у разных программистов. Для простейших проектов это хранение всех исходников с хедерами (их не более 10) в одной папке с файлами проекта. Для сложных поектов это древовидная структура папок, которую представил alexander55 и которая применяется, скажем, в Linux и в очень многих проектах в сообществе Open Source. На эту тему, в общем, спора не возникает, но вот в чём вопрос, зачем держать в корневой папке проекта .c и .h файлы, где по смыслу должны лежать лишь eww, ewp и некоторые служебные файлы среды? Ведь это разные сути. Ведь это же крайне неудобно (опять же на мой взгляд) хотя бы с той точки зрения, что выделив исходники в отдельную папку их можно всей папкой скопировать и перенести в другой проект. С большими проектами я именно так и работаю, отсюда и моё недоумение тем, что же можно искать в папке $PROJ_DIR$\ В результате вышесказанного мои проекты выглядят примерно так:
|
|
|
|
|
Nov 7 2007, 08:17
|
Местный
  
Группа: Участник*
Сообщений: 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 минусов - было бы желание... В данном случае - минусы пересиливаются несомненными плюсами разработки и при желании легко снимаются без особенных трудов. Цитата Приводите аргументы. Я не знаю, какие науки _вы_ изучали, а мне язык С кажется устроенным весьма системно. И что-то не слышал про "наказание" от тех, кто им профессионально владеет. Возможно, вы пропустили науку, именуемую "изучение языка высокого уровня С"?  Я полагаю - это тема отдельного разговора, если об этом есть желание поговорить - тут все-таки немного другая тема... Тем не менее могу назвать то, что обычно относят к недостаткам C, когда рассматривают его с точки зрения теории т.н. "системно построенных" языков. Вот эти претензии: 1) Слабая типизация объектов... Пример тому - именно упомянутые Вами забитые warning-и... Вернее - это следствие слабой типизации. 2) Плохая "структуризация" программы, которая приводит к тому, что компилятор легко сбивается из-за простой забытой ";" , "," или "скобки" настолько, что даже не способен определить место ошибки... Это приводит к тому, что он диагностирует ошибку зачастую весьма далеко от места ее появления и Вам приходится просматривать в поиске этого места 3-4-5 или больше страниц текста. 3) Синтаксис провоцирующий написание весьма маловразумительных, но очень коротких выражений, кторые мало кто кроме самого автора способен понять за короткое время... Которые никак не повышают эффекитивность работы ни компилятора(сложно написанное и краткое - почти всегда компилируется хуже), ни эффективность работы человека пишушего или вынужденного разбираться в таком коде... Я думаю - для ответа Вам названных и известных еще 20-ть лет назад недостатков C - более чем достаточно... Если нужно - то продолжение этого перечисления Вы легко найдете в соответствующих форумах где этих "религиозных дискуссий" тьма. Я же предпочитаю на самом деле не вести их, а использовать то, что имею в данный момент здесь и сейчас... Ну принят C в качестве промышленного стандарта - и ладно. Приходится его использовать в работе и знать его слабые места и стараться их избегать - вот и все.
|
|
|
|
|
Nov 7 2007, 08:24
|
Местный
  
Группа: Участник*
Сообщений: 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
|
|
|
|
|
Nov 7 2007, 09:27
|

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

|
Цитата(Николай Z @ Nov 7 2007, 10:24)  Ну вот сделали такой проект, что без прописанной $PROJ_DIR$\ не обойтись - тем сделали, что в корень сложили важный настроечный файл *.h ... Что же теперь сделаешь? И даже более того - сами разрработчики видимо так же поступают часто иначе бы они в каждом примере не писали бы эту дирректорию в опциях проекта, которые поставляют вместе с компайлером. А-а-а-а!!! Ну так бы сразу и сказали, что проект чужой, а я уж было подумал, что Вы за такой подход агитируете  . Вынужден согласиться, что в примерах от IAR, во всяком случае для ARM, это встречается довольно часто. Очевидно, и такой подход имеет право на жизнь, раз им кто-то пользуется, хоть мне это и кажется неудобным.
|
|
|
|
|
Nov 7 2007, 09:58
|
Местный
  
Группа: Участник*
Сообщений: 418
Регистрация: 20-08-07
Пользователь №: 29 930

|
Цитата(IgorKossak @ Nov 7 2007, 12:27)  А-а-а-а!!! Ну так бы сразу и сказали, что проект чужой, а я уж было подумал, что Вы за такой подход агитируете  . Вынужден согласиться, что в примерах от IAR, во всяком случае для ARM, это встречается довольно часто. Очевидно, и такой подход имеет право на жизнь, раз им кто-то пользуется, хоть мне это и кажется неудобным. Дык я же с этого и начал по-моему отвечать - и привел как раз объяснение так сказать на примере примера IAR... Возможно я этот факт не слишком ясно пояснил сразу конечно... Ну и вообще, изначально это было возражение для Непомнящий Евгений - насчет того, что он перед $PROJ_DIR$\ поставил две точки - чего вообще говоря в IAR делать не нужно...
Сообщение отредактировал Николай Z - Nov 7 2007, 10:02
|
|
|
|
|
Nov 7 2007, 15:42
|

Местный
  
Группа: Свой
Сообщений: 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
|
|
|
|
|
Nov 7 2007, 15:57
|
Местный
  
Группа: Участник*
Сообщений: 418
Регистрация: 20-08-07
Пользователь №: 29 930

|
Цитата(Т.Достоевский @ Nov 7 2007, 18:42)  Весь проэкт называется теплица, состоит из: Обьектовый плк, Центральный модуль, Прорамма на пк.
Центральный модуль в свою очередь состоит из меги 64 и 8 тиней работающих как 485 адаптеры
В komand_descriptions.h лежит; скорость, количество байт в посылках, адреса регистров плк итд.
Например поменял скорость 485, и поменялась сразу везде. Адреса/биты регистров, могут напрямую использоваться Ц на пк. Это.... типа.... оппа... А нельзя ли это перевести на нормальный русский технический язык Ваш вопрос? А то как-то совершенно неясно что именно Вы желаете спросить.
|
|
|
|
|
Nov 7 2007, 15:59
|

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

|
to Т.ДостоевскийБыл и у меня подобный случай. В одном воркспейсе три проекта на три разные МК. Для общих файлов имею привычку создавать папку Common, на которую и делаю ссылки из проектов примерно так: Код $PROJ_DIR$\..\Common\ Структура получается примерно такая: Код Proj1 Src Proj1.ewp Proj2 Src Proj2.ewp ... Common Device.eww
|
|
|
|
|
Nov 7 2007, 16:09
|

Местный
  
Группа: Свой
Сообщений: 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 О! Теперь воркспейсы то-же так сделаю.
|
|
|
|
|
Nov 7 2007, 17:46
|
Местный
  
Группа: Участник*
Сообщений: 418
Регистрация: 20-08-07
Пользователь №: 29 930

|
Цитата(Т.Достоевский @ Nov 7 2007, 19:09)  Ответил зачем мне желательно помещать хидер в корень проэкта. Ответ на вопрос "Как прописать путь к файлу" получил давно и в полной мере. Спасибо всем. О! Теперь воркспейсы то-же так сделаю. Да не за что... Мне лично не жалко... Вот только я что-то сомневаюсь, в том, что помещать больше одного проекта в один корень имеет хоть какой-то смысл. Имеет смысл - завести общую директорию, куда сваливаете(возможно в тематические подиректории) - разные части разных наработок, а вот общую директорию для 2-3-4-х текущих проектов иметь - по-моему нецелесообразно. Просто жаль времени, которое потом тратится на растаскиваение кучи разных файлов при последующем сохранении завершенного проекта и дальнейшем его сопровождении... Впрочем в этом деле каждый следует своим убеждениям и привычкам и пусть Вам в этом помогает Ваш собственный опыт. Чужие шишки как известно не болят... Для начала - всегда надо попробовать набить 2-3-4 штуки собственных
|
|
|
|
|
Nov 7 2007, 22:20
|
Местный
  
Группа: Участник*
Сообщений: 418
Регистрация: 20-08-07
Пользователь №: 29 930

|
Цитата(IgorKossak @ Nov 7 2007, 21:55)  Николай Z, поясню в каом случае и почему я делаю именно так как показал. Например, когда делается многопроцессорная плата и разные МК на ней связаны некоторым интерфейсом. В этом случае изменение общей части должно повлечь за собой пересборку во всех связанных проектах. Для этого в IAR есть даже специальная команда Batch build..., которая действует в пределах воркспейса. Разнородные же проекты, естественно нет смысла валить в кучу. Ну так по-моему Ваши подпроекты вовсе не обязаны лежать для этого в одной директории? Я этот вариант не проверял, но что-то мне подсказывает, что если они будут лежать в соседних поддиректориях - то вряд ли что-то поменяется?
|
|
|
|
|
Nov 8 2007, 10:08
|
Местный
  
Группа: Участник*
Сообщений: 418
Регистрация: 20-08-07
Пользователь №: 29 930

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