<div dir="ltr"><div>Yes but not all cmake projects which I build are mine. So i would still have to modify a CMakeLists from someone else, which is in my opinion a bad thing. <br></div>When you have the possiblity to inject cmake stuff without modifying the project itself you can implement a clean separation between project dependencies and how/where to find those.<br>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Nov 1, 2013 at 5:28 PM, John Drescher <span dir="ltr"><<a href="mailto:drescherjm@gmail.com" target="_blank">drescherjm@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">> +1 for updating cmake-gui to work equally to ccmake<br>
><br>
> But my opinion regarding CMAKE_MODULE_PATH is different. The problem is that<br>
> alot of the default find-modules don't work because the dependency is not in<br>
> the location where the find-module expects it. Currently there are only two<br>
> workarounds:<br>
> - Change the find-module directly so it works in the local environment<br>
> - Change the CMakeLists.txt of the project - which is bad because it's just<br>
> a LOCAL problem and the CMakeLists should be mostly independent of the<br>
> environment.<br>
><br>
> With the command-line option it's possible to setup a custom cmake-gui batch<br>
> file once per computer which sets e.g. the CMAKE_MODULE_PATH to a directory<br>
> with customized find modules. If one doesn't want to use custom find modules<br>
> that's fine too but I think everyone should have the option to place<br>
> dependent libraries wherever she/he wants.<br>
><br>
<br>
</div>For these kind of things I use environment variables in my<br>
CMakeLists.txt. If the environment variable is set I use it. If not I<br>
use the default behavior.<br>
<span class="HOEnZb"><font color="#888888"><br>
John<br>
</font></span></blockquote></div><br></div>