[CMake] Import libraries prefix bug under windows?

[Ronan Collobert]

ok thanks -- well, the variable works fine on all system i tried except 
windows. i have a workaround, just wanted to mention the problem.

even under windows, it recognizes it, as it creates "libfoo.dll" and 
"libfoo.lib". it is only when linking, that somebody forgot about these 
prefixes: it tries to find "foo.lib" instead of "libfoo.lib".

as all the other systems have a consistent behavior, i considered that 
as a bug, but, who knows, as you say.

ronan.

Brandon Van Every wrote:
> On Nov 7, 2007 2:09 PM, Ronan Collobert <collober at nec-labs.com> wrote:
>> Yes, indeed, it does work with SET_TARGET_PROPERTIES.
>>
>> CMAKE_SHARED_LIBRARY_PREFIX advantage is that it set up the prefix for
>> all libraries. So no need each time you have a library target to have
>> this SET_TARGET_PROPERTIES additional line.
>>
>> Like that, I do not remember where I saw doc about it. It is actually
>> referenced (without any comments) on the CMake Useful Variables page:
>> http://www.cmake.org/Wiki/CMake_Useful_Variables
>>
>> Also, if you look at the code of CMake in Modules/Platform/*.cmake it is
>> used in  a lot of scripts to initialize the default prefixes (including
>> Windows!).
> 
> Use as an initializer does not imply that it's an interface for the
> user to change the value.  There's a fair number of CMake "useful"
> variables that are actually pretty darned useless if you try to write
> to them.  The good news is that in CMake 2.6.0 all the public
> variables are going to be documented, so perhaps this "read only"
> confusion will go away.
> 
> 
> Cheers,
> Brandon Van Every
> _______________________________________________
> CMake mailing list
> CMake at cmake.org
> http://www.cmake.org/mailman/listinfo/cmake