Re: [cmake-developers] [PATCH] FindBoost: Add imported targets
On 18/11/2015 11:27, rle...@codelibre.net wrote: On 11/16/2015 09:26 AM, Florent Castelli wrote: But one there’s one thing that comes to mind. Some compiled libraries have dependencies on other compiled libraries. Don’t you think it would make sense to teach FindBoost about those so we link everything properly? And also maybe add the native dependencies for some modules that have one like maybe pthread or openssl. Though, this might be hard to get right in a cross platform way. Please look at adding these. The imported targets should come with all usage requirements as if they were provided by upstream Boost. It may be tricky to get right on all platforms but if we do not do it then application code will have to do it instead. I have made a first attempt at this. I suspect it will need some refinement, but hopefully useful as a starting point. Please see the attached patch. I'd certainly be very appreciative of any comments. [...] Did anyone have a chance to look at this yet? I'd very much like to get this to a state where it can be included. The performance is something I'd like to improve, and I hope someone might have a suggestion for speeding up the parsing overhead. Kind regards, Roger -- 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] Add command line options for deprecation message control
Hi Brad,
I've gone back and redone the patches with the suggestions you made,
hopefully they should be acceptable to apply now.
* The Help/release/dev/cmake-W-options.rst file is now modified as
part of the patches
* The method of enabling dev and deprecated warnings by default no
longer sets the CMake variables, instead it's handled by the new
GetSuppressDevWarnings and GetSuppressDeprecatedWarnings methods
* The change of enabling deprecated warnings by default is now in a
separate patch (0008)
I haven't included any patches for the cmake-gui as I want to get these
bits nailed down and in first.
Cheers,
Michael
>From 02016a44d1f6f571b96c54a0008c37e2e1fa3b7d Mon Sep 17 00:00:00 2001
From: Michael Scott
Date: Sun, 1 Nov 2015 16:05:15 +
Subject: [PATCH 1/8] Tests: Revise message in RunCMake.CommandLine -Wdev case
Use more prose-like capitalization.
---
Tests/RunCMake/CommandLine/Wdev-stderr.txt | 2 +-
Tests/RunCMake/CommandLine/Wdev.cmake | 2 +-
Tests/RunCMake/CommandLine/Wno-dev.cmake | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/Tests/RunCMake/CommandLine/Wdev-stderr.txt b/Tests/RunCMake/CommandLine/Wdev-stderr.txt
index 92c1d23..88cfb3a 100644
--- a/Tests/RunCMake/CommandLine/Wdev-stderr.txt
+++ b/Tests/RunCMake/CommandLine/Wdev-stderr.txt
@@ -1,5 +1,5 @@
^CMake Warning \(dev\) at Wdev.cmake:1 \(message\):
- Some Author Warning
+ Some author warning
Call Stack \(most recent call first\):
CMakeLists.txt:3 \(include\)
This warning is for project developers. Use -Wno-dev to suppress it.
diff --git a/Tests/RunCMake/CommandLine/Wdev.cmake b/Tests/RunCMake/CommandLine/Wdev.cmake
index e5026ef..756f31e 100644
--- a/Tests/RunCMake/CommandLine/Wdev.cmake
+++ b/Tests/RunCMake/CommandLine/Wdev.cmake
@@ -1,4 +1,4 @@
-message(AUTHOR_WARNING "Some Author Warning")
+message(AUTHOR_WARNING "Some author warning")
# with -Wdev this will also cause an AUTHOR_WARNING message, checks that
# messages issued outside of the message command, by other CMake commands, also
diff --git a/Tests/RunCMake/CommandLine/Wno-dev.cmake b/Tests/RunCMake/CommandLine/Wno-dev.cmake
index d81b858..802b435 100644
--- a/Tests/RunCMake/CommandLine/Wno-dev.cmake
+++ b/Tests/RunCMake/CommandLine/Wno-dev.cmake
@@ -1,4 +1,4 @@
-message(AUTHOR_WARNING "Some Author Warning")
+message(AUTHOR_WARNING "Some author warning")
# without -Wno-dev this will also cause an AUTHOR_WARNING message, checks that
# messages issued outside of the message command, by other CMake commands, also
--
2.5.0
>From 10801dab11c8e81ac351f725c37e30555f7febcf Mon Sep 17 00:00:00 2001
From: Michael Scott
Date: Sun, 8 Nov 2015 12:20:47 +
Subject: [PATCH 2/8] Make message suppression more consistent.
Make the message suppression more consistent, by adding a check
for the message related CMake variables in cmake::IssueMessage,
which allows callers of IssueMessage other than the message
command to behave as expected. Also added a check for
CMAKE_SUPPRESS_DEVELOPER_WARNINGS in the message command to
mirror the deprecated message type behaviour.
Added a 'force' flag to the cmake::IssueMessage method, to
make the message suppression consistent, when setting the
message related CMake variables directly in a CMake file.
Expand message command tests to cover the AUTHOR_WARNING message
type as well.
---
Source/cmMakefile.cxx | 8 +--
Source/cmMakefile.h | 3 +-
Source/cmMessageCommand.cxx | 12 -
Source/cmake.cxx | 70 ++-
Source/cmake.h| 12 -
Tests/RunCMake/message/nomessage.cmake| 4 ++
Tests/RunCMake/message/warnmessage-stderr.txt | 11 -
Tests/RunCMake/message/warnmessage.cmake | 6 ++-
8 files changed, 102 insertions(+), 24 deletions(-)
diff --git a/Source/cmMakefile.cxx b/Source/cmMakefile.cxx
index a1f143a..fd93a41 100644
--- a/Source/cmMakefile.cxx
+++ b/Source/cmMakefile.cxx
@@ -130,7 +130,8 @@ cmMakefile::~cmMakefile()
//
void cmMakefile::IssueMessage(cmake::MessageType t,
- std::string const& text) const
+ std::string const& text,
+ bool force) const
{
// Collect context information.
if(!this->ExecutionStatusStack.empty())
@@ -139,7 +140,8 @@ void cmMakefile::IssueMessage(cmake::MessageType t,
{
this->ExecutionStatusStack.back()->SetNestedError(true);
}
-this->GetCMakeInstance()->IssueMessage(t, text, this->GetBacktrace());
+this->GetCMakeInstance()->IssueMessage(t, text, this->GetBacktrace(),
+ force);
}
else
{
@@ -154,7 +156,7 @@ void cmMakefile::IssueMessage(cmake::MessageType t,
lfc.FilePath = converter.Convert(lfc.FilePath, cmOutputConverter::HO
Re: [cmake-developers] Obtaining header file dependencies of a source file manually
On Sun, Nov 29, 2015, 10:47 Dan Liew wrote: Hi, # TL;DR I need a way of determining the header file dependencies of a source file and inform CMake about them. CMake doesn't do this automatically because I'm using custom commands for the compilation step so CMake doesn't do it's usual magic of automatically inferring source file header dependencies. This is because this part of the compilation step requires a separate C++ compiler (completely independent from the one that CMake detects at configure time). Is there a way of doing this that will also regenerate the dependencies if the source file changes? # Long version A C++ project that I work on [1] is (amongst other things) a compiler. In order to compile applications it needs to link in a supporting runtime that is compiled to LLVM bitcode which is linked into the applications it compiles. The supporting runtime is written in C++ and compiled with Clang. The compilation of the runtime is currently achieved using ``add_custom_command()`` and so I am not using CMake's in built support for detecting header file dependencies. The reason for doing it this way is because the LLVM bitcode compiler (i.e. Clang) **is not** the same compiler as the host C++ compiler for the project. For example the host code might be built with MSVC but the supporting runtime is **always** built with Clang. To see this concretely take a look at [2]. The build works correctly if you build from a clean build directory. It does not work correctly if you perform a rebuild and change one of the header files that the supporting runtime depends on. This is because CMake doesn't know that the runtime source files depend on the header files and so doesn't rebuild the relevant source files. I can obviously tell CMake about these manually (adding more entries under ``DEPENDS`` in the ``add_custom_command()`` invocation) but this is very cumbersome. What I really need is a way to * Automatically infer the dependencies of a source file and tell CMake about them * Have the dependencies automatically regenerated if the source file changes (someone could add or remove a header file include). In a simple Makefile build system this typically achieved by doing something like this: ``` all:: $(SRCS:.cpp:.o) SRCS := foo.cpp bar.cpp # Include SRC file dependencies generated by the compiler if they exist -include $(SRCs:.cpp=.d) %.o : %.cpp $(CXX) -c $< -o $@ -MP -MMD -MF $*.d ``` Note the ``-M*`` flags get the compiler when it runs to generate additional makefile rules that will get included next time a build happens. I don't really know how to do the same thing with CMake. One idea is at configure time invoke Clang with the ``-MP -MMD -MF`` flags on each runtime source file, extract the dependencies then pass them to ``DEPENDS`` in ``add_custom_command()``. If I wanted the dependencies regenerated if the runtime source file changes then I would need to somehow get CMake to reconfigure every time this happens. I don't like this idea very much due to * Having to invoke Clang manually to determine the dependencies. CMake already knows how to determine source file dependencies, but this functionality (AFAIK) isn't exposed to me. * Reconfiguring every time one of the runtime source file changes is annoying (configuring can be slow sometimes). Does anyone have any other ideas? CMake obviously knows how to do all this stuff already for source files being compiled for the detected host C++ compiler, I just don't know how to get at this logic for source files that need to be built with a second independent C++ compiler. [1] https://github.com/halide/Halide [2] https://github.com/halide/Halide/blob/master/src/CMakeLists.txt#L140 Thanks, Dan. Hi Dan, Not going into detail as I'm typing on the phone, but this really sounds like a case where a "SuperBuild" ( http://www.kitware.com/media/html/BuildingExternalProjectsWithCMake2.8.html) can help you to simplify things a lot. Michael -- 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] Obtaining header file dependencies of a source file manually
Hi, # TL;DR I need a way of determining the header file dependencies of a source file and inform CMake about them. CMake doesn't do this automatically because I'm using custom commands for the compilation step so CMake doesn't do it's usual magic of automatically inferring source file header dependencies. This is because this part of the compilation step requires a separate C++ compiler (completely independent from the one that CMake detects at configure time). Is there a way of doing this that will also regenerate the dependencies if the source file changes? # Long version A C++ project that I work on [1] is (amongst other things) a compiler. In order to compile applications it needs to link in a supporting runtime that is compiled to LLVM bitcode which is linked into the applications it compiles. The supporting runtime is written in C++ and compiled with Clang. The compilation of the runtime is currently achieved using ``add_custom_command()`` and so I am not using CMake's in built support for detecting header file dependencies. The reason for doing it this way is because the LLVM bitcode compiler (i.e. Clang) **is not** the same compiler as the host C++ compiler for the project. For example the host code might be built with MSVC but the supporting runtime is **always** built with Clang. To see this concretely take a look at [2]. The build works correctly if you build from a clean build directory. It does not work correctly if you perform a rebuild and change one of the header files that the supporting runtime depends on. This is because CMake doesn't know that the runtime source files depend on the header files and so doesn't rebuild the relevant source files. I can obviously tell CMake about these manually (adding more entries under ``DEPENDS`` in the ``add_custom_command()`` invocation) but this is very cumbersome. What I really need is a way to * Automatically infer the dependencies of a source file and tell CMake about them * Have the dependencies automatically regenerated if the source file changes (someone could add or remove a header file include). In a simple Makefile build system this typically achieved by doing something like this: ``` all:: $(SRCS:.cpp:.o) SRCS := foo.cpp bar.cpp # Include SRC file dependencies generated by the compiler if they exist -include $(SRCs:.cpp=.d) %.o : %.cpp $(CXX) -c $< -o $@ -MP -MMD -MF $*.d ``` Note the ``-M*`` flags get the compiler when it runs to generate additional makefile rules that will get included next time a build happens. I don't really know how to do the same thing with CMake. One idea is at configure time invoke Clang with the ``-MP -MMD -MF`` flags on each runtime source file, extract the dependencies then pass them to ``DEPENDS`` in ``add_custom_command()``. If I wanted the dependencies regenerated if the runtime source file changes then I would need to somehow get CMake to reconfigure every time this happens. I don't like this idea very much due to * Having to invoke Clang manually to determine the dependencies. CMake already knows how to determine source file dependencies, but this functionality (AFAIK) isn't exposed to me. * Reconfiguring every time one of the runtime source file changes is annoying (configuring can be slow sometimes). Does anyone have any other ideas? CMake obviously knows how to do all this stuff already for source files being compiled for the detected host C++ compiler, I just don't know how to get at this logic for source files that need to be built with a second independent C++ compiler. [1] https://github.com/halide/Halide [2] https://github.com/halide/Halide/blob/master/src/CMakeLists.txt#L140 Thanks, Dan. -- 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
