Парсер C/C++ в эклипсе Опции

[esaulenka]

Здравствуйте.

Занимаюсь реанимацией древнего проекта.
Разрабатывалось оно в CodeWarrior, но в 2017 году тамошним редактором я пользоваться не могу совсем.
Перетащил все файлики в эклипс (компилятор оставил старый). Подсветка-рефакторинг-поиск - всё прекрасно, но...

Но как научить эклипс корректно обрабатывать конструкции вида
{asm{nop};}
или
uchar DEVID_ @ (DevInfoAddr+4) = 123;
?
При виде первой он подчёркивает всё, что дальше, красным.
Во втором просто не видит переменной.

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

где-нибудь объявить

Код

#if REAL_BUILD
#define ECLIPSE(...) __VA_ARGS__
#else
#define ECLIPSE(...)
#endif

и затем

Код

ECLIPSE({asm{nop}});

uchar DEVID_ ECLIPSE(@ (DevInfoAddr+4)) = 123;

REAL_BUILD надо указать в дефайнах при билде (в проекте codewarior или как вы строите), но не указывать в дефайнах в эклипсе

Ну или взять исходники cdt и подхачить их

[Aaron]

я делал иначе - создавал отдельный .h - файл, подключаемый к файлам проекта, где неизвестные для эклипса конструкции задавал через #define.
Сам .h-файл оборачивался в #if для различных компиляторов вида:
#define __ECLIPSE__
#if defined (__SDCC__)
#elif defined (__ARMCC__)
#elif defined (__GNUC__)
#elif defined (__ECLIPSE__)
#endif
Такой подход позволит и работать с кодом в эклипсе, и запускать компиляцию разными компиляторами без коррекции каждый раз макроса, т.к. вызываемые компиляторы добавляют свои встроенные определения, автоматом подхватится нужный кусок из h-файла. Баловался таким именно когда использовал одни и те же файлы для абсолютно разных компиляторов.
Сейчас не помню, вроде как для парсинга эклипс использует по-умолчанию GNUC компилятор и его определения.. Ну если что - #elif defined (__ECLIPSE__) покатит.

Второй путь - добавить такие макроопределения на уровне свойств проекта (Paths and Symbols) - тогда в коде проекта не придётся ничего добавлять/изменять.