Inline responses.
Harry Mallon CODEX | Software Engineer 60 Poland Street | London | England | W1F 7NT E ha...@codexdigital.com | T +44 203 7000 989 > On 19 Jan 2016, at 15:42, Brad King <brad.k...@kitware.com> wrote: > > On 01/18/2016 01:32 PM, Harry Mallon wrote: >> https://github.com/Kitware/CMake/pull/209 >> This passes through the output of the run (as well as the return value) >> so that users can access any output without using try_run. > > Thanks. The signature of the macro takes a variable for the return value > to be stored. We need something similar to control the name of the variable > used to store the output. This could either be done with an optional/named > argument or simply by documenting that the output will come in `<var>_OUTPUT`. Sounds sensible > We also need to define what happens when the check has already been run. > The normal `<var>` result is cached to prevent repeat runs of the check. > I don't think we can reasonably cache the entire output of the run and > provide it on later re-runs of CMake when the check does not actually run. I agree, we shouldn't be caching all of that > OTOH your use case for extracting versions may have other solutions. > We generally try to avoid try_run because it only works when the toolchain > targets the host architecture and so does not work when cross compiling > in general. Look at what Modules/CMakeDetermineCompilerId.cmake does to > extract the compiler id and version information. It also leaves files > in build trees under CMakeFiles/${CMAKE_VERSION}/CompilerIdC that you > can see. Basically it encodes the needed information in strings that > can be extracted from the binaries without running them. I have read CMakeDetermineCompilerId.cmake but I can't see how I can use that kind of an approach. Having static const char* set by the preprocessor is a good idea for the reasons that you mention but I cannot retrieve a version number without linking and interrogating the library. I could be missing something though. H -- 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