CMake's message() directive has an AUTHOR_WARNING mode, however the documentation (v3.11.1) doesn't say anything on what the differences are between an AUTHOR_WARNING and a regular WARNING.
The documentation states these modes and their description as follows:
WARNING = CMake Warning, continue processing
AUTHOR_WARNING = CMake Warning (dev), continue processing
Author warning are meant to warn the author (developer) of a CMakeLists.txt, but not a user of it. With the CMake arguments -Wdev, -Wno-dev, and -Werror=dev you have control over how to these warnings are handled (documentation).
The idea is that users should not be scared or annoyed by warnings they cannot change anyway, because they are not supposed to modify this part (of potentially third-party) code. This includes programmers who include CMake code from others and don't want to warned about issues they cannot fix within their code.
Since CMake 3.5, the dev flags also suppress or enable deprecation warnings, following the spirit of warning only people who can fix the underlying issues.
Related
In my project I had to copy a library into my source to make some minor adjustments.
This library throws a couple of warnings when compiling. I don't like that ;-)
Since I don't want to change the library code any more than absolutely necessary, I do not want to put #Suppress lines into the library code.
Is there a possability to advise the compiler "Please ignore warnings, but only in src/foo/bar"? Maybe a compiler flag?
I am using a Gradle build, if that opens additional options.
foo.bar is a package and packages can not be suppressed.
Your options are:
Remove compiler warnings entirely
Create separate source set and compile task for the problematic code.
Fix the warnings.
In my project some code can be optional compiled in a different language (nasm & fortran), but it's also fine to compile the project without having these compiler installed. E.g. on Windows.
I would like to check if the the compiler are installed, before enabling the languages with enable_language
enable_language(ASM_NASM)
enable_language(Fortran)
If I use enable_language without an additional check, CMake stops with an error message.
(At the moment I check for if (MSVC) as workaround.)
Btw. I have a similar problem with the check for Qt. The check don't stop with an error, but generate a lot of noisy warnings.
So use check_language to check if a language can be enabled.
When specify linkerOpts, we need set absolute path for -L option, but it's easy to break.
In older version, setting linkerOpts in build.gradle could work, but in 1.3.50, it warns that "-linker-option(s)/-linkerOpts/-lopt option is not supported by cinterop. Please add linker options to .def file or binary compilation instead.", and build do fail with "Undefined symbols" error.
What could I do?
This option is going to be deprecated once, so the warning was intentionally added after the 1.3.50 release. The motivation here is that one should prefer to set all linker options, even platform-specific, via .def file.
But, the build should not break apart in this case. Can you add the script contents, to make it clearer - what exactly led to the error?
UPD: After the GH project was shared in the comments I want to add some details here. This problem is described in the documentation here, this part:
Often it's necessary to specify target-specific linker options for a binary which uses a native library. It can be done using the linkerOpts property of the binary.
So, in this particular case, it will be correct to add the option to the binaries section instead of the cinterops. In the end, I made things together with
binaries {
all {
linkerOpts = ['-L'+rootProject.projectDir+'/libs/NativeBase64/iOS/', '-lNativeBase64']
}
}
I just started using the Clion IDE. Maybe this is written somewhere but I haven't seen it in a Google search. If I put a message() call in my CMake script, where in Clion can I see the output? These message calls are the only way that I know how to debug my CMake scripts.
Use message(WARNING ...) instead of message(...). Warnings go to stderr.
Another possible workaround:
disable "cmake auto-reload" if it is enabled
after you changed something in your cmake file, don't trigger "Reload changes"
run/build your project
When clion starts a build, it realizes the cmake files are not up-to-date and reloads them, but like other build output it is displayed inside the Messages tab.
Warning and errors are displayed, but other messages are currently suppressed. However, there is a feature request concerning this issue.
As of CLion 2016.2.2,
Build #CL-162.1967.7, CLion is displaying CMake message(STATUS) output in its Messages tool window (Alt+0) during Build (Ctrl+F9) when a project is first built after changes to CMakeLists.txt. But as noted in the other answers, this output doesn't show in CLion's CMake tool window (as many would prefer).
Update: Above I wrote that CLion "is displaying message(STATUS) output." I now find that this occurs intermittently. #Michael wrote that this happens if you skip cmake reload after modifying your cmake file, but I've found CLion sometimes does not display any CMake output in its Messages tool window even under this condition. So far I haven't discovered the exact circumstances that make CLion show CMake message(STATUS) output, will report back here when/if I do.
Big Update: CLion opens 2016.3 EAP: user-defined literals, CMake output, C11 keywords completion and more. See in particular:CMake output window: a separate I think it fixes this whole problem: CLion 2016.3 EAP adds a new tab that contains CMake command output.
Of course, this is EAP, which comes with JetBrains' caveat:
It is important to distinguish EAP from traditional pre-release
software. Please note that the quality of EAP versions may at times be
way below even usual beta standards.
So use it at your own risk, but you may judge this a risk worth taking if you need the CMake debugging.
In my whole code I never use LINK_INTERFACE_LIBRARIES or something similar. All install, export and link_* command are used without.The only somewhat similar occurrence I was able to grep was in the build directory in the file lib/CMakeFiles/Export/lib/cmake/mylib-targets-noconfig.cmake:
IMPORTED_LINK_INTERFACE_LANGUAGES_NOCONFIG "CXX"
IMPORTED_LINK_INTERFACE_LIBRARIES_NOCONFIG
Still, I get a CMP0022 warning:
CMake Warning (dev) in lib/CMakeLists.txt: Policy CMP0022 is not set:
INTERFACE_LINK_LIBRARIES defines the link interface. Run "cmake
--help-policy CMP0022" for policy details. Use the cmake_policy command to set the policy and suppress this warning.
Target "mylib" has an INTERFACE_LINK_LIBRARIES property. This should
be preferred as the source of the link interface for this library but
because CMP0022 is not set CMake is ignoring the property and using
the link implementation as the link interface instead.
INTERFACE_LINK_LIBRARIES:
This happens when I link an external library to mylib. When I use CMake 2.8.12.1 which improved the handling of CMP0022 compared to 2.8.12 the number of warnings is massively reduced and I get only one warning per external library.
What causes the warning? From the documentation I don't get it.
What should I do to get rid of this warning? Is this compatible to older versions?
CMake 2.8.12.1 was released to address this issue. Please try that version.
In the meantime there was a similar question posted to the CMake mailing list. Stephen Kelly answered there are three options. [1, 2] The one I liked most uses LINK_PRIVATE and LINK_PUBLIC. But it is only backwards compatible to CMake 2.8.9.
Try putting this block:
IF(COMMAND CMAKE_POLICY)
CMAKE_POLICY(SET ???? OLD)
CMAKE_POLICY(SET ???? OLD)
ENDIF(COMMAND CMAKE_POLICY)
WHERE ???? is the name of the offending policy
I haven't read much about this yet, but I think is because they added a mechanism to set the target properties to avoid ambiguities when dealing with different targets, in any case, if a new version of CMake warns you about some policy you can set that policy to an old behavior.
https://cmake.org/cmake/help/v3.0/policy/CMP0022.html