From jaime.armendariz at aurorasat.es Fri Aug 1 04:39:19 2014 From: jaime.armendariz at aurorasat.es (Jaime Armendariz) Date: Fri, 1 Aug 2014 10:39:19 +0200 Subject: [CMake] /MP[num_threads] not working in Cmake 3.0.0 In-Reply-To: <53DA6335.1010707@kitware.com> References: <53DA6335.1010707@kitware.com> Message-ID: Hello Brad, You are right. It is working fine. My fault configuring the options. Thank you and sorry for this. On Thu, Jul 31, 2014 at 5:39 PM, Brad King wrote: > On Thu, Jul 31, 2014 at 10:29 AM, Jaime Armendariz wrote: > > If I add "/MP4" for example in my${CMAKE_CXX_FLAGS_RELEASE}, cmake > converts > > it to "/MP" that means "all cores available". > [snip] > > Cmake 3.0.0 and 2.8.12.2 > > Windows 7 64 bits > > Visual Studio 2013 / Visual Studio 2010 SP1 > > With CMake 3.0.0 on VS 2013 I tried that and got: > > true > 4 > > in the .vcxproj file. The compilation command-line then had "/MP4" > as expected. > > -Brad > -- * Jaime Armendariz Villalba*Software Director / Information Systems Director Aurora Software and Testing, S. L. Universidad Polit?cnica de Valencia Edificio de Desarrollo Empresarial 9B Camino de Vera, s/n, 46022 Valencia, Spain Tlf: +34 963 714 254 -- La informaci?n contenida en este correo electr?nico, y en su caso, cualquier fichero anexo al mismo, son de car?cter privado y confidencial siendo para uso exclusivo de su destinatario. Si usted no es el destinatario correcto, el empleado o agente responsable de entregar el mensaje al destinatario, o ha recibido esta comunicaci?n por error, le informamos que est? totalmente prohibida cualquier divulgaci?n, distribuci?n o reproducci?n de esta comunicaci?n seg?n la legislaci?n vigente y le rogamos que nos lo notifique inmediatamente, procediendo a su destrucci?n sin continuar su lectura. Le informamos que su direcci?n de correo electr?nico, as? como el resto de los datos de car?cter personal que nos facilite, podr?an ser objeto de tratamiento automatizado en nuestros ficheros, con la finalidad de gestionar la agenda de contactos de nuestra empresa. Vd. podr? en cualquier momento ejercer el derecho de acceso, rectificaci?n, cancelaci?n y oposici?n en los t?rminos establecidos en la Ley Org?nica 15/1999 de Protecci?n de Datos de Car?cter Personal mediante notificaci?n a esta direcci?n de correo electr?nico. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ravi.raman at Xoriant.Com Fri Aug 1 07:50:57 2014 From: ravi.raman at Xoriant.Com (Ravi Raman) Date: Fri, 1 Aug 2014 11:50:57 +0000 Subject: [CMake] Cmake issue regarding conversion of existing Visual Studio .targets files to cmake References: <8D179F530C72B33-1AB8-751D@webmail-va013.sysops.aol.com> <3056ae878153436da4a35990db9632a1@XORMUM-MBX02.India.XoriantCorp.com> <8D17A255B13AD2A-26BC-11F0C@webmail-vm027.sysops.aol.com> <8D17AC923E1771A-2E74-153EF@webmail-d159.sysops.aol.com> Message-ID: Hi David, We are executing the following POST_BUILD commands using add_custom_command() call in cmake. add_custom_command( TARGET ${TARGETNAME} POST_BUILD COMMAND ${TBIN}/VerCheck.exe \"$(TargetPath)\" POST_BUILD COMMAND copy \"$(TargetPath)\" \"$(TargetPath).vercheck_dummy_target\" COMMENT "Checking if $(TargetPath) has version info...") The issue we are facing is with the execution of the post-build command ${TBIN}/VerCheck.exe \"$(TargetPath)\". It gives the following error: C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V110\Microsoft.CppCommon.targets(134,5): error MSB3073: The command "setlocal\r [E:\RaviRaman\Project\Auto Desk\Source\AutoDesk_Project\autodesk_project\XoriantRepo\components\global\src\objectdbx\build\x64\versioninfo\GenVerInfo.vcxproj] C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V110\Microsoft.CppCommon.targets(134,5): error MSB3073: ..\..\..\..\..\..\..\develop\tools\bin\VerCheck.exe "E:\RaviRaman\Project\AutoDesk\Source\AutoDesk_Project\autodesk_project\XoriantRepo\components\global\src\objectdbx\build\x64\versioninfo\Debug\GenVerInfo_d.exe"\r [E:\RaviRaman\Project\AutoDesk\Source\AutoDesk_Project\autodesk_project\XoriantRepo\components\global\src\objectdbx\build\x64\versioninfo\GenVerInfo.vcxproj] Also, note the following: 1. The execution is successful and there is no error when I keep only the copy command and comment out the command ${TBIN}/VerCheck.exe \"$(TargetPath)\" 2. VerCheck.exe is a project specific executable which checks the version of the specified target 3. All the variables above in ${...} are getting correctly replaced. So, that is not an issue. 4. We are able to execute both the commands ${TBIN}/VerCheck.exe and copy successfully from the DOS command line. Thanks & Regards Ravi Raman Xoriant Solutions Pvt. Ltd 4th Floor, Winchester, Hiranandani Business Park, Powai, Mumbai 400076, INDIA. Tel: +91 22 30511000,9930100026 Extn: 2144 Voip No. 4088344495/96/97/98 Voip Extn:1178| Fax: +91 22 30511111 ravi.raman at xoriant.com| http://www.xoriant.com -----Original Message----- From: Ravi Raman Sent: Thursday, July 31, 2014 5:07 PM To: 'David Cole' Cc: cmake at cmake.org Subject: RE: [CMake] Cmake issue regarding conversion of existing Visual Studio .targets files to cmake Hi David, Thanks for the reply. Understood. Will use the cmake function add_custom_command() with POST_BUILD option in case of after build and PRE_BUILD option in case of before build. Thanks & Regards Ravi Raman Xoriant Solutions Pvt. Ltd 4th Floor, Winchester, Hiranandani Business Park, Powai, Mumbai 400076, INDIA. Tel: +91 22 30511000,9930100026 Extn: 2144 Voip No. 4088344495/96/97/98 Voip Extn:1178| Fax: +91 22 30511111 ravi.raman at xoriant.com| http://www.xoriant.com -----Original Message----- From: David Cole [mailto:dlrdave at aol.com] Sent: Thursday, July 31, 2014 4:55 PM To: Ravi Raman Cc: cmake at cmake.org Subject: Re: [CMake] Cmake issue regarding conversion of existing Visual Studio .targets files to cmake So from the example you've sent, it seems like the stuff in your targets file is just a bunch of custom commands that you'd need to run. There are plenty of examples of projects using add_custom_command and add_custom_target out there, and if you have specific questions about how those commands work, do send more emails and ask those questions. I don't think there's anything out there that will help you automate this task.... but if there is, hopefully somebody who can point you to them will show up here. Otherwise, it's just "roll up your sleeves" time, and do the work manually to convert targets files into CMakeLists that use add_custom_command. Cheers, David C. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dlrdave at aol.com Fri Aug 1 08:04:32 2014 From: dlrdave at aol.com (David Cole) Date: Fri, 1 Aug 2014 08:04:32 -0400 (EDT) Subject: [CMake] Cmake issue regarding conversion of existing Visual Studio .targets files to cmake In-Reply-To: References: <8D179F530C72B33-1AB8-751D@webmail-va013.sysops.aol.com> <3056ae878153436da4a35990db9632a1@XORMUM-MBX02.India.XoriantCorp.com> <8D17A255B13AD2A-26BC-11F0C@webmail-vm027.sysops.aol.com> <8D17AC923E1771A-2E74-153EF@webmail-d159.sysops.aol.com> Message-ID: <8D17B97E39AE344-BD0-159A4@webmail-d258.sysops.aol.com> First try this: -----Original Message----- From: Ravi Raman To: David Cole Cc: cmake Sent: Fri, Aug 1, 2014 7:49 am Subject: RE: [CMake] Cmake issue regarding conversion of existing Visual Studio .targets files to cmake Hi David, ? We are executing the following POST_BUILD commands using add_custom_command() call in cmake. ? add_custom_command( ??????? TARGET ${TARGETNAME} ??????? POST_BUILD COMMAND ${TBIN}/VerCheck.exe \"$(TargetPath)\" ??????? POST_BUILD COMMAND copy \"$(TargetPath)\" \"$(TargetPath).vercheck_dummy_target\" ??????? COMMENT "Checking if $(TargetPath) has version info...") ? The issue we are facing is with the execution of the post-build command ${TBIN}/VerCheck.exe \"$(TargetPath)\". It gives the following error: ? ? C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V110\Microsoft.CppCommon.targets(134,5): error MSB3073: The command "setlocal\r [E:\RaviRaman\Project\Auto Desk\Source\AutoDesk_Project\autodesk_project\XoriantRepo\components\glob al\src\objectdbx\build\x64\versioninfo\GenVerInfo.vcxproj] C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V110\Microsoft.CppCommon.targets(134,5): error MSB3073: ..\..\..\..\..\..\..\develop\tools\bin\VerCheck.exe "E:\RaviRaman\Project\AutoDesk\Source\AutoDesk_Project\autodesk_project\X oriantRepo\components\global\src\objectdbx\build\x64\versioninfo\Debug\Ge nVerInfo_d.exe"\r [E:\RaviRaman\Project\AutoDesk\Source\AutoDesk_Project\autodesk_project\X oriantRepo\components\global\src\objectdbx\build\x64\versioninfo\GenVerIn fo.vcxproj] ? Also, note the following: 1. The execution is successful and there is no error when I keep only the copy command and comment out the command ${TBIN}/VerCheck.exe \"$(TargetPath)\" 2. VerCheck.exe is a project specific executable which checks the version of the specified target 3. All the variables above in ${...} are getting correctly replaced. So, that is not an issue. 4. We are able to execute both the commands ${TBIN}/VerCheck.exe and copy successfully from the DOS command line. ? ? Thanks & Regards ? Ravi Raman Xoriant Solutions Pvt. Ltd 4th Floor, Winchester,?Hiranandani Business Park, Powai,?Mumbai 400076, INDIA. Tel: +91 22 30511000,9930100026 Extn: 2144 Voip No. 4088344495/96/97/98 Voip Extn:1178| Fax: +91 22 30511111 ravi.raman at xoriant.com|?http://www.xoriant.com ? ? -----Original Message----- From: Ravi Raman Sent: Thursday, July 31, 2014 5:07 PM To: 'David Cole' Cc: cmake at cmake.org Subject: RE: [CMake] Cmake issue regarding conversion of existing Visual Studio .targets files to cmake ? Hi David, ? Thanks for the reply. Understood. Will use the cmake function add_custom_command() with POST_BUILD option in case of after build and PRE_BUILD option in case of before build. ? Thanks & Regards ? Ravi Raman Xoriant Solutions Pvt. Ltd 4th Floor, Winchester,?Hiranandani Business Park, Powai,?Mumbai 400076, INDIA. Tel: +91 22 30511000,9930100026 Extn: 2144 Voip No. 4088344495/96/97/98 Voip Extn:1178| Fax: +91 22 30511111 ravi.raman at xoriant.com|?http://www.xoriant.com ? ? -----Original Message----- From: David Cole [mailto:dlrdave at aol.com] Sent: Thursday, July 31, 2014 4:55 PM To: Ravi Raman Cc: cmake at cmake.org Subject: Re: [CMake] Cmake issue regarding conversion of existing Visual Studio .targets files to cmake ? So from the example you've sent, it seems like the stuff in your targets file is just a bunch of custom commands that you'd need to run. There are plenty of examples of projects using add_custom_command and add_custom_target out there, and if you have specific questions about how those commands work, do send more emails and ask those questions. ? I don't think there's anything out there that will help you automate this task.... but if there is, hopefully somebody who can point you to them will show up here. ? Otherwise, it's just "roll up your sleeves" time, and do the work manually to convert targets files into CMakeLists that use add_custom_command. ? ? Cheers, David C. ? ? From dlrdave at aol.com Fri Aug 1 08:11:18 2014 From: dlrdave at aol.com (David Cole) Date: Fri, 1 Aug 2014 08:11:18 -0400 (EDT) Subject: [CMake] Cmake issue regarding conversion of existing Visual Studio .targets files to cmake Message-ID: <8D17B98D58C24C4-BD0-159DA@webmail-d258.sysops.aol.com> Sorry about the premature "send" on that last email... First try this: add_custom_command( TARGET ${TARGETNAME} POST_BUILD COMMAND ${TBIN}/VerCheck.exe \"$(TargetPath)\" COMMAND copy \"$(TargetPath)\" \"$(TargetPath).vercheck_dummy_target\" COMMENT "Checking if $(TargetPath) has version info...") i.e. -- just say "POST_BUILD" once, then a sequence of COMMAND lines. (I think it's passing your second POST_BUILD as an argument to VerCheck...) If that still doesn't work, try: add_custom_command( TARGET ${TARGETNAME} POST_BUILD COMMAND VerCheckAndCopy.bat "${TBIN}" "$(TargetPath)" COMMENT "Checking if $(TargetPath) has version info...") and delegate it to a batch script that takes arguments which internally does the sequence of commands you want. If you go this route, you may still need nested quotes around "$(TargetPath)" -- CMake doesn't know about expanding those VS values, and whether or not they'll need quotes around them. HTH, David C. From ravi.raman at Xoriant.Com Fri Aug 1 10:31:17 2014 From: ravi.raman at Xoriant.Com (Ravi Raman) Date: Fri, 1 Aug 2014 14:31:17 +0000 Subject: [CMake] Cmake issue regarding conversion of existing Visual Studio .targets files to cmake In-Reply-To: <8D17B98D58C24C4-BD0-159DA@webmail-d258.sysops.aol.com> References: <8D17B98D58C24C4-BD0-159DA@webmail-d258.sysops.aol.com> Message-ID: <310a49547dce481392cdd26545c4d5c3@XORMUM-MBX02.India.XoriantCorp.com> Hi David, Thanks. The 2nd approach of using batch file worked successfully. Thanks & Regards Ravi Raman Xoriant Solutions Pvt. Ltd 4th Floor, Winchester,?Hiranandani Business Park, Powai,?Mumbai 400076, INDIA. Tel: +91 22 30511000,9930100026 Extn: 2144 Voip No. 4088344495/96/97/98 Voip Extn:1178| Fax: +91 22 30511111 ravi.raman at xoriant.com|?http://www.xoriant.com -----Original Message----- From: David Cole [mailto:dlrdave at aol.com] Sent: Friday, August 01, 2014 5:41 PM To: Ravi Raman Cc: cmake at cmake.org Subject: Re: [CMake] Cmake issue regarding conversion of existing Visual Studio .targets files to cmake Sorry about the premature "send" on that last email... First try this: add_custom_command( TARGET ${TARGETNAME} POST_BUILD COMMAND ${TBIN}/VerCheck.exe \"$(TargetPath)\" COMMAND copy \"$(TargetPath)\" \"$(TargetPath).vercheck_dummy_target\" COMMENT "Checking if $(TargetPath) has version info...") i.e. -- just say "POST_BUILD" once, then a sequence of COMMAND lines. (I think it's passing your second POST_BUILD as an argument to VerCheck...) If that still doesn't work, try: add_custom_command( TARGET ${TARGETNAME} POST_BUILD COMMAND VerCheckAndCopy.bat "${TBIN}" "$(TargetPath)" COMMENT "Checking if $(TargetPath) has version info...") and delegate it to a batch script that takes arguments which internally does the sequence of commands you want. If you go this route, you may still need nested quotes around "$(TargetPath)" -- CMake doesn't know about expanding those VS values, and whether or not they'll need quotes around them. HTH, David C. From nicolasbock at gmail.com Fri Aug 1 12:54:13 2014 From: nicolasbock at gmail.com (Nicolas Bock) Date: Fri, 1 Aug 2014 10:54:13 -0600 Subject: [CMake] Fwd: set_target_properties and language specific COMPILE_FLAGS In-Reply-To: References: Message-ID: Hi, I am building a library containing Fortran and C sources. I would like to add language specific compile flags without affecting the global compile flags: set_target_properties( foo PROPERTIES C_FLAGS "-fopenmp" Fortran_FLAGS "-openmp" ) However, it seems there is only COMPILE_FLAGS which presumably affects both languages. Thanks already, nick From chuck.atkins at kitware.com Fri Aug 1 14:37:01 2014 From: chuck.atkins at kitware.com (Chuck Atkins) Date: Fri, 1 Aug 2014 14:37:01 -0400 Subject: [CMake] Fwd: set_target_properties and language specific COMPILE_FLAGS In-Reply-To: References: Message-ID: Hi Nick, You could split your target in to two object libraries that combine into a singe "real" library: add_library(foo_f OBJECT ${FOO_F_SOURCES}) # set necessary compile flags specific to the Fortran components # on the foo_f target add_library(foo_c OBJECT ${FOO_C_SOURCES}) # set necessary compile flags specific to the C components # on the foo_c target # Combine into a "real" library add_library(foo $ $) See http://www.cmake.org/Wiki/CMake/Tutorials/Object_Library - Chuck On Fri, Aug 1, 2014 at 12:54 PM, Nicolas Bock wrote: > Hi, > > I am building a library containing Fortran and C sources. I would like > to add language specific compile flags without affecting the global > compile flags: > > set_target_properties( foo PROPERTIES C_FLAGS "-fopenmp" Fortran_FLAGS > "-openmp" ) > > However, it seems there is only COMPILE_FLAGS which presumably affects > both languages. > > Thanks already, > > nick > -- > > 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 chrysalisx at gmail.com Fri Aug 1 20:30:43 2014 From: chrysalisx at gmail.com (Walter Gray) Date: Fri, 01 Aug 2014 17:30:43 -0700 Subject: [CMake] Defining a function in a macro Message-ID: <53DC3133.9030104@gmail.com> Hey List - Just wanted to put this out there for posterity, and in case anyone runs into the same question I had. I had a bunch of nearly identical functions, so I wanted to write a function to define them for me to reduce code repetition. The problem I ran into was that if you write macro(_define_function name) function(namespaced_${function_name} ...) message(${ARGV} from ${name}) endfunction() endmacro() _define_function(foo) namespaced_foo("Message") you actually wind up printing "foo from foo", since all variable references to a macro are expanded first. I also couldn't use a function, since there would be no way to access ${name} from inside the function (that I'm aware of - please correct me on this if I'm wrong) The solution I came up with was, if I wanted to reference the function's argv, I would do a double-dereference of a string containing "ARGV" like so: macro(_define_function name) function(namespaced_${function_name} ...) set(my_argv ARGV) message(${${my_argv}} from ${name}) endfunction() endmacro() This produced the correct results. If any of you know of a cleaner way to do this, I'd love to hear about it. If not, have fun writing functions to write your functions! As a relatively useless, but I thought entertaining aside: macro(_define_function name my_argv) function(namespaced_${function_name} ...) message(${my_argv} from ${name}) endfunction() endmacro() _define_function(foo "\${ARGV}") namespaced_foo("Message") The result is "foo Message from foo" because ${my_argv} gets expand to ${ARGV}, which then expands to "foo ${ARGV}". Thanks! From glenn.coombs at gmail.com Sat Aug 2 11:11:36 2014 From: glenn.coombs at gmail.com (Glenn Coombs) Date: Sat, 2 Aug 2014 16:11:36 +0100 Subject: [CMake] Is it possible for a dependee to use the dependency LINKER_FLAGS ? In-Reply-To: References: Message-ID: I think that you can use the target_link_libraries command to do this: add_library(A a.cpp) target_link_libraries(A INTERFACE -custom-flags) -- Glenn On 30 July 2014 16:51, Adrian M Negreanu wrote: > Hi, > > Is it possible to attach a property on a target, and that property > to be used whenever the target is used ? > > ex: > > add_library(A a.cpp) > somehow_attach_LINK_FLAGS(A "--custom-flags") > > # in a different directory > add_executable(E e.cpp) > target_link_libraries(E A) > # ^--- this would do something similiar to > set_target_properties(E PROPERTIES LINK_FLAGS "--custom-flags") > > For example, to use A:LINK_FLAGS > > 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 chrysalisx at gmail.com Sat Aug 2 12:38:41 2014 From: chrysalisx at gmail.com (Walter Gray) Date: Sat, 2 Aug 2014 09:38:41 -0700 Subject: [CMake] Is it possible for a dependee to use the dependency LINKER_FLAGS ? In-Reply-To: References: Message-ID: Glen is correct. You should take a look at the docs for interface modules here: http://www.cmake.org/cmake/help/v3.0/manual/cmake-buildsystem.7.html#interface-libraries I also put up some examples of how to do this on github a while back. https://github.com/wal-rus/cmake-modules Hope that helps! Also for future googling the concept is called Usage Requirements. On Aug 2, 2014 8:11 AM, "Glenn Coombs" wrote: > I think that you can use the target_link_libraries command to do this: > > add_library(A a.cpp) > target_link_libraries(A INTERFACE -custom-flags) > > -- > Glenn > > > > On 30 July 2014 16:51, Adrian M Negreanu wrote: > >> Hi, >> >> Is it possible to attach a property on a target, and that property >> to be used whenever the target is used ? >> >> ex: >> >> add_library(A a.cpp) >> somehow_attach_LINK_FLAGS(A "--custom-flags") >> >> # in a different directory >> add_executable(E e.cpp) >> target_link_libraries(E A) >> # ^--- this would do something similiar to >> set_target_properties(E PROPERTIES LINK_FLAGS "--custom-flags") >> >> For example, to use A:LINK_FLAGS >> >> 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 >> > > > -- > > 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 groleo at gmail.com Sun Aug 3 02:43:23 2014 From: groleo at gmail.com (Adrian M Negreanu) Date: Sun, 3 Aug 2014 09:43:23 +0300 Subject: [CMake] Is it possible for a dependee to use the dependency LINKER_FLAGS ? In-Reply-To: References: Message-ID: I've tested this with vs 2013 but a few things makes me think that using target_link_libraries is not for this type of usage. First, for setup 1: ===== CMakeLists.txt ================ cmake_minimum_required(VERSION 3.0) add_library(A a.cpp) target_link_libraries(A INTERFACE -custom-flags) add_executable(E e.cpp) target_link_libraries(E A) ################################### Cmake warns me: CMake Warning (dev) in CMakeLists.txt: Policy CMP0022 is not set: INTERFACE_LINK_LIBRARIES defines the link interface. Run "cmake --help-policy CMP0022" for policy details. Use the cmake_policy command to set the policy and suppress this warning. Target "A" has an INTERFACE_LINK_LIBRARIES property. This should be preferred as the source of the link interface for this library but because CMP0022 is not set CMake is ignoring the property and using the link implementation as the link interface instead. INTERFACE_LINK_LIBRARIES: /FORCE:multiple For setup 2: ===== CMakeLists.txt ================ cmake_minimum_required(VERSION 3.0) add_library(A a.cpp) set_target_properties(A PROPERTIES INTERFACE_LINK_LIBRARIES "/FORCE:multiple") add_executable(E e.cpp) target_link_libraries(E A) ################################### Cmake works fine, _but_ "/FORCE:multiple" is seen as a file, which leads to error: 1>------ Build started: Project: ZERO_CHECK, Configuration: Debug Win32 ------ 2>------ Build started: Project: A, Configuration: Debug Win32 ------ 2> A.vcxproj -> C:\Users\amnegrea\Debug\A.lib 3>------ Build started: Project: E, Configuration: Debug Win32 ------ 3>LINK : fatal error LNK1104: cannot open file '\FORCE:multiple.obj' 4>------ Skipped Build: Project: ALL_BUILD, Configuration: Debug Win32 ------ 4>Project not selected to build for this solution configuration ========== Build: 2 succeeded, 1 failed, 0 up-to-date, 1 skipped ========== On Sat, Aug 2, 2014 at 7:38 PM, Walter Gray wrote: > Glen is correct. You should take a look at the docs for interface modules > here: > > > http://www.cmake.org/cmake/help/v3.0/manual/cmake-buildsystem.7.html#interface-libraries > > I also put up some examples of how to do this on github a while back. > > https://github.com/wal-rus/cmake-modules > > Hope that helps! Also for future googling the concept is called Usage > Requirements. > On Aug 2, 2014 8:11 AM, "Glenn Coombs" wrote: > >> I think that you can use the target_link_libraries command to do this: >> >> add_library(A a.cpp) >> target_link_libraries(A INTERFACE -custom-flags) >> >> -- >> Glenn >> >> >> >> On 30 July 2014 16:51, Adrian M Negreanu wrote: >> >>> Hi, >>> >>> Is it possible to attach a property on a target, and that property >>> to be used whenever the target is used ? >>> >>> ex: >>> >>> add_library(A a.cpp) >>> somehow_attach_LINK_FLAGS(A "--custom-flags") >>> >>> # in a different directory >>> add_executable(E e.cpp) >>> target_link_libraries(E A) >>> # ^--- this would do something similiar to >>> set_target_properties(E PROPERTIES LINK_FLAGS "--custom-flags") >>> >>> For example, to use A:LINK_FLAGS >>> >>> 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 >>> >> >> >> -- >> >> 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 >> > -- Regards! http://groleo.wordpress.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From dlrdave at aol.com Sun Aug 3 08:43:44 2014 From: dlrdave at aol.com (David Cole) Date: Sun, 3 Aug 2014 08:43:44 -0400 (EDT) Subject: [CMake] Defining a function in a macro In-Reply-To: <53DC3133.9030104@gmail.com> References: <53DC3133.9030104@gmail.com> Message-ID: <8D17D2FB28CEB97-64C-1B8CC@webmail-vm084.sysops.aol.com> Ouch... my brain hurts... Another idea would be to write the "generated functions" out to a file, and then, after all functions are written to the file, include the file. Might result in something you can actually look at in an editor (and make sense of) without your brain hurting too much, too. ;-) D -----Original Message----- From: Walter Gray To: cmake Sent: Fri, Aug 1, 2014 8:32 pm Subject: [CMake] Defining a function in a macro Hey List - Just wanted to put this out there for posterity, and in case anyone runs into the same question I had. I had a bunch of nearly identical functions, so I wanted to write a function to define them for me to reduce code repetition. The problem I ran into was that if you write macro(_define_function name) function(namespaced_${function_name} ...) message(${ARGV} from ${name}) endfunction() endmacro() _define_function(foo) namespaced_foo("Message") you actually wind up printing "foo from foo", since all variable references to a macro are expanded first. I also couldn't use a function, since there would be no way to access ${name} from inside the function (that I'm aware of - please correct me on this if I'm wrong) The solution I came up with was, if I wanted to reference the function's argv, I would do a double-dereference of a string containing "ARGV" like so: macro(_define_function name) function(namespaced_${function_name} ...) set(my_argv ARGV) message(${${my_argv}} from ${name}) endfunction() endmacro() This produced the correct results. If any of you know of a cleaner way to do this, I'd love to hear about it. If not, have fun writing functions to write your functions! As a relatively useless, but I thought entertaining aside: macro(_define_function name my_argv) function(namespaced_${function_name} ...) message(${my_argv} from ${name}) endfunction() endmacro() _define_function(foo "\${ARGV}") namespaced_foo("Message") The result is "foo Message from foo" because ${my_argv} gets expand to ${ARGV}, which then expands to "foo ${ARGV}". 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 glenn.coombs at gmail.com Sun Aug 3 16:30:28 2014 From: glenn.coombs at gmail.com (Glenn Coombs) Date: Sun, 3 Aug 2014 21:30:28 +0100 Subject: [CMake] Spaces in a command In-Reply-To: <53D7FCAC.1080704@nvidia.com> References: <53D283DB.1020609@nvidia.com> <53D7E44C.1010003@nvidia.com> <53D7FCAC.1080704@nvidia.com> Message-ID: Not for me it doesn't: $ make VERBOSE=yes /usr/bin/cmake -H/home/glenn/src/cmake-test -B/home/glenn/src/cmake-test/build --check-build-system CMakeFiles/Makefile.cmake 0 /usr/bin/cmake -E cmake_progress_start /home/glenn/src/cmake-test/build/CMakeFiles /home/glenn/src/cmake-test/build/CMakeFiles/progress.marks make -f CMakeFiles/Makefile2 all make[1]: Entering directory `/home/glenn/src/cmake-test/build' make -f CMakeFiles/do-foo.dir/build.make CMakeFiles/do-foo.dir/depend make[2]: Entering directory `/home/glenn/src/cmake-test/build' cd /home/glenn/src/cmake-test/build && /usr/bin/cmake -E cmake_depends "Unix Makefiles" /home/glenn/src/cmake-test /home/glenn/src/cmake-test /home/glenn/src/cmake-test/build /home/glenn/src/cmake-test/build /home/glenn/src/cmake-test/build/CMakeFiles/do-foo.dir/DependInfo.cmake --color= make[2]: Leaving directory `/home/glenn/src/cmake-test/build' make -f CMakeFiles/do-foo.dir/build.make CMakeFiles/do-foo.dir/build make[2]: Entering directory `/home/glenn/src/cmake-test/build' /usr/bin/cmake -E cmake_progress_report /home/glenn/src/cmake-test/build/CMakeFiles 1 [100%] Generating foo generate-foo || echo \"no big deal\" make[2]: Leaving directory `/home/glenn/src/cmake-test/build' /usr/bin/cmake -E cmake_progress_report /home/glenn/src/cmake-test/build/CMakeFiles 1 [100%] Built target do-foo make[1]: Leaving directory `/home/glenn/src/cmake-test/build' /usr/bin/cmake -E cmake_progress_start /home/glenn/src/cmake-test/build/CMakeFiles 0 I'm seeing the || outside of the double quotes. This is on Kubuntu 14.10 with cmake 2.8.12.2. -- Glenn On 29 July 2014 20:57, Bill Newcomb wrote: > On linux, at least, this results in there being double quotes around the > ||, which causes it to not be interpreted by the shell. > > B. > > > On 07/29/2014 12:25 PM, Glenn Coombs wrote: > >> I think this works like you want: >> >> cmake_minimum_required(VERSION 2.6) >> >> set(DO_RELAX 1) >> if(DO_RELAX) >> set(OR_RELAX || echo \"no big deal\") >> else() >> set(OR_RELAX) >> endif() >> >> add_custom_command(OUTPUT foo COMMAND generate-foo ${OR_RELAX} VERBATIM) >> add_custom_target(do-foo ALL DEPENDS foo) >> >> >> -- >> Glenn >> >> >> On 29 July 2014 19:19, J Decker > > wrote: >> >> can try removing the quotes and subst space for semicolon? >> >> >> On Tue, Jul 29, 2014 at 11:13 AM, Bill Newcomb > > wrote: >> >> That doesn't work either: >> >> foo: >> $(CMAKE_COMMAND) -E cmake_progress_report >> /home/bnewcomb/tmp/cmake-tests/custom-or/CMakeFiles >> $(CMAKE_PROGRESS_1) >> @$(CMAKE_COMMAND) -E cmake_echo_color --switch=$(COLOR) >> --blue --bold "Generating foo" >> generate-foo "|| echo \"no big deal\"" >> >> The whole string gets passed as the first argument to >> generate-foo. >> >> B. >> >> On 07/25/2014 09:43 AM, Iosif Neitzke wrote: >> > "If VERBATIM is given then all arguments to the commands will >> be >> > escaped properly for the build tool so that the invoked command >> > receives each argument unchanged. Note that one level of >> escapes is >> > still used by the CMake language processor before >> add_custom_command >> > even sees the arguments. Use of VERBATIM is recommended as it >> enables >> > correct behavior. When VERBATIM is not given the behavior is >> platform >> > specific because there is no protection of tool-specific >> special >> > characters." >> > >> > >> http://www.cmake.org/cmake/help/v3.0/command/add_custom_ >> command.html >> > >> > On Fri, Jul 25, 2014 at 11:20 AM, Bill Newcomb >> > wrote: >> >> I want to add stuff to a custom command based on some >> definition: >> >> >> >> cmake_minimum_required(VERSION 2.6) >> >> >> >> set(DO_RELAX 1) >> >> if(DO_RELAX) >> >> set(OR_RELAX "|| echo \"no big deal\"") >> >> else() >> >> set(OR_RELAX "") >> >> endif() >> >> >> >> add_custom_command(OUTPUT foo COMMAND generate-foo >> ${OR_RELAX}) >> >> add_custom_target(do-foo ALL DEPENDS foo) >> >> >> >> >> >> However, this produces the following rule in the generated >> makefile: >> >> >> >> foo: >> >> $(CMAKE_COMMAND) -E cmake_progress_report >> /home/bnewcomb/tmp/cmake-tests/custom-or/CMakeFiles >> $(CMAKE_PROGRESS_1) >> >> @$(CMAKE_COMMAND) -E cmake_echo_color >> --switch=$(COLOR) --blue --bold "Generating foo" >> >> generate-foo ||\ echo\ "no\ big\ deal" >> >> >> >> Is there some way I can get cmake to not escape all of the >> >> spaces in the value of OR_RELAX? >> >> >> >> Thanks, >> >> B. >> >> >> >> >> ------------------------------------------------------------ >> ----------------------- >> >> This email message is for the sole use of the intended >> recipient(s) and may contain >> >> confidential information. Any unauthorized review, use, >> disclosure or distribution >> >> is prohibited. If you are not the intended recipient, >> please contact the sender by >> >> reply email and destroy all copies of the original message. >> >> >> ------------------------------------------------------------ >> ----------------------- >> >> -- >> >> >> >> 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 david at zemon.name Sun Aug 3 18:46:40 2014 From: david at zemon.name (David Zemon) Date: Sun, 03 Aug 2014 17:46:40 -0500 Subject: [CMake] Settings different flags in sub projects Message-ID: <53DEBBD0.2040604@zemon.name> Hello, For the simple case of three directories and two projects - /root, /root/p1, and /root/p2 - I would like to set some common flags for both projects and then other flags should be independent. For instance, p1 should be compiled with "-std=c99 -Os" and p2 should be compiled with "-std=c99 -O1". The first flag, -std=c99, is common to all projects and the second, -Os, might be changed from project to project. How do I do this? I thought I could create MyRulesOverride.cmake with the content: set(CMAKE_C_FLAGS_INIT "-std=c99") And that would be the end of it, but apparently not. The CMakeLists.txt files in each project have a line such as " set(CMAKE_C_FLAGS "-Os")" which is apparently overwriting the cached value from CMakeCInformation.cmake. I can't write a line like "set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -Os")" because then the result is "-std=c99 -std=c99 -Os" for the second project. Any help would be greatly appreciated. David -------------- next part -------------- An HTML attachment was scrubbed... URL: From magnus at therning.org Mon Aug 4 00:16:46 2014 From: magnus at therning.org (Magnus Therning) Date: Mon, 4 Aug 2014 06:16:46 +0200 Subject: [CMake] Settings different flags in sub projects In-Reply-To: <53DEBBD0.2040604@zemon.name> References: <53DEBBD0.2040604@zemon.name> Message-ID: <20140804041646.GB1295@tatooine.lan> On Sun, Aug 03, 2014 at 05:46:40PM -0500, David Zemon wrote: > Hello, > > For the simple case of three directories and two projects - /root, /root/p1, > and /root/p2 - I would like to set some common flags for both projects and > then other flags should be independent. For instance, p1 should be compiled > with "-std=c99 -Os" and p2 should be compiled with "-std=c99 -O1". The first > flag, -std=c99, is common to all projects and the second, -Os, might be > changed from project to project. How do I do this? > > I thought I could create MyRulesOverride.cmake with the content: > > set(CMAKE_C_FLAGS_INIT "-std=c99") > > And that would be the end of it, but apparently not. The CMakeLists.txt > files in each project have a line such as " set(CMAKE_C_FLAGS "-Os")" which > is apparently overwriting the cached value from CMakeCInformation.cmake. I > can't write a line like "set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -Os")" because > then the result is "-std=c99 -std=c99 -Os" for the second project. > > Any help would be greatly appreciated. I haven't tested this, but would you have to *add* to the flag? AFAIU setting always over writes the previous value. /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus at therning.org jabber: magnus at therning.org twitter: magthe http://therning.org/magnus The results point out the fragility of programmer expertise: advanced programmers have strong expectations about what programs should look like, and when those expectations are violated--in seemingly innocuous ways--their performance drops drastically. -- Elliot Soloway and Kate Ehrlich -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 181 bytes Desc: not available URL: From rodrigo.faccioli at gmail.com Mon Aug 4 10:26:03 2014 From: rodrigo.faccioli at gmail.com (Rodrigo Faccioli) Date: Mon, 4 Aug 2014 11:26:03 -0300 Subject: [CMake] Help cmake First project Message-ID: Hi, I'm trying to use cmake in my project. In fact, it is my first time using cmake. My CmakeList file is below. You can see it is very simple because I'm trying to compile a binary. cmake_minimum_required(VERSION 2.8) project(2pg_cartesian) set(PROJECT_VERSION "1.0") include_directories(${2pg_cartesian_SOURCE_DIR}/include) add_executable(protpred-Gromacs-NSGA2 ${2pg_cartesian_SOURCE_DIR}/src/protpred-Gromacs-NSGA2.c) install(TARGETS protpred-Gromacs-NSGA2 DESTINATION bin) When I run cmake .. I receive Build files have been written to: /home/faccioli/Downloads/2pg_cartesian/build. I understand that all is ok. faccioli at faccioli:~/Downloads/2pg_cartesian/build$ cmake .. -- The C compiler identification is GNU 4.7.2 -- The CXX compiler identification is GNU 4.7.2 -- Check for working C compiler: /usr/bin/gcc -- Check for working C compiler: /usr/bin/gcc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working CXX compiler: /usr/bin/c++ -- Check for working CXX compiler: /usr/bin/c++ -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Configuring done -- Generating done -- Build files have been written to: /home/faccioli/Downloads/2pg_cartesian/build faccioli at faccioli:~/Downloads/2pg_cartesian/build$ However, when I run make, I receive an error message as below: faccioli at faccioli:~/Downloads/2pg_cartesian/build$ make Scanning dependencies of target protpred-Gromacs-NSGA2 [100%] Building C object CMakeFiles/protpred-Gromacs-NSGA2.dir/src/protpred-Gromacs-NSGA2.c.o Linking C executable protpred-Gromacs-NSGA2 CMakeFiles/protpred-Gromacs-NSGA2.dir/src/protpred-Gromacs-NSGA2.c.o: In function `main': protpred-Gromacs-NSGA2.c:(.text+0x1e): undefined reference to `display_msg' protpred-Gromacs-NSGA2.c:(.text+0x3e): undefined reference to `load_parameters_from_file' protpred-Gromacs-NSGA2.c:(.text+0x58): undefined reference to `ea_nsga2' protpred-Gromacs-NSGA2.c:(.text+0x64): undefined reference to `fatal_error' protpred-Gromacs-NSGA2.c:(.text+0x73): undefined reference to `deAllocateload_parameters' protpred-Gromacs-NSGA2.c:(.text+0x7d): undefined reference to `display_msg' collect2: error: ld returned 1 exit status make[2]: ** [protpred-Gromacs-NSGA2] Erro 1 make[1]: ** [CMakeFiles/protpred-Gromacs-NSGA2.dir/all] Erro 2 make: ** [all] Erro 2 faccioli at faccioli:~/Downloads/2pg_cartesian/build$ Could you help me understand how can I fix this problem? I appreciate any help. Best regards, -- Rodrigo Antonio Faccioli, Ph.D Development Software for Structural Bioinformatics Barao de Maua University University of Sao Paulo Lindedin - br.linkedin.com/pub/rodrigo-antonio-faccioli/7/589/a5/ Curriculum Lattes - http://lattes.cnpq.br/1025157978990218 -------------- next part -------------- An HTML attachment was scrubbed... URL: From angeliki.chrysochou at gmail.com Mon Aug 4 10:44:44 2014 From: angeliki.chrysochou at gmail.com (Angeliki Chrysochou) Date: Mon, 4 Aug 2014 16:44:44 +0200 Subject: [CMake] Help cmake First project In-Reply-To: References: Message-ID: Hi Rodrigo, Where is the implementation of the undefined references? If it is in another source file (other than protpred-Gromacs-NSGA2.c, which seems to be the only one you are compiling) you should add it to the compilation. If it is in another library that is already compiled, you should add it as a linking dependency (using target_link_libraries). Check out http://www.cmake.org/cmake/help/cmake_tutorial.html Cheers! Angeliki On Mon, Aug 4, 2014 at 4:26 PM, Rodrigo Faccioli wrote: > Hi, > > I'm trying to use cmake in my project. In fact, it is my first time using > cmake. > > My CmakeList file is below. You can see it is very simple because I'm > trying to compile a binary. > > cmake_minimum_required(VERSION 2.8) > > project(2pg_cartesian) > set(PROJECT_VERSION "1.0") > > include_directories(${2pg_cartesian_SOURCE_DIR}/include) > > add_executable(protpred-Gromacs-NSGA2 > ${2pg_cartesian_SOURCE_DIR}/src/protpred-Gromacs-NSGA2.c) > > install(TARGETS protpred-Gromacs-NSGA2 DESTINATION bin) > > When I run cmake .. I receive Build files have been written to: > /home/faccioli/Downloads/2pg_cartesian/build. I understand that all is > ok. > > faccioli at faccioli:~/Downloads/2pg_cartesian/build$ cmake .. > -- The C compiler identification is GNU 4.7.2 > -- The CXX compiler identification is GNU 4.7.2 > -- Check for working C compiler: /usr/bin/gcc > -- Check for working C compiler: /usr/bin/gcc -- works > -- Detecting C compiler ABI info > -- Detecting C compiler ABI info - done > -- Check for working CXX compiler: /usr/bin/c++ > -- Check for working CXX compiler: /usr/bin/c++ -- works > -- Detecting CXX compiler ABI info > -- Detecting CXX compiler ABI info - done > -- Configuring done > -- Generating done > -- Build files have been written to: > /home/faccioli/Downloads/2pg_cartesian/build > faccioli at faccioli:~/Downloads/2pg_cartesian/build$ > > However, when I run make, I receive an error message as below: > > faccioli at faccioli:~/Downloads/2pg_cartesian/build$ make > Scanning dependencies of target protpred-Gromacs-NSGA2 > [100%] Building C object > CMakeFiles/protpred-Gromacs-NSGA2.dir/src/protpred-Gromacs-NSGA2.c.o > Linking C executable protpred-Gromacs-NSGA2 > CMakeFiles/protpred-Gromacs-NSGA2.dir/src/protpred-Gromacs-NSGA2.c.o: In > function `main': > protpred-Gromacs-NSGA2.c:(.text+0x1e): undefined reference to `display_msg' > protpred-Gromacs-NSGA2.c:(.text+0x3e): undefined reference to > `load_parameters_from_file' > protpred-Gromacs-NSGA2.c:(.text+0x58): undefined reference to `ea_nsga2' > protpred-Gromacs-NSGA2.c:(.text+0x64): undefined reference to `fatal_error' > protpred-Gromacs-NSGA2.c:(.text+0x73): undefined reference to > `deAllocateload_parameters' > protpred-Gromacs-NSGA2.c:(.text+0x7d): undefined reference to `display_msg' > collect2: error: ld returned 1 exit status > make[2]: ** [protpred-Gromacs-NSGA2] Erro 1 > make[1]: ** [CMakeFiles/protpred-Gromacs-NSGA2.dir/all] Erro 2 > make: ** [all] Erro 2 > faccioli at faccioli:~/Downloads/2pg_cartesian/build$ > > Could you help me understand how can I fix this problem? > > I appreciate any help. > > Best regards, > > -- > Rodrigo Antonio Faccioli, Ph.D > Development Software for Structural Bioinformatics > Barao de Maua University > University of Sao Paulo > Lindedin - br.linkedin.com/pub/rodrigo-antonio-faccioli/7/589/a5/ > Curriculum Lattes - http://lattes.cnpq.br/1025157978990218 > > -- > > 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 chuck.atkins at kitware.com Mon Aug 4 10:53:58 2014 From: chuck.atkins at kitware.com (Chuck Atkins) Date: Mon, 4 Aug 2014 10:53:58 -0400 Subject: [CMake] Help cmake First project In-Reply-To: References: Message-ID: Hi Rodrigo, It looks like you are probably missing some source files in your executable. Is protpred-Gromacs-NSGA2.c the only piece of code that gets built for the executable? If not, you'll need to make sure that all the necessary source files get either built into the executable or build as a separate library and linked into the executable. Also, you can simply your CMakeLists.txt and clean it up a bit by leaving out the ${2pg_cartesian_SOURCE_DIR} in most commands since CMake looks in the current directory of the CMakeLists.txt file by default for most of its functions: include_directories(include) add_executable(protpred-Gromacs-NSGA2 src/protpred-Gromacs-NSGA2.c) install(TARGETS protpred-Gromacs-NSGA2 DESTINATION bin) - Chuck On Mon, Aug 4, 2014 at 10:26 AM, Rodrigo Faccioli < rodrigo.faccioli at gmail.com> wrote: > Hi, > > I'm trying to use cmake in my project. In fact, it is my first time using > cmake. > > My CmakeList file is below. You can see it is very simple because I'm > trying to compile a binary. > > cmake_minimum_required(VERSION 2.8) > > project(2pg_cartesian) > set(PROJECT_VERSION "1.0") > > include_directories(${2pg_cartesian_SOURCE_DIR}/include) > > add_executable(protpred-Gromacs-NSGA2 > ${2pg_cartesian_SOURCE_DIR}/src/protpred-Gromacs-NSGA2.c) > > install(TARGETS protpred-Gromacs-NSGA2 DESTINATION bin) > > When I run cmake .. I receive Build files have been written to: > /home/faccioli/Downloads/2pg_cartesian/build. I understand that all is > ok. > > faccioli at faccioli:~/Downloads/2pg_cartesian/build$ cmake .. > -- The C compiler identification is GNU 4.7.2 > -- The CXX compiler identification is GNU 4.7.2 > -- Check for working C compiler: /usr/bin/gcc > -- Check for working C compiler: /usr/bin/gcc -- works > -- Detecting C compiler ABI info > -- Detecting C compiler ABI info - done > -- Check for working CXX compiler: /usr/bin/c++ > -- Check for working CXX compiler: /usr/bin/c++ -- works > -- Detecting CXX compiler ABI info > -- Detecting CXX compiler ABI info - done > -- Configuring done > -- Generating done > -- Build files have been written to: > /home/faccioli/Downloads/2pg_cartesian/build > faccioli at faccioli:~/Downloads/2pg_cartesian/build$ > > However, when I run make, I receive an error message as below: > > faccioli at faccioli:~/Downloads/2pg_cartesian/build$ make > Scanning dependencies of target protpred-Gromacs-NSGA2 > [100%] Building C object > CMakeFiles/protpred-Gromacs-NSGA2.dir/src/protpred-Gromacs-NSGA2.c.o > Linking C executable protpred-Gromacs-NSGA2 > CMakeFiles/protpred-Gromacs-NSGA2.dir/src/protpred-Gromacs-NSGA2.c.o: In > function `main': > protpred-Gromacs-NSGA2.c:(.text+0x1e): undefined reference to `display_msg' > protpred-Gromacs-NSGA2.c:(.text+0x3e): undefined reference to > `load_parameters_from_file' > protpred-Gromacs-NSGA2.c:(.text+0x58): undefined reference to `ea_nsga2' > protpred-Gromacs-NSGA2.c:(.text+0x64): undefined reference to `fatal_error' > protpred-Gromacs-NSGA2.c:(.text+0x73): undefined reference to > `deAllocateload_parameters' > protpred-Gromacs-NSGA2.c:(.text+0x7d): undefined reference to `display_msg' > collect2: error: ld returned 1 exit status > make[2]: ** [protpred-Gromacs-NSGA2] Erro 1 > make[1]: ** [CMakeFiles/protpred-Gromacs-NSGA2.dir/all] Erro 2 > make: ** [all] Erro 2 > faccioli at faccioli:~/Downloads/2pg_cartesian/build$ > > Could you help me understand how can I fix this problem? > > I appreciate any help. > > Best regards, > > -- > Rodrigo Antonio Faccioli, Ph.D > Development Software for Structural Bioinformatics > Barao de Maua University > University of Sao Paulo > Lindedin - br.linkedin.com/pub/rodrigo-antonio-faccioli/7/589/a5/ > Curriculum Lattes - http://lattes.cnpq.br/1025157978990218 > > -- > > 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 rodrigo.faccioli at gmail.com Mon Aug 4 11:35:11 2014 From: rodrigo.faccioli at gmail.com (Rodrigo Faccioli) Date: Mon, 4 Aug 2014 12:35:11 -0300 Subject: [CMake] Help cmake First project In-Reply-To: References: Message-ID: Thanks Chuck and Angeliki. Thanks your help. However, unfortunatelly, I couldn't fix. In [1] I show all my project. In src directory there is all .c files. In include directory there is .h files. The protpred-Gromacs-NSGA2.c is one of executable. The others are: protpred-Gromacs-Dominance.c, protpred-Gromacs-Front.c, protpred-Gromacs-MC_Metropolis.c, protpred-Gromacs-Mono.c, protpred-Gromacs-Random_Algorithm.c. All executable share the include directory. In [2] contains my Makefile that I have already used in my project. Therefore, I would like to build this make file using cmake. Furthermore, I would compile in windows too. Because of this, I have studied cmake. My doubt is how can I build CMakeList.txt. I appreciate any help. [1] https://dl.dropboxusercontent.com/u/4270818/2pg_cartesian_cmake.zip [2] https://dl.dropboxusercontent.com/u/4270818/Makefile Best regards, -- Rodrigo Antonio Faccioli, Ph.D Development Software for Structural Bioinformatics Barao de Maua University University of Sao Paulo Lindedin - br.linkedin.com/pub/rodrigo-antonio-faccioli/7/589/a5/ Curriculum Lattes - http://lattes.cnpq.br/1025157978990218 On Mon, Aug 4, 2014 at 11:53 AM, Chuck Atkins wrote: > Hi Rodrigo, > > It looks like you are probably missing some source files in your > executable. Is protpred-Gromacs-NSGA2.c the only piece of code that gets > built for the executable? If not, you'll need to make sure that all the > necessary source files get either built into the executable or build as a > separate library and linked into the executable. Also, you can simply your > CMakeLists.txt and clean it up a bit by leaving out the > ${2pg_cartesian_SOURCE_DIR} in most commands since CMake looks in the > current directory of the CMakeLists.txt file by default for most of its > functions: > > include_directories(include) > add_executable(protpred-Gromacs-NSGA2 src/protpred-Gromacs-NSGA2.c) > install(TARGETS protpred-Gromacs-NSGA2 DESTINATION bin) > > > - Chuck > > > On Mon, Aug 4, 2014 at 10:26 AM, Rodrigo Faccioli < > rodrigo.faccioli at gmail.com> wrote: > >> Hi, >> >> I'm trying to use cmake in my project. In fact, it is my first time using >> cmake. >> >> My CmakeList file is below. You can see it is very simple because I'm >> trying to compile a binary. >> >> cmake_minimum_required(VERSION 2.8) >> >> project(2pg_cartesian) >> set(PROJECT_VERSION "1.0") >> >> include_directories(${2pg_cartesian_SOURCE_DIR}/include) >> >> add_executable(protpred-Gromacs-NSGA2 >> ${2pg_cartesian_SOURCE_DIR}/src/protpred-Gromacs-NSGA2.c) >> >> install(TARGETS protpred-Gromacs-NSGA2 DESTINATION bin) >> >> When I run cmake .. I receive Build files have been written to: >> /home/faccioli/Downloads/2pg_cartesian/build. I understand that all is >> ok. >> >> faccioli at faccioli:~/Downloads/2pg_cartesian/build$ cmake .. >> -- The C compiler identification is GNU 4.7.2 >> -- The CXX compiler identification is GNU 4.7.2 >> -- Check for working C compiler: /usr/bin/gcc >> -- Check for working C compiler: /usr/bin/gcc -- works >> -- Detecting C compiler ABI info >> -- Detecting C compiler ABI info - done >> -- Check for working CXX compiler: /usr/bin/c++ >> -- Check for working CXX compiler: /usr/bin/c++ -- works >> -- Detecting CXX compiler ABI info >> -- Detecting CXX compiler ABI info - done >> -- Configuring done >> -- Generating done >> -- Build files have been written to: >> /home/faccioli/Downloads/2pg_cartesian/build >> faccioli at faccioli:~/Downloads/2pg_cartesian/build$ >> >> However, when I run make, I receive an error message as below: >> >> faccioli at faccioli:~/Downloads/2pg_cartesian/build$ make >> Scanning dependencies of target protpred-Gromacs-NSGA2 >> [100%] Building C object >> CMakeFiles/protpred-Gromacs-NSGA2.dir/src/protpred-Gromacs-NSGA2.c.o >> Linking C executable protpred-Gromacs-NSGA2 >> CMakeFiles/protpred-Gromacs-NSGA2.dir/src/protpred-Gromacs-NSGA2.c.o: In >> function `main': >> protpred-Gromacs-NSGA2.c:(.text+0x1e): undefined reference to >> `display_msg' >> protpred-Gromacs-NSGA2.c:(.text+0x3e): undefined reference to >> `load_parameters_from_file' >> protpred-Gromacs-NSGA2.c:(.text+0x58): undefined reference to `ea_nsga2' >> protpred-Gromacs-NSGA2.c:(.text+0x64): undefined reference to >> `fatal_error' >> protpred-Gromacs-NSGA2.c:(.text+0x73): undefined reference to >> `deAllocateload_parameters' >> protpred-Gromacs-NSGA2.c:(.text+0x7d): undefined reference to >> `display_msg' >> collect2: error: ld returned 1 exit status >> make[2]: ** [protpred-Gromacs-NSGA2] Erro 1 >> make[1]: ** [CMakeFiles/protpred-Gromacs-NSGA2.dir/all] Erro 2 >> make: ** [all] Erro 2 >> faccioli at faccioli:~/Downloads/2pg_cartesian/build$ >> >> Could you help me understand how can I fix this problem? >> >> I appreciate any help. >> >> Best regards, >> >> -- >> Rodrigo Antonio Faccioli, Ph.D >> Development Software for Structural Bioinformatics >> Barao de Maua University >> University of Sao Paulo >> Lindedin - br.linkedin.com/pub/rodrigo-antonio-faccioli/7/589/a5/ >> Curriculum Lattes - http://lattes.cnpq.br/1025157978990218 >> >> -- >> >> 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 Mon Aug 4 11:49:27 2014 From: angeliki.chrysochou at gmail.com (Angeliki Chrysochou) Date: Mon, 4 Aug 2014 17:49:27 +0200 Subject: [CMake] Help cmake First project In-Reply-To: References: Message-ID: Hi Rodrigo, You have to state to cmake all of your source files for compilation, otherwise they won't be found in the generated makefiles. You can do this either by writing all file names individually in add_executable, or create a variable or a list that contains all of the file names, or assign the file names to a variable using glob which is sort of like grep for cmake. Then you must provide this variable instead to add_executable. With glob it could look something like this (a "quick and dirty" solution): # get all files under directory src file(GLOB SRC_FILES "src/*.c") # set include and link directories include_directories(...) link_directories(...) # add target add_executable(protpred-Gromacs-NSGA2 ${SRC_FILES}) Since you say that only the protpred-Gromacs-NSGA2.c is part of the executable, I would personally create properly a library using the rest of the files that could form a library and an executable that links against this library. Look for the commands "add_library" and "target_link_libraries". All the best, Angeliki On Mon, Aug 4, 2014 at 5:35 PM, Rodrigo Faccioli wrote: > Thanks Chuck and Angeliki. Thanks your help. > > However, unfortunatelly, I couldn't fix. > > In [1] I show all my project. In src directory there is all .c files. In > include directory there is .h files. > > The protpred-Gromacs-NSGA2.c is one of executable. The others are: > protpred-Gromacs-Dominance.c, > protpred-Gromacs-Front.c, protpred-Gromacs-MC_Metropolis.c, protpred-Gromacs-Mono.c, protpred-Gromacs-Random_Algorithm.c. > > All executable share the include directory. > > In [2] contains my Makefile that I have already used in my project. > Therefore, I would like to build this make file using cmake. Furthermore, I > would compile in windows too. Because of this, I have studied cmake. My > doubt is how can I build CMakeList.txt. > > I appreciate any help. > > [1] https://dl.dropboxusercontent.com/u/4270818/2pg_cartesian_cmake.zip > [2] https://dl.dropboxusercontent.com/u/4270818/Makefile > > Best regards, > > > -- > Rodrigo Antonio Faccioli, Ph.D > Development Software for Structural Bioinformatics > Barao de Maua University > University of Sao Paulo > Lindedin - br.linkedin.com/pub/rodrigo-antonio-faccioli/7/589/a5/ > Curriculum Lattes - http://lattes.cnpq.br/1025157978990218 > > > On Mon, Aug 4, 2014 at 11:53 AM, Chuck Atkins > wrote: > >> Hi Rodrigo, >> >> It looks like you are probably missing some source files in your >> executable. Is protpred-Gromacs-NSGA2.c the only piece of code that gets >> built for the executable? If not, you'll need to make sure that all the >> necessary source files get either built into the executable or build as a >> separate library and linked into the executable. Also, you can simply your >> CMakeLists.txt and clean it up a bit by leaving out the >> ${2pg_cartesian_SOURCE_DIR} in most commands since CMake looks in the >> current directory of the CMakeLists.txt file by default for most of its >> functions: >> >> include_directories(include) >> add_executable(protpred-Gromacs-NSGA2 src/protpred-Gromacs-NSGA2.c) >> install(TARGETS protpred-Gromacs-NSGA2 DESTINATION bin) >> >> >> - Chuck >> >> >> On Mon, Aug 4, 2014 at 10:26 AM, Rodrigo Faccioli < >> rodrigo.faccioli at gmail.com> wrote: >> >>> Hi, >>> >>> I'm trying to use cmake in my project. In fact, it is my first time >>> using cmake. >>> >>> My CmakeList file is below. You can see it is very simple because I'm >>> trying to compile a binary. >>> >>> cmake_minimum_required(VERSION 2.8) >>> >>> project(2pg_cartesian) >>> set(PROJECT_VERSION "1.0") >>> >>> include_directories(${2pg_cartesian_SOURCE_DIR}/include) >>> >>> add_executable(protpred-Gromacs-NSGA2 >>> ${2pg_cartesian_SOURCE_DIR}/src/protpred-Gromacs-NSGA2.c) >>> >>> install(TARGETS protpred-Gromacs-NSGA2 DESTINATION bin) >>> >>> When I run cmake .. I receive Build files have been written to: >>> /home/faccioli/Downloads/2pg_cartesian/build. I understand that all is >>> ok. >>> >>> faccioli at faccioli:~/Downloads/2pg_cartesian/build$ cmake .. >>> -- The C compiler identification is GNU 4.7.2 >>> -- The CXX compiler identification is GNU 4.7.2 >>> -- Check for working C compiler: /usr/bin/gcc >>> -- Check for working C compiler: /usr/bin/gcc -- works >>> -- Detecting C compiler ABI info >>> -- Detecting C compiler ABI info - done >>> -- Check for working CXX compiler: /usr/bin/c++ >>> -- Check for working CXX compiler: /usr/bin/c++ -- works >>> -- Detecting CXX compiler ABI info >>> -- Detecting CXX compiler ABI info - done >>> -- Configuring done >>> -- Generating done >>> -- Build files have been written to: >>> /home/faccioli/Downloads/2pg_cartesian/build >>> faccioli at faccioli:~/Downloads/2pg_cartesian/build$ >>> >>> However, when I run make, I receive an error message as below: >>> >>> faccioli at faccioli:~/Downloads/2pg_cartesian/build$ make >>> Scanning dependencies of target protpred-Gromacs-NSGA2 >>> [100%] Building C object >>> CMakeFiles/protpred-Gromacs-NSGA2.dir/src/protpred-Gromacs-NSGA2.c.o >>> Linking C executable protpred-Gromacs-NSGA2 >>> CMakeFiles/protpred-Gromacs-NSGA2.dir/src/protpred-Gromacs-NSGA2.c.o: In >>> function `main': >>> protpred-Gromacs-NSGA2.c:(.text+0x1e): undefined reference to >>> `display_msg' >>> protpred-Gromacs-NSGA2.c:(.text+0x3e): undefined reference to >>> `load_parameters_from_file' >>> protpred-Gromacs-NSGA2.c:(.text+0x58): undefined reference to `ea_nsga2' >>> protpred-Gromacs-NSGA2.c:(.text+0x64): undefined reference to >>> `fatal_error' >>> protpred-Gromacs-NSGA2.c:(.text+0x73): undefined reference to >>> `deAllocateload_parameters' >>> protpred-Gromacs-NSGA2.c:(.text+0x7d): undefined reference to >>> `display_msg' >>> collect2: error: ld returned 1 exit status >>> make[2]: ** [protpred-Gromacs-NSGA2] Erro 1 >>> make[1]: ** [CMakeFiles/protpred-Gromacs-NSGA2.dir/all] Erro 2 >>> make: ** [all] Erro 2 >>> faccioli at faccioli:~/Downloads/2pg_cartesian/build$ >>> >>> Could you help me understand how can I fix this problem? >>> >>> I appreciate any help. >>> >>> Best regards, >>> >>> -- >>> Rodrigo Antonio Faccioli, Ph.D >>> Development Software for Structural Bioinformatics >>> Barao de Maua University >>> University of Sao Paulo >>> Lindedin - br.linkedin.com/pub/rodrigo-antonio-faccioli/7/589/a5/ >>> Curriculum Lattes - http://lattes.cnpq.br/1025157978990218 >>> >>> -- >>> >>> 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 bill.hoffman at kitware.com Mon Aug 4 11:54:57 2014 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Mon, 04 Aug 2014 11:54:57 -0400 Subject: [CMake] Help cmake First project In-Reply-To: References: Message-ID: <53DFACD1.6050807@kitware.com> On 8/4/2014 10:26 AM, Rodrigo Faccioli wrote: > protpred-Gromacs-NSGA2.c:(.text+0x1e): undefined reference to `display_msg' > protpred-Gromacs-NSGA2.c:(.text+0x3e): undefined reference to > `load_parameters_from_file' > protpred-Gromacs-NSGA2.c:(.text+0x58): undefined reference to `ea_nsga2' > protpred-Gromacs-NSGA2.c:(.text+0x64): undefined reference to `fatal_error' > protpred-Gromacs-NSGA2.c:(.text+0x73): undefined reference to > `deAllocateload_parameters' > protpred-Gromacs-NSGA2.c:(.text+0x7d): undefined reference to `display_msg' You have to find out where these symbols are defined. If you have a working Makefile version use nm and grep to find the places. You can also grep your source tree. You are either missing a source file, or a -D option. Another approach is to run make VERBOSE=1 and compare the build command lines to your Makefile build. -Bill From hobbes1069 at gmail.com Mon Aug 4 15:54:37 2014 From: hobbes1069 at gmail.com (Richard Shaw) Date: Mon, 4 Aug 2014 14:54:37 -0500 Subject: [CMake] CPack patch version getting set erroneously... Message-ID: I converted a project from autotools/handmade makefiles to cmake and afterwards I added NSIS packaging for win32 builds via the cpack integration. Everything was fine while the version patch level was being used, but upon the next release "0.97" w/o a patch level the resultant installer has the show "0.97.1". Here's the logic I use: set(CPACK_PACKAGE_VERSION_MAJOR ${FREEDV_VERSION_MAJOR}) set(CPACK_PACKAGE_VERSION_MINOR ${FREEDV_VERSION_MINOR}) if(FREEDV_VERSION_PATCH) set(CPACK_PACKAGE_VERSION_PATCH ${FREEDV_VERSION_PATCH}) endif(FREEDV_VERSION_PATCH) Although I have also tried "unset(..." to get it to stop but nothing seems to work. The resultant file always ends up with at "1" in the patch level. Thanks, Richard -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicolasbock at gmail.com Mon Aug 4 17:00:21 2014 From: nicolasbock at gmail.com (Nicolas Bock) Date: Mon, 4 Aug 2014 15:00:21 -0600 Subject: [CMake] Fwd: set_target_properties and language specific COMPILE_FLAGS In-Reply-To: References: Message-ID: Hi Chuck, seems a bit hackish, but works for me :) Thanks for the trick! nick On Fri, Aug 1, 2014 at 12:37 PM, Chuck Atkins wrote: > Hi Nick, > > You could split your target in to two object libraries that combine into a > singe "real" library: > > add_library(foo_f OBJECT ${FOO_F_SOURCES}) > # set necessary compile flags specific to the Fortran components > # on the foo_f target > > add_library(foo_c OBJECT ${FOO_C_SOURCES}) > # set necessary compile flags specific to the C components > # on the foo_c target > > # Combine into a "real" library > add_library(foo $ $) > > See http://www.cmake.org/Wiki/CMake/Tutorials/Object_Library > > - Chuck > > > On Fri, Aug 1, 2014 at 12:54 PM, Nicolas Bock wrote: >> >> Hi, >> >> I am building a library containing Fortran and C sources. I would like >> to add language specific compile flags without affecting the global >> compile flags: >> >> set_target_properties( foo PROPERTIES C_FLAGS "-fopenmp" Fortran_FLAGS >> "-openmp" ) >> >> However, it seems there is only COMPILE_FLAGS which presumably affects >> both languages. >> >> Thanks already, >> >> nick >> -- >> >> 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 nicolasbock at gmail.com Mon Aug 4 17:35:05 2014 From: nicolasbock at gmail.com (Nicolas Bock) Date: Mon, 4 Aug 2014 15:35:05 -0600 Subject: [CMake] Fwd: set_target_properties and language specific COMPILE_FLAGS In-Reply-To: References: Message-ID: Hi Chuck, I am building both static and shared libraries using the object files. After splitting the Fortran and C source as you suggest, I get the following linker error: /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/../../../../x86_64-pc-linux-gnu/bin/ld: CMakeFiles/spammpack-serial-C.dir/spamm_get_time.c.o: relocation R_X86_64_32 against `.rodata' can not be used when making a shared object; recompile with -fPIC Unfortunately I can't reproduce this error with a smaller test. Should I pass some additional compiler flags into the OBJECT convenience library, such as -fPIC as is suggested by the linker? How portable would that be? Thanks already, nick On Fri, Aug 1, 2014 at 12:37 PM, Chuck Atkins wrote: > Hi Nick, > > You could split your target in to two object libraries that combine into a > singe "real" library: > > add_library(foo_f OBJECT ${FOO_F_SOURCES}) > # set necessary compile flags specific to the Fortran components > # on the foo_f target > > add_library(foo_c OBJECT ${FOO_C_SOURCES}) > # set necessary compile flags specific to the C components > # on the foo_c target > > # Combine into a "real" library > add_library(foo $ $) > > See http://www.cmake.org/Wiki/CMake/Tutorials/Object_Library > > - Chuck > > > On Fri, Aug 1, 2014 at 12:54 PM, Nicolas Bock wrote: >> >> Hi, >> >> I am building a library containing Fortran and C sources. I would like >> to add language specific compile flags without affecting the global >> compile flags: >> >> set_target_properties( foo PROPERTIES C_FLAGS "-fopenmp" Fortran_FLAGS >> "-openmp" ) >> >> However, it seems there is only COMPILE_FLAGS which presumably affects >> both languages. >> >> Thanks already, >> >> nick >> -- >> >> 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 nicolasbock at gmail.com Mon Aug 4 17:58:32 2014 From: nicolasbock at gmail.com (Nicolas Bock) Date: Mon, 4 Aug 2014 15:58:32 -0600 Subject: [CMake] Fwd: set_target_properties and language specific COMPILE_FLAGS In-Reply-To: References: Message-ID: The solution is to add the POSITION_INDENPENDENT_CODE target property to the C and Fortran convenience library targets. Thanks again for the help, nick On Mon, Aug 4, 2014 at 3:35 PM, Nicolas Bock wrote: > Hi Chuck, > > I am building both static and shared libraries using the object files. > After splitting the Fortran and C source as you suggest, I get the > following linker error: > > /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/../../../../x86_64-pc-linux-gnu/bin/ld: > CMakeFiles/spammpack-serial-C.dir/spamm_get_time.c.o: relocation > R_X86_64_32 against `.rodata' can not be used when making a shared > object; recompile with -fPIC > > Unfortunately I can't reproduce this error with a smaller test. Should > I pass some additional compiler flags into the OBJECT convenience > library, such as -fPIC as is suggested by the linker? How portable > would that be? > > Thanks already, > > nick > > On Fri, Aug 1, 2014 at 12:37 PM, Chuck Atkins wrote: >> Hi Nick, >> >> You could split your target in to two object libraries that combine into a >> singe "real" library: >> >> add_library(foo_f OBJECT ${FOO_F_SOURCES}) >> # set necessary compile flags specific to the Fortran components >> # on the foo_f target >> >> add_library(foo_c OBJECT ${FOO_C_SOURCES}) >> # set necessary compile flags specific to the C components >> # on the foo_c target >> >> # Combine into a "real" library >> add_library(foo $ $) >> >> See http://www.cmake.org/Wiki/CMake/Tutorials/Object_Library >> >> - Chuck >> >> >> On Fri, Aug 1, 2014 at 12:54 PM, Nicolas Bock wrote: >>> >>> Hi, >>> >>> I am building a library containing Fortran and C sources. I would like >>> to add language specific compile flags without affecting the global >>> compile flags: >>> >>> set_target_properties( foo PROPERTIES C_FLAGS "-fopenmp" Fortran_FLAGS >>> "-openmp" ) >>> >>> However, it seems there is only COMPILE_FLAGS which presumably affects >>> both languages. >>> >>> Thanks already, >>> >>> nick >>> -- >>> >>> 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 glenn.coombs at gmail.com Mon Aug 4 18:09:49 2014 From: glenn.coombs at gmail.com (Glenn Coombs) Date: Mon, 4 Aug 2014 23:09:49 +0100 Subject: [CMake] Settings different flags in sub projects In-Reply-To: <53DEBBD0.2040604@zemon.name> References: <53DEBBD0.2040604@zemon.name> Message-ID: Something like this should work: add_compile_options(-std=c99) set_property(DIRECTORY "/root/p1" PROPERTY COMPILE_OPTIONS "-Os") set_property(DIRECTORY "/root/p2" PROPERTY COMPILE_OPTIONS "-O1") or you just use the add_compile_options command in all 3 CMakeLists.txt files. The CMakeLists.txt files in root/p1 and root/p2 will inherit the compile options set in the parent root/CMakeLists.txt file. -- Glenn On 3 August 2014 23:46, David Zemon wrote: > Hello, > > For the simple case of three directories and two projects - /root, > /root/p1, and /root/p2 - I would like to set some common flags for both > projects and then other flags should be independent. For instance, p1 > should be compiled with "-std=c99 -Os" and p2 should be compiled with "-std=c99 > -O1". The first flag, -std=c99, is common to all projects and the second, > -Os, might be changed from project to project. How do I do this? > > I thought I could create MyRulesOverride.cmake with the content: > > set(CMAKE_C_FLAGS_INIT "-std=c99") > > And that would be the end of it, but apparently not. The CMakeLists.txt > files in each project have a line such as " set(CMAKE_C_FLAGS "-Os")" > which is apparently overwriting the cached value from > CMakeCInformation.cmake. I can't write a line like "set(CMAKE_C_FLAGS > "${CMAKE_C_FLAGS} -Os")" because then the result is "-std=c99 -std=c99 -Os" > for the second project. > > Any help would be greatly appreciated. > > David > > -- > > 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 chrysalisx at gmail.com Mon Aug 4 18:54:00 2014 From: chrysalisx at gmail.com (Walter Gray) Date: Mon, 04 Aug 2014 15:54:00 -0700 Subject: [CMake] Possible bug install(EXPORT ...) and 'DIRECTORY .' & questions regarding Config file authoring Message-ID: <53E00F08.7030705@gmail.com> I've been trying to figure out how to correctly author install steps for a library that will generate a self-contained folder that can be distributed and used by others, including a good Config.cmake file and I ran into what seems like a bug. If you say install(EXPORT DESTINATION .) Then the resulting file will, when generating the _IMPORT_PREFIX will produce the following: get_filename_component(_IMPORT_PREFIX "${CMAKE_CURRENT_LIST_FILE}" PATH) get_filename_component(_IMPORT_PREFIX "${_IMPORT_PREFIX}" PATH) Which for an install directory of C:\libraries\mypackage will produce an import prefix of C:\libraries. I can work around this for now by installing to the cmake subdirectory, but I thought someone should be aware of this. Is this a known issue? Also, what are the expected best practices regarding the authoring of good Config.cmake files? The tutorial on http://www.cmake.org/cmake/help/git-master/manual/cmake-packages.7.html#creating-packages is somewhat lacking. For example, while it mentions that cmake does not provide a way to register installed packages with the package registry, it does say you can do this yourself. Is that the recommended thing to do? If so, how? providing a .bat or .sh file in your distributed folder's root that sets that up? From david at zemon.name Mon Aug 4 19:10:38 2014 From: david at zemon.name (David Zemon) Date: Mon, 04 Aug 2014 18:10:38 -0500 Subject: [CMake] Settings different flags in sub projects In-Reply-To: References: <53DEBBD0.2040604@zemon.name> Message-ID: <53E012EE.2050907@zemon.name> Glenn, thanks for the tip. Those two options are new to me. It's not very clear to me how the add_compile_options function works. Complexity might be added when I mention that I've also defined 4 new custom languages (all essentially identical to C). When add_compile_options is executed, will it add the flags to all languages (that would be desirable in my case)? What about assembly (that would be undesirable but I don't think detrimental)? If I use the "header guard" concept, could I just tack that add_compile_options line onto my ToolChain file? That would save trouble for users of my library so that they don't have to define all the basics in every one of their projects. Can I assume that set_property(DIRECTORY "..." PROPERTY COMPILE_OPTIONS "...") affects the same variables as add_compile_options? Thank you, David On 08/04/2014 05:09 PM, Glenn Coombs wrote: > Something like this should work: > > add_compile_options(-std=c99) > > set_property(DIRECTORY "/root/p1" PROPERTY COMPILE_OPTIONS "-Os") > set_property(DIRECTORY "/root/p2" PROPERTY COMPILE_OPTIONS "-O1") > > > or you just use the add_compile_options command in all 3 CMakeLists.txt files. The CMakeLists.txt files in root/p1 and root/p2 will inherit the compile options set in the parent root/CMakeLists.txt file. > > > -- > Glenn > > > On 3 August 2014 23:46, David Zemon > wrote: > > Hello, > > For the simple case of three directories and two projects - /root, > /root/p1, and /root/p2 - I would like to set some common flags for > both projects and then other flags should be independent. For > instance, p1 should be compiled with "-std=c99 -Os" and p2 should > be compiled with "-std=c99 -O1". The first flag, -std=c99, is > common to all projects and the second, -Os, might be changed from > project to project. How do I do this? > > I thought I could create MyRulesOverride.cmake with the content: > > set(CMAKE_C_FLAGS_INIT "-std=c99") > > And that would be the end of it, but apparently not. The > CMakeLists.txt files in each project have a line such as " > set(CMAKE_C_FLAGS "-Os")" which is apparently overwriting the > cached value from CMakeCInformation.cmake. I can't write a line > like "set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -Os")" because then the > result is "-std=c99 -std=c99 -Os" for the second project. > > Any help would be greatly appreciated. > > David > > -- > > 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 david at zemon.name Mon Aug 4 19:48:13 2014 From: david at zemon.name (David Zemon) Date: Mon, 04 Aug 2014 18:48:13 -0500 Subject: [CMake] Settings different flags in sub projects In-Reply-To: References: <53DEBBD0.2040604@zemon.name> Message-ID: <53E01BBD.5020709@zemon.name> Poking around some more I think I may have found a better solution. # Toolchain file include(FileWithInitFlags.cmake) set(CMAKE_C_COMPILE_OBJECT " ${CMAKE_C_FLAGS_INIT} -o -c ") And for the custom languages I can add that to CMakeInformation.cmake. I'm not sure why I didn't think of this earlier - I think just sparking off Glenn or getting some sleep helped :P Cheers, David On 08/04/2014 05:09 PM, Glenn Coombs wrote: > Something like this should work: > > add_compile_options(-std=c99) > > set_property(DIRECTORY "/root/p1" PROPERTY COMPILE_OPTIONS "-Os") > set_property(DIRECTORY "/root/p2" PROPERTY COMPILE_OPTIONS "-O1") > > > or you just use the add_compile_options command in all 3 CMakeLists.txt files. The CMakeLists.txt files in root/p1 and root/p2 will inherit the compile options set in the parent root/CMakeLists.txt file. > > > -- > Glenn > > > On 3 August 2014 23:46, David Zemon > wrote: > > Hello, > > For the simple case of three directories and two projects - /root, > /root/p1, and /root/p2 - I would like to set some common flags for > both projects and then other flags should be independent. For > instance, p1 should be compiled with "-std=c99 -Os" and p2 should > be compiled with "-std=c99 -O1". The first flag, -std=c99, is > common to all projects and the second, -Os, might be changed from > project to project. How do I do this? > > I thought I could create MyRulesOverride.cmake with the content: > > set(CMAKE_C_FLAGS_INIT "-std=c99") > > And that would be the end of it, but apparently not. The > CMakeLists.txt files in each project have a line such as " > set(CMAKE_C_FLAGS "-Os")" which is apparently overwriting the > cached value from CMakeCInformation.cmake. I can't write a line > like "set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -Os")" because then the > result is "-std=c99 -std=c99 -Os" for the second project. > > Any help would be greatly appreciated. > > David > > -- > > 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 leif.walsh at gmail.com Mon Aug 4 23:30:43 2014 From: leif.walsh at gmail.com (Leif Walsh) Date: Mon, 4 Aug 2014 23:30:43 -0400 Subject: [CMake] cmake version/feature detection Message-ID: Hi, I'm wondering what is the best way to do feature detection or version checking of cmake itself, in cmake. In particular, I'd like to check for the OBJECT library feature and either use it or fall back to our current mechanism if we're using an older cmake. -- Cheers, Leif -------------- next part -------------- An HTML attachment was scrubbed... URL: From nagymatef at freemail.hu Tue Aug 5 07:30:57 2014 From: nagymatef at freemail.hu (=?utf-8?B?TmFneS1FZ3JpIE3DoXTDqSBGZXJlbmM=?=) Date: Tue, 5 Aug 2014 11:30:57 +0000 Subject: [CMake] =?utf-8?q?CMake_3=2E0_and_Visual_Studio_2013_peculiaritie?= =?utf-8?q?s?= Message-ID: Hi! I have been using CMake for quite some time now, but there are a few things I don?t understand or I just don?t know how to accomplish. 1) Some time ago I posted about Unicode paths inside generated project files do not work properly. The issue has been fixed. Though this issue is only a cosmetic one, when I genetate anything with CMake under such a path I see -- Build files have been written to: C:/Users/M?t?Ferenc/OneDrive/Develop/Active/GridRipper/VS2013 in the command line, where the actual path should contain ?M?t?Ferenc?. I don?t know if the displayed string internally is stored this way, or the encoding gets messed at the very last moment when printed to the console. Inspecting which is the case might uncover some bugs. 2) For some reason Visual Studio does not find certain files it should. This might not even be a CMake bug, but related to Visual Studio, although there might be someone on the list that knows the solution to the problem. #include <> paths are set up by CMake seemingly correctly by using absolute paths. I have set (CMAKE_USE_RELATIVE_PATHS ?true?) option set, and inside my projects I have statements such as include_directories (${PROJECT_SOURCE_DIR}/inc/) include_directories (${Gripper_ADDITIONAL_INCLUDE_DIRS}) at other places I use include_directories ("${PROJECT_SOURCE_DIR}/inc/") include_directories (${Gripper_ADDITIONAL_INCLUDE_DIRS}) Both seem to work (though I would be curious which is the better one), even the generated project file seems right, in which I can see parts that read C:\GridRipper\tests\STL-Test4-Plotter\inc;C:\GridRipper\Gripper\inc;C:\Kellekek\GSL\include;%(AdditionalIncludeDirectories) So indeed my project correctly sets it?s own include dir and that of the libraries that it will link (plus GSL as a dependancy. The application compiles fine, intellisense parses the files properly, however when I right click inside the IDE, and say Open File, it brings up a dialog saying it cannot find the file. It lists all the directories it is looking inside, and none of the AdditionalIncludeDirectories entries are among the paths it is trying to find the file. Why is this? Is this a bug in CMake or VS messes up something? 3) How can I create a makefile that forces a certain platform toolset to be used? I have seen in a Makefile of another project that set(CMAKE_GENERATOR_TOOLSET "CTP_Nov2013" CACHE STRING "Platform Toolset" FORCE) set(CMAKE_VS_PLATFORM_TOOLSET "CTP_Nov2013" CACHE STRING "Platform Toolset" FORCE) should do the trick, however for the initial makefile/project generation, this does not work. I issue the command cmake -G"Visual Studio 12 2013 Win64" -DBUILD_EXAMPLES:BOOL=ON -DBUILD_TESTS:BOOL=ON ..\ but all projects use the regular vs120 platform toolset. If I immediately issue cmake ..\ after this, then everything will go as expected. What is the canonical way of obtaining a 64-bit project file with a given toolset without having to do multipass generation? My project uses automatic return type deduction, thus I need the CTP_Nov2013 toolset, otherwise my app won?t compile. Thanks in advance, M?t? -------------- next part -------------- An HTML attachment was scrubbed... URL: From mrestelli at gmail.com Tue Aug 5 10:29:14 2014 From: mrestelli at gmail.com (marco restelli) Date: Tue, 5 Aug 2014 16:29:14 +0200 Subject: [CMake] Resetting CMAKE_Fortran_FLAGS for a specific file Message-ID: Hi, I would like to reset CMAKE_Fortran_FLAGS for one specific file in a project. I have tried SET_SOURCE_FILES_PROPERTIES(my_file.f90 PROPERTIES COMPILE_FLAGS "-O0 -g") but it appends the new flags keeping the old ones. How can reset these flags? Specifically, I have some files for which I need to avoid any error checking and any optimization, independently from the selected compiler. Thanks, regards, Marco From rodrigo.faccioli at gmail.com Tue Aug 5 11:08:28 2014 From: rodrigo.faccioli at gmail.com (Rodrigo Faccioli) Date: Tue, 5 Aug 2014 12:08:28 -0300 Subject: [CMake] Help cmake First project In-Reply-To: <53DFACD1.6050807@kitware.com> References: <53DFACD1.6050807@kitware.com> Message-ID: Hi, Thanks Angeliki and Bill for your attentation. I have updated my CMakeList.txt based on your post. Below my CMakeList.txt is showed. cmake_minimum_required(VERSION 2.8) # project Information project(2pg_cartesian) set(PROJECT_VERSION "1.0") # add definitions to compiler add_definitions(-std=c99) # get all files under directory src file(GLOB SRC_FILES "src/*.c") # set include include_directories(include) # added libries add_library(ALL STATIC ${SRC_FILES}) # add target add_executable(protpred-Gromacs-NSGA2 src/protpred-Gromacs-NSGA2.c) target_link_libraries(protpred-Gromacs-NSGA2 ALL) Unfortunatelly, I have received error messages as cited below: faccioli at faccioli:~/Downloads/2pg_cartesian/build$ make Scanning dependencies of target ALL [ 2%] Building C object CMakeFiles/ALL.dir/src/protpred-Gromacs-NSGA2.c.o [ 5%] Building C object CMakeFiles/ALL.dir/src/ea_mono.c.o [ 7%] Building C object CMakeFiles/ALL.dir/src/topologyio.c.o [ 10%] Building C object CMakeFiles/ALL.dir/src/aminoacids.c.o [ 12%] Building C object CMakeFiles/ALL.dir/src/populationio.c.o [ 15%] Building C object CMakeFiles/ALL.dir/src/osutil.c.o [ 17%] Building C object CMakeFiles/ALL.dir/src/aminoacids_io.c.o [ 20%] Building C object CMakeFiles/ALL.dir/src/protpred-Gromacs-Sort_Method_Files_by_Front_Dominance.c.o [ 23%] Building C object CMakeFiles/ALL.dir/src/pdbio.c.o [ 25%] Building C object CMakeFiles/ALL.dir/src/solution.c.o [ 28%] Building C object CMakeFiles/ALL.dir/src/vector_math.c.o [ 30%] Building C object CMakeFiles/ALL.dir/src/math_owner.c.o [ 33%] Building C object CMakeFiles/ALL.dir/src/protein.c.o [ 35%] Building C object CMakeFiles/ALL.dir/src/load_parameters.c.o In file included from /home/faccioli/Downloads/2pg_cartesian/src/load_parameters.c:7:0: /home/faccioli/Downloads/2pg_cartesian/include/LoadConfig.h:1:18: fatal error: string: Arquivo ou diret?rio n?o encontrado compilation terminated. make[2]: ** [CMakeFiles/ALL.dir/src/load_parameters.c.o] Erro 1 make[1]: ** [CMakeFiles/ALL.dir/all] Erro 2 make: ** [all] Erro 2 faccioli at faccioli:~/Downloads/2pg_cartesian/build$ I did not understand what mistakes I have done since all files share same structure of directory. In [1] is my project completly. If prefer I can send its github repository. I appreciate any help. Best regards, [1] https://dl.dropboxusercontent.com/u/4270818/2pg_cartesian_cmake.zip -- Rodrigo Antonio Faccioli, Ph.D Development Software for Structural Bioinformatics Barao de Maua University University of Sao Paulo Lindedin - br.linkedin.com/pub/rodrigo-antonio-faccioli/7/589/a5/ Curriculum Lattes - http://lattes.cnpq.br/1025157978990218 On Mon, Aug 4, 2014 at 12:54 PM, Bill Hoffman wrote: > On 8/4/2014 10:26 AM, Rodrigo Faccioli wrote: > >> protpred-Gromacs-NSGA2.c:(.text+0x1e): undefined reference to >> `display_msg' >> protpred-Gromacs-NSGA2.c:(.text+0x3e): undefined reference to >> `load_parameters_from_file' >> protpred-Gromacs-NSGA2.c:(.text+0x58): undefined reference to `ea_nsga2' >> protpred-Gromacs-NSGA2.c:(.text+0x64): undefined reference to >> `fatal_error' >> protpred-Gromacs-NSGA2.c:(.text+0x73): undefined reference to >> `deAllocateload_parameters' >> protpred-Gromacs-NSGA2.c:(.text+0x7d): undefined reference to >> `display_msg' >> > You have to find out where these symbols are defined. If you have a > working Makefile version use nm and grep to find the places. You can also > grep your source tree. You are either missing a source file, or a -D > option. > > Another approach is to run make VERBOSE=1 and compare the build command > lines to your Makefile build. > > -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 clinton at elemtech.com Tue Aug 5 11:28:54 2014 From: clinton at elemtech.com (Clinton Stimpson) Date: Tue, 05 Aug 2014 09:28:54 -0600 Subject: [CMake] CMake 3.0 and Visual Studio 2013 peculiarities In-Reply-To: References: Message-ID: <1463155.2k1XkOMhif@stryke> On Tuesday, August 05, 2014 11:30:57 AM Nagy-Egri M?t? Ferenc wrote: > Hi! > > > > > I have been using CMake for quite some time now, but there are a few things > I don?t understand or I just don?t know how to accomplish. > > 1) Some time ago I posted about Unicode paths inside generated project files > do not work properly. The issue has been fixed. Though this issue is only a > cosmetic one, when I genetate anything with CMake under such a path I see > > -- Build files have been written to: > C:/Users/M?t?Ferenc/OneDrive/Develop/Active/GridRipper/VS2013 > > in the command line, where the actual path should contain ?M?t?Ferenc?. I > don?t know if the displayed string internally is stored this way, or the > encoding gets messed at the very last moment when printed to the console. > Inspecting which is the case might uncover some bugs. Its messed up when printed to the console. CMake is using the ANSI code page, but your console is using the OEM code page. If you look at the two tables for your ANSI and OEM code pages, you'll see that ? on the ANSI code page is the same as ? on the OEM code page. So, when CMake prints the ? character, the console displays the ? character. There is a chcp command you can use to change your console code page to your ANSI code page to fix the display. - Clint From david at zemon.name Tue Aug 5 13:56:25 2014 From: david at zemon.name (david at zemon.name) Date: Tue, 5 Aug 2014 12:56:25 -0500 (CDT) Subject: [CMake] Windows Path Issues Message-ID: <1407261385.111226741@webmail.emailpower.biz> I'm generally a Linux guy but need this project to work on all three main platforms. I have my toolchain file working nicely in Linux, but for some reason I'm getting an error on Windows. Here's top of the console output: bash-3.1$ cmake -G "Unix Makefiles" . -- The C compiler identification is GNU 4.6.1 -- The CXX compiler identification is GNU 4.6.1 -- The COGCXX compiler identification is GNU 4.6.1 -- The ECOGC compiler identification is GNU 4.6.1 -- The ECOGCXX compiler identification is GNU 4.6.1 -- The ASM compiler identification is GNU -- Found assembler: C:/software/propgcc/bin/propeller-elf-gcc CMake Error at CMakeLists.txt:6 (project): The CMAKE_C_COMPILER: C:/software/propgcc/bin/propeller-elf-gcc is not a full path to an existing compiler tool. Tell CMake where to find the compiler by setting either the environment variable "CC" or the CMake cache entry CMAKE_C_COMPILER to the full path to the compiler, or to the compiler name if it is in the PATH. This doesn't make too much sense to me. Anyone know why it would find the compiler at first and then loose it? The path that it lists is perfectly valid. Thanks, David -------------- next part -------------- An HTML attachment was scrubbed... URL: From abhrasko at gmail.com Tue Aug 5 15:21:01 2014 From: abhrasko at gmail.com (Ivan Hrasko) Date: Tue, 5 Aug 2014 21:21:01 +0200 Subject: [CMake] Windows Path Issues Message-ID: 1. What your environment exactly is? It does not look like Windows only (because I see in your log: bash-3.1$ cmake -G "Unix Makefiles" . ), so I expect you are using something like Cygwin and when you use this kind of environment you can have problems with paths. For example C:/software/propgcc/bin/propeller-elf-gcc is not a valid path for Cygwin, because cygwin uses /cygdrive/ in its path for things which are located in Windows. 2. When I use cmake on Windows (just Windows, cmd, not Cygwin or else) I use "MinGW Makefiles" not "Unix Makefiles" with GNU compilers. -------------- next part -------------- An HTML attachment was scrubbed... URL: From abhrasko at gmail.com Tue Aug 5 15:26:18 2014 From: abhrasko at gmail.com (Ivan Hrasko) Date: Tue, 5 Aug 2014 21:26:18 +0200 Subject: [CMake] Windows Path Issues In-Reply-To: <1407261385.111226741@webmail.emailpower.biz> References: <1407261385.111226741@webmail.emailpower.biz> Message-ID: 1. What your environment exactly is? It does not look like Windows only (because I see in your log: bash-3.1$ cmake -G "Unix Makefiles" . ), so I expect you are using something like Cygwin and when you use this kind of environment you can have problems with paths. For example C:/software/propgcc/bin/propeller-elf-gcc is not a valid path for Cygwin, because cygwin uses /cygdrive/ in its path for things which are located in Windows. 2. When I use cmake on Windows (just Windows, cmd, not Cygwin or else) I use "MinGW Makefiles" not "Unix Makefiles" with GNU compilers. 2014-08-05 19:56 GMT+02:00 : > I'm generally a Linux guy but need this project to work on all three main > platforms. > > > > I have my toolchain file working nicely in Linux, but for some reason I'm > getting an error on Windows. Here's top of the console output: > > > > bash-3.1$ cmake -G "Unix Makefiles" . > -- The C compiler identification is GNU 4.6.1 > -- The CXX compiler identification is GNU 4.6.1 > -- The COGCXX compiler identification is GNU 4.6.1 > -- The ECOGC compiler identification is GNU 4.6.1 > -- The ECOGCXX compiler identification is GNU 4.6.1 > -- The ASM compiler identification is GNU > -- Found assembler: C:/software/propgcc/bin/propeller-elf-gcc > CMake Error at CMakeLists.txt:6 (project): > The CMAKE_C_COMPILER: > > > > C:/software/propgcc/bin/propeller-elf-gcc > > > > is not a full path to an existing compiler tool. > > > > Tell CMake where to find the compiler by setting either the environment > variable "CC" or the CMake cache entry CMAKE_C_COMPILER to the full path > to > the compiler, or to the compiler name if it is in the PATH. > > > > This doesn't make too much sense to me. Anyone know why it would find the > compiler at first and then loose it? The path that it lists is perfectly > valid. > > > > Thanks, > > David > > -- > > 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 > -- Ivan Hrasko -------------- next part -------------- An HTML attachment was scrubbed... URL: From abhrasko at gmail.com Tue Aug 5 15:57:45 2014 From: abhrasko at gmail.com (Ivan Hrasko) Date: Tue, 5 Aug 2014 21:57:45 +0200 Subject: [CMake] I have discovered a bug (probably) Message-ID: 1. This is the code CMAKE_MINIMUM_REQUIRED(VERSION 2.8.10 FATAL_ERROR) PROJECT(CMake_Version_Tutorial C CXX Fortran) if(DEFINED CMAKE_C_COMPILER_VERSION) message(STATUS "C version is defined.") else() message(STATUS "C version is not defined.") endif() if(DEFINED CMAKE_CXX_COMPILER_VERSION) message(STATUS "C++ version is defined.") else() message(STATUS "C++ version is not defined.") endif() if(DEFINED CMAKE_Fortran_COMPILER_VERSION) message(STATUS "Fortran version is defined.") else() message(STATUS "Fortran version is not defined.") endif() 2. I have run this code on Windows 7 (32-bit) using tdm-gcc GNU compilers (32-bit) with three versions of CMake (cmake -G "MinGW Makefiles"): a) with cmake 2.8.10.2 and cmake 2.8.12.2 i got this output: -- The C compiler identification is GNU 4.8.1 -- The CXX compiler identification is GNU 4.8.1 -- The Fortran compiler identification is GNU ... -- C version is defined. -- C++ version is defined. -- Fortran version is not defined. -- Configuring done -- Generating done ... b) but with cmake 3.0.0 i got this: -- The C compiler identification is GNU 4.8.1 -- The CXX compiler identification is GNU 4.8.1 -- The Fortran compiler identification is GNU ... -- C version is defined. -- C++ version is defined. -- Fortran version is defined. -- Configuring done -- Generating done ... 3. You can see there is a difference between Fortran version is defined (cmake 3.0.0) and Fortran version is not defined (cmake 2.8.x.x). So behaviour of CMake has changed a lot and I think it is a bug and can cause problems if someone relies on it. I have also information about this "surprise" behaviour on Linux when used with Intel compilers. -- Ivan Hrasko -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodrigo.faccioli at gmail.com Tue Aug 5 16:13:54 2014 From: rodrigo.faccioli at gmail.com (Rodrigo Faccioli) Date: Tue, 5 Aug 2014 17:13:54 -0300 Subject: [CMake] Help cmake First project In-Reply-To: References: <53DFACD1.6050807@kitware.com> Message-ID: Hi, I am thankfull for all help. Now, it is working :-) Radovan, thank you to try to run and your comments. My CMakeList.txt is showed below. I would like to know about best practice to make a CMakeList. If agree, I will compile others executables of my project based on how I compiled this executable. In [1] contains my full project. cmake_minimum_required(VERSION 2.8) # project Information project(2pg_cartesian) set(PROJECT_VERSION "1.0") # Set compiler flags SET ( CMAKE_CXX_FLAGS "-lm -pedantic") #Set CXX compiler for all files below set_source_files_properties(include/LoadConfig.h PROPERTIES LANGUAGE CXX ) set_source_files_properties(src/protpred-Gromacs-NSGA2.c PROPERTIES LANGUAGE CXX ) set_source_files_properties(src/LoadConfig.cpp PROPERTIES LANGUAGE CXX ) set_source_files_properties(src/ea_mono.c PROPERTIES LANGUAGE CXX ) set_source_files_properties(src/topology.c PROPERTIES LANGUAGE CXX ) set_source_files_properties(src/pdbio.c PROPERTIES LANGUAGE CXX ) set_source_files_properties(src/protein.c PROPERTIES LANGUAGE CXX ) set_source_files_properties(src/futil.c PROPERTIES LANGUAGE CXX ) set_source_files_properties(src/pdbatom.c PROPERTIES LANGUAGE CXX ) set_source_files_properties(src/messages.c PROPERTIES LANGUAGE CXX ) set_source_files_properties(src/topologyio.c PROPERTIES LANGUAGE CXX ) set_source_files_properties(src/topologylib.c PROPERTIES LANGUAGE CXX ) set_source_files_properties(src/randomlib.c PROPERTIES LANGUAGE CXX ) set_source_files_properties(src/vector_math.c PROPERTIES LANGUAGE CXX ) set_source_files_properties(src/string_owner.c PROPERTIES LANGUAGE CXX ) set_source_files_properties(src/math_owner.c PROPERTIES LANGUAGE CXX ) set_source_files_properties(src/osutil.c PROPERTIES LANGUAGE CXX ) set_source_files_properties(src/load_parameters.c PROPERTIES LANGUAGE CXX ) set_source_files_properties(src/objective.c PROPERTIES LANGUAGE CXX ) set_source_files_properties(src/aminoacids.c PROPERTIES LANGUAGE CXX ) set_source_files_properties(src/aminoacids_io.c PROPERTIES LANGUAGE CXX ) set_source_files_properties(src/populationio.c PROPERTIES LANGUAGE CXX ) set_source_files_properties(src/rotation.c PROPERTIES LANGUAGE CXX ) set_source_files_properties(src/solution.c PROPERTIES LANGUAGE CXX ) set_source_files_properties(src/gromacs_objectives.c PROPERTIES LANGUAGE CXX ) set_source_files_properties(src/solutionio.c PROPERTIES LANGUAGE CXX ) set_source_files_properties(src/algorithms.c PROPERTIES LANGUAGE CXX ) set_source_files_properties(src/ea_nsga2.c PROPERTIES LANGUAGE CXX ) set_source_files_properties(src/dominance.c PROPERTIES LANGUAGE CXX ) # set include include_directories(include) # add libries add_library(2PG-NSGA2_lib STATIC src/LoadConfig.cpp src/ea_mono.c src/topology.c src/pdbio.c src/protein.c src/futil.c src/pdbatom.c src/messages.c src/topologyio.c src/topologylib.c src/randomlib.c src/vector_math.c src/string_owner.c src/math_owner.c src/osutil.c src/load_parameters.c src/objective.c src/aminoacids.c src/aminoacids_io.c src/populationio.c src/rotation.c src/solution.c src/gromacs_objectives.c src/solutionio.c src/algorithms.c src/ea_nsga2.c src/dominance.c ) #end of 2PG-NSGA2_lib # add target add_executable(protpred-Gromacs-NSGA2 src/protpred-Gromacs-NSGA2.c) target_link_libraries(protpred-Gromacs-NSGA2 2PG-NSGA2_lib) # install install(TARGETS protpred-Gromacs-NSGA2 DESTINATION bin) [1] https://dl.dropboxusercontent.com/u/4270818/2pg_cartesian_cmake.zip Best regards, -- Rodrigo Antonio Faccioli, Ph.D Development Software for Structural Bioinformatics Barao de Maua University University of Sao Paulo Lindedin - br.linkedin.com/pub/rodrigo-antonio-faccioli/7/589/a5/ Curriculum Lattes - http://lattes.cnpq.br/1025157978990218 On Tue, Aug 5, 2014 at 3:39 PM, radovan bast wrote: > dear Rodrigo, > > i tried it but ran into many other problems in the source, not cmake. > > but also some cmake suggestions: > - list the language(s) that the project uses > - the c99 flag is not a definition but a compiler flag, use > CMAKE_CXX_FLAGS_... for portability > - "ALL" is not a good library name > - i recommend to not glob sources but to list them explicitly, there are > several discussions on the net > which explain why if you search for the topic > > good luck! > radovan > > > On Tue, Aug 5, 2014 at 5:08 PM, Rodrigo Faccioli < > rodrigo.faccioli at gmail.com> wrote: > >> Hi, >> >> Thanks Angeliki and Bill for your attentation. >> >> I have updated my CMakeList.txt based on your post. Below my >> CMakeList.txt is showed. >> >> cmake_minimum_required(VERSION 2.8) >> # project Information >> project(2pg_cartesian) >> set(PROJECT_VERSION "1.0") >> # add definitions to compiler >> add_definitions(-std=c99) >> # get all files under directory src >> file(GLOB SRC_FILES "src/*.c") >> # set include >> include_directories(include) >> # added libries >> add_library(ALL STATIC ${SRC_FILES}) >> # add target >> add_executable(protpred-Gromacs-NSGA2 src/protpred-Gromacs-NSGA2.c) >> target_link_libraries(protpred-Gromacs-NSGA2 ALL) >> >> Unfortunatelly, I have received error messages as cited below: >> faccioli at faccioli:~/Downloads/2pg_cartesian/build$ make >> Scanning dependencies of target ALL >> [ 2%] Building C object CMakeFiles/ALL.dir/src/protpred-Gromacs-NSGA2.c.o >> [ 5%] Building C object CMakeFiles/ALL.dir/src/ea_mono.c.o >> [ 7%] Building C object CMakeFiles/ALL.dir/src/topologyio.c.o >> [ 10%] Building C object CMakeFiles/ALL.dir/src/aminoacids.c.o >> [ 12%] Building C object CMakeFiles/ALL.dir/src/populationio.c.o >> [ 15%] Building C object CMakeFiles/ALL.dir/src/osutil.c.o >> [ 17%] Building C object CMakeFiles/ALL.dir/src/aminoacids_io.c.o >> [ 20%] Building C object >> CMakeFiles/ALL.dir/src/protpred-Gromacs-Sort_Method_Files_by_Front_Dominance.c.o >> [ 23%] Building C object CMakeFiles/ALL.dir/src/pdbio.c.o >> [ 25%] Building C object CMakeFiles/ALL.dir/src/solution.c.o >> [ 28%] Building C object CMakeFiles/ALL.dir/src/vector_math.c.o >> [ 30%] Building C object CMakeFiles/ALL.dir/src/math_owner.c.o >> [ 33%] Building C object CMakeFiles/ALL.dir/src/protein.c.o >> [ 35%] Building C object CMakeFiles/ALL.dir/src/load_parameters.c.o >> In file included from >> /home/faccioli/Downloads/2pg_cartesian/src/load_parameters.c:7:0: >> /home/faccioli/Downloads/2pg_cartesian/include/LoadConfig.h:1:18: fatal >> error: string: Arquivo ou diret?rio n?o encontrado >> compilation terminated. >> make[2]: ** [CMakeFiles/ALL.dir/src/load_parameters.c.o] Erro 1 >> make[1]: ** [CMakeFiles/ALL.dir/all] Erro 2 >> make: ** [all] Erro 2 >> faccioli at faccioli:~/Downloads/2pg_cartesian/build$ >> >> I did not understand what mistakes I have done since all files share same >> structure of directory. In [1] is my project completly. If prefer I can >> send its github repository. >> >> I appreciate any help. >> >> Best regards, >> >> [1] https://dl.dropboxusercontent.com/u/4270818/2pg_cartesian_cmake.zip >> >> >> -- >> Rodrigo Antonio Faccioli, Ph.D >> Development Software for Structural Bioinformatics >> Barao de Maua University >> University of Sao Paulo >> Lindedin - br.linkedin.com/pub/rodrigo-antonio-faccioli/7/589/a5/ >> Curriculum Lattes - http://lattes.cnpq.br/1025157978990218 >> >> >> On Mon, Aug 4, 2014 at 12:54 PM, Bill Hoffman >> wrote: >> >>> On 8/4/2014 10:26 AM, Rodrigo Faccioli wrote: >>> >>>> protpred-Gromacs-NSGA2.c:(.text+0x1e): undefined reference to >>>> `display_msg' >>>> protpred-Gromacs-NSGA2.c:(.text+0x3e): undefined reference to >>>> `load_parameters_from_file' >>>> protpred-Gromacs-NSGA2.c:(.text+0x58): undefined reference to >>>> `ea_nsga2' >>>> protpred-Gromacs-NSGA2.c:(.text+0x64): undefined reference to >>>> `fatal_error' >>>> protpred-Gromacs-NSGA2.c:(.text+0x73): undefined reference to >>>> `deAllocateload_parameters' >>>> protpred-Gromacs-NSGA2.c:(.text+0x7d): undefined reference to >>>> `display_msg' >>>> >>> You have to find out where these symbols are defined. If you have a >>> working Makefile version use nm and grep to find the places. You can also >>> grep your source tree. You are either missing a source file, or a -D >>> option. >>> >>> Another approach is to run make VERBOSE=1 and compare the build command >>> lines to your Makefile build. >>> >>> -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 >>> >> >> >> -- >> >> 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 >> > > > > -- > # PDC Center for High Performance Computing & > # Department of Theoretical Chemistry and Biology > # Royal Institute of Technology, Stockholm > # +46-8-790-6628 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.hoffman at kitware.com Tue Aug 5 16:16:14 2014 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Tue, 05 Aug 2014 16:16:14 -0400 Subject: [CMake] I have discovered a bug (probably) In-Reply-To: References: Message-ID: <53E13B8E.4040603@kitware.com> On 8/5/2014 3:57 PM, Ivan Hrasko wrote: > > 3. You can see there is a difference between Fortran version is defined > (cmake 3.0.0) and Fortran version is not defined (cmake 2.8.x.x). > So behaviour of CMake has changed a lot and I think it is a bug and can > cause problems if someone relies on it. I have also information > about this "surprise" behaviour on Linux when used with Intel compilers. Sounds like a bug got fixed. In older versions fortran version was not defined now it is defined. -Bill From abhrasko at gmail.com Tue Aug 5 16:23:41 2014 From: abhrasko at gmail.com (Ivan Hrasko) Date: Tue, 5 Aug 2014 22:23:41 +0200 Subject: [CMake] I have discovered a bug (probably) In-Reply-To: <53E13B8E.4040603@kitware.com> References: <53E13B8E.4040603@kitware.com> Message-ID: Not absolutely, CMake still does not know Fortran compiler version, variable is defined but as an empty string... But OK, I wil chage conditions in my other scripts. :) 2014-08-05 22:16 GMT+02:00 Bill Hoffman : > On 8/5/2014 3:57 PM, Ivan Hrasko wrote: > >> >> 3. You can see there is a difference between Fortran version is defined >> (cmake 3.0.0) and Fortran version is not defined (cmake 2.8.x.x). >> So behaviour of CMake has changed a lot and I think it is a bug and can >> cause problems if someone relies on it. I have also information >> about this "surprise" behaviour on Linux when used with Intel compilers. >> > Sounds like a bug got fixed. In older versions fortran version was not > defined now it is defined. > > -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 > -- Ivan Hrasko -------------- next part -------------- An HTML attachment was scrubbed... URL: From david at zemon.name Tue Aug 5 16:34:41 2014 From: david at zemon.name (david at zemon.name) Date: Tue, 5 Aug 2014 15:34:41 -0500 (CDT) Subject: [CMake] Windows Path Issues In-Reply-To: References: <1407261385.111226741@webmail.emailpower.biz> Message-ID: <1407270881.240315445@webmail.emailpower.biz> Sorry about that. I am using "Git Bash" which is definitely a confusing environment. The compiler is PropGCC - the target is an embedded system. PropGCC ships with GNU Make 3.81 (and "make --version" confirms that is the version of make in my PATH). Perhaps the output of "bash --version" will help: bash-3.1$ bash --version GNU bash, version 3.1.0(1)-release (i686-pc-msys) Copyright (C) 2005 Free Software Foundation, Inc. bash-3.1$ Thanks, David -----Original Message----- From: "Ivan Hrasko" Sent: Tuesday, August 5, 2014 2:26pm To: david at zemon.name Cc: cmake at cmake.org Subject: Re: [CMake] Windows Path Issues 1. What your environment exactly is? It does not look like Windows only (because I see in your log: bash-3.1$ cmake -G "Unix Makefiles" . ), so I expect you are using something like Cygwin and when you use this kind of environment you can have problems with paths. For example C:/software/propgcc/bin/propeller-elf-gcc is not a valid path for Cygwin, because cygwin uses /cygdrive/ in its path for things which are located in Windows. 2. When I use cmake on Windows (just Windows, cmd, not Cygwin or else) I use "MinGW Makefiles" not "Unix Makefiles" with GNU compilers. 2014-08-05 19:56 GMT+02:00 <[ david at zemon.name ]( mailto:david at zemon.name )>: I'm generally a Linux guy but need this project to work on all three main platforms. I have my toolchain file working nicely in Linux, but for some reason I'm getting an error on Windows. Here's top of the console output: bash-3.1$ cmake -G "Unix Makefiles" . -- The C compiler identification is GNU 4.6.1 -- The CXX compiler identification is GNU 4.6.1 -- The COGCXX compiler identification is GNU 4.6.1 -- The ECOGC compiler identification is GNU 4.6.1 -- The ECOGCXX compiler identification is GNU 4.6.1 -- The ASM compiler identification is GNU -- Found assembler: C:/software/propgcc/bin/propeller-elf-gcc CMake Error at CMakeLists.txt:6 (project): The CMAKE_C_COMPILER: C:/software/propgcc/bin/propeller-elf-gcc is not a full path to an existing compiler tool. Tell CMake where to find the compiler by setting either the environment variable "CC" or the CMake cache entry CMAKE_C_COMPILER to the full path to the compiler, or to the compiler name if it is in the PATH. This doesn't make too much sense to me. Anyone know why it would find the compiler at first and then loose it? The path that it lists is perfectly valid. Thanks, David -- Powered by [ www.kitware.com ]( http://www.kitware.com ) Please keep messages on-topic and check the CMake FAQ at: [ http://www.cmake.org/Wiki/CMake_FAQ ]( 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 ]( http://cmake.org/cmake/help/support.html ) CMake Consulting: [ http://cmake.org/cmake/help/consulting.html ]( http://cmake.org/cmake/help/consulting.html ) CMake Training Courses: [ http://cmake.org/cmake/help/training.html ]( http://cmake.org/cmake/help/training.html ) Visit other Kitware open-source projects at [ http://www.kitware.com/opensource/opensource.html ]( http://www.kitware.com/opensource/opensource.html ) Follow this link to subscribe/unsubscribe: [ http://public.kitware.com/mailman/listinfo/cmake ]( http://public.kitware.com/mailman/listinfo/cmake ) -- Ivan Hrasko <[ abhrasko at gmail.com ]( mailto:abhrasko at gmail.com )> -------------- next part -------------- An HTML attachment was scrubbed... URL: From post at hendrik-sattler.de Tue Aug 5 23:54:23 2014 From: post at hendrik-sattler.de (Hendrik Sattler) Date: Wed, 06 Aug 2014 05:54:23 +0200 Subject: [CMake] Help cmake First project In-Reply-To: References: <53DFACD1.6050807@kitware.com> Message-ID: <84766c09-e75c-458b-a175-6b130d9a865e@email.android.com> Hi, -lm does not belong to CMAKE_CXX_FLAGS as it is a linker option to link libm. Use target_link_libraries(protpred-Gromacs-NSGA2 m) instead. (Don't search for libm, the linker knows where it is.) It is also more common to use a variable for the list of source files. That would make it also possible to set the compile language for all files in one command without listing files twice. Adding headers and not just .c/.cpp/.cxx files makes it easier when using an IDE. On 5. August 2014 22:13:54 MESZ, Rodrigo Faccioli wrote: >Hi, > >I am thankfull for all help. Now, it is working :-) > >Radovan, thank you to try to run and your comments. > >My CMakeList.txt is showed below. I would like to know about best >practice >to make a CMakeList. If agree, I will compile others executables of my >project based on how I compiled this executable. In [1] contains my >full >project. > >cmake_minimum_required(VERSION 2.8) > ># project Information >project(2pg_cartesian) >set(PROJECT_VERSION "1.0") > ># Set compiler flags >SET ( CMAKE_CXX_FLAGS "-lm -pedantic") > >#Set CXX compiler for all files below >set_source_files_properties(include/LoadConfig.h PROPERTIES LANGUAGE >CXX ) >set_source_files_properties(src/protpred-Gromacs-NSGA2.c PROPERTIES >LANGUAGE CXX ) >set_source_files_properties(src/LoadConfig.cpp PROPERTIES LANGUAGE CXX >) >set_source_files_properties(src/ea_mono.c PROPERTIES LANGUAGE CXX ) >set_source_files_properties(src/topology.c PROPERTIES LANGUAGE CXX ) >set_source_files_properties(src/pdbio.c PROPERTIES LANGUAGE CXX ) >set_source_files_properties(src/protein.c PROPERTIES LANGUAGE CXX ) >set_source_files_properties(src/futil.c PROPERTIES LANGUAGE CXX ) >set_source_files_properties(src/pdbatom.c PROPERTIES LANGUAGE CXX ) >set_source_files_properties(src/messages.c PROPERTIES LANGUAGE CXX ) >set_source_files_properties(src/topologyio.c PROPERTIES LANGUAGE CXX ) >set_source_files_properties(src/topologylib.c PROPERTIES LANGUAGE CXX >) >set_source_files_properties(src/randomlib.c PROPERTIES LANGUAGE CXX ) >set_source_files_properties(src/vector_math.c PROPERTIES LANGUAGE CXX >) >set_source_files_properties(src/string_owner.c PROPERTIES LANGUAGE CXX >) >set_source_files_properties(src/math_owner.c PROPERTIES LANGUAGE CXX >) >set_source_files_properties(src/osutil.c PROPERTIES LANGUAGE CXX ) >set_source_files_properties(src/load_parameters.c PROPERTIES LANGUAGE >CXX ) >set_source_files_properties(src/objective.c PROPERTIES LANGUAGE CXX ) >set_source_files_properties(src/aminoacids.c PROPERTIES LANGUAGE CXX ) >set_source_files_properties(src/aminoacids_io.c PROPERTIES LANGUAGE >CXX ) >set_source_files_properties(src/populationio.c PROPERTIES LANGUAGE CXX >) >set_source_files_properties(src/rotation.c PROPERTIES LANGUAGE CXX ) >set_source_files_properties(src/solution.c PROPERTIES LANGUAGE CXX ) >set_source_files_properties(src/gromacs_objectives.c PROPERTIES >LANGUAGE >CXX ) >set_source_files_properties(src/solutionio.c PROPERTIES LANGUAGE CXX ) >set_source_files_properties(src/algorithms.c PROPERTIES LANGUAGE CXX ) >set_source_files_properties(src/ea_nsga2.c PROPERTIES LANGUAGE CXX ) >set_source_files_properties(src/dominance.c PROPERTIES LANGUAGE CXX ) > ># set include >include_directories(include) > ># add libries >add_library(2PG-NSGA2_lib STATIC >src/LoadConfig.cpp >src/ea_mono.c >src/topology.c >src/pdbio.c >src/protein.c >src/futil.c >src/pdbatom.c >src/messages.c >src/topologyio.c >src/topologylib.c >src/randomlib.c >src/vector_math.c >src/string_owner.c >src/math_owner.c >src/osutil.c >src/load_parameters.c >src/objective.c >src/aminoacids.c >src/aminoacids_io.c >src/populationio.c >src/rotation.c >src/solution.c >src/gromacs_objectives.c >src/solutionio.c >src/algorithms.c >src/ea_nsga2.c >src/dominance.c >) #end of 2PG-NSGA2_lib > ># add target >add_executable(protpred-Gromacs-NSGA2 src/protpred-Gromacs-NSGA2.c) >target_link_libraries(protpred-Gromacs-NSGA2 2PG-NSGA2_lib) > ># install >install(TARGETS protpred-Gromacs-NSGA2 DESTINATION bin) > >[1] https://dl.dropboxusercontent.com/u/4270818/2pg_cartesian_cmake.zip > >Best regards, > >-- >Rodrigo Antonio Faccioli, Ph.D >Development Software for Structural Bioinformatics >Barao de Maua University >University of Sao Paulo >Lindedin - br.linkedin.com/pub/rodrigo-antonio-faccioli/7/589/a5/ >Curriculum Lattes - http://lattes.cnpq.br/1025157978990218 > > >On Tue, Aug 5, 2014 at 3:39 PM, radovan bast wrote: > >> dear Rodrigo, >> >> i tried it but ran into many other problems in the source, not cmake. >> >> but also some cmake suggestions: >> - list the language(s) that the project uses >> - the c99 flag is not a definition but a compiler flag, use >> CMAKE_CXX_FLAGS_... for portability >> - "ALL" is not a good library name >> - i recommend to not glob sources but to list them explicitly, there >are >> several discussions on the net >> which explain why if you search for the topic >> >> good luck! >> radovan >> >> >> On Tue, Aug 5, 2014 at 5:08 PM, Rodrigo Faccioli < >> rodrigo.faccioli at gmail.com> wrote: >> >>> Hi, >>> >>> Thanks Angeliki and Bill for your attentation. >>> >>> I have updated my CMakeList.txt based on your post. Below my >>> CMakeList.txt is showed. >>> >>> cmake_minimum_required(VERSION 2.8) >>> # project Information >>> project(2pg_cartesian) >>> set(PROJECT_VERSION "1.0") >>> # add definitions to compiler >>> add_definitions(-std=c99) >>> # get all files under directory src >>> file(GLOB SRC_FILES "src/*.c") >>> # set include >>> include_directories(include) >>> # added libries >>> add_library(ALL STATIC ${SRC_FILES}) >>> # add target >>> add_executable(protpred-Gromacs-NSGA2 src/protpred-Gromacs-NSGA2.c) >>> target_link_libraries(protpred-Gromacs-NSGA2 ALL) >>> >>> Unfortunatelly, I have received error messages as cited below: >>> faccioli at faccioli:~/Downloads/2pg_cartesian/build$ make >>> Scanning dependencies of target ALL >>> [ 2%] Building C object >CMakeFiles/ALL.dir/src/protpred-Gromacs-NSGA2.c.o >>> [ 5%] Building C object CMakeFiles/ALL.dir/src/ea_mono.c.o >>> [ 7%] Building C object CMakeFiles/ALL.dir/src/topologyio.c.o >>> [ 10%] Building C object CMakeFiles/ALL.dir/src/aminoacids.c.o >>> [ 12%] Building C object CMakeFiles/ALL.dir/src/populationio.c.o >>> [ 15%] Building C object CMakeFiles/ALL.dir/src/osutil.c.o >>> [ 17%] Building C object CMakeFiles/ALL.dir/src/aminoacids_io.c.o >>> [ 20%] Building C object >>> >CMakeFiles/ALL.dir/src/protpred-Gromacs-Sort_Method_Files_by_Front_Dominance.c.o >>> [ 23%] Building C object CMakeFiles/ALL.dir/src/pdbio.c.o >>> [ 25%] Building C object CMakeFiles/ALL.dir/src/solution.c.o >>> [ 28%] Building C object CMakeFiles/ALL.dir/src/vector_math.c.o >>> [ 30%] Building C object CMakeFiles/ALL.dir/src/math_owner.c.o >>> [ 33%] Building C object CMakeFiles/ALL.dir/src/protein.c.o >>> [ 35%] Building C object CMakeFiles/ALL.dir/src/load_parameters.c.o >>> In file included from >>> /home/faccioli/Downloads/2pg_cartesian/src/load_parameters.c:7:0: >>> /home/faccioli/Downloads/2pg_cartesian/include/LoadConfig.h:1:18: >fatal >>> error: string: Arquivo ou diret?rio n?o encontrado >>> compilation terminated. >>> make[2]: ** [CMakeFiles/ALL.dir/src/load_parameters.c.o] Erro 1 >>> make[1]: ** [CMakeFiles/ALL.dir/all] Erro 2 >>> make: ** [all] Erro 2 >>> faccioli at faccioli:~/Downloads/2pg_cartesian/build$ >>> >>> I did not understand what mistakes I have done since all files share >same >>> structure of directory. In [1] is my project completly. If prefer I >can >>> send its github repository. >>> >>> I appreciate any help. >>> >>> Best regards, >>> >>> [1] >https://dl.dropboxusercontent.com/u/4270818/2pg_cartesian_cmake.zip >>> >>> >>> -- >>> Rodrigo Antonio Faccioli, Ph.D >>> Development Software for Structural Bioinformatics >>> Barao de Maua University >>> University of Sao Paulo >>> Lindedin - br.linkedin.com/pub/rodrigo-antonio-faccioli/7/589/a5/ >>> Curriculum Lattes - http://lattes.cnpq.br/1025157978990218 >>> >>> >>> On Mon, Aug 4, 2014 at 12:54 PM, Bill Hoffman > >>> wrote: >>> >>>> On 8/4/2014 10:26 AM, Rodrigo Faccioli wrote: >>>> >>>>> protpred-Gromacs-NSGA2.c:(.text+0x1e): undefined reference to >>>>> `display_msg' >>>>> protpred-Gromacs-NSGA2.c:(.text+0x3e): undefined reference to >>>>> `load_parameters_from_file' >>>>> protpred-Gromacs-NSGA2.c:(.text+0x58): undefined reference to >>>>> `ea_nsga2' >>>>> protpred-Gromacs-NSGA2.c:(.text+0x64): undefined reference to >>>>> `fatal_error' >>>>> protpred-Gromacs-NSGA2.c:(.text+0x73): undefined reference to >>>>> `deAllocateload_parameters' >>>>> protpred-Gromacs-NSGA2.c:(.text+0x7d): undefined reference to >>>>> `display_msg' >>>>> >>>> You have to find out where these symbols are defined. If you have >a >>>> working Makefile version use nm and grep to find the places. You >can also >>>> grep your source tree. You are either missing a source file, or a >-D >>>> option. >>>> >>>> Another approach is to run make VERBOSE=1 and compare the build >command >>>> lines to your Makefile build. >>>> >>>> -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 >>>> >>> >>> >>> -- >>> >>> 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 >>> >> >> >> >> -- >> # PDC Center for High Performance Computing & >> # Department of Theoretical Chemistry and Biology >> # Royal Institute of Technology, Stockholm >> # +46-8-790-6628 >> > > >------------------------------------------------------------------------ From johan.laneau at nxp.com Wed Aug 6 03:39:12 2014 From: johan.laneau at nxp.com (Johan Laneau) Date: Wed, 6 Aug 2014 07:39:12 +0000 Subject: [CMake] Combining several static libraries into a single static library Message-ID: <21eba91aa5664be0b17d9ed8e4c2bbdb@DB4PR04MB0720.eurprd04.prod.outlook.com> Hi, I am in the process of deploying CMake into the build process of our department. I got already quite a lot of it working but I get stuck at one point: I can't see how we can combine several static libraries into a single static library with CMake. I'll give some background first, to help you understand my problem. Our code is split up in more than 100 projects. Echo of those project is built into static libraries. In our department we work with static libraries because we target embedded systems that don't have support shared libraries, so shared libraries are not allowed. The static libraries can have dependencies on other projects. We build these project on many different platforms so CMake will definitely help in our build system. With our current build system, we combine these static libraries into "Release libraries". "Release libraries" are a combination of all required static libraries (no dependencies left anymore) into a single static library without any new code being added. This makes it very easy to release the combined functionality to a 3rd Party (such as another department or customer). We have a lot of "Release Libraries" with different combinations of the projects because we target different applications. So I could simplify our build structure as below: /Project01 (Static library) /Project02 (Static library) /Project03 (Static library) ... /Project99 (Static library) /ReleaseLibrary01 (Static library links e.g. Project01, Project02 and Project03) /ReleaseLibrary02 (Static library links e.g. Project01, Project02 and Project04) /ReleaseLibrary02 (Static library links e.g. Project05, Project06 and Project99) /... We already succeeded in building all our projects into static libraries with CMake. We also succeeded in building our test applications based upon those static libraries including the resolution of the dependencies (CMake is easy for this). But we are not able to build our "Release Libraries". Simply adding a target with add_library for the "Release Library" does not work. What I already read so far is that there are several workarounds: (e.g. rebuild the "Release Library" with the source of all dependent projects, unpack all libraries and repack again with platform specific commands, etc.). Some references I found are: https://svn.jmodelica.org/FMILibrary/trunk/Config.cmake/mergestaticlibs.cmake, https://code.google.com/p/toadlet/source/browse/cmake/Modules/MergeStaticLibraries.cmake, http://www.cmake.org/pipermail/cmake/2011-February/043002.html. I also saw that CMake supports an OBJECT library which might be helpful. All of this seems very clumsy to me and I can't find any convergence on the best way to approach this. Is there any good reference where it is guided how to combine static libraries into a single static library with CMake ? Thanks already for the support. Johan Laneau Software Architect, NXP Software Interleuvenlaan 80, B-3001 Leuven, Belgium Phone: +32 495 354 839, Fax: +32 16 390 855 E-mail: johan.laneau at nxp.com, http://www.nxpsoftware.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From angeliki.chrysochou at gmail.com Wed Aug 6 04:32:17 2014 From: angeliki.chrysochou at gmail.com (Angeliki Chrysochou) Date: Wed, 6 Aug 2014 10:32:17 +0200 Subject: [CMake] Help cmake First project In-Reply-To: <84766c09-e75c-458b-a175-6b130d9a865e@email.android.com> References: <53DFACD1.6050807@kitware.com> <84766c09-e75c-458b-a175-6b130d9a865e@email.android.com> Message-ID: Hi Rodrigo, Glad that it is working for you now. I just wanted to mention that I never had to set the language as properties to the source files since cmake detects it from the suffix of the source files you list, or at least I never had a case where the language was not properly detected. Other than that I agree with Hendrik's suggestions as well! Cheers, Angeliki On Wed, Aug 6, 2014 at 5:54 AM, Hendrik Sattler wrote: > Hi, > > -lm does not belong to CMAKE_CXX_FLAGS as it is a linker option to link > libm. > Use > target_link_libraries(protpred-Gromacs-NSGA2 m) > instead. (Don't search for libm, the linker knows where it is.) > > It is also more common to use a variable for the list of source files. > That would make it also possible to set the compile language for all files > in one command without listing files twice. > > Adding headers and not just .c/.cpp/.cxx files makes it easier when using > an IDE. > > > On 5. August 2014 22:13:54 MESZ, Rodrigo Faccioli < > rodrigo.faccioli at gmail.com> wrote: > >Hi, > > > >I am thankfull for all help. Now, it is working :-) > > > >Radovan, thank you to try to run and your comments. > > > >My CMakeList.txt is showed below. I would like to know about best > >practice > >to make a CMakeList. If agree, I will compile others executables of my > >project based on how I compiled this executable. In [1] contains my > >full > >project. > > > >cmake_minimum_required(VERSION 2.8) > > > ># project Information > >project(2pg_cartesian) > >set(PROJECT_VERSION "1.0") > > > ># Set compiler flags > >SET ( CMAKE_CXX_FLAGS "-lm -pedantic") > > > >#Set CXX compiler for all files below > >set_source_files_properties(include/LoadConfig.h PROPERTIES LANGUAGE > >CXX ) > >set_source_files_properties(src/protpred-Gromacs-NSGA2.c PROPERTIES > >LANGUAGE CXX ) > >set_source_files_properties(src/LoadConfig.cpp PROPERTIES LANGUAGE CXX > >) > >set_source_files_properties(src/ea_mono.c PROPERTIES LANGUAGE CXX ) > >set_source_files_properties(src/topology.c PROPERTIES LANGUAGE CXX ) > >set_source_files_properties(src/pdbio.c PROPERTIES LANGUAGE CXX ) > >set_source_files_properties(src/protein.c PROPERTIES LANGUAGE CXX ) > >set_source_files_properties(src/futil.c PROPERTIES LANGUAGE CXX ) > >set_source_files_properties(src/pdbatom.c PROPERTIES LANGUAGE CXX ) > >set_source_files_properties(src/messages.c PROPERTIES LANGUAGE CXX ) > >set_source_files_properties(src/topologyio.c PROPERTIES LANGUAGE CXX ) > >set_source_files_properties(src/topologylib.c PROPERTIES LANGUAGE CXX > >) > >set_source_files_properties(src/randomlib.c PROPERTIES LANGUAGE CXX ) > >set_source_files_properties(src/vector_math.c PROPERTIES LANGUAGE CXX > >) > >set_source_files_properties(src/string_owner.c PROPERTIES LANGUAGE CXX > >) > >set_source_files_properties(src/math_owner.c PROPERTIES LANGUAGE CXX > >) > >set_source_files_properties(src/osutil.c PROPERTIES LANGUAGE CXX ) > >set_source_files_properties(src/load_parameters.c PROPERTIES LANGUAGE > >CXX ) > >set_source_files_properties(src/objective.c PROPERTIES LANGUAGE CXX ) > >set_source_files_properties(src/aminoacids.c PROPERTIES LANGUAGE CXX ) > >set_source_files_properties(src/aminoacids_io.c PROPERTIES LANGUAGE > >CXX ) > >set_source_files_properties(src/populationio.c PROPERTIES LANGUAGE CXX > >) > >set_source_files_properties(src/rotation.c PROPERTIES LANGUAGE CXX ) > >set_source_files_properties(src/solution.c PROPERTIES LANGUAGE CXX ) > >set_source_files_properties(src/gromacs_objectives.c PROPERTIES > >LANGUAGE > >CXX ) > >set_source_files_properties(src/solutionio.c PROPERTIES LANGUAGE CXX ) > >set_source_files_properties(src/algorithms.c PROPERTIES LANGUAGE CXX ) > >set_source_files_properties(src/ea_nsga2.c PROPERTIES LANGUAGE CXX ) > >set_source_files_properties(src/dominance.c PROPERTIES LANGUAGE CXX ) > > > ># set include > >include_directories(include) > > > ># add libries > >add_library(2PG-NSGA2_lib STATIC > >src/LoadConfig.cpp > >src/ea_mono.c > >src/topology.c > >src/pdbio.c > >src/protein.c > >src/futil.c > >src/pdbatom.c > >src/messages.c > >src/topologyio.c > >src/topologylib.c > >src/randomlib.c > >src/vector_math.c > >src/string_owner.c > >src/math_owner.c > >src/osutil.c > >src/load_parameters.c > >src/objective.c > >src/aminoacids.c > >src/aminoacids_io.c > >src/populationio.c > >src/rotation.c > >src/solution.c > >src/gromacs_objectives.c > >src/solutionio.c > >src/algorithms.c > >src/ea_nsga2.c > >src/dominance.c > >) #end of 2PG-NSGA2_lib > > > ># add target > >add_executable(protpred-Gromacs-NSGA2 src/protpred-Gromacs-NSGA2.c) > >target_link_libraries(protpred-Gromacs-NSGA2 2PG-NSGA2_lib) > > > ># install > >install(TARGETS protpred-Gromacs-NSGA2 DESTINATION bin) > > > >[1] https://dl.dropboxusercontent.com/u/4270818/2pg_cartesian_cmake.zip > > > >Best regards, > > > >-- > >Rodrigo Antonio Faccioli, Ph.D > >Development Software for Structural Bioinformatics > >Barao de Maua University > >University of Sao Paulo > >Lindedin - br.linkedin.com/pub/rodrigo-antonio-faccioli/7/589/a5/ > >Curriculum Lattes - http://lattes.cnpq.br/1025157978990218 > > > > > >On Tue, Aug 5, 2014 at 3:39 PM, radovan bast wrote: > > > >> dear Rodrigo, > >> > >> i tried it but ran into many other problems in the source, not cmake. > >> > >> but also some cmake suggestions: > >> - list the language(s) that the project uses > >> - the c99 flag is not a definition but a compiler flag, use > >> CMAKE_CXX_FLAGS_... for portability > >> - "ALL" is not a good library name > >> - i recommend to not glob sources but to list them explicitly, there > >are > >> several discussions on the net > >> which explain why if you search for the topic > >> > >> good luck! > >> radovan > >> > >> > >> On Tue, Aug 5, 2014 at 5:08 PM, Rodrigo Faccioli < > >> rodrigo.faccioli at gmail.com> wrote: > >> > >>> Hi, > >>> > >>> Thanks Angeliki and Bill for your attentation. > >>> > >>> I have updated my CMakeList.txt based on your post. Below my > >>> CMakeList.txt is showed. > >>> > >>> cmake_minimum_required(VERSION 2.8) > >>> # project Information > >>> project(2pg_cartesian) > >>> set(PROJECT_VERSION "1.0") > >>> # add definitions to compiler > >>> add_definitions(-std=c99) > >>> # get all files under directory src > >>> file(GLOB SRC_FILES "src/*.c") > >>> # set include > >>> include_directories(include) > >>> # added libries > >>> add_library(ALL STATIC ${SRC_FILES}) > >>> # add target > >>> add_executable(protpred-Gromacs-NSGA2 src/protpred-Gromacs-NSGA2.c) > >>> target_link_libraries(protpred-Gromacs-NSGA2 ALL) > >>> > >>> Unfortunatelly, I have received error messages as cited below: > >>> faccioli at faccioli:~/Downloads/2pg_cartesian/build$ make > >>> Scanning dependencies of target ALL > >>> [ 2%] Building C object > >CMakeFiles/ALL.dir/src/protpred-Gromacs-NSGA2.c.o > >>> [ 5%] Building C object CMakeFiles/ALL.dir/src/ea_mono.c.o > >>> [ 7%] Building C object CMakeFiles/ALL.dir/src/topologyio.c.o > >>> [ 10%] Building C object CMakeFiles/ALL.dir/src/aminoacids.c.o > >>> [ 12%] Building C object CMakeFiles/ALL.dir/src/populationio.c.o > >>> [ 15%] Building C object CMakeFiles/ALL.dir/src/osutil.c.o > >>> [ 17%] Building C object CMakeFiles/ALL.dir/src/aminoacids_io.c.o > >>> [ 20%] Building C object > >>> > > >CMakeFiles/ALL.dir/src/protpred-Gromacs-Sort_Method_Files_by_Front_Dominance.c.o > >>> [ 23%] Building C object CMakeFiles/ALL.dir/src/pdbio.c.o > >>> [ 25%] Building C object CMakeFiles/ALL.dir/src/solution.c.o > >>> [ 28%] Building C object CMakeFiles/ALL.dir/src/vector_math.c.o > >>> [ 30%] Building C object CMakeFiles/ALL.dir/src/math_owner.c.o > >>> [ 33%] Building C object CMakeFiles/ALL.dir/src/protein.c.o > >>> [ 35%] Building C object CMakeFiles/ALL.dir/src/load_parameters.c.o > >>> In file included from > >>> /home/faccioli/Downloads/2pg_cartesian/src/load_parameters.c:7:0: > >>> /home/faccioli/Downloads/2pg_cartesian/include/LoadConfig.h:1:18: > >fatal > >>> error: string: Arquivo ou diret?rio n?o encontrado > >>> compilation terminated. > >>> make[2]: ** [CMakeFiles/ALL.dir/src/load_parameters.c.o] Erro 1 > >>> make[1]: ** [CMakeFiles/ALL.dir/all] Erro 2 > >>> make: ** [all] Erro 2 > >>> faccioli at faccioli:~/Downloads/2pg_cartesian/build$ > >>> > >>> I did not understand what mistakes I have done since all files share > >same > >>> structure of directory. In [1] is my project completly. If prefer I > >can > >>> send its github repository. > >>> > >>> I appreciate any help. > >>> > >>> Best regards, > >>> > >>> [1] > >https://dl.dropboxusercontent.com/u/4270818/2pg_cartesian_cmake.zip > >>> > >>> > >>> -- > >>> Rodrigo Antonio Faccioli, Ph.D > >>> Development Software for Structural Bioinformatics > >>> Barao de Maua University > >>> University of Sao Paulo > >>> Lindedin - br.linkedin.com/pub/rodrigo-antonio-faccioli/7/589/a5/ > >>> Curriculum Lattes - http://lattes.cnpq.br/1025157978990218 > >>> > >>> > >>> On Mon, Aug 4, 2014 at 12:54 PM, Bill Hoffman > > > >>> wrote: > >>> > >>>> On 8/4/2014 10:26 AM, Rodrigo Faccioli wrote: > >>>> > >>>>> protpred-Gromacs-NSGA2.c:(.text+0x1e): undefined reference to > >>>>> `display_msg' > >>>>> protpred-Gromacs-NSGA2.c:(.text+0x3e): undefined reference to > >>>>> `load_parameters_from_file' > >>>>> protpred-Gromacs-NSGA2.c:(.text+0x58): undefined reference to > >>>>> `ea_nsga2' > >>>>> protpred-Gromacs-NSGA2.c:(.text+0x64): undefined reference to > >>>>> `fatal_error' > >>>>> protpred-Gromacs-NSGA2.c:(.text+0x73): undefined reference to > >>>>> `deAllocateload_parameters' > >>>>> protpred-Gromacs-NSGA2.c:(.text+0x7d): undefined reference to > >>>>> `display_msg' > >>>>> > >>>> You have to find out where these symbols are defined. If you have > >a > >>>> working Makefile version use nm and grep to find the places. You > >can also > >>>> grep your source tree. You are either missing a source file, or a > >-D > >>>> option. > >>>> > >>>> Another approach is to run make VERBOSE=1 and compare the build > >command > >>>> lines to your Makefile build. > >>>> > >>>> -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 > >>>> > >>> > >>> > >>> -- > >>> > >>> 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 > >>> > >> > >> > >> > >> -- > >> # PDC Center for High Performance Computing & > >> # Department of Theoretical Chemistry and Biology > >> # Royal Institute of Technology, Stockholm > >> # +46-8-790-6628 > >> > > > > > >------------------------------------------------------------------------ > > -- > > 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 romain.leguay at gmail.com Wed Aug 6 04:46:52 2014 From: romain.leguay at gmail.com (Romain Leguay) Date: Wed, 06 Aug 2014 10:46:52 +0200 Subject: [CMake] CMake 3.0, Qt 5, plugins and multiple executables inside OS X Bundle Message-ID: <53E1EB7C.6070306@gmail.com> Hello everyone, I have a Qt application that search for another Qt applications and some plugins too. On Windows, I just create the executables in the same folder but on Mac OS X, I can't do that: I must create a bundle like this: MyApplication.app/ Contents/ Frameworks/ **all qt library** **all application dependencies** libPluginInterface.dylib Resources/ **application icon** MacOS/ MyApplication subApplication1 subApplication2 PlugIns/ **all my plugins** (.dylib) When I'll open MyApplication.app, I'd like to launch MyApplication executable. For now, my applications and plugins are store like this: Project/ CMakeLists.txt MyApplication/ CMakeLists.txt **source_files** PluginInterface/ CMakeLists.txt **source_files** subApplication1/ CMakeLists.txt **source_files** subApplication2/ CMakeLists.txt **source_files** plugins/ CMakeLists.txt plugin1/ CMakeLists.txt **source_files** MyApplication and all the plugins depends on PluginInterface (a shared library). For now, I have many difficulties about the link path. I don't understand very well how to use @rpath for my libraries. So, my first question: is-it possible to do something like this? Second, can you show me some examples about this please? Thank you. Romain From ycollette.nospam at free.fr Wed Aug 6 05:19:00 2014 From: ycollette.nospam at free.fr (ycollette.nospam at free.fr) Date: Wed, 6 Aug 2014 11:19:00 +0200 (CEST) Subject: [CMake] Ctest and custom measurements In-Reply-To: <878735249.541918.1406736428949.JavaMail.root@zimbra35-e6.priv.proxad.net> Message-ID: <2034464649.9636155.1407316740007.JavaMail.root@zimbra35-e6.priv.proxad.net> Hello, I make a patch (against maint branch) to allow detection of: ......... Instead of only: ... Where can I add some documentation related to this ? Best regards, YC ----- Mail original ----- De: "ycollette nospam" ?: "David Cole" Cc: cmake at cmake.org Envoy?: Mercredi 30 Juillet 2014 18:07:08 Objet: Re: [CMake] Ctest and custom measurements OK, I will try to make a patch. YC ----- Mail original ----- De: "David Cole" ?: "ycollette nospam" Cc: cmake at cmake.org Envoy?: Mercredi 30 Juillet 2014 17:42:07 Objet: Re: [CMake] Ctest and custom measurements > By the way, this should be better documented in the cmake / ctest > documentation. > And we should be allowed to add measurements like these in the log: > Log message - date - 0.1 I agree on both points. I would go even farther and say what you were trying to do originally should have "just worked"... > Do I fill a bug report for this ? You can. Although it would be more effective if you could contribute a patch to improve the docs, or to implement the code required to improve the DartMeasurement parsing so it's not necessarily at the beginning of the line, or even to accept "NamedMeasurement" values directly from the output... Are you able to submit patches that do any of this? Do you have the time or the inclination? :-) David C. -- 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 -------------- A non-text attachment was scrubbed... Name: dart_measurement.diff Type: text/x-patch Size: 954 bytes Desc: not available URL: From dlrdave at aol.com Wed Aug 6 06:19:30 2014 From: dlrdave at aol.com (David Cole) Date: Wed, 6 Aug 2014 06:19:30 -0400 (EDT) Subject: [CMake] Combining several static libraries into a single static library In-Reply-To: <21eba91aa5664be0b17d9ed8e4c2bbdb@DB4PR04MB0720.eurprd04.prod.outlook.com> References: <21eba91aa5664be0b17d9ed8e4c2bbdb@DB4PR04MB0720.eurprd04.prod.outlook.com> Message-ID: <8D17F770AF81527-1AA4-28E2A@webmail-d212.sysops.aol.com> Seems like your best bet using CMake would be to use OBJECT libraries for your Project01 through Project99 -- and then use STATIC libraries for your ReleaseLibraries, which combine the objects of the appropriate project libraries... You may need to use dummy source files for the static libs, depending on your build environment. See the Tests/ObjectLibrary/CMakeLists.txt in the CMake source tree for an example of all the different workarounds there are for older Visual Studios and Xcode... http://cmake.org/gitweb?p=cmake.git;a=blob;f=Tests/ObjectLibrary/CMakeLists.txt;h=0aeefaa48753feec0c5e0af2f850b32d6cd28279;hb=55d6aa36a522f2dd7849ccd53d9e743a88f8c7a1 Another alternative would be to use STATIC libraries all the way through and let CMake do its transitive linking thing via target_link_libraries, but then your executables that link to them would need access to all of the static libraries including the Project01 to Project99 ones, even at the very client level where you are no doubt trying to simplify the build experience for those that require your release libraries. Good luck! HTH, David C. From nautsch2 at gmail.com Wed Aug 6 06:32:24 2014 From: nautsch2 at gmail.com (Andre Naujoks) Date: Wed, 06 Aug 2014 12:32:24 +0200 Subject: [CMake] "make package_source" with only symlinks in a subdirectory fails Message-ID: <53E20438.4020909@gmail.com> Hi. I reported this bug to the debian bug-tracker some time ago, but there seems to be no activity regarding this. So I report this here as well and hope for someone to respond. I created a patch (see below), which works for me, but might change things in a completely wrong place. I am on cmake version 2.8.12.1 (debian version 2.8.12.1-1.6) This is the text of the debian bug report (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=749892): If I try to create a source package with cmake via CPack and "make package_source" and there is a directory in the sources, that only contains symlinks (only one in my case), the generation of the source package fails with: CPack Error: Cannot create symlink: --> where source and destination are the file/symlink names of course. It seems CPack tries to create the paths for the destination only if it copies files and not when creating symlinks. The following patch fixes this for me. I don't know, if this is actually the right place to put this, but it should point to the exact problem. diff -Naur cmake-2.8.12.1_orig/Source/kwsys/SystemTools.cxx cmake-2.8.12.1/Source/kwsys/SystemTools.cxx --- cmake-2.8.12.1_orig/Source/kwsys/SystemTools.cxx 2013-11-05 20:07:23.000000000 +0100 +++ cmake-2.8.12.1/Source/kwsys/SystemTools.cxx 2014-05-30 14:25:23.912154919 +0200 @@ -2835,6 +2835,9 @@ #else bool SystemTools::CreateSymlink(const char* origName, const char* newName) { + kwsys_stl::string destination_dir = newName; + destination_dir = GetFilenamePath(destination_dir); + MakeDirectory(destination_dir.c_str()); return symlink(origName, newName) >= 0; } #endif Regards Andre From nicolasbock at gmail.com Wed Aug 6 10:14:42 2014 From: nicolasbock at gmail.com (Nicolas Bock) Date: Wed, 6 Aug 2014 08:14:42 -0600 Subject: [CMake] A potential fix for issue #0014656 Message-ID: Hi, I have modified the existing FindOpenMP.cmake code and added a Fortran test. In addition I copied CheckCSourceCompiles.cmake to compile Fortran code, which is needed by the Fortran test in FindOpenMP.cmake. Please find the two scripts attached. Could a CMake developer look the two scripts over and give me feedback on their quality? Thanks already, nick -------------- next part -------------- A non-text attachment was scrubbed... Name: FindOpenMP.cmake Type: text/x-cmake Size: 6715 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: CheckFortranSourceCompiles.cmake Type: text/x-cmake Size: 3586 bytes Desc: not available URL: From david at zemon.name Wed Aug 6 11:49:40 2014 From: david at zemon.name (david at zemon.name) Date: Wed, 6 Aug 2014 10:49:40 -0500 (CDT) Subject: [CMake] Windows Path Issues In-Reply-To: <1407270881.240315445@webmail.emailpower.biz> References: <1407261385.111226741@webmail.emailpower.biz> <1407270881.240315445@webmail.emailpower.biz> Message-ID: <1407340180.387410141@webmail.emailpower.biz> I've run it from CMD this time instead of Git Bash. Same results: C:\Users\IGEN006\WORKSPACE_C_CPP\PropWare>cmake -G "Unix Makefiles" . -- The C compiler identification is GNU 4.6.1 -- The CXX compiler identification is GNU 4.6.1 -- The COGCXX compiler identification is GNU 4.6.1 -- The ECOGC compiler identification is GNU 4.6.1 -- The ECOGCXX compiler identification is GNU 4.6.1 -- The ASM compiler identification is GNU -- Found assembler: C:/software/propgcc/bin/propeller-elf-gcc CMake Error at CMakeLists.txt:6 (project): The CMAKE_C_COMPILER: C:/software/propgcc/bin/propeller-elf-gcc is not a full path to an existing compiler tool. Tell CMake where to find the compiler by setting either the environment variable "CC" or the CMake cache entry CMAKE_C_COMPILER to the full path to the compiler, or to the compiler name if it is in the PATH. Any ideas are greatly appreciated. Thanks, David -----Original Message----- From: david at zemon.name Sent: Tuesday, August 5, 2014 3:34pm To: "Ivan Hrasko" Cc: cmake at cmake.org Subject: Re: [CMake] Windows Path Issues Sorry about that. I am using "Git Bash" which is definitely a confusing environment. The compiler is PropGCC - the target is an embedded system. PropGCC ships with GNU Make 3.81 (and "make --version" confirms that is the version of make in my PATH). Perhaps the output of "bash --version" will help: bash-3.1$ bash --version GNU bash, version 3.1.0(1)-release (i686-pc-msys) Copyright (C) 2005 Free Software Foundation, Inc. bash-3.1$ Thanks, David -----Original Message----- From: "Ivan Hrasko" Sent: Tuesday, August 5, 2014 2:26pm To: david at zemon.name Cc: cmake at cmake.org Subject: Re: [CMake] Windows Path Issues 1. What your environment exactly is? It does not look like Windows only (because I see in your log: bash-3.1$ cmake -G "Unix Makefiles" . ), so I expect you are using something like Cygwin and when you use this kind of environment you can have problems with paths. For example C:/software/propgcc/bin/propeller-elf-gcc is not a valid path for Cygwin, because cygwin uses /cygdrive/ in its path for things which are located in Windows. 2. When I use cmake on Windows (just Windows, cmd, not Cygwin or else) I use "MinGW Makefiles" not "Unix Makefiles" with GNU compilers. 2014-08-05 19:56 GMT+02:00 <[ david at zemon.name ]( mailto:david at zemon.name )>: I'm generally a Linux guy but need this project to work on all three main platforms. I have my toolchain file working nicely in Linux, but for some reason I'm getting an error on Windows. Here's top of the console output: bash-3.1$ cmake -G "Unix Makefiles" . -- The C compiler identification is GNU 4.6.1 -- The CXX compiler identification is GNU 4.6.1 -- The COGCXX compiler identification is GNU 4.6.1 -- The ECOGC compiler identification is GNU 4.6.1 -- The ECOGCXX compiler identification is GNU 4.6.1 -- The ASM compiler identification is GNU -- Found assembler: C:/software/propgcc/bin/propeller-elf-gcc CMake Error at CMakeLists.txt:6 (project): The CMAKE_C_COMPILER: C:/software/propgcc/bin/propeller-elf-gcc is not a full path to an existing compiler tool. Tell CMake where to find the compiler by setting either the environment variable "CC" or the CMake cache entry CMAKE_C_COMPILER to the full path to the compiler, or to the compiler name if it is in the PATH. This doesn't make too much sense to me. Anyone know why it would find the compiler at first and then loose it? The path that it lists is perfectly valid. Thanks, David -- Powered by [ www.kitware.com ]( http://www.kitware.com ) Please keep messages on-topic and check the CMake FAQ at: [ http://www.cmake.org/Wiki/CMake_FAQ ]( 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 ]( http://cmake.org/cmake/help/support.html ) CMake Consulting: [ http://cmake.org/cmake/help/consulting.html ]( http://cmake.org/cmake/help/consulting.html ) CMake Training Courses: [ http://cmake.org/cmake/help/training.html ]( http://cmake.org/cmake/help/training.html ) Visit other Kitware open-source projects at [ http://www.kitware.com/opensource/opensource.html ]( http://www.kitware.com/opensource/opensource.html ) Follow this link to subscribe/unsubscribe: [ http://public.kitware.com/mailman/listinfo/cmake ]( http://public.kitware.com/mailman/listinfo/cmake ) -- Ivan Hrasko <[ abhrasko at gmail.com ]( mailto:abhrasko at gmail.com )> -------------- next part -------------- An HTML attachment was scrubbed... URL: From dlrdave at aol.com Wed Aug 6 12:47:17 2014 From: dlrdave at aol.com (David Cole) Date: Wed, 6 Aug 2014 12:47:17 -0400 (EDT) Subject: [CMake] Windows Path Issues In-Reply-To: <1407340180.387410141@webmail.emailpower.biz> References: <1407261385.111226741@webmail.emailpower.biz> <1407270881.240315445@webmail.emailpower.biz> <1407340180.387410141@webmail.emailpower.biz> Message-ID: <8D17FAD37A96684-1AA4-2A1C0@webmail-d212.sysops.aol.com> What's in your toolchain file? Is the file at "C:/software/propgcc/bin/propeller-elf-gcc" named propeller-elf-gcc.exe? Should there be a ".exe" in the compiler file name? What "GNU make" are you using? (The primary ones well tested for use with CMake on Windows are MinGW and MSYS...) Can you build anything with "Unix Makefiles" in a non-MSYS-shell Windows environment? Seems like you'd want to use either "MSYS Makefiles" or "MinGW Makefiles" depending on your environment. HTH, David C. From dschepler at scalable-networks.com Wed Aug 6 12:42:02 2014 From: dschepler at scalable-networks.com (Daniel Schepler) Date: Wed, 6 Aug 2014 16:42:02 +0000 Subject: [CMake] Windows Path Issues In-Reply-To: <1407340180.387410141@webmail.emailpower.biz> References: <1407261385.111226741@webmail.emailpower.biz> <1407270881.240315445@webmail.emailpower.biz> <1407340180.387410141@webmail.emailpower.biz> Message-ID: Maybe you need to set it to C:/software/propgcc/bin/propeller-elf-gcc.exe instead? (Or ${WHATEVER_PATH}/propeller-elf-gcc${CMAKE_EXECUTABLE_SUFFIX} .) -- Daniel From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of david at zemon.name Sent: Wednesday, August 06, 2014 8:50 AM To: cmake at cmake.org Subject: Re: [CMake] Windows Path Issues I've run it from CMD this time instead of Git Bash. Same results: C:\Users\IGEN006\WORKSPACE_C_CPP\PropWare>cmake -G "Unix Makefiles" . -- The C compiler identification is GNU 4.6.1 -- The CXX compiler identification is GNU 4.6.1 -- The COGCXX compiler identification is GNU 4.6.1 -- The ECOGC compiler identification is GNU 4.6.1 -- The ECOGCXX compiler identification is GNU 4.6.1 -- The ASM compiler identification is GNU -- Found assembler: C:/software/propgcc/bin/propeller-elf-gcc CMake Error at CMakeLists.txt:6 (project): The CMAKE_C_COMPILER: C:/software/propgcc/bin/propeller-elf-gcc is not a full path to an existing compiler tool. Tell CMake where to find the compiler by setting either the environment variable "CC" or the CMake cache entry CMAKE_C_COMPILER to the full path to the compiler, or to the compiler name if it is in the PATH. Any ideas are greatly appreciated. Thanks, David -----Original Message----- From: david at zemon.name Sent: Tuesday, August 5, 2014 3:34pm To: "Ivan Hrasko" > Cc: cmake at cmake.org Subject: Re: [CMake] Windows Path Issues Sorry about that. I am using "Git Bash" which is definitely a confusing environment. The compiler is PropGCC - the target is an embedded system. PropGCC ships with GNU Make 3.81 (and "make --version" confirms that is the version of make in my PATH). Perhaps the output of "bash --version" will help: bash-3.1$ bash --version GNU bash, version 3.1.0(1)-release (i686-pc-msys) Copyright (C) 2005 Free Software Foundation, Inc. bash-3.1$ Thanks, David -----Original Message----- From: "Ivan Hrasko" > Sent: Tuesday, August 5, 2014 2:26pm To: david at zemon.name Cc: cmake at cmake.org Subject: Re: [CMake] Windows Path Issues 1. What your environment exactly is? It does not look like Windows only (because I see in your log: bash-3.1$ cmake -G "Unix Makefiles" . ), so I expect you are using something like Cygwin and when you use this kind of environment you can have problems with paths. For example C:/software/propgcc/bin/propeller-elf-gcc is not a valid path for Cygwin, because cygwin uses /cygdrive/ in its path for things which are located in Windows. 2. When I use cmake on Windows (just Windows, cmd, not Cygwin or else) I use "MinGW Makefiles" not "Unix Makefiles" with GNU compilers. 2014-08-05 19:56 GMT+02:00 >: I'm generally a Linux guy but need this project to work on all three main platforms. I have my toolchain file working nicely in Linux, but for some reason I'm getting an error on Windows. Here's top of the console output: bash-3.1$ cmake -G "Unix Makefiles" . -- The C compiler identification is GNU 4.6.1 -- The CXX compiler identification is GNU 4.6.1 -- The COGCXX compiler identification is GNU 4.6.1 -- The ECOGC compiler identification is GNU 4.6.1 -- The ECOGCXX compiler identification is GNU 4.6.1 -- The ASM compiler identification is GNU -- Found assembler: C:/software/propgcc/bin/propeller-elf-gcc CMake Error at CMakeLists.txt:6 (project): The CMAKE_C_COMPILER: C:/software/propgcc/bin/propeller-elf-gcc is not a full path to an existing compiler tool. Tell CMake where to find the compiler by setting either the environment variable "CC" or the CMake cache entry CMAKE_C_COMPILER to the full path to the compiler, or to the compiler name if it is in the PATH. This doesn't make too much sense to me. Anyone know why it would find the compiler at first and then loose it? The path that it lists is perfectly valid. Thanks, David -- 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 -- Ivan Hrasko > -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.maynard at kitware.com Wed Aug 6 14:40:03 2014 From: robert.maynard at kitware.com (Robert Maynard) Date: Wed, 6 Aug 2014 14:40:03 -0400 Subject: [CMake] [ANNOUNCE] CMake 3.0.1 Released Message-ID: We are pleased to announce that CMake 3.0.1 is now available for download. The change log page for this bug-fix only release is here: http://public.kitware.com/Bug/roadmap_page.php?version_id=123 Please use the latest release from our download page: http://cmake.org/cmake/resources/software.html Thanks for your support! ------------------------------------------------------------------------- Changes in 3.0.1 since 3.0.0: Adam Strzelecki (1): Ninja: Remove CMake includes from explicit depends (#14972) Bob E (1): KWSys SystemInformation: No SA_RESTART on QNX Brad King (10): cmake: Fix read-after-free while checking command-line arguments Fortran: Add support for GNU >= 4.9 compressed modules (#14975) bootstrap: Clarify name of configured source directory bootstrap: Fix "make test" and "make package" targets (#14989) UseSWIG: Fix check for noproxy flag (#14990) CMakeExpandImportedTargets: Do not read property on non-target (#15008) MSVC: Fix linking of DLLs on WinCE (#15013) Xcode: Fix static library creation for Xcode 6 (#15038) Check*CompilerFlag: Avoid ';' in common pattern (#15048) CMake 3.0.1 Chuck Atkins (1): cmcurl: Fix a build failure with the Cray compiler on Linux (#15026) Mathieu MARACHE (1): FindQt4: Add nativewifi and qtga plugins Stephen Kelly (1): QNX: Add missing flags for configurations and artifact creation. Tim Blechmann (1): OS X: Install CFBundles as complete directories From glenn.coombs at gmail.com Thu Aug 7 03:32:59 2014 From: glenn.coombs at gmail.com (Glenn Coombs) Date: Thu, 7 Aug 2014 08:32:59 +0100 Subject: [CMake] cmake version/feature detection In-Reply-To: References: Message-ID: If you know which version of cmake first introduced the feature you want to check for then you could base your decision on the values of these 3 cmake variables: CMAKE_MAJOR_VERSION CMAKE_MINOR_VERSION CMAKE_PATCH_VERSION -- Glenn On 5 August 2014 04:30, Leif Walsh wrote: > Hi, > > I'm wondering what is the best way to do feature detection or version > checking of cmake itself, in cmake. In particular, I'd like to check for > the OBJECT library feature and either use it or fall back to our current > mechanism if we're using an older cmake. > > -- > Cheers, > Leif > > -- > > 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 glenn.coombs at gmail.com Thu Aug 7 04:27:40 2014 From: glenn.coombs at gmail.com (Glenn Coombs) Date: Thu, 7 Aug 2014 09:27:40 +0100 Subject: [CMake] Is it possible for a dependee to use the dependency LINKER_FLAGS ? In-Reply-To: References: Message-ID: I just tried reproducing your 2 examples. Setup 1 works fine for me with no messages about policy CMP0022. The only way I could get that message produced was by omitting the cmake_minimum_required(VERSION 3.0) line. Are you sure you're running the exact same CMakeLists.txt file that you have posted here ? For setup 2 I get the same results as you. CMake seems to insist on converting the forward slash into a backwards slash, probably because it thinks it is a file path, which totally screws things up. I suspect this is a bug in cmake: adding linker flags like this works for linux because it doesn't mess with strings like "-Wl,-Bstatic". The only workaround I can suggest is to set CMAKE_EXE_LINKER_FLAGS: if (MSVC) set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} /FORCE:Multiple") endif() which correctly adds the option you want but it will do it for all libraries in the current context. In order to only have it applied to the one library you would need to have a separate CMakeLists.txt for that library and add the lines above to adjust the CMAKE_EXE_LINKER_FLAGS only in that CMakeLists.txt. Then you would have to do and add_subdirectory(special_lib) somewhere in your higher level CMakeLists.txt. -- Glenn On 3 August 2014 07:43, Adrian M Negreanu wrote: > I've tested this with vs 2013 but a few things makes me think > that using target_link_libraries is not for this type of usage. > > First, for setup 1: > ===== CMakeLists.txt ================ > cmake_minimum_required(VERSION 3.0) > > add_library(A a.cpp) > target_link_libraries(A INTERFACE -custom-flags) > > add_executable(E e.cpp) > target_link_libraries(E A) > ################################### > > Cmake warns me: > > CMake Warning (dev) in CMakeLists.txt: > Policy CMP0022 is not set: INTERFACE_LINK_LIBRARIES defines the link > interface. Run "cmake --help-policy CMP0022" for policy details. Use > the > cmake_policy command to set the policy and suppress this warning. > > Target "A" has an INTERFACE_LINK_LIBRARIES property. This should be > preferred as the source of the link interface for this library but > because > CMP0022 is not set CMake is ignoring the property and using the link > implementation as the link interface instead. > > INTERFACE_LINK_LIBRARIES: > > /FORCE:multiple > > > For setup 2: > ===== CMakeLists.txt ================ > cmake_minimum_required(VERSION 3.0) > add_library(A a.cpp) > set_target_properties(A PROPERTIES INTERFACE_LINK_LIBRARIES > "/FORCE:multiple") > > add_executable(E e.cpp) > target_link_libraries(E A) > ################################### > > > Cmake works fine, _but_ "/FORCE:multiple" is seen as a file, which leads > to error: > > 1>------ Build started: Project: ZERO_CHECK, Configuration: Debug Win32 > ------ > 2>------ Build started: Project: A, Configuration: Debug Win32 ------ > 2> A.vcxproj -> C:\Users\amnegrea\Debug\A.lib > 3>------ Build started: Project: E, Configuration: Debug Win32 ------ > 3>LINK : fatal error LNK1104: cannot open file '\FORCE:multiple.obj' > 4>------ Skipped Build: Project: ALL_BUILD, Configuration: Debug Win32 > ------ > 4>Project not selected to build for this solution configuration > ========== Build: 2 succeeded, 1 failed, 0 up-to-date, 1 skipped ========== > > > > > > On Sat, Aug 2, 2014 at 7:38 PM, Walter Gray wrote: > >> Glen is correct. You should take a look at the docs for interface modules >> here: >> >> >> http://www.cmake.org/cmake/help/v3.0/manual/cmake-buildsystem.7.html#interface-libraries >> >> I also put up some examples of how to do this on github a while back. >> >> https://github.com/wal-rus/cmake-modules >> >> Hope that helps! Also for future googling the concept is called Usage >> Requirements. >> On Aug 2, 2014 8:11 AM, "Glenn Coombs" wrote: >> >>> I think that you can use the target_link_libraries command to do this: >>> >>> add_library(A a.cpp) >>> target_link_libraries(A INTERFACE -custom-flags) >>> >>> -- >>> Glenn >>> >>> >>> >>> On 30 July 2014 16:51, Adrian M Negreanu wrote: >>> >>>> Hi, >>>> >>>> Is it possible to attach a property on a target, and that property >>>> to be used whenever the target is used ? >>>> >>>> ex: >>>> >>>> add_library(A a.cpp) >>>> somehow_attach_LINK_FLAGS(A "--custom-flags") >>>> >>>> # in a different directory >>>> add_executable(E e.cpp) >>>> target_link_libraries(E A) >>>> # ^--- this would do something similiar to >>>> set_target_properties(E PROPERTIES LINK_FLAGS "--custom-flags") >>>> >>>> For example, to use A:LINK_FLAGS >>>> >>>> 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 >>>> >>> >>> >>> -- >>> >>> 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 >>> >> > > > -- > Regards! > http://groleo.wordpress.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ravi.raman at Xoriant.Com Thu Aug 7 06:52:27 2014 From: ravi.raman at Xoriant.Com (Ravi Raman) Date: Thu, 7 Aug 2014 10:52:27 +0000 Subject: [CMake] Cmake issue regarding conversion of existing Visual Studio .targets files to cmake References: <8D17B98D58C24C4-BD0-159DA@webmail-d258.sysops.aol.com> Message-ID: <0f25a88d35dc4352a407214035ccb309@XORMUM-MBX01.India.XoriantCorp.com> Hi David, We have a query regarding how to use MIDL related commands in cmake. In our project, many Visual Studio project files involve MIDL command execution. So, there are few Visual Studio targets which use MIDL related macros. For example, here is one such target: The above target creates an output file testmidl.rsp containing the MIDL command line as set in Link.MidlCommandLine which is a Visual Studio macro. So, in cmake we have taken the following approach: 1. We have added a PRE-LINK custom command using add_custom_command as follows: add_custom_command( TARGET ${TARGETNAME} PRE_LINK COMMAND ${CMAKE_SOURCE_DIR}/GenTestMidlFile.bat "$(IntDir)" \"${MIDLCOMMAND}\" COMMENT "Generate MIDL command file $(IntDir)/testmidl.rsp") 2. The batch file GenTestMidlFile.bat takes MIDLCOMMAND as one of the arguments. The MIDLCOMMAND argument will contain the MIDL command line value which will be set accordingly for each module that uses MIDL command, otherwise it will be empty. The batch file logic is to create the file testmidl.rsp to contain the contents present in MIDLCOMMAND argument. We have tested this and it works fine. Just wanted to know, if there is a better approach or anything specific for MIDL in cmake? Thanks & Regards Ravi Raman Xoriant Solutions Pvt. Ltd 4th Floor, Winchester, Hiranandani Business Park, Powai, Mumbai 400076, INDIA. Tel: +91 22 30511000,9930100026 Extn: 2144 Voip No. 4088344495/96/97/98 Voip Extn:1178| Fax: +91 22 30511111 ravi.raman at xoriant.com| http://www.xoriant.com -----Original Message----- From: Ravi Raman Sent: Friday, August 01, 2014 8:01 PM To: 'David Cole' Cc: cmake at cmake.org Subject: RE: [CMake] Cmake issue regarding conversion of existing Visual Studio .targets files to cmake Hi David, Thanks. The 2nd approach of using batch file worked successfully. Thanks & Regards Ravi Raman Xoriant Solutions Pvt. Ltd 4th Floor, Winchester, Hiranandani Business Park, Powai, Mumbai 400076, INDIA. Tel: +91 22 30511000,9930100026 Extn: 2144 Voip No. 4088344495/96/97/98 Voip Extn:1178| Fax: +91 22 30511111 ravi.raman at xoriant.com| http://www.xoriant.com -----Original Message----- From: David Cole [mailto:dlrdave at aol.com] Sent: Friday, August 01, 2014 5:41 PM To: Ravi Raman Cc: cmake at cmake.org Subject: Re: [CMake] Cmake issue regarding conversion of existing Visual Studio .targets files to cmake Sorry about the premature "send" on that last email... First try this: add_custom_command( TARGET ${TARGETNAME} POST_BUILD COMMAND ${TBIN}/VerCheck.exe \"$(TargetPath)\" COMMAND copy \"$(TargetPath)\" \"$(TargetPath).vercheck_dummy_target\" COMMENT "Checking if $(TargetPath) has version info...") i.e. -- just say "POST_BUILD" once, then a sequence of COMMAND lines. (I think it's passing your second POST_BUILD as an argument to VerCheck...) If that still doesn't work, try: add_custom_command( TARGET ${TARGETNAME} POST_BUILD COMMAND VerCheckAndCopy.bat "${TBIN}" "$(TargetPath)" COMMENT "Checking if $(TargetPath) has version info...") and delegate it to a batch script that takes arguments which internally does the sequence of commands you want. If you go this route, you may still need nested quotes around "$(TargetPath)" -- CMake doesn't know about expanding those VS values, and whether or not they'll need quotes around them. HTH, David C. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dlrdave at aol.com Thu Aug 7 07:55:50 2014 From: dlrdave at aol.com (David Cole) Date: Thu, 7 Aug 2014 07:55:50 -0400 (EDT) Subject: [CMake] cmake version/feature detection Message-ID: <8D1804DAABCB862-2CB8-8B7@webmail-d212.sysops.aol.com> Specifically, for the OBJECT library feature, I figured out what version of CMake introduced it like this: gitk -- Tests/ObjectLibrary/CMakeLists.txt leads to finding this first commit of that file: 69d3d183 [1] gitk 69d3d183 leads to b87d7a60 [2] (4 parent commits up) which introduced the feature itself. Then, git describe --contains b87d7a60 yields: v2.8.8~29^2~15 So.... OBJECT libraries were introduced in CMake v2.8.8. Also, in all the gitk views for these commits, it tells you "Follows: v2.8.7" and "Precedes: v2.8.8". You could therefore write code like: if (${CMAKE_VERSION} VERSION_LESS 2.8.8) # avoid OBJECT libraries else() # ok to use OBJECT libraries endif() HTH, David C. [1] http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=69d3d183 [2] http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b87d7a60 From dlrdave at aol.com Thu Aug 7 09:12:01 2014 From: dlrdave at aol.com (David Cole) Date: Thu, 7 Aug 2014 09:12:01 -0400 (EDT) Subject: [CMake] Cmake issue regarding conversion of existing Visual Studio .targets files to cmake Message-ID: <8D180584F47E059-2CB8-CD1@webmail-d212.sysops.aol.com> If it works, do it. Custom commands are the easiest way to do MIDL stuff driven by CMake if you need things to work with any generator. Alternatively, if you are guaranteed to be using Visual Studio generators, you can try just adding the idl file as a source file of the library or executable that contains it, as the VSMidl test does: [1] -- but it may only work with source/build tree names that contain no spaces depending on your VS version. The parent CMakeLists that builds it arranges for this to be the case: [2] HTH, David C. [1] http://cmake.org/gitweb?p=cmake.git;a=blob;f=Tests/VSMidl/src/CMakeLists.txt;h=86c04ed9;hb=029edcdf [2] http://cmake.org/gitweb?p=cmake.git;a=blob;f=Tests/VSMidl/CMakeLists.txt;h=432506c3;hb=029edcdf From abhrasko at gmail.com Thu Aug 7 12:51:28 2014 From: abhrasko at gmail.com (Ivan Hrasko) Date: Thu, 7 Aug 2014 18:51:28 +0200 Subject: [CMake] Windows Path Issues In-Reply-To: <1407340180.387410141@webmail.emailpower.biz> References: <1407261385.111226741@webmail.emailpower.biz> <1407270881.240315445@webmail.emailpower.biz> <1407340180.387410141@webmail.emailpower.biz> Message-ID: I found at < https://code.google.com/p/android-cmake/source/browse/toolchain/android.toolchain.cmake?r=25d186d534477c063d780ac22a8c44bded2ca71d> this: "# Usage Windows: # You need native port of make to build your project. # For example this one: http://gnuwin32.sourceforge.net/packages/make.htm # # $ SET ANDROID_NDK=C:\\android-ndk-r6 # $ cmake.exe -G"Unix Makefiles" -DCMAKE_TOOLCHAIN_FILE=\android.toolchain.cmake -DCMAKE_MAKE_PROGRAM=C:\\make.exe .. # $ C:\\make.exe" *So maybe you can try make from: http://gnuwin32.sourceforge.net/packages/make.htm * 2014-08-06 17:49 GMT+02:00 : > I've run it from CMD this time instead of Git Bash. Same results: > > C:\Users\IGEN006\WORKSPACE_C_CPP\PropWare>cmake -G "Unix Makefiles" . > -- The C compiler identification is GNU 4.6.1 > -- The CXX compiler identification is GNU 4.6.1 > -- The COGCXX compiler identification is GNU 4.6.1 > -- The ECOGC compiler identification is GNU 4.6.1 > -- The ECOGCXX compiler identification is GNU 4.6.1 > -- The ASM compiler identification is GNU > -- Found assembler: C:/software/propgcc/bin/propeller-elf-gcc > CMake Error at CMakeLists.txt:6 (project): > > > The CMAKE_C_COMPILER: > > > > C:/software/propgcc/bin/propeller-elf-gcc > > is not a full path to an existing compiler tool. > > > > Tell CMake where to find the compiler by setting either the environment > variable "CC" or the CMake cache entry CMAKE_C_COMPILER to the full path > to > the compiler, or to the compiler name if it is in the PATH. > > > > Any ideas are greatly appreciated. > > > > Thanks, > > David > > > > -----Original Message----- > From: david at zemon.name > Sent: Tuesday, August 5, 2014 3:34pm > To: "Ivan Hrasko" > Cc: cmake at cmake.org > Subject: Re: [CMake] Windows Path Issues > > Sorry about that. I am using "Git Bash" which is definitely a confusing > environment. The compiler is PropGCC - the target is an embedded system. > PropGCC ships with GNU Make 3.81 (and "make --version" confirms that is the > version of make in my PATH). > > > > Perhaps the output of "bash --version" will help: > > > > bash-3.1$ bash --version > GNU bash, version 3.1.0(1)-release (i686-pc-msys) > Copyright (C) 2005 Free Software Foundation, Inc. > bash-3.1$ > > > > Thanks, > > David > > > > -----Original Message----- > From: "Ivan Hrasko" > Sent: Tuesday, August 5, 2014 2:26pm > To: david at zemon.name > Cc: cmake at cmake.org > Subject: Re: [CMake] Windows Path Issues > > 1. What your environment exactly is? It does not look like Windows only > (because I see in your log: bash-3.1$ cmake -G "Unix Makefiles" . ), so I > expect you are using something like Cygwin and when you use this kind of > environment you can > have problems with paths. For example C:/software/propgcc/bin/propeller-elf-gcc > is not a valid path for Cygwin, because cygwin uses /cygdrive/ in its > path for things which are located in Windows. > 2. When I use cmake on Windows (just Windows, cmd, not Cygwin or else) I > use "MinGW Makefiles" not "Unix Makefiles" with GNU compilers. > > > 2014-08-05 19:56 GMT+02:00 : > >> I'm generally a Linux guy but need this project to work on all three main >> platforms. >> >> >> >> I have my toolchain file working nicely in Linux, but for some reason I'm >> getting an error on Windows. Here's top of the console output: >> >> >> >> bash-3.1$ cmake -G "Unix Makefiles" . >> -- The C compiler identification is GNU 4.6.1 >> -- The CXX compiler identification is GNU 4.6.1 >> -- The COGCXX compiler identification is GNU 4.6.1 >> -- The ECOGC compiler identification is GNU 4.6.1 >> -- The ECOGCXX compiler identification is GNU 4.6.1 >> -- The ASM compiler identification is GNU >> -- Found assembler: C:/software/propgcc/bin/propeller-elf-gcc >> CMake Error at CMakeLists.txt:6 (project): >> The CMAKE_C_COMPILER: >> >> >> >> C:/software/propgcc/bin/propeller-elf-gcc >> >> >> >> is not a full path to an existing compiler tool. >> >> >> >> Tell CMake where to find the compiler by setting either the environment >> variable "CC" or the CMake cache entry CMAKE_C_COMPILER to the full >> path to >> the compiler, or to the compiler name if it is in the PATH. >> >> >> >> This doesn't make too much sense to me. Anyone know why it would find the >> compiler at first and then loose it? The path that it lists is perfectly >> valid. >> >> >> >> Thanks, >> >> David >> >> -- >> >> 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 > > > > > -- > Ivan Hrasko > > -- Ivan Hrasko -------------- next part -------------- An HTML attachment was scrubbed... URL: From leif.walsh at gmail.com Thu Aug 7 14:10:43 2014 From: leif.walsh at gmail.com (Leif Walsh) Date: Thu, 7 Aug 2014 14:10:43 -0400 Subject: [CMake] cmake version/feature detection In-Reply-To: <8D1804DAABCB862-2CB8-8B7@webmail-d212.sysops.aol.com> References: <8D1804DAABCB862-2CB8-8B7@webmail-d212.sysops.aol.com> Message-ID: Thanks! On Thu, Aug 7, 2014 at 7:55 AM, David Cole wrote: > Specifically, for the OBJECT library feature, I figured out what > version of CMake introduced it like this: > > gitk -- Tests/ObjectLibrary/CMakeLists.txt > > leads to finding this first commit of that file: 69d3d183 [1] > > gitk 69d3d183 > > leads to b87d7a60 [2] (4 parent commits up) which introduced the > feature itself. Then, > > git describe --contains b87d7a60 > > yields: > > v2.8.8~29^2~15 > > So.... OBJECT libraries were introduced in CMake v2.8.8. Also, in all > the gitk views for these commits, it tells you "Follows: v2.8.7" and > "Precedes: v2.8.8". > > > You could therefore write code like: > > if (${CMAKE_VERSION} VERSION_LESS 2.8.8) > # avoid OBJECT libraries > else() > # ok to use OBJECT libraries > endif() > > > HTH, > David C. > > > [1] http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=69d3d183 > [2] http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b87d7a60 > > > -- Cheers, Leif -------------- next part -------------- An HTML attachment was scrubbed... URL: From jmerkow at gmail.com Thu Aug 7 17:19:02 2014 From: jmerkow at gmail.com (jmerkow) Date: Thu, 7 Aug 2014 14:19:02 -0700 (PDT) Subject: [CMake] Question regarding External Project add and VTK In-Reply-To: <1403199806493-7587722.post@n2.nabble.com> References: <1401774586474-7587563.post@n2.nabble.com> <1401833063339-7587571.post@n2.nabble.com> <8D14DEFF7FB0297-1DEC-54AAF@webmail-vm052.sysops.aol.com> <1402277995826-7587601.post@n2.nabble.com> <1402297580345.7a49d3d7@Nodemailer> <1402851665772-7587690.post@n2.nabble.com> <1403199806493-7587722.post@n2.nabble.com> Message-ID: <1407446342430-7588095.post@n2.nabble.com> Jc, I guess I spoke too soon on my 'last question.' How does make install work with this superbuild system. Looking at slicer and ctk, they seem to set INSTALL_COMMAND to "" in their superbuild.cmake, but presumably these packages still install even with superbuild mode on. Can you offer any advice? -Jameson -- View this message in context: http://cmake.3232098.n2.nabble.com/Question-regarding-External-Project-add-and-VTK-tp7587557p7588095.html Sent from the CMake mailing list archive at Nabble.com. From matt.dawson at thermofisher.com Fri Aug 8 09:11:41 2014 From: matt.dawson at thermofisher.com (Dawson, Matt) Date: Fri, 8 Aug 2014 09:11:41 -0400 Subject: [CMake] cmake 3.0 not working on windows (mantis #14910) Message-ID: <47E5FDEB396BB5488F60EB4B5FBF210D7E31C994D3@USPHO-MXVS07.amer.thermo.com> I had a lot of difficulty getting cmake 3.0 to work under windows. I noticed that there is a bug (mantis #14910) which describes the problem. I had to fall back to 12.8.4 to get things to work. This was reported back in may. Will this be fixed anytime soon. Its kind of a show stopper bug and will probably drive away first time windows users like me. Matt Dawson Dissemination, distribution or copying of this e-mail or the information herein by anyone other than the intended recipient, or an employee or agent of a system responsible for delivering the message to the intended recipient, is prohibited. If you are not the intended recipient, please inform the sender and delete all copies. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nilsgladitz at gmail.com Fri Aug 8 10:05:51 2014 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Fri, 08 Aug 2014 16:05:51 +0200 Subject: [CMake] cmake 3.0 not working on windows (mantis #14910) In-Reply-To: <47E5FDEB396BB5488F60EB4B5FBF210D7E31C994D3@USPHO-MXVS07.amer.thermo.com> References: <47E5FDEB396BB5488F60EB4B5FBF210D7E31C994D3@USPHO-MXVS07.amer.thermo.com> Message-ID: <53E4D93F.3050109@gmail.com> On 08.08.2014 15:11, Dawson, Matt wrote: > > I had a lot of difficulty getting cmake 3.0 to work under windows. I > noticed that there is a bug (mantis #14910) which describes the > problem. I had to fall back to 12.8.4 to get things to work. This was > reported back in may. Will this be fixed anytime soon. Its kind of a > show stopper bug and will probably drive away first time windows users > like me. > > Can you elaborate what exactly isn't working and which generator you are trying to use? "0014910: CMake ignores CMAKE_TOOLCHAIN_FILE even without existing cache file" doesn't seem to have been confirmed and there seems to be missing feedback (see the note under it). If one of the visual studio generators has been used this would be expected behavior (in both 2.8.x and 3.0). For the issue to be analyzed or even fixed it has to be reproduced first. Nils -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt.dawson at thermofisher.com Fri Aug 8 12:31:03 2014 From: matt.dawson at thermofisher.com (Dawson, Matt) Date: Fri, 8 Aug 2014 12:31:03 -0400 Subject: [CMake] cmake 3.0 not working on windows (mantis #14910) Message-ID: <47E5FDEB396BB5488F60EB4B5FBF210D7E31C99561@USPHO-MXVS07.amer.thermo.com> Ok I spent the last hour trying to put together a reproducible example and found that I had way overstated things. I'm trying to Use cmake with the Texas Instruments Arm Compiler (Code Composer 5.5). I'm using windows 7 x64. I'm putting together a custom compiler support package. I know that there is support for a "TI" compiler In cmake but I could not get it to work because the compiler id test always craps out. Below is my custom tool chain file. include("CMakeForceCompiler") set(CMAKE_SYSTEM_NAME "Generic") #set(CMAKE_SYSTEM_VERSION "1.0") #set(CMAKE_SYSTEM_PROCESSOR "C6000") set(CMAKE_FIND_ROOT_PATH "C:/ti/ccsv5/tools/compiler/arm_5.1.1" ) CMAKE_FORCE_C_COMPILER("armcl" "TI") CMAKE_FORCE_CXX_COMPILER("armcl" "TI") message( STATUS, "hello from toolchain ${CMAKE_C_COMPILER_ID}") set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER) set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE BOTH) set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY) When I run this under 3.0 using the command line cmake -G "MinGW Makefiles" -DCMAKE_MODULE_PATH="../my_modules" -DCMAKE_TOOLCHAIN_FILE="../my_toolchain.cmake" ../src I get the following error output The CMAKE_C_COMPILER: armcl is not a full path and was not found in the PATH. Tell CMake where to find the compiler by setting either the environment variable "CC" or the CMake cache entry CMAKE_C_COMPILER to the full path to the compiler, or to the compiler name if it is in the PATH. Under 2.8.4 this same toolchain file works fine. I've attached a zip file with the example. There is a build directory with 3.0 output (bld3_0) and and 2.8 output (bld2_8). They Have text files of captured stdout and stderr for each run. I have my own version of "TI-CXX.cmake" which I have put in a custom modules subdirectory. I tried to reproduce this problem With MinGW but could not. I copied the "GNU-C.cmake" compiler setup script into my Compiler directory had a CMAKE_FORCE_COMPILER(c++ "GNU") in my toolchain file. Everything worked just find under 3.0. I suspect that cmake has a lot of logic for auto-finding the mingw compiler. Matt Dawson From: Nils Gladitz [mailto:nilsgladitz at gmail.com] Sent: Friday, August 08, 2014 9:06 AM To: Dawson, Matt; cmake at cmake.org Subject: Re: [CMake] cmake 3.0 not working on windows (mantis #14910) On 08.08.2014 15:11, Dawson, Matt wrote: I had a lot of difficulty getting cmake 3.0 to work under windows. I noticed that there is a bug (mantis #14910) which describes the problem. I had to fall back to 12.8.4 to get things to work. This was reported back in may. Will this be fixed anytime soon. Its kind of a show stopper bug and will probably drive away first time windows users like me. Can you elaborate what exactly isn't working and which generator you are trying to use? "0014910: CMake ignores CMAKE_TOOLCHAIN_FILE even without existing cache file" doesn't seem to have been confirmed and there seems to be missing feedback (see the note under it). If one of the visual studio generators has been used this would be expected behavior (in both 2.8.x and 3.0). For the issue to be analyzed or even fixed it has to be reproduced first. Nils -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bug_example.zip Type: application/x-zip-compressed Size: 24908 bytes Desc: bug_example.zip URL: From groleo at gmail.com Fri Aug 8 14:43:35 2014 From: groleo at gmail.com (Adrian M Negreanu) Date: Fri, 8 Aug 2014 21:43:35 +0300 Subject: [CMake] Is it possible for a dependee to use the dependency LINKER_FLAGS ? In-Reply-To: References: Message-ID: On Thu, Aug 7, 2014 at 11:27 AM, Glenn Coombs wrote: > I just tried reproducing your 2 examples. Setup 1 works fine for me with > no messages about policy CMP0022. The only way I could get that message > produced was by omitting the cmake_minimum_required(VERSION 3.0) line. Are > you sure you're running the exact same CMakeLists.txt file that you have > posted here ? > Right. I must've messed the copy-paste; I see no cmake warnings either. > > For setup 2 I get the same results as you. CMake seems to insist on > converting the forward slash into a backwards slash, probably because it > thinks it is a file path, which totally screws things up. I suspect this > is a bug in cmake: adding linker flags like this works for linux because it > doesn't mess with strings like "-Wl,-Bstatic". The only workaround I can > suggest is to set CMAKE_EXE_LINKER_FLAGS: > > if (MSVC) > set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} > /FORCE:Multiple") > endif() > This indeed was my first reaction too, but it's becoming '/FORCE:multiple' specific. One other use case would be for a library to require a certain symbol to be undefined (-u for LD) I looked through the sources and there's no INTERFACE_LINK_FLAGS appended when the target construction is done. As a work-around I'm setting a variable which is either msvc or gcc specific. When I get the linker errors, I append the variable to the LINK_FLAGS of the erroneous target > > which correctly adds the option you want but it will do it for all > libraries in the current context. In order to only have it applied to the > one library you would need to have a separate CMakeLists.txt for that > library and add the lines above to adjust the CMAKE_EXE_LINKER_FLAGS only > in that CMakeLists.txt. Then you would have to do and > add_subdirectory(special_lib) somewhere in your higher level CMakeLists.txt. > > -- > Glenn > > > > On 3 August 2014 07:43, Adrian M Negreanu wrote: > >> I've tested this with vs 2013 but a few things makes me think >> that using target_link_libraries is not for this type of usage. >> >> First, for setup 1: >> ===== CMakeLists.txt ================ >> cmake_minimum_required(VERSION 3.0) >> >> add_library(A a.cpp) >> target_link_libraries(A INTERFACE -custom-flags) >> >> add_executable(E e.cpp) >> target_link_libraries(E A) >> ################################### >> >> Cmake warns me: >> >> CMake Warning (dev) in CMakeLists.txt: >> Policy CMP0022 is not set: INTERFACE_LINK_LIBRARIES defines the link >> interface. Run "cmake --help-policy CMP0022" for policy details. Use >> the >> cmake_policy command to set the policy and suppress this warning. >> >> Target "A" has an INTERFACE_LINK_LIBRARIES property. This should be >> preferred as the source of the link interface for this library but >> because >> CMP0022 is not set CMake is ignoring the property and using the link >> implementation as the link interface instead. >> >> INTERFACE_LINK_LIBRARIES: >> >> /FORCE:multiple >> >> >> For setup 2: >> ===== CMakeLists.txt ================ >> cmake_minimum_required(VERSION 3.0) >> add_library(A a.cpp) >> set_target_properties(A PROPERTIES INTERFACE_LINK_LIBRARIES >> "/FORCE:multiple") >> >> add_executable(E e.cpp) >> target_link_libraries(E A) >> ################################### >> >> >> Cmake works fine, _but_ "/FORCE:multiple" is seen as a file, which leads >> to error: >> >> 1>------ Build started: Project: ZERO_CHECK, Configuration: Debug Win32 >> ------ >> 2>------ Build started: Project: A, Configuration: Debug Win32 ------ >> 2> A.vcxproj -> C:\Users\amnegrea\Debug\A.lib >> 3>------ Build started: Project: E, Configuration: Debug Win32 ------ >> 3>LINK : fatal error LNK1104: cannot open file '\FORCE:multiple.obj' >> 4>------ Skipped Build: Project: ALL_BUILD, Configuration: Debug Win32 >> ------ >> 4>Project not selected to build for this solution configuration >> ========== Build: 2 succeeded, 1 failed, 0 up-to-date, 1 skipped >> ========== >> >> >> >> >> >> On Sat, Aug 2, 2014 at 7:38 PM, Walter Gray wrote: >> >>> Glen is correct. You should take a look at the docs for interface >>> modules here: >>> >>> >>> http://www.cmake.org/cmake/help/v3.0/manual/cmake-buildsystem.7.html#interface-libraries >>> >>> I also put up some examples of how to do this on github a while back. >>> >>> https://github.com/wal-rus/cmake-modules >>> >>> Hope that helps! Also for future googling the concept is called Usage >>> Requirements. >>> On Aug 2, 2014 8:11 AM, "Glenn Coombs" wrote: >>> >>>> I think that you can use the target_link_libraries command to do this: >>>> >>>> add_library(A a.cpp) >>>> target_link_libraries(A INTERFACE -custom-flags) >>>> >>>> -- >>>> Glenn >>>> >>>> >>>> >>>> On 30 July 2014 16:51, Adrian M Negreanu wrote: >>>> >>>>> Hi, >>>>> >>>>> Is it possible to attach a property on a target, and that property >>>>> to be used whenever the target is used ? >>>>> >>>>> ex: >>>>> >>>>> add_library(A a.cpp) >>>>> somehow_attach_LINK_FLAGS(A "--custom-flags") >>>>> >>>>> # in a different directory >>>>> add_executable(E e.cpp) >>>>> target_link_libraries(E A) >>>>> # ^--- this would do something similiar to >>>>> set_target_properties(E PROPERTIES LINK_FLAGS "--custom-flags") >>>>> >>>>> For example, to use A:LINK_FLAGS >>>>> >>>>> 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 >>>>> >>>> >>>> >>>> -- >>>> >>>> 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 >>>> >>> >> >> >> -- >> Regards! >> http://groleo.wordpress.com >> > > -- Regards! http://groleo.wordpress.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From jmerkow at gmail.com Fri Aug 8 15:28:38 2014 From: jmerkow at gmail.com (jmerkow) Date: Fri, 8 Aug 2014 12:28:38 -0700 (PDT) Subject: [CMake] Question regarding External Project add and VTK In-Reply-To: <1407446342430-7588095.post@n2.nabble.com> References: <1401833063339-7587571.post@n2.nabble.com> <8D14DEFF7FB0297-1DEC-54AAF@webmail-vm052.sysops.aol.com> <1402277995826-7587601.post@n2.nabble.com> <1402297580345.7a49d3d7@Nodemailer> <1402851665772-7587690.post@n2.nabble.com> <1403199806493-7587722.post@n2.nabble.com> <1407446342430-7588095.post@n2.nabble.com> Message-ID: Ahh, I believe I answered my own question. There seems to be a new function, ExternalProject_Install_CMake, Im testing it out now. Thanks! -Jameson On Thu, Aug 7, 2014 at 2:19 PM, jmerkow [via CMake] < ml-node+s3232098n7588095h33 at n2.nabble.com> wrote: > Jc, > > I guess I spoke too soon on my 'last question.' How does make install > work with this superbuild system. > Looking at slicer and ctk, they seem to set INSTALL_COMMAND to "" in their > superbuild.cmake, but presumably these packages still install even with > superbuild mode on. > > Can you offer any advice? > > -Jameson > > > ------------------------------ > If you reply to this email, your message will be added to the discussion > below: > > http://cmake.3232098.n2.nabble.com/Question-regarding-External-Project-add-and-VTK-tp7587557p7588095.html > To unsubscribe from Question regarding External Project add and VTK, click > here > > . > NAML > > -- View this message in context: http://cmake.3232098.n2.nabble.com/Question-regarding-External-Project-add-and-VTK-tp7587557p7588100.html Sent from the CMake mailing list archive at Nabble.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcel.loose at zonnet.nl Sat Aug 9 09:46:25 2014 From: marcel.loose at zonnet.nl (Marcel Loose) Date: Sat, 09 Aug 2014 15:46:25 +0200 Subject: [CMake] How to deal with incompatible changes in interface of target_link_libraries()? Message-ID: <53E62631.9060500@zonnet.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all, I'm struggling with the problem that CMake 2.8.12 introduced incompatible changes in the interface of target_link_libraries() w.r.t. dealing with direct and indirect (transitive) link dependencies. Pre-2.8.12 you would use the keyword LINK_INTERFACE_LIBRARIES to indicate indirect link dependencies. CMake 2.8.12 introduced the keywords PRIVATE, INTERFACE and PUBLIC, and immediately deprecated the LINK_INTERFACE_LIBRARIES keyword, triggering policy warnings CMP0022 and CMP0023. What is the proper way to get rid of these policy warnings, while at the same time staying backward compatible with older CMake versions? I need to support all 2.8.x versions, but I don't want to set these policies to OLD. I also don't want to wrap each call to target_link_libraries() inside a conditional if (${CMAKE_VERSION} VERSION_LESS 2.8.12) ... else() ... endif() Of course I could put this logic in a macro, but how then do I handle the new keywords. Some hints or tips would be very much appreciated. Kind regards, Marcel Loose. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJT5iYxAAoJEEpMyb1AIWdYFR4IAJXH0KV9dc8cCPItf2R1UTTS dkdvoqJtRRqKIS/fyQv4VHsbqP0DqH9qlCjc6O6h27I461PUwwfk+hYNDQI+q5wH SKu3kosT4rIxDg+CmGr/yhzSdzuWKyhRu+L4syunoOxeXXreKSzSIrTvdRA1fPZg aSJR4hvnA5cDUA/0pdV9pPKm4JATK8s2/S64PPjA2CRbq6pZfnnX4tRrQMnkt/+S R1xmmVVzcuctdIAdanUnDlTfRHMNOyY3uWozXkO2OCeTFJLc00xQcvJdcr2zXyRx EtvpFVmBU9IsAu4LY3gZZfjWwpwsMyYptaYSSF7oDJjshw5LctObJZ89jgFhtmw= =RhRJ -----END PGP SIGNATURE----- From arindam.mukerjee at gmail.com Mon Aug 11 06:56:28 2014 From: arindam.mukerjee at gmail.com (Arindam Mukherjee) Date: Mon, 11 Aug 2014 16:26:28 +0530 Subject: [CMake] Setting variables in included cmake module files Message-ID: I have a listfile CMakeLists.txt which includes two cmake modules - vardefs.cmake and unix.cmake, both of which are included by the list file from some path set using CMAKE_MODULE_PATH. I set some variables in vardefs.cmake which I am trying to use in the list file and in unix.cmake. Looks like it is not available in unix.cmake. Is there a way to fix this? Thanks, Arindam From alexey.petruchik at gmail.com Mon Aug 11 10:45:23 2014 From: alexey.petruchik at gmail.com (Alexey Petruchik) Date: Mon, 11 Aug 2014 17:45:23 +0300 Subject: [CMake] Why there is not MSI installer for CMake? Message-ID: It is well known that msi installers are more preferable way of distributing apps on Windows than exe installers. For example msi packages can be installed silently from command line. So why there is no msi package for cmake? Regards, Alexey -------------- next part -------------- An HTML attachment was scrubbed... URL: From sergey.nikulov at gmail.com Mon Aug 11 10:52:04 2014 From: sergey.nikulov at gmail.com (Sergei Nikulov) Date: Mon, 11 Aug 2014 18:52:04 +0400 Subject: [CMake] Why there is not MSI installer for CMake? In-Reply-To: References: Message-ID: 2014-08-11 18:45 GMT+04:00 Alexey Petruchik : > It is well known that msi installers are more preferable way of > distributing apps on Windows than exe installers. For example msi packages > can be installed silently from command line. So why there is no msi package > for cmake? > > Regards, Alexey > http://www.cmake.org/cmake/help/v3.0/module/CPackWIX.html > -- > > 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 dlrdave at aol.com Mon Aug 11 11:12:51 2014 From: dlrdave at aol.com (David Cole) Date: Mon, 11 Aug 2014 11:12:51 -0400 (EDT) Subject: [CMake] Why there is not MSI installer for CMake? In-Reply-To: References: Message-ID: <8D1838DDA48C684-734-11B87@webmail-m233.sysops.aol.com> If silently installing is your objective, you may do so with an NSIS built *.exe installer. See this old blog post for details: http://www.kitware.com/blog/home/post/186 HTH, David C. From brad.king at kitware.com Mon Aug 11 12:47:38 2014 From: brad.king at kitware.com (Brad King) Date: Mon, 11 Aug 2014 12:47:38 -0400 Subject: [CMake] How to deal with incompatible changes in interface of target_link_libraries()? In-Reply-To: <53E62631.9060500@zonnet.nl> References: <53E62631.9060500@zonnet.nl> Message-ID: <53E8F3AA.40002@kitware.com> On 08/09/2014 09:46 AM, Marcel Loose wrote: > CMake 2.8.12 introduced the keywords PRIVATE, INTERFACE and PUBLIC, and > immediately deprecated the LINK_INTERFACE_LIBRARIES keyword, > triggering policy warnings CMP0022 and CMP0023. > > What is the proper way to get rid of these policy warnings, while at > the same time staying backward compatible with older CMake versions? >From the documentation of CMP0022: "Warning-free future-compatible code which works with CMake 2.8.9 onwards can be written by using the LINK_PRIVATE and LINK_PUBLIC keywords of target_link_libraries()." Actually it should say 2.8.7, not 2.8.9. CMP0023 docs mention 2.8.7. -Brad From rodrigo.faccioli at gmail.com Mon Aug 11 16:01:40 2014 From: rodrigo.faccioli at gmail.com (Rodrigo Faccioli) Date: Mon, 11 Aug 2014 17:01:40 -0300 Subject: [CMake] Help cmake First project In-Reply-To: References: <53DFACD1.6050807@kitware.com> <84766c09-e75c-458b-a175-6b130d9a865e@email.android.com> Message-ID: Hi, Angeliki, thanks your comments. I used properties because my old makefile was written to use g++ despite my files have suffix .c. I understood that cmake tried to compile my files using gcc instead of g++. I removed my set compiler flags. Moreover, I have finished to compile all programs of my project using cmake. My newer CMakeLists.txt is below and works fine. Now I will try to compile my project for Visual Studio 10. Any tips for this new work, I am thankful. cmake_minimum_required(VERSION 2.8) # project Information project(2pg_cartesian) set(PROJECT_VERSION "1.0") #Set CXX compiler for all files below set_source_files_properties(include/LoadConfig.h PROPERTIES LANGUAGE CXX ) set_source_files_properties(src/protpred-Gromacs-NSGA2.c PROPERTIES LANGUAGE CXX ) set_source_files_properties(src/protpred-Gromacs-Dominance.c PROPERTIES LANGUAGE CXX ) set_source_files_properties(src/protpred-Gromacs-Front.c PROPERTIES LANGUAGE CXX ) set_source_files_properties(src/protpred-Gromacs-MC_Metropolis.c PROPERTIES LANGUAGE CXX ) set_source_files_properties(src/protpred-Gromacs-Mono.c PROPERTIES LANGUAGE CXX ) set_source_files_properties(src/protpred-Gromacs-Random_Algorithm.c PROPERTIES LANGUAGE CXX ) set_source_files_properties(src/protpred-Gromacs-Sort_Method_Files_by_Front_Dominance.c PROPERTIES LANGUAGE CXX ) set_source_files_properties(src/LoadConfig.cpp PROPERTIES LANGUAGE CXX ) set_source_files_properties(src/ea_mono.c PROPERTIES LANGUAGE CXX ) set_source_files_properties(src/topology.c PROPERTIES LANGUAGE CXX ) set_source_files_properties(src/pdbio.c PROPERTIES LANGUAGE CXX ) set_source_files_properties(src/protein.c PROPERTIES LANGUAGE CXX ) set_source_files_properties(src/futil.c PROPERTIES LANGUAGE CXX ) set_source_files_properties(src/pdbatom.c PROPERTIES LANGUAGE CXX ) set_source_files_properties(src/messages.c PROPERTIES LANGUAGE CXX ) set_source_files_properties(src/topologyio.c PROPERTIES LANGUAGE CXX ) set_source_files_properties(src/topologylib.c PROPERTIES LANGUAGE CXX ) set_source_files_properties(src/randomlib.c PROPERTIES LANGUAGE CXX ) set_source_files_properties(src/vector_math.c PROPERTIES LANGUAGE CXX ) set_source_files_properties(src/string_owner.c PROPERTIES LANGUAGE CXX ) set_source_files_properties(src/math_owner.c PROPERTIES LANGUAGE CXX ) set_source_files_properties(src/osutil.c PROPERTIES LANGUAGE CXX ) set_source_files_properties(src/load_parameters.c PROPERTIES LANGUAGE CXX ) set_source_files_properties(src/objective.c PROPERTIES LANGUAGE CXX ) set_source_files_properties(src/aminoacids.c PROPERTIES LANGUAGE CXX ) set_source_files_properties(src/aminoacids_io.c PROPERTIES LANGUAGE CXX ) set_source_files_properties(src/populationio.c PROPERTIES LANGUAGE CXX ) set_source_files_properties(src/rotation.c PROPERTIES LANGUAGE CXX ) set_source_files_properties(src/solution.c PROPERTIES LANGUAGE CXX ) set_source_files_properties(src/gromacs_objectives.c PROPERTIES LANGUAGE CXX ) set_source_files_properties(src/solutionio.c PROPERTIES LANGUAGE CXX ) set_source_files_properties(src/algorithms.c PROPERTIES LANGUAGE CXX ) set_source_files_properties(src/ea_nsga2.c PROPERTIES LANGUAGE CXX ) set_source_files_properties(src/dominance.c PROPERTIES LANGUAGE CXX ) set_source_files_properties(src/owner_file_analysis.c PROPERTIES LANGUAGE CXX ) set_source_files_properties(src/mc_metropolis.c PROPERTIES LANGUAGE CXX ) set_source_files_properties(src/random_algorithm.c PROPERTIES LANGUAGE CXX ) # set include include_directories(include) # add libries add_library(2PG_lib STATIC src/LoadConfig.cpp src/ea_mono.c src/topology.c src/pdbio.c src/protein.c src/futil.c src/pdbatom.c src/messages.c src/topologyio.c src/topologylib.c src/randomlib.c src/vector_math.c src/string_owner.c src/math_owner.c src/osutil.c src/load_parameters.c src/objective.c src/aminoacids.c src/aminoacids_io.c src/populationio.c src/rotation.c src/solution.c src/gromacs_objectives.c src/solutionio.c src/algorithms.c src/ea_nsga2.c src/dominance.c src/owner_file_analysis.c src/mc_metropolis.c src/random_algorithm.c ) #end of 2PG_lib # add target add_executable(protpred-Gromacs-NSGA2 src/protpred-Gromacs-NSGA2.c) target_link_libraries(protpred-Gromacs-NSGA2 2PG_lib) add_executable(protpred-Gromacs-Dominance src/protpred-Gromacs-Dominance.c) target_link_libraries(protpred-Gromacs-Dominance 2PG_lib) add_executable(protpred-Gromacs-Front src/protpred-Gromacs-Front.c) target_link_libraries(protpred-Gromacs-Front 2PG_lib) add_executable(protpred-Gromacs-MC_Metropolis src/protpred-Gromacs-MC_Metropolis.c) target_link_libraries(protpred-Gromacs-MC_Metropolis 2PG_lib) add_executable(protpred-Gromacs-Mono src/protpred-Gromacs-Mono.c) target_link_libraries(protpred-Gromacs-Mono 2PG_lib) add_executable(protpred-Gromacs-Random_Algorithm src/protpred-Gromacs-Random_Algorithm.c) target_link_libraries(protpred-Gromacs-Random_Algorithm 2PG_lib) add_executable(protpred-Gromacs-Sort_Method_Files_by_Front_Dominance src/protpred-Gromacs-Sort_Method_Files_by_Front_Dominance.c) target_link_libraries(protpred-Gromacs-Sort_Method_Files_by_Front_Dominance 2PG_lib) # install install(TARGETS protpred-Gromacs-NSGA2 DESTINATION bin) install(TARGETS protpred-Gromacs-Dominance DESTINATION bin) install(TARGETS protpred-Gromacs-Front DESTINATION bin) install(TARGETS protpred-Gromacs-MC_Metropolis DESTINATION bin) install(TARGETS protpred-Gromacs-Mono DESTINATION bin) install(TARGETS protpred-Gromacs-Random_Algorithm DESTINATION bin) install(TARGETS protpred-Gromacs-Sort_Method_Files_by_Front_Dominance DESTINATION bin) Best regards, -- Rodrigo Antonio Faccioli, Ph.D Development Software for Structural Bioinformatics Barao de Maua University University of Sao Paulo Lindedin - br.linkedin.com/pub/rodrigo-antonio-faccioli/7/589/a5/ Curriculum Lattes - http://lattes.cnpq.br/1025157978990218 On Wed, Aug 6, 2014 at 5:32 AM, Angeliki Chrysochou < angeliki.chrysochou at gmail.com> wrote: > Hi Rodrigo, > > Glad that it is working for you now. I just wanted to mention that I never > had to set the language as properties to the source files since cmake > detects it from the suffix of the source files you list, or at least I > never had a case where the language was not properly detected. > > Other than that I agree with Hendrik's suggestions as well! > > Cheers, > Angeliki > > > > > > > On Wed, Aug 6, 2014 at 5:54 AM, Hendrik Sattler > wrote: > >> Hi, >> >> -lm does not belong to CMAKE_CXX_FLAGS as it is a linker option to link >> libm. >> Use >> target_link_libraries(protpred-Gromacs-NSGA2 m) >> instead. (Don't search for libm, the linker knows where it is.) >> >> It is also more common to use a variable for the list of source files. >> That would make it also possible to set the compile language for all files >> in one command without listing files twice. >> >> Adding headers and not just .c/.cpp/.cxx files makes it easier when using >> an IDE. >> >> >> >> On 5. August 2014 22:13:54 MESZ, Rodrigo Faccioli < >> rodrigo.faccioli at gmail.com> wrote: >> >Hi, >> > >> >I am thankfull for all help. Now, it is working :-) >> > >> >Radovan, thank you to try to run and your comments. >> > >> >My CMakeList.txt is showed below. I would like to know about best >> >practice >> >to make a CMakeList. If agree, I will compile others executables of my >> >project based on how I compiled this executable. In [1] contains my >> >full >> >project. >> > >> >cmake_minimum_required(VERSION 2.8) >> > >> ># project Information >> >project(2pg_cartesian) >> >set(PROJECT_VERSION "1.0") >> > >> ># Set compiler flags >> >SET ( CMAKE_CXX_FLAGS "-lm -pedantic") >> > >> >#Set CXX compiler for all files below >> >set_source_files_properties(include/LoadConfig.h PROPERTIES LANGUAGE >> >CXX ) >> >set_source_files_properties(src/protpred-Gromacs-NSGA2.c PROPERTIES >> >LANGUAGE CXX ) >> >set_source_files_properties(src/LoadConfig.cpp PROPERTIES LANGUAGE CXX >> >) >> >set_source_files_properties(src/ea_mono.c PROPERTIES LANGUAGE CXX ) >> >set_source_files_properties(src/topology.c PROPERTIES LANGUAGE CXX ) >> >set_source_files_properties(src/pdbio.c PROPERTIES LANGUAGE CXX ) >> >set_source_files_properties(src/protein.c PROPERTIES LANGUAGE CXX ) >> >set_source_files_properties(src/futil.c PROPERTIES LANGUAGE CXX ) >> >set_source_files_properties(src/pdbatom.c PROPERTIES LANGUAGE CXX ) >> >set_source_files_properties(src/messages.c PROPERTIES LANGUAGE CXX ) >> >set_source_files_properties(src/topologyio.c PROPERTIES LANGUAGE CXX ) >> >set_source_files_properties(src/topologylib.c PROPERTIES LANGUAGE CXX >> >) >> >set_source_files_properties(src/randomlib.c PROPERTIES LANGUAGE CXX ) >> >set_source_files_properties(src/vector_math.c PROPERTIES LANGUAGE CXX >> >) >> >set_source_files_properties(src/string_owner.c PROPERTIES LANGUAGE CXX >> >) >> >set_source_files_properties(src/math_owner.c PROPERTIES LANGUAGE CXX >> >) >> >set_source_files_properties(src/osutil.c PROPERTIES LANGUAGE CXX ) >> >set_source_files_properties(src/load_parameters.c PROPERTIES LANGUAGE >> >CXX ) >> >set_source_files_properties(src/objective.c PROPERTIES LANGUAGE CXX ) >> >set_source_files_properties(src/aminoacids.c PROPERTIES LANGUAGE CXX ) >> >set_source_files_properties(src/aminoacids_io.c PROPERTIES LANGUAGE >> >CXX ) >> >set_source_files_properties(src/populationio.c PROPERTIES LANGUAGE CXX >> >) >> >set_source_files_properties(src/rotation.c PROPERTIES LANGUAGE CXX ) >> >set_source_files_properties(src/solution.c PROPERTIES LANGUAGE CXX ) >> >set_source_files_properties(src/gromacs_objectives.c PROPERTIES >> >LANGUAGE >> >CXX ) >> >set_source_files_properties(src/solutionio.c PROPERTIES LANGUAGE CXX ) >> >set_source_files_properties(src/algorithms.c PROPERTIES LANGUAGE CXX ) >> >set_source_files_properties(src/ea_nsga2.c PROPERTIES LANGUAGE CXX ) >> >set_source_files_properties(src/dominance.c PROPERTIES LANGUAGE CXX ) >> > >> ># set include >> >include_directories(include) >> > >> ># add libries >> >add_library(2PG-NSGA2_lib STATIC >> >src/LoadConfig.cpp >> >src/ea_mono.c >> >src/topology.c >> >src/pdbio.c >> >src/protein.c >> >src/futil.c >> >src/pdbatom.c >> >src/messages.c >> >src/topologyio.c >> >src/topologylib.c >> >src/randomlib.c >> >src/vector_math.c >> >src/string_owner.c >> >src/math_owner.c >> >src/osutil.c >> >src/load_parameters.c >> >src/objective.c >> >src/aminoacids.c >> >src/aminoacids_io.c >> >src/populationio.c >> >src/rotation.c >> >src/solution.c >> >src/gromacs_objectives.c >> >src/solutionio.c >> >src/algorithms.c >> >src/ea_nsga2.c >> >src/dominance.c >> >) #end of 2PG-NSGA2_lib >> > >> ># add target >> >add_executable(protpred-Gromacs-NSGA2 src/protpred-Gromacs-NSGA2.c) >> >target_link_libraries(protpred-Gromacs-NSGA2 2PG-NSGA2_lib) >> > >> ># install >> >install(TARGETS protpred-Gromacs-NSGA2 DESTINATION bin) >> > >> >[1] https://dl.dropboxusercontent.com/u/4270818/2pg_cartesian_cmake.zip >> > >> >Best regards, >> > >> >-- >> >Rodrigo Antonio Faccioli, Ph.D >> >Development Software for Structural Bioinformatics >> >Barao de Maua University >> >University of Sao Paulo >> >Lindedin - br.linkedin.com/pub/rodrigo-antonio-faccioli/7/589/a5/ >> >Curriculum Lattes - http://lattes.cnpq.br/1025157978990218 >> > >> > >> >On Tue, Aug 5, 2014 at 3:39 PM, radovan bast wrote: >> > >> >> dear Rodrigo, >> >> >> >> i tried it but ran into many other problems in the source, not cmake. >> >> >> >> but also some cmake suggestions: >> >> - list the language(s) that the project uses >> >> - the c99 flag is not a definition but a compiler flag, use >> >> CMAKE_CXX_FLAGS_... for portability >> >> - "ALL" is not a good library name >> >> - i recommend to not glob sources but to list them explicitly, there >> >are >> >> several discussions on the net >> >> which explain why if you search for the topic >> >> >> >> good luck! >> >> radovan >> >> >> >> >> >> On Tue, Aug 5, 2014 at 5:08 PM, Rodrigo Faccioli < >> >> rodrigo.faccioli at gmail.com> wrote: >> >> >> >>> Hi, >> >>> >> >>> Thanks Angeliki and Bill for your attentation. >> >>> >> >>> I have updated my CMakeList.txt based on your post. Below my >> >>> CMakeList.txt is showed. >> >>> >> >>> cmake_minimum_required(VERSION 2.8) >> >>> # project Information >> >>> project(2pg_cartesian) >> >>> set(PROJECT_VERSION "1.0") >> >>> # add definitions to compiler >> >>> add_definitions(-std=c99) >> >>> # get all files under directory src >> >>> file(GLOB SRC_FILES "src/*.c") >> >>> # set include >> >>> include_directories(include) >> >>> # added libries >> >>> add_library(ALL STATIC ${SRC_FILES}) >> >>> # add target >> >>> add_executable(protpred-Gromacs-NSGA2 src/protpred-Gromacs-NSGA2.c) >> >>> target_link_libraries(protpred-Gromacs-NSGA2 ALL) >> >>> >> >>> Unfortunatelly, I have received error messages as cited below: >> >>> faccioli at faccioli:~/Downloads/2pg_cartesian/build$ make >> >>> Scanning dependencies of target ALL >> >>> [ 2%] Building C object >> >CMakeFiles/ALL.dir/src/protpred-Gromacs-NSGA2.c.o >> >>> [ 5%] Building C object CMakeFiles/ALL.dir/src/ea_mono.c.o >> >>> [ 7%] Building C object CMakeFiles/ALL.dir/src/topologyio.c.o >> >>> [ 10%] Building C object CMakeFiles/ALL.dir/src/aminoacids.c.o >> >>> [ 12%] Building C object CMakeFiles/ALL.dir/src/populationio.c.o >> >>> [ 15%] Building C object CMakeFiles/ALL.dir/src/osutil.c.o >> >>> [ 17%] Building C object CMakeFiles/ALL.dir/src/aminoacids_io.c.o >> >>> [ 20%] Building C object >> >>> >> >> >CMakeFiles/ALL.dir/src/protpred-Gromacs-Sort_Method_Files_by_Front_Dominance.c.o >> >>> [ 23%] Building C object CMakeFiles/ALL.dir/src/pdbio.c.o >> >>> [ 25%] Building C object CMakeFiles/ALL.dir/src/solution.c.o >> >>> [ 28%] Building C object CMakeFiles/ALL.dir/src/vector_math.c.o >> >>> [ 30%] Building C object CMakeFiles/ALL.dir/src/math_owner.c.o >> >>> [ 33%] Building C object CMakeFiles/ALL.dir/src/protein.c.o >> >>> [ 35%] Building C object CMakeFiles/ALL.dir/src/load_parameters.c.o >> >>> In file included from >> >>> /home/faccioli/Downloads/2pg_cartesian/src/load_parameters.c:7:0: >> >>> /home/faccioli/Downloads/2pg_cartesian/include/LoadConfig.h:1:18: >> >fatal >> >>> error: string: Arquivo ou diret?rio n?o encontrado >> >>> compilation terminated. >> >>> make[2]: ** [CMakeFiles/ALL.dir/src/load_parameters.c.o] Erro 1 >> >>> make[1]: ** [CMakeFiles/ALL.dir/all] Erro 2 >> >>> make: ** [all] Erro 2 >> >>> faccioli at faccioli:~/Downloads/2pg_cartesian/build$ >> >>> >> >>> I did not understand what mistakes I have done since all files share >> >same >> >>> structure of directory. In [1] is my project completly. If prefer I >> >can >> >>> send its github repository. >> >>> >> >>> I appreciate any help. >> >>> >> >>> Best regards, >> >>> >> >>> [1] >> >https://dl.dropboxusercontent.com/u/4270818/2pg_cartesian_cmake.zip >> >>> >> >>> >> >>> -- >> >>> Rodrigo Antonio Faccioli, Ph.D >> >>> Development Software for Structural Bioinformatics >> >>> Barao de Maua University >> >>> University of Sao Paulo >> >>> Lindedin - br.linkedin.com/pub/rodrigo-antonio-faccioli/7/589/a5/ >> >>> Curriculum Lattes - http://lattes.cnpq.br/1025157978990218 >> >>> >> >>> >> >>> On Mon, Aug 4, 2014 at 12:54 PM, Bill Hoffman >> > >> >>> wrote: >> >>> >> >>>> On 8/4/2014 10:26 AM, Rodrigo Faccioli wrote: >> >>>> >> >>>>> protpred-Gromacs-NSGA2.c:(.text+0x1e): undefined reference to >> >>>>> `display_msg' >> >>>>> protpred-Gromacs-NSGA2.c:(.text+0x3e): undefined reference to >> >>>>> `load_parameters_from_file' >> >>>>> protpred-Gromacs-NSGA2.c:(.text+0x58): undefined reference to >> >>>>> `ea_nsga2' >> >>>>> protpred-Gromacs-NSGA2.c:(.text+0x64): undefined reference to >> >>>>> `fatal_error' >> >>>>> protpred-Gromacs-NSGA2.c:(.text+0x73): undefined reference to >> >>>>> `deAllocateload_parameters' >> >>>>> protpred-Gromacs-NSGA2.c:(.text+0x7d): undefined reference to >> >>>>> `display_msg' >> >>>>> >> >>>> You have to find out where these symbols are defined. If you have >> >a >> >>>> working Makefile version use nm and grep to find the places. You >> >can also >> >>>> grep your source tree. You are either missing a source file, or a >> >-D >> >>>> option. >> >>>> >> >>>> Another approach is to run make VERBOSE=1 and compare the build >> >command >> >>>> lines to your Makefile build. >> >>>> >> >>>> -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 >> >>>> >> >>> >> >>> >> >>> -- >> >>> >> >>> 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 >> >>> >> >> >> >> >> >> >> >> -- >> >> # PDC Center for High Performance Computing & >> >> # Department of Theoretical Chemistry and Biology >> >> # Royal Institute of Technology, Stockholm >> >> # +46-8-790-6628 >> >> >> > >> > >> >------------------------------------------------------------------------ >> >> >> -- >> >> 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 cvolpe at ara.com Mon Aug 11 19:25:41 2014 From: cvolpe at ara.com (Chris Volpe ARA/SED) Date: Mon, 11 Aug 2014 23:25:41 +0000 Subject: [CMake] Possible bug in environment variable expansion? Message-ID: <7B8A49496E564B4781559C6C1AEB79338E3A5872@colo-mail-2.exchange2.ara.wan> I am trying to build an Open Source project called PCL which uses Boost, and CMake's ability to find the Boost libraries seems dependent on whether the BOOST_LIBRARYDIR contains a literal path string, or whether it contains a string that incorporates the expansion of BOOST_ROOT. Here are the details: Boost is installed from a pre-built installer in the folder C:\local\boost_1_55_0. This folder contains, among other things, a subfolder called "boost", which contains the headers, and a subfolder called "lib64-msvc-12.0", which contains 64-bit libraries built with MS Visual Studio 2013. Ordinarily, CMake would like that folder to be called simply "lib", but that's not what the installer created, so I'm trying to override the default with environment variables. I have the following three environment variables defined, all of which are of type "Expandable string": BOOST_ROOT=C:\local\boost_1_55_0 BOOST_INCLUDEDIR=%BOOST_ROOT% BOOST_LIBRARYDIR=%BOOST_ROOT%\lib64-msvc-12.0 With these settings, CMake reports an error during the configuration process, as follows: CMake Error at C:/Program Files (x86)/CMake/share/cmake-3.0/Modules/FindBoost.cmake:1179 (message): Unable to find the requested Boost libraries. Boost version: 1.55.0 Boost include path: C:/local/boost_1_55_0 Could not find the following Boost libraries: boost_system boost_filesystem boost_thread boost_date_time boost_iostreams boost_chrono No Boost libraries were found. You may need to set BOOST_LIBRARYDIR to the directory containing Boost libraries or BOOST_ROOT to the location of Boost. Call Stack (most recent call first): cmake/pcl_find_boost.cmake:38 (find_package) CMakeLists.txt:230 (include) But if change the definition of BOOST_LIBRARYDIR by replacing "%BOOST_ROOT%" with the value assigned to BOOST_ROOT, resulting in this: BOOST_LIBRARYDIR=C:\local\boost_1_55_0\lib64-msvc-12.0 the configuration succeeds. The only difference seems to be whether the "C:\local\boost_1_55_0" part of the path is specified explicitly, or obtained implicitly with %BOOST_ROOT%. It would surprise me if this behavior were by design. Does anyone have an explanation for this? Thanks, Chris Christopher R. Volpe, Ph.D. Senior Scientist, Remote Sensing & Decision Analytics [Description: Description: cid:image003.png at 01CE888B.0167BAD0] NATIONAL SECURITY | INFRASTRUCTURE | ENERGY & ENVIRONMENT | HEALTH SOLUTIONS Applied Research Associates, Inc. 8537 Six Forks Road, Suite 600, Raleigh, NC 27615 | T 919.582.3380 | F 919.582.3301 Find Us Online www.ara.com Facebook: Applied Research Associates LinkedIn: Company Page LinkedIn Group Twitter: ARA News YouTube: Applied Research Associates -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 9687 bytes Desc: image001.png URL: From mark.j.abraham at gmail.com Mon Aug 11 23:13:26 2014 From: mark.j.abraham at gmail.com (Mark Abraham) Date: Mon, 11 Aug 2014 20:13:26 -0700 Subject: [CMake] how to really change CMake linker Message-ID: Hi, In order to build an application with several HPC performance utilities, it would be good to be able to specify the linker and have it show up on the link command line. I learned from http://cmake.3232098.n2.nabble.com/Specify-the-link-command-in-CMake-td6786695.html that using CMAKE_C_LINKER_EXECUTABLE and CMAKE_CXX_LINKER_EXECUTABLE is not the right approach, because you have to specify the entire link line, not just the linker. cmake -DCMAKE_LINKER=/path/to/my/linker seems like it should be the right way to do this, yet the C++ compiler ends up on the link line, not the linker I specified (which has a different name, of course). http://stackoverflow.com/questions/1867745/cmake-use-a-custom-linker is having the same experience. How should this be accomplished reliably? Thanks! Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: From ravi.raman at Xoriant.Com Mon Aug 11 23:20:50 2014 From: ravi.raman at Xoriant.Com (Ravi Raman) Date: Tue, 12 Aug 2014 03:20:50 +0000 Subject: [CMake] Cmake issue regarding conversion of existing Visual Studio .targets files to cmake References: <8D17B98D58C24C4-BD0-159DA@webmail-d258.sysops.aol.com> Message-ID: Hi David, Executing the batch file from cmake function add_custom_command() in the COMMAND option is successful. But is there any mechanism in cmake in which we can specify the user-built executables OR project-specific executables directly from cmake function add_custom_command() in the COMMAND option ? Like, for example, if we want to execute something like this in cmake: add_custom_command( TARGET ${TARGETNAME} POST_BUILD COMMAND ${VERBIN}/TestVersion.exe \"$(VersionPath)\" COMMENT "Check if $(VersionPath) has version information...") Note that here ${VERBIN}/TestVersion.exe is a project specific executable. When we execute this in cmake, we get the following error: 'TestVer\TestVersion.exe' is not recognized as an internal or external command,operable program or batch file. So, please let us know if there is any way other than batch file for this ? Thanks & Regards Ravi Raman Xoriant Solutions Pvt. Ltd 4th Floor, Winchester, Hiranandani Business Park, Powai, Mumbai 400076, INDIA. Tel: +91 22 30511000,9930100026 Extn: 2144 Voip No. 4088344495/96/97/98 Voip Extn:1178| Fax: +91 22 30511111 ravi.raman at xoriant.com| http://www.xoriant.com -----Original Message----- From: Ravi Raman Sent: Friday, August 01, 2014 8:01 PM To: 'David Cole' Cc: cmake at cmake.org Subject: RE: [CMake] Cmake issue regarding conversion of existing Visual Studio .targets files to cmake Hi David, Thanks. The 2nd approach of using batch file worked successfully. Thanks & Regards Ravi Raman Xoriant Solutions Pvt. Ltd 4th Floor, Winchester, Hiranandani Business Park, Powai, Mumbai 400076, INDIA. Tel: +91 22 30511000,9930100026 Extn: 2144 Voip No. 4088344495/96/97/98 Voip Extn:1178| Fax: +91 22 30511111 ravi.raman at xoriant.com| http://www.xoriant.com -----Original Message----- From: David Cole [mailto:dlrdave at aol.com] Sent: Friday, August 01, 2014 5:41 PM To: Ravi Raman Cc: cmake at cmake.org Subject: Re: [CMake] Cmake issue regarding conversion of existing Visual Studio .targets files to cmake Sorry about the premature "send" on that last email... First try this: add_custom_command( TARGET ${TARGETNAME} POST_BUILD COMMAND ${TBIN}/VerCheck.exe \"$(TargetPath)\" COMMAND copy \"$(TargetPath)\" \"$(TargetPath).vercheck_dummy_target\" COMMENT "Checking if $(TargetPath) has version info...") i.e. -- just say "POST_BUILD" once, then a sequence of COMMAND lines. (I think it's passing your second POST_BUILD as an argument to VerCheck...) If that still doesn't work, try: add_custom_command( TARGET ${TARGETNAME} POST_BUILD COMMAND VerCheckAndCopy.bat "${TBIN}" "$(TargetPath)" COMMENT "Checking if $(TargetPath) has version info...") and delegate it to a batch script that takes arguments which internally does the sequence of commands you want. If you go this route, you may still need nested quotes around "$(TargetPath)" -- CMake doesn't know about expanding those VS values, and whether or not they'll need quotes around them. HTH, David C. -------------- next part -------------- An HTML attachment was scrubbed... URL: From loose at astron.nl Tue Aug 12 03:59:33 2014 From: loose at astron.nl (Marcel Loose) Date: Tue, 12 Aug 2014 09:59:33 +0200 Subject: [CMake] How to deal with incompatible changes in interface of target_link_libraries()? In-Reply-To: <53E8F3AA.40002@kitware.com> References: <53E62631.9060500@zonnet.nl> <53E8F3AA.40002@kitware.com> Message-ID: <53E9C965.5000609@astron.nl> On 11/08/14 18:47, Brad King wrote: > On 08/09/2014 09:46 AM, Marcel Loose wrote: >> CMake 2.8.12 introduced the keywords PRIVATE, INTERFACE and PUBLIC, and >> immediately deprecated the LINK_INTERFACE_LIBRARIES keyword, >> triggering policy warnings CMP0022 and CMP0023. >> >> What is the proper way to get rid of these policy warnings, while at >> the same time staying backward compatible with older CMake versions? > From the documentation of CMP0022: > > "Warning-free future-compatible code which works with CMake 2.8.9 > onwards can be written by using the LINK_PRIVATE and LINK_PUBLIC > keywords of target_link_libraries()." > > Actually it should say 2.8.7, not 2.8.9. CMP0023 docs mention 2.8.7. > > -Brad Hi, Another problem I faced with policy CMP0022 is that I was unable to really silence it. Setting the policy to OLD doesn't really work (at least not in my case), maybe because the "cmake_policy()" command is scoped(?). I have a macro that contains the now deprecated use of LINK_INTERFACE_LIBRARIES, so I thought I could simply wrap that statement inside the following code block: if (POLICY CMP0022) cmake_policy(PUSH) cmake_policy(SET CMP0022 OLD) endif() target_link_libraries (... LINK_INTERFACE_LIBRARIES ...) if (POLICY CMP0022) cmake_policy(POP) endif() But that doesn't seem to work. I still get the policy warnings for CMP0022. Also setting the policy to OLD once at top-level doesn't seem to work; probably due to policy scoping. I played a bit with NO_POLICY_SCOPE to different include() and find_package() statements, but to no avail. Regards, Marcel Loose. -------------- next part -------------- A non-text attachment was scrubbed... Name: loose.vcf Type: text/x-vcard Size: 292 bytes Desc: not available URL: From loose at astron.nl Tue Aug 12 03:48:17 2014 From: loose at astron.nl (Marcel Loose) Date: Tue, 12 Aug 2014 09:48:17 +0200 Subject: [CMake] How to deal with incompatible changes in interface of target_link_libraries()? In-Reply-To: <53E8F3AA.40002@kitware.com> References: <53E62631.9060500@zonnet.nl> <53E8F3AA.40002@kitware.com> Message-ID: <53E9C6C1.9080204@astron.nl> On 11/08/14 18:47, Brad King wrote: > On 08/09/2014 09:46 AM, Marcel Loose wrote: >> CMake 2.8.12 introduced the keywords PRIVATE, INTERFACE and PUBLIC, and >> immediately deprecated the LINK_INTERFACE_LIBRARIES keyword, >> triggering policy warnings CMP0022 and CMP0023. >> >> What is the proper way to get rid of these policy warnings, while at >> the same time staying backward compatible with older CMake versions? > From the documentation of CMP0022: > > "Warning-free future-compatible code which works with CMake 2.8.9 > onwards can be written by using the LINK_PRIVATE and LINK_PUBLIC > keywords of target_link_libraries()." > > Actually it should say 2.8.7, not 2.8.9. CMP0023 docs mention 2.8.7. > > -Brad Hmm, That's probably in the CMake 3.0.x docs; CMake 2.8.12 doesn't mention LINK_PUBLIC and LINK_PRIVATE in the policy documentation. I only read the following in the docs on target_link_libraries The LINK_PUBLIC and LINK_PRIVATE modes can be used to specify both the link dependencies and the link interface in one command. This signature is for compatibility only. Prefer the PUBLIC or PRIVATE keywords instead. "... for compatibility only" didn't give me the feeling that this is the way to go, which is underscored by the next sentence: "Prefer the ..." On a side note. Even using the new PRIVATE and PUBLIC keywords I am unable to exactly specify which libraries are needed for linking. Without breaking builds with static libraries, I am forced to specify too many library dependencies. Maybe I'm doing something wrong, but my setup is quite complicated. Fortunately, modern version of ld will get rid of unused libraries anyway, so it's not really that much of an issue for me. Regards, Marcel Loose. -------------- next part -------------- A non-text attachment was scrubbed... Name: loose.vcf Type: text/x-vcard Size: 292 bytes Desc: not available URL: From dlrdave at aol.com Tue Aug 12 06:43:32 2014 From: dlrdave at aol.com (David Cole) Date: Tue, 12 Aug 2014 06:43:32 -0400 (EDT) Subject: [CMake] Cmake issue regarding conversion of existing Visual Studio .targets files to cmake Message-ID: <8D18431651CAD63-1D58-1EA0B@webmail-vm030.sysops.aol.com> From http://www.cmake.org/cmake/help/v3.0/command/add_custom_command.html : "If COMMAND specifies an executable target (created by ADD_EXECUTABLE) it will automatically be replaced by the location of the executable created at build time. Additionally a target-level dependency will be added so that the executable target will be built before any target using this custom command. However this does NOT add a file-level dependency that would cause the custom command to re-run whenever the executable is recompiled." So... if TestVersion.exe is created as a result of an "add_executable(TestVersion ..." call, then you should be able to use add_custom_command( TARGET ${TARGETNAME} POST_BUILD COMMAND TestVersion \"$(VersionPath)\" COMMENT "Check if $(VersionPath) has version information...") If you must pass the full path to TestVersion as an argument to a batch file, you should be able to use $ (again, assuming TestVersion is the name of your add_executable target) By the way, the error message "'TestVer\TestVersion.exe' is not recognized ..." is probably happening because the working directory is not set correctly relative to the name "TestVer\TestVersion.exe" - a simple pushd/popd combination to the correct directory in the batch file may solve this. HTH, David From dlrdave at aol.com Tue Aug 12 08:38:52 2014 From: dlrdave at aol.com (David Cole) Date: Tue, 12 Aug 2014 08:38:52 -0400 (EDT) Subject: [CMake] how to really change CMake linker Message-ID: <8D1844181DA3E82-1D58-1F38A@webmail-vm030.sysops.aol.com> Unless it is overridden somewhere else along the way, the following is used to create the link command line for a C++ executable: (found in Modules/CMakeCXXInformation.cmake) if(NOT CMAKE_CXX_LINK_EXECUTABLE) set(CMAKE_CXX_LINK_EXECUTABLE " -o ") endif() As you can see, by default, the C++ compiler is used as a front end to link C++ executables... Similarly for other types of targets, there are CMAKE_CXX_CREATE_SHARED_LIBRARY and CMAKE_CXX_CREATE_SHARED_MODULE. And for other languages, there are CMAKE_${LANG}_CREATE_... variables too. In order to use the linker you want, you would have to define a custom CMAKE_CXX_LINK_EXECUTABLE that uses "" in its definition of the linker command line. HTH, David C. From brad.king at kitware.com Tue Aug 12 09:06:13 2014 From: brad.king at kitware.com (Brad King) Date: Tue, 12 Aug 2014 09:06:13 -0400 Subject: [CMake] How to deal with incompatible changes in interface of target_link_libraries()? In-Reply-To: <53E9C965.5000609@astron.nl> References: <53E62631.9060500@zonnet.nl> <53E8F3AA.40002@kitware.com> <53E9C965.5000609@astron.nl> Message-ID: <53EA1145.8090907@kitware.com> On 08/12/2014 03:59 AM, Marcel Loose wrote: > Another problem I faced with policy CMP0022 is that I was unable to > really silence it. Setting the policy to OLD doesn't really work (at > least not in my case), maybe because the "cmake_policy()" command is > scoped(?). For CMP0022 and CMP0023 the policy setting is recorded on each target when it is created by and add_library command. That affects all target_link_libraries calls that give the library as the first argument. > setting the policy to OLD once at top-level doesn't seem to work Any call to cmake_minimum_required(VERSION) will unset policies introduced in versions larger than that named. FYI, the only intended use case for setting a policy to OLD is to quiet warnings in a maintenance branch of an existing release. Some day support for OLD behavior of some policies may be dropped, so all project development moving forward should set the policy to NEW. -Brad From brad.king at kitware.com Tue Aug 12 09:06:16 2014 From: brad.king at kitware.com (Brad King) Date: Tue, 12 Aug 2014 09:06:16 -0400 Subject: [CMake] How to deal with incompatible changes in interface of target_link_libraries()? In-Reply-To: <53E9C6C1.9080204@astron.nl> References: <53E62631.9060500@zonnet.nl> <53E8F3AA.40002@kitware.com> <53E9C6C1.9080204@astron.nl> Message-ID: <53EA1148.9010900@kitware.com> On 08/12/2014 03:48 AM, Marcel Loose wrote: > That's probably in the CMake 3.0.x docs; CMake 2.8.12 doesn't mention > LINK_PUBLIC and LINK_PRIVATE in the policy documentation. I only read > the following in the docs on target_link_libraries > > The LINK_PUBLIC and LINK_PRIVATE modes can be used to specify > both the > link dependencies and the link interface in one command. This > signature is for compatibility only. Prefer the PUBLIC or PRIVATE > keywords instead. > > "... for compatibility only" didn't give me the feeling that this is the > way to go, which is underscored by the next sentence: "Prefer the ..." If your project requires CMake 2.8.12 or higher then it is preferred to use PUBLIC/PRIVATE. For compatibility with earlier CMake versions you can still use LINK_PUBLIC/LINK_PRIVATE. > On a side note. Even using the new PRIVATE and PUBLIC keywords I am > unable to exactly specify which libraries are needed for linking. Can you provide a concrete example of this trouble? -Brad From mark.j.abraham at gmail.com Tue Aug 12 12:04:14 2014 From: mark.j.abraham at gmail.com (Mark Abraham) Date: Tue, 12 Aug 2014 09:04:14 -0700 Subject: [CMake] how to really change CMake linker In-Reply-To: <8D1844181DA3E82-1D58-1F38A@webmail-vm030.sysops.aol.com> References: <8D1844181DA3E82-1D58-1F38A@webmail-vm030.sysops.aol.com> Message-ID: Hi David, Thanks very much for your reply! That was extremely helpful, and will let several packages document a functional workflow for the future. On Tue, Aug 12, 2014 at 5:38 AM, David Cole wrote: > Unless it is overridden somewhere else along the way, the following is > used to create the link command line for a C++ executable: > > (found in Modules/CMakeCXXInformation.cmake) > > if(NOT CMAKE_CXX_LINK_EXECUTABLE) > set(CMAKE_CXX_LINK_EXECUTABLE > " > -o ") > endif() > > As you can see, by default, the C++ compiler is used as a front end to > link C++ executables... > > Similarly for other types of targets, there are > CMAKE_CXX_CREATE_SHARED_LIBRARY and CMAKE_CXX_CREATE_SHARED_MODULE. And > for other languages, there are CMAKE_${LANG}_CREATE_... variables too. > Ah, that explains one source of confusion. I read CMAKE_CXX_LINK_EXECUTABLE with LINK as an adjective - specify the executable that does linking - whereas the above use of CREATE makes clear that the sense of LINK is intended to be as a verb - specify how to create an executable. The docs did say that this variable specifies a rule, now that I know what to look for. :-( In order to use the linker you want, you would have to define a custom > CMAKE_CXX_LINK_EXECUTABLE that uses "" in its definition > of the linker command line. > Right. It's easy to assume that this would be the default behaviour for constructing linking command lines. It's probably too late to consider a change, but I hope the original reasoning works well somewhere! :-) Mark > HTH, > David C. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cvolpe at ara.com Tue Aug 12 12:44:24 2014 From: cvolpe at ara.com (Chris Volpe ARA/SED) Date: Tue, 12 Aug 2014 16:44:24 +0000 Subject: [CMake] Possible bug in environment variable expansion? In-Reply-To: <45BF0169B950CD4A97DC5223BB2B44B3385954@VACH-MX1.EGL.ENGILITYCORP.COM> References: <7B8A49496E564B4781559C6C1AEB79338E3A5872@colo-mail-2.exchange2.ara.wan> <45BF0169B950CD4A97DC5223BB2B44B3385954@VACH-MX1.EGL.ENGILITYCORP.COM> Message-ID: <7B8A49496E564B4781559C6C1AEB79338E3A5C00@colo-mail-2.exchange2.ara.wan> That's a good thought, but unfortunately it didn't pan out. I tried both styles, and I even tried explicitly mixing styles like this: BOOST_LIBRARYDIR=C:/local/boost_1_55_0\lib64-msvc-12.0 Or this: BOOST_LIBRARYDIR=C:\local\boost_1_55_0/lib64-msvc-12.0 And those worked fine. From: Lucas.Pettey at engilitycorp.com [mailto:Lucas.Pettey at engilitycorp.com] Sent: Monday, August 11, 2014 11:03 PM To: Chris Volpe ARA/SED; cmake at cmake.org Subject: RE: Possible bug in environment variable expansion? Could it be something as simple as UNIX (slash /) vs Windows (backslash \) in the directory expression? When this environment variable is expanded BOOST_LIBRARYDIR=%BOOST_ROOT%\lib64-msvc-12.0, it looks like it is converting the %BOOST_ROOT% in UNIX style and then the "\lib-msvc-12.0" is Windows. This mixture of styles may be causing a "no such directory" system error. I know on Windows systems I need to be consistent with directory styles or it fails. Lucas Pettey, PhD HPCMP PETTT EQM CTA Lead ERDC-DSRC OnSite Vicksburg, MS 512-297-9833 Mobile (preferred) 601-634-2980 Office lucas.pettey at engilitycorp.com ________________________________ From: CMake [cmake-bounces at cmake.org] on behalf of Chris Volpe ARA/SED [cvolpe at ara.com] Sent: Monday, August 11, 2014 6:25 PM To: cmake at cmake.org Subject: [CMake] Possible bug in environment variable expansion? I am trying to build an Open Source project called PCL which uses Boost, and CMake's ability to find the Boost libraries seems dependent on whether the BOOST_LIBRARYDIR contains a literal path string, or whether it contains a string that incorporates the expansion of BOOST_ROOT. Here are the details: Boost is installed from a pre-built installer in the folder C:\local\boost_1_55_0. This folder contains, among other things, a subfolder called "boost", which contains the headers, and a subfolder called "lib64-msvc-12.0", which contains 64-bit libraries built with MS Visual Studio 2013. Ordinarily, CMake would like that folder to be called simply "lib", but that's not what the installer created, so I'm trying to override the default with environment variables. I have the following three environment variables defined, all of which are of type "Expandable string": BOOST_ROOT=C:\local\boost_1_55_0 BOOST_INCLUDEDIR=%BOOST_ROOT% BOOST_LIBRARYDIR=%BOOST_ROOT%\lib64-msvc-12.0 With these settings, CMake reports an error during the configuration process, as follows: CMake Error at C:/Program Files (x86)/CMake/share/cmake-3.0/Modules/FindBoost.cmake:1179 (message): Unable to find the requested Boost libraries. Boost version: 1.55.0 Boost include path: C:/local/boost_1_55_0 Could not find the following Boost libraries: boost_system boost_filesystem boost_thread boost_date_time boost_iostreams boost_chrono No Boost libraries were found. You may need to set BOOST_LIBRARYDIR to the directory containing Boost libraries or BOOST_ROOT to the location of Boost. Call Stack (most recent call first): cmake/pcl_find_boost.cmake:38 (find_package) CMakeLists.txt:230 (include) But if change the definition of BOOST_LIBRARYDIR by replacing "%BOOST_ROOT%" with the value assigned to BOOST_ROOT, resulting in this: BOOST_LIBRARYDIR=C:\local\boost_1_55_0\lib64-msvc-12.0 the configuration succeeds. The only difference seems to be whether the "C:\local\boost_1_55_0" part of the path is specified explicitly, or obtained implicitly with %BOOST_ROOT%. It would surprise me if this behavior were by design. Does anyone have an explanation for this? Thanks, Chris Christopher R. Volpe, Ph.D. Senior Scientist, Remote Sensing & Decision Analytics [Description: Description: Description: cid:image003.png at 01CE888B.0167BAD0] NATIONAL SECURITY | INFRASTRUCTURE | ENERGY & ENVIRONMENT | HEALTH SOLUTIONS Applied Research Associates, Inc. 8537 Six Forks Road, Suite 600, Raleigh, NC 27615 | T 919.582.3380 | F 919.582.3301 Find Us Online www.ara.com Facebook: Applied Research Associates LinkedIn: Company Page LinkedIn Group Twitter: ARA News YouTube: Applied Research Associates -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 9687 bytes Desc: image001.png URL: From FMiller at sjm.com Tue Aug 12 12:44:03 2014 From: FMiller at sjm.com (Miller, Frank) Date: Tue, 12 Aug 2014 16:44:03 +0000 Subject: [CMake] Windows RC files with Ninja Message-ID: Greetings, I tried to move from 2.8 to 3.0.1 today and I'm experiencing an issue with RC files. Looks like a simple problem but I would be baffled if I'm the first to experience this so I expect I have some kind of configuration issue. Here is the offending snippet in the rules.ninja file: rule RC_COMPILER depfile = $DEP_FILE deps = gcc command = "" RC $in "$DEP_FILE" $out "" "c:/Program Files (x86)/Microsoft Visual Studio 12.0/VC/bin/cl.exe" c:\PROGRA~2\WI3CF2~1\8.1\bin\x86\rc.exe $FLAGS $DEFINES /fo$out $in description = Building RC object $out If I put the path to "cmcldeps.exe" in the empty quotes on the command line, it works as expected. Does anyone else have this problem? Frank 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 cvolpe at ara.com Tue Aug 12 15:37:47 2014 From: cvolpe at ara.com (Chris Volpe ARA/SED) Date: Tue, 12 Aug 2014 19:37:47 +0000 Subject: [CMake] Possible bug in environment variable expansion? In-Reply-To: <7B8A49496E564B4781559C6C1AEB79338E3A5C00@colo-mail-2.exchange2.ara.wan> References: <7B8A49496E564B4781559C6C1AEB79338E3A5872@colo-mail-2.exchange2.ara.wan> <45BF0169B950CD4A97DC5223BB2B44B3385954@VACH-MX1.EGL.ENGILITYCORP.COM> <7B8A49496E564B4781559C6C1AEB79338E3A5C00@colo-mail-2.exchange2.ara.wan> Message-ID: <7B8A49496E564B4781559C6C1AEB79338E3A5D2A@colo-mail-2.exchange2.ara.wan> As it turns out, something weirder is going on, and it's not cmake's fault, so I won't look for a solution here, but I'll describe the problem in case anyone's interested. *Windows* is not expanding those environment variables. First, I hacked up the installed version of FindBoost.cmake to spit out some debugging information, with the following, circa line 860: message(DEBUG "_ENV_BOOST_LIBRARYDIR has value <${_ENV_BOOST_LIBRARYDIR}>") and then I ran configure in debug mode, which gave me the following from my extra hacked debugging output: DEBUG_ENV_BOOST_LIBRARYDIR has value <%BOOST_ROOT%/lib64-msvc-12.0> So, when cmake asked the OS for the BOOST_LIBRARYDIR environment variable, the OS gave it the string without expanding BOOST_ROOT. I have verified this OS behavior by opening up a command window and using the set command: It's not getting expanded. I've verified (with RapidEE) that the environment variables in question are of type "expandable string", not "string". While playing with the variables in RapidEE (a wonderful tool, BTW), I noticed two other strange things. First, I do have a couple of env vars that do have other env var references in them, and they *do* get expanded in cmd.exe. Second, my PATH env var used to have embedded env vars for various things, but somewhere along the way they all got replaced in the PATH *definition* with their expanded versions, so now everything in my path is now "hard coded", so to speak. Ugh. So, basically, something is messed up in my system. From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Chris Volpe ARA/SED Sent: Tuesday, August 12, 2014 12:44 PM To: Lucas.Pettey at engilitycorp.com; cmake at cmake.org Subject: Re: [CMake] Possible bug in environment variable expansion? That's a good thought, but unfortunately it didn't pan out. I tried both styles, and I even tried explicitly mixing styles like this: BOOST_LIBRARYDIR=C:/local/boost_1_55_0\lib64-msvc-12.0 Or this: BOOST_LIBRARYDIR=C:\local\boost_1_55_0/lib64-msvc-12.0 And those worked fine. From: Lucas.Pettey at engilitycorp.com [mailto:Lucas.Pettey at engilitycorp.com] Sent: Monday, August 11, 2014 11:03 PM To: Chris Volpe ARA/SED; cmake at cmake.org Subject: RE: Possible bug in environment variable expansion? Could it be something as simple as UNIX (slash /) vs Windows (backslash \) in the directory expression? When this environment variable is expanded BOOST_LIBRARYDIR=%BOOST_ROOT%\lib64-msvc-12.0, it looks like it is converting the %BOOST_ROOT% in UNIX style and then the "\lib-msvc-12.0" is Windows. This mixture of styles may be causing a "no such directory" system error. I know on Windows systems I need to be consistent with directory styles or it fails. Lucas Pettey, PhD HPCMP PETTT EQM CTA Lead ERDC-DSRC OnSite Vicksburg, MS 512-297-9833 Mobile (preferred) 601-634-2980 Office lucas.pettey at engilitycorp.com ________________________________ From: CMake [cmake-bounces at cmake.org] on behalf of Chris Volpe ARA/SED [cvolpe at ara.com] Sent: Monday, August 11, 2014 6:25 PM To: cmake at cmake.org Subject: [CMake] Possible bug in environment variable expansion? I am trying to build an Open Source project called PCL which uses Boost, and CMake's ability to find the Boost libraries seems dependent on whether the BOOST_LIBRARYDIR contains a literal path string, or whether it contains a string that incorporates the expansion of BOOST_ROOT. Here are the details: Boost is installed from a pre-built installer in the folder C:\local\boost_1_55_0. This folder contains, among other things, a subfolder called "boost", which contains the headers, and a subfolder called "lib64-msvc-12.0", which contains 64-bit libraries built with MS Visual Studio 2013. Ordinarily, CMake would like that folder to be called simply "lib", but that's not what the installer created, so I'm trying to override the default with environment variables. I have the following three environment variables defined, all of which are of type "Expandable string": BOOST_ROOT=C:\local\boost_1_55_0 BOOST_INCLUDEDIR=%BOOST_ROOT% BOOST_LIBRARYDIR=%BOOST_ROOT%\lib64-msvc-12.0 With these settings, CMake reports an error during the configuration process, as follows: CMake Error at C:/Program Files (x86)/CMake/share/cmake-3.0/Modules/FindBoost.cmake:1179 (message): Unable to find the requested Boost libraries. Boost version: 1.55.0 Boost include path: C:/local/boost_1_55_0 Could not find the following Boost libraries: boost_system boost_filesystem boost_thread boost_date_time boost_iostreams boost_chrono No Boost libraries were found. You may need to set BOOST_LIBRARYDIR to the directory containing Boost libraries or BOOST_ROOT to the location of Boost. Call Stack (most recent call first): cmake/pcl_find_boost.cmake:38 (find_package) CMakeLists.txt:230 (include) But if change the definition of BOOST_LIBRARYDIR by replacing "%BOOST_ROOT%" with the value assigned to BOOST_ROOT, resulting in this: BOOST_LIBRARYDIR=C:\local\boost_1_55_0\lib64-msvc-12.0 the configuration succeeds. The only difference seems to be whether the "C:\local\boost_1_55_0" part of the path is specified explicitly, or obtained implicitly with %BOOST_ROOT%. It would surprise me if this behavior were by design. Does anyone have an explanation for this? Thanks, Chris Christopher R. Volpe, Ph.D. Senior Scientist, Remote Sensing & Decision Analytics [Description: Description: Description: cid:image003.png at 01CE888B.0167BAD0] NATIONAL SECURITY | INFRASTRUCTURE | ENERGY & ENVIRONMENT | HEALTH SOLUTIONS Applied Research Associates, Inc. 8537 Six Forks Road, Suite 600, Raleigh, NC 27615 | T 919.582.3380 | F 919.582.3301 Find Us Online www.ara.com Facebook: Applied Research Associates LinkedIn: Company Page LinkedIn Group Twitter: ARA News YouTube: Applied Research Associates -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 9687 bytes Desc: image001.png URL: From bill.hoffman at kitware.com Tue Aug 12 15:50:04 2014 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Tue, 12 Aug 2014 15:50:04 -0400 Subject: [CMake] Possible bug in environment variable expansion? In-Reply-To: <7B8A49496E564B4781559C6C1AEB79338E3A5C00@colo-mail-2.exchange2.ara.wan> References: <7B8A49496E564B4781559C6C1AEB79338E3A5872@colo-mail-2.exchange2.ara.wan> <45BF0169B950CD4A97DC5223BB2B44B3385954@VACH-MX1.EGL.ENGILITYCORP.COM> <7B8A49496E564B4781559C6C1AEB79338E3A5C00@colo-mail-2.exchange2.ara.wan> Message-ID: <53EA6FEC.2050508@kitware.com> On 8/12/2014 12:44 PM, Chris Volpe ARA/SED wrote: > That?s a good thought, but unfortunately it didn?t pan out. I tried both > styles, and I even tried explicitly mixing styles like this: > > BOOST_LIBRARYDIR=C:/local/boost_1_55_0\lib64-msvc-12.0 > > Or this: > > BOOST_LIBRARYDIR=C:\local\boost_1_55_0/lib64-msvc-12.0 > Try setting Boost_DEBUG=1 in your CMake run, and then it should show you where it is searching and the problem may become more obvious. -Bill From cvolpe at ara.com Tue Aug 12 17:11:27 2014 From: cvolpe at ara.com (Chris Volpe ARA/SED) Date: Tue, 12 Aug 2014 21:11:27 +0000 Subject: [CMake] Possible bug in environment variable expansion? In-Reply-To: <53EA6FEC.2050508@kitware.com> References: <7B8A49496E564B4781559C6C1AEB79338E3A5872@colo-mail-2.exchange2.ara.wan> <45BF0169B950CD4A97DC5223BB2B44B3385954@VACH-MX1.EGL.ENGILITYCORP.COM> <7B8A49496E564B4781559C6C1AEB79338E3A5C00@colo-mail-2.exchange2.ara.wan> <53EA6FEC.2050508@kitware.com> Message-ID: <7B8A49496E564B4781559C6C1AEB79338E3A5DF6@colo-mail-2.exchange2.ara.wan> Thanks, Bill. As it turns out, the problem appears to be a bug in Windows. Through experimentation, I have determined a truth about environment variables that I have yet to be able to find spelled out anywhere: If the type of an environment variable does not *need* to be "Expandable String", then it *mustn't* be "Expandable String". Environment variable expansion (including nested multiple levels) works only when all the variables that reference others are of type "Expandable String", and the ones that don't are of type "String". -----Original Message----- From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Bill Hoffman Sent: Tuesday, August 12, 2014 3:50 PM To: cmake at cmake.org Subject: Re: [CMake] Possible bug in environment variable expansion? On 8/12/2014 12:44 PM, Chris Volpe ARA/SED wrote: > That's a good thought, but unfortunately it didn't pan out. I tried > both styles, and I even tried explicitly mixing styles like this: > > BOOST_LIBRARYDIR=C:/local/boost_1_55_0\lib64-msvc-12.0 > > Or this: > > BOOST_LIBRARYDIR=C:\local\boost_1_55_0/lib64-msvc-12.0 > Try setting Boost_DEBUG=1 in your CMake run, and then it should show you where it is searching and the problem may become more obvious. -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 From andrew.amaclean at gmail.com Tue Aug 12 18:57:23 2014 From: andrew.amaclean at gmail.com (Andrew Maclean) Date: Wed, 13 Aug 2014 08:57:23 +1000 Subject: [CMake] Possible bug in environment variable expansion? Message-ID: I only define: BOOST_ROOT=C:\local\boost_1_56_0 BOOST_LIBRARYDIR=C:\local\boost_1_56_0\lib64-msvc-12.0 and this works Ok. This will not work: BOOST_LIBRARYDIR=%BOOST_ROOT%\lib64-msvc-12.0 If you go to a command prompt and type "set" you will see that %BOOST_ROOT% is not expanded. So this is a Windows issue, not a CMake issue. The only clue I have is that Microsoft expands these variables in order and since BOOST_ROOT is ordered after BOOST_LIBRARYDIR the expansion does not happen. Regards Andrew On Wed, Aug 13, 2014 at 5:37 AM, wrote: > Send CMake mailing list submissions to > cmake at cmake.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://public.kitware.com/mailman/listinfo/cmake > or, via email, send a message with subject or body 'help' to > cmake-request at cmake.org > > You can reach the person managing the list at > cmake-owner at cmake.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of CMake digest..." > > Today's Topics: > > 1. Windows RC files with Ninja (Miller, Frank) > 2. Re: Possible bug in environment variable expansion? > (Chris Volpe ARA/SED) > > > ---------- Forwarded message ---------- > From: "Miller, Frank" > To: CMake MailingList > Cc: > Date: Tue, 12 Aug 2014 16:44:03 +0000 > Subject: [CMake] Windows RC files with Ninja > Greetings, > > I tried to move from 2.8 to 3.0.1 today and I'm experiencing an issue with > RC files. Looks like a simple problem but I would be baffled if I'm the > first to experience this so I expect I have some kind of configuration > issue. Here is the offending snippet in the rules.ninja file: > > rule RC_COMPILER > depfile = $DEP_FILE > deps = gcc > command = "" RC $in "$DEP_FILE" $out "" "c:/Program Files > (x86)/Microsoft Visual Studio 12.0/VC/bin/cl.exe" > c:\PROGRA~2\WI3CF2~1\8.1\bin\x86\rc.exe $FLAGS $DEFINES /fo$out $in > description = Building RC object $out > > If I put the path to "cmcldeps.exe" in the empty quotes on the command > line, it works as expected. > > Does anyone else have this problem? > > Frank > > 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. > > > > ---------- Forwarded message ---------- > From: Chris Volpe ARA/SED > To: Chris Volpe ARA/SED , "Lucas.Pettey at engilitycorp.com" > , "cmake at cmake.org" > Cc: > Date: Tue, 12 Aug 2014 19:37:47 +0000 > Subject: Re: [CMake] Possible bug in environment variable expansion? > > As it turns out, something weirder is going on, and it?s not cmake?s > fault, so I won?t look for a solution here, but I?ll describe the problem > in case anyone?s interested. **Windows** is not expanding those > environment variables. First, I hacked up the installed version of > FindBoost.cmake to spit out some debugging information, with the following, > circa line 860: > > > > message(DEBUG "_ENV_BOOST_LIBRARYDIR has value > <${_ENV_BOOST_LIBRARYDIR}>") > > > > and then I ran configure in debug mode, which gave me the following from > my extra hacked debugging output: > > > > DEBUG_ENV_BOOST_LIBRARYDIR has value <%BOOST_ROOT%/lib64-msvc-12.0> > > > > So, when cmake asked the OS for the BOOST_LIBRARYDIR environment variable, > the OS gave it the string without expanding BOOST_ROOT. I have verified > this OS behavior by opening up a command window and using the set command: > It?s not getting expanded. I?ve verified (with RapidEE) that the > environment variables in question are of type ?expandable string?, not > ?string?. > > > > While playing with the variables in RapidEE (a wonderful tool, BTW), I > noticed two other strange things. First, I do have a couple of env vars > that do have other env var references in them, and they **do** get > expanded in cmd.exe. Second, my PATH env var used to have embedded env vars > for various things, but somewhere along the way they all got replaced in > the PATH **definition** with their expanded versions, so now everything > in my path is now ?hard coded?, so to speak. Ugh. > > > > So, basically, something is messed up in my system. > > > > > > *From:* CMake [mailto:cmake-bounces at cmake.org] *On Behalf Of *Chris Volpe > ARA/SED > *Sent:* Tuesday, August 12, 2014 12:44 PM > *To:* Lucas.Pettey at engilitycorp.com; cmake at cmake.org > *Subject:* Re: [CMake] Possible bug in environment variable expansion? > > > > That?s a good thought, but unfortunately it didn?t pan out. I tried both > styles, and I even tried explicitly mixing styles like this: > > > > BOOST_LIBRARYDIR=C:/local/boost_1_55_0\lib64-msvc-12.0 > > > > Or this: > > > > BOOST_LIBRARYDIR=C:\local\boost_1_55_0/lib64-msvc-12.0 > > > > And those worked fine. > > > > *From:* Lucas.Pettey at engilitycorp.com [mailto: > Lucas.Pettey at engilitycorp.com] > *Sent:* Monday, August 11, 2014 11:03 PM > *To:* Chris Volpe ARA/SED; cmake at cmake.org > *Subject:* RE: Possible bug in environment variable expansion? > > > > Could it be something as simple as UNIX (slash /) vs Windows (backslash \) > in the directory expression? > > > > When this environment variable is expanded BOOST_LIBRARYDIR=%BOOST_ROOT%\lib64-msvc-12.0, > it looks like it is converting the %BOOST_ROOT% in UNIX style and then the > "\lib-msvc-12.0" is Windows. This mixture of styles may be causing a "no > such directory" system error. I know on Windows systems I need to be > consistent with directory styles or it fails. > > > > Lucas Pettey, PhD > > HPCMP PETTT EQM CTA Lead > > ERDC-DSRC OnSite > > Vicksburg, MS > > 512-297-9833 Mobile (preferred) > > 601-634-2980 Office > > lucas.pettey at engilitycorp.com > ------------------------------ > > *From:* CMake [cmake-bounces at cmake.org] on behalf of Chris Volpe ARA/SED [ > cvolpe at ara.com] > *Sent:* Monday, August 11, 2014 6:25 PM > *To:* cmake at cmake.org > *Subject:* [CMake] Possible bug in environment variable expansion? > > I am trying to build an Open Source project called PCL which uses Boost, > and CMake?s ability to find the Boost libraries seems dependent on whether > the BOOST_LIBRARYDIR contains a literal path string, or whether it contains > a string that incorporates the expansion of BOOST_ROOT. Here are the > details: > > > > Boost is installed from a pre-built installer in the folder > C:\local\boost_1_55_0. This folder contains, among other things, a > subfolder called ?boost?, which contains the headers, and a subfolder > called ?lib64-msvc-12.0?, which contains 64-bit libraries built with MS > Visual Studio 2013. Ordinarily, CMake would like that folder to be called > simply ?lib?, but that?s not what the installer created, so I?m trying to > override the default with environment variables. I have the following three > environment variables defined, all of which are of type ?Expandable string?: > > > > BOOST_ROOT=C:\local\boost_1_55_0 > > BOOST_INCLUDEDIR=%BOOST_ROOT% > > BOOST_LIBRARYDIR=%BOOST_ROOT%\lib64-msvc-12.0 > > > > With these settings, CMake reports an error during the configuration > process, as follows: > > > > CMake Error at C:/Program Files > (x86)/CMake/share/cmake-3.0/Modules/FindBoost.cmake:1179 (message): > Unable to find the requested Boost libraries. > > Boost version: 1.55.0 > > Boost include path: C:/local/boost_1_55_0 > > Could not find the following Boost libraries: > > boost_system > boost_filesystem > boost_thread > boost_date_time > boost_iostreams > boost_chrono > > No Boost libraries were found. You may need to set BOOST_LIBRARYDIR to the > directory containing Boost libraries or BOOST_ROOT to the location of > Boost. > Call Stack (most recent call first): > cmake/pcl_find_boost.cmake:38 (find_package) > CMakeLists.txt:230 (include) > > > > But if change the definition of BOOST_LIBRARYDIR by replacing > ?%BOOST_ROOT%? with the value assigned to BOOST_ROOT, resulting in this: > > BOOST_LIBRARYDIR=C:\local\boost_1_55_0\lib64-msvc-12.0 > > the configuration succeeds. The only difference seems to be whether the > ?C:\local\boost_1_55_0? part of the path is specified explicitly, or > obtained implicitly with %BOOST_ROOT%. It would surprise me if this > behavior were by design. Does anyone have an explanation for this? > > > > Thanks, > > Chris > > > > > > *Christopher R. Volpe, Ph.D.* > > *Senior Scientist, Remote Sensing & Decision Analytics* > > > > [image: Description: Description: Description: > cid:image003.png at 01CE888B.0167BAD0] > > *NATIONAL SECURITY** | ** INFRASTRUCTURE ** | **ENERGY & ENVIRONMENT * > * |** HEALTH SOLUTIONS* > > Applied Research Associates, Inc. > > 8537 Six Forks Road, Suite 600, Raleigh, NC 27615 | *T *919.582.3380 | > *F* 919.582.3301 > > > > *Find Us Online* > > www.ara.com > > Facebook: Applied Research Associates > > > LinkedIn: Company Page > > LinkedIn Group > > > Twitter: ARA News > > YouTube: Applied Research Associates > > > > > > > > > -- > > 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 > -- ___________________________________________ Andrew J. P. Maclean ___________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 9687 bytes Desc: not available URL: From Matt.Bolger at csiro.au Tue Aug 12 21:06:47 2014 From: Matt.Bolger at csiro.au (Matt.Bolger at csiro.au) Date: Wed, 13 Aug 2014 01:06:47 +0000 Subject: [CMake] Removing the original CDash admin Message-ID: Hi All, Does anyone know how to remove the primary (first) Administrator of a CDash instance? All the other users show up with a 'make normal user' and 'remove user' button but not the original administrator who setup the instance. Thanks Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: From dlrdave at aol.com Tue Aug 12 21:37:11 2014 From: dlrdave at aol.com (David Cole) Date: Tue, 12 Aug 2014 21:37:11 -0400 (EDT) Subject: [CMake] Removing the original CDash admin In-Reply-To: References: Message-ID: <8D184AE3C6D8947-1D58-24A6C@webmail-vm030.sysops.aol.com> You can always brute force it and go in and remove that user from the database table with MySQL or phpMyAdmin... HTH, David C. From Matt.Bolger at csiro.au Tue Aug 12 21:45:52 2014 From: Matt.Bolger at csiro.au (Matt.Bolger at csiro.au) Date: Wed, 13 Aug 2014 01:45:52 +0000 Subject: [CMake] Removing the original CDash admin In-Reply-To: <8D184AE3C6D8947-1D58-24A6C@webmail-vm030.sysops.aol.com> References: <8D184AE3C6D8947-1D58-24A6C@webmail-vm030.sysops.aol.com> Message-ID: Yeah I was just worried that since CDash seems to be so fond of this user it might react badly to their forced departure. Matt -----Original Message----- From: David Cole [mailto:dlrdave at aol.com] Sent: Wednesday, 13 August 2014 11:37 AM To: Bolger, Matt (DP&S, Clayton); cmake at cmake.org Subject: Re: [CMake] Removing the original CDash admin You can always brute force it and go in and remove that user from the database table with MySQL or phpMyAdmin... HTH, David C. From rcdailey.lists at gmail.com Tue Aug 12 21:50:24 2014 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Tue, 12 Aug 2014 20:50:24 -0500 Subject: [CMake] Generator expressions for optimized/debug configurations Message-ID: I just installed CMake 3.0 and I'm trying out the new generator expressions for the target_compile_definitions() command. I am doing this: target_compile_definitions( ${project_name} PRIVATE ${general_defs} PRIVATE "$<$:${debug_defs}>" PRIVATE "$<$:${release_defs}>" ) The problem here is that there are many "release" configurations provided by CMake by default. I would like a way to target "optimized" and "unoptimized" configurations, regardless of name. I'm working on a generic CMake framework (written in CMake language) that hides away some details of using CMake directly for complex tasks. As such I can't really know from a generic level which configurations (by name) will exist. Users could add more or less. The best I can do from the framework level is target "optimized" or "unoptimized" configs. Any way to do this with 3.0? Thanks in advance. From dlrdave at aol.com Tue Aug 12 21:58:05 2014 From: dlrdave at aol.com (David Cole) Date: Tue, 12 Aug 2014 21:58:05 -0400 (EDT) Subject: [CMake] Removing the original CDash admin In-Reply-To: References: <8D184AE3C6D8947-1D58-24A6C@webmail-vm030.sysops.aol.com> Message-ID: <8D184B1282129E3-1D58-24C32@webmail-vm030.sysops.aol.com> I think you should be ok... just make another user admin before you do it, of course. You can always put the user back by brute force, too, if you discover you need it for something. I'm not aware of anything special about the user besides its "admin-ness". Good luck, and let us know if you find anything that doesn't work after you remove it. D From petr.kmoch at gmail.com Wed Aug 13 03:20:29 2014 From: petr.kmoch at gmail.com (Petr Kmoch) Date: Wed, 13 Aug 2014 09:20:29 +0200 Subject: [CMake] Resetting CMAKE_Fortran_FLAGS for a specific file In-Reply-To: References: Message-ID: Hi Marco. Sane compilers allow later command-line options to override earlier ones, so what you're doing should be fine. Unfortunately, I know some Fortran compilers are not sane in this regard. If you really need to solve this by explicitly modifying the global list for a particular file, the only thing I can think of is move those files to a separate CMakeList and turn them into an object library: # In normal CMakeList: add_subdirectory(special_file_dir) add_executable(YourNormalTarget normal_file1.f90 normal_file2.f90 $) # In special_file_dir/CMakeLists.txt: set(CMAKE_Fortran_FLAGS "-only -flags -you -want") add_library(special_files OBJECT special_fil1.f90 special_file2.f90) I haven't tested it, but it should work. Petr On Tue, Aug 5, 2014 at 4:29 PM, marco restelli wrote: > Hi, > I would like to reset CMAKE_Fortran_FLAGS for one specific file in > a project. I have tried > > SET_SOURCE_FILES_PROPERTIES(my_file.f90 PROPERTIES COMPILE_FLAGS "-O0 -g") > > but it appends the new flags keeping the old ones. How can reset these > flags? Specifically, I have some files for which I need to avoid any > error checking and any optimization, independently from the selected > compiler. > > Thanks, regards, > Marco > -- > > 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 mrestelli at gmail.com Wed Aug 13 06:18:20 2014 From: mrestelli at gmail.com (marco restelli) Date: Wed, 13 Aug 2014 12:18:20 +0200 Subject: [CMake] Resetting CMAKE_Fortran_FLAGS for a specific file In-Reply-To: References: Message-ID: Hi Petr, thanks, very informative! 2014-08-13 9:20 GMT+0200, Petr Kmoch : > Hi Marco. > > Sane compilers allow later command-line options to override earlier ones, > so what you're doing should be fine. Unfortunately, I know some Fortran > compilers are not sane in this regard. Here, I would really like to reduce as much as possible the flags regardless of the chosen compiler, so "undoing" the chosen flags seems to me cumbersome and compiler dependent, compared to resetting them altogether. I like the idea of OBJECT libraries better (it also solves other problems I have, I did not know about it!). > If you really need to solve this by explicitly modifying the global list > for a particular file, the only thing I can think of is move those files to > a separate CMakeList and turn them into an object library: This almost works, I have a problem specifying liking dependencies for the OBJECT libraries. With a normal library, I can use TARGET_LINK_LIBRARIES( my_library ${other_libs_my_library_depends_on} ) but if my_library is OBJECT I see the error Object library target "my_library" may not link to anything. One option would be adding the TARGET_LINK_LIBRARIES to the STATIC library where the TARGET_OBJECTS are used, but this seems to contradict the modularity idea of the OBJECT libraries. Is there a better solution? Marco From hansbogert at gmail.com Wed Aug 13 08:03:09 2014 From: hansbogert at gmail.com (Hans van den Bogert) Date: Wed, 13 Aug 2014 14:03:09 +0200 Subject: [CMake] ExternalProject and install dir Message-ID: <31B3646C-136A-4CE7-B52E-4D0AA731CF05@gmail.com> Hi, I?m using ExternalProject, but the documentation does not really reflect what I am witnessing I have a Project X which is included through ExternalProject in Project A Project X has no PREFIX set in its CMakeLists I include project X like this: include(ExternalProject) ExternalProject_Add(x PREFIX x URL ${CMAKE_CURRENT_SOURCE_DIR}/externals/x ) Now according to the documentation the installed files should be available in the top of the prefix-dir, in this case ${CMAKE_BINARY_DIR}/x/ [installed files], though I can only see the src dir of ?x? and when looking at the output of the make of ?x? I can see its trying to install to default directories in this case '/usr/local?. In the documentation, doesn?t the install_dir not mean the same as the install directory where project ?x? will install its files? Because one would think so because BINARY_DIR does have these semantics. For reference from the documentation: The *_DIR options specify directories for the project, with default directories computed as follows. If the PREFIX option is given to ExternalProject_Add() or the EP_PREFIX directory property is set, then an external project is built and installed under the specified prefix: TMP_DIR = /tmp STAMP_DIR = /src/-stamp DOWNLOAD_DIR = /src SOURCE_DIR = /src/ BINARY_DIR = /src/-build INSTALL_DIR = From dlrdave at aol.com Wed Aug 13 09:20:04 2014 From: dlrdave at aol.com (David Cole) Date: Wed, 13 Aug 2014 09:20:04 -0400 (EDT) Subject: [CMake] ExternalProject and install dir In-Reply-To: <31B3646C-136A-4CE7-B52E-4D0AA731CF05@gmail.com> References: <31B3646C-136A-4CE7-B52E-4D0AA731CF05@gmail.com> Message-ID: <8D185106DBD620C-1F2C-A24@webmail-m150.sysops.aol.com> If x is a CMake-driven project, you'll also need to explicitly set CMAKE_INSTALL_PREFIX when configuring. If not, there's likely a "--prefix" arg for configuring... One of those also has to be set to install to a non-default location. The PREFIX arg for ExternalProject is only used to organize the source/build/install directory values for the custom target. It's still up to you to configure and build it properly for a non-default install location. HTH, David C. From dlrdave at aol.com Wed Aug 13 09:23:55 2014 From: dlrdave at aol.com (David Cole) Date: Wed, 13 Aug 2014 09:23:55 -0400 (EDT) Subject: [CMake] ExternalProject and install dir In-Reply-To: <8D185106DBD620C-1F2C-A24@webmail-m150.sysops.aol.com> References: <31B3646C-136A-4CE7-B52E-4D0AA731CF05@gmail.com> <8D185106DBD620C-1F2C-A24@webmail-m150.sysops.aol.com> Message-ID: <8D18510F71D3602-1F2C-A9B@webmail-m150.sysops.aol.com> See, for example: https://github.com/OpenChemistry/openchemistry/blob/master/CMakeLists.txt#L24 A common CMAKE_INSTALL_PREFIX is used for all OpenChemistry ExternalProject builds that are driven by CMake. From hansbogert at gmail.com Wed Aug 13 09:39:34 2014 From: hansbogert at gmail.com (Hans van den Bogert) Date: Wed, 13 Aug 2014 15:39:34 +0200 Subject: [CMake] ExternalProject and install dir In-Reply-To: <8D18510F71D3602-1F2C-A9B@webmail-m150.sysops.aol.com> References: <31B3646C-136A-4CE7-B52E-4D0AA731CF05@gmail.com> <8D185106DBD620C-1F2C-A24@webmail-m150.sysops.aol.com> <8D18510F71D3602-1F2C-A9B@webmail-m150.sysops.aol.com> Message-ID: <042F2777-B8C1-494C-8BDB-6549BEBBBB48@gmail.com> I see thanks, so install_dir has a different meaning than the eventual install dir of the external project, I thought there would be some ?magic? where the ExternalProject functions would override the the prefix of, in this case, project x. I still have one issue, perhaps I should start a new thread, but here goes: The external project produces a library, how can I make that library a target, so that any executables in the main project who depend on the library from ?x? will not link before the library is compiled/available. Because I some instances if I have a parallelized build the following scenario can happen. 1) x is being built 1) an executable which depends on an library, libx, from ?x? is being built. 2) the executable proceeds to its linking phase, but needs libx, which is not there; build fails. 3) ?x? has now produced libx libx was produced too late. My current setup (which exhibits the above) is simply to deduce the complete path to the library and add it the executable target. Is there any way this can be fixed with custom targets or something related? On 13 Aug 2014, at 15:23, David Cole wrote: > See, for example: > > https://github.com/OpenChemistry/openchemistry/blob/master/CMakeLists.txt#L24 > > A common CMAKE_INSTALL_PREFIX is used for all OpenChemistry ExternalProject builds that are driven by CMake. > From mark.j.abraham at gmail.com Wed Aug 13 09:53:14 2014 From: mark.j.abraham at gmail.com (Mark Abraham) Date: Wed, 13 Aug 2014 06:53:14 -0700 Subject: [CMake] Resetting CMAKE_Fortran_FLAGS for a specific file In-Reply-To: References: Message-ID: On Wed, Aug 13, 2014 at 3:18 AM, marco restelli wrote: > Hi Petr, > thanks, very informative! > > 2014-08-13 9:20 GMT+0200, Petr Kmoch : > > Hi Marco. > > > > Sane compilers allow later command-line options to override earlier ones, > > so what you're doing should be fine. Unfortunately, I know some Fortran > > compilers are not sane in this regard. > > Here, I would really like to reduce as much as possible the flags > regardless of the chosen compiler, so "undoing" the chosen flags > seems to me cumbersome and compiler dependent, compared to resetting > them altogether. I like the idea of OBJECT libraries better (it also > solves other problems I have, I did not know about it!). > > > If you really need to solve this by explicitly modifying the global list > > for a particular file, the only thing I can think of is move those files > to > > a separate CMakeList and turn them into an object library: > > This almost works, I have a problem specifying liking dependencies for > the OBJECT libraries. With a normal library, I can use > > TARGET_LINK_LIBRARIES( my_library ${other_libs_my_library_depends_on} ) > > but if my_library is OBJECT I see the error > > Object library target "my_library" may not link to anything. > See http://www.cmake.org/cmake/help/v3.0/command/add_library.html for the correct way to do things with object libraries - for this purpose, they are closer to source files than libraries, which makes sense given that there's not actually a library written to disk anywhere. Mark > One option would be adding the TARGET_LINK_LIBRARIES to the STATIC > library where the TARGET_OBJECTS are used, but this seems to > contradict the modularity idea of the OBJECT libraries. Is there a > better solution? > > Marco > -- > > 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 christopher.mullins at kitware.com Wed Aug 13 10:00:49 2014 From: christopher.mullins at kitware.com (Christopher Mullins) Date: Wed, 13 Aug 2014 10:00:49 -0400 Subject: [CMake] ExternalProject and install dir In-Reply-To: <042F2777-B8C1-494C-8BDB-6549BEBBBB48@gmail.com> References: <31B3646C-136A-4CE7-B52E-4D0AA731CF05@gmail.com> <8D185106DBD620C-1F2C-A24@webmail-m150.sysops.aol.com> <8D18510F71D3602-1F2C-A9B@webmail-m150.sysops.aol.com> <042F2777-B8C1-494C-8BDB-6549BEBBBB48@gmail.com> Message-ID: If project Y needs to link to project X, you could build project Y with ExternalProject_Add and list project X in the DEPENDS parameter. http://www.cmake.org/cmake/help/v3.0/module/ExternalProject.html On Wed, Aug 13, 2014 at 9:39 AM, Hans van den Bogert wrote: > I see thanks, so install_dir has a different meaning than the eventual > install dir of the external project, I thought there would be some ?magic? > where the ExternalProject functions would override the the prefix of, in > this case, project x. > > I still have one issue, perhaps I should start a new thread, but here > goes: > > The external project produces a library, how can I make that library a > target, so that any executables in the main project who depend on the > library from ?x? will not link before the library is compiled/available. > > Because I some instances if I have a parallelized build the following > scenario can happen. > > 1) x is being built > 1) an executable which depends on an library, libx, from ?x? is being > built. > 2) the executable proceeds to its linking phase, but needs libx, which is > not there; build fails. > 3) ?x? has now produced libx > > libx was produced too late. > > > My current setup (which exhibits the above) is simply to deduce the > complete path to the library and add it the executable target. > > Is there any way this can be fixed with custom targets or something > related? > > > On 13 Aug 2014, at 15:23, David Cole wrote: > > > See, for example: > > > > > https://github.com/OpenChemistry/openchemistry/blob/master/CMakeLists.txt#L24 > > > > A common CMAKE_INSTALL_PREFIX is used for all OpenChemistry > ExternalProject builds that are driven by 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 > -- Christopher Mullins R&D Engineer Kitware Inc., 919.869.8871 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mrestelli at gmail.com Wed Aug 13 10:12:15 2014 From: mrestelli at gmail.com (marco restelli) Date: Wed, 13 Aug 2014 16:12:15 +0200 Subject: [CMake] Resetting CMAKE_Fortran_FLAGS for a specific file In-Reply-To: References: Message-ID: 2014-08-13 15:53 GMT+0200, Mark Abraham : > On Wed, Aug 13, 2014 at 3:18 AM, marco restelli > wrote: > >> Hi Petr, >> thanks, very informative! >> >> 2014-08-13 9:20 GMT+0200, Petr Kmoch : >> > Hi Marco. >> > >> > Sane compilers allow later command-line options to override earlier >> > ones, >> > so what you're doing should be fine. Unfortunately, I know some Fortran >> > compilers are not sane in this regard. >> >> Here, I would really like to reduce as much as possible the flags >> regardless of the chosen compiler, so "undoing" the chosen flags >> seems to me cumbersome and compiler dependent, compared to resetting >> them altogether. I like the idea of OBJECT libraries better (it also >> solves other problems I have, I did not know about it!). >> >> > If you really need to solve this by explicitly modifying the global >> > list >> > for a particular file, the only thing I can think of is move those >> > files >> to >> > a separate CMakeList and turn them into an object library: >> >> This almost works, I have a problem specifying liking dependencies for >> the OBJECT libraries. With a normal library, I can use >> >> TARGET_LINK_LIBRARIES( my_library ${other_libs_my_library_depends_on} ) >> >> but if my_library is OBJECT I see the error >> >> Object library target "my_library" may not link to anything. >> > > See http://www.cmake.org/cmake/help/v3.0/command/add_library.html for the > correct way to do things with object libraries - for this purpose, they are > closer to source files than libraries, which makes sense given that there's > not actually a library written to disk anywhere. Mark, thanks, but here I don't find anything that answers my question, namely specifying that my OBJECT library (i.e. the files included in it) require other libraries for linking. Marco From mark.j.abraham at gmail.com Wed Aug 13 10:16:46 2014 From: mark.j.abraham at gmail.com (Mark Abraham) Date: Wed, 13 Aug 2014 07:16:46 -0700 Subject: [CMake] Resetting CMAKE_Fortran_FLAGS for a specific file In-Reply-To: References: Message-ID: On Wed, Aug 13, 2014 at 7:12 AM, marco restelli wrote: > 2014-08-13 15:53 GMT+0200, Mark Abraham : > > On Wed, Aug 13, 2014 at 3:18 AM, marco restelli > > wrote: > > > >> Hi Petr, > >> thanks, very informative! > >> > >> 2014-08-13 9:20 GMT+0200, Petr Kmoch : > >> > Hi Marco. > >> > > >> > Sane compilers allow later command-line options to override earlier > >> > ones, > >> > so what you're doing should be fine. Unfortunately, I know some > Fortran > >> > compilers are not sane in this regard. > >> > >> Here, I would really like to reduce as much as possible the flags > >> regardless of the chosen compiler, so "undoing" the chosen flags > >> seems to me cumbersome and compiler dependent, compared to resetting > >> them altogether. I like the idea of OBJECT libraries better (it also > >> solves other problems I have, I did not know about it!). > >> > >> > If you really need to solve this by explicitly modifying the global > >> > list > >> > for a particular file, the only thing I can think of is move those > >> > files > >> to > >> > a separate CMakeList and turn them into an object library: > >> > >> This almost works, I have a problem specifying liking dependencies for > >> the OBJECT libraries. With a normal library, I can use > >> > >> TARGET_LINK_LIBRARIES( my_library ${other_libs_my_library_depends_on} ) > >> > >> but if my_library is OBJECT I see the error > >> > >> Object library target "my_library" may not link to anything. > >> > > > > See http://www.cmake.org/cmake/help/v3.0/command/add_library.html for > the > > correct way to do things with object libraries - for this purpose, they > are > > closer to source files than libraries, which makes sense given that > there's > > not actually a library written to disk anywhere. > > Mark, thanks, but here I don't find anything that answers my question, > namely specifying that my OBJECT library (i.e. the files included in > it) require other libraries for linking. The object library is never linked, so the issue of linking with it or to it does not arise. The targets that use the object library have transitive linking dependencies, just like you had if the source files in the object library had been directly specified as part of those targets. Mark > Marco > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mrestelli at gmail.com Wed Aug 13 10:44:36 2014 From: mrestelli at gmail.com (marco restelli) Date: Wed, 13 Aug 2014 16:44:36 +0200 Subject: [CMake] Resetting CMAKE_Fortran_FLAGS for a specific file In-Reply-To: References: Message-ID: 2014-08-13 16:16 GMT+0200, Mark Abraham : > On Wed, Aug 13, 2014 at 7:12 AM, marco restelli > wrote: > >> 2014-08-13 15:53 GMT+0200, Mark Abraham : >> > On Wed, Aug 13, 2014 at 3:18 AM, marco restelli >> > wrote: >> > >> >> Hi Petr, >> >> thanks, very informative! >> >> >> >> 2014-08-13 9:20 GMT+0200, Petr Kmoch : >> >> > Hi Marco. >> >> > >> >> > Sane compilers allow later command-line options to override earlier >> >> > ones, >> >> > so what you're doing should be fine. Unfortunately, I know some >> Fortran >> >> > compilers are not sane in this regard. >> >> >> >> Here, I would really like to reduce as much as possible the flags >> >> regardless of the chosen compiler, so "undoing" the chosen flags >> >> seems to me cumbersome and compiler dependent, compared to resetting >> >> them altogether. I like the idea of OBJECT libraries better (it also >> >> solves other problems I have, I did not know about it!). >> >> >> >> > If you really need to solve this by explicitly modifying the global >> >> > list >> >> > for a particular file, the only thing I can think of is move those >> >> > files >> >> to >> >> > a separate CMakeList and turn them into an object library: >> >> >> >> This almost works, I have a problem specifying liking dependencies for >> >> the OBJECT libraries. With a normal library, I can use >> >> >> >> TARGET_LINK_LIBRARIES( my_library ${other_libs_my_library_depends_on} >> >> ) >> >> >> >> but if my_library is OBJECT I see the error >> >> >> >> Object library target "my_library" may not link to anything. >> >> >> > >> > See http://www.cmake.org/cmake/help/v3.0/command/add_library.html for >> the >> > correct way to do things with object libraries - for this purpose, they >> are >> > closer to source files than libraries, which makes sense given that >> there's >> > not actually a library written to disk anywhere. >> >> Mark, thanks, but here I don't find anything that answers my question, >> namely specifying that my OBJECT library (i.e. the files included in >> it) require other libraries for linking. > > > The object library is never linked, so the issue of linking with it or to > it does not arise. The targets that use the object library have transitive > linking dependencies, just like you had if the source files in the object > library had been directly specified as part of those targets. OK, let me see if I understad it. Using the example in http://www.cmake.org/Wiki/CMake/Tutorials/Object_Library let us say I have # A/CMakeLists.txt add_library(A OBJECT ${A_srcs}) # B/CMakeLists.txt add_library(B OBJECT ${B_srcs}) # CMakeLists.txt add_subdirectory(A) add_subdirectory(B) add_library(big ${other_srcs} $ $) and I know that whenever I link the files listed in ${A_srcs}, i.e. whenever I likd the OBJECT library A, I also need to link libsomeotherlibrary.a . Then in the main CMakeLists.txt I add TARGET_LINK_LIBRARIES( big someotherlibrary ) right? Moreover, there is no way to specify someotherlibrary in A/CMakeLists.txt, it has to be done where I define the target big, namely in the main CMakeLists.txt. Is this correct? Thanks, Marco From chuck.atkins at kitware.com Wed Aug 13 14:06:17 2014 From: chuck.atkins at kitware.com (Chuck Atkins) Date: Wed, 13 Aug 2014 14:06:17 -0400 Subject: [CMake] Help cmake First project In-Reply-To: References: <53DFACD1.6050807@kitware.com> <84766c09-e75c-458b-a175-6b130d9a865e@email.android.com> Message-ID: Are these actually C++ files? If so then they should really have a C++ extension (like .cp or .cxx). It may be a good idea in general since other build tools may run in to the same sort of issue of assuming they are C files. A few other tips: first, by placing all your source files in a list variable you can simplify things by operating on the entire list at once for most commands. For instance: set(2PG_SOURCES src/LoadConfig.cpp ... src/random_algorithm.c ) set_source_files_property(${2PG_SOURCES} PROPERTIES LANGUAGE CXX) add_library(2PG STATIC ${2PG_SOURCES}) Also, since you're targeting windows as well, This isn't an issue yet but something to consider: If you decide to switch to a shared library instead of static, then you will need to install that as well and shared libs on windows end up with both a resulting .lib and .dll file. When installing, you can instruct CMake to place them in different locations with: install(TARGETS 2PG_lib protpred-Gromacs-NSGA2 ... protpred-Gromacs-Sort_Method_Files_by_Front_Dominance RUNTIME DESTINATION bin LIBRARY DESTINATION lib ARCHIVE DESTINATION lib/static ) This will make sure that all executables and dll's go into the runtime location, all shared link libraries (.lib) go into the library location, and all static libraries (also.lib) go into the archive location. - Chuck On Mon, Aug 11, 2014 at 4:01 PM, Rodrigo Faccioli < rodrigo.faccioli at gmail.com> wrote: > Hi, > > Angeliki, thanks your comments. > > I used properties because my old makefile was written to use g++ despite > my files have suffix .c. I understood that cmake tried to compile my files > using gcc instead of g++. > > I removed my set compiler flags. Moreover, I have finished to compile all > programs of my project using cmake. My newer CMakeLists.txt is below and > works fine. Now I will try to compile my project for Visual Studio 10. Any > tips for this new work, I am thankful. > > cmake_minimum_required(VERSION 2.8) > > # project Information > project(2pg_cartesian) > set(PROJECT_VERSION "1.0") > > > #Set CXX compiler for all files below > set_source_files_properties(include/LoadConfig.h PROPERTIES LANGUAGE CXX ) > set_source_files_properties(src/protpred-Gromacs-NSGA2.c PROPERTIES > LANGUAGE CXX ) > set_source_files_properties(src/protpred-Gromacs-Dominance.c PROPERTIES > LANGUAGE CXX ) > set_source_files_properties(src/protpred-Gromacs-Front.c PROPERTIES > LANGUAGE CXX ) > set_source_files_properties(src/protpred-Gromacs-MC_Metropolis.c > PROPERTIES LANGUAGE CXX ) > set_source_files_properties(src/protpred-Gromacs-Mono.c PROPERTIES > LANGUAGE CXX ) > set_source_files_properties(src/protpred-Gromacs-Random_Algorithm.c > PROPERTIES LANGUAGE CXX ) > set_source_files_properties(src/protpred-Gromacs-Sort_Method_Files_by_Front_Dominance.c > PROPERTIES LANGUAGE CXX ) > set_source_files_properties(src/LoadConfig.cpp PROPERTIES LANGUAGE CXX ) > set_source_files_properties(src/ea_mono.c PROPERTIES LANGUAGE CXX ) > set_source_files_properties(src/topology.c PROPERTIES LANGUAGE CXX ) > set_source_files_properties(src/pdbio.c PROPERTIES LANGUAGE CXX ) > set_source_files_properties(src/protein.c PROPERTIES LANGUAGE CXX ) > set_source_files_properties(src/futil.c PROPERTIES LANGUAGE CXX ) > set_source_files_properties(src/pdbatom.c PROPERTIES LANGUAGE CXX ) > set_source_files_properties(src/messages.c PROPERTIES LANGUAGE CXX ) > set_source_files_properties(src/topologyio.c PROPERTIES LANGUAGE CXX ) > set_source_files_properties(src/topologylib.c PROPERTIES LANGUAGE CXX ) > set_source_files_properties(src/randomlib.c PROPERTIES LANGUAGE CXX ) > set_source_files_properties(src/vector_math.c PROPERTIES LANGUAGE CXX ) > set_source_files_properties(src/string_owner.c PROPERTIES LANGUAGE CXX ) > set_source_files_properties(src/math_owner.c PROPERTIES LANGUAGE CXX ) > set_source_files_properties(src/osutil.c PROPERTIES LANGUAGE CXX ) > set_source_files_properties(src/load_parameters.c PROPERTIES LANGUAGE CXX > ) > set_source_files_properties(src/objective.c PROPERTIES LANGUAGE CXX ) > set_source_files_properties(src/aminoacids.c PROPERTIES LANGUAGE CXX ) > set_source_files_properties(src/aminoacids_io.c PROPERTIES LANGUAGE CXX ) > set_source_files_properties(src/populationio.c PROPERTIES LANGUAGE CXX ) > set_source_files_properties(src/rotation.c PROPERTIES LANGUAGE CXX ) > set_source_files_properties(src/solution.c PROPERTIES LANGUAGE CXX ) > set_source_files_properties(src/gromacs_objectives.c PROPERTIES LANGUAGE > CXX ) > set_source_files_properties(src/solutionio.c PROPERTIES LANGUAGE CXX ) > set_source_files_properties(src/algorithms.c PROPERTIES LANGUAGE CXX ) > set_source_files_properties(src/ea_nsga2.c PROPERTIES LANGUAGE CXX ) > set_source_files_properties(src/dominance.c PROPERTIES LANGUAGE CXX ) > set_source_files_properties(src/owner_file_analysis.c PROPERTIES LANGUAGE > CXX ) > set_source_files_properties(src/mc_metropolis.c PROPERTIES LANGUAGE CXX ) > set_source_files_properties(src/random_algorithm.c PROPERTIES LANGUAGE CXX > ) > > # set include > include_directories(include) > > # add libries > add_library(2PG_lib STATIC > src/LoadConfig.cpp > src/ea_mono.c > src/topology.c > src/pdbio.c > src/protein.c > src/futil.c > src/pdbatom.c > src/messages.c > src/topologyio.c > src/topologylib.c > src/randomlib.c > src/vector_math.c > src/string_owner.c > src/math_owner.c > src/osutil.c > src/load_parameters.c > src/objective.c > src/aminoacids.c > src/aminoacids_io.c > src/populationio.c > src/rotation.c > src/solution.c > src/gromacs_objectives.c > src/solutionio.c > src/algorithms.c > src/ea_nsga2.c > src/dominance.c > src/owner_file_analysis.c > src/mc_metropolis.c > src/random_algorithm.c > ) #end of 2PG_lib > > # add target > add_executable(protpred-Gromacs-NSGA2 src/protpred-Gromacs-NSGA2.c) > target_link_libraries(protpred-Gromacs-NSGA2 2PG_lib) > > add_executable(protpred-Gromacs-Dominance src/protpred-Gromacs-Dominance.c) > target_link_libraries(protpred-Gromacs-Dominance 2PG_lib) > > add_executable(protpred-Gromacs-Front src/protpred-Gromacs-Front.c) > target_link_libraries(protpred-Gromacs-Front 2PG_lib) > > add_executable(protpred-Gromacs-MC_Metropolis > src/protpred-Gromacs-MC_Metropolis.c) > target_link_libraries(protpred-Gromacs-MC_Metropolis 2PG_lib) > > add_executable(protpred-Gromacs-Mono src/protpred-Gromacs-Mono.c) > target_link_libraries(protpred-Gromacs-Mono 2PG_lib) > > add_executable(protpred-Gromacs-Random_Algorithm > src/protpred-Gromacs-Random_Algorithm.c) > target_link_libraries(protpred-Gromacs-Random_Algorithm 2PG_lib) > > add_executable(protpred-Gromacs-Sort_Method_Files_by_Front_Dominance > src/protpred-Gromacs-Sort_Method_Files_by_Front_Dominance.c) > target_link_libraries(protpred-Gromacs-Sort_Method_Files_by_Front_Dominance > 2PG_lib) > > > # install > install(TARGETS protpred-Gromacs-NSGA2 DESTINATION bin) > install(TARGETS protpred-Gromacs-Dominance DESTINATION bin) > install(TARGETS protpred-Gromacs-Front DESTINATION bin) > install(TARGETS protpred-Gromacs-MC_Metropolis DESTINATION bin) > install(TARGETS protpred-Gromacs-Mono DESTINATION bin) > install(TARGETS protpred-Gromacs-Random_Algorithm DESTINATION bin) > install(TARGETS protpred-Gromacs-Sort_Method_Files_by_Front_Dominance > DESTINATION bin) > > > Best regards, > > > > -- > Rodrigo Antonio Faccioli, Ph.D > Development Software for Structural Bioinformatics > Barao de Maua University > University of Sao Paulo > Lindedin - br.linkedin.com/pub/rodrigo-antonio-faccioli/7/589/a5/ > Curriculum Lattes - http://lattes.cnpq.br/1025157978990218 > > > On Wed, Aug 6, 2014 at 5:32 AM, Angeliki Chrysochou < > angeliki.chrysochou at gmail.com> wrote: > >> Hi Rodrigo, >> >> Glad that it is working for you now. I just wanted to mention that I >> never had to set the language as properties to the source files since cmake >> detects it from the suffix of the source files you list, or at least I >> never had a case where the language was not properly detected. >> >> Other than that I agree with Hendrik's suggestions as well! >> >> Cheers, >> Angeliki >> >> >> >> >> >> >> On Wed, Aug 6, 2014 at 5:54 AM, Hendrik Sattler >> wrote: >> >>> Hi, >>> >>> -lm does not belong to CMAKE_CXX_FLAGS as it is a linker option to link >>> libm. >>> Use >>> target_link_libraries(protpred-Gromacs-NSGA2 m) >>> instead. (Don't search for libm, the linker knows where it is.) >>> >>> It is also more common to use a variable for the list of source files. >>> That would make it also possible to set the compile language for all files >>> in one command without listing files twice. >>> >>> Adding headers and not just .c/.cpp/.cxx files makes it easier when >>> using an IDE. >>> >>> >>> >>> On 5. August 2014 22:13:54 MESZ, Rodrigo Faccioli < >>> rodrigo.faccioli at gmail.com> wrote: >>> >Hi, >>> > >>> >I am thankfull for all help. Now, it is working :-) >>> > >>> >Radovan, thank you to try to run and your comments. >>> > >>> >My CMakeList.txt is showed below. I would like to know about best >>> >practice >>> >to make a CMakeList. If agree, I will compile others executables of my >>> >project based on how I compiled this executable. In [1] contains my >>> >full >>> >project. >>> > >>> >cmake_minimum_required(VERSION 2.8) >>> > >>> ># project Information >>> >project(2pg_cartesian) >>> >set(PROJECT_VERSION "1.0") >>> > >>> ># Set compiler flags >>> >SET ( CMAKE_CXX_FLAGS "-lm -pedantic") >>> > >>> >#Set CXX compiler for all files below >>> >set_source_files_properties(include/LoadConfig.h PROPERTIES LANGUAGE >>> >CXX ) >>> >set_source_files_properties(src/protpred-Gromacs-NSGA2.c PROPERTIES >>> >LANGUAGE CXX ) >>> >set_source_files_properties(src/LoadConfig.cpp PROPERTIES LANGUAGE CXX >>> >) >>> >set_source_files_properties(src/ea_mono.c PROPERTIES LANGUAGE CXX ) >>> >set_source_files_properties(src/topology.c PROPERTIES LANGUAGE CXX ) >>> >set_source_files_properties(src/pdbio.c PROPERTIES LANGUAGE CXX ) >>> >set_source_files_properties(src/protein.c PROPERTIES LANGUAGE CXX ) >>> >set_source_files_properties(src/futil.c PROPERTIES LANGUAGE CXX ) >>> >set_source_files_properties(src/pdbatom.c PROPERTIES LANGUAGE CXX ) >>> >set_source_files_properties(src/messages.c PROPERTIES LANGUAGE CXX ) >>> >set_source_files_properties(src/topologyio.c PROPERTIES LANGUAGE CXX ) >>> >set_source_files_properties(src/topologylib.c PROPERTIES LANGUAGE CXX >>> >) >>> >set_source_files_properties(src/randomlib.c PROPERTIES LANGUAGE CXX ) >>> >set_source_files_properties(src/vector_math.c PROPERTIES LANGUAGE CXX >>> >) >>> >set_source_files_properties(src/string_owner.c PROPERTIES LANGUAGE CXX >>> >) >>> >set_source_files_properties(src/math_owner.c PROPERTIES LANGUAGE CXX >>> >) >>> >set_source_files_properties(src/osutil.c PROPERTIES LANGUAGE CXX ) >>> >set_source_files_properties(src/load_parameters.c PROPERTIES LANGUAGE >>> >CXX ) >>> >set_source_files_properties(src/objective.c PROPERTIES LANGUAGE CXX ) >>> >set_source_files_properties(src/aminoacids.c PROPERTIES LANGUAGE CXX ) >>> >set_source_files_properties(src/aminoacids_io.c PROPERTIES LANGUAGE >>> >CXX ) >>> >set_source_files_properties(src/populationio.c PROPERTIES LANGUAGE CXX >>> >) >>> >set_source_files_properties(src/rotation.c PROPERTIES LANGUAGE CXX ) >>> >set_source_files_properties(src/solution.c PROPERTIES LANGUAGE CXX ) >>> >set_source_files_properties(src/gromacs_objectives.c PROPERTIES >>> >LANGUAGE >>> >CXX ) >>> >set_source_files_properties(src/solutionio.c PROPERTIES LANGUAGE CXX ) >>> >set_source_files_properties(src/algorithms.c PROPERTIES LANGUAGE CXX ) >>> >set_source_files_properties(src/ea_nsga2.c PROPERTIES LANGUAGE CXX ) >>> >set_source_files_properties(src/dominance.c PROPERTIES LANGUAGE CXX ) >>> > >>> ># set include >>> >include_directories(include) >>> > >>> ># add libries >>> >add_library(2PG-NSGA2_lib STATIC >>> >src/LoadConfig.cpp >>> >src/ea_mono.c >>> >src/topology.c >>> >src/pdbio.c >>> >src/protein.c >>> >src/futil.c >>> >src/pdbatom.c >>> >src/messages.c >>> >src/topologyio.c >>> >src/topologylib.c >>> >src/randomlib.c >>> >src/vector_math.c >>> >src/string_owner.c >>> >src/math_owner.c >>> >src/osutil.c >>> >src/load_parameters.c >>> >src/objective.c >>> >src/aminoacids.c >>> >src/aminoacids_io.c >>> >src/populationio.c >>> >src/rotation.c >>> >src/solution.c >>> >src/gromacs_objectives.c >>> >src/solutionio.c >>> >src/algorithms.c >>> >src/ea_nsga2.c >>> >src/dominance.c >>> >) #end of 2PG-NSGA2_lib >>> > >>> ># add target >>> >add_executable(protpred-Gromacs-NSGA2 src/protpred-Gromacs-NSGA2.c) >>> >target_link_libraries(protpred-Gromacs-NSGA2 2PG-NSGA2_lib) >>> > >>> ># install >>> >install(TARGETS protpred-Gromacs-NSGA2 DESTINATION bin) >>> > >>> >[1] https://dl.dropboxusercontent.com/u/4270818/2pg_cartesian_cmake.zip >>> > >>> >Best regards, >>> > >>> >-- >>> >Rodrigo Antonio Faccioli, Ph.D >>> >Development Software for Structural Bioinformatics >>> >Barao de Maua University >>> >University of Sao Paulo >>> >Lindedin - br.linkedin.com/pub/rodrigo-antonio-faccioli/7/589/a5/ >>> >Curriculum Lattes - http://lattes.cnpq.br/1025157978990218 >>> > >>> > >>> >On Tue, Aug 5, 2014 at 3:39 PM, radovan bast wrote: >>> > >>> >> dear Rodrigo, >>> >> >>> >> i tried it but ran into many other problems in the source, not cmake. >>> >> >>> >> but also some cmake suggestions: >>> >> - list the language(s) that the project uses >>> >> - the c99 flag is not a definition but a compiler flag, use >>> >> CMAKE_CXX_FLAGS_... for portability >>> >> - "ALL" is not a good library name >>> >> - i recommend to not glob sources but to list them explicitly, there >>> >are >>> >> several discussions on the net >>> >> which explain why if you search for the topic >>> >> >>> >> good luck! >>> >> radovan >>> >> >>> >> >>> >> On Tue, Aug 5, 2014 at 5:08 PM, Rodrigo Faccioli < >>> >> rodrigo.faccioli at gmail.com> wrote: >>> >> >>> >>> Hi, >>> >>> >>> >>> Thanks Angeliki and Bill for your attentation. >>> >>> >>> >>> I have updated my CMakeList.txt based on your post. Below my >>> >>> CMakeList.txt is showed. >>> >>> >>> >>> cmake_minimum_required(VERSION 2.8) >>> >>> # project Information >>> >>> project(2pg_cartesian) >>> >>> set(PROJECT_VERSION "1.0") >>> >>> # add definitions to compiler >>> >>> add_definitions(-std=c99) >>> >>> # get all files under directory src >>> >>> file(GLOB SRC_FILES "src/*.c") >>> >>> # set include >>> >>> include_directories(include) >>> >>> # added libries >>> >>> add_library(ALL STATIC ${SRC_FILES}) >>> >>> # add target >>> >>> add_executable(protpred-Gromacs-NSGA2 src/protpred-Gromacs-NSGA2.c) >>> >>> target_link_libraries(protpred-Gromacs-NSGA2 ALL) >>> >>> >>> >>> Unfortunatelly, I have received error messages as cited below: >>> >>> faccioli at faccioli:~/Downloads/2pg_cartesian/build$ make >>> >>> Scanning dependencies of target ALL >>> >>> [ 2%] Building C object >>> >CMakeFiles/ALL.dir/src/protpred-Gromacs-NSGA2.c.o >>> >>> [ 5%] Building C object CMakeFiles/ALL.dir/src/ea_mono.c.o >>> >>> [ 7%] Building C object CMakeFiles/ALL.dir/src/topologyio.c.o >>> >>> [ 10%] Building C object CMakeFiles/ALL.dir/src/aminoacids.c.o >>> >>> [ 12%] Building C object CMakeFiles/ALL.dir/src/populationio.c.o >>> >>> [ 15%] Building C object CMakeFiles/ALL.dir/src/osutil.c.o >>> >>> [ 17%] Building C object CMakeFiles/ALL.dir/src/aminoacids_io.c.o >>> >>> [ 20%] Building C object >>> >>> >>> >>> >CMakeFiles/ALL.dir/src/protpred-Gromacs-Sort_Method_Files_by_Front_Dominance.c.o >>> >>> [ 23%] Building C object CMakeFiles/ALL.dir/src/pdbio.c.o >>> >>> [ 25%] Building C object CMakeFiles/ALL.dir/src/solution.c.o >>> >>> [ 28%] Building C object CMakeFiles/ALL.dir/src/vector_math.c.o >>> >>> [ 30%] Building C object CMakeFiles/ALL.dir/src/math_owner.c.o >>> >>> [ 33%] Building C object CMakeFiles/ALL.dir/src/protein.c.o >>> >>> [ 35%] Building C object CMakeFiles/ALL.dir/src/load_parameters.c.o >>> >>> In file included from >>> >>> /home/faccioli/Downloads/2pg_cartesian/src/load_parameters.c:7:0: >>> >>> /home/faccioli/Downloads/2pg_cartesian/include/LoadConfig.h:1:18: >>> >fatal >>> >>> error: string: Arquivo ou diret?rio n?o encontrado >>> >>> compilation terminated. >>> >>> make[2]: ** [CMakeFiles/ALL.dir/src/load_parameters.c.o] Erro 1 >>> >>> make[1]: ** [CMakeFiles/ALL.dir/all] Erro 2 >>> >>> make: ** [all] Erro 2 >>> >>> faccioli at faccioli:~/Downloads/2pg_cartesian/build$ >>> >>> >>> >>> I did not understand what mistakes I have done since all files share >>> >same >>> >>> structure of directory. In [1] is my project completly. If prefer I >>> >can >>> >>> send its github repository. >>> >>> >>> >>> I appreciate any help. >>> >>> >>> >>> Best regards, >>> >>> >>> >>> [1] >>> >https://dl.dropboxusercontent.com/u/4270818/2pg_cartesian_cmake.zip >>> >>> >>> >>> >>> >>> -- >>> >>> Rodrigo Antonio Faccioli, Ph.D >>> >>> Development Software for Structural Bioinformatics >>> >>> Barao de Maua University >>> >>> University of Sao Paulo >>> >>> Lindedin - br.linkedin.com/pub/rodrigo-antonio-faccioli/7/589/a5/ >>> >>> Curriculum Lattes - http://lattes.cnpq.br/1025157978990218 >>> >>> >>> >>> >>> >>> On Mon, Aug 4, 2014 at 12:54 PM, Bill Hoffman >>> > >>> >>> wrote: >>> >>> >>> >>>> On 8/4/2014 10:26 AM, Rodrigo Faccioli wrote: >>> >>>> >>> >>>>> protpred-Gromacs-NSGA2.c:(.text+0x1e): undefined reference to >>> >>>>> `display_msg' >>> >>>>> protpred-Gromacs-NSGA2.c:(.text+0x3e): undefined reference to >>> >>>>> `load_parameters_from_file' >>> >>>>> protpred-Gromacs-NSGA2.c:(.text+0x58): undefined reference to >>> >>>>> `ea_nsga2' >>> >>>>> protpred-Gromacs-NSGA2.c:(.text+0x64): undefined reference to >>> >>>>> `fatal_error' >>> >>>>> protpred-Gromacs-NSGA2.c:(.text+0x73): undefined reference to >>> >>>>> `deAllocateload_parameters' >>> >>>>> protpred-Gromacs-NSGA2.c:(.text+0x7d): undefined reference to >>> >>>>> `display_msg' >>> >>>>> >>> >>>> You have to find out where these symbols are defined. If you have >>> >a >>> >>>> working Makefile version use nm and grep to find the places. You >>> >can also >>> >>>> grep your source tree. You are either missing a source file, or a >>> >-D >>> >>>> option. >>> >>>> >>> >>>> Another approach is to run make VERBOSE=1 and compare the build >>> >command >>> >>>> lines to your Makefile build. >>> >>>> >>> >>>> -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 >>> >>>> >>> >>> >>> >>> >>> >>> -- >>> >>> >>> >>> 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 >>> >>> >>> >> >>> >> >>> >> >>> >> -- >>> >> # PDC Center for High Performance Computing & >>> >> # Department of Theoretical Chemistry and Biology >>> >> # Royal Institute of Technology, Stockholm >>> >> # +46-8-790-6628 >>> >> >>> > >>> > >>> >------------------------------------------------------------------------ >>> >>> >>> -- >>> >>> 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 nagger at gmx.de Wed Aug 13 15:40:34 2014 From: nagger at gmx.de (Nagger) Date: Wed, 13 Aug 2014 21:40:34 +0200 Subject: [CMake] Generator-independent incremental CMake run Message-ID: <53EBBF32.7000709@gmx.de> Hello, For our Continuous Integration tests we need fast incremental builds (only build what has changed). This also includes that CMake only has to run if necessary (some CMakeLists.txt changed). It seems there is no beautiful/portable/generator-independent way to do this?! Fortunately we mainly use the VisualStudio2010 x64 Generator, so I wrote this hard-coded batch script: echo === %DATE% == %TIME% ========= CMake... set BUILD_DIR=build set SOURCE_DIR=%CD% if not exist %BUILD_DIR% goto generate if not exist %BUILD_DIR%\CMakeCache.txt goto generate if not exist %BUILD_DIR%\*.sln goto generate :update echo Solution exists, only updating... cmake --build %BUILD_DIR% --target ZERO_CHECK if %errorlevel% == 0 goto build :generate if not exist "%BUILD_DIR%" mkdir "%BUILD_DIR%" pushd %BUILD_DIR% echo Generating Solution... cmake -G "Visual Studio 10 Win64" "%SOURCE_DIR%" set el=%ERRORLEVEL% popd if %el% neq 0 exit /b %el% :build echo === %DATE% == %TIME% ========= Building... cmake --build %BUILD_DIR% --config Release exit /b %ERRORLEVEL% This script works well, but I'm looking for a generator-independent way for this script! Does anyone already came up with a good solution? Isn't this a common problem? Some of my thoughts: "cmake --build" returns "1" on every kind of error (no binary dir, no solution, real build errors, ...). It would be nice to have a different return value for cmake internal errors (every error prior starting the actual build). But what I really miss is an "--update" option for CMake which is doing all the work (updating if possible, configuring if necessary) internally. It would use the implementation of 'cmake --build' to trigger a re-configure and if that is not possible it would start a fresh configure&generate. Any thoughts about that? Thanks, Marc From paul at mad-scientist.net Wed Aug 13 15:59:35 2014 From: paul at mad-scientist.net (Paul Smith) Date: Wed, 13 Aug 2014 15:59:35 -0400 Subject: [CMake] Generator-independent incremental CMake run In-Reply-To: <53EBBF32.7000709@gmx.de> References: <53EBBF32.7000709@gmx.de> Message-ID: <1407959975.3525.16.camel@mad-scientist.net> On Wed, 2014-08-13 at 21:40 +0200, Nagger wrote: > Does anyone already came up with a good solution? Isn't this a common > problem? I'm not sure about the other generators, but the makefile generator has this built-in; that is, if the makefiles detect that a cmake file has changed it will re-run cmake then restart the build. From nagger at gmx.de Wed Aug 13 16:53:45 2014 From: nagger at gmx.de (Nagger) Date: Wed, 13 Aug 2014 22:53:45 +0200 Subject: [CMake] Generator-independent incremental CMake run In-Reply-To: <1407959975.3525.16.camel@mad-scientist.net> References: <53EBBF32.7000709@gmx.de> <1407959975.3525.16.camel@mad-scientist.net> Message-ID: <53EBD059.8000408@gmx.de> Am 13.08.2014 21:59, schrieb Paul Smith: > On Wed, 2014-08-13 at 21:40 +0200, Nagger wrote: >> Does anyone already came up with a good solution? Isn't this a common >> problem? > > I'm not sure about the other generators, but the makefile generator has > this built-in; that is, if the makefiles detect that a cmake file has > changed it will re-run cmake then restart the build. > I'm aware of this. But at least you have to know that a make-generator creates a 'Makefile'. You must test if it exists or start an initial CMake run otherwise. And for every other generator a different filename must be checked. And maybe for other generators there is also a ZERO_CHECK target which needs to run before the actual build is started. "cmake --build" already unifies lot of this stuff, but unfortunately not enough. I hope(d) someone already did some work. The Jenkins CMake-plugin is quite stupid for running CMake 'incrementally'. What about other CI servers? Thanks, Marc From post at hendrik-sattler.de Thu Aug 14 02:13:38 2014 From: post at hendrik-sattler.de (Hendrik Sattler) Date: Thu, 14 Aug 2014 08:13:38 +0200 Subject: [CMake] Generator-independent incremental CMake run In-Reply-To: <53EBBF32.7000709@gmx.de> References: <53EBBF32.7000709@gmx.de> Message-ID: <893c17d6-7d88-4f6c-9738-c89a652a3cef@email.android.com> On 13. August 2014 21:40:34 MESZ, Nagger wrote: >But what I really miss is an "--update" option for CMake which is doing > >all the work (updating if possible, configuring if necessary) >internally. It would use the implementation of 'cmake --build' to >trigger a re-configure and if that is not possible it would start a >fresh configure&generate. >Any thoughts about that? cmake $builddir does exactly that. The ZERO_CHECK visual studio target that is present in every cmake generated solution does this: it checks if cmake needs to be re-run. It is built before every other target. So your batch file does a lot of things that are already done by cmake. Well unless you explicitly disabled this. But you'd know then. HS From ycollette.nospam at free.fr Thu Aug 14 05:19:19 2014 From: ycollette.nospam at free.fr (ycollette.nospam at free.fr) Date: Thu, 14 Aug 2014 11:19:19 +0200 (CEST) Subject: [CMake] ctest and tracks Message-ID: <1888798950.20039900.1408007959300.JavaMail.root@zimbra35-e6.priv.proxad.net> Hello, I've have configured a project to use dash to save test results. On thing is not clear in the ctest documentation: what is the use of the --track option ? Does it allow to create a new category (like Weekly) and submit the test results to this new category ? Best regards, YC From dlrdave at aol.com Thu Aug 14 07:33:01 2014 From: dlrdave at aol.com (David Cole) Date: Thu, 14 Aug 2014 07:33:01 -0400 (EDT) Subject: [CMake] ctest and tracks In-Reply-To: <1888798950.20039900.1408007959300.JavaMail.root@zimbra35-e6.priv.proxad.net> References: <1888798950.20039900.1408007959300.JavaMail.root@zimbra35-e6.priv.proxad.net> Message-ID: <8D185CAA3D670F7-1F2C-7F24@webmail-m150.sysops.aol.com> --track is the same as the TRACK argument to the ctest_start scripting command. http://www.cmake.org/cmake/help/v3.0/command/ctest_start.html It will send a dashboard to the named section of a CDash project page, but it will NOT create it. You have to create the track (called a "group" in the CDash admin pages) as the CDash project admin first before you can send to it. For example, on the VTK Wiki Examples dashboard, there is a "Wiki Examples" track/group/section, which was created by the project admin before dashboards were submitted to that track. http://open.cdash.org/index.php?project=VTKWikiExamples HTH, David C. From ravi.raman at Xoriant.Com Thu Aug 14 08:55:11 2014 From: ravi.raman at Xoriant.Com (Ravi Raman) Date: Thu, 14 Aug 2014 12:55:11 +0000 Subject: [CMake] Regarding enviroment variables directly used in executables In-Reply-To: <8D18431651CAD63-1D58-1EA0B@webmail-vm030.sysops.aol.com> References: <8D18431651CAD63-1D58-1EA0B@webmail-vm030.sysops.aol.com> Message-ID: <94d375eed2714627b828cdb0e31ac779@XORMUM-MBX01.India.XoriantCorp.com> Hi David, In our cmake project, we have the following scenario: 1. add_custom_command() call is as follows: add_custom_command(TARGET ${TESTTARGETNAME} POST_BUILD COMMENT "Test target 1..." COMMAND python ${CMAKE_SOURCE_DIR}/testthetargets.bat "TestTarget1" "${TESTBIN}" ) 2. The code in the batch file testthetargets.bat is as follows: It invokes a project specific executable testtarget1.exe. The source code of testtarget1.exe has calls to get few environment variables using getenv() function call. For example, a sample getenv() call is as follows: target2_exe_path = getenv("TARGET2_EXE_PATH"); So, here the above getenv() call is supposed to get the value of environment variable TARGET2_EXE_PATH. Issue we are facing is as follows: 1. We set environment variable TARGET2_EXE_PATH using the following cmake SET command before the add_custom_command() execution: SET(ENV{TARGET2_EXE_PATH} "C:/Test/Target2") 2. But when the add_custom_command() gets executed, we observe that the environment variable TARGET2_EXE_PATH is not getting reflected in the above getenv() call in the source code of testtarget1.exe. The getenv() call returns an empty string. But this issue does not occur when TARGET2_EXE_PATH environment variable is set from Windows directly (i.e. from System Properties -> Advanced -> Environment Variables). In that case, TARGET2_EXE_PATH gets reflected in the above getenv() call. So, basically the call to SET(ENV{TARGET2_EXE_PATH} "C:/Test/Target2") has no impact on the call to getenv() in the source code. Kindly let us know if there is any other way in this case other than setting the TARGET2_EXE_PATH environment variable from Windows directly ? Thanks & Regards Ravi Raman Xoriant Solutions Pvt. Ltd 4th Floor, Winchester, Hiranandani Business Park, Powai, Mumbai 400076, INDIA. Tel: +91 22 30511000,9930100026 Extn: 2144 Voip No. 4088344495/96/97/98 Voip Extn:1178| Fax: +91 22 30511111 ravi.raman at xoriant.com| http://www.xoriant.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From dlrdave at aol.com Thu Aug 14 09:32:19 2014 From: dlrdave at aol.com (David Cole) Date: Thu, 14 Aug 2014 09:32:19 -0400 (EDT) Subject: [CMake] Regarding enviroment variables directly used in executables In-Reply-To: <94d375eed2714627b828cdb0e31ac779@XORMUM-MBX01.India.XoriantCorp.com> References: <8D18431651CAD63-1D58-1EA0B@webmail-vm030.sysops.aol.com> <94d375eed2714627b828cdb0e31ac779@XORMUM-MBX01.India.XoriantCorp.com> Message-ID: <8D185DB4E714DE3-1F2C-8ACA@webmail-m150.sysops.aol.com> A "SET(ENV{TARGET2_EXE_PATH} "C:/Test/Target2")" call in a CMakeLists file only has an effect while CMake is running. If you need the env var set for your batch file to run, you should pass the value for it down in as an arg to the batch file, and then do: set TARGET2_EXE_PATH=%~1 (no quotes in the batch file set, %~1 means arg 1 to the batch file, but with any surrounding quotes stripped...) HTH, David From ycollette.nospam at free.fr Thu Aug 14 09:35:43 2014 From: ycollette.nospam at free.fr (ycollette.nospam at free.fr) Date: Thu, 14 Aug 2014 15:35:43 +0200 (CEST) Subject: [CMake] ctest and tracks In-Reply-To: <8D185CAA3D670F7-1F2C-7F24@webmail-m150.sysops.aol.com> Message-ID: <1682905093.20338406.1408023343373.JavaMail.root@zimbra35-e6.priv.proxad.net> OK, thanks for the informations. It's a lot more clear now. YC ----- Mail original ----- De: "David Cole" ?: "ycollette nospam" , cmake at cmake.org Envoy?: Jeudi 14 Ao?t 2014 13:33:01 Objet: Re: [CMake] ctest and tracks --track is the same as the TRACK argument to the ctest_start scripting command. http://www.cmake.org/cmake/help/v3.0/command/ctest_start.html It will send a dashboard to the named section of a CDash project page, but it will NOT create it. You have to create the track (called a "group" in the CDash admin pages) as the CDash project admin first before you can send to it. For example, on the VTK Wiki Examples dashboard, there is a "Wiki Examples" track/group/section, which was created by the project admin before dashboards were submitted to that track. http://open.cdash.org/index.php?project=VTKWikiExamples HTH, David C. From nagger at gmx.de Thu Aug 14 10:02:26 2014 From: nagger at gmx.de (Nagger) Date: Thu, 14 Aug 2014 16:02:26 +0200 Subject: [CMake] Generator-independent incremental CMake run In-Reply-To: <893c17d6-7d88-4f6c-9738-c89a652a3cef@email.android.com> References: <53EBBF32.7000709@gmx.de> <893c17d6-7d88-4f6c-9738-c89a652a3cef@email.android.com> Message-ID: <53ECC172.3020906@gmx.de> Am 14.08.2014 08:13, schrieb Hendrik Sattler: > On 13. August 2014 21:40:34 MESZ, Nagger wrote: >> But what I really miss is an "--update" option for CMake which is doing >> >> all the work (updating if possible, configuring if necessary) >> internally. It would use the implementation of 'cmake --build' to >> trigger a re-configure and if that is not possible it would start a >> fresh configure&generate. >> Any thoughts about that? > > cmake $builddir > > does exactly that. This does not work here. "cmake $builddir" does a full configure&generate. (CMake version is 2.8.12) We have a fairly large project with about 400 targets. $ cmake %builddir% -> takes about 5 minutes for a No-op $ cmake --build %builddir% --target ZERO_CHECK -> takes 20 seconds for No-op > The ZERO_CHECK visual studio target that is present in every cmake generated solution does this: it checks if cmake needs to be re-run. It is built before every other target. So your batch file does a lot of things that are already done by cmake. If the build is started from command line (cmake --build or msbuild directly) your wont get the "Project has changed! Abort and Reload?"-Dialog. The old solution will be build. You need to execute the build-process a seconds time. Or - as the script does - start a separate ZERO_CHECK before the actual build. Marc From dlrdave at aol.com Thu Aug 14 10:31:33 2014 From: dlrdave at aol.com (David Cole) Date: Thu, 14 Aug 2014 10:31:33 -0400 (EDT) Subject: [CMake] Generator-independent incremental CMake run In-Reply-To: <53ECC172.3020906@gmx.de> References: <53EBBF32.7000709@gmx.de> <893c17d6-7d88-4f6c-9738-c89a652a3cef@email.android.com> <53ECC172.3020906@gmx.de> Message-ID: <8D185E394B05BC3-1F2C-9145@webmail-m150.sysops.aol.com> > We have a fairly large project with about 400 targets. > $ cmake %builddir% > -> takes about 5 minutes for a No-op > > $ cmake --build %builddir% --target ZERO_CHECK > -> takes 20 seconds for No-op This is the problem. "cmake %builddir%" should be as fast as possible for a no-op... If it's not, it would be good to solve the real underlying problem that causes it to take 5 minutes for "nothing" rather than write elaborate scripts to try to workaround it. Is your project publicly available so CMake devs can try to figure out why it takes so long? Or... can you produce a generated repro case that demonstrates a long no-op time....? There must be something in your project's CMake code that triggers the performance problem. Does it still happen with the latest release (CMake 3.0.1)? D From nagger at gmx.de Thu Aug 14 11:26:39 2014 From: nagger at gmx.de (Nagger) Date: Thu, 14 Aug 2014 17:26:39 +0200 Subject: [CMake] Generator-independent incremental CMake run In-Reply-To: <8D185E394B05BC3-1F2C-9145@webmail-m150.sysops.aol.com> References: <53EBBF32.7000709@gmx.de> <893c17d6-7d88-4f6c-9738-c89a652a3cef@email.android.com> <53ECC172.3020906@gmx.de> <8D185E394B05BC3-1F2C-9145@webmail-m150.sysops.aol.com> Message-ID: <53ECD52F.8010104@gmx.de> Am 14.08.2014 16:31, schrieb David Cole: >> We have a fairly large project with about 400 targets. >> $ cmake %builddir% >> -> takes about 5 minutes for a No-op >> >> $ cmake --build %builddir% --target ZERO_CHECK >> -> takes 20 seconds for No-op > > This is the problem. > > "cmake %builddir%" should be as fast as possible for a no-op... If it's > not, it would be good to solve the real underlying problem that causes > it to take 5 minutes for "nothing" rather than write elaborate scripts > to try to workaround it. I already had a look into our large generation time. They are multiple reasons, not one big issue which can be solved easily. But with all due respect, its not just a 'workaround'. I do not want to re-compile things that haven't changed, so i also do not want to re-generate if nothing has changed. A ZERO_CHECK (comparing timestamps of all used CMakeLists.txt) will always be faster than generating the project. Test with CMake 3.0.1 configuring CMake itself: $ git describe v3.0.1-1690-geb3b550 $ cmake --version cmake version 3.0.1 CMake suite maintained and supported by Kitware (kitware.com/cmake). $ time cmake build -- Configuring done -- Generating done -- Build files have been written to: D:/Playground/cmake/cmake/build real 0m14.414s user 0m0.000s sys 0m0.015s $ time cmake --build build --target ZERO_CHECK Microsoft (R) Build Engine version 4.0.30319.17929 [....] real 0m0.421s user 0m0.000s sys 0m0.015s So ZERO_CHECK is 34 times faster. Why shouldn't I take advantage of that. Thank, Marc From bill.hoffman at kitware.com Thu Aug 14 11:42:50 2014 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Thu, 14 Aug 2014 11:42:50 -0400 Subject: [CMake] Generator-independent incremental CMake run In-Reply-To: <53ECD52F.8010104@gmx.de> References: <53EBBF32.7000709@gmx.de> <893c17d6-7d88-4f6c-9738-c89a652a3cef@email.android.com> <53ECC172.3020906@gmx.de> <8D185E394B05BC3-1F2C-9145@webmail-m150.sysops.aol.com> <53ECD52F.8010104@gmx.de> Message-ID: <53ECD8FA.7050009@kitware.com> On 8/14/2014 11:26 AM, Nagger wrote: > > So ZERO_CHECK is 34 times faster. Why shouldn't I take advantage of that. If CMake does not need to re-run, then ZERO_CHECK will always be faster than cmake build_dir. cmake build_dir will run a full configure and generate no matter what. That said, a cmake --build all, should do the same thing. Going back to your original question: > > For our Continuous Integration tests we need fast incremental builds (only build what has changed). > This also includes that CMake only has to run if necessary (some CMakeLists.txt changed). > It seems there is no beautiful/portable/generator-independent way to do this?! The way to do this is to use a ctest script. You can basically do all the stuff in your batch script. It would be something like this: if(NOT EXISTS ${BULD_TREE) do_configure_and_build() endif() function(do_configure_and_build) ctest_update() ctest_configure() ctest_build() endfunction() Usually, it should be enough to have your version control system tell you if something has really changed. If so, you will want to do a configure/build. -Bill From glenn.coombs at gmail.com Thu Aug 14 14:58:36 2014 From: glenn.coombs at gmail.com (Glenn Coombs) Date: Thu, 14 Aug 2014 19:58:36 +0100 Subject: [CMake] Resetting CMAKE_Fortran_FLAGS for a specific file In-Reply-To: References: Message-ID: In my opinion this is a deficiency in how cmake currently works with object libraries. If one of the source files in an object library depends on a third library then it should be possible to specify that in the link interface of either the object library or the source file. It is wrong to have to specify the dependency multiple times for every library or executable that uses the object library. It is a property of the object library, not the users of the object library. I believe there is already a enhancement request open for something like this. -- Glenn On 13 August 2014 15:44, marco restelli wrote: > 2014-08-13 16:16 GMT+0200, Mark Abraham : > > On Wed, Aug 13, 2014 at 7:12 AM, marco restelli > > wrote: > > > >> 2014-08-13 15:53 GMT+0200, Mark Abraham : > >> > On Wed, Aug 13, 2014 at 3:18 AM, marco restelli > >> > wrote: > >> > > >> >> Hi Petr, > >> >> thanks, very informative! > >> >> > >> >> 2014-08-13 9:20 GMT+0200, Petr Kmoch : > >> >> > Hi Marco. > >> >> > > >> >> > Sane compilers allow later command-line options to override earlier > >> >> > ones, > >> >> > so what you're doing should be fine. Unfortunately, I know some > >> Fortran > >> >> > compilers are not sane in this regard. > >> >> > >> >> Here, I would really like to reduce as much as possible the flags > >> >> regardless of the chosen compiler, so "undoing" the chosen flags > >> >> seems to me cumbersome and compiler dependent, compared to resetting > >> >> them altogether. I like the idea of OBJECT libraries better (it also > >> >> solves other problems I have, I did not know about it!). > >> >> > >> >> > If you really need to solve this by explicitly modifying the global > >> >> > list > >> >> > for a particular file, the only thing I can think of is move those > >> >> > files > >> >> to > >> >> > a separate CMakeList and turn them into an object library: > >> >> > >> >> This almost works, I have a problem specifying liking dependencies > for > >> >> the OBJECT libraries. With a normal library, I can use > >> >> > >> >> TARGET_LINK_LIBRARIES( my_library ${other_libs_my_library_depends_on} > >> >> ) > >> >> > >> >> but if my_library is OBJECT I see the error > >> >> > >> >> Object library target "my_library" may not link to anything. > >> >> > >> > > >> > See http://www.cmake.org/cmake/help/v3.0/command/add_library.html for > >> the > >> > correct way to do things with object libraries - for this purpose, > they > >> are > >> > closer to source files than libraries, which makes sense given that > >> there's > >> > not actually a library written to disk anywhere. > >> > >> Mark, thanks, but here I don't find anything that answers my question, > >> namely specifying that my OBJECT library (i.e. the files included in > >> it) require other libraries for linking. > > > > > > The object library is never linked, so the issue of linking with it or to > > it does not arise. The targets that use the object library have > transitive > > linking dependencies, just like you had if the source files in the object > > library had been directly specified as part of those targets. > > OK, let me see if I understad it. Using the example in > > http://www.cmake.org/Wiki/CMake/Tutorials/Object_Library > > let us say I have > > > # A/CMakeLists.txt > add_library(A OBJECT ${A_srcs}) > > # B/CMakeLists.txt > add_library(B OBJECT ${B_srcs}) > > # CMakeLists.txt > add_subdirectory(A) > add_subdirectory(B) > add_library(big ${other_srcs} $ $) > > > and I know that whenever I link the files listed in ${A_srcs}, i.e. > whenever I likd the OBJECT library A, I also need to link > libsomeotherlibrary.a . Then in the main CMakeLists.txt I add > > TARGET_LINK_LIBRARIES( big someotherlibrary ) > > right? > > > Moreover, there is no way to specify someotherlibrary in > A/CMakeLists.txt, it has to be done where I define the target big, > namely in the main CMakeLists.txt. Is this correct? > > > Thanks, > Marco > -- > > 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 FMiller at sjm.com Thu Aug 14 17:48:25 2014 From: FMiller at sjm.com (Miller, Frank) Date: Thu, 14 Aug 2014 21:48:25 +0000 Subject: [CMake] Windows RC files with Ninja In-Reply-To: References: Message-ID: I found a workaround. Turns out that the issue is caused when not enabling C language support in the project() command. i.e I was doing cmake_minimum_required( VERSION 3.0.0 ) project( proj CXX) Changing this to cmake_minimum_required( VERSION 3.0.0 ) project( proj CXX) fixes the issue. http://public.kitware.com/Bug/view.php?id=15088 Frank > -----Original Message----- > From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Miller, > Frank > Sent: Tuesday, August 12, 2014 11:44 AM > To: CMake MailingList > Subject: [CMake] Windows RC files with Ninja > > Greetings, > > I tried to move from 2.8 to 3.0.1 today and I'm experiencing an issue with RC > files. Looks like a simple problem but I would be baffled if I'm the first to > experience this so I expect I have some kind of configuration issue. Here is > the offending snippet in the rules.ninja file: > > rule RC_COMPILER > depfile = $DEP_FILE > deps = gcc > command = "" RC $in "$DEP_FILE" $out "" "c:/Program Files (x86)/Microsoft > Visual Studio 12.0/VC/bin/cl.exe" > c:\PROGRA~2\WI3CF2~1\8.1\bin\x86\rc.exe $FLAGS $DEFINES /fo$out $in > description = Building RC object $out > > If I put the path to "cmcldeps.exe" in the empty quotes on the command > line, it works as expected. > > Does anyone else have this problem? > > Frank > > 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 co > mmunication with the company, you consent to such lawful monitoring, to > the extent such consent is required and valid in your local area. > -- > > 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 Matt.Bolger at csiro.au Thu Aug 14 19:59:26 2014 From: Matt.Bolger at csiro.au (Matt.Bolger at csiro.au) Date: Thu, 14 Aug 2014 23:59:26 +0000 Subject: [CMake] Viewing the full build log from the CDash Dashboard Message-ID: Apologies if this is a stupid question with an obvious answer staring me in the face but... How does one view the full build log from the dashboard? This relates to our own dashboard but looking at a build of CMake as an example (http://open.cdash.org/buildSummary.php?buildid=3450103) The full output of the configure step seems to be displayed on the buildSummary page but there's nothing for the actual build (gmake in this case) step. CDash will show a cut-down summary of where it thinks the errors or warnings are but sometimes (especially with parallel builds) these are wrong (or false positives) or alternatively everything succeeded but you still want to browse through the build output. Our current build system captures the output of the ctest process and emails it separately but surely this must be available through CDash? Thanks Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: From pa at letnes.com Fri Aug 15 01:47:32 2014 From: pa at letnes.com (Paul Anton Letnes) Date: Fri, 15 Aug 2014 07:47:32 +0200 Subject: [CMake] Using a custom preprocessor Message-ID: <20CE9B56-FA82-46C0-B5B5-72EAED4AD91D@letnes.com> Hi! I am currently working on a project which uses plain old make as a build system. Needless to say, adding new compilers etc. is a lot of work, so I would like to start using CMake, which I have had excellent experience with in the past. There is one peculiarity that I do not know how to handle. Some of our code (C and Fortran) is contained in files that end with .cs or .fs, which are run through an in-house preprocessor. A Makefile target is then something along the lines of (but not exactly) foo.o: foo.f $(FC) -c $(FFLAGS) foo.f foo.f: foo.fs custom_preproc foo.fs -o foo.f Is it possible to, somehow, add this pre-compilation step for such files, and then add_executable(myexe foo.fs bar.cs main.f90) ? Cheers, Paul From tim at klingt.org Fri Aug 15 03:57:01 2014 From: tim at klingt.org (Tim Blechmann) Date: Fri, 15 Aug 2014 09:57:01 +0200 Subject: [CMake] generating info.plist files in POST_BUILD step unreliable Message-ID: hi all, a combination of question and feature request: i'm using a highly customized shell script to generate Info.plists on osx. this build script has to make use of the usage requirements of the corresponding target and it is called via a POST_BUILD custom command. however this conflicts with cmake's info.plist generation (cmLocalGenerator::GenerateAppleInfoPList()): the post-build step will only be called after a build, but cmake's info.plist generation will overwrite this file at configure-time. 1. run cmake: generate info.plist from MacOSXBundleInfo.plist.in 2. build: overwrite generated info.plist from post-build step 3. re-run cmake: overwrite correctly generated info.plist file from MacOSXBundleInfo.plist.in 4. build: since the target's sources did not change, the target is not rebuilt and the post-build step is not executed. the info.plist file is therefore incorrect. the 'cmake way' of generating info.plist files (setting MACOSX_BUNDLE_INFO_PLIST) will not work for me, as the shell script requires the usage requirements of the target. -- so i think that my issue could be solved in two ways: * if there would be a way to suppress the automatic generation of info.plist files in cmLocalGenerator::GenerateAppleInfoPList(), e.g. via a new property (MACOSX_BUNDLE_PREVENT_INFO_PLIST_GENERATION) * if there would be a way to force the evaluation of post-build steps after re-running cmake. any advice how to proceed from here? or maybe there is a workaround that i am missing? thanks a lot, tim From dlrdave at aol.com Fri Aug 15 07:13:49 2014 From: dlrdave at aol.com (David Cole) Date: Fri, 15 Aug 2014 07:13:49 -0400 (EDT) Subject: [CMake] Viewing the full build log from the CDash Dashboard Message-ID: <8D186911FA6F0E5-824-10D2A@webmail-vm033.sysops.aol.com> > Apologies if this is a stupid question with an obvious answer staring > me in the face but... Nope, it's not. The dashboard does not have the "full build log" because ctest does not send the full output from the build step. Only the contents of "Build.xml" are sent when a build is submitted to CDash. The reason is simply volume and scale. The configure output is typically fairly small (so we send all of it), but build output can be megabytes and megabytes (so we only send what we think is important...). So CDash shows its "cut-down summary" because that's all it has. To get the full build output, you need access to the machine that submitted the dashboard. The full build log is found in the build tree in a file named "Testing/Temporary/LastBuild_20140806-1658.log" (but adjust the timestamp part of the name to when the build actually occurred.....) > Our current build system captures the output of the ctest process and > emails it separately but surely this must be available through CDash? Nope. If you need it, keep your current system for now. HTH, David C. From nilsgladitz at gmail.com Fri Aug 15 07:36:10 2014 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Fri, 15 Aug 2014 13:36:10 +0200 Subject: [CMake] Viewing the full build log from the CDash Dashboard In-Reply-To: References: Message-ID: <53EDF0AA.3010909@gmail.com> On 15.08.2014 01:59, Matt.Bolger at csiro.au wrote: > CDash will show a cut-down summary of where it thinks the errors or > warnings are but sometimes (especially with parallel builds) these are > wrong (or false positives) or alternatively everything succeeded but > you still want to browse through the build output. In case you are using one of the makefile or ninja generators CTest launchers might help a bit[1]. Every compile, link and custom command will be wrapped by a command that captures the output and command line of its child process. You still don't get the output of successful commands on your Dashboard but full output (not sure if there is a limit) of failed commands. A random CMake dashboard submission with launchers looks e.g. like this: http://open.cdash.org/viewBuildError.php?type=1&buildid=3450912 Nils [1] http://www.cmake.org/cmake/help/v3.0/module/CTest.html?highlight=ctest_use_launchers -------------- next part -------------- An HTML attachment was scrubbed... URL: From cvolpe at ara.com Fri Aug 15 11:14:06 2014 From: cvolpe at ara.com (Chris Volpe ARA/SED) Date: Fri, 15 Aug 2014 15:14:06 +0000 Subject: [CMake] Possible bug in environment variable expansion? In-Reply-To: References: Message-ID: <7B8A49496E564B4781559C6C1AEB79338E3B6718@colo-mail-2.exchange2.ara.wan> Andrew- You are correct that it was a Windows issue, not a CMake issue. See the post I made about two hours before yours. The problem isn?t the alphabetic ordering, though. Is the ?type? of environment variable. There are two types, ?expandable string? and ?string?. (There are other types for other general registry values, but env vars can only be of these two types.) It seems that if you create an env var in the normal Windows GUI, the first value you give it determines which type it is. If it contains a reference to another env var, it?s created as ?expandable string?, otherwise it?s ?string?. The type of the variable isn?t updated if you update the value, so the first value you gave to BOOST_LIBRARYDIR in your test below made it type ?string?, even though you modified it to reference %BOOST_ROOT% later. You need to use RapidEE (http://www.rapidee.com/en/about ) to change the type of an env var, since the Windows GUI doesn?t even indicate that there are two types. -Chris From: Andrew Maclean [mailto:andrew.amaclean at gmail.com] Sent: Tuesday, August 12, 2014 6:57 PM To: cmake at cmake.org; Chris Volpe ARA/SED; Lucas.Pettey at engilitycorp.com Subject: Re: [CMake] Possible bug in environment variable expansion? I only define: BOOST_ROOT=C:\local\boost_1_56_0 BOOST_LIBRARYDIR=C:\local\boost_1_56_0\lib64-msvc-12.0 and this works Ok. This will not work: BOOST_LIBRARYDIR=%BOOST_ROOT%\lib64-msvc-12.0 If you go to a command prompt and type "set" you will see that %BOOST_ROOT% is not expanded. So this is a Windows issue, not a CMake issue. The only clue I have is that Microsoft expands these variables in order and since BOOST_ROOT is ordered after BOOST_LIBRARYDIR the expansion does not happen. Regards Andrew On Wed, Aug 13, 2014 at 5:37 AM, > wrote: Send CMake mailing list submissions to cmake at cmake.org To subscribe or unsubscribe via the World Wide Web, visit http://public.kitware.com/mailman/listinfo/cmake or, via email, send a message with subject or body 'help' to cmake-request at cmake.org You can reach the person managing the list at cmake-owner at cmake.org When replying, please edit your Subject line so it is more specific than "Re: Contents of CMake digest..." Today's Topics: 1. Windows RC files with Ninja (Miller, Frank) 2. Re: Possible bug in environment variable expansion? (Chris Volpe ARA/SED) ---------- Forwarded message ---------- From: "Miller, Frank" > To: CMake MailingList > Cc: Date: Tue, 12 Aug 2014 16:44:03 +0000 Subject: [CMake] Windows RC files with Ninja Greetings, I tried to move from 2.8 to 3.0.1 today and I'm experiencing an issue with RC files. Looks like a simple problem but I would be baffled if I'm the first to experience this so I expect I have some kind of configuration issue. Here is the offending snippet in the rules.ninja file: rule RC_COMPILER depfile = $DEP_FILE deps = gcc command = "" RC $in "$DEP_FILE" $out "" "c:/Program Files (x86)/Microsoft Visual Studio 12.0/VC/bin/cl.exe" c:\PROGRA~2\WI3CF2~1\8.1\bin\x86\rc.exe $FLAGS $DEFINES /fo$out $in description = Building RC object $out If I put the path to "cmcldeps.exe" in the empty quotes on the command line, it works as expected. Does anyone else have this problem? Frank 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. ---------- Forwarded message ---------- From: Chris Volpe ARA/SED > To: Chris Volpe ARA/SED >, "Lucas.Pettey at engilitycorp.com" >, "cmake at cmake.org" > Cc: Date: Tue, 12 Aug 2014 19:37:47 +0000 Subject: Re: [CMake] Possible bug in environment variable expansion? As it turns out, something weirder is going on, and it?s not cmake?s fault, so I won?t look for a solution here, but I?ll describe the problem in case anyone?s interested. *Windows* is not expanding those environment variables. First, I hacked up the installed version of FindBoost.cmake to spit out some debugging information, with the following, circa line 860: message(DEBUG "_ENV_BOOST_LIBRARYDIR has value <${_ENV_BOOST_LIBRARYDIR}>") and then I ran configure in debug mode, which gave me the following from my extra hacked debugging output: DEBUG_ENV_BOOST_LIBRARYDIR has value <%BOOST_ROOT%/lib64-msvc-12.0> So, when cmake asked the OS for the BOOST_LIBRARYDIR environment variable, the OS gave it the string without expanding BOOST_ROOT. I have verified this OS behavior by opening up a command window and using the set command: It?s not getting expanded. I?ve verified (with RapidEE) that the environment variables in question are of type ?expandable string?, not ?string?. While playing with the variables in RapidEE (a wonderful tool, BTW), I noticed two other strange things. First, I do have a couple of env vars that do have other env var references in them, and they *do* get expanded in cmd.exe. Second, my PATH env var used to have embedded env vars for various things, but somewhere along the way they all got replaced in the PATH *definition* with their expanded versions, so now everything in my path is now ?hard coded?, so to speak. Ugh. So, basically, something is messed up in my system. From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Chris Volpe ARA/SED Sent: Tuesday, August 12, 2014 12:44 PM To: Lucas.Pettey at engilitycorp.com; cmake at cmake.org Subject: Re: [CMake] Possible bug in environment variable expansion? That?s a good thought, but unfortunately it didn?t pan out. I tried both styles, and I even tried explicitly mixing styles like this: BOOST_LIBRARYDIR=C:/local/boost_1_55_0\lib64-msvc-12.0 Or this: BOOST_LIBRARYDIR=C:\local\boost_1_55_0/lib64-msvc-12.0 And those worked fine. From: Lucas.Pettey at engilitycorp.com [mailto:Lucas.Pettey at engilitycorp.com] Sent: Monday, August 11, 2014 11:03 PM To: Chris Volpe ARA/SED; cmake at cmake.org Subject: RE: Possible bug in environment variable expansion? Could it be something as simple as UNIX (slash /) vs Windows (backslash \) in the directory expression? When this environment variable is expanded BOOST_LIBRARYDIR=%BOOST_ROOT%\lib64-msvc-12.0, it looks like it is converting the %BOOST_ROOT% in UNIX style and then the "\lib-msvc-12.0" is Windows. This mixture of styles may be causing a "no such directory" system error. I know on Windows systems I need to be consistent with directory styles or it fails. Lucas Pettey, PhD HPCMP PETTT EQM CTA Lead ERDC-DSRC OnSite Vicksburg, MS 512-297-9833 Mobile (preferred) 601-634-2980 Office lucas.pettey at engilitycorp.com ________________________________ From: CMake [cmake-bounces at cmake.org] on behalf of Chris Volpe ARA/SED [cvolpe at ara.com] Sent: Monday, August 11, 2014 6:25 PM To: cmake at cmake.org Subject: [CMake] Possible bug in environment variable expansion? I am trying to build an Open Source project called PCL which uses Boost, and CMake?s ability to find the Boost libraries seems dependent on whether the BOOST_LIBRARYDIR contains a literal path string, or whether it contains a string that incorporates the expansion of BOOST_ROOT. Here are the details: Boost is installed from a pre-built installer in the folder C:\local\boost_1_55_0. This folder contains, among other things, a subfolder called ?boost?, which contains the headers, and a subfolder called ?lib64-msvc-12.0?, which contains 64-bit libraries built with MS Visual Studio 2013. Ordinarily, CMake would like that folder to be called simply ?lib?, but that?s not what the installer created, so I?m trying to override the default with environment variables. I have the following three environment variables defined, all of which are of type ?Expandable string?: BOOST_ROOT=C:\local\boost_1_55_0 BOOST_INCLUDEDIR=%BOOST_ROOT% BOOST_LIBRARYDIR=%BOOST_ROOT%\lib64-msvc-12.0 With these settings, CMake reports an error during the configuration process, as follows: CMake Error at C:/Program Files (x86)/CMake/share/cmake-3.0/Modules/FindBoost.cmake:1179 (message): Unable to find the requested Boost libraries. Boost version: 1.55.0 Boost include path: C:/local/boost_1_55_0 Could not find the following Boost libraries: boost_system boost_filesystem boost_thread boost_date_time boost_iostreams boost_chrono No Boost libraries were found. You may need to set BOOST_LIBRARYDIR to the directory containing Boost libraries or BOOST_ROOT to the location of Boost. Call Stack (most recent call first): cmake/pcl_find_boost.cmake:38 (find_package) CMakeLists.txt:230 (include) But if change the definition of BOOST_LIBRARYDIR by replacing ?%BOOST_ROOT%? with the value assigned to BOOST_ROOT, resulting in this: BOOST_LIBRARYDIR=C:\local\boost_1_55_0\lib64-msvc-12.0 the configuration succeeds. The only difference seems to be whether the ?C:\local\boost_1_55_0? part of the path is specified explicitly, or obtained implicitly with %BOOST_ROOT%. It would surprise me if this behavior were by design. Does anyone have an explanation for this? Thanks, Chris Christopher R. Volpe, Ph.D. Senior Scientist, Remote Sensing & Decision Analytics [Description: Description: Description: cid:image003.png at 01CE888B.0167BAD0] NATIONAL SECURITY | INFRASTRUCTURE | ENERGY & ENVIRONMENT | HEALTH SOLUTIONS Applied Research Associates, Inc. 8537 Six Forks Road, Suite 600, Raleigh, NC 27615 | T 919.582.3380 | F 919.582.3301 Find Us Online www.ara.com Facebook: Applied Research Associates LinkedIn: Company Page LinkedIn Group Twitter: ARA News YouTube: Applied Research Associates -- 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 -- ___________________________________________ Andrew J. P. Maclean ___________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 9687 bytes Desc: image001.png URL: From dlrdave at aol.com Fri Aug 15 11:57:12 2014 From: dlrdave at aol.com (David Cole) Date: Fri, 15 Aug 2014 11:57:12 -0400 (EDT) Subject: [CMake] Possible bug in environment variable expansion? In-Reply-To: <7B8A49496E564B4781559C6C1AEB79338E3B6718@colo-mail-2.exchange2.ara.wan> References: <7B8A49496E564B4781559C6C1AEB79338E3B6718@colo-mail-2.exchange2.ara.wan> Message-ID: <8D186B8B6588E20-1DDC-1361F@webmail-d173.sysops.aol.com> There are no "types" for environment variables. There are types for values stored in the registry. See this article: http://support.microsoft.com/kb/256986 and note the descriptions of REG_SZ and REG_EXPAND_SZ. The fact that you can do it in RapidEE does not mean it's a built-in feature of Windows environment variables. It means they have a nice feature built on top of Windows environment variables, ... but you can't count on that feature for use from *any* program that deals with environment variables. You can only count on it when you are setting an environment variable via RapidEE's user interface. David C. From cvolpe at ara.com Fri Aug 15 12:29:45 2014 From: cvolpe at ara.com (Chris Volpe ARA/SED) Date: Fri, 15 Aug 2014 16:29:45 +0000 Subject: [CMake] "Hidden" cache values in Registry? Message-ID: <7B8A49496E564B4781559C6C1AEB79338E3B67FE@colo-mail-2.exchange2.ara.wan> I have been using CMake to build a few open-source projects recently, and I've been experimenting and moving around build directories and such. In a small test application, CMake tries to find a library that I built and installed in one place, and then I rebuilt and installed somewhere else. Meanwhile, I changed the "_ROOT" environment variable to point to the new location, restarted CMake to pick up the new environment variable, and deleted the cache. There should be no record left of the old location of the library (which wasn't in a "standard" location such as "C:\Program Files"), but still, CMake is finding the old location. There should be nothing pointing CMake to this location anymore, but it's still doing so. On a hunch, I searched through the Windows Registry and found several keys of the form H_C_R\Software\Kitware\CMakeSetup\Settings\StartPath\WhereBuild where is an integer. One of these contains the offending path. Is there a way to tell CMake to ignore this and start fresh? Obviously, "delete cache" doesn't do the trick. Is my only option to go into regedit.exe and delete these things from time to time? Thanks, Chris Christopher R. Volpe, Ph.D. Senior Scientist, Remote Sensing & Decision Analytics [Description: Description: cid:image003.png at 01CE888B.0167BAD0] NATIONAL SECURITY | INFRASTRUCTURE | ENERGY & ENVIRONMENT | HEALTH SOLUTIONS Applied Research Associates, Inc. 8537 Six Forks Road, Suite 600, Raleigh, NC 27615 | T 919.582.3380 | F 919.582.3301 Find Us Online www.ara.com Facebook: Applied Research Associates LinkedIn: Company Page LinkedIn Group Twitter: ARA News YouTube: Applied Research Associates -------------- next part -------------- A non-text attachment was scrubbed... Name: winmail.dat Type: application/ms-tnef Size: 20071 bytes Desc: not available URL: From cvolpe at ara.com Fri Aug 15 13:14:04 2014 From: cvolpe at ara.com (Chris Volpe ARA/SED) Date: Fri, 15 Aug 2014 17:14:04 +0000 Subject: [CMake] Possible bug in environment variable expansion? In-Reply-To: <8D186B8B6588E20-1DDC-1361F@webmail-d173.sysops.aol.com> References: <7B8A49496E564B4781559C6C1AEB79338E3B6718@colo-mail-2.exchange2.ara.wan> <8D186B8B6588E20-1DDC-1361F@webmail-d173.sysops.aol.com> Message-ID: <7B8A49496E564B4781559C6C1AEB79338E3B6886@colo-mail-2.exchange2.ara.wan> David- > There are no "types" for environment variables. Not in other operating systems, perhaps, but I think it's perfectly reasonable to adopt the colloquial operating definition that, in Windows, the "type of an environment variable" is the type of the Registry value used to hold that environment variable. > See this article: http://support.microsoft.com/kb/256986 and note the descriptions of REG_SZ and REG_EXPAND_SZ. I don't think I've said anything that indicates that I don't already understand what's contained there. > The fact that you can do it in RapidEE does not mean it's a built-in feature of Windows environment variables. Given that the environment variables are stored in the registry, I'd say that *does* mean it's a built-in feature of Windows environment variables, insofar as it's a built-in feature of the implementation of environment variables on Windows. > but you can't count on that feature for use from *any* program that deals with environment variables. You can only count on it when you are setting an environment variable via RapidEE's user interface. Apparently, I can count on the setting of that type in RapidEE as having a profound impact on what value is reported by the "set" command in cmd.exe. I'm having a hard time figuring out what your point is. I'm merely trying to point out Windows behavior which, to my knowledge, is not widely known, and may give some people trouble when dealing with applications (like CMake) that make use of environment variables that contain references to other environment variables. Are we arguing over semantics here? -Chris -----Original Message----- From: David Cole [mailto:dlrdave at aol.com] Sent: Friday, August 15, 2014 11:57 AM To: Chris Volpe ARA/SED; andrew.amaclean at gmail.com; cmake at cmake.org; Lucas.Pettey at engilitycorp.com Subject: Re: [CMake] Possible bug in environment variable expansion? There are no "types" for environment variables. There are types for values stored in the registry. See this article: http://support.microsoft.com/kb/256986 and note the descriptions of REG_SZ and REG_EXPAND_SZ. The fact that you can do it in RapidEE does not mean it's a built-in feature of Windows environment variables. It means they have a nice feature built on top of Windows environment variables, ... but you can't count on that feature for use from *any* program that deals with environment variables. You can only count on it when you are setting an environment variable via RapidEE's user interface. David C. From dlrdave at aol.com Fri Aug 15 13:58:46 2014 From: dlrdave at aol.com (David Cole) Date: Fri, 15 Aug 2014 13:58:46 -0400 (EDT) Subject: [CMake] Possible bug in environment variable expansion? Message-ID: <8D186C9B189DDEE-1DDC-14580@webmail-d173.sysops.aol.com> OK, I partially take it back, you can set an environment variable that references other environment variables even through the Windows UI... But it's a little hard to grasp, because you see it when you're editing the value, but then when you click OK, the view shows the resolved value in the result. Combine that with the fact that I nearly always avoid setting machine-wide env vars, and you can see why I might assert the type-less-ness of env vars. But even then, when you inspect the values with "set" or "echo" in a cmd prompt, there's no evidence of the nested variable, because the value you get back resolves the contained/nested reference. The same is true of any other program that calls "getenv" and inspects values in the environment. Windows resolves the references before it gets to the program consuming it. To set a "nested" value via CMake you should use CMake ENV syntax all the way through, but it will be stored only as a plain old string type when set via CMake. Plus... any value you set via CMake only takes effect for the duration of that CMake run. In other words, your initial attempt to do something like: set(ENV{VAR} "%NESTED_VAR%") should be written as: set(ENV{VAR} "$ENV{NESTED_VAR}") Although, the limited duration of the scope of such a construct makes it useful only for the duration of running a CMake script, or of the configure/generate process. Sorry for the confusion. I could have been more clear in my email this morning by saying "cross platform programs using environment variables in a portable way will likely not have an implementation for dealing with Windows nested environment variables properly..." -- which is definitely the case for CMake and friends. HTH, David C. From robert.maynard at kitware.com Fri Aug 15 16:20:46 2014 From: robert.maynard at kitware.com (Robert Maynard) Date: Fri, 15 Aug 2014 16:20:46 -0400 Subject: [CMake] "Hidden" cache values in Registry? In-Reply-To: <7B8A49496E564B4781559C6C1AEB79338E3B67FE@colo-mail-2.exchange2.ara.wan> References: <7B8A49496E564B4781559C6C1AEB79338E3B67FE@colo-mail-2.exchange2.ara.wan> Message-ID: Hi these registry entries are added by cmake-gui and I don't see any way for them to be cleared. Can you please create a new bug on http://public.kitware.com/Bug/view_all_bug_page.php with this issue and I will look into adding a feature to cmake-gui to clear dead paths. On Fri, Aug 15, 2014 at 12:29 PM, Chris Volpe ARA/SED wrote: > I have been using CMake to build a few open-source projects recently, and I've been experimenting and moving around build directories and such. In a small test application, CMake tries to find a library that I built and installed in one place, and then I rebuilt and installed somewhere else. Meanwhile, I changed the "_ROOT" environment variable to point to the new location, restarted CMake to pick up the new environment variable, and deleted the cache. There should be no record left of the old location of the library (which wasn't in a "standard" location such as "C:\Program Files"), but still, CMake is finding the old location. There should be nothing pointing CMake to this location anymore, but it's still doing so. On a hunch, I searched through the Windows Registry and found several keys of the form H_C_R\Software\Kitware\CMakeSetup\Settings\StartPath\WhereBuild where is an integer. One of these contains the offending path. Is there a way to tell CMake to ignore this and start fresh? Obviously, "delete cache" doesn't do the trick. Is my only option to go into regedit.exe and delete these things from time to time? > > Thanks, > Chris > > Christopher R. Volpe, Ph.D. > Senior Scientist, Remote Sensing & Decision Analytics > > [Description: Description: cid:image003.png at 01CE888B.0167BAD0] > NATIONAL SECURITY | INFRASTRUCTURE | ENERGY & ENVIRONMENT | HEALTH SOLUTIONS > Applied Research Associates, Inc. > 8537 Six Forks Road, Suite 600, Raleigh, NC 27615 | T 919.582.3380 | F 919.582.3301 > > Find Us Online > www.ara.com > Facebook: Applied Research Associates > LinkedIn: Company Page > LinkedIn Group > Twitter: ARA News > YouTube: Applied Research Associates > > > > > -- > > 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 marcel.loose at zonnet.nl Sat Aug 16 11:03:23 2014 From: marcel.loose at zonnet.nl (Marcel Loose) Date: Sat, 16 Aug 2014 17:03:23 +0200 Subject: [CMake] How to deal with incompatible changes in interface of target_link_libraries()? In-Reply-To: <53EA1148.9010900@kitware.com> References: <53E62631.9060500@zonnet.nl> <53E8F3AA.40002@kitware.com> <53E9C6C1.9080204@astron.nl> <53EA1148.9010900@kitware.com> Message-ID: <53EF72BB.8080309@zonnet.nl> Op 12-08-14 om 15:06 schreef Brad King: > On 08/12/2014 03:48 AM, Marcel Loose wrote: >> On a side note. Even using the new PRIVATE and PUBLIC keywords I am >> unable to exactly specify which libraries are needed for linking. > > Can you provide a concrete example of this trouble? I've further analyzed the problem, and figured out that the troubles I'm facing are caused by the way I add libraries and executables to the build. It's no big deal. Like I said, modern versions of ld will get rid of unused libraries anyway, so the only remaining problem would be some increased link time. I can live with that. > > -Brad > Cheers, Marcel. From a.neundorf-work at gmx.net Sat Aug 16 11:52:46 2014 From: a.neundorf-work at gmx.net (Alexander Neundorf) Date: Sat, 16 Aug 2014 17:52:46 +0200 Subject: [CMake] How to get rid of AUTOMOC: Checking ... messages In-Reply-To: <58AC22C72FD8E842B3DA5842573BB5C839494A6F@excorpuk2.paradigmgeo.net> References: <58AC22C72FD8E842B3DA5842573BB5C839494A6F@excorpuk2.paradigmgeo.net> Message-ID: <3977492.OsHDaKdIZA@tuxedo.neundorf.net> On Thursday, July 24, 2014 08:38:08 Dominique Ledit wrote: > Hi > > I currently use 2.8.12.2 CMake version and Qt 4.7.3 and set in my top-level > CMakeLists.txt the CMAKE_AUTOMOC to true Set (CMAKE_AUTOMOC on) > As a result, in the build log there are a lot of messages like: > > AUTOMOC: Checking > AUTOMOC: Checking > > Is there a way to get rid of them? Do you have VERBOSE enabled ? It should only be visible in this case. Alex From david at zemon.name Sat Aug 16 16:02:33 2014 From: david at zemon.name (David Zemon) Date: Sat, 16 Aug 2014 15:02:33 -0500 Subject: [CMake] No Such File or Directory Message-ID: <53EFB8D9.40505@zemon.name> Hello, After downloading the 3.0.1 binary Linux distribution of CMake, I am running into the following bash error: *david at fresh-ubuntu:~/**PropWare/util$* cmake bash: /home/david/cmake-3.0.1-Linux-i386/bin/cmake: No such file or directory *david at fresh-ubuntu:~/**PropWare/util$* which cmake /home/david/cmake-3.0.1-Linux-i386/bin/cmake *david at fresh-ubuntu:~/**PropWare/util$* /home/david/cmake-3.0.1-Linux-i386/bin/cmake bash: /home/david/cmake-3.0.1-Linux-i386/bin/cmake: No such file or directory *david at fresh-ubuntu:~/PropWare/util$* Does anyone have any idea why? This problem seems to have existed for quite a long time as I am seeing evidence of it as far back as 2009. The system in question is a fresh installation of Ubuntu 14.04 64-bit running in VirtualBox. CMake has never been installed on the machine before. The only non-default packages installed are git, vim, make and VirtualBox Guest Additions. Thanks, David -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcel.loose at zonnet.nl Sat Aug 16 19:11:39 2014 From: marcel.loose at zonnet.nl (Marcel Loose) Date: Sun, 17 Aug 2014 01:11:39 +0200 Subject: [CMake] No Such File or Directory In-Reply-To: <53EFB8D9.40505@zemon.name> References: <53EFB8D9.40505@zemon.name> Message-ID: <53EFE52B.6010707@zonnet.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Op 16-08-14 om 22:02 schreef David Zemon: > Hello, > > After downloading the 3.0.1 binary Linux distribution of CMake, I > am running into the following bash error: > > *david at fresh-ubuntu:~/**PropWare/util$* cmake bash: > /home/david/cmake-3.0.1-Linux-i386/bin/cmake: No such file or > directory *david at fresh-ubuntu:~/**PropWare/util$* which cmake > /home/david/cmake-3.0.1-Linux-i386/bin/cmake > *david at fresh-ubuntu:~/**PropWare/util$* > /home/david/cmake-3.0.1-Linux-i386/bin/cmake bash: > /home/david/cmake-3.0.1-Linux-i386/bin/cmake: No such file or > directory *david at fresh-ubuntu:~/PropWare/util$* > > Does anyone have any idea why? This problem seems to have existed > for quite a long time as I am seeing evidence of it > > > as far back as 2009. > > The system in question is a fresh installation of Ubuntu 14.04 > 64-bit running in VirtualBox. CMake has never been installed on the > machine before. The only non-default packages installed are git, > vim, make and VirtualBox Guest Additions. > > Thanks, David > > Hi David, - From the directory name where your cmake resides, I gather this is a 32-bit version. If you have a 64-bit Ubuntu, then you must install the 32-bit libraries. Unfortunately, bash its error message is far from clear in that respect :( Usually, it boils down to installing the package ia32-libs, but I heard some rumors that more recent Ubuntu's no longer support multi-arch by default. In that case you might need to run the following command: sudo dpkg --add-architecture i386 After that you will be able to install all 32-bit libraries at once (package ia32-libs), or one at a time, by just specifying the architecture of the package, e.g. libc6:i386. Hope this helps, Marcel Loose. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJT7+UrAAoJEEpMyb1AIWdYH8EH/2xcKu1vtXuoGvMDEzFZwkos DRsR3BPjiU5MYyoGIaatIH7N4ioR6r0vniS4r+BP4qDqbt33Wuv/UHTMbGTN3iyf 4HCJI3xCEO6MCDpkhl59EciRyQb4GmFM9pi/NYDzTUaPvfQoLQ/ZldHaP0jkm72q AEt51Y1bsc3p822Hv68AD2BFDwkf2VUsg+ooB1vhlo1qn0nlbyAqkmk0nSKs2thh Zsi0gbfxuRNFILUBC8pvMw62QSmcqYZD6SaYViFGvCUMSn7If8nJvEwiVWKpcOr3 +agyi8a6adAiHGI/AMtzB0DJYB82olMwjhR19H9rIaaAcxdxefNRs6951b4J31k= =No1X -----END PGP SIGNATURE----- From irwin at beluga.phys.uvic.ca Sat Aug 16 19:51:18 2014 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Sat, 16 Aug 2014 16:51:18 -0700 (PDT) Subject: [CMake] No Such File or Directory In-Reply-To: <53EFB8D9.40505@zemon.name> References: <53EFB8D9.40505@zemon.name> Message-ID: On 2014-08-16 15:02-0500 David Zemon wrote: > Hello, > > After downloading the 3.0.1 binary Linux distribution of CMake, I am running > into the following bash error: > > *david at fresh-ubuntu:~/**PropWare/util$* cmake ^ ==> that is a prompt followed by a blank so it looks like there is no actual path in front of your cmake invocation. > bash: /home/david/cmake-3.0.1-Linux-i386/bin/cmake: No such file or > directory I am pretty sure this issue is due to a very long-standing Linux security feature where you have to specify executables using a path in front of the name, i.e., from that directory invoke cmake with ./cmake or from anywhere invoke it with the full pathname, e.g., /home/david/cmake-3.0.1-Linux-i386/bin/cmake Hope this guess is right. 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 petasisg at yahoo.gr Sun Aug 17 08:30:51 2014 From: petasisg at yahoo.gr (Georgios Petasis) Date: Sun, 17 Aug 2014 15:30:51 +0300 Subject: [CMake] CMake 3.0.1 - avast Win32;Dropper-gen Message-ID: <53F0A07B.8050508@yahoo.gr> Hi all, I installed the latest cmake under windows, and avast keeps telling me cmake.exe has a virus. The detected virus is Win32:Dropper-gen. Avast finds it in cmake.exe, inside both the windows zip file, and the setup file. Is it really a virus, or a false alarm? George From marco.atzeri at gmail.com Sun Aug 17 09:40:39 2014 From: marco.atzeri at gmail.com (Marco Atzeri) Date: Sun, 17 Aug 2014 15:40:39 +0200 Subject: [CMake] CMake 3.0.1 - avast Win32;Dropper-gen In-Reply-To: <53F0A07B.8050508@yahoo.gr> References: <53F0A07B.8050508@yahoo.gr> Message-ID: <53F0B0D7.50103@gmail.com> On 17/08/2014 14:30, Georgios Petasis wrote: > Hi all, > > I installed the latest cmake under windows, and avast keeps telling me > cmake.exe has a virus. > The detected virus is Win32:Dropper-gen. > > Avast finds it in cmake.exe, inside both the windows zip file, and the > setup file. > > Is it really a virus, or a false alarm? > > George I will bet on the second Marco From golubdr at gmail.com Sun Aug 17 21:04:36 2014 From: golubdr at gmail.com (David Golub) Date: Sun, 17 Aug 2014 21:04:36 -0400 Subject: [CMake] CMake Tools for Visual Studio 1.2 Released! Message-ID: <016501cfba80$6154c780$23fe5680$@gmail.com> I've just released version 1.2 of CMake Tools for Visual Studio. This version adds support for CMake 3.0 and also incorporates a few small enhancements and bug fixes. As usual, it is available from the project web site at http://cmaketools.codeplex.com. Enjoy! David Golub -------------- next part -------------- An HTML attachment was scrubbed... URL: From yue.nicholas at gmail.com Sun Aug 17 23:25:28 2014 From: yue.nicholas at gmail.com (Nicholas Yue) Date: Sun, 17 Aug 2014 20:25:28 -0700 Subject: [CMake] CMake 3.0.1 : Visual Studio 2012 solution not useable Message-ID: Hi, Whilst upgrading compilers to 2012 (Visual Studio 2012 Express Desktop), I also upgraded CMake to 3.0.1 as I read there were updates to make it work with the Express version of Visual Studio. However, I found that the generated solutions and *.vcxproj files not working at all. Looking at the content in the *.vcxproj file, it looks like this and VS 2012 has a hard time finding even it's own header files let alone the additional ones. Note : The include directories is show how being specified as additional options . C:/PROGRA~1/SIDEEF~1/HOUDIN~1.507/toolkit/include C:/PROGRA~2/MICROS~3.0/VC/include "C:/Program Files (x86)/Windows Kits/8.0/Include/um" "C:/Program Files (x86)/Windows Kits/8.0/Include/shared" -w14996 -bigobj %(AdditionalOptions) C:\Program Files\Side Effects Software\Houdini 13.0.507\toolkit\include;%(AdditionalIncludeDirectories) ;;;;;%(AdditionalIncludeDirectories) Release/ CompileAsCpp 4355;4996 Cheers -- Nicholas Yue Graphics - Arnold, Alembic, RenderMan, OpenGL, HDF5 Custom Dev - C++ porting, OSX, Linux, Windows http://au.linkedin.com/in/nicholasyue https://vimeo.com/channels/naiadtools -------------- next part -------------- An HTML attachment was scrubbed... URL: From petr.kmoch at gmail.com Mon Aug 18 03:20:26 2014 From: petr.kmoch at gmail.com (Petr Kmoch) Date: Mon, 18 Aug 2014 09:20:26 +0200 Subject: [CMake] Using a custom preprocessor In-Reply-To: <20CE9B56-FA82-46C0-B5B5-72EAED4AD91D@letnes.com> References: <20CE9B56-FA82-46C0-B5B5-72EAED4AD91D@letnes.com> Message-ID: Hi Paul. The straightfroward way to do thisis with custom commands: add_custom_command( OUTPUT ${CMAKE_BINARY_DIR}/foo.f COMMAND custom_preproc foo.fs -o ${CMAKE_BINARY_DIR}/foo.f MAIN_DEPENDENCY foo.fs COMMENT "Custom-preprocessing foo.fs" VERBATIM ) add_executable(myexe ${CMAKE_BINARY_DIR}/foo.f main.f90 ) Analogously with cs, of course. See documentation of add_custom_command() for all options available. Petr On Fri, Aug 15, 2014 at 7:47 AM, Paul Anton Letnes wrote: > Hi! > > I am currently working on a project which uses plain old make as a build > system. Needless to say, adding new compilers etc. is a lot of work, so I > would like to start using CMake, which I have had excellent experience with > in the past. > > There is one peculiarity that I do not know how to handle. Some of our > code (C and Fortran) is contained in files that end with .cs or .fs, which > are run through an in-house preprocessor. A Makefile target is then > something along the lines of (but not exactly) > > foo.o: foo.f > $(FC) -c $(FFLAGS) foo.f > > foo.f: foo.fs > custom_preproc foo.fs -o foo.f > > Is it possible to, somehow, add this pre-compilation step for such files, > and then > add_executable(myexe > foo.fs > bar.cs > main.f90) > ? > > Cheers, > Paul > -- > > 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 jzakrzewski at e2e.ch Mon Aug 18 03:13:52 2014 From: jzakrzewski at e2e.ch (Jakub Zakrzewski) Date: Mon, 18 Aug 2014 07:13:52 +0000 Subject: [CMake] No Such File or Directory In-Reply-To: References: <53EFB8D9.40505@zemon.name> Message-ID: -----Original Message----- From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Alan W. Irwin Sent: Sonntag, 17. August 2014 01:51 To: David Zemon Cc: cmake at cmake.org Subject: Re: [CMake] No Such File or Directory On 2014-08-16 15:02-0500 David Zemon wrote: > Hello, > > After downloading the 3.0.1 binary Linux distribution of CMake, I am > running into the following bash error: > > *david at fresh-ubuntu:~/**PropWare/util$* cmake ^ ==> that is a prompt followed by a blank so it looks like there is no actual path in front of your cmake invocation. > bash: /home/david/cmake-3.0.1-Linux-i386/bin/cmake: No such file or > directory I am pretty sure this issue is due to a very long-standing Linux security feature where you have to specify executables using a path in front of the name, i.e., from that directory invoke cmake with ./cmake or from anywhere invoke it with the full pathname, e.g., /home/david/cmake-3.0.1-Linux-i386/bin/cmake Hope this guess is right. 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 __________________________ -- 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 Hi, I think you didn't read careful enough. David tries once withou and second time with full path. Furthermore, the `which` command can find cmake, what means it's somewhere in the PATH, so there's no need to specify full path by invokation (do you specify full path when invoking `grep` for example? - I don't think so.) So apparently system cannot find some file, but it's not the CMake executable itself. Marcel Loose's answer makes a lot of sense to me. -- Gruesse, Jakub From post at hendrik-sattler.de Mon Aug 18 04:08:51 2014 From: post at hendrik-sattler.de (Hendrik Sattler) Date: Mon, 18 Aug 2014 10:08:51 +0200 Subject: [CMake] Using a custom preprocessor In-Reply-To: References: <20CE9B56-FA82-46C0-B5B5-72EAED4AD91D@letnes.com> Message-ID: <4328e2f9-d5a5-4a3c-b97a-486003ac055d@email.android.com> On 18. August 2014 09:20:26 MESZ, Petr Kmoch wrote: >Hi Paul. > >The straightfroward way to do thisis with custom commands: > >add_custom_command( > OUTPUT ${CMAKE_BINARY_DIR}/foo.f > COMMAND custom_preproc foo.fs -o ${CMAKE_BINARY_DIR}/foo.f > MAIN_DEPENDENCY foo.fs > COMMENT "Custom-preprocessing foo.fs" > VERBATIM >) > >add_executable(myexe > ${CMAKE_BINARY_DIR}/foo.f > main.f90 >) The foo.fs should also appear here. It is a source file and listing it improves behavior for e.g. Visual Studio. >Analogously with cs, of course. See documentation of >add_custom_command() >for all options available. > >Petr > > > >On Fri, Aug 15, 2014 at 7:47 AM, Paul Anton Letnes >wrote: > >> Hi! >> >> I am currently working on a project which uses plain old make as a >build >> system. Needless to say, adding new compilers etc. is a lot of work, >so I >> would like to start using CMake, which I have had excellent >experience with >> in the past. >> >> There is one peculiarity that I do not know how to handle. Some of >our >> code (C and Fortran) is contained in files that end with .cs or .fs, >which >> are run through an in-house preprocessor. A Makefile target is then >> something along the lines of (but not exactly) >> >> foo.o: foo.f >> $(FC) -c $(FFLAGS) foo.f >> >> foo.f: foo.fs >> custom_preproc foo.fs -o foo.f >> >> Is it possible to, somehow, add this pre-compilation step for such >files, >> and then >> add_executable(myexe >> foo.fs >> bar.cs >> main.f90) >> ? >> >> Cheers, >> Paul >> -- >> >> 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 david at zemon.name Mon Aug 18 06:57:55 2014 From: david at zemon.name (David Zemon) Date: Mon, 18 Aug 2014 05:57:55 -0500 Subject: [CMake] No Such File or Directory Message-ID: The first reply was perfect. All I needed was libc6:i386. So bizarre, but I'm glad you guys could help. David On Aug 18, 2014 2:13 AM, Jakub Zakrzewski wrote: > > > -----Original Message----- > From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Alan W. Irwin > Sent: Sonntag, 17. August 2014 01:51 > To: David Zemon > Cc: cmake at cmake.org > Subject: Re: [CMake] No Such File or Directory > > On 2014-08-16 15:02-0500 David Zemon wrote: > > > Hello, > > > > After downloading the 3.0.1 binary Linux distribution of CMake, I am > > running into the following bash error: > > > >?? *david at fresh-ubuntu:~/**PropWare/util$* cmake > ??????????????????????????????????????????? ^ ==> that is a prompt followed by a blank so it looks like there is no actual path in front of your cmake invocation. > > >?? bash: /home/david/cmake-3.0.1-Linux-i386/bin/cmake: No such file or > >?? directory > > I am pretty sure this issue is due to a very long-standing Linux security feature where you have to specify executables using a path in front of the name, i.e., from that directory invoke cmake with > > ./cmake > > or from anywhere invoke it with the full pathname, e.g., > > /home/david/cmake-3.0.1-Linux-i386/bin/cmake > > Hope this guess is right. > > 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 > __________________________ > -- > > 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 > > > > Hi, > > I think you didn't read careful enough. David tries once withou and second time with full path. Furthermore, the `which` command can find cmake, what means it's somewhere in the PATH, so there's no need to specify full path by invokation (do you specify full path when invoking `grep` for example? - I don't think so.) > > So apparently system cannot find some file, but it's not the CMake executable itself. Marcel Loose's answer makes a lot of sense to me. > > -- > Gruesse, > Jakub > > > From me at eddy-ilg.net Tue Aug 19 03:00:57 2014 From: me at eddy-ilg.net (Eddy Ilg) Date: Tue, 19 Aug 2014 09:00:57 +0200 Subject: [CMake] Qt UI Filename Bug Message-ID: <53F2F629.6050407@eddy-ilg.net> Dear CMake Developers, I have the following problem in QtCreator with CMake, which seems like a bug: My project has several MainWindow classes and files (.h,.cpp,.ui). In each application I use qt5_wrap_ui( app_UI_SOURCES ${app_UI} ) add_executable( app ${app_SOURCES} ${app_UI_SOURCES} ) QtCreator autocompletion always uses the MainWindow class -> there is no distinction between the separate applications and separate MainWindow files from different directories. Renaming MainWindow to something else solves the problem. Where is the best place to post this bug? Best regards, Eddy Ilg From jzakrzewski at e2e.ch Tue Aug 19 03:53:44 2014 From: jzakrzewski at e2e.ch (Jakub Zakrzewski) Date: Tue, 19 Aug 2014 07:53:44 +0000 Subject: [CMake] Qt UI Filename Bug In-Reply-To: <53F2F629.6050407@eddy-ilg.net> References: <53F2F629.6050407@eddy-ilg.net> Message-ID: <56b872f8f8e54fe1bcbb8247a927b693@DBXPR03MB478.eurprd03.prod.outlook.com> -----Original Message----- From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Eddy Ilg Sent: Dienstag, 19. August 2014 09:01 To: cmake Subject: [CMake] Qt UI Filename Bug Dear CMake Developers, I have the following problem in QtCreator with CMake, which seems like a bug: My project has several MainWindow classes and files (.h,.cpp,.ui). In each application I use qt5_wrap_ui( app_UI_SOURCES ${app_UI} ) add_executable( app ${app_SOURCES} ${app_UI_SOURCES} ) QtCreator autocompletion always uses the MainWindow class -> there is no distinction between the separate applications and separate MainWindow files from different directories. Renaming MainWindow to something else solves the problem. Where is the best place to post this bug? Best regards, Eddy Ilg -- 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 Hi. I'd say if you can build your project without problems, this is a QtCreator issue. In my project it sometimes confuses same-named source/headers from different dorectories also, so it may be it. Otherwise this is CMake problem. -- Gruesse, Jakub From me at eddy-ilg.net Tue Aug 19 04:25:48 2014 From: me at eddy-ilg.net (Eddy Ilg) Date: Tue, 19 Aug 2014 10:25:48 +0200 Subject: [CMake] Qt UI Filename Bug In-Reply-To: <56b872f8f8e54fe1bcbb8247a927b693@DBXPR03MB478.eurprd03.prod.outlook.com> References: <53F2F629.6050407@eddy-ilg.net> <56b872f8f8e54fe1bcbb8247a927b693@DBXPR03MB478.eurprd03.prod.outlook.com> Message-ID: <53F30A0C.4050104@eddy-ilg.net> Hi Jakub, yes, I can compile without problems, but the QtCreator bug in relation to CMake is very annoying when autocompleting code in GUIs. Is your project QMake or also CMake? To me this seems to be an isse of QtCreator related to CMake. As you said the filenames get confused / are not coupled with the directories correctly. Best regards, Eddy > Hi. > > I'd say if you can build your project without problems, this is a QtCreator issue. In my > project it sometimes confuses same-named source/headers from different dorectories also, > so it may be it. > > Otherwise this is CMake problem. > > Gruesse, > Jakub From jzakrzewski at e2e.ch Tue Aug 19 04:36:53 2014 From: jzakrzewski at e2e.ch (Jakub Zakrzewski) Date: Tue, 19 Aug 2014 08:36:53 +0000 Subject: [CMake] Qt UI Filename Bug In-Reply-To: <53F30A0C.4050104@eddy-ilg.net> References: <53F2F629.6050407@eddy-ilg.net> <56b872f8f8e54fe1bcbb8247a927b693@DBXPR03MB478.eurprd03.prod.outlook.com> <53F30A0C.4050104@eddy-ilg.net> Message-ID: <602d9d3c3be44f0a891359bdc18f4a89@DBXPR03MB478.eurprd03.prod.outlook.com> -----Original Message----- From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Eddy Ilg Sent: Dienstag, 19. August 2014 10:26 To: cmake Subject: Re: [CMake] Qt UI Filename Bug Hi Jakub, yes, I can compile without problems, but the QtCreator bug in relation to CMake is very annoying when autocompleting code in GUIs. Is your project QMake or also CMake? To me this seems to be an isse of QtCreator related to CMake. As you said the filenames get confused / are not coupled with the directories correctly. Best regards, Eddy > Hi. > > I'd say if you can build your project without problems, this is a QtCreator issue. In my > project it sometimes confuses same-named source/headers from different dorectories also, > so it may be it. > > Otherwise this is CMake problem. > > Gruesse, > Jakub -- 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 Hi. I'm using CMake and I have never used anything else with QtCreator, so I cannot be sure if this is only CMake-related or more genereal problem. Anywway, right now I'm doing complete refactor/rewrite of one project module, so as starting point I have copied old source tree. It is build as separate shared library, all paths have been adjusted. Still "Ctrl+LMB" opens the old definitions. I just never had time to compose a minimum-reproduce example to file a bug for QtCreator. Anyway, I wouldn't blame CMake itself. It can be QtCreator or its CMake support. -- Gruesse, Jakub From hobbes1069 at gmail.com Tue Aug 19 09:09:04 2014 From: hobbes1069 at gmail.com (Richard Shaw) Date: Tue, 19 Aug 2014 08:09:04 -0500 Subject: [CMake] Collecting libraries for NSIS installer Message-ID: I have a project where I currently have a dumb list of libraries to package with the NSIS installer so the program will work under win32. It really only works for one setup (currently Fedora mingw) with some prebuilt libraries downloaded, others provided through Fedora, and others I build myself. This is not very portable to say the least. Is there an easy way when after find_library(...) or find_package(...) to "collect" the appropriate libraries for the NSIS installer? Some of the dependencies might be static libraries which I need to ignore, but the others will be DLL's which I need to pull into the installer. Thanks, Richard -------------- next part -------------- An HTML attachment was scrubbed... URL: From dlrdave at aol.com Tue Aug 19 09:47:07 2014 From: dlrdave at aol.com (David Cole) Date: Tue, 19 Aug 2014 09:47:07 -0400 (EDT) Subject: [CMake] Collecting libraries for NSIS installer In-Reply-To: References: Message-ID: <8D189CB337C09E1-20B4-122E@webmail-vm046.sysops.aol.com> Have you considered GetPrerequisites.cmake or BundleUtilities.cmake? http://www.cmake.org/cmake/help/v3.0/module/GetPrerequisites.html http://www.cmake.org/cmake/help/v3.0/module/BundleUtilities.html It sounds like exactly what you're asking for. HTH, David C. From dlrdave at aol.com Tue Aug 19 10:36:14 2014 From: dlrdave at aol.com (David Cole) Date: Tue, 19 Aug 2014 10:36:14 -0400 (EDT) Subject: [CMake] Collecting libraries for NSIS installer Message-ID: <8D189D2106A0A37-20B4-190A@webmail-vm046.sysops.aol.com> > Definitely getting warmer! It looks like that GetPrerequistes only > works on an existing target so I'm thinking I would have to set this > up as a "super" cmake project after the main project is already built? Right, or as a script that runs at "install" time. It requires an executable file to analyze, so it can come up with the required DLLs. D From post at hendrik-sattler.de Tue Aug 19 12:40:19 2014 From: post at hendrik-sattler.de (Hendrik Sattler) Date: Tue, 19 Aug 2014 18:40:19 +0200 Subject: [CMake] Collecting libraries for NSIS installer In-Reply-To: <8D189D2106A0A37-20B4-190A@webmail-vm046.sysops.aol.com> References: <8D189D2106A0A37-20B4-190A@webmail-vm046.sysops.aol.com> Message-ID: On 19. August 2014 16:36:14 MESZ, David Cole via CMake wrote: >> Definitely getting warmer! It looks like that GetPrerequistes only >> works on an existing target so I'm thinking I would have to set this >> up as a "super" cmake project after the main project is already >built? > >Right, or as a script that runs at "install" time. It requires an >executable file to analyze, so it can come up with the required DLLs. Actually I wonder why this is needed? If all libraries are linked will full path or via imported targets (those that do it right on windows), why do the binaries have to be checked? HS From ope-devel at gmx.de Tue Aug 19 14:42:11 2014 From: ope-devel at gmx.de (Olaf Peter) Date: Tue, 19 Aug 2014 20:42:11 +0200 Subject: [CMake] Linker error with sub project's static libs Message-ID: <53F39A83.7060606@gmx.de> Hello, for my project I have the following structure in my project directory: ./CMakeLists.txt ./source/CMakeLists.txt ./source/eea/CMakeLists.txt ./source/eea/ui/CMakeLists.txt ./source/eea/ui/schematic/CMakeLists.txt with ---8<--- ./CMakeLists.txt: project(eea) ... ---8<--- ./source/CMakeLists.txt: add_subdirectory(eea) ... ---8<--- ./source/eea/CMakeLists.txt add_executable(eea ...) target_link_libraries(eea eea_ui_schematic_lib eea_ui_lib ... ) qt5_use_modules(eea Widgets ...) add_subdirectory(ui) ... ---8<--- ./source/eea/ui/CMakeLists.txt project(eea_ui) ... set(eea_ui_SOURCE mainwindow_private.cpp graphics_view.cpp...) add_library(eea_ui_lib STATIC ${eea_ui_SOURCE} ... ) qt5_use_modules(eea_ui_lib Widgets ...) add_subdirectory(schematic) ... ---8<--- ./source/eea/ui/schematic/CMakeLists.txt: project(eea_ui_schematic) ... set(eea_ui_schematic_SOURCE schematics_view.cpp ...) add_library(eea_ui_schematic_lib STATIC ${eea_ui_schematic_SOURCE} ... ) qt5_use_modules(eea_ui_schematic_lib Widgets ...) So far, so good - all compiles. With ---8<--- ./source/eea/ui/mainwindow_private.cpp : ... createWindows() { SchematicView* schematicView = new SchematicView(q); ... } ---8<--- ./source/eea/ui/graphics_view.cpp: GraphicsView::GraphicsView(QWidget* parent) { ... } ---8<--- ./source/eea/ui/schematic/schematic_view.cpp class SchematicView : public GraphicsView { .... } I got the linker error: ../../lib/libeea_ui_lib.a(mainwindow_private.cpp.o): In function `eea::ui::MainWindowPrivate::createWindows()': mainwindow_private.cpp:(.text+0xbb): warning: undefined reference to `eea::ui::SchematicView::SchematicView(QWidget*)' So, what happened here and how to solve it? Before the contents of ui/schematic moved into the ui directory/project and I've got no errors. Thanks, Olaf From hobbes1069 at gmail.com Wed Aug 20 11:36:21 2014 From: hobbes1069 at gmail.com (Richard Shaw) Date: Wed, 20 Aug 2014 10:36:21 -0500 Subject: [CMake] Collecting libraries for NSIS installer In-Reply-To: References: <8D189D2106A0A37-20B4-190A@webmail-vm046.sysops.aol.com> Message-ID: On Tue, Aug 19, 2014 at 11:40 AM, Hendrik Sattler wrote: > > > On 19. August 2014 16:36:14 MESZ, David Cole via CMake > wrote: > >> Definitely getting warmer! It looks like that GetPrerequistes only > >> works on an existing target so I'm thinking I would have to set this > >> up as a "super" cmake project after the main project is already > >built? > > > >Right, or as a script that runs at "install" time. It requires an > >executable file to analyze, so it can come up with the required DLLs. > > Actually I wonder why this is needed? > If all libraries are linked will full path or via imported targets (those > that do it right on windows), why do the binaries have to be checked > Yes, the more I look at this the more I realize it's not going to work. The script method is going to install the required libraries, in my case on win32 no one is going to run "make install" it's instead going to be "make package". I guess what I need is a way to translate the import libraries into the runtime dll paths. The ".a" is easy enough to handle in regex, but in most cases the import library is in /usr/lib and the runtime library is in /usr/bin. Is there a property I can interrogate to get there? Thanks, Richard -------------- next part -------------- An HTML attachment was scrubbed... URL: From dlrdave at aol.com Wed Aug 20 11:41:23 2014 From: dlrdave at aol.com (David Cole) Date: Wed, 20 Aug 2014 11:41:23 -0400 (EDT) Subject: [CMake] Collecting libraries for NSIS installer Message-ID: <8D18AA454A8BB38-1DCC-991C@webmail-d163.sysops.aol.com> > Yes, the more I look at this the more I realize it's not going to > work. The script method is going to install the required libraries, > in my case on win32 no one is going to run "make install" it's > instead going to be "make package". But "make package" typically runs "make install" under the hood... So if you get it to work with "make install" it should "just work" with "make package". D From nico.schloemer at gmail.com Wed Aug 20 13:46:50 2014 From: nico.schloemer at gmail.com (=?UTF-8?Q?Nico_Schl=C3=B6mer?=) Date: Wed, 20 Aug 2014 19:46:50 +0200 Subject: [CMake] organizing export link libraries Message-ID: Hi all, a general question: I have a dependency chain of libraries A -> B -> C -> ... -> Z and all of those libraries are built with CMake, using CMake's export functionality [1] to let the next in the chain know about its the dependencies. If all of the libraries are built statically and A needs some symbols from a third-party library A1, this information needs to travel to Z. Right now, in the export file I'm writing out the link line as set(a_EXTRA_LIBS -lhdf5 -lhdf5_hl -ldl -lm -lz -lcurl) and then in B set(b_EXTRA_LIBS " -lhdf5 -lhdf5_hl -ldl -lm -lz -lcurl") and so on. Is that the preferred way to handle this in CMake? Any other recommendations? Cheers, Nico [1] http://www.cmake.org/cmake/help/v3.0/module/CMakePackageConfigHelpers.html From a.neundorf-work at gmx.net Wed Aug 20 16:28:02 2014 From: a.neundorf-work at gmx.net (Alexander Neundorf) Date: Wed, 20 Aug 2014 22:28:02 +0200 Subject: [CMake] Variable shadowing between scope, cache and command line argument In-Reply-To: References: Message-ID: <3289997.RrrPv64eG3@tuxedo.neundorf.net> On Wednesday, July 30, 2014 14:59:46 Ghyslain Leclerc wrote: > Hello, > > First post here. Sorry if its too long. Simply trying to be as clear as I > can be. > > I am trying to make sense of the various ways to set a variable and how one > can shadow the other. Long story short, I am trying to get the following > behaviour for a variable in a script: > > 1 - check if MYVAR exists > 1.1 - If it does, test its validity and set a second variable > named MYVAR_VALID to TRUE or FALSE > > 2 - if MYVAR does not exist or if MYVAR_VALID is FALSE, inspect system for > information and set MYVAR (with FORCE in the cache) and MYVAR_VALID (not in > cache, but does not seem to make a difference). > > Hope this is written clearly enough to be understood. Sorry, english is not > my first language. Anyhow, I get the following behaviour easily except in > one case, which is the reason for my question. These are the cases I have > tested : > > - Start with empty cache and call ccmake. Then, MYVAR does not exist. My > script inspects the system, sets the value, sets MYVAR_VALID to TRUE and > stops. On successive runs, the variable is defined and valid, so the > system is not inspected again. Everything is fine. > > - Start with empty cache. Run it once, but can?t find a valid entry (or > find a wrong one somehow, but that?s practically impossible since the code > in my script to inspect the system and to test the variable are basically > the same. I digress, sorry). Set MYVAR_VALID to FALSE. User can set the > value to a valid one and on next run, the script will set MYVAR_VALID to > TRUE and then, we are back to variable defined and valid. Everything is > fine. > > - Start with "non-empty cache" because ccmake (or cmake) is called with > -DMYVAR:PATH="/Users/?, for instance. If the value set on command line is > fine, then MYVAR_VALID will be set to TRUE on the first run and no system > inspection is necessary. The value is now set and valid. Everything is > fine. > > Now, for my problem : > - Start with "non-empty cache" because ccmake (or cmake) is called with > -DMYVAR:PATH="/Users/?, for instance. But this time, the value is not a > valid one. Then, the variable is defined but not valid. So on the first > run, the script will inspect the system. If it can find a valid value, I > would like my script to override the variable with the valid one. Then, set > to valid and so on and so forth... > > I have not been able to do this. I can find the correct value, I can set > the new value, but it is not used. I mean by that that I have inspected > the CMakeCache.txt file and when I call ccmake, the cache contains the > value set on the command line. Then, I launch my cmake script and output > the values of MYVAR and MYVAR_VALID and they are respectively the one of > the command line and FALSE. Then, I find the correct value for MYVAR and > try and set it. When I inspect the cache, it seems the value has > effectively been overwritten. You are using set(... FORCE), right ? > But when I try to output the new variables, > it seems to remain stuck at the value provided on the command line. I have > tried using unset( MYVAR ) in scope, How do you mean that ? IIRC -DVAR=value sets the cache variable. Not sure, it seems -D maybe also sets the non-cache variable ? Then uset() should have worked. Can you post a small example to reproduce it ? Alex From hobbes1069 at gmail.com Wed Aug 20 16:32:00 2014 From: hobbes1069 at gmail.com (Richard Shaw) Date: Wed, 20 Aug 2014 15:32:00 -0500 Subject: [CMake] Collecting libraries for NSIS installer In-Reply-To: <8D18AA454A8BB38-1DCC-991C@webmail-d163.sysops.aol.com> References: <8D18AA454A8BB38-1DCC-991C@webmail-d163.sysops.aol.com> Message-ID: Ok, that being the case I tried it out. There's two things I'm doing differently than the only example[1] I found: 1. Using install(CODE...) instead of install(SCRIPT...), shouldn't work any differently, right? 2. The example is from 2009 and uses: GET_TARGET_PROPERTY(MY_BINARY_LOCATION my_binary LOCATION) Which I get a policy warning about. I tried using $ inside of "get_but apparently I'm not getting how that's supposed to be used. Here's the whole code block: if(WIN32) install(CODE " INCLUDE(GetPrerequisites) GET_PREREQUISITES($ DEPENDENCIES 1 1 \"\" \"\") message(\"Checking for dependencies in $\") message(\"Dependencies: ${DEPENDENCIES}\") FOREACH(DEPENDENCY ${DEPENDENCIES}) GET_FILENAME_COMPONENT(DEPENDENCY_NAME \"${DEPENDENCY}\" NAME) GET_FILENAME_COMPONENT(DEPENDENCY_ACTUAL \"${DEPENDENCY}\" REALPATH) message(\"DEPENDENCY_NAME: ${DEPENDENCY_NAME}\") message(\"DEPENDENCY_ACTUAL: ${DEPENDENCY_ACTUAL}\") FILE(INSTALL DESTINATION bin TYPE EXECUTABLE RENAME \"${DEPENDENCY_NAME}\" FILES \"${DEPENDENCY_ACTUAL}\" ) ENDFOREACH() ") endif(WIN32) --- end --- Ideas? Thanks, Richard [1] http://www.cmake.org/pipermail/cmake/2009-June/029975.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From a.neundorf-work at gmx.net Wed Aug 20 16:50:52 2014 From: a.neundorf-work at gmx.net (Alexander Neundorf) Date: Wed, 20 Aug 2014 22:50:52 +0200 Subject: [CMake] How to deal with incompatible changes in interface of target_link_libraries()? In-Reply-To: <53EA1145.8090907@kitware.com> References: <53E62631.9060500@zonnet.nl> <53E9C965.5000609@astron.nl> <53EA1145.8090907@kitware.com> Message-ID: <1451744.4h30tpZWHN@tuxedo.neundorf.net> On Tuesday, August 12, 2014 09:06:13 Brad King wrote: ... > FYI, the only intended use case for setting a policy to OLD is to > quiet warnings in a maintenance branch of an existing release. > Some day support for OLD behavior of some policies may be dropped, > so all project development moving forward should set the policy > to NEW. Fixing a warning may make the project require the newer cmake version. E.g. if MyProject requires cmake 2.8.10, and there is a new policy in 3.0.0, which generates a warning, a developer using cmake 3.0.0 may see the warning and fix it, but by that he may have broken the build for the required 2.8.10 and actually now 3.0.0 is required. Alex From hobbes1069 at gmail.com Wed Aug 20 17:37:39 2014 From: hobbes1069 at gmail.com (Richard Shaw) Date: Wed, 20 Aug 2014 16:37:39 -0500 Subject: [CMake] Collecting libraries for NSIS installer In-Reply-To: References: <8D18AA454A8BB38-1DCC-991C@webmail-d163.sysops.aol.com> Message-ID: Ok, short answer to #1, no you can't use install(CODE because all your cmake variables we be evaluated now instead of later. Same problem though when I use install(SCRIPT... Run CPack packaging tool... CPack: Create package using NSIS CPack: Install projects CPack: - Run preinstall target for: FreeDV CPack: - Install project: FreeDV warning: target '$' is not absolute... warning: target '$' does not exist... C:/msys32/mingw32/bin/objdump.exe: '$': No such file "Dependencies:" Thanks, Richard -------------- next part -------------- An HTML attachment was scrubbed... URL: From loose at astron.nl Thu Aug 21 03:29:20 2014 From: loose at astron.nl (Marcel Loose) Date: Thu, 21 Aug 2014 09:29:20 +0200 Subject: [CMake] How to deal with incompatible changes in interface of target_link_libraries()? In-Reply-To: <1451744.4h30tpZWHN@tuxedo.neundorf.net> References: <53E62631.9060500@zonnet.nl> <53E9C965.5000609@astron.nl> <53EA1145.8090907@kitware.com> <1451744.4h30tpZWHN@tuxedo.neundorf.net> Message-ID: <53F59FD0.5010305@astron.nl> On 20/08/14 22:50, Alexander Neundorf wrote: > On Tuesday, August 12, 2014 09:06:13 Brad King wrote: > ... >> FYI, the only intended use case for setting a policy to OLD is to >> quiet warnings in a maintenance branch of an existing release. >> Some day support for OLD behavior of some policies may be dropped, >> so all project development moving forward should set the policy >> to NEW. > Fixing a warning may make the project require the newer cmake version. > E.g. if MyProject requires cmake 2.8.10, and there is a new policy in 3.0.0, > which generates a warning, a developer using cmake 3.0.0 may see the warning > and fix it, but by that he may have broken the build for the required 2.8.10 > and actually now 3.0.0 is required. > > Alex That's exactly the problem I keep running into. I want my project to be compatible with any CMake 2.8.x, but also want it to run warning-free with newer CMake versions, without having to resort to -Wno-dev. AFAIK that can only be accomplished by setting some policies temporarily to OLD. However, wrapping target_link_libraries() in a macro that temporarily sets CMP0022 to OLD failed, due to scoping issues :( Cheers, Marcel -------------- next part -------------- A non-text attachment was scrubbed... Name: loose.vcf Type: text/x-vcard Size: 292 bytes Desc: not available URL: From faresoftware.it at gmail.com Thu Aug 21 07:27:10 2014 From: faresoftware.it at gmail.com (Mauro Ziliani) Date: Thu, 21 Aug 2014 13:27:10 +0200 Subject: [CMake] Debug and Release build from a make option Message-ID: Hi all. I came from bakefile 0.2.9 generator. In my projects I defined the default build type as debug. So when I run make my project will build in debug mode. When I need to produce the final executable i have to run make BUILD=release and I'll get the final release executable. How can I achieve the same behavious in CMake (3.0)? Best regards, MZ -------------- next part -------------- An HTML attachment was scrubbed... URL: From ope-devel at gmx.de Thu Aug 21 07:29:52 2014 From: ope-devel at gmx.de (Olaf Peter) Date: Thu, 21 Aug 2014 13:29:52 +0200 Subject: [CMake] Linker error with sub project's static libs In-Reply-To: <53F39A83.7060606@gmx.de> References: <53F39A83.7060606@gmx.de> Message-ID: <53F5D830.6060102@gmx.de> no idea here? It's seems to be a C++ problem, but how to solve it. Changing the order of target_link_libraries(eea eea_ui_schematic_lib eea_ui_lib to target_link_libraries(eea eea_ui_lib eea_ui_schematic_lib makes it even worser - more unresolved symbols. So what happens here? > for my project I have the following structure in my project directory: > > ./CMakeLists.txt > ./source/CMakeLists.txt > ./source/eea/CMakeLists.txt > ./source/eea/ui/CMakeLists.txt > ./source/eea/ui/schematic/CMakeLists.txt > > with > ---8<--- > ./CMakeLists.txt: > project(eea) > ... > > ---8<--- > ./source/CMakeLists.txt: > add_subdirectory(eea) > ... > > ---8<--- > ./source/eea/CMakeLists.txt > add_executable(eea ...) > > target_link_libraries(eea > eea_ui_schematic_lib > eea_ui_lib > ... > ) > > qt5_use_modules(eea Widgets ...) > > add_subdirectory(ui) > ... > > ---8<--- > ./source/eea/ui/CMakeLists.txt > project(eea_ui) > ... > set(eea_ui_SOURCE mainwindow_private.cpp graphics_view.cpp...) > add_library(eea_ui_lib STATIC > ${eea_ui_SOURCE} > ... > ) > > qt5_use_modules(eea_ui_lib Widgets ...) > > add_subdirectory(schematic) > ... > ---8<--- > ./source/eea/ui/schematic/CMakeLists.txt: > project(eea_ui_schematic) > ... > set(eea_ui_schematic_SOURCE schematics_view.cpp ...) > add_library(eea_ui_schematic_lib STATIC > ${eea_ui_schematic_SOURCE} > ... > ) > > qt5_use_modules(eea_ui_schematic_lib Widgets ...) > > So far, so good - all compiles. > > > > With > ---8<--- > ./source/eea/ui/mainwindow_private.cpp : > ... > createWindows() { > SchematicView* schematicView = new SchematicView(q); > ... > } > > ---8<--- > ./source/eea/ui/graphics_view.cpp: > GraphicsView::GraphicsView(QWidget* parent) { ... } > > ---8<--- > ./source/eea/ui/schematic/schematic_view.cpp > class SchematicView > : public GraphicsView > { .... } > > > I got the linker error: > > ../../lib/libeea_ui_lib.a(mainwindow_private.cpp.o): In function > `eea::ui::MainWindowPrivate::createWindows()': > mainwindow_private.cpp:(.text+0xbb): warning: undefined reference to > `eea::ui::SchematicView::SchematicView(QWidget*)' > > So, what happened here and how to solve it? Before the contents of > ui/schematic moved into the ui directory/project and I've got no errors. > > Thanks, > Olaf From nilsgladitz at gmail.com Thu Aug 21 07:39:16 2014 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Thu, 21 Aug 2014 13:39:16 +0200 Subject: [CMake] Debug and Release build from a make option In-Reply-To: References: Message-ID: <53F5DA64.5060808@gmail.com> On 21.08.2014 13:27, Mauro Ziliani wrote: > Hi all. > I came from bakefile 0.2.9 generator. > In my projects I defined the default build type as debug. > > So when I run > > make > > my project will build in debug mode. > > When I need to produce the final executable i have to run > > make BUILD=release > > and I'll get the final release executable. > > How can I achieve the same behavious in CMake (3.0)? CMake has multi- (e.g. Visual Studio, XCode) and single-configuration (e.g. Makefile, Ninja) generators. With multi-configuration generators you pick the build type at build time (build tool invocation). With single-configuration generators you pick the build type at configuration time (cmake invocation). Assuming one of the single-configuration Makefile generators you tell cmake about the build type with e.g. -DCMAKE_BUILD_TYPE=Debug or -DCMAKE_BUILD_TYPE=Release. I would maintain one out of source tree build directory per configuration of interest. Nils From loose at astron.nl Thu Aug 21 08:31:23 2014 From: loose at astron.nl (Marcel Loose) Date: Thu, 21 Aug 2014 14:31:23 +0200 Subject: [CMake] Linker error with sub project's static libs In-Reply-To: <53F5D830.6060102@gmx.de> References: <53F39A83.7060606@gmx.de> <53F5D830.6060102@gmx.de> Message-ID: <53F5E69B.8090200@astron.nl> Olaf, Unless your code snippets are incomplete, I'm missing the following statement in ./source/eea/ui/CMakeLists.txt target_link_libraries(eea_ui_lib eea_ui_schematic_lib) I'm not sure this is causing the link error, but it's worth a try. Furthermore, I think the order of add_subdirectory(), add_library(), and target_link_libraries() is important. You might want to check those as well. Cheers, Marcel Loose. On 21/08/14 13:29, Olaf Peter wrote: > no idea here? It's seems to be a C++ problem, but how to solve it. > Changing the order of > > target_link_libraries(eea > eea_ui_schematic_lib > eea_ui_lib > > to > > target_link_libraries(eea > eea_ui_lib > eea_ui_schematic_lib > > makes it even worser - more unresolved symbols. So what happens here? > >> for my project I have the following structure in my project directory: >> >> ./CMakeLists.txt >> ./source/CMakeLists.txt >> ./source/eea/CMakeLists.txt >> ./source/eea/ui/CMakeLists.txt >> ./source/eea/ui/schematic/CMakeLists.txt >> >> with >> ---8<--- >> ./CMakeLists.txt: >> project(eea) >> ... >> >> ---8<--- >> ./source/CMakeLists.txt: >> add_subdirectory(eea) >> ... >> >> ---8<--- >> ./source/eea/CMakeLists.txt >> add_executable(eea ...) >> >> target_link_libraries(eea >> eea_ui_schematic_lib >> eea_ui_lib >> ... >> ) >> >> qt5_use_modules(eea Widgets ...) >> >> add_subdirectory(ui) >> ... >> >> ---8<--- >> ./source/eea/ui/CMakeLists.txt >> project(eea_ui) >> ... >> set(eea_ui_SOURCE mainwindow_private.cpp graphics_view.cpp...) >> add_library(eea_ui_lib STATIC >> ${eea_ui_SOURCE} >> ... >> ) >> >> qt5_use_modules(eea_ui_lib Widgets ...) >> >> add_subdirectory(schematic) >> ... >> ---8<--- >> ./source/eea/ui/schematic/CMakeLists.txt: >> project(eea_ui_schematic) >> ... >> set(eea_ui_schematic_SOURCE schematics_view.cpp ...) >> add_library(eea_ui_schematic_lib STATIC >> ${eea_ui_schematic_SOURCE} >> ... >> ) >> >> qt5_use_modules(eea_ui_schematic_lib Widgets ...) >> >> So far, so good - all compiles. >> >> >> >> With >> ---8<--- >> ./source/eea/ui/mainwindow_private.cpp : >> ... >> createWindows() { >> SchematicView* schematicView = new SchematicView(q); >> ... >> } >> >> ---8<--- >> ./source/eea/ui/graphics_view.cpp: >> GraphicsView::GraphicsView(QWidget* parent) { ... } >> >> ---8<--- >> ./source/eea/ui/schematic/schematic_view.cpp >> class SchematicView >> : public GraphicsView >> { .... } >> >> >> I got the linker error: >> >> ../../lib/libeea_ui_lib.a(mainwindow_private.cpp.o): In function >> `eea::ui::MainWindowPrivate::createWindows()': >> mainwindow_private.cpp:(.text+0xbb): warning: undefined reference to >> `eea::ui::SchematicView::SchematicView(QWidget*)' >> >> So, what happened here and how to solve it? Before the contents of >> ui/schematic moved into the ui directory/project and I've got no errors. >> >> Thanks, >> Olaf > -------------- next part -------------- A non-text attachment was scrubbed... Name: loose.vcf Type: text/x-vcard Size: 292 bytes Desc: not available URL: From faresoftware.it at gmail.com Thu Aug 21 10:16:54 2014 From: faresoftware.it at gmail.com (Mauro Ziliani) Date: Thu, 21 Aug 2014 16:16:54 +0200 Subject: [CMake] Fwd: Debug and Release build from a make option In-Reply-To: References: <53F5DA64.5060808@gmail.com> Message-ID: ---------- Forwarded message ---------- From: Mauro Ziliani Date: 2014-08-21 16:16 GMT+02:00 Subject: Re: [CMake] Debug and Release build from a make option To: Nils Gladitz So the best choice for Makefile compilation environment is use two different folder out-of-the-source: one for debug build and another for release? 2014-08-21 13:39 GMT+02:00 Nils Gladitz : On 21.08.2014 13:27, Mauro Ziliani wrote: > >> Hi all. >> I came from bakefile 0.2.9 generator. >> In my projects I defined the default build type as debug. >> >> So when I run >> >> make >> >> my project will build in debug mode. >> >> When I need to produce the final executable i have to run >> >> make BUILD=release >> >> and I'll get the final release executable. >> >> How can I achieve the same behavious in CMake (3.0)? >> > > CMake has multi- (e.g. Visual Studio, XCode) and single-configuration > (e.g. Makefile, Ninja) generators. > > With multi-configuration generators you pick the build type at build time > (build tool invocation). > With single-configuration generators you pick the build type at > configuration time (cmake invocation). > > Assuming one of the single-configuration Makefile generators you tell > cmake about the build type with e.g. > -DCMAKE_BUILD_TYPE=Debug or -DCMAKE_BUILD_TYPE=Release. > > I would maintain one out of source tree build directory per configuration > of interest. > > Nils > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nilsgladitz at gmail.com Thu Aug 21 10:34:38 2014 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Thu, 21 Aug 2014 16:34:38 +0200 Subject: [CMake] Fwd: Debug and Release build from a make option In-Reply-To: References: <53F5DA64.5060808@gmail.com> Message-ID: <53F6037E.7060608@gmail.com> On 21.08.2014 16:16, Mauro Ziliani wrote: > > So the best choice for Makefile compilation environment is use two > different folder out-of-the-source: one for debug build and another > for release? > Yes, you could also keep switching the configuration of a single build directory but two distinct build directories will minimize incremental build times. Nils From ope-devel at gmx.de Thu Aug 21 14:19:29 2014 From: ope-devel at gmx.de (Olaf Peter) Date: Thu, 21 Aug 2014 20:19:29 +0200 Subject: [CMake] Linker error with sub project's static libs In-Reply-To: <53F5E69B.8090200@astron.nl> References: <53F39A83.7060606@gmx.de> <53F5D830.6060102@gmx.de> <53F5E69B.8090200@astron.nl> Message-ID: <53F63831.2020201@gmx.de> Hello Marcel, > Olaf, > > Unless your code snippets are incomplete, I'm missing the following > statement in ./source/eea/ui/CMakeLists.txt > > target_link_libraries(eea_ui_lib > eea_ui_schematic_lib) > > I'm not sure this is causing the link error, but it's worth a try. thank you a lot, this solves the linker problem - I have to add these twice, reference to the other lib each time. > > Furthermore, I think the order of add_subdirectory(), add_library(), and > target_link_libraries() is important. You might want to check those as well. The order matches of course, but I haven't never such linker problems. The first time I'm using target_link_lib for a library self. The reason is not clear for me. What happens under the hood here? Thanks, Olaf From leif.walsh at gmail.com Thu Aug 21 14:22:39 2014 From: leif.walsh at gmail.com (Leif Walsh) Date: Thu, 21 Aug 2014 14:22:39 -0400 Subject: [CMake] Linker error with sub project's static libs In-Reply-To: <53F63831.2020201@gmx.de> References: <53F39A83.7060606@gmx.de> <53F5D830.6060102@gmx.de> <53F5E69B.8090200@astron.nl> <53F63831.2020201@gmx.de> Message-ID: Are your libraries mutually dependent? You may be hitting the mutually-dependent static library problem. Look for the word "mutual" near the end of http://www.cmake.org/cmake/help/v3.0/command/target_link_libraries.html, that section explains some of what is going on. On Thu, Aug 21, 2014 at 2:19 PM, Olaf Peter wrote: > Hello Marcel, > > Olaf, >> >> Unless your code snippets are incomplete, I'm missing the following >> statement in ./source/eea/ui/CMakeLists.txt >> >> target_link_libraries(eea_ui_lib >> eea_ui_schematic_lib) >> >> I'm not sure this is causing the link error, but it's worth a try. >> > thank you a lot, this solves the linker problem - I have to add these > twice, reference to the other lib each time. > > >> Furthermore, I think the order of add_subdirectory(), add_library(), and >> target_link_libraries() is important. You might want to check those as >> well. >> > The order matches of course, but I haven't never such linker problems. The > first time I'm using target_link_lib for a library self. The reason is not > clear for me. What happens under the hood here? > > > Thanks, > Olaf > > -- > > 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 > -- Cheers, Leif -------------- next part -------------- An HTML attachment was scrubbed... URL: From braden at endoframe.com Thu Aug 21 16:27:36 2014 From: braden at endoframe.com (Braden McDaniel) Date: Thu, 21 Aug 2014 16:27:36 -0400 Subject: [CMake] =?utf-8?q?add=5Fcustom=5Fcommand_doesn=27t_know_about_tar?= =?utf-8?q?get=3B_but_get=5Ftarget=5Fproperty_does?= Message-ID: I have the following code that executes in a top-level CMakeLists.txt *after* having recursed into subdirectories: get_target_property(TARGET_NAME ${EXPORT_TARGET} NAME) message(STATUS "${EXPORT_TARGET} NAME = ${TARGET_NAME}") add_custom_command( TARGET ${EXPORT_TARGET} POST_BUILD COMMAND ${CMAKE_COMMAND} -E echo $ > ${CMAKE_BINARY_DIR}/${LIB_PATHS}/${EXPORT_TARGET}_$ ) EXPORT_TARGET is a library target defined in a subdirectory. This results in the following output from CMake: my_target NAME = my_target CMake Warning (dev) at CMakeLists.txt:965 (add_custom_command): Policy CMP0040 is not set: The target in the TARGET signature of add_custom_command() must exist. Run "cmake --help-policy CMP0040" for policy details. Use the cmake_policy command to set the policy and suppress this warning. The target name "my_target" is unknown in this context. How come get_target_property knows about the target but add_custom_command does not? I am using CMake 3.0.1. -- Braden McDaniel From nilsgladitz at gmail.com Thu Aug 21 17:05:00 2014 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Thu, 21 Aug 2014 23:05:00 +0200 Subject: [CMake] add_custom_command doesn't know about target; but get_target_property does In-Reply-To: References: Message-ID: <53F65EFC.1080700@gmail.com> On 21.08.2014 22:27, Braden McDaniel wrote: > I have the following code that executes in a top-level CMakeLists.txt > *after* having recursed into subdirectories: > > get_target_property(TARGET_NAME ${EXPORT_TARGET} NAME) > message(STATUS "${EXPORT_TARGET} NAME = ${TARGET_NAME}") > add_custom_command( > TARGET ${EXPORT_TARGET} POST_BUILD > COMMAND ${CMAKE_COMMAND} -E echo $ > > ${CMAKE_BINARY_DIR}/${LIB_PATHS}/${EXPORT_TARGET}_$ > ) > > EXPORT_TARGET is a library target defined in a subdirectory. This > results in the following output from CMake: > > my_target NAME = my_target > CMake Warning (dev) at CMakeLists.txt:965 (add_custom_command): > Policy CMP0040 is not set: The target in the TARGET signature of > add_custom_command() must exist. Run "cmake --help-policy CMP0040" for > policy details. Use the cmake_policy command to set the policy and > suppress this warning. > > The target name "my_target" is unknown in this context. > > How come get_target_property knows about the target but > add_custom_command does not? > > I am using CMake 3.0.1. > Custom commands can only be attached to targets defined in the current directory. Nils From braden at endoframe.com Thu Aug 21 20:15:01 2014 From: braden at endoframe.com (Braden McDaniel) Date: Thu, 21 Aug 2014 20:15:01 -0400 Subject: [CMake] add_custom_command doesn't know about target; but get_target_property does In-Reply-To: <53F65EFC.1080700@gmail.com> References: <53F65EFC.1080700@gmail.com> Message-ID: <1408666501.17227.4.camel@hinge.endoframe.net> On Thu, 2014-08-21 at 23:05 +0200, Nils Gladitz wrote: > On 21.08.2014 22:27, Braden McDaniel wrote: > > I have the following code that executes in a top-level CMakeLists.txt > > *after* having recursed into subdirectories: > > > > get_target_property(TARGET_NAME ${EXPORT_TARGET} NAME) > > message(STATUS "${EXPORT_TARGET} NAME = ${TARGET_NAME}") > > add_custom_command( > > TARGET ${EXPORT_TARGET} POST_BUILD > > COMMAND ${CMAKE_COMMAND} -E echo $ > > > ${CMAKE_BINARY_DIR}/${LIB_PATHS}/${EXPORT_TARGET}_$ > > ) > > > > EXPORT_TARGET is a library target defined in a subdirectory. This > > results in the following output from CMake: > > > > my_target NAME = my_target > > CMake Warning (dev) at CMakeLists.txt:965 (add_custom_command): > > Policy CMP0040 is not set: The target in the TARGET signature of > > add_custom_command() must exist. Run "cmake --help-policy CMP0040" for > > policy details. Use the cmake_policy command to set the policy and > > suppress this warning. > > > > The target name "my_target" is unknown in this context. > > > > How come get_target_property knows about the target but > > add_custom_command does not? > > > > I am using CMake 3.0.1. > > > > Custom commands can only be attached to targets defined in the current > directory. Ah. Bummer. Well, as you might have guessed, I'm trying to address an issue where the LOCATION property of a target (EXPORT_TARGET, in the example above) was being used. Is there some way I can get this information about the target that doesn't involve modifying the CMakeLists.txt in each subdirectory where a target of interest resides? -- Braden McDaniel From kl222 at 126.com Thu Aug 21 21:47:45 2014 From: kl222 at 126.com (kl222) Date: Fri, 22 Aug 2014 09:47:45 +0800 Subject: [CMake] set(CMAKE_AUTOUIC ON) question:Don't process ui file Message-ID: <134a01cfbdab$19cfa690$4d6ef3b0$@126.com> Hello all: I use cmake build qt5 project. I use set(CMAKE_AUTOUIC ON). It can handle most of the files, but there are a file are not processed. Please help us to see why? The file is not be processed in the annex. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: FrmSendFile.zip Type: application/octet-stream Size: 1382 bytes Desc: not available URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: CMakeLists.txt URL: From ope-devel at gmx.de Fri Aug 22 02:00:01 2014 From: ope-devel at gmx.de (Olaf Peter) Date: Fri, 22 Aug 2014 08:00:01 +0200 Subject: [CMake] Linker error with sub project's static libs In-Reply-To: References: <53F39A83.7060606@gmx.de> <53F5D830.6060102@gmx.de> <53F5E69B.8090200@astron.nl> <53F63831.2020201@gmx.de> Message-ID: <53F6DC61.9050307@gmx.de> Hello Leif, > Are your libraries mutually dependent? You may be hitting the > mutually-dependent static library problem. Look for the word "mutual" near > the end of > http://www.cmake.org/cmake/help/v3.0/command/target_link_libraries.html, > that section explains some of what is going on. yes it is mutually, ui_lib creates a SchematicView, which is derived from GraphicView. SchematicView's instance is in ui_schematic_lib, where GraphicsView is in ui_lib. Probably I should stay the files inside these directory and add them to the source in ui_lib project as the docs suggested. Thanks, Olaf >>> Unless your code snippets are incomplete, I'm missing the following >>> statement in ./source/eea/ui/CMakeLists.txt >>> >>> target_link_libraries(eea_ui_lib >>> eea_ui_schematic_lib) >>> >>> I'm not sure this is causing the link error, but it's worth a try. >>> >> thank you a lot, this solves the linker problem - I have to add these >> twice, reference to the other lib each time. >> >> >>> Furthermore, I think the order of add_subdirectory(), add_library(), and >>> target_link_libraries() is important. You might want to check those as >>> well. >>> >> The order matches of course, but I haven't never such linker problems. The >> first time I'm using target_link_lib for a library self. The reason is not >> clear for me. What happens under the hood here? >> >> >> Thanks, >> Olaf >> >> -- >> >> 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 loose at astron.nl Fri Aug 22 03:34:59 2014 From: loose at astron.nl (Marcel Loose) Date: Fri, 22 Aug 2014 09:34:59 +0200 Subject: [CMake] Linker error with sub project's static libs In-Reply-To: <53F63831.2020201@gmx.de> References: <53F39A83.7060606@gmx.de> <53F5D830.6060102@gmx.de> <53F5E69B.8090200@astron.nl> <53F63831.2020201@gmx.de> Message-ID: <53F6F2A3.80002@astron.nl> Hi Olaf, See my reply below inline. On 21/08/14 20:19, Olaf Peter wrote: > Hello Marcel, >> Olaf, >> >> Unless your code snippets are incomplete, I'm missing the following >> statement in ./source/eea/ui/CMakeLists.txt >> >> target_link_libraries(eea_ui_lib >> eea_ui_schematic_lib) >> >> I'm not sure this is causing the link error, but it's worth a try. > thank you a lot, this solves the linker problem - I have to add these > twice, reference to the other lib each time. >> >> Furthermore, I think the order of add_subdirectory(), add_library(), and >> target_link_libraries() is important. You might want to check those >> as well. > The order matches of course, but I haven't never such linker problems. > The first time I'm using target_link_lib for a library self. The > reason is not clear for me. What happens under the hood here? Libraries can depend on one another. If code that produces libB uses functions that are implemented in code that produces libA, then libB depends on libA. When creating static libraries this doesn't make much of a difference; after all a static library is just a bunch of object files. However, when creating shared libraries it does. Shared library libB will record internally that it depends on libA; something a static library cannot do. Suppose you're linking a main program that only uses functions defined in libB. When using shared libraries, you only need to link your main program against libB; remember, libB has recorded internally that it depends on libA. However, when using static libraries you need to link against libB and libA, even though your main program doesn't use any functions in libA. CMake to the rescue! The only thing you have to tell CMake is that libB depends on libA, using target_link_libraries(B A). CMake will then make sure that the correct libraries on put on the link line in the correct order. There's only one exception: circular dependencies. In that case you may need to help CMake a bit. IMHO you should try very hard to avoid circular library dependencies; they are a real PITA. > Thanks, > Olaf > Cheers, Marcel Loose. -------------- next part -------------- A non-text attachment was scrubbed... Name: loose.vcf Type: text/x-vcard Size: 292 bytes Desc: not available URL: From nilsgladitz at gmail.com Fri Aug 22 06:37:32 2014 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Fri, 22 Aug 2014 12:37:32 +0200 Subject: [CMake] add_custom_command doesn't know about target; but get_target_property does In-Reply-To: <1408666501.17227.4.camel@hinge.endoframe.net> References: <53F65EFC.1080700@gmail.com> <1408666501.17227.4.camel@hinge.endoframe.net> Message-ID: <53F71D6C.6020204@gmail.com> On 22.08.2014 02:15, Braden McDaniel wrote: > Ah. Bummer. > > Well, as you might have guessed, I'm trying to address an issue where > the LOCATION property of a target (EXPORT_TARGET, in the example above) > was being used. Is there some way I can get this information about the > target that doesn't involve modifying the CMakeLists.txt in each > subdirectory where a target of interest resides? Perhaps something like: file(GENERATE OUTPUT "${CMAKE_BINARY_DIR}/${LIB_PATHS}/${EXPORT_TARGET}_$" CONTENT "$" ) Or if you want to keep this at build time a custom command with the OUTPUT signature and e.g. a custom target that depends on that output. Nils From rleigh at codelibre.net Fri Aug 22 06:31:13 2014 From: rleigh at codelibre.net (Roger Leigh) Date: Fri, 22 Aug 2014 11:31:13 +0100 Subject: [CMake] Behaviour of FindPythonInterp appears suboptimal Message-ID: <20140822103113.GH7997@codelibre.net> I thought using FindPythonInterp would be more portable than simply invoking "python" directly (i.e. using $PYTHON_EXECUTABLE). However, this does not appear to be the case. I'd be interested to know if this is intentional or if I'm doing something wrong. I've tried using "find_package(PythonInterp 2.6.0 REQUIRED)" on a variety of systems. The software in question works with any python 2.6 or 2.7 version. On Debian, with the default python 2.7 installed, it picked up python 2.6.8 (from python2.6-minimal) which lacked all the required modules. /usr/bin/python was 2.7 and matched the version requirement, and had all the required modules available. On Windows, with an active virtualenv, it doesn't use the virtualenv python on the path, but an entirely different version without the modules I need available. Similar problems seen for Ubuntu. I think the general problem here is that it tries to be too clever, and tries to find a lower version in preference to a perfectly suitable newer version, and even the version on the path. This includes using virtualenv, where I've carefully gone to the effort of setting up a custom environment for the purpose only to have it be ignored. I would have expected that if the default path contained "python", "python2" or "python2.7", these should all be preferred (in order) over "python2.6" or any autodetected version not on the path, if the version meets the requirement from find_package. The current behaviour gets it wrong in almost every situation except where there's only a single version to choose from! Regards, 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 eike at sf-mail.de Fri Aug 22 06:48:15 2014 From: eike at sf-mail.de (Rolf Eike Beer) Date: Fri, 22 Aug 2014 12:48:15 +0200 Subject: [CMake] Behaviour of FindPythonInterp appears suboptimal In-Reply-To: <20140822103113.GH7997@codelibre.net> References: <20140822103113.GH7997@codelibre.net> Message-ID: <1531093.rmvzB1l5jC@eto> Roger Leigh wrote: > I thought using FindPythonInterp would be more portable than > simply invoking "python" directly (i.e. using $PYTHON_EXECUTABLE). > However, this does not appear to be the case. I'd be interested to > know if this is intentional or if I'm doing something wrong. > > I've tried using "find_package(PythonInterp 2.6.0 REQUIRED)" on a > variety of systems. The software in question works with any > python 2.6 or 2.7 version. > > On Debian, with the default python 2.7 installed, it picked up > python 2.6.8 (from python2.6-minimal) which lacked all the > required modules. /usr/bin/python was 2.7 and matched the > version requirement, and had all the required modules > available. In case you want the newest version of any Python major, as in your case, try find_package(PythonInterp 2 REQUIRED). But you are right, this would also successfully return you a 2.5. Greetings, 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 dlrdave at aol.com Fri Aug 22 07:24:43 2014 From: dlrdave at aol.com (David Cole) Date: Fri, 22 Aug 2014 07:24:43 -0400 (EDT) Subject: [CMake] Behaviour of FindPythonInterp appears suboptimal Message-ID: <8D18C12CE04FA36-E14-16693@webmail-m149.sysops.aol.com> >> I thought using FindPythonInterp would be more portable than >> simply invoking "python" directly (i.e. using $PYTHON_EXECUTABLE). > In case you want the newest version of any Python major, as in your > case, try > find_package(PythonInterp 2 REQUIRED). But you are right, this would > also successfully return you a 2.5. Or, if you want to prefer the python in the environment PATH, and then do your own version check to make sure it's suitable, use something like this: # http://www.cmake.org/cmake/help/v3.0/command/find_program.html find_program(PYTHON_EXECUTABLE python PATHS ENV PATH # look in the PATH environment variable NO_DEFAULT_PATH # do not look anywhere else... ) find_package(PythonInterp) And then after the find_package, you can do your own version check with the variables: PYTHON_VERSION_MAJOR='2' PYTHON_VERSION_MINOR='7' PYTHON_VERSION_PATCH='6' PYTHON_VERSION_STRING='2.7.6' and the VERSION_GREATER / VERSION_LESS arguments to the "if" command. HTH, David C. From braden at endoframe.com Fri Aug 22 08:24:48 2014 From: braden at endoframe.com (Braden McDaniel) Date: Fri, 22 Aug 2014 08:24:48 -0400 Subject: [CMake] add_custom_command doesn't know about target; but get_target_property does In-Reply-To: <53F71D6C.6020204@gmail.com> References: <53F65EFC.1080700@gmail.com> <1408666501.17227.4.camel@hinge.endoframe.net> <53F71D6C.6020204@gmail.com> Message-ID: <1408710288.17227.6.camel@hinge.endoframe.net> On Fri, 2014-08-22 at 12:37 +0200, Nils Gladitz wrote: > On 22.08.2014 02:15, Braden McDaniel wrote: > > Ah. Bummer. > > > > Well, as you might have guessed, I'm trying to address an issue where > > the LOCATION property of a target (EXPORT_TARGET, in the example above) > > was being used. Is there some way I can get this information about the > > target that doesn't involve modifying the CMakeLists.txt in each > > subdirectory where a target of interest resides? > > Perhaps something like: > > file(GENERATE > OUTPUT "${CMAKE_BINARY_DIR}/${LIB_PATHS}/${EXPORT_TARGET}_$" > CONTENT "$" > ) > > Or if you want to keep this at build time a custom command with the > OUTPUT signature and > e.g. a custom target that depends on that output. Actually, I'd rather not do it at build time; I just didn't realize I could avoid it. That should work quite nicely. Thanks! -- Braden McDaniel From mike.jackson at bluequartz.net Fri Aug 22 10:02:09 2014 From: mike.jackson at bluequartz.net (Michael Jackson) Date: Fri, 22 Aug 2014 10:02:09 -0400 Subject: [CMake] Preferred way to find Qt5 Plugins with CMake 3.x Message-ID: <09BC2269-E1DC-48D5-9C56-1E5149200ED9@bluequartz.net> I am trying to locate specific plugins from the Qt5 installation. I guess in previous iterations of FindQt4 possibly the "QT_PLUGINS_DIR" may have been defined because I am using this variable in my Qt4 based codes. I am still trying to wade my way through Qt5 so I maybe missing something obvious on how to do this. Any help is much appreciated. Thanks Mike Jackson dream3d.bluequarz.net From mike.jackson at bluequartz.net Fri Aug 22 10:48:30 2014 From: mike.jackson at bluequartz.net (Michael Jackson) Date: Fri, 22 Aug 2014 10:48:30 -0400 Subject: [CMake] Preferred way to find Qt5 Plugins with CMake 3.x In-Reply-To: <09BC2269-E1DC-48D5-9C56-1E5149200ED9@bluequartz.net> References: <09BC2269-E1DC-48D5-9C56-1E5149200ED9@bluequartz.net> Message-ID: <0CB04F4C-5F1F-4B96-9A20-D2A332637E9D@bluequartz.net> To answer my own question, this bit of code gets me started: foreach(plugin ${Qt5Gui_PLUGINS}) get_target_property(_loc ${plugin} LOCATION) message("Core Plugin ${plugin} is at location ${_loc}") endforeach() Now I need to find the debug versions of the library.? http://qt-project.org/doc/qt-5/cmake-manual.html ? Looking on Google gives me this bit of Code: # Find the QtWidgets library find_package(Qt5 COMPONENTS Core Widgets Network Gui Concurrent) get_target_property(qjpeg_loc_release Qt5::QJpegPlugin LOCATION_Release) message("QJpeg DLL: ${qjpeg_loc_release}") get_target_property(qjpeg_loc Qt5::QJpegPlugin LOCATION_Debug) message("QJpeg DLL: ${qjpeg_loc}") Interestingly on OS X 10.8.5 with CMake 3.0.1 and Qt5 self built I get the following output: QJpeg DLL: /Users/Shared/Toolkits/Qt-5.3.1/plugins/imageformats/libqjpeg.dylib QJpeg DLL: /Users/Shared/Toolkits/Qt-5.3.1/plugins/imageformats/libqjpeg.dylib but on Windows 7x64 with VS2013 and Qt5 (Downloaded from qt-project.org). I get the following: QJpeg DLL: C:/Developer/x64/Qt5.3.1/5.3/msvc2013_64_opengl/plugins/imageformats/qjpeg.dll QJpeg DLL: C:/Developer/x64/Qt5.3.1/5.3/msvc2013_64_opengl/plugins/imageformats/qjpegd.dll I know when I configured Qt5 on OS X i used -debug-and-release and in fact there are _debug versions of the plugins on OS X? Anyone have any thoughts on this? I know in reality on OS X I can mix-n-match Release and Debug libraries but I just want to make sure I am not missing something critical? I have not even tried Linux yet Thanks for any clarifications Mike Jackson On Aug 22, 2014, at 10:02 AM, Michael Jackson wrote: > I am trying to locate specific plugins from the Qt5 installation. I guess in previous iterations of FindQt4 possibly the "QT_PLUGINS_DIR" may have been defined because I am using this variable in my Qt4 based codes. I am still trying to wade my way through Qt5 so I maybe missing something obvious on how to do this. Any help is much appreciated. > > Thanks > Mike Jackson > dream3d.bluequarz.net > From braden at endoframe.com Fri Aug 22 12:18:01 2014 From: braden at endoframe.com (Braden McDaniel) Date: Fri, 22 Aug 2014 16:18:01 +0000 (UTC) Subject: [CMake] =?utf-8?q?add=5Fcustom=5Fcommand_doesn=27t_know_about_tar?= =?utf-8?q?get=3B_but_get=5Ftarget=5Fproperty_does?= References: <53F65EFC.1080700@gmail.com> <1408666501.17227.4.camel@hinge.endoframe.net> <53F71D6C.6020204@gmail.com> Message-ID: Nils Gladitz writes: > Perhaps something like: > > file(GENERATE > OUTPUT "${CMAKE_BINARY_DIR}/${LIB_PATHS}/${EXPORT_TARGET}_$" > CONTENT "$" > ) Actually, upon closer inspection, it looks like this doesn't work because $ won't be aware of the current configuration at CMake configure-time. I'm trying to get the configuration-dependent path of the emitted library. (And I need to support Windows project files.) > Or if you want to keep this at build time a custom command with the > OUTPUT signature and > e.g. a custom target that depends on that output. It's not clear to me that this approach would solve the above problem. Braden From nilsgladitz at gmail.com Fri Aug 22 12:49:41 2014 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Fri, 22 Aug 2014 18:49:41 +0200 Subject: [CMake] add_custom_command doesn't know about target; but get_target_property does In-Reply-To: References: <53F65EFC.1080700@gmail.com> <1408666501.17227.4.camel@hinge.endoframe.net> <53F71D6C.6020204@gmail.com> Message-ID: <53F774A5.7040303@gmail.com> On 22.08.2014 18:18, Braden McDaniel wrote: > Actually, upon closer inspection, it looks like this doesn't work because > $ won't be aware of the current configuration at CMake > configure-time. I'm trying to get the configuration-dependent path of the emitted library. > (And I need to support Windows project files.) It generates one file per configuration (see the $ generator expression at the end of the output filename) and uses the configuration specific expansion of $ respectively. Nils From braden at endoframe.com Fri Aug 22 16:29:51 2014 From: braden at endoframe.com (Braden McDaniel) Date: Fri, 22 Aug 2014 16:29:51 -0400 Subject: [CMake] =?utf-8?q?add=5Fcustom=5Fcommand_and_CONFIG-dependent_out?= =?utf-8?q?put?= Message-ID: I'm trying to do this: set(LIB_STAGEDIR "${STAGEDIR}/lib/$") add_custom_command( OUTPUT ${LIB_STAGEDIR} COMMAND ${CMAKE_COMMAND} -E make_directory ${LIB_STAGEDIR} ) ?and CMake complains thusly: add_custom_command called with OUTPUT containing a "<". This character is not allowed. Is there some way to specify OUTPUT when it is dependent on the value of $ or similar? -- Braden McDaniel From dlrdave at aol.com Fri Aug 22 16:58:10 2014 From: dlrdave at aol.com (David Cole) Date: Fri, 22 Aug 2014 16:58:10 -0400 (EDT) Subject: [CMake] add_custom_command and CONFIG-dependent output Message-ID: <8D18C62EA93BA62-1814-196F8@webmail-va051.sysops.aol.com> Use "${CMAKE_CFG_INTDIR}" in the context of add_custom_command OUTPUT, not $. You may also use that in the COMMAND arguments. See documentation here: http://www.cmake.org/cmake/help/v3.0/variable/CMAKE_CFG_INTDIR.html The $<> generator expressions are relatively new, and do not work in all contexts that you might expect yet. CMAKE_CFG_INTDIR has been around for quite some time, though, and works very well with custom commands. HTH, David C. From david at zemon.name Fri Aug 22 20:29:41 2014 From: david at zemon.name (David Zemon) Date: Fri, 22 Aug 2014 19:29:41 -0500 Subject: [CMake] CMake Error With No Description Message-ID: <53F7E075.6090107@zemon.name> Hello all, I have a working (in Linux) CMake project and am now trying to make it cross-platform. I'm nearly there! CMake generates the Makefiles without error but upon trying to run Make, things die. Here's the output from "make VERBOSE=1" C:\Users\David\Documents\GitHub\PropWare>make VERBOSE=1 C:/Users/David/cmake-3.0.1-win32-x86/bin/cmake.exe -HC:/Users/David/Documents/GitHub/PropWare -BC:/Users/David/Documents/GitHub/PropWare --check-build-system CMakeFiles/Makefile.cmake 0 C:/Users/David/cmake-3.0.1-win32-x86/bin/cmake.exe -E cmake_progress_start C:/Users/David/Documents/GitHub/PropWare/CMakeFiles C:/Users/David/Documents/GitHub/PropWare/CMakeFiles/progress.marks make -f CMakeFiles/Makefile2 all make[1]: Entering directory `C:/Users/David/Documents/GitHub/PropWare' make -f simple/cog/CMakeFiles/Simple_cog.dir/build.make simple/cog/CMakeFiles/Simple_cog.dir/depend make[2]: Entering directory `C:/Users/David/Documents/GitHub/PropWare' C:/Users/David/cmake-3.0.1-win32-x86/bin/cmake.exe -E cmake_depends "Unix Makefiles" C:/Users/David/Documents/GitHub/PropWare C:/Users/David/Documents/GitHub/PropWare/simple/cog C:/Users/David/Documents/GitHub/PropWare C:/Users/David/Documents/GitHub/PropWare/simpl e/cog C:/Users/David/Documents/GitHub/PropWare/simple/cog/CMakeFiles/Simple_cog.dir/DependInfo.cmake --color= make[2]: *** [simple/cog/CMakeFiles/Simple_cog.dir/depend] Error 1 make[2]: Leaving directory `C:/Users/David/Documents/GitHub/PropWare' make[1]: *** [simple/cog/CMakeFiles/Simple_cog.dir/all] Error 2 make[1]: Leaving directory `C:/Users/David/Documents/GitHub/PropWare' make: *** [all] Error 2 C:\Users\David\Documents\GitHub\PropWare> A note: yes, it is set to Unix Makefiles. Yes, that is on purpose - a copy of GNU Make is included in the compiler package for this project. Anyone have ideas on what to look for? I'm completely lost. Thanks, David -------------- next part -------------- An HTML attachment was scrubbed... URL: From nico.schloemer at gmail.com Sat Aug 23 02:12:51 2014 From: nico.schloemer at gmail.com (=?UTF-8?Q?Nico_Schl=C3=B6mer?=) Date: Sat, 23 Aug 2014 08:12:51 +0200 Subject: [CMake] make target export file follow symlinks (or something better?) Message-ID: Hi all, I'm linking my shared library against ``` /usr/lib/x86_64-linux-gnu/libhdf5.so -> libhdf5.so.7.0.0 /usr/lib/x86_64-linux-gnu/libhdf5.so.7 -> libhdf5.so.7.0.0 /usr/lib/x86_64-linux-gnu/libhdf5.so.7.0.0 ``` resulting in the dynamic dependency ``` $ ldd mylib.so.1.0.0 | grep hdf5 libhdf5.so.7 => /usr/lib/x86_64-linux-gnu/libhdf5.so.7 (0x00007f50179e2000) ``` The export file `mylibTargets.cmake` however lists ``` set_target_properties(mylib PROPERTIES INTERFACE_INCLUDE_DIRECTORIES "${_IMPORT_PREFIX}/include" INTERFACE_LINK_LIBRARIES "/usr/lib/x86_64-linux-gnu/libhdf5.so" ) ``` (without the so-version). This is not good since this symlink might not be present when I configure a project against mylib. And it doesn't have to be either: All I need is `/usr/lib/x86_64-linux-gnu/libhdf5.so.7` as specified by `ldd`. What can I do to have the actual `ldd` info present in the target export file? Cheers, Nico From apaku at gmx.de Sat Aug 23 05:01:15 2014 From: apaku at gmx.de (Andreas Pakulat) Date: Sat, 23 Aug 2014 11:01:15 +0200 Subject: [CMake] make target export file follow symlinks (or something better?) In-Reply-To: References: Message-ID: Hi, On Sat, Aug 23, 2014 at 8:12 AM, Nico Schl?mer wrote: > Hi all, > > I'm linking my shared library against > ``` > /usr/lib/x86_64-linux-gnu/libhdf5.so -> libhdf5.so.7.0.0 > /usr/lib/x86_64-linux-gnu/libhdf5.so.7 -> libhdf5.so.7.0.0 > /usr/lib/x86_64-linux-gnu/libhdf5.so.7.0.0 > ``` > resulting in the dynamic dependency > ``` > $ ldd mylib.so.1.0.0 | grep hdf5 > libhdf5.so.7 => /usr/lib/x86_64-linux-gnu/libhdf5.so.7 (0x00007f50179e2000) > ``` > The export file `mylibTargets.cmake` however lists > ``` > set_target_properties(mylib PROPERTIES > INTERFACE_INCLUDE_DIRECTORIES "${_IMPORT_PREFIX}/include" > INTERFACE_LINK_LIBRARIES "/usr/lib/x86_64-linux-gnu/libhdf5.so" > ) > ``` > (without the so-version). This is not good since this symlink might > not be present when I configure a project against mylib. And it > doesn't have to be either: Actually it does have to be there (or rather it will be there). > > All I need is > `/usr/lib/x86_64-linux-gnu/libhdf5.so.7` as specified by `ldd`. > No, what you also need are the headers of that library, i.e. the 'development' part of the library installation. Since those development parts are usually mutually exclusively installable between different versions there's going to be only 1 installed. So the .so symlink will be there and hence the linking will work. If the symlink links to a different so-version the linker will abort when trying to link against mylib. The only exception would be if your mylib does not expose any of the API that hdf5 provides and a user of mylib does not need to know or care that you're using hdf5. In that case you should drop that library from your public link interface. That'll automatically drop the imported target in the export file, as the linker does not need to know what mylib links against when linking an app against mylib. (at least for shared libraries). Andreas -------------- next part -------------- An HTML attachment was scrubbed... URL: From nico.schloemer at gmail.com Sat Aug 23 09:51:18 2014 From: nico.schloemer at gmail.com (=?UTF-8?Q?Nico_Schl=C3=B6mer?=) Date: Sat, 23 Aug 2014 15:51:18 +0200 Subject: [CMake] make target export file follow symlinks (or something better?) In-Reply-To: References: Message-ID: Hi, thanks for your concise reply! > The only exception would be if your mylib does not expose any of the API > that hdf5 provides and a user of mylib does not need to know or care that > you're using hdf5. That is exactly my use case. > In that case you should drop that library from your public link interface. Right, it should not be INTERFACE_LINK_LIBRARIES but LINK_LIBRARIES [1]. The reason why I do need to have the link libraries is > (at least for shared libraries). exactly that: static libs. How do I get LINK_LIBRARIES instead of INTERFACE_LINK_LIBRARIES in the target file? --Nico [1] http://www.cmake.org/cmake/help/v3.0/prop_tgt/LINK_LIBRARIES.html On Sat, Aug 23, 2014 at 11:01 AM, Andreas Pakulat wrote: > Hi, > > On Sat, Aug 23, 2014 at 8:12 AM, Nico Schl?mer > wrote: >> >> Hi all, >> >> I'm linking my shared library against >> ``` >> /usr/lib/x86_64-linux-gnu/libhdf5.so -> libhdf5.so.7.0.0 >> /usr/lib/x86_64-linux-gnu/libhdf5.so.7 -> libhdf5.so.7.0.0 >> /usr/lib/x86_64-linux-gnu/libhdf5.so.7.0.0 >> ``` >> resulting in the dynamic dependency >> ``` >> $ ldd mylib.so.1.0.0 | grep hdf5 >> libhdf5.so.7 => /usr/lib/x86_64-linux-gnu/libhdf5.so.7 >> (0x00007f50179e2000) >> ``` >> The export file `mylibTargets.cmake` however lists >> ``` >> set_target_properties(mylib PROPERTIES >> INTERFACE_INCLUDE_DIRECTORIES "${_IMPORT_PREFIX}/include" >> INTERFACE_LINK_LIBRARIES "/usr/lib/x86_64-linux-gnu/libhdf5.so" >> ) >> ``` >> (without the so-version). This is not good since this symlink might >> not be present when I configure a project against mylib. And it >> doesn't have to be either: > > > Actually it does have to be there (or rather it will be there). > >> >> > All I need is >> `/usr/lib/x86_64-linux-gnu/libhdf5.so.7` as specified by `ldd`. > > > No, what you also need are the headers of that library, i.e. the > 'development' part of the library installation. Since those development > parts are usually mutually exclusively installable between different > versions there's going to be only 1 installed. So the .so symlink will be > there and hence the linking will work. If the symlink links to a different > so-version the linker will abort when trying to link against mylib. > > The only exception would be if your mylib does not expose any of the API > that hdf5 provides and a user of mylib does not need to know or care that > you're using hdf5. In that case you should drop that library from your > public link interface. That'll automatically drop the imported target in the > export file, as the linker does not need to know what mylib links against > when linking an app against mylib. (at least for shared libraries). > > Andreas From nico.schloemer at gmail.com Sat Aug 23 12:36:46 2014 From: nico.schloemer at gmail.com (=?UTF-8?Q?Nico_Schl=C3=B6mer?=) Date: Sat, 23 Aug 2014 18:36:46 +0200 Subject: [CMake] make target export file follow symlinks (or something better?) In-Reply-To: References: Message-ID: > How do I get LINK_LIBRARIES instead of INTERFACE_LINK_LIBRARIES in the > target file? Got it! It's the PRIVATE attribute for TARGET_LINK_LIBRARIES that i need [1]. Cheers, Nico [1] http://www.cmake.org/cmake/help/v3.0/command/target_link_libraries.html On Sat, Aug 23, 2014 at 3:51 PM, Nico Schl?mer wrote: > Hi, > > thanks for your concise reply! > >> The only exception would be if your mylib does not expose any of the API >> that hdf5 provides and a user of mylib does not need to know or care that >> you're using hdf5. > > That is exactly my use case. > >> In that case you should drop that library from your public link interface. > > Right, it should not be INTERFACE_LINK_LIBRARIES but LINK_LIBRARIES > [1]. The reason why I do need to have the link libraries is > >> (at least for shared libraries). > > exactly that: static libs. > How do I get LINK_LIBRARIES instead of INTERFACE_LINK_LIBRARIES in the > target file? > > --Nico > > > [1] http://www.cmake.org/cmake/help/v3.0/prop_tgt/LINK_LIBRARIES.html > > > > On Sat, Aug 23, 2014 at 11:01 AM, Andreas Pakulat wrote: >> Hi, >> >> On Sat, Aug 23, 2014 at 8:12 AM, Nico Schl?mer >> wrote: >>> >>> Hi all, >>> >>> I'm linking my shared library against >>> ``` >>> /usr/lib/x86_64-linux-gnu/libhdf5.so -> libhdf5.so.7.0.0 >>> /usr/lib/x86_64-linux-gnu/libhdf5.so.7 -> libhdf5.so.7.0.0 >>> /usr/lib/x86_64-linux-gnu/libhdf5.so.7.0.0 >>> ``` >>> resulting in the dynamic dependency >>> ``` >>> $ ldd mylib.so.1.0.0 | grep hdf5 >>> libhdf5.so.7 => /usr/lib/x86_64-linux-gnu/libhdf5.so.7 >>> (0x00007f50179e2000) >>> ``` >>> The export file `mylibTargets.cmake` however lists >>> ``` >>> set_target_properties(mylib PROPERTIES >>> INTERFACE_INCLUDE_DIRECTORIES "${_IMPORT_PREFIX}/include" >>> INTERFACE_LINK_LIBRARIES "/usr/lib/x86_64-linux-gnu/libhdf5.so" >>> ) >>> ``` >>> (without the so-version). This is not good since this symlink might >>> not be present when I configure a project against mylib. And it >>> doesn't have to be either: >> >> >> Actually it does have to be there (or rather it will be there). >> >>> >>> > All I need is >>> `/usr/lib/x86_64-linux-gnu/libhdf5.so.7` as specified by `ldd`. >> >> >> No, what you also need are the headers of that library, i.e. the >> 'development' part of the library installation. Since those development >> parts are usually mutually exclusively installable between different >> versions there's going to be only 1 installed. So the .so symlink will be >> there and hence the linking will work. If the symlink links to a different >> so-version the linker will abort when trying to link against mylib. >> >> The only exception would be if your mylib does not expose any of the API >> that hdf5 provides and a user of mylib does not need to know or care that >> you're using hdf5. In that case you should drop that library from your >> public link interface. That'll automatically drop the imported target in the >> export file, as the linker does not need to know what mylib links against >> when linking an app against mylib. (at least for shared libraries). >> >> Andreas From phil at voltage.com Sat Aug 23 13:17:31 2014 From: phil at voltage.com (Phil Smith) Date: Sat, 23 Aug 2014 10:17:31 -0700 Subject: [CMake] Dependency weirdness Message-ID: <84BCCD71182F0046BCD2FB054FE52379112D524822@HQMAILSVR02.voltage.com> A while ago, folks on this list kindly helped me through adding dependency checking for assembler macros with the cross-compiler we use (summary: if module foo.asm uses macro bar.mac, we wanted foo.asm picked up by CMake if bar.mac changed). I recently realized this was no longer working. I had the old version's source path, and verified that it still worked there, and then that the CMakeLists had not changed in any substantive way. Some more tinkering led me to try a "This can't possible matter/work" scenario: The old, working path was named C:\SVN\zFPE4.3.0 The new, broken path was named C:\SVN\zFPE510 I did various renames (4.3.0==>430 and 510==>5.1.0), clean builds,.mac changes, and CMAKEs. The results: - If the periods are in the filename, the dependency checking works - If no period, it doesn't work But the dependency code in CMakeLists is: foreach(entry ${ZPROTECT_ASM_DEPENDENCIES}) # Convert each entry into a new list string(REPLACE "," ";" entry ${entry}) # Get the source filename from the list list(GET entry 0 file) # And remove it so we can now traverse the list list(REMOVE_AT entry 0) # Now traverse the list and set each dependency foreach(temp ${entry}) # Note hard-coded path; MUST be full path, cannot be relative (CMake restriction) set_property(SOURCE ${CMAKE_CURRENT_SOURCE_DIR}/src/zprotect/asm/${file} APPEND PROPERTY OBJECT_DEPENDS ${CMAKE_CURRENT_SOURCE_DIR}/src/zprotect/asm/${temp}) endforeach(temp ${entry}) endforeach(entry ${ZPROTECT_ASM_DEPENDENCIES} I see no periods here...I see commas, but no periods. And I'd've expected it to be more likely that the presence of periods would upset it than their absence! I added a diagnostic MESSAGE in the code and reran it. Good: -- set_property(SOURCE C:/SVN/zFPE5.1.0/src/zprotect/asm/VSHVOLT.asm APPEND PROPERTY OBJECT_DEPENDS C:/SVN/zFPE5.1.0/src/zprotect/asm/VSHVOLTX.mac) Bad: -- set_property(SOURCE C:/SVN/zFPE510/src/zprotect/asm/VSHVOLT.asm APPEND PROPERTY OBJECT_DEPENDS C:/SVN/zFPE510/src/zprotect/asm/VSHVOLTX.mac) Those are identical other than the periods in the directory name, as expected! Any ideas? cmake --version says: cmake version 2.8.1 I know this is old but there are reasons. In any case, seems like an odd bug. Is the period perhaps some regex confusion kicking in? -------------- next part -------------- An HTML attachment was scrubbed... URL: From christer.solskogen at gmail.com Sun Aug 24 13:40:09 2014 From: christer.solskogen at gmail.com (Christer Solskogen) Date: Sun, 24 Aug 2014 19:40:09 +0200 Subject: [CMake] Find SDL Message-ID: Hi! I have a cross compiler, installed into /opt/cross, which is compiled by me. This cross compiler (gcc) is sysroot aware, which means that every header and library is installed into /opt/cross/. In order to get cmake to find SDL (both SDL1 and SDL2) I need to specify SDLDIR. The project I'm using (called hatari, a Atari ST(e) emulator) is also using other libraries like readline and png, which cmake have no problem finding. Is this a bug in cmake? Right now the cmake version I'm using is 2.8.12.2, but this problem have been there since I can remember. -- chs From david at zemon.name Sun Aug 24 14:56:49 2014 From: david at zemon.name (David Zemon) Date: Sun, 24 Aug 2014 13:56:49 -0500 Subject: [CMake] Unhelpful cmListFileCache error Message-ID: <53FA3571.6050508@zemon.name> Hello all, This problem does not exist in Linux - I have perfect compilation there. Windows, however, is throwing the following error: CMake Error: cmListFileCache: error can not open file C:/Users/David/Documents/GitHub/PropWare CMake Error: Could not find cmake module file: The "can not open file" points to the root directory of my project. The error is somehow connected to enabling new languages. I get the above two lines once for each new language that I try to add. The line enabling the project is as follows: project(PropWare C CXX ASM COGC COGCXX ECOGC ECOGCXX) My language files are in /CMakeModules and I tell CMake to find there with the following: list(APPEND CMAKE_MODULE_PATH ${PROPWARE_PATH}/CMakeModules) Like I said - this all works great in Linux. Not so much in Windows though :( Full source code at https://github.com/SwimDude0614/PropWare/tree/release-2.0-nightly. Easiest way to test this for yourself is to run INSTALL.py from the util directory - it will install necessary dependencies (the compiler and CMake 3 if not in the PATH already). Thanks, David -------------- next part -------------- An HTML attachment was scrubbed... URL: From ravi.raman at Xoriant.Com Mon Aug 25 01:36:34 2014 From: ravi.raman at Xoriant.Com (Ravi Raman) Date: Mon, 25 Aug 2014 05:36:34 +0000 Subject: [CMake] File concatenation in cmake add_custom_command() Message-ID: Hi David, We have a query regarding file concatenation in cmake First the details of what we have done: Input Files: main.h, main.c Copy Right file: copyright.txt Output Files: mainWithCopyRight.c, mainWithCopyRight.h Please find attached herewith a zip file containing the logic that we have used in cmake to perform file concatenation. It works successfully. The requirement is that we have to do this in the cmake function add_custom_command() We have done this as follows: 1. There is one CMakeLists.txt file for the source file main.cpp and header file main.h 2. Functions.cmake containing the function ac_prepend_copyright() which has the file concatenation logic 3. In the user-defined function ac_prepend_copyright(): 1. First created a temporary fileconcat.cmake file which has the required FILE operations logic 2. In the add_custom_command() function call used the -D and -P options accordingly. 4. Invoked the function ac_prepend_copyright() from CMakeLists.txt Note that the files mainWithCopyRight.c, mainWithCopyRight.h contain the contents of copyright.txt at the beginning followed by the source contents. So, this works fine. Query: Is there a simpler way of performing file concatenation in cmake? Thanks & Regards Ravi Raman Xoriant Solutions Pvt. Ltd 4th Floor, Winchester, Hiranandani Business Park, Powai, Mumbai 400076, INDIA. Tel: +91 22 30511000,9930100026 Extn: 2144 Voip No. 4088344495/96/97/98 Voip Extn:1178| Fax: +91 22 30511111 ravi.raman at xoriant.com| http://www.xoriant.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: FileConcat.zip Type: application/x-zip-compressed Size: 1693 bytes Desc: FileConcat.zip URL: From braden at endoframe.com Mon Aug 25 01:53:00 2014 From: braden at endoframe.com (Braden McDaniel) Date: Mon, 25 Aug 2014 01:53:00 -0400 Subject: [CMake] add_custom_command and CONFIG-dependent output In-Reply-To: <8D18C62EA93BA62-1814-196F8@webmail-va051.sysops.aol.com> References: <8D18C62EA93BA62-1814-196F8@webmail-va051.sysops.aol.com> Message-ID: <1408945980.5591.7.camel@hinge.endoframe.net> On Fri, 2014-08-22 at 16:58 -0400, David Cole via CMake wrote: > Use "${CMAKE_CFG_INTDIR}" in the context of add_custom_command OUTPUT, > not $. > > You may also use that in the COMMAND arguments. > > See documentation here: > http://www.cmake.org/cmake/help/v3.0/variable/CMAKE_CFG_INTDIR.html > > The $<> generator expressions are relatively new, and do not work in > all contexts that you might expect yet. CMAKE_CFG_INTDIR has been > around for quite some time, though, and works very well with custom > commands. Ah, thanks... Though, I think there may be a general disconnect here: that is, it seems likely that one would want to construct output with a pattern composed from generator expressions. For instance, in a subsequent rule I attempted to do this: set(LIB "$") set(STAGED_LIB "${LIB_STAGEDIR}/$") add_custom_command( OUTPUT ${STAGED_LIB} COMMAND ${CMAKE_COMMAND} -E copy ${LIB} ${STAGED_LIB} MAIN_DEPENDENCY ${LIB_STAGEDIR} ) ... which obviously has the same problem. While I gather from your comment that something like this might be possible in the future, is there some other general approach that can be taken with current CMake? Braden From michael.nikonov at mail.ru Mon Aug 25 06:36:21 2014 From: michael.nikonov at mail.ru (=?UTF-8?B?0J3QuNC60L7QvdC+0LIg0JzQuNGF0LDQuNC7INCd0LjQutC+0LvQsNC10LLQuNGH?=) Date: Mon, 25 Aug 2014 14:36:21 +0400 Subject: [CMake] Platform information override file is ignored for ASM language Message-ID: Hello, In a bare-metal embedded project, I need to initialize compiler flags to custom values while toolchains are initialized; for that, I'm using override files to set _INIT variables. From what I've encountered, it appears that CMAKE_USER_MAKE_RULES_OVERRIDE file (and language-specific *_ASM one) are not loaded during initialization of assembly compiler. Here's a test to reproduce it, made of two files: CMakeLists.txt: set(CMAKE_USER_MAKE_RULES_OVERRIDE override.cmake) project(Test C CXX ASM) override.cmake: set(CMAKE_C_FLAGS_INIT "-Wall") set(CMAKE_CXX_FLAGS_INIT "-Wall") set(CMAKE_ASM_FLAGS_INIT "-Wall") After running cmake, CMAKE_C_FLAGS and CMAKE_CXX_FLAGS in CMakeCache.txt contain flag -Wall, while CMAKE_ASM_FLAGS doesn't (tested with CMake 2.8.12.2 and 3.0.1 and gcc 4.8.2 on latest Ubuntu). Is there any mistake I made? And if not, is there any elegant workaround for that? I'm aware that I can just force flags' values into cache in toolchain file itself, before project() call, but from what I understood, it's a discouraged practice. Regards, Mikhail. From dlrdave at aol.com Mon Aug 25 07:07:41 2014 From: dlrdave at aol.com (David Cole) Date: Mon, 25 Aug 2014 07:07:41 -0400 (EDT) Subject: [CMake] add_custom_command and CONFIG-dependent output Message-ID: <8D18E6BEC2219DD-2E5C-2B308@webmail-va015.sysops.aol.com> > Ah, thanks... Though, I think there may be a general disconnect here: > that is, it seems likely that one would want to construct output with > a pattern composed from generator expressions. > ... > While I gather from your comment that something like this might be > possible in the future, is there some other general approach that can > be taken with current CMake? The "disconnect" is that generator expressions were bolted on top of existing CMake functionality, and are not fully supported in all contexts. The documentation for add_custom_command [1] explicitly says "Arguments to COMMAND may use ?generator expressions?" -- but it says nothing about OUTPUT using them at all. I don't know if there's a strong reason behind not supporting them in the OUTPUT clause... but I suspect if it was easy, it would have been done already. For now, any OUTPUT you need to specify will have to be done without the use of generator expressions. In some cases, that means you need to know what the behavior of CMake is (like the library file name in your example), and duplicate it if you need it in the OUTPUT clause. So, no: no general approach that I know of, but you can use CMAKE_CFG_INTDIR as needed to separate the output of different config builds... (If I'm wrong here, I do hope somebody else more intimately involved with generator expressions will chime in and correct me.) HTH, David C. [1] http://www.cmake.org/cmake/help/v3.0/command/add_custom_command.html From petr.kmoch at gmail.com Mon Aug 25 07:27:21 2014 From: petr.kmoch at gmail.com (Petr Kmoch) Date: Mon, 25 Aug 2014 13:27:21 +0200 Subject: [CMake] add_custom_command and CONFIG-dependent output In-Reply-To: <8D18E6BEC2219DD-2E5C-2B308@webmail-va015.sysops.aol.com> References: <8D18E6BEC2219DD-2E5C-2B308@webmail-va015.sysops.aol.com> Message-ID: On Mon, Aug 25, 2014 at 1:07 PM, David Cole via CMake wrote: > > Ah, thanks... Though, I think there may be a general disconnect here: > > that is, it seems likely that one would want to construct output with > > a pattern composed from generator expressions. > > ... > > While I gather from your comment that something like this might be > > possible in the future, is there some other general approach that can > > be taken with current CMake? > > > The "disconnect" is that generator expressions were bolted on top of > existing CMake functionality, and are not fully supported in all > contexts. The documentation for add_custom_command [1] explicitly says > "Arguments to COMMAND may use ?generator expressions?" -- but it says > nothing about OUTPUT using them at all. > > I don't know if there's a strong reason behind not supporting them in > the OUTPUT clause... but I suspect if it was easy, it would have been > done already. > Brad suggests it's far from easy in this bug comment: http://public.kitware.com/Bug/view.php?id=12877#c28315 > > For now, any OUTPUT you need to specify will have to be done without > the use of generator expressions. In some cases, that means you need to > know what the behavior of CMake is (like the library file name in your > example), and duplicate it if you need it in the OUTPUT clause. So, no: > no general approach that I know of, but you can use CMAKE_CFG_INTDIR as > needed to separate the output of different config builds... > > (If I'm wrong here, I do hope somebody else more intimately involved > with generator expressions will chime in and correct me.) > > > HTH, > David C. > > > [1] http://www.cmake.org/cmake/help/v3.0/command/add_custom_command.html > Petr -------------- next part -------------- An HTML attachment was scrubbed... URL: From dlrdave at aol.com Mon Aug 25 07:29:01 2014 From: dlrdave at aol.com (David Cole) Date: Mon, 25 Aug 2014 07:29:01 -0400 (EDT) Subject: [CMake] File concatenation in cmake add_custom_command() In-Reply-To: References: Message-ID: <8D18E6EE7158FE1-2E5C-2B3FF@webmail-va015.sysops.aol.com> First: thanks for your questions to the CMake list. However, when you send an email to the list, please just ask the question -- that is, please do *not* ask me by name. I know I've answered a few questions for you in the last few weeks, but I am not the only one here, and asking me by name may discourage somebody else from answering earlier if they are able to. The list is a community resource, and all should feel welcome to chime in on any discussion where they can add something useful. I think using "file(WRITE..." followed by "file(APPEND..." is the simplest way of performing file concatenation using the CMake language. However, I would never write a custom command rule that writes files into the source tree of a project. For one thing, it precludes having two separate build trees for a single source tree that do not clobber each other - the build trees should be independent of each other... but when you push output to the source tree, multiple builds can never be independent of each other. It might be simpler or more elegant to use a different language (python, perl, ?) for this task, but if you must do it in CMake, what you have is just fine. I'm certain you could make the code easier to understand by naming variables more descriptively (FILE1, FILE2, FILE3, ... are not very descriptive) and by adding some comments. Also, there's no reason to file(WRITE the script itself in your example: the script could simply be written, and be a part of your source code, and then just called from the custom command. That would remove a leap of indirection that a developer reading the code has to make mentally to understand what you've got. If the script file is just a script file, and they can look at it as such, then the add_custom_command becomes easier to read, because it doesn't have the crazy file(WRITE with backslashes in it to interpret. HTH, David C. From ravi.raman at Xoriant.Com Mon Aug 25 07:35:57 2014 From: ravi.raman at Xoriant.Com (Ravi Raman) Date: Mon, 25 Aug 2014 11:35:57 +0000 Subject: [CMake] File concatenation in cmake add_custom_command() In-Reply-To: <8D18E6EE7158FE1-2E5C-2B3FF@webmail-va015.sysops.aol.com> References: <8D18E6EE7158FE1-2E5C-2B3FF@webmail-va015.sysops.aol.com> Message-ID: <34e98ac4ecea48abb651497dbfcbdce8@XORMUM-MBX01.India.XoriantCorp.com> Thanks for the reply. Thanks & Regards Ravi Raman Xoriant Solutions Pvt. Ltd 4th Floor, Winchester,?Hiranandani Business Park, Powai,?Mumbai 400076, INDIA. Tel: +91 22 30511000,9930100026 Extn: 2144 Voip No. 4088344495/96/97/98 Voip Extn:1178| Fax: +91 22 30511111 ravi.raman at xoriant.com|?http://www.xoriant.com -----Original Message----- From: David Cole [mailto:dlrdave at aol.com] Sent: Monday, August 25, 2014 4:59 PM To: Ravi Raman Cc: cmake at cmake.org Subject: Re: File concatenation in cmake add_custom_command() First: thanks for your questions to the CMake list. However, when you send an email to the list, please just ask the question -- that is, please do *not* ask me by name. I know I've answered a few questions for you in the last few weeks, but I am not the only one here, and asking me by name may discourage somebody else from answering earlier if they are able to. The list is a community resource, and all should feel welcome to chime in on any discussion where they can add something useful. I think using "file(WRITE..." followed by "file(APPEND..." is the simplest way of performing file concatenation using the CMake language. However, I would never write a custom command rule that writes files into the source tree of a project. For one thing, it precludes having two separate build trees for a single source tree that do not clobber each other - the build trees should be independent of each other... but when you push output to the source tree, multiple builds can never be independent of each other. It might be simpler or more elegant to use a different language (python, perl, ?) for this task, but if you must do it in CMake, what you have is just fine. I'm certain you could make the code easier to understand by naming variables more descriptively (FILE1, FILE2, FILE3, ... are not very descriptive) and by adding some comments. Also, there's no reason to file(WRITE the script itself in your example: the script could simply be written, and be a part of your source code, and then just called from the custom command. That would remove a leap of indirection that a developer reading the code has to make mentally to understand what you've got. If the script file is just a script file, and they can look at it as such, then the add_custom_command becomes easier to read, because it doesn't have the crazy file(WRITE with backslashes in it to interpret. HTH, David C. From cmake at eikel.org Mon Aug 25 08:34:14 2014 From: cmake at eikel.org (Benjamin Eikel) Date: Mon, 25 Aug 2014 12:34:14 +0000 Subject: [CMake] Find SDL In-Reply-To: References: Message-ID: <20140825123414.Horde.q_tU-hQN77HTEmcZoU8_Bw5@webmail.eikel.org> Hello Christer, Zitat von Christer Solskogen : > Hi! > > I have a cross compiler, installed into /opt/cross, which is > compiled by me. This cross compiler (gcc) is sysroot aware, which > means that every header and library is installed into > /opt/cross/. > > In order to get cmake to find SDL (both SDL1 and SDL2) I need to > specify SDLDIR. The project I'm using (called hatari, a Atari ST(e) > emulator) is also using other libraries like readline and png, which > cmake have no problem finding. > > Is this a bug in cmake? Right now the cmake version I'm using is > 2.8.12.2, but this problem have been there since I can remember. in order to help you, I need more information. If I understand you correctly, you do not want to set the environment variable SDLDIR. Instead, you expect the FindSDL module to find SDL without that information. Is that correct? Please give some more information about your installation. In which path exactly is SDL located (where is "SDL.h", where is "libSDL.a" or "libSDL.so")? Kind regards Benjamin From mike.jackson at bluequartz.net Mon Aug 25 13:10:27 2014 From: mike.jackson at bluequartz.net (Michael Jackson) Date: Mon, 25 Aug 2014 13:10:27 -0400 Subject: [CMake] Setting additional Plist values for OS X Bundle Message-ID: <9E659DA1-667F-4FB0-B7EE-D388AC42417E@bluequartz.net> Are there are newer facilities in CMake 3.x that would allow me to add additional Plist values to the standard Mac OS X bundle plist that gets created? I use the following code currently: set_target_properties(${TARGET_NAME} PROPERTIES MACOSX_BUNDLE_INFO_STRING "${PROJECT_NAME}${DBG_EXTENSION} Version ${VERSION_STRING}, Copyright 2014 BlueQuartz Software." MACOSX_BUNDLE_ICON_FILE ${ICON_FILE_NAME} MACOSX_BUNDLE_GUI_IDENTIFIER "${PROJECT_NAME}${DBG_EXTENSION}" MACOSX_BUNDLE_LONG_VERSION_STRING "${PROJECT_NAME}${DBG_EXTENSION} Version ${VERSION_STRING}" MACOSX_BUNDLE_BUNDLE_NAME ${PROJECT_NAME}${DBG_EXTENSION} MACOSX_BUNDLE_SHORT_VERSION_STRING ${VERSION_STRING} MACOSX_BUNDLE_BUNDLE_VERSION ${VERSION_STRING} MACOSX_BUNDLE_COPYRIGHT "Copyright 2014, BlueQuartz Software. All Rights Reserved." ) But I need to add the following to my plist: NSHighResolutionCapable True Thanks for any help -- Mike Jackson www.bluequartz.net From clinton at elemtech.com Mon Aug 25 13:48:37 2014 From: clinton at elemtech.com (Clinton Stimpson) Date: Mon, 25 Aug 2014 11:48:37 -0600 Subject: [CMake] Setting additional Plist values for OS X Bundle In-Reply-To: <9E659DA1-667F-4FB0-B7EE-D388AC42417E@bluequartz.net> References: <9E659DA1-667F-4FB0-B7EE-D388AC42417E@bluequartz.net> Message-ID: <6604415.VH6vhQAsli@stryke> On Monday, August 25, 2014 01:10:27 PM Michael Jackson wrote: > Are there are newer facilities in CMake 3.x that would allow me to add > additional Plist values to the standard Mac OS X bundle plist that gets > created? > > I use the following code currently: > > set_target_properties(${TARGET_NAME} PROPERTIES > MACOSX_BUNDLE_INFO_STRING "${PROJECT_NAME}${DBG_EXTENSION} Version > ${VERSION_STRING}, Copyright 2014 BlueQuartz Software." > MACOSX_BUNDLE_ICON_FILE ${ICON_FILE_NAME} > MACOSX_BUNDLE_GUI_IDENTIFIER "${PROJECT_NAME}${DBG_EXTENSION}" > MACOSX_BUNDLE_LONG_VERSION_STRING "${PROJECT_NAME}${DBG_EXTENSION} > Version ${VERSION_STRING}" MACOSX_BUNDLE_BUNDLE_NAME > ${PROJECT_NAME}${DBG_EXTENSION} > MACOSX_BUNDLE_SHORT_VERSION_STRING ${VERSION_STRING} > MACOSX_BUNDLE_BUNDLE_VERSION ${VERSION_STRING} > MACOSX_BUNDLE_COPYRIGHT "Copyright 2014, BlueQuartz Software. All > Rights Reserved." ) > > > But I need to add the following to my plist: > > NSHighResolutionCapable > True > > > Thanks for any help > -- > Mike Jackson www.bluequartz.net Even with CMake 2.x, you can make your own .plist.in copied from CMake/Modules/MacOSXBundleInfo.plist.in, then add your part in there. NSHighResolutionCapable True Then add one more line to your set of target properties: MACOSX_BUNDLE_INFO_PLIST "${CMAKE_CURRENT_SOURCE_DIR}/MacOSXBundleInfo.plist.in" - Clint From clinton at elemtech.com Mon Aug 25 13:48:37 2014 From: clinton at elemtech.com (Clinton Stimpson) Date: Mon, 25 Aug 2014 11:48:37 -0600 Subject: [CMake] Setting additional Plist values for OS X Bundle In-Reply-To: <9E659DA1-667F-4FB0-B7EE-D388AC42417E@bluequartz.net> References: <9E659DA1-667F-4FB0-B7EE-D388AC42417E@bluequartz.net> Message-ID: <6604415.VH6vhQAsli@stryke> On Monday, August 25, 2014 01:10:27 PM Michael Jackson wrote: > Are there are newer facilities in CMake 3.x that would allow me to add > additional Plist values to the standard Mac OS X bundle plist that gets > created? > > I use the following code currently: > > set_target_properties(${TARGET_NAME} PROPERTIES > MACOSX_BUNDLE_INFO_STRING "${PROJECT_NAME}${DBG_EXTENSION} Version > ${VERSION_STRING}, Copyright 2014 BlueQuartz Software." > MACOSX_BUNDLE_ICON_FILE ${ICON_FILE_NAME} > MACOSX_BUNDLE_GUI_IDENTIFIER "${PROJECT_NAME}${DBG_EXTENSION}" > MACOSX_BUNDLE_LONG_VERSION_STRING "${PROJECT_NAME}${DBG_EXTENSION} > Version ${VERSION_STRING}" MACOSX_BUNDLE_BUNDLE_NAME > ${PROJECT_NAME}${DBG_EXTENSION} > MACOSX_BUNDLE_SHORT_VERSION_STRING ${VERSION_STRING} > MACOSX_BUNDLE_BUNDLE_VERSION ${VERSION_STRING} > MACOSX_BUNDLE_COPYRIGHT "Copyright 2014, BlueQuartz Software. All > Rights Reserved." ) > > > But I need to add the following to my plist: > > NSHighResolutionCapable > True > > > Thanks for any help > -- > Mike Jackson www.bluequartz.net Even with CMake 2.x, you can make your own .plist.in copied from CMake/Modules/MacOSXBundleInfo.plist.in, then add your part in there. NSHighResolutionCapable True Then add one more line to your set of target properties: MACOSX_BUNDLE_INFO_PLIST "${CMAKE_CURRENT_SOURCE_DIR}/MacOSXBundleInfo.plist.in" - Clint From dank at kegel.com Mon Aug 25 13:59:10 2014 From: dank at kegel.com (Dan Kegel) Date: Mon, 25 Aug 2014 10:59:10 -0700 Subject: [CMake] Can't run cmd.exe directly in ctest? Message-ID: Hi! The simple CMakeLists.txt cmake_minimum_required(VERSION 2.8) project(foo) enable_testing() add_test(NAME bar COMMAND cmd /c echo hello) fails for me when run on Windows 7 64 bit (only platform I've tried) with ctest 2.8.12 or 2.8.11. "ctest -V -C Debug" outputs ... test 1 Start 1: bar 1: Test command: C:\Windows\System32\cmd.exe "/c" "echo" "hello" 1: Test timeout computed to be: 9.99988e+006 1: The syntax of the command is incorrect. 1/1 Test #1: bar ..............................***Failed 0.07 sec Watching with ProcessMonitor, the only funky business I can see is that ctest uses forward slashes in the path it passes to CreateProcess. Trying this with a little C program shows that, yes, cmd.exe outputs "The syntax of the command is incorrect" if run with CreateProcess( NULL, "c:/windows/system32/cmd.exe /c echo hi", ...) but executes properly if run with CreateProcess( NULL, "c:\\windows\\system32\\cmd.exe /c echo hi", ...) The obvious workaround is... just use a bat file without mentioning cmd at all: cmake_minimum_required(VERSION 2.8) project(foo) enable_testing() add_test(NAME bar COMMAND foobar.bat) If you forget to do chmod +x foobar.bat first, it'll fail with "***Not Run". The only reason I'm posting this is because I forgot to do the chmod +x, and tried using cmd directly without a batch file as a minimal test case. Bit of a detour :-) - Dan From a.neundorf-work at gmx.net Mon Aug 25 16:27:20 2014 From: a.neundorf-work at gmx.net (Alexander Neundorf) Date: Mon, 25 Aug 2014 22:27:20 +0200 Subject: [CMake] Platform information override file is ignored for ASM language In-Reply-To: References: Message-ID: <2344618.LIvh6tEHHW@tuxedo.neundorf.net> On Monday, August 25, 2014 14:36:21 ??????? ?????? ?????????? wrote: > Hello, > > In a bare-metal embedded project, I need to initialize compiler flags > to custom values while toolchains are initialized; for that, I'm using > override files to set _INIT variables. From what I've encountered, it > appears that CMAKE_USER_MAKE_RULES_OVERRIDE file (and > language-specific *_ASM one) are not loaded during initialization of > assembly compiler. Here's a test to reproduce it, made of two files: > > CMakeLists.txt: > set(CMAKE_USER_MAKE_RULES_OVERRIDE override.cmake) > project(Test C CXX ASM) > > override.cmake: > set(CMAKE_C_FLAGS_INIT "-Wall") > set(CMAKE_CXX_FLAGS_INIT "-Wall") > set(CMAKE_ASM_FLAGS_INIT "-Wall") > > After running cmake, CMAKE_C_FLAGS and CMAKE_CXX_FLAGS in > CMakeCache.txt contain flag -Wall, while CMAKE_ASM_FLAGS doesn't > (tested with CMake 2.8.12.2 and 3.0.1 and gcc 4.8.2 on latest Ubuntu). > > Is there any mistake I made? And if not, is there any elegant > workaround for that? I'm aware that I can just force flags' values > into cache in toolchain file itself, before project() call, but from > what I understood, it's a discouraged practice. please enter a bug report at http://public.kitware.com/Bug Thanks Alex From hobbes1069 at gmail.com Mon Aug 25 17:02:38 2014 From: hobbes1069 at gmail.com (Richard Shaw) Date: Mon, 25 Aug 2014 16:02:38 -0500 Subject: [CMake] Collecting libraries for NSIS installer In-Reply-To: References: <8D18AA454A8BB38-1DCC-991C@webmail-d163.sysops.aol.com> Message-ID: Ok, apparently I'm the only person that can't figure out how generator expressions work but I worked around it using "find_program" to find the resultant executable in the source directory, which I think is a really bad way to do it, but it works. Then I use find_library to get the full path of the library because get_filename_component isn't working for me. Thanks, Richard -------------- next part -------------- An HTML attachment was scrubbed... URL: From david at zemon.name Mon Aug 25 17:19:15 2014 From: david at zemon.name (david at zemon.name) Date: Mon, 25 Aug 2014 16:19:15 -0500 (CDT) Subject: [CMake] Unhelpful cmListFileCache error Message-ID: <1409001555.191414004@webmail.emailpower.biz> I am at a complete loss on what to look for here. This error started when I tried adding "list(append ....)" instead of copying the language files to the CMake installation directory. If anyone has any idea where to look, I'm all ears. I think 95% of my users will be on Windows, so I can't launch until I get past this bug. Cheers, David -----Original Message----- From: "David Zemon" Sent: Sunday, August 24, 2014 1:56pm To: cmake at cmake.org Subject: [CMake] Unhelpful cmListFileCache error Hello all, This problem does not exist in Linux - I have perfect compilation there. Windows, however, is throwing the following error: CMake Error: cmListFileCache: error can not open file C:/Users/David/Documents/GitHub/PropWare CMake Error: Could not find cmake module file:The "can not open file" points to the root directory of my project. The error is somehow connected to enabling new languages. I get the above two lines once for each new language that I try to add. The line enabling the project is as follows: project(PropWare C CXX ASM COGC COGCXX ECOGC ECOGCXX)My language files are in /CMakeModules and I tell CMake to find there with the following: list(APPEND CMAKE_MODULE_PATH ${PROPWARE_PATH}/CMakeModules)Like I said - this all works great in Linux. Not so much in Windows though :( Full source code at [ https://github.com/SwimDude0614/PropWare/tree/release-2.0-nightly ]( https://github.com/SwimDude0614/PropWare/tree/release-2.0-nightly ). Easiest way to test this for yourself is to run INSTALL.py from the util directory - it will install necessary dependencies (the compiler and CMake 3 if not in the PATH already). Thanks, David -------------- next part -------------- An HTML attachment was scrubbed... URL: From jchris.fillionr at kitware.com Mon Aug 25 17:10:45 2014 From: jchris.fillionr at kitware.com (Jean-Christophe Fillion-Robin) Date: Mon, 25 Aug 2014 17:10:45 -0400 Subject: [CMake] Collecting libraries for NSIS installer In-Reply-To: References: <8D18AA454A8BB38-1DCC-991C@webmail-d163.sysops.aol.com> Message-ID: Hi Richard, Generator expression won't work in install rules. Instead, I suggest you simply use "install(TARGET ...") for regular targets. Hth Jc On Mon, Aug 25, 2014 at 5:02 PM, Richard Shaw wrote: > Ok, apparently I'm the only person that can't figure out how generator > expressions work but I worked around it using "find_program" to find the > resultant executable in the source directory, which I think is a really bad > way to do it, but it works. > > Then I use find_library to get the full path of the library because > get_filename_component isn't working for me. > > Thanks, > Richard > > -- > > 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 > -- +1 919 869 8849 -------------- next part -------------- An HTML attachment was scrubbed... URL: From hobbes1069 at gmail.com Mon Aug 25 17:43:38 2014 From: hobbes1069 at gmail.com (Richard Shaw) Date: Mon, 25 Aug 2014 16:43:38 -0500 Subject: [CMake] Collecting libraries for NSIS installer In-Reply-To: References: <8D18AA454A8BB38-1DCC-991C@webmail-d163.sysops.aol.com> Message-ID: On Mon, Aug 25, 2014 at 4:10 PM, Jean-Christophe Fillion-Robin < jchris.fillionr at kitware.com> wrote: > Hi Richard, > > Generator expression won't work in install rules. Instead, I suggest you > simply use "install(TARGET ...") for regular targets. > That explains that problem. I'm not sure if you followed the whole thread but what I'm trying to do is collect all the dependent DLL's for packaging into the NSIS installer. I don't think install(TARGET... will work here. I'm using the GetPrerequisites module which needs the absolute path to the binary/library to scan. I tried to use get_target_property but it complained that generator expressions should be used instead, which as you mention don't work for install rules. I use find_program to get the full location to the generated binary which I then pass to get_prerequisites(...) to get the required dll's. Then I used find_library to get the location to the library for installation purposes (win32 only). Thanks, Richard -------------- next part -------------- An HTML attachment was scrubbed... URL: From phil at voltage.com Mon Aug 25 18:38:38 2014 From: phil at voltage.com (Phil Smith) Date: Mon, 25 Aug 2014 15:38:38 -0700 Subject: [CMake] Dependency weirdness Message-ID: <84BCCD71182F0046BCD2FB054FE52379112D524998@HQMAILSVR02.voltage.com> A colleague figured it out. We had: ${CMAKE_CURRENT_SOURCE_DIR}/src/zprotect But the actual directory name is zProtect, capital P. Windows "doesn't care", sorta kinda, but apparently CMake or Cygwin or Windows does somehow. If the directory has a period in the name, it works; if it doesn't, it fails. After 40+ years of software I should know better than to be surprised by anything, but I still am... ...phsiii From: Phil Smith Sent: Saturday, August 23, 2014 1:18 PM To: cmake at cmake.org Cc: zTeam Subject: Dependency weirdness A while ago, folks on this list kindly helped me through adding dependency checking for assembler macros with the cross-compiler we use (summary: if module foo.asm uses macro bar.mac, we wanted foo.asm picked up by CMake if bar.mac changed). I recently realized this was no longer working. I had the old version's source path, and verified that it still worked there, and then that the CMakeLists had not changed in any substantive way. Some more tinkering led me to try a "This can't possible matter/work" scenario: The old, working path was named C:\SVN\zFPE4.3.0 The new, broken path was named C:\SVN\zFPE510 I did various renames (4.3.0==>430 and 510==>5.1.0), clean builds,.mac changes, and CMAKEs. The results: - If the periods are in the filename, the dependency checking works - If no period, it doesn't work But the dependency code in CMakeLists is: foreach(entry ${ZPROTECT_ASM_DEPENDENCIES}) # Convert each entry into a new list string(REPLACE "," ";" entry ${entry}) # Get the source filename from the list list(GET entry 0 file) # And remove it so we can now traverse the list list(REMOVE_AT entry 0) # Now traverse the list and set each dependency foreach(temp ${entry}) # Note hard-coded path; MUST be full path, cannot be relative (CMake restriction) set_property(SOURCE ${CMAKE_CURRENT_SOURCE_DIR}/src/zprotect/asm/${file} APPEND PROPERTY OBJECT_DEPENDS ${CMAKE_CURRENT_SOURCE_DIR}/src/zprotect/asm/${temp}) endforeach(temp ${entry}) endforeach(entry ${ZPROTECT_ASM_DEPENDENCIES} I see no periods here...I see commas, but no periods. And I'd've expected it to be more likely that the presence of periods would upset it than their absence! I added a diagnostic MESSAGE in the code and reran it. Good: -- set_property(SOURCE C:/SVN/zFPE5.1.0/src/zprotect/asm/VSHVOLT.asm APPEND PROPERTY OBJECT_DEPENDS C:/SVN/zFPE5.1.0/src/zprotect/asm/VSHVOLTX.mac) Bad: -- set_property(SOURCE C:/SVN/zFPE510/src/zprotect/asm/VSHVOLT.asm APPEND PROPERTY OBJECT_DEPENDS C:/SVN/zFPE510/src/zprotect/asm/VSHVOLTX.mac) Those are identical other than the periods in the directory name, as expected! Any ideas? cmake --version says: cmake version 2.8.1 I know this is old but there are reasons. In any case, seems like an odd bug. Is the period perhaps some regex confusion kicking in? -------------- next part -------------- An HTML attachment was scrubbed... URL: From ravi.raman at Xoriant.Com Tue Aug 26 00:28:43 2014 From: ravi.raman at Xoriant.Com (Ravi Raman) Date: Tue, 26 Aug 2014 04:28:43 +0000 Subject: [CMake] Need to know the ASM flag that needs to be modified in cmake Message-ID: <183c6dfc322748efaba85a04c467875b@XORMUM-MBX01.India.XoriantCorp.com> Hi, In our cmake project, there is an assembler file (.asm extension) that needs to be compiled to create object file (.obj) using microsoft macro assembler (ml.exe for 32-bit and ml64.exe for 64-bit) This is happening successfully. But there is a preprocessor directive (_WIN64) as follows within the .asm code, which is not getting set. IFDEF _WIN64 We would like to know which is the ASM related cmake flag variable that needs to be manipulated in order to set _WIN64 Details as follows: 1. In CMakeLists.txt, we do the following to enable microsoft macro assembler to compile .asm files enable_language(ASM_MASM) 2. We include the .asm file Testx64.asm in the source list 3. Because of the above enable_language step, the MASM step gets correctly triggered as follows with the following ml64.exe options to compile the .asm to create corresponding .obj _MASM: Assembling ..\..\..\testx64\Testx64.asm... cmd.exe /C "C:\Users\raman_r\AppData\Local\Temp\tmp8a9b40c55523496e9edce668c1f812a2.cmd" ml64.exe /c /nologo /Zi /Fo"testx64.dir\Release\Testx64.obj" /W3 /errorReport:prompt /Ta..\..\..\testx64\Testx64.asm Note that in the above step 3, ml64.exe execution creates the output object file Testx64.obj, but in this there is no pre-processor switch /D _WIN64 Is there a way in cmake to manipulate any ASM related cmake flag, so that the above ml64.exe execution has /D _WIN64 option set ? Thanks & Regards Ravi Raman Xoriant Solutions Pvt. Ltd 4th Floor, Winchester, Hiranandani Business Park, Powai, Mumbai 400076, INDIA. Tel: +91 22 30511000,9930100026 Extn: 2144 Voip No. 4088344495/96/97/98 Voip Extn:1178| Fax: +91 22 30511111 ravi.raman at xoriant.com| http://www.xoriant.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From nico.schloemer at gmail.com Tue Aug 26 05:50:43 2014 From: nico.schloemer at gmail.com (=?UTF-8?Q?Nico_Schl=C3=B6mer?=) Date: Tue, 26 Aug 2014 11:50:43 +0200 Subject: [CMake] pipe add_test() output into a file Message-ID: Hi all, I would like to add a test for a file converter. The output of the converter is written out to stdout, and I would like to direct this into a file to compare it against a reference file. The signature of add_test() [1] however doesn't seem to allow that. How would you go about this problem? Cheers, Nico [1] http://www.cmake.org/cmake/help/v3.0/command/add_test.html From nilsgladitz at gmail.com Tue Aug 26 06:03:37 2014 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Tue, 26 Aug 2014 12:03:37 +0200 Subject: [CMake] pipe add_test() output into a file In-Reply-To: References: Message-ID: <53FC5B79.3020503@gmail.com> On 08/26/2014 11:50 AM, Nico Schl?mer wrote: > I would like to add a test for a file converter. The output of the > converter is written out to stdout, and I would like to direct this > into a file to compare it against a reference file. The signature of > add_test() [1] however doesn't seem to allow that. > > How would you go about this problem? You could run cmake in script mode (${CMAKE_COMMAND} -P) and have the script call your converter with execute_process(). You can pass the path to the converter with the $ generator expression and -D (-D options have to be listed before -P). Note that generator expressions in tests are only supported when the test is defined with the NAME/COMMAND signature of add_test(). execute_process() can capture the output of the command in a file or variable. The script could then also perform the comparison. You can make the script (and the test) fail with e.g. message(FATAL_ERROR "message") Nils From christer.solskogen at gmail.com Tue Aug 26 08:06:35 2014 From: christer.solskogen at gmail.com (Christer Solskogen) Date: Tue, 26 Aug 2014 12:06:35 +0000 (UTC) Subject: [CMake] Find SDL References: <20140825123414.Horde.q_tU-hQN77HTEmcZoU8_Bw5@webmail.eikel.org> Message-ID: Benjamin Eikel writes: > > Hello Christer, > > Zitat von Christer Solskogen : > > > Hi! > > > > I have a cross compiler, installed into /opt/cross, which is > > compiled by me. This cross compiler (gcc) is sysroot aware, which > > means that every header and library is installed into > > /opt/cross/?target>. > > > > In order to get cmake to find SDL (both SDL1 and SDL2) I need to > > specify SDLDIR. The project I'm using (called hatari, a Atari ST(e) > > emulator) is also using other libraries like readline and png, which > > cmake have no problem finding. > > > > Is this a bug in cmake? Right now the cmake version I'm using is > > 2.8.12.2, but this problem have been there since I can remember. > > in order to help you, I need more information. If I understand you > correctly, you do not want to set the environment variable SDLDIR. > Instead, you expect the FindSDL module to find SDL without that > information. Is that correct? Yes, that is correct. > Please give some more information about your installation. In which > path exactly is SDL located (where is "SDL.h", where is "libSDL.a" or > "libSDL.so")? > They are cross compiled for Windows (mingw-w64) which means that they have different names (libSDL.dll.a for instance) but they are installed in /opt/cross-mingw-w64/x86_64-w64-mingw32/{include,lib}. x86_64-w64-mingw32-gcc is using /home/solskogen/obj/cross-mingw-w64 as sysroot. cmake have no trouble finding png or zlib. -- Found ZLIB: /opt/cross-mingw-w64/x86_64-w64-mingw32/lib/libz.a (found version "1.2.8") -- Found PNG: /opt/cross-mingw-w64/x86_64-w64-mingw32/lib/libpng.a (found version "1.6.12") -- chs From ruslan_baratov at yahoo.com Tue Aug 26 08:26:21 2014 From: ruslan_baratov at yahoo.com (Ruslan Baratov) Date: Tue, 26 Aug 2014 16:26:21 +0400 Subject: [CMake] organizing export link libraries In-Reply-To: References: Message-ID: <53FC7CED.7090100@yahoo.com> On 21-Aug-14 00:50, Nico Schl?mer wrote: > Hi all, > > a general question: > I have a dependency chain of libraries > > A -> B -> C -> ... -> Z > > and all of those libraries are built with CMake, using CMake's export > functionality [1] to let the next in the chain know about its the > dependencies. > If all of the libraries are built statically and A needs some symbols > from a third-party library A1, this information needs to travel to Z. > Right now, in the export file I'm writing out the link line as > > set(a_EXTRA_LIBS -lhdf5 -lhdf5_hl -ldl -lm -lz -lcurl) You need to use find_package instead of raw `-l` option since `-l` will not work for windows. In this case it will looks something like this (e.g. curl): # CMakeLists.txt find_package(CURL REQUIRED) target_include_directories( PUBLIC ${CURL_INCLUDE_DIRS}) target_link_libraries( PUBLIC ${CURL_LIBRARIES}) See that library's paths are hard-coded in Targets*.cmake after exporting: set_target_properties( PROPERTIES INTERFACE_INCLUDE_DIRECTORIES "/usr/include" ) set_target_properties( PROPERTIES IMPORTED_LINK_INTERFACE_LIBRARIES_RELEASE "/usr/lib/x86_64-linux-gnu/libcurl.so" ) If it's not appropriate you can "find" it inside Config.cmake.in file: @PACKAGE_INIT@ find_package(CURL REQUIRED) include(".../Targets.cmake") # import target_include_directories( PUBLIC ${CURL_INCLUDE_DIRS}) # New curl location target_link_libraries( PUBLIC ${CURL_LIBRARIES}) but link type need to be PRIVATE: # CMakeLists.txt find_package(CURL REQUIRED) target_include_directories( PRIVATE ${CURL_INCLUDE_DIRS}) # Avoid publishing hard-coded location target_link_libraries( PRIVATE ${CURL_LIBRARIES}) It's simplier when third-party package is config mode friendly: # CMakeLists.txt find_package(SomePack CONFIG REQUIRED) target_link_libraries( PUBLIC SomePack::some_lib) # Config.cmake.in @PACKAGE_INIT@ find_package(SomePack CONFIG REQUIRED) # import SomePack::some_lib include(".../Targets.cmake") # link to SomePack::some_lib automatically # `target_link_libraries` not needed, already linked Hope this helps. From pasci.bach at gmail.com Tue Aug 26 08:57:51 2014 From: pasci.bach at gmail.com (Pascal Bach) Date: Tue, 26 Aug 2014 14:57:51 +0200 Subject: [CMake] Windows Embedded Compact 2013 support Message-ID: Hi. I would like to compile some software for Windows Embedded Compact 2013 (WEC2013). But I was unable to find any documentation about WEC2013 support. Does somebody already use CMake to build for Windows Embedded Compact 2013? Is it supported at all? If not where would I need to start to add support for it to the CMake project? Thanks for your help. Pascal From nico.schloemer at gmail.com Tue Aug 26 09:17:28 2014 From: nico.schloemer at gmail.com (=?UTF-8?Q?Nico_Schl=C3=B6mer?=) Date: Tue, 26 Aug 2014 15:17:28 +0200 Subject: [CMake] pipe add_test() output into a file In-Reply-To: <53FC5B79.3020503@gmail.com> References: <53FC5B79.3020503@gmail.com> Message-ID: Thanks Nils! That does the trick. --Nico On Tue, Aug 26, 2014 at 12:03 PM, Nils Gladitz wrote: > On 08/26/2014 11:50 AM, Nico Schl?mer wrote: >> >> I would like to add a test for a file converter. The output of the >> converter is written out to stdout, and I would like to direct this >> into a file to compare it against a reference file. The signature of >> add_test() [1] however doesn't seem to allow that. >> >> How would you go about this problem? > > > You could run cmake in script mode (${CMAKE_COMMAND} -P) and have the script > call your converter with execute_process(). > > You can pass the path to the converter with the $ generator > expression and -D (-D options have to be listed before -P). > > Note that generator expressions in tests are only supported when the test is > defined with the NAME/COMMAND signature of add_test(). > > execute_process() can capture the output of the command in a file or > variable. > > The script could then also perform the comparison. > > You can make the script (and the test) fail with e.g. message(FATAL_ERROR > "message") > > Nils From mike.jackson at bluequartz.net Tue Aug 26 10:26:00 2014 From: mike.jackson at bluequartz.net (Michael Jackson) Date: Tue, 26 Aug 2014 10:26:00 -0400 Subject: [CMake] Setting additional Plist values for OS X Bundle In-Reply-To: <6604415.VH6vhQAsli@stryke> References: <9E659DA1-667F-4FB0-B7EE-D388AC42417E@bluequartz.net> <6604415.VH6vhQAsli@stryke> Message-ID: Was hoping not to have to bring in a custom plist, but thanks for the heads up. Mike Jackson On Aug 25, 2014, at 1:48 PM, Clinton Stimpson wrote: > On Monday, August 25, 2014 01:10:27 PM Michael Jackson wrote: >> Are there are newer facilities in CMake 3.x that would allow me to add >> additional Plist values to the standard Mac OS X bundle plist that gets >> created? >> >> I use the following code currently: >> >> set_target_properties(${TARGET_NAME} PROPERTIES >> MACOSX_BUNDLE_INFO_STRING "${PROJECT_NAME}${DBG_EXTENSION} Version >> ${VERSION_STRING}, Copyright 2014 BlueQuartz Software." >> MACOSX_BUNDLE_ICON_FILE ${ICON_FILE_NAME} >> MACOSX_BUNDLE_GUI_IDENTIFIER "${PROJECT_NAME}${DBG_EXTENSION}" >> MACOSX_BUNDLE_LONG_VERSION_STRING "${PROJECT_NAME}${DBG_EXTENSION} >> Version ${VERSION_STRING}" MACOSX_BUNDLE_BUNDLE_NAME >> ${PROJECT_NAME}${DBG_EXTENSION} >> MACOSX_BUNDLE_SHORT_VERSION_STRING ${VERSION_STRING} >> MACOSX_BUNDLE_BUNDLE_VERSION ${VERSION_STRING} >> MACOSX_BUNDLE_COPYRIGHT "Copyright 2014, BlueQuartz Software. All >> Rights Reserved." ) >> >> >> But I need to add the following to my plist: >> >> NSHighResolutionCapable >> True >> >> >> Thanks for any help >> -- >> Mike Jackson www.bluequartz.net > > Even with CMake 2.x, you can make your own .plist.in copied from > CMake/Modules/MacOSXBundleInfo.plist.in, then add your part in there. > NSHighResolutionCapable > True > > Then add one more line to your set of target properties: > > MACOSX_BUNDLE_INFO_PLIST > "${CMAKE_CURRENT_SOURCE_DIR}/MacOSXBundleInfo.plist.in" > > - Clint From digitalriptide at gmail.com Tue Aug 26 12:41:25 2014 From: digitalriptide at gmail.com (digitalriptide) Date: Tue, 26 Aug 2014 12:41:25 -0400 Subject: [CMake] Color Output with Ninja? Message-ID: Is there a way to enable color compiler messages with the ninja generator? With make and clang, for example, the makefile generator is able to produce color output. Thank you for your assistance. -------------- next part -------------- An HTML attachment was scrubbed... URL: From camlorn38 at gmail.com Tue Aug 26 14:28:16 2014 From: camlorn38 at gmail.com (Austin Hicks) Date: Tue, 26 Aug 2014 14:28:16 -0400 Subject: [CMake] Trouble with library Dependencies not being reflected in the generated project files Message-ID: <53FCD1C0.2070300@gmail.com> Hello, I'm having some interesting problems with dependencies, and I'm trying to determine if this is my fault or CMake's. For the record, I'm on cmake 3.0.1, Windows 7, and Visual Studio 2013. I've got a project consisting of a vendored copy of Portaudio, a shared library, and something like 10 example programs. I've set everything up in the obvious manner-the example programs go to the library with target_link_libraries. The example programs do not rebuild with the library. I've been fighting with it for 6 hours. And here comes the strangeness that makes me think this may not be my fault. First, there is one generated file, made through add_custom_command to a python script. I thought this could be the problem, but temporarily turned it into a regular static file. No luck. So I went to the Graphviz output. There is an explicit dependency from the executables to the library, and everything looks right. This is apparently not being reflected in any of the three backends I tried: NMake Makefiles, NMake Makefiles JOM, or VS2013 MSBuild scripts. I have tried a full regeneration of the build tree along with everything I've done to fix it, so this isn't some sort of phantom state (I saw that once or twice). Not unless CMake stores stuff outside my build tree. I've not posted my CMakeLists.txt here because it's actually 5 linked by add_subdirectory. I can attach them, link to the Github repository, or post them in an e-mail one after another. I'm not sure what the convention is, and this problem is something I've not yet managed to isolate to a small test case. Any help is appreciated. From amul.shah at fisglobal.com Tue Aug 26 14:23:41 2014 From: amul.shah at fisglobal.com (Amul Shah) Date: Tue, 26 Aug 2014 14:23:41 -0400 Subject: [CMake] Switching between i386, i586 and i686 Message-ID: <53FCD0AD.7060801@fisglobal.com> My host machine is RedHat 6 i686. I was wondering how I could direct CMake to set -march to either i386 or i586 without manually setting -march=. I tried changing CMAKE_SYSTEM_PROCESSOR, but that did not work. thanks, Amul _____________ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. From chuck.atkins at kitware.com Tue Aug 26 15:13:42 2014 From: chuck.atkins at kitware.com (Chuck Atkins) Date: Tue, 26 Aug 2014 15:13:42 -0400 Subject: [CMake] Switching between i386, i586 and i686 In-Reply-To: <53FCD0AD.7060801@fisglobal.com> References: <53FCD0AD.7060801@fisglobal.com> Message-ID: Hi Amul, The -march flag doesn't automatically get set by CMake since it tends to be highly system specific; you'll need to explicitly add it to your CMAKE_{C,CXX,Fortran}_FLAGS variables if you want it used. The CMAKE_SYSTEM_PROCESSOR variable is usually used only for packaging to determine output file names and in cross compiling. - Chuck On Tue, Aug 26, 2014 at 2:23 PM, Amul Shah wrote: > My host machine is RedHat 6 i686. I was wondering how I could direct CMake > to set -march to either i386 or i586 without manually setting -march=. I > tried changing CMAKE_SYSTEM_PROCESSOR, but that did not work. > > thanks, > Amul > > _____________ > The information contained in this message is proprietary and/or > confidential. If you are not the intended recipient, please: (i) delete the > message and all copies; (ii) do not disclose, distribute or use the message > in any manner; and (iii) notify the sender immediately. In addition, please > be aware that any message addressed to our domain is subject to archiving > and review by persons other than the intended recipient. Thank you. > -- > > 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 ashoknn at qti.qualcomm.com Tue Aug 26 21:24:53 2014 From: ashoknn at qti.qualcomm.com (Ashok Nalkund) Date: Tue, 26 Aug 2014 18:24:53 -0700 Subject: [CMake] Controlling output of ctest Message-ID: <53FD3365.1020907@qti.qualcomm.com> Hi, I use cmake/ctest to build and run my tests. I'm using "ctest -T Test -V --output-on-failure --no-compress-output -R ...". I noticed that some of the tests have truncated output in the Test.xml report. Also I see the truncation length is different in different scenarios. From what I see, if the test failed, the length is 307200: > [DEBUG3] [FeatureInstanceReader][ReadNext] IsGood 1, IsEOF 0 > [DEBUG1... > The rest of the test output was removed since it exceeds the threshold > of 307200 bytes. > But if the test had passed, the length is 1024: > push: > /local/mnt/workspace/jenkins-slave/workspace/build/arm-android-gcc4... > The rest of the test output was removed since it exceeds the threshold > of 1024 bytes. > The actual binary executed in the test is a gtest binary. I'm using cmake/ctest 2.8.9. Can somebody shed light on why the threshold is different in the two cases? Also can I completely remove the threshold? I've read that having 'CTEST_FULL_OUTPUT' anywhere in the output will allow me to do that but I'm hoping to avoid having each of my test output that. TIA, Ashok From ashoknn at qti.qualcomm.com Tue Aug 26 21:32:01 2014 From: ashoknn at qti.qualcomm.com (Ashok Nalkund) Date: Tue, 26 Aug 2014 18:32:01 -0700 Subject: [CMake] Controlling output of ctest In-Reply-To: <53FD3365.1020907@qti.qualcomm.com> References: <53FD3365.1020907@qti.qualcomm.com> Message-ID: <53FD3511.20701@qti.qualcomm.com> I think I've found the solution at http://www.vtk.org/Wiki/CMake_Testing_With_CTest. I'm going to try setting CTEST_CUSTOM_MAXIMUM_PASSED_TEST_OUTPUT_SIZE and CTEST_CUSTOM_MAXIMUM_FAILED_TEST_OUTPUT_SIZE and report back. Thanks, Ashok On 8/26/2014 6:24 PM, Ashok Nalkund wrote: > Hi, > I use cmake/ctest to build and run my tests. I'm using "ctest -T > Test -V --output-on-failure --no-compress-output -R ...". I noticed > that some of the tests have truncated output in the Test.xml report. > Also I see the truncation length is different in different scenarios. > From what I see, if the test failed, the length is 307200: >> [DEBUG3] [FeatureInstanceReader][ReadNext] IsGood 1, IsEOF 0 >> [DEBUG1... >> The rest of the test output was removed since it exceeds the >> threshold of 307200 bytes. >> > > But if the test had passed, the length is 1024: >> push: >> /local/mnt/workspace/jenkins-slave/workspace/build/arm-android-gcc4... >> The rest of the test output was removed since it exceeds the >> threshold of 1024 bytes. >> > > The actual binary executed in the test is a gtest binary. I'm using > cmake/ctest 2.8.9. > > Can somebody shed light on why the threshold is different in the two > cases? Also can I completely remove the threshold? I've read that > having 'CTEST_FULL_OUTPUT' anywhere in the output will allow me to do > that but I'm hoping to avoid having each of my test output that. > > TIA, > Ashok > From jonas at lippuner.ca Tue Aug 26 23:44:21 2014 From: jonas at lippuner.ca (Jonas Lippuner) Date: Tue, 26 Aug 2014 20:44:21 -0700 Subject: [CMake] Global dependency Message-ID: <53FD5415.9070309@lippuner.ca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all, I have a custom target called BuildInfoDateTime that generates a *.cpp file containing the date and time of the build. I specified the target with ALL, so it gets run if I simply type make. However, I would also like all other targets (executables and libraries) to depend on BuildInfoDateTime. Of course, I can add the dependency manually, but that is tedious and could be forgotten when new targets are added. So, is there a way to make all targets depend on my custom target BuildInfoDateTime? Thanks, Jonas - -- My email is signed and I encrypt email on request. To verify my signature or send me encrypted email, get my public key: http://lippuner.ca/key -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJT/VQTAAoJELH92qHy0gnt08AP/1rjVLQ5n0L6+VsW98H0MC3s ccHipuwsvoCZX01R1/q/NS3e+5QV4Lx/MplhBysucM+eNesmzFPq0u5DlPI/G6wm KGbLGCQnczx7nWI1Dsso0lkj1bOxsMaa83u4LL0xn9g5UJUpzRI2MMgFzasLfOcA e4mkQKpp6O3asQ56DECvzg3RwZRgrjIi7UAKbxyO1U6p/3XmkYzzIAFoJxfeABNi 5LD0SS1W1aVTUrBseu+puADC4I8K5zit7uI7zlIyujxyFyj+7SkBmvYKrgXs18nR Y2ycy/nruUMIxblYIdm723Tu+T9+Y51qZvHbLVuJGKergVFCjsIntkjXMcmbqyLD Q/uAKFSRzYOlYHPsNrNkQbuaB7dM3VDGMCtfZiJQQaWGZpI58Iyqgr0JaY+pFXPC ZskjI1BH7T5uKy5KG+XMfZSbSFzUi2woZpMYPROQi0DqCfgIpLiZsnyHcD6erzMv DTkmciltZTn0/u953lJWj7lH+8vxSRJm7KLcFmpKRMI8Nq6YLXUkQBj/1gtIt8q/ Y98qHJOM/IcrW2hUC6i1s5yQGqgV60tzBFCVOkG/GTO9uUbA4KyXYw/lUDyb0lq+ oKkCS0EsOIiscQxfemFwVh/sO8Vqap2Az4JaxrM8s8YDP3otYtVXBL/nn2sYrOwv 4BEjtuSuvJf/mz0EiqYQ =p1nK -----END PGP SIGNATURE----- From petr.kmoch at gmail.com Wed Aug 27 02:45:46 2014 From: petr.kmoch at gmail.com (Petr Kmoch) Date: Wed, 27 Aug 2014 08:45:46 +0200 Subject: [CMake] Need to know the ASM flag that needs to be modified in cmake In-Reply-To: <183c6dfc322748efaba85a04c467875b@XORMUM-MBX01.India.XoriantCorp.com> References: <183c6dfc322748efaba85a04c467875b@XORMUM-MBX01.India.XoriantCorp.com> Message-ID: Hi Ravi, I've never used ASM_MASM (or any other language beside C, CXX and Fortran), but if it follows normal CMake language rules, the following variables should exist: CMAKE_ASM_MASM_FLAGS CMAKE_ASM_MASM_FLAGS_ (where is a placeholder for uppercase configuration name). See the list of per-language variables in the docs: http://www.cmake.org/cmake/help/v3.0/manual/cmake-variables.7.html#variables-for-languages Petr On Tue, Aug 26, 2014 at 6:28 AM, Ravi Raman wrote: > Hi, > > > > In our cmake project, there is an assembler file (.asm extension) that > needs to be compiled to create object file (.obj) using microsoft macro > assembler (ml.exe for 32-bit and ml64.exe for 64-bit) > > This is happening successfully. > > But there is a preprocessor directive (_WIN64) as follows within the .asm > code, which is not getting set. > > IFDEF _WIN64 > > We would like to know which is the ASM related cmake flag variable that > needs to be manipulated in order to set _WIN64 > > > > Details as follows: > > 1. In CMakeLists.txt, we do the following to enable microsoft macro > assembler to compile .asm files > > enable_language(ASM_MASM) > > 2. We include the .asm file Testx64.asm in the source list > > 3. Because of the above enable_language step, the MASM step gets > correctly triggered as follows with the following ml64.exe options to > compile the .asm to create corresponding .obj > > _MASM: > > Assembling ..\..\..\testx64\Testx64.asm... > > cmd.exe /C > "C:\Users\raman_r\AppData\Local\Temp\tmp8a9b40c55523496e9edce668c1f812a2.cmd" > > ml64.exe /c /nologo /Zi /Fo"testx64.dir\Release\Testx64.obj" /W3 > /errorReport:prompt /Ta..\..\..\testx64\Testx64.asm > > > > Note that in the above step 3, ml64.exe execution creates the output > object file Testx64.obj, but in this there is no pre-processor switch /D > _WIN64 > > > > Is there a way in cmake to manipulate any ASM related cmake flag, so that > the above ml64.exe execution has /D _WIN64 option set ? > > > > Thanks & Regards > > > > *Ravi Raman * > > *Xoriant Solutions Pvt. Ltd* > > 4th Floor, Winchester, Hiranandani Business Park, Powai, Mumbai 400076, > INDIA. > > Tel: +91 22 30511000,9930100026 Extn: 2144 Voip No. 4088344495/96/97/98 > Voip Extn:1178| Fax: +91 22 30511111 > > ravi.raman at xoriant.com | http://www.xoriant.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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From petr.kmoch at gmail.com Wed Aug 27 02:57:26 2014 From: petr.kmoch at gmail.com (Petr Kmoch) Date: Wed, 27 Aug 2014 08:57:26 +0200 Subject: [CMake] Global dependency In-Reply-To: <53FD5415.9070309@lippuner.ca> References: <53FD5415.9070309@lippuner.ca> Message-ID: Hi Jonas. As a hacky solution, you could override add_library() and add_executable(), like this: function(add_library targetName) _add_library(${targetName} ${ARGN}) add_dependencies(${targetName} BuildInfoDateTime) endfunction() Petr On Wed, Aug 27, 2014 at 5:44 AM, Jonas Lippuner wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi all, > > I have a custom target called BuildInfoDateTime that generates a *.cpp > file containing the date and time of the build. I specified the target > with ALL, so it gets run if I simply type make. However, I would also > like all other targets (executables and libraries) to depend on > BuildInfoDateTime. Of course, I can add the dependency manually, but > that is tedious and could be forgotten when new targets are added. > > So, is there a way to make all targets depend on my custom target > BuildInfoDateTime? > > > Thanks, > Jonas > > > - -- > My email is signed and I encrypt email on request. > To verify my signature or send me encrypted email, > get my public key: http://lippuner.ca/key > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1 > > iQIcBAEBAgAGBQJT/VQTAAoJELH92qHy0gnt08AP/1rjVLQ5n0L6+VsW98H0MC3s > ccHipuwsvoCZX01R1/q/NS3e+5QV4Lx/MplhBysucM+eNesmzFPq0u5DlPI/G6wm > KGbLGCQnczx7nWI1Dsso0lkj1bOxsMaa83u4LL0xn9g5UJUpzRI2MMgFzasLfOcA > e4mkQKpp6O3asQ56DECvzg3RwZRgrjIi7UAKbxyO1U6p/3XmkYzzIAFoJxfeABNi > 5LD0SS1W1aVTUrBseu+puADC4I8K5zit7uI7zlIyujxyFyj+7SkBmvYKrgXs18nR > Y2ycy/nruUMIxblYIdm723Tu+T9+Y51qZvHbLVuJGKergVFCjsIntkjXMcmbqyLD > Q/uAKFSRzYOlYHPsNrNkQbuaB7dM3VDGMCtfZiJQQaWGZpI58Iyqgr0JaY+pFXPC > ZskjI1BH7T5uKy5KG+XMfZSbSFzUi2woZpMYPROQi0DqCfgIpLiZsnyHcD6erzMv > DTkmciltZTn0/u953lJWj7lH+8vxSRJm7KLcFmpKRMI8Nq6YLXUkQBj/1gtIt8q/ > Y98qHJOM/IcrW2hUC6i1s5yQGqgV60tzBFCVOkG/GTO9uUbA4KyXYw/lUDyb0lq+ > oKkCS0EsOIiscQxfemFwVh/sO8Vqap2Az4JaxrM8s8YDP3otYtVXBL/nn2sYrOwv > 4BEjtuSuvJf/mz0EiqYQ > =p1nK > -----END PGP SIGNATURE----- > -- > > 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 jonas at lippuner.ca Wed Aug 27 03:58:48 2014 From: jonas at lippuner.ca (Jonas Lippuner) Date: Wed, 27 Aug 2014 00:58:48 -0700 Subject: [CMake] Global dependency In-Reply-To: References: <53FD5415.9070309@lippuner.ca> Message-ID: <53FD8FB8.4040208@lippuner.ca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Petr, Thanks! This works. Best, Jonas - -------- Original Message -------- Subject: Re: [CMake] Global dependency From: Petr Kmoch To: Jonas Lippuner CC: "cmake at cmake.org" Date: Tue 26 Aug 2014 11:57:26 PM PDT > Hi Jonas. > > As a hacky solution, you could override add_library() and > add_executable(), like this: > > function(add_library targetName) _add_library(${targetName} > ${ARGN}) add_dependencies(${targetName} BuildInfoDateTime) > endfunction() > > Petr > > > > On Wed, Aug 27, 2014 at 5:44 AM, Jonas Lippuner > wrote: > > Hi all, > > I have a custom target called BuildInfoDateTime that generates a > *.cpp file containing the date and time of the build. I specified > the target with ALL, so it gets run if I simply type make. However, > I would also like all other targets (executables and libraries) to > depend on BuildInfoDateTime. Of course, I can add the dependency > manually, but that is tedious and could be forgotten when new > targets are added. > > So, is there a way to make all targets depend on my custom target > BuildInfoDateTime? > > > Thanks, Jonas > > > -- > > 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 > > - -- My email is signed and I encrypt email on request. To verify my signature or send me encrypted email, get my public key: http://lippuner.ca/key -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJT/Y+tAAoJELH92qHy0gntSgMQANZGcSpj9w44j52U2IQbkI/Q P/s2IhHnfL/yrbNQwhQok5T37w5+lLx0/NJJGrSMZoCVLG1FVoj+ARCfovQSnkWB OMrRqHAh57kcrti/7HMfLbhTTvPYfc3t6Rw0HPfzQecFNlApHU0N+uinZpe6FBrK gqH3dugK1AwLyk19Htif6JL4uRfrOh2Gp709L4hOMLd3C264sOVIrlct2xVBy1Uv P9oAGznh2pgYITrUUL66XT7n8BBW9zGsjcYbxnHbo4ikRWZ3gl/+2cQP+0/i0y+C 9Ku/w7jJI5wC5jG+rOORJFwiVQShXBd13WPBuwKbz5MXv4fdr91dwnaNrug9iMRB o1Ql2wR2lU7cDBUV/D7GvSwbHTrTswwG5rvr5Bdv7HrqdyGJuYZ9dYkcqBx8wqz+ ijAmGMDMazTCoESU1uR7gQOTo5GwwK9TYPdV/93wg3P+lY3tJAEjB9RU1TG94//p QDNJ58mgoAATKQKJzpcgokEuhAJAOqjgSv62Eh+M0YavV8nODsH9mswmMvqNLzt0 sklvY3qD7Bmhu1AhEPOQG5+zwXAAOVjW9GXfh7hqZNr8d+pNyZ+nfidIlOLVpy3G JEPK4ZvnJ/0DomTPyLq9aXh4es9BVY7Tvcz0P5A80YV/JdUvFwMZONQOdMamo9Xp +XwdvGa0oERaAhH2vPp4 =EwpZ -----END PGP SIGNATURE----- From lukasz at tasz.eu Wed Aug 27 04:30:52 2014 From: lukasz at tasz.eu (=?UTF-8?B?xYF1a2FzeiBUYXN6?=) Date: Wed, 27 Aug 2014 10:30:52 +0200 Subject: [CMake] compilation order dependencies, Message-ID: Dear experts, I hit the wall again with order of compilation in generated Makefiles, Uscase: add_library(foo ${foosources}) add_library(bar ${barsources}) add_library... ... ... add_executable(foo_exe main.cpp) target_link_libraries(foo_exe foo bar ... ... ...) while libs objects will be compiled in parallel, man.cpp.o will be compiled after linking of all libs, If main.cpp is compiling long then this is overall additional waist of time which could be done much earlier. Do you have some ideas how this situation could be optimised? with best regards ?ukasz Tasz From petr.kmoch at gmail.com Wed Aug 27 04:58:42 2014 From: petr.kmoch at gmail.com (Petr Kmoch) Date: Wed, 27 Aug 2014 10:58:42 +0200 Subject: [CMake] compilation order dependencies, In-Reply-To: References: Message-ID: Hi Lukasz. I believe you could put `main.cpp` into an object library: add_library(foo ${foosources}) add_library(bar ${barsources}) add_library... ... ... add_library(main_sources OBJECT main.cpp) add_executable(foo_exe $) target_link_libraries(foo_exe foo bar ... ... ...) This should make `main.cpp` compilable independently, as only the linking of foo_exe will wait until the libraries (including the object one) are finished. Petr On Wed, Aug 27, 2014 at 10:30 AM, ?ukasz Tasz wrote: > Dear experts, > > I hit the wall again with order of compilation in generated Makefiles, > > Uscase: > > add_library(foo ${foosources}) > add_library(bar ${barsources}) > add_library... > ... > ... > add_executable(foo_exe main.cpp) > target_link_libraries(foo_exe foo bar ... ... ...) > > while libs objects will be compiled in parallel, man.cpp.o will be > compiled after linking of all libs, > If main.cpp is compiling long then this is overall additional waist of > time which could be done much earlier. > > Do you have some ideas how this situation could be optimised? > > with best regards > ?ukasz Tasz > -- > > 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 ravi.raman at Xoriant.Com Wed Aug 27 06:35:26 2014 From: ravi.raman at Xoriant.Com (Ravi Raman) Date: Wed, 27 Aug 2014 10:35:26 +0000 Subject: [CMake] Need to know the ASM flag that needs to be modified in cmake In-Reply-To: References: <183c6dfc322748efaba85a04c467875b@XORMUM-MBX01.India.XoriantCorp.com> Message-ID: <5c0ecbd621e44bd28b476a04dddf817e@XORMUM-MBX01.India.XoriantCorp.com> Hi, Thanks Petr for your comments. We had already tried this approach. But it did not work. We set the option ?/D _WIN64? in CMAKE_ASM_MASM_FLAGS but it has no impact on the execution of ml64.exe. ml64.exe execution always shows only the following options i.e. does not include ?/D _WIN64?. ml64.exe /c /nologo /Zi /Fo"testx64.dir\Release\Testx64.obj" /W3 /errorReport:prompt /Ta..\..\..\testx64\Testx64.asm We also tried setting the cmake variable CMAKE_ASM_MASM_COMPILER_ARG1 with the option ?/D _WIN64? But with that also, there is no change, the result is the same. So, somehow we need to find a way to stuff ?/D _WIN64? in the compile options of ml64.exe Thanks & Regards Ravi Raman Xoriant Solutions Pvt. Ltd 4th Floor, Winchester, Hiranandani Business Park, Powai, Mumbai 400076, INDIA. Tel: +91 22 30511000,9930100026 Extn: 2144 Voip No. 4088344495/96/97/98 Voip Extn:1178| Fax: +91 22 30511111 ravi.raman at xoriant.com| http://www.xoriant.com From: Petr Kmoch [mailto:petr.kmoch at gmail.com] Sent: Wednesday, August 27, 2014 12:16 PM To: Ravi Raman Cc: cmake at cmake.org Subject: Re: [CMake] Need to know the ASM flag that needs to be modified in cmake Hi Ravi, I've never used ASM_MASM (or any other language beside C, CXX and Fortran), but if it follows normal CMake language rules, the following variables should exist: CMAKE_ASM_MASM_FLAGS CMAKE_ASM_MASM_FLAGS_ (where is a placeholder for uppercase configuration name). See the list of per-language variables in the docs: http://www.cmake.org/cmake/help/v3.0/manual/cmake-variables.7.html#variables-for-languages Petr On Tue, Aug 26, 2014 at 6:28 AM, Ravi Raman > wrote: Hi, In our cmake project, there is an assembler file (.asm extension) that needs to be compiled to create object file (.obj) using microsoft macro assembler (ml.exe for 32-bit and ml64.exe for 64-bit) This is happening successfully. But there is a preprocessor directive (_WIN64) as follows within the .asm code, which is not getting set. IFDEF _WIN64 We would like to know which is the ASM related cmake flag variable that needs to be manipulated in order to set _WIN64 Details as follows: 1. In CMakeLists.txt, we do the following to enable microsoft macro assembler to compile .asm files enable_language(ASM_MASM) 2. We include the .asm file Testx64.asm in the source list 3. Because of the above enable_language step, the MASM step gets correctly triggered as follows with the following ml64.exe options to compile the .asm to create corresponding .obj _MASM: Assembling ..\..\..\testx64\Testx64.asm... cmd.exe /C "C:\Users\raman_r\AppData\Local\Temp\tmp8a9b40c55523496e9edce668c1f812a2.cmd" ml64.exe /c /nologo /Zi /Fo"testx64.dir\Release\Testx64.obj" /W3 /errorReport:prompt /Ta..\..\..\testx64\Testx64.asm Note that in the above step 3, ml64.exe execution creates the output object file Testx64.obj, but in this there is no pre-processor switch /D _WIN64 Is there a way in cmake to manipulate any ASM related cmake flag, so that the above ml64.exe execution has /D _WIN64 option set ? Thanks & Regards Ravi Raman Xoriant Solutions Pvt. Ltd 4th Floor, Winchester, Hiranandani Business Park, Powai, Mumbai 400076, INDIA. Tel: +91 22 30511000,9930100026 Extn: 2144 Voip No. 4088344495/96/97/98 Voip Extn:1178| Fax: +91 22 30511111 ravi.raman at xoriant.com| http://www.xoriant.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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ts at medical-insight.com Wed Aug 27 07:21:02 2014 From: ts at medical-insight.com (Thomas Sondergaard) Date: Wed, 27 Aug 2014 13:21:02 +0200 Subject: [CMake] Fail target if buildtype is not RelWithDebInfo Message-ID: <53FDBF1E.5050705@medical-insight.com> Hi, I have a custom target that is only enabled on Windows and it only works with buildtype RelWithDebInfo. When a developer accidentally runs it under a different configuration it doesn't fail in a very obvious way, and I'd like to improve that, if possible. I am using the "Visual Studio 12" (2013) generator. I imagine something like this if (WIN32) add_custom_target(msi-installer COMMAND if NOT "%CMAKE_BUILD_TYPE%" == "RELWITHDEBINFO" (echo "msi-installer only works for build type RELWITHDEBINFO" && exit 1) COMMAND ...) endif() But that requires the CMAKE_BUILD_TYPE to be in the environment. Is there a way to do what I want? Thanks, Thomas From petr.kmoch at gmail.com Wed Aug 27 07:48:34 2014 From: petr.kmoch at gmail.com (Petr Kmoch) Date: Wed, 27 Aug 2014 13:48:34 +0200 Subject: [CMake] Fail target if buildtype is not RelWithDebInfo In-Reply-To: <53FDBF1E.5050705@medical-insight.com> References: <53FDBF1E.5050705@medical-insight.com> Message-ID: Hi Thomas, you should be able to make this work using the variable CMAKE_CFG_INTDIR: if (WIN32) add_custom_target(msi-installer COMMAND IF NOT "${CMAKE_CFG_INTDIR}" == "RELWITHDEBINFO" (echo "msi-installer only works for build type RELWITHDEBINFO" && exit 1) COMMAND ...) endif() Petr On Wed, Aug 27, 2014 at 1:21 PM, Thomas Sondergaard wrote: > Hi, > > I have a custom target that is only enabled on Windows and it only works > with buildtype RelWithDebInfo. When a developer accidentally runs it under > a different configuration it doesn't fail in a very obvious way, and I'd > like to improve that, if possible. I am using the "Visual Studio 12" (2013) > generator. > > I imagine something like this > > if (WIN32) > add_custom_target(msi-installer > COMMAND if NOT "%CMAKE_BUILD_TYPE%" == > "RELWITHDEBINFO" (echo "msi-installer only works for build type > RELWITHDEBINFO" && exit 1) > COMMAND ...) > endif() > > But that requires the CMAKE_BUILD_TYPE to be in the environment. Is there > a way to do what I want? > > Thanks, > Thomas > > -- > > 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 ts at medical-insight.com Wed Aug 27 08:45:45 2014 From: ts at medical-insight.com (Thomas Sondergaard) Date: Wed, 27 Aug 2014 14:45:45 +0200 Subject: [CMake] Fail target if buildtype is not RelWithDebInfo In-Reply-To: References: <53FDBF1E.5050705@medical-insight.com> Message-ID: Thanks Petr, It works. I ended up having to make it slightly more complicated to also work with the Ninja generator, but CMAKE_CFG_INTDIR was exactly what I was looking for. Thanks, Thomas On 2014-08-27 13:48, Petr Kmoch wrote: > Hi Thomas, > > you should be able to make this work using the variable CMAKE_CFG_INTDIR: > > if (WIN32) > add_custom_target(msi-installer > COMMAND IF NOT "${CMAKE_CFG_INTDIR}" == "RELWITHDEBINFO" (echo > "msi-installer only works for build type RELWITHDEBINFO" && exit 1) > COMMAND ...) > endif() > > Petr From phil at voltage.com Wed Aug 27 13:17:55 2014 From: phil at voltage.com (Phil Smith) Date: Wed, 27 Aug 2014 10:17:55 -0700 Subject: [CMake] CMake hangs Message-ID: <84BCCD71182F0046BCD2FB054FE52379112D524C0B@HQMAILSVR02.voltage.com> For a long time, we've been stuck on CMake 2.8 because later versions silently hang for us. This is doing in-source builds, which I know are considered Evil, but we can't move off them yet. We had another problem (see my earlier posts with Subject: Dependency weirdness) that turned out to be related to a bug in CMake, Cygwin, or Windows, where the dependencies worked if the source directory had a period in the name and didn't if not, due to a case mismatch in the CMakeLists.txt. That led me to wonder whether that was causing the hang. I do not believe it does. I installed CMake 3.0.1 and did NOT customize it to support the cross-compiler we're using, then switched to it and tried that. Hang. This is the CMake command: cmake -DCMAKE_TOOLCHAIN_FILE:string="%~dp0\zosport.cmake" -G"Unix Makefiles" .\ Hmm, sez I, I wonder if it's due to the lack of cross-compiler support. I know, I'll copy the CMakeLists.txt to c:\temp and try it there. Hang. What about 2.8? I removed (well, renamed) the compiler support and tried it: C:\temp>cmake -DCMAKE_TOOLCHAIN_FILE:string="%~dp0\zosport.cmake" -G"Unix Makefiles" .\ CMake Error at C:/Program Files (x86)/CMake 2.8/share/cmake-2.8/Modules/CMakeDetermineSystem.cmake:92 (MESSAGE): Could not find toolchain file: %~dp0\zosport.cmake Call Stack (most recent call first): CMakeLists.txt:8 (project) CMake Error: Error required internal CMake variable not set, cmake may be not be built correctly. Missing variable is: CMAKE_C_COMPILER_ENV_VAR CMake Error: Error required internal CMake variable not set, cmake may be not be built correctly. Missing variable is: CMAKE_C_COMPILER CMake Error: Could not find cmake module file:C:/temp/CMakeFiles/CMakeCCompiler.cmake CMake Error: cmListFileCache: error can not open file C:/temp CMake Error: Could not find cmake module file: CMake Error: Error required internal CMake variable not set, cmake may be not be built correctly. Missing variable is: CMAKE_ASM_DIGNUS_COMPILER_ENV_VAR CMake Error: Error required internal CMake variable not set, cmake may be not be built correctly. Missing variable is: CMAKE_ASM_DIGNUS_COMPILER CMake Error: Could not find cmake module file:C:/temp/CMakeFiles/CMakeASM_DIGNUSCompiler.cmake CMake Error: Error required internal CMake variable not set, cmake may be not be built correctly. Missing variable is: CMAKE_CXX_COMPILER_ENV_VAR CMake Error: Error required internal CMake variable not set, cmake may be not be built correctly. Missing variable is: CMAKE_CXX_COMPILER CMake Error: Could not find cmake module file:C:/temp/CMakeFiles/CMakeCXXCompiler.cmake CMake Error: Could not find cmake module file:CMakeASM_DIGNUSInformation.cmake CMake Error: CMAKE_C_COMPILER not set, after EnableLanguage CMake Error: CMAKE_ASM_DIGNUS_COMPILER not set, after EnableLanguage CMake Error: CMAKE_CXX_COMPILER not set, after EnableLanguage -- Configuring incomplete, errors occurred! Seems like the hang in 3.0.1 is wrong, but I don't have the skills to tell. And since the Toolchain file is not missing in the actual path, this isn't necessarily the same hang, but it seems worth understanding. The hang *feels* like something is getting a null input and is thus trying to read from stdin, though typing junk on the console doesn't make it happy, even with a ^Z after it. Any ideas? ...phsiii -------------- next part -------------- An HTML attachment was scrubbed... URL: From victor.zverovich at gmail.com Wed Aug 27 17:19:43 2014 From: victor.zverovich at gmail.com (victor.zverovich at gmail.com) Date: Wed, 27 Aug 2014 14:19:43 -0700 Subject: [CMake] linking with libstdc++ statically Message-ID: Hello, I am trying to link an application with libstdc++ statically on Linux and OS X. The first attempt was to add -static-libstdc++ to CMAKE_EXE_LINKER_FLAGS: set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -static-libstdc++") This works on Linux with GCC, but Clang gives the following error on OS X: clang: warning: argument unused during compilation: '-static-libstdc++' Another way that I found is to find the location of static libstdc++ library in the directories given by CMAKE_CXX_IMPLICIT_LINK_DIRECTORIES and modify CMAKE_CXX_IMPLICIT_LINK_LIBRARIES. Is there a better way to link with libstdc++ statically in CMake? Thanks, Victor -------------- next part -------------- An HTML attachment was scrubbed... URL: From cmake at lanrules.de Thu Aug 28 07:48:52 2014 From: cmake at lanrules.de (Johannes Jordan) Date: Thu, 28 Aug 2014 13:48:52 +0200 Subject: [CMake] Building project with Boost thread, TBB, OpenCV, QT, -lpthread missing Message-ID: <53FF1724.2010500@lanrules.de> Hello, I am running a project that uses several libs which seemingly rely on pthread. In my CMake files, I don't explicitely refer to pthread (especially as it is a different story under different OS's like Windows). Instead I use the find_package logic, e.g.: find_package(Boost ${VOLE_MINIMUM_BOOST_VERSION} COMPONENTS thread) then use "${Boost_INCLUDE_DIR}/include/;${Boost_INCLUDE_DIR}", ${Boost_THREAD_LIBRARY} appropriately. On the GNU/Linux systems I tested, I get a linker output like this: /usr/bin/g++ -Wall -Wno-long-long -Wno-reorder -pedantic -O3 -DNDEBUG CMakeFiles/qgerbil.dir/main.cpp.o CMakeFiles/qgerbil.dir/qrc_gerbil.cxx.o -o ../../bin/qgerbil -rdynamic ../core/libcore-lib.a libgerbil_gui-lib.a -lQtOpenGL -lGLU -lGL -lSM -lICE -lX11 -lXext ../rgb/librgb-lib.a ../../librgb-optional-lib.a ../seg_graphs/libseg_graphs-lib.a ../csparse/libcsparse-lib.a ../../libseg_graphs-optional-lib.a ../../libgerbil_gui-optional-lib.a ../seg_meanshift/libseg_meanshift-lib.a ../lsh/liblsh-lib.a ../../libseg_meanshift-optional-lib.a ../seg_felzenszwalb/libseg_felzenszwalb-lib.a ../edge_detect/libedge_detect-lib.a ../som/libsom-lib.a ../imginput/libimginput-lib.a -lgdal ../similarity_measures/libsimilarity_measures-lib.a ../core/libcore-lib.a -ltbb -lboost_system -lboost_filesystem -lQtCore -lQtGui -lboost_thread -lboost_date_time -lboost_chrono /usr/lib/libopencv_videostab.so.2.4.9 /usr/lib/libopencv_ts.a -ldl -lm -lpthread -lrt -lGLU -lGL -lSM -lICE -lX11 -lXext -ltbb /usr/lib/libopencv_superres.so.2.4.9 /usr/lib/libopencv_stitching.so.2.4.9 /usr/lib/libopencv_contrib.so.2.4.9 /usr/lib/libopencv_nonfree.so.2.4.9 /usr/lib/libopencv_ocl.so.2.4.9 /usr/lib/libopencv_gpu.so.2.4.9 /usr/lib/libopencv_photo.so.2.4.9 /usr/lib/libopencv_objdetect.so.2.4.9 /usr/lib/libopencv_legacy.so.2.4.9 /usr/lib/libopencv_video.so.2.4.9 /usr/lib/libopencv_ml.so.2.4.9 /usr/lib/libopencv_calib3d.so.2.4.9 /usr/lib/libopencv_features2d.so.2.4.9 /usr/lib/libopencv_highgui.so.2.4.9 /usr/lib/libopencv_imgproc.so.2.4.9 /usr/lib/libopencv_flann.so.2.4.9 /usr/lib/libopencv_core.so.2.4.9 -lboost_program_options Now a user wrote me that he gets this output: /usr/bin/c++ -Wall -Wno-long-long -Wno-reorder -pedantic -O3 -DNDEBUG CMakeFiles/qgerbil.dir/main.cpp.o CMakeFiles/qgerbil.dir/qrc_gerbil.cxx.o -o ../../bin/qgerbil -rdynamic ../core/libcore-lib.a libgerbil_gui-lib.a /usr/lib64/qt4/libQtOpenGL.so -lGLU -lGL -lSM -lICE -lX11 -lXext ../rgb/librgb-lib.a ../../librgb-optional-lib.a ../seg_graphs/libseg_graphs-lib.a ../csparse/libcsparse-lib.a ../../libseg_graphs-optional-lib.a ../../libgerbil_gui-optional-lib.a ../seg_meanshift/libseg_meanshift-lib.a ../lsh/liblsh-lib.a ../../libseg_meanshift-optional-lib.a ../seg_felzenszwalb/libseg_felzenszwalb-lib.a ../edge_detect/libedge_detect-lib.a ../som/libsom-lib.a ../imginput/libimginput-lib.a -lgdal ../similarity_measures/libsimilarity_measures-lib.a ../core/libcore-lib.a -ltbb -lboost_system-mt -lboost_filesystem-mt /usr/lib64/qt4/libQtCore.so /usr/lib64/qt4/libQtGui.so -lboost_thread-mt -lboost_date_time-mt -lboost_chrono-mt -lopencv_calib3d -lopencv_contrib -lopencv_core -lopencv_features2d -lopencv_flann -lopencv_gpu -lopencv_highgui -lopencv_imgproc -lopencv_legacy -lopencv_ml -lopencv_nonfree -lopencv_objdetect -lopencv_photo -lopencv_stitching -lopencv_superres -lopencv_ts -lopencv_video -lopencv_videostab -lboost_program_options-mt -Wl,-rpath,/usr/lib64/qt4 I see two differences: 1. -ldl -lm -lpthread -lrt are missing 2. both Qt and OpenCV libs are referenced differently (in an opposing way) Can anybody shed light on the issue how my user might have obtained this different behaviour? What can or should I do in my CMake files to prevent this problem from happening. The successful workaround my user applied is to set CFLAGS='-lpthread'. Obviously that is not a good solution, but it shows that there are no other issues in the build (and it seems that missing -ldl -lm -lrt doesn't matter). Thank you for your time and your help! Best Regards, Johannes p.s.: the project can be found at http://gerbilvis.org From mostajab at in.tum.de Thu Aug 28 08:32:46 2014 From: mostajab at in.tum.de (Morteza mostajab) Date: Thu, 28 Aug 2014 14:32:46 +0200 Subject: [CMake] Problem with turning on the AUTO_MOC Message-ID: Dear all, Hi, I have a project which I have used the winsock2 in it and windows.h should not be includede before the winsock2.h. Also, I have used the QT in my project. Everything was completely compiled and run but I wanted to auto generate the moc files, so I have added "set(CMAKE_AUTOMOC ON)" but now it says that winsock functions and struct are redefined. I am really stucked in this problem and I don't know how to get rid of it. Please help! Regards Morteza -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex at stunpix.com Thu Aug 28 12:21:27 2014 From: alex at stunpix.com (Alexander Shashkevych) Date: Thu, 28 Aug 2014 19:21:27 +0300 Subject: [CMake] CFLAGS disables link directories? Message-ID: Hi all, I did't found info how cmake internally handles CFLAGS environment variable, but I know that cmake picks it up from environment and seems this removes link directories from linking flags added by link_directories() command. For example. I'm using custom sysroot, to build my app and I run cmake with following command: export CFLAGS="--sysroot=/sysroot/" cmake .. My cmake file is: # GStreamer_LIBRARY_DIRS is set by pkg_check_modules() link_directories(${GStreamer_LIBRARY_DIRS}) get_directory_property(LINK_DIRS LINK_DIRECTORIES) message("LINK_DIRS: ${LINK_DIRS}") add_executable(myapp main.c) target_link_libraries(myapp ${GStreamer_LIBRARIES}) When CFLAGS isn't specified, then file src/CMakeFiles/myapp.dir/link.txt contains -L/sysroot/usr/lib and -Wl,-rpath,/sysroot/usr/lib flags as expected, but when I add CFLAGS to environment, then -L and -Wl,-rpath are disappearing from linker options. Could someone to confirm, is this expected behavior? PS: Regardless of CFLAGS specified in command line or not, message() always prints: LINK_DIRS: /sysroot/usr/lib, so internally cmake sets this property. Thanks! Alexander -------------- next part -------------- An HTML attachment was scrubbed... URL: From Andreas-Naumann at gmx.net Thu Aug 28 14:08:02 2014 From: Andreas-Naumann at gmx.net (Andreas Naumann) Date: Thu, 28 Aug 2014 20:08:02 +0200 Subject: [CMake] CFLAGS disables link directories? In-Reply-To: References: Message-ID: <53FF7002.4020801@gmx.net> An HTML attachment was scrubbed... URL: From hobbes1069 at gmail.com Thu Aug 28 15:36:45 2014 From: hobbes1069 at gmail.com (Richard Shaw) Date: Thu, 28 Aug 2014 14:36:45 -0500 Subject: [CMake] Autotools->CMake build error Message-ID: I'm working on converting a project[1] from autotools to CMake and I've gotten a lot of it working. The project HEAVILY relies on values from a config.h but I think I've gotten the essentials covered although it took a while. Currently the build is failing on the following: [ 23%] Building CXX object src/CMakeFiles/fldigi.dir/widgets/FTextRXTX.cxx.o cd /home/build/tmp/build_fldigi/src && /usr/lib64/ccache/c++ -DBUILD_FLDIGI -DHAVE_CONFIG_H -DLOCALEDIR=\"/usr/local/share/locale\" -DPKGDATADIR=\"/usr/local/share\" -DUSE_HAMLIB -DUSE_PNG -DUSE_PORTAUDIO -DUSE_PULSEAUDIO -DUSE_SAMPLERATE -DUSE_SNDFILE -DUSE_X -Wall -ffast-math -finline-functions -I/usr/include/freetype2 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_THREAD_SAFE -D_REENTRANT -pthread -O3 -DNDEBUG -I/home/build/tmp/build_fldigi -I/home/build/git/fldigi/src/xmlrpcpp -I/home/build/git/fldigi/src/fileselector -I/home/build/git/fldigi/src/libtiniconv -I/home/build/git/fldigi/src/irrxml -I/home/build/git/fldigi/src/include -I/home/build/git/fldigi/src -I/usr/include/libpng16 -I/usr/include/alsa -I/home/build/tmp/build_fldigi/src -I/home/build/git/fldigi/src/flarq-src/include -o CMakeFiles/fldigi.dir/widgets/FTextRXTX.cxx.o -c /home/build/git/fldigi/src/widgets/FTextRXTX.cxx /home/build/git/fldigi/src/widgets/FTextRXTX.cxx:252:6: error: prototype for ?void FTextRX::add(unsigned int, int)? does not match any in class ?FTextRX? void FTextRX::add(unsigned int c, int attr) ^ In file included from /home/build/git/fldigi/src/include/fl_digi.h:34:0, from /home/build/git/fldigi/src/widgets/FTextRXTX.cxx:47: /home/build/git/fldigi/src/include/FTextRXTX.h:50:15: error: candidates are: virtual void FTextRX::add(const char*, int) virtual void add(const char *s, int attr = RECV) ^ /home/build/git/fldigi/src/include/FTextRXTX.h:49:15: error: virtual void FTextRX::add(unsigned char, int) virtual void add(unsigned char c, int attr = RECV); ^ --- end --- The automake line is: g++ -DHAVE_CONFIG_H -I. -DBUILD_FLDIGI -DLOCALEDIR=\"/usr/share/locale\" -I. -I./include -I./irrxml -I./libtiniconv -I./fileselector -I./xmlrpcpp -DPKGDATADIR=\"/usr/share/fldigi\" -pthread -I/usr/include/alsa -I/usr/include/freetype2 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_THREAD_SAFE -D_REENTRANT -D_REENTRANT -I/usr/include/libpng16 -pipe -Wall -fexceptions -O2 -ffast-math -finline-functions -DNDEBUG -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -c -o fldigi-FTextRXTX.o `test -f 'widgets/FTextRXTX.cxx' || echo './'`widgets/FTextRXTX.cxx --- end --- Besides a lot of extra flags enforced by Fedora, I can't seem to find the essential difference between the two. Can someone point me in the right direction? I was going to put in a link to my remote branch at sourceforge but I'm not able to push to it right now.... Thanks, Richard [1] http://www.w1hkj.com/Fldigi.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From kornel at lyx.org Thu Aug 28 16:39:48 2014 From: kornel at lyx.org (Kornel Benko) Date: Thu, 28 Aug 2014 22:39:48 +0200 Subject: [CMake] Autotools->CMake build error In-Reply-To: References: Message-ID: <13425977.Zn5cUgRmsp@amd64> Am Donnerstag, 28. August 2014 um 14:36:45, schrieb Richard Shaw > I'm working on converting a project[1] from autotools to CMake and I've > gotten a lot of it working. The project HEAVILY relies on values from a > config.h but I think I've gotten the essentials covered although it took a > while. > > Currently the build is failing on the following: > [ 23%] Building CXX object src/CMakeFiles/fldigi.dir/widgets/FTextRXTX.cxx.o > cd /home/build/tmp/build_fldigi/src && /usr/lib64/ccache/c++ > -DBUILD_FLDIGI -DHAVE_CONFIG_H -DLOCALEDIR=\"/usr/local/share/locale\" > -DPKGDATADIR=\"/usr/local/share\" -DUSE_HAMLIB -DUSE_PNG -DUSE_PORTAUDIO > -DUSE_PULSEAUDIO -DUSE_SAMPLERATE -DUSE_SNDFILE -DUSE_X -Wall -ffast-math > -finline-functions -I/usr/include/freetype2 -D_LARGEFILE_SOURCE > -D_LARGEFILE64_SOURCE -D_THREAD_SAFE -D_REENTRANT -pthread -O3 -DNDEBUG > -I/home/build/tmp/build_fldigi -I/home/build/git/fldigi/src/xmlrpcpp > -I/home/build/git/fldigi/src/fileselector > -I/home/build/git/fldigi/src/libtiniconv > -I/home/build/git/fldigi/src/irrxml -I/home/build/git/fldigi/src/include > -I/home/build/git/fldigi/src -I/usr/include/libpng16 -I/usr/include/alsa > -I/home/build/tmp/build_fldigi/src > -I/home/build/git/fldigi/src/flarq-src/include -o > CMakeFiles/fldigi.dir/widgets/FTextRXTX.cxx.o -c > /home/build/git/fldigi/src/widgets/FTextRXTX.cxx > /home/build/git/fldigi/src/widgets/FTextRXTX.cxx:252:6: error: prototype > for ?void FTextRX::add(unsigned int, int)? does not match any in class > ?FTextRX? > void FTextRX::add(unsigned int c, int attr) > ^ > In file included from /home/build/git/fldigi/src/include/fl_digi.h:34:0, > from /home/build/git/fldigi/src/widgets/FTextRXTX.cxx:47: > /home/build/git/fldigi/src/include/FTextRXTX.h:50:15: error: candidates > are: virtual void FTextRX::add(const char*, int) > virtual void add(const char *s, int attr = RECV) > ^ > /home/build/git/fldigi/src/include/FTextRXTX.h:49:15: error: > virtual void FTextRX::add(unsigned char, int) > virtual void add(unsigned char c, int attr = RECV); > ^ > --- end --- > > The automake line is: > g++ -DHAVE_CONFIG_H -I. -DBUILD_FLDIGI -DLOCALEDIR=\"/usr/share/locale\" > -I. -I./include -I./irrxml -I./libtiniconv -I./fileselector -I./xmlrpcpp > -DPKGDATADIR=\"/usr/share/fldigi\" -pthread -I/usr/include/alsa > -I/usr/include/freetype2 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE > -D_THREAD_SAFE -D_REENTRANT -D_REENTRANT -I/usr/include/libpng16 > -pipe -Wall -fexceptions -O2 -ffast-math -finline-functions -DNDEBUG -O2 > -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions > -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches > -m64 -mtune=generic -c -o fldigi-FTextRXTX.o `test -f > 'widgets/FTextRXTX.cxx' || echo './'`widgets/FTextRXTX.cxx > --- end --- > > Besides a lot of extra flags enforced by Fedora, I can't seem to find the > essential difference between the two. > > Can someone point me in the right direction? > > I was going to put in a link to my remote branch at sourceforge but I'm not > able to push to it right now.... > > Thanks, > Richard > > [1] http://www.w1hkj.com/Fldigi.html You use '-DHAVE_CONFIG_H', this means probably generated 'config.h'. Differences between generation of this file of automake/cmake? Kornel -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part. URL: From hobbes1069 at gmail.com Thu Aug 28 16:47:06 2014 From: hobbes1069 at gmail.com (Richard Shaw) Date: Thu, 28 Aug 2014 15:47:06 -0500 Subject: [CMake] Autotools->CMake build error In-Reply-To: <13425977.Zn5cUgRmsp@amd64> References: <13425977.Zn5cUgRmsp@amd64> Message-ID: On Thu, Aug 28, 2014 at 3:39 PM, Kornel Benko wrote: > You use '-DHAVE_CONFIG_H', this means probably generated 'config.h'. > Differences between generation of this file of automake/cmake? > > Could be but I think I found most of those. I tried browsing through the code and I didn't see any #if's that would affect what code is built but I can check again. Thanks, Richard -------------- next part -------------- An HTML attachment was scrubbed... URL: From kornel at lyx.org Thu Aug 28 17:07:02 2014 From: kornel at lyx.org (Kornel Benko) Date: Thu, 28 Aug 2014 23:07:02 +0200 Subject: [CMake] Autotools->CMake build error In-Reply-To: References: <13425977.Zn5cUgRmsp@amd64> Message-ID: <2252092.EnNcTfTH03@amd64> Am Donnerstag, 28. August 2014 um 15:47:06, schrieb Richard Shaw > On Thu, Aug 28, 2014 at 3:39 PM, Kornel Benko wrote: > > > You use '-DHAVE_CONFIG_H', this means probably generated 'config.h'. > > Differences between generation of this file of automake/cmake? > > > > Could be but I think I found most of those. I tried browsing through the > code and I didn't see any #if's that would affect what code is built but I > can check again. If your compiler is g++, you could try '-g3 -E' options to create preprocessed output. E.g.: # cd /home/build/tmp/build_fldigi/src # g++ -g3 -E -DHAVE_CONFIG_H ... /home/build/git/fldigi/src/widgets/FTextRXTX.cxx > FTextRXTX.i > > Thanks, > Richard Kornel -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part. URL: From hobbes1069 at gmail.com Thu Aug 28 17:09:40 2014 From: hobbes1069 at gmail.com (Richard Shaw) Date: Thu, 28 Aug 2014 16:09:40 -0500 Subject: [CMake] Autotools->CMake build error In-Reply-To: <2252092.EnNcTfTH03@amd64> References: <13425977.Zn5cUgRmsp@amd64> <2252092.EnNcTfTH03@amd64> Message-ID: On Thu, Aug 28, 2014 at 4:07 PM, Kornel Benko wrote: > Am Donnerstag, 28. August 2014 um 15:47:06, schrieb Richard Shaw < > hobbes1069 at gmail.com> > > On Thu, Aug 28, 2014 at 3:39 PM, Kornel Benko wrote: > > > > > You use '-DHAVE_CONFIG_H', this means probably generated 'config.h'. > > > Differences between generation of this file of automake/cmake? > You were right to begin with, I implemented all the HAVE_ stuff but missed a part where it had a conditional for what version of FLTK was being used. The FindFLTK module doesn't report the API version (fltk-config --api-version) and upstream doesn't plan on supporting versions <1.3 anymore so I just hardcoded it into config.h.in for now. Thanks, Richard -------------- next part -------------- An HTML attachment was scrubbed... URL: From loose at astron.nl Fri Aug 29 07:48:24 2014 From: loose at astron.nl (Marcel Loose) Date: Fri, 29 Aug 2014 13:48:24 +0200 Subject: [CMake] How to let CTest pass a signal (e.g. ctrl-c) to test program Message-ID: <54006888.9020608@astron.nl> Hi all, I noticed that CTest doesn't seem to pass (Unix) signals to the test(s) it is running. This is unfortunate, because some of my tests need to do some cleanup when they receive a signal like SIGHUP, SIGINT, SIGQUIT, or SIGTERM. When I run these tests manually from the command-line and interrupt them with Ctrl-C, cleanup is done properly. However, if I run them from CTest and interrupt them, cleanup is not done. Is there a way to let CTest pass these signals? Or is there another solution for this? Best regards, Marcel Loose. -------------- next part -------------- A non-text attachment was scrubbed... Name: loose.vcf Type: text/x-vcard Size: 292 bytes Desc: not available URL: From felix.schwitzer at gmx.at Fri Aug 29 17:27:01 2014 From: felix.schwitzer at gmx.at (felix) Date: Fri, 29 Aug 2014 14:27:01 -0700 (PDT) Subject: [CMake] Building project with Boost thread, TBB, OpenCV, QT, -lpthread missing In-Reply-To: <53FF1724.2010500@lanrules.de> References: <53FF1724.2010500@lanrules.de> Message-ID: <1409347621046-7588302.post@n2.nabble.com> see http://public.kitware.com/Bug/view.php?id=10692 -- View this message in context: http://cmake.3232098.n2.nabble.com/Building-project-with-Boost-thread-TBB-OpenCV-QT-lpthread-missing-tp7588292p7588302.html Sent from the CMake mailing list archive at Nabble.com. From gregsharp.geo at yahoo.com Fri Aug 29 17:33:07 2014 From: gregsharp.geo at yahoo.com (Gregory Sharp) Date: Fri, 29 Aug 2014 17:33:07 -0400 Subject: [CMake] InstallRequiredSystemLibraries and OpenMP (patch) Message-ID: <20140829173307.65fc4d06@sherbert.partners.org> Hi, We recently ran into a problem with creating downloadable packages that use OpenMP on Windows. The problem is that programs compiled with MSVC which use OpenMP require the vcomp${ver}.dll runtime library. Normally one would expect the InstallRequiredSystemLibraries module to copy this dll over, but it does not. I've uploaded a patch [1] that addresses this issue, and appreciate if this patch can be considered for inclusion in a future version of cmake. [1] http://www.cmake.org/Bug/view.php?id=15117 Thank you, Greg Sharp gregsharp at geocities.com From nautsch2 at gmail.com Fri Aug 29 17:38:59 2014 From: nautsch2 at gmail.com (Andre Naujoks) Date: Fri, 29 Aug 2014 23:38:59 +0200 Subject: [CMake] "make package_source" with only symlinks in a subdirectory fails In-Reply-To: <53E20438.4020909@gmail.com> References: <53E20438.4020909@gmail.com> Message-ID: <5400F2F3.70105@gmail.com> On 06.08.2014 12:32, Andre Naujoks wrote: > Hi. > > I reported this bug to the debian bug-tracker some time ago, but there > seems to be no activity regarding this. > So I report this here as well and hope for someone to respond. I created > a patch (see below), which works for me, > but might change things in a completely wrong place. > > I am on cmake version 2.8.12.1 (debian version 2.8.12.1-1.6) > > This is the text of the debian bug report > (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=749892): > > > > If I try to create a source package with cmake via CPack and "make > package_source" and there is a directory in the sources, that only > contains symlinks (only one in my case), the generation of the > source package fails with: > > CPack Error: Cannot create symlink: --> > > where source and destination are the file/symlink names of course. > > It seems CPack tries to create the paths for the destination only if > it copies files and not when creating symlinks. > > The following patch fixes this for me. I don't know, if this is > actually the right place to put this, but it should point to the > exact problem. > > > diff -Naur cmake-2.8.12.1_orig/Source/kwsys/SystemTools.cxx > cmake-2.8.12.1/Source/kwsys/SystemTools.cxx > --- cmake-2.8.12.1_orig/Source/kwsys/SystemTools.cxx 2013-11-05 > 20:07:23.000000000 +0100 > +++ cmake-2.8.12.1/Source/kwsys/SystemTools.cxx 2014-05-30 > 14:25:23.912154919 +0200 > @@ -2835,6 +2835,9 @@ > #else > bool SystemTools::CreateSymlink(const char* origName, const char* newName) > { > + kwsys_stl::string destination_dir = newName; > + destination_dir = GetFilenamePath(destination_dir); > + MakeDirectory(destination_dir.c_str()); > return symlink(origName, newName) >= 0; > } > #endif > > > > > Regards > Andre > Hi again. Attached is a small example which reproduces the problem. To reproduce: - Unpack the attached tar.gz. - create a "build" directory next to it - from inside the build directory issue the command: cmake ../cmake_make_package_source_error - then issue: make package_source The following error occurs for me: Run CPack packaging tool for source... CPack: Create package using TGZ CPack: Install projects CPack: - Install directory: /home/nautsch/test/cmake_make_package_source_error CPack Error: Cannot create symlink: tstlnk/thisishello.c--> ../hello.c CPack Error: Error when generating package: Project Makefile:75: recipe for target 'package_source' failed make: *** [package_source] Error 1 Regards nautsch -------------- next part -------------- A non-text attachment was scrubbed... Name: cmake_make_package_source_error.tar.gz Type: application/gzip Size: 416 bytes Desc: not available URL: From sergey.nikulov at gmail.com Fri Aug 29 17:41:43 2014 From: sergey.nikulov at gmail.com (Sergei Nikulov) Date: Sat, 30 Aug 2014 01:41:43 +0400 Subject: [CMake] Building project with Boost thread, TBB, OpenCV, QT, -lpthread missing In-Reply-To: <1409347621046-7588302.post@n2.nabble.com> References: <53FF1724.2010500@lanrules.de> <1409347621046-7588302.post@n2.nabble.com> Message-ID: 2014-08-30 1:27 GMT+04:00 felix : > see http://public.kitware.com/Bug/view.php?id=10692 > > AFAIR, to handle -lpthread switch following script can be used find_package(Threads REQUIRED) target_link_libraries(target-name ${CMAKE_THREAD_LIBS_INIT}) -- Best Regards, Sergei Nikulov -------------- next part -------------- An HTML attachment was scrubbed... URL: From max.savenkov at gmail.com Sat Aug 30 01:21:49 2014 From: max.savenkov at gmail.com (Max Savenkov) Date: Sat, 30 Aug 2014 09:21:49 +0400 Subject: [CMake] CMake, Visual Studio and cross-compilation. Message-ID: <54015F6D.1010001@gmail.com> Lately, there appeared some tools that allow C++ programmers to use Visual Studio for cross-compiling code for platforms other than Windows. I would very much like to generate projects that use these tools with CMake. There are two cases I'm primarily interested in: vs-android (and NVidia's VS addon that is based on it), which allows cross-compilation to Android vs-tool (https://github.com/juj/vs-tool), which allows cross-compilation into JavaScript using Emscripten Both work by adding a new Platform type to use in Visual Studio. As far as I understand, there is no way to generate Visual Studio solutions that support these new platforms presently (if there is one, please tell me). Depending on complexity of task, I'm maybe ready to get my hands dirty, but first I need some advice. Where should I start? Is there some kind of a guide about adding a new platform (it would be a new generator, wouldn't it?) to CMake? From nilsgladitz at gmail.com Sat Aug 30 04:38:44 2014 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Sat, 30 Aug 2014 10:38:44 +0200 Subject: [CMake] CMake, Visual Studio and cross-compilation. In-Reply-To: <54015F6D.1010001@gmail.com> References: <54015F6D.1010001@gmail.com> Message-ID: <54018D94.3040607@gmail.com> On 30.08.2014 07:21, Max Savenkov wrote: > > There are two cases I'm primarily interested in: > vs-android (and NVidia's VS addon that is based on it), which allows > cross-compilation to Android > vs-tool (https://github.com/juj/vs-tool), which allows > cross-compilation into JavaScript using Emscripten > > Both work by adding a new Platform type to use in Visual Studio. > > As far as I understand, there is no way to generate Visual Studio > solutions that support these new platforms presently (if there is one, > please tell me). The more recent Visual Studio generators (>=2010) support platform toolset selection with -T [1]. I don't know if or how well this works with the custom toolsets added by vs-tool but it might be worth a try. As for NVIDIA's NSight Tegra there seems to be: http://public.kitware.com/pipermail/cmake-developers/2014-July/010811.html Nils [1] http://www.cmake.org/cmake/help/v3.0/manual/cmake.1.html?highlight=toolset From max.savenkov at gmail.com Sat Aug 30 05:21:36 2014 From: max.savenkov at gmail.com (Max Savenkov) Date: Sat, 30 Aug 2014 13:21:36 +0400 Subject: [CMake] CMake, Visual Studio and cross-compilation. In-Reply-To: <54018D94.3040607@gmail.com> References: <54015F6D.1010001@gmail.com> <54018D94.3040607@gmail.com> Message-ID: <540197A0.9020109@gmail.com> Thank you. It's nice to see somebody already worked on NVidia NSight addition. As with -T option, it unfortunately does not help, since I not only need to choose a platform toolset, but an entirely different platform (like Win32 or x64, named "Emscripten"). From what I've read, there is no way to do it in CMake, short of adding ANOTHER generator, like they did with NSight, "Visual Studio 10 2010 Emscripten" or something. I don't like this, because multiplying number of generators by number of VS versions seems like an awful idea, but maybe it's OK, since project generation for Visual Studio is such a special case anyway... Guess I can try to create a patch similar to one for NSight, because vs-android (on which NSight is based) and vs-tool are fairly similar too... 30.08.2014 12:38, Nils Gladitz ?????: > On 30.08.2014 07:21, Max Savenkov wrote: >> >> There are two cases I'm primarily interested in: >> vs-android (and NVidia's VS addon that is based on it), which allows >> cross-compilation to Android >> vs-tool (https://github.com/juj/vs-tool), which allows >> cross-compilation into JavaScript using Emscripten >> >> Both work by adding a new Platform type to use in Visual Studio. >> >> As far as I understand, there is no way to generate Visual Studio >> solutions that support these new platforms presently (if there is >> one, please tell me). > > The more recent Visual Studio generators (>=2010) support platform > toolset selection with -T [1]. > I don't know if or how well this works with the custom toolsets added > by vs-tool but it might be worth a try. > > As for NVIDIA's NSight Tegra there seems to be: > http://public.kitware.com/pipermail/cmake-developers/2014-July/010811.html > > > Nils > > [1] > http://www.cmake.org/cmake/help/v3.0/manual/cmake.1.html?highlight=toolset > From hobbes1069 at gmail.com Sat Aug 30 10:18:26 2014 From: hobbes1069 at gmail.com (Richard Shaw) Date: Sat, 30 Aug 2014 09:18:26 -0500 Subject: [CMake] Autotools->cmake: Are these checks really needed anymore? Message-ID: In the project I'm converting to cmake there are a lot of checks for headers and functions I've reimplemented in cmake, but it seems a lot of autotools based programs do a lot of excessive checking and I don't want to implement stuff that can be safely assumed on most systems. Here's a snippet of the checks in question: # Checks for typedefs, structures, and compiler characteristics. #AC_C_CONST #AC_C_INLINE #AC_TYPE_INT16_T #AC_TYPE_INT32_T #AC_TYPE_INT64_T #AC_TYPE_INT8_T #AC_C_RESTRICT #AC_TYPE_SIZE_T #AC_HEADER_TIME #AC_STRUCT_TM #AC_TYPE_UINT16_T #AC_TYPE_UINT32_T #AC_TYPE_UINT64_T #AC_TYPE_UINT8_T #AC_C_VOLATILE Are they safe to skip? Thanks, Richard -------------- next part -------------- An HTML attachment was scrubbed... URL: From eike at sf-mail.de Sat Aug 30 10:30:15 2014 From: eike at sf-mail.de (Rolf Eike Beer) Date: Sat, 30 Aug 2014 16:30:15 +0200 Subject: [CMake] Autotools->cmake: Are these checks really needed anymore? In-Reply-To: References: Message-ID: <2235920.JMTDzZGepv@caliban.sf-tec.de> Am Samstag, 30. August 2014, 09:18:26 schrieb Richard Shaw: > In the project I'm converting to cmake there are a lot of checks for > headers and functions I've reimplemented in cmake, but it seems a lot of > autotools based programs do a lot of excessive checking and I don't want to > implement stuff that can be safely assumed on most systems. > > Here's a snippet of the checks in question: Just my personal view, YMMV > # Checks for typedefs, structures, and compiler characteristics. > #AC_C_CONST > #AC_C_INLINE I don't think you will find a compiler these days crappy enough to _not_ support them. > #AC_TYPE_INT16_T > #AC_TYPE_INT32_T > #AC_TYPE_INT64_T > #AC_TYPE_INT8_T > #AC_TYPE_UINT16_T > #AC_TYPE_UINT32_T > #AC_TYPE_UINT64_T > #AC_TYPE_UINT8_T This is basically "is there a usable " or . The latter you will find in newer versions of MSVC and everything else that understands recent C++, the former in every compiler supporting at least a decent level of C99, which _excludes_ MSVC for policy reasons that even MS will probably find hard to explain. So you usually don't check for these types but for the header. > #AC_STRUCT_TM > #AC_HEADER_TIME This should be safe on every Un*x-like system and even Windows IIRC. > #AC_TYPE_SIZE_T Should be there everywhere. > #AC_C_RESTRICT > #AC_C_VOLATILE I'm not sure if you should even think of using them. Especially volatile is often something that means "you are doing something scary". 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 chuck.atkins at kitware.com Sat Aug 30 11:32:01 2014 From: chuck.atkins at kitware.com (Chuck Atkins) Date: Sat, 30 Aug 2014 11:32:01 -0400 Subject: [CMake] Autotools->cmake: Are these checks really needed anymore? In-Reply-To: <2235920.JMTDzZGepv@caliban.sf-tec.de> References: <2235920.JMTDzZGepv@caliban.sf-tec.de> Message-ID: On Sat, Aug 30, 2014 at 10:30 AM, Rolf Eike Beer wrote: > > # Checks for typedefs, structures, and compiler characteristics. > > #AC_C_CONST > > #AC_C_INLINE > ... > > #AC_TYPE_SIZE_T > ... > > #AC_C_RESTRICT > > #AC_C_VOLATILE > These should be generally safe to assume > #AC_STRUCT_TM > > #AC_HEADER_TIME > Unless you're targeting embedded systems and / or microcontrollors then you shouldn't have a problem with these either, even still there's a good chance you'd have it. > #AC_TYPE_INT16_T > > #AC_TYPE_INT32_T > > #AC_TYPE_INT64_T > > #AC_TYPE_INT8_T > > #AC_TYPE_UINT16_T > > #AC_TYPE_UINT32_T > > #AC_TYPE_UINT64_T > > #AC_TYPE_UINT8_T > > This is basically "is there a usable " or . The latter > you > will find in newer versions of MSVC and everything else that understands > recent > C++, the former in every compiler supporting at least a decent level of > C99, > which _excludes_ MSVC for policy reasons that even MS will probably find > hard > to explain. So you usually don't check for these types but for the header. > Ugh, this is definitely one of those irritating Windows-isms. cstdint is guaranteed available in C++11, so if you require that then most of this goes away. stdint.h, as Rolf mentioned, wasn't available until VS2010, so if you can place that as a requirement then you're all set. You can restrict this in your top level cmake with something like this: if(MSVC_VERSION LESS 1700) message(FATAL_ERROR "Only Visual C++ 2010 or greater is supported") endif() However, if you do have to support older MSVC versions then this is a problem and you will need to either redefine the types or include your own stdint.h (bringing the header is usally easier), a commonly used one by numerous projects for porting unix -> windows can be found here: https://code.google.com/p/msinttypes/source/browse/trunk/stdint.h. -------------- next part -------------- An HTML attachment was scrubbed... URL: From post at hendrik-sattler.de Sat Aug 30 13:12:03 2014 From: post at hendrik-sattler.de (Hendrik Sattler) Date: Sat, 30 Aug 2014 19:12:03 +0200 Subject: [CMake] Autotools->cmake: Are these checks really needed anymore? In-Reply-To: References: Message-ID: <6a7a3432-cd0a-489b-904c-f7bd9c5574f4@email.android.com> On 30. August 2014 16:18:26 MESZ, Richard Shaw wrote: >In the project I'm converting to cmake there are a lot of checks for >headers and functions I've reimplemented in cmake, but it seems a lot >of >autotools based programs do a lot of excessive checking and I don't >want to >implement stuff that can be safely assumed on most systems. They actually do this checking because they are part of some standard macros. You should ask yourself if you actually use this information anywhere. I never check for header files that are usually part of the compiler or base system. The corner cases can often be easier handled in other ways than some strange checking in the build system. And this is still one of the most annoying thing about autotools. HS From post at hendrik-sattler.de Sat Aug 30 13:12:03 2014 From: post at hendrik-sattler.de (Hendrik Sattler) Date: Sat, 30 Aug 2014 19:12:03 +0200 Subject: [CMake] Autotools->cmake: Are these checks really needed anymore? In-Reply-To: References: Message-ID: <6a7a3432-cd0a-489b-904c-f7bd9c5574f4@email.android.com> On 30. August 2014 16:18:26 MESZ, Richard Shaw wrote: >In the project I'm converting to cmake there are a lot of checks for >headers and functions I've reimplemented in cmake, but it seems a lot >of >autotools based programs do a lot of excessive checking and I don't >want to >implement stuff that can be safely assumed on most systems. They actually do this checking because they are part of some standard macros. You should ask yourself if you actually use this information anywhere. I never check for header files that are usually part of the compiler or base system. The corner cases can often be easier handled in other ways than some strange checking in the build system. And this is still one of the most annoying thing about autotools. HS From dthomas at osrfoundation.org Sat Aug 30 14:13:19 2014 From: dthomas at osrfoundation.org (Dirk Thomas) Date: Sat, 30 Aug 2014 11:13:19 -0700 Subject: [CMake] Weird STREQUAL result Message-ID: I ran into weird behavior with STREQUAL and boiled it down to the following simple example: cmake_minimum_required(VERSION 2.8) if("f" STREQUAL "") # happens with CMake version 2.8.12.2 message(FATAL_ERROR "This should not be TRUE: 'f' STREQUAL '' ") endif() I would expect that the condition evaluates to FALSE since the two strings are obviously not equal. But in my case (using CMake 2.8.12.2 on Ubuntu 14.04) the condition evaluates to TRUE. Is this a known bug, should I fill a ticket for it or is that "expected" behavior? If it is the latter could someone please describe why that is the case? Thank you, - Dirk From dthomas at osrfoundation.org Sat Aug 30 14:21:32 2014 From: dthomas at osrfoundation.org (Dirk Thomas) Date: Sat, 30 Aug 2014 11:21:32 -0700 Subject: [CMake] Weird STREQUAL result In-Reply-To: References: Message-ID: I guess I asked the question without searching enough before. It indeed seems to be "indented behavior". Answering my own question with the following link: http://stackoverflow.com/questions/19982340/cmake-compare-to-empty-string-with-strequal-failed Sorry for the noise. - Dirk On Sat, Aug 30, 2014 at 11:13 AM, Dirk Thomas wrote: > I ran into weird behavior with STREQUAL and boiled it down to the > following simple example: > > cmake_minimum_required(VERSION 2.8) > if("f" STREQUAL "") > # happens with CMake version 2.8.12.2 > message(FATAL_ERROR "This should not be TRUE: 'f' STREQUAL '' ") > endif() > > I would expect that the condition evaluates to FALSE since the two > strings are obviously not equal. > But in my case (using CMake 2.8.12.2 on Ubuntu 14.04) the condition > evaluates to TRUE. > > Is this a known bug, should I fill a ticket for it or is that > "expected" behavior? > If it is the latter could someone please describe why that is the case? > > Thank you, > - Dirk From hobbes1069 at gmail.com Sat Aug 30 15:45:24 2014 From: hobbes1069 at gmail.com (Richard Shaw) Date: Sat, 30 Aug 2014 14:45:24 -0500 Subject: [CMake] Autotools->cmake: Are these checks really needed anymore? In-Reply-To: <6a7a3432-cd0a-489b-904c-f7bd9c5574f4@email.android.com> References: <6a7a3432-cd0a-489b-904c-f7bd9c5574f4@email.android.com> Message-ID: Thanks for the responses everyone. I'm just volunteering to change the build system on one of my favorite pieces of software so I don't know the code inside and out. As far as I know linux, windows, freebsd and OSX are supported for *running* but I believe the windows version is cross-compiled from Linux so no need to worry about MSVC. Thanks, Richard -------------- next part -------------- An HTML attachment was scrubbed... URL: From rleigh at codelibre.net Sat Aug 30 17:56:45 2014 From: rleigh at codelibre.net (Roger Leigh) Date: Sat, 30 Aug 2014 22:56:45 +0100 Subject: [CMake] Autotools->cmake: Are these checks really needed anymore? In-Reply-To: <2235920.JMTDzZGepv@caliban.sf-tec.de> References: <2235920.JMTDzZGepv@caliban.sf-tec.de> Message-ID: <20140830215645.GL7997@codelibre.net> On Sat, Aug 30, 2014 at 04:30:15PM +0200, Rolf Eike Beer wrote: > Am Samstag, 30. August 2014, 09:18:26 schrieb Richard Shaw: > > > #AC_C_RESTRICT > > #AC_C_VOLATILE > > I'm not sure if you should even think of using them. Especially volatile is > often something that means "you are doing something scary". If you're a strict C99 programmer, you might well be using restrict routinely. I certainly did before I migrated to mainly using C++, and if you look at the prototypes used by e.g. glibc you'll see restrict is used throughout. volatile is a little more scary, but you might well find you need it e.g. in signal handlers. The merits of either aside, these are standard language features and like all the other features in the list, they will be present if you're using a conforming compiler. As someone who made the same switch from autotools to cmake last year (and who wrote some of the C99 checks for autoconf in the first place!), I can't help but feel that autoconf is still trying to solve portability problems from two decades ago which have now been long solved. I stopped worrying about these details--all current compilers (modulo MSVC and C99 support) support all these features, so unless you really care about some long obsolete unsupported system, all this stuff is wasted effort except for maybe / in which case you can do something like: https://github.com/openmicroscopy/bioformats/blob/develop/cpp/lib/ome/compat/cstdint.h https://github.com/openmicroscopy/bioformats/blob/develop/cpp/lib/ome/compat/config.h.in https://github.com/openmicroscopy/bioformats/blob/develop/cpp/cmake/CompilerChecks.cmake Regards, 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 mkmi2015 at hotmail.com Sun Aug 31 12:18:38 2014 From: mkmi2015 at hotmail.com (Mo .) Date: Sun, 31 Aug 2014 18:18:38 +0200 Subject: [CMake] Error when bootstrapping CMake In-Reply-To: References: Message-ID: Hi, I am using a bootstrapped Synology 112j for building cmake 3.0.1, but the following error appears: make: `cmake' is up to date. loading initial cache file /volume1/homes/Mo/cmake-2.8.10/Bootstrap.cmk/InitialCacheFlags.cmake CMake Error at Utilities/cmcurl/CMake/OtherTests.cmake:89 (MESSAGE): Unable to link function recv Call Stack (most recent call first): Utilities/cmcurl/CMakeLists.txt:677 (INCLUDE) -- Configuring incomplete, errors occurred! --------------------------------------------- Error when bootstrapping CMake: Problem while running initial CMake --------------------------------------------- The log files can be found at https://dl.dropboxusercontent.com/u/63137351/cmake/CMakeError.log https://dl.dropboxusercontent.com/u/63137351/cmake/cmake.check_cache Could you help me please? What can I do? How can I solve it? Regards Mo -------------- next part -------------- An HTML attachment was scrubbed... URL: From irwin at beluga.phys.uvic.ca Sun Aug 31 15:43:44 2014 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Sun, 31 Aug 2014 12:43:44 -0700 (PDT) Subject: [CMake] --debug-trycompile not working as documented with the results being overwritten Message-ID: I have the usual try_compile debug scenario; all but one of them in my project (PLplot) is working (some with expected false results some with true), and I would like to debug the one that isn't working (the result is expected to be true, but it is false). The (CMake-2.8.12.1) documentation says: "If you use --debug-trycompile, you can only debug one try_compile call at a time. The recommended procedure is to configure with cmake all the way through once, then delete the cache entry associated with the try_compile call of interest, and then re-run cmake again with --debug-trycompile." I have followed exactly that procedure on Linux with CMake-2.8.12.1, but at least one of the PLplot build system's other try_compile calls is overwriting ./CMakeFiles/CMakeTmp/CMakeLists.txt so I cannot debug the try_compile I want to debug. Here are the details of all those different cached try_compile results. I run the following commands: software at raven> cmake \ -DCMAKE_INSTALL_PREFIX=/home/software/plplot/installcmake \ -DBUILD_TEST=ON ../plplot.git >& cmake.out edit CMakeCache to remove the two lines relevant to the try_compile I want to debug: //Result of TRY_COMPILE CONSISTENT_HEADER_ITCL_VERSION:INTERNAL=FALSE software at raven> cmake --debug-trycompile \ -DCMAKE_INSTALL_PREFIX=/home/software/plplot/installcmake -DBUILD_TEST=ON ../plplot.git >& cmake.out1 software at raven> grep -A1 TRY_COMPILE CMakeCache.txt //Result of TRY_COMPILE CMAKE_BROKEN_ISNAN_CXX:INTERNAL=TRUE -- //Result of TRY_COMPILE CMAKE_CXX_STDINT_H:INTERNAL=TRUE -- //Result of TRY_COMPILE CMAKE_D_TANGO_WORKS:INTERNAL=FALSE -- //Result of TRY_COMPILE CMAKE_FORTRAN_HAVE_ISNAN:INTERNAL=FALSE -- //Result of TRY_COMPILE CMAKE_HIGH_BIT_CHARACTERS:INTERNAL=TRUE -- //Result of TRY_COMPILE CMAKE_TEST_SIGNAL_TYPE:INTERNAL=TRUE -- //Result of TRY_COMPILE CMAKE_USE_NAMESPACE:INTERNAL=TRUE -- //Result of TRY_COMPILE CONSISTENT_HEADER_ITCL_VERSION:INTERNAL=FALSE //Result of TRY_COMPILE COMPILE_RESULT:INTERNAL=TRUE //Result of TRY_COMPILE CONSISTENT_HEADER_ITK_VERSION:INTERNAL=TRUE -- //Result of TRY_COMPILE HAVE_SAHOOKS:INTERNAL=TRUE By looking at CMakeFiles/CMakeTmp/CMakeLists.txt I have discovered it is the HAVE_SAHOOKS one that last overwrites the CMakeFiles/CMakeTmp/CMakeLists.txt file for the second CMake invocation. Also, notice that the one I removed, CONSISTENT_HEADER_ITCL_VERSION is restored indicating that try_compile was executed (and returned a failure which I am trying to debug, but I cannot do that with CMakeFiles/CMakeTmp/CMakeLists.txt being overwritten). The last time I had to debug a try_compile was years ago, but as far as I can remember in that case --debug-trycompile worked as documented. And technically --debug-trycompile works for this case as well (CMakeFiles/CMakeTmp/CMakeLists.txt is retained for each try_compile). But in practice it is useless because the other try_compiles are overwriting the results. Is there some known bugs for cmake-2.8.12.x such that try_compiles are repeated even if a cached result (whether true of false) is found for the resulting variable? (For what it is worth, note that HAVE_SAHOOKS is true above.) 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 cmake at eikel.org Sun Aug 31 16:15:37 2014 From: cmake at eikel.org (Benjamin Eikel) Date: Sun, 31 Aug 2014 20:15:37 +0000 Subject: [CMake] Find SDL In-Reply-To: References: <20140825123414.Horde.q_tU-hQN77HTEmcZoU8_Bw5@webmail.eikel.org> Message-ID: <20140831201537.Horde.3jL7W16pQAIVqp7-tGSpkg4@webmail.eikel.org> Hi Christer, Zitat von Christer Solskogen : > They are cross compiled for Windows (mingw-w64) which means that they have > different names (libSDL.dll.a for instance) but they are installed in > /opt/cross-mingw-w64/x86_64-w64-mingw32/{include,lib}. > > x86_64-w64-mingw32-gcc is using /home/solskogen/obj/cross-mingw-w64 as > sysroot. > cmake have no trouble finding png or zlib. > -- Found ZLIB: /opt/cross-mingw-w64/x86_64-w64-mingw32/lib/libz.a (found > version "1.2.8") > -- Found PNG: /opt/cross-mingw-w64/x86_64-w64-mingw32/lib/libpng.a (found > version "1.6.12") > I have created a small test [1] that downloads and builds SDL2, installs it, and builds a little test program using SDL2. For cross-compiling, I am using the mingw-w64 [2] compilers provided in Debian GNU/Linux. I use the FindSDL2 module that I posted to this mailing list some time ago [3, 4]. This module has no problem finding the SDL2 installation: -- Found SDL2: [? snip ?]/cmake-FindSDL-test/install/include/SDL2 (found suitable version "2.0.3", minimum required is "2.0.3") Have you also installed SDL2, or did you try to find the build directory? Kind regards Benjamin [1] https://github.com/eikel/CMake-FindSDL-Test [2] https://packages.debian.org/sid/mingw-w64 [3] http://www.cmake.org/pipermail/cmake/2013-August/055518.html [4] https://github.com/PADrend/Util/blob/master/cmake/FindSDL2.cmake From irwin at beluga.phys.uvic.ca Sun Aug 31 17:33:21 2014 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Sun, 31 Aug 2014 14:33:21 -0700 (PDT) Subject: [CMake] --debug-trycompile not working as documented with the results being overwritten In-Reply-To: References: Message-ID: On 2014-08-31 12:43-0700 Alan W. Irwin wrote: > I have the usual try_compile debug scenario; all but one of them in my > project (PLplot) is working (some with expected false results some with > true), > and I would like to debug the one that isn't working (the result > is expected to be true, but it is false). > > The (CMake-2.8.12.1) documentation says: > > "If you use --debug-trycompile, you can only debug one try_compile call > at a time. The recommended procedure is to configure with cmake all > the way through once, then delete the cache entry associated with the > try_compile call of interest, and then re-run cmake again with > --debug-trycompile." > > I have followed exactly that procedure on Linux with CMake-2.8.12.1, > but at least one of the PLplot build system's other try_compile calls is > overwriting ./CMakeFiles/CMakeTmp/CMakeLists.txt so I cannot debug > the try_compile I want to debug. > > Here are the details of all those different cached try_compile results. > I run the following commands: > > software at raven> cmake \ > -DCMAKE_INSTALL_PREFIX=/home/software/plplot/installcmake \ > -DBUILD_TEST=ON ../plplot.git >& cmake.out > > edit CMakeCache to remove the two lines relevant to the try_compile > I want to debug: > //Result of TRY_COMPILE > CONSISTENT_HEADER_ITCL_VERSION:INTERNAL=FALSE > > software at raven> cmake --debug-trycompile \ > -DCMAKE_INSTALL_PREFIX=/home/software/plplot/installcmake > -DBUILD_TEST=ON ../plplot.git >& cmake.out1 > > software at raven> grep -A1 TRY_COMPILE CMakeCache.txt > //Result of TRY_COMPILE > CMAKE_BROKEN_ISNAN_CXX:INTERNAL=TRUE > -- > //Result of TRY_COMPILE > CMAKE_CXX_STDINT_H:INTERNAL=TRUE > -- > //Result of TRY_COMPILE > CMAKE_D_TANGO_WORKS:INTERNAL=FALSE > -- > //Result of TRY_COMPILE > CMAKE_FORTRAN_HAVE_ISNAN:INTERNAL=FALSE > -- > //Result of TRY_COMPILE > CMAKE_HIGH_BIT_CHARACTERS:INTERNAL=TRUE > -- > //Result of TRY_COMPILE > CMAKE_TEST_SIGNAL_TYPE:INTERNAL=TRUE > -- > //Result of TRY_COMPILE > CMAKE_USE_NAMESPACE:INTERNAL=TRUE > -- > //Result of TRY_COMPILE > CONSISTENT_HEADER_ITCL_VERSION:INTERNAL=FALSE > //Result of TRY_COMPILE > COMPILE_RESULT:INTERNAL=TRUE > //Result of TRY_COMPILE > CONSISTENT_HEADER_ITK_VERSION:INTERNAL=TRUE > -- > //Result of TRY_COMPILE > HAVE_SAHOOKS:INTERNAL=TRUE > > By looking at CMakeFiles/CMakeTmp/CMakeLists.txt I have discovered it > is the HAVE_SAHOOKS one that last overwrites the > CMakeFiles/CMakeTmp/CMakeLists.txt file for the second CMake > invocation. Also, notice that the one I removed, > CONSISTENT_HEADER_ITCL_VERSION is restored indicating that try_compile > was executed (and returned a failure which I am trying to debug, but I > cannot do that with CMakeFiles/CMakeTmp/CMakeLists.txt being > overwritten). > > The last time I had to debug a try_compile was years ago, but as far > as I can remember in that case --debug-trycompile worked as > documented. And technically --debug-trycompile works for this case as > well (CMakeFiles/CMakeTmp/CMakeLists.txt is retained for each > try_compile). But in practice it is useless because the other > try_compiles are overwriting the results. Is there some known bugs > for cmake-2.8.12.x such that try_compiles are repeated even if a > cached result (whether true of false) is found for the resulting > variable? (For what it is worth, note that HAVE_SAHOOKS is true > above.) Some further information. The HAVE_SAHOOKS try_compile that keeps repeating regardless is implemented as follows: # See if shapelib is a modern version with access to SAHooks type. file(WRITE ${CMAKE_CURRENT_BINARY_DIR}/Check_SAHooks.c "#include void main(void){SAHooks sHooks;} " ) try_compile(HAVE_SAHOOKS ${CMAKE_BINARY_DIR} ${CMAKE_CURRENT_BINARY_DIR}/Check_SAHooks.c CMAKE_FLAGS "-DINCLUDE_DIRECTORIES:STRING=${SHAPELIB_INCLUDE_DIR}" ) I thought perhaps the repeat was caused by that "file(WRITE...." command rewriting out the file with a new date for the second cmake invocation, but I tried some if(NOT EXISTS ${CMAKE_CURRENT_BINARY_DIR}/Check_SAHooks.c) logic (which worked, that file was not redated on second cmake call), but the above try_compile still overwrites CMakeFiles/CMakeTmp/CMakeLists.txt for the second cmake invocation with --debug-trycompile. I would appreciate hearing from anyone here that has had success with debug try_compile for recent CMake versions when there is at least one other try_compile invocation that is interfering. For now, though, to work around what I am beginning to think is a cmake bug I am going to surround the entire block of above code with if(NOT DEFINED HAVE_SAHOOKS) (and similarly for any other try_compiles that are currently interfering with the one I want to debug). 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 mark.j.abraham at gmail.com Sun Aug 31 19:26:08 2014 From: mark.j.abraham at gmail.com (Mark Abraham) Date: Mon, 1 Sep 2014 01:26:08 +0200 Subject: [CMake] --debug-trycompile not working as documented with the results being overwritten In-Reply-To: References: Message-ID: Hi, Raw try_compile is not a great idiom for general use (though it is unclear why it is not working well for you). Using the Modules/Check*cmake gear is a much better option, e.g. with check_symbol_exists() Mark On Sun, Aug 31, 2014 at 11:33 PM, Alan W. Irwin wrote: > On 2014-08-31 12:43-0700 Alan W. Irwin wrote: > > I have the usual try_compile debug scenario; all but one of them in my >> project (PLplot) is working (some with expected false results some with >> true), >> and I would like to debug the one that isn't working (the result >> is expected to be true, but it is false). >> >> The (CMake-2.8.12.1) documentation says: >> >> "If you use --debug-trycompile, you can only debug one try_compile call >> at a time. The recommended procedure is to configure with cmake all >> the way through once, then delete the cache entry associated with the >> try_compile call of interest, and then re-run cmake again with >> --debug-trycompile." >> >> I have followed exactly that procedure on Linux with CMake-2.8.12.1, >> but at least one of the PLplot build system's other try_compile calls is >> overwriting ./CMakeFiles/CMakeTmp/CMakeLists.txt so I cannot debug >> the try_compile I want to debug. >> >> Here are the details of all those different cached try_compile results. >> I run the following commands: >> >> software at raven> cmake \ >> -DCMAKE_INSTALL_PREFIX=/home/software/plplot/installcmake \ >> -DBUILD_TEST=ON ../plplot.git >& cmake.out >> >> edit CMakeCache to remove the two lines relevant to the try_compile >> I want to debug: >> //Result of TRY_COMPILE >> CONSISTENT_HEADER_ITCL_VERSION:INTERNAL=FALSE >> >> software at raven> cmake --debug-trycompile \ >> -DCMAKE_INSTALL_PREFIX=/home/software/plplot/installcmake >> -DBUILD_TEST=ON ../plplot.git >& cmake.out1 >> >> software at raven> grep -A1 TRY_COMPILE CMakeCache.txt >> //Result of TRY_COMPILE >> CMAKE_BROKEN_ISNAN_CXX:INTERNAL=TRUE >> -- >> //Result of TRY_COMPILE >> CMAKE_CXX_STDINT_H:INTERNAL=TRUE >> -- >> //Result of TRY_COMPILE >> CMAKE_D_TANGO_WORKS:INTERNAL=FALSE >> -- >> //Result of TRY_COMPILE >> CMAKE_FORTRAN_HAVE_ISNAN:INTERNAL=FALSE >> -- >> //Result of TRY_COMPILE >> CMAKE_HIGH_BIT_CHARACTERS:INTERNAL=TRUE >> -- >> //Result of TRY_COMPILE >> CMAKE_TEST_SIGNAL_TYPE:INTERNAL=TRUE >> -- >> //Result of TRY_COMPILE >> CMAKE_USE_NAMESPACE:INTERNAL=TRUE >> -- >> //Result of TRY_COMPILE >> CONSISTENT_HEADER_ITCL_VERSION:INTERNAL=FALSE >> //Result of TRY_COMPILE >> COMPILE_RESULT:INTERNAL=TRUE >> //Result of TRY_COMPILE >> CONSISTENT_HEADER_ITK_VERSION:INTERNAL=TRUE >> -- >> //Result of TRY_COMPILE >> HAVE_SAHOOKS:INTERNAL=TRUE >> >> By looking at CMakeFiles/CMakeTmp/CMakeLists.txt I have discovered it >> is the HAVE_SAHOOKS one that last overwrites the >> CMakeFiles/CMakeTmp/CMakeLists.txt file for the second CMake >> invocation. Also, notice that the one I removed, >> CONSISTENT_HEADER_ITCL_VERSION is restored indicating that try_compile >> was executed (and returned a failure which I am trying to debug, but I >> cannot do that with CMakeFiles/CMakeTmp/CMakeLists.txt being >> overwritten). >> >> The last time I had to debug a try_compile was years ago, but as far >> as I can remember in that case --debug-trycompile worked as >> documented. And technically --debug-trycompile works for this case as >> well (CMakeFiles/CMakeTmp/CMakeLists.txt is retained for each >> try_compile). But in practice it is useless because the other >> try_compiles are overwriting the results. Is there some known bugs >> for cmake-2.8.12.x such that try_compiles are repeated even if a >> cached result (whether true of false) is found for the resulting >> variable? (For what it is worth, note that HAVE_SAHOOKS is true >> above.) >> > > Some further information. The HAVE_SAHOOKS try_compile that keeps > repeating > regardless is implemented as follows: > > # See if shapelib is a modern version with access to SAHooks type. > file(WRITE ${CMAKE_CURRENT_BINARY_DIR}/Check_SAHooks.c > "#include > void main(void){SAHooks sHooks;} > " > ) > try_compile(HAVE_SAHOOKS ${CMAKE_BINARY_DIR} > ${CMAKE_CURRENT_BINARY_DIR}/Check_SAHooks.c > CMAKE_FLAGS "-DINCLUDE_DIRECTORIES:STRING=${SHAPELIB_INCLUDE_DIR}" > ) > > I thought perhaps the repeat was caused by that "file(WRITE...." command > rewriting out the file with a new date for the second cmake > invocation, but I tried some > > if(NOT EXISTS ${CMAKE_CURRENT_BINARY_DIR}/Check_SAHooks.c) > > logic (which worked, that file was not redated on second cmake call), > but the above try_compile still overwrites CMakeFiles/CMakeTmp/ > CMakeLists.txt > for the second cmake invocation with --debug-trycompile. > > I would appreciate hearing from anyone here that has had success with > debug try_compile for recent CMake versions when there is at least one > other try_compile invocation that is interfering. > > For now, though, to work around what I am beginning to think is a > cmake bug I am going to surround the entire block of above code with > if(NOT DEFINED HAVE_SAHOOKS) (and similarly for any other try_compiles > that are currently interfering with the one I want to debug). > > > 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 > __________________________ > -- > > 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: