为构建依赖使用绝对路径

本文关键字：路径 构建 依赖 | 更新日期: 2023-09-27 18:08:23

目前我们使用Source Safe并开始迁移到Subversion。所有外部SDK(> 500 MB)现在都保存在Source Safe中，我正在寻找将它们从VSS中移出的方法到某个存储库

我们有c++(大部分)，c#(很多)，Java(很少)项目。数百个项目。仅限Windows平台。

我有几个依赖管理器，但不满意:

  • NuGet -对。net很好，但对c++很痛苦
  • Ivy -不深入，但似乎不适合c++

第一个问题:我还可以检查什么?它应该易于最终开发人员使用。最佳情况-在IDE内简单构建。

目前我倾向于下一个解决方案:

分配一些很少使用的磁盘，如S:并声明为'DEV HOME'

然后在这里放置外部元素:

S:'SDK'boost'1.30'...
S:'SDK'boost'1.45'...
S:'SDK'oracle'agile_9.0.0.0'...
S:'SDK'IBM'lotus_8.0'...
S:'SDK'IBM'lotus_9.0'...
S:'Tools'NuGet'nuget.exe
S:'Tools'clr'gacutil.exe

Autobuild机器将保存这个'DEV HOME'的母版。每个开发人员都应该将必要的sdk从自动构建机器复制到本地，并使用subst创建磁盘。

我不觉得这个解决方案有什么大问题:

  • 分支。不同分支中的项目可以包含对不同版本SDK的引用(例如boost)
  • 外部组件的版本不会改变得太频繁，所以这里不会有数百个，比如说，boost版本。
  • 易于开发人员设置。
  • 任何工具支持的绝对路径。
  • 如果你想使用不太大的SSD驱动器作为源代码，没有磁盘空间问题。(目前我移动我的外部单独驱动器与符号链接的帮助。但对于其他开发人员来说，这看起来像是黑魔法)

小问题:

  • 就我个人而言，这不是一个美丽的解决方案。
  • 磁盘(S:)可以忙
  • 不能在Linux中使用(但目前我们对它不感兴趣)

第二个问题:在这个解决方案中哪些问题是可能的?

Update 1: Why not relative paths.

  1. 外部应该在一个目录与源根?:

: 

externals/...
branch-root-1.0/project_collection_1/project1/...
branch-root-2.0/project_collection_2/...

这里所有的项目应该在一个地方或重复的外部。似乎与绝对路径的解没有太大区别。

  1. 外部应该在同一文件夹与源根?:

: 

branch-root-1.0/externals/...
branch-root-1.0/project_collection_1/project1/...
branch-root-1.0/project_collection_2/...
branch-root-2.0/externals/...

那么外部将在每个签出的分支中重复。这为每个分支签出+500MB +一些额外的安装工作。

好吧，这看起来可以接受，但我不认为它比绝对路径更好。真的，我想知道相对路径的优点，因为我也不喜欢绝对路径

为构建依赖使用绝对路径

我已经沿着您的路径....这是可行的。然而，我建议你把所有的东西都设置成相对路径，并花时间把你的项目按相对路径排序。

任何固定目录系统和源代码控制的问题是你可以对你的项目进行分支或多次签出。

另外，虽然subversion很好，但值得考虑使用Mercurial或Git。它们允许许多不同类型的工作流，而subversion不允许。考虑如何构建存储库需要做更多的工作，但这是非常值得的。它与sourcesafe相比是一个很大的飞跃，根据我的经验，很多来自sourcesafe的人一开始真的很挣扎/不喜欢subversion/git/mercurial。它们都要求你更详细地了解版本控制，但这是一件好事，因为它是一个非常好的工具。

我认为，如果你的平台只有Windows和Visual Studio，那么NuGet是最好的。我喜欢Nuget的一点是几乎不需要配置。例如，您可以在将Boost Nuget包安装到项目后立即使用Boost库。

  • 你不需要配置include/library路径(你当前的问题)。
  • 一旦你复制(存储在SVN/mercurial中)包，它就会自动为你的项目在其他计算机上安装/配置/更新包。配置文件。
  • 可以解决/警告包之间的兼容性问题。

我不知道这个问题有什么好的跨平台解决方案

相关文章：