3

There is a stable and rarely modified c++ & cmake & gcc/msvs project which statically uses, say, version 1.0 of our libfoo library for object recognition. Our customer now wants some new functionality (a detector of a new type of specific objects) which demands to use libfoo version 2.0.

Upgrading libfoo from version 1.0 to 2.0 in the whole project is not an option for a few reasons, the primary being that it will change recognition behaviour in an undesired way (so subsequent painstaking tweaking would be necessary to come back to the previous quality levels and we are not paid for this work).

I see the following bruteforce solution:

  1. Wrap all version 2.0 source files with namespace foo20 {...}
  2. Rename version 2.0 cmake target names from foo to foo-2.0.
  3. From the main program link to foo-2.0 to implement the new functionality.

Apart from 'niceness', this solution is cumbersome for in fact libfoo depends on a bunch of other our internal libraries and the procedure above should be repeated for each of them.

Does anyone know a better solution for the whole problem or at least for one of the steps?

tim
  • 81
  • 1
  • 6
  • 1
    Tell the customer it's paid work and then migrate to libfoo2.0 for the whole project ;) – UKMonkey Apr 16 '18 at 12:53
  • @UKMonkey, tweaking recognition quality would be times more expensive than injecting `libfoo-2.0`, we definitely cannot go this way. I just wanna know a nicer way to inject. – tim Apr 16 '18 at 12:57
  • 2
    My application has multiple versions of multiple libraries in one project. I highly recommend avoiding this kind of situation. Regardless of the lifetime guaranteed job security. – Eljay Apr 16 '18 at 12:58
  • 1
    How about merge the required features from 2.0 into 1.0? You really really don't want 2 versions of the same library like this. – UKMonkey Apr 16 '18 at 13:01
  • Guys, I understand that in general case we should have simply migrated from 1.0 to 2.0, it's common good practice, but in recognition software there are specific problems which we try to avoid. – tim Apr 16 '18 at 13:03
  • I would say it also depends on : 1/ is libfoo a static or dynamically library ? 2/ Do you have a branch for this particular client on your versionning system 3/ Do you expect/ do you have so,e sort or requirements of API /ABI compatibility between libfoo2.0 and libfoo1.0 ? – sandwood Apr 23 '18 at 12:34
  • 1. Static. 2. This is the only client for this particular system. 3. API is mostly compatible between 1.0 and 2.0. – tim Apr 24 '18 at 14:02

0 Answers0