On 05/23/2014 03:39 AM, Nicolas Desprès wrote: >> One remaining challenge is CMAKE_CURRENT_LIST_FILE and >> CMAKE_CURRENT_LIST_LINE. Since the "current file" is not [snip] > I think we should not touch those variables because they have > dynamic behavior and if they are used in the generated code I > expect the current behavior.
CMAKE_CURRENT_LIST_LINE comes from the lexer currently. I think CMAKE_CURRENT_LIST_FILE could too, and I'm not sure why it does not currently. That would take some investigation in the history to learn. > Why not adding __FILE__ and __LINE__ tokens that would be > expanded by the lexer with the file name and line number > last set by #cmake-source-line? That is what the above variables were meant to be. They just happen to be implemented by replacing during variable evaluation instead of by the lexer. Having the lexer do actual replacements would be a change to the language beyond the scope of the #line proposal. I think this issue as a reason to not add a #line feature. For your generated source case you can add comments that refer back to the original source locations for human reference. -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/cgi-bin/mailman/listinfo/cmake-developers
