[cmake-developers] [CMake] add_custom_command() OUTPUT does not accept generator expressions, why?

[Brad King]

On 04/06/2016 08:02 AM, Petr Kmoch wrote:
> On 6 April 2016 at 09:51, Yves Frederix wrote:
>>   add_custom_target(test_target ALL SOURCES $<TARGET_FILE_DIR:test_lib>/generated_file.cpp)

Watch out for circular logic here.  For example:

  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.

>>  Target "test_target" has source files which vary by configuration.  This is
>>  not supported by the "Visual Studio 14 2015" generator.
>> 
>> Intuitively I understand why this is not supported (different
>> configurations share the same project file in VS, so which source file
>> would the project point to?) Is this also a technical limitation
>> though? Or do VS project files (and other multiconfig generator
>> project files such as xcode) support this setup but was it merely not
>> implemented yet?
> 
> 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.

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.

-Brad