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

Philip Lowman philip at yhbt.com
Wed Apr 30 12:48:39 EDT 2008


On Wed, Apr 30, 2008 at 9:27 AM, Brad King <brad.king at kitware.com> wrote:

> Philip Lowman wrote:
>
> > 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?
> >
> > 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?
> >
>
> 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.
>
> 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.



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)

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


More information about the CMake mailing list