Re: [cmake-developers] CMake API for warnings
On 22-Apr-16 20:36, Brad King wrote: On 04/20/2016 09:50 AM, Ruslan Baratov wrote: 1) add_compile_warnings * similar to add_definitions, add_compile_options * modify COMPILE_WARNINGS directory property (append) 2) target_compile_warnings * similar to target_compile_options, target_compile_definitions * modify COMPILE_WARNINGS target property (append) 3) source_files_compile_warnings * similar to set_source_files_properties * modify COMPILE_WARNINGS sources property (append) Sounds good. Note that cmTarget has dedicated storage with backtrace information for other build system properties. Please use the same pattern for these. I also suggest getting the directory/target level working first and work on source files later. The infrastructure for the latter is not as mature so it may need more work. *_compile_warnings( DISABLE # add =off to COMPILE_WARNINGS property ENABLE # add =on to COMPILE_WARNINGS property TREAT_AS_ERROR # add =error to COMPILE_WARNINGS property ) Sounds good. * all (compiler specific "all", e.g. /Wall or -Wall) * default * level * none * everything (all possible warnings for compiler, if there is no such option use maximum level plus some warnings explicitly) Okay. Let's drop level for now for the reason you outlined. We can always add it later. Properties will be set in form =on|off|error, e.g.: add_compile_warnings(DISABLE undef unused ENABLE inline TREAT_AS_ERROR everything) will set COMPILE_WARNINGS directory property to: undef=off unused=off inline=on everything=error Good. In case of any conflicts return CMake warning for developer message (cmake -Wdev/cmake -Wno-dev). Good. Directory properties affect targets and sources, target properties affect sources of this target. E.g.: add_compile_warnings(DISABLE undef) target_compile_warnings(foo DISABLE unused) effectively equivalent to: target_compile_warnings(foo DISABLE undef unused) Question: do we need to control this? probably by 'target_compile_warnings(foo DISABLE unused IGNORE DIRECTORY)' ? It should be possible to merge the directory/target/source settings with proper precedence. I don't understand your example well enough to see what "IGNORE DIRECTORY" would mean. Either way, such information needs to be encoded somehow in the property values. It means ignoring directory properties. So by default we will inherit settings. Target will inherit directory properties: add_compile_warnings(DISABLE warn-A) target_compile_warnings(foo DISABLE warn-B) COMPILE_WARNINGS of target 'foo' property value: warn-A=off warn-B=off Sources: add_compile_warnings(ENABLE warn-A) target_compile_warnings(foo ENABLE warn-B) source_files_compile_warnings(foo.cpp ENABLE warn-C) COMPILE_WARNINGS of 'foo.cpp' property value: warn-A=on warn-B=on warn-C=on To disable inheriting we need to add extra argument (?) to *_compile_warnings: add_compile_warnings(DISABLE warn-A) target_compile_warnings(foo DISABLE warn-B IGNORE DIRECTORY) COMPILE_WARNINGS of target 'foo' property value (warn-A from directory properties ignored): warn-B=off Same with IGNORE TARGET: add_compile_warnings(ENABLE warn-A) target_compile_warnings(foo ENABLE warn-B) source_files_compile_warnings(foo.cpp ENABLE warn-C IGNORE TARGET) COMPILE_WARNINGS of 'foo.cpp' property value (warn-B from target ignored, directory not): warn-C=on warn-A=on Ignoring both: add_compile_warnings(ENABLE warn-A) target_compile_warnings(foo ENABLE warn-B) source_files_compile_warnings(foo.cpp ENABLE warn-C IGNORE TARGET DIRECTORY) Result: warn-C=on may expand to nothing in case warning make no sense for current language or warning not implemented by compiler: Okay. After this feature implemented we need to introduce new policy to avoid adding warnings flags to CMAKE_CXX_FLAGS by default (e.g. "/W3" added by default for Visual Studio). Yes. Warnings should not be propagated via INTERFACE because unlike definitions or other compiler flags they doesn't affect final binary or compatibility. Okay. On 29-Mar-16 22:42, Ruslan Baratov wrote: One more note. Properties is a good abstraction and works great for the native CMake project. But there is a tricky scenario about them - when we need to create ExternalProject_Add for the non-CMake project. Would be nice to have this one. This is beyond the scope of this change and affects all flags, so let's defer this for a later time. Is it possible in general to control warnings globally? Imagine I have target that should ignore all warnings for any reason. If you able to control warnings globally this target will generate tons of useless messages. How to enable warnings for all targets except this one? This thread has not yet designed any means for a user to control warnings globally (e.g. via a
[cmake-developers] [CMake 0016077]: FindProtobuf.cmake doesn't have required flexibility to configure protoc usage for all use cases
The following issue has been SUBMITTED.
==
https://cmake.org/Bug/view.php?id=16077
==
Reported By:skebanga
Assigned To:
==
Project:CMake
Issue ID: 16077
Category: Modules
Reproducibility:always
Severity: minor
Priority: normal
Status: new
==
Date Submitted: 2016-04-22 17:09 EDT
Last Modified: 2016-04-22 17:09 EDT
==
Summary:FindProtobuf.cmake doesn't have required flexibility
to configure protoc usage for all use cases
Description:
I have here a very simple test project which has 2 protobuf files, one of which
is included in the other.
Using cmake, I will create a static library for each generated protobuf message.
##Protobuf files:
**`src/foo/message.proto`:**
package test.foo;
message FooMsg
{
required string s = 1;
}
**`src/bar/message.proto`:**
package test.bar;
import "foo/message.proto";
message BarMsg
{
optional foo.FooMsg f = 1;
}
##CMake files:
I build `lib_foo` from generated `foo/message.proto` files.
**`src/foo/CMakeLists.txt`:**
protobuf_generate_cpp(PROTO_SRCS PROTO_HDRS message.proto)
add_library(lib_foo STATIC ${PROTO_SRCS})
I build `lib_bar` from the generated `bar/message.proto` files, and link in
`lib_foo`:
**`src/bar/CMakeLists.txt`:**
protobuf_generate_cpp(PROTO_SRCS PROTO_HDRS message.proto )
add_library(lib_bar STATIC ${PROTO_SRCS})
target_link_libraries(lib_bar lib_foo)
**`src/CMakeLists.txt`:**
cmake_minimum_required (VERSION 3.5)
project (cmake_proto_test CXX)
find_package(Protobuf REQUIRED)
# proto files import from the source root directory, so add the required -I
flag
set(PROTOBUF_IMPORT_DIRS ${CMAKE_SOURCE_DIR})
# genererated proto files go into the CMake binary output dir
include_directories("${CMAKE_BINARY_DIR}")
add_subdirectory(foo)
add_subdirectory(bar)
##Build error:
When I try to build this, I get the following error:
$ make .. VERBOSE=1
cd src/cmake_proto/build/bar && /usr/bin/c++
-I src/cmake_proto/build
-o CMakeFiles/lib_bar.dir/message.pb.cc.o
-c src/cmake_proto/build/bar/message.pb.cc
In file included from src/cmake_proto/build/bar/message.pb.cc:5:0:
src/cmake_proto/build/bar/message.pb.h:99:24:
error: ‘foo’ in namespace ‘test’ does not name a type
inline const ::test::foo::FooMsg& f() const;
^
##Reason:
The error is due to the header guard created by `protoc` being the same for the
2 generated files:
#ifndef PROTOBUF_message_2eproto__INCLUDED
#define PROTOBUF_message_2eproto__INCLUDED
...
#endif
The reason is that the header guard is derived from a combination of the output
directory and the generated file's path.
The current command issued by `FindProtobuf.cmake` results in the header guard
only using the filename:
cd src/cmake_proto/build/foo && /usr/local/bin/protoc --cpp_out
src/cmake_proto/build/foo -I src/cmake_proto/foo -I src/cmake_proto
src/cmake_proto/foo/message.proto
cd src/cmake_proto/build/bar && /usr/local/bin/protoc --cpp_out
src/cmake_proto/build/bar -I src/cmake_proto/bar -I src/cmake_proto
src/cmake_proto/bar/message.proto
This command, however, will result in the files being generated in the same
location, but with a different header guard:
cd src/cmake_proto/build && /usr/local/bin/protoc --cpp_out
src/cmake_proto/build -I src/cmake_proto src/cmake_proto/foo/message.proto
cd src/cmake_proto/build && /usr/local/bin/protoc --cpp_out
src/cmake_proto/build -I src/cmake_proto src/cmake_proto/bar/message.proto
Header guards:
PROTOBUF_foo_2fmessage_2eproto__INCLUDED
PROTOBUF_bar_2fmessage_2eproto__INCLUDED
There are three key differences here:
- The `WORKING_DIRECTORY` from which `protoc` is run from is
`${CMAKE_BINARY_DIR}`
- The `--cpp_out` directory passed to `protoc` is `${CMAKE_BINARY_DIR}`
- The `-I` include path passed to `protoc` does **not** include the folder where
the proto file is found
Being able to control these 3 items would give the flexibility required to use
this tool in the above setup.
==
Issue History
Date ModifiedUsername FieldChange
==
2016-04-22 17:09 skebanga New Issue
[cmake-developers] [CMake 0016076]: bin install directory configuration
The following issue has been SUBMITTED. == https://public.kitware.com/Bug/view.php?id=16076 == Reported By:blackstar Assigned To: == Project:CMake Issue ID: 16076 Category: CMakeSetup Reproducibility:always Severity: block Priority: normal Status: new == Date Submitted: 2016-04-22 10:39 EDT Last Modified: 2016-04-22 10:39 EDT == Summary:bin install directory configuration Description: It is impossible to set the CMake bin install directory with bootstrap options. The bin install directory is always /bin. If cmake binary is moved to other location, The CMAKE_ROOT could not be find, because the unique search directory of /Modules/CMake.cmake file is at the same level of bin directory. CMake Error: Could not find CMAKE_ROOT !!! CMake has most likely not been installed correctly. Modules directory not found in So it is impossible to have in the same install directory, several CMake binary of different OS. For example : cmake-3.5.2/bin/centos6.2/cmake cmake-3.5.2/bin/ubuntu14.04/cmake Is it possible to add an option in bootstrap, like --docdir, to set the binary install directory relative to ? Steps to Reproduce: do a cmake installation move the cmake binary run cmake == Issue History Date ModifiedUsername FieldChange == 2016-04-22 10:39 blackstar New Issue == -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Autogen subdirectories patches
On 04/21/2016 03:14 AM, Sebastian Holtermann wrote: >> Thanks! I've applied them locally and merged the cleanup/refactoring >> commits to 'next' for testing first. Once those test cleanly I'll move >> on to the rest. > > It is good too see the patches made it into the next branch. The rest of the changes are now in 'master'. Thanks for working on this! > Now there is another issue I have a partially fix for. > > As of now all included mocs and uis get generated in > CMAKE_CURRENT_BINARY_DIR/ > because they must be within INCLUDE_DIRECTORIES. > I think a more robust approach would be to generate them in > CMAKE_CURRENT_BINARY_DIR/TARGET_automoc.dir/ > and to add the _automoc.dir to INCLUDE_DIRECTORIES. > > I've attached a patch that does does so > - it is relative to current "next" branch. You should be able to rebase on 'master' now. > It is incomplete though because I didn't manage to get > CMAKE_CURRENT_BINARY_DIR/TARGET_automoc.dir/ > into INCLUDE_DIRECTORIES in Source/cmQtAutoGeneratorInitializer.cxx. > (GetAutogenTargetBuildDir() in Source/cmQtAutoGeneratorInitializer.cxx) > > If someone could do that or give me pointers on how to do it > then this could be another improvement. I'm afraid I'm not familiar enough with this infrastructure to know for sure. The entire Qt autogen infrastructure was built by others. Take a look at cmGlobalGenerator::Compute to see a carefully ordered set of operations. Among them is the QtAutoGenerator step. I'm not sure of its order relative to INCLUDE_DIRECTORIES evaluation. Thanks, -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] CMake API for warnings
On 04/20/2016 09:50 AM, Ruslan Baratov wrote: > 1) add_compile_warnings >* similar to add_definitions, add_compile_options >* modify COMPILE_WARNINGS directory property (append) > 2) target_compile_warnings >* similar to target_compile_options, target_compile_definitions >* modify COMPILE_WARNINGS target property (append) > 3) source_files_compile_warnings >* similar to set_source_files_properties >* modify COMPILE_WARNINGS sources property (append) Sounds good. Note that cmTarget has dedicated storage with backtrace information for other build system properties. Please use the same pattern for these. I also suggest getting the directory/target level working first and work on source files later. The infrastructure for the latter is not as mature so it may need more work. >*_compile_warnings( > >DISABLE # add =off to COMPILE_WARNINGS > property >ENABLE # add =on to COMPILE_WARNINGS > property >TREAT_AS_ERROR # add =error to > COMPILE_WARNINGS property >) Sounds good. >* all (compiler specific "all", e.g. /Wall or -Wall) >* default >* level >* none >* everything (all possible warnings for compiler, if there is no such > option use maximum level plus some warnings explicitly) Okay. Let's drop level for now for the reason you outlined. We can always add it later. > Properties will be set in form =on|off|error, e.g.: > >add_compile_warnings(DISABLE undef unused ENABLE inline TREAT_AS_ERROR > everything) > > will set COMPILE_WARNINGS directory property to: > >undef=off unused=off inline=on everything=error Good. > In case of any conflicts return CMake warning for developer message > (cmake -Wdev/cmake -Wno-dev). Good. >Directory properties affect targets and sources, target properties > affect sources of this target. E.g.: > > add_compile_warnings(DISABLE undef) > target_compile_warnings(foo DISABLE unused) > >effectively equivalent to: > > target_compile_warnings(foo DISABLE undef unused) > >Question: do we need to control this? probably by > 'target_compile_warnings(foo DISABLE unused IGNORE DIRECTORY)' ? It should be possible to merge the directory/target/source settings with proper precedence. I don't understand your example well enough to see what "IGNORE DIRECTORY" would mean. Either way, such information needs to be encoded somehow in the property values. > may expand to nothing in case warning make no sense for > current language or warning not implemented by compiler: Okay. > After this feature implemented we need to introduce new policy to avoid > adding warnings flags to CMAKE_CXX_FLAGS by default (e.g. "/W3" added by > default for Visual Studio). Yes. > Warnings should not be propagated via INTERFACE because unlike > definitions or other compiler flags they doesn't affect final binary or > compatibility. Okay. > On 29-Mar-16 22:42, Ruslan Baratov wrote: >> One more note. Properties is a good abstraction and works great for >> the native CMake project. But there is a tricky scenario about them - >> when we need to create ExternalProject_Add for the non-CMake project. > > Would be nice to have this one. This is beyond the scope of this change and affects all flags, so let's defer this for a later time. > Is it possible in general to control warnings globally? Imagine I have > target that should ignore all warnings for any reason. If you able to > control warnings globally this target will generate tons of useless > messages. How to enable warnings for all targets except this one? This thread has not yet designed any means for a user to control warnings globally (e.g. via a cache entry). Project code should be able to offer such options manually, but it would also be nice to have a CMake-defined setting. The semantics of such a setting will need to be defined carefully to allow the project to override (or not override) settings for specific targets. -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0016075]: Play jeopardy theme during compilation
The following issue has been SUBMITTED. == https://cmake.org/Bug/view.php?id=16075 == Reported By:Richard Wiedenhöft Assigned To: == Project:CMake Issue ID: 16075 Category: CMake Reproducibility:N/A Severity: feature Priority: normal Status: new == Date Submitted: 2016-04-22 03:53 EDT Last Modified: 2016-04-22 03:53 EDT == Summary:Play jeopardy theme during compilation Description: I'd like to request the addition of a command line flag that enables playback of the Jeopardy theme while a compilation is running. This should be trivially possible using mplayer (on Linux at least). Reasons: - It would be awesome == Issue History Date ModifiedUsername FieldChange == 2016-04-22 03:53 Richard WiedenhöftNew Issue == -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
