gcc头文件依赖顺序所遇到的坑

公司的genmake编译系统是用python对ninja + gcc所写的一个wrapper, 最终编译命令诸如:

[100%] ${GCCPREFIX}/home/lajiang/.genmake/artifactory/toolchain/arm_gcc-8.3.0_glibc-2.28-x86_64-linux-gnueabihf/bin/arm-cisco-linux-gnueabihf-gcc -D_GNU_SOURCE -isystem platform/compiler/glibc -D_GCC8_ ${GCCOTHERSWITCHES} ${GCCCOLORSWITCHES} -Wall -Wextra -Wno-unknown-pragmas -Wno-discarded-qualifiers -Wno-sign-compare -Wno-missing-field-initializers -Wno-unused-result -Wno-unused-variable -Wno-unused-function -Wno-unused-but-set-variable -Wno-incompatible-pointer-types -Wno-implicit-function-declaration -Wno-unused-parameter -Wno-pointer-sign -Wno-format-truncation -Wno-return-type -Wno-array-bounds -Wno-missing-braces -Wno-misleading-indentation -Wno-stringop-overflow -Wno-implicit-fallthrough -Wno-sizeof-pointer-memaccess -Wno-parentheses -Wno-pointer-compare -Wno-cast-function-type -Wno-memset-elt-size -Wno-unused-value -Wno-int-conversion -Wno-format -Wno-bool-compare -Wno-enum-compare -Wno-type-limits -Wno-unused-parameter -Wno-maybe-uninitialized -Wwrite-strings -Wno-psabi -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -isystem platform/compiler/glibc -D_GCC8_ -funwind-tables -rdynamic -fno-omit-frame-pointer -mabi=aapcs-linux -mapcs -B /home/lajiang/.genmake/artifactory/toolchain/arm_gcc-8.3.0_glibc-2.28-x86_64-linux-gnueabihf/bin/arm-cisco-linux-gnueabihf- --sysroot=/home/lajiang/.genmake/artifactory/toolchain/arm_gcc-8.3.0_glibc-2.28-x86_64-linux-gnueabihf/arm-cisco-linux-gnueabihf/sysroot -fno-common -fexceptions -fstack-protector-all -pthread -g -fPIC -fPIC -D_BUMBLEBEE_ -D_DSPGDVF2300_ -DTAM_SUPPORT -DNON_ANDROID -DDBUS_HAS_RECURSIVE_MUTEX -DGLIBC_VERSION_GT_2_19 -DUSE_CISCOSSL_7 -DFEATURE_IPV6 -DFEATURE_CE -DFEATURE_WLAN -DFEATURE_WLAN_IPV6 -DFEATURE_ASLR -DFEATURE_ICE -DFEATURE_BT -DFEATURE_USB -DFEATURE_HOTSPOT -DFEATURE_EEE -DFEATURE_DP_FAST -DFEATURE_VENDOR_CH -DFEATURE_VIDEO -DFEATURE_WIFI_DIAG -DFEATURE_WIFI_LTWT -DCPR_API_LINUX -DCPR_MEMORY_LITTLE_ENDIAN -DCPR_MEMORY_UNALIGNED -D__ICE__ -DDISABLE_MEM_MGMT -DFT_SHARED_LINE_CALL_LOG -DSDP_CPR -DSIP_FIXME -DUSE_TIMER_SELECT_BASED -D_REENTRANT -D_SYNERGYLIsecd-apiTE_ -D__GSI_SERVICEABILITY -D__HL_API__ -D__LIBXML2__ -D__EDGE__ -D__EDGE_PROTO_SYNERGYLITE__ -D_SYNERGYLITE_ -D__STDC_LIMIT_MACROS -iquote sipstack/synbase/sipcc -iquote sipstack/synbase/sipcc/include -iquote sipstack/synbase/sipcc/core/sipstack/h -iquote sipstack/synbase/sipcc/core/gsm/h -iquote sipstack/synbase/sipcc/core/sdp -iquote sipstack/synbase/sipcc/core/api -iquote sipstack/synbase/sipcc/core/ccapp -iquote sipstack/synbase/sipcc/core/utils -iquote sipstack/synbase/sipcc/core/ccapi -iquote sipstack/synbase/sipcc/core/ccapi/config -iquote sipstack/synbase/sipcc/plat/sl -iquote sipstack/synbase/sipcc/plat/common -iquote sipstack/synbase/sipcc/nattools/icemgr/api -iquote sipstack/synbase/sipcc/nattools/sockaddrutil/include -iquote sipstack/synbase/sipcc/nattools/icelib/include -iquote sipstack/synbase/sipcc/nattools/icelib/src -iquote _build/bumblebee/rootfs/libedge/infra/services/edge_gateway/api -iquote infra/include -iquote sipstack/synbase/cpr/linux -iquote 

假如某个.c需要cpr_types.h, 但是dir sipstack/synbase/cpr/include 和 dir infra/services/secd/include/security_toolkit都有cpr_types.h, 尽管其内容不同. 

假如先 sipstack/synbase/cpr/include -iquote 后 sipstack/synbase/cpr/include -iquote, 则gcc找到了前者的cpr_types.h, 即便后者也有cpr_types.h不再包含进项目内.
当然dir infra/services/secd/include/security_toolkit的其他h文件还是会被包含的.

_build/bumblebee/rootfs/libedge/infra/services/edge_gateway/api -iquote infra/include -iquote sipstack/synbase/cpr/linux -iquote 
sipstack/synbase/cpr/include -iquote 《------first
infra/lib/cuva/include -iquote infra/services/secd/include -iquote 
infra/services/secd/include/security_toolkit -iquote 《------second

此外, gcc所搜寻目录分为-iquote 和 -isystem, 前者普通路径后者系统路径. gcc cmd中, 先读普通路径后读系统路径:

...
_build/git-worktrees/git@sqbu-github.cisco.com/SL/security.git/750fc5b28824e31686de5987f1a2d91c5fcdfef7/secureApi/include -iquote
sipstack/synbase/sipcc -isystem
...

因此, 假如dir B作为一个system目录, dir A作为一个普通目录, 则dir B的a.h势必在dir A的a.h之后被引用. 同样决定gcc只会使用dir A的a.h.

要解决上述问题, 有几种方法:

1.  一般不同文件夹下的同名.h文件本就不应被同一个gcc build obj所引用到, 考虑写多个build obj并引用不同的目录.
2.  如build一个obj不得以同时引用带有同名文件的2个文件夹, 则应先明确本obj应该使用哪个.h文件, 将所使用的那个目录放在较前的位置. 

refer: Directory Options (Using the GNU Compiler Collection (GCC))Directory Options (Using the GNU Compiler Collection (GCC))https://gcc.gnu.org/onlinedocs/gcc/Directory-Options.html