Re: [cmake-developers] Introducing: message(DEBUG)
On 3/3/2012 5:25 AM, Rolf Eike Beer wrote:
+ else if (*i == DEBUG)
+{
...
+status = true;
Rather than being a conditional version of STATUS I think full stack
information is useful for debugging. Add to the cmake::MessageType
enumeration a DEBUG value and teach cmake::IssueMessage to handle it.
The output should look like an error or warning but with CMake Debug
as the header instead of CMake Error or CMake Warning.
Once the decision to display the message has a cmListFileBacktrace
instance available for the context then you can have fancier rules
for deciding what messages to display.
-Brad
--
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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Introducing: message(DEBUG)
On 3/3/2012 5:25 AM, Rolf Eike Beer wrote:
+ else if (*i == DEBUG)
+{
...
+status = true;
Rather than being a conditional version of STATUS I think full stack
information is useful for debugging. Add to the cmake::MessageType
enumeration a DEBUG value and teach cmake::IssueMessage to handle it.
The output should look like an error or warning but with CMake Debug
as the header instead of CMake Error or CMake Warning.
I would like to have that switchable in some way. E.g. for Boost_DEBUG I
don't have stack traces at the moment, but the contents are the
information I need. Stacktraces are useful, but not always.
Once the decision to display the message has a cmListFileBacktrace
instance available for the context then you can have fancier rules
for deciding what messages to display.
I don't think I fully understand what you are trying to say here.
Eike
--
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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Introducing: message(DEBUG)
On 3/5/2012 10:22 AM, Rolf Eike Beer wrote: Rather than being a conditional version of STATUS I think full stack information is useful for debugging. Add to the cmake::MessageType enumeration a DEBUG value and teach cmake::IssueMessage to handle it. The output should look like an error or warning but with CMake Debug as the header instead of CMake Error or CMake Warning. I would like to have that switchable in some way. E.g. for Boost_DEBUG I don't have stack traces at the moment, but the contents are the information I need. Stacktraces are useful, but not always. I'm not opposed to a switch but extra verbosity rarely hurts debug output IMO. Even a switch at the call site may be the wrong place because it is up to the viewer of the message whether the full context is important. Perhaps the switch can be based on something similar to the context filters (see below). Once the decision to display the message has a cmListFileBacktrace instance available for the context then you can have fancier rules for deciding what messages to display. I don't think I fully understand what you are trying to say here. Elsewhere in this thread discussion proposed filters on messages based on their context. Filters based on the full backtrace should be possible and would give a lot of control. -Brad -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Introducing: message(DEBUG)
2012/3/5 Rolf Eike Beer e...@sf-mail.de:
On 3/3/2012 5:25 AM, Rolf Eike Beer wrote:
+ else if (*i == DEBUG)
+ {
...
+ status = true;
Rather than being a conditional version of STATUS I think full stack
information is useful for debugging. Add to the cmake::MessageType
enumeration a DEBUG value and teach cmake::IssueMessage to handle it.
The output should look like an error or warning but with CMake Debug
as the header instead of CMake Error or CMake Warning.
I would like to have that switchable in some way. E.g. for Boost_DEBUG I
don't have stack traces at the moment, but the contents are the
information I need. Stacktraces are useful, but not always.
Then may be you can have a bunch of control var for that:
CMAKE_DEBUG_MESSAGES_STACKTRACE ON/OFF
CMAKE_DEBUG_MESSAGES_FILEPREFIX ON/OFF
CMAKE_DEBUG_MESSAGES_USERPREFIX stringvalue
then you display some prefix depending on ON/OFF value and if
USERPREFIX is set.
Once the decision to display the message has a cmListFileBacktrace
instance available for the context then you can have fancier rules
for deciding what messages to display.
I don't think I fully understand what you are trying to say here.
May be something like my previous proposal?
--
Erk
Le gouvernement représentatif n'est pas la démocratie --
http://www.le-message.org
--
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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Introducing: message(DEBUG)
2012/3/5 Brad King brad.k...@kitware.com: On 3/5/2012 10:22 AM, Rolf Eike Beer wrote: Rather than being a conditional version of STATUS I think full stack information is useful for debugging. Add to the cmake::MessageType enumeration a DEBUG value and teach cmake::IssueMessage to handle it. The output should look like an error or warning but with CMake Debug as the header instead of CMake Error or CMake Warning. I would like to have that switchable in some way. E.g. for Boost_DEBUG I don't have stack traces at the moment, but the contents are the information I need. Stacktraces are useful, but not always. I'm not opposed to a switch but extra verbosity rarely hurts debug output IMO. Even a switch at the call site may be the wrong place because it is up to the viewer of the message whether the full context is important. Perhaps the switch can be based on something similar to the context filters (see below). Once the decision to display the message has a cmListFileBacktrace instance available for the context then you can have fancier rules for deciding what messages to display. I don't think I fully understand what you are trying to say here. Elsewhere in this thread discussion proposed filters on messages based on their context. Filters based on the full backtrace should be possible and would give a lot of control. You mean something like a regex? So that if the stacktrace and/or prefix (and/or the whole message) matches the regex it is displayed ? It may cost a lot at runtime? -- Erk Le gouvernement représentatif n'est pas la démocratie -- http://www.le-message.org -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Introducing: message(DEBUG)
On 3/5/2012 10:33 AM, Eric Noulard wrote: 2012/3/5 Brad Kingbrad.k...@kitware.com: Elsewhere in this thread discussion proposed filters on messages based on their context. Filters based on the full backtrace should be possible and would give a lot of control. You mean something like a regex? I had no particular interface in mind and was just pointing out what is possible. So that if the stacktrace and/or prefix (and/or the whole message) matches the regex it is displayed ? That sounds reasonable. It may cost a lot at runtime? Possibly, but there should be a fast-path if DEBUG messages are not turned on at all. Once they are on then the runtime cost may be worthwhile for such control. -Brad -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] Introducing: message(DEBUG)
I have a small patch to CMake that looks like this:
diff --git a/Source/cmMessageCommand.cxx b/Source/cmMessageCommand.cxx
index e1dbf34..ad24368 100644
--- a/Source/cmMessageCommand.cxx
+++ b/Source/cmMessageCommand.cxx
@@ -52,6 +52,18 @@ bool cmMessageCommand
status = true;
++i;
}
+ else if (*i == DEBUG)
+{
+if (!this-Makefile-GetCMakeInstance()-GetDebugOutput())
+ {
+ if (!this-Makefile-IsOn(CMAKE_DEBUG_MESSAGES))
+{
+return true;
+}
+ }
+status = true;
+++i;
+}
for(;i != args.end(); ++i)
{
The idea behind this is like that: you can write message(DEBUG ...) everywhere
in your CMake code and it will just print out nothing. Once you run cmake --
debug-output these messages will behave like message(STATUS), i.e. give you
their contents and call trace. If at the point of the message(DEBUG) call a
variable CMAKE_DEBUG_MESSAGES is set the message will behave like a normal
message(STATUS), too. This variable is a completely normal CMake variable,
i.e. it follows the normal scoping rules. My idea is to go into
Modules/Find*.cmake and e.g. replace if(Boost_DEBUG) message(...) endif() just
by CMAKE_DEBUG_MESSAGES |= Boost_DEBUG message(DEBUG ...).
Opinions?
Eike
signature.asc
Description: This is a digitally signed message part.
--
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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Introducing: message(DEBUG)
Rolf Eike Beer wrote: I have a small patch to CMake that looks like this: + if (!this-Makefile-IsOn(CMAKE_DEBUG_MESSAGES)) I propose to print message if one of the following holds: * CMAKE_DEBUG_MESSAGES is true; * CMAKE_DEBUG_MESSAGES_FileName is true, where FileName is CMAKE_CURRENT_LIST_FILE's name without extension; * Current list file is CMakeLists.txt and CMAKE_DEBUG_MESSAGES_CurrentDirectory is true. This will allow # Turn all debug messages -DCMAKE_DEBUG_MESSAGES=ON # Turn all debug messages in FindBoost.cmake -DCMAKE_DEBUG_MESSAGES_FindBoost=ON # Turn all debug messages in mysubdir/CMakeLists.txt -DCMAKE_DEBUG_MESSAGES_mysubdir=ON # Turn all debug messages in **/CMakeLists.txt -DCMAKE_DEBUG_MESSAGES_CMakeLists=ON -- Yury G. Kudryashov, mailto: ur...@mccme.ru -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Introducing: message(DEBUG)
Am Samstag, 3. März 2012, 17:05:11 schrieb Yury G. Kudryashov: Rolf Eike Beer wrote: I have a small patch to CMake that looks like this: + if (!this-Makefile-IsOn(CMAKE_DEBUG_MESSAGES)) I propose to print message if one of the following holds: * CMAKE_DEBUG_MESSAGES is true; * CMAKE_DEBUG_MESSAGES_FileName is true, where FileName is CMAKE_CURRENT_LIST_FILE's name without extension; * Current list file is CMakeLists.txt and CMAKE_DEBUG_MESSAGES_CurrentDirectory is true. This will allow # Turn all debug messages -DCMAKE_DEBUG_MESSAGES=ON # Turn all debug messages in FindBoost.cmake -DCMAKE_DEBUG_MESSAGES_FindBoost=ON # Turn all debug messages in mysubdir/CMakeLists.txt -DCMAKE_DEBUG_MESSAGES_mysubdir=ON # Turn all debug messages in **/CMakeLists.txt -DCMAKE_DEBUG_MESSAGES_CMakeLists=ON I'm not absolutely sure if this is worth the effort. Not that it is generally a bad idea, but it will likely require some code. The way you simply could do this stuff is to just put set(CMAKE_DEBUG_MESSAGES On) at the beginning of the subdir/module you want to debug and reset it at the end. Eike signature.asc Description: This is a digitally signed message part. -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Introducing: message(DEBUG)
I have a small patch to CMake that looks like this: For easier access I pushed the topic debug-messages to stage. I don't guarantee for stability here, so I may force-push at any time. Eike signature.asc Description: This is a digitally signed message part. -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
