Using absolute paths for build dependencies

Question

Currently we use Source Safe and start migration to Subversion. All external SDK(> 500 MB) hold in Source Safe now, and I look for way to move them from VSS to some repository.

We have C++ (mostly), C# (many), Java (few) projects. Hundreds projects. Only Windows platform.

I a couple several dependency managers but not satisfied:

• NuGet - good for .Net but painful for C++
• Ivy - not look in depth, but seems not acceptable for C++

First question: what I can check else? It should be easy for using by end developer. Best case - simple build within IDE.

---

Currently I am inclined to next solution:

Allocate some rarely used drive, like S: and declare it as 'DEV HOME'.

Then place externals here:

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 machine will hold mastercopy of this 'DEV HOME'. Every developer should copy necessary SDKs from autobuild machine to local and create disk with subst.

I can't find big problems with this solution:

• Branches. Projects in different branches can contains references to different versions of SDK (boost for example)
• Version of external component will not change too frequently, so here will no hundreds of, say, boost versions.
• Easy for developers to setup.
• Absolute paths supported by any tool.
• No problems with disk space if you want use not-so-big SSD drive for sources. (Currently I move my externals to separate drive with help of symbolic links. But for other developers this look like black magic)

Minor problems:

• Personally for me it is not beautiful solution.
• Disk (S:) can be busy
• Can't be uses as is in Linux (but currently we not interested in it)

Second question: which troubles in this solution can be?

---

Update 1: Why not relative paths.

1. Is externals should be in one directory up with sources root? :

:

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

Here all projects should be in one place or duplicate externals. Seems not much different from solutions with absolute path.

1. Externals should be in same folder with sources root? :

:

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/...

Then externals will be duplicate in each checkouted branch. This +500MB for every branch checkout + some additional work for setup them.

Well, this look acceptable, but I do not see how it is beter then absolute paths. Really, I want to know advantages of relative paths, because I am also uncomforntable with absolute paths.

Answer 1

I think, if your platform is Windows only and Visual Studio then NuGet is the best one. What I like about Nuget is almost no configuration. For example, you can use Boost library immediately after you install Boost Nuget package to your project.

• You don't need to configure include/library paths (your current problem).
• It automatically installs/configures/updates packages for your project on other computers as soon as you copy (store in SVN/mercurial) the packages.config file.
• It can solve/warning about compatibility problems between packages.

I'm not aware about any good cross-platform solution for this problem.

Answer 2

I have gone down the path you have.... it can work. However I suggest you make everything relative paths and spend the time getting your projects sorted for relative paths.

The problem with any fixed directory system and source control is you can branch or have multiple check outs of your projects.

Also, while subversion is good, it is worth considering Mercurial or Git. They allow for a number of different kinds of work flows that subversion doesn't. It takes a bit more work thinking how to structure your repositories, but it's well worth it. It is a big jump from sourcesafe, and from my experience, many people coming from sourcesafe really struggle / dislike subversion / git / mercurial initially. They all require you to understand version control in a bit more detail, but thats a good thing, as it is a very good tool.