Linking Issue While building different binaries

Question

Our codebase has thousands of lines and legacy code. Across time different developers have coded as per their suitability and standards. One of the wrongly implemented code is that a common header is included is declared and defined in different directories to be lined to different binaries with little difference. Ex:

dir1/xxx.h

class ABC{

public:

int init();
};

dir1/xxx.cpp

ABC::init()

Similarly

dir2 has its own copy.

The issue was that developers wanted to keep different versions - primary because they should know when the need to call source code under dir1 or dir2 which is independent of modifications to each.

Now its the hierarchy of how we are linking code in our binary is our issue. The header file in concern is conditionally compiled using same inclusive directive #ifndef .. #define .. #endif. The header files gets archived into lib1.a lib2.a and so on. Hence when we link our library and if incase we required it from lib3.a during linking we need to make sure that it linked the first:

ldd .. lib1.a lib2.a lib3.a -- so the exact header does not gets linked properly. Note that all .a have some additional interfaces compiled and linked.

Its unfortunate is that the required header contains common declaration (defines same methods but are little bit different)

How can we resolve the issue? Including Namespace would mean a lot of revamp in our codebase? Is there a better way to do that?

What would be best design for such a code base - so that later onwards no developer can accidentally include these fatal signatures?

Please help

Answer 1

There are several approaches to sharing code between developers:

1. Let everyone share the same code. Make a team responsible for the shared code, and if they make changes to the shared code, make sure that these changes (e.g. an extra argument to a method) are 'propagated' to all the applications using the shared code.

   Alternatively, you can make 'everybody' responsible for the shraed code, but even then, if the shared code is changed, the developer that did the the change should propagate this to all other applications.

   In this approach you can still choose to distribute the shared code as a LIB, or as a DLL.

2. Give everyone their own copy of the shared code. At the same time, make a 'central version' of the shared code, and make this 'central version' the 'trunk'. This means, whenever the shared code needs to be changed, it is this 'central version' that is changed. All the local copies of the shared code in the applications are not changed.

   Additionally, assign the task of 'Integration Manager" to a member of every application team. He/She will be responsible for bringing in new versions of the shared code, from the central version to the local copy. He/She will have to make changes in the application to make sure that the application still works with the new copy, and make sure the application is re-tested with the new shared code version.

Answer 2

If at all possible, you really need to rethink the basic practice, and undo it if you can. If this same basic header and class (or set of classes) is used in all the different library projects, even with minor variations, there ought to be some way to harmonize those variations into a proper class hierarchy such that a single library, with subclasses implementing slightly different variations as necessary, replaces multiple copies.