This will not be consistent with autotools on all platforms (I'd really like to know the reason libtool decides to have 100 different ways to compute this). But will work on normal Linux distributions, and it's quite open for extension.
I think we can roll with that for starters.

I think libtool works on more esoteric platforms than cmake does (or where our users will use it), so possibly this will not need the same amount of crazy logic.

Sure. Nevertheless, I have identified following common platforms (each group use different calculations):

• AIX, Linux, GNU/kFreeBSD, (modern) FreeBSD, Haiku, SunOS (version 5, 6)
• HP-UX, NetBSD, OpenBSD, SunOS (version < 5)
• SCO_SV, UnixWare, UNIX_SV, XENIX
• Windows
• Cygwin
• All Apple OSes

My old PR trying to solve this has been deemed too complicated.

I suppose that answers the question why libtool has so many different ways...

My old PR trying to solve this has been deemed too complicated.

This functionality is not possible to provide for all these platforms without a lot of complication. It is a complication I wish cmake itself provided for us, but since it doesn't I think we need to provide the logic if we ever want the cmake build to seriously become a serious autoconf alternative for curl builds.

each group use different calculations

I suppose this also means that my very simplified approach in this PR is then completely wrong for several of those groups?

Tested this with curl-for-win and it did not break the trick used to suppress soname with autotools builds (libcurl dll versioning is not generally desired for standalone/native libcurl Windows builds). It also didn't disturb CMake Windows builds. So, it seems fine from these ends.

Basically your changes will work correctly for the first group I mentioned.
On plain windows, AFAIR it's also OK because a) SONAME does not exist, b) there's no version number in the library name anyway (right?). Note that Cygwin is another story.

As for the others, the good question is if anybody really cares.

It is a complication I wish cmake itself provided for us

Well, CMake let's us set whatever SONAME/VERSION we want, it just does not deal with the autotools version scheme.

I could try to submit my changes again, and see if you all would want it the codebase. Otherwise, it's probably better if it works at least partially, then not at all. But I'm wondering if an option to either build without SONAME, or to override it would be a good idea in this case.

Well, CMake let's us set whatever SONAME/VERSION we want, it just does not deal with the autotools version scheme.

And therein lies the problem. The libtool version setup is made like to that to hide the platform complexities. It allows us to set one string and have that used automagically to set the correct number on numerous platforms. Without us having to know all those platforms. Without libtool since cmake doesn't help us here, we need to do that translation ourselves.

I could try to submit my changes again, and see if you all would want it the codebase. Otherwise, it's probably better if it works at least partially, then not at all. But I'm wondering if an option to either build without SONAME, or to override it would be a good idea in this case.

I think we should make an effort to do the right thing, yes! An option to switch it off or override is probably a good idea.

I'll see if I can put something together this week.

Unfortunately, life happens, and there's no way in hell I will be able to do anything till February.
If you want to temporary improve the situation on Linux you could merge this PR.
Sorry.

If you want to temporary improve the situation on Linux you could merge this PR.

It might be a small step forward anyway. But how will this affect non-Linux builds?

Not sure about Windows, but for other platforms the SONAME and/or file name may diverge from the one produced by the autotools.

According to curl-for-win tests, the Windows CMake build is not affected.

but for other platforms the SONAME and/or file name may diverge from the one produced by the autotools.

Does this mean that we cannot merge any fix for SONAME in cmake without trying to fix the entire world's set of platforms at once or should we merge the first take and let the ones you run into problems provide fixes?

I think we shouldn't introduce an incorrect change. Maybe just guard your changes with a condition like:

 if(CMAKE_SYSTEM_NAME STREQUAL "AIX" OR
    CMAKE_SYSTEM_NAME STREQUAL "Linux" OR
    CMAKE_SYSTEM_NAME STREQUAL "GNU/kFreeBSD" OR

    # FreeBSD comes with the a.out and elf flavours
    # but a.out was supported up to version 3.x and
    # elf from 3.x. I cannot imagine someone runnig
    # CMake on those ancient systems
    CMAKE_SYSTEM_NAME STREQUAL "FreeBSD" OR

    CMAKE_SYSTEM_NAME STREQUAL "Haiku")

?
It will still be an improvement, at the same time it won't screw it up for other platforms.

Thanks. Adapted to that, but also made the cmake version use the same numbers from the soname makefile with the necessary math.