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