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

[Philip Lowman]

On Wed, Apr 30, 2008 at 1:00 PM, Brad King <brad.king at kitware.com> wrote:

> 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.


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.

-- 
Philip Lowman
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20080430/2e7da008/attachment.htm>