IAR Embedded Workbench не может найти файлы Pe1696, хотя ищет их

Я использую IAR Embedded workbench 5.51 для MSP430. Я использую C99.

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

Неустранимая ошибка [Pe1696]: невозможно открыть исходный файл "ThirdPartyLib / Subdir / file.h"

Однако в журнале IAR показывает:

искал: "C: \ ... бла бла бла ... \ Source \ ThirdPartyLib \ Subdir \"

Операторы include в каждом из исходных файлов в этой библиотеке похожи на:

#include "ThirdPartyLib/Subdir/someheader.h"

Я попытался добавить путь к препроцессору C, перейдя по ссылке:

Проект -> Параметры -> Компилятор C / C ++ -> Препроцессор

и добавляем строки:

$PROJ_DIR$\ThirdPartyLib\
$PROJ_DIR$\ThirdPartyLib\Subdir\
$PROJ_DIR$\ThirdPartyLib\Utils\

У меня не проверено "Многофайловая компиляция".

Все исходные файлы, о которых идет речь, были добавлены в проект. Я создал группы, чтобы имитировать структуру каталогов библиотеки.

Проблема исчезнет, ​​если я изменю пути с абсолютных на относительные пути, такие как

#include "somelocalheader.h"
#include "../Utils/someotherheader.h"

Но я имею дело с большим количеством файлов и хочу как можно меньше изменять их.

У меня никогда раньше не было проблем с этим - кто-нибудь знает, почему это могло произойти. Есть ли простое решение для этого, чтобы мне не приходилось очищать каждый оператор include в каждом файле c?

Вот как выглядит мое дерево каталогов:

  • Source
    • Debug
      • Exe
        • Output.d43
      • List
        • blabla.map
      • Obj
        • ...
    • Release
      • ...
    • settings
      • ...
    • ThirdPartyLib
      • Subdir
        • ... Third Party Code Files Live Here ...
      • Utils
        • ... More Third Party Code Files Live Here ...
    • ... Мой код живет здесь вместе с EWP, EWW и т. Д.

РЕДАКТИРОВАТЬ №2: я переместил каталог ThirdPartyLib на более высокий уровень, потому что я рекурсивно запускаю doxygen на / Source / и понял, что doxygen принимает НАВСЕГДА, и, кроме того, у библиотеки есть собственный API.

Во всяком случае, вот как выглядит структура сейчас:

  • Working Copy
    • Source
      • Debug
        • Exe
          • Output.d43
        • List
          • blabla.map
        • Obj
          • ...
      • Release
        • ...
      • settings
        • ...
      • ... Мой код живет здесь вместе с EWP, EWW и т. Д.
    • ThirdPartyLib
      • Subdir
        • ... Third Party Code Files Live Here ...
      • Utils
        • ... More Third Party Code Files Live Here ...

Я снова добавил в свой проект группу для ThirdPartyLib с двумя подгруппами SubDir и Utils и добавил все файлы из каталогов Subdir и Utils в соответствующие подгруппы.

Теперь я снова попытался скомпилировать это и снова столкнулся с ошибкой Pe1696. IAR говорит:

searched: "C:\...\Working Copy\ThirdPartyLib\SubDir"

Тем не менее, он все еще не находит файлы.

Я сослался на этот пост: http://e2e.ti.com/support/low_power_rf/f/155/t/110195.aspx Я не уверен, что это полностью актуально, потому что каталоги, которые я включаю, похоже, не «выпали». IAR явно ищет файлы.

Но я все равно попытался добавить в препроцессор следующие строки

$PROJ_DIR$\..\ThirdPartyLib\SubDir
$PROJ_DIR$\..\ThirdPartyLib\utils

Кажется, это не помогает. Я получаю эти дополнительные строки в журнале сообщений:

searched: "C:\...\Working Copy\Source\..\ThirdPartyLib\SubDir\"
searched: "C:\...\Working Copy\Source\..\ThirdPartyLib\Utils\"

Редактировать №3. Я попытался переместить EWW / EWP на уровень выше до «Рабочей копии», а затем прочитал все группы и все файлы ... без костей. Я потерялся здесь. Больше всего расстраивает то, что та же библиотека реализована в другом проекте, который был выполнен некоторыми бывшими разработчиками, и я пытаюсь включить ее таким же образом. Я знаю, что это будет что-то тривиальное, просто не знаю что.


person Nick    schedule 08.07.2013    source источник
comment
Покажите, пожалуйста, дерево каталогов вашего проекта. Поскольку пути включения начинаются с lib/, препроцессор будет ожидать, по крайней мере, найти каталог lib в вашем пути включения.   -  person Austin Phillips    schedule 09.07.2013
comment
Остин, я использую проприетарную библиотеку, поэтому имя libdir заменяет настоящее имя этой библиотеки. Но я отредактирую свой пост, включив в него что-то более информативное для дерева каталогов.   -  person Nick    schedule 09.07.2013
comment
Хорошо, я редактировал OP. Отныне каталог библиотеки - ThirdPartyLib, и он включает в себя два подкаталога Subdir и Utils. Все находится в папке с именем Source.   -  person Nick    schedule 09.07.2013
comment
Учитывая вашу последнюю структуру каталогов, не должно Working Copy быть в пути включения, а не ...\ThirdPartyLib, поскольку все ссылки внутри библиотеки относятся к ThirdPartyLib/xxx? Компилятор будет эффективно объединять каждую командную строку, включая путь и путь #include при поиске.   -  person Austin Phillips    schedule 10.07.2013
comment
Да, ты прав! $ PROJ_DIR $ \ .. \ .. \ Working Copy \ Fixes it ... Мне просто нужно было назвать имя каталога Working Copy. Как я могу отдать вам должное / пометить это как ответ, если вы ответили на это в комментарии?   -  person Nick    schedule 11.07.2013
comment
Рад, что это сработало. Я сформулировал ответ, в котором резюмируются комментарии.   -  person Austin Phillips    schedule 11.07.2013


Ответы (1)


Если все ссылки #include внутри библиотеки имеют форму #include "ThirdPartyLib/Subdir/file.h", то корневой каталог, в котором находится ThirdPartyLib, должен находиться в пути включения препроцессора.

Если ваша структура каталогов:

C:\My Project\Source
             \ThirdPartyLib

тогда ожидается, что C:\My Project будет в пути включения препроцессора.

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

person Austin Phillips    schedule 10.07.2013