Re: [CMake] How to set a preprocessor define for all build configurations except one ?

Glenn Coombs glenn.coo...@gmail.com writes: Is there a more elegant solution that I am missing ? Ideally something like: add_definitions(CONFIG=Debug;Release;RelWithDebInfo;MinSizeRel -DGEN_OUTFILES) which I know doesn't exist but I really wish it did :-) Isn't it OK to just do something

Re: [CMake] Undefined reference

Mauricio Klein mauricio.klein@gmail.com writes: I can compile all my codes without problems, but in the linkage step, i receive a lot of errors about undefined reference to OpenSSL functions (yes, my code uses OpenSSL). In my own (and ugly :P) Makefile, i use -lssl flag in g++ compile

Re: [CMake] Patch for cmake-mode.el

Roy Crihfield rscr...@gmail.com writes: I have a patch the the CMake emacs mode I'd like to have reviewed and push. What is the preferred way to do this - should I just send the patch, or fork and push to the repository? Both sending a patch to cmake-devel via `git patch' and sending a pull

Re: [CMake] Patch for cmake-mode.el

Paul Smith p...@mad-scientist.net writes: On Sun, 2013-11-17 at 20:03 +0200, Raphael Kubo da Costa wrote: Roy Crihfield rscr...@gmail.com writes: I have a patch the the CMake emacs mode I'd like to have reviewed and push. What is the preferred way to do this - should I just send

Re: [cmake-developers] Checking for -pthread before -lpthread{s} in FindThreads.cmake

Raphael Kubo da Costa kub...@gmail.com writes: FreeBSD explicitly recommends using -pthread [1], and I guess the same holds for at least gcc-based systems, where -pthread usually translates into automatically passing -lpthread and any necessary definitions to the compiler and the linker

Re: [cmake-developers] Checking for -pthread before -lpthread{s} in FindThreads.cmake

Rolf Eike Beer e...@sf-mail.de writes: Am Sonntag 17 April 2011, 03:23:39 schrieb Raphael Kubo da Costa: Depending on the patch implementation, this would probably fix CMake bug #7830 as a side-effect. I think 7830 is another incarnation of what I submitted as bug 11333. And there is even

[cmake-developers] [PATCH] Fix typo in set_target_properties' documentation.

our - or --- Source/cmSetTargetPropertiesCommand.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/Source/cmSetTargetPropertiesCommand.h b/Source/cmSetTargetPropertiesCommand.h index feead00..320378d 100644 --- a/Source/cmSetTargetPropertiesCommand.h +++

[cmake-developers] [PATCH] Remove the apparently outdated README in Source/QtDialog.

Qt has been LGPL-licensed for a few years, so the clause mentioning only developers with a paid Qt license can change the code seems to be outdated. --- Source/QtDialog/README |3 --- 1 files changed, 0 insertions(+), 3 deletions(-) delete mode 100644 Source/QtDialog/README diff --git

[cmake-developers] [PATCH] QtDialog: Set Ctrl+Q as the shortcut for quitting the program.

QKeySequence::Quit does not work on all platforms, and since it translates to Ctrl+Q on all platforms where it does work, Ctrl+Q was hardcoded instead. --- Source/QtDialog/CMakeSetupDialog.cxx |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git

Re: [cmake-developers] [PATCH] QtDialog: Set Ctrl+Q as the shortcut for quitting the program.

Clinton Stimpson clin...@elemtech.com writes: On Tuesday, December 13, 2011 04:51:16 pm Raphael Kubo da Costa wrote: QKeySequence::Quit does not work on all platforms, and since it translates to Ctrl+Q on all platforms where it does work, Ctrl+Q was hardcoded instead. --- Source/QtDialog

[cmake-developers] Setting the INCLUDE_DIRECTORIES property before and after a target after 9106b564

While packaging CMake 2.8.8 for FreeBSD, an old port of lprof [1] started failing to build after some include headers were not found. The relevant CMakeLists does the following: add_library(foo foo.c) set_directory_properties( PROPERTIES INCLUDE_DIRECTORIES ${SOME_DIRECTORY}) foo.c

Re: [cmake-developers] Setting the INCLUDE_DIRECTORIES property before and after a target after 9106b564

Brad King brad.k...@kitware.com writes: CMake 2.8.8 introduced support for per-target include directories. Prior to that the directory-level INCLUDE_DIRECTORIES property was documented as read-only: $ cmake --help-property INCLUDE_DIRECTORIES cmake version 2.8.7 INCLUDE_DIRECTORIES

[cmake-developers] [PATCH] KWSys: Include backtrace-related headers on FreeBSD.

This was probably broken for a long while, but the problem was not apparent because the check for execinfo.h would fail by default because -I/usr/local/include was not being passed to the compiler when making the checks for the header's existence. Now that very recent FreeBSD versions (ie.

[cmake-developers] [PATCH] Help: Fix typo in `if's documentation.

--- Help/command/if.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Help/command/if.rst b/Help/command/if.rst index 49c356e..a45b995 100644 --- a/Help/command/if.rst +++ b/Help/command/if.rst @@ -187,7 +187,7 @@ above-documented signature accepts ``variable|string``:

[cmake-developers] [PATCH] Tests: Use a less strict regular expression to look for "SONAME".

Commit 899458ab ("Tests: Cover NO_SONAME property for SHARED libraries") introduced a few new ExportImport tests, and the check_lib_{no}soname.cmake scripts that parse readelf(1)'s output. Make the regular expression matching the SONAME line output by readelf less strict, as the output format

Re: [cmake-developers] [PATCH] Tests: Use a less strict regular expression to look for "SONAME".

Brad King <brad.k...@kitware.com> writes: > On 09/01/2015 09:30 AM, Raphael Kubo da Costa wrote: >> That's because that script is asserting that the regular expression does >> _not_ match, which is always the case when GNU binutils is not used. > > Prior to the

Re: [cmake-developers] [PATCH] Tests: Use a less strict regular expression to look for "SONAME".

Brad King writes: > The same regex appears in > > Tests/Plugin/check_mod_soname.cmake > > and has for years. I think that one should be updated too, but I > wonder why this problem has not been revealed in that test before. That's because that script is asserting that

[cmake-developers] [PATCH v2] Tests: Use a less strict regular expression to look for "SONAME".

Commit 899458ab ("Tests: Cover NO_SONAME property for SHARED libraries") introduced a few new ExportImport tests, and the check_lib_{no}soname.cmake scripts that parse readelf(1)'s output. Make the regular expression matching the SONAME line output by readelf less strict, as the output format

[cmake-developers] [PATCH] Features: Only enable C11 support on GCC >= 4.9.

As of version 3.3.1, CMake sets CMAKE_C11_STANDARD_COMPILE_OPTION and CMAKE_C11_EXTENSION_COMPILE_OPTION for GCC >= 4.7, and checks for C11 features for GCC >= 4.6. It also means CMake itself will be built with -std=gnu11 if GCC >= 4.7 is used. However, GCC only has full C11 support with the 4.9

Re: [cmake-developers] [PATCH] Features: Only enable C11 support on GCC >= 4.9.

Stephen Kelly <steve...@gmail.com> writes: > Raphael Kubo da Costa wrote: > >> Adjust the GCC feature detection code to only consider C11 support to >> exist on GCC >= 4.9. > > If you do that you must remove the definition of > CMAKE_CXX11_STANDARD_COMPILE_OPT

Re: [cmake-developers] [PATCH] Features: Only enable C11 support on GCC >= 4.9.

Brad King writes: > In this case CMake itself cannot build with C11 on this compiler/platform > combination so we should not try to do so. We already have some checks > here: > > http://www.cmake.org/gitweb?p=cmake.git;a=blob;f=CMakeLists.txt;hb=v3.3.1#l39 > > to decide

[cmake-developers] [PATCH] Do not build CMake in C11 mode if _Thread_local support is broken.

Support for C11's _Thread_local was introduced in GCC in the 4.9 series, even though we make the C11 compiler flags available in CMake with GCC >= 4.6. FreeBSD's runetype.h uses _Thread_local, which causes CMake's own build to fail when using GCC < 4.9 and -std=gnu11: