Hi Guys,<div><br></div><div>I ran into a very similar issue, It seems that CMAKE_TOOLCHAIN_FILE does not trigger the whatever "mark as used" code in question, so even if it actually *does* use the variable, you still get a warning.</div>
<div><br></div><div>Example output:</div><div><div>Johan-Bjorks-MacBook-Pro-2:build-morpher phb$ cmake -G Xcode -DCMAKE_TOOLCHAIN_FILE=~/DEV/client/cmake/morpher-toolchain.cmake ../</div><div>......</div><div>-- Configuring done</div>
<div>-- Generating done</div><div>CMake Warning: The variable, 'CMAKE_TOOLCHAIN_FILE', specified manually, was not used during the generation.</div><div>-- Build files have been written to: /Users/phb/DEV/client/build-morpher</div>
</div><div><br></div><div>/Johan</div><div><br></div><div><div class="gmail_quote">On Wed, Feb 2, 2011 at 7:29 PM, Alexander Neundorf <span dir="ltr"><<a href="mailto:a.neundorf-work@gmx.net">a.neundorf-work@gmx.net</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">On Wednesday 02 February 2011, Eric Noulard wrote:<br>
> 2011/2/2 Emmanuel Blot <<a href="http://eblot.ml" target="_blank">eblot.ml</a>@<a href="http://gmail.com" target="_blank">gmail.com</a>>:<br>
> >> Currently, there is no way to turn this off.<br>
> ><br>
> > Very, very bad news ;-(<br>
> > IMHO, this is a recurrent issue with CMake. It seems there is no way<br>
> > to guarantee that a project that builds well with a version of CMake<br>
> > will build the same way with the next minor iteration (used to be<br>
> > called "patch release").<br>
><br>
> I think "recurrent" is a relatively tough statement, I'm using<br>
> CMake for 7+ years now and never get caught by such an issue.<br>
><br>
> I think that, CMake developpers are indeed very concerned with<br>
> backward compatibilty.<br>
<br>
</div>Yes. It is one of _the_ main concerns.<br>
If any change is made which is obvously backward incompatible (except for<br>
internal stuff), it is rejected.<br>
If there is a change with slight chances of breaking something somewhere in<br>
some cases, it is at least discussed at length, with the outcome, that either<br>
it is internal stuff, so people shouldn't rely on, or a policy is added, or<br>
it is rejected.<br>
It may happen that a change which breaks something is overlooked, but if you<br>
report it during the rc phase, this most probably will get fixed.<br>
(not sure this applies to the new warnings, since they are only warnings after<br>
all)<br>
<br>
I'm caring for KDE since, damn, almost 5 years now, and it's not bad.<br>
There are very few breakages, or IOW, current KDE requires cmake 2.6.4, and<br>
I'm not aware of any problems with newer versions of CMake.<br>
<br>
Alex<br>
<div><div></div><div class="h5">_______________________________________________<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></div>