Fix version dependencies and versioning

[Matthias Vogelgesang]

pcilib links against an unversioned libufodecode. However, libufodecode changed its API which was reflected in the version number. This means pcilib will not always compile correctly.

In the same direction, libpcilib _must_ be versioned correctly. It was a PITA to find a working version for the HEB board _and_ the corresponding libufodecode.

[Suren A. Chilingaryan]

Can you explain in more details that do you need? The latest ABI version version of UFO decode library is still 0. I getting the libufodecode.so.0 after build. What do you want me to check?

I don't have any device-specific branches. The latest version should work fine with HEB. Normally, you need either to get the latest stable version from camera/pcitool or latest development version from csa/pcitool. If the upstream version is not working with HEB or any other device, please, fill the ticket. It is the bug either in electronics or software.

[Matthias Vogelgesang]

Replying to csa:

Can you explain in more details that do you need? The latest ABI version version of UFO decode library is still 0. I getting the libufodecode.so.0 after build. What do you want me to check?

The API version, e.g. using pkg-config. The HEB board was working only with an older revision of pcilib that - of course - was programmed against an older version of libufodecode. CMake could've warned and told me what version of libufodecode I need, if the call to pkg-config would have a version number.

I don't have any device-specific branches. The latest version should work fine with HEB.

It was not. For details, please ask Michele.

[Suren A. Chilingaryan]

I.e. you want me to always require a very specific version of ufodecode, like 0.2.2? But then I'll need to update pcitool also after all small changes which are not breaking API. Also, unless you increment major version of library interface, the pcitool may be easily broken by updating ufodecode after pcitool have been built.

1. I'd suggest to adjust the major version of library interface on API breakages.
2. I'll, then, check it in the pcitool build system.
3. Also, it will be the best if people would just need the latest versions of both pcitool and ufodecode. So if you notify me when you change the interface of ufodecode, I'll try to make correspondent changes in pcitool ASAP.
4. I'll clarify with Michele about HEB. In future, just let me know if the upstream version has problems.

[Matthias Vogelgesang]

Replying to csa:

I.e. you want me to always require a very specific version of ufodecode, like 0.2.2? But then I'll need to update pcitool also after all small changes which are not breaking API.

As long as it is not >= 1.0, every minor version increment breaks API, every patch increment does not. Hence, you can check >= 0.2 for example.

Also, unless you increment major version of library interface, the pcitool may be easily broken by updating ufodecode after pcitool have been built.

Well, the real problem here is that we do not do any meaningful packaging. And we always build from source. And as we can see it will always be a problem.

3. Also, it will be the best if people would just need the latest versions of both pcitool and ufodecode.

As said before, the problem was incompatibility with the hardware which required an older pcilib which required an older libufodecode. And the only solution was to use a driver that used to work with that firmware.

[Suren A. Chilingaryan]

OK. I'll add check as you wish. Still according to my knowledge any hardware should work with the latest version. If not I think it is better to feel a ticket when trying to find an old working version.