[CMake] global variable passing up via INTERNAL cache variable

[James Bigler]

On Nov 27, 2007, at 3:55 PM, Luigi CALORI wrote:

> I encoundered the same problems and in the end used the horrible  
> hack to use a file where
> append, clear it in the main file.

I think I saw a thread about this.  Good to know in the future.

I did figure out a solution without involving a file.  You use one  
variable to build the result and use a second variable to store it.

MACRO(APPEND_VALUE VALUE)
   SET(temp_value ${MY_VALUE_BUILD} ${VALUE})
   SET(MY_VALUE_BUILD ${temp_value} CACHE INTERNAL "List of values")
ENDMACRO(APPEND_VALUE)

ADD_SUBDIRECTORY(subdir1)
ADD_SUBDIRECTORY(subdir2)

# Make a copy of the built value
SET(MY_VALUE ${MY_VALUE_BUILD} CACHE INTERNAL "List of values")

# Clear the built value for the next run of cmake
SET(MY_VALUE_BUILD "" CACHE INTERNAL "List of values")

This worked just great for my project.  The issue really isn't about  
macros and more about getting a true "global" variable.  It looks  
like this feature is in CVS cmake, but I can't move to that yet.

> I agree is an annoying limitation of the language and, as well as  
> lack of scope in variables
> pose problems in using macros....

This actually hasn't bit me yet (thankfully).  I agree with the  
thread that more powerful variable scoping would be very useful.

> A question for the other LUA thread: are these problem solved in  
> LUA wrapping?
> That would be another good reason to add LUA scripting

This is OT, but I've been following that thread, and I wouldn't mind  
CMake script being based on a different language, but I would want a  
wholesale conversion (i.e. either use CMake script or Lua or  
whatever, because allowing mixing would cause a legacy nightmare).  I  
don't want to have to deal with more than a single language.

In the end, I don't think Kitware will make the transition unless  
there are very compelling reasons since it will involve converting  
huge number of scripts and documentation.

James

> On Tue, 27 Nov 2007 15:31:25 -0700, James Bigler said:
>>
>> I got a hint that I could do this to set values that could be read by
>> the CMakeLists.txt file above:
>>
>> MACRO(APPEND_VALUE VALUE)
>>    SET(temp_value ${MY_VALUE} ${VALUE})
>>    MESSAGE("temp_value = ${temp_value}")
>>    SET(MY_VALUE ${temp_value} CACHE INTERNAL "List of values")
>> ENDMACRO(APPEND_VALUE)
>>
>> I would then call APPEND_VALUE in sub directories.
>>
>> Life was good until I noticed that subsequent calls of
>> cmake would
>> append to the list making it grow and grow.  I could do an insert
>> only if the value didn't already exist, but that would prevent me
>> from having values disappear if they wouldn't have added themselves
>> (i.e. removing calls to APPEND_VALUE).
>>
>> I tried adding this to the top level CMakeLists.txt before any of my
>> ADD_SUBDIRECTORY.  The hope was that when CMake was called it would
>> clear the variable before adding stuff to it again.
>>
>> SET(MY_VALUE "" CACHE INTERNAL "")
>>
>> However this stopped the appending from happening.  It looks like
>> every time it pops up from a directory it resets MY_VALUE to what was
>> in there before decending the directory.  This behavior is different
>> from when the variable wasn't explicitly created in the top level
>> CMakeLists.txt file.  Is this because the variable was created at the
>> top level CMake instead of down below?
>>
>> Is there any way to reliably get information passed automatically
>> from subdirs?  This seems like a fundamental capability, and I'm very
>> frustrated trying to figure out how to make this work.
>>
>> I've attached a simple project that illustates the problem.  Run with
>> cmake