Ilker Murat Karakas Ilker Murat Karakas - 7 months ago 47
C Question

Supporting more than one codebase in ANSI-C

I am working on a project, with an associated Ansi-C code base. (let me call this the 'main' codebase).

I now am confronted with a typical problem (stated below), which I believe I would be able to solve much easily if I had an object-oriented language at hand.

The problem is this:
I will have to start more than one codebases; i.e. I will have to start supporting a parallel codebase (even maybe more in the future). The initial codebases for all the new (i.e. parallel) codebases will initially be identical as the old (i.e. 'main') codebase.

As we are talking about the 'C' language, I have till now been thinking of adding '#ifdef' statements to code, and writing the branch-spacific code inside those 'ifdef' blocks.

Hoping that I made the problem clear (enough!), I would like to hear thoughts on clever patterns that would help me handle this problem elegantly in Ansi C.



What is going to change between the different code bases?

  • If it is just different platforms, you carefully isolate the platform dependencies, keeping as much of the core code the same across all platforms as possible, and putting platform-specific stuff into separate files.

  • If you are going to be changing the program functionality radically, you need to work out how to keep a common core of unchanged code while allowing for the differences between the programs.

Notice that in both cases, it is first and foremost a question of understanding what is going to change, and setting up the code so that as little as possible changes. Often, the best way to handle the variations (there are inevitably going to be variations; otherwise, there's no point in having two or more versions) is to put the different variations in separate files, and compile and link the correct files. Sometimes, though, it is deemed better to put the variations (or one part of the variations) in a single file and use #ifdef style conditional compilation.

The other key point is to keep everything under the same version control system - for as long as possible, or a decade or two longer than that.

The biggest disaster I've seen occurred when the different versions stopped using a common code base. Now we need to reintegrate the two code bases, the decade of separate development is a major obstacle. The previous fifteen years of integrated development had its ups and downs - but nothing compared to the problem we now face. Ugh!