[mdmitry 0]

.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

 

Надеялся, что по мнемоникам не будет вопросов. :laughing: Кратко прокомментирую.

Свой 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}.

[сарматъ 0]

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

[mdmitry 0]

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

И ещё *.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.

[сарматъ 0]

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

[mdmitry 0]

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

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

 

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

 #ifdef __cplusplus
extern "C" {
#endif

#ifdef __cplusplus
}
#endif

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

[сарматъ 0]

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

 

хых...

 

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

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

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

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

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

 

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

не срабатывает в core_cm4.h

 

блок

  #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__

Изменено 12 октября, 2013 пользователем сарматъ

[IgorKossak 0]

Слегка помучившись, после некоторых экспериментов и углублённого изучения документации 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 0]

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 0]

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

Именно это имеется в виду.

Расширение присваивается самой Eclipse, точнее её плагином CDT. Вот так они решили ;)

Кроме того, различать язык можно не только по расширению (переменная среды ${EXT}), а и по команде (переменная ${COMMAND}).

Во втором случае их можно различать по gcc или g++.

[mdmitry 0]

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 0]

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

Да вроде бы давно уже так.

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

 

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

Смотря какая вожжа под хвост попадёт. Могут поменять расширения на C и CPP ;)

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

[mdmitry 0]

IgorKossak, Вы проверяли такую ситуацию:

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

[IgorKossak 0]

Не проверял, но не вижу препятствий.

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

[abutorin 0]

Добрый день.

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

[mdmitry 0]

Добрый день.

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

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