$<IN_LIST:...> doesn't handle empty strings the same way as if(IN_LIST) (#18556) · Issues · CMake / CMake

$<IN_LIST:...> doesn't handle empty strings the same way as if(IN_LIST)

These two don't work the same:

# Test if(IN_LIST)
set(_item "")
set(_mylist ";a")
if(_item IN_LIST _mylist)
  message(STATUS "In the list")
else()
  message(STATUS "Not in the list")
endif()

# Test $<IN_LIST:...>
add_custom_target(tgt COMMAND ${CMAKE_COMMAND} -E echo $<IN_LIST:,$<SEMICOLON>a>)

The if(IN_LIST) case says "yes", but the generator expression says "no". This is surprising and unexpected behavior.

Unfortunately, it seems to be enforced by Tests/GeneratorExpression/CMakeLists.txt line 64:

    -Dtest_inlist_empty_3=$<IN_LIST:,>

and Tests/GeneratorExpression/check-part1.cmake line 56:

check(test_inlist_empty_3 "0")

The fix would be to change line 291 in Source/cmGeneratorExpressionNode.cxx:

    cmSystemTools::ExpandListArgument(parameters[1], values); // Add a true parameter to the end to handle empty items

However, this would break backwards compatibility. We could add a policy that tries it both ways and warns the user if they differ.

These two don't work the same:

```cmake
# Test if(IN_LIST)
set(_item "")
set(_mylist ";a")
if(_item IN_LIST _mylist)
  message(STATUS "In the list")
else()
  message(STATUS "Not in the list")
endif()

# Test $<IN_LIST:...>
add_custom_target(tgt COMMAND ${CMAKE_COMMAND} -E echo $<IN_LIST:,$<SEMICOLON>a>)
```

The `if(IN_LIST)` case says "yes", but the generator expression says "no". This is surprising and unexpected behavior.

Unfortunately, it seems to be enforced by `Tests/GeneratorExpression/CMakeLists.txt` line 64:

```cmake
    -Dtest_inlist_empty_3=$<IN_LIST:,>
```

and `Tests/GeneratorExpression/check-part1.cmake` line 56:
```cmake
check(test_inlist_empty_3 "0")
```

The fix would be to change line 291 in `Source/cmGeneratorExpressionNode.cxx`:

```c++
    cmSystemTools::ExpandListArgument(parameters[1], values); // Add a true parameter to the end to handle empty items
```

However, this would break backwards compatibility. We could add a policy that tries it both ways and warns the user if they differ.