From Anjaneyulu.Korapu-contr at trw.com Mon Dec 1 08:56:41 2014 From: Anjaneyulu.Korapu-contr at trw.com (Anjaneyulu Korapu-contr) Date: Mon, 1 Dec 2014 13:56:41 +0000 Subject: [CMake] How to provide Common properties to all sub projects in Visual studio using CMake Message-ID: Hello All, I would like to know , How to provide Common properties to all sub projects in Visual studio using CMake? Basically I would like to put all properties in a file and attach them to sub projects using CMake. Thanks Anji -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill at classdesign.com Mon Dec 1 10:50:50 2014 From: bill at classdesign.com (Bill Somerville) Date: Mon, 01 Dec 2014 15:50:50 +0000 Subject: [CMake] 3.1 can't link my MinGW executables any more. In-Reply-To: <5479B5E2.7080807@classdesign.com> References: <5479B4E9.3010203@classdesign.com> <5479B5E2.7080807@classdesign.com> Message-ID: <547C8E5A.4020103@classdesign.com> On 29/11/2014 12:02, Bill Somerville wrote: > On 29/11/2014 11:58, Bill Somerville wrote: >> Hi, >> >> I have just tried 3.1.0-rc2 and my executable links are failing >> because all the link libraries are not being added. >> >> I use: >> >> add_executable (jt65code lib/jt65code.f90 wsjtx.rc) >> target_link_libraries (jt65code wsjt) >> >> where wsjt is a static library target with Fortran and C functions. >> This normally gives a link edit step of: >> >> C:\Tools\Qt\Tools\mingw48_32\bin\g++.exe -Wall -Wextra -std=c++11 >> -fexceptions -frtti -pthread -g -Wl,--whole-archive >> CMakeFiles\jt65code.dir/objects.a -Wl,--no-whole-archive -o >> jt65code.exe -Wl,--out-implib,libjt65code.dll.a >> -Wl,--major-image-version,0,--minor-image-version,0 libwsjt.a >> -lgfortran -lquadmath -lm -lkernel32 -luser32 -lgdi32 -lwinspool >> -lshell32 -lole32 -loleaut32 -luuid -lcomdlg32 -ladvapi32 >> >> but in 3.1.0-rc2 I get: >> >> C:\Tools\Qt\Tools\mingw48_32\bin\ar.exe cr >> CMakeFiles\jt65code.dir/objects.a @CMakeFiles\jt65code.dir\objects1.rsp >> C:\Tools\Qt\Tools\mingw48_32\bin\g++.exe -Wall -Wextra -std=c++11 >> -fexceptions -frtti -pthread -g -Wl,--whole-archive >> CMakeFiles\jt65code.dir/objects.a -Wl,--no-whole-archive -o >> jt65code.exe -Wl,--out-implib,libjt65code.dll.a >> -Wl,--major-image-version,0,--minor-image-version,0 >> @CMakeFiles\jt65code.dir\linklibs.rsp >> >> So it looks like the linklibs.rsp response file doesn't have the >> required entries. >> >> Looking at the build tree I find a linklibs.rsp in the top level >> directory (CMakeFIles/jt65code.dir) with the correct entries but the >> link edit command is passing a file in the subordinate 'lib' >> directory that doesn't exist. Something wrong with the use of a >> source in a subdirectory perhaps? > Sorry, I am talking rubbish here! > > So something is wrong with the response file itself, here it is: > > libwsjt.a -lquadmath -lm -lkernel32 -luser32 -lgdi32 -lwinspool > -lshell32 -lole32 -loleaut32 -luuid -lcomdlg32 -ladvapi32 > > and the problem is in fact that -lgfortran is missing! No ideas? Is mixed language support in v3.1 no longer supporting Fortran? Should I be asking somewhere else? >> >> Regards >> Bill Somerville. > Regards > Bill Somerville. Regards Bill Somerville. From brad.king at kitware.com Mon Dec 1 11:33:21 2014 From: brad.king at kitware.com (Brad King) Date: Mon, 01 Dec 2014 11:33:21 -0500 Subject: [CMake] 3.1 can't link my MinGW executables any more. In-Reply-To: <5479B4E9.3010203@classdesign.com> References: <5479B4E9.3010203@classdesign.com> Message-ID: <547C9851.3050704@kitware.com> On 11/29/2014 06:58 AM, Bill Somerville wrote: > -lgfortran -lquadmath -lm -lkernel32 -luser32 -lgdi32 -lwinspool > -lshell32 -lole32 -loleaut32 -luuid -lcomdlg32 -ladvapi32 > > but in 3.1.0-rc2 I get: > > -lquadmath -lm -lkernel32 -luser32 -lgdi32 -lwinspool > -lshell32 -lole32 -loleaut32 -luuid -lcomdlg32 -ladvapi32 The missing -lgfortran may be due to a failure to detect the implicit libraries linked by the gfortran front-end. Compare these files: CMakeFiles/3.0.2/CMakeFortranCompiler.cmake CMakeFiles/3.1.0-rc2/CMakeFortranCompiler.cmake In particular check the values of CMAKE_Fortran_IMPLICIT_LINK_LIBRARIES CMAKE_Fortran_IMPLICIT_LINK_DIRECTORIES recorded in the two files. Check CMakeFiles/CMakeOutput.log and/or CMakeFiles/CMakeError.log for information about how the values were extracted. Something here may have changed in 3.1. Thanks, -Brad From bill at classdesign.com Mon Dec 1 12:04:57 2014 From: bill at classdesign.com (Bill Somerville) Date: Mon, 01 Dec 2014 17:04:57 +0000 Subject: [CMake] 3.1 can't link my MinGW executables any more. In-Reply-To: <547C9851.3050704@kitware.com> References: <5479B4E9.3010203@classdesign.com> <547C9851.3050704@kitware.com> Message-ID: <547C9FB9.3010401@classdesign.com> On 01/12/2014 16:33, Brad King wrote: Hi Brad, > On 11/29/2014 06:58 AM, Bill Somerville wrote: >> -lgfortran -lquadmath -lm -lkernel32 -luser32 -lgdi32 -lwinspool >> -lshell32 -lole32 -loleaut32 -luuid -lcomdlg32 -ladvapi32 >> >> but in 3.1.0-rc2 I get: >> >> -lquadmath -lm -lkernel32 -luser32 -lgdi32 -lwinspool >> -lshell32 -lole32 -loleaut32 -luuid -lcomdlg32 -ladvapi32 > The missing -lgfortran may be due to a failure to detect the implicit > libraries linked by the gfortran front-end. Compare these files: > > CMakeFiles/3.0.2/CMakeFortranCompiler.cmake > CMakeFiles/3.1.0-rc2/CMakeFortranCompiler.cmake > > In particular check the values of > > CMAKE_Fortran_IMPLICIT_LINK_LIBRARIES > CMAKE_Fortran_IMPLICIT_LINK_DIRECTORIES > > recorded in the two files. Check CMakeFiles/CMakeOutput.log and/or > CMakeFiles/CMakeError.log for information about how the values were > extracted. Something here may have changed in 3.1. An initial scan of the CMakeFiles/CMakeOutput.log for the same project between 3.0.2 and 3.1.0-rc2 shows huge differences and I can't see any obvious single cause of the issue. Here are the two files FWIW: https://dl.dropboxusercontent.com/u/4192709/CMakeOutput.log.3.0.2 https://dl.dropboxusercontent.com/u/4192709/CMakeOutput.log.3.1.0-rc2 One thing that looks suspicious are the lines mapping words to content along the lines of : arg [-lmingw32] ==> lib [mingw32] arg [-lgcc] ==> lib [gcc] arg [-lgcc_eh] ==> lib [gcc_eh] which in 3.1 look like this: arg [-lmingw32] ==> lib [] arg [-lgcc] ==> lib [] arg [-lgcc_eh] ==> lib [] I'm not sure where they are generated. > > Thanks, > -Brad > 73 Bill G4WJS. From bill at classdesign.com Mon Dec 1 12:12:30 2014 From: bill at classdesign.com (Bill Somerville) Date: Mon, 01 Dec 2014 17:12:30 +0000 Subject: [CMake] 3.1 can't link my MinGW executables any more. In-Reply-To: <547C9FB9.3010401@classdesign.com> References: <5479B4E9.3010203@classdesign.com> <547C9851.3050704@kitware.com> <547C9FB9.3010401@classdesign.com> Message-ID: <547CA17E.2070206@classdesign.com> On 01/12/2014 17:04, Bill Somerville wrote: > On 01/12/2014 16:33, Brad King wrote: > > Hi Brad, >> On 11/29/2014 06:58 AM, Bill Somerville wrote: >>> -lgfortran -lquadmath -lm -lkernel32 -luser32 -lgdi32 -lwinspool >>> -lshell32 -lole32 -loleaut32 -luuid -lcomdlg32 -ladvapi32 >>> >>> but in 3.1.0-rc2 I get: >>> >>> -lquadmath -lm -lkernel32 -luser32 -lgdi32 -lwinspool >>> -lshell32 -lole32 -loleaut32 -luuid -lcomdlg32 -ladvapi32 >> The missing -lgfortran may be due to a failure to detect the implicit >> libraries linked by the gfortran front-end. Compare these files: >> >> CMakeFiles/3.0.2/CMakeFortranCompiler.cmake >> CMakeFiles/3.1.0-rc2/CMakeFortranCompiler.cmake >> >> In particular check the values of >> >> CMAKE_Fortran_IMPLICIT_LINK_LIBRARIES >> CMAKE_Fortran_IMPLICIT_LINK_DIRECTORIES >> >> recorded in the two files. Check CMakeFiles/CMakeOutput.log and/or >> CMakeFiles/CMakeError.log for information about how the values were >> extracted. Something here may have changed in 3.1. > An initial scan of the CMakeFiles/CMakeOutput.log for the same project > between 3.0.2 and 3.1.0-rc2 shows huge differences and I can't see any > obvious single cause of the issue. Here are the two files FWIW: > > https://dl.dropboxusercontent.com/u/4192709/CMakeOutput.log.3.0.2 > > https://dl.dropboxusercontent.com/u/4192709/CMakeOutput.log.3.1.0-rc2 > > One thing that looks suspicious are the lines mapping words to content > along the lines of : > > arg [-lmingw32] ==> lib [mingw32] > arg [-lgcc] ==> lib [gcc] > arg [-lgcc_eh] ==> lib [gcc_eh] > > which in 3.1 look like this: > > arg [-lmingw32] ==> lib [] > arg [-lgcc] ==> lib [] > arg [-lgcc_eh] ==> lib [] > > I'm not sure where they are generated. An extra data point, the configure phase appears to work but I've just noticed this: -- Verifying Fortran/CXX Compiler Compatibility - Failed because the link test there fails for the same reason - missing Fortran library. That one had slipped under the net since the configure pass carried on running finders after that message. >> >> Thanks, >> -Brad >> > 73 > Bill > G4WJS. Regards Bill Somerville. From bill at classdesign.com Mon Dec 1 12:20:33 2014 From: bill at classdesign.com (Bill Somerville) Date: Mon, 01 Dec 2014 17:20:33 +0000 Subject: [CMake] 3.1 can't link my MinGW executables any more. In-Reply-To: <547CA17E.2070206@classdesign.com> References: <5479B4E9.3010203@classdesign.com> <547C9851.3050704@kitware.com> <547C9FB9.3010401@classdesign.com> <547CA17E.2070206@classdesign.com> Message-ID: <547CA361.3020607@classdesign.com> On 01/12/2014 17:12, Bill Somerville wrote: > On 01/12/2014 17:04, Bill Somerville wrote: >> On 01/12/2014 16:33, Brad King wrote: >> >> Hi Brad, >>> On 11/29/2014 06:58 AM, Bill Somerville wrote: >>>> -lgfortran -lquadmath -lm -lkernel32 -luser32 -lgdi32 -lwinspool >>>> -lshell32 -lole32 -loleaut32 -luuid -lcomdlg32 -ladvapi32 >>>> >>>> but in 3.1.0-rc2 I get: >>>> >>>> -lquadmath -lm -lkernel32 -luser32 -lgdi32 -lwinspool >>>> -lshell32 -lole32 -loleaut32 -luuid -lcomdlg32 -ladvapi32 >>> The missing -lgfortran may be due to a failure to detect the implicit >>> libraries linked by the gfortran front-end. Compare these files: >>> >>> CMakeFiles/3.0.2/CMakeFortranCompiler.cmake >>> CMakeFiles/3.1.0-rc2/CMakeFortranCompiler.cmake >>> >>> In particular check the values of >>> >>> CMAKE_Fortran_IMPLICIT_LINK_LIBRARIES >>> CMAKE_Fortran_IMPLICIT_LINK_DIRECTORIES Forgot to mention that this the case, here are the files: https://dl.dropboxusercontent.com/u/4192709/CMakeFortranCompiler.cmake.3.0.2 https://dl.dropboxusercontent.com/u/4192709/CMakeFortranCompiler.cmake.3.1.0-rc2 >>> >>> recorded in the two files. Check CMakeFiles/CMakeOutput.log and/or >>> CMakeFiles/CMakeError.log for information about how the values were >>> extracted. Something here may have changed in 3.1. >> An initial scan of the CMakeFiles/CMakeOutput.log for the same >> project between 3.0.2 and 3.1.0-rc2 shows huge differences and I >> can't see any obvious single cause of the issue. Here are the two >> files FWIW: >> >> https://dl.dropboxusercontent.com/u/4192709/CMakeOutput.log.3.0.2 >> >> https://dl.dropboxusercontent.com/u/4192709/CMakeOutput.log.3.1.0-rc2 >> >> One thing that looks suspicious are the lines mapping words to >> content along the lines of : >> >> arg [-lmingw32] ==> lib [mingw32] >> arg [-lgcc] ==> lib [gcc] >> arg [-lgcc_eh] ==> lib [gcc_eh] >> >> which in 3.1 look like this: >> >> arg [-lmingw32] ==> lib [] >> arg [-lgcc] ==> lib [] >> arg [-lgcc_eh] ==> lib [] >> >> I'm not sure where they are generated. > An extra data point, the configure phase appears to work but I've just > noticed this: > > -- Verifying Fortran/CXX Compiler Compatibility - Failed > > because the link test there fails for the same reason - missing > Fortran library. That one had slipped under the net since the > configure pass carried on running finders after that message. >>> >>> Thanks, >>> -Brad >>> >> 73 >> Bill >> G4WJS. > Regards > Bill Somerville. From bill at classdesign.com Mon Dec 1 13:37:04 2014 From: bill at classdesign.com (Bill Somerville) Date: Mon, 01 Dec 2014 18:37:04 +0000 Subject: [CMake] 3.1 can't link my MinGW executables any more. In-Reply-To: <547CA361.3020607@classdesign.com> References: <5479B4E9.3010203@classdesign.com> <547C9851.3050704@kitware.com> <547C9FB9.3010401@classdesign.com> <547CA17E.2070206@classdesign.com> <547CA361.3020607@classdesign.com> Message-ID: <547CB550.8040303@classdesign.com> I'm trying to debug this issue but the 3.1.0-rc2 use of linker response files is a PITA because they are created as temporary files and gone before I can look into them. Is there for flag I can set to stop them being used so I can see the whole link line? Regards Bill Somerville. From brad.king at kitware.com Mon Dec 1 13:55:29 2014 From: brad.king at kitware.com (Brad King) Date: Mon, 01 Dec 2014 13:55:29 -0500 Subject: [CMake] 3.1 can't link my MinGW executables any more. In-Reply-To: <547C9FB9.3010401@classdesign.com> References: <5479B4E9.3010203@classdesign.com> <547C9851.3050704@kitware.com> <547C9FB9.3010401@classdesign.com> Message-ID: <547CB9A1.6000700@kitware.com> On 12/01/2014 12:04 PM, Bill Somerville wrote: > https://dl.dropboxusercontent.com/u/4192709/CMakeOutput.log.3.0.2 > https://dl.dropboxusercontent.com/u/4192709/CMakeOutput.log.3.1.0-rc2 The relevant portion of these logs starts in the line Detecting Fortran compiler ABI info compiled with the following output: Below that we see CMake's log of the command it invoked in 3.0: C:\Tools\Qt\Tools\mingw48_32\bin\gfortran.exe ... versus 3.1: C:\Tools\Qt\Tools\mingw48_32\bin\gfortran.exe ... @CMakeFiles\cmTryCompileExec3596737510.dir\linklibs.rsp The response file will be empty in this case. This difference comes from the topic merged here: Merge topic 'link-libraries-response-files' http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7c9041bd The next line in both logs is printed by the gfortran tool and is identical: Driving: C:\Tools\Qt\Tools\mingw48_32\bin\gfortran.exe -v ... -l gfortran -shared-libgcc This means the gfortran front-end's invocation of its internal compiler to do the linking is identical in the two cases. However, later the logs show different lines, both starting with c:/tools/qt/tools/mingw48_32/bin/../libexec/gcc/i686-w64-mingw32/4.8.0/collect2.exe In 3.0 it has the form: .../collect2.exe ... --whole-archive CMakeFiles\cmTryCompileExec480971319.dir/objects.a --no-whole-archive --out-implib libcmTryCompileExec480971319.dll.a --major-image-version 0 --minor-image-version 0 -lgfortran ... and in 3.1 it has the form: .../collect2.exe ... @C:\Users\bill\AppData\Local\Temp\cc7mMWSg ... where the '...' parts are the same in both logs. Something causes gfortran to decide to put all those arguments in a response file. They are hidden from CMake so the -lgfortran part cannot be extracted. Somehow using a response file on the initial command line causes gfortran to use one for its internal invocation. This is reasonable behavior because if the original caller had a long command line then so might the internal invocation. I've created the following workaround: Makefile: Do not create an empty linker response file http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=1c5be1f3 Please let me know if that works for you. > One thing that looks suspicious are the lines mapping words to content > along the lines of : > > arg [-lmingw32] ==> lib [mingw32] > arg [-lgcc] ==> lib [gcc] > arg [-lgcc_eh] ==> lib [gcc_eh] > > which in 3.1 look like this: > > arg [-lmingw32] ==> lib [] > arg [-lgcc] ==> lib [] > arg [-lgcc_eh] ==> lib [] > > I'm not sure where they are generated. That looks like a regression only in construction of the log messages. I've fixed that here: CMakeParseImplicitLinkInfo: Fix implicit library logging http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=20bf6971 and will include it in the next 3.1 release candidate. Thanks, -Brad From brad.king at kitware.com Mon Dec 1 13:59:03 2014 From: brad.king at kitware.com (Brad King) Date: Mon, 01 Dec 2014 13:59:03 -0500 Subject: [CMake] 3.1 can't link my MinGW executables any more. In-Reply-To: <547CB550.8040303@classdesign.com> References: <5479B4E9.3010203@classdesign.com> <547C9851.3050704@kitware.com> <547C9FB9.3010401@classdesign.com> <547CA17E.2070206@classdesign.com> <547CA361.3020607@classdesign.com> <547CB550.8040303@classdesign.com> Message-ID: <547CBA77.4060806@kitware.com> On 12/01/2014 01:37 PM, Bill Somerville wrote: > I'm trying to debug this issue but the 3.1.0-rc2 use of linker response > files is a PITA because they are created as temporary files and gone > before I can look into them. > > Is there for flag I can set to stop them being used so I can see the > whole link line? There are two sources of response files involved. One is generated by CMake (linklibs.rsp), and the other is generated by gfortran. The former is persistent, the latter is temporary and CMake can do nothing about it. However, in this particular case the ABI detection build is done in a temporary directory and wiped out when finished, just like most other try_compile calls. Therefore even the files holding flags not in response files are gone too. In order to keep them around one may use --debug-trycompile, but it is a bit tricky to do because some of the files will still be overwritten by checks after the one in question. Anyway, see my sibling response for an explanation of the underlying problem and the fix. Thanks, -Brad From eike at sf-mail.de Mon Dec 1 14:52:02 2014 From: eike at sf-mail.de (Rolf Eike Beer) Date: Mon, 01 Dec 2014 20:52:02 +0100 Subject: [CMake] 3.1 can't link my MinGW executables any more. In-Reply-To: <547CB9A1.6000700@kitware.com> References: <5479B4E9.3010203@classdesign.com> <547C9FB9.3010401@classdesign.com> <547CB9A1.6000700@kitware.com> Message-ID: <1963867.JA6dRAkyQD@eto> Brad King wrote: > On 12/01/2014 12:04 PM, Bill Somerville wrote: > > One thing that looks suspicious are the lines mapping words to content > > > > along the lines of : > > arg [-lmingw32] ==> lib [mingw32] > > arg [-lgcc] ==> lib [gcc] > > arg [-lgcc_eh] ==> lib [gcc_eh] > > > > which in 3.1 look like this: > > arg [-lmingw32] ==> lib [] > > arg [-lgcc] ==> lib [] > > arg [-lgcc_eh] ==> lib [] > > > > I'm not sure where they are generated. > > That looks like a regression only in construction of the log messages. > I've fixed that here: > > CMakeParseImplicitLinkInfo: Fix implicit library logging > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=20bf6971 > > and will include it in the next 3.1 release candidate. Can't CMAKE_MATCH_1 be used twice? Otherwise the "lib" variable should explicitely be unset, the name is much too generic to not be reused by someone perhaps wondering about the content already in there. Eike -- From d3ck0r at gmail.com Tue Dec 2 03:53:37 2014 From: d3ck0r at gmail.com (J Decker) Date: Tue, 2 Dec 2014 00:53:37 -0800 Subject: [CMake] This used to work... Message-ID: MinGW Makefile generator... (yes ${target} is blank... it should be 'a') ------- cmake_minimum_required(VERSION 2.8) add_library( a main.c ) set( MOREDEFS "TARGETNAME=\"${target}\" TARGET_LABEL=${TARGET_LABEL}" ) SET_PROPERTY(TARGET a APPEND PROPERTY COMPILE_DEFINITIONS ${MOREDEFS} ) # this used to be more like... but simplified the quotes... SET_PROPERTY(TARGET a APPEND PROPERTY COMPILE_DEFINITIONS "TARGET_LABEL=${TARGET_LABEL};${MOREDEFS}" ) ---- [100%] Building C object CMakeFiles/a.dir/main.c.obj c:\tools\unix\MinGW\bin\gcc.exe -DTARGETNAME="\"\" TARGET_LABEL=" -o CMakeFiles\a.dir\main.c.obj -c M:\tmp\mingw\cmake\main.c -------- the quoting on the parameters is wrong... -DTARGETNAME="\"\" TARGET_LABEL=" -------------- next part -------------- An HTML attachment was scrubbed... URL: From foss at grueninger.de Tue Dec 2 05:59:29 2014 From: foss at grueninger.de (=?UTF-8?Q?Christoph_Gr=C3=BCninger?=) Date: Tue, 2 Dec 2014 11:59:29 +0100 (CET) Subject: [CMake] CTest errors out when skipping a test Message-ID: <2010610472.374564.1417517969333.JavaMail.open-xchange@omgreatgod.store> Hi CMake, I am testing the SKIP_RETURN_CODE property for tests. Unfortunately ctest error out when it found skipped tests. I expect ctest to not fail, because skipped tests should be indicated, but are to some extend expected and should still leave ctest passing. Is this a bug? Or do I misunderstand the way CTest considers skipped tests? Thanks Christoph == Test output == [..] Start 24: dtest 24/48 Test #24: dtest .......***Skipped 0.00 sec Start 25: etest 25/48 Test #25: etest ............................ Passed 0.00 sec [..] 92% tests passed, 4 tests failed out of 48 Total Test time (real) = 4.50 sec The following tests FAILED: 3 - atest (Not Run) 4 - btest (Not Run) 5 - ctest (Not Run) 24 - dtest (Not Run) Errors while running CTest make: *** [test] Error 8 From Georg.Altmann at informatik.stud.uni-erlangen.de Tue Dec 2 06:28:41 2014 From: Georg.Altmann at informatik.stud.uni-erlangen.de (Georg Altmann) Date: Tue, 02 Dec 2014 12:28:41 +0100 Subject: [CMake] Nvidia nsight (eclipse cdt) error parsing Message-ID: Hi, I am using CMake for generating a project file for nvidia nsight to edit CUDA sources. $ mkdir myproj-build && cd myproj-build $ cmake -G"Eclipse CDT4 - Unix Makefiles" ../myproj The problem is, eclipse won't recognize the compiler errors output by nvcc. I enabled the "nvcc error parser" in "project->properties->C/C++ Make Project->Error Parsers" and moved it to the top of the list. Error parsing works fine for "native" nsight CUDA projects and for non-CUDA/non-nvcc c++ cmake generated projects. Is this a known issue? Anybody have a fix? System: Linux Ubuntu 14.04.1 LTS x64 Tested cmake versions: cmake version 2.8.12.2 (Ubuntu 14.04.1 LTS) cmake version 3.1.0-rc2 (built from source) Nsight Eclipse Edition 6.5 Eclipse C/C++ Development Tools Version: 8.1.2.nvidia-qualifier Regards Georg From bill at classdesign.com Tue Dec 2 09:30:48 2014 From: bill at classdesign.com (Bill Somerville) Date: Tue, 02 Dec 2014 14:30:48 +0000 Subject: [CMake] 3.1 can't link my MinGW executables any more. In-Reply-To: <547CB9A1.6000700@kitware.com> References: <5479B4E9.3010203@classdesign.com> <547C9851.3050704@kitware.com> <547C9FB9.3010401@classdesign.com> <547CB9A1.6000700@kitware.com> Message-ID: <547DCD18.40104@classdesign.com> On 01/12/2014 18:55, Brad King wrote: Hi Brad, thanks for the quick response on this one. > On 12/01/2014 12:04 PM, Bill Somerville wrote: >> https://dl.dropboxusercontent.com/u/4192709/CMakeOutput.log.3.0.2 >> https://dl.dropboxusercontent.com/u/4192709/CMakeOutput.log.3.1.0-rc2 > The relevant portion of these logs starts in the line > > Detecting Fortran compiler ABI info compiled with the following output: > > Below that we see CMake's log of the command it invoked in 3.0: > > C:\Tools\Qt\Tools\mingw48_32\bin\gfortran.exe ... > > versus 3.1: > > C:\Tools\Qt\Tools\mingw48_32\bin\gfortran.exe ... @CMakeFiles\cmTryCompileExec3596737510.dir\linklibs.rsp > > The response file will be empty in this case. This difference comes from > the topic merged here: > > Merge topic 'link-libraries-response-files' > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7c9041bd > > The next line in both logs is printed by the gfortran tool and is identical: > > Driving: C:\Tools\Qt\Tools\mingw48_32\bin\gfortran.exe -v ... -l gfortran -shared-libgcc > > This means the gfortran front-end's invocation of its internal compiler > to do the linking is identical in the two cases. However, later the logs > show different lines, both starting with > > c:/tools/qt/tools/mingw48_32/bin/../libexec/gcc/i686-w64-mingw32/4.8.0/collect2.exe > > In 3.0 it has the form: > > .../collect2.exe ... --whole-archive CMakeFiles\cmTryCompileExec480971319.dir/objects.a > --no-whole-archive --out-implib libcmTryCompileExec480971319.dll.a > --major-image-version 0 --minor-image-version 0 -lgfortran ... > > and in 3.1 it has the form: > > .../collect2.exe ... @C:\Users\bill\AppData\Local\Temp\cc7mMWSg ... > > where the '...' parts are the same in both logs. Something causes gfortran to > decide to put all those arguments in a response file. They are hidden from > CMake so the -lgfortran part cannot be extracted. Somehow using a response > file on the initial command line causes gfortran to use one for its internal > invocation. This is reasonable behavior because if the original caller had > a long command line then so might the internal invocation. > > I've created the following workaround: > > Makefile: Do not create an empty linker response file > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=1c5be1f3 > > Please let me know if that works for you. Ran with last nights snapshot dev binary build and it all seems to be fine now. I did have to fix a Qt cmake file error where COPY_ONLY rather than COPYONLY was used in a configure_file() command, this will probably hit quite a few users. I hope the qt-project.org team have been given a heads up on this tightening up of arguments. > >> One thing that looks suspicious are the lines mapping words to content >> along the lines of : >> >> arg [-lmingw32] ==> lib [mingw32] >> arg [-lgcc] ==> lib [gcc] >> arg [-lgcc_eh] ==> lib [gcc_eh] >> >> which in 3.1 look like this: >> >> arg [-lmingw32] ==> lib [] >> arg [-lgcc] ==> lib [] >> arg [-lgcc_eh] ==> lib [] >> >> I'm not sure where they are generated. > That looks like a regression only in construction of the log messages. > I've fixed that here: > > CMakeParseImplicitLinkInfo: Fix implicit library logging > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=20bf6971 > > and will include it in the next 3.1 release candidate. This also looks good in the log now. > > Thanks, > -Brad > Thanks Bill SOmerville. From brad.king at kitware.com Tue Dec 2 09:35:35 2014 From: brad.king at kitware.com (Brad King) Date: Tue, 02 Dec 2014 09:35:35 -0500 Subject: [CMake] 3.1 can't link my MinGW executables any more. In-Reply-To: <547DCD18.40104@classdesign.com> References: <5479B4E9.3010203@classdesign.com> <547C9851.3050704@kitware.com> <547C9FB9.3010401@classdesign.com> <547CB9A1.6000700@kitware.com> <547DCD18.40104@classdesign.com> Message-ID: <547DCE37.4000701@kitware.com> On 12/02/2014 09:30 AM, Bill Somerville wrote: > Ran with last nights snapshot dev binary build and it all seems to be > fine now. Great, thanks for testing. -Brad From cxjohnson at gmail.com Tue Dec 2 12:01:05 2014 From: cxjohnson at gmail.com (Chris Johnson) Date: Tue, 2 Dec 2014 11:01:05 -0600 Subject: [CMake] How to set path to library header files? Message-ID: Background: I'm converting an existing project from a custom build process which uses BSD Make to CMake. The source for the project is contained in about 600 directories, and has about a dozen libraries and maybe a hundred executables. The old build system (make) has to continue working until the new CMake-based system is fully operational and tested. For the most part, this has been straight forward and easy, since make is building in source using in-source Makefiles. I've simply added a CMakeLists.txt file to each directory, and the actual CMake build occurs out-of-source. It's only the edge cases (of course!) which have given me a headache. I've solved some of them. This message is about one I have not yet been able to solve. The basic problem is this: my executables cannot find the header files for some of the libraries, because they are in a subdirectory when installed, but are not in a subdirectory while in source. Here's a simplified example (SSCCE) which reproduces this problem. The file structure: . |-- bin/ |-- include/ | `-- mylib/ |-- lib/ `-- src/ |-- CMakeLists.txt |-- mylib/ | |-- CMakeLists.txt | |-- myfunc.cpp | `-- myfunc.h `-- prog/ |-- CMakeLists.txt `-- prog.cpp The top-level bin, include and lib directories are the install locations, exactly parallel to standard Unix locations. Note that file myfunc.h installs into ./include/mylib. Note also that prog.cpp includes this header via #include "myfunc.h". Here are the current CMakeLists.txt files. Top level (../src): cmake_minimum_required(VERSION 2.8.4) project(src) add_subdirectory(mylib) add_subdirectory(prog) mylib: cmake_minimum_required(VERSION 2.8.4) project(mylib) set(CPP_SOURCE myfunc.cpp) set(HEADERS myfunc.h) add_library(mylib ${CPP_SOURCE} ) target_include_directories( mylib PUBLIC # Headers used from source/build location: "$" # Headers used from the installed location: "$" ) install(TARGETS mylib DESTINATION lib) install(FILES ${HEADERS} DESTINATION include/mylib) prog: cmake_minimum_required(VERSION 2.8.4) project(prog) set(SOURCE_FILES prog.cpp) set(LIBS mylib) add_executable(prog ${SOURCE_FILES}) target_link_libraries(prog ${LIBS}) install(TARGETS prog DESTINATION bin) When I build, I get this error: src/.build$ make install -- Configuring done -- Generating done -- Build files have been written to: /sandbox/src/.build Scanning dependencies of target mylib [ 50%] Building CXX object mylib/CMakeFiles/mylib.dir/myfunc.cpp.o Linking CXX static library libmylib.a [ 50%] Built target mylib Scanning dependencies of target prog [100%] Building CXX object prog/CMakeFiles/prog.dir/prog.cpp.o /sandbox/src/prog/prog.cpp:1:10: fatal error: 'mylib/myfunc.h' file not found #include "mylib/myfunc.h" ^ 1 error generated. make[2]: *** [prog/CMakeFiles/prog.dir/prog.cpp.o] Error 1 make[1]: *** [prog/CMakeFiles/prog.dir/all] Error 2 make: *** [all] Error 2 How can I create CMake rules that will allow me to work around this? As I mentioned above, the existing make-based build has to continue working, so I cannot change the #include statement to remove the subdirectory path. ..chris -------------- next part -------------- An HTML attachment was scrubbed... URL: From cxjohnson at gmail.com Tue Dec 2 12:03:48 2014 From: cxjohnson at gmail.com (Chris Johnson) Date: Tue, 2 Dec 2014 11:03:48 -0600 Subject: [CMake] How to set path to library header files? In-Reply-To: References: Message-ID: Ah, and I royally typo'd: prog.cpp includes the header via: #include "mylib/myfunc.h" (not just "myfunc.h") On Tue, Dec 2, 2014 at 11:01 AM, Chris Johnson wrote: > Background: I'm converting an existing project from a custom build > process which uses BSD Make to CMake. The source for the project is > contained in about 600 directories, and has about a dozen libraries and > maybe a hundred executables. The old build system (make) has to continue > working until the new CMake-based system is fully operational and tested. > For the most part, this has been straight forward and easy, since make is > building in source using in-source Makefiles. I've simply added a > CMakeLists.txt file to each directory, and the actual CMake build occurs > out-of-source. It's only the edge cases (of course!) which have given me a > headache. I've solved some of them. This message is about one I have not > yet been able to solve. > > The basic problem is this: my executables cannot find the header files > for some of the libraries, because they are in a subdirectory when > installed, but are not in a subdirectory while in source. > > Here's a simplified example (SSCCE) which reproduces this problem. > > The file structure: > . > |-- bin/ > |-- include/ > | `-- mylib/ > |-- lib/ > `-- src/ > |-- CMakeLists.txt > |-- mylib/ > | |-- CMakeLists.txt > | |-- myfunc.cpp > | `-- myfunc.h > `-- prog/ > |-- CMakeLists.txt > `-- prog.cpp > > The top-level bin, include and lib directories are the install locations, > exactly parallel to standard Unix locations. Note that file myfunc.h > installs into ./include/mylib. Note also that prog.cpp includes this > header via #include "myfunc.h". > > Here are the current CMakeLists.txt files. > > Top level (../src): > cmake_minimum_required(VERSION 2.8.4) > project(src) > add_subdirectory(mylib) > add_subdirectory(prog) > > mylib: > cmake_minimum_required(VERSION 2.8.4) > project(mylib) > > set(CPP_SOURCE myfunc.cpp) > set(HEADERS myfunc.h) > > add_library(mylib ${CPP_SOURCE} ) > > target_include_directories( > mylib PUBLIC > # Headers used from source/build location: > "$" > # Headers used from the installed location: > "$" > ) > > install(TARGETS mylib DESTINATION lib) > install(FILES ${HEADERS} DESTINATION include/mylib) > > prog: > cmake_minimum_required(VERSION 2.8.4) > project(prog) > > set(SOURCE_FILES prog.cpp) > > set(LIBS mylib) > > add_executable(prog ${SOURCE_FILES}) > target_link_libraries(prog ${LIBS}) > install(TARGETS prog DESTINATION bin) > > When I build, I get this error: > > src/.build$ make install > -- Configuring done > -- Generating done > -- Build files have been written to: /sandbox/src/.build > Scanning dependencies of target mylib > [ 50%] Building CXX object mylib/CMakeFiles/mylib.dir/myfunc.cpp.o > Linking CXX static library libmylib.a > [ 50%] Built target mylib > Scanning dependencies of target prog > [100%] Building CXX object prog/CMakeFiles/prog.dir/prog.cpp.o > /sandbox/src/prog/prog.cpp:1:10: fatal error: 'mylib/myfunc.h' > file not found > #include "mylib/myfunc.h" > ^ > 1 error generated. > make[2]: *** [prog/CMakeFiles/prog.dir/prog.cpp.o] Error 1 > make[1]: *** [prog/CMakeFiles/prog.dir/all] Error 2 > make: *** [all] Error 2 > > > How can I create CMake rules that will allow me to work around this? > > As I mentioned above, the existing make-based build has to continue > working, so I cannot change the #include statement to remove the > subdirectory path. > > ..chris > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cxjohnson at gmail.com Tue Dec 2 12:06:01 2014 From: cxjohnson at gmail.com (Chris Johnson) Date: Tue, 2 Dec 2014 11:06:01 -0600 Subject: [CMake] How to set path to library header files? In-Reply-To: References: Message-ID: Just for completeness. File prog/prog.cpp: #include "mylib/myfunc.h" int main(int argc, char** argv) { return myfunc(); } File mylib/myfunc.h: int myfunc(); And file mylib/myfunc.cpp: #include "myfunc.h" int myfunc() { return 1; } -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.hoffman at kitware.com Tue Dec 2 12:33:12 2014 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Tue, 02 Dec 2014 12:33:12 -0500 Subject: [CMake] How to set path to library header files? In-Reply-To: References: Message-ID: <547DF7D8.4060206@kitware.com> This should work: include_directories(${CMAKE_SOURCE_DIR}/src) On 12/2/2014 12:06 PM, Chris Johnson wrote: > Just for completeness. > > File prog/prog.cpp: > > #include "mylib/myfunc.h" > > int > main(int argc, char** argv) > { > return myfunc(); > } > > > File mylib/myfunc.h: > int myfunc(); > > > And file mylib/myfunc.cpp: > #include "myfunc.h" > > int > myfunc() > { > return 1; > } > > -- Bill Hoffman Kitware, Inc. 28 Corporate Drive Clifton Park, NY 12065 bill.hoffman at kitware.com http://www.kitware.com 518 881-4905 (Direct) 518 371-3971 x105 Fax (518) 371-4573 From MillerHenry at JohnDeere.com Tue Dec 2 12:07:28 2014 From: MillerHenry at JohnDeere.com (Miller Henry) Date: Tue, 2 Dec 2014 17:07:28 +0000 Subject: [CMake] How to set path to library header files? In-Reply-To: References: Message-ID: <35F6921410093E4CA40D524BD5C18D4C2681AE05@EDXMB57.jdnet.deere.com> You need to use include_directories to tell cmake where to find headers. include_directories(${CMAKE_SOURCE_DIR}/src) http://www.cmake.org/cmake/help/v3.0/command/include_directories.html http://www.cmake.org/cmake/help/v3.0/variable/CMAKE_SOURCE_DIR.html From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Chris Johnson Sent: Tuesday, December 02, 2014 11:04 AM To: cmake at cmake.org Subject: Re: [CMake] How to set path to library header files? Ah, and I royally typo'd: prog.cpp includes the header via: #include "mylib/myfunc.h" (not just "myfunc.h") On Tue, Dec 2, 2014 at 11:01 AM, Chris Johnson > wrote: Background: I'm converting an existing project from a custom build process which uses BSD Make to CMake. The source for the project is contained in about 600 directories, and has about a dozen libraries and maybe a hundred executables. The old build system (make) has to continue working until the new CMake-based system is fully operational and tested. For the most part, this has been straight forward and easy, since make is building in source using in-source Makefiles. I've simply added a CMakeLists.txt file to each directory, and the actual CMake build occurs out-of-source. It's only the edge cases (of course!) which have given me a headache. I've solved some of them. This message is about one I have not yet been able to solve. The basic problem is this: my executables cannot find the header files for some of the libraries, because they are in a subdirectory when installed, but are not in a subdirectory while in source. Here's a simplified example (SSCCE) which reproduces this problem. The file structure: . |-- bin/ |-- include/ | `-- mylib/ |-- lib/ `-- src/ |-- CMakeLists.txt |-- mylib/ | |-- CMakeLists.txt | |-- myfunc.cpp | `-- myfunc.h `-- prog/ |-- CMakeLists.txt `-- prog.cpp The top-level bin, include and lib directories are the install locations, exactly parallel to standard Unix locations. Note that file myfunc.h installs into ./include/mylib. Note also that prog.cpp includes this header via #include "myfunc.h". Here are the current CMakeLists.txt files. Top level (../src): cmake_minimum_required(VERSION 2.8.4) project(src) add_subdirectory(mylib) add_subdirectory(prog) mylib: cmake_minimum_required(VERSION 2.8.4) project(mylib) set(CPP_SOURCE myfunc.cpp) set(HEADERS myfunc.h) add_library(mylib ${CPP_SOURCE} ) target_include_directories( mylib PUBLIC # Headers used from source/build location: "$" # Headers used from the installed location: "$" ) install(TARGETS mylib DESTINATION lib) install(FILES ${HEADERS} DESTINATION include/mylib) prog: cmake_minimum_required(VERSION 2.8.4) project(prog) set(SOURCE_FILES prog.cpp) set(LIBS mylib) add_executable(prog ${SOURCE_FILES}) target_link_libraries(prog ${LIBS}) install(TARGETS prog DESTINATION bin) When I build, I get this error: src/.build$ make install -- Configuring done -- Generating done -- Build files have been written to: /sandbox/src/.build Scanning dependencies of target mylib [ 50%] Building CXX object mylib/CMakeFiles/mylib.dir/myfunc.cpp.o Linking CXX static library libmylib.a [ 50%] Built target mylib Scanning dependencies of target prog [100%] Building CXX object prog/CMakeFiles/prog.dir/prog.cpp.o /sandbox/src/prog/prog.cpp:1:10: fatal error: 'mylib/myfunc.h' file not found #include "mylib/myfunc.h" ^ 1 error generated. make[2]: *** [prog/CMakeFiles/prog.dir/prog.cpp.o] Error 1 make[1]: *** [prog/CMakeFiles/prog.dir/all] Error 2 make: *** [all] Error 2 How can I create CMake rules that will allow me to work around this? As I mentioned above, the existing make-based build has to continue working, so I cannot change the #include statement to remove the subdirectory path. ..chris -------------- next part -------------- An HTML attachment was scrubbed... URL: From cxjohnson at gmail.com Tue Dec 2 13:04:48 2014 From: cxjohnson at gmail.com (Chris Johnson) Date: Tue, 2 Dec 2014 12:04:48 -0600 Subject: [CMake] How to set path to library header files? In-Reply-To: <547DF7D8.4060206@kitware.com> References: <547DF7D8.4060206@kitware.com> Message-ID: Adding this directive does not seem to change the results at all, actually. Am I missing something?? Thanks, ..chris On Tue, Dec 2, 2014 at 11:33 AM, Bill Hoffman wrote: > This should work: > > include_directories(${CMAKE_SOURCE_DIR}/src) > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From angeliki.chrysochou at gmail.com Tue Dec 2 13:33:26 2014 From: angeliki.chrysochou at gmail.com (Angeliki Chrysochou) Date: Tue, 2 Dec 2014 19:33:26 +0100 Subject: [CMake] How to set path to library header files? In-Reply-To: References: <547DF7D8.4060206@kitware.com> Message-ID: Hi Chris, Given your file structure The file structure: . |-- bin/ |-- include/ | `-- mylib/ |-- lib/ `-- src/ |-- CMakeLists.txt |-- mylib/ | |-- CMakeLists.txt | |-- myfunc.cpp | `-- myfunc.h `-- prog/ |-- CMakeLists.txt `-- prog.cpp you should add in ./src/prog/CMakeLists.txt in include_directories the correct path to myfunc.h. Assuming CMAKE_SOURCE_DIR is "." (this is where your top level CMakeLists.txt is located): include_directories(${CMAKE_SOURCE_DIR}/src/mylib) Cheers! Angeliki On Tue, Dec 2, 2014 at 7:04 PM, Chris Johnson wrote: > Adding this directive does not seem to change the results at all, > actually. Am I missing something?? > > Thanks, > ..chris > > On Tue, Dec 2, 2014 at 11:33 AM, Bill Hoffman > wrote: > >> This should work: >> >> include_directories(${CMAKE_SOURCE_DIR}/src) >> >> > -- > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From DLRdave at aol.com Tue Dec 2 13:42:48 2014 From: DLRdave at aol.com (David Cole) Date: Tue, 2 Dec 2014 13:42:48 -0500 Subject: [CMake] How to set path to library header files? In-Reply-To: References: <547DF7D8.4060206@kitware.com> Message-ID: This chunk: target_include_directories( mylib PUBLIC # Headers used from source/build location: "$" # Headers used from the installed location: "$" ) uses CMAKE_CURRENT_SOURCE_DIR, which already ends with "/mylib". Don't you need to use the parent directory in order to include "mylib/..." ? Once you have that correct, the settings should propagate to the prog executable as well via your target_link_libraries call. D On Tue, Dec 2, 2014 at 1:04 PM, Chris Johnson wrote: > Adding this directive does not seem to change the results at all, actually. > Am I missing something? > > Thanks, > ..chris > > On Tue, Dec 2, 2014 at 11:33 AM, Bill Hoffman > wrote: >> >> This should work: >> >> include_directories(${CMAKE_SOURCE_DIR}/src) >> > > -- > > 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 From fifteenknots505 at gmail.com Tue Dec 2 13:58:53 2014 From: fifteenknots505 at gmail.com (Martin Weber) Date: Tue, 02 Dec 2014 19:58:53 +0100 Subject: [CMake] [ANNOUNCE] Please test staged cmake for eclipse CDT 1.3.0 Message-ID: <1748199.T0kXFcAlk0@linux> Hi all, I about to release a new version of the plugin for Eclipse CDT to integrate CMake. It should make setting up CDT to use cmake much easier. A short description can be found at the project home page The update site URL of the staged version is Any feedback is welcome, especially for OS X. Thanks, Martin -------- [1] https://code.google.com/p/cmake4eclipsecdt/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.hoffman at kitware.com Tue Dec 2 14:09:49 2014 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Tue, 02 Dec 2014 14:09:49 -0500 Subject: [CMake] How to set path to library header files? In-Reply-To: References: <547DF7D8.4060206@kitware.com> Message-ID: <547E0E7D.4040904@kitware.com> On 12/2/2014 1:33 PM, Angeliki Chrysochou wrote: > > you should add in ./src/prog/CMakeLists.txt in include_directories the > correct path to myfunc.h. Assuming CMAKE_SOURCE_DIR is "." (this is > where your top level CMakeLists.txt is located): > > include_directories(${CMAKE_SOURCE_DIR}/src/mylib) I don't think that will work. Two reasons: CMAKE_SOURCE_DIR is the top level source directory for the project, not the current one. Also, he wants to include the file like this: #include "mylib/myfunc.h" So, the include needs to go to src and not src/mylib. -Bill From bill.hoffman at kitware.com Tue Dec 2 14:10:48 2014 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Tue, 02 Dec 2014 14:10:48 -0500 Subject: [CMake] How to set path to library header files? In-Reply-To: References: <547DF7D8.4060206@kitware.com> Message-ID: <547E0EB8.2000100@kitware.com> On 12/2/2014 1:04 PM, Chris Johnson wrote: > Adding this directive does not seem to change the results at all, > actually. Am I missing something?? > What build tool are you using? Can you show a verbose compile line? Then check the -I paths. make VERBOSE=1 will do it for make. -Bill From angeliki.chrysochou at gmail.com Tue Dec 2 14:44:01 2014 From: angeliki.chrysochou at gmail.com (Angeliki Chrysochou) Date: Tue, 2 Dec 2014 20:44:01 +0100 Subject: [CMake] How to set path to library header files? In-Reply-To: <547E0E7D.4040904@kitware.com> References: <547DF7D8.4060206@kitware.com> <547E0E7D.4040904@kitware.com> Message-ID: Hi Bill, He wrote "Note also that prog.cpp includes this header via #include "myfunc.h"." in his first email, so I thought he wants to include it directly. Cheers! Angeliki On Tue, Dec 2, 2014 at 8:09 PM, Bill Hoffman wrote: > On 12/2/2014 1:33 PM, Angeliki Chrysochou wrote: > >> >> you should add in ./src/prog/CMakeLists.txt in include_directories the >> correct path to myfunc.h. Assuming CMAKE_SOURCE_DIR is "." (this is >> where your top level CMakeLists.txt is located): >> >> include_directories(${CMAKE_SOURCE_DIR}/src/mylib) >> > I don't think that will work. Two reasons: > > CMAKE_SOURCE_DIR is the top level source directory for the project, not > the current one. Also, he wants to include the file like this: > > #include "mylib/myfunc.h" > > So, the include needs to go to src and not src/mylib. > > -Bill > > > -- > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From angeliki.chrysochou at gmail.com Tue Dec 2 14:53:34 2014 From: angeliki.chrysochou at gmail.com (Angeliki Chrysochou) Date: Tue, 2 Dec 2014 20:53:34 +0100 Subject: [CMake] How to set path to library header files? In-Reply-To: <547E0E7D.4040904@kitware.com> References: <547DF7D8.4060206@kitware.com> <547E0E7D.4040904@kitware.com> Message-ID: Hi Bill.. Apparently, from his first email his top directory is src: Here are the current CMakeLists.txt files. Top level (../src): cmake_minimum_required(VERSION 2.8.4) project(src) project(src) add_subdirectory(mylib) add_subdirectory(prog) So this would probably work: include_directories(${CMAKE_SOURCE_DIR}/mylib) If he prefers to include it via mylib/myfunc.h then this should work (given his top level CMakeLists.txt is indeed in src/): include_directories(${CMAKE_SOURCE_DIR}) The file structure: . |-- bin/ |-- include/ | `-- mylib/ |-- lib/ `-- src/ |-- CMakeLists.txt |-- mylib/ | |-- CMakeLists.txt | |-- myfunc.cpp | `-- myfunc.h `-- prog/ |-- CMakeLists.txt `-- prog.cpp Cheers! On Tue, Dec 2, 2014 at 8:09 PM, Bill Hoffman wrote: > On 12/2/2014 1:33 PM, Angeliki Chrysochou wrote: > >> >> you should add in ./src/prog/CMakeLists.txt in include_directories the >> correct path to myfunc.h. Assuming CMAKE_SOURCE_DIR is "." (this is >> where your top level CMakeLists.txt is located): >> >> include_directories(${CMAKE_SOURCE_DIR}/src/mylib) >> > I don't think that will work. Two reasons: > > CMAKE_SOURCE_DIR is the top level source directory for the project, not > the current one. Also, he wants to include the file like this: > > #include "mylib/myfunc.h" > > So, the include needs to go to src and not src/mylib. > > -Bill > > > -- > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cxjohnson at gmail.com Tue Dec 2 15:05:36 2014 From: cxjohnson at gmail.com (Chris Johnson) Date: Tue, 2 Dec 2014 14:05:36 -0600 Subject: [CMake] How to set path to library header files? In-Reply-To: <547E0EB8.2000100@kitware.com> References: <547DF7D8.4060206@kitware.com> <547E0EB8.2000100@kitware.com> Message-ID: I'm using Make as my build tool. Here's the failing compile line with the -I paths. Indeed, they're not quite correct. This is with the suggested include_directories() directive. [100%] Building CXX object prog/CMakeFiles/prog.dir/prog.cpp.o cd /sandbox/src/.build/prog && /usr/bin/c++ -I/sandbox/include -I/sandbox/src/src -I/sandbox/src/mylib -o CMakeFiles/prog.dir/prog.cpp.o -c /sandbox/src/prog/prog.cpp Since the ../src/src path is wrong, I tried changing to include_directories(${CMAKE_SOURCE_DIR}) and that seems to work. That seems to imply the top-level source is not part of the default include path, correct? Thanks, ..chris On Tue, Dec 2, 2014 at 1:10 PM, Bill Hoffman wrote: > On 12/2/2014 1:04 PM, Chris Johnson wrote: > >> Adding this directive does not seem to change the results at all, >> actually. Am I missing something?? >> >> > What build tool are you using? Can you show a verbose compile line? Then > check the -I paths. make VERBOSE=1 will do it for make. > > -Bill > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From angeliki.chrysochou at gmail.com Tue Dec 2 15:46:45 2014 From: angeliki.chrysochou at gmail.com (Angeliki Chrysochou) Date: Tue, 2 Dec 2014 21:46:45 +0100 Subject: [CMake] How to set path to library header files? In-Reply-To: References: <547DF7D8.4060206@kitware.com> <547E0EB8.2000100@kitware.com> Message-ID: Glad it worked! No I don't think it is automatically an include path, only the files in the current directory where your sources are should be by default an include path. On Tue, Dec 2, 2014 at 9:05 PM, Chris Johnson wrote: > I'm using Make as my build tool. Here's the failing compile line with the > -I paths. Indeed, they're not quite correct. This is with the suggested > include_directories() directive. > > [100%] Building CXX object prog/CMakeFiles/prog.dir/prog.cpp.o > cd /sandbox/src/.build/prog && /usr/bin/c++ -I/sandbox/include > -I/sandbox/src/src -I/sandbox/src/mylib -o > CMakeFiles/prog.dir/prog.cpp.o -c /sandbox/src/prog/prog.cpp > > Since the ../src/src path is wrong, I tried changing to > include_directories(${CMAKE_SOURCE_DIR}) and that seems to work. That > seems to imply the top-level source is not part of the default include > path, correct? > > Thanks, > ..chris > > > On Tue, Dec 2, 2014 at 1:10 PM, Bill Hoffman > wrote: > >> On 12/2/2014 1:04 PM, Chris Johnson wrote: >> >>> Adding this directive does not seem to change the results at all, >>> actually. Am I missing something?? >>> >>> >> What build tool are you using? Can you show a verbose compile line? Then >> check the -I paths. make VERBOSE=1 will do it for make. >> >> -Bill >> >> > -- > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cxjohnson at gmail.com Tue Dec 2 16:53:58 2014 From: cxjohnson at gmail.com (Chris Johnson) Date: Tue, 2 Dec 2014 15:53:58 -0600 Subject: [CMake] How to set path to library header files? In-Reply-To: References: <547DF7D8.4060206@kitware.com> <547E0EB8.2000100@kitware.com> Message-ID: Well, this fixed my example. But my real project still fails the same way. It is, of course, much more complex and the library directories are often several layers down in subdirectory trees. :-( On Tue, Dec 2, 2014 at 2:05 PM, Chris Johnson wrote: > I'm using Make as my build tool. Here's the failing compile line with the > -I paths. Indeed, they're not quite correct. This is with the suggested > include_directories() directive. > > [100%] Building CXX object prog/CMakeFiles/prog.dir/prog.cpp.o > cd /sandbox/src/.build/prog && /usr/bin/c++ -I/sandbox/include > -I/sandbox/src/src -I/sandbox/src/mylib -o > CMakeFiles/prog.dir/prog.cpp.o -c /sandbox/src/prog/prog.cpp > > Since the ../src/src path is wrong, I tried changing to > include_directories(${CMAKE_SOURCE_DIR}) and that seems to work. That > seems to imply the top-level source is not part of the default include > path, correct? > > Thanks, > ..chris > > > On Tue, Dec 2, 2014 at 1:10 PM, Bill Hoffman > wrote: > >> On 12/2/2014 1:04 PM, Chris Johnson wrote: >> >>> Adding this directive does not seem to change the results at all, >>> actually. Am I missing something?? >>> >>> >> What build tool are you using? Can you show a verbose compile line? Then >> check the -I paths. make VERBOSE=1 will do it for make. >> >> -Bill >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From cxjohnson at gmail.com Tue Dec 2 17:00:36 2014 From: cxjohnson at gmail.com (Chris Johnson) Date: Tue, 2 Dec 2014 16:00:36 -0600 Subject: [CMake] How to set path to library header files? In-Reply-To: References: <547DF7D8.4060206@kitware.com> <547E0EB8.2000100@kitware.com> Message-ID: Yes, by adding another directory between my top-level ./src/ directory and ./mylib, I can cause the example to fail. I understand now that the include_directory() directive really has no hidden intelligence to it at all, as I had mistakenly believed. It's just a path. However, I don't really want to have to go around to all my executables and add a bunch of relative paths based on which libraries they use, and where they are located in the tree. Is there some way that I can instead do something like force the install of the libraries to happen before the build of the programs which depend upon them? On Tue, Dec 2, 2014 at 3:53 PM, Chris Johnson wrote: > Well, this fixed my example. But my real project still fails the same > way. It is, of course, much more complex and the library directories are > often several layers down in subdirectory trees. :-( > > On Tue, Dec 2, 2014 at 2:05 PM, Chris Johnson wrote: > >> I'm using Make as my build tool. Here's the failing compile line with >> the -I paths. Indeed, they're not quite correct. This is with the >> suggested include_directories() directive. >> >> [100%] Building CXX object prog/CMakeFiles/prog.dir/prog.cpp.o >> cd /sandbox/src/.build/prog && /usr/bin/c++ -I/sandbox/include >> -I/sandbox/src/src -I/sandbox/src/mylib -o >> CMakeFiles/prog.dir/prog.cpp.o -c /sandbox/src/prog/prog.cpp >> >> Since the ../src/src path is wrong, I tried changing to >> include_directories(${CMAKE_SOURCE_DIR}) and that seems to work. That >> seems to imply the top-level source is not part of the default include >> path, correct? >> >> Thanks, >> ..chris >> >> >> On Tue, Dec 2, 2014 at 1:10 PM, Bill Hoffman >> wrote: >> >>> On 12/2/2014 1:04 PM, Chris Johnson wrote: >>> >>>> Adding this directive does not seem to change the results at all, >>>> actually. Am I missing something?? >>>> >>>> >>> What build tool are you using? Can you show a verbose compile line? >>> Then check the -I paths. make VERBOSE=1 will do it for make. >>> >>> -Bill >>> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cxjohnson at gmail.com Tue Dec 2 17:19:06 2014 From: cxjohnson at gmail.com (Chris Johnson) Date: Tue, 2 Dec 2014 16:19:06 -0600 Subject: [CMake] How to set path to library header files? In-Reply-To: References: <547DF7D8.4060206@kitware.com> <547E0EB8.2000100@kitware.com> Message-ID: The target_link_libraries() directive is adequate for this job when the header files for the library are simply referred to with no directory prefix, i.e. #include "some file.h" instead of #include "my lib/somefile.h". Referencing the library with target_link_libraries() appears to automatically add the necessary source directories of the mentioned libraries to the include paths. On Tue, Dec 2, 2014 at 4:00 PM, Chris Johnson wrote: > Yes, by adding another directory between my top-level ./src/ directory and > ./mylib, I can cause the example to fail. I understand now that the > include_directory() directive really has no hidden intelligence to it at > all, as I had mistakenly believed. It's just a path. > > However, I don't really want to have to go around to all my executables > and add a bunch of relative paths based on which libraries they use, and > where they are located in the tree. > > Is there some way that I can instead do something like force the install > of the libraries to happen before the build of the programs which depend > upon them? > > On Tue, Dec 2, 2014 at 3:53 PM, Chris Johnson wrote: > >> Well, this fixed my example. But my real project still fails the same >> way. It is, of course, much more complex and the library directories are >> often several layers down in subdirectory trees. :-( >> >> On Tue, Dec 2, 2014 at 2:05 PM, Chris Johnson >> wrote: >> >>> I'm using Make as my build tool. Here's the failing compile line with >>> the -I paths. Indeed, they're not quite correct. This is with the >>> suggested include_directories() directive. >>> >>> [100%] Building CXX object prog/CMakeFiles/prog.dir/prog.cpp.o >>> cd /sandbox/src/.build/prog && /usr/bin/c++ -I/sandbox/include >>> -I/sandbox/src/src -I/sandbox/src/mylib -o >>> CMakeFiles/prog.dir/prog.cpp.o -c /sandbox/src/prog/prog.cpp >>> >>> Since the ../src/src path is wrong, I tried changing to >>> include_directories(${CMAKE_SOURCE_DIR}) and that seems to work. That >>> seems to imply the top-level source is not part of the default include >>> path, correct? >>> >>> Thanks, >>> ..chris >>> >>> >>> On Tue, Dec 2, 2014 at 1:10 PM, Bill Hoffman >>> wrote: >>> >>>> On 12/2/2014 1:04 PM, Chris Johnson wrote: >>>> >>>>> Adding this directive does not seem to change the results at all, >>>>> actually. Am I missing something?? >>>>> >>>>> >>>> What build tool are you using? Can you show a verbose compile line? >>>> Then check the -I paths. make VERBOSE=1 will do it for make. >>>> >>>> -Bill >>>> >>>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From calebwherry at gmail.com Tue Dec 2 22:24:37 2014 From: calebwherry at gmail.com (J. Caleb Wherry) Date: Tue, 2 Dec 2014 22:24:37 -0500 Subject: [CMake] Linking Shared C++ Object from ExternalProject Produces Binaries with Relative Path, not Absolute Message-ID: All, I've been beating my head over this for about 3 days now and haven't gotten anywhere. There have been a few discussions on topics related to this question but nothing has gotten me a 100% solution (yet). I have created a StackOverflow post to see if I could get anything there but have yet to get any hits yet: http://stackoverflow.com/q/27261288/408160 My problem is this: I am using ExternalProject to add a project that gets built by make. I want the libs that come out of this project to be linked in with apps and libs I have in my project (I have created a sample project here: https://github.com/calebwherry/cmake-superprj-main-test). The external lib compiles correctly but the issue is with how it is linked to my apps and libs: whenever I do ldd on them the path shows up as relative for the external lib. This means that is cannot be run anywhere but from the directory CMake puts it. Setting LD_LIBRARY_PATH or messing with RPATH does not effect the external lib, it always shows up with a relative path like so: libTestLib.so => /home/jwherry3/repos/cmake-superprj-main-test/build/src/lib/TestLib/libTestLib.so (0x00007f592da57000) ../../lib/libExtLib.so (0x00007f592d855000) The first lib (libTestLib.so) is the one built with CMake in the superproject and the second (libExtLib.so) is the external lib. I have no idea how to get it NOT to do this. I think it is potentially something wrong with how I am interfacing with the ExternalProject target but am not sure. The github example is fully compilable and exhibits the undesired behavior (Debian Wheezy 64-bit, CMake 3.0.1, g++-4.9.2). Thanks for the help! Caleb -- J. Caleb Wherry *Scientific Software Engineer* http://www.calebwherry.com +1 (615) 708-5651 calebwherry at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From Georg.Altmann at informatik.stud.uni-erlangen.de Wed Dec 3 05:20:47 2014 From: Georg.Altmann at informatik.stud.uni-erlangen.de (Georg Altmann) Date: Wed, 03 Dec 2014 11:20:47 +0100 Subject: [CMake] Nvidia nsight (eclipse cdt) error parsing In-Reply-To: References: Message-ID: On 02.12.2014 12:28, Georg Altmann wrote: > Hi, > > I am using CMake for generating a project file for nvidia nsight to edit > CUDA sources. > > $ mkdir myproj-build && cd myproj-build > $ cmake -G"Eclipse CDT4 - Unix Makefiles" ../myproj > > The problem is, eclipse won't recognize the compiler errors output by nvcc. > I enabled the "nvcc error parser" in "project->properties->C/C++ Make > Project->Error Parsers" and moved it to the top of the list. > Error parsing works fine for "native" nsight CUDA projects and for > non-CUDA/non-nvcc c++ cmake generated projects. > > Is this a known issue? Anybody have a fix? > > System: Linux Ubuntu 14.04.1 LTS x64 > > Tested cmake versions: > cmake version 2.8.12.2 (Ubuntu 14.04.1 LTS) > cmake version 3.1.0-rc2 (built from source) > > Nsight Eclipse Edition 6.5 > Eclipse C/C++ Development Tools Version: 8.1.2.nvidia-qualifier I opened a bug for this issue: http://public.kitware.com/Bug/view.php?id=15277 Regards Georg From lode.leroy at gmail.com Wed Dec 3 06:23:29 2014 From: lode.leroy at gmail.com (Lode Leroy) Date: Wed, 3 Dec 2014 12:23:29 +0100 Subject: [CMake] include problems Message-ID: I have a something.cmake file that works when included directly, but does not work when it is included from inside a function. can someone explain if there is an intentional difference, and what it is, between include(something) and function(use_something) include(something) endfunction() use_something() in other words: how can I make the function use_something() behave as include(something)? From petr.kmoch at gmail.com Wed Dec 3 06:40:05 2014 From: petr.kmoch at gmail.com (Petr Kmoch) Date: Wed, 3 Dec 2014 12:40:05 +0100 Subject: [CMake] include problems In-Reply-To: References: Message-ID: Hi. The difference is that if there are any variables defined in something, they will be defined in the scope of the function in the second case, making them invisible outside of the function. If that is your problem, you could help this by turning the function into a macro (which has its own set of caveats, of course). Petr On Wed, Dec 3, 2014 at 12:23 PM, Lode Leroy wrote: > I have a something.cmake file that works when included directly, but > does not work when it is included from inside a function. > > can someone explain if there is an intentional difference, and what it > is, between > > include(something) > > and > > function(use_something) > include(something) > endfunction() > use_something() > > in other words: how can I make the function use_something() behave as > include(something)? > -- > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.hoffman at kitware.com Wed Dec 3 11:56:49 2014 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Wed, 03 Dec 2014 11:56:49 -0500 Subject: [CMake] How to set path to library header files? In-Reply-To: References: <547DF7D8.4060206@kitware.com> <547E0EB8.2000100@kitware.com> Message-ID: <547F40D1.9040608@kitware.com> On 12/2/2014 5:19 PM, Chris Johnson wrote: > The target_link_libraries() directive is adequate for this job when the > header files for the library are simply referred to with no directory > prefix, i.e. #include "some file.h" instead of #include "my > lib/somefile.h". Referencing the library with target_link_libraries() > appears to automatically add the necessary source directories of the > mentioned libraries to the include paths. The include directories will be copied out of the library and chained along, but they need to be explicitly set somewhere. Although you could get an install to happen in the middle of a build with custom commands and targets, I would not recommend it. Just get the include paths correctly specified and things should work. -- Bill Hoffman Kitware, Inc. 28 Corporate Drive Clifton Park, NY 12065 bill.hoffman at kitware.com http://www.kitware.com 518 881-4905 (Direct) 518 371-3971 x105 Fax (518) 371-4573 From cxjohnson at gmail.com Wed Dec 3 15:22:06 2014 From: cxjohnson at gmail.com (Chris Johnson) Date: Wed, 3 Dec 2014 14:22:06 -0600 Subject: [CMake] How to set path to library header files? In-Reply-To: <547F40D1.9040608@kitware.com> References: <547DF7D8.4060206@kitware.com> <547E0EB8.2000100@kitware.com> <547F40D1.9040608@kitware.com> Message-ID: I think I've made it work by adding 1 ugly hack and 1 reasonable directive to each library's CMakeLists.txt, which is at least far preferable to adding several new include paths to potentially hundreds of programs which refer to those libraries. The hack is a function which is defined in my global CMake "include" file, which when called simply (well, not so simply -- it's a hack!) creates a subdirectory of the library's name in the BUILD directory and then copies the *.h files from the SOURCE directory to it. Then I add # Headers used from build location: "$" to my existing target_include_directories(). While this appears to work in early testing, I'd sure like a better solution. It's pretty much best practice to install one's private library header files in a subdirectory of /usr/include, /usr/local/include, etc. So having to jump through hoops to support that paradigm is kind of strange. Thanks, ..chris On Wed, Dec 3, 2014 at 10:56 AM, Bill Hoffman wrote: > On 12/2/2014 5:19 PM, Chris Johnson wrote: > >> The target_link_libraries() directive is adequate for this job when the >> header files for the library are simply referred to with no directory >> prefix, i.e. #include "some file.h" instead of #include "my >> lib/somefile.h". Referencing the library with target_link_libraries() >> appears to automatically add the necessary source directories of the >> mentioned libraries to the include paths. >> > The include directories will be copied out of the library and chained > along, but they need to be explicitly set somewhere. Although you could > get an install to happen in the middle of a build with custom commands and > targets, I would not recommend it. Just get the include paths correctly > specified and things should work. > > -- > Bill Hoffman > Kitware, Inc. > 28 Corporate Drive > Clifton Park, NY 12065 > bill.hoffman at kitware.com > http://www.kitware.com > 518 881-4905 (Direct) > 518 371-3971 x105 > Fax (518) 371-4573 > -- > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From domen.vrankar at gmail.com Wed Dec 3 17:13:00 2014 From: domen.vrankar at gmail.com (Domen Vrankar) Date: Wed, 3 Dec 2014 23:13:00 +0100 Subject: [CMake] How to set path to library header files? In-Reply-To: References: <547DF7D8.4060206@kitware.com> <547E0EB8.2000100@kitware.com> <547F40D1.9040608@kitware.com> Message-ID: 2014-12-03 21:22 GMT+01:00 Chris Johnson : > I think I've made it work by adding 1 ugly hack and 1 reasonable directive > to each library's CMakeLists.txt, which is at least far preferable to adding > several new include paths to potentially hundreds of programs which refer to > those libraries. Years ago when I changed build system on ~75 programs I did exactly that (added new include paths to each one with include_directories command in cmake) as everything else would seem to me as an ugly hack... You don't need to refer to them with a relative path depending on where in the build tree you are - when you call porject(project_name) command you can refer to its location from other CMakeLists.txt with ${project_name_SOURCE_DIR} and ${project_name_BINARY_DIR} so by putting project command at the top of every library cmake list you don't need to know the relative location in each executable. Here's an example: Executable cmake list: cmake_minimum_required(VERSION 2.8) project(main) add_subdirectory(test_b) message("src: ${test_b_SOURCE_DIR}") # prints out the path just to show that it is really set message("build: ${test_b_BINARY_DIR}") # prints out the path just to show that it is really set add_executable(${PROJECT_NAME} main.cpp) target_link_libraries(${PROJECT_NAME} test_b) And libary cmake list: project(test_b) add_library(${PROJECT_NAME} b.cpp) > The hack is a function which is defined in my global CMake "include" file, > which when called simply (well, not so simply -- it's a hack!) creates a > subdirectory of the library's name in the BUILD directory and then copies > the *.h files from the SOURCE directory to it. > > Then I add > # Headers used from build location: > "$" > to my existing target_include_directories(). > > While this appears to work in early testing, I'd sure like a better > solution. It's pretty much best practice to install one's private library > header files in a subdirectory of /usr/include, /usr/local/include, etc. So > having to jump through hoops to support that paradigm is kind of strange. >From what I've understood from the thread I guess that you would like to access some header files at compile time on a location that would be accessible after install time. I've started solving this a while ago with treating every library as an external dependency even if it is part of the same repository as the code for the executable. For every new library that I write I also write a FindSomeLib.cmake script so that I'm able to refer to the library header and lib files by calling find_library(SomeLib) and that sets SomeLib_LIBRARY_DIRS and SomeLib_INCLUDE_DIRS variables that can be used by all the projects that refer to it. The logic in FindSomeLib.cmake script that I'm using is a fallback structure: 1. check that the library is not already set 2. check how to set SomeLib_LIBRARY_DIRS and SomeLib_INCLUDE_DIRS variables a. if a target by the name of SomeLib already exists in my project (for e.g. because my uberbuild builds the libraries before it starts building the executables so that I can add all the targets in one RPM package for distribution) b. else if a certain variable is set then we are in development mode and we add the library as a sub-directory with add_subdirectory(path_to_lib lib_name) -> this is useful when we are developing and fixing bugs both in executable and library code c. else if a library is already installed (useful if we are creating a production build that must link to an exact version of a library that we have on the production build server) d. else -> library not found 3. if library was found -> set the SomeLib_LIBRARY_DIRS and SomeLib_INCLUDE_DIRS variables accordingly This way programs/other libraries only set the above variables as include dir (note that SomeLib_INCLUDE_DIRS may point to more than one location in a list) and SomeLib_LIBRARY_DIRS and they don't care if the library was created with external_project command, built as a target or already existed in the environment (just like they wouldn't care if a library would be from a different vendor but since it is ours we can have additional logic as explained above). And if you ever need to change the structure of the library (for e.g. add more sub directories or rename the existing directories) you only have to change the find script and all the project will work out of the box without changing their CMakeLIsts.txt. This will still not solve your problem of #include "lib_name/include_file.hpp" if your library repository is not structured to have private headers in lib_name subdir but you can hide away the hack of copying the headers inside the Find cmake script. But I'd say that not having the right directory structure in the repo would be something bagging for hacks so in that case repo restructuring would probably be a better way to go. Alternative to the solution above would be to treat all libraries as an ExternalProject (http://www.cmake.org/cmake/help/v3.0/module/ExternalProject.html) which can be used to install the library in build directory while compiling the project but this has some drawbacks (packaging such a library in the same package as executable with CPack requires more work, during development you can't treat such a library as part of the project so you're not able to fix library sources as easy as with the above solution,...). It also has an advantage - library can be fetched from a different repository. When I'm using ExternalProject command I hide it away in Find cmake script as well so that changes to repository name or something like that doesn't affect all the executables/libraries that use it... Hope this helps, Domen From steveire at gmail.com Wed Dec 3 19:14:18 2014 From: steveire at gmail.com (Stephen Kelly) Date: Thu, 04 Dec 2014 01:14:18 +0100 Subject: [CMake] How to set path to library header files? References: <547DF7D8.4060206@kitware.com> <547E0EB8.2000100@kitware.com> Message-ID: Chris Johnson wrote: > That > seems to imply the top-level source is not part of the default include > path, correct? Correct. CMake doesn't add anything by default. The only defaults are those provided by the compiler. From steveire at gmail.com Wed Dec 3 19:17:59 2014 From: steveire at gmail.com (Stephen Kelly) Date: Thu, 04 Dec 2014 01:17:59 +0100 Subject: [CMake] How to set path to library header files? References: <547DF7D8.4060206@kitware.com> <547E0EB8.2000100@kitware.com> Message-ID: Chris Johnson wrote: > Yes, by adding another directory between my top-level ./src/ directory and > ./mylib, I can cause the example to fail. I understand now that the > include_directory() directive really has no hidden intelligence to it at > all, as I had mistakenly believed. It's just a path. I'm curious: What hidden intelligence did you expect? > However, I don't really want to have to go around to all my executables > and add a bunch of relative paths based on which libraries they use, and > where they are located in the tree. Use PUBLIC or INTERFACE target_include_directories for that. And please really go ahead and read http://www.cmake.org/cmake/help/v3.1/manual/cmake-buildsystem.7.html > > Is there some way that I can instead do something like force the install > of the libraries to happen before the build of the programs which depend > upon them? Instead, use target_include_directories, as your initial example did to use different directories for the build and install locations. Thanks, Steve. From steveire at gmail.com Wed Dec 3 19:31:46 2014 From: steveire at gmail.com (Stephen Kelly) Date: Thu, 04 Dec 2014 01:31:46 +0100 Subject: [CMake] How to set path to library header files? References: <547DF7D8.4060206@kitware.com> <547E0E7D.4040904@kitware.com> Message-ID: Angeliki Chrysochou wrote: > Hi Bill, > > He wrote > > "Note also that prog.cpp includes this header via #include "myfunc.h"." > > in his first email, so I thought he wants to include it directly. > See his second email. Thanks, Steve. From steveire at gmail.com Wed Dec 3 19:39:10 2014 From: steveire at gmail.com (Stephen Kelly) Date: Thu, 04 Dec 2014 01:39:10 +0100 Subject: [CMake] How to set path to library header files? References: <547DF7D8.4060206@kitware.com> <547E0EB8.2000100@kitware.com> <547F40D1.9040608@kitware.com> Message-ID: Domen Vrankar wrote: > I've started solving this a while ago with treating every library as > an external dependency even if it is part of the same repository as > the code for the executable. > For every new library that I write I also write a FindSomeLib.cmake Much of what you describe should not be necessary in a modern CMake system. http://www.cmake.org/cmake/help/v3.0/manual/cmake-packages.7.html http://www.cmake.org/cmake/help/v3.0/manual/cmake-buildsystem.7.html#alias-targets http://www.cmake.org/cmake/help/v3.0/command/export.html#command:export Thanks, Steve. From Micha.Renner at t-online.de Thu Dec 4 10:13:07 2014 From: Micha.Renner at t-online.de (Micha Renner) Date: Thu, 04 Dec 2014 16:13:07 +0100 Subject: [CMake] CMake and 64-bit Systems Message-ID: <1417705987.2803.1.camel@t-online.de> Hallo, does CMake run on 64-bit OS (e.g. Ubuntu 14.10 64-bit) without problems or are there some workarounds necessary to get it run? If so, is there a description available? Greetings Michael From drescherjm at gmail.com Thu Dec 4 10:39:43 2014 From: drescherjm at gmail.com (John Drescher) Date: Thu, 4 Dec 2014 10:39:43 -0500 Subject: [CMake] CMake and 64-bit Systems In-Reply-To: <1417705987.2803.1.camel@t-online.de> References: <1417705987.2803.1.camel@t-online.de> Message-ID: > does CMake run on 64-bit OS (e.g. Ubuntu 14.10 64-bit) without problems > or are there some workarounds necessary to get it run? If so, is there a > description available? > I have not had any real issue with cmake (32 or 64 bit binary) on 64 bit linux or windows. John From jzakrzewski at e2e.ch Thu Dec 4 10:26:13 2014 From: jzakrzewski at e2e.ch (Jakub Zakrzewski) Date: Thu, 4 Dec 2014 15:26:13 +0000 Subject: [CMake] CMake and 64-bit Systems In-Reply-To: <1417705987.2803.1.camel@t-online.de> References: <1417705987.2803.1.camel@t-online.de> Message-ID: Hallo Michael, > does CMake run on 64-bit OS (e.g. Ubuntu 14.10 64-bit) without problems or are there some workarounds necessary > to get it run? If so, is there a description available? CMake runs smoothly on much more exotic than 64-bit OS, so what makes you think it wouldn't work on those? But let's be clear. It runs without problems on my OpenSUSE, Gentoo, Solaris 10/11 and Windows 64-bit boxes. Just install / build and off you go. -- Gruesse, Jakub From Allen.Barnett at varian.com Thu Dec 4 18:29:34 2014 From: Allen.Barnett at varian.com (Allen Barnett) Date: Thu, 4 Dec 2014 23:29:34 +0000 Subject: [CMake] Visual Studio 12 C++ Compiler Detection Message-ID: <088f168a820e4bba9252f3fa1dfa8d89@PA-EX2013-MBX02.vms.ad.varian.com> Hi: I'm trying to create a 64-bit Visual Studio 12 (aka 2013) project with CMake 3.0.2. My CMakeLists.txt file is really simple: cmake_minimum_required( VERSION 3.0 ) project( cmc CXX ) # What compiler did we find? message( "C++: ${CMAKE_CXX_COMPILER}" ) >From a windows shell I do: > c:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\bin\amd64\vcvars64.bat > cmake -G "Visual Studio 12 Win64" . -- The CXX compiler identification is MSVC 18.0.31101.0 -- Check for working CXX compiler using: Visual Studio 12 2013 Win64 -- Check for working CXX compiler using: Visual Studio 12 2013 Win64 -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done C++: C:/Program Files (x86)/Microsoft Visual Studio 12.0/VC/bin/x86_amd64/cl.exe -- Configuring done -- Generating done -- Build files have been written to: C:/Users/dbarnett/cmc/build So, it appears to find the compiler OK since it emits the correct compiler identification. But, the actual value of CMAKE_CXX_COMPILER is not usable. If you try to execute C:/Program..../x86_amd64/cl.exe from within a CMake script or even from the command line, it will fail and produce the well-known "0xc000007b" dialog (missing DLL). Unless you've sourced vcvarsx86_amd64.bat, the correct environment variables are not set for this version of the compiler. On the other hand, if I do "cmake -G NMake Makefiles", I get what I expect: -- The CXX compiler identification is MSVC 18.0.31101.0 -- Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual Studio 12.0/VC/bin/amd64/cl.exe -- Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual Studio 12.0/VC/bin/amd64/cl.exe -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done C++: C:/Program Files (x86)/Microsoft Visual Studio 12.0/VC/bin/amd64/cl.exe -- Configuring done -- Generating done -- Build files have been written to: C:/Users/dbarnett/cmc/other Namely, it finds C:/Program..../amd64/cl.exe. I've looked through the CMake Modules, but I could not really find the place where CMake derives the value for CMAKE_CXX_COMPILER when you generate a VS project. Could someone point me to the source code where this occurs? I would like to see how it is coming up with this version of the compiler which isn't even in the PATH. Thanks, Allen -------------- next part -------------- An HTML attachment was scrubbed... URL: From cxjohnson at gmail.com Thu Dec 4 22:27:31 2014 From: cxjohnson at gmail.com (Chris Johnson) Date: Thu, 4 Dec 2014 21:27:31 -0600 Subject: [CMake] project directive overwrites CMAKE_INSTALL_PREFIX? Message-ID: I have a global include file used by all of the CMakeLists.txt files in my project. In it, I set the value of CMAKE_INSTALL_PREFIX, as well as a number of other variables and functions. In my CMakeLists.txt file, I had this: cmake_minimum_require(VERSION 2.8.4) include(global.inc) project(whatever) When I run cmake, the value of CMAKE_INSTALL_PREFIX is lost! Instead, in the resulting cmake_install.cmake file has been defaulted back to /usr/local which is completely wrong. However, if I change the order to this: cmake_minimum_require(VERSION 2.8.4) project(whatever) include(global.inc) It appears to work. I find nothing in the documentation saying that the project() directive will set CMAKE_INSTALL_PREFIX. Even more strangely, if I run cmake a second time with the first configuration (include before project), it will rewrite cmake_install.cmake with the correct value. ? ? That is, the behavior of cmake appears to be different based on whether the build directory is empty or already contains cmake_install.cmake and CMakeCache.txt files ?, even though they contain the wrong path value for CMAKE_INSTALL_PREFIX.? What is going on here? -------------- next part -------------- An HTML attachment was scrubbed... URL: From d3ck0r at gmail.com Thu Dec 4 22:48:47 2014 From: d3ck0r at gmail.com (J Decker) Date: Thu, 4 Dec 2014 19:48:47 -0800 Subject: [CMake] project directive overwrites CMAKE_INSTALL_PREFIX? In-Reply-To: References: Message-ID: I find it's better to define CMAKE_INSTALL_PREFIX on the command line when building I do have this bit of code... IF(CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT) SET(CMAKE_INSTALL_PREFIX ${CMAKE_BINARY_DIR}/../${CMAKE_BUILD_TYPE}_out CACHE PATH "Install default 'out' in this directory." FORCE ) ENDIF(CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT) which keeps it from overwriting an already set value (from the command line); and make sure it's in the cache so cmake-gui can edit it... (if project() does something with cmake_isnstall_prefix might also be a bug) On Thu, Dec 4, 2014 at 7:27 PM, Chris Johnson wrote: > I have a global include file used by all of the CMakeLists.txt files in my > project. In it, I set the value of CMAKE_INSTALL_PREFIX, as well as a > number of other variables and functions. > > In my CMakeLists.txt file, I had this: > > cmake_minimum_require(VERSION 2.8.4) > include(global.inc) > project(whatever) > > When I run cmake, the value of CMAKE_INSTALL_PREFIX is lost! Instead, in > the resulting cmake_install.cmake file has been defaulted back to > /usr/local which is completely wrong. > > However, if I change the order to this: > > cmake_minimum_require(VERSION 2.8.4) > project(whatever) > include(global.inc) > > It appears to work. > > I find nothing in the documentation saying that the project() directive > will set CMAKE_INSTALL_PREFIX. > > Even more strangely, if I run cmake a second time with the first > configuration (include before project), it will rewrite cmake_install.cmake > with the correct value. > ? ? > That is, the behavior of cmake appears to be different based on whether > the build directory is empty or already contains cmake_install.cmake and > CMakeCache.txt files > ?, even though they contain the wrong path value for CMAKE_INSTALL_PREFIX.? > > What is going on here? > > > > > > > -- > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam.getchell at gmail.com Fri Dec 5 00:30:39 2014 From: adam.getchell at gmail.com (Adam Getchell) Date: Thu, 4 Dec 2014 21:30:39 -0800 Subject: [CMake] Correct settings to add docopt.cpp to target list Message-ID: <7D7D2DBD-0834-48B1-9103-9B539F3A90C3@gmail.com> Hello all, I?m trying to use the docopt.cpp parser for my project[1]: https://github.com/docopt/docopt.cpp The usual invocation to build works: ??[adam][Hapkido][?][docopt ?][~/CDT-plusplus/src/docopt] ??? clang++ --std=c++11 --stdlib=libc++ -I . docopt.cpp examples/naval_fate.cpp -o naval_fate So, I want to add docopt.cpp and have the compiler look for header files in the same directory, and add that to my executable. So far, what I?ve attempted is to add the lines: include_directories (BEFORE "src/docopt") add_library(docopt.cpp "src/docopt/docopt.cpp?) My program uses CGAL[2], and all of those library headers are incorporated using the create_single_source_cgal_program function in the CGAL_CreateSingleSourceCGALProgram.cmake module. The error messages I?m getting correspond to the ones I get when docopt.cpp is not included: ??[adam][Hapkido][?][docopt ?][~/CDT-plusplus/src/docopt] ??? clang++ --std=c++11 --stdlib=libc++ -I . examples/naval_fate.cpp -o naval_fate Undefined symbols for architecture x86_64: "docopt::docopt(std::__1::basic_string, std::__1::allocator > const&, std::__1::vector, std::__1::allocator >, std::__1::allocator, std::__1::allocator > > > const&, bool, std::__1::basic_string, std::__1::allocator > const&, bool)", referenced from: _main in naval_fate-780283.o "docopt::operator<<(std::__1::basic_ostream >&, docopt::value const&)", referenced from: _main in naval_fate-780283.o ld: symbol(s) not found for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation) Compare to: ??[adam][Hapkido][?][docopt ?][~/CDT-plusplus] ??? ./build.sh -- The C compiler identification is AppleClang 6.0.0.6000054 -- The CXX compiler identification is AppleClang 6.0.0.6000054 -- Check for working C compiler using: Ninja -- Check for working C compiler using: Ninja -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working CXX compiler using: Ninja -- Check for working CXX compiler using: Ninja -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Build type: Release -- USING CXXFLAGS = ' -O3 -DNDEBUG' -- USING EXEFLAGS = ' -Wl,-dylib_file,/System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib:/System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib ' -- Targetting Ninja -- Using /usr/bin/c++ compiler. -- DARWIN_VERSION=14 -- Mac Leopard detected -- Requested component: Core -- Requested component: MPFR -- Requested component: GMP -- Found Eigen3: /usr/local/include/eigen3 (found suitable version "3.2.2", minimum required is "3.1.0") -- Configuring done -- Generating done -- Build files have been written to: /Users/adam/CDT-plusplus/build [10/13] Linking CXX executable cdt-docopt FAILED: : && /usr/bin/c++ -O3 -DNDEBUG -Wl,-search_paths_first -Wl,-headerpad_max_install_names -Wl,-dylib_file,/System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib:/System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib CMakeFiles/cdt-docopt.dir/src/cdt-docopt.cpp.o -o cdt-docopt -L/Users/adam/gmock-1.7.0/lib/.libs -L/Users/adam/gmock-1.7.0/gtest/lib/.libs /usr/local/lib/libmpfr.dylib /usr/local/lib/libgmp.dylib /usr/local/lib/libCGAL_Core.dylib /usr/local/lib/libCGAL.dylib /usr/local/lib/libboost_thread-mt.dylib /usr/local/lib/libboost_system-mt.dylib /usr/local/lib/libCGAL_Core.dylib /usr/local/lib/libCGAL.dylib /usr/local/lib/libboost_thread-mt.dylib /usr/local/lib/libboost_system-mt.dylib -Wl,-rpath,/Users/adam/gmock-1.7.0/lib/.libs -Wl,-rpath,/Users/adam/gmock-1.7.0/gtest/lib/.libs && : Undefined symbols for architecture x86_64: "docopt::docopt(std::__1::basic_string, std::__1::allocator > const&, std::__1::vector, std::__1::allocator >, std::__1::allocator, std::__1::allocator > > > const&, bool, std::__1::basic_string, std::__1::allocator > const&, bool)", referenced from: _main in cdt-docopt.cpp.o "docopt::operator<<(std::__1::basic_ostream >&, docopt::value const&)", referenced from: _main in cdt-docopt.cpp.o ld: symbol(s) not found for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation) [10/13] Building CXX object CMakeFiles/unittests.dir/unittests/Triangulated2SphereTest.cpp.o ninja: build stopped: subcommand failed. Any suggestions? [1] https://github.com/acgetchell/CDT-plusplus/tree/docopt [2] https://www.cgal.org Adam Getchell about.me/adamgetchell -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam.getchell at gmail.com Fri Dec 5 01:54:23 2014 From: adam.getchell at gmail.com (Adam Getchell) Date: Thu, 4 Dec 2014 22:54:23 -0800 Subject: [CMake] Correct settings to add docopt.cpp to target list In-Reply-To: <7D7D2DBD-0834-48B1-9103-9B539F3A90C3@gmail.com> References: <7D7D2DBD-0834-48B1-9103-9B539F3A90C3@gmail.com> Message-ID: I should note that I'm doing an out of source build, and that for my project the following line works: ??[*adam*][Hapkido][*?*][docopt *?*][~/CDT-plusplus/build] ??? clang++ --std=c++11 --stdlib=libc++ -I ../src/docopt ../src/docopt/docopt.cpp ../src/cdt-docopt.cpp -o cdt_docopt On Thu, Dec 4, 2014 at 9:30 PM, Adam Getchell wrote: > Hello all, > > I?m trying to use the docopt.cpp parser for my project[1]: > > https://github.com/docopt/docopt.cpp > > The usual invocation to build works: > > ??[*adam*][Hapkido][*?*][docopt *?*][~/CDT-plusplus/src/docopt] > ??? clang++ --std=c++11 --stdlib=libc++ -I . docopt.cpp > examples/naval_fate.cpp -o naval_fate > > So, I want to add docopt.cpp and have the compiler look for header files > in the same directory, and add that to my executable. > > So far, what I?ve attempted is to add the lines: > > include_directories (BEFORE "src/docopt") > add_library(docopt.cpp "src/docopt/docopt.cpp?) > > My program uses CGAL[2], and all of those library headers are incorporated > using the create_single_source_cgal_program function in the > CGAL_CreateSingleSourceCGALProgram.cmake module. > > The error messages I?m getting correspond to the ones I get when > docopt.cpp is not included: > > ??[*adam*][Hapkido][*?*][docopt *?*][~/CDT-plusplus/src/docopt] > ??? clang++ --std=c++11 --stdlib=libc++ -I . examples/naval_fate.cpp -o > naval_fate > Undefined symbols for architecture x86_64: > "docopt::docopt(std::__1::basic_string std::__1::char_traits, std::__1::allocator > const&, > std::__1::vector, > std::__1::allocator >, > std::__1::allocator std::__1::char_traits, std::__1::allocator > > > const&, bool, > std::__1::basic_string, > std::__1::allocator > const&, bool)", referenced from: > _main in naval_fate-780283.o > "docopt::operator<<(std::__1::basic_ostream std::__1::char_traits >&, docopt::value const&)", referenced from: > _main in naval_fate-780283.o > ld: symbol(s) not found for architecture x86_64 > clang: error: linker command failed with exit code 1 (use -v to see > invocation) > > Compare to: > > ??[*adam*][Hapkido][*?*][docopt *?*][~/CDT-plusplus] > ??? ./build.sh > -- The C compiler identification is AppleClang 6.0.0.6000054 > -- The CXX compiler identification is AppleClang 6.0.0.6000054 > -- Check for working C compiler using: Ninja > -- Check for working C compiler using: Ninja -- works > -- Detecting C compiler ABI info > -- Detecting C compiler ABI info - done > -- Check for working CXX compiler using: Ninja > -- Check for working CXX compiler using: Ninja -- works > -- Detecting CXX compiler ABI info > -- Detecting CXX compiler ABI info - done > -- Build type: Release > -- USING CXXFLAGS = ' -O3 -DNDEBUG' > -- USING EXEFLAGS = ' > -Wl,-dylib_file,/System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib:/System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib > ' > -- Targetting Ninja > -- Using /usr/bin/c++ compiler. > -- DARWIN_VERSION=14 > -- Mac Leopard detected > -- Requested component: Core > -- Requested component: MPFR > -- Requested component: GMP > -- Found Eigen3: /usr/local/include/eigen3 (found suitable version > "3.2.2", minimum required is "3.1.0") > -- Configuring done > -- Generating done > -- Build files have been written to: /Users/adam/CDT-plusplus/build > [10/13] Linking CXX executable cdt-docopt > FAILED: : && /usr/bin/c++ -O3 -DNDEBUG -Wl,-search_paths_first > -Wl,-headerpad_max_install_names > -Wl,-dylib_file,/System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib:/System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib > CMakeFiles/cdt-docopt.dir/src/cdt-docopt.cpp.o -o cdt-docopt > -L/Users/adam/gmock-1.7.0/lib/.libs > -L/Users/adam/gmock-1.7.0/gtest/lib/.libs /usr/local/lib/libmpfr.dylib > /usr/local/lib/libgmp.dylib /usr/local/lib/libCGAL_Core.dylib > /usr/local/lib/libCGAL.dylib /usr/local/lib/libboost_thread-mt.dylib > /usr/local/lib/libboost_system-mt.dylib /usr/local/lib/libCGAL_Core.dylib > /usr/local/lib/libCGAL.dylib /usr/local/lib/libboost_thread-mt.dylib > /usr/local/lib/libboost_system-mt.dylib > -Wl,-rpath,/Users/adam/gmock-1.7.0/lib/.libs > -Wl,-rpath,/Users/adam/gmock-1.7.0/gtest/lib/.libs && : > Undefined symbols for architecture x86_64: > "docopt::docopt(std::__1::basic_string std::__1::char_traits, std::__1::allocator > const&, > std::__1::vector, > std::__1::allocator >, > std::__1::allocator std::__1::char_traits, std::__1::allocator > > > const&, bool, > std::__1::basic_string, > std::__1::allocator > const&, bool)", referenced from: > _main in cdt-docopt.cpp.o > "docopt::operator<<(std::__1::basic_ostream std::__1::char_traits >&, docopt::value const&)", referenced from: > _main in cdt-docopt.cpp.o > ld: symbol(s) not found for architecture x86_64 > clang: error: linker command failed with exit code 1 (use -v to see > invocation) > [10/13] Building CXX object > CMakeFiles/unittests.dir/unittests/Triangulated2SphereTest.cpp.o > ninja: build stopped: subcommand failed. > > Any suggestions? > > [1] https://github.com/acgetchell/CDT-plusplus/tree/docopt > [2] https://www.cgal.org > > Adam Getchell > about.me/adamgetchell > > -- Adam Getchell about.me/adamgetchell "Invincibility is in oneself, vulnerability in the opponent." -- Sun Tzu -------------- next part -------------- An HTML attachment was scrubbed... URL: From luca.gherardi at unibg.it Fri Dec 5 03:58:17 2014 From: luca.gherardi at unibg.it (Luca Gherardi) Date: Fri, 5 Dec 2014 09:58:17 +0100 Subject: [CMake] Generate Eclipse project with support for c++ 11 Message-ID: Hi all, I?m writing a CMake file for a project that should be compiled both in Ubuntu and OS X. I want to use eclipse as IDE, gcc and C++ 11. I read different threads that suggest how to enable C++ 11 in eclipse. According to them I included these lines in my CMake: set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++11 -Wall") if (${CMAKE_EXTRA_GENERATOR} MATCHES "Eclipse CDT4") set(CMAKE_CXX_COMPILER_ARG1 "-std=c++11" CACHE STRING "C++ version for eclipse" FORCE) set(CMAKE_ECLIPSE_VERSION "4.3" CACHE STRING "Eclipse version" FORCE) endif (${CMAKE_EXTRA_GENERATOR} MATCHES "Eclipse CDT4?) However, eclipse still set a wrong value for the symbol __cplusplus (199711L instead of 201103L I guess). For this reason eclipse is not able to index C++ 11 features such as shared pointer. Therefore I get a syntax error also if the code compiles. Any idea on how can I address this issue? Thanks, Luca -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam.getchell at gmail.com Fri Dec 5 04:05:50 2014 From: adam.getchell at gmail.com (Adam Getchell) Date: Fri, 5 Dec 2014 01:05:50 -0800 Subject: [CMake] Correct settings to add docopt.cpp to target list In-Reply-To: References: <7D7D2DBD-0834-48B1-9103-9B539F3A90C3@gmail.com> Message-ID: It turns out that CGAL's CGAL_CreateSingleSourceCGALProgram.cmake module handles this nicely: create_single_source_cgal_program( "src/cdt-docopt.cpp" "src/docopt/docopt.cpp") does the trick. Thanks for your consideration! On Thu, Dec 4, 2014 at 10:54 PM, Adam Getchell wrote: > I should note that I'm doing an out of source build, and that for my > project the following line works: > > ??[*adam*][Hapkido][*?*][docopt *?*][~/CDT-plusplus/build] > > ??? clang++ --std=c++11 --stdlib=libc++ -I ../src/docopt > ../src/docopt/docopt.cpp ../src/cdt-docopt.cpp -o cdt_docopt > > On Thu, Dec 4, 2014 at 9:30 PM, Adam Getchell > wrote: > >> Hello all, >> >> I?m trying to use the docopt.cpp parser for my project[1]: >> >> https://github.com/docopt/docopt.cpp >> >> The usual invocation to build works: >> >> ??[*adam*][Hapkido][*?*][docopt *?*][~/CDT-plusplus/src/docopt] >> ??? clang++ --std=c++11 --stdlib=libc++ -I . docopt.cpp >> examples/naval_fate.cpp -o naval_fate >> >> So, I want to add docopt.cpp and have the compiler look for header files >> in the same directory, and add that to my executable. >> >> So far, what I?ve attempted is to add the lines: >> >> include_directories (BEFORE "src/docopt") >> add_library(docopt.cpp "src/docopt/docopt.cpp?) >> >> My program uses CGAL[2], and all of those library headers are >> incorporated using the create_single_source_cgal_program function in the >> CGAL_CreateSingleSourceCGALProgram.cmake module. >> >> The error messages I?m getting correspond to the ones I get when >> docopt.cpp is not included: >> >> ??[*adam*][Hapkido][*?*][docopt *?*][~/CDT-plusplus/src/docopt] >> ??? clang++ --std=c++11 --stdlib=libc++ -I . examples/naval_fate.cpp -o >> naval_fate >> Undefined symbols for architecture x86_64: >> "docopt::docopt(std::__1::basic_string> std::__1::char_traits, std::__1::allocator > const&, >> std::__1::vector, >> std::__1::allocator >, >> std::__1::allocator> std::__1::char_traits, std::__1::allocator > > > const&, bool, >> std::__1::basic_string, >> std::__1::allocator > const&, bool)", referenced from: >> _main in naval_fate-780283.o >> "docopt::operator<<(std::__1::basic_ostream> std::__1::char_traits >&, docopt::value const&)", referenced from: >> _main in naval_fate-780283.o >> ld: symbol(s) not found for architecture x86_64 >> clang: error: linker command failed with exit code 1 (use -v to see >> invocation) >> >> Compare to: >> >> ??[*adam*][Hapkido][*?*][docopt *?*][~/CDT-plusplus] >> ??? ./build.sh >> -- The C compiler identification is AppleClang 6.0.0.6000054 >> -- The CXX compiler identification is AppleClang 6.0.0.6000054 >> -- Check for working C compiler using: Ninja >> -- Check for working C compiler using: Ninja -- works >> -- Detecting C compiler ABI info >> -- Detecting C compiler ABI info - done >> -- Check for working CXX compiler using: Ninja >> -- Check for working CXX compiler using: Ninja -- works >> -- Detecting CXX compiler ABI info >> -- Detecting CXX compiler ABI info - done >> -- Build type: Release >> -- USING CXXFLAGS = ' -O3 -DNDEBUG' >> -- USING EXEFLAGS = ' >> -Wl,-dylib_file,/System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib:/System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib >> ' >> -- Targetting Ninja >> -- Using /usr/bin/c++ compiler. >> -- DARWIN_VERSION=14 >> -- Mac Leopard detected >> -- Requested component: Core >> -- Requested component: MPFR >> -- Requested component: GMP >> -- Found Eigen3: /usr/local/include/eigen3 (found suitable version >> "3.2.2", minimum required is "3.1.0") >> -- Configuring done >> -- Generating done >> -- Build files have been written to: /Users/adam/CDT-plusplus/build >> [10/13] Linking CXX executable cdt-docopt >> FAILED: : && /usr/bin/c++ -O3 -DNDEBUG -Wl,-search_paths_first >> -Wl,-headerpad_max_install_names >> -Wl,-dylib_file,/System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib:/System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib >> CMakeFiles/cdt-docopt.dir/src/cdt-docopt.cpp.o -o cdt-docopt >> -L/Users/adam/gmock-1.7.0/lib/.libs >> -L/Users/adam/gmock-1.7.0/gtest/lib/.libs /usr/local/lib/libmpfr.dylib >> /usr/local/lib/libgmp.dylib /usr/local/lib/libCGAL_Core.dylib >> /usr/local/lib/libCGAL.dylib /usr/local/lib/libboost_thread-mt.dylib >> /usr/local/lib/libboost_system-mt.dylib /usr/local/lib/libCGAL_Core.dylib >> /usr/local/lib/libCGAL.dylib /usr/local/lib/libboost_thread-mt.dylib >> /usr/local/lib/libboost_system-mt.dylib >> -Wl,-rpath,/Users/adam/gmock-1.7.0/lib/.libs >> -Wl,-rpath,/Users/adam/gmock-1.7.0/gtest/lib/.libs && : >> Undefined symbols for architecture x86_64: >> "docopt::docopt(std::__1::basic_string> std::__1::char_traits, std::__1::allocator > const&, >> std::__1::vector, >> std::__1::allocator >, >> std::__1::allocator> std::__1::char_traits, std::__1::allocator > > > const&, bool, >> std::__1::basic_string, >> std::__1::allocator > const&, bool)", referenced from: >> _main in cdt-docopt.cpp.o >> "docopt::operator<<(std::__1::basic_ostream> std::__1::char_traits >&, docopt::value const&)", referenced from: >> _main in cdt-docopt.cpp.o >> ld: symbol(s) not found for architecture x86_64 >> clang: error: linker command failed with exit code 1 (use -v to see >> invocation) >> [10/13] Building CXX object >> CMakeFiles/unittests.dir/unittests/Triangulated2SphereTest.cpp.o >> ninja: build stopped: subcommand failed. >> >> Any suggestions? >> >> [1] https://github.com/acgetchell/CDT-plusplus/tree/docopt >> [2] https://www.cgal.org >> >> Adam Getchell >> about.me/adamgetchell >> >> > > > -- > Adam Getchell > about.me/adamgetchell > "Invincibility is in oneself, vulnerability in the opponent." -- Sun Tzu > -- Adam Getchell about.me/adamgetchell "Invincibility is in oneself, vulnerability in the opponent." -- Sun Tzu -------------- next part -------------- An HTML attachment was scrubbed... URL: From jzakrzewski at e2e.ch Fri Dec 5 03:58:28 2014 From: jzakrzewski at e2e.ch (Jakub Zakrzewski) Date: Fri, 5 Dec 2014 08:58:28 +0000 Subject: [CMake] Visual Studio 12 C++ Compiler Detection In-Reply-To: <088f168a820e4bba9252f3fa1dfa8d89@PA-EX2013-MBX02.vms.ad.varian.com> References: <088f168a820e4bba9252f3fa1dfa8d89@PA-EX2013-MBX02.vms.ad.varian.com> Message-ID: > So, it appears to find the compiler OK since it emits the correct compiler identification. But, the actual value of CMAKE_CXX_COMPILER is not usable. If you try to execute > C:/Program?./x86_amd64/cl.exe from within a CMake script or even from the command line, it will fail and produce the well-known ?0xc000007b? dialog (missing DLL). Unless you?ve sourced > vcvarsx86_amd64.bat, the correct environment variables are not set for this version of the compiler. > On the other hand, if I do ?cmake ?G NMake Makefiles?, I get what I expect: > Namely, it finds C:/Program?./amd64/cl.exe. > I would like to see how it is coming up with this version of the compiler which isn?t even in the PATH. Hi Allen, CMake does not pay attention to the PATH when you ask for VisualStudio generator. It simply finds it using it's internal logic. The generated projects are suitable for opening in the IDE. The NMake generator behaves much more like Unix Makefiles generator, so it is sensitive to the environment variables and remembers all variables it needs. -- Gruesse, Jakub -------------- next part -------------- An HTML attachment was scrubbed... URL: From petr.kmoch at gmail.com Fri Dec 5 05:46:03 2014 From: petr.kmoch at gmail.com (Petr Kmoch) Date: Fri, 5 Dec 2014 11:46:03 +0100 Subject: [CMake] Get native build command with CMake 3+ Message-ID: Hi all. I'm converting a small Makefile-based project to CMake. The project is not mine, so I am trying to match its existing buildsystem as closely as possible. One of the rules in the original Makefile is (simplified) as follows: examples: all make -C example_dir all This gives a target 'examples' in the top-level Makefile, which is not included in 'all', but can be used to build all examples. I would like to achieve something similar with CMake. I added example_dir/CMakeLists.txt, which includes a project() command and defines all the targets for example executables. In the toplevel CMakeList, I did this: # Add the subdirectory but don't include its targets by default add_subdirectory(example_dir EXCLUDE_FROM_ALL) # Add a custom target to build all examples add_custom_target(examples ???) I'm stuck at the custom target. What I need for its command is a generator-agnostic equivalent for 'make -C example_dir all' (or 'make -f example_dir/Makefile all'). I tried 'cmake --build ${CMAKE_CURRENT_BINARY_DIR}/example_dir ...', but this complains that example_dir does not contain a CMakeCache.txt (which is correct of course, it's not the toplevel directory). Then I remembered that build_command() can be used to get a command line to build a project; unfortunately, in 3.0 and later, this just returns 'cmake --build ...' and so is unusable in my situation. Is there a way to query CMake for the native command line (or something else) I could use to build the CMake-generated buildsystem in the subdirectory? I thought a bit about CMAKE_MAKE_PROGRAM, but that doesn't tell me anything about what arguments I should pass, and it's not even set on Visual Studio generators. As a workaround, I thought of not doing add_subdirectory() at all and instead adding a custom target with 'ctest --build-and-test ...', but I would prefer to configure & generate the two directories together. I plan to eventually add install() rules for the examples as well, and the examples also use one of the targets from the toplevel cmakelist in add_custom_command(OUTPUT ...), so I would really like to keep them as one CMake system. Is there a way to do so? Petr -------------- next part -------------- An HTML attachment was scrubbed... URL: From DLRdave at aol.com Fri Dec 5 08:59:51 2014 From: DLRdave at aol.com (David Cole) Date: Fri, 5 Dec 2014 08:59:51 -0500 Subject: [CMake] Get native build command with CMake 3+ In-Reply-To: References: Message-ID: Try: cmake --build . --target examples (where "." represents the current working directory, and assumes you're in the top level build tree...) On Fri, Dec 5, 2014 at 5:46 AM, Petr Kmoch wrote: > Hi all. > > I'm converting a small Makefile-based project to CMake. The project is not > mine, so I am trying to match its existing buildsystem as closely as > possible. > > One of the rules in the original Makefile is (simplified) as follows: > > examples: all > make -C example_dir all > > This gives a target 'examples' in the top-level Makefile, which is not > included in 'all', but can be used to build all examples. I would like to > achieve something similar with CMake. > > I added example_dir/CMakeLists.txt, which includes a project() command and > defines all the targets for example executables. In the toplevel CMakeList, > I did this: > > # Add the subdirectory but don't include its targets by default > add_subdirectory(example_dir EXCLUDE_FROM_ALL) > > # Add a custom target to build all examples > add_custom_target(examples ???) > > I'm stuck at the custom target. What I need for its command is a > generator-agnostic equivalent for 'make -C example_dir all' (or 'make -f > example_dir/Makefile all'). > > I tried 'cmake --build ${CMAKE_CURRENT_BINARY_DIR}/example_dir ...', but > this complains that example_dir does not contain a CMakeCache.txt (which is > correct of course, it's not the toplevel directory). Then I remembered that > build_command() can be used to get a command line to build a project; > unfortunately, in 3.0 and later, this just returns 'cmake --build ...' and > so is unusable in my situation. > > Is there a way to query CMake for the native command line (or something > else) I could use to build the CMake-generated buildsystem in the > subdirectory? I thought a bit about CMAKE_MAKE_PROGRAM, but that doesn't > tell me anything about what arguments I should pass, and it's not even set > on Visual Studio generators. > > As a workaround, I thought of not doing add_subdirectory() at all and > instead adding a custom target with 'ctest --build-and-test ...', but I > would prefer to configure & generate the two directories together. I plan to > eventually add install() rules for the examples as well, and the examples > also use one of the targets from the toplevel cmakelist in > add_custom_command(OUTPUT ...), so I would really like to keep them as one > CMake system. Is there a way to do so? > > Petr > > -- > > 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 From Allen.Barnett at varian.com Fri Dec 5 09:06:18 2014 From: Allen.Barnett at varian.com (Allen Barnett) Date: Fri, 5 Dec 2014 14:06:18 +0000 Subject: [CMake] Visual Studio 12 C++ Compiler Detection In-Reply-To: References: <088f168a820e4bba9252f3fa1dfa8d89@PA-EX2013-MBX02.vms.ad.varian.com> Message-ID: <0cab5fa12c014907a263caa2c62ffdcd@PA-EX2013-MBX02.vms.ad.varian.com> Hi Jakub: Thanks for the tip. What is the proper way to execute the compiler during the initial configure step? try_compile? Thanks, Allen > So, it appears to find the compiler OK since it emits the correct compiler identification. But, the actual value of CMAKE_CXX_COMPILER is not usable. If you try to execute > C:/Program?./x86_amd64/cl.exe from within a CMake script or even from the command line, it will fail and produce the well-known ?0xc000007b? dialog (missing DLL). Unless you?ve sourced > vcvarsx86_amd64.bat, the correct environment variables are not set for this version of the compiler. > On the other hand, if I do ?cmake ?G NMake Makefiles?, I get what I expect: > Namely, it finds C:/Program?./amd64/cl.exe. > I would like to see how it is coming up with this version of the compiler which isn?t even in the PATH. Hi Allen, CMake does not pay attention to the PATH when you ask for VisualStudio generator. It simply finds it using it's internal logic. The generated projects are suitable for opening in the IDE. The NMake generator behaves much more like Unix Makefiles generator, so it is sensitive to the environment variables and remembers all variables it needs. From petr.kmoch at gmail.com Fri Dec 5 09:23:46 2014 From: petr.kmoch at gmail.com (Petr Kmoch) Date: Fri, 5 Dec 2014 15:23:46 +0100 Subject: [CMake] Get native build command with CMake 3+ In-Reply-To: References: Message-ID: I assume you actually meant 'cmake --build . --target example_dir', the name of the directory. 'examples' is the name of the custom target; if that target's command was to build itself, I believe it would become a fork bomb. Anyway, I tried it with the directory name, it doesn't work. I'm generating with VS2008, and devenv was complaining about "Invalid project." Which kind of makes sense, there is no 'example_dir' project in the solution. On Fri, Dec 5, 2014 at 2:59 PM, David Cole wrote: > Try: > > cmake --build . --target examples > > (where "." represents the current working directory, and assumes > you're in the top level build tree...) > > > On Fri, Dec 5, 2014 at 5:46 AM, Petr Kmoch wrote: > > Hi all. > > > > I'm converting a small Makefile-based project to CMake. The project is > not > > mine, so I am trying to match its existing buildsystem as closely as > > possible. > > > > One of the rules in the original Makefile is (simplified) as follows: > > > > examples: all > > make -C example_dir all > > > > This gives a target 'examples' in the top-level Makefile, which is not > > included in 'all', but can be used to build all examples. I would like to > > achieve something similar with CMake. > > > > I added example_dir/CMakeLists.txt, which includes a project() command > and > > defines all the targets for example executables. In the toplevel > CMakeList, > > I did this: > > > > # Add the subdirectory but don't include its targets by default > > add_subdirectory(example_dir EXCLUDE_FROM_ALL) > > > > # Add a custom target to build all examples > > add_custom_target(examples ???) > > > > I'm stuck at the custom target. What I need for its command is a > > generator-agnostic equivalent for 'make -C example_dir all' (or 'make -f > > example_dir/Makefile all'). > > > > I tried 'cmake --build ${CMAKE_CURRENT_BINARY_DIR}/example_dir ...', but > > this complains that example_dir does not contain a CMakeCache.txt (which > is > > correct of course, it's not the toplevel directory). Then I remembered > that > > build_command() can be used to get a command line to build a project; > > unfortunately, in 3.0 and later, this just returns 'cmake --build ...' > and > > so is unusable in my situation. > > > > Is there a way to query CMake for the native command line (or something > > else) I could use to build the CMake-generated buildsystem in the > > subdirectory? I thought a bit about CMAKE_MAKE_PROGRAM, but that doesn't > > tell me anything about what arguments I should pass, and it's not even > set > > on Visual Studio generators. > > > > As a workaround, I thought of not doing add_subdirectory() at all and > > instead adding a custom target with 'ctest --build-and-test ...', but I > > would prefer to configure & generate the two directories together. I > plan to > > eventually add install() rules for the examples as well, and the examples > > also use one of the targets from the toplevel cmakelist in > > add_custom_command(OUTPUT ...), so I would really like to keep them as > one > > CMake system. Is there a way to do so? > > > > Petr > > > > -- > > > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From micha.hergarden at gmail.com Fri Dec 5 09:42:58 2014 From: micha.hergarden at gmail.com (Micha Hergarden) Date: Fri, 5 Dec 2014 15:42:58 +0100 Subject: [CMake] Get native build command with CMake 3+ In-Reply-To: References: Message-ID: Hello Petr, In your example the original make command simply states that it should switch to the example_dir and build an 'all' target there. It does not specify how this target is build. That is the part that should end up in your custom command. You can name the command 'examples', set WORKING_DIR to the example_dir and then perform the steps needed to build. If you want that to be a separate cmake based solution, you may want to take a look at the external_project module. With kind regards, Micha Hergarden 2014-12-05 11:46 GMT+01:00 Petr Kmoch : > Hi all. > > I'm converting a small Makefile-based project to CMake. The project is not > mine, so I am trying to match its existing buildsystem as closely as > possible. > > One of the rules in the original Makefile is (simplified) as follows: > > examples: all > make -C example_dir all > > This gives a target 'examples' in the top-level Makefile, which is not > included in 'all', but can be used to build all examples. I would like to > achieve something similar with CMake. > > I added example_dir/CMakeLists.txt, which includes a project() command and > defines all the targets for example executables. In the toplevel CMakeList, > I did this: > > # Add the subdirectory but don't include its targets by default > add_subdirectory(example_dir EXCLUDE_FROM_ALL) > > # Add a custom target to build all examples > add_custom_target(examples ???) > > I'm stuck at the custom target. What I need for its command is a > generator-agnostic equivalent for 'make -C example_dir all' (or 'make -f > example_dir/Makefile all'). > > I tried 'cmake --build ${CMAKE_CURRENT_BINARY_DIR}/example_dir ...', but > this complains that example_dir does not contain a CMakeCache.txt (which is > correct of course, it's not the toplevel directory). Then I remembered that > build_command() can be used to get a command line to build a project; > unfortunately, in 3.0 and later, this just returns 'cmake --build ...' and > so is unusable in my situation. > > Is there a way to query CMake for the native command line (or something > else) I could use to build the CMake-generated buildsystem in the > subdirectory? I thought a bit about CMAKE_MAKE_PROGRAM, but that doesn't > tell me anything about what arguments I should pass, and it's not even set > on Visual Studio generators. > > As a workaround, I thought of not doing add_subdirectory() at all and > instead adding a custom target with 'ctest --build-and-test ...', but I > would prefer to configure & generate the two directories together. I plan > to eventually add install() rules for the examples as well, and the > examples also use one of the targets from the toplevel cmakelist in > add_custom_command(OUTPUT ...), so I would really like to keep them as one > CMake system. Is there a way to do so? > > Petr > > -- > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From post at hendrik-sattler.de Fri Dec 5 09:50:22 2014 From: post at hendrik-sattler.de (Hendrik Sattler) Date: Fri, 05 Dec 2014 15:50:22 +0100 Subject: [CMake] Get native build command with CMake 3+ In-Reply-To: References: Message-ID: Hi, this original makefile rule was probably just a simplification. Make your custom target depend on all example targets which link the desired parts, then you get what the original makefile author just didn't want to do manually: having built all examples and their dependencies. And it's less ugly... HS Am 5. Dezember 2014 11:46:03 MEZ, schrieb Petr Kmoch : >Hi all. > >I'm converting a small Makefile-based project to CMake. The project is >not >mine, so I am trying to match its existing buildsystem as closely as >possible. > >One of the rules in the original Makefile is (simplified) as follows: > >examples: all > make -C example_dir all > >This gives a target 'examples' in the top-level Makefile, which is not >included in 'all', but can be used to build all examples. I would like >to >achieve something similar with CMake. > >I added example_dir/CMakeLists.txt, which includes a project() command >and >defines all the targets for example executables. In the toplevel >CMakeList, >I did this: > ># Add the subdirectory but don't include its targets by default >add_subdirectory(example_dir EXCLUDE_FROM_ALL) > ># Add a custom target to build all examples >add_custom_target(examples ???) > >I'm stuck at the custom target. What I need for its command is a >generator-agnostic equivalent for 'make -C example_dir all' (or 'make >-f >example_dir/Makefile all'). > >I tried 'cmake --build ${CMAKE_CURRENT_BINARY_DIR}/example_dir ...', >but >this complains that example_dir does not contain a CMakeCache.txt >(which is >correct of course, it's not the toplevel directory). Then I remembered >that >build_command() can be used to get a command line to build a project; >unfortunately, in 3.0 and later, this just returns 'cmake --build ...' >and >so is unusable in my situation. > >Is there a way to query CMake for the native command line (or something >else) I could use to build the CMake-generated buildsystem in the >subdirectory? I thought a bit about CMAKE_MAKE_PROGRAM, but that >doesn't >tell me anything about what arguments I should pass, and it's not even >set >on Visual Studio generators. > >As a workaround, I thought of not doing add_subdirectory() at all and >instead adding a custom target with 'ctest --build-and-test ...', but I >would prefer to configure & generate the two directories together. I >plan >to eventually add install() rules for the examples as well, and the >examples also use one of the targets from the toplevel cmakelist in >add_custom_command(OUTPUT ...), so I would really like to keep them as >one >CMake system. Is there a way to do so? > >Petr > > >------------------------------------------------------------------------ > >-- > >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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From petr.kmoch at gmail.com Fri Dec 5 10:06:56 2014 From: petr.kmoch at gmail.com (Petr Kmoch) Date: Fri, 5 Dec 2014 16:06:56 +0100 Subject: [CMake] Get native build command with CMake 3+ In-Reply-To: References: Message-ID: Hi Micha. I understand how the original works, and I know I can work around it with a separate buildsystem (using e.g. ExternalProject_Add() or ctest --build-and-test). I was just wondering: since CMake generates a .sln (or Makefile) in the subdirectory (because I put a project() call in there), does it somehow offer a way to build the 'all' target from that solution (or Makefile)? Petr On Fri, Dec 5, 2014 at 3:42 PM, Micha Hergarden wrote: > Hello Petr, > > In your example the original make command simply states that it should > switch to the example_dir and build an 'all' target there. It does not > specify how this target is build. That is the part that should end up in > your custom command. You can name the command 'examples', set WORKING_DIR > to the example_dir and then perform the steps needed to build. If you want > that to be a separate cmake based solution, you may want to take a look at > the external_project module. > > With kind regards, > Micha Hergarden > > 2014-12-05 11:46 GMT+01:00 Petr Kmoch : > >> Hi all. >> >> I'm converting a small Makefile-based project to CMake. The project is >> not mine, so I am trying to match its existing buildsystem as closely as >> possible. >> >> One of the rules in the original Makefile is (simplified) as follows: >> >> examples: all >> make -C example_dir all >> >> This gives a target 'examples' in the top-level Makefile, which is not >> included in 'all', but can be used to build all examples. I would like to >> achieve something similar with CMake. >> >> I added example_dir/CMakeLists.txt, which includes a project() command >> and defines all the targets for example executables. In the toplevel >> CMakeList, I did this: >> >> # Add the subdirectory but don't include its targets by default >> add_subdirectory(example_dir EXCLUDE_FROM_ALL) >> >> # Add a custom target to build all examples >> add_custom_target(examples ???) >> >> I'm stuck at the custom target. What I need for its command is a >> generator-agnostic equivalent for 'make -C example_dir all' (or 'make -f >> example_dir/Makefile all'). >> >> I tried 'cmake --build ${CMAKE_CURRENT_BINARY_DIR}/example_dir ...', but >> this complains that example_dir does not contain a CMakeCache.txt (which is >> correct of course, it's not the toplevel directory). Then I remembered that >> build_command() can be used to get a command line to build a project; >> unfortunately, in 3.0 and later, this just returns 'cmake --build ...' and >> so is unusable in my situation. >> >> Is there a way to query CMake for the native command line (or something >> else) I could use to build the CMake-generated buildsystem in the >> subdirectory? I thought a bit about CMAKE_MAKE_PROGRAM, but that doesn't >> tell me anything about what arguments I should pass, and it's not even set >> on Visual Studio generators. >> >> As a workaround, I thought of not doing add_subdirectory() at all and >> instead adding a custom target with 'ctest --build-and-test ...', but I >> would prefer to configure & generate the two directories together. I plan >> to eventually add install() rules for the examples as well, and the >> examples also use one of the targets from the toplevel cmakelist in >> add_custom_command(OUTPUT ...), so I would really like to keep them as one >> CMake system. Is there a way to do so? >> >> Petr >> >> -- >> >> 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 >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From DLRdave at aol.com Fri Dec 5 10:19:34 2014 From: DLRdave at aol.com (David Cole) Date: Fri, 5 Dec 2014 10:19:34 -0500 Subject: [CMake] Get native build command with CMake 3+ In-Reply-To: References: Message-ID: No, I meant exactly what I said. --target takes a CMake target name. HTH, D On Fri, Dec 5, 2014 at 9:23 AM, Petr Kmoch wrote: > I assume you actually meant 'cmake --build . --target example_dir', the name > of the directory. 'examples' is the name of the custom target; if that > target's command was to build itself, I believe it would become a fork bomb. > > Anyway, I tried it with the directory name, it doesn't work. I'm generating > with VS2008, and devenv was complaining about "Invalid project." Which kind > of makes sense, there is no 'example_dir' project in the solution. > > On Fri, Dec 5, 2014 at 2:59 PM, David Cole wrote: >> >> Try: >> >> cmake --build . --target examples >> >> (where "." represents the current working directory, and assumes >> you're in the top level build tree...) >> >> >> On Fri, Dec 5, 2014 at 5:46 AM, Petr Kmoch wrote: >> > Hi all. >> > >> > I'm converting a small Makefile-based project to CMake. The project is >> > not >> > mine, so I am trying to match its existing buildsystem as closely as >> > possible. >> > >> > One of the rules in the original Makefile is (simplified) as follows: >> > >> > examples: all >> > make -C example_dir all >> > >> > This gives a target 'examples' in the top-level Makefile, which is not >> > included in 'all', but can be used to build all examples. I would like >> > to >> > achieve something similar with CMake. >> > >> > I added example_dir/CMakeLists.txt, which includes a project() command >> > and >> > defines all the targets for example executables. In the toplevel >> > CMakeList, >> > I did this: >> > >> > # Add the subdirectory but don't include its targets by default >> > add_subdirectory(example_dir EXCLUDE_FROM_ALL) >> > >> > # Add a custom target to build all examples >> > add_custom_target(examples ???) >> > >> > I'm stuck at the custom target. What I need for its command is a >> > generator-agnostic equivalent for 'make -C example_dir all' (or 'make -f >> > example_dir/Makefile all'). >> > >> > I tried 'cmake --build ${CMAKE_CURRENT_BINARY_DIR}/example_dir ...', but >> > this complains that example_dir does not contain a CMakeCache.txt (which >> > is >> > correct of course, it's not the toplevel directory). Then I remembered >> > that >> > build_command() can be used to get a command line to build a project; >> > unfortunately, in 3.0 and later, this just returns 'cmake --build ...' >> > and >> > so is unusable in my situation. >> > >> > Is there a way to query CMake for the native command line (or something >> > else) I could use to build the CMake-generated buildsystem in the >> > subdirectory? I thought a bit about CMAKE_MAKE_PROGRAM, but that doesn't >> > tell me anything about what arguments I should pass, and it's not even >> > set >> > on Visual Studio generators. >> > >> > As a workaround, I thought of not doing add_subdirectory() at all and >> > instead adding a custom target with 'ctest --build-and-test ...', but I >> > would prefer to configure & generate the two directories together. I >> > plan to >> > eventually add install() rules for the examples as well, and the >> > examples >> > also use one of the targets from the toplevel cmakelist in >> > add_custom_command(OUTPUT ...), so I would really like to keep them as >> > one >> > CMake system. Is there a way to do so? >> > >> > Petr >> > >> > -- >> > >> > 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 > > From petr.kmoch at gmail.com Fri Dec 5 10:41:20 2014 From: petr.kmoch at gmail.com (Petr Kmoch) Date: Fri, 5 Dec 2014 16:41:20 +0100 Subject: [CMake] Get native build command with CMake 3+ In-Reply-To: References: Message-ID: OK, sorry for misunderstanding. But then I don't have a target like this. Basically, I am trying to create a custom target that would do this: # When using Makefile generator add_custom_target( examples COMMAND make -C example_dir all VERBATIM ) # When using vs2008 generator add_custom_target( examples COMMAND devenv Examples.sln /Build /Project:ALL_BUILD /ProjectConfig:$ WORKING_DIRECTORY example_dir VERBATIM ) # When using vs2010 generator, use msbuild # etc... without having to hardcode the logic (CMake must have this info inside somewhere). So I am effectively trying to *create* the target 'examples'. My current solution is to make the custom target empty and have it depend on all the targets in example_dir. But this has two consequences I don't like: 1. I have to collect the target names in example_dir/CMakeLists.txt, as it has to communicate them to its parent 2. Being dependecies, the targets from example_dir show up in the toplevel solution file/Makefile. I was trying to prevent that. I looked at the commit message which changed build_command() from returning the native command line to returning cmake --build, at it mentions the fact that sometimes, the native tool has to be selected based on the contents of the solution (devenv instead of msbuild when ifort is involved). So I guess the only way to get what I want would be with a generator expression (one which does not currently exist). I guess I'll stick to my workaround with dependencies. But thanks for your help. Petr On Fri, Dec 5, 2014 at 4:19 PM, David Cole wrote: > No, I meant exactly what I said. > > --target takes a CMake target name. > > > HTH, > D > > > > On Fri, Dec 5, 2014 at 9:23 AM, Petr Kmoch wrote: > > I assume you actually meant 'cmake --build . --target example_dir', the > name > > of the directory. 'examples' is the name of the custom target; if that > > target's command was to build itself, I believe it would become a fork > bomb. > > > > Anyway, I tried it with the directory name, it doesn't work. I'm > generating > > with VS2008, and devenv was complaining about "Invalid project." Which > kind > > of makes sense, there is no 'example_dir' project in the solution. > > > > On Fri, Dec 5, 2014 at 2:59 PM, David Cole wrote: > >> > >> Try: > >> > >> cmake --build . --target examples > >> > >> (where "." represents the current working directory, and assumes > >> you're in the top level build tree...) > >> > >> > >> On Fri, Dec 5, 2014 at 5:46 AM, Petr Kmoch > wrote: > >> > Hi all. > >> > > >> > I'm converting a small Makefile-based project to CMake. The project is > >> > not > >> > mine, so I am trying to match its existing buildsystem as closely as > >> > possible. > >> > > >> > One of the rules in the original Makefile is (simplified) as follows: > >> > > >> > examples: all > >> > make -C example_dir all > >> > > >> > This gives a target 'examples' in the top-level Makefile, which is not > >> > included in 'all', but can be used to build all examples. I would like > >> > to > >> > achieve something similar with CMake. > >> > > >> > I added example_dir/CMakeLists.txt, which includes a project() command > >> > and > >> > defines all the targets for example executables. In the toplevel > >> > CMakeList, > >> > I did this: > >> > > >> > # Add the subdirectory but don't include its targets by default > >> > add_subdirectory(example_dir EXCLUDE_FROM_ALL) > >> > > >> > # Add a custom target to build all examples > >> > add_custom_target(examples ???) > >> > > >> > I'm stuck at the custom target. What I need for its command is a > >> > generator-agnostic equivalent for 'make -C example_dir all' (or 'make > -f > >> > example_dir/Makefile all'). > >> > > >> > I tried 'cmake --build ${CMAKE_CURRENT_BINARY_DIR}/example_dir ...', > but > >> > this complains that example_dir does not contain a CMakeCache.txt > (which > >> > is > >> > correct of course, it's not the toplevel directory). Then I remembered > >> > that > >> > build_command() can be used to get a command line to build a project; > >> > unfortunately, in 3.0 and later, this just returns 'cmake --build ...' > >> > and > >> > so is unusable in my situation. > >> > > >> > Is there a way to query CMake for the native command line (or > something > >> > else) I could use to build the CMake-generated buildsystem in the > >> > subdirectory? I thought a bit about CMAKE_MAKE_PROGRAM, but that > doesn't > >> > tell me anything about what arguments I should pass, and it's not even > >> > set > >> > on Visual Studio generators. > >> > > >> > As a workaround, I thought of not doing add_subdirectory() at all and > >> > instead adding a custom target with 'ctest --build-and-test ...', but > I > >> > would prefer to configure & generate the two directories together. I > >> > plan to > >> > eventually add install() rules for the examples as well, and the > >> > examples > >> > also use one of the targets from the toplevel cmakelist in > >> > add_custom_command(OUTPUT ...), so I would really like to keep them as > >> > one > >> > CMake system. Is there a way to do so? > >> > > >> > Petr > >> > > >> > -- > >> > > >> > 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 > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mellery451 at gmail.com Fri Dec 5 13:31:47 2014 From: mellery451 at gmail.com (Michael Ellery) Date: Fri, 5 Dec 2014 10:31:47 -0800 Subject: [CMake] unexpected behavior with TARGET_FILE_DIR and Visual Studio 2010 Message-ID: <2E8A0F00-5AC9-4270-9620-8CFB9DD51F06@gmail.com> Hi cmake-users, I have the following setup: CMAKE: 3.0.2 Visual Studio 2010 In one of my cmake files, I?m trying to create a preprocessor definition based on the TARGET_FILE_DIR of a different target ? so I?m trying this: target_compile_definitions(my_target_B PUBLIC -DTARGET_A_DIR="$" ) When I run this for my visual studio build (2010), I get the following settings created in the project file: test/my_target_B.vcxproj:95: WIN32;_WINDOWS;_DEBUG;_DEBUG;TARGET_A_DIR="Y:/work/some_lib/bld_win/src/my_target_A/Debug";CMAKE_INTDIR="Debug";%(PreprocessorDefinitions) test/my_target_B.vcxproj:99: WIN32;_WINDOWS;_DEBUG;_DEBUG;TARGET_A_DIR=\"Y:/work/some_lib/bld_win/src/my_target_A/Debug\";CMAKE_INTDIR=\"Debug\";%(PreprocessorDefinitions) test/my_target_B.vcxproj:392: WIN32;_WINDOWS;NDEBUG;TARGET_A_DIR="Y:/work/some_lib/bld_win/src/my_target_A/Debug";CMAKE_INTDIR="Release";%(PreprocessorDefinitions) test/my_target_B.vcxproj:396: WIN32;_WINDOWS;NDEBUG;TARGET_A_DIR=\"Y:/work/some_lib/bld_win/src/my_target_A/Debug\";CMAKE_INTDIR=\"Release\";%(PreprocessorDefinitions) test/my_target_B.vcxproj:689: WIN32;_WINDOWS;NDEBUG;TARGET_A_DIR="Y:/work/some_lib/bld_win/src/my_target_A/Debug";CMAKE_INTDIR="MinSizeRel";%(PreprocessorDefinitions) test/my_target_B.vcxproj:693: WIN32;_WINDOWS;NDEBUG;TARGET_A_DIR=\"Y:/work/some_lib/bld_win/src/my_target_A/Debug\";CMAKE_INTDIR=\"MinSizeRel\";%(PreprocessorDefinitions) test/my_target_B.vcxproj:986: WIN32;_WINDOWS;NDEBUG;TARGET_A_DIR="Y:/work/some_lib/bld_win/src/my_target_A/Debug";CMAKE_INTDIR="RelWithDebInfo";%(PreprocessorDefinitions) test/my_target_B.vcxproj:990: WIN32;_WINDOWS;NDEBUG;TARGET_A_DIR=\"Y:/work/some_lib/bld_win/src/my_target_A/Debug\";CMAKE_INTDIR=\"RelWithDebInfo\";%(PreprocessorDefinitions) in other words, it looks like the generator expression is only being evaluated once (as Debug) and then used for ALL of the build configs in the visual studio project. This isn?t exactly what I want since I need the actual output dir for each config to be the correct one for that build type. This same thing works fine on my linux/makefile build since the output dir is the same for all builds. Can anyone offer advice? Is this how the visual studio generator works or is this possibly a bug in CMake? Thanks, Mike -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: From cxjohnson at gmail.com Fri Dec 5 15:06:51 2014 From: cxjohnson at gmail.com (Chris Johnson) Date: Fri, 5 Dec 2014 14:06:51 -0600 Subject: [CMake] project directive overwrites CMAKE_INSTALL_PREFIX? In-Reply-To: References: Message-ID: Strangely, running "cmake -DCMAKE_INSTALL_PREFIX=/some/path" does NOT rewrite the cmake_install.cmake, but does rewrite the CMakeCache.txt and other files. The result is a bad install path won't go away until one manually removes the cmake_install.cmake file(s). On Thu, Dec 4, 2014 at 9:48 PM, J Decker wrote: > I find it's better to define CMAKE_INSTALL_PREFIX on the command line when > building > > I do have this bit of code... > > IF(CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT) > SET(CMAKE_INSTALL_PREFIX > ${CMAKE_BINARY_DIR}/../${CMAKE_BUILD_TYPE}_out CACHE PATH "Install > default 'out' in this directory." FORCE > ) > ENDIF(CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT) > > > which keeps it from overwriting an already set value (from the command > line); and make sure it's in the cache so cmake-gui can edit it... > > (if project() does something with cmake_isnstall_prefix might also be a > bug) > > On Thu, Dec 4, 2014 at 7:27 PM, Chris Johnson wrote: > >> I have a global include file used by all of the CMakeLists.txt files in >> my project. In it, I set the value of CMAKE_INSTALL_PREFIX, as well as a >> number of other variables and functions. >> >> In my CMakeLists.txt file, I had this: >> >> cmake_minimum_require(VERSION 2.8.4) >> include(global.inc) >> project(whatever) >> >> When I run cmake, the value of CMAKE_INSTALL_PREFIX is lost! Instead, in >> the resulting cmake_install.cmake file has been defaulted back to >> /usr/local which is completely wrong. >> >> However, if I change the order to this: >> >> cmake_minimum_require(VERSION 2.8.4) >> project(whatever) >> include(global.inc) >> >> It appears to work. >> >> I find nothing in the documentation saying that the project() directive >> will set CMAKE_INSTALL_PREFIX. >> >> Even more strangely, if I run cmake a second time with the first >> configuration (include before project), it will rewrite cmake_install.cmake >> with the correct value. >> ? ? >> That is, the behavior of cmake appears to be different based on whether >> the build directory is empty or already contains cmake_install.cmake and >> CMakeCache.txt files >> ?, even though they contain the wrong path value for >> CMAKE_INSTALL_PREFIX.? >> >> What is going on here? >> >> >> >> >> >> >> -- >> >> 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 >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From apoorva.gaddagimath at markit.com Fri Dec 5 16:11:53 2014 From: apoorva.gaddagimath at markit.com (Apoorva Gaddagimath) Date: Fri, 5 Dec 2014 21:11:53 +0000 Subject: [CMake] Common language runtime Message-ID: <8c3a7d2d9586445ba5720bfffe6821d0@RIC1PDMSGDAG01.markit.partners> Hi everyone, I'm trying to add a .NET assembly reference to my CMake project. Various forums on Google suggested to use /clr. The problem I've found, is that while CMake sets the "Common Language RunTime Support" option in the C/C++ section of the configuration properties if "/clr" is in the CXX_FLAGS, it does not set the "Common Language RunTime Support" in the general configuration properties, and that causes problems with linking .NET references. Is there a different way to do this or a different approach> Would greatly appreciate any help on this. Thanks Apoorva Gaddagimath Software Engineer Markit On Demand Markit 5718 Central Avenue Boulder, CO 80301 +1 720-648-4907 apoorva.gaddagimath at markit.com www.markit.com ________________________________ This e-mail, including accompanying communications and attachments, is strictly confidential and only for the intended recipient. Any retention, use or disclosure not expressly authorised by Markit is prohibited. This email is subject to all waivers and other terms at the following link: http://www.markit.com/en/about/legal/email-disclaimer.page Please visit http://www.markit.com/en/about/contact/contact-us.page for contact information on our offices worldwide. -------------- next part -------------- An HTML attachment was scrubbed... URL: From d3ck0r at gmail.com Fri Dec 5 16:38:47 2014 From: d3ck0r at gmail.com (J Decker) Date: Fri, 5 Dec 2014 13:38:47 -0800 Subject: [CMake] Common language runtime In-Reply-To: <8c3a7d2d9586445ba5720bfffe6821d0@RIC1PDMSGDAG01.markit.partners> References: <8c3a7d2d9586445ba5720bfffe6821d0@RIC1PDMSGDAG01.markit.partners> Message-ID: To enable compiling as/with CLR... SET_TARGET_PROPERTIES(bag PROPERTIES COMPILE_FLAGS "/CLR" ) # need to set unicode characters... add_definitions( -D_UNICODE -DUNICODE ) string( REPLACE "/EHsc" "" CMAKE_CXX_FLAGS_INIT ${CMAKE_CXX_FLAGS_INIT} ) string( REPLACE "/EHsc" "" CMAKE_C_FLAGS_INIT ${CMAKE_C_FLAGS_INIT} ) string( REPLACE "/EHs" "" CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS_INIT} ) string( REPLACE "/EHs" "" CMAKE_C_FLAGS_INIT ${CMAKE_C_FLAGS_INIT} ) string( REPLACE "/RTC1" "" CMAKE_CXX_FLAGS_DEBUG ${CMAKE_CXX_FLAGS_DEBUG} ) # cannot set CLR for C code anyway; only C++ #string( REPLACE "/RTC1" "/CLR" CMAKE_C_FLAGS_DEBUG ${CMAKE_C_FLAGS_DEBUG} ) set( FORCE_CXX ON ) force_cxx flag also forces compiling C as C++..... set_source_files_properties(${_SOURCES} PROPERTIES LANGUAGE CXX ) On Fri, Dec 5, 2014 at 1:11 PM, Apoorva Gaddagimath < apoorva.gaddagimath at markit.com> wrote: > Hi everyone, > > I?m trying to add a .NET assembly reference to my CMake project. Various > forums on Google suggested to use /clr. The problem I've found, is that > while CMake sets the "Common Language RunTime Support" option in the C/C++ > section of the configuration properties if "/clr" is in the CXX_FLAGS, it > does not set the "Common Language RunTime Support" in the general > configuration properties, and that causes problems with linking .NET > references. Is there a different way to do this or a different approach> > Would greatly appreciate any help on this. > > > > Thanks > > > > Apoorva Gaddagimath > > Software Engineer > > Markit On Demand > > > > Markit > > > > 5718 Central Avenue > > Boulder, CO 80301 > > +1 720-648-4907 > > apoorva.gaddagimath at markit.com > > www.markit.com > > > > ------------------------------ > > This e-mail, including accompanying communications and attachments, is > strictly confidential and only for the intended recipient. Any retention, > use or disclosure not expressly authorised by Markit is prohibited. This > email is subject to all waivers and other terms at the following link: > http://www.markit.com/en/about/legal/email-disclaimer.page > > Please visit http://www.markit.com/en/about/contact/contact-us.page for > contact information on our offices worldwide. > > -- > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From d3ck0r at gmail.com Fri Dec 5 16:43:32 2014 From: d3ck0r at gmail.com (J Decker) Date: Fri, 5 Dec 2014 13:43:32 -0800 Subject: [CMake] Get native build command with CMake 3+ In-Reply-To: References: Message-ID: Isn't it as smiple as add_subdirectory( examples_dir ) which has it's own CMakeLists? Does it really have to build as an extra step or would OPTION( BUILD_EXAMPLES "Build Examples?" ON ) .... if( BUILD_EXAMPLES) add_subdirectory( examples_dir) endif( BUILD_EXAMPLES) On Fri, Dec 5, 2014 at 7:41 AM, Petr Kmoch wrote: > OK, sorry for misunderstanding. But then I don't have a target like this. > Basically, I am trying to create a custom target that would do this: > > # When using Makefile generator > add_custom_target( > examples > COMMAND make -C example_dir all > VERBATIM > ) > > # When using vs2008 generator > add_custom_target( > examples > COMMAND devenv Examples.sln /Build /Project:ALL_BUILD > /ProjectConfig:$ > WORKING_DIRECTORY example_dir > VERBATIM > ) > > # When using vs2010 generator, use msbuild > # etc... > > without having to hardcode the logic (CMake must have this info inside > somewhere). So I am effectively trying to *create* the target 'examples'. > > My current solution is to make the custom target empty and have it depend > on all the targets in example_dir. But this has two consequences I don't > like: > 1. I have to collect the target names in example_dir/CMakeLists.txt, as it > has to communicate them to its parent > 2. Being dependecies, the targets from example_dir show up in the toplevel > solution file/Makefile. I was trying to prevent that. > > I looked at the commit message which changed build_command() from > returning the native command line to returning cmake --build, at it > mentions the fact that sometimes, the native tool has to be selected based > on the contents of the solution (devenv instead of msbuild when ifort is > involved). So I guess the only way to get what I want would be with a > generator expression (one which does not currently exist). > > I guess I'll stick to my workaround with dependencies. But thanks for your > help. > > Petr > > On Fri, Dec 5, 2014 at 4:19 PM, David Cole wrote: > >> No, I meant exactly what I said. >> >> --target takes a CMake target name. >> >> >> HTH, >> D >> >> >> >> On Fri, Dec 5, 2014 at 9:23 AM, Petr Kmoch wrote: >> > I assume you actually meant 'cmake --build . --target example_dir', the >> name >> > of the directory. 'examples' is the name of the custom target; if that >> > target's command was to build itself, I believe it would become a fork >> bomb. >> > >> > Anyway, I tried it with the directory name, it doesn't work. I'm >> generating >> > with VS2008, and devenv was complaining about "Invalid project." Which >> kind >> > of makes sense, there is no 'example_dir' project in the solution. >> > >> > On Fri, Dec 5, 2014 at 2:59 PM, David Cole wrote: >> >> >> >> Try: >> >> >> >> cmake --build . --target examples >> >> >> >> (where "." represents the current working directory, and assumes >> >> you're in the top level build tree...) >> >> >> >> >> >> On Fri, Dec 5, 2014 at 5:46 AM, Petr Kmoch >> wrote: >> >> > Hi all. >> >> > >> >> > I'm converting a small Makefile-based project to CMake. The project >> is >> >> > not >> >> > mine, so I am trying to match its existing buildsystem as closely as >> >> > possible. >> >> > >> >> > One of the rules in the original Makefile is (simplified) as follows: >> >> > >> >> > examples: all >> >> > make -C example_dir all >> >> > >> >> > This gives a target 'examples' in the top-level Makefile, which is >> not >> >> > included in 'all', but can be used to build all examples. I would >> like >> >> > to >> >> > achieve something similar with CMake. >> >> > >> >> > I added example_dir/CMakeLists.txt, which includes a project() >> command >> >> > and >> >> > defines all the targets for example executables. In the toplevel >> >> > CMakeList, >> >> > I did this: >> >> > >> >> > # Add the subdirectory but don't include its targets by default >> >> > add_subdirectory(example_dir EXCLUDE_FROM_ALL) >> >> > >> >> > # Add a custom target to build all examples >> >> > add_custom_target(examples ???) >> >> > >> >> > I'm stuck at the custom target. What I need for its command is a >> >> > generator-agnostic equivalent for 'make -C example_dir all' (or >> 'make -f >> >> > example_dir/Makefile all'). >> >> > >> >> > I tried 'cmake --build ${CMAKE_CURRENT_BINARY_DIR}/example_dir ...', >> but >> >> > this complains that example_dir does not contain a CMakeCache.txt >> (which >> >> > is >> >> > correct of course, it's not the toplevel directory). Then I >> remembered >> >> > that >> >> > build_command() can be used to get a command line to build a project; >> >> > unfortunately, in 3.0 and later, this just returns 'cmake --build >> ...' >> >> > and >> >> > so is unusable in my situation. >> >> > >> >> > Is there a way to query CMake for the native command line (or >> something >> >> > else) I could use to build the CMake-generated buildsystem in the >> >> > subdirectory? I thought a bit about CMAKE_MAKE_PROGRAM, but that >> doesn't >> >> > tell me anything about what arguments I should pass, and it's not >> even >> >> > set >> >> > on Visual Studio generators. >> >> > >> >> > As a workaround, I thought of not doing add_subdirectory() at all and >> >> > instead adding a custom target with 'ctest --build-and-test ...', >> but I >> >> > would prefer to configure & generate the two directories together. I >> >> > plan to >> >> > eventually add install() rules for the examples as well, and the >> >> > examples >> >> > also use one of the targets from the toplevel cmakelist in >> >> > add_custom_command(OUTPUT ...), so I would really like to keep them >> as >> >> > one >> >> > CMake system. Is there a way to do so? >> >> > >> >> > Petr >> >> > >> >> > -- >> >> > >> >> > 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 >> > >> > >> > > > -- > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cxjohnson at gmail.com Fri Dec 5 17:46:19 2014 From: cxjohnson at gmail.com (Chris Johnson) Date: Fri, 5 Dec 2014 16:46:19 -0600 Subject: [CMake] project directive overwrites CMAKE_INSTALL_PREFIX? In-Reply-To: References: Message-ID: This looks like a bug to me. I have a very simple test case where CMAKE_INSTALL_PREFIX is set correctly if I do so after the project() statement, and fails to be set correctly if I do it before the project() statement. On Fri, Dec 5, 2014 at 2:06 PM, Chris Johnson wrote: > Strangely, running "cmake -DCMAKE_INSTALL_PREFIX=/some/path" does NOT > rewrite the cmake_install.cmake, but does rewrite the CMakeCache.txt and > other files. The result is a bad install path won't go away until one > manually removes the cmake_install.cmake file(s). > > On Thu, Dec 4, 2014 at 9:48 PM, J Decker wrote: > >> I find it's better to define CMAKE_INSTALL_PREFIX on the command line >> when building >> >> I do have this bit of code... >> >> IF(CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT) >> SET(CMAKE_INSTALL_PREFIX >> ${CMAKE_BINARY_DIR}/../${CMAKE_BUILD_TYPE}_out CACHE PATH "Install >> default 'out' in this directory." FORCE >> ) >> ENDIF(CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT) >> >> >> which keeps it from overwriting an already set value (from the command >> line); and make sure it's in the cache so cmake-gui can edit it... >> >> (if project() does something with cmake_isnstall_prefix might also be a >> bug) >> >> On Thu, Dec 4, 2014 at 7:27 PM, Chris Johnson >> wrote: >> >>> I have a global include file used by all of the CMakeLists.txt files in >>> my project. In it, I set the value of CMAKE_INSTALL_PREFIX, as well as a >>> number of other variables and functions. >>> >>> In my CMakeLists.txt file, I had this: >>> >>> cmake_minimum_require(VERSION 2.8.4) >>> include(global.inc) >>> project(whatever) >>> >>> When I run cmake, the value of CMAKE_INSTALL_PREFIX is lost! Instead, in >>> the resulting cmake_install.cmake file has been defaulted back to >>> /usr/local which is completely wrong. >>> >>> However, if I change the order to this: >>> >>> cmake_minimum_require(VERSION 2.8.4) >>> project(whatever) >>> include(global.inc) >>> >>> It appears to work. >>> >>> I find nothing in the documentation saying that the project() directive >>> will set CMAKE_INSTALL_PREFIX. >>> >>> Even more strangely, if I run cmake a second time with the first >>> configuration (include before project), it will rewrite cmake_install.cmake >>> with the correct value. >>> ? ? >>> That is, the behavior of cmake appears to be different based on whether >>> the build directory is empty or already contains cmake_install.cmake and >>> CMakeCache.txt files >>> ?, even though they contain the wrong path value for >>> CMAKE_INSTALL_PREFIX.? >>> >>> What is going on here? >>> >>> >>> >>> >>> >>> >>> -- >>> >>> 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 >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From steveire at gmail.com Sat Dec 6 07:51:39 2014 From: steveire at gmail.com (Stephen Kelly) Date: Sat, 06 Dec 2014 13:51:39 +0100 Subject: [CMake] unexpected behavior with TARGET_FILE_DIR and Visual Studio 2010 References: <2E8A0F00-5AC9-4270-9620-8CFB9DD51F06@gmail.com> Message-ID: Michael Ellery wrote: > Can anyone offer advice? Is this how the visual studio generator works or > is this possibly a bug in CMake? I'm not very familiar with that generator. It looks like a bug to me too though. Thanks, Steve. From Allen.Barnett at varian.com Sun Dec 7 15:12:32 2014 From: Allen.Barnett at varian.com (Allen Barnett) Date: Sun, 7 Dec 2014 20:12:32 +0000 Subject: [CMake] Visual Studio 12 C++ Compiler Detection In-Reply-To: <0cab5fa12c014907a263caa2c62ffdcd@PA-EX2013-MBX02.vms.ad.varian.com> References: <088f168a820e4bba9252f3fa1dfa8d89@PA-EX2013-MBX02.vms.ad.varian.com> <0cab5fa12c014907a263caa2c62ffdcd@PA-EX2013-MBX02.vms.ad.varian.com> Message-ID: If anyone is interested, it turns out that visual studio 2013 prefers the 32-bit cross compiler. You can set the environment variable PreferredToolArchtecture=x64 to get the native 64-bit compiler (say, before you run CMake). Some discussion is here: https://connect.microsoft.com/VisualStudio/feedback/details/800059/isnativeenvironment-true-no-longer-works-on-visual-studio-2013-rc Allen > -----Original Message----- > From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Allen > Barnett > Sent: Friday, December 05, 2014 9:06 AM > To: Jakub Zakrzewski > Cc: cmake at cmake.org > Subject: Re: [CMake] Visual Studio 12 C++ Compiler Detection > > Hi Jakub: Thanks for the tip. What is the proper way to execute the compiler > during the initial configure step? try_compile? > > Thanks, > Allen > > > So, it appears to find the compiler OK since it emits the correct > > compiler identification. But, the actual value of CMAKE_CXX_COMPILER is > not usable. If you try to execute C:/Program?./x86_amd64/cl.exe from > within a CMake script or even from the command line, it will fail and > produce the well-known ?0xc000007b? dialog (missing DLL). Unless you?ve > sourced > vcvarsx86_amd64.bat, the correct environment variables are not > set for this version of the compiler. > > > On the other hand, if I do ?cmake ?G NMake Makefiles?, I get what I > expect: > > > Namely, it finds C:/Program?./amd64/cl.exe. > > > I would like to see how it is coming up with this version of the compiler > which isn?t even in the PATH. > > Hi Allen, > > CMake does not pay attention to the PATH when you ask for VisualStudio > generator. It simply finds it using it's internal logic. The generated projects > are suitable for opening in the IDE. > The NMake generator behaves much more like Unix Makefiles generator, so > it is sensitive to the environment variables and remembers all variables it > needs. > > > -- > > 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 From a.neundorf-work at gmx.net Sun Dec 7 16:52:30 2014 From: a.neundorf-work at gmx.net (Alexander Neundorf) Date: Sun, 07 Dec 2014 22:52:30 +0100 Subject: [CMake] Generate Eclipse project with support for c++ 11 In-Reply-To: References: Message-ID: <1534429.nSMQHeMcCT@tuxedo.neundorf.net> On Friday, December 05, 2014 09:58:17 Luca Gherardi wrote: > Hi all, > > I?m writing a CMake file for a project that should be compiled both in > Ubuntu and OS X. I want to use eclipse as IDE, gcc and C++ 11. > > I read different threads that suggest how to enable C++ 11 in eclipse. > According to them I included these lines in my CMake: > > set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++11 -Wall") > > if (${CMAKE_EXTRA_GENERATOR} MATCHES "Eclipse CDT4") > set(CMAKE_CXX_COMPILER_ARG1 "-std=c++11" CACHE STRING "C++ version for > eclipse" FORCE) set(CMAKE_ECLIPSE_VERSION "4.3" CACHE STRING "Eclipse > version" FORCE) endif (${CMAKE_EXTRA_GENERATOR} MATCHES "Eclipse CDT4?) > > However, eclipse still set a wrong value for the symbol __cplusplus (199711L > instead of 201103L I guess). For this reason eclipse is not able to index > C++ 11 features such as shared pointer. Therefore I get a syntax error also > if the code compiles. > > Any idea on how can I address this issue? please enter a ticket at http://public.kitware.com/Bug/ You could try to set the environment variable CXX to "g++ -std=c++11" and see whether that works (didn't try). Thanks Alex From irwin.zaid at physics.ox.ac.uk Mon Dec 8 09:31:46 2014 From: irwin.zaid at physics.ox.ac.uk (Irwin Zaid) Date: Mon, 8 Dec 2014 14:31:46 +0000 Subject: [CMake] FindCUDA ignores project dependencies when separable compilation is on Message-ID: <5485B652.2010408@physics.ox.ac.uk> Hi all, Just wanted to mention this issue I've run into. I have a project (libdynd -- https://github.com/libdynd/libdynd) that uses FindCUDA to deal with CUDA compilation. A part of our library is generated at compile-time, which we handle by the command "add_dependencies(libdynd some_exe)", where "some_exe" is an executable built with a custom command. This part of our library needs to be present before anything else is built. So far, everything has worked great, with and without CUDA. However, I found that by just turning separable compilation on, via set(CUDA_SEPARABLE_COMPILATION ON), the dependency I've added is then ignored and the necessary files are not generated. Basically, CMake goes straight to NVCC without running the custom command. This seems to me to be something wrong with FindCUDA, but it is of course possible that I've done something wrong. Any help would be appreciated! Irwin From cxjohnson at gmail.com Mon Dec 8 13:53:47 2014 From: cxjohnson at gmail.com (Chris Johnson) Date: Mon, 8 Dec 2014 12:53:47 -0600 Subject: [CMake] Is this expected behavior? Message-ID: When I change a header file for a library, and then do a "make" in the build directory, only source (C++) files which directly include that header get rebuilt, but those which use it indirectly do not. But when I link to the library, the other files do get rebuilt. Example: lib/mod.cpp lib/mod2.cpp lib/mod3.cpp lib/lib/mod.h lib/lib/mod2.h lib/lib/mod3.h mod1.h: class mod { }; mod2.h: #include "lib/mod1.h" class mod2 : public mod1 { }; mod.cpp #include "lib/mod.h" mod2.cpp: #include "lib/mod2.h" // etc. So mod.h contains the base class, and mod2.h and mod3.h contain derived classes. Changing mod.h requires all of the example source files above to be recompiled to be correct, but "make" in the lib directory only recompiles mod.cpp. If I have a program elsewhere which references this library, doing a "make" in its build directory causes dependency checks and results in mod2.cpp and mod3.cpp being recompiled as well as mod.cpp. The depend.mak and depend.internal files correctly list mod.h as being in the dependencies for mod2.o and mod3.o, but those rules don't appear to get used. Is this expected behavior? Is there some way to change it to cause a "make" in the lib directory to compile all files dependent on the header, even if transitively (correct word?)? Thanks. This is really throwing our developers for a loop as we transition from home-grown make to CMake. ..chris -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.robinson.msc at gmail.com Mon Dec 8 14:46:21 2014 From: ben.robinson.msc at gmail.com (Ben Robinson) Date: Mon, 8 Dec 2014 11:46:21 -0800 Subject: [CMake] 'MinGW Makefiles' generator can't link when using Intel Fortran Message-ID: I am having trouble getting a CMake to compile Fortran on Windows. I have mingw32-make.exe in my path. I have the Intel Fortran compile ifort.exe in my path. If I choose the 'Visual Studio 11 2012' generator, Fortran is properly detected and the project sets up fine. I am willing to use a different Makefiles generator, provided I can also compile C++ with Visual Studio compiler in a Makefiles based build. Here is my entire top level CMakeLists.txt file: project(Fortran_1 LANGUAGES Fortran) cmake_minimum_required(VERSION 3.0) That's not an excerpt. :) I invoke CMake via the following shell command: F:\workspaces\cmake_fortran_1\build\Debug> cmake -G"MinGW Makefiles" -DCMAKE_BUILD_TYPE=Debug -DOUTPUT_DIR=F:\workspaces\cmake_fortran_1\build\ F:\workspaces\cmake_fortran_1\source And I get the following output: -- The Fortran compiler identification is unknown -- Check for working Fortran compiler: C:/Program Files (x86)/Intel/Composer XE 2015/bin/intel64/ifort.exe -- Check for working Fortran compiler: C:/Program Files (x86)/Intel/Composer XE 2015/bin/intel64/ifort.exe -- broken CMake Error at C:/Program Files (x86)/CMake/share/cmake-3.0/Modules/CMakeTestFortranCompiler.cmake:54 (message): The Fortran compiler "C:/Program Files (x86)/Intel/Composer XE 2015/bin/intel64/ifort.exe" is not able to compile a simple test program. It fails with the following output: Change Dir: F:/workspaces/cmake_fortran_1/build/Debug/CMakeFiles/CMakeTmp Run Build Command:"C:/MinGW/bin/mingw32-make.exe" "cmTryCompileExec3922092051/fast" C:/MinGW/bin/mingw32-make.exe -f CMakeFiles\cmTryCompileExec3922092051.dir\build.make CMakeFiles/cmTryCompileExec3922092051.dir/build mingw32-make.exe[1]: Entering directory 'F:/workspaces/cmake_fortran_1/build/Debug/CMakeFiles/CMakeTmp' "C:\Program Files (x86)\CMake\bin\cmake.exe" -E cmake_progress_report F:\workspaces\cmake_fortran_1\build\Debug\CMakeFiles\CMakeTmp\CMakeFiles 1 Building Fortran object CMakeFiles/cmTryCompileExec3922092051.dir/testFortranCompiler.f.obj C:\PROGRA~2\Intel\COMPOS~4\bin\intel64\ifort.exe -c F:\workspaces\cmake_fortran_1\build\Debug\CMakeFiles\CMakeTmp\testFortranCompiler.f -o CMakeFiles\cmTryCompileExec3922092051.dir\testFortranCompiler.f.obj Intel(R) Visual Fortran Intel(R) 64 Compiler XE for applications running on Intel(R) 64, Version 15.0.0.108 Build 20140726 Copyright (C) 1985-2014 Intel Corporation. All rights reserved. Linking Fortran executable cmTryCompileExec3922092051.exe "C:\Program Files (x86)\CMake\bin\cmake.exe" -E cmake_link_script CMakeFiles\cmTryCompileExec3922092051.dir\link.txt --verbose=1 C:\PROGRA~2\Intel\COMPOS~4\bin\intel64\ifort.exe CMakeFiles/cmTryCompileExec3922092051.dir/testFortranCompiler.f.obj -o cmTryCompileExec3922092051.exe Intel(R) Visual Fortran Intel(R) 64 Compiler XE for applications running on Intel(R) 64, Version 15.0.0.108 Build 20140726 Copyright (C) 1985-2014 Intel Corporation. All rights reserved. Microsoft (R) Incremental Linker Version 12.00.31101.0 Copyright (C) Microsoft Corporation. All rights reserved. -out:cmTryCompileExec3922092051.exe -subsystem:console CMakeFiles/cmTryCompileExec3922092051.dir/testFortranCompiler.f.obj LINK : fatal error LNK1104: cannot open file 'ifconsol.lib' CMakeFiles\cmTryCompileExec3922092051.dir\build.make:79: recipe for target 'cmTryCompileExec3922092051.exe' failed mingw32-make.exe[1]: *** [cmTryCompileExec3922092051.exe] Error 1104 mingw32-make.exe[1]: Leaving directory 'F:/workspaces/cmake_fortran_1/build/Debug/CMakeFiles/CMakeTmp' Makefile:117: recipe for target 'cmTryCompileExec3922092051/fast' failed mingw32-make.exe: *** [cmTryCompileExec3922092051/fast] Error 2 CMake will not be able to correctly generate this project. Call Stack (most recent call first): CMakeLists.txt:1 (project) -- Configuring incomplete, errors occurred! See also "F:/workspaces/cmake_fortran_1/build/Debug/CMakeFiles/CMakeOutput.log". See also "F:/workspaces/cmake_fortran_1/build/Debug/CMakeFiles/CMakeError.log". Anything I should try? Thank you! Ben Robinson -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.robinson.msc at gmail.com Mon Dec 8 14:55:14 2014 From: ben.robinson.msc at gmail.com (Ben Robinson) Date: Mon, 8 Dec 2014 11:55:14 -0800 Subject: [CMake] 'MinGW Makefiles' generator can't link when using Intel Fortran In-Reply-To: References: Message-ID: More information, I do not have msys in my path. My mingw32-make.exe version support the job server as it is version: GNU Make 3.82.90 Built for i686-pc-mingw32 My CMake version is 3.0.2. My Intel Fortran compiler version is: Intel(R) Visual Fortran Intel(R) 64 Compiler XE for applications running on Intel(R) 64, Version 15.0.0.108 Build 20140726 Thank you, Ben -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.hoffman at kitware.com Mon Dec 8 15:55:55 2014 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Mon, 08 Dec 2014 15:55:55 -0500 Subject: [CMake] 'MinGW Makefiles' generator can't link when using Intel Fortran In-Reply-To: References: Message-ID: <5486105B.90508@kitware.com> On 12/8/2014 2:46 PM, Ben Robinson wrote: > CMakeFiles/cmTryCompileExec3922092051.dir/testFortranCompiler.f.obj > > LINK : fatal error LNK1104: cannot open file 'ifconsol.lib' Looks like you are running from a shell that is not setup for the Intel fortran compiler to work. The LIBPATH seems to be wrong as fortran can not find its own run time libraries. Can you run cmake from the intel compiler command prompt shell? -Bill From irwin at beluga.phys.uvic.ca Mon Dec 8 15:58:41 2014 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Mon, 8 Dec 2014 12:58:41 -0800 (PST) Subject: [CMake] Is this expected behavior? In-Reply-To: References: Message-ID: On 2014-12-08 12:53-0600 Chris Johnson wrote: > When I change a header file for a library, and then do a "make" in the > build directory, only source (C++) files which directly include that header > get rebuilt, but those which use it indirectly do not. But when I link to > the library, the other files do get rebuilt. > > Example: > > lib/mod.cpp > lib/mod2.cpp > lib/mod3.cpp > lib/lib/mod.h > lib/lib/mod2.h > lib/lib/mod3.h > > mod1.h: > class mod { > }; > > mod2.h: > #include "lib/mod1.h" > > class mod2 : public mod1 { > }; > > mod.cpp > #include "lib/mod.h" > > mod2.cpp: > #include "lib/mod2.h" > > // etc. > > So mod.h contains the base class, and mod2.h and mod3.h contain derived > classes. Changing mod.h requires all of the example source files above to > be recompiled to be correct, but "make" in the lib directory only > recompiles mod.cpp. > > If I have a program elsewhere which references this library, doing a "make" > in its build directory causes dependency checks and results in mod2.cpp and > mod3.cpp being recompiled as well as mod.cpp. > > The depend.mak and depend.internal files correctly list mod.h as being in > the dependencies for mod2.o and mod3.o, but those rules don't appear to get > used. > > Is this expected behavior? Is there some way to change it to cause a > "make" in the lib directory to compile all files dependent on the header, > even if transitively (correct word?)? > > Thanks. This is really throwing our developers for a loop as we transition > from home-grown make to CMake. Hi Chris: I have used CMake for years, but I am still a naive user with respect to such dependency tracker issues. But my own personal opinion is the transitive behaviour is the correct one so I am quite surprised this is happening. So my opinion is this is likely a bug for your particular platform. So I strongly suggest you follow up with the list with more details concerning your platform, e.g., what OS, what CMake version (including whether you built it yourself or installed a binary version from somewhere), which CMake generator (e.g., "Unix Makefiles", "MSYS Makefiles", or whatever you used), which compiler, which compiler version. You may also want to try to build the absolutely latest released version of CMake as well (if that is not what you are currently using) to see if that changes anything. >From the above you have obviously started down the road of making the simplest possible example which exhibits the behaviour. I suggest you finish such a mini-project and wrap that into a compressed tarball that you attach to your post to the list. That would allow others here to conveniently confirm (or not) whether the dependency tracker has this non-transitive issue with headers on their particular platform. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ From ben.robinson.msc at gmail.com Mon Dec 8 16:19:10 2014 From: ben.robinson.msc at gmail.com (Ben Robinson) Date: Mon, 8 Dec 2014 13:19:10 -0800 Subject: [CMake] 'MinGW Makefiles' generator can't link when using Intel Fortran In-Reply-To: References: Message-ID: Thank you Bill! By running from the Intel command prompt shell, I am able to compile F90 code using CMake + MinGW Make + Intel Fortran. Then, in order to support both CXX and Fortran, I set 'CXX=cl.exe' before calling CMake to generate the project. This seems to work for now. I was surprised I didn't need to run from within the VS command prompt shell to support C++, as I did for Intel Fortran. Of course, I am only using Makefiles for Fortran as a workaround until there is CMake+Ninja+Fortran support. :P Cheers, Ben On Mon, Dec 8, 2014 at 11:55 AM, Ben Robinson wrote: > More information, I do not have msys in my path. My mingw32-make.exe > version support the job server as it is version: > > GNU Make 3.82.90 > Built for i686-pc-mingw32 > > My CMake version is 3.0.2. > > My Intel Fortran compiler version is: > > Intel(R) Visual Fortran Intel(R) 64 Compiler XE for applications running > on Intel(R) 64, Version 15.0.0.108 Build 20140726 > > Thank you, > > Ben > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.hoffman at kitware.com Mon Dec 8 16:34:19 2014 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Mon, 08 Dec 2014 16:34:19 -0500 Subject: [CMake] 'MinGW Makefiles' generator can't link when using Intel Fortran In-Reply-To: References: Message-ID: <5486195B.4020104@kitware.com> On 12/8/2014 4:19 PM, Ben Robinson wrote: > Thank you Bill! > > By running from the Intel command prompt shell, I am able to compile F90 > code using CMake + MinGW Make + Intel Fortran. Then, in order to > support both CXX and Fortran, I set 'CXX=cl.exe' before calling CMake to > generate the project. This seems to work for now. I was surprised I > didn't need to run from within the VS command prompt shell to support > C++, as I did for Intel Fortran. I think the Fortran env also sets up the visual studio compiler. > > Of course, I am only using Makefiles for Fortran as a workaround until > there is CMake+Ninja+Fortran support. :P Sure. -Bill From cxjohnson at gmail.com Mon Dec 8 17:55:30 2014 From: cxjohnson at gmail.com (Chris Johnson) Date: Mon, 8 Dec 2014 16:55:30 -0600 Subject: [CMake] Is this expected behavior? In-Reply-To: References: Message-ID: Thanks for the reply and good advice, Alan. Will do. ..chris On Mon, Dec 8, 2014 at 2:58 PM, Alan W. Irwin wrote: > On 2014-12-08 12:53-0600 Chris Johnson wrote: > > When I change a header file for a library, and then do a "make" in the >> build directory, only source (C++) files which directly include that >> header >> get rebuilt, but those which use it indirectly do not. But when I link to >> the library, the other files do get rebuilt. >> >> Example: >> >> lib/mod.cpp >> lib/mod2.cpp >> lib/mod3.cpp >> lib/lib/mod.h >> lib/lib/mod2.h >> lib/lib/mod3.h >> >> mod1.h: >> class mod { >> }; >> >> mod2.h: >> #include "lib/mod1.h" >> >> class mod2 : public mod1 { >> }; >> >> mod.cpp >> #include "lib/mod.h" >> >> mod2.cpp: >> #include "lib/mod2.h" >> >> // etc. >> >> So mod.h contains the base class, and mod2.h and mod3.h contain derived >> classes. Changing mod.h requires all of the example source files above to >> be recompiled to be correct, but "make" in the lib directory only >> recompiles mod.cpp. >> >> If I have a program elsewhere which references this library, doing a >> "make" >> in its build directory causes dependency checks and results in mod2.cpp >> and >> mod3.cpp being recompiled as well as mod.cpp. >> >> The depend.mak and depend.internal files correctly list mod.h as being in >> the dependencies for mod2.o and mod3.o, but those rules don't appear to >> get >> used. >> >> Is this expected behavior? Is there some way to change it to cause a >> "make" in the lib directory to compile all files dependent on the header, >> even if transitively (correct word?)? >> >> Thanks. This is really throwing our developers for a loop as we >> transition >> from home-grown make to CMake. >> > > Hi Chris: > > I have used CMake for years, but I am still a naive user with respect > to such dependency tracker issues. But my own personal opinion is the > transitive behaviour is the correct one so I am quite surprised this > is happening. > > So my opinion is this is likely a bug for your particular platform. So > I strongly suggest you follow up with the list with more details > concerning your platform, e.g., what OS, what CMake version (including > whether you built it yourself or installed a binary version from > somewhere), which CMake generator (e.g., "Unix Makefiles", "MSYS > Makefiles", or whatever you used), which compiler, which compiler > version. You may also want to try to build the absolutely latest > released version of CMake as well (if that is not what you are > currently using) to see if that changes anything. > > From the above you have obviously started down the road of making the > simplest possible example which exhibits the behaviour. I suggest you > finish such a mini-project and wrap that into a compressed tarball > that you attach to your post to the list. That would allow others > here to conveniently confirm (or not) whether the dependency > tracker has this non-transitive issue with headers on their particular > platform. > > Alan > __________________________ > Alan W. Irwin > > Astronomical research affiliation with Department of Physics and Astronomy, > University of Victoria (astrowww.phys.uvic.ca). > > Programming affiliations with the FreeEOS equation-of-state > implementation for stellar interiors (freeeos.sf.net); the Time > Ephemerides project (timeephem.sf.net); PLplot scientific plotting > software package (plplot.sf.net); the libLASi project > (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); > and the Linux Brochure Project (lbproject.sf.net). > __________________________ > > Linux-powered Science > __________________________ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From irwin at beluga.phys.uvic.ca Mon Dec 8 20:10:47 2014 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Mon, 8 Dec 2014 17:10:47 -0800 (PST) Subject: [CMake] Is this expected behavior? In-Reply-To: References: Message-ID: On 2014-12-08 12:53-0600 Chris Johnson wrote: > When I change a header file for a library, and then do a "make" in the > build directory, only source (C++) files which directly include that header > get rebuilt, but those which use it indirectly do not. Hi Chris: For one of my C projects (ephcom) I cannot confirm this behaviour on Linux (Debian Stable); using CMake-3.0.2 (which I built myself from source using the boostrap method); using the "Unix Makefiles" generator; and using gcc (Debian 4.7.2-5) 4.7.2. I also use ccache, but I don't think it is relevant because all that means is if you are rebuilding something exactly (no source changes and no option changes) it will be very fast. But you will actually see that ccache command being executed if CMake thinks a rebuild is necessary, and otherwise not. Here is the relevant layout of the source and header files of the ephcom_spice library: The complete source code for the ephcom_spice library: ephcom/src/libs/ephcom_spice.c The relevant headers: software at raven> grep include ephcom/src/libs/ephcom_spice.c \ > ephcom/src/include/ephcom_spice.h ephcom/src/libs/ephcom_spice.c:#include ephcom/src/libs/ephcom_spice.c:#include ephcom/src/libs/ephcom_spice.c:#include ephcom/src/libs/ephcom_spice.c:#include ephcom/src/libs/ephcom_spice.c:#include ephcom/src/libs/ephcom_spice.c:#include "ephcom_spice.h" ephcom/src/libs/ephcom_spice.c:#include "ephcom.h" ephcom/src/libs/ephcom_spice.c:#include "gnulliver.h" ephcom/src/include/ephcom_spice.h:#include ephcom/src/include/ephcom_spice.h:#include "ephcomdll.h" ephcom/src/include/ephcom_spice.h:#include "ephcom.h" So I think from your above description that ephcomdll.h qualifies as an indirectly used header. However, if I touch ephcom/src/include/ephcomdll.h, the ephcom_spice library always rebuilds meaning I cannot confirm your reported behaviour. Note this is a complex example (the ephcom_spice library depends on other libraries in the same source tree which may be dictating the rebuild behaviour), but also note that none of them depend directly on ephcomdll.h as illustrated by the following empty results: software at raven> grep ephcomdll.h ephcom/src/libs/*.[ch] So it is a fairly clean counterexample, and I am glad to hear from your subsequent post that you will be attempting to define a complete simple project that demonstrates the non-transitive header dependency tracker issue you have found on your platform with a much more complex project. By the way, generating those simple projects to illustrate a CMake issue is extremely helpful in one other way. Whenever, I do that I usually (~80 per cent of the time) find there is no "CMake issue" that I can replicate in the simple example, and the problem is actually a misuse of CMake (e.g., wrong library dependencies) in my complex "real world" example. :-) So good luck figuring this out, and there is certainly no shame if it turns out to be the latter case. However, if it is the former case, then it will be interesting to see if the CMake dependency tracker issue demonstrated by your complete simple project on your platform occurs on my and other's platforms as well. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ From bill.hoffman at kitware.com Mon Dec 8 21:06:30 2014 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Mon, 08 Dec 2014 21:06:30 -0500 Subject: [CMake] Is this expected behavior? In-Reply-To: References: Message-ID: <54865926.5080609@kitware.com> On 12/8/2014 1:53 PM, Chris Johnson wrote: > When I change a header file for a library, and then do a "make" in the > build directory, only source (C++) files which directly include that > header get rebuilt, but those which use it indirectly do not. But when > I link to the library, the other files do get rebuilt. This should work. If you can create a complete example in a tar file that shows this issue, I can take a look at it. -Bill From bartlettra at ornl.gov Mon Dec 8 22:05:51 2014 From: bartlettra at ornl.gov (Bartlett, Roscoe A.) Date: Tue, 9 Dec 2014 03:05:51 +0000 Subject: [CMake] CMakePackageConfigHelpers.cmake support "Sematic Versioning"? Message-ID: Hello CMake Developers, Any chance a "Semantic Versioning" option can be added to the standard CMake module CMakePackageConfigHelpers.cmake that implements the "Semantic Versioning" described at: http://semver.org/ This is the best defined standard for versioning I have ever seen. It makes a lot of sense. The problem with the current implementation of CMakePackageConfigHelpers.cmake is that it does not have a mode where X in X.Y.Z defines a backward compatible set. Cheers, -Ross _______________________________________________________________________________ Dr. Roscoe A. Bartlett, PhD Oak Ridge National Laboratory CASL Physics Integration Software Engineering Lead Trilinos Software Engineering Technologies and Integration Lead http://web.ornl.gov/~8vt/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From Micha.Renner at t-online.de Tue Dec 9 02:30:49 2014 From: Micha.Renner at t-online.de (Micha Renner) Date: Tue, 09 Dec 2014 08:30:49 +0100 Subject: [CMake] Unclear warning Message-ID: <1418110249.3486.1.camel@t-online.de> Hi, what does this message mean? The ASM_MASM compiler identification is MSVC CMake Warning (dev) at C:/Program Files/CMake/share/cmake-3.1/Modules/CMakeFindBinUtils.cmake:33 (if): Policy CMP0054 is not set: Only interpret if() arguments as variables or keywords when unquoted. Run "cmake --help-policy CMP0054" for policy details. Use the cmake_policy command to set the policy and suppress this warning. Quoted variables like "MSVC" will no longer be dereferenced when the policy is set to NEW. Since the policy is not set the OLD behavior will be used. Call Stack (most recent call first): C:/Program Files/CMake/share/cmake-3.1/Modules/CMakeDetermineASMCompiler.cmake:137 (include) C:/Program Files/CMake/share/cmake-3.1/Modules/CMakeDetermineASM_MASMCompiler.cmake:27 (include) src/CMakeLists.txt:44 (ENABLE_LANGUAGE) Is this a wanted warning? Greetings Michael From nilsgladitz at gmail.com Tue Dec 9 02:56:45 2014 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Tue, 09 Dec 2014 08:56:45 +0100 Subject: [CMake] Unclear warning In-Reply-To: <1418110249.3486.1.camel@t-online.de> References: <1418110249.3486.1.camel@t-online.de> Message-ID: <5486AB3D.3050409@gmail.com> On 12/09/2014 08:30 AM, Micha Renner wrote: > Hi, > > what does this message mean? > > The ASM_MASM compiler identification is MSVC > CMake Warning (dev) at C:/Program > Files/CMake/share/cmake-3.1/Modules/CMakeFindBinUtils.cmake:33 (if): > Policy CMP0054 is not set: Only interpret if() arguments as variables > or > keywords when unquoted. Run "cmake --help-policy CMP0054" for policy > details. Use the cmake_policy command to set the policy and suppress > this > warning. > > Quoted variables like "MSVC" will no longer be dereferenced when the > policy > is set to NEW. Since the policy is not set the OLD behavior > will be used. > Call Stack (most recent call first): > C:/Program > Files/CMake/share/cmake-3.1/Modules/CMakeDetermineASMCompiler.cmake:137 > (include) > C:/Program > Files/CMake/share/cmake-3.1/Modules/CMakeDetermineASM_MASMCompiler.cmake:27 (include) > src/CMakeLists.txt:44 (ENABLE_LANGUAGE) > > Is this a wanted warning? The warning is due to an ambiguity of if() argument evaluation in an internal module (CMakeFindBinUtils.cmake). Assuming CMAKE_C_COMPILER_ID is MSVC and MSVC is 1 the following expression: if("${CMAKE_C_COMPILER_ID}" STREQUAL "MSVC") With OLD CMP0054 behavior is basically the same as: if(1 STREQUAL 1) with NEW CMP0054 policy behavior quoted arguments are protected from implicit expansion so the same conditional boils down to: if("MSVC" STREQUAL "MSVC") The warning was fixed in http://www.cmake.org/gitweb?p=stage/cmake.git;a=commit;h=4d52cd36 . The fix should also be in the upcoming rc3. Nils From ax487 at gmx.de Tue Dec 9 04:38:42 2014 From: ax487 at gmx.de (ax487) Date: Tue, 09 Dec 2014 10:38:42 +0100 Subject: [CMake] Programmatically-generated dependencies Message-ID: <5486C322.7020508@gmx.de> Hello all, I am mainly asking having glib-compile-resources in mind. This little program translates files into C source code to be used with the gresource system. It works in the following way: You have a file.xml describing the resources: some_file.txt To generate the source you use `glib-compile-resources --generate-source --target=output.c file.xml`. Clearly the generated output.c depends on file.xml. But it also depends on some_file.txt. It is possible to get a list of dependencies using `glib-compile-resources --generate-dependencies file.xml` which will output some_file.txt The situation is similar to the case of auto-generated header dependencies for C/C++ source code using the "-MM" option of gcc. I saw the following version on github: https://github.com/bgK/vba-ttb/blob/master/cmake/GResource.cmake which does not correctly detect dependencies, but nothing apart from that. But since the process works with C/C++ source code I figured there is no reason why it shouldn't also work in this case. Could anyone give me some pointers on how to get this to work? ax487 From irwin at beluga.phys.uvic.ca Tue Dec 9 04:52:59 2014 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Tue, 9 Dec 2014 01:52:59 -0800 (PST) Subject: [CMake] Unclear warning In-Reply-To: <5486AB3D.3050409@gmail.com> References: <1418110249.3486.1.camel@t-online.de> <5486AB3D.3050409@gmail.com> Message-ID: On 2014-12-09 08:56+0100 Nils Gladitz wrote: > On 12/09/2014 08:30 AM, Micha Renner wrote: >> Hi, >> >> what does this message mean? >> >> The ASM_MASM compiler identification is MSVC >> CMake Warning (dev) at C:/Program >> Files/CMake/share/cmake-3.1/Modules/CMakeFindBinUtils.cmake:33 (if): >> Policy CMP0054 is not set: Only interpret if() arguments as variables >> or >> keywords when unquoted. Run "cmake --help-policy CMP0054" for policy >> details. Use the cmake_policy command to set the policy and suppress >> this >> warning. >> >> Quoted variables like "MSVC" will no longer be dereferenced when the >> policy >> is set to NEW. Since the policy is not set the OLD behavior >> will be used. >> Call Stack (most recent call first): >> C:/Program >> Files/CMake/share/cmake-3.1/Modules/CMakeDetermineASMCompiler.cmake:137 >> (include) >> C:/Program >> Files/CMake/share/cmake-3.1/Modules/CMakeDetermineASM_MASMCompiler.cmake:27 >> (include) >> src/CMakeLists.txt:44 (ENABLE_LANGUAGE) >> >> Is this a wanted warning? > > The warning is due to an ambiguity of if() argument evaluation in an internal > module (CMakeFindBinUtils.cmake). > > Assuming CMAKE_C_COMPILER_ID is MSVC and MSVC is 1 the following expression: > if("${CMAKE_C_COMPILER_ID}" STREQUAL "MSVC") > > With OLD CMP0054 behavior is basically the same as: > if(1 STREQUAL 1) > > with NEW CMP0054 policy behavior quoted arguments are protected from implicit > expansion so the same conditional boils down to: > if("MSVC" STREQUAL "MSVC") Hi Nils: I have never understood CMP0054 until now when I read your above clear explanation. So thanks very much for that! My problem was the bad/ambiguous documentation of CMP0054 at which states "Only interpret if() arguments as variables or keywords when unquoted." This wording implies (if taken rigourously) that "${CMAKE_C_COMPILER_ID}" is that exact literal string under NEW CMP0054 which I am sure (now after reading your above explanation) was not meant by the author of that documentation. Instead, of course, ${CMAKE_C_COMPILER_ID} always explicitly dereferences the variable even if inside quotes. I think this is all covered beautifully by your above "protected from implicit expansion" wording. So could you please change to reflect that much clearer wording? > > The warning was fixed in > http://www.cmake.org/gitweb?p=stage/cmake.git;a=commit;h=4d52cd36 . This brings up the "ugly x" issue. There, effectively if(CMAKE_C_COMPILER_ID STREQUAL "MSVC") is replaced by the extraordinarily ugly (in my opinion because it reminds me of that sort of logic I used to see in shell scripts configured by autotools [!]) if("x${CMAKE_C_COMPILER_ID}" STREQUAL "xMSVC") According to your above explanation when CMAKE_C_COMPILER_ID derefences to MSVC and MSVC dereferences to 1, this boils down to if("x1" STREQUAL "x1") for OLD CMP0054 and if("xMSVC" STREQUAL "xMSVC") for NEW CMP0054 (since MSVC will not implicitly dereference for NEW). So this style of logic will work regardless of whether the user is using OLD CMP0054, NEW CMP0054 or even a a CMake version which does not define CMP0054. That's great, but could use of these ugly "x"'s, be accompanied by the following comment? # When OLD CMP0054 is no longer supported can drop the x. Such self documentation of these ugly x's will avoid the situation where users are inspired to propagate x's to user code (even if that already assumes the latest CMake version with CMP0054 NEW). Furthermore, such self-documentation insures these x's can all be easily found and removed from the distributed Modules/CMakeFindBinUtils.cmake when support for CMP0054 OLD gets dropped from CMake (in the far distant feature). In sum, I think a change to use much less ambiguous language in is essential, and an extra line in distributed modules saying # When OLD CMP0054 is no longer supported can drop the x. is a "would be nice" wherever this ugly x logic is currently being deployed. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ From nilsgladitz at gmail.com Tue Dec 9 06:00:33 2014 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Tue, 09 Dec 2014 12:00:33 +0100 Subject: [CMake] Unclear warning In-Reply-To: References: <1418110249.3486.1.camel@t-online.de> <5486AB3D.3050409@gmail.com> Message-ID: <5486D651.4060700@gmail.com> > Hi Nils: > > I have never understood CMP0054 until now when I read your above > clear explanation. So thanks very much for that! > > My problem was the bad/ambiguous documentation of CMP0054 at > which > states > > "Only interpret if() arguments as variables or keywords when unquoted." > > This wording implies (if taken rigourously) that > > "${CMAKE_C_COMPILER_ID}" > > is that exact literal string under NEW CMP0054 which I am sure (now > after reading your above explanation) was not > meant by the author of that documentation. I am the author of that documentation :) The policy influences how if() itself dereferences arguments. It has no effect on explicit ${} expansion which happens before if() gets or handles its arguments. Instead, of course, > ${CMAKE_C_COMPILER_ID} always explicitly dereferences the variable > even if inside quotes. I think this is all covered beautifully by > your above "protected from implicit expansion" wording. So could you > please change > to reflect > that much clearer wording? I don't think it is actually ambiguous given that if() itself only performs implicit expansion and not ${} expansion but I'll think about revising it. >> The warning was fixed in >> http://www.cmake.org/gitweb?p=stage/cmake.git;a=commit;h=4d52cd36 . > > This brings up the "ugly x" issue. > > There, effectively > > if(CMAKE_C_COMPILER_ID STREQUAL "MSVC") > > is replaced by the extraordinarily ugly (in my opinion because it > reminds me of that sort of logic I used to see in shell scripts > configured by autotools [!]) > > if("x${CMAKE_C_COMPILER_ID}" STREQUAL "xMSVC") > > According to your above explanation when CMAKE_C_COMPILER_ID > derefences to MSVC and MSVC dereferences to 1, this boils down to > > if("x1" STREQUAL "x1") This is not the case. After explicit expansion you've got: if("xMSVC" STREQUAL "xMSVC") if() with OLD CMP0054 behavior would implicitly expand xMSVC if it were a variable but the assumption of the workaround is that while MSVC is 1, xMSVC is unset. Since xMSVC is unset if() will not implicitly dereference it and will interpret it as a literal string instead. > > for OLD CMP0054 and > > if("xMSVC" STREQUAL "xMSVC") > > for NEW CMP0054 (since MSVC will not implicitly dereference for NEW). > So this > style of logic will work regardless of whether the user is using OLD > CMP0054, NEW CMP0054 or even a a CMake version which does not define > CMP0054. > > That's great, but could use of these ugly "x"'s, be accompanied by > the following comment? > > # When OLD CMP0054 is no longer supported can drop the x. > > Such self documentation of these ugly x's will avoid the situation > where users are inspired to propagate x's to user code (even if that > already assumes the latest CMake version with CMP0054 NEW). > Furthermore, such self-documentation insures these x's can all be > easily found and removed from the distributed > Modules/CMakeFindBinUtils.cmake when support for CMP0054 OLD gets > dropped from CMake (in the far distant feature). > > In sum, I think a change to use much less ambiguous language > in is > essential, and an extra line in distributed modules saying > > # When OLD CMP0054 is no longer supported can drop the x. > > is a "would be nice" wherever this ugly x logic is currently being > deployed. I'd defer those kind of decisions to Brad though I'd personally not vote for adding those comments. I think that if CMP0054 OLD behavior does get removed at some point the if() calls that can be cleaned up are more easily and thoroughly found by looking for the actual call pattern than spurious comments. Users getting inspired by code in cmake shipped modules might be a problem that goes beyond just CMP0054. The requirements for writing those modules might be quite different from requirements a developer might have for his own modules or cmake setup. The effects of CMP0054 might be more evident but in general find modules are intended to work irregardless of a project's current policy settings. Best practice advice should be part of the actual documentation rather than comments in internal modules. Nils From brad.king at kitware.com Tue Dec 9 08:12:46 2014 From: brad.king at kitware.com (Brad King) Date: Tue, 09 Dec 2014 08:12:46 -0500 Subject: [CMake] CMakePackageConfigHelpers.cmake support "Sematic Versioning"? In-Reply-To: References: Message-ID: <5486F54E.60602@kitware.com> On 12/8/2014 10:05 PM, Bartlett, Roscoe A. wrote: > The problem with the current implementation of > CMakePackageConfigHelpers.cmake is that it does not have a mode where X > in X.Y.Z defines a backward compatible set. It has a "SameMajorVersion" mode which is close, but IIUC a "SemanticVersion" mode would be "SameMajorVersion" for the major version component and "AnyNewerVersion" for the minor component and beyond. Is that correct? -Brad From Micha.Renner at t-online.de Tue Dec 9 09:22:46 2014 From: Micha.Renner at t-online.de (Micha Renner) Date: Tue, 09 Dec 2014 15:22:46 +0100 Subject: [CMake] Unclear warning In-Reply-To: References: <1418110249.3486.1.camel@t-online.de> <5486AB3D.3050409@gmail.com> Message-ID: <1418134966.1894.1.camel@t-online.de> Am Dienstag, den 09.12.2014, 01:52 -0800 schrieb Alan W. Irwin: > Hi Nils: > > I have never understood CMP0054 until now when I read your above > clear explanation. So thanks very much for that! > Same from me. Excellent work. It makes things clearer. Greetings Michael From norulez at me.com Tue Dec 9 09:25:21 2014 From: norulez at me.com (NoRulez) Date: Tue, 09 Dec 2014 15:25:21 +0100 Subject: [CMake] Green Hills Generator #0014992 In-Reply-To: <20809D15-5525-4B03-BE24-5B8B4F4959FA@me.com> References: <20809D15-5525-4B03-BE24-5B8B4F4959FA@me.com> Message-ID: <0CCA1E25-FC9D-4F17-B7C9-556663A2CEF4@me.com> No one? The patch is already working. > Am 12.11.2014 um 09:45 schrieb NoRulez : > > Hi, > > is it possible to get the patch for the green hills generator into CMake 3.1 > > Thanks in advance > > Best Regards > > -- > > 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 From cxjohnson at gmail.com Tue Dec 9 09:45:07 2014 From: cxjohnson at gmail.com (Chris Johnson) Date: Tue, 9 Dec 2014 08:45:07 -0600 Subject: [CMake] Is this expected behavior? In-Reply-To: <54865926.5080609@kitware.com> References: <54865926.5080609@kitware.com> Message-ID: Well of course it had to not be all that simple. My first attempt to create a simple (2 header files in library) example failed to fail in the same way as my much more complex real-life project. :-p I will continue to try to whittle down the real problem to the smallest possible set, but it may take a while. ..chris On Mon, Dec 8, 2014 at 8:06 PM, Bill Hoffman wrote: > On 12/8/2014 1:53 PM, Chris Johnson wrote: > >> When I change a header file for a library, and then do a "make" in the >> build directory, only source (C++) files which directly include that >> header get rebuilt, but those which use it indirectly do not. But when >> I link to the library, the other files do get rebuilt. >> > This should work. If you can create a complete example in a tar file that > shows this issue, I can take a look at it. > > > -Bill > > -- > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nilsgladitz at gmail.com Tue Dec 9 09:48:01 2014 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Tue, 09 Dec 2014 15:48:01 +0100 Subject: [CMake] Green Hills Generator #0014992 In-Reply-To: <0CCA1E25-FC9D-4F17-B7C9-556663A2CEF4@me.com> References: <20809D15-5525-4B03-BE24-5B8B4F4959FA@me.com> <0CCA1E25-FC9D-4F17-B7C9-556663A2CEF4@me.com> Message-ID: <54870BA1.2090907@gmail.com> On 12/09/2014 03:25 PM, NoRulez wrote: > No one? > > The patch is already working. 3.1 has been closed for a while now since it is being prepared for release. New features are unlikely to get accepted at this stage. Looking at the mailing list thread it sounds like the patch is still work in progress as well. Nils From dank at kegel.com Tue Dec 9 10:47:42 2014 From: dank at kegel.com (Dan Kegel) Date: Tue, 9 Dec 2014 07:47:42 -0800 Subject: [CMake] Books on cmake Message-ID: Is "Mastering CMake" still the only book out there? BTW, the doc site for 3.0 is great, I really appreciate the effort that went into it. - Dan From bill.hoffman at kitware.com Tue Dec 9 11:25:17 2014 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Tue, 09 Dec 2014 11:25:17 -0500 Subject: [CMake] Is this expected behavior? In-Reply-To: References: <54865926.5080609@kitware.com> Message-ID: <5487226D.2020000@kitware.com> On 12/9/2014 9:45 AM, Chris Johnson wrote: > Well of course it had to not be all that simple. My first attempt to > create a simple (2 header files in library) example failed to fail in > the same way as my much more complex real-life project. :-p > > I will continue to try to whittle down the real problem to the smallest > possible set, but it may take a while. find . -name depend.make in the build tree will show you were all the depend information is kept. Those files will not be populated until after the first build. But that might give you a clue as to what is going wrong. -Bill From calebwherry at gmail.com Tue Dec 9 12:26:01 2014 From: calebwherry at gmail.com (J. Caleb Wherry) Date: Tue, 9 Dec 2014 12:26:01 -0500 Subject: [CMake] ExternalProject with target_link_library produces incorrect linking? Message-ID: Let's try again... I submitted a question last week but got no responses so I have assumed my question and/or example was not explicit enough. I have stripped out all unnecessary structure from the code and am posing the question better (I hope)... The functionality that I am using is expressed in this old bug: http://public.kitware.com/Bug/view.php?id=10395. I am adding dependencies in my project based on an imported library which is built by ExternalProject_add. Everything works but the linking is not as I would expect. I add my imported library like so (see code for ExternalProject_add statement): add_library(ExtLib SHARED IMPORTED) set_property(TARGET ExtLib PROPERTY IMPORTED_LOCATION "${CMAKE_BINARY_DIR}/${EXT_LIB_NAME}") add_dependencies(ExtLib ExtLibBuild) I then link against this in my binary like so: add_executable(testApp testApp.cpp) target_link_libraries(testApp LINK_PUBLIC TestLib ExtLib) However, when I do this, the binray that comes out has a relative path to the 'ExtLib' which means I can only run it from the directory CMake builds it in. When I change the linking to be the below with the full path to ExtLib, it works just fine and I can run it from anywhere: target_link_libraries(testApp LINK_PUBLIC TestLib "${CMAKE_BINARY_DIR}/${EXT_LIB_NAME}") I gave the full path to the imported library in the "set_property..IMPORTED_LOCATION..." so I am unsure why the first one does not work? In this previous post from Brad in 2010 ( http://www.cmake.org/pipermail/cmake/2010-September/039639.html), it seems that the first way should work like I want, correct? A few other notes: * I have my RPATH properties set which has been a factor in getting this to work but I haven't tested enough to known which ones are actually helping or not. * The (more) SSCCE project is here: https://github.com/calebwherry/cmake-SO-question-main.git * I have also attached a tar'ed version. * System specs: Debian Wheezy 64-bit, CMake 3.0.2, GCC 4.9.2. Thanks, Caleb -- J. Caleb Wherry *Scientific Software Engineer* http://www.calebwherry.com +1 (615) 708-5651 calebwherry at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: cmake-SO-question-main.tar.gz Type: application/x-gzip Size: 36550 bytes Desc: not available URL: From vharron at google.com Tue Dec 9 13:53:56 2014 From: vharron at google.com (Vince Harron) Date: Tue, 9 Dec 2014 10:53:56 -0800 Subject: [CMake] Debugging check_cxx_source_compiles Message-ID: Hi all, check_cxx_source_compiles is failing for me. I can compile the test program from the command line, no problem. I'm taking the flags passed to the working command line and setting them to CMAKE_REQUIRED_FLAGS before check_cxx_source_compiles. How do I see the command line that cmake is trying? Thanks, Vince -- Vince Harron | Technical Lead Manager | vharron at google.com | 858-442-0868 -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.hoffman at kitware.com Tue Dec 9 14:12:17 2014 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Tue, 09 Dec 2014 14:12:17 -0500 Subject: [CMake] Debugging check_cxx_source_compiles In-Reply-To: References: Message-ID: <54874991.8070304@kitware.com> On 12/9/2014 1:53 PM, Vince Harron via CMake wrote: > How do I see the command line that cmake is trying? Look in CMakeFiles/CMakeError.log. -- Bill Hoffman Kitware, Inc. 28 Corporate Drive Clifton Park, NY 12065 bill.hoffman at kitware.com http://www.kitware.com 518 881-4905 (Direct) 518 371-3971 x105 Fax (518) 371-4573 From iosif.neitzke+cmake at gmail.com Tue Dec 9 14:28:12 2014 From: iosif.neitzke+cmake at gmail.com (Iosif Neitzke) Date: Tue, 9 Dec 2014 13:28:12 -0600 Subject: [CMake] Books on cmake In-Reply-To: References: Message-ID: Pretty much. There is also the slim e-book Introduction to CMake [0]. [0] http://www.amazon.com/Introduction-CMake-Software-Tool-Book-ebook/dp/B00KE807Q0/ref=la_B00GPU8HLS_1_1?s=books&ie=UTF8&qid=1418153199&sr=1-1 On Tue, Dec 9, 2014 at 9:47 AM, Dan Kegel wrote: > Is "Mastering CMake" still the only book out there? > > BTW, the doc site for 3.0 is great, I really appreciate the effort > that went into it. > - Dan > -- > > 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 From brad.king at kitware.com Tue Dec 9 14:30:06 2014 From: brad.king at kitware.com (Brad King) Date: Tue, 09 Dec 2014 14:30:06 -0500 Subject: [CMake] ExternalProject with target_link_library produces incorrect linking? In-Reply-To: References: Message-ID: <54874DBE.5040908@kitware.com> On 12/09/2014 12:26 PM, J. Caleb Wherry wrote: > add_library(ExtLib SHARED IMPORTED) > set_property(TARGET ExtLib PROPERTY IMPORTED_LOCATION "${CMAKE_BINARY_DIR}/${EXT_LIB_NAME}") > add_dependencies(ExtLib ExtLibBuild) Thanks for the complete/simple example. The problem is that the libExtLib.so file built by the external project does not have DT_SONAME set by the linker. When a linker is given a path to a shared library file that has no soname then the path is copied into the DT_NEEDED field of the consumer since it has no soname to use for that. There are two solutions: 1. Make sure DT_SONAME gets set properly by the external build system. 2. Tell CMake that the imported library file has no soname: set_property(TARGET ExtLib PROPERTY IMPORTED_NO_SONAME 1) CMake will then link it via -lExtLib and the linker will not store the path to the file in DT_NEEDED but only the file name. Either of these should resolve the issue. Number 1 is cleaner. -Brad From cxjohnson at gmail.com Tue Dec 9 14:39:34 2014 From: cxjohnson at gmail.com (Chris Johnson) Date: Tue, 9 Dec 2014 13:39:34 -0600 Subject: [CMake] Is this expected behavior? In-Reply-To: <5487226D.2020000@kitware.com> References: <54865926.5080609@kitware.com> <5487226D.2020000@kitware.com> Message-ID: That's the strange thing. All the dependencies in those files in the real project look right. It's as if they are just not getting used during the library compile, although they do get used when the program is linked to the library and the "current-ness" of the library is checked before the actual link. On Tue, Dec 9, 2014 at 10:25 AM, Bill Hoffman wrote: > On 12/9/2014 9:45 AM, Chris Johnson wrote: > >> Well of course it had to not be all that simple. My first attempt to >> create a simple (2 header files in library) example failed to fail in >> the same way as my much more complex real-life project. :-p >> >> I will continue to try to whittle down the real problem to the smallest >> possible set, but it may take a while. >> > find . -name depend.make > in the build tree will show you were all the depend information is kept. > Those files will not be populated until after the first build. But that > might give you a clue as to what is going wrong. > > > -Bill > > -- > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From calebwherry at gmail.com Tue Dec 9 16:05:22 2014 From: calebwherry at gmail.com (J. Caleb Wherry) Date: Tue, 9 Dec 2014 16:05:22 -0500 Subject: [CMake] ExternalProject with target_link_library produces incorrect linking? In-Reply-To: <54874DBE.5040908@kitware.com> References: <54874DBE.5040908@kitware.com> Message-ID: Works like a charm, I knew I was overlooking something small. Thanks, Brad! -Caleb On Tue, Dec 9, 2014 at 2:30 PM, Brad King wrote: > On 12/09/2014 12:26 PM, J. Caleb Wherry wrote: > > add_library(ExtLib SHARED IMPORTED) > > set_property(TARGET ExtLib PROPERTY IMPORTED_LOCATION > "${CMAKE_BINARY_DIR}/${EXT_LIB_NAME}") > > add_dependencies(ExtLib ExtLibBuild) > > Thanks for the complete/simple example. The problem is that > the libExtLib.so file built by the external project does not > have DT_SONAME set by the linker. When a linker is given a > path to a shared library file that has no soname then the path > is copied into the DT_NEEDED field of the consumer since it > has no soname to use for that. > > There are two solutions: > > 1. Make sure DT_SONAME gets set properly by the external build system. > > 2. Tell CMake that the imported library file has no soname: > > set_property(TARGET ExtLib PROPERTY IMPORTED_NO_SONAME 1) > > CMake will then link it via -lExtLib and the linker will not > store the path to the file in DT_NEEDED but only the file name. > > Either of these should resolve the issue. Number 1 is cleaner. > > -Brad > > -- J. Caleb Wherry *Scientific Software Engineer* http://www.calebwherry.com +1 (615) 708-5651 calebwherry at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.maynard at kitware.com Tue Dec 9 17:01:28 2014 From: robert.maynard at kitware.com (Robert Maynard) Date: Tue, 9 Dec 2014 17:01:28 -0500 Subject: [CMake] [ANNOUNCE] CMake 3.1.0-rc3 is now ready! Message-ID: I am proud to announce the CMake 3.1 third release candidate. Sources and binaries are available at: http://www.cmake.org/files/v3.1/?C=M;O=D Documentation is available at: http://www.cmake.org/cmake/help/v3.1 Release notes appear below and are also published at http://www.cmake.org/cmake/help/v3.1/release/3.1.0.html Some of the more significant features of CMake 3.1 are: * Windows Phone and Windows Store support has been added to Visual Studio 11 (2012) and above Generators. * NVIDIA Nsight Tegra support has been added to Visual Studio 10 (2010) and above Generators. * New "target_compile_features" command allows populating target based compile features. CMake uses this information to ensure that the compiler in use is capable of building the target, and to add any necessary compile flags such as -std=gnu++11 to support language features. More information on this is found at: - http://www.cmake.org/cmake/help/v3.1/manual/cmake-compile-features.7.html * The syntax for *Variable References* and *Escape Sequences* was simplified in order to allow a much faster implementation. See policy "CMP0053". * The "if" command no longer automatically dereferences variables named in quoted or bracket arguments. See policy "CMP0054". * The target property "SOURCES" now generally supports "Generator Expressions". The generator expressions may be used in the "add_library" and "add_executable" commands. * It is now possible to write and append to the target property "SOURCES". The variable "CMAKE_DEBUG_TARGET_PROPERTIES" can be used to trace the origin of sources. * CPack gained "7Z" and "TXZ" generators supporting lzma-compressed archives. * The ExternalProject module has learned to support lzma-compressed source tarballs with ".7z", ".tar.xz", and ".txz" extensions. * The ExternalProject module ExternalProject_Add command learned a new BUILD_ALWAYS option to cause the external project build step to run every time the host project is built. * The ctest_coverage command learned to support Intel coverage files with the "codecov" tool. * The ctest_memcheck command learned to support sanitizer modes, including "AddressSanitizer", "MemorySanitizer", "ThreadSanitizer", and "UndefinedBehaviorSanitizer". Deprecated and Removed Features: * In CMake 3.0 the "target_link_libraries" command accidentally began allowing unquoted arguments to use Generator Expressions containing a semicolon separated list within them. For example: set(libs B C) target_link_libraries(A PUBLIC $) This is equivalent to writing: target_link_libraries(A PUBLIC $) and was never intended to work. It did not work in CMake 2.8.12. Such generator expressions should be in quoted arguments: set(libs B C) target_link_libraries(A PUBLIC "$") CMake 3.1 again requires the quotes for this to work correctly. CMake 3.1.0 Release Notes ************************* Changes made since CMake 3.0.0 include the following. Documentation Changes ===================== * A new "cmake-compile-features(7)" manual was added. New Features ============ Generators ---------- * The "Visual Studio 14 2015" generator was added. Windows Phone and Windows Store ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * Generators for Visual Studio 11 (2012) and above learned to generate projects for Windows Phone and Windows Store. One may set the "CMAKE_SYSTEM_NAME" variable to "WindowsPhone" or "WindowsStore" on the "cmake(1)" command-line or in a "CMAKE_TOOLCHAIN_FILE" to activate these platforms. Also set "CMAKE_SYSTEM_VERSION" to "8.0" or "8.1" to specify the version of Windows to be targeted. NVIDIA Nsight Tegra ~~~~~~~~~~~~~~~~~~~ * Generators for Visual Studio 10 (2010) and above learned to generate projects for NVIDIA Nsight Tegra Visual Studio Edition. One may set the "CMAKE_SYSTEM_NAME" variable to "Android" on the "cmake(1)" command-line or in a "CMAKE_TOOLCHAIN_FILE" to activate this platform. Syntax ------ * The "cmake-language(7)" syntax for *Variable References* and *Escape Sequences* was simplified in order to allow a much faster implementation. See policy "CMP0053". * The "if()" command no longer automatically dereferences variables named in quoted or bracket arguments. See policy "CMP0054". Commands -------- * The "add_custom_command()" command learned to interpret "cmake- generator-expressions(7)" in arguments to "DEPENDS". * The "export(PACKAGE)" command learned to check the "CMAKE_EXPORT_NO_PACKAGE_REGISTRY" variable to skip exporting the package. * The "file(STRINGS)" command gained a new "ENCODING" option to enable extraction of "UTF-8" strings. * The "find_package()" command learned to check the "CMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY" and "CMAKE_FIND_PACKAGE_NO_SYSTEM_PACKAGE_REGISTRY" variables to skip searching the package registries. * The "get_property()" command learned a new "INSTALL" scope for properties. * The "install()" command learned a "MESSAGE_NEVER" option to avoid output during installation. * The "set_property()" command learned a new "INSTALL" scope for properties. * The "string()" command learned a new "GENEX_STRIP" subcommand which removes "generator expression". * The "string()" command learned a new "UUID" subcommand to generate a univerally unique identifier. * New "target_compile_features()" command allows populating the "COMPILE_FEATURES" target property, just like any other build variable. * The "target_sources()" command was added to add to the "SOURCES" target property. Variables --------- * The Visual Studio generators for versions 8 (2005) and above learned to read the target platform name from a new "CMAKE_GENERATOR_PLATFORM" variable when it is not specified as part of the generator name. The platform name may be specified on the "cmake(1)" command line with the "-A" option, e.g. "-G "Visual Studio 12 2013" -A x64". * The "CMAKE_GENERATOR_TOOLSET" variable may now be initialized in a toolchain file specified by the "CMAKE_TOOLCHAIN_FILE" variable. This is useful when cross-compiling with the Xcode or Visual Studio generators. * The "CMAKE_INSTALL_MESSAGE" variable was introduced to optionally reduce output installation. Properties ---------- * New "CXX_STANDARD" and "CXX_EXTENSIONS" target properties may specify values which CMake uses to compute required compile options such as "-std=c++11" or "-std=gnu++11". The "CMAKE_CXX_STANDARD" and "CMAKE_CXX_EXTENSIONS" variables may be set to initialize the target properties. * New "C_STANDARD" and "C_EXTENSIONS" target properties may specify values which CMake uses to compute required compile options such as "-std=c11" or "-std=gnu11". The "CMAKE_C_STANDARD" and "CMAKE_C_EXTENSIONS" variables may be set to initialize the target properties. * New "COMPILE_FEATURES" target property may contain a list of features required to compile a target. CMake uses this information to ensure that the compiler in use is capable of building the target, and to add any necessary compile flags to support language features. * New "COMPILE_PDB_NAME" and "COMPILE_PDB_OUTPUT_DIRECTORY" target properties were introduced to specify the MSVC compiler program database file location ("cl /Fd"). This complements the existing "PDB_NAME" and "PDB_OUTPUT_DIRECTORY" target properties that specify the linker program database file location ("link /pdb"). * The "INTERFACE_LINK_LIBRARIES" target property now supports a "$" "generator expression". * A new "INTERFACE_SOURCES" target property was introduced. This is consumed by dependent targets, which compile and link the listed sources. * The "SOURCES" target property now contains "generator expression" such as "TARGET_OBJECTS" when read at configure time, if policy "CMP0051" is "NEW". * The "SOURCES" target property now generally supports "generator expression". The generator expressions may be used in the "add_library()" and "add_executable()" commands. * It is now possible to write and append to the "SOURCES" target property. The "CMAKE_DEBUG_TARGET_PROPERTIES" variable may be used to trace the origin of sources. * A "VS_DEPLOYMENT_CONTENT" source file property was added to tell the Visual Studio generators to mark content for deployment in Windows Phone and Windows Store projects. * The "VS_WINRT_COMPONENT" target property was created to tell Visual Studio generators to compile a shared library as a Windows Runtime (WinRT) component. * A "VS_DEPLOYMENT_LOCATION" source file property was added to tell the Visual Studio generators the relative location of content marked for deployment in Windows Phone and Windows Store projects. * The "Xcode" generator learned to check source file properties "XCODE_EXPLICIT_FILE_TYPE" and "XCODE_LAST_KNOWN_FILE_TYPE" for a custom Xcode file reference type. Modules ------- * The "BundleUtilities" module learned to resolve and replace "@rpath" placeholders on OS X to correctly bundle applications using them. * The "CMakePackageConfigHelpers" module "configure_package_config_file()" command learned a new "INSTALL_PREFIX" option to generate package configuration files meant for a prefix other than "CMAKE_INSTALL_PREFIX". * The "CheckFortranSourceCompiles" module was added to provide a "CHECK_Fortran_SOURCE_COMPILES" macro. * The "ExternalData" module learned to tolerate a "DATA{}" reference to a missing source file with a warning instead of rejecting it with an error. This helps developers write new "DATA{}" references to test reference outputs that have not yet been created. * The "ExternalProject" module learned to support lzma-compressed source tarballs with ".7z", ".tar.xz", and ".txz" extensions. * The "ExternalProject" module "ExternalProject_Add" command learned a new "BUILD_ALWAYS" option to cause the external project build step to run every time the host project is built. * The "ExternalProject" module "ExternalProject_Add" command learned a new "EXCLUDE_FROM_ALL" option to cause the external project target to have the "EXCLUDE_FROM_ALL" target property set. * The "ExternalProject" module "ExternalProject_Add_Step" command learned a new "EXCLUDE_FROM_MAIN" option to cause the step to not be a direct dependency of the main external project target. * The "ExternalProject" module "ExternalProject_Add" command learned a new "DOWNLOAD_NO_PROGRESS" option to disable progress output while downloading the source tarball. * The "FeatureSummary" module "feature_summary" API learned to accept multiple values for the "WHAT" option and combine them appropriately. * The "FindCUDA" module learned to support "fatbin" and "cubin" modules. * The "FindGTest" module "gtest_add_tests" macro learned a new "AUTO" option to automatically read the "SOURCES" target property of the test executable and scan the source files for tests to be added. * The "FindGLEW" module now provides imported targets. * The "FindGLUT" module now provides imported targets. * The "FindHg" module gained a new "Hg_WC_INFO" macro to help run "hg" to extract information about a Mercurial work copy. * The "FindOpenCL" module was introduced. * The "FindOpenMP" module learned to support Fortran. * The "FindPkgConfig" module learned to use the "PKG_CONFIG" environment variable value as the "pkg-config" executable, if set. * The "FindXercesC" module was introduced. * The "FindZLIB" module now provides imported targets. * The "GenerateExportHeader" module "generate_export_header" function learned to allow use with *Object Libraries*. * The "InstallRequiredSystemLibraries" module gained a new "CMAKE_INSTALL_OPENMP_LIBRARIES" option to install MSVC OpenMP runtime libraries. * The "UseSWIG" module learned to detect the module name from ".i" source files if possible to avoid the need to set the "SWIG_MODULE_NAME" source file property explicitly. * The "WriteCompilerDetectionHeader" module was added to allow creation of a portable header file for compiler optional feature detection. Generator Expressions --------------------- * New "COMPILE_FEATURES" "generator expression" allows setting build properties based on available compiler features. CTest ----- * The "ctest_coverage()" command learned to read variable "CTEST_COVERAGE_EXTRA_FLAGS" to set "CoverageExtraFlags". * The "ctest_coverage()" command learned to support Intel coverage files with the "codecov" tool. * The "ctest_memcheck()" command learned to support sanitizer modes, including "AddressSanitizer", "MemorySanitizer", "ThreadSanitizer", and "UndefinedBehaviorSanitizer". Options may be set using the new "CTEST_MEMORYCHECK_SANITIZER_OPTIONS" variable. CPack ----- * "cpack(1)" gained an "IFW" generator to package using Qt Framework Installer tools. See the "CPackIFW" module. * "cpack(1)" gained "7Z" and "TXZ" generators supporting lzma- compressed archives. * The "CPackDeb" module learned a new "CPACK_DEBIAN_COMPRESSION_TYPE" variable to set the tarball compression type. * The "cpack(1)" "WiX" generator learned to support a "CPACK_WIX_ACL" installed file property to specify an Access Control List. Other ----- * The "cmake(1)" "-E" option learned a new "env" command. * The "cmake(1)" "-E tar" command learned to support lzma-compressed files. * *Object Libraries* may now have extra sources that do not compile to object files so long as they would not affect linking of a normal library (e.g. ".dat" is okay but not ".def"). * Visual Studio generators for VS 8 and later learned to support the "ASM_MASM" language. * The Visual Studio generators learned to treat ".hlsl" source files as High Level Shading Language sources (using "FXCompile" in ".vcxproj" files). Source file properties "VS_SHADER_TYPE", "VS_SHADER_MODEL", and "VS_SHADER_ENTRYPOINT" were added added to specify the shader type, model, and entry point name. New Diagnostics =============== * Policy "CMP0052" introduced to control directories in the "INTERFACE_INCLUDE_DIRECTORIES" of exported targets. Deprecated and Removed Features =============================== * In CMake 3.0 the "target_link_libraries()" command accidentally began allowing unquoted arguments to use "generator expressions" containing a (";" separated) list within them. For example: set(libs B C) target_link_libraries(A PUBLIC $) This is equivalent to writing: target_link_libraries(A PUBLIC $) and was never intended to work. It did not work in CMake 2.8.12. Such generator expressions should be in quoted arguments: set(libs B C) target_link_libraries(A PUBLIC "$") CMake 3.1 again requires the quotes for this to work correctly. * Callbacks established by the "variable_watch()" command will no longer receive the "ALLOWED_UNKNOWN_READ_ACCESS" access type when the undocumented "CMAKE_ALLOW_UNKNOWN_VARIABLE_READ_ACCESS" variable is set. Uninitialized variable accesses will always be reported as "UNKNOWN_READ_ACCESS". * The "CMakeDetermineVSServicePack" module now warns that it is deprecated and should not longer be used. Use the "CMAKE__COMPILER_VERSION" variable instead. * The "FindITK" module has been removed altogether. It was a thin- wrapper around "find_package(ITK ... NO_MODULE)". This produces much clearer error messages when ITK is not found. * The "FindVTK" module has been removed altogether. It was a thin- wrapper around "find_package(VTK ... NO_MODULE)". This produces much clearer error messages when VTK is not found. The module also provided compatibility support for finding VTK 4.0. This capability has been dropped. Other Changes ============= * The "cmake-gui(1)" learned to capture output from child processes started by the "execute_process()" command and display it in the output window. * The "cmake-language(7)" internal implementation of generator expression and list expansion parsers have been optimized and shows non-trivial speedup on large projects. * The Makefile generators learned to use response files with GNU tools on Windows to pass library directories and names to the linker. * When generating linker command-lines, CMake now avoids repeating items corresponding to SHARED library targets. * Support for the Open Watcom compiler has been overhauled. The "CMAKE__COMPILER_ID" is now "OpenWatcom", and the "CMAKE__COMPILER_VERSION" now uses the Open Watcom external version numbering. The external version numbers are lower than the internal version number by 11. * The "cmake-mode.el" major Emacs editing mode no longer treats "_" as part of words, making it more consistent with other major modes. ------------------------------------------------------------------- Changes made since CMake 3.1.0-rc2: Ben Boeckel (1): Revert "ClearMatches: Only clear matches which were actually set" (#15261) Brad King (18): Help: Document COMPONENT option of install(SCRIPT/CODE) (#14956) Do not use just-built CMake to install itself when cross-compiling (#15248) KWSys SharedForward: Hard-code the ldpath buffer size to below VS 14 limit VS: Rename VS 14 generator to 'Visual Studio 14 2015' Help: target_include_directories does not allow target names Utilities/Sphinx: Add missing call to note_explicit_target FindJava: Do not accept OS X stub 'java' as Java Fix lookup of source names after conversion to their actual case (#15259) Help: Format set_property and get_property command docs Help: Add 3.1 release notes for INSTALL property scope CMakeParseImplicitLinkInfo: Fix implicit library logging Makefile: Do not create an empty linker response file FindOpenGL: Revert support for imported targets (#15267) Help: Document Nsight Tegra toolchain configuration (#15276) Utilities/Sphinx: Fix link targets for mixed-case command names Modules: Rename FindXerces to FindXercesC Help: Document file(GENERATE) signature option order CMake 3.1.0-rc3 Cedric Perthuis (1): VS: Add source file properties to set the hlsl shader entry point and model Christoph Gr?ninger (1): Help: Remove duplicate '#' in CMP0053 valid character list Christopher Dembia (1): Help: Add missing space to ctest -j option description Christopher Gittner (1): FindwxWidgets: Add versions 3.0.1 and 3.0.2 David Demelier (2): Help: Fix typo in cmake-compile-features(7) manual Help: Fix typo in CMAKE_CXX_KNOWN_FEATURES docs Dmitry Polyanitsa (1): VS: Change Nsight Tegra 2.0 Project Revision Number from 8 to 9 Fraser Hutchison (1): Avoid if() quoted auto-dereference when checking for "MSVC" Gilles Khouzam (3): VS: Improve error messages when compiler is not detected (#15228) VS: Do not produce WinMD file for OBJECT libraries (#15228) VS: Add source file property to specify Windows App deployment location Konstantin Podsvirov (1): CPackIFW: Correction of the module documentation Nils Gladitz (2): FindOpenMP: Use fixed form Fortran test program Help: Document installed file property API Pascal Bach (1): VS, WINCE: Fix entry point for Unicode builds Rolf Eike Beer (1): FindPythonInterp: fix version component variables for Python 1.4 (#15275) Stephen Kelly (12): Features: Don't record for AppleClang Features: Test the CXX compiler only if it has features. Features: Fix references to CXX compiler version in Clang-C.cmake. Features: Record C++11 dialect switch only for GNU 4.7 and later. Features: Fix the default C dialect for Clang and GNU. Fix the test for running the CxxDialog unit test. WCDH: Don't imply that MSVC is supported by the module. WCDH: Make the header -Wundef safe for the C language. Genex: Fix evaluation context propagation for TARGET_OBJECTS. cmTarget: Don't allow relative paths in INTERFACE_SOURCES Export: Disallow export of targets with INTERFACE_SOURCES Help: Document the export limitation of INTERFACE_SOURCES. From chrysalisx at gmail.com Tue Dec 9 18:38:37 2014 From: chrysalisx at gmail.com (Walter Gray) Date: Tue, 09 Dec 2014 15:38:37 -0800 Subject: [CMake] Copying shared libraries in a post-build step Message-ID: <548787FD.5020503@gmail.com> Hey all, I'm working on a module that will allow me to automatically copy all the required .dll files as defined by well-formed import library targets to the appropriate location (same folder for windows, Frameworks folder for OSX bundle, ect). I've got the code that scans an executable's INTERFACE_LINK_LIBRARIES property recursively to find all such shared library, however I'm running into a small problem. I really like using file globbing in higher level source directories to add all appropriate sub-directories, but this means that sometimes a dependency will not be fully defined yet. This is normally fine since these things are usually resolved at *generation* time, but since I'm doing a manual traversal of the list of link libraries at config time that's not really acceptable. I realize I could just not do the globbing and just make sure the directories were setup in the correct order, but I really don't like making the add_subdirectory calls order dependent. One solution I've come up with is to add the targets I want to do this to to a global list, then iterate over that list as the last step in my top-level cmake lists file, but that has the issue that I can no longer use add_custom_command on those targets at that point. I'm wondering 3 things: 1)What is the reasoning behind not allowing add_custom_command on targets not defined in the current directory? Especially now that SOURCE can be modified, the restriction seems very arbitrary. 2)How stupid would it be to reserve the command using something like add_custom_command(TARGET ${target} POST_BUILD COMMAND $) then use set_property(TARGET ${target} APPEND PROPERTY COPY_SHARED_LIBS_COMMAND to add more copy steps to the command? 3) Am I completely missing something and there's already a totally well supported way of making sure that an executable's shared library dependencies end up in the correct directory? I couldn't find a really satisfactory answer on stack overflow or the archives. Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From d3ck0r at gmail.com Tue Dec 9 19:15:18 2014 From: d3ck0r at gmail.com (J Decker) Date: Tue, 9 Dec 2014 16:15:18 -0800 Subject: [CMake] Copying shared libraries in a post-build step In-Reply-To: <548787FD.5020503@gmail.com> References: <548787FD.5020503@gmail.com> Message-ID: This sounds more like an install phase... to bring the whole package together in one appropriate place. if( WIN32 ) INSTALL( TARGET RUNTIME DESTINATION bin LIBRARY DESTINATION bin ARCHIVE DESTINATION lib ) else( WIN32 ) INSTALL( TARGET RUNTIME DESTINATION bin LIBRARY DESTINATION lib ARCHIVE DESTINATION lib ) endif( WIN32 ) On Tue, Dec 9, 2014 at 3:38 PM, Walter Gray wrote: > Hey all, > I'm working on a module that will allow me to automatically copy all the > required .dll files as defined by well-formed import library targets to the > appropriate location (same folder for windows, Frameworks folder for OSX > bundle, ect). I've got the code that scans an executable's > INTERFACE_LINK_LIBRARIES property recursively to find all such shared > library, however I'm running into a small problem. I really like using > file globbing in higher level source directories to add all appropriate > sub-directories, but this means that sometimes a dependency will not be > fully defined yet. This is normally fine since these things are usually > resolved at *generation* time, but since I'm doing a manual traversal of > the list of link libraries at config time that's not really acceptable. I > realize I could just not do the globbing and just make sure the directories > were setup in the correct order, but I really don't like making the > add_subdirectory calls order dependent. > > One solution I've come up with is to add the targets I want to do this to > to a global list, then iterate over that list as the last step in my > top-level cmake lists file, but that has the issue that I can no longer use > add_custom_command on those targets at that point. I'm wondering 3 things: > > 1)What is the reasoning behind not allowing add_custom_command on targets > not defined in the current directory? Especially now that SOURCE can be > modified, the restriction seems very arbitrary. > > 2)How stupid would it be to reserve the command using something like > add_custom_command(TARGET ${target} POST_BUILD COMMAND > $) > then use set_property(TARGET ${target} APPEND PROPERTY > COPY_SHARED_LIBS_COMMAND to add more copy steps to the command? > > 3) Am I completely missing something and there's already a totally well > supported way of making sure that an executable's shared library > dependencies end up in the correct directory? I couldn't find a really > satisfactory answer on stack overflow or the archives. > > Thanks! > > -- > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From d3ck0r at gmail.com Tue Dec 9 19:16:08 2014 From: d3ck0r at gmail.com (J Decker) Date: Tue, 9 Dec 2014 16:16:08 -0800 Subject: [CMake] Copying shared libraries in a post-build step In-Reply-To: References: <548787FD.5020503@gmail.com> Message-ID: Mind you 'install' doesn't have to be '/usr' or 'program files/whatever' but could be 'output' which will be relative to ${CMAKE_BINARY_DIR} if not absolute On Tue, Dec 9, 2014 at 4:15 PM, J Decker wrote: > This sounds more like an install phase... to bring the whole package > together in one appropriate place. > > if( WIN32 ) > INSTALL( TARGET RUNTIME DESTINATION bin LIBRARY DESTINATION bin > ARCHIVE DESTINATION lib ) > else( WIN32 ) > INSTALL( TARGET RUNTIME DESTINATION bin LIBRARY DESTINATION lib > ARCHIVE DESTINATION lib ) > endif( WIN32 ) > > On Tue, Dec 9, 2014 at 3:38 PM, Walter Gray wrote: > >> Hey all, >> I'm working on a module that will allow me to automatically copy all the >> required .dll files as defined by well-formed import library targets to the >> appropriate location (same folder for windows, Frameworks folder for OSX >> bundle, ect). I've got the code that scans an executable's >> INTERFACE_LINK_LIBRARIES property recursively to find all such shared >> library, however I'm running into a small problem. I really like using >> file globbing in higher level source directories to add all appropriate >> sub-directories, but this means that sometimes a dependency will not be >> fully defined yet. This is normally fine since these things are usually >> resolved at *generation* time, but since I'm doing a manual traversal of >> the list of link libraries at config time that's not really acceptable. I >> realize I could just not do the globbing and just make sure the directories >> were setup in the correct order, but I really don't like making the >> add_subdirectory calls order dependent. >> >> One solution I've come up with is to add the targets I want to do this to >> to a global list, then iterate over that list as the last step in my >> top-level cmake lists file, but that has the issue that I can no longer use >> add_custom_command on those targets at that point. I'm wondering 3 things: >> >> 1)What is the reasoning behind not allowing add_custom_command on targets >> not defined in the current directory? Especially now that SOURCE can be >> modified, the restriction seems very arbitrary. >> >> 2)How stupid would it be to reserve the command using something like >> add_custom_command(TARGET ${target} POST_BUILD COMMAND >> $) >> then use set_property(TARGET ${target} APPEND PROPERTY >> COPY_SHARED_LIBS_COMMAND to add more copy steps to the command? >> >> 3) Am I completely missing something and there's already a totally well >> supported way of making sure that an executable's shared library >> dependencies end up in the correct directory? I couldn't find a really >> satisfactory answer on stack overflow or the archives. >> >> Thanks! >> >> -- >> >> 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 >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ewmailing at gmail.com Tue Dec 9 19:34:02 2014 From: ewmailing at gmail.com (Eric Wing) Date: Tue, 9 Dec 2014 16:34:02 -0800 Subject: [CMake] Copying shared libraries in a post-build step In-Reply-To: <548787FD.5020503@gmail.com> References: <548787FD.5020503@gmail.com> Message-ID: On 12/9/14, Walter Gray wrote: > Hey all, > I'm working on a module that will allow me to automatically copy all the > required .dll files as defined by well-formed import library targets to > the appropriate location (same folder for windows, Frameworks folder for > OSX bundle, ect). I've got the code that scans an executable's > INTERFACE_LINK_LIBRARIES property recursively to find all such shared > library, however I'm running into a small problem. I really like using > file globbing in higher level source directories to add all appropriate > sub-directories, but this means that sometimes a dependency will not be > fully defined yet. This is normally fine since these things are usually > resolved at *generation* time, but since I'm doing a manual traversal of > the list of link libraries at config time that's not really acceptable. > I realize I could just not do the globbing and just make sure the > directories were setup in the correct order, but I really don't like > making the add_subdirectory calls order dependent. > > One solution I've come up with is to add the targets I want to do this > to to a global list, then iterate over that list as the last step in my > top-level cmake lists file, but that has the issue that I can no longer > use add_custom_command on those targets at that point. I'm wondering 3 > things: > > 1)What is the reasoning behind not allowing add_custom_command on > targets not defined in the current directory? Especially now that SOURCE > can be modified, the restriction seems very arbitrary. > > 2)How stupid would it be to reserve the command using something like > add_custom_command(TARGET ${target} POST_BUILD COMMAND > $) > then use set_property(TARGET ${target} APPEND PROPERTY > COPY_SHARED_LIBS_COMMAND to add more copy steps to the command? > > 3) Am I completely missing something and there's already a totally well > supported way of making sure that an executable's shared library > dependencies end up in the correct directory? I couldn't find a really > satisfactory answer on stack overflow or the archives. > > Thanks! > I think this is a good idea if you can pull it off. I recently wrote a lot of excruciating CMake code to do this for me. (I also was dealing with resource and plugin code which shares similar issues.) This actually took me a very long time to implement and it would be better if CMake handled this automatically. Here is a list of ideas that I needed to deal with: - My motivation was to build a runnable product when you build. On Visual Studio, you can't run through the debugger because none of the .dlls are in place. Similarly on Mac, iOS, Android, and now WinRT, there is no separation/distinction between compiling the executable and packaging the contents. This is in my opinion of the most problematic design issues in CMake. I also strongly feel that having to run the install target is very wrong because it violates the normal workflow on all these platforms and you also end up developing/testing something different than what you ship to testers/users. - The fix_bundle_utils didn't work for me because it did stuff in the install stage (too late). Also, it didn't handle my usage of Mac @rpath (not sure if that was fixed since) so I gave up on it early. - I needed an explicit declaration mechanism to describe which libraries needed to be bundled (or which did not). Some are system libraries while others need to be redistributed with the app. And some might be static libraries which you don't copy. (A .lib/.dll on Visual Studio and a .framework on iOS is ambiguous to whether they are static or dynamic.) - There was also both implicit knowledge about where they go for each platform (had to make decisions about Linux and RPATH_ORIGIN), and also made decisions when they were nested in subdirectories. (I preserve the layout.) - For Visual Studio, that explicit mechanism had to be aware that you link with .libs, but copy the .dll. - I didn't do an explicit scan of the libraries for dependencies for multiple reasons. One important reason to me though is I want the build to be as fast as possible (ideally on par with Xcode normally does which is apples-to-apples in this case). - I don't think scanning INTERFACE_LINK_LIBRARIES is sufficient because it won't capture what libraries each of those might depend on. For example, I deal with a pre-build SDL_image library on Windows which depends on libtiff, libjpeg, libpng. libpng then in turn depends on zlib. - The complexity of recursively walking the dependencies, and then also knowing which ones are system supplied libraries and which are not is really hard, which is another reason I went the explicit declaration route. (And shipping Linux binaries is a nightmare; you have to make hard decisions about what is a system library and what you need to need to ship yourself.) - Mac/iOS framework copies were a pain because they are bundles (directory structures) and also have symlinks, both of which CMake does not support well for copying. I ended up using rsync on those platforms. - rsync had a nice advantage of resyncing if the source framework/library changed and its a very efficient copy. - But rsync got me into performance overhead when I introduced codesigning because codesigning always changes the library, causing the library to be resynced with the original and then needing to codesign again. (Codesigning is a slow operation.) - I also need an explicit mechanism that signed libraries/plugins. This signing MUST happen before Xcode tries to do the final codesigning for your application. (I don't know if POST_BUILD is too late or not.) - I was thinking that it would be nice if there was a CMake way to declare which things need to be codesigned too. (Some kind of SET_PROPERTIES thing.) - In some cases, libraries get nested into subdirectories and this information needs to be preserved for packing. Traversing the file hierarchy relative to the bundles and preserving this information was really nasty. I needed data structures in CMake and ended up doing really nasty string tricks since everything is a string in CMake. - I needed to handle things like rpath (Linux, Mac). - Note, almost all this stuff I ended up re-applying for plugins and resources. - I ended up dealing with icons, launch screens, application manifests, sandboxing entitlements as completely separate entities. There's probably a lot more. Thanks, Eric -- Beginning iPhone Games Development http://playcontrol.net/iphonegamebook/ From d3ck0r at gmail.com Tue Dec 9 19:44:42 2014 From: d3ck0r at gmail.com (J Decker) Date: Tue, 9 Dec 2014 16:44:42 -0800 Subject: [CMake] Copying shared libraries in a post-build step In-Reply-To: References: <548787FD.5020503@gmail.com> Message-ID: This is all handled by install. Plugins get installed in their correct directory resources; data files etc get installed in their correct directory... each type of target is handled with INSTALL( TARGET ) but you get 3 destinations; RUNTIME (exe), LIBRARY(.dll,.so) and ARCHIVE (.lib,.a) ; they claim that runtime is .dll on windows; but this is just not true; if library is set, DLL goes to that path... but otherwise... Sounds really like you're working to build a package, which install is intended to do. With a few more cmake commands after building install rules, can use package command and build an installable.... NSIS works good for windows; I know there's MAC dmz(?) support also... but the first thing you'd do is build a directory structure. Again INSTALL doesn't have to be 'install' but can be 'write to this relative directory, this directory structure' Then you just have to right-click on the project, edit debugging properties, and browse to the installed location. CMAKE is really fast in visual studio if you have a large project of lots of targets and only a few rebuild and copy. The INSTALL output can be really noisy, but there's a new setting that can be applied at the top of the root cmake script file... set( CMAKE_INSTALL_MESSAGE "LAZY" ) that will cut down on the output and only show what was actually updated. On Tue, Dec 9, 2014 at 4:34 PM, Eric Wing wrote: > On 12/9/14, Walter Gray wrote: > > Hey all, > > I'm working on a module that will allow me to automatically copy all the > > required .dll files as defined by well-formed import library targets to > > the appropriate location (same folder for windows, Frameworks folder for > > OSX bundle, ect). I've got the code that scans an executable's > > INTERFACE_LINK_LIBRARIES property recursively to find all such shared > > library, however I'm running into a small problem. I really like using > > file globbing in higher level source directories to add all appropriate > > sub-directories, but this means that sometimes a dependency will not be > > fully defined yet. This is normally fine since these things are usually > > resolved at *generation* time, but since I'm doing a manual traversal of > > the list of link libraries at config time that's not really acceptable. > > I realize I could just not do the globbing and just make sure the > > directories were setup in the correct order, but I really don't like > > making the add_subdirectory calls order dependent. > > > > One solution I've come up with is to add the targets I want to do this > > to to a global list, then iterate over that list as the last step in my > > top-level cmake lists file, but that has the issue that I can no longer > > use add_custom_command on those targets at that point. I'm wondering 3 > > things: > > > > 1)What is the reasoning behind not allowing add_custom_command on > > targets not defined in the current directory? Especially now that SOURCE > > can be modified, the restriction seems very arbitrary. > > > > 2)How stupid would it be to reserve the command using something like > > add_custom_command(TARGET ${target} POST_BUILD COMMAND > > $) > > then use set_property(TARGET ${target} APPEND PROPERTY > > COPY_SHARED_LIBS_COMMAND to add more copy steps to the command? > > > > 3) Am I completely missing something and there's already a totally well > > supported way of making sure that an executable's shared library > > dependencies end up in the correct directory? I couldn't find a really > > satisfactory answer on stack overflow or the archives. > > > > Thanks! > > > > > I think this is a good idea if you can pull it off. I recently wrote a > lot of excruciating CMake code to do this for me. (I also was dealing > with resource and plugin code which shares similar issues.) This > actually took me a very long time to implement and it would be better > if CMake handled this automatically. Here is a list of ideas that I > needed to deal with: > > - My motivation was to build a runnable product when you build. On > Visual Studio, you can't run through the debugger because none of the > .dlls are in place. Similarly on Mac, iOS, Android, and now WinRT, > there is no separation/distinction between compiling the executable > and packaging the contents. This is in my opinion of the most > problematic design issues in CMake. I also strongly feel that having > to run the install target is very wrong because it violates the normal > workflow on all these platforms and you also end up developing/testing > something different than what you ship to testers/users. > > - The fix_bundle_utils didn't work for me because it did stuff in the > install stage (too late). Also, it didn't handle my usage of Mac > @rpath (not sure if that was fixed since) so I gave up on it early. > > > - I needed an explicit declaration mechanism to describe which > libraries needed to be bundled (or which did not). Some are system > libraries while others need to be redistributed with the app. And some > might be static libraries which you don't copy. (A .lib/.dll on Visual > Studio and a .framework on iOS is ambiguous to whether they are static > or dynamic.) > > - There was also both implicit knowledge about where they go for > each platform (had to make decisions about Linux and RPATH_ORIGIN), > and also made decisions when they were nested in subdirectories. (I > preserve the layout.) > > - For Visual Studio, that explicit mechanism had to be aware that > you link with .libs, but copy the .dll. > > - I didn't do an explicit scan of the libraries for dependencies > for multiple reasons. One important reason to me though is I want the > build to be as fast as possible (ideally on par with Xcode normally > does which is apples-to-apples in this case). > > - I don't think scanning INTERFACE_LINK_LIBRARIES is > sufficient because it won't capture what libraries each of those might > depend on. For example, I deal with a pre-build SDL_image library on > Windows which depends on libtiff, libjpeg, libpng. libpng then in turn > depends on zlib. > > - The complexity of recursively walking the dependencies, > and then also knowing which ones are system supplied libraries and > which are not is really hard, which is another reason I went the > explicit declaration route. (And shipping Linux binaries is a > nightmare; you have to make hard decisions about what is a system > library and what you need to need to ship yourself.) > > - Mac/iOS framework copies were a pain because they are bundles > (directory structures) and also have symlinks, both of which CMake > does not support well for copying. I ended up using rsync on those > platforms. > > - rsync had a nice advantage of resyncing if the source > framework/library changed and its a very efficient copy. > > - But rsync got me into performance overhead when I introduced > codesigning because codesigning always changes the library, causing > the library to be resynced with the original and then needing to > codesign again. (Codesigning is a slow operation.) > > - I also need an explicit mechanism that signed libraries/plugins. > This signing MUST happen before Xcode tries to do the final > codesigning for your application. (I don't know if POST_BUILD is too > late or not.) > > - I was thinking that it would be nice if there was a CMake way to > declare which things need to be codesigned too. (Some kind of > SET_PROPERTIES thing.) > > - In some cases, libraries get nested into subdirectories and this > information needs to be preserved for packing. Traversing the file > hierarchy relative to the bundles and preserving this information was > really nasty. I needed data structures in CMake and ended up doing > really nasty string tricks since everything is a string in CMake. > > > - I needed to handle things like rpath (Linux, Mac). > > > - Note, almost all this stuff I ended up re-applying for plugins and > resources. > > - I ended up dealing with icons, launch screens, application > manifests, sandboxing entitlements as completely separate entities. > > > There's probably a lot more. > > > Thanks, > Eric > -- > Beginning iPhone Games Development > http://playcontrol.net/iphonegamebook/ > -- > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ewmailing at gmail.com Tue Dec 9 19:58:13 2014 From: ewmailing at gmail.com (Eric Wing) Date: Tue, 9 Dec 2014 16:58:13 -0800 Subject: [CMake] Copying shared libraries in a post-build step In-Reply-To: References: <548787FD.5020503@gmail.com> Message-ID: On 12/9/14, J Decker wrote: > This is all handled by install. I already addressed INSTALL. I know you can change the directory. That is irrelevant to the point which I already addressed. > > Sounds really like you're working to build a package, which install is > intended to do. Another problem which I didn't make explicit was that Xcode's codesigning and entitlements phase will not work with INSTALL because it signs when you build via Xcode. And there are cases where you must develop and test with codesigning and entitlements enabled, like testing App Store purchases, Game Center, or want to use the new built-into-Safari JavaScriptCore debugger if you have a JSContext in your app. Also, iOS/Android/WinRT, the INSTALL target is useless. The INSTALL thing is a hack in my opinion that we as a community have accepted as a solution. I'm now calling it out as a design problem in CMake, especially as the winds have shifted to more platforms focusing on shipping binaries than the former and now treat packaging as a first class citizen. It is an impediment to the natural workflow on those platforms, it is an impediment to people adopting CMake, and it is an impediment to people wanting to deal with native languages because build systems are too complicated. (The scripts I wrote are intended to deal with all those things in a new middleware product I'm developing and hopefully bring native crossplatform development to people that otherwise wouldn't touch it before.) Thanks, Eric -- Beginning iPhone Games Development http://playcontrol.net/iphonegamebook/ From d3ck0r at gmail.com Tue Dec 9 20:19:07 2014 From: d3ck0r at gmail.com (J Decker) Date: Tue, 9 Dec 2014 17:19:07 -0800 Subject: [CMake] Copying shared libraries in a post-build step In-Reply-To: References: <548787FD.5020503@gmail.com> Message-ID: On Tue, Dec 9, 2014 at 4:58 PM, Eric Wing wrote: > On 12/9/14, J Decker wrote: > > This is all handled by install. > > I already addressed INSTALL. I know you can change the directory. That > is irrelevant to the point which I already addressed. > > You gave a personal opinion about install... not sure that addresses it. > > > > > Sounds really like you're working to build a package, which install is > > intended to do. > > Another problem which I didn't make explicit was that Xcode's > codesigning and entitlements phase will not work with INSTALL because > it signs when you build via Xcode. And there are cases where you must > develop and test with codesigning and entitlements enabled, like > testing App Store purchases, Game Center, or want to use the new > built-into-Safari JavaScriptCore debugger if you have a JSContext in > your app. > > Also, iOS/Android/WinRT, the INSTALL target is useless. > Android It's not useless... it puts all the files in a correct place to be able to do manual packaging things. Massaging a system that's already been installed is a lot easier than pulling from sources scattered all over the build directory; and doesn't require a lot of custom macros and scripts to do the job. True; I had to write another cmake layer on top of the already existing projects which go to their install... and make some custom commands for 'install' and 'package' for android that pull from the one place just what it needs to stuff into the android directory... but those scripts were really simple since everything was already in a simple, known location after install. > > The INSTALL thing is a hack in my opinion that we as a community have > accepted as a solution. I'm now calling it out as a design problem in > CMake, especially as the winds have shifted to more platforms focusing > on shipping binaries than the former and now treat packaging as a > first class citizen. It is an impediment to the natural workflow on > those platforms, it is an impediment to people adopting CMake, and it > is an impediment to people wanting to deal with native languages > because build systems are too complicated. (The scripts I wrote are > intended to deal with all those things in a new middleware product I'm > developing and hopefully bring native crossplatform development to > people that otherwise wouldn't touch it before.) > > Your scripts would still only work for one target... since you'd have to pick one to build the rest of the package around, so if I have a build product that has a dozen utilities, rather than having one place they can all work from, I have now to either duplicate all files to all runnable targets or have a central one that would be the only one to work. This is more of a hack. > > Thanks, > Eric > -- > Beginning iPhone Games Development > http://playcontrol.net/iphonegamebook/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ewmailing at gmail.com Tue Dec 9 20:30:03 2014 From: ewmailing at gmail.com (Eric Wing) Date: Tue, 9 Dec 2014 17:30:03 -0800 Subject: [CMake] Copying shared libraries in a post-build step In-Reply-To: References: <548787FD.5020503@gmail.com> Message-ID: >> Your scripts would still only work for one target... since you'd have to > pick one to build the rest of the package around, so if I have a build > product that has a dozen utilities, rather than having one place they can > all work from, I have now to either duplicate all files to all runnable > targets or have a central one that would be the only one to work. This is > more of a hack. I don't think this is true at all. My scripts do the "right" thing when you build and they are efficient. But I still respect INSTALL and you can still install. I still use INSTALL and PACKAGE, particularly the latter on Windows for creating an NSIS installer. Thanks, Eric -- Beginning iPhone Games Development http://playcontrol.net/iphonegamebook/ From d3ck0r at gmail.com Tue Dec 9 20:59:46 2014 From: d3ck0r at gmail.com (J Decker) Date: Tue, 9 Dec 2014 17:59:46 -0800 Subject: [CMake] Copying shared libraries in a post-build step In-Reply-To: References: <548787FD.5020503@gmail.com> Message-ID: > > > I'm now calling it out as a design problem in > CMake, especially as the winds have shifted to more platforms focusing > on shipping binaries than the former and now treat packaging as a > first class citizen. It is an impediment to the natural workflow on > those platforms, it is an impediment to people adopting CMake, and it > is an impediment to people wanting to deal with native languages > because build systems are too complicated. Using cmake requires adaptation of workflow. That in itself is already an added complication for VS etc sort of developers that want to just use the high level IDE functions to, say, add a source file...if you don't want to 'impede natural workflow' don't use cmake? It was an impediment to me when first started, because the makefile system I was coming from I already had targets going to the right locations... had to adapt thinking to allow cmake to track its build products separately and then add an install rule to gather them together.... but doing that once I did I have no regrets. I don't develop for Mac; so don't know issues with signing there.... but then I've not seen a lot of complaints come across the list like 'sure would wish that...' even if you're just shipping binaries likely you also have additional resources needed to be included.... and that the binary will be an installable package. Can still just zip the temp install location and distribute that... "I don't think this is true at all. My scripts do the "right" thing when you build and they are efficient. But I still respect INSTALL and you can still install. I still use INSTALL and PACKAGE, particularly the latter on Windows for creating an NSIS installer." I used some macros to make implementation simpler so I can just do "install_default( target_name)" and even that I don't really like, because it's not 'native' so I found people had issues dealing with it, even if it was just a matter of copy and paste and change a name... adding addtional scripts with their own esoterics I don't think is a good thing either... True; in the beginning, I thought I wanted lists of libraries etc that were used to build an exectuable so I could just reference that and all dependant files... but in reality I didn't really need that once they were just all put in the same location. My old make system used to do a 'program_copy' command which would read a target list of .exe and .dll (or .so on linux) and do a copy of all files that were actually referenced... this failed for plugins though, since they are dynamically referenced through code. > > Thanks, > Eric > -- > Beginning iPhone Games Development > http://playcontrol.net/iphonegamebook/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tim at klingt.org Wed Dec 10 05:14:02 2014 From: tim at klingt.org (Tim Blechmann) Date: Wed, 10 Dec 2014 11:14:02 +0100 Subject: [CMake] Copying shared libraries in a post-build step In-Reply-To: References: <548787FD.5020503@gmail.com> Message-ID: > This sounds more like an install phase... to bring the whole package > together in one appropriate place. > > if( WIN32 ) > INSTALL( TARGET RUNTIME DESTINATION bin LIBRARY DESTINATION bin > ARCHIVE DESTINATION lib ) > else( WIN32 ) > INSTALL( TARGET RUNTIME DESTINATION bin LIBRARY DESTINATION lib > ARCHIVE DESTINATION lib ) > endif( WIN32 ) on unixy platforms, shared libraries can be resolved using rpaths. on windows this is not the case: if you link a dll into an executable the executable will not run, unless the dll can be resolved at startup time. the is typically done by placing he dll next to the exe. the install step is a possible workaround, but in my experience this implies that you have to run the install script in order to debug the binary, which is pretty inconvenient. > On Tue, Dec 9, 2014 at 3:38 PM, Walter Gray > > wrote: > > Hey all, > I'm working on a module that will allow me to automatically copy all > the required .dll files as defined by well-formed import library > targets to the appropriate location (same folder for windows, > Frameworks folder for OSX bundle, ect). I've got the code that > scans an executable's INTERFACE_LINK_LIBRARIES property recursively > to find all such shared library, however I'm running into a small > problem. I really like using file globbing in higher level source > directories to add all appropriate sub-directories, but this means > that sometimes a dependency will not be fully defined yet. This is > normally fine since these things are usually resolved at > *generation* time, but since I'm doing a manual traversal of the > list of link libraries at config time that's not really acceptable. > I realize I could just not do the globbing and just make sure the > directories were setup in the correct order, but I really don't like > making the add_subdirectory calls order dependent. > > One solution I've come up with is to add the targets I want to do > this to to a global list, then iterate over that list as the last > step in my top-level cmake lists file, but that has the issue that I > can no longer use add_custom_command on those targets at that > point. I'm wondering 3 things: > > 1)What is the reasoning behind not allowing add_custom_command on > targets not defined in the current directory? Especially now that > SOURCE can be modified, the restriction seems very arbitrary. > > 2)How stupid would it be to reserve the command using something like > add_custom_command(TARGET ${target} POST_BUILD COMMAND > $) > then use set_property(TARGET ${target} APPEND PROPERTY > COPY_SHARED_LIBS_COMMAND to add more copy steps to the command? > > 3) Am I completely missing something and there's already a totally > well supported way of making sure that an executable's shared > library dependencies end up in the correct directory? I couldn't > find a really satisfactory answer on stack overflow or the archives. > > Thanks! > > -- > > 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 > > > > From d3ck0r at gmail.com Wed Dec 10 05:28:36 2014 From: d3ck0r at gmail.com (J Decker) Date: Wed, 10 Dec 2014 02:28:36 -0800 Subject: [CMake] Copying shared libraries in a post-build step In-Reply-To: References: <548787FD.5020503@gmail.com> Message-ID: On Wed, Dec 10, 2014 at 2:14 AM, Tim Blechmann wrote: > > This sounds more like an install phase... to bring the whole package > > together in one appropriate place. > > > > if( WIN32 ) > > INSTALL( TARGET RUNTIME DESTINATION bin LIBRARY DESTINATION bin > > ARCHIVE DESTINATION lib ) > > else( WIN32 ) > > INSTALL( TARGET RUNTIME DESTINATION bin LIBRARY DESTINATION lib > > ARCHIVE DESTINATION lib ) > > endif( WIN32 ) > > on unixy platforms, shared libraries can be resolved using rpaths. on > windows this is not the case: if you link a dll into an executable the > executable will not run, unless the dll can be resolved at startup time. > the is typically done by placing he dll next to the exe. > > the install step is a possible workaround, but in my experience this > implies that you have to run the install script in order to debug the > binary, which is pretty inconvenient. > > No more inconvenient than building any other target... from the command line cmake --build . <--target install / instead of blank>; or 'make install' instead of 'make' click and build in a gui environment; again not a big issue... and can just select that as the default target anyway... again just a modification to workflow. If it was a base library everything will be rebuilt appropriately and nothing more or less.. just one extra copy step that's pretty quick... and even that only copies what it needs to. So I don't know why you would attribute that as a negative 'pretty inconvenient' when it's really just a thing that just is... nature of the beast although now that you mention it; it would be nice to define install as the default 'all' project. Or do something really rude that would make every target depend on install such that building a sub-executable would still trigger the install script phase. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sergey.nikulov at gmail.com Wed Dec 10 05:29:50 2014 From: sergey.nikulov at gmail.com (Sergei Nikulov) Date: Wed, 10 Dec 2014 13:29:50 +0300 Subject: [CMake] Copying shared libraries in a post-build step In-Reply-To: <548787FD.5020503@gmail.com> References: <548787FD.5020503@gmail.com> Message-ID: 2014-12-10 2:38 GMT+03:00 Walter Gray : > Hey all, > I'm working on a module that will allow me to automatically copy all the > required .dll files as defined by well-formed import library targets to the > appropriate location (same folder for windows, Frameworks folder for OSX > bundle, ect). I've got the code that scans an executable's > INTERFACE_LINK_LIBRARIES property recursively to find all such shared > library, however I'm running into a small problem. I really like using > file globbing in higher level source directories to add all appropriate > sub-directories, but this means that sometimes a dependency will not be > fully defined yet. This is normally fine since these things are usually > resolved at *generation* time, but since I'm doing a manual traversal of > the list of link libraries at config time that's not really acceptable. I > realize I could just not do the globbing and just make sure the directories > were setup in the correct order, but I really don't like making the > add_subdirectory calls order dependent. > > One solution I've come up with is to add the targets I want to do this to > to a global list, then iterate over that list as the last step in my > top-level cmake lists file, but that has the issue that I can no longer use > add_custom_command on those targets at that point. I'm wondering 3 things: > > 1)What is the reasoning behind not allowing add_custom_command on targets > not defined in the current directory? Especially now that SOURCE can be > modified, the restriction seems very arbitrary. > > 2)How stupid would it be to reserve the command using something like > add_custom_command(TARGET ${target} POST_BUILD COMMAND > $) > then use set_property(TARGET ${target} APPEND PROPERTY > COPY_SHARED_LIBS_COMMAND to add more copy steps to the command? > > 3) Am I completely missing something and there's already a totally well > supported way of making sure that an executable's shared library > dependencies end up in the correct directory? I couldn't find a really > satisfactory answer on stack overflow or the archives. > > Thanks! > > -- > > 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 > -- Best Regards, Sergei Nikulov -------------- next part -------------- An HTML attachment was scrubbed... URL: From tim at klingt.org Wed Dec 10 05:36:32 2014 From: tim at klingt.org (Tim Blechmann) Date: Wed, 10 Dec 2014 11:36:32 +0100 Subject: [CMake] Copying shared libraries in a post-build step In-Reply-To: References: <548787FD.5020503@gmail.com> Message-ID: > > This sounds more like an install phase... to bring the whole package > > together in one appropriate place. > > > > if( WIN32 ) > > INSTALL( TARGET RUNTIME DESTINATION bin LIBRARY DESTINATION bin > > ARCHIVE DESTINATION lib ) > > else( WIN32 ) > > INSTALL( TARGET RUNTIME DESTINATION bin LIBRARY DESTINATION lib > > ARCHIVE DESTINATION lib ) > > endif( WIN32 ) > > on unixy platforms, shared libraries can be resolved using rpaths. on > windows this is not the case: if you link a dll into an executable the > executable will not run, unless the dll can be resolved at startup time. > the is typically done by placing he dll next to the exe. > > the install step is a possible workaround, but in my experience this > implies that you have to run the install script in order to debug the > binary, which is pretty inconvenient. > > No more inconvenient than building any other target... from the command > line cmake --build . <--target install / instead of blank>; a: typically you don't want to build the complete project, but only the binary you want to debug (install requires all). depending on the size of your project, this can be a big issue. b: in msvc, you cannot debug by right-click on the target -> debug -> start new instance. From sergey.nikulov at gmail.com Wed Dec 10 05:36:59 2014 From: sergey.nikulov at gmail.com (Sergei Nikulov) Date: Wed, 10 Dec 2014 13:36:59 +0300 Subject: [CMake] Copying shared libraries in a post-build step In-Reply-To: References: <548787FD.5020503@gmail.com> Message-ID: 2014-12-10 13:29 GMT+03:00 Sergei Nikulov : > > > 2014-12-10 2:38 GMT+03:00 Walter Gray : > >> Hey all, >> I'm working on a module that will allow me to automatically copy all the >> required .dll files as defined by well-formed import library targets to the >> appropriate location (same folder for windows, Frameworks folder for OSX >> bundle, ect). I've got the code that scans an executable's >> INTERFACE_LINK_LIBRARIES property recursively to find all such shared >> library, however I'm running into a small problem. I really like using >> file globbing in higher level source directories to add all appropriate >> sub-directories, but this means that sometimes a dependency will not be >> fully defined yet. This is normally fine since these things are usually >> resolved at *generation* time, but since I'm doing a manual traversal of >> the list of link libraries at config time that's not really acceptable. I >> realize I could just not do the globbing and just make sure the directories >> were setup in the correct order, but I really don't like making the >> add_subdirectory calls order dependent. >> > Sorry for empty email. Instead of globbing you can set single place for all project binary output set(EXECUTABLE_OUTPUT_PATH ${PROJECT_BINARY_DIR}/dist) Or whatever other place instead of top project folder. -- Best Regards, Sergei Nikulov -------------- next part -------------- An HTML attachment was scrubbed... URL: From d3ck0r at gmail.com Wed Dec 10 05:37:36 2014 From: d3ck0r at gmail.com (J Decker) Date: Wed, 10 Dec 2014 02:37:36 -0800 Subject: [CMake] Copying shared libraries in a post-build step In-Reply-To: References: <548787FD.5020503@gmail.com> Message-ID: > > > b: in msvc, you cannot debug by right-click on the target -> debug -> > start new instance. > > I can and do all the time. > -- > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alain.miniussi at oca.eu Wed Dec 10 07:49:29 2014 From: alain.miniussi at oca.eu (Alain Miniussi) Date: Wed, 10 Dec 2014 13:49:29 +0100 Subject: [CMake] No rule to build mod file Message-ID: <54884159.8090004@oca.eu> Hi, I am experiencing a problem related with dependencies on fortran mod files. Basically, the "make -j" it's failing with: make[2]: *** No rule to make target `dsfdm3d/inc/modacqui.mod', needed by `dsfdm3d/src/CMakeFiles/dsfdm_sp-exe.dir/main.f90.o'. Stop. mod file are generated as a side effect of source file compilation, so a file A.f90 using a mod B.mod must be compiled after the file producing the module (say B.f90). cmake seems to be able to convert those constraints in terms of build order (that is, B.f90 will be compiled before A.f90) and insert a dependency from A.f90 to B.mod. But sinces there are no specific rule to build B.mod, a full parallel build will fail on the dependencies. That is, before building anything, make will detect that A.f90 depends on a non existing file (yet) and fail to see that the compilation of B.f90 would have produced the file. For some reason, the problem seems to appears only if I build an executable (from A.f90) and have many files suc a B.f90 used to build a library. When building with a simple 'make' everything is okay (I guess because the build order is good), the problem only appears with "make -j". I have the problem with cmake 3.1.0-rc1 and 2.8.12.2 the CMakeLists.txt looks like: add_library(somelib OBJECT [some 52 source files>.f90 ) set_target_properties(somelib PROPERTIES Fortran_MODULE_DIRECTORY "${CMAKE_CURRENT_BINARY_DIR}/../inc") set_target_properties(somelib PROPERTIES COMPILE_FLAGS "") add_executable(exe main.f90 $) set_target_properties(exe PROPERTIES COMPILE_FLAGS "") add_dependencies(exe somelib) Is this something expected ? Thanks From Micha.Renner at t-online.de Wed Dec 10 09:03:46 2014 From: Micha.Renner at t-online.de (Micha Renner) Date: Wed, 10 Dec 2014 15:03:46 +0100 Subject: [CMake] CMake Vs 2012 Express 64bit Message-ID: <1418220226.30435.1.camel@t-online.de> Hi all, is there a way that CMake create solution files for 64-bit targets? (Visual Studio 2012 Express) Greetings Michael From domagoj.saric at littleendian.com Wed Dec 10 08:58:45 2014 From: domagoj.saric at littleendian.com (Domagoj Saric) Date: Wed, 10 Dec 2014 14:58:45 +0100 Subject: [CMake] Target 'copy-construction'/'fork' Message-ID: <54885195.3@littleendian.com> Hi, Given a target named Foo, is there a simple/builtin way to create a copy of that target named Bar so that it retains all the properties of Foo but can be independently changed from that point onward i.e. is there a way for CMake targets to follow the semantics of standard C++ objects with copy-constructors..? This would be useful for creating targets which are essentially the same but differ only in a few properties (e.g. creating /MD and /MT versions of a MSVC DLL)... -- Domagoj Saric Software Architect www.LittleEndian.com From parag at ionicsecurity.com Wed Dec 10 09:39:53 2014 From: parag at ionicsecurity.com (Parag Chandra) Date: Wed, 10 Dec 2014 14:39:53 +0000 Subject: [CMake] CMake Vs 2012 Express 64bit In-Reply-To: <1418220226.30435.1.camel@t-online.de> References: <1418220226.30435.1.camel@t-online.de> Message-ID: Not sure, but I believe that is a limitation of the Express edition itself; not a problem with CMake per se. You may want to try the just-released VS 2013 Community Edition instead. If you insist on using 2012 Express, perhaps this link may be of help: http://www.kobashicomputing.com/64-bit-c-development-under-visual-studio-20 12-express Parag Chandra Software Engineer, Mobile Team Mobile: +1.919.824.1410 Ionic Security Inc. 1170 Peachtree St. NE STE 2285, Atlanta, GA 30309 On 12/10/14, 9:03 AM, "Micha Renner" wrote: >Hi all, > >is there a way that CMake create solution files for 64-bit targets? >(Visual Studio 2012 Express) > >Greetings >Michael > > >-- > >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 From benapetr at gmail.com Wed Dec 10 09:42:23 2014 From: benapetr at gmail.com (Petr Bena) Date: Wed, 10 Dec 2014 15:42:23 +0100 Subject: [CMake] Including another CMakeLists project Message-ID: I have 3 projects, all using cmake. When I run cmake on each of them and separately build them, it's all fine. When I use include() on these 2 cmake files in 1 of them, so that I could run only 1 cmake and then build them all using 1 make, it fails. I believe that these 3 cmakes are colliding with each other, is there a way to run it isolated? From robert.maynard at kitware.com Wed Dec 10 09:43:37 2014 From: robert.maynard at kitware.com (Robert Maynard) Date: Wed, 10 Dec 2014 09:43:37 -0500 Subject: [CMake] Including another CMakeLists project In-Reply-To: References: Message-ID: I would try using add_subdirectory() instead of include() On Wed, Dec 10, 2014 at 9:42 AM, Petr Bena wrote: > I have 3 projects, all using cmake. When I run cmake on each of them > and separately build them, it's all fine. > > When I use include() on these 2 cmake files in 1 of them, so that I > could run only 1 cmake and then build them all using 1 make, it fails. > > I believe that these 3 cmakes are colliding with each other, is there > a way to run it isolated? > -- > > 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 From benapetr at gmail.com Wed Dec 10 10:00:03 2014 From: benapetr at gmail.com (Petr Bena) Date: Wed, 10 Dec 2014 16:00:03 +0100 Subject: [CMake] Including another CMakeLists project In-Reply-To: References: Message-ID: Yup, that works. Thanks On Wed, Dec 10, 2014 at 3:48 PM, Parag Chandra wrote: > I think you may want to try the add_subdirectory() command instead of > include(), if you truly have multiple projects that are being built by > CMake. The name suggests that it would only work with a hierarchical > directory structure, but that is not the case - you can specify absolute > paths if necessary. > > On the other hand, if you need to use include() to add shared logic across > build scripts (but not actual entire projects), then it?s helpful to think > of include() as analogous to the #include directive. I?ve found that I > needed to condition guard the included file, something like this: > > if (NOT (DEFINED Foo_cmake)) > set (Foo_cmake TRUE) > # Add shared logic below, then end with: > endif () > > Hope this helps. > > > Parag Chandra > Software Engineer, Mobile Team > Mobile: +1.919.824.1410 > > > > Ionic Security Inc. > 1170 Peachtree St. NE STE 2285, Atlanta, GA 30309 > > > > > > > > > > > > On 12/10/14, 9:42 AM, "Petr Bena" wrote: > >>I have 3 projects, all using cmake. When I run cmake on each of them >>and separately build them, it's all fine. >> >>When I use include() on these 2 cmake files in 1 of them, so that I >>could run only 1 cmake and then build them all using 1 make, it fails. >> >>I believe that these 3 cmakes are colliding with each other, is there >>a way to run it isolated? >>-- >> >>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 > From parag at ionicsecurity.com Wed Dec 10 09:48:45 2014 From: parag at ionicsecurity.com (Parag Chandra) Date: Wed, 10 Dec 2014 14:48:45 +0000 Subject: [CMake] Including another CMakeLists project In-Reply-To: References: Message-ID: I think you may want to try the add_subdirectory() command instead of include(), if you truly have multiple projects that are being built by CMake. The name suggests that it would only work with a hierarchical directory structure, but that is not the case - you can specify absolute paths if necessary. On the other hand, if you need to use include() to add shared logic across build scripts (but not actual entire projects), then it?s helpful to think of include() as analogous to the #include directive. I?ve found that I needed to condition guard the included file, something like this: if (NOT (DEFINED Foo_cmake)) set (Foo_cmake TRUE) # Add shared logic below, then end with: endif () Hope this helps. Parag Chandra Software Engineer, Mobile Team Mobile: +1.919.824.1410 Ionic Security Inc. 1170 Peachtree St. NE STE 2285, Atlanta, GA 30309 On 12/10/14, 9:42 AM, "Petr Bena" wrote: >I have 3 projects, all using cmake. When I run cmake on each of them >and separately build them, it's all fine. > >When I use include() on these 2 cmake files in 1 of them, so that I >could run only 1 cmake and then build them all using 1 make, it fails. > >I believe that these 3 cmakes are colliding with each other, is there >a way to run it isolated? >-- > >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 From robert.pollak at jku.at Wed Dec 10 10:47:38 2014 From: robert.pollak at jku.at (Robert Pollak) Date: Wed, 10 Dec 2014 16:47:38 +0100 Subject: [CMake] 64 bit build of wxWidgets-2.8.12 is not found Message-ID: <54886B1A.7000601@jku.at> Hello, I am using: - Windows 7 Professional 64 Bit - Visual Studio 2010 Professional - CMake 3.0.1 and I have installed wxMSW-2.8.12-Setup.exe to L:\wxWidgets-2.8.12-vc10\ and created 32 bit and 64 bit shared library builds there (see footnote [1]). Now I want to use the 64-bit wxWidgets libraries in a CMake-based project. For that, I have started with a minimal CMakeLists.txt in an empty folder: > cmake_minimum_required(VERSION 3.0.1) > > find_package(wxWidgets REQUIRED core base) and created a 64 bit configuration cmake-win64-libs-vc10.conf next to it: > set(wxWidgets_ROOT_DIR "L:/wxWidgets-2.8.12-vc10" CACHE PATH "wxWidgets base directory" FORCE) > set(wxWidgets_LIB_DIR "L:/wxWidgets-2.8.12-vc10/lib/vc_amd64_dll" CACHE PATH "wxWidgets libraries directory" FORCE) > set(wxWidgets_CONFIGURATION msw CACHE PATH "wxWidgets configuration" FORCE) When I now call my configure-win64-vc10.bat there: > setlocal > rmdir /S /Q build > mkdir build > cd build > set WXWIN=L:\wxWidgets-2.8.12-vc10 > cmake -C ..\cmake-win64-libs-vc10.conf ^ > -G "Visual Studio 10 Win64" ^ > .. > cd .. > endlocal , I get the error > CMake Error at C:/Program Files (x86)/CMake/share/cmake-3.0/Modules/FindPackageHandleStandardArgs.cmake:136 (message): > Could NOT find wxWidgets (missing: wxWidgets_FOUND) > Call Stack (most recent call first): > C:/Program Files (x86)/CMake/share/cmake-3.0/Modules/FindPackageHandleStandardArgs.cmake:343 (_FPHSA_FAILURE_MESSAGE) > C:/Program Files (x86)/CMake/share/cmake-3.0/Modules/FindwxWidgets.cmake:869 (FIND_PACKAGE_HANDLE_STANDARD_ARGS) > CMakeLists.txt:4 (find_package) However, a corresponding 32-bit configuration works! The only differences of my 32-bit and 64-bit configurations are * the wxWidgets_LIB_DIR: vc_amd64_dll vs. vc_dll (both directories are existing and filled with the corresponding dlls) * the CMake generator: "Visual Studio 10 Win64" vs. "Visual Studio 10" This looks to me like a bug of FindwxWidgets.cmake. Can anyone confirm? How can I debug this? Best regards, Robert -------- [1] with > call "C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\vcvarsall.bat" x86 > set WXWIN=D:\libraries\wxWidgets-2.8.12-vc10 > cd \wxWidgets-2.8.12-vc10\build\msw > nmake /f makefile.vc BUILD=debug SHARED=1 > nmake /f makefile.vc BUILD=release SHARED=1 resp. > call "C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\vcvarsall.bat" x86_amd64 > set WXWIN=D:\libraries\wxWidgets-2.8.12-vc10 > cd \wxWidgets-2.8.12-vc10\build\msw > nmake /f makefile.vc TARGET_CPU=AMD64 BUILD=debug SHARED=1 > nmake /f makefile.vc TARGET_CPU=AMD64 BUILD=release SHARED=1 From micha.hergarden at gmail.com Wed Dec 10 13:15:30 2014 From: micha.hergarden at gmail.com (Micha Hergarden) Date: Wed, 10 Dec 2014 19:15:30 +0100 Subject: [CMake] Including another CMakeLists project In-Reply-To: References: Message-ID: <54888DC2.9040306@gmail.com> If the projects are truly independent, you may also want to look at the external_project command. Regards, Micha On 12/10/2014 03:42 PM, Petr Bena wrote: > I have 3 projects, all using cmake. When I run cmake on each of them > and separately build them, it's all fine. > > When I use include() on these 2 cmake files in 1 of them, so that I > could run only 1 cmake and then build them all using 1 make, it fails. > > I believe that these 3 cmakes are colliding with each other, is there > a way to run it isolated? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From brad.king at kitware.com Wed Dec 10 13:31:15 2014 From: brad.king at kitware.com (Brad King) Date: Wed, 10 Dec 2014 13:31:15 -0500 Subject: [CMake] No rule to build mod file In-Reply-To: <54884159.8090004@oca.eu> References: <54884159.8090004@oca.eu> Message-ID: <54889173.50700@kitware.com> On 12/10/2014 7:49 AM, Alain Miniussi wrote: > Is this something expected ? Parallel builds of Fortran 90 sources with modules are expected to work with the Makefile generator, and known to work on several non-trivial projects. Please post or link a complete example tarball with sources that reproduces the problem. Thanks, -Brad From ben.robinson.msc at gmail.com Wed Dec 10 19:00:49 2014 From: ben.robinson.msc at gmail.com (Ben Robinson) Date: Wed, 10 Dec 2014 16:00:49 -0800 Subject: [CMake] MSYS Generator with Visual Studio compilers Message-ID: Hello, Due to the relative slowness of mingw32-make.exe (MinGW) compared to make.exe (MSYS) I set out to convert a working MinGW generator project over to MSYS. The project uses Visual Studio CXX and Intel Fortran. Is this even possible? My approach was to treat the toolchain like a cross compile, since MSYS assumes GCC and GFortran. I printed the relevant toolchain variables from the working MinGW build, and set them in the MSYS build before the project statement. The statements are: set(CMAKE_SYSTEM_NAME "Windows") set(CMAKE_C_COMPILER "C:/Program Files (x86)/Microsoft Visual Studio 12.0/VC/bin/amd64/cl.exe") set(CMAKE_C_COMPILER_ID "MSVC") set(CMAKE_CXX_COMPILER "C:/Program Files (x86)/Microsoft Visual Studio 12.0/VC/bin/amd64/cl.exe") set(CMAKE_CXX_COMPILER_ID "MSVC") set(CMAKE_Fortran_COMPILER "C:/Program Files (x86)/Intel/Composer XE 2015/bin/intel64/ifort.exe") set(CMAKE_Fortran_COMPILER_ID "Intel") set(CMAKE_AR "C:/Program Files (x86)/Microsoft Visual Studio 12.0/VC/bin/amd64/lib.exe" CACHE FILEPATH "Archiver") However, when I perform the initial cmake specifying the MSYS Makefiles generator I get the following error: -- The CXX compiler identification is MSVC 18.0.31101.0 -- Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual Studio 12.0/VC/bin/amd64/cl.exe -- Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual Studio 12.0/VC/bin/amd64/cl.exe -- broken CMake Error at c:/Program Files (x86)/CMake/share/cmake-3.0/Modules/CMakeTestCXXCompiler.cmake:54 (message): The C++ compiler "C:/Program Files (x86)/Microsoft Visual Studio 12.0/VC/bin/amd64/cl.exe" is not able to compile a simple test program. It fails with the following output: Change Dir: F:/P4V/brobins_sim_DEV/build_msys/Release/CMakeFiles/CMakeTmp Run Build Command:"c:/opt/gnuwin32/bin/make.exe" "cmTryCompileExec3536241854/fast" c:/opt/gnuwin32/bin/make.exe -f CMakeFiles/cmTryCompileExec3536241854.dir/build.make CMakeFiles/cmTryCompileExec3536241854.dir/build make.exe[1]: Entering directory `F:/P4V/brobins_sim_DEV/build_msys/Release/CMakeFiles/CMakeTmp' "/c/Program Files (x86)/CMake/bin/cmake.exe" -E cmake_progress_report /F/P4V/brobins_sim_DEV/build_msys/Release/CMakeFiles/CMakeTmp/CMakeFiles 1 The system cannot find the path specified. make.exe[1]: *** [CMakeFiles/cmTryCompileExec3536241854.dir/testCXXCompiler.cxx.obj] Error 1 make.exe[1]: Leaving directory `F:/P4V/brobins_sim_DEV/build_msys/Release/CMakeFiles/CMakeTmp' make.exe: *** [cmTryCompileExec3536241854/fast] Error 2 CMake will not be able to correctly generate this project. Call Stack (most recent call first): CMakeLists.txt:30 (project) -- Configuring incomplete, errors occurred! See also "F:/P4V/brobins_sim_DEV/build_msys/Release/CMakeFiles/CMakeOutput.log". See also "F:/P4V/brobins_sim_DEV/build_msys/Release/CMakeFiles/CMakeError.log". Any ideas what I should attempt next? Thank you! Ben -------------- next part -------------- An HTML attachment was scrubbed... URL: From scott.bloom at onshorecs.com Thu Dec 11 04:13:26 2014 From: scott.bloom at onshorecs.com (Scott Aron Bloom) Date: Thu, 11 Dec 2014 09:13:26 +0000 Subject: [CMake] CMP0043 policy warning Message-ID: <6FD2E165340D9A429CF831C7A2D4F42E4E4F6A27@WIN-R92V03RFJ85.onshorecs.local> Im in the process of converting a CMake 2.X project to 3.X. I cant for the life of me, find a deterministic way to properly SET the policy so I don't get the Policy CMP0043 is not set: Ignore COMPILE_DEFINITIONS_ properties. Run "cmake --help-policy CMP0043" for policy details. Use the cmake_policy command to set the policy and suppress this warning. Should it be in each individual CMakeList.txt file? Or just the top one? to be honest, on my companies main project, I finally got it fixed, by putting it just about everywhere, but this is very frustrating. Scott -------------- next part -------------- An HTML attachment was scrubbed... URL: From petr.kmoch at gmail.com Thu Dec 11 04:36:05 2014 From: petr.kmoch at gmail.com (Petr Kmoch) Date: Thu, 11 Dec 2014 10:36:05 +0100 Subject: [CMake] CMP0043 policy warning In-Reply-To: <6FD2E165340D9A429CF831C7A2D4F42E4E4F6A27@WIN-R92V03RFJ85.onshorecs.local> References: <6FD2E165340D9A429CF831C7A2D4F42E4E4F6A27@WIN-R92V03RFJ85.onshorecs.local> Message-ID: Hi Scott. Policy state is changed by explicit calls to cmake_policy() and implicitly by calls to cmake_minimum_required(). So you need to set the policy to the setting you want whenever each of these occurs (or modify them so that they set the policy the way you want it). The documentation of cmake_policy() has details about this, including how the policy stack works. You should be able to find more info there. Petr On Thu, Dec 11, 2014 at 10:13 AM, Scott Aron Bloom < scott.bloom at onshorecs.com> wrote: > Im in the process of converting a CMake 2.X project to 3.X. > > > > I cant for the life of me, find a deterministic way to properly SET the > policy so I don?t get the > > > > Policy CMP0043 is not set: Ignore COMPILE_DEFINITIONS_ > properties. > > Run "cmake --help-policy CMP0043" for policy details. Use the > cmake_policy > > command to set the policy and suppress this warning. > > > > Should it be in each individual CMakeList.txt file? Or just the top one? > > to be honest, on my companies main project, I finally got it fixed, by > putting it just about everywhere, but this is very frustrating. > > > > Scott > > -- > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From scott.bloom at onshorecs.com Thu Dec 11 04:50:17 2014 From: scott.bloom at onshorecs.com (Scott Aron Bloom) Date: Thu, 11 Dec 2014 09:50:17 +0000 Subject: [CMake] CMP0043 policy warning In-Reply-To: References: <6FD2E165340D9A429CF831C7A2D4F42E4E4F6A27@WIN-R92V03RFJ85.onshorecs.local> Message-ID: <6FD2E165340D9A429CF831C7A2D4F42E4E4F6A8B@WIN-R92V03RFJ85.onshorecs.local> That did it.. A bunch of my ?sub? libraries get used across multiple projects, so they have their OWN ?minimum?, now I put the policy setting in each cmake after the set_minum. Thanks Scott From: Petr Kmoch [mailto:petr.kmoch at gmail.com] Sent: Thursday, December 11, 2014 1:36 AM To: Scott Aron Bloom Cc: cmake at cmake.org Subject: Re: [CMake] CMP0043 policy warning Hi Scott. Policy state is changed by explicit calls to cmake_policy() and implicitly by calls to cmake_minimum_required(). So you need to set the policy to the setting you want whenever each of these occurs (or modify them so that they set the policy the way you want it). The documentation of cmake_policy() has details about this, including how the policy stack works. You should be able to find more info there. Petr On Thu, Dec 11, 2014 at 10:13 AM, Scott Aron Bloom > wrote: Im in the process of converting a CMake 2.X project to 3.X. I cant for the life of me, find a deterministic way to properly SET the policy so I don?t get the Policy CMP0043 is not set: Ignore COMPILE_DEFINITIONS_ properties. Run "cmake --help-policy CMP0043" for policy details. Use the cmake_policy command to set the policy and suppress this warning. Should it be in each individual CMakeList.txt file? Or just the top one? to be honest, on my companies main project, I finally got it fixed, by putting it just about everywhere, but this is very frustrating. Scott -- 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From Johannes.Sebastian.Mueller-Roemer at igd.fraunhofer.de Thu Dec 11 07:40:41 2014 From: Johannes.Sebastian.Mueller-Roemer at igd.fraunhofer.de (Mueller-Roemer, Johannes Sebastian) Date: Thu, 11 Dec 2014 12:40:41 +0000 Subject: [CMake] Copying shared libraries in a post-build step In-Reply-To: References: <548787FD.5020503@gmail.com> Message-ID: <8D981219EEA621479C112DA9BDC39A8E26D45218@EXMBS1.ad.igd.fraunhofer.de> Only after manually changing per-user project debug settings. -- Johannes S. Mueller-Roemer, MSc Wiss. Mitarbeiter - Interactive Engineering Technologies (IET) Fraunhofer-Institut f?r Graphische Datenverarbeitung IGD Fraunhoferstr. 5 | 64283 Darmstadt | Germany Tel +49 6151 155-606 | Fax +49 6151 155-139 johannes.mueller-roemer at igd.fraunhofer.de | www.igd.fraunhofer.de From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of J Decker Sent: Wednesday, December 10, 2014 11:38 To: Tim Blechmann Cc: cmake at cmake.org Subject: Re: [CMake] Copying shared libraries in a post-build step b: in msvc, you cannot debug by right-click on the target -> debug -> start new instance. I can and do all the time. -- 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From d3ck0r at gmail.com Thu Dec 11 08:04:30 2014 From: d3ck0r at gmail.com (J Decker) Date: Thu, 11 Dec 2014 05:04:30 -0800 Subject: [CMake] Copying shared libraries in a post-build step In-Reply-To: <8D981219EEA621479C112DA9BDC39A8E26D45218@EXMBS1.ad.igd.fraunhofer.de> References: <548787FD.5020503@gmail.com> <8D981219EEA621479C112DA9BDC39A8E26D45218@EXMBS1.ad.igd.fraunhofer.de> Message-ID: On Thu, Dec 11, 2014 at 4:40 AM, Mueller-Roemer, Johannes Sebastian < Johannes.Sebastian.Mueller-Roemer at igd.fraunhofer.de> wrote: > Only after manually changing per-user project debug settings. > > > a one time thing to do. Although it would be nice if the user file didn't exist if a reasonable default xml could be written by cmake that had the right settings. If you're only changing the code in a single exe or lib then only that is built and copied anyway... so no difference in the work for the build. but really I don't right click and debug ever... I just hit F5... > -- > > Johannes S. Mueller-Roemer, MSc > > Wiss. Mitarbeiter - Interactive Engineering Technologies (IET) > > > > Fraunhofer-Institut f?r Graphische Datenverarbeitung IGD > > Fraunhoferstr. 5 | 64283 Darmstadt | Germany > > Tel +49 6151 155-606 | Fax +49 6151 155-139 > > johannes.mueller-roemer at igd.fraunhofer.de | www.igd.fraunhofer.de > > > > *From:* CMake [mailto:cmake-bounces at cmake.org] *On Behalf Of *J Decker > *Sent:* Wednesday, December 10, 2014 11:38 > *To:* Tim Blechmann > *Cc:* cmake at cmake.org > *Subject:* Re: [CMake] Copying shared libraries in a post-build step > > > > > b: in msvc, you cannot debug by right-click on the target -> debug -> > start new instance. > > > > I can and do all the time. > > > > -- > > 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 > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jackcmedia at gmail.com Thu Dec 11 08:16:53 2014 From: jackcmedia at gmail.com (Jack) Date: Thu, 11 Dec 2014 13:16:53 +0000 Subject: [CMake] Windows 7 64 bits, C++ third party libraries and FIND_LIBRARY_USE_LIB64_PATHS Message-ID: Greetings, I am a neophyte in CMake and I am trying to set up a CMakeLists.txt file to compile a project I was working on, which uses a third party library called SFML 2.1. My compilation environment is as follows: - Windows 7 , 64 bits - CLion EAP, which uses: - TDM-GCC's MinGW-w64 4.9.2 (which can generate both 32 and 64 bits binaries) - CMake 3.0.2 And SFML 2.1 is located on a folder which contains the following subfolders: - bin (dlls for x86) - bin64 (dlls for x64) - include - lib (libraries for x86) - lib64 (libraries for x64) A FindSFML.cmake script, which was provided by the SFML development team, looks for the libs in the usual places (on *nix OSes) and, for Windows OSes, it uses a CMake or an environmental variable that points to the base folder. Now, here comes my main dilemma. CMake is able to locate the libraries to generate 32 bit binaries. However, the FIND_LIBRARY_USE_LIB64_PATHS global parameter, when set to ON or TRUE, doesn't seem to allow CMake to locate the 64 bit libraries on the "lib64" folder, which means that, whenever I want to generate binaries for another architecture, I have to go around renaming folders. Of course, it could be that I'm simply doing this the wrong way and I should have only the 64 bit libraries on my system, then use another computer or VM to generate 32 bit binaries. Does anyone know if the global property FIND_LIBRARY_USE_LIB64_PATHS has ever worked on Windows? Should it or not? -------------- next part -------------- An HTML attachment was scrubbed... URL: From parag at ionicsecurity.com Thu Dec 11 09:47:40 2014 From: parag at ionicsecurity.com (Parag Chandra) Date: Thu, 11 Dec 2014 14:47:40 +0000 Subject: [CMake] Target 'copy-construction'/'fork' In-Reply-To: <54885195.3@littleendian.com> References: <54885195.3@littleendian.com> Message-ID: I?m not aware of any means to clone a target, but for what you are describing, custom configurations will work better. For the specific use case you mention below, start by seeding the new configurations like this: set (CMAKE_CONFIGURATION_TYPES Debug;Release;RelWithDebInfo;MinSizeRel;Debug_Clone;Release_Clone;RelWithDe bInfo_Clone;MinSizeRel_Clone CACHE INTERNAL "Configuration types" FORCE) foreach (cfg "DEBUG" "RELEASE" "MINSIZEREL" "RELWITHDEBINFO") foreach (flag "CXX" "C" "EXE_LINKER" "MODULE_LINKER" "SHARED_LINKER" "STATIC_LINKER") set (CMAKE_${flag}_FLAGS_${cfg}_Clone ${CMAKE_${flag}_FLAGS_${cfg}} CACHE STRING "${flag} flags for ${cfg}_Clone" FORCE) endforeach () endforeach () So you essentially start with a clone of the default configurations that CMake gives you. Then you can adjust the new configurations as you see fit. The following block will adjust all the _Clone configurations to link with /MT rather than the default /MD: foreach (cfg "DEBUG" "RELEASE" "MINSIZEREL" "RELWITHDEBINFO") foreach (flag_var CMAKE_C_FLAGS_${cfg}_Clone CMAKE_CXX_FLAGS_${cfg}_Clone) if (${flag_var} MATCHES "/MD") string(REGEX REPLACE "/MD" "/MT" ${flag_var} "${${flag_var}}") endif () endforeach () endforeach () Hope this helps. Parag Chandra Software Engineer, Mobile Team Mobile: +1.919.824.1410 Ionic Security Inc. 1170 Peachtree St. NE STE 2285, Atlanta, GA 30309 On 12/10/14, 8:58 AM, "Domagoj Saric" wrote: >Hi, > >Given a target named Foo, is there a simple/builtin way to create a copy >of that >target named Bar so that it retains all the properties of Foo but can be >independently changed from that point onward i.e. is there a way for >CMake >targets to follow the semantics of standard C++ objects with >copy-constructors..? >This would be useful for creating targets which are essentially the same >but >differ only in a few properties (e.g. creating /MD and /MT versions of a >MSVC >DLL)... > > >-- >Domagoj Saric >Software Architect >www.LittleEndian.com >-- > >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 From ax487 at gmx.de Thu Dec 11 09:48:51 2014 From: ax487 at gmx.de (ax487) Date: Thu, 11 Dec 2014 15:48:51 +0100 Subject: [CMake] Programmatically-generated dependencies In-Reply-To: <5486C322.7020508@gmx.de> References: <5486C322.7020508@gmx.de> Message-ID: <5489AED3.6070309@gmx.de> *bump* On 09.12.2014 10:38, ax487 wrote: > Hello all, > > I am mainly asking having glib-compile-resources in mind. This little > program translates files into C source code to be used with the > gresource system. It works in the following way: You have a file.xml > describing the resources: > > > > > > some_file.txt > > > > To generate the source you use `glib-compile-resources --generate-source > --target=output.c file.xml`. Clearly the generated output.c depends on > file.xml. But it also depends on some_file.txt. It is possible to get a > list of dependencies using `glib-compile-resources > --generate-dependencies file.xml` which will output > > some_file.txt > > The situation is similar to the case of auto-generated header > dependencies for C/C++ source code using the "-MM" option of gcc. > I saw the following version on github: > > https://github.com/bgK/vba-ttb/blob/master/cmake/GResource.cmake > > which does not correctly detect dependencies, but nothing apart from > that. But since the process works with C/C++ source code I figured there > is no reason why it shouldn't also work in this case. Could anyone give > me some pointers on how to get this to work? > > ax487 > From jzakrzewski at e2e.ch Thu Dec 11 10:06:07 2014 From: jzakrzewski at e2e.ch (Jakub Zakrzewski) Date: Thu, 11 Dec 2014 15:06:07 +0000 Subject: [CMake] Programmatically-generated dependencies In-Reply-To: <5489AED3.6070309@gmx.de> References: <5486C322.7020508@gmx.de> <5489AED3.6070309@gmx.de> Message-ID: Hi, CMake provides functions to execute commands and capture the output. You would use them as a part of configure step to get dependencies. Then add_custom_command to actually generate the C file and use the output to generate the DEPENDS section. -- Gruesse, Jakub -----Original Message----- From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of ax487 Sent: Donnerstag, 11. Dezember 2014 15:49 To: cmake at cmake.org Subject: Re: [CMake] Programmatically-generated dependencies *bump* On 09.12.2014 10:38, ax487 wrote: > Hello all, > > I am mainly asking having glib-compile-resources in mind. This little > program translates files into C source code to be used with the > gresource system. It works in the following way: You have a file.xml > describing the resources: > > prefix="/some/prefix"> > > some_file.txt > > > > To generate the source you use `glib-compile-resources > --generate-source --target=output.c file.xml`. Clearly the generated > output.c depends on file.xml. But it also depends on some_file.txt. It > is possible to get a list of dependencies using > `glib-compile-resources --generate-dependencies file.xml` which will > output > > some_file.txt > > The situation is similar to the case of auto-generated header > dependencies for C/C++ source code using the "-MM" option of gcc. > I saw the following version on github: > > https://github.com/bgK/vba-ttb/blob/master/cmake/GResource.cmake > > which does not correctly detect dependencies, but nothing apart from > that. But since the process works with C/C++ source code I figured > there is no reason why it shouldn't also work in this case. Could > anyone give me some pointers on how to get this to work? > > ax487 > -- 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 From FMiller at sjm.com Thu Dec 11 12:23:46 2014 From: FMiller at sjm.com (Miller, Frank) Date: Thu, 11 Dec 2014 17:23:46 +0000 Subject: [CMake] Programmatically-generated dependencies In-Reply-To: References: <5486C322.7020508@gmx.de> <5489AED3.6070309@gmx.de> Message-ID: You will want to also make sure that a reconfigure happens when the xml file changes which can be done with the recently added CMAKE_CONFIGURE_DEPENDS property. If you need to support older versions of cmake, then you can use configure_file() to copy the xml file somewhere (no need to use it). This is unfortunate. I was hoping someone would have a better solution but it looks like the feature we want doesn't exist. http://public.kitware.com/Bug/view.php?id=2172 Frank > -----Original Message----- > From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Jakub > Zakrzewski > Sent: Thursday, December 11, 2014 9:06 AM > To: ax487 > Cc: cmake at cmake.org > Subject: Re: [CMake] Programmatically-generated dependencies > > Hi, > > CMake provides functions to execute commands and capture the output. > You would use them as a part of configure step to get dependencies. > Then add_custom_command to actually generate the C file and use the > output to generate the DEPENDS section. > > -- > Gruesse, > Jakub > > > > > -----Original Message----- > From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of ax487 > Sent: Donnerstag, 11. Dezember 2014 15:49 > To: cmake at cmake.org > Subject: Re: [CMake] Programmatically-generated dependencies > > *bump* > > On 09.12.2014 10:38, ax487 wrote: > > Hello all, > > > > I am mainly asking having glib-compile-resources in mind. This little > > program translates files into C source code to be used with the > > gresource system. It works in the following way: You have a file.xml > > describing the resources: > > > > > prefix="/some/prefix"> > > > > some_file.txt > > > > > > > > To generate the source you use `glib-compile-resources > > --generate-source --target=output.c file.xml`. Clearly the generated > > output.c depends on file.xml. But it also depends on some_file.txt. It > > is possible to get a list of dependencies using > > `glib-compile-resources --generate-dependencies file.xml` which will > > output > > > > some_file.txt > > > > The situation is similar to the case of auto-generated header > > dependencies for C/C++ source code using the "-MM" option of gcc. > > I saw the following version on github: > > > > https://github.com/bgK/vba-ttb/blob/master/cmake/GResource.cmake > > > > which does not correctly detect dependencies, but nothing apart from > > that. But since the process works with C/C++ source code I figured > > there is no reason why it shouldn't also work in this case. Could > > anyone give me some pointers on how to get this to work? > > > > ax487 > > > -- > > 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 > -- > > 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 This communication, including any attachments, may contain information that is proprietary, privileged, confidential or legally exempt from disclosure. If you are not a named addressee, you are hereby notified that you are not authorized to read, print, retain a copy of or disseminate any portion of this communication without the consent of the sender and that doing so may be unlawful. If you have received this communication in error, please immediately notify the sender via return e-mail and delete it from your system. In order to safeguard its employee data as well as sensitive patient, customer, business, legal and other information, the company uses all lawful means, under all applicable law, to access, monitor, preserve, collect and review all communications between employees and all other users only when, and to the extent necessary, to fulfill investigatory and other important business and legal responsibilities. By responding to this communication, or initiating additional communication with the company, you consent to such lawful monitoring, to the extent such consent is required and valid in your local area. From schnitzeltony at googlemail.com Fri Dec 12 04:45:26 2014 From: schnitzeltony at googlemail.com (=?UTF-8?Q?Andreas_M=C3=BCller?=) Date: Fri, 12 Dec 2014 10:45:26 +0100 Subject: [CMake] Maximum length COMMAND in add_custom_command Message-ID: Hi, I am building packages using cmake in yocto environment (cmake 2.8.12.2) and face an issue caused by long paths (I guess). Investigations at cmake doc/source-code and google did not lead to success so I ask here for help. I attached a text file because googlemail wraps lines. As you can see there is a custom command defined. During expansion of the command to build.make the command string is cut off (wayland-server-plasma-shell.h -> wayland-server-plasma-shel). Is there a way to avoid this limitation either by a environment setting or patching a fixes limitation to cmake? Help appreciated Andreas -------------- next part -------------- A non-text attachment was scrubbed... Name: custom-command-cut-off Type: application/octet-stream Size: 949 bytes Desc: not available URL: From jackie at sdiwc.info Fri Dec 12 08:42:33 2014 From: jackie at sdiwc.info (ANNOUNCEMENT) Date: Fri, 12 Dec 2014 06:42:33 -0700 Subject: [CMake] Call for Papers: Switzerland - International Conference on Semantic Web Business and Innovation (SWBI2015) Message-ID: <340442d96d4fd80a687ed3d045caac02@sdiwc.info> The International Conference on Semantic Web Business and Innovation (SWBI2015) The University of Applied Sciences and Arts Western Switzerland (HES-SO Valais-Wallis) October 7-9, 2015 http://sdiwc.net/conferences/swbi2015/ All registered papers will be included in SDIWC Digital Library ================================================================ The proposed conference on the above theme will be held at he University of Applied Sciences and Arts Western Switzerland (HES-SO Valais-Wallis) on October 7-9, 2015 which aims to enable researchers build connections between different digital applications. The conference welcomes papers on the following (but not limited to) research topics: *Semantic Web and Linked Data - Database, IR, NLP and AI technologies for the Semantic Web - Geospatial Semantic Web - Information Extraction from unstructured data - Information visualization of Semantic Web data and Linked Data - Internet of things - Languages, tools, and methodologies for representing and managing Semantic Web data - Linked open data - Management of Semantic Web data and Linked Data - Ontology engineering and ontology patterns for the Semantic Web - Ontology modularity, mapping, merging, and alignment - Ontology-based data access - Privacy and Security - Query and inference over data streams - Search, query, integration, and analysis on the Semantic Web - Semantic business process management - Semantic Sensor networks - Semantic technologies for mobile platforms - Semantic Web and Linked Data for Cloud Environments - Semantic Web, Ontologies - Social networks and processes on the Semantic Web - Supporting multi-linguality in the Semantic Web - User Interfaces and interacting with Semantic Web data and Linked Data *Business and Innovation in Semantic Web - Business Model Innovation - Business Models and E-Commerce - Business Technology Intelligence - Challenges for change in semantic services - Collaborative improvement and innovation - E-Business Applications and Software - E-commerce Technology Adoption - E-commerce, E-Business Strategies - E-tailing and Multi-Channel selling - Evolution of Business model for Semantic Web Applications - High-tech marketing - Implementation strategies for responsible innovation - Innovation for E-Business - Innovative methods and tools for products and services - Practices and Cases in E-Commerce - Production of Knowledge Economy - Technology and Business Transformation - Technology strategies - The Latest Trends in Linked Data - Web Advertising and Web Publishing - Web and Mobile Applications Researchers are encouraged to submit their work electronically. All papers will be fully refereed by a minimum of two specialized referees. Before final acceptance, all referees comments must be considered. Important Dates ============== Submission Date: Open from now until Sept. 1, 2015 Notification of Acceptance: 6 weeks from the submission date Camera Ready Submission: September 14, 2015 Registration Deadline: September 14, 2015 Conference Dates: October 7-9, 2015 From karl-heinz.konrad at wai.com Sat Dec 13 02:24:41 2014 From: karl-heinz.konrad at wai.com (Konrad, Karl-Heinz) Date: Sat, 13 Dec 2014 07:24:41 +0000 Subject: [CMake] Issues compiling cmake Message-ID: <3e136da513794be69b159d05a506ab51@ny-mbox01.wai.com> Hello All, I am running SL 6.6 and it comes with Qt 4.6.2 pre-installed. I have compiled Qt 4.8.6 on the system and am trying to build cmake-3.1.0-rc2 using the 4.8.6 binaries, but the bootstrap is finding the 4.6.2 binaries instead. I have set the environmental variables QTDIR, QTLIB, QTINC and LD_LIBRARY_PATH to point to the complied Qt 4.8.6 binaries, but the bootstrap indicates that I am using Qt 4.6.2 instead, what am I missing? Karl-Heinz Konrad -------------- next part -------------- An HTML attachment was scrubbed... URL: From ambreen2006 at gmail.com Sat Dec 13 03:08:44 2014 From: ambreen2006 at gmail.com (ambreen haleem) Date: Sat, 13 Dec 2014 00:08:44 -0800 Subject: [CMake] KDevelop Projects Message-ID: In my main repository where my project reside, I created a sub-directory called build. When I do cmake -G "KDevelop3", I do get a kdevelop project in the build but it has no src files and most of the files in there are cmake related. I'm on Ubuntu 14.04 and KDevelop4. How do I generate a usable KDevelop project. Regards Ambreen -------------- next part -------------- An HTML attachment was scrubbed... URL: From eike at sf-mail.de Sat Dec 13 03:38:56 2014 From: eike at sf-mail.de (Rolf Eike Beer) Date: Sat, 13 Dec 2014 09:38:56 +0100 Subject: [CMake] KDevelop Projects In-Reply-To: References: Message-ID: <9155948.Cosx8ULPsy@caliban.sf-tec.de> Am Samstag, 13. Dezember 2014, 00:08:44 schrieb ambreen haleem: > In my main repository where my project reside, I created a sub-directory > called build. When I do cmake -G "KDevelop3", I do get a kdevelop project > in the build but it has no src files and most of the files in there are > cmake related. I'm on Ubuntu 14.04 and KDevelop4. > > How do I generate a usable KDevelop project. You don't. You open KDevelop, say "open/import project", point it to your main CMakeLists.txt, tell it the build dir, done. Eike -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From eike at sf-mail.de Sat Dec 13 03:39:56 2014 From: eike at sf-mail.de (Rolf Eike Beer) Date: Sat, 13 Dec 2014 09:39:56 +0100 Subject: [CMake] Issues compiling cmake In-Reply-To: <3e136da513794be69b159d05a506ab51@ny-mbox01.wai.com> References: <3e136da513794be69b159d05a506ab51@ny-mbox01.wai.com> Message-ID: <2471480.tZCierhcLY@caliban.sf-tec.de> Am Samstag, 13. Dezember 2014, 07:24:41 schrieb Konrad, Karl-Heinz: > Hello All, > I am running SL 6.6 and it comes with Qt 4.6.2 pre-installed. I have > compiled Qt 4.8.6 on the system and am trying to build cmake-3.1.0-rc2 > using the 4.8.6 binaries, but the bootstrap is finding the 4.6.2 binaries > instead. I have set the environmental variables QTDIR, QTLIB, QTINC and > LD_LIBRARY_PATH to point to the complied Qt 4.8.6 binaries, but the > bootstrap indicates that I am using Qt 4.6.2 instead, what am I missing? > Karl-Heinz Konrad You probably only need to set PATH that way that the new qmake comes before your system one. Eike -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From a.neundorf-work at gmx.net Sat Dec 13 08:11:15 2014 From: a.neundorf-work at gmx.net (Alexander Neundorf) Date: Sat, 13 Dec 2014 14:11:15 +0100 Subject: [CMake] KDevelop Projects In-Reply-To: References: Message-ID: <1491115.PoHoNzYT2X@tuxedo.neundorf.net> On Saturday, December 13, 2014 00:08:44 ambreen haleem wrote: > In my main repository where my project reside, I created a sub-directory > called build. When I do cmake -G "KDevelop3", I do get a kdevelop project > in the build but it has no src files and most of the files in there are > cmake related. I'm on Ubuntu 14.04 and KDevelop4. > > How do I generate a usable KDevelop project. the project files are for KDevelop 3. Are you still using that version ? I would guess you are using version 4 of KDevelop. Alex From post at lespocky.de Sat Dec 13 13:08:07 2014 From: post at lespocky.de (Alexander Dahl) Date: Sat, 13 Dec 2014 19:08:07 +0100 Subject: [CMake] KDevelop Projects In-Reply-To: References: Message-ID: <548C8087.6040706@lespocky.de> Hei hei, On 13.12.2014 09:08, ambreen haleem wrote: > In my main repository where my project reside, I created a sub-directory > called build. When I do cmake -G "KDevelop3", I do get a kdevelop project > in the build but it has no src files and most of the files in there are > cmake related. I'm on Ubuntu 14.04 and KDevelop4. KDE4 heavily relies on CMake so KDevelop4 has integrated support for CMake. You choose your source folder and you'll be prompted for a build folder. That's it. No creation of some project from the outside before. Greets Alex -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: OpenPGP digital signature URL: From csiga.biga at aol.com Sat Dec 13 15:28:26 2014 From: csiga.biga at aol.com (=?utf-8?Q?Nagy-Egri_M=C3=A1t=C3=A9_Ferenc?=) Date: Sat, 13 Dec 2014 20:28:26 +0000 Subject: [CMake] =?utf-8?q?Invoke-Build_support?= Message-ID: Hi! Being a CMake user for some time, I have come across the issue of parallel builds still being problem with no trivial solution. the NMake back-end does not have batch support, which is said to be non-trivial, while the ninja generator did tend to fail some builds for me too, when I gave it a spin not too long ago (few months). MSBuild.exe seems to do the job, yet some argued that if one does not have access to the IDE itself (I do not exactly know that is possible to have cl.exe but not MSBuild.exe) then it is not feasable. I have started using PowerShell recently (to move out of my comfort zone, which is C++ and GPGPU), and instantly fell in love. I was looking for scriptable PS build systems, and found PSake and Invoke-Build. The former I did not take a deep look into, but the latter seems like a very nice project, with a fairly straight-forward syntax (as far as the makefile goes), as well as parallel capable back-end. The simplicity of the makefile, along with the power of .NET and all the built-in scripting fun of PS, I?d guess it might be the simplest back-end of CMake yet, if it were supported. I am very enthusiastic with a very limited amount of time I could dedicate to such work, but I thought I?d ask you folks if you see any added value in case such a back-end existed? With the chocolatey repository for Windows (in case you?ve never heard of it, google first hit gives you the answer) boasting a successful Kickstarter funding to raise it to a new level, I believe all package maintainers would benefit from a scriptable make system in PS. I have not looked at CMake source code, but just how much effort would it take to fork CMake and create a back-end for Invoke-Build? I have already contacted Invoke-Build?s developer, and while he never had to use CMake during his work, he is willing to take on the effort from IB?s side if some feature were missing to make ends meet. Best regards, M?t? -------------- next part -------------- An HTML attachment was scrubbed... URL: From cliffyapp at gmail.com Sat Dec 13 21:03:57 2014 From: cliffyapp at gmail.com (Clifford Yapp) Date: Sat, 13 Dec 2014 21:03:57 -0500 Subject: [CMake] CTest location of executables on Windows Message-ID: We have a ctest setup in our software that runs a series of test executables , and the setup works well on Linux. When trying to run the same setup on Windows, ctest reports the following: Test project C:/Users/User/project-build Start 1: bu_test_1 Could not find executable tester_bu_test_1 Looked in the following places: tester_bu_test_1 tester_bu_test_1.exe Debug/tester_bu_test_1 Debug/tester_bu_test_1.exe Release/tester_bu_test_1 Release/tester_bu_test_1.exe Unable to find executable: tester_bu_test_1 The executable is actually located at Debug/bin/tester_bu_test_1.exe (all of our binaries are put in that subdirectory) but I can't figure out how to let CTest know to search there. Does anyone know how to specify search directories for CTest to look in? Thanks, CY From eike at sf-mail.de Sun Dec 14 02:22:00 2014 From: eike at sf-mail.de (Rolf Eike Beer) Date: Sun, 14 Dec 2014 08:22 +0100 Subject: [CMake] CTest location of executables on Windows In-Reply-To: References: Message-ID: <11631985.eaUO18dafU@caliban.sf-tec.de> Am Samstag, 13. Dezember 2014, 21:03:57 schrieb Clifford Yapp: > We have a ctest setup in our software that runs a series of test > executables , and the setup works well on Linux. When trying to run > the same setup on Windows, ctest reports the following: > > Test project C:/Users/User/project-build > Start 1: bu_test_1 > Could not find executable tester_bu_test_1 > Looked in the following places: > tester_bu_test_1 > tester_bu_test_1.exe > Debug/tester_bu_test_1 > Debug/tester_bu_test_1.exe > Release/tester_bu_test_1 > Release/tester_bu_test_1.exe > Unable to find executable: tester_bu_test_1 > > The executable is actually located at Debug/bin/tester_bu_test_1.exe > (all of our binaries are put in that subdirectory) but I can't figure > out how to let CTest know to search there. Does anyone know how to > specify search directories for CTest to look in? Use the second form of add_test(), the one where you explicitely give NAME and COMMAND. This may be called with a target name instead of only an executable location, so CMake will figure out automatically where the matching executable is located. Eike -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From rleigh at codelibre.net Sun Dec 14 14:29:38 2014 From: rleigh at codelibre.net (Roger Leigh) Date: Sun, 14 Dec 2014 19:29:38 +0000 Subject: [CMake] Qt automoc (CMAKE_AUTOMOC) failure with name clashes Message-ID: <20141214192938.GB1657@codelibre.net> I have a source directory layout like this: ??? gl ??? ??? Axis2D.h ??? ??? Grid2D.h ??? ??? Image2D.h ??? ??? v20 ??? ??? Axis2D.h ??? ??? Grid2D.h ??? ??? Image2D.h ??? GLContainer.h ??? glsl ??? ??? v110 ??? ??? GLFlatShader2D.h ??? ??? GLImageShader2D.h ??? ??? GLLineShader2D.h ??? GLUtil.h ??? GLView2D.h ??? GLWindow.h ??? TexelProperties.h And use this cmake configuration: set(CMAKE_AUTOMOC ON) set(CMAKE_INCLUDE_CURRENT_DIR ON) set(QTWIDGETS_GL_HEADERS gl/Axis2D.h gl/Grid2D.h gl/Image2D.h) set(QTWIDGETS_GL_V20_HEADERS gl/v20/Axis2D.h gl/v20/Grid2D.h gl/v20/Image2D.h) As you can see, the names are duplicated in the two subdirectories. Unfortunately, automoc generates this: /* This file is autogenerated, do not edit*/ #include "moc_GLContainer.cpp" #include "moc_GLView2D.cpp" #include "moc_GLWindow.cpp" #include "moc_Axis2D.cpp" #include "moc_Grid2D.cpp" #include "moc_Image2D.cpp" #include "moc_Axis2D.cpp" #include "moc_Grid2D.cpp" #include "moc_Image2D.cpp" #include "moc_GLFlatShader2D.cpp" #include "moc_GLImageShader2D.cpp" #include "moc_GLLineShader2D.cpp" Compilation inevitably fails due to it including the generated source files twice. It's discarded the path information. - is this a known issue? - is there any way to get automoc support to add the full pathname to the generated sources e.g. moc_gl_Axis2D.cpp and moc_gl_v20_Axis2D.cpp. - any workarounds known for this issue? Many thanks, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `- GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 From cliffyapp at gmail.com Sun Dec 14 14:45:44 2014 From: cliffyapp at gmail.com (Clifford Yapp) Date: Sun, 14 Dec 2014 14:45:44 -0500 Subject: [CMake] CTest location of executables on Windows In-Reply-To: <11631985.eaUO18dafU@caliban.sf-tec.de> References: <11631985.eaUO18dafU@caliban.sf-tec.de> Message-ID: That got it - thank you! For future reference, anyone wanting to run ctest from a CMake target in msvc needs to have the -C $ option specified: add_custom_target(check COMMAND ${CMAKE_CTEST_COMMAND} -C $ -E check-tests) CY From rleigh at codelibre.net Sun Dec 14 15:29:21 2014 From: rleigh at codelibre.net (Roger Leigh) Date: Sun, 14 Dec 2014 20:29:21 +0000 Subject: [CMake] Qt automoc (CMAKE_AUTOMOC) failure with name clashes In-Reply-To: <20141214192938.GB1657@codelibre.net> References: <20141214192938.GB1657@codelibre.net> Message-ID: <20141214202921.GD1657@codelibre.net> On Sun, Dec 14, 2014 at 07:29:38PM +0000, Roger Leigh wrote: > Compilation inevitably fails due to it including the generated source > files twice. It's discarded the path information. > > - is this a known issue? > - is there any way to get automoc support to add the full pathname to > the generated sources e.g. moc_gl_Axis2D.cpp and moc_gl_v20_Axis2D.cpp. > - any workarounds known for this issue? Looks like this might be fixable in Source/cmQtAutoGenerators.cxx where it's running moc and outputting the main file with the includes in GenerateMoc and RunAutogen, if these were used to generate the sources in subdirectories rather than only at the toplevel? -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `- GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 From benapetr at gmail.com Mon Dec 15 03:34:46 2014 From: benapetr at gmail.com (Petr Bena) Date: Mon, 15 Dec 2014 09:34:46 +0100 Subject: [CMake] Linking a library that is made by cmake Message-ID: I have a project: /Target A - CMakeLists.txt - /Target B -- CMakeLists.txt - /Target C -- CMakeLists.txt So, A is including B and C using add_subdirectory. However, A is producing 2 targets, one of which is a library and I need to link B and C against that library. How would I do that? From d3ck0r at gmail.com Mon Dec 15 03:37:02 2014 From: d3ck0r at gmail.com (J Decker) Date: Mon, 15 Dec 2014 00:37:02 -0800 Subject: [CMake] Linking a library that is made by cmake In-Reply-To: References: Message-ID: target_link_libraries( B A_product_name) target_link_libraries( C A_product_name) On Mon, Dec 15, 2014 at 12:34 AM, Petr Bena wrote: > > I have a project: > > /Target A > - CMakeLists.txt > - /Target B > -- CMakeLists.txt > - /Target C > -- CMakeLists.txt > > So, A is including B and C using add_subdirectory. However, A is > producing 2 targets, one of which is a library and I need to link B > and C against that library. How would I do that? > -- > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From benapetr at gmail.com Mon Dec 15 03:49:31 2014 From: benapetr at gmail.com (Petr Bena) Date: Mon, 15 Dec 2014 09:49:31 +0100 Subject: [CMake] Linking a library that is made by cmake In-Reply-To: References: Message-ID: Ok, one more question How do I enforce run of ldconfig during `sudo make install` on linux? The library doesn't load without it. On Mon, Dec 15, 2014 at 9:37 AM, J Decker wrote: > target_link_libraries( B A_product_name) > target_link_libraries( C A_product_name) > > > On Mon, Dec 15, 2014 at 12:34 AM, Petr Bena wrote: >> >> I have a project: >> >> /Target A >> - CMakeLists.txt >> - /Target B >> -- CMakeLists.txt >> - /Target C >> -- CMakeLists.txt >> >> So, A is including B and C using add_subdirectory. However, A is >> producing 2 targets, one of which is a library and I need to link B >> and C against that library. How would I do that? >> -- >> >> 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 From d3ck0r at gmail.com Mon Dec 15 03:59:28 2014 From: d3ck0r at gmail.com (J Decker) Date: Mon, 15 Dec 2014 00:59:28 -0800 Subject: [CMake] Linking a library that is made by cmake In-Reply-To: References: Message-ID: http://www.cmake.org/cmake/help/v3.0/command/add_custom_target.html looks like all existing projects just do it by hand... it's safer if the build script doesn't have it. (much like not making copying runtime libraries easy) On Mon, Dec 15, 2014 at 12:49 AM, Petr Bena wrote: > > Ok, one more question > > How do I enforce run of ldconfig during `sudo make install` on linux? > The library doesn't load without it. > > On Mon, Dec 15, 2014 at 9:37 AM, J Decker wrote: > > target_link_libraries( B A_product_name) > > target_link_libraries( C A_product_name) > > > > > > On Mon, Dec 15, 2014 at 12:34 AM, Petr Bena wrote: > >> > >> I have a project: > >> > >> /Target A > >> - CMakeLists.txt > >> - /Target B > >> -- CMakeLists.txt > >> - /Target C > >> -- CMakeLists.txt > >> > >> So, A is including B and C using add_subdirectory. However, A is > >> producing 2 targets, one of which is a library and I need to link B > >> and C against that library. How would I do that? > >> -- > >> > >> 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 > -- > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From johannes.zarl at jku.at Mon Dec 15 04:52:53 2014 From: johannes.zarl at jku.at (Johannes Zarl) Date: Mon, 15 Dec 2014 10:52:53 +0100 Subject: [CMake] 64 bit build of wxWidgets-2.8.12 is not found In-Reply-To: <54886B1A.7000601@jku.at> References: <54886B1A.7000601@jku.at> Message-ID: <1674799.RP92CWv19J@ersa> Hello Robert, I don't have a test-environment handy, but it seems like FindwxWidgets checks for the vc_x64 library directory prefix, not for vc_amd64: # /usr/share/cmake-3.0/Modules/FindwxWidgets.cmake:511: if(MINGW) set(WX_LIB_DIR_PREFIX gcc) elseif(CMAKE_CL_64) set(WX_LIB_DIR_PREFIX vc_x64) else() set(WX_LIB_DIR_PREFIX vc) endif() The wxWidgets changelog[1] seems to suggest that "_x64" is the correct name. Maybe this is a bug in the wxWidgets installer? Cheers, Johannes [1] https://github.com/wxWidgets/wxWidgets/blob/WX_3_0_2/docs/changes.txt#L520 On Wednesday 10 December 2014 16:47:38 Robert Pollak wrote: > Hello, > > I am using: > - Windows 7 Professional 64 Bit > - Visual Studio 2010 Professional > - CMake 3.0.1 > > and I have installed wxMSW-2.8.12-Setup.exe to L:\wxWidgets-2.8.12-vc10\ > and created 32 bit and 64 bit shared library builds there (see footnote > [1]). > > Now I want to use the 64-bit wxWidgets libraries in a CMake-based project. > > For that, I have started with a minimal CMakeLists.txt in an empty folder: > > cmake_minimum_required(VERSION 3.0.1) > > > > find_package(wxWidgets REQUIRED core base) > > and created a 64 bit configuration cmake-win64-libs-vc10.conf next to it: > > set(wxWidgets_ROOT_DIR "L:/wxWidgets-2.8.12-vc10" CACHE PATH "wxWidgets > > base directory" FORCE) set(wxWidgets_LIB_DIR > > "L:/wxWidgets-2.8.12-vc10/lib/vc_amd64_dll" CACHE PATH "wxWidgets > > libraries directory" FORCE) set(wxWidgets_CONFIGURATION msw CACHE PATH > > "wxWidgets configuration" FORCE) > When I now call my configure-win64-vc10.bat there: > > setlocal > > rmdir /S /Q build > > mkdir build > > cd build > > set WXWIN=L:\wxWidgets-2.8.12-vc10 > > cmake -C ..\cmake-win64-libs-vc10.conf ^ > > > > -G "Visual Studio 10 Win64" ^ > > .. > > > > cd .. > > endlocal > > , I get the error > > > CMake Error at C:/Program Files (x86)/CMake/share/cmake-3.0/Modules/FindPackageHandleStandardArgs.cmake:136 (message): > > Could NOT find wxWidgets (missing: wxWidgets_FOUND) > > > > Call Stack (most recent call first): > > C:/Program Files > > (x86)/CMake/share/cmake-3.0/Modules/FindPackageHandleStandardArgs.cmake > > :343 (_FPHSA_FAILURE_MESSAGE) C:/Program Files > > (x86)/CMake/share/cmake-3.0/Modules/FindwxWidgets.cmake:869 > > (FIND_PACKAGE_HANDLE_STANDARD_ARGS) CMakeLists.txt:4 (find_package) > > However, a corresponding 32-bit configuration works! > The only differences of my 32-bit and 64-bit configurations are > * the wxWidgets_LIB_DIR: vc_amd64_dll vs. vc_dll (both directories are > existing and filled with the corresponding dlls) * the CMake generator: > "Visual Studio 10 Win64" vs. "Visual Studio 10" > > This looks to me like a bug of FindwxWidgets.cmake. > Can anyone confirm? How can I debug this? > > > Best regards, > Robert > > -------- > > [1] with > > > call "C:\Program Files (x86)\Microsoft Visual Studio > > 10.0\VC\vcvarsall.bat" x86 set WXWIN=D:\libraries\wxWidgets-2.8.12-vc10 > > cd \wxWidgets-2.8.12-vc10\build\msw > > nmake /f makefile.vc BUILD=debug SHARED=1 > > nmake /f makefile.vc BUILD=release SHARED=1 > > resp. > > > call "C:\Program Files (x86)\Microsoft Visual Studio > > 10.0\VC\vcvarsall.bat" x86_amd64 set > > WXWIN=D:\libraries\wxWidgets-2.8.12-vc10 > > cd \wxWidgets-2.8.12-vc10\build\msw > > nmake /f makefile.vc TARGET_CPU=AMD64 BUILD=debug SHARED=1 > > nmake /f makefile.vc TARGET_CPU=AMD64 BUILD=release SHARED=1 From norulez at me.com Mon Dec 15 06:34:46 2014 From: norulez at me.com (NoRulez) Date: Mon, 15 Dec 2014 12:34:46 +0100 Subject: [CMake] Problems with CMake 3.1.0-rc3 write_compiler_detection_header Message-ID: <436B34E7-A1EE-49B2-A2E8-48B364EA213B@me.com> Hello, I tried write_compiler_detection_header as in the example provided with VS2013 but i only get the following message: "Unsupported compiler MSVC" Any suggestions? Best Regards From robert.pollak at jku.at Mon Dec 15 07:12:22 2014 From: robert.pollak at jku.at (Robert Pollak) Date: Mon, 15 Dec 2014 13:12:22 +0100 Subject: [CMake] 64 bit build of wxWidgets-2.8.12 is not found In-Reply-To: <1674799.RP92CWv19J@ersa> References: <54886B1A.7000601@jku.at> <1674799.RP92CWv19J@ersa> Message-ID: <548ED026.5050507@jku.at> Hello Johannes! You wrote: > I don't have a test-environment handy, but it seems like FindwxWidgets checks > for the vc_x64 library directory prefix, not for vc_amd64: > > # /usr/share/cmake-3.0/Modules/FindwxWidgets.cmake:511: > if(MINGW) > set(WX_LIB_DIR_PREFIX gcc) > elseif(CMAKE_CL_64) > set(WX_LIB_DIR_PREFIX vc_x64) > else() > set(WX_LIB_DIR_PREFIX vc) > endif() Thank you! That's certainly the reason for the problem. It should check for both variants to find the 2.8.x versions. However, I do not need to test this any more, because I have switched to wxWidgets 3.0.2 in the meantime. > The wxWidgets changelog[1] seems to suggest that "_x64" is the correct name. > Maybe this is a bug in the wxWidgets installer? This changelog describes the changes from 2.8.x to 3.0.2, so the "_amd64" is correct for 2.8.12 and there is no installer bug. --Robert > [1] https://github.com/wxWidgets/wxWidgets/blob/WX_3_0_2/docs/changes.txt#L520 From robert.pollak at jku.at Mon Dec 15 07:30:27 2014 From: robert.pollak at jku.at (Robert Pollak) Date: Mon, 15 Dec 2014 13:30:27 +0100 Subject: [CMake] 64 bit build of wxWidgets-2.8.12 is not found In-Reply-To: <1674799.RP92CWv19J@ersa> References: <54886B1A.7000601@jku.at> <1674799.RP92CWv19J@ersa> Message-ID: <548ED463.8040803@jku.at> > [...] FindwxWidgets checks > for the vc_x64 library directory prefix, not for vc_amd64: I have now filed http://www.cmake.org/Bug/view.php?id=15309 about this. --Robert From norulez at me.com Mon Dec 15 08:40:18 2014 From: norulez at me.com (NoRulez) Date: Mon, 15 Dec 2014 14:40:18 +0100 Subject: [CMake] Problems with CMake 3.1.0-rc3 write_compiler_detection_header In-Reply-To: <436B34E7-A1EE-49B2-A2E8-48B364EA213B@me.com> References: <436B34E7-A1EE-49B2-A2E8-48B364EA213B@me.com> Message-ID: <54318A7D-09AD-42E1-90E1-065E9BEB3EDE@me.com> I see that only GNU and Clang is currently supported ("set(compilers GNU Clang);") Is that right and would MSVC be added to the final 3.1.0 version? Thanks in advance Best Regards > Am 15.12.2014 um 12:34 schrieb NoRulez : > > Hello, > > I tried write_compiler_detection_header as in the example provided with VS2013 but i only get the following message: "Unsupported compiler MSVC" > > Any suggestions? > > Best Regards > -- > > 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 From hobbes1069 at gmail.com Mon Dec 15 08:49:35 2014 From: hobbes1069 at gmail.com (Richard Shaw) Date: Mon, 15 Dec 2014 07:49:35 -0600 Subject: [CMake] 64 bit build of wxWidgets-2.8.12 is not found In-Reply-To: <1674799.RP92CWv19J@ersa> References: <54886B1A.7000601@jku.at> <1674799.RP92CWv19J@ersa> Message-ID: On Mon, Dec 15, 2014 at 3:52 AM, Johannes Zarl wrote: > > Hello Robert, > > I don't have a test-environment handy, but it seems like FindwxWidgets > checks > for the vc_x64 library directory prefix, not for vc_amd64: > > # /usr/share/cmake-3.0/Modules/FindwxWidgets.cmake:511: > if(MINGW) > set(WX_LIB_DIR_PREFIX gcc) > elseif(CMAKE_CL_64) > set(WX_LIB_DIR_PREFIX vc_x64) > else() > set(WX_LIB_DIR_PREFIX vc) > endif() > A quick and dirty fix may be to add an additional prefix such as "WS_LIB_DIR_PREFIX2 vc_amd64" and add appropriate lines to the find_path command... It would obviously fail for the other two conditions because PREFIX2 wouldn't be set but I think that's a lot easier than trying to add conditionals based on the wx version discovered. I technically support the module but I only run Linux so I have no way to test... Richard -------------- next part -------------- An HTML attachment was scrubbed... URL: From benapetr at gmail.com Mon Dec 15 11:16:20 2014 From: benapetr at gmail.com (Petr Bena) Date: Mon, 15 Dec 2014 17:16:20 +0100 Subject: [CMake] MinGW flags Message-ID: Hi, Is it possible to set a compiler flags only if compiler is MinGW (that means these flags wouldn't be set on MSVC). if (WIN32) matches both compilers obviously. Thanks From calebwherry at gmail.com Mon Dec 15 11:43:23 2014 From: calebwherry at gmail.com (J. Caleb Wherry) Date: Mon, 15 Dec 2014 11:43:23 -0500 Subject: [CMake] MinGW flags In-Reply-To: References: Message-ID: Very useful page for these types of questions: http://www.cmake.org/Wiki/CMake_Useful_Variables "if (MINGW)" should work. Or if you want to go off the compiler id use: CMAKE_CXX_COMPILER_ID. -Caleb On Mon, Dec 15, 2014 at 11:16 AM, Petr Bena wrote: > > Hi, > > Is it possible to set a compiler flags only if compiler is MinGW (that > means these flags wouldn't be set on MSVC). > > if (WIN32) matches both compilers obviously. Thanks > -- > > 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 > -- J. Caleb Wherry *Scientific Software Engineer* http://www.calebwherry.com +1 (615) 708-5651 calebwherry at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel at kogitoapp.com Mon Dec 15 11:47:29 2014 From: daniel at kogitoapp.com (Daniel S. Reichenbach) Date: Mon, 15 Dec 2014 17:47:29 +0100 Subject: [CMake] MinGW flags In-Reply-To: References: Message-ID: Hi, > Is it possible to set a compiler flags only if compiler is MinGW (that > means these flags wouldn't be set on MSVC). to target specific compilers you can make use of?CMAKE_CXX_COMPILER_ID. In my projects I usually include compiler specific settings like this: foreach(_base ? ? ${CMAKE_CXX_COMPILER_ID}-${CMAKE_CXX_COMPILER_VERSION} ? ? ${CMAKE_CXX_COMPILER_ID}) ? ? set(_file ${CMAKE_SOURCE_DIR}/cmake/compilers/${_base}.cmake) ? ? if(EXISTS ${_file}) ? ? ? ? include(${_file}) ? ? ? ? break() ? ? endif() endforeach() ? and in ${CMAKE_SOURCE_DIR}/cmake/compilers/ I keep the target compiler specific settings in Clang.cmake, GNU.cmake, MSVC.cmake and MinGW.cmake. For normal use cases this works fine. With kind regards, Daniel From parag at ionicsecurity.com Mon Dec 15 11:26:17 2014 From: parag at ionicsecurity.com (Parag Chandra) Date: Mon, 15 Dec 2014 16:26:17 +0000 Subject: [CMake] MinGW flags In-Reply-To: References: Message-ID: This page from the documentation might help: http://www.cmake.org/cmake/help/v3.1/manual/cmake-variables.7.html One in particular that may be useful for you to test is CMAKE__COMPILER_ID: http://www.cmake.org/cmake/help/v3.1/variable/CMAKE_LANG_COMPILER_ID.html Note that it does state it?s not guaranteed to be defined, so you?ll have to experiment. Regards, Parag Chandra Software Engineer, Mobile Team Mobile: +1.919.824.1410 Ionic Security Inc. 1170 Peachtree St. NE STE 2285, Atlanta, GA 30309 On 12/15/14, 11:16 AM, "Petr Bena" wrote: >Hi, > >Is it possible to set a compiler flags only if compiler is MinGW (that >means these flags wouldn't be set on MSVC). > >if (WIN32) matches both compilers obviously. Thanks >-- > >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 From dschepler at scalable-networks.com Mon Dec 15 12:38:34 2014 From: dschepler at scalable-networks.com (Daniel Schepler) Date: Mon, 15 Dec 2014 17:38:34 +0000 Subject: [CMake] Problems with CMake 3.1.0-rc3 write_compiler_detection_header In-Reply-To: <54318A7D-09AD-42E1-90E1-065E9BEB3EDE@me.com> References: <436B34E7-A1EE-49B2-A2E8-48B364EA213B@me.com>, <54318A7D-09AD-42E1-90E1-065E9BEB3EDE@me.com> Message-ID: Why would we need specific support for each compiler? Couldn't the module use check_cxx_source_compiles() etc. tests instead? -- Daniel Schepler ________________________________________ From: CMake [cmake-bounces at cmake.org] on behalf of NoRulez [norulez at me.com] Sent: Monday, December 15, 2014 5:40 AM To: CMake MailingList Subject: Re: [CMake] Problems with CMake 3.1.0-rc3 write_compiler_detection_header I see that only GNU and Clang is currently supported ("set(compilers GNU Clang);") Is that right and would MSVC be added to the final 3.1.0 version? Thanks in advance Best Regards > Am 15.12.2014 um 12:34 schrieb NoRulez : > > Hello, > > I tried write_compiler_detection_header as in the example provided with VS2013 but i only get the following message: "Unsupported compiler MSVC" > > Any suggestions? > > Best Regards > -- > > 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 -- 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 From brad.king at kitware.com Mon Dec 15 12:49:31 2014 From: brad.king at kitware.com (Brad King) Date: Mon, 15 Dec 2014 12:49:31 -0500 Subject: [CMake] Problems with CMake 3.1.0-rc3 write_compiler_detection_header In-Reply-To: <54318A7D-09AD-42E1-90E1-065E9BEB3EDE@me.com> References: <436B34E7-A1EE-49B2-A2E8-48B364EA213B@me.com> <54318A7D-09AD-42E1-90E1-065E9BEB3EDE@me.com> Message-ID: <548F1F2B.7070002@kitware.com> On 12/15/2014 08:40 AM, NoRulez wrote: > I see that only GNU and Clang is currently supported > ("set(compilers GNU Clang);") > > Is that right and would MSVC be added to the final 3.1.0 version? This was a mistake in the documentation that was updated here: WCDH: Don't imply that MSVC is supported by the module. http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=0db3db41 MSVC is not supported. The contributor of the feature does not work extensively with MS tools. Someone else will have to work on populating the feature table. -Brad From brad.king at kitware.com Mon Dec 15 12:53:30 2014 From: brad.king at kitware.com (Brad King) Date: Mon, 15 Dec 2014 12:53:30 -0500 Subject: [CMake] Problems with CMake 3.1.0-rc3 write_compiler_detection_header In-Reply-To: References: <436B34E7-A1EE-49B2-A2E8-48B364EA213B@me.com>, <54318A7D-09AD-42E1-90E1-065E9BEB3EDE@me.com> Message-ID: <548F201A.9060402@kitware.com> On 12/15/2014 12:38 PM, Daniel Schepler wrote: > Why would we need specific support for each compiler? One goal of the module is to avoid running dozens of compiler introspection tests for every new build tree. Compiler vendors document support for new language features in each release. There is a feature table where CMake memorizes the supported features for each version. It also knows what language-standard flags (like -std=c++11) may be needed to activate a feature. That can't be guessed so a lookup table is needed anyway. -Brad From norulez at me.com Mon Dec 15 16:07:06 2014 From: norulez at me.com (NoRulez) Date: Mon, 15 Dec 2014 22:07:06 +0100 Subject: [CMake] Problems with CMake 3.1.0-rc3 write_compiler_detection_header In-Reply-To: <548F1F2B.7070002@kitware.com> References: <436B34E7-A1EE-49B2-A2E8-48B364EA213B@me.com> <54318A7D-09AD-42E1-90E1-065E9BEB3EDE@me.com> <548F1F2B.7070002@kitware.com> Message-ID: Not supported in general or only in the rc/final 3.1.0? Because it would be very helpful for Features which are supported for e.g. in VS2010 to VS2014 and more. Best Regards > Am 15.12.2014 um 18:49 schrieb Brad King : > >> On 12/15/2014 08:40 AM, NoRulez wrote: >> I see that only GNU and Clang is currently supported >> ("set(compilers GNU Clang);") >> >> Is that right and would MSVC be added to the final 3.1.0 version? > > This was a mistake in the documentation that was updated here: > > WCDH: Don't imply that MSVC is supported by the module. > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=0db3db41 > > MSVC is not supported. The contributor of the feature does not > work extensively with MS tools. Someone else will have to work > on populating the feature table. > > -Brad > From brad.king at kitware.com Mon Dec 15 16:28:40 2014 From: brad.king at kitware.com (Brad King) Date: Mon, 15 Dec 2014 16:28:40 -0500 Subject: [CMake] Problems with CMake 3.1.0-rc3 write_compiler_detection_header In-Reply-To: References: <436B34E7-A1EE-49B2-A2E8-48B364EA213B@me.com> <54318A7D-09AD-42E1-90E1-065E9BEB3EDE@me.com> <548F1F2B.7070002@kitware.com> Message-ID: <548F5288.1030600@kitware.com> On 12/15/2014 04:07 PM, NoRulez wrote: > Not supported in general or only in the rc/final 3.1.0? Support for MSVC was not included in the original contribution and will not be included in the 3.1 release. We welcome contribution of the MSVC support from anyone interested in providing it as new development. AFAIK it requires tables to be filled out in a few files by someone with knowledge of the support for C++ features as of each MSVC version. -Brad From deepak.garg at ingv.it Tue Dec 16 00:15:33 2014 From: deepak.garg at ingv.it (Deepak Garg) Date: Tue, 16 Dec 2014 10:45:33 +0530 Subject: [CMake] Cmake project Message-ID: I am a new bee in Cmake. I want to make a project with Cmake. The Project lay out is given below. deepak/ gales/ directory_1_of_header_files/ directory_2_of_header_files/ directory_3_of_header_files/ samples/ src/ main.cpp top_header_files How should I start to construct CMakeLists.txt files? Any suggestion will be a great help. Thank you in advance Deepak -------------- next part -------------- An HTML attachment was scrubbed... URL: From lloydkl.tech at gmail.com Tue Dec 16 00:28:57 2014 From: lloydkl.tech at gmail.com (Lloyd) Date: Tue, 16 Dec 2014 10:58:57 +0530 Subject: [CMake] Cmake project In-Reply-To: References: Message-ID: You can write the root cmake file in the samples directory then adding project specific cmake file in the src directory. You can also start by writing a single cmake file in the src directory alone. Then move it to the samples directory, if the project complexity increases On Tue, Dec 16, 2014 at 10:45 AM, Deepak Garg wrote: > > I am a new bee in Cmake. I want to make a project with Cmake. The Project > lay out is given below. > > deepak/ > gales/ > directory_1_of_header_files/ > directory_2_of_header_files/ > directory_3_of_header_files/ > samples/ > src/ > main.cpp > top_header_files > > > How should I start to construct CMakeLists.txt files? Any suggestion will > be a great help. Thank you in advance > > Deepak > > -- > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From becker.tobi at gmail.com Tue Dec 16 10:22:08 2014 From: becker.tobi at gmail.com (Tobias Becker) Date: Tue, 16 Dec 2014 16:22:08 +0100 Subject: [CMake] Parallel Processes in CMake Message-ID: Hi I Implemented support for parallel processes based on bash xor powershell. If you have long running processes in CMake you might want to check it out and try it at http://thetoeb.de/2014/12/16/parallel-processes-cmake/ resp. https://github.com/toeb/oo-cmake the gist ist: ``` # these to processes run concurrently start_process(COMMAND ping cmake.org) ans(handle1) start_process(COMMAND ping github.org) ans(handle2) set(handles ${handle1} ${handle2}) ## waits until all processes are terminated process_wait_all(${handles}) ## prints the standard output stream of both processes to the console foreach(handle ${handles} process_stdout(${handle}) ans(stdout) message(STATUS "${stdout}) endforeach() ``` Tell me if you like it (or if you don't want me to shamelessly plug my Blog posts on this mailing list) :) Cheers! Tobias -------------- next part -------------- An HTML attachment was scrubbed... URL: From ramey at rrsd.com Tue Dec 16 15:19:27 2014 From: ramey at rrsd.com (Robert Ramey) Date: Tue, 16 Dec 2014 13:19:27 -0700 (MST) Subject: [CMake] Generating an Xcode project for C++11 Message-ID: <1418761167994-7589301.post@n2.nabble.com> My CMakeLists.txt contains in part:
# # Compiler settings # message(STATUS "compiler is ${CMAKE_CXX_COMPILER_ID}" ) if( CMAKE_CXX_COMPILER_ID STREQUAL "GNU" ) add_definitions( -ftemplate-depth=300 ) # we use gcc to test for C++03 compatibility add_definitions( std=c++03 ) message(STATUS "compiler is g++ c++03") elseif( CMAKE_CXX_COMPILER_ID STREQUAL "MSVC" ) add_definitions( /wd4996 ) message(STATUS "compiler is MSVC") elseif( CMAKE_CXX_COMPILER_ID STREQUAL "Clang" ) set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -ftemplate-depth=300") #set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++98") set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++11") set(CMAKE_CXX_FLAGS_DEBUG "-g -O0" ) set(CMAKE_CXX_FLAGS_RELWITHDEBINFO "-g -O3" ) set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -stdlib=libc++ -dead_strip") endif() # # IDE settings # if( CMAKE_HOST_APPLE ) # note: it seems that bjam builds both address models in any case # so we can defer this decision to the IDE just as we do for debug/release # so we'll not use this now # set(Boost_ADDRESS_MODEL 64 CACHE INTEGER "32/64 bits") set(Boost_USE_STATIC_LIBS ON CACHE BOOL "Link to Boost static libraries") set(Boost_USE_MULTITHREADED ON) else() set(Boost_ADDRESS_MODEL 64 CACHE INTEGER "32/64 bits") set(Boost_USE_STATIC_LIBS ON CACHE BOOL "Link to Boost static libraries") set(Boost_USE_MULTITHREADED ON) endif()
but the Xcode project generated specifies under Apple LLVM 6.0 Language - C++ C++ Language Dialect Compiler Default rather than what I want which is: Apple LLVM 6.0 Language - C++ C++ Language Dialect C++11 [-std=c++11] What do I have to change to get the desired result? RObert Ramey -- View this message in context: http://cmake.3232098.n2.nabble.com/Generating-an-Xcode-project-for-C-11-tp7589301.html Sent from the CMake mailing list archive at Nabble.com. From robert.maynard at kitware.com Tue Dec 16 15:24:17 2014 From: robert.maynard at kitware.com (Robert Maynard) Date: Tue, 16 Dec 2014 15:24:17 -0500 Subject: [CMake] Generating an Xcode project for C++11 In-Reply-To: <1418761167994-7589301.post@n2.nabble.com> References: <1418761167994-7589301.post@n2.nabble.com> Message-ID: If your CMake minimum required version is 3.0 you need to check for AppleClang not Clang ( http://www.cmake.org/cmake/help/v3.0/policy/CMP0025.html#policy:CMP0025 ). On Tue, Dec 16, 2014 at 3:19 PM, Robert Ramey wrote: > My CMakeLists.txt contains in part: >
> # > # Compiler settings > # > > message(STATUS "compiler is ${CMAKE_CXX_COMPILER_ID}" ) > > if( CMAKE_CXX_COMPILER_ID STREQUAL "GNU" ) > add_definitions( -ftemplate-depth=300 ) > # we use gcc to test for C++03 compatibility > add_definitions( std=c++03 ) > message(STATUS "compiler is g++ c++03") > elseif( CMAKE_CXX_COMPILER_ID STREQUAL "MSVC" ) > add_definitions( /wd4996 ) > message(STATUS "compiler is MSVC") > elseif( CMAKE_CXX_COMPILER_ID STREQUAL "Clang" ) > set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -ftemplate-depth=300") > #set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++98") > set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++11") > set(CMAKE_CXX_FLAGS_DEBUG "-g -O0" ) > set(CMAKE_CXX_FLAGS_RELWITHDEBINFO "-g -O3" ) > set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -stdlib=libc++ > -dead_strip") > endif() > > # > # IDE settings > # > > if( CMAKE_HOST_APPLE ) > # note: it seems that bjam builds both address models in any case > # so we can defer this decision to the IDE just as we do for debug/release > # so we'll not use this now > # set(Boost_ADDRESS_MODEL 64 CACHE INTEGER "32/64 bits") > set(Boost_USE_STATIC_LIBS ON CACHE BOOL "Link to Boost static libraries") > set(Boost_USE_MULTITHREADED ON) > else() > set(Boost_ADDRESS_MODEL 64 CACHE INTEGER "32/64 bits") > set(Boost_USE_STATIC_LIBS ON CACHE BOOL "Link to Boost static libraries") > set(Boost_USE_MULTITHREADED ON) > endif() >
> > but the Xcode project generated specifies under > Apple LLVM 6.0 Language - C++ > C++ Language Dialect > Compiler Default > > rather than what I want which is: > > Apple LLVM 6.0 Language - C++ > C++ Language Dialect > C++11 [-std=c++11] > > What do I have to change to get the desired result? > > RObert Ramey > > > > > > -- > View this message in context: http://cmake.3232098.n2.nabble.com/Generating-an-Xcode-project-for-C-11-tp7589301.html > Sent from the CMake mailing list archive at Nabble.com. > -- > > 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 From wonder.mice at gmail.com Tue Dec 16 17:09:15 2014 From: wonder.mice at gmail.com (Andrey Pokrovskiy) Date: Tue, 16 Dec 2014 14:09:15 -0800 Subject: [CMake] Separating spaces are escaped by JOIN generator expression Message-ID: Let's say: set(WORDS "cat" "dog") and then: "" which will produce "cat\ dog" instead of "cat dog". Looks like a bug to me. Minimal example to reproduce the issue. File - CMakeLists.txt: cmake_minimum_required(VERSION 3.1) project(escape_me_not) set(WORDS "cat" "dog") add_custom_command(OUTPUT cage.zip COMMAND zip cage.zip "") add_custom_target(escape_me_not ALL DEPENDS cage.zip) File - cat: A cat File - dog: A dog After calling cmake in CMakeFiles/escape_me_not.dir/build.make: zip cage.zip cat\ dog After calling make: zip warning: name not matched: cat dog Does any workaround exists for that? Should I file a bug? -------------- next part -------------- An HTML attachment was scrubbed... URL: From parag at ionicsecurity.com Tue Dec 16 17:23:56 2014 From: parag at ionicsecurity.com (Parag Chandra) Date: Tue, 16 Dec 2014 22:23:56 +0000 Subject: [CMake] CMake 3.1 unable to detect AppleClang when cross-compiling for iOS Message-ID: This problem seems related to some others: http://www.cmake.org/Bug/view.php?id=15237 http://www.cmake.org/Bug/view.php?id=15214 Basically, my colleague gets the following errors when he tries to run CMake on a project that I created: -- The C compiler identification is unknown -- The CXX compiler identification is unknown CMake Error in : No CMAKE_C_COMPILER could be found. CMake Error in : No CMAKE_CXX_COMPILER could be found. However, I don't encounter this error on my machine - CMake correctly detects AppleClang for both C and C++. We are both using the same Xcode (6.1.1), both on OSX 10.9. As a workaround, he is passing -DCMAKE_C_COMPILER=clang and -DCMAKE_CXX_COMPILER=clang++ on the command line, which still results in the "compiler identification is unknown" messages, but enables CMake to still successfully generate the Xcode project. We've tried both 3.1rc2 and 3.1rc3. Does anyone have any ideas? Thanks, Parag Chandra Software Engineer, Mobile Team Mobile: +1.919.824.1410 [https://www.ionicsecurity.com/IonicSigHz.png] Ionic Security Inc. 1170 Peachtree St. NE STE 2285, Atlanta, GA 30309 -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcdailey.lists at gmail.com Tue Dec 16 22:49:06 2014 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Tue, 16 Dec 2014 21:49:06 -0600 Subject: [CMake] Removing compiler options In-Reply-To: References: Message-ID: I still really need help with this. It's a blocker at this point for me. Help is greatly appreciated; thanks in advance. On Sun, Nov 9, 2014 at 10:02 PM, Robert Dailey wrote: > When setting up a CLR project through CMake, it becomes important to > be able to *remove* compiler options at the project level. For > example, the following need to be removed (MSVC12): > > /RTC1 > /EHsc > > There is no "remove_compile_options()" (which would be convenient). > Any reason why this doesn't exist? > > Right now I'm trying to remove these via CMAKE_CXX_FLAGS locally but > this doesn't work unless I forcefully change the cache. But this is a > permanent operation that affects *all* projects, which I do not want. > This is crazy, I'm hoping there is a better way. I'm using CMake 3.1 > RC1. Can anyone help me figure out how to remove compiler options on a > per-project basis? > > Here is what I'm doing: > > function( add_clr_library target_name references ) > set( source_files ${ARGN} ) > > set( default_references > System > System.Core > System.Data > System.Drawing > #System.Xml > #WindowsBase > ) > > if( CMAKE_CXX_FLAGS_DEBUG MATCHES "/RTC1" ) > string( REGEX REPLACE "/RTC(su|[1su])" "" > CMAKE_CXX_FLAGS_DEBUG "${CMAKE_CXX_FLAGS_DEBUG}" ) > endif() > > if( CMAKE_CXX_FLAGS MATCHES "/EHsc" ) > string( REPLACE "/EHsc" "" CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS}" ) > endif() > > add_library( ${target_name} SHARED ${source_files} ) > > list( APPEND references ${default_references} ) > > set_target_properties( ${target_name} PROPERTIES > VS_DOTNET_REFERENCES "${references}" > VS_DOTNET_TARGET_FRAMEWORK_VERSION "v4.5" > COMPILE_FLAGS "/clr /EHa" > DEBUG_POSTFIX "d" > ) > endfunction() From domen.vrankar at gmail.com Wed Dec 17 02:08:49 2014 From: domen.vrankar at gmail.com (Domen Vrankar) Date: Wed, 17 Dec 2014 08:08:49 +0100 Subject: [CMake] Removing compiler options In-Reply-To: References: Message-ID: This was asked a few years ago and I doubt that things have changed since then... http://www.cmake.org/pipermail/cmake/2010-May/036924.html (http://www.cmake.org/cmake/help/v2.8.10/cmake.html#prop_sf%3aCOMPILE_FLAGS). An alternative would be to use http://www.cmake.org/cmake/help/v3.0/module/ExternalProject.html Regards, Domen 2014-12-17 4:49 GMT+01:00 Robert Dailey : > I still really need help with this. It's a blocker at this point for > me. Help is greatly appreciated; thanks in advance. > > On Sun, Nov 9, 2014 at 10:02 PM, Robert Dailey wrote: >> When setting up a CLR project through CMake, it becomes important to >> be able to *remove* compiler options at the project level. For >> example, the following need to be removed (MSVC12): >> >> /RTC1 >> /EHsc >> >> There is no "remove_compile_options()" (which would be convenient). >> Any reason why this doesn't exist? >> >> Right now I'm trying to remove these via CMAKE_CXX_FLAGS locally but >> this doesn't work unless I forcefully change the cache. But this is a >> permanent operation that affects *all* projects, which I do not want. >> This is crazy, I'm hoping there is a better way. I'm using CMake 3.1 >> RC1. Can anyone help me figure out how to remove compiler options on a >> per-project basis? >> >> Here is what I'm doing: >> >> function( add_clr_library target_name references ) >> set( source_files ${ARGN} ) >> >> set( default_references >> System >> System.Core >> System.Data >> System.Drawing >> #System.Xml >> #WindowsBase >> ) >> >> if( CMAKE_CXX_FLAGS_DEBUG MATCHES "/RTC1" ) >> string( REGEX REPLACE "/RTC(su|[1su])" "" >> CMAKE_CXX_FLAGS_DEBUG "${CMAKE_CXX_FLAGS_DEBUG}" ) >> endif() >> >> if( CMAKE_CXX_FLAGS MATCHES "/EHsc" ) >> string( REPLACE "/EHsc" "" CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS}" ) >> endif() >> >> add_library( ${target_name} SHARED ${source_files} ) >> >> list( APPEND references ${default_references} ) >> >> set_target_properties( ${target_name} PROPERTIES >> VS_DOTNET_REFERENCES "${references}" >> VS_DOTNET_TARGET_FRAMEWORK_VERSION "v4.5" >> COMPILE_FLAGS "/clr /EHa" >> DEBUG_POSTFIX "d" >> ) >> endfunction() > -- > > 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 From d3ck0r at gmail.com Wed Dec 17 02:30:31 2014 From: d3ck0r at gmail.com (J Decker) Date: Tue, 16 Dec 2014 23:30:31 -0800 Subject: [CMake] Removing compiler options In-Reply-To: References: Message-ID: string( REPLACE "/EHsc" "" CMAKE_CXX_FLAGS_INIT ${CMAKE_CXX_FLAGS_INIT} ) string( REPLACE "/EHsc" "" CMAKE_C_FLAGS_INIT ${CMAKE_C_FLAGS_INIT} ) string( REPLACE "/EHs" "" CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS_INIT} ) string( REPLACE "/EHs" "" CMAKE_C_FLAGS_INIT ${CMAKE_C_FLAGS_INIT} ) string( REPLACE "/RTC1" "" CMAKE_CXX_FLAGS_DEBUG ${CMAKE_CXX_FLAGS_DEBUG} ) # cannot set CLR for C code anyway #string( REPLACE "/RTC1" "/CLR" CMAKE_C_FLAGS_DEBUG ${CMAKE_C_FLAGS_DEBUG} ) However; this ends up being a global sort of thing... would be nice to be able to edit properties per target... There's also a true flag in the project file that it doesn't look like cmake supports emitting at all... it's the setting that's in General Configuration Properties... doesn't look like it's required to compile and link as MSIL... but maybe that's where the setting to enable adding references is? ... ya... clearing that removes COM and .NET assemblies from the reference add page; just solution targets are available... On Tue, Dec 16, 2014 at 11:08 PM, Domen Vrankar wrote: > > This was asked a few years ago and I doubt that things have changed > since then... http://www.cmake.org/pipermail/cmake/2010-May/036924.html > ( > http://www.cmake.org/cmake/help/v2.8.10/cmake.html#prop_sf%3aCOMPILE_FLAGS > ). > An alternative would be to use > http://www.cmake.org/cmake/help/v3.0/module/ExternalProject.html > > Regards, > Domen > > 2014-12-17 4:49 GMT+01:00 Robert Dailey : > > I still really need help with this. It's a blocker at this point for > > me. Help is greatly appreciated; thanks in advance. > > > > On Sun, Nov 9, 2014 at 10:02 PM, Robert Dailey > wrote: > >> When setting up a CLR project through CMake, it becomes important to > >> be able to *remove* compiler options at the project level. For > >> example, the following need to be removed (MSVC12): > >> > >> /RTC1 > >> /EHsc > >> > >> There is no "remove_compile_options()" (which would be convenient). > >> Any reason why this doesn't exist? > >> > >> Right now I'm trying to remove these via CMAKE_CXX_FLAGS locally but > >> this doesn't work unless I forcefully change the cache. But this is a > >> permanent operation that affects *all* projects, which I do not want. > >> This is crazy, I'm hoping there is a better way. I'm using CMake 3.1 > >> RC1. Can anyone help me figure out how to remove compiler options on a > >> per-project basis? > >> > >> Here is what I'm doing: > >> > >> function( add_clr_library target_name references ) > >> set( source_files ${ARGN} ) > >> > >> set( default_references > >> System > >> System.Core > >> System.Data > >> System.Drawing > >> #System.Xml > >> #WindowsBase > >> ) > >> > >> if( CMAKE_CXX_FLAGS_DEBUG MATCHES "/RTC1" ) > >> string( REGEX REPLACE "/RTC(su|[1su])" "" > >> CMAKE_CXX_FLAGS_DEBUG "${CMAKE_CXX_FLAGS_DEBUG}" ) > >> endif() > >> > >> if( CMAKE_CXX_FLAGS MATCHES "/EHsc" ) > >> string( REPLACE "/EHsc" "" CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS}" > ) > >> endif() > >> > >> add_library( ${target_name} SHARED ${source_files} ) > >> > >> list( APPEND references ${default_references} ) > >> > >> set_target_properties( ${target_name} PROPERTIES > >> VS_DOTNET_REFERENCES "${references}" > >> VS_DOTNET_TARGET_FRAMEWORK_VERSION "v4.5" > >> COMPILE_FLAGS "/clr /EHa" > >> DEBUG_POSTFIX "d" > >> ) > >> endfunction() > > -- > > > > 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 > -- > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eblot.ml at gmail.com Wed Dec 17 04:15:56 2014 From: eblot.ml at gmail.com (Emmanuel Blot) Date: Wed, 17 Dec 2014 10:15:56 +0100 Subject: [CMake] Using clang + assembly language (cross compilation) Message-ID: Hi, Is there a special order to make CMake recognize .S files - with Clang toolchain - as valid source files? -- ASM: /usr/local/bin/clang -- The ASM compiler identification is Clang -- Found assembler: /usr/local/bin/clang -- Configuring done CMake Error at lib/CMakeLists.txt:9 (ADD_LIBRARY): Cannot find source file: .../lib/arch/arm/gen/divide.S Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm .hpp .hxx .in .txx with INCLUDE (Platform/Generic) ... FIND_PROGRAM (xcc clang) SET (CMAKE_ASM_COMPILER_ID Clang) INCLUDE (CMakeForceCompiler) CMAKE_FORCE_C_COMPILER (${xcc} Clang) CMAKE_FORCE_CXX_COMPILER (${xcc} Clang) SET (CMAKE_ASM_COMPILER ${xcc}) ... PROJECT (project C ASM) ... Thanks, Manu. From eblot.ml at gmail.com Wed Dec 17 04:21:24 2014 From: eblot.ml at gmail.com (Emmanuel Blot) Date: Wed, 17 Dec 2014 10:21:24 +0100 Subject: [CMake] Using clang + assembly language (cross compilation) In-Reply-To: References: Message-ID: Ooops, sorry for the noise, there was an issue with the CMakeLists.txt file. Please ignore my last post. On Wed, Dec 17, 2014 at 10:15 AM, Emmanuel Blot wrote: > Hi, > > Is there a special order to make CMake recognize .S files - with Clang > toolchain - as valid source files? > > -- ASM: /usr/local/bin/clang > -- The ASM compiler identification is Clang > -- Found assembler: /usr/local/bin/clang > -- Configuring done > CMake Error at lib/CMakeLists.txt:9 (ADD_LIBRARY): > Cannot find source file: > > .../lib/arch/arm/gen/divide.S > > Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm .hpp > .hxx .in .txx > > with > > INCLUDE (Platform/Generic) > ... > FIND_PROGRAM (xcc clang) > > SET (CMAKE_ASM_COMPILER_ID Clang) > > INCLUDE (CMakeForceCompiler) > CMAKE_FORCE_C_COMPILER (${xcc} Clang) > CMAKE_FORCE_CXX_COMPILER (${xcc} Clang) > SET (CMAKE_ASM_COMPILER ${xcc}) > > ... > > PROJECT (project C ASM) > > ... > > > Thanks, > Manu. From angeliki.chrysochou at gmail.com Wed Dec 17 05:59:04 2014 From: angeliki.chrysochou at gmail.com (Angeliki Chrysochou) Date: Wed, 17 Dec 2014 11:59:04 +0100 Subject: [CMake] Removing compiler options In-Reply-To: References: Message-ID: Hi Robert, A solution could be to create a custom build type with specific flags by appending "_" to CMAKE_CXX_FLAGS. In that way one could specify different flags for different build types and then set them as default for the project they wish to build. This could work like this for example, assuming I want my build type name to be "CustomRel": # set default build type and available options if(NOT CMAKE_BUILD_TYPE) set(CMAKE_BUILD_TYPE CustomRel CACHE STRING "Choose the type of build, options are: None CustomRel Debug." FORCE) SET_PROPERTY(CACHE CMAKE_BUILD_TYPE PROPERTY STRINGS None CustomRel Debug) endif() # set default flags for build type set(CMAKE_CXX_FLAGS_CUSTOMREL "-O2 -Werror" CACHE STRING "Flags used by the C++ compiler." FORCE) set(CMAKE_C_FLAGS_CUSTOMREL "-O2 -Wall -Wpointer-arith" CACHE STRING "Flags used by the C compiler." FORCE) Cheers! Angeliki On Wed, Dec 17, 2014 at 8:30 AM, J Decker wrote: > > string( REPLACE "/EHsc" "" CMAKE_CXX_FLAGS_INIT > ${CMAKE_CXX_FLAGS_INIT} ) > string( REPLACE "/EHsc" "" CMAKE_C_FLAGS_INIT ${CMAKE_C_FLAGS_INIT} ) > string( REPLACE "/EHs" "" CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS_INIT} ) > string( REPLACE "/EHs" "" CMAKE_C_FLAGS_INIT ${CMAKE_C_FLAGS_INIT} ) > string( REPLACE "/RTC1" "" CMAKE_CXX_FLAGS_DEBUG > ${CMAKE_CXX_FLAGS_DEBUG} ) > # cannot set CLR for C code anyway > #string( REPLACE "/RTC1" "/CLR" CMAKE_C_FLAGS_DEBUG > ${CMAKE_C_FLAGS_DEBUG} ) > > > However; this ends up being a global sort of thing... would be nice to be > able to edit properties per target... > > There's also a true flag in the project > file that it doesn't look like cmake supports emitting at all... it's the > setting that's in General Configuration Properties... doesn't look like > it's required to compile and link as MSIL... but maybe that's where the > setting to enable adding references is? ... ya... clearing that removes > COM and .NET assemblies from the reference add page; just solution targets > are available... > > > > On Tue, Dec 16, 2014 at 11:08 PM, Domen Vrankar > wrote: >> >> This was asked a few years ago and I doubt that things have changed >> since then... http://www.cmake.org/pipermail/cmake/2010-May/036924.html >> ( >> http://www.cmake.org/cmake/help/v2.8.10/cmake.html#prop_sf%3aCOMPILE_FLAGS >> ). >> An alternative would be to use >> http://www.cmake.org/cmake/help/v3.0/module/ExternalProject.html >> >> Regards, >> Domen >> >> 2014-12-17 4:49 GMT+01:00 Robert Dailey : >> > I still really need help with this. It's a blocker at this point for >> > me. Help is greatly appreciated; thanks in advance. >> > >> > On Sun, Nov 9, 2014 at 10:02 PM, Robert Dailey < >> rcdailey.lists at gmail.com> wrote: >> >> When setting up a CLR project through CMake, it becomes important to >> >> be able to *remove* compiler options at the project level. For >> >> example, the following need to be removed (MSVC12): >> >> >> >> /RTC1 >> >> /EHsc >> >> >> >> There is no "remove_compile_options()" (which would be convenient). >> >> Any reason why this doesn't exist? >> >> >> >> Right now I'm trying to remove these via CMAKE_CXX_FLAGS locally but >> >> this doesn't work unless I forcefully change the cache. But this is a >> >> permanent operation that affects *all* projects, which I do not want. >> >> This is crazy, I'm hoping there is a better way. I'm using CMake 3.1 >> >> RC1. Can anyone help me figure out how to remove compiler options on a >> >> per-project basis? >> >> >> >> Here is what I'm doing: >> >> >> >> function( add_clr_library target_name references ) >> >> set( source_files ${ARGN} ) >> >> >> >> set( default_references >> >> System >> >> System.Core >> >> System.Data >> >> System.Drawing >> >> #System.Xml >> >> #WindowsBase >> >> ) >> >> >> >> if( CMAKE_CXX_FLAGS_DEBUG MATCHES "/RTC1" ) >> >> string( REGEX REPLACE "/RTC(su|[1su])" "" >> >> CMAKE_CXX_FLAGS_DEBUG "${CMAKE_CXX_FLAGS_DEBUG}" ) >> >> endif() >> >> >> >> if( CMAKE_CXX_FLAGS MATCHES "/EHsc" ) >> >> string( REPLACE "/EHsc" "" CMAKE_CXX_FLAGS >> "${CMAKE_CXX_FLAGS}" ) >> >> endif() >> >> >> >> add_library( ${target_name} SHARED ${source_files} ) >> >> >> >> list( APPEND references ${default_references} ) >> >> >> >> set_target_properties( ${target_name} PROPERTIES >> >> VS_DOTNET_REFERENCES "${references}" >> >> VS_DOTNET_TARGET_FRAMEWORK_VERSION "v4.5" >> >> COMPILE_FLAGS "/clr /EHa" >> >> DEBUG_POSTFIX "d" >> >> ) >> >> endfunction() >> > -- >> > >> > 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 >> -- >> >> 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 >> > > -- > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From me at eddy-ilg.net Wed Dec 17 06:19:57 2014 From: me at eddy-ilg.net (Eddy Ilg) Date: Wed, 17 Dec 2014 12:19:57 +0100 Subject: [CMake] CMAKE Install Configurations Message-ID: <549166DD.30303@eddy-ilg.net> Hi, I am trying to set up a project that has fine-grained installation control. The hierarchy is like this: Project Group Component There should be three install variants: 1. "make install" should install the whole project. 2. "make Group1-install" should install everything that is in group 1 3. "make Component1-install" should install component 1 only I created custom targets for Group1-install: install( TARGETS ${component} DESTINATION bin COMPONENT ${group} ) add_custom_target( ${group}-install DEPENDS ${group} COMMAND "${CMAKE_COMMAND}" -DCOMPONENT=${group} -P "${CMAKE_BINARY_DIR}/cmake_install.cmake" ) and Component1-install: install( TARGETS ${component} DESTINATION bin COMPONENT ${component} ) add_custom_target( ${component}-install DEPENDS ${component} COMMAND "${CMAKE_COMMAND}" -DCOMPONENT=${component} -P "${CMAKE_BINARY_DIR}/cmake_install.cmake" ) Variants 2 and 3 work, 3 also works but installs everything twice (because of the two install commands). I tried to make one OPTIONAL, but no luck. When leaving the second install command out, "make Component1-install" does nothing. Any hints how I could solve the duplicate installation problem with "make install"? Cheers, Eddy From robert.maynard at kitware.com Wed Dec 17 15:54:01 2014 From: robert.maynard at kitware.com (Robert Maynard) Date: Wed, 17 Dec 2014 15:54:01 -0500 Subject: [CMake] [ANNOUNCE] CMake 3.1.0 Released! Message-ID: I am proud to announce that CMake 3.1 is now available for download at: http://www.cmake.org/download http://www.cmake.org/files/v3.1/?C=M;O=D Documentation is available at: http://www.cmake.org/cmake/help/v3.1 Release notes appear below and are also published at http://www.cmake.org/cmake/help/v3.1/release/3.1.0.html Some of the more significant features of CMake 3.1 are: * Windows Phone and Windows Store support has been added to Visual Studio 11 (2012) and above Generators. * NVIDIA Nsight Tegra support has been added to Visual Studio 10 (2010) and above Generators. * New "target_compile_features" command allows populating target based compile features. CMake uses this information to ensure that the compiler in use is capable of building the target, and to add any necessary compile flags such as -std=gnu++11 to support language features. More information on this is found at: - http://www.cmake.org/cmake/help/v3.1/manual/cmake-compile-features.7.html * The syntax for *Variable References* and *Escape Sequences* was simplified in order to allow a much faster implementation. See policy "CMP0053". * The "if" command no longer automatically dereferences variables named in quoted or bracket arguments. See policy "CMP0054". * The target property "SOURCES" now generally supports "Generator Expressions". The generator expressions may be used in the "add_library" and "add_executable" commands. * It is now possible to write and append to the target property "SOURCES". The variable "CMAKE_DEBUG_TARGET_PROPERTIES" can be used to trace the origin of sources. * CPack gained "7Z" and "TXZ" generators supporting lzma-compressed archives. * The ExternalProject module has learned to support lzma-compressed source tarballs with ".7z", ".tar.xz", and ".txz" extensions. * The ExternalProject module ExternalProject_Add command learned a new BUILD_ALWAYS option to cause the external project build step to run every time the host project is built. * The ctest_coverage command learned to support Intel coverage files with the "codecov" tool. * The ctest_memcheck command learned to support sanitizer modes, including "AddressSanitizer", "MemorySanitizer", "ThreadSanitizer", and "UndefinedBehaviorSanitizer". Deprecated and Removed Features: * In CMake 3.0 the "target_link_libraries" command accidentally began allowing unquoted arguments to use Generator Expressions containing a semicolon separated list within them. For example: set(libs B C) target_link_libraries(A PUBLIC $) This is equivalent to writing: target_link_libraries(A PUBLIC $) and was never intended to work. It did not work in CMake 2.8.12. Such generator expressions should be in quoted arguments: set(libs B C) target_link_libraries(A PUBLIC "$") CMake 3.1 again requires the quotes for this to work correctly. CMake 3.1.0 Release Notes ************************* Changes made since CMake 3.0.0 include the following. Documentation Changes ===================== * A new "cmake-compile-features(7)" manual was added. New Features ============ Generators ---------- * The "Visual Studio 14 2015" generator was added. Windows Phone and Windows Store ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * Generators for Visual Studio 11 (2012) and above learned to generate projects for Windows Phone and Windows Store. One may set the "CMAKE_SYSTEM_NAME" variable to "WindowsPhone" or "WindowsStore" on the "cmake(1)" command-line or in a "CMAKE_TOOLCHAIN_FILE" to activate these platforms. Also set "CMAKE_SYSTEM_VERSION" to "8.0" or "8.1" to specify the version of Windows to be targeted. NVIDIA Nsight Tegra ~~~~~~~~~~~~~~~~~~~ * Generators for Visual Studio 10 (2010) and above learned to generate projects for NVIDIA Nsight Tegra Visual Studio Edition. One may set the "CMAKE_SYSTEM_NAME" variable to "Android" on the "cmake(1)" command-line or in a "CMAKE_TOOLCHAIN_FILE" to activate this platform. Syntax ------ * The "cmake-language(7)" syntax for *Variable References* and *Escape Sequences* was simplified in order to allow a much faster implementation. See policy "CMP0053". * The "if()" command no longer automatically dereferences variables named in quoted or bracket arguments. See policy "CMP0054". Commands -------- * The "add_custom_command()" command learned to interpret "cmake- generator-expressions(7)" in arguments to "DEPENDS". * The "export(PACKAGE)" command learned to check the "CMAKE_EXPORT_NO_PACKAGE_REGISTRY" variable to skip exporting the package. * The "file(STRINGS)" command gained a new "ENCODING" option to enable extraction of "UTF-8" strings. * The "find_package()" command learned to check the "CMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY" and "CMAKE_FIND_PACKAGE_NO_SYSTEM_PACKAGE_REGISTRY" variables to skip searching the package registries. * The "get_property()" command learned a new "INSTALL" scope for properties. * The "install()" command learned a "MESSAGE_NEVER" option to avoid output during installation. * The "set_property()" command learned a new "INSTALL" scope for properties. * The "string()" command learned a new "GENEX_STRIP" subcommand which removes "generator expression". * The "string()" command learned a new "UUID" subcommand to generate a univerally unique identifier. * New "target_compile_features()" command allows populating the "COMPILE_FEATURES" target property, just like any other build variable. * The "target_sources()" command was added to add to the "SOURCES" target property. Variables --------- * The Visual Studio generators for versions 8 (2005) and above learned to read the target platform name from a new "CMAKE_GENERATOR_PLATFORM" variable when it is not specified as part of the generator name. The platform name may be specified on the "cmake(1)" command line with the "-A" option, e.g. "-G "Visual Studio 12 2013" -A x64". * The "CMAKE_GENERATOR_TOOLSET" variable may now be initialized in a toolchain file specified by the "CMAKE_TOOLCHAIN_FILE" variable. This is useful when cross-compiling with the Xcode or Visual Studio generators. * The "CMAKE_INSTALL_MESSAGE" variable was introduced to optionally reduce output installation. Properties ---------- * New "CXX_STANDARD" and "CXX_EXTENSIONS" target properties may specify values which CMake uses to compute required compile options such as "-std=c++11" or "-std=gnu++11". The "CMAKE_CXX_STANDARD" and "CMAKE_CXX_EXTENSIONS" variables may be set to initialize the target properties. * New "C_STANDARD" and "C_EXTENSIONS" target properties may specify values which CMake uses to compute required compile options such as "-std=c11" or "-std=gnu11". The "CMAKE_C_STANDARD" and "CMAKE_C_EXTENSIONS" variables may be set to initialize the target properties. * New "COMPILE_FEATURES" target property may contain a list of features required to compile a target. CMake uses this information to ensure that the compiler in use is capable of building the target, and to add any necessary compile flags to support language features. * New "COMPILE_PDB_NAME" and "COMPILE_PDB_OUTPUT_DIRECTORY" target properties were introduced to specify the MSVC compiler program database file location ("cl /Fd"). This complements the existing "PDB_NAME" and "PDB_OUTPUT_DIRECTORY" target properties that specify the linker program database file location ("link /pdb"). * The "INTERFACE_LINK_LIBRARIES" target property now supports a "$" "generator expression". * A new "INTERFACE_SOURCES" target property was introduced. This is consumed by dependent targets, which compile and link the listed sources. * The "SOURCES" target property now contains "generator expression" such as "TARGET_OBJECTS" when read at configure time, if policy "CMP0051" is "NEW". * The "SOURCES" target property now generally supports "generator expression". The generator expressions may be used in the "add_library()" and "add_executable()" commands. * It is now possible to write and append to the "SOURCES" target property. The "CMAKE_DEBUG_TARGET_PROPERTIES" variable may be used to trace the origin of sources. * A "VS_DEPLOYMENT_CONTENT" source file property was added to tell the Visual Studio generators to mark content for deployment in Windows Phone and Windows Store projects. * A "VS_DEPLOYMENT_LOCATION" source file property was added to tell the Visual Studio generators the relative location of content marked for deployment in Windows Phone and Windows Store projects. * The "VS_WINRT_COMPONENT" target property was created to tell Visual Studio generators to compile a shared library as a Windows Runtime (WinRT) component. * The "Xcode" generator learned to check source file properties "XCODE_EXPLICIT_FILE_TYPE" and "XCODE_LAST_KNOWN_FILE_TYPE" for a custom Xcode file reference type. Modules ------- * The "BundleUtilities" module learned to resolve and replace "@rpath" placeholders on OS X to correctly bundle applications using them. * The "CMakePackageConfigHelpers" module "configure_package_config_file()" command learned a new "INSTALL_PREFIX" option to generate package configuration files meant for a prefix other than "CMAKE_INSTALL_PREFIX". * The "CheckFortranSourceCompiles" module was added to provide a "CHECK_Fortran_SOURCE_COMPILES" macro. * The "ExternalData" module learned to tolerate a "DATA{}" reference to a missing source file with a warning instead of rejecting it with an error. This helps developers write new "DATA{}" references to test reference outputs that have not yet been created. * The "ExternalProject" module learned to support lzma-compressed source tarballs with ".7z", ".tar.xz", and ".txz" extensions. * The "ExternalProject" module "ExternalProject_Add" command learned a new "BUILD_ALWAYS" option to cause the external project build step to run every time the host project is built. * The "ExternalProject" module "ExternalProject_Add" command learned a new "EXCLUDE_FROM_ALL" option to cause the external project target to have the "EXCLUDE_FROM_ALL" target property set. * The "ExternalProject" module "ExternalProject_Add_Step" command learned a new "EXCLUDE_FROM_MAIN" option to cause the step to not be a direct dependency of the main external project target. * The "ExternalProject" module "ExternalProject_Add" command learned a new "DOWNLOAD_NO_PROGRESS" option to disable progress output while downloading the source tarball. * The "FeatureSummary" module "feature_summary" API learned to accept multiple values for the "WHAT" option and combine them appropriately. * The "FindCUDA" module learned to support "fatbin" and "cubin" modules. * The "FindGTest" module "gtest_add_tests" macro learned a new "AUTO" option to automatically read the "SOURCES" target property of the test executable and scan the source files for tests to be added. * The "FindGLEW" module now provides imported targets. * The "FindGLUT" module now provides imported targets. * The "FindHg" module gained a new "Hg_WC_INFO" macro to help run "hg" to extract information about a Mercurial work copy. * The "FindOpenCL" module was introduced. * The "FindOpenMP" module learned to support Fortran. * The "FindPkgConfig" module learned to use the "PKG_CONFIG" environment variable value as the "pkg-config" executable, if set. * The "FindXercesC" module was introduced. * The "FindZLIB" module now provides imported targets. * The "GenerateExportHeader" module "generate_export_header" function learned to allow use with *Object Libraries*. * The "InstallRequiredSystemLibraries" module gained a new "CMAKE_INSTALL_OPENMP_LIBRARIES" option to install MSVC OpenMP runtime libraries. * The "UseSWIG" module learned to detect the module name from ".i" source files if possible to avoid the need to set the "SWIG_MODULE_NAME" source file property explicitly. * The "WriteCompilerDetectionHeader" module was added to allow creation of a portable header file for compiler optional feature detection. Generator Expressions --------------------- * New "COMPILE_FEATURES" "generator expression" allows setting build properties based on available compiler features. CTest ----- * The "ctest_coverage()" command learned to read variable "CTEST_COVERAGE_EXTRA_FLAGS" to set "CoverageExtraFlags". * The "ctest_coverage()" command learned to support Intel coverage files with the "codecov" tool. * The "ctest_memcheck()" command learned to support sanitizer modes, including "AddressSanitizer", "MemorySanitizer", "ThreadSanitizer", and "UndefinedBehaviorSanitizer". Options may be set using the new "CTEST_MEMORYCHECK_SANITIZER_OPTIONS" variable. CPack ----- * "cpack(1)" gained an "IFW" generator to package using Qt Framework Installer tools. See the "CPackIFW" module. * "cpack(1)" gained "7Z" and "TXZ" generators supporting lzma- compressed archives. * The "CPackDeb" module learned a new "CPACK_DEBIAN_COMPRESSION_TYPE" variable to set the tarball compression type. * The "cpack(1)" "WiX" generator learned to support a "CPACK_WIX_ACL" installed file property to specify an Access Control List. Other ----- * The "cmake(1)" "-E" option learned a new "env" command. * The "cmake(1)" "-E tar" command learned to support lzma-compressed files. * *Object Libraries* may now have extra sources that do not compile to object files so long as they would not affect linking of a normal library (e.g. ".dat" is okay but not ".def"). * Visual Studio generators for VS 8 and later learned to support the "ASM_MASM" language. * The Visual Studio generators learned to treat ".hlsl" source files as High Level Shading Language sources (using "FXCompile" in ".vcxproj" files). Source file properties "VS_SHADER_TYPE", "VS_SHADER_MODEL", and "VS_SHADER_ENTRYPOINT" were added added to specify the shader type, model, and entry point name. New Diagnostics =============== * Policy "CMP0052" introduced to control directories in the "INTERFACE_INCLUDE_DIRECTORIES" of exported targets. Deprecated and Removed Features =============================== * In CMake 3.0 the "target_link_libraries()" command accidentally began allowing unquoted arguments to use "generator expressions" containing a (";" separated) list within them. For example: set(libs B C) target_link_libraries(A PUBLIC $) This is equivalent to writing: target_link_libraries(A PUBLIC $) and was never intended to work. It did not work in CMake 2.8.12. Such generator expressions should be in quoted arguments: set(libs B C) target_link_libraries(A PUBLIC "$") CMake 3.1 again requires the quotes for this to work correctly. * Callbacks established by the "variable_watch()" command will no longer receive the "ALLOWED_UNKNOWN_READ_ACCESS" access type when the undocumented "CMAKE_ALLOW_UNKNOWN_VARIABLE_READ_ACCESS" variable is set. Uninitialized variable accesses will always be reported as "UNKNOWN_READ_ACCESS". * The "CMakeDetermineVSServicePack" module now warns that it is deprecated and should not longer be used. Use the "CMAKE__COMPILER_VERSION" variable instead. * The "FindITK" module has been removed altogether. It was a thin- wrapper around "find_package(ITK ... NO_MODULE)". This produces much clearer error messages when ITK is not found. * The "FindVTK" module has been removed altogether. It was a thin- wrapper around "find_package(VTK ... NO_MODULE)". This produces much clearer error messages when VTK is not found. The module also provided compatibility support for finding VTK 4.0. This capability has been dropped. Other Changes ============= * The "cmake-gui(1)" learned to capture output from child processes started by the "execute_process()" command and display it in the output window. * The "cmake-language(7)" internal implementation of generator expression and list expansion parsers have been optimized and shows non-trivial speedup on large projects. * The Makefile generators learned to use response files with GNU tools on Windows to pass library directories and names to the linker. * When generating linker command-lines, CMake now avoids repeating items corresponding to SHARED library targets. * Support for the Open Watcom compiler has been overhauled. The "CMAKE__COMPILER_ID" is now "OpenWatcom", and the "CMAKE__COMPILER_VERSION" now uses the Open Watcom external version numbering. The external version numbers are lower than the internal version number by 11. * The "cmake-mode.el" major Emacs editing mode no longer treats "_" as part of words, making it more consistent with other major modes. ------------------------------------------------------------------- Changes made since CMake 3.1.0-rc3: Brad King (2): Help: Drop FeatureSummary example in cmake-developer.7 CMake 3.1.0 Nils Gladitz (1): Help: Extend policy CMP0054 documentation with an example From benapetr at gmail.com Wed Dec 17 18:43:38 2014 From: benapetr at gmail.com (Petr Bena) Date: Thu, 18 Dec 2014 00:43:38 +0100 Subject: [CMake] How to add license Message-ID: I am using cpack and license always show No license provided. I do have SET(CPACK_RESOURCE_FILE_LICENSE "${CMAKE_CURRENT_SOURCE_DIR}/Copyright.txt") and the file is there. Why is that? From benapetr at gmail.com Thu Dec 18 03:13:45 2014 From: benapetr at gmail.com (Petr Bena) Date: Thu, 18 Dec 2014 09:13:45 +0100 Subject: [CMake] How to add license In-Reply-To: References: Message-ID: INCLUDE(CPACK) must be on end, not on beginning :) On Thu, Dec 18, 2014 at 12:43 AM, Petr Bena wrote: > I am using cpack and license always show No license provided. > > I do have SET(CPACK_RESOURCE_FILE_LICENSE > "${CMAKE_CURRENT_SOURCE_DIR}/Copyright.txt") and the file is there. > Why is that? From dschepler at scalable-networks.com Thu Dec 18 13:42:01 2014 From: dschepler at scalable-networks.com (Daniel Schepler) Date: Thu, 18 Dec 2014 18:42:01 +0000 Subject: [CMake] Installing vcomp120.dll Message-ID: This should hopefully be an easy question: Our build of FreeImage has a dependency on vcomp120.dll. However, it would seem that GetPrerequisites.cmake is skipping that dependency because it's in the Visual Studio installation directory, and also InstallRequiredSystemLibraries.cmake doesn't seem to have any facilities for installing that (even optionally). So, my question is: what would be the best way to add an installation of that DLL so that we don't require the VS 2013 x64 redistributable, in such a way that it would be future-proof? -- Daniel -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.hoffman at kitware.com Thu Dec 18 15:39:33 2014 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Thu, 18 Dec 2014 15:39:33 -0500 Subject: [CMake] Installing vcomp120.dll In-Reply-To: References: Message-ID: <54933B85.2050602@kitware.com> On 12/18/2014 1:42 PM, Daniel Schepler wrote: > This should hopefully be an easy question: Our build of FreeImage has a > dependency on vcomp120.dll. However, it would seem that > GetPrerequisites.cmake is skipping that dependency because it?s in the > Visual Studio installation directory, and also > InstallRequiredSystemLibraries.cmake doesn?t seem to have any facilities > for installing that (even optionally). So, my question is: what would > be the best way to add an installation of that DLL so that we don?t > require the VS 2013 x64 redistributable, in such a way that it would be > future-proof? Looks like it is in \VC\redist\arm\Microsoft.VC120.OPENMP\vcomp120.dll. Your best bet would be to copy what is being done in InstallRequiredSystemLibraries but only use the OPENMP directory. Maybe InstallOpenMP.cmake in your project. When you get that working you might want to integrate it into InstallRequiredSystemLibraries and create a patch for CMake. -Bill From raduma at raduma.com Thu Dec 18 17:59:21 2014 From: raduma at raduma.com (Radu Margarint) Date: Thu, 18 Dec 2014 14:59:21 -0800 Subject: [CMake] xcode generator's use of explicitFileType vs lastKnownFileType Message-ID: Greetings, I hope I'm asking this in correct place. I have recently been running into some issues using the xcode project files generated though cmake, and I have traced them down to PBXFileReference nodes using explicitFileType attributes (vs lastKnownFileType). The projects generated are some fairly vanilla mac static libs + console apps, with a file count of ~500ish, about a dozen targets in all. Nothing I would consider complex. However, attempting to open the generated project files in xcode results in xcode hanging for about 3-4 minutes parsing the project file, at open time or whenever it decides it should reparse it. (Sampling it indicates that it's spending it's time calling [PBXFileReference _getEffectiveFileType:fileProperties:] over and over and over). Eventually it finishes and wakes up. Though a lot of trial and error manually mucking with the generated project files, I've traced the slowdown to the use of "explicitFileType" on the file reference nodes. A simple replace to "lastKnownFileType" fixes the issue and xcode opens the project instantly. I'm wondering if anyone has seen this before, and if there are any fixes recommended. (The obvious one being I can patch my cmake generator locally to use the desired attribute, though I'm hoping that maybe there are some known root causes and better fixes). (FWIW, the slow down occurs on both Xcode 5.x and 6.x, on a couple of machines across Yosemite and Mavericks). Thanks --radu From ewmailing at gmail.com Fri Dec 19 02:20:33 2014 From: ewmailing at gmail.com (Eric Wing) Date: Thu, 18 Dec 2014 23:20:33 -0800 Subject: [CMake] xcode generator's use of explicitFileType vs lastKnownFileType In-Reply-To: References: Message-ID: On 12/18/14, Radu Margarint wrote: > Greetings, > > I hope I'm asking this in correct place. I have recently been running > into some issues using the xcode project files generated though cmake, > and I have traced them down to PBXFileReference nodes using > explicitFileType attributes (vs lastKnownFileType). > > The projects generated are some fairly vanilla mac static libs + > console apps, with a file count of ~500ish, about a dozen targets in > all. Nothing I would consider complex. However, attempting to open the > generated project files in xcode results in xcode hanging for about > 3-4 minutes parsing the project file, at open time or whenever it > decides it should reparse it. (Sampling it indicates that it's > spending it's time calling [PBXFileReference > _getEffectiveFileType:fileProperties:] over and over and over). > Eventually it finishes and wakes up. > > Though a lot of trial and error manually mucking with the generated > project files, I've traced the slowdown to the use of > "explicitFileType" on the file reference nodes. A simple replace to > "lastKnownFileType" fixes the issue and xcode opens the project > instantly. > > I'm wondering if anyone has seen this before, and if there are any > fixes recommended. (The obvious one being I can patch my cmake > generator locally to use the desired attribute, though I'm hoping that > maybe there are some known root causes and better fixes). (FWIW, the > slow down occurs on both Xcode 5.x and 6.x, on a couple of machines > across Yosemite and Mavericks). > > Thanks > --radu > -- > I have experienced the extremely long and 100% CPU utilization of Xcode indexing. And in Xcode 5, there seemed to be conditions where it would completely hang and you have to force kill Xcode. And it seems to be random luck on whether it freezes again; certain computers seem to be more susceptible to freezing here. (So far Xcode 6 doesn't seem to need killing, but the CPU taxing is still painful.) And this problem I'm hitting is for relatively small projects, not necessarily large ones. I had not been able to look into this problem and don't know any of the backend details, so I'm happy to hear you found something. This is one of my most worrisome concerns about the Xcode generator right now. (And moving forward, I see it unlikely that the Makefile generator will be sufficient for real Mac & iOS development and we need a much better Xcode generator.) Another thing I just came across is that the internal $SRCROOT directory maps to the root CMakeList.txt directory instead of where the Xcode project resides. Right now, I think this is confusing the OSX entitlements file feature which is causing me pain. I don't have any recommendations, except whatever you find/fix is probably good and well needed. Thanks, Eric -- Beginning iPhone Games Development http://playcontrol.net/iphonegamebook/ From benapetr at gmail.com Fri Dec 19 05:22:26 2014 From: benapetr at gmail.com (Petr Bena) Date: Fri, 19 Dec 2014 11:22:26 +0100 Subject: [CMake] How to use a multiline long string as a variable for CPACK_PACKAGE_DESCRIPTION_SUMMARY Message-ID: There is this variable that cpack uses for description of package. This description has many lines and uses special symbols, like quotes. Putting it into a variable is extremely complex, so I would prefer to load it from external resource. I did this: FILE(READ "${CMAKE_CURRENT_SOURCE_DIR}/build/summary" CPACK_PACKAGE_DESCRIPTION) following http://www.cmake.org/cmake/help/v3.0/command/file.html the only thing that happened was that this variable expanded in CPackConfig.cmake to a long unescaped text, that caused a syntax error in that cmake file. What is a correct way to do that? From eric.noulard at gmail.com Fri Dec 19 05:25:58 2014 From: eric.noulard at gmail.com (Eric Noulard) Date: Fri, 19 Dec 2014 11:25:58 +0100 Subject: [CMake] How to use a multiline long string as a variable for CPACK_PACKAGE_DESCRIPTION_SUMMARY In-Reply-To: References: Message-ID: 2014-12-19 11:22 GMT+01:00 Petr Bena : > > There is this variable that cpack uses for description of package. > This description has many lines and uses special symbols, like quotes. > > Putting it into a variable is extremely complex, so I would prefer to > load it from external resource. I did this: > > FILE(READ "${CMAKE_CURRENT_SOURCE_DIR}/build/summary" > CPACK_PACKAGE_DESCRIPTION) > > following http://www.cmake.org/cmake/help/v3.0/command/file.html > > the only thing that happened was that this variable expanded in > CPackConfig.cmake to a long unescaped text, that caused a syntax error > in that cmake file. > > What is a correct way to do that? > You can use CPACK_PACKAGE_DESCRIPTION_FILE instead of CPACK_PACKAGE_DESCRIPTION i.e. set(CPACK_PACKAGE_DESCRIPTION_FILE "${CMAKE_CURRENT_SOURCE_DIR}/build/summary) > -- > > 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 > -- Eric L'?lection n'est pas la d?mocratie -- http://www.le-message.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric.noulard at gmail.com Fri Dec 19 05:28:00 2014 From: eric.noulard at gmail.com (Eric Noulard) Date: Fri, 19 Dec 2014 11:28:00 +0100 Subject: [CMake] How to use a multiline long string as a variable for CPACK_PACKAGE_DESCRIPTION_SUMMARY In-Reply-To: References: Message-ID: 2014-12-19 11:25 GMT+01:00 Eric Noulard : > > > > 2014-12-19 11:22 GMT+01:00 Petr Bena : >> >> There is this variable that cpack uses for description of package. >> This description has many lines and uses special symbols, like quotes. >> >> Putting it into a variable is extremely complex, so I would prefer to >> load it from external resource. I did this: >> >> FILE(READ "${CMAKE_CURRENT_SOURCE_DIR}/build/summary" >> CPACK_PACKAGE_DESCRIPTION) >> >> following http://www.cmake.org/cmake/help/v3.0/command/file.html >> >> the only thing that happened was that this variable expanded in >> CPackConfig.cmake to a long unescaped text, that caused a syntax error >> in that cmake file. >> >> What is a correct way to do that? >> > > You can use CPACK_PACKAGE_DESCRIPTION_FILE instead of > CPACK_PACKAGE_DESCRIPTION > i.e. > > set(CPACK_PACKAGE_DESCRIPTION_FILE > "${CMAKE_CURRENT_SOURCE_DIR}/build/summary) > see documentations of CPACK_XXX vars: http://www.cmake.org/cmake/help/v3.0/module/CPack.html?highlight=cpack_package_description#variable:CPACK_PACKAGE_DESCRIPTION_FILE -- Eric L'?lection n'est pas la d?mocratie -- http://www.le-message.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From benapetr at gmail.com Fri Dec 19 05:30:40 2014 From: benapetr at gmail.com (Petr Bena) Date: Fri, 19 Dec 2014 11:30:40 +0100 Subject: [CMake] How to use a multiline long string as a variable for CPACK_PACKAGE_DESCRIPTION_SUMMARY In-Reply-To: References: Message-ID: I am using this to build debian package and as http://www.cmake.org/Wiki/CMake:CPackPackageGenerators#control_file_.28aka_DEBIAN.2Fcontrol.29_for_binary_package say, I need to fill CPACK_PACKAGE_DESCRIPTION_SUMMARY Doing what you suggested, produces a debian package with empty summary. On Fri, Dec 19, 2014 at 11:28 AM, Eric Noulard wrote: > > > 2014-12-19 11:25 GMT+01:00 Eric Noulard : >> >> >> >> 2014-12-19 11:22 GMT+01:00 Petr Bena : >>> >>> There is this variable that cpack uses for description of package. >>> This description has many lines and uses special symbols, like quotes. >>> >>> Putting it into a variable is extremely complex, so I would prefer to >>> load it from external resource. I did this: >>> >>> FILE(READ "${CMAKE_CURRENT_SOURCE_DIR}/build/summary" >>> CPACK_PACKAGE_DESCRIPTION) >>> >>> following http://www.cmake.org/cmake/help/v3.0/command/file.html >>> >>> the only thing that happened was that this variable expanded in >>> CPackConfig.cmake to a long unescaped text, that caused a syntax error >>> in that cmake file. >>> >>> What is a correct way to do that? >> >> >> You can use CPACK_PACKAGE_DESCRIPTION_FILE instead of >> CPACK_PACKAGE_DESCRIPTION >> i.e. >> >> set(CPACK_PACKAGE_DESCRIPTION_FILE >> "${CMAKE_CURRENT_SOURCE_DIR}/build/summary) > > > see documentations of CPACK_XXX vars: > > http://www.cmake.org/cmake/help/v3.0/module/CPack.html?highlight=cpack_package_description#variable:CPACK_PACKAGE_DESCRIPTION_FILE > > -- > Eric > L'?lection n'est pas la d?mocratie -- http://www.le-message.org > > -- > > 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 From benapetr at gmail.com Fri Dec 19 05:35:24 2014 From: benapetr at gmail.com (Petr Bena) Date: Fri, 19 Dec 2014 11:35:24 +0100 Subject: [CMake] How to use a multiline long string as a variable for CPACK_PACKAGE_DESCRIPTION_SUMMARY In-Reply-To: References: Message-ID: This must be some bug, I was trying to fill in something in there by hand and it's still empty, I will try to fill in a bug report On Fri, Dec 19, 2014 at 11:30 AM, Petr Bena wrote: > I am using this to build debian package and as > http://www.cmake.org/Wiki/CMake:CPackPackageGenerators#control_file_.28aka_DEBIAN.2Fcontrol.29_for_binary_package > say, I need to fill > > CPACK_PACKAGE_DESCRIPTION_SUMMARY > > Doing what you suggested, produces a debian package with empty summary. > > On Fri, Dec 19, 2014 at 11:28 AM, Eric Noulard wrote: >> >> >> 2014-12-19 11:25 GMT+01:00 Eric Noulard : >>> >>> >>> >>> 2014-12-19 11:22 GMT+01:00 Petr Bena : >>>> >>>> There is this variable that cpack uses for description of package. >>>> This description has many lines and uses special symbols, like quotes. >>>> >>>> Putting it into a variable is extremely complex, so I would prefer to >>>> load it from external resource. I did this: >>>> >>>> FILE(READ "${CMAKE_CURRENT_SOURCE_DIR}/build/summary" >>>> CPACK_PACKAGE_DESCRIPTION) >>>> >>>> following http://www.cmake.org/cmake/help/v3.0/command/file.html >>>> >>>> the only thing that happened was that this variable expanded in >>>> CPackConfig.cmake to a long unescaped text, that caused a syntax error >>>> in that cmake file. >>>> >>>> What is a correct way to do that? >>> >>> >>> You can use CPACK_PACKAGE_DESCRIPTION_FILE instead of >>> CPACK_PACKAGE_DESCRIPTION >>> i.e. >>> >>> set(CPACK_PACKAGE_DESCRIPTION_FILE >>> "${CMAKE_CURRENT_SOURCE_DIR}/build/summary) >> >> >> see documentations of CPACK_XXX vars: >> >> http://www.cmake.org/cmake/help/v3.0/module/CPack.html?highlight=cpack_package_description#variable:CPACK_PACKAGE_DESCRIPTION_FILE >> >> -- >> Eric >> L'?lection n'est pas la d?mocratie -- http://www.le-message.org >> >> -- >> >> 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 From eric.noulard at gmail.com Fri Dec 19 06:10:11 2014 From: eric.noulard at gmail.com (Eric Noulard) Date: Fri, 19 Dec 2014 12:10:11 +0100 Subject: [CMake] How to use a multiline long string as a variable for CPACK_PACKAGE_DESCRIPTION_SUMMARY In-Reply-To: References: Message-ID: 2014-12-19 11:30 GMT+01:00 Petr Bena : > > I am using this to build debian package and as > > http://www.cmake.org/Wiki/CMake:CPackPackageGenerators#control_file_.28aka_DEBIAN.2Fcontrol.29_for_binary_package > say, I need to fill > > CPACK_PACKAGE_DESCRIPTION_SUMMARY > Yes right. See there as well: http://www.cmake.org/cmake/help/v3.0/module/CPackDeb.html?#variable:CPACK_DEBIAN_PACKAGE_DESCRIPTION Doing what you suggested, produces a debian package with empty summary. > This is a bug of the CPackDeb generator. You should report it. In any case if you test & try, beware or purging the build dir between each try. -- Eric L'?lection n'est pas la d?mocratie -- http://www.le-message.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From gjasny at googlemail.com Fri Dec 19 07:33:32 2014 From: gjasny at googlemail.com (Gregor Jasny) Date: Fri, 19 Dec 2014 13:33:32 +0100 Subject: [CMake] xcode generator's use of explicitFileType vs lastKnownFileType In-Reply-To: References: Message-ID: <54941B1C.3080701@googlemail.com> Hi, On 18/12/14 23:59, Radu Margarint wrote: > I hope I'm asking this in correct place. I have recently been running > into some issues using the xcode project files generated though cmake, > and I have traced them down to PBXFileReference nodes using > explicitFileType attributes (vs lastKnownFileType). Real Xcode adds includeInIndex = 0; to some entries; CMake does not. Did you consider this attribute in your investigation? Thanks, Gregor From gjasny at googlemail.com Fri Dec 19 07:51:01 2014 From: gjasny at googlemail.com (Gregor Jasny) Date: Fri, 19 Dec 2014 13:51:01 +0100 Subject: [CMake] CMake 3.1 unable to detect AppleClang when cross-compiling for iOS In-Reply-To: References: Message-ID: <54941F35.3030006@googlemail.com> Hello, On 16/12/14 23:23, Parag Chandra wrote: > Basically, my colleague gets the following errors when he tries to run CMake on a project that I created: > > -- The C compiler identification is unknown > -- The CXX compiler identification is unknown > CMake Error in : > No CMAKE_C_COMPILER could be found. The symptom is that building the XCTest binary fails because code signing for XCTest bundles is mandatory with Xcode 6.1.1 and iOS SDK 8.1. This is caused by the CMakeDetermineCompilerId.cmake module which insists in actually linking something with the compiler used. And with iOS 8.1 everything the gets linked must be also code signed. I'm able to configure the attachment of bug 15214 properly if I add the following line to the CMake invocation: -DCMAKE_XCODE_ATTRIBUTE_CODE_SIGN_IDENTITY="iPhone Developer" (I also have a valid signing key in place) Hope this helps, Gregor From raduma at raduma.com Fri Dec 19 13:37:29 2014 From: raduma at raduma.com (Radu Margarint) Date: Fri, 19 Dec 2014 10:37:29 -0800 Subject: [CMake] xcode generator's use of explicitFileType vs lastKnownFileType In-Reply-To: <54941B1C.3080701@googlemail.com> References: <54941B1C.3080701@googlemail.com> Message-ID: I didn't know about includeInIndex, but I just tried it and it does nothing. To clarify something, the xcode freeze is not a drastic slowdown at indexing time. It's a complete halt at project open time, before the UX even those up. XCode is completely unresponsive doing a ton of [PBXFileReference _getEffectiveFileType:fileProperties:] until it finishes them all, then every starts up fine, indexing is fairly quick and etc. It seems about a year ago the xcode generator switched from lastKnownFileType to explicitFileType, (https://gitorious.org/cmake/cmake/commit/5683146) but without a ton of details as to what was not working when using lastKnownFileType. On Fri, Dec 19, 2014 at 4:33 AM, Gregor Jasny wrote: > Hi, > > On 18/12/14 23:59, Radu Margarint wrote: >> I hope I'm asking this in correct place. I have recently been running >> into some issues using the xcode project files generated though cmake, >> and I have traced them down to PBXFileReference nodes using >> explicitFileType attributes (vs lastKnownFileType). > > Real Xcode adds includeInIndex = 0; to some entries; CMake does not. Did > you consider this attribute in your investigation? > > Thanks, > Gregor > From eric.huhtala at gmail.com Fri Dec 19 18:36:32 2014 From: eric.huhtala at gmail.com (Eric Huhtala) Date: Fri, 19 Dec 2014 17:36:32 -0600 Subject: [CMake] CPack combine source and binary Message-ID: Is there some way to combine source and binary into a single package, specifically in the way described below? I have: source in project/sources binaries in project/build Right now, the closest I've gotten is installing the sources, then getting the .zip file to contain zip/build zip/build/sources but, I would like the .zip file to contain zip/sources zip/build Is there some way I can get CPack to do this for me? Thanks, Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From hlprasu at gmail.com Fri Dec 19 23:48:14 2014 From: hlprasu at gmail.com (Prasad Bhat) Date: Sat, 20 Dec 2014 10:18:14 +0530 Subject: [CMake] Request to reopen a bug (#13231) and apply patch given in to mainstream Message-ID: Hi all, I request to reopen the bug/feature request (#13231) -- https://www.cmake.org/Bug/view.php?id=13231&nbn=1 Other than use case mentioned in the bug, common use case for which I find this to very useful is as follows - 1. If you are packaging a library, it is common practice to have a) shared library and necessary files in lib-.deb and b) all header files and development related files in lib-dev-.deb 2. Packaging two libraries, both of which have differing dependencies. Call to dpkg-shlibs is not always reliable and coding the dependencies directly in CMakeLists.txt is quite often easy. Solution to this bug would help to resolve these problems. The bug (#13231) already has a patch listed in it. Of course, there are work-a-rounds like http://www.cmake.org/pipermail/cmake/2011-April/043715.html But, that is quite round-about methods and involve unrecommended practices like multiple include(CPack). Get this in mainstream would be a great help! Thanks, Prasad ~ Prasad Bhat -------------- next part -------------- An HTML attachment was scrubbed... URL: From domen.vrankar at gmail.com Mon Dec 22 03:19:06 2014 From: domen.vrankar at gmail.com (Domen Vrankar) Date: Mon, 22 Dec 2014 09:19:06 +0100 Subject: [CMake] Request to reopen a bug (#13231) and apply patch given in to mainstream In-Reply-To: References: Message-ID: > I request to reopen the bug/feature request (#13231) -- > https://www.cmake.org/Bug/view.php?id=13231&nbn=1 Hi, I'll have a look at it next week when I'll have more time and get back to you then. Regards, Domen From hlprasu at gmail.com Mon Dec 22 03:20:34 2014 From: hlprasu at gmail.com (Prasad Bhat) Date: Mon, 22 Dec 2014 13:50:34 +0530 Subject: [CMake] Request to reopen a bug (#13231) and apply patch given in to mainstream In-Reply-To: References: Message-ID: Sure! Thanks, Prasad ~ Prasad Bhat On 22 December 2014 at 13:49, Domen Vrankar wrote: > > I request to reopen the bug/feature request (#13231) -- > > https://www.cmake.org/Bug/view.php?id=13231&nbn=1 > > Hi, > > I'll have a look at it next week when I'll have more time and get back > to you then. > > Regards, > Domen > -------------- next part -------------- An HTML attachment was scrubbed... URL: From randomdsdevel at gmail.com Mon Dec 22 16:57:55 2014 From: randomdsdevel at gmail.com (Bryce Glover) Date: Mon, 22 Dec 2014 16:57:55 -0500 Subject: [CMake] Should CMake Ask to Overwrite 'CMakeLists.txt' After It's Been Updated? Message-ID: <31F2EA99-A3EF-4937-851A-B70E7C53E89D@gmail.com> Hello, fellow subscribers, As described here , CMake doesn?t seem to be able to regenerate projects generated by older versions of itself. I?ve read that this might be due to the fact that encountering copies of ?CMakeLists.txt? tends to crash CMake. If this is the case, then shouldn?t CMake have some way of dealing with this when it comes across it? Could CMake update or overwrite ?CMakeLists.txt? if it couldn?t use the copy it finds in a project? Curious, Bryce Glover -------------- next part -------------- An HTML attachment was scrubbed... URL: From golubdr at gmail.com Mon Dec 22 21:03:19 2014 From: golubdr at gmail.com (David Golub) Date: Mon, 22 Dec 2014 21:03:19 -0500 Subject: [CMake] CMake Tools for Visual Studio 1.3 RC1 Available Message-ID: <01b301d01e54$a1565460$e402fd20$@gmail.com> I've made available the first release candidate of CMake Tools for Visual Studio 1.3, which adds support for CMake 3.1 and IntelliSense for generator expressions. As usual, it's available from the project web site at http://cmaketools.codeplex.com. Enjoy! David Golub -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul at mad-scientist.net Tue Dec 23 16:06:44 2014 From: paul at mad-scientist.net (Paul Smith) Date: Tue, 23 Dec 2014 16:06:44 -0500 Subject: [CMake] Help with Policy CMP0026 (disallow LOCATION target property) Message-ID: <1419368804.19591.10.camel@mad-scientist.net> Hi all. I need a pointer or two. In my environment I need to have my executables and binaries copied to another location; this has to happen as part of the default "all" target: it can't be required to run "install" for example (we use the "install" rule for a "real" install step, for one thing). What I was doing with 2.8.12 was creating a custom target "stage_" with a prerequisite of target , which had a custom command that copied . To do this I need to run get_property(pth TARGET PROPERTY LOCATION) so I know where the target file is living, and then I use "cmake -E copy ${pth} ${DESTDIR}" to copy it to the right place. In 3.x this use is deprecated and I wonder what to do instead. If I add a POST_BUILD custom command directly to target which copies the file then I can use $> in my COMMAND script and that works... Except, if someone deletes the copy of the file without touching anything else, it doesn't get recopied (because cmake doesn't know about the copy and so doesn't realize something is wrong). I need this to be recopied because we have a habit of just deleting the entire destination directory and re-running the build to make a fresh copy without changing anything else. I've thought about many ways to do this, but I can't seem to get around the fact that generator expressions like $ are only available within the commands of the target. Help? Thx! From parag at ionicsecurity.com Tue Dec 23 16:32:51 2014 From: parag at ionicsecurity.com (Parag Chandra) Date: Tue, 23 Dec 2014 21:32:51 +0000 Subject: [CMake] Help with Policy CMP0026 (disallow LOCATION target property) In-Reply-To: <1419368804.19591.10.camel@mad-scientist.net> References: <1419368804.19591.10.camel@mad-scientist.net> Message-ID: Have you tried the CMake variables LIBRARY_OUTPUT_PATH and EXECUTABLE_OUTPUT_PATH? I?ve been using them to accomplish much the same thing. Parag Chandra Software Engineer, Mobile Team Mobile: +1.919.824.1410 Ionic Security Inc. 1170 Peachtree St. NE STE 2285, Atlanta, GA 30309 On 12/23/14, 4:06 PM, "Paul Smith" wrote: >Hi all. I need a pointer or two. > >In my environment I need to have my executables and binaries copied to >another location; this has to happen as part of the default "all" >target: it can't be required to run "install" for example (we use the >"install" rule for a "real" install step, for one thing). > >What I was doing with 2.8.12 was creating a custom target "stage_" >with a prerequisite of target , which had a custom command that >copied . To do this I need to run get_property(pth TARGET >PROPERTY LOCATION) so I know where the target file is living, and then I >use "cmake -E copy ${pth} ${DESTDIR}" to copy it to the right place. > >In 3.x this use is deprecated and I wonder what to do instead. > >If I add a POST_BUILD custom command directly to target which >copies the file then I can use $> in my COMMAND script >and that works... > >Except, if someone deletes the copy of the file without touching >anything else, it doesn't get recopied (because cmake doesn't know about >the copy and so doesn't realize something is wrong). > >I need this to be recopied because we have a habit of just deleting the >entire destination directory and re-running the build to make a fresh >copy without changing anything else. > >I've thought about many ways to do this, but I can't seem to get around >the fact that generator expressions like $ are only >available within the commands of the target. > >Help? >Thx! > >-- > >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 From DLRdave at aol.com Tue Dec 23 16:59:50 2014 From: DLRdave at aol.com (David Cole) Date: Tue, 23 Dec 2014 16:59:50 -0500 Subject: [CMake] Help with Policy CMP0026 (disallow LOCATION target property) In-Reply-To: References: <1419368804.19591.10.camel@mad-scientist.net> Message-ID: Paul, Are you sure there's a problem using TARGET_FILE in your original context? It seems to me it should work... >From http://www.cmake.org/cmake/help/v3.1/manual/cmake-generator-expressions.7.html : $ Full path to main file (.exe, .so.1.2, .a) where tgt is the name of a target. You should be able to use that in a custom command in your custom stage_tgt target... You have to give the name of the target for the TARGET_FILE generator expression, so it should work for any target that cmake knows about. Can you point to a simplified reproducible case where this does not work? Maybe there's some other complication in your real project that is making it seem like it's not working.... but I think it should. Can you send us any code? HTH, David C. On Tue, Dec 23, 2014 at 4:32 PM, Parag Chandra wrote: > Have you tried the CMake variables LIBRARY_OUTPUT_PATH and > EXECUTABLE_OUTPUT_PATH? I?ve been using them to accomplish much the same > thing. > > > Parag Chandra > Software Engineer, Mobile Team > Mobile: +1.919.824.1410 > > > > Ionic Security Inc. > 1170 Peachtree St. NE STE 2285, Atlanta, GA 30309 > > > > > > > > > > > > On 12/23/14, 4:06 PM, "Paul Smith" wrote: > >>Hi all. I need a pointer or two. >> >>In my environment I need to have my executables and binaries copied to >>another location; this has to happen as part of the default "all" >>target: it can't be required to run "install" for example (we use the >>"install" rule for a "real" install step, for one thing). >> >>What I was doing with 2.8.12 was creating a custom target "stage_" >>with a prerequisite of target , which had a custom command that >>copied . To do this I need to run get_property(pth TARGET >>PROPERTY LOCATION) so I know where the target file is living, and then I >>use "cmake -E copy ${pth} ${DESTDIR}" to copy it to the right place. >> >>In 3.x this use is deprecated and I wonder what to do instead. >> >>If I add a POST_BUILD custom command directly to target which >>copies the file then I can use $> in my COMMAND script >>and that works... >> >>Except, if someone deletes the copy of the file without touching >>anything else, it doesn't get recopied (because cmake doesn't know about >>the copy and so doesn't realize something is wrong). >> >>I need this to be recopied because we have a habit of just deleting the >>entire destination directory and re-running the build to make a fresh >>copy without changing anything else. >> >>I've thought about many ways to do this, but I can't seem to get around >>the fact that generator expressions like $ are only >>available within the commands of the target. >> >>Help? >>Thx! >> >>-- >> >>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 > > -- > > 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 From paul at mad-scientist.net Wed Dec 24 08:04:21 2014 From: paul at mad-scientist.net (Paul Smith) Date: Wed, 24 Dec 2014 08:04:21 -0500 Subject: [CMake] Help with Policy CMP0026 (disallow LOCATION target property) In-Reply-To: References: <1419368804.19591.10.camel@mad-scientist.net> Message-ID: <1419426261.7095.55.camel@homebase> On Tue, 2014-12-23 at 16:59 -0500, David Cole wrote: > Are you sure there's a problem using TARGET_FILE in your original > context? > You should be able to use that in a custom command in your custom > stage_tgt target... > > You have to give the name of the target for the TARGET_FILE generator > expression, so it should work for any target that cmake knows about. > > Can you point to a simplified reproducible case where this does not > work? > > Maybe there's some other complication in your real project that is > making it seem like it's not working.... but I think it should. Can > you send us any code? Thanks for the reply David. The complication is that the rule I'm trying to create that copies files uses the destination file as the target, so I'm using the target name in the OUTPUT section of add_custom_command. Basically, my current implementation is like this: function(stageobj target dir) get_property(targetpath TARGET ${target} PROPERTY LOCATION) get_filename_component(targetname ${targetpath} NAME) add_custom_command(OUTPUT "${DESTDIR}/${dir}/${targetname}" COMMAND "${CMAKE_COMMAND}" -E make_directory "${DESTDIR}/${dir}" COMMAND "${CMAKE_COMMAND}" -E copy "${targetpath}" "${DESTDIR}/${dir}" DEPENDS ${target} COMMENT "Staging ${target} to ${DESTDIR}/${dir}" VERBATIM) add_custom_target("stage_${target}" ALL DEPENDS "${DESTDIR}/${dir}/${target}") endfunction() This has the very nice feature that it's a real rule, and it only fires if needed (that is, ${target} has been updated since the last time we copied it). But, I can't replace "${targetname}" in the OUTPUT section with a generator expression, because they don't seem to be allowed there: CMake Error at CMake/Stage.cmake:93 (add_custom_command): add_custom_command called with OUTPUT containing a "<". This character is not allowed. Thoughts or alternatives are welcome... From paul at mad-scientist.net Wed Dec 24 08:08:36 2014 From: paul at mad-scientist.net (Paul Smith) Date: Wed, 24 Dec 2014 08:08:36 -0500 Subject: [CMake] Help with Policy CMP0026 (disallow LOCATION target property) In-Reply-To: References: <1419368804.19591.10.camel@mad-scientist.net> Message-ID: <1419426516.7095.58.camel@homebase> On Tue, 2014-12-23 at 21:32 +0000, Parag Chandra wrote: > Have you tried the CMake variables LIBRARY_OUTPUT_PATH and > EXECUTABLE_OUTPUT_PATH? I?ve been using them to accomplish much the > same thing. Well, I don't want ALL my executables and libraries to go into these locations. Only specific ones. However, I see that there's a target property RUNTIME_OUTPUT_DIRECTORY, etc. so maybe setting that property would be an option. When I first started messing with this cmake environment we had a batch of scripts, etc. that were using the original location so I really needed things to live in both locations, for backward compatibility. But at this point I'm pretty sure no one uses the original locations anymore so this could work. I'll look into it. From cxjohnson at gmail.com Wed Dec 24 11:13:43 2014 From: cxjohnson at gmail.com (Chris Johnson) Date: Wed, 24 Dec 2014 10:13:43 -0600 Subject: [CMake] PHP Composer Message-ID: Has anyone out there used CMake to build a PHP Phar file, and more interestingly, used CMake to install a PHP project which uses Composer for dependency management? If so, could you share some information about what your custom commands and custom targets must look like to get this to work? Thanks, ..chris -------------- next part -------------- An HTML attachment was scrubbed... URL: From cxjohnson at gmail.com Wed Dec 24 11:17:07 2014 From: cxjohnson at gmail.com (Chris Johnson) Date: Wed, 24 Dec 2014 10:17:07 -0600 Subject: [CMake] Simultaneous makes? Message-ID: One of my co-workers likes to start multiple makes in various parts of his project source tree. Under our old Makefile-based, build-in-source system, this worked fine. Under our new CMake-based, out-of-source build system, this causes problems, since any make might cause CMake to rebuild its internal files. Is this a "don't do that" problem, or can CMake be used in a manner where it is smart enough not to step on its own toes? Thanks, ..chris -------------- next part -------------- An HTML attachment was scrubbed... URL: From eike at sf-mail.de Wed Dec 24 11:22:43 2014 From: eike at sf-mail.de (Rolf Eike Beer) Date: Wed, 24 Dec 2014 17:22:43 +0100 Subject: [CMake] Simultaneous makes? In-Reply-To: References: Message-ID: <4817209.5g2xGgXyT5@caliban.sf-tec.de> Am Mittwoch, 24. Dezember 2014, 10:17:07 schrieb Chris Johnson: > One of my co-workers likes to start multiple makes in various parts of his > project source tree. Under our old Makefile-based, build-in-source system, > this worked fine. Under our new CMake-based, out-of-source build system, > this causes problems, since any make might cause CMake to rebuild its > internal files. > > Is this a "don't do that" problem, or can CMake be used in a manner where > it is smart enough not to step on its own toes? He should just use "make -j something". Eike -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From cxjohnson at gmail.com Wed Dec 24 12:07:02 2014 From: cxjohnson at gmail.com (Chris Johnson) Date: Wed, 24 Dec 2014 11:07:02 -0600 Subject: [CMake] Simultaneous makes? In-Reply-To: <4817209.5g2xGgXyT5@caliban.sf-tec.de> References: <4817209.5g2xGgXyT5@caliban.sf-tec.de> Message-ID: Perhaps I need to clarify. It's a very large project with many directories and interdependent libraries. So he is starting a make in one library, and then working on a program in another subtree of the same project, and running a make there. Since the entire project shares just one large build tree out-of-source, both compiles share the same CMakeCache.txt and CMakeFiles/*. This is not a case of "parallel" makes (-j N) started from one directory. Thanks, ..chris On Wed, Dec 24, 2014 at 10:22 AM, Rolf Eike Beer wrote: > Am Mittwoch, 24. Dezember 2014, 10:17:07 schrieb Chris Johnson: > > One of my co-workers likes to start multiple makes in various parts of > his > > project source tree. Under our old Makefile-based, build-in-source > system, > > this worked fine. Under our new CMake-based, out-of-source build system, > > this causes problems, since any make might cause CMake to rebuild its > > internal files. > > > > Is this a "don't do that" problem, or can CMake be used in a manner where > > it is smart enough not to step on its own toes? > > He should just use "make -j something". > > Eike > -- > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From irwin at beluga.phys.uvic.ca Wed Dec 24 19:54:49 2014 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Wed, 24 Dec 2014 16:54:49 -0800 (PST) Subject: [CMake] Simultaneous makes? In-Reply-To: References: <4817209.5g2xGgXyT5@caliban.sf-tec.de> Message-ID: On 2014-12-24 11:07-0600 Chris Johnson wrote: > Perhaps I need to clarify. > > It's a very large project with many directories and interdependent > libraries. So he is starting a make in one library, and then working on a > program in another subtree of the same project, and running a make there. > > Since the entire project shares just one large build tree out-of-source, > both compiles share the same CMakeCache.txt and CMakeFiles/*. > > This is not a case of "parallel" makes (-j N) started from one directory. Hi Chris: I haven't used it myself that way, but my understanding is CMake deals well with the issue of building extremely large sets of interdependent software libraries. I therefore suggest you take a look at some large software projects (e.g., KDE and/or VTK, but perhaps others here have additional examples) to see how those software projects organize their builds with CMake. That may give you some ideas on how to avoid the build issue you have discovered for the current way you organize the build of your interdependent set of libraries. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ From erik.nicolas at gmail.com Thu Dec 25 12:07:42 2014 From: erik.nicolas at gmail.com (Eric Nicolas) Date: Thu, 25 Dec 2014 18:07:42 +0100 Subject: [CMake] Issue: CMake 3.1 + Xcode 6.1.1 Message-ID: Hello, I generate a Xcode project using CMake 3.1. The compilation runs fine, but when I launch the binary within Xcode, it makes Xcode crash. The binary is correct however as I can launch it from the command line without problems. Here is a striped down CMakeLists.txt : -------------------------------------------------------- cmake_minimum_required(VERSION 2.8) project(cx21) set(CMAKE_SUPPRESS_REGENERATION TRUE) SET_PROPERTY(GLOBAL PROPERTY USE_FOLDERS ON) set(CMAKE_XCODE_ATTRIBUTE_CLANG_CXX_LANGUAGE_STANDARD "c++0x") find_library(LIB_SDL SDL2 "../_contribs") find_library(LIB_SDLIMAGE SDL2_image "../_contribs") file(GLOB PKG_INC "tester/*.h") file(GLOB PKG_SRC "tester/*.cpp") source_group(include FILES ${PKG_INC}) source_group(src FILES ${PKG_SRC}) add_executable(tester ${PKG_INC} ${PKG_SRC}) target_link_libraries(tester ${LIB_SDL} ${LIB_SDLIMAGE}) -------------------------------------------------------- Producing the Xcode project : -------------------------------------------------------- MacBook-Air:_build enicolas$ cmake --version cmake version 3.1.0 MacBook-Air:_build enicolas$ cmake -G Xcode .. -- The C compiler identification is AppleClang 6.0.0.6000056 -- The CXX compiler identification is AppleClang 6.0.0.6000056 -- Check for working C compiler using: Xcode -- Check for working C compiler using: Xcode -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working CXX compiler using: Xcode -- Check for working CXX compiler using: Xcode -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Configuring done -- Generating done -- Build files have been written to: /Users/enicolas/dev/cx21/v0_2/_build -------------------------------------------------------- Any idea ? Thanks very much. -------------- next part -------------- An HTML attachment was scrubbed... URL: From d3ck0r at gmail.com Sat Dec 27 06:53:23 2014 From: d3ck0r at gmail.com (J Decker) Date: Sat, 27 Dec 2014 03:53:23 -0800 Subject: [CMake] MinGW Makefiles Generator no longer supports toolsets? Message-ID: Is there a particular reason why something that worked perfectly fine no longer does? CMake Error in : Generator MinGW Makefiles does not support toolset specification, but toolset M:/sack/tc_local.txt was specified. CMake Error: CMAKE_C_COMPILER not set, after EnableLanguage CMake Error: CMAKE_CXX_COMPILER not set, after EnableLanguage -------------- next part -------------- An HTML attachment was scrubbed... URL: From d3ck0r at gmail.com Sat Dec 27 07:01:33 2014 From: d3ck0r at gmail.com (J Decker) Date: Sat, 27 Dec 2014 04:01:33 -0800 Subject: [CMake] MinGW Makefiles Generator no longer supports toolsets? In-Reply-To: References: Message-ID: Nevermind; I guess it should have been "Unix Makefiles" went back versions and same thing; so checked other projects sorry. On Sat, Dec 27, 2014 at 3:53 AM, J Decker wrote: > Is there a particular reason why something that worked perfectly fine no > longer does? > > CMake Error in : > Generator > > MinGW Makefiles > > does not support toolset specification, but toolset > > M:/sack/tc_local.txt > > was specified. > > > CMake Error: CMAKE_C_COMPILER not set, after EnableLanguage > CMake Error: CMAKE_CXX_COMPILER not set, after EnableLanguage > -------------- next part -------------- An HTML attachment was scrubbed... URL: From d3ck0r at gmail.com Sat Dec 27 07:10:52 2014 From: d3ck0r at gmail.com (J Decker) Date: Sat, 27 Dec 2014 04:10:52 -0800 Subject: [CMake] MinGW Makefiles Generator no longer supports toolsets? In-Reply-To: References: Message-ID: Even more confusing cmake -G "MinGW Makefiles" -T"" -DCMAKE_TOOLCHAIN_FILE="M:/sack/tc_local.txt" works just fine... (Unix Makefiles also don't like -T option after thinking that was the solution) it's not toolset it's toolchain On Sat, Dec 27, 2014 at 4:01 AM, J Decker wrote: > Nevermind; I guess it should have been "Unix Makefiles" went back > versions and same thing; so checked other projects sorry. > > On Sat, Dec 27, 2014 at 3:53 AM, J Decker wrote: > >> Is there a particular reason why something that worked perfectly fine no >> longer does? >> >> CMake Error in : >> Generator >> >> MinGW Makefiles >> >> does not support toolset specification, but toolset >> >> M:/sack/tc_local.txt >> >> was specified. >> >> >> CMake Error: CMAKE_C_COMPILER not set, after EnableLanguage >> CMake Error: CMAKE_CXX_COMPILER not set, after EnableLanguage >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From csiga.biga at aol.com Sun Dec 28 11:21:13 2014 From: csiga.biga at aol.com (=?utf-8?Q?Nagy-Egri_M=C3=A1t=C3=A9_Ferenc?=) Date: Sun, 28 Dec 2014 16:21:13 +0000 Subject: [CMake] =?utf-8?q?Invoke-Build_support?= In-Reply-To: <20141213205529.1726AA816F@public.kitware.com> References: <20141213205529.1726AA816F@public.kitware.com> Message-ID: I wasn?t hoping for much enthusiasm, but at least some feedback would be welcome. Am I making any sense here? Would such work be completely useless? I figured a crossplatform make language could make use of a script-friendly back-end to facilitate automated building for multiple platforms. Felad?: cmake at cmake.org Elk?ldve: ?szombat?, ?2014?. ?december? ?13?. ?21?:?28 C?mzett: cmake at cmake.org Hi! Being a CMake user for some time, I have come across the issue of parallel builds still being problem with no trivial solution. the NMake back-end does not have batch support, which is said to be non-trivial, while the ninja generator did tend to fail some builds for me too, when I gave it a spin not too long ago (few months). MSBuild.exe seems to do the job, yet some argued that if one does not have access to the IDE itself (I do not exactly know that is possible to have cl.exe but not MSBuild.exe) then it is not feasable. I have started using PowerShell recently (to move out of my comfort zone, which is C++ and GPGPU), and instantly fell in love. I was looking for scriptable PS build systems, and found PSake and Invoke-Build. The former I did not take a deep look into, but the latter seems like a very nice project, with a fairly straight-forward syntax (as far as the makefile goes), as well as parallel capable back-end. The simplicity of the makefile, along with the power of .NET and all the built-in scripting fun of PS, I?d guess it might be the simplest back-end of CMake yet, if it were supported. I am very enthusiastic with a very limited amount of time I could dedicate to such work, but I thought I?d ask you folks if you see any added value in case such a back-end existed? With the chocolatey repository for Windows (in case you?ve never heard of it, google first hit gives you the answer) boasting a successful Kickstarter funding to raise it to a new level, I believe all package maintainers would benefit from a scriptable make system in PS. I have not looked at CMake source code, but just how much effort would it take to fork CMake and create a back-end for Invoke-Build? I have already contacted Invoke-Build?s developer, and while he never had to use CMake during his work, he is willing to take on the effort from IB?s side if some feature were missing to make ends meet. Best regards, M?t? -------------- next part -------------- An HTML attachment was scrubbed... URL: From fraser.hutchison at gmail.com Sun Dec 28 21:03:13 2014 From: fraser.hutchison at gmail.com (Fraser Hutchison) Date: Mon, 29 Dec 2014 02:03:13 +0000 Subject: [CMake] Help with Policy CMP0026 (disallow LOCATION target property) In-Reply-To: <1419426261.7095.55.camel@homebase> References: <1419368804.19591.10.camel@mad-scientist.net> <1419426261.7095.55.camel@homebase> Message-ID: <54A0B661.2090207@gmail.com> An HTML attachment was scrubbed... URL: From steveire at gmail.com Tue Dec 30 07:08:46 2014 From: steveire at gmail.com (Stephen Kelly) Date: Tue, 30 Dec 2014 13:08:46 +0100 Subject: [CMake] CMake Tools for Visual Studio 1.3 RC1 Available References: <01b301d01e54$a1565460$e402fd20$@gmail.com> Message-ID: David Golub wrote: > I've made available the first release candidate of CMake Tools for Visual > Studio 1.3, which adds support for CMake 3.1 and IntelliSense for > generator > expressions. As usual, it's available from the project web site at > http://cmaketools.codeplex.com. Enjoy! Are you aware of this thread? http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711 And does it present possibilities of interesting features to you? Thanks, Steve. From steveire at gmail.com Tue Dec 30 07:13:57 2014 From: steveire at gmail.com (Stephen Kelly) Date: Tue, 30 Dec 2014 13:13:57 +0100 Subject: [CMake] Help with Policy CMP0026 (disallow LOCATION target property) References: <1419368804.19591.10.camel@mad-scientist.net> <1419426261.7095.55.camel@homebase> <54A0B661.2090207@gmail.com> Message-ID: Fraser Hutchison wrote: > Alternatively, you can tell CMake to allow the use of the LOCATION target > property by setting the relevant policy to use the old behaviour > temporarily Please don't do that. Please don't encourage others to do it either. Policies are not feature toggles. http://www.cmake.org/gitweb?p=cmake.git;a=commitdiff;h=cd4fa896 Thanks, Steve. From steveire at gmail.com Tue Dec 30 07:11:38 2014 From: steveire at gmail.com (Stephen Kelly) Date: Tue, 30 Dec 2014 13:11:38 +0100 Subject: [CMake] Invoke-Build support References: <20141213205529.1726AA816F@public.kitware.com> <20141228163023.4E3CFA7F83@public.kitware.com> Message-ID: Nagy-Egri M?t? Ferenc via CMake wrote: > I wasn?t hoping for much enthusiasm, but at least some feedback would be > welcome. Am I making any sense here? Would such work be completely > useless? On the issue of parallelism, jom builds in parallel using NMake makefiles. Apart from that, discussion of a new generator you want to write/contribute belongs on the cmake-developer mailing list. Thanks, Steve. From steveire at gmail.com Tue Dec 30 07:14:52 2014 From: steveire at gmail.com (Stephen Kelly) Date: Tue, 30 Dec 2014 13:14:52 +0100 Subject: [CMake] Help with Policy CMP0026 (disallow LOCATION target property) References: <1419368804.19591.10.camel@mad-scientist.net> Message-ID: Paul Smith wrote: > I've thought about many ways to do this, but I can't seem to get around > the fact that generator expressions like $ are only > available within the commands of the target. It would probably help to have an sscce to experiment with. Thanks, Steve. From cmake.bobd at dfgh.net Tue Dec 30 14:01:37 2014 From: cmake.bobd at dfgh.net (cmake.bobd at dfgh.net) Date: Tue, 30 Dec 2014 14:01:37 -0500 Subject: [CMake] Specifying a file owner Message-ID: <54A2F691.3020905@doolittle.us.com> Hi, I was looking at https://www.cmake.org/Bug/view.php?id=3602 "Add possibility to change file owner into install macro". I have some issues with the comments, but the last note says to discuss the bug on this list, so here goes: CMake already allows the install command to accept PERMISSIONS SETUID It already deals with platforms that can't support SETUID. So the argument that we should not support setting a file owner seems specious to me. It seems inconsistent/incomplete to allow specifying SETUID without allowing specification of the file ownership itself, particularly since changing the file owner after the fact (e.g. in a postinst package script) will clear the SETUID bit anyway, thus rendering its specification useless for anything other than the default (and currently non-overrideable) file owner (root). I believe we should in fact support specifying the file owner, and handle the case where that owner does not exist in the same way (from a user experience) as we handle platforms that don't support SETUID - i.e. do nothing (logging some kind of non-fatal error would be good). Automatically creating a non-existing user would also be nice but is orthogonal and should be handled as a separate feature request rather than muddying the waters around this feature discussion. -Bob From fraser.hutchison at gmail.com Tue Dec 30 17:59:49 2014 From: fraser.hutchison at gmail.com (Fraser Hutchison) Date: Tue, 30 Dec 2014 22:59:49 +0000 Subject: [CMake] Help with Policy CMP0026 (disallow LOCATION target property) In-Reply-To: References: <1419368804.19591.10.camel@mad-scientist.net> <1419426261.7095.55.camel@homebase> <54A0B661.2090207@gmail.com> Message-ID: <54A32E65.2020202@gmail.com> Yup - fair enough. I downgrade my "Alternatively" to "As a last resort". Thanks, Fraser. On 30/12/2014 12:13, Stephen Kelly wrote: > Fraser Hutchison wrote: > >> Alternatively, you can tell CMake to allow the use of the LOCATION target >> property by setting the relevant policy to use the old behaviour >> temporarily > Please don't do that. > > Please don't encourage others to do it either. > > Policies are not feature toggles. > > http://www.cmake.org/gitweb?p=cmake.git;a=commitdiff;h=cd4fa896 > > Thanks, > > Steve. > > From kohaugustine at yahoo.com.sg Tue Dec 30 22:19:54 2014 From: kohaugustine at yahoo.com.sg (Koh Augustine) Date: Wed, 31 Dec 2014 03:19:54 +0000 (UTC) Subject: [CMake] Help with understanding some CMake commands and variables Message-ID: <1580667524.1924317.1419995994387.JavaMail.yahoo@jws10965.mail.sg3.yahoo.com> Dear All CMake Users and Developers, I have a question which I put into a post on Stackoverflow. See:?Understanding CMake variable behavior in SET() and MESSAGE() commands | ? | | ? | | ? | ? | ? | ? | ? | | Understanding CMake variable behavior in SET() and M...I am trying to understand CMake and have worked with some statements requiring me to comprehend the behavior of SET() and MESSAGE(). I worked out the follo... | | | | View on?stackoverflow.com | Preview by Yahoo | | | | ? | I would greatly appreciate anyone's explanation to clarify my questions and doubts. Thank you very much!?Best regards, Augustine Koh -------------- next part -------------- An HTML attachment was scrubbed... URL: From kohaugustine at yahoo.com.sg Tue Dec 30 22:27:40 2014 From: kohaugustine at yahoo.com.sg (Koh Augustine) Date: Wed, 31 Dec 2014 03:27:40 +0000 (UTC) Subject: [CMake] Fw: Help with understanding some CMake commands and variables In-Reply-To: <1580667524.1924317.1419995994387.JavaMail.yahoo@jws10965.mail.sg3.yahoo.com> References: <1580667524.1924317.1419995994387.JavaMail.yahoo@jws10965.mail.sg3.yahoo.com> Message-ID: <2104885664.1950088.1419996460782.JavaMail.yahoo@jws10957.mail.sg3.yahoo.com> Dear All, I realized that somehow the hyperlink did not appear on the mailing list. Here it is:?http://stackoverflow.com/questions/27715669/understanding-cmake-variable-behavior-in-set-and-message-commands Thank you.?Best regards, Augustine Koh On Wednesday, 31 December 2014, 11:19, Koh Augustine wrote: Dear All CMake Users and Developers, I have a question which I put into a post on Stackoverflow. See:?Understanding CMake variable behavior in SET() and MESSAGE() commands | ? | | ? | | ? | ? | ? | ? | ? | | Understanding CMake variable behavior in SET() and M...I am trying to understand CMake and have worked with some statements requiring me to comprehend the behavior of SET() and MESSAGE(). I worked out the follo... | | | | View on?stackoverflow.com | Preview by Yahoo | | | | ? | I would greatly appreciate anyone's explanation to clarify my questions and doubts. Thank you very much!?Best regards, Augustine Koh -------------- next part -------------- An HTML attachment was scrubbed... URL: From erik.nicolas at gmail.com Wed Dec 31 03:08:55 2014 From: erik.nicolas at gmail.com (Eric Nicolas) Date: Wed, 31 Dec 2014 09:08:55 +0100 Subject: [CMake] Issue: CMake 3.1 + Xcode 6.1.1 Message-ID: Hello, I generate a Xcode project using CMake 3.1. The compilation runs fine, but when I launch the binary within Xcode, it makes Xcode crash. The binary is correct however as I can launch it from the command line without problems. Here is a striped down CMakeLists.txt : -------------------------------------------------------- cmake_minimum_required(VERSION 2.8) project(cx21) set(CMAKE_SUPPRESS_REGENERATION TRUE) SET_PROPERTY(GLOBAL PROPERTY USE_FOLDERS ON) set(CMAKE_XCODE_ATTRIBUTE_CLANG_CXX_LANGUAGE_STANDARD "c++0x") find_library(LIB_SDL SDL2 "../_contribs") find_library(LIB_SDLIMAGE SDL2_image "../_contribs") file(GLOB PKG_INC "tester/*.h") file(GLOB PKG_SRC "tester/*.cpp") source_group(include FILES ${PKG_INC}) source_group(src FILES ${PKG_SRC}) add_executable(tester ${PKG_INC} ${PKG_SRC}) target_link_libraries(tester ${LIB_SDL} ${LIB_SDLIMAGE}) -------------------------------------------------------- Producing the Xcode project : -------------------------------------------------------- MacBook-Air:_build enicolas$ cmake --version cmake version 3.1.0 MacBook-Air:_build enicolas$ cmake -G Xcode .. -- The C compiler identification is AppleClang 6.0.0.6000056 -- The CXX compiler identification is AppleClang 6.0.0.6000056 -- Check for working C compiler using: Xcode -- Check for working C compiler using: Xcode -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working CXX compiler using: Xcode -- Check for working CXX compiler using: Xcode -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Configuring done -- Generating done -- Build files have been written to: /Users/enicolas/dev/cx21/v0_2/_build -------------------------------------------------------- Any idea ? Thanks very much. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jose.passes at gmx.com Wed Dec 31 08:19:28 2014 From: jose.passes at gmx.com (=?windows-1252?Q?Z=E9?=) Date: Wed, 31 Dec 2014 13:19:28 +0000 Subject: [CMake] Simultaneous makes? In-Reply-To: References: <4817209.5g2xGgXyT5@caliban.sf-tec.de> Message-ID: <54A3F7E0.9020203@gmx.com> On 12/24/2014 05:07 PM, Chris Johnson wrote: > Perhaps I need to clarify. > > It's a very large project with many directories and interdependent > libraries. So he is starting a make in one library, and then working on > a program in another subtree of the same project, and running a make there. > > Since the entire project shares just one large build tree out-of-source, > both compiles share the same CMakeCache.txt and CMakeFiles/*. > > This is not a case of "parallel" makes (-j N) started from one directory. I don't know if this will help, but as no one managed to provide any useful tip, here's my 0,02?: Wouldn't it be possible to write a Makefile that managed all concurrent builds by calling the relevant make commands for each subproject? -- Z?