[CMake] Windows library target names

Olaf van der Spek olafvdspek at gmail.com
Thu Jul 22 17:42:45 EDT 2010


On Thu, Jul 22, 2010 at 11:36 PM, Michael Jackson
<mike.jackson at bluequartz.net> wrote:
>> How does the loader find the DLL?
>
> Because when Visual Studio launches an executable it will look in the same
> directory that the executable resides in for libraries to load. Now, if you
> have 2 completely separate projects where one builds libraries and the other
> builds the executables OR you have set the various CMAKE_RUNTIME_DIR,
> CMAKE_ARCHIVE_DIR and CMAKE_EXECUTABLE_DIR to different directories then you
> are going to have to setup your PATH accordingly for each solution/project.
> Most people set all three of those CMake variables to the same output
> directory.

Of course I have separate projects. I didn't write libz... Did you?
DLLs should be *shared*. There shouldn't be a need for me to copy them
to my app dir.

>> Why is this abuse?
>
> Because it circumvents CMakes generally accepted practice of a single type
> of configuration per build directory. I guess "abuse" is subject to each
> different person.

Of course you build in separate dirs. Doesn't mean you have to install
into separate dirs.

>> If I look in C:\Program Files (x86)\Microsoft Visual Studio
>> 10.0\VC\lib I see plenty of libs with a "d" suffix...
>
> Sorry, I got the idea of decorating the debug versions confused with naming
> of static and dynamic libraries. My Bad. You are correct. But that is one
> platform and CMake generally has to play down to the lowest common
> denominator.

I don't see why. There's plenty of platform-specific behaviour.

> On OS X the decoration seems to be _debug. Not sure what it is
> on Linux, solaris, AIX or some of the other Operating Systems that CMake
> supports.

That's exactly the reason it should be done by CMake!
Developers shouldn't have to worry about such platform specifics.

>>>  You _can_ very easily do this if you want. The code is out there in the

You mean copy/pasting is easy? It's also bad...
Code duplication!

Olaf


More information about the CMake mailing list