我们的系统中有许多在Linux上运行的小项目（Slackware 7-11，正在缓慢迁移到RHEL 6.0）。大约50-100个应用程序和15-20个库。我们几乎所有的应用程序都使用一个或多个我们的库。我们的源代码树如下所示：
/app1 /app2 /app3 /include /foo/app4 /foo/app5 /foo/app6 /foo/lib1 /foo/lib2 /lib/lib3 /lib/lib4 /lib/include
现在，我已经完成了一些创建CMakeLists.txt文件的工作，并构建了大多数库和某些应用程序。我对使用cmake进行构建相当满意。我使用v2.6做到了这一点，最近（一个小时前）我升级到2.8。以上每个项目都有自己的特定于该项目的CMakeLists.txt文件，以进行构建和安装（尚无包装）。
我需要利用并强制执行持续集成。我安装了Jenkins并在其中玩耍，从我所看到的印象中，我印象非常深刻。我也在评估JIRA来进行问题跟踪。
只是为了使事情顺利进行，我已经在所有库上进行了cmake安装，以便应用程序可以在文件系统中找到它们。标头安装到/ usr / local / include，库安装到/ usr / local / lib。这是一件坏事吗？最好告诉cmake查找lib的源目录，使用导出接口或最近引入的ExternalProject_Add吗？
因为我将要使用Jenkins，所以不能保证cmake可以找到源目录或构建目录。当然，我可以告诉Jenkins按顺序构建项目（或至少首先构建依赖项）。如果对库的更新中断了另一个项目的构建，那么我想这将取决于有3/4智慧的人来确定。
先感谢您
只是为了使事情顺利进行，我已经在所有库上进行了cmake安装，以便应用程序可以在文件系统中找到它们。标头安装到/ usr / local / include，库安装到/ usr / local / lib。这是一件坏事吗？
不，这不是一件坏事，但是您的构建应该从头开始复制资源。如果需要在构建过程之外将其预先安装在系统中，则诸如可移植性和修复构建错误之类的问题将成为一个问题。如果您能够像您提到的那样以其他方式做到这一点，我会建议您这样做，但是如果它会使您的构建变得更长，那么您需要感觉一下。我的意识形态是，一切都应该转移到新的Jenkins机器上，只要戴上帽子就可以重新安装，这总是无法实现的，但是需要努力。
我在相互依赖的工作中要做的一件事是，成功建立一项工作会触发依赖于此的工作。因此，例如，如果A依赖于B，而A失败，则B将永远不会运行，并且在版本A中创建问题的人都应对此负责。这样可以防止由于破坏的依赖关系而导致的构建破坏的连锁影响。我建议您将文件保留在其作业文件夹中的特定版本中，并为依赖项指定所需文件的位置。再次使您的构建分离且干净。
我也在评估JIRA来进行问题跟踪。
我强烈推荐JIRA作为公司的问题跟踪系统；您可能需要查看此 Jenkins插件进行集成。如果您使用的是git，并且您不介意不在站点外托管代码，那么我也会在GitHub上发个镜头。
祝您好运，您似乎走对了。
