代码之家  ›  专栏  ›  技术社区  ›  ataraxis

CMake和C源层次结构

  •  0
  • ataraxis  · 技术社区  · 7 年前

    在我的大多数项目中,我习惯于以下结构:

    src/
    inc/
    ext/
    build/
    [...]
    CMakeLists.txt
    README
    LICENCE
    

    哪里 src 是源代码所在的目录, inc 是标题, ext 是放置外部库(然后由CMake构建)的地方。


    这个结构看起来不太好,因为我面临以下问题:

    1. 我正在写图书馆。

    2. 在我的 股份有限公司 全部的 我的标题是, 私有的 平民的 一个。

    3. 在我的 CMakeLists.txt 我使用类似以下内容:

      target_include_directories(${PROJECT_NAME}
          PUBLIC
              inc
      )
      

    问题是,现在 全部的 private public 文件夹内 股份有限公司

    src/
    inc/
      private/
      public/
    ext/
    build/
    [...]
    CMakeLists.txt
    README
    LICENCE
    

    然后我可以使用:

    target_include_directories(${PROJECT_NAME}
        PUBLIC
            inc/public
        PRIVATE
            inc/private
    )
    

    1 回复  |  直到 7 年前
        1
  •  2
  •   Myst    7 年前

    老实说,我不是CMake的粉丝。我使用GNU make,它与我的操作系统捆绑在一起,我很高兴,我的代码对协作者的要求更少。

    但撇开CMake不谈,我会重新参观这个建筑。

    您的文件夹结构虽然并不少见,但与库或其组件无关。它不会为未来的维护人员提供任何可用信息。

    考虑下面的源代码结构:

    src
    src/io
    src/http
    src/pubsub
    src/database
    

    突然,没有阅读一行代码,我就有了一个关于应用程序(或库)可能是什么以及在哪里可以找到我可能需要查看的每个组件的强烈提示。

    看这张照片 Linux repo 例如

    在库中,这通常更重要,因为(希望)许多人会阅读代码并做出贡献。

    include文件夹在哪里? ...

    将头文件与源文件分离的问题是,这会使维护更加困难。

    我建议 usr/include (公共包含安装文件)可以使用脚本或 make

    另一个常见的选项是将公共头放在单独的文件中,该选项假定公共头与实现头明显分开(即,包含API限制,除非在主要修订期间,否则不进行编辑) include 文件夹