Re: [CMake] What is the default build type?
On Wed, Aug 2, 2017 at 4:18 PM, J Decker wrote:
>
> On Wed, Aug 2, 2017 at 8:55 AM, Marcus D. Hanwell
> wrote:
>>
>> On Wed, Aug 2, 2017 at 3:03 AM, Bo Zhou wrote:
>>>
>>> It depends on the Generator.
>>>
>>> To the Makefile, the actual type was controlled by the compiler options. If
>>> you don't specific any type, usually it means non-debug and
>>> non-optimization because the CMAKE_CXX_FLAGS is empty as default. This is
>>> critical, so usually people should specific the actual type they want to
>>> build.
>>>
>>> To the generator of the IDE, such as Visual Studio and Xcode, the
>>> CMAKE_BUILD_TYPE doesn't make sense but we have to use
>>> CMAKE_CONFIGURATION_TYPES, then CMake will create the several configuration
>>> sets for the IDE from the CMAKE_C|CXX_FLAGS_{CONFIG} .
>>
>>
>> This thread inspired me to write up how we have been doing it in some of the
>> projects I work on for quite a while now,
>>
>> https://blog.kitware.com/cmake-and-the-default-build-type/
>>
> These should use lower case 'debug' 'release' etc. Because if it's not VS,
> it's probably also not windows, and case matters.
>
No, camel case works just fine. I took a quick look and lowercase will
work, as well as all caps. I have used this for many years on Linux
builds with Makefile/Ninja without issue.
--
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
Re: [CMake] CMake 3.9 change to dependencies of object compilation
> . The Ninja generator has loosened the dependencies of object > compilation. Object compilation now depends only on custom targets and > custom commands associated with libraries on which the object's target > depends and no longer depends on the libraries themselves. Source > files in dependent targets may now compile without waiting for their > targets' dependencies to link. Correct. > We have a few cases where the object compilation really does depend on > the TARGET_FILE itself, e.g. > 1. An RC compiler embedding the resulting file of a custom target (I > think this one may still work, since custom targets appear to have > been exempted from the change) Correct, though this issue: https://gitlab.kitware.com/cmake/cmake/issues/17097 requests that that be fixed as well (though that is backwards compatible since the solution will likely involve ). > 2. MSVC's #import construct which needs the indirect dependencies > (dependencies of the #import-ed dependency) be registered, which is > handled as part of the target using add_custom_command(TARGET foo > POST_BUILD COMMAND ...) So there's an issue here that there's a dependency between your build rules which CMake doesn't know about (though I don't know #import well enough, the docs don't state where the information *goes*). When adding this custom command, you may use the `BYPRODUCTS` argument (introduced in 3.2.0) to let CMake know what's going on here. It only affects Ninja, but the other generators do target-level dependencies anyways. That output can then be depended on via `OBJECT_DEPENDS` and the dependency should link up properly. If it instead gets registered somewhere in the aether (as far as CMake is concerned), adding support for generator expressions to `OBJECT_DEPENDS` so that `$` may be used there would be the next solution. Making `POST_BUILD` write out a stamp file would also work and then using `OBJECT_DEPENDS` on that would also work. --Ben -- 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
[CMake] find_package(Threads) leads to CMake Error: TRY_RUN() invoked in cross-compiling mode
Hi, I tried to fix linux (p)thread usage on a proprietary, somewhat complex (300-400 cmake files, ca 30.000 lines) cmake project. We have CMAKE_TOOLCHAIN_FILEs for the cross compiling platforms. These set(CMAKE_SYSTEM_NAME Linux), CMAKE_C_FLAGS(-D_REENTRANT... CACHE STRING "" FORCE)) and so on. I like to see -pthread on gcc (g++4 and g++5) and if needed -lphtread. I now spent almost two days without success and hope I can get a bit help here. I learned that someone is supposed to use find_package(Threads REQUIRED) instead of specifying CMAKE_C_FLAGS. This works fine for a minimal CMakeLists.txt example (cmake version 3.6.2): cmake_minimum_required(VERSION 3.6) project(phello C CXX) set(CMAKE_THREAD_PREFER_PTHREAD TRUE) set(THREADS_PREFER_PTHREAD_FLAG TRUE) find_package(Threads REQUIRED) add_executable(phello phello.c) target_link_libraries(phello Threads::Threads) but the same fails when cross compiling: -- Looking for pthread.h -- Looking for pthread.h - found -- Looking for pthread_create -- Looking for pthread_create - not found -- Check if compiler accepts -pthread CMake Error: TRY_RUN() invoked in cross-compiling mode, please set the following cache variables appropriately: THREADS_PTHREAD_ARG (advanced) For details see /local/users/sdettmer/work/cmake-toolchain-1.4/threadtest/b2/TryRunResults.cmake -- Check if compiler accepts -pthread - no -- Found Threads: TRUE -- Configuring incomplete, errors occurred! See also "/local/users/sdettmer/work/cmake-toolchain-1.4/threadtest/b2/CMakeFiles/CMakeOutput.log". See also "/local/users/sdettmer/work/cmake-toolchain-1.4/threadtest/b2/CMakeFiles/CMakeError.log". and then no Makefile as expected: $ make make: *** No targets specified and no makefile found. Stop. If then I run cmake again without any change: -- Configuring done -- Generating done -- Build files have been written to: /local/users/sdettmer/work/cmake-toolchain-1.4/threadtest/b2 suddenly no error and then it even works: $ make VERBOSE=1 [...] /opt/xyzcross/x86-linux2/bin/powerpc-linux-gnu-gcc \ --sysroot=/opt/xyzcross/1.2.0.0/sysroots/xyz/sysroot \ -L/opt/xyzcross/1.2.0.0/sysroots/sysroot/lib \ -L/opt/xyzcross/1.2.0.0/sysroots/sysroot/usr/lib \ CMakeFiles/phello.dir/phello.c.o -o phello -pthread a behavior I don't understand. I think this is incorrect. I think, first, cmake should not TRY_RUN when crosscompiling, second, running cmake again should not generate different results. What do I wrong? How can I get it working correctly on first run? In CMakeFiles/CMakeError.log I see that linking fails without -pthread (undefined reference to `pthread_create') and then works when using -pthread, so actually looks like expected when assuming find_package(Threads) tries to check first whether -pthread is needed at all and then if it is working. However, the second run may treated as error: Determining if compiler accepts -pthread returned PLEASE_FILL_OUT-FAILED_TO_RUN instead of 2. The compiler had the following output: Change Dir: /local/users/sdettmer/work/cmake-toolchain-1.4/threadtest/b2/CMakeFiles/CMakeTmp Run Build Command:"/usr/bin/make" "cmTC_47cd8/fast" /usr/bin/make -f CMakeFiles/cmTC_47cd8.dir/build.make CMakeFiles/cmTC_47cd8.dir/build make[1]: Entering directory '/srv/local/sdettmer/work/cmake-toolchain-1.4/threadtest/b2/CMakeFiles/CMakeTmp' Building C object CMakeFiles/cmTC_47cd8.dir/CheckForPthreads.c.o /opt/xyzcross/x86-linux2/bin/powerpc-linux-gnu-gcc --sysroot=... -o CMakeFiles/cmTC_47cd8.dir/CheckForPthreads.c.o -c /usr/local/share/cmake-3.6/Modules/CheckForPthreads.c Linking C executable cmTC_47cd8 /usr/local/bin/cmake -E cmake_link_script CMakeFiles/cmTC_47cd8.dir/link.txt --verbose=1 /opt/xyzcross/x86-linux2/bin/powerpc-linux-gnu-gcc [...] CMakeFiles/cmTC_47cd8.dir/CheckForP threads.c.o -o cmTC_47cd8 -pthread make[1]: Leaving directory '/srv/local/sdettmer/work/cmake-toolchain-1.4/threadtest/b2/CMakeFiles/CMakeTmp' (blank lines + line wraps added by me) If I copy the mentioned gcc command to a shell and change only the file name (CheckForPthreads does not exist anymore, so I use an own pthread_create() main test), it works as expected, no output to console but $ file cmTC_47cd8 cmTC_47cd8: ELF 32-bit MSB executable, PowerPC or cisco 4500, version 1 (SYSV), dynamically linked, interpreter /lib/ld.so.1, for GNU/Linux 2.6.10, not stripped so compiler seems to work fine. What does "-pthread returned PLEASE_FILL_OUT-FAILED_TO_RUN instead of 2." mean? That I'm supposed to run the test binary on target and put the result in a CMakeFiles.txt variable? Any hints appreciated, Steffen TryRunResults.cmake: # This file was generated by CMake because it detected TRY_RUN() commands # in crosscompiling mode. It will be overwritten by the next CMake run. # Copy it to a safe location, set the variables to appropriate values # and use it then to
Re: [CMake] find_package(Threads) leads to CMake Error: TRY_RUN() invoked in cross-compiling mode
a small correction: On Thu, Aug 3, 2017 at 5:59 PM, Steffen Dettmer wrote: > Building C object CMakeFiles/cmTC_47cd8.dir/CheckForPthreads.c.o > /opt/xyzcross/x86-linux2/bin/powerpc-linux-gnu-gcc --sysroot=... >-o CMakeFiles/cmTC_47cd8.dir/CheckForPthreads.c.o -c > /usr/local/share/cmake-3.6/Modules/CheckForPthreads.c > > If I copy the mentioned gcc command to a shell and change only > the file name (CheckForPthreads does not exist anymore Ohh, of course the .c file still exists, just the directory for the .o file had been removed. When I create it, the compile and link commands from the ErrorLog both work fine. Steffen -- 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
[CMake] Change LTO Type in CMake 3.9 with Clang?
Testing the new LTO support in CMake 3.9, it appears that setting INTERPROCEDURAL_OPTIMIZATION to TRUE causes CMake to pass '-flto=thin' to Clang. Is it possible to instead have CMake pass '-flto=full' (or just '-flto') to Clang? 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
[CMake] Not able to find boost with cmake
I'm trying to build PCL which has boost as dependency. However, when I download boost and build it, cmake cannot find it through any way. I tried two version of boost, one is pre-build boost which was built by other person online and version is 1.61, another is one I downloaded whose version is 1.64. File structures of the two versions are the same: [XXX]/include/boost-1_64/boost is the include dir and [XXX]/lib is the bin dir I try to specify the Boost_INCLUDE_DIR to [XXX]/include/boost-1_64/boost, the messages in output window is attached (I turned Boost_DEBUG on). I'm on Window 10 and VS2017 Thanks, Jacob Zhong -- ?? Yuanxin Zhong ?? Dept. of Automotive Engineering, Tsinghua Univ. Ad:Haidian District, Beijing, P.R.China100084 Tel:+86 1733119 E-mail??cmp...@foxmail.com / zhongy...@mails.tsinghua.edu.cn-- 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
Re: [CMake] Not able to find boost with cmake
It's better not to use downloaded pre-built libraries, always build by yourself locally. Before using Boost with CMake, please check https://cmake.org/cmake/help/v3.0/module/FindBoost.html If you're trying to use static boost libraries build by MSVC with shared runtime, please make sure the following statements exist in the PCL. set(Boost_USE_STATIC_LIBS ON) set(Boost_USE_MULTITHREADED ON) set(Boost_USE_STATIC_RUNTIME OFF) Then if you properly set the Boost_INCLUDE_DIR, all the libraries should be ready then. On Fri, Aug 4, 2017 at 1:05 PM, 钟元鑫 wrote: > I'm trying to build PCL which has boost as dependency. However, when I > download boost and build it, cmake cannot find it through any way. > > I tried two version of boost, one is pre-build boost which was built by > other person online and version is 1.61, another is one I downloaded whose > version is 1.64. File structures of the two versions are the same: > [XXX]/include/boost-1_64/boost is the include dir and [XXX]/lib is the bin > dir > > I try to specify the Boost_INCLUDE_DIR to [XXX]/include/boost-1_64/boost, > the messages in output window is attached (I turned Boost_DEBUG on). > > I'm on Window 10 and VS2017 > > Thanks, > Jacob Zhong > > -- > 顺颂时祺 > > 钟元鑫 Yuanxin Zhong > 清华大学汽车工程系 Dept. of Automotive Engineering, Tsinghua Univ. > Ad:Haidian District, Beijing, P.R.China100084 > Tel:+86 1733119 <+86%20178%208883%203119> > E-mail：cmp...@foxmail.com / zhongyx > 1...@mails.tsinghua.edu.cn > > > -- > > 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
Re: [CMake] Change LTO Type in CMake 3.9 with Clang?
Not yet, but it is a known issue : https://gitlab.kitware.com/cmake/cmake/issues/16808 Le ven. 4 août 2017 à 06:03, Breannan Smith a écrit : > Testing the new LTO support in CMake 3.9, it appears that > setting INTERPROCEDURAL_OPTIMIZATION to TRUE causes CMake to pass > '-flto=thin' to Clang. Is it possible to instead have CMake pass > '-flto=full' (or just '-flto') to Clang? > > 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
Re: [CMake] What is the default build type?
Exactly. Also, CMAKE_CONFIGURATION_TYPES uses the CamelCase Versions by
default, so if your CMake code breaks with that spelling, your CMakeLists.txt
can be considered broken anyways...
Fraunhofer-Institut für Graphische Datenverarbeitung IGD
Fraunhoferstr. 5 | 64283 Darmstadt | Germany
Tel +49 6151 155-606 | Fax +49 6151 155-139
johannes.mueller-roe...@igd.fraunhofer.de | www.igd.fraunhofer.de
-Original Message-
From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Marcus D. Hanwell
Sent: Thursday, August 3, 2017 16:25
To: J Decker
Cc: cmake@cmake.org
Subject: Re: [CMake] What is the default build type?
On Wed, Aug 2, 2017 at 4:18 PM, J Decker wrote:
>
> On Wed, Aug 2, 2017 at 8:55 AM, Marcus D. Hanwell
> wrote:
>>
>> On Wed, Aug 2, 2017 at 3:03 AM, Bo Zhou wrote:
>>>
>>> It depends on the Generator.
>>>
>>> To the Makefile, the actual type was controlled by the compiler options. If
>>> you don't specific any type, usually it means non-debug and
>>> non-optimization because the CMAKE_CXX_FLAGS is empty as default. This is
>>> critical, so usually people should specific the actual type they want to
>>> build.
>>>
>>> To the generator of the IDE, such as Visual Studio and Xcode, the
>>> CMAKE_BUILD_TYPE doesn't make sense but we have to use
>>> CMAKE_CONFIGURATION_TYPES, then CMake will create the several configuration
>>> sets for the IDE from the CMAKE_C|CXX_FLAGS_{CONFIG} .
>>
>>
>> This thread inspired me to write up how we have been doing it in some
>> of the projects I work on for quite a while now,
>>
>> https://blog.kitware.com/cmake-and-the-default-build-type/
>>
> These should use lower case 'debug' 'release' etc. Because if it's not VS,
> it's probably also not windows, and case matters.
>
No, camel case works just fine. I took a quick look and lowercase will work, as
well as all caps. I have used this for many years on Linux builds with
Makefile/Ninja without issue.
--
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
