I think the delayed-\n approach is the simplest. In the
case that the output is interrupted by other content it
almost certainly means something is going wrong anyway.
Does CMake use popen to launch processes? Or it just spawns them providing them
direct access to stdin/out/err? If it was
FYI stage/compact-status-log was updated with more elegant C++ implementation
introducing new cmStdoutFilter cmThread utility classes enabled when certain
headers are present in the system, so in cmakemain.cxx we simply put:
cmStdoutFilter stdoutFilter(-- );
--Adam
--
Powered by
On 09/24/2014 08:02 AM, Adam Strzelecki wrote:
cmThread utility class
Introducing threads is exactly the too much infrastructure
to which I was referring in my previous response. I'm sorry
to reject all the effort you put into the threads approach so
far, but I did say this earlier.
cmake
I like the idea of reducing the extra-verbose output, and maybe I'm missing
something here but could this possibly be done with a much simpler
approach? It seems the way these double messages happen is with the
following CMake code:
message(STATUS Doing something)
# Do some stuff
message(STATUS
On 09/24/2014 09:44 AM, Chuck Atkins wrote:
message(STATUS Doing something NOENDL)
# Do some stuff
message(STATUS - Result)
What happens if something else occurs in between that prints
a message? Do we tolerate
-- Doing something-- Unrelated Message
- Result
instead of
-- Doing
What happens if something else occurs in between that prints
a message? Do we tolerate
-- Doing something-- Unrelated Message
- Result
instead of
-- Doing something
-- Unrelated Message
-- Doing something - Result
Sure, why not? There's no requirement to use the NOENDL, it
What happens if something else occurs in between that prints
a message?
That's why my solution is completely automatic, does not require any changes in
existing modules, and it works as desired so only:
-- Doing something
-- Doing something - Result
That arrive to stdout are compacted
On 09/24/2014 10:29 AM, Adam Strzelecki wrote:
Please try to build this stage branch and try to run cmake
In case I was not clear the last two times:
We will *NOT* be introducing use of *THREADS* in CMake just
to filter our own output.
-Brad
--
Powered by www.kitware.com
Please keep
We will *NOT* be introducing use of *THREADS* in CMake just
to filter our own output.
Yeah, got it. Are subprocess allowed then?
(…) just to filter our own output.
Please note that such solution that filters stdout low level is superior to
doing it as CMake owns level because cmake may be
On 09/24/2014 10:47 AM, Adam Strzelecki wrote:
Are subprocess allowed then?
(…) just to filter our own output.
Please note that such solution that filters stdout low level
Yes, but I do not think we should have to do any filtering
at all. The output should just be written to match what
we
On 09/21/2014 12:45 PM, Adam Strzelecki wrote:
I have pushed new branch stage/compact-status-log for review.
Neat.
Idea behind is to reduce cmake output when we are in terminal.
When we are outputting message Trying feature we can later
remove it when new output comes using ANSI escape
What if stdout's buffer happens to fill up and flush anyway?
I think I can provide other terminal-less solution via filtering stdout and
stderr via pipe and background thread.
I got some proof-of-concept program already. Idea is:
stdout stderr are duped and proxied by some background thread.
On 09/22/2014 12:26 PM, Adam Strzelecki wrote:
stdout stderr are duped and proxied by some background thread.
IMO that is too much infrastructure to solve what is essentially
a cosmetic problem.
-Brad
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
IMO that is too much infrastructure to solve what is essentially
a cosmetic problem.
Well, IMHO it is usability problem, because cmake emits simply too much
(redundant) information.
FYI I have pushed new stage/compact-status-log which does include this
automatic subsequent status log line
14 matches
Mail list logo
