[CMake] msvc linking problem k3b on windows

[Ralf Habacker]

Brad King schrieb:
> Ralf Habacker wrote:
>> For my opinion the problem here is caused by the fact that cmake uses 
>> the value of the OUPUT_NAME property for creating the import library 
>> name and not the target name which is expected.
>
to be more specific  - s/not the target/not only the target/g

- there are situations like this where a specific type of file created 
by a target need to have a different name - In this case the import 
library (= type ARCHIVE) can have the target name as basename while the 
dll/exe(= type RUNTIME) target should be changeable.

May be the following (new) properties

OUTPUT_RUNTIME_NAME
OUTPUT_ARCHIVE_NAME
OUTPUT_LIBRARY_NAME

which enforce the developer to change individual types of generated 
files would solve this problem in a generic way

For the given problem    

set_target_properties(k3b_bin PROPERTIES OUTPUT_RUNTIME_NAME k3b) 

would solve it completly.
>
> You can tweak the name of the import library by setting the IMPORT_PREFIX
> and/or IMPORT_SUFFIX properties on the target:
>
> set_target_properties(k3b_bin PROPERTIES IMPORT_SUFFIX _bin)
Using this property removes the extension - The doc says

Properties that affect the name of a target's output file are as
follows.  The PREFIX and SUFFIX properties override the default target
name prefix (such as "lib") and suffix (such as ".so").  IMPORT_PREFIX
and IMPORT_SUFFIX are the equivalent properties for the import library
corresponding to a DLL (for SHARED library targets). 

A workaround would be

if (MSVC)
    set_target_properties(k3b_bin PROPERTIES IMPORT_SUFFIX _bin.lib)
endif(MSVC)

if (MINGW OR CYGWIN)
    set_target_properties(k3b_bin PROPERTIES IMPORT_SUFFIX _bin.dll.a)
endif(MINGW OR CYGWIN)

which is not very comfortable - a generic solution is mentioned above.

Regards
 Ralf