On 10/04/2015 10:47 AM, Stephen Kelly wrote: > So, is this thread really about a bug, or is it a feature request?
I think it has become a feature request to select link flags for language standard levels. It is conflated with a bug fix because the link flags are needed to support existing features on Solaris. > Perhaps those commits should be reverted. I see no reason for SolarisStudio > on linux to behave any differently than on solaris, so the commit relating > to that is probably not appropriate. I don't want CMake to generate broken builds by default. We *know* it goes wrong on Solaris and cannot possibly work without user intervention. If a problem comes up on Linux too we can deal with it as necessary. > I wrote here some ideas of a design for specifying the standard library to > use: > > > http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/13284/focus=13296 Is that the right link? I don't see discussion of -stdlib= in that message. > Perhaps, rather than passing CMAKE_CXX11_EXTENSION_COMPILE_OPTION to the > linker, we should work more on a design like the above way to specify a > standard library. Yes, but the -std= and -stdlib= flags are different from the full LINK_OPTIONS discussion because they are meant specifically for the front end and not for the linker (never "-Wl,"). Also they need to be selected by CMake rather than propagated as a flag specified by project code. > The compile features can imply a default and a set of allowed alternatives > (for example, compiling with cxx_static_assert implies the use of stdlibc++ > or libc++ with Clang by default but there is a way to use the other > instead). The COMPATIBLE_INTERFACE features may also be used to ensure that > targets which link together all use the same standard library. Originally I was thinking we should just use the same -std= for linking that we do for compilation, but don't we currently support compiling different targets at different standard levels and then linking them? In that case we will certainly need more sophisticated logic for selecting the link flag. BTW, I noticed in cmLocalGenerator::AddCompileOptions that we currently mutate the configure step result by setting target properties like <LANG>_STANDARD during generation. Also, this is done with one "config" value which may not be appropriate in multi-config generators. Thanks, -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
