On Wed, Apr 30, 2008 at 1:00 PM, Brad King <<a href="mailto:brad.king@kitware.com" target="_blank">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>Philip Lowman wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
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>
</blockquote>
<br></div>
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.</blockquote>
<div><br>You're right, my suggestion would complicate things. You have a point that users can work around this issue by just manipulating LIBRARY_OUTPUT_DIRECTORY on WIN32 to be different. Thanks for the quick response, I wasn't aware this was how it was designed when I originally posted.<br>
</div></div><br>-- <br>Philip Lowman