可移植构建环境

Portable Build Environment

本文关键字：环境 构建 可移植      更新时间：2023-10-16

我正试图弄清楚如何定义我的构建环境。

  • 我有多个可重复使用的独立模块，它们是根据自己的发布时间表开发的
  • 我也有多个客户，每个客户都有自己的自定义构建应用程序，使用每个可重用模块的不同版本
  • 我的构建系统使用g++/makefiles

  • 我需要使它可移植到Cygwin和Linux。

    1. 假设每个模块/客户都是用自己的Makefile构建的，我如何配置我的Makefile以动态地指向正确版本的依赖项？

    2. 我如何/应该设置我的CM回购，以允许每个项目和模块的开发团队独立工作，而不必在每次创建新分支时进行大量手动配置？

我正在使用以下目录结构，但它似乎不足以满足我的需要。

./fooLibrary
    ./include
    ./lib 
./barLibrary
    ./include
    ./lib 
./plugins
    ./pluginX
        ./include
        ./lib 
    ./pluginY
        ./include
        ./lib 
    ./pluginZ
        ./include
        ./lib 
./projects
    ./customer1
        ./bin
        ./obj       
./projects/customer2
        ./bin
        ./obj       
./projects/unittests
        ./bin
        ./obj

我曾尝试为每个模块创建一个版本化的安装目录，其中包含它们自己的include/lib目录，但这似乎有些过头了，而且我从来都不喜欢版本化的构建产品。即

    ./fooLibrary
        ./src
        ./1.0
            ./include
            ./lib 
        ./1.1
            ./include
            ./lib 
        ./1.2
            ./include
            ./lib 
        ./1.2.1
            ./include
            ./lib

我只是想让开发团队保持简单

编辑：重要的是要注意，我还没有任何工作。我觉得我在努力做正确的事情，但我在努力把它做好的同时却在挣扎。

关于CM部分，如果您使用GIT，您可以为顶部目录和基本构建系统提供一个主存储库，并为每个子项目提供子模块。

至于构建，我建议您使每个子项目独立，然后按依赖关系顺序在顶级容器项目中列出子项目。每个子项目都安装到一个特定的目录中，顶级容器项目将标志传递给每个项目，告诉他们该安装目录的位置，这样他们就可以找到头文件和库。使此(临时(安装目录与实际安装目录镜像，以便在需要时轻松复制到实际安装目录。

如果不是所有文件都应该从临时安装目录复制到实际安装目录，请让每个子项目生成一个文件，该文件告诉应该复制哪些文件。

对于独立于平台的构建系统，我建议使用CMake。它可以处理用于构建的配置和生成makefile，用于比您可能需要的更多的平台和编译器。

我希望这些对你来说都有意义。

相关文章：