![]() It enables common warnings like use of uninitialized variables. Note that this is not equivalent to -Werror -pedantic, because why would it? ![]() pedantic-errors: This enables strict standard conformance, basically. Later compilation doesn’t touch that file again, so the warnings is not emitted again. Without that flag a warning is generated when compiling, but you might miss it. I like this one because it forces me to fix warnings.Īlso it makes it impossible to miss a warning. Let’s close this post by talking about a list of warnings you should enable.įor GCC/clang I usually have the following set of warnings: If you know anything, please let me know. So I don’t know any other solution besides duplicating the configuration of the my_library target for my_library_test as well, Tip: For header-only libraries enable warnings on the test target of the library.Īs the test target links to the header-only target, it will get the SYSTEM include so you won’t actually get any warnings!Īdding the include directory again but without SYSTEM doesn’t seem to work reliably, When including the header files in my source files, I want warnings.īut when including them from other source files, I don’t want them.Īdd_executable ( my_library_test … ) target_link_libraries ( my_library_test PUBLIC my_library ) target_compile_options ( my_library_test PRIVATE … ) So an external project linking my_library will not get any warnings from the header files of my library.īut the source files of my library will not get warnings either! The SYSTEM turns the include directory into a system include directory.Ĭompilers will not issue warnings from header files originating from there. The trick is to use target_include_directories(my_library SYSTEM PUBLIC include/). There is not much I can do besides pull-requests to fix those warnings or locally disabling them,īut as a library writer you can prevent the issue for projects with you as a dependency. ![]() So the header files have a couple of instances where the warning is issued, which is annoying. So with that you have warnings automatically enabled when compiling your library, and will hopefully fix all of them.īut what if you are used by another project that has more warnings?įor example, I compile with -Wconversion but my dependencies don’t. Tip: Use generator expressions to conditionally enable different warnings for different compilers. This code will enable -Wall for GCC and clang and /W4 for MSVC. Target_compile_options ( my_library PRIVATE $, $, $ >: -Wall> $ : /W4> ) The above warnings will work on GCC and clang, but not MSVC.īefore you start doing if(), take a look at generator expressions: This is a nice clean solution, the only issue is that the compiler flags are compiler dependent. Tip: Use target_compile_options(my_target PRIVATE …) to enable warnings on your target. On the contrast, targets linking to it will get the include directories and other libraries as they are PUBLIC. Targets linking to it will not get the warnings enabled. You can use that to specify warnings as well.Īnd as the warnings are specified as PRIVATE, they will only be used when compiling your library. With target_compile_options() you can also specify compiler flags for your target. When creating a library you specify include directories and link to other libraries. If -DCMAKE_CXX_FLAGS="…" is annoying, why not move it into the CMakeLists.txt?Īdd_library ( my_library … ) target_include_directories ( my_library PUBLIC include/ ) target_link_libraries ( my_library PUBLIC other_library ) target_compile_options ( my_library PRIVATE -Werror -Wall -Wextra ) Enabling Warnings by Modifying Target Properties So with my latest project, foonathan/lex, I looked for a better solution. This should also be reflected by the build files. I think this is problematic, because your code is designed with a certain warning level in mind. It decouples the warning options from your version control system and build files. You either have to remove -Werror or manually disable warnings on the external target somehow. This is problematic when you use add_subdirectory() to compile some external dependencies which do not compile without warnings. The warnings are used to compile everything with warnings enabled. There compilation failed due to warnings, which was annoying. I occasionally forgot to do that, implemented a feature, pushed it to CI. You have to remember to manually update CMAKE_CXX_FLAGS on CI and on every locale development machine. While this approach definitely works, it has a couple of problems: That way the compiler will always have the warning flags enabled. “A great technology choice that our community helped us make was moving to CMake, a cross-platform build tool, which makes it much simpler to maintain makefiles for many different platforms.Cmake -DCMAKE_CXX_FLAGS = "-Werror -Wall -Wextra …"
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |