MantisBT - CMake
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0008154CMakeCMakepublic2008-11-24 13:372011-06-17 12:39
ReporterRoscoe A. Bartlett 
Assigned ToDavid Cole 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product VersionCMake-2-6 
Target VersionCMake 2.8.5Fixed in VersionCMake 2.8.5 
Summary0008154: LIST(REMOVE_DUPLICATES VARNAME) creates a local variable when passed a global varaible
DescriptionAfter about two hours of debugging, I found out that LIST(REMOVE_DUPLICATES VARNAME) will create a regular scoped local varaible VARNAME when passed a global (i.e. CACHE INTERNAL) variable VARNAME. This is not what I expected. To get around this, I wrote the following macro(s):

==============================================================================

FUNCTION(ASSERT_DEFINED VARIBLE_NAME)
  IF(NOT DEFINED ${VARIBLE_NAME})
    MESSAGE(SEND_ERROR "Error, the varible ${VARIBLE_NAME} is not defined!")
  ENDIF()
ENDFUNCTION()

MACRO(GLOBAL_SET VARNAME)
  SET(${VARNAME} ${ARGN} CACHE INTERNAL "")
ENDMACRO()

FUNCTION(REMOVE_GLOBAL_DUPLICATES VARNAME)
  ASSERT_DEFINED(${VARNAME})
  IF (${VARNAME})
    SET(TMP ${${VARNAME}})
    LIST(REMOVE_DUPLICATES TMP)
    GLOBAL_SET(${VARNAME} ${TMP})
  ENDIF()
ENDFUNCTION()

# 2008/11/21: rabartl: The above function is necessary in order to
# preserve the "global" natrue of the variable. If you just call
# LIST(REMOVE_DUPLICATES ...) it will actually create a local variable
# of the same name and shadow the global varible. It took me something
# like two hours to track down that bug!

==============================================================================

There is no mention of this type of behavior at:

    http://www.cmake.org/cmake/help/cmake2.6docs.html#command:list [^]

I am assuming this is a bug and not designed behavior.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2008-11-24 13:37Roscoe A. BartlettNew Issue
2009-09-23 10:26Bill HoffmanStatusnew => assigned
2009-09-23 10:26Bill HoffmanAssigned To => David Cole
2009-12-28 15:34David ColeAssigned ToDavid Cole => Brad King
2009-12-28 15:35David ColeNote Added: 0019001
2010-01-04 10:32Brad KingNote Added: 0019021
2010-01-04 10:32Brad KingAssigned ToBrad King => David Cole
2011-02-07 17:22David ColeNote Added: 0025319
2011-02-07 17:22David ColeStatusassigned => resolved
2011-02-07 17:22David ColeResolutionopen => fixed
2011-02-16 11:45David ColeTarget Version => CMake 2.8.5
2011-06-06 18:25David ColeStatusresolved => closed
2011-06-06 18:25David ColeNote Added: 0026724
2011-06-17 12:39David ColeFixed in Version => CMake 2.8.5

Notes
(0019001)
David Cole   
2009-12-28 15:35   
Brad, what do you think about this....? It seems to me that any CMake command that creates a variable should, in the context of a function, create a local variable... So this is actually acting correctly.

What do you think?
(0019021)
Brad King   
2010-01-04 10:32   
It is an implementation artifact that list() reads from CACHE entries at all. The command was only intended to work with local variables. We should clarify the documentation. Only commands that document CACHE support can set cache entries.
(0025319)
David Cole   
2011-02-07 17:22   
Fix pushed to 'next'
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=2d14b15ec22a83ef78b0b9f1e5947f281e35d11a [^]

This behavior is as intended. More by organic growth than by design, really, but nevertheless, it's working as it's supposed to. The fix here is simply to clarify the situation in the LIST command's documentation.
(0026724)
David Cole   
2011-06-06 18:25   
Closing resolved issues that have not been updated in more than 3 months.