关于源代码目录结构的思考

我们同事今天讨论了一个问题：源代码目录结构。

 

一般源代码目录结构类似于这样的

-----include

 

-----drivers

  |

  ----uart

  |

  ----i2c

  |

  ---flash

  |

  ---timer

 

-----hardware

 

-----sys

  |

  ------os

  |

  ------hal

  |

  ------common

 

-----libs(for third party libs or app libs)

 

-----samples(for customer)

 

-----test case(test drivers or apps)

 

 

如果头文件中类型定义和函数声明超过1000行，最好分成两个头文件，一个xxx_type.h， 一个xxx_def.h。最好定义一个xxx_cfg.h，用于配置模块。 把所有模块的配置头文件生成一个config.h(据说是gcc -E方法可以达到此目的)，然后直接只用gcc -iconfig.h连接config.h头文件，而不是直接包含头文件，因为如果直接包含，一旦config.h改变，则整个工程的编译要耗费很多时间。

 

但是linux系统采用了另外一个做法，采用menu config生成config.h，每个模块则有一个kconfig配置脚本。用户直接直接修改config.h或者重新修改kconfig然后menu config配置系统。

 

还有一个讨论，如果a.h可能修改为b.h， 但是很多源文件直接包含了a.h，修改起来可能很费时。但是如果我们加入一个c.h中间proxy，a.h包含进c.h，源文件直接包含c.h，如果a.h修改为b.h，我们只需要修改c.h文件即可。这也是一个设计模式的思路，可见设计模式在生活中无处不在啊。我们提供的客户的头文件都可以包含在xxx_lib.h，客户做二次开发只需要包含这个文件即可，因为用户不需要关心哪个头文件具体干什么，尽量傻瓜化。