Are there any good dependency management tools that aren't language specific?

Question

I'm looking for dependency management tool that isn't specific to Java or any other language.

We use SystemVerilog, a hardware description language, to create stand-alone modules. We tag releases of those modules at various milestones. Higher level designs frequently pull in other modules using Subversion tags.

We attempted to use Subversion externals to automate things, so that when you check out a module you get its dependencies as well. But by the time you get to the system level, there are so many nested externals that it takes an hour to run svn update. Clearly that approach isn't working.

Basically, I want to be able to say, "My module depends on this version of module A, this version of module B, and this version of module C." The tool would do the work of checking out the dependencies, checking out the dependencies of the dependencies, and making sure that there are no conflicting dependencies (e.g. two versions of the same module).

Are there any tools out there that work well with an arbitrary language and Subversion?

Answer 1

Once I had a tool flow that looked for source files in two places. First, it looked in the local directory. Second, it looked in the "master" area which was shared, read-only directory with all the code checked out for everyone to use. If I needed to modify the code, I only checked out the module I needed. Then, the script would pick up that module from my local workspace. The rest of the code it read from the master area. This was all custom scripting, no off the shelf tools, but it wasn't too hard.

If you get this working, you might be able to go further and compile the master area code into shared, master libraries. This could really speed up compile time.

Answer 2

I'm not feeling the pain of dependency tracking that you are describing, which means I probably don't fully understand your problem.

One approach is to keep all versions of modules in separate files in the same library. For example, you can have adder_0_0.sv for the first version of a full adder HDL module, which would describe a module called adder_0. If you find a bug in the module, you can create a file called adder_0_1.sv also describing adder_0. You will be able to use adder_0_1.sv instead of adder_0_0.sv. If you want to change the interface, either by adding or removing ports, or changing the semantics of the ports, then you can create a file called adder_1_0.sv describing a module called adder_1. Note that adder_0 and adder_1 cannot be used interchangeably.

The philosophy behind this approach is that all of these files are write once. You just keep adding new files to your library. Any project that uses this library just checks out the whole library and uses whatever files they want. Dependency management is only as complicated as putting the right filenames in the right project description file for whatever simulation or synthesis tool you use. No special dependency management tool is required. The fewer separate libraries you have, the easier it will be to manage them.