Why I need this feature is irrelevant, the important thing is that I need the feature. I know a couple of other people who&#39;ve posted on various other mailing lists that have asked for this as well.<br><br>However, if you must know, I need this mainly because of wxWidgets. wxWidgets has a setup.h file that is located in a directory specific to the configuration in which wxWidgets was built. For the respective configuration, I need to tell the compiler to use a different setup.h, which means I need to specify a different include directory per configuration. There&#39;s other ways to solve this problem other than using include directories, but this is the most trivial and simplified way.<br>
<br><div class="gmail_quote">On Tue, Dec 23, 2008 at 5:00 AM, cyril_wobow <span dir="ltr">&lt;<a href="mailto:cyril@wobow.com">cyril@wobow.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Philip Lowman a écrit :<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d">
On Mon, Dec 22, 2008 at 11:27 PM, Robert Dailey &lt;<a href="mailto:rcdailey@gmail.com" target="_blank">rcdailey@gmail.com</a> &lt;mailto:<a href="mailto:rcdailey@gmail.com" target="_blank">rcdailey@gmail.com</a>&gt;&gt; wrote:<br>

<br>
 &nbsp; &nbsp;On Mon, Dec 22, 2008 at 9:23 PM, Bill Hoffman<br></div><div><div></div><div class="Wj3C7c">
 &nbsp; &nbsp;&lt;<a href="mailto:bill.hoffman@kitware.com" target="_blank">bill.hoffman@kitware.com</a> &lt;mailto:<a href="mailto:bill.hoffman@kitware.com" target="_blank">bill.hoffman@kitware.com</a>&gt;&gt; wrote:<br>
<br>
<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Investigate CMAKE_CFG_INTDIR.<br>
<br>
<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;I believe for Visual Studio output, this will be<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;$(OutDir), right? If this is the case, this is a visual<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;studio environment variable that will have no meaning when<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;used in CMake scripts.<br>
<br>
<br>
 &nbsp; &nbsp; &nbsp; &nbsp;It is . when not in VS, and $(OutDir) when it is. &nbsp;So, you can<br>
 &nbsp; &nbsp; &nbsp; &nbsp;say /foo/bar/bin/${CMAKE_CFG_INTDIR}/runit.<br>
<br>
 &nbsp; &nbsp; &nbsp; &nbsp;It will be /foo/bar/bin/./runit with makefiles.<br>
 &nbsp; &nbsp; &nbsp; &nbsp;It will be /foo/bar/bin/$(OutDir)/runit with VS projects.<br>
<br>
<br>
 &nbsp; &nbsp;Keep in mind this is for include directories, which will not work<br>
 &nbsp; &nbsp;with visual studio environment variables. I need to statically<br>
 &nbsp; &nbsp;tell CMake which include directories go along with what<br>
 &nbsp; &nbsp;configuration. I don&#39;t believe this can be done at the moment, at<br>
 &nbsp; &nbsp;least with visual studio generation.<br>
<br>
<br>
Just curious, why would you ever want to have two different include directories, one for debug and one for release? &nbsp;It doesn&#39;t seem like a very good idea to me, but then again perhaps there is a good use case for this. &nbsp;How many header files are affected? &nbsp;I assume you are aware of and have rejected using the NDEBUG definition for your problem (via a 3rd wrapper file for every affected header file)<br>

<br>
-- <br>
Philip Lowman<br></div></div>
------------------------------------------------------------------------<div class="Ih2E3d"><br>
<br>
_______________________________________________<br>
CMake mailing list<br>
<a href="mailto:CMake@cmake.org" target="_blank">CMake@cmake.org</a><br>
<a href="http://www.cmake.org/mailman/listinfo/cmake" target="_blank">http://www.cmake.org/mailman/listinfo/cmake</a><br>
</div></blockquote>
<br>
Hi<br>
<br>
That sounds funny. Each time I see a question about &quot;how to do something configuration-specifically when generating for visual studio&quot; it ends up &quot;why on earth would you want to do that?&quot;. I guess it proves one more time that visual studio users expect every feature that cmake provides at configuration-time to also be provided at pre-build time. Thanks to a lot of cmake scripting, I have managed to get something like that to work but it is true that some features are still not utilizable configuration-specifically.<br>

(Last critical thing for me was how to tell cmake which CMAKE_BUILD_TYPE is &quot;debug&quot; and which is &quot;optimized&quot;, which is why I am bound to use cmake from cvs where Brad King introduced a DEBUG_CONFIGURATIONS global property).<br>

I am really interested ni cmake developers&#39; feelings about that.<br><font color="#888888">
<br>
Cyril<br>
</font></blockquote></div><br>