Есть кусок кода

SOME_VAR определена в каком-то хэдэре, который виден эклиспу, но по каким-то причинам он не видит этот дефайн и соответственно весь код под ifdef становится ему не виден. Это страшно неудобно т.к. очень привык Ctrl+click на функции и попадать к её определению. А если она определена под таким блоком ifdef, то эклипс её не видит и приходится мучится с поиском.

Пути к инклюдам эклипс видит (дописал их в path and symbols, по ктрл+клику находит инклюды). Там же в symbols дописал эти дефайны - не помогло.

Подскажите как бороться с этим?

Надеялся, что по мнемоникам не будет вопросов. Кратко прокомментирую.
Свой Makefile пытался сделать максимально универсальным. Можно использовать и другие названия (`GNUmakefile', `makefile', и `Makefile'), понимая разницу между ними.
В начале Makefile есть определение типа проекта: С (CXX_PROJECT=NO) или С++ (CXX_PROJECT=YES). В строке 1) проверяется тип проекта. Если С++ проект, то выполняется строка 2), в противном случае строка 4) (С проект). $(CXX) соответствующий компилятор g++ (например, arm-none-eabi-g++), $(CC) - gcc (arm-none-eabi-gcc). $(INCS) полный список каталогов для поиска заголовочных файлов, исключая каталоги самого компилятора. $(ALL_CXXFLAGS) - ключи (опции) для g++, $(ALL_CFLAGS) - для gcc. Они различаются, так как не все опции совпадают и могут быть применены (например, gnu99 для gcc). Строка 6) удаление ненужного служебного файла зависимостей spec.d, созданного в результате запуска компилятора.

Командная строка:

вызов утилиты make для достижения цели discovery для файла specs_file, название которого определяется встроенной в Eclipse переменной ${INPUTS}.

а если в проекте и с и с++?

И ещё *.S для полноты.
Правила компиляции файлов Вы сами задаете в Makefile. Например, для *.S

где
ASXX = $(CROSS_TOOLS)gcc -x assembler-with-cpp
AS = $(CROSS_TOOLS)gcc
$(CROSS_TOOLS) - префикс или полный путь (arm-none-eabi- или /opt/GNU_ARM/4.7_2013q3/bin/arm-none-eabi-)

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

Есть в сети хороший перевод документации по утилите make.

ну с компиляцией то ладно - у меня чужой мейк файл и там сделано что он все нормально компилирует и собирает, я про то чему должно быть равно CXX_PROJECT=? чтобы в проекте где есть и си и с++ дефайны бы попадали в эклипс?

CXX_PROJECT=YES. Иначе не соберётся проект. Проекты с scmRTOS имеют все файлы (*.cpp, *.c, в зависимости от порта могут быть и *.S). Можете глянуть Makefile в портах для GCC. Они достаточно минималистичны и понятны.

ADD: в этом случае (CXX_PROJECT=YES) у Вас и

правильно подсвечивается.

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

хых...

ну вот получилось появилась консоль дополнительная в ней видно что дефайны появились

но вот эта дрянь все равно в эклипсе серая...

может еще что подкрутить надо?

ой.. тут как раз все сработало это я стормозил...
не срабатывает в core_cm4.h

блок


остается серым, хотя #define __VFP_FP__ 1 и не определена __SOFTFP__

Сообщение отредактировал сарматъ - Oct 12 2013, 09:51

Слегка помучившись, после некоторых экспериментов и углублённого изучения документации Eclipse, пришёл к следующему:
1. запускать дискаверинг после анализа CXX_PROJECT не верно, т. к. сама суть дискаверинга состоит в определении путей, дефайнов и прочего в зависимости от языка, которых в смешанном проекте может быть (в нашем случае) 1 или 2, а не в зависимости от некоего дефайна, определённого на весь проект.
2. изменил настройки проекта и makefile следующим образом:

IgorKossak, проверка именно вначале на С? Ведь далее идет запуск для CXX.
Учитывая, что расширения файлов для C++ не стандартизованы (cc, cpp) может делать сначала проверку на файл С, а все что не подходит считать файлом C++.

specs_file имеет расширение C для C++ и c для C.
Именно это имеется в виду.
Расширение присваивается самой Eclipse, точнее её плагином CDT. Вот так они решили
Кроме того, различать язык можно не только по расширению (переменная среды ${EXT}), а и по команде (переменная ${COMMAND}).
Во втором случае их можно различать по gcc или g++.

Если со временем не изменят расширение, то все хорошо. Для С невероятно, что поменяют.
Спасибо.
У себя буду переделывать, наверно, в таком виде:

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


Смотря какая вожжа под хвост попадёт. Могут поменять расширения на C и CPP
И в этом случае у Вас всё порушится. Так что без пространного комментария в мейкфайле не обойтись.

IgorKossak, Вы проверяли такую ситуацию:
проект имеет c и cpp файлы, причем включаемые файлы пользователя для C находятся в одной директории, а для CPP в другой. И для полноты картины и #define в файлах разные. В этом случае все корректно у Вас работало?

Не проверял, но не вижу препятствий.
Ведь если делается различие по флагам (ALL_CFLAGS и ALL_CXXFLAGS), то почему бы не сделать аналогичное различие и по INCS и по DEFS.

Добрый день.
Задам наверное глупый вопрос. Но я не совсем понял когда Eclipse вызывает make с целью discover? При ребилде он у меня это делает а можно ли как-то заставить делать это в фоновом режиме?

Цель discovery является целью только для Eclipse. Eclipse получает информацию о путях для заголовочных файлов и всех объявленных define. Результат работы влияет на навигацию по проекту и подсветку синтаксиса. Вполне логично, что цель строится при изменении исходных кодов проекта. У себя не замечал частых вызовов.