Use --trace with the cmake command line, redirect that to a file, then search the file
On Thu, Oct 20, 2011 at 5:11 PM, Robert Dailey <rcdai...@gmail.com> wrote: > So I created a small project to attempt to reproduce this problem on a much > smaller scale, but it functioned as designed in that case. > It's only in my large, corporate project that this happens. Is there any way > to dump a "scope stack" or call stack of some sort in CMake? That way I can > see what the real parent scope is? Maybe it's not what I think it is. > > --------- > Robert Dailey > > > On Thu, Oct 20, 2011 at 3:42 PM, Michael Hertling <mhertl...@online.de> > wrote: >> >> On 10/20/2011 08:44 PM, Robert Dailey wrote: >> > On Thu, Oct 20, 2011 at 12:56 PM, Michael Hertling >> > <mhertl...@online.de>wrote: >> > >> >> On 10/20/2011 06:59 PM, Robert Dailey wrote: >> >>> Let me ask this, >> >>> >> >>> What would be the parent of a function located in the root CMakeLists >> >> file >> >>> but called from a subordinate CMakeLists file? >> >> >> >> It's the subordinate CMakeLists.txt file's parent, but what Michael >> >> probably aims at is that some variables undergo a lazy evaluation, >> >> i.e. when you say >> >> >> >> set( CMAKE_MFC_FLAG 2 ) >> >> add_executable( ... ) >> >> >> >> in a function, and CMAKE_MFC_FLAG isn't evaluated till generation time, >> >> the value "2" will be lost since it is limited to the function's scope. >> >> See the following project for an example: >> > >> > >> > Does this lazy evaluation also apply to variables set with PARENT_SCOPE? >> > If >> > so, that would explain why not even that helped. >> >> If the variable is subject to lazy evaluation - not all variables are, >> and I don't know if CMAKE_MFC_FLAG is - it doesn't matter how it has >> received its final value at the concerned CMakeLists.txt's end, i.e. >> if it has been set in the CMakeLists.txt immediately or in a function >> using PARENT_SCOPE or in a subordinate CMakeLists.txt file entered by >> ADD_SUBDIRECTORY(), also using PARENT_SCOPE; the latest value will be >> in effect for the generation step. >> >> BTW, I talked trash: >> >> >>> What would be the parent of a function located in the root CMakeLists >> >> file >> >>> but called from a subordinate CMakeLists file? >> >> >> >> It's the subordinate CMakeLists.txt file's parent, [...] >> >> This is not true, of course. A function called from a CMakeLists.txt >> file opens up its own scope, and its parent scope is the one of the >> calling CMakeLists.txt file, not the one of the latter's parent. >> Sorry about the mistake. >> >> If your issue still persists, could you come up with a minimal >> but complete exemplary project for further investigation? >> >> Regards, >> >> Michael >> -- >> >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Please keep messages on-topic and check the CMake FAQ at: >> http://www.cmake.org/Wiki/CMake_FAQ >> >> Follow this link to subscribe/unsubscribe: >> http://www.cmake.org/mailman/listinfo/cmake > > > -- > > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Follow this link to subscribe/unsubscribe: > http://www.cmake.org/mailman/listinfo/cmake > -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake