[CMake] Per target, per configuration compile flags issue

I'm having some problem with custom configurations in combination with multiple cmake projects. Basically what I have is some helper function/macro which sets the available configurations, sets the CMAKE_CXX_FLAGS_ etc. I do this with: set(CMAKE_CONFIGURATION_TYPES Debug Release) set(CMAKE_CONFIG

Re: [CMake] ExternalProject can't have interface library as a dependency

> That sounds odd. What provides it as an INTERFACE library? Me :) I created that target with add_library(openssl INTERFACE). I think I better ask the same question on dev list, since it's mostly details of get_property() implementation. On Sat, Apr 18, 2015 at 2:32 AM, Stephen Kelly wrote: > A

Re: [CMake] Do build after GIT_TAG changed in ExternalProject_Add

I'm using CMake 3.0.2 with the Visual Studio 2013 generator. -- View this message in context: http://cmake.3232098.n2.nabble.com/Do-build-after-GIT-TAG-changed-in-ExternalProject-Add-tp7590299p7590302.html Sent from the CMake mailing list archive at Nabble.com. -- Powered by www.kitware.com

Re: [CMake] Don't download external projects again after calling "make clean"

What version of CMake are you using? All the modern pre-built CMake installations should support https without extra effort on your part. Are you using a pre-built version from somewhere or are you building CMake yourself? On Saturday, April 18, 2015, Cedric Doucet wrote: > > Ok it seems the an

Re: [CMake] Do build after GIT_TAG changed in ExternalProject_Add

What version of CMake are you using? And what generator? On Saturday, April 18, 2015, typ1232 wrote: > Hello, > > The command is used as follows: > > INCLUDE(ExternalProject) > ExternalProject_Add(name > GIT_REPOSITORY https://bitbucket.org/foo/bar.git > GIT_TAG 0fcae6c2c975b309b38b8c84

[CMake] Do build after GIT_TAG changed in ExternalProject_Add

Hello, The command is used as follows: INCLUDE(ExternalProject) ExternalProject_Add(name GIT_REPOSITORY https://bitbucket.org/foo/bar.git GIT_TAG 0fcae6c2c975b309b38b8c84ac681b6bf3ae12e7 CMAKE_ARGS "" INSTALL_COMMAND "" ) This downloads and builds the project successfully, but if

Re: [CMake] Don't download external projects again after calling "make clean"

Ok it seems the answer to my problem is here: http://www.cmake.org/pipermail/cmake/2010-December/041295.html I will try it. - Mail original - > De: "Cedric Doucet" > À: cmake@cmake.org > Envoyé: Samedi 18 Avril 2015 13:38:31 > Objet: Re: [CMake] Don't download external projects again aft

Re: [CMake] Don't download external projects again after calling "make clean"

I have just tried to install curl to get https support. To do that, I have followed the steps below: 1. Installation of openssl: 1.a. ./config --prefix=/my/openssl/path 1.b. make 1.c. make test 1.d. make install 2. Installation of curl 2.a. ./configure --prefix=/my/curl/path --with-ssl=

Re: [CMake] Don't download external projects again after calling "make clean"

Hello David, thank you very much. Unfortunately, I get the following error message if I remove my download command: -- downloading... src='http://bitbucket.org/eigen/eigen/get/3.2.4.tar.gz' dst='/home/cdoucet/Downloads/eigen/download/3.2.4.tar.gz' timeout='none' -- [download 100%

Re: [CMake] cmp0026, file(GENERATE...), and configure_file

Alan W. Irwin wrote: > So is it recommended that a two-step procedure be used to configure > a file? For example: Yes, that seems to be a valid thing to do. > If the above complications for configured files are the only way to > deal with a mixture of @...@ items and generator expressions to >

Re: [CMake] ExternalProject can't have interface library as a dependency

Andrey Pokrovskiy wrote: > /* I'm using cmake-3.2.20150331-gb190c. */ > > I have a following construction: > > ExternalProject_Add( > websockets_ep > DEPENDS ev openssl > ...) > > But it so happened, that "openssl" is a INTERFACE library. That sounds odd. What provides

Re: [CMake] Strange behaviour of STREQUAL with a variable containing only "type"

Nils Gladitz wrote: > It is expected if "type" itself is a variable (set by some module > evaluated by project()). Indeed we should probably clean up after ourselves (in the project() implementation) when using such generic names... Thanks, Steve. -- Powered by www.kitware.com Please keep