[cmake-developers] COMPILE_LANGUAGE generator expression

[Stephen Kelly]

Brad King wrote:

> However, in VS >= 10 each source-specific property value must explicitly
> reference the target-wide value to not be totally overridden.  This
> means generating all the properties for every source file separately
> would allow lang-specific things in those generators.  However, an
> additional cost is that msbuild will no longer be able to group
> many source files into a single invocation of the compiler, so builds
> will be slower.  This would have to be done on an as-needed basis, and
> the associated tracking may make the generator more complex.  I'm also
> not sure it will work for all settings.

Is this already the case to handle the COMPILE_FLAGS source file property?

> 
> Rather than trying to hack something for VS >= 10 I think we should just
> make it behave however we decide for the other IDEs.  We need to define
> some kind of behavior.  Perhaps evaluating w.r.t. the link language is
> a reasonable default.  We could also provide a target property that
> can be used to specify which language to choose.

I'm not fond of the idea of setting the compile language to the link 
language of the target. It would make this look correct/portable, even 
though it behaves incorrectly with IDEs:

 add_executable(foo foo.c foo.cpp main.cpp)
 target_compile_options(foo 
   PRIVATE $<$<COMPILE_LANGUAGE:CXX>,-fno-exceptions>

This means that a portable buildsystem which wishes to mix languages will 
have to do so in separate STATIC or OBJECT libraries, both in the future and 
now, without the COMPILE_LANGUAGE generator expression:

 add_library(foo_c STATIC
   foo.c
 ) 
 add_library(foo_cxx STATIC
   foo.cxx
 ) 
 target_compile_options(foo_cxx PRIVATE -fno-exceptions)

 add_executable(foo main.cpp)
 target_link_libraries(foo foo_c foo_cxx)


For the convenience of buildsystems which do not target the IDEs, should we 
allow the use of COMPILE_LANGUAGE? And issue an error if using an IDE 
generator?

Thanks,

Steve.