<div dir="ltr">On Tue, Jul 15, 2008 at 4:17 AM, Hauke Heibel &lt;<a href="mailto:heibel@cs.tum.edu">heibel@cs.tum.edu</a>&gt; wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi there,<br>
<br>
I&#39;ve stumbled over three little questions which I could not answer from the FAQs nor the CMake documentation or the Wiki. Maybe one of the specialists can help me out...<br>
<br>
The first question is whether it is possible to prevent environment variables from being expanded by CMake when it comes to setting include or link directories (INCLUDE_DIRECTORIES and LINK_DIRECTORIES).</blockquote><div>
<br>Not sure what you mean here.&nbsp; You might be able to do this (don&#39;t know, never tried), but I wouldn&#39;t recommend it:<br><br>INCLUDE_DIRECTORIES($ENV{FOO})<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

<br>
The second question is whether I can prevent the MSVC generator to append $(OutDir) to LINK_DIRECTORIES. For each call to LINK_DIRECTORIES I get two directories (e.g. LINK_DIRECTORIES(c:/foo/bar) creates c:/foo/bar/$(OutDir) and c:/foo/bar).</blockquote>
<div><br>I didn&#39;t even realize that it did that.&nbsp; I think that&#39;s probably meant as a convenience for MSVC developers who sometimes like to share the same filename across different release configurations (in different directories obviously). &nbsp; Not sure if it&#39;s disableable or not, is it causing you problems?<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
And the last question is, if it is possible to tell the FindQt.cmake script to give me the plain libraries without the full path of them being prepended (I am talking about the content of the QT_LIBRARIES variable). I would rather like to use LINK_DIRECTORIES and TARGET_LINK_LIBRARIES separately, i.e. I would prefer QtGuid4.lib over C:\Qt\lib\QtGuid4.lib.</blockquote>
<div><br>It should be possible to do this with STRING(REGEX REPLACE... ) if there is no better way.&nbsp; I&#39;m curious why you would need to do this though.&nbsp; The use of TARGET_LINK_LIBRARIES() with full paths is highly desired over LINK_LIBRARIES() and TARGET_LINK_LIBRARIES() with a relative library filename.&nbsp; It allows you to support use cases like this:<br>
<br>If you have two external packages that both provide &quot;sys.lib&quot; for example..<br>C:\foo\sys.lib<br>C:\bar\sys.lib<br>...there is no way to link them both in using LINK_DIRECTORIES() and TARGET_LINK_LIBRARIES().&nbsp; If you only want one trying to figure out which one you want is usually impossible if for other reasons you need other libraries from both C:\foo and C:\bar.&nbsp; If on the other hand you&#39;re using TARGET_LINK_LIBRARIES with full paths the linker should be able to figure everything out since most linkers support full paths to libraries.<br>
<br>Usually people just use the absolute paths determined by CMake Find modules or by manual calls to FIND_LIBRARY().&nbsp; There are several variables that you can modify prior to calling FIND_LIBRARY() or FIND_PACKAGE() that will usually allow you to override the default directory search paths.&nbsp; See CMAKE_PREFIX_PATH and CMAKE_LIBRARY_PATH.<br>
<br><a href="http://www.cmake.org/HTML/cmake-2.6.html#command:find_library">http://www.cmake.org/HTML/cmake-2.6.html#command:find_library</a><br><br></div></div>-- <br>Philip Lowman
</div>