一，前言

之前已经定制了自己的menuconfig，并且让其生成#define xxx xxx，这样的二次开发工具还是有一些应用场景的，比如不熟悉功能的新手，通过界面的帮助提示来选择功能模块，最后生成config.h文件用来构建code。但是menuconfig主要还是用来生成makefile需要用的配置参数。所以呢，我又换成了之前轻度定制的menuconfig工具，并且基于我之前制作的stm32f4的makefile进行了简单的修改后，加入了.config的配置参数使用，参考nuttxOS工程中的make.defs，我在每个文件夹下添加了make.mk。一个完整的基于win10，带menuconfig的gcc makefile编译工程就完成了。

二，主要修改点

3.1 makefile的主要修改点
原来我做的makefile工程只能放入需要编译的c和h文件，说白了，不能多放预留文件。当然，我之前想到的方法就是通过一个h文件作为宏开关，现在支持可配置了，不需要添加h宏定义文件，也可以多放些预留文件啦！
修改前

C_SOURCES = $(foreach dir, $(DIRS), $(wildcard $(dir)/*.c))  
C_HEADERS = $(foreach dir, $(DIRS), $(wildcard $(dir)/*.h))

修改后

-include Src/make.mk
C_SOURCES = $(CSRCS-y)

3.2 来揭开make.mk神秘的面纱
Src文件夹下的make.mk,主要包含了关键路径，其中配置项CONFIG_USE_HARDWARE可以用来选择是否要编译Hardware文件夹的内容。

-include $(TOP_SRC)/Core/make.mk-include $(TOP_SRC)/Drivers/make.mk
ifeq ($(CONFIG_USE_HARDWARE),y)-include $(TOP_SRC)/Hardware/make.mk
endif-include $(TOP_SRC)/System/make.mk-include $(TOP_SRC)/User/make.mk

Hardware文件夹下的make.mk，里面有2个配置项用来决定是否要编译c文件。而其中VPATH是比较关键的，我之前用的是小写的vpath %.c $(sort $(dir $(C_SOURCES)))直接写入makefile的，但是现在我已经注释掉了，因为引入了make.mk，里面包括了大写的VPATH就直接设置了搜索c文件的路径。C_HEADERS_FOLDER是设置的头文件路径，直接在make.mk中添加-I也是可以的，但是我期望make.mk中尽量简短，所以我在makefile中添加$(addprefix -I,$(C_HEADERS_FOLDER))即可。关于DEPPATH是我从nuttxOS中参考来的，没删除，但这应该是不起作用的。

CSRCS-$(CONFIG_USE_LED) += led.c
CSRCS-$(CONFIG_USE_KEY) += key.c

VPATH += :$(TOP_SRC)/Hardware
C_HEADERS_FOLDER += '$(TOP_SRC)/Hardware'

3.3 至于Kconfig就使用标准语法即可
我使用了2个myKonfig，主的包含一个子的myKonfig，这个就是标准语法，没什么好说了。

menu 'Hardware'source Src/Hardware/myKconfig
endmenu

三，效果演示

定制的主界面

image.png

第一次配置中没有包括hardware文件夹

image.png

第二次追加配置，支持hardware文件夹中LED模块的配置项，make命令后，会进行增量编译如下

image.png

文件夹结构展示

image.png

四，总结

学以致用，乐趣无穷。用着自己开发的stm32F4工具链。基于win10 gcc的makefile及menuconfig的二次开发感觉好有成就感。虽然这和计算机视觉关系不大，有点跑题。但是难得花点时间玩玩，base工程环境搭建及各类实用工具开发，掌握这些内容是可以用来提高工作效率的。