On Wed, Apr 30, 2008 at 9:27 AM, Brad King <<a href="mailto:brad.king@kitware.com">brad.king@kitware.com</a>> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">Philip Lowman wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
I noticed testing tonight with CMake 2.6.0 RC9 that MODULE_LIBRARY targets (i.e. DLL plugins under Windows) are NOT copied to the RUNTIME_OUTPUT_DIRECTORY. Is this a bug?<br>
<br>
I thought the impetus for the CMAKE_RUNTIME_OUTPUT_DIRECTORY feature was to get all DLLs dumped into a single directory so developers wouldn't have to concoct custom POST BUILD rules or modify PATH environment variables prior to runtime?<br>
</blockquote>
<br></div>
This was the reason, but the behavior is also not a bug. On Windows the LIBRARY_OUTPUT_DIRECTORY is not actually used for anything except MODULE libraries. The .lib part of a SHARED library goes to the ARCHIVE_OUTPUT_DIRECTORY and the .dll part goes to the RUNTIME_OUTPUT_DIRECTORY. In the case of a MODULE library there is no .lib part because nothing is supposed to link to it. Therefore to provide more granularity we decided to use LIBRARY_OUTPUT_DIRECTORY for modules.<br>
<br>
In many cases the .dll for a module is stand-alone and meant for loading only by an executable via LoadLibrary. In these cases it would go to a separate plugins directory or something like that. If you want the .dll for a MODULE library to go to the RUNTIME_OUTPUT_DIRECTORY, just set the LIBRARY_OUTPUT_DIRECTORY to point at the same place.</blockquote>
<div><br><br></div></div>The vast majority of the time users are going to want their plugins
dumped in RUNTIME_OUTPUT_DIRECTORY anyways so LoadLibrary() just works
properly. I can understand the desire to redirect these plugins to a
separate location in your build tree (i.e.a plugins directory) although
I would argue if this is the desired feature, another property name
should be used instead of complicating the meaning of
LIBRARY_OUTPUT_DIRECTORY. What about simply introducing a
MODULE_OUTPUT_DIRECTORY that functions identically both on Windows and
Linux and let the user decide. The net effect is the same that on
Windows you would want it to likely be in "bin" and in Linux likely in
"lib", but the flexibility would be there to use a separate directory
for plugins if it was desired:<br>
<br>What I'm talking about is something like this:<br><br>ARCHIVE_OUTPUT_DIRECTORY<br> static ".a" archives<br> import libraries for MSVC ".lib" or MinGW ".dll.a"<br><br>LIBRARY_OUTPUT_DIRECTORY<br>
shared ".so" libraries generated through ADD_LIBRARY(... SHARED)<br><br>RUNTIME_OUTPUT_DIRECTORY<br> shared ".dll" libraries generated through ADD_LIBRARY(... SHARED) on Windows (MSVC, MinGW)<br><br>
MODULE_OUTPUT_DIRECTORY<br> shared ".so" libraries generated through ADD_LIBRARY(... MODULE)<br> ".dll" dynamically linked runtime files generated through ADD_LIBRARY(... MODULE) on Windows(MSVC, MinGW)<br clear="all">
<br>-- <br>Philip Lowman