Eclipse Makefile project дефайны в мейкфайле, ifdef и индексация кода, Код за ifdef не индексируется и этих дефайнов эклипс не видит Опции

[Cosmojam]

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

Код

#if SOME_VAR
void func(void);
#else

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

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

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

[сарматъ]

попробовать сделать переиндексацию

[Cosmojam]

попробовать сделать переиндексацию

Неа, и настройки индексера менял (включал "index unused headers"). Не прокатывает

[AHTOXA]

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

Смотрите вот здесь.
(Это касаемо заголовка топика, про дефайны в makefile).

[Сергей Борщ]

Смотрите вот здесь.
(Это касаемо заголовка топика, про дефайны в makefile).

Да, удобная была штука. А вот в Eclipse kepler у меня пропала напрочь. Выкусили?

[mdmitry]

Да, удобная была штука. А вот в 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) не распознаются. Проблем, описанных здесь не заметил.

[Сергей Борщ]

Использую так:

Спасибо! Сам бы не догадался. Кстати, все -D из makefile передаются.

[Cosmojam]

Смотрите вот здесь.
(Это касаемо заголовка топика, про дефайны в makefile).

О, спасибо, пол-беды решено. А вот с дейфайнами внутри хидеров какие-то глюки индексера видимо. Некоторые нормально видит, некоторые - нет.

[Cosmojam]

Кажется понял причину. В каталоге проекта есть неиспользуемые при сборке хидеры, в которых нужные символы переобъявлены. В данном случае это lwipots.h из юниттестов в составе lwip. Видимо реальный lwipopts.h индексируется раньше чем тестовый и некоторые символы оказываются переобъявлены.

[mdmitry]

Кстати, все -D из makefile передаются.

Да, передаются правильно.

[IgorKossak]

Да, удобная была штука. А вот в Eclipse kepler у меня пропала напрочь. Выкусили?

Не выкусили, глубже зарыли (по умолчанию скрыто, но можно открыть Window->Preferences->C/C++->Property Pages Settings) и объявили deprecated.
В версии Luna обещали удалить вообще, но пока ещё наблюдаю.

[Сергей Борщ]

В версии Luna обещали удалить вообще, но пока ещё наблюдаю.

Раз новый вариант мы с помощью mdmitry освоили, можно его смело забыть.

[сарматъ]

хых... расскажите какую проблему вы тут решаете? что то я не могу уловить разницы что с этими опциями

CODE

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

собираю что с теми что по умолчанию...
если вставляю это в майкфайл

CODE

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

вообще не собирается пишет ошибку что какого то разделителя не хватает...

Сообщение отредактировал сарматъ - Oct 11 2013, 05:22

[Сергей Борщ]

расскажите какую проблему вы тут решаете? что то я не могу уловить разницы

Как бы проще объяснить - в makefile задаются некие глобальные опции проекта:
1) компилятор и, следовательно, пути к его библиотечным заголовочным файлам.
2) сторонние библиотеки и, следовательно, пути поиска их заголовочных файлов.
3) Тип процессора, который может определять некие define, по которым в некоторых файлах (и заголовчных, и исходного кода) могут включаться какие-либо участки либо подключаться те или иные другие заголовочные файлы.
4) просто какие-то глобальные на весть проект #define вроде NDEBUG

Вот чтобы эклипса могла все это учитывать, правильно раскрашивать исходники и правильно осуществлять навигацию по ним, обо всех этих параметрах надо ей правильно сообщить. Можно тупо их набивать на соответствующих вкладках вручную. Но во-первых это нудно, а во-вторых при любом изменении придется править как минимум в двух местах - в makefile и на одной/нескольких вкладках Эклипсы. Это муторно и не наш метод. В эклипсе реализован автоматический механизм: она вызывает компилятор, пытками заставляет его выдать в stdout все #define и пути, после чего анализирует и усваивает вывод. Вот чтобы компилятор выдал все что нужно с учетом наших установок в makefile мы и просим Эклипсу вызывать не голый писишный компилятор ${COMMAND} -E -P -v -dD "${INPUTS}", а определенный в нашем makefile компилятор со всеми необходимыми для нашего проекта опциями. И делаем мы это заставляя make достичь цель discovery.

вообще не собирается пишет ошибку что какого то разделителя не хватает...

Там в начале строк табуляторы должны стоять, а не пробелы. А перед этим куском должна стоять цель discovery:
В общем у меня так:

CODE

#discovery target for Eclipse parser
.PHONY: discovery
discovery:
    $(CC) $(INCLUDES) $(CFLAGS) -E -P -v -dD '$(specs_file)'

P.S. чуть-чуть отшлифовал текст.

[сарматъ]

понял, спасибо, буду пробовать

может там еще слова волшебные какие шепнуть надо?

у меня как был этот блок серым так и остался(

CODE

#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

Сообщение отредактировал сарматъ - Oct 11 2013, 08:58

[mdmitry]

CODE

.PHONY: discovery
discovery:
1)ifeq ($(CXX_PROJECT),YES)
2) $(CXX) $(INCS) $(ALL_CXXFLAGS) -E -P -v -dD '$(specs_file)'
3)else
4) $(CC) $(INCS) $(ALL_CFLAGS) -E -P -v -dD '$(specs_file)'
5)endif
6) $(REMOVE) spec.d

Надеялся, что по мнемоникам не будет вопросов. Кратко прокомментирую.
Свой 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 specs_file=${INPUTS} discovery

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

[сарматъ]

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

[mdmitry]

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

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

Код

# Assemble: create object files from assembler source files.
$(OBJDIR)/%.o : %.S $(BUILDONCHANGE)
    @echo $(MSG_ASSEMBLING) $<
ifeq ($(CXX_PROJECT),YES)
    $(ASXX) -c $(ALL_ASFLAGS) -o $@ $<
else
    $(AS) -c $(ALL_ASFLAGS) -o $@ $<
endif

где
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=? чтобы в проекте где есть и си и с++ дефайны бы попадали в эклипс?

[mdmitry]

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

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

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

Код

#ifdef __cplusplus
extern "C" {
#endif

#ifdef __cplusplus
}
#endif

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

[сарматъ]

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

хых...

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

CODE

#define STM32F40XX 1
#define USE_STDPERIPH_DRIVER 1
#define VER_MAJOR 0
#define VER_MINOR 1
#define HSE_VALUE 8000000

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

CODE

#if !defined (STM32F4XX) && !defined (STM32F40XX) && !defined (STM32F427X)
/* #define STM32F40XX */ /*!< STM32F40xx/41xx Devices */
/* #define STM32F427X */ /*!< STM32F427x/437x Devices*/
#endif

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

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

блок

CODE

#if defined (__VFP_FP__) && !defined(__SOFTFP__)
#if (__FPU_PRESENT == 1)
#define __FPU_USED 1
#else
#warning "Compiler generates FPU instructions for a device without an FPU (check __FPU_PRESENT)"
#define __FPU_USED 0
#endif

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

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

[IgorKossak]

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

Код

make extension="${EXT}" specs_file="${INPUTS}" discovery

Код

discovery:
ifeq ($(extension),C)
    @echo -- discovery for $(CXX)
    $(CXX) $(INCS) $(CXXFLAGS) -E -P -v -dD '$(specs_file)'
else
    @echo -- discovery for $(CC)
    $(CC) $(INCS) $(CFLAGS) -E -P -v -dD '$(specs_file)'
endif
    $(RM) spec.d

[mdmitry]

Код

make extension="${EXT}" specs_file="${INPUTS}" discovery

Код

discovery:
ifeq ($(extension),C)
    @echo -- discovery for $(CXX)
    $(CXX) $(INCS) $(CXXFLAGS) -E -P -v -dD '$(specs_file)'
else
    @echo -- discovery for $(CC)
    $(CC) $(INCS) $(CFLAGS) -E -P -v -dD '$(specs_file)'
endif
    $(RM) spec.d

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

[IgorKossak]

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

[mdmitry]

specs_file имеет расширение C для C++ и c для C.

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

Код

discovery:
ifeq ($(extension),с)
    @echo -- discovery for $(CС)
    $(CC) $(INCS) $(ALL_CFLAGS) -E -P -v -dD '$(specs_file)'
else
    @echo -- discovery for $(CXX)
    $(CXX) $(INCS) $(ALL_CXXFLAGS) -E -P -v -dD '$(specs_file)'
endif
    $(REMOVE) spec.d

[IgorKossak]

Если со временем не изменят расширение, то все хорошо.

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

Если со временем не изменят расширение, то все хорошо. Для С невероятно, что поменяют.

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

[mdmitry]

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

[IgorKossak]

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

[abutorin]

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

[mdmitry]

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

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

[abutorin]

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

Это я понял. Когда эклипс вызывает эту команду? При изменении файлов исходного кода этого не происходит. Сейчас заметил что при сборке проекта тоже не происходит. Хочется заставить эклипс это делать автоматом.

[mdmitry]

Когда эклипс вызывает эту команду? При изменении файлов исходного кода этого не происходит. Сейчас заметил что при сборке проекта тоже не происходит. Хочется заставить эклипс это делать автоматом.

Первый запуск будет после заполнения настроек в Eclipse для цели discovery. Clear Entries, Apply вызывает перестроение зависимостей.
Для постоянного вызова можно включить discovery в цель all, но зачем это?

[abutorin]

Первый запуск будет после заполнения настроек в Eclipse для цели discovery. Clear Entries, Apply вызывает перестроение зависимостей.
Для постоянного вызова можно включить discovery в цель all, но зачем это?

После внесения изменений каких либо дефайнов в исходниках эклипс этого не замечает. И продолжает ругаться что где-то, что-то не определено, хотя сборка происходит корректно.

[mdmitry]

После внесения изменений каких либо дефайнов в исходниках эклипс этого не замечает. И продолжает ругаться что где-то, что-то не определено, хотя сборка происходит корректно.

сейчас проверил на тестовом проекте. Изменил специально один define для условной компиляции. После пересборки подсвечиваются необходимые ветки условной компиляции.
Как Вы настраиваете Eclipse и какой Makefile?

[abutorin]

сейчас проверил на тестовом проекте. Изменил специально один define для условной компиляции. После пересборки подсвечиваются необходимые ветки условной компиляции.
Как Вы настраиваете Eclipse и какой Makefile?

Настраивал как вы рекомендовали в этой ветке.
В разделе C/C++ Generel->Preprocessor Include/Providers
галка CDTGCC Built-in Compiler Settings
команда make specs_file=${INPUTS} discovery
галка Allocate console in the concole view

Остальные галки сняты

[mdmitry]

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

CDT User Setting Entries
CDT Managed Build Setting Entries [Shared]
CDT GCC Build Output Parser

Настройки там не менялись.

В Makefile изменения идеалогически правильно делать как указал IgorKossak.

[Сергей Борщ]

Я понял, что на вкладке Providers достаточно оставить только CDT GCC Build-in compiler settings без галки "Use global provider shared between projects" (с ней эклипс пытается выполнить команду черт знает в какой директории и не находит там нужного makefile). CDT GCC Build Output Parser добавляет установки (директории заголовочных файлов, по умолчанию предопределенные символы и т.д.) от системного компилятора, которые абсолютно не нужны при кросс-компиляции.

Если память не изменяет, цель discovery вызывается не только после build, но еще и при принудительной переиндексации проекта (Project->C/C++ Index -> Rebuild).

[abutorin]

Если память не изменяет, цель discovery вызывается не только после build, но еще и при принудительной переиндексации проекта (Project->C/C++ Index -> Rebuild).

Никак не пойму. Она у меня только вызывается при изменении настроек. При ребилде не вызывается. При переиндексации тоже.

[IgorKossak]

Window->Preferences->C/C++->Indexer
+ Automatically update the index
+ Update index immediately after every file-save

Всё абсолютно верно.

[abutorin]

Window->Preferences->C/C++->Indexer
+ Automatically update the index
+ Update index immediately after every file-save

Похоже часть проблемы была в компе. Попробовал на другой машине все указанные настройки. Ручная переиндексация работает, обновление при пересборке работает. Но автоматическое обновление при сохранении файла не работает.

[mdmitry]

CDT GCC Build Output Parser добавляет установки (директории заголовочных файлов, по умолчанию предопределенные символы и т.д.) от системного компилятора, которые абсолютно не нужны при кросс-компиляции.

У меня выбран, но при просмотре найденных путей и define нет ничего от системного компилятора (mingw32-gcc), под linux не проверял. Позже посмотрю. А если не влият, то и не надо лишних действий, и можно отключить.

Window->Preferences->C/C++->Indexer
+ Automatically update the index
+ Update index immediately after every file-save

Так это вроде как по умолчанию выбрано.

[AHTOXA]

Я тут наконец-то дозрел до перехода на Luna. Вспомнил про эту тему, проштудировал.
Давайте я для потомков подытожу:

Настройка обнаружения дефайнов в Eclipse Kepler и более поздних

Project->Properties->C/C++ General->Preprocessor Include Paths, Macros etc.->Providers:

• Снимаем все прички в списке "Providers";
• Ставим причку на "CDT GCC Built-in compiler settings";
• В настройках этого провайдера:
  
  • снимаем птичку "Use global provider shared between projects";
    
  • в строке "Command to get compiler specs" прописываем:
    
    Код
    make extension="${EXT}" specs_file="${INPUTS}" discovery
• В makefile создаём цель для дисковеринга:
  
  Код
  #  specs_file has extension "C" for C++ and "c" for C.
  discovery:
  ifeq ($(extension),c)
      @echo -- discovery for $(CC)
      $(CC) $(INCS) $(CFLAGS) -E -P -v -dD '$(specs_file)'
  else
      @echo -- discovery for $(CCX)
      $(CXX) $(INCS) $(CXXFLAGS) -E -P -v -dD '$(specs_file)'
  endif
      $(RM) spec.d
  
  
• Если вдруг индексация не выполняется при изменении файлов проекта, зайти в
  Window->Preferences->C/C++->Indexer
  и проверить установку следующих птичек :
  
  • Automatically update the index
    
  • Update index immediately after every file-save

[IgorKossak]

По поводу индексации Антоха сказал всё правильно, но этого бывает не достаточно. Например, после изменения пути к тулчейну, изменения дефайнов в мейкфайле, и т. д.
Для обновления состояния проекта надо ещё провести "редискаверинг" - в настройках провайдера CDT GCC Built-in compiler settings нажать кнопку Clear Entries, потом Apply и наконец OK.

[Aaron]

Оу, спасибо! Наконец-то индексация в Luna заработала адекватно )))

[swisst]

Я тут наконец-то дозрел до перехода на Luna. Вспомнил про эту тему, проштудировал.
Давайте я для потомков подытожу:

можно увидеть Ваш вывод в консоль при вызове Index->Rebuild ?

не могу добиться стабильности на Luna - во первых команда Index->Rebuild ничего на консоль не выводит, манипуляция Properties->Providers->Clear Entries->Apply(OK) работает через раз (на консоль выводит, entries обновляет, завершается, правда, цель discovery с ошибкой) - перезапуск среды помогает.

Код

23:12:08 **** Running scanner discovery: CDT GCC Built-in Compiler Settings ****
make extension=C specs_file=D:/Prog/EclipseWS/.metadata/.plugins/org.eclipse.cdt.managedbuilder.core/spec.C discovery
COMSPEC detected C:\Windows\system32\cmd.exe
SHELL is C:/Windows/system32/cmd.exe, REMOVE_CMD is cs-rm
-- discovery for "C:\Program Files (x86)\GNU Tools ARM Embedded\4.9 2014q4\bin"\arm-none-eabi-gcc
"C:\Program Files (x86)\GNU Tools ARM Embedded\4.9 2014q4\bin"\arm-none-eabi-gcc "C:/Program Files (x86)/GNU Tools ARM Embedded/4.9 2014q4/arm-none-eabi/include" . ./cmsis  -ggdb -Os -mcpu=cortex-m0 -mthumb-interwork   -DVECT_TAB_FLASH -DFLASH_RUN -DLPC1114 -DLPC1114_TK -I. -I./cmsis -I. -ffunction-sections -fdata-sections -Wall -Wextra -Wcast-align -Wpointer-arith -Wredundant-decls -Wshadow -Wcast-qual -Wcast-align -Wa,-adhlns= -E -P -v -dD 'D:/Prog/EclipseWS/.metadata/.plugins/org.eclipse.cdt.managedbuilder.core/spec.C'
arm-none-eabi-gcc: error: 'D:/Prog/EclipseWS/.metadata/.plugins/org.eclipse.cdt.managedbuilder.core/spec.C': Invalid argument
Using built-in specs.
COLLECT_GCC=C:\Program Files (x86)\GNU Tools ARM Embedded\4.9 2014q4\bin\arm-none-eabi-gcc
Target: arm-none-eabi
Configured with: /home/build/work/GCC-4-9-build/src/gcc/configure --build=i686-linux-gnu --host=i686-w64-mingw32 --target=arm-none-eabi --prefix=/home/build/work/GCC-4-9-build/install-mingw --libexecdir=/home/build/work/GCC-4-9-build/install-mingw/lib --infodir=/home/build/work/GCC-4-9-build/install-mingw/share/doc/gcc-arm-none-eabi/info --mandir=/home/build/work/GCC-4-9-build/install-mingw/share/doc/gcc-arm-none-eabi/man --htmldir=/home/build/work/GCC-4-9-build/install-mingw/share/doc/gcc-arm-none-eabi/html --pdfdir=/home/build/work/GCC-4-9-build/install-mingw/share/doc/gcc-arm-none-eabi/pdf --enable-languages=c,c++ --disable-decimal-float --disable-libffi --disable-libgomp --disable-libmudflap --disable-libquadmath --disable-libssp --disable-libstdcxx-pch --disable-nls --disable-shared --disable-threads --disable-tls --with-gnu-as --with-gnu-ld --with-headers=yes --with-newlib --with-python-dir=share/gcc-arm-none-eabi --with-sysroot=/home/build/work/GCC-4-9-build/install-mingw/arm-none-eabi --with-libiconv-prefix=/home/build/work/GCC-4-9-build/build-mingw/host-libs/usr --with-gmp=/home/build/work/GCC-4-9-build/build-mingw/host-libs/usr --with-mpfr=/home/build/work/GCC-4-9-build/build-mingw/host-libs/usr --with-mpc=/home/build/work/GCC-4-9-build/build-mingw/host-libs/usr --with-isl=/home/build/work/GCC-4-9-build/build-mingw/host-libs/usr --with-cloog=/home/build/work/GCC-4-9-build/build-mingw/host-libs/usr --with-libelf=/home/build/work/GCC-4-9-build/build-mingw/host-libs/usr --with-host-libstdcxx='-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic -lm' --with-pkgversion='GNU Tools for ARM Embedded Processors' --with-multilib-list=armv6-m,armv7-m,armv7e-m,armv7-r
Thread model: single
gcc version 4.9.3 20141119 (release) [ARM/embedded-4_9-branch revision 218278] (GNU Tools for ARM Embedded Processors)
make: *** [discovery] Error 1

23:12:08 Build Finished (took 187ms)

[AHTOXA]

У вас в makefile похоже ошибка:

Код

"C:\Program Files (x86)\GNU Tools ARM Embedded\4.9 2014q4\bin"\arm-none-eabi-gcc "C:/Program Files (x86)/GNU Tools ARM Embedded/4.9 2014q4/arm-none-eabi/include" . ./cmsis  -ggdb -Os -mcpu=cortex-m0 -mthumb-interwork   -DVECT_TAB_FLASH -DFLASH_RUN -DLPC1114 -DLPC1114_TK -I. -I./cmsis -I. -ffunction-sections -fdata-sections -Wall -Wextra -Wcast-align -Wpointer-arith -Wredundant-decls -Wshadow -Wcast-qual -Wcast-align -Wa,-adhlns= -E -P -v -dD 'D:/Prog/EclipseWS/.metadata/.plugins/org.eclipse.cdt.managedbuilder.core/spec.C'

После arm-none-eabi-gcc с путём идут пути инклюдов без префикса "-I" ("C:/Program Files (x86)/GNU Tools ARM Embedded/4.9 2014q4/arm-none-eabi/include" . ./cmsis). Поэтому вызов make при дискаверинге завершается с ошибкой, и ничего не срабатывает. Чините makefile.

[Spider]

Прошу прощения что встреваю
А тоже самое возможно с sdcc?
Ключи подобные у компилятора есть. makefile я доработал примерно следующей строкой

Код

discovery:
    @echo Discovery $(extension)
    sdcc -I"C:\Program Files\SDCC\include" -E -dD "$(specs_file)"
    @echo ' '

но даже если у меня получается заставить Eclipse выполнить male .... discovery, то в консоль он ругается что нет такой цели для сборки discovery. Настройках проекта отключена генерация makefile и судя по всему он пользуется моим при сборке all или clear. Но вот discovery не хочет делать. Руками вызвать make получается. Как это?

Я не совсем допонимаю механизм работы этого всего. Что должно быть в результате? Как с этим связан spec.C файл?