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 -- 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
