[cmake-developers] [CMake] add_custom_command() OUTPUT does not accept generator expressions, why?
Yves Frederix
yves.frederix+cmake at gmail.com
Wed Apr 6 09:59:24 EDT 2016
> 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
More information about the cmake-developers
mailing list