Cosmojam 0 9 октября, 2013 Опубликовано 9 октября, 2013 · Жалоба Есть кусок кода #if SOME_VAR void func(void); #else SOME_VAR определена в каком-то хэдэре, который виден эклиспу, но по каким-то причинам он не видит этот дефайн и соответственно весь код под ifdef становится ему не виден. Это страшно неудобно т.к. очень привык Ctrl+click на функции и попадать к её определению. А если она определена под таким блоком ifdef, то эклипс её не видит и приходится мучится с поиском. Пути к инклюдам эклипс видит (дописал их в path and symbols, по ктрл+клику находит инклюды). Там же в symbols дописал эти дефайны - не помогло. Подскажите как бороться с этим? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
сарматъ 0 9 октября, 2013 Опубликовано 9 октября, 2013 · Жалоба попробовать сделать переиндексацию Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Cosmojam 0 9 октября, 2013 Опубликовано 9 октября, 2013 · Жалоба попробовать сделать переиндексацию Неа, и настройки индексера менял (включал "index unused headers"). Не прокатывает Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AHTOXA 14 9 октября, 2013 Опубликовано 9 октября, 2013 · Жалоба Подскажите как бороться с этим? Смотрите вот здесь. (Это касаемо заголовка топика, про дефайны в makefile). Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Сергей Борщ 119 9 октября, 2013 Опубликовано 9 октября, 2013 · Жалоба Смотрите вот здесь. (Это касаемо заголовка топика, про дефайны в makefile). Да, удобная была штука. А вот в Eclipse kepler у меня пропала напрочь. Выкусили? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
mdmitry 0 9 октября, 2013 Опубликовано 9 октября, 2013 · Жалоба Да, удобная была штука. А вот в Eclipse kepler у меня пропала напрочь. Выкусили? Использую так: Eclipse Kepler SR1 Project->Properties->C/C++ General->Preprocessor Include Paths, Macros etc.->Providers: CDT GCC Built-in compiler Settings [checked] Use providers shared between projects [unchecked] Allocate console in the Console View [checked] в командной строке: make specs_file=${INPUTS} discovery в Makefile .PHONY: discovery discovery: ifeq ($(CXX_PROJECT),YES) $(CXX) $(INCS) $(ALL_CXXFLAGS) -E -P -v -dD '$(specs_file)' else $(CC) $(INCS) $(ALL_CFLAGS) -E -P -v -dD '$(specs_file)' endif $(REMOVE) spec.d Замеченные неудобства: из Makefile глобальные дефайны задаваемые в командной строке компилятора (-DSOMENAME) не распознаются. Проблем, описанных здесь не заметил. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Сергей Борщ 119 9 октября, 2013 Опубликовано 9 октября, 2013 · Жалоба Использую так:Спасибо! Сам бы не догадался. Кстати, все -D из makefile передаются. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Cosmojam 0 9 октября, 2013 Опубликовано 9 октября, 2013 · Жалоба Смотрите вот здесь. (Это касаемо заголовка топика, про дефайны в makefile). О, спасибо, пол-беды решено. А вот с дейфайнами внутри хидеров какие-то глюки индексера видимо. Некоторые нормально видит, некоторые - нет. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Cosmojam 0 10 октября, 2013 Опубликовано 10 октября, 2013 · Жалоба Кажется понял причину. В каталоге проекта есть неиспользуемые при сборке хидеры, в которых нужные символы переобъявлены. В данном случае это lwipots.h из юниттестов в составе lwip. Видимо реальный lwipopts.h индексируется раньше чем тестовый и некоторые символы оказываются переобъявлены. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
mdmitry 0 10 октября, 2013 Опубликовано 10 октября, 2013 · Жалоба Кстати, все -D из makefile передаются. Да, передаются правильно. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
IgorKossak 0 10 октября, 2013 Опубликовано 10 октября, 2013 · Жалоба Да, удобная была штука. А вот в Eclipse kepler у меня пропала напрочь. Выкусили? Не выкусили, глубже зарыли (по умолчанию скрыто, но можно открыть Window->Preferences->C/C++->Property Pages Settings) и объявили deprecated. В версии Luna обещали удалить вообще, но пока ещё наблюдаю. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Сергей Борщ 119 10 октября, 2013 Опубликовано 10 октября, 2013 · Жалоба В версии Luna обещали удалить вообще, но пока ещё наблюдаю.Раз новый вариант мы с помощью mdmitry освоили, можно его смело забыть. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
сарматъ 0 11 октября, 2013 Опубликовано 11 октября, 2013 (изменено) · Жалоба хых... расскажите какую проблему вы тут решаете? что то я не могу уловить разницы что с этими опциями CDT GCC Built-in compiler Settings [checked] Use providers shared between projects [unchecked] Allocate console in the Console View [checked] в командной строке: make specs_file=${INPUTS} discovery собираю что с теми что по умолчанию... если вставляю это в майкфайл ifeq ($(CXX_PROJECT),YES) $(CXX) $(INCS) $(ALL_CXXFLAGS) -E -P -v -dD '$(specs_file)' else $(CC) $(INCS) $(ALL_CFLAGS) -E -P -v -dD '$(specs_file)' endif $(REMOVE) spec.d вообще не собирается пишет ошибку что какого то разделителя не хватает... Изменено 11 октября, 2013 пользователем сарматъ Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Сергей Борщ 119 11 октября, 2013 Опубликовано 11 октября, 2013 · Жалоба расскажите какую проблему вы тут решаете? что то я не могу уловить разницыКак бы проще объяснить - в makefile задаются некие глобальные опции проекта: 1) компилятор и, следовательно, пути к его библиотечным заголовочным файлам. 2) сторонние библиотеки и, следовательно, пути поиска их заголовочных файлов. 3) Тип процессора, который может определять некие define, по которым в некоторых файлах (и заголовчных, и исходного кода) могут включаться какие-либо участки либо подключаться те или иные другие заголовочные файлы. 4) просто какие-то глобальные на весть проект #define вроде NDEBUG Вот чтобы эклипса могла все это учитывать, правильно раскрашивать исходники и правильно осуществлять навигацию по ним, обо всех этих параметрах надо ей правильно сообщить. Можно тупо их набивать на соответствующих вкладках вручную. Но во-первых это нудно, а во-вторых при любом изменении придется править как минимум в двух местах - в makefile и на одной/нескольких вкладках Эклипсы. Это муторно и не наш метод. В эклипсе реализован автоматический механизм: она вызывает компилятор, пытками ;) заставляет его выдать в stdout все #define и пути, после чего анализирует и усваивает вывод. Вот чтобы компилятор выдал все что нужно с учетом наших установок в makefile мы и просим Эклипсу вызывать не голый писишный компилятор ${COMMAND} -E -P -v -dD "${INPUTS}", а определенный в нашем makefile компилятор со всеми необходимыми для нашего проекта опциями. И делаем мы это заставляя make достичь цель discovery. вообще не собирается пишет ошибку что какого то разделителя не хватает...Там в начале строк табуляторы должны стоять, а не пробелы. А перед этим куском должна стоять цель discovery: В общем у меня так: #discovery target for Eclipse parser .PHONY: discovery discovery: $(CC) $(INCLUDES) $(CFLAGS) -E -P -v -dD '$(specs_file)' P.S. чуть-чуть отшлифовал текст. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
сарматъ 0 11 октября, 2013 Опубликовано 11 октября, 2013 (изменено) · Жалоба понял, спасибо, буду пробовать может там еще слова волшебные какие шепнуть надо? у меня как был этот блок серым так и остался( #if (__FPU_PRESENT == 1) && (__FPU_USED == 1) SCB->CPACR |= ((3UL << 10*2)|(3UL << 11*2)); /* set CP10 and CP11 Full Access */ RCC->CR |= (uint32_t)0x00000001; RCC->CFGR = 0x00000000; RCC->CR &= (uint32_t)0xFEF6FFFF; #endif Изменено 11 октября, 2013 пользователем сарматъ Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться