> add_library(test_lib STATIC $<TARGET_FILE_DIR:test_lib>/generated_file.cpp) > add_custom_command(OUTPUT $<TARGET_FILE_DIR:test_lib>/generated_file.cpp > ...) > > When we compute the output information like target file directory and > target file name we need to also determine the linker language. For > that we need the full list of source files to infer the language. If > that list of sources uses generator expressions that refer back to the > location of the target itself then we have a circular dependency in the > computation. This will have to be diagnosed and rejected.
Yes, agree. Or alternatively, document that source files that contain generator expressions are not taken into account during automatic linker language computation? In this case, you would need to set it manually if this particular source file would make a difference. <snip> >> I don't know anything about XCode, unfortunately. However, Visual Studio >> definitely supports a form of varying the source file list of the project >> between configurations. That's because a source file can be marked as >> _excluded_ from build for a particular configuration. So the solution >> CMake could use would be to add all source files from all configurations >> into the project, but mark them as excluded from [in]appropriate >> configurations. > > The current limitation is mostly because no one has thoroughly > investigated how to support it in VS IDE projects. If there is an > approach that will work then we'd be happy to see it implemented. > Similarly for Xcode. In order to implement this, CMake should be able to determine if the result of resolving a generator expression depends on the configuration or not. Does the generator expression logic currently allow such check? I did see cmGeneratorExpression::GetHadContextSensitiveCondition(), but I have the feeling it does not really do exactly that. > A fallback approach could be to generate a wrapper source file > that uses the preprocessor to conditionally include the real > per-config source file based on the configuration. That would be an option as well. I suspect best by using the CMAKE_INTDIR preprocessor define? Yves -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
