[CMake] versioned dll support on windows (was msvc linking problem k3b on windows)

[Ralf Habacker]

Brad King schrieb:
> Ralf Habacker wrote:
>> Brad King schrieb:
>>> We do support the "image version" fields in dll binaries.  What do 
>>> you mean by "real" versioned DLLs?  Are you talking about 
>>> side-by-side stuff?
>> I mean integrating api versions in the runtime target filename to be 
>> able to have different versions of a library in the same dir like the 
>> unix version of set_target_properties property SOVERSION.
>
> I was not aware that windows people did this (except on cygwin).  
in the cmake space this is probably because of the egg and hen problem - 
until now there is no such cmake support on windows available, so noone 
can use this feature
> Can you cite any precedent?  
In my kde on windows installation amoung all others dll's I found the 
following dll's which looks like typical versioned dll's

libaspell-15.dll
libcharset-1.dll
libiconv-2.dll
libidn-11.dll
liblcms-1.dll
libpng12.dll
libpspell-15.dll

They come from initial the gnuwin32 project, which are using the 
autotools build chain.

QtCore4.dll
QtGui4.dll

Those files comes from a qt release
> Anyway, I doubt people will want it by default when SOVERSION is set 
for what else is SOVERSION be good ?
The only case i can see is if people on windows are using a unix based 
cmake buildsystem with SOVERSION - then they will have versioned dll 
starting with a further cmake release.. If they don't like that they can 
disable the related settings.

In the kde4 buildsystem there are two variables defining the soversion 
set(GENERIC_LIB_SOVERSION "4")
set(KDE_NON_GENERIC_LIB_SOVERSION "5")

they could easily be cleared on windows
if (WIN32)
set(GENERIC_LIB_SOVERSION "")
set(KDE_NON_GENERIC_LIB_SOVERSION "")
else (WIN32)
set(GENERIC_LIB_SOVERSION "4")
set(KDE_NON_GENERIC_LIB_SOVERSION "5")
endif(WIN32)

Also I remember there are policies - there could be a kind of 
compatibility flag. cmake could warn when SOVERSION are used - those 
warning could be disabled later

> (plus it's a change in behavior).
You mean
     "If only one of both is specified the missing is assumed to have "
     "the same version number. "

On windows SOVERSION isn't currently implemented, which mean it could be 
designed from scratch. When no SOVERSION is defined the related target 
is created without versioned filename

On compile side SOVERSION only affects runtime files (dll/exe) of a 
given target. The filename of the runtime file is stored by the linker 
in the related import library.
Any other target(s) using those import libraries will not recognize any 
difference. While linking the import library of the versioned dll will 
be added to the binary file and will have the versioned dll/executable 
name automatically included.

> Perhaps those who do can use the new OUTPUT_NAME features we're 
> discussing.
this is technical possible - unfortunally this would require massive 
changes of the the build system (I have in mind - kde4) Having SOVERSION 
on windows would give versioned dll support on windows out of the box.

Refering to the above listed gnuwin32 example i guess the version 
information would be added to the resulting dll/executable file name 
similar like the following line (I may be wrong with the exact variable 
names)

... 
${CMAKE_DEBUG_PREFIX}${CMAKE_SOVERSION_PREFIX}${SOVERSION_VALUE}${CMAKE_SHARED_LIBRARY_SUFFIX}

where CMAKE_SOVERSION_PREFIX is a new variable and set to '-' by default 
and SOVERSION_VALUE cointains the target related value of the SOVERSION 
property.

Hope I got everything related

Ralf