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 emits simply too much (redundant) information.
IIRC the original reason for having separate
-- Looking for iconv.h
-- Looking for iconv.h - Found
lines is that the first one prints what is about to be
done in case something happens (e.g. crash) that prevents
the second output from ever showing up. That helps a lot
in tracking down the problem. If another thread buffers
the first message then it might not show up at all. The
terminal escape codes approach does not have that problem.
The same de-dup you do in the threaded filter could be done
with a shell alias that pipes 'cmake' output through a sed
script or something to de-dup it. That would handle local
interactive terminal use of cmake without any upstream
changes.
-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
