On Wed, Jul 15, 2015 at 9:10 AM, Brad King <brad.k...@kitware.com> wrote: > On 07/09/2015 01:53 PM, Clifford Yapp wrote: >> Actually, thinking about that, what's really needed is not an >> in-memory log but a way to specify log files, since an unexpected >> crash or exit is not a situation under which such in-memory logs could >> be reliably written to disk. So it would instead need to be >> CMAKE_STATUS_MESSAGE_LOG, CMAKE_ERROR_MESSAGES_LOG, etc. which would >> hold paths to which messages would be copied before being written to >> stdout/stderr. > > These could be defined as GLOBAL properties since there can only > be one.
Makes sense. > Internally we already have callback infrastructure to > dispatch where these messages go. Hooks could be added to check > these properties too. Or, the property setting logic could have > special handling for these properties to install the needed > callbacks internally. This approach would avoid opening/closing > the log files over and over. We could just keep them open all > the time and flush after each write. Sounds good! (Always in favor of less filesystem hits, especially on Windows...) In hopes of writing an acceptable patch, is there an approach that would be preferred? Cheers, CY -- 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
