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