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
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'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 follo
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
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-top
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
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
> . 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
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 d