[CMake] MODULE_LIBRARY targets not copied to RUNTIME_OUTPUT_DIRECTORY (on 2.6.0 RC9)

[Brad King]

Philip Lowman wrote:
> 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:
> 
> What I'm talking about is something like this:
> 
> ARCHIVE_OUTPUT_DIRECTORY
>    static ".a" archives
>    import libraries for MSVC ".lib" or MinGW ".dll.a"
> 
> LIBRARY_OUTPUT_DIRECTORY
>    shared ".so" libraries generated through ADD_LIBRARY(... SHARED)
> 
> RUNTIME_OUTPUT_DIRECTORY
>   shared ".dll" libraries generated through ADD_LIBRARY(... SHARED) on 
> Windows (MSVC, MinGW)
> 
> MODULE_OUTPUT_DIRECTORY
>   shared ".so" libraries generated through ADD_LIBRARY(... MODULE)
>   ".dll" dynamically linked runtime files generated through 
> ADD_LIBRARY(... MODULE) on Windows(MSVC, MinGW)

I think this is even more complicated.  It leaves the LIBRARY variable 
unused on windows and the MODULE variable would still have to be set 
differently on different platforms.  The current design is powerful 
enough to do what you need.  The output directories used in the build 
tree are not that important.  It's the install() command that matters, 
and that has been using this dichotomy for years.

-Brad