我的CMakeLists.txt文件解析了开发人员指定库依赖关系的一些文本文件。这些文件，我们称之为linkfile.txt，是列出要链接的库的简单文本文件，这使得不熟悉CMake的开发人员可以轻松扩展库依赖列表。
我使用的是Visual Studio 2015生成器。
现在，当修改此文本文件时，Visual Studio在您请求构建时不会自动运行CMake来更新解决方案（当您修改包含的cmake文件或CMakeLists.txt文件时，它会执行此操作）。 / p>
有没有办法告诉CMake某些额外的文件可能会使解决方案无效并需要再次运行CMake？
如果没有，我已经有了一个自定义目标，让用户在需要时手动运行CMake：
ADD_CUSTOM_TARGET( RECONFIGURE COMMAND ${CMAKE_COMMAND} ${CMAKE_BINARY_DIR} )
所以我可以重复使用它。但是，如果我将DEPENDS [path_to]/linkfile.txt参数指定为ADD_CUSTOM_TARGET，则RECONFIGURE在我{{}}}修改后请求生成解决方案时不会自动生成linkfile.txt文件或CMakeLists.txt文件已被修改。）
答案 0 :(得分：2)
有没有办法告诉
CMake某些额外的文件可能会使解决方案无效并需要再次运行CMake？
是。您正在寻找目录属性CMAKE_CONFIGURE_DEPENDS。在你的情况下，你会像这样使用它：
set_property(DIRECTORY APPEND PROPERTY CMAKE_CONFIGURE_DEPENDS linkfile.txt)
但是，我对CMake 3.7.2和VS 2013的实验表明，虽然该文件实际上已添加到解决方案中的依赖项列表中，但依赖扫描程序无法以某种方式将其捕获。因此，您可以通过将文件传递到configure_file：
configure_file(linkfile.txt linkfile.txt COPYONLY)
这会将文件从其源位置复制到二进制目录中，也以CMake 荣誉的方式将其作为配置步骤的依赖项引入。
尝试使用自定义目标执行此操作会更复杂。 CMake的自定义目标始终被视为过时，因此，每当您要求构建包含自定义目标的一组目标时，将运行该自定义目标。请注意，默认情况下，自定义目标不属于all，这就是为什么您的目标无法通过简单的解决方案重建获得。如果它是all的一部分（通过在ALL调用中添加参数add_custom_target()），它将在每次重建时触发，而不考虑依赖项（自定义目标） 总是过时了。）
前进的方法是运行CMake的自定义命令，该命令取决于linkfile.txt并触及文件x。然后，自定义目标RECONFIGURE会在其x中显示DEPENDS。构建自定义目标意味着必须更新其所有依赖项，这意味着必要时将检查并触发从“x生成linkfile.txt”的自定义命令。
但是，以上仅作为解释;解决问题的正确方法是使用CMAKE_CONFIGURE_DEPENDS。