Some fixes for CMakeLists

[Vogtinator]

See commits for details.

I wonder whether the VERSION for shared library targets should just use ${PROJECT_VERSION} instead or be omitted altogether. Using libtool's current:age:revision calculation is a bit weird.

[debrouxl]

On the autotools side, I've been changing the LT_CURRENT value upon every release, as a way to increment the DLL/SO name, so as to hopefully help spot install / environment issues on Windows.

[debrouxl]

• the first commit LGTM, obviously;
• I don't yet understand why the second and third part of the version number are swapped by the second commit (and what I did wrong by requesting that one of the version numbers be swapped in #59 , or by not requesting that the three others be swapped), I guess I'll have to look at the libtool documentation.
• you both seem to be happy with the third commit, so I'll defer to you :)

[Vogtinator]

There are targets already, use them directly.

Right, I think I initially wanted to make it possible to use the built libs for testing instead of the installed ones. But maybe this way already makes it work like that...? I'm not sure why I ended up doing it that way if what you propose works, since my version is clearly ugly.

Yes, this links against the built libraries. If they had target_include_directories(PUBLIC) or INTERFACE set, those would be used as well.

I don't yet understand why the second and third part of the version number are swapped by the second commit (and what I did wrong by requesting that one of the version numbers be swapped in https://github.com/debrouxl/tilibs/pull/59 , or by not requesting that the three others be swapped), I guess I'll have to look at the libtool documentation.

The libtools and cmake library version systems are completely different, this results in identical names (at least on Linux).

The libtool documentation is not that helpful, and just doesn't explain any OS dependent parts: https://autotools.info/libtool/version.html

[debrouxl]

Thanks :)