[cmake-developers] COMPILE_LANGUAGE generator expression

Brad King brad.king at kitware.com
Mon Feb 23 14:06:05 EST 2015


On 02/22/2015 01:21 PM, Stephen Kelly wrote:
> Is there any updated knowledge since 
> 
>  http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/6844/focus=6855

AFAICT nothing has changed, except:

> I saw commit 06e527b3 (Merge topic 'xcode-flags-per-language', 2015-02-10) 
> go in recently, but I don't know if it relates to this.

That allows OTHER_CFLAGS and OTHER_CPLUSPLUSFLAGS to be populated
separately regardless of the linker language used in the target.
The restriction had been due to our implementation and the fix
should work for all versions of Xcode.  With the fix we can now
generate per-target/per-config/per-language flags for Xcode.

We still cannot generate per-source/per-config flags though, except
perhaps by generating a wrapper $src-$config.$lang source file that
#include-s the original source and can then have its own reference
in Xcode.  However, I don't think we need that for $<COMPILE_LANGUAGE>
in target-wide locations.

> Even if the issue can be solved for compile options and compile definitions, 
> it seems that for the IDEs, include directories may pose greater problems 
> because there is no way to keep one list for that, while also allowing the 
> context to be compile language dependent?

For Xcode and VS < 10 that will remain a problem.  There is only only
one place to put preprocessor settings for each target/config pair.
They are not language-specific.

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.

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.

-Brad



More information about the cmake-developers mailing list