[CMake] Invalid library output directory when VC++ solution is generated

[Glenn Coombs]

You could set the target property RUNTIME_OUTPUT_DIRECTORY on your library
targets.  That would override the CMAKE_RUNTIME_OUTPUT_DIRECTORY variable
just for those targets.

2011/7/27 Laura Autón García <laura.auton at gmail.com>

> Hello Alan,
> Thank you very much for your answer.
> It woks perfectly using deprecated options, which is kind of funny,
> isn't it? As Glenn pointed out in his reply afterwards, newer options
> (ARCHIVE_OUTPUT_DIRECTORY, LIBRARY_OUTPUT_DIRECTORY and
> RUNTIME_OUTPUT_DIRECTORY) work differently from deprecated ones, as in
> Windows, shared libraries are generated in the runtime directory
> instead of the library directory. And static libraries are even
> generated in the archive output directory instead of library
> directory:
>
> "Executables are always treated as runtime targets. --> Static
> libraries are always treated as archive targets <---. Module libraries
> are always treated as library targets. --> For non-DLL platforms
> shared libraries are treated as library targets <-- (that's why it
> works as expected in Linux). --> For DLL platforms the DLL part of a
> shared library is treated as a runtime target <-- and the
> corresponding import library is treated as an archive target. All
> Windows-based systems including Cygwin are DLL platforms."
>
> By the way, we build shared libraries after our project solution is
> generated. I mean, we first generate with CMake the solution to be
> opened in Visual C++ and then we compile the solution in Visual C++.
> At the point of compilation, the dll library is generated. So that,
> there is no conflict between when we determine where the dll is to be
> generated and when is generated.
>
> I am not really experienced with CMake tool, but it seems their
> developers had their reasons to determine that dll's have to be
> generated in the runtime directory rather than library one. That's not
> what we want though. We may accept the changes unless we figure out
> other way to do it.
>
> 2011/7/25 Alan W. Irwin <irwin at beluga.phys.uvic.ca>:
> > On 2011-07-25 12:19+0100 Laura Autón García wrote:
> >
> >> Hello all,
> >> In the project I am collaborating on, CMake is used in Windows in
> >> order to generate a Visual C++ solution to be compiled afterwards. In
> >> this process, everything seems to work fine as the external
> >> directories and libraries are well included and everything compiles
> >> and so. However, we are experiencing problems with the directory in
> >> which our dll library is to be created.
> >> We specify in CMake that the directory is ../lib but
> >> when checking the configuration in Visual C++ software, it seems to be
> >> ../bin/Release directory, so the library is generated there.
> >> The CMake sentences we wrote regarding this issue are as follows:
> >>
> >>  SET(LIB_DIR      "${PROJECT_SOURCE_DIR}/lib")
> >>  SET(CMAKE_LIBRARY_OUTPUT_DIRECTORY ${LIB_DIR} CACHE PATH "Directory
> >> for libraries")
> >
> > One possibility is you are setting CMAKE_LIBRARY_OUTPUT_DIRECTORY
> > after your dll's are built.
> >
> > Just in case that is not the source of the problem, here is
> > some further discussion.
> >
> > I cannot spot anything wrong with your command above.  However, our
> > project (PLplot) hasn't tried that recommended variable yet.  Instead
> > we use the deprecated LIBRARY_OUTPUT_PATH variable (mentioned in the
> > documentation) like the following (because we are a cross-platform
> > project):
> >
> > # in windows all created dlls are gathered in the dll directory
> > # if you add this directory to your PATH all shared libraries are
> > available
> > if(BUILD_SHARED_LIBS AND WIN32 AND NOT CYGWIN)
> >  set(LIBRARY_OUTPUT_PATH ${CMAKE_CURRENT_BINARY_DIR}/dll)
> > endif(BUILD_SHARED_LIBS AND WIN32 AND NOT CYGWIN)
> >
> > This works on Windows according to others, and I have also
> > personally verified that it works under Wine.
> >
> > Although a different variable is used, note the differences with
> > how that variable is set with your case.
> >
> > (1) The subdirectory is in the build tree rather than the source
> > tree.
> >
> > (2) We don't cache the variable.
> >
> > I don't think any of these differences should matter in terms of
> > whether the functionality works or not, but you might want to try them
> > with CMAKE_LIBRARY_OUTPUT_DIRECTORY just in case that might be the
> > source of your difficulty.  You could also set LIBRARY_OUTPUT_PATH
> > like we do as a test, but it would be better to figure out how to get
> > CMAKE_LIBRARY_OUTPUT_DIRECTORY to work correctly since our approach is
> > deprecated.  (It wasn't deprecated when we started using CMake years
> > ago, and we plan to switch over to the recommended method at some point.)
> >
> > Alan
> > __________________________
> > Alan W. Irwin
> >
> > Astronomical research affiliation with Department of Physics and
> Astronomy,
> > University of Victoria (astrowww.phys.uvic.ca).
> >
> > Programming affiliations with the FreeEOS equation-of-state
> implementation
> > for stellar interiors (freeeos.sf.net); PLplot scientific plotting
> software
> > package (plplot.org); the libLASi project (unifont.org/lasi); the Loads
> of
> > Linux Links project (loll.sf.net); and the Linux Brochure Project
> > (lbproject.sf.net).
> > __________________________
> >
> > Linux-powered Science
> > __________________________
> >
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Follow this link to subscribe/unsubscribe:
> http://www.cmake.org/mailman/listinfo/cmake
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20110727/7848cc72/attachment.htm>