[CMake] Passing CMAKE_TOOLCHAIN_FILE on command line causes CMake warning

[Pat Marion]

Thanks for the discussion guys!  And thanks Marcus for the CMAKE_CACHE_ARGS
tip.  I'll try that out.


In fact, the current design could be problematic because if you *do*
specify a different toolchain file, cmake will ignore it instead of sending
you a warning like it does if you change the CMAKE_CXX_COMPILER.  Would it
be straightforward to compare the passed in value of CMAKE_TOOLCHAIN_FILE
against the cached version?  That would prevent the "noisy" warning
message, and afford the opportunity to send a legitimate warning or error
if it does not match.

Pat

On Wed, Feb 6, 2013 at 11:56 PM, David Cole <dlrdave at aol.com> wrote:

> -----Original Message-----
>  From: Pat Marion <pat.marion at kitware.com>
> To: David Cole <dlrdave at aol.com>
> Cc: themiwi <themiwi at gmail.com>; cmake <cmake at cmake.org>
> Sent: Wed, Feb 6, 2013 8:34 am
> Subject: Re: [CMake] Passing CMAKE_TOOLCHAIN_FILE on command line causes
> CMake warning
>
>  I'd like you to try pasting the following text into a google search, so
> you can appreciate how widespread the warning is, 257 results from lots of
> different projects:
>
>
> CMake Warning:   Manually-specified variables were not used by the
> project:      CMAKE_TOOLCHAIN_FILE
>
>
> Most of these projects are not going to incorporate workarounds.  The
> warning is confusing to lots of users, and they're already unsure of the
> while crosscompiling thing, so seeing a warning adds uncertainty that
> they're doing it right.  Adding a workaround into the target project is not
> always possible since you might not have commit access or are compiling a
> previously released, stable version.
>
> Pat
>
>
>
>  On Wed, Feb 6, 2013 at 10:51 PM, David Cole <dlrdave at aol.com> wrote:
>
>> If you don't want to see the warning, then also pass in
>> --no-warn-unused-cli on the command line.
>>
>>   --no-warn-unused-cli        = Don't warn about command line options.
>>
>> But that suppresses the warning for all unreferenced variables.
>>
>> Or... add:
>>
>>   message(STATUS "CMAKE_TOOLCHAIN_FILE='${CMAKE_TOOLCHAIN_FILE}'")
>>
>> to the project's CMakeLists.txt file so the variable is always
>> referenced.
>>
>> The point is: CMAKE_TOOLCHAIN_FILE is only read on the first configure.
>> After that point, all toolchain stuff is cached and the file is unnecessary
>> for subsequent configures.
>>
>> That bug should just be closed as "won't fix" because it's not a bug.
>> It's the intended behavior, and there are multiple ways to avoid the
>> legitimate warning.
>>
>>
>> Just my opinion,
>> D
>>
>>
>>
>>   -----Original Message-----
>> From: Pat Marion <pat.marion at kitware.com>
>> To: Michael Wild <themiwi at gmail.com>
>> Cc: cmake <cmake at cmake.org>
>> Sent: Wed, Feb 6, 2013 7:23 am
>> Subject: Re: [CMake] Passing CMAKE_TOOLCHAIN_FILE on command line causes
>> CMake warning
>>
>>  That's a pretty messy workaround though, I think.  ExternalProject_Add
>> passes in lots of variables, including ones that do not typically change,
>> like CMAKE_CXX_COMPILER.  Why impose a special requirement on the
>> CMAKE_TOOLCHAIN_FILE variable?  Would a patch to avoid the warning be a
>> welcome change, or is there a reason the warning should remain?
>>
>> Pat
>>
>> On Wed, Feb 6, 2013 at 9:52 PM, Michael Wild <themiwi at gmail.com> wrote:
>>
>>> Hi
>>>
>>>
>>>  On Wed, Feb 6, 2013 at 11:59 AM, Pat Marion <pat.marion at kitware.com>wrote:
>>>
>>>> Hi,
>>>>
>>>> I'm emailing about bug 13093<http://public.kitware.com/Bug/view.php?id=13093>in the backlog.  I found comments
>>>> by Brad<http://www.cmake.org/pipermail/cmake/2011-February/042556.html>that suggest it's a legitimate warning, but I'm not sure how a project
>>>> could avoid the warning.
>>>
>>>
>>> By not specifying the toolchain file, for instance? If you have the
>>> problem in conjunction with ExternalProject_Add, check whether the
>>> CMakeCache.txt file exists in the build tree of the external project. If
>>> not, include the flag, otherwise drop it.
>>>
>>> My 2c
>>>
>>> Michael
>>>
>>
>>   --
>>
>> Powered by www.kitware.com
>>
>> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>>
>> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ
>>
>> Follow this link to subscribe/unsubscribe:http://www.cmake.org/mailman/listinfo/cmake
>>
>>
>
> I appreciate the widespread nature of "the problem." Really, I do. (If
> you do the same search, but without CMAKE_TOOLCHAIN_FILE, you get 20,000+
> results.)
>
> The intent of the warning feature is to point out that you may have misspelled
> a variable name, since usually, variables specified on the command line
> *are* in fact, referenced during the configure or generate steps.
>
> Unfortunately, the text of the warning does not say "you may have
> misspelled this, double-check your spelling". Nor does it say the more
> clear "this variable was not referenced at all by any of the CMakeLists
> code used during configuration or generation". It could even say
> "reference the variable, or use --no-warn-unused-cli to eliminate this
> warning" -- but it doesn't.
>
> The other positive effect here is that it may point out that you're not
> using all the variables that you think you're using. Therefore, you may be
> able to simplify your command line, or your CMakeLists files.
>
>
> I'm not a big fan of special-casing variable names for code like this.
> But if CMAKE_TOOLCHAIN_FILE is really "special", then maybe that's the
> right call here. You could certainly check if it's the same as the cached
> value, and only warn if it's different. If you do add such a warning, use
> text something like "start with a completely clean build tree if you are
> changing toolchain files" when a difference is detected.
>
>
> Cheers,
> D
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20130207/1cb5a2e2/attachment-0001.htm>