[CMake] Problem with try_compile() for iOS

[Eric Doenges]

Hi,

I'm currently testing CMake 3.14.2's iOS support with our build system 
and ran into a problem with try_compile() not finding the binary. Here 
is an example while trying to configure libjpeg-turbo 2.0.2 (I've 
shortened the paths to make this easier to read):


--- SNIP ---

-- Check size of size_t
CMake Error at share/cmake-3.14/Modules/CheckTypeSize.cmake:120 
(try_compile):

  Cannot copy output executable

    ''

  to destination specified by COPY_FILE:

'libjpegturbo_library-ext-build/CMakeFiles/CheckTypeSize/SIZE_T.bin'

  Unable to find the executable at any of:

    libjpegturbo_library-ext-build/CMakeFiles/CMakeTmp/cmTC_3f58e
libjpegturbo_library-ext-build/CMakeFiles/CMakeTmp/Debug/cmTC_3f58e
libjpegturbo_library-ext-build/CMakeFiles/CMakeTmp/Debug/cmTC_3f58e.app/cmTC_3f58e
libjpegturbo_library-ext-build/CMakeFiles/CMakeTmp/Development/cmTC_3f58e

Call Stack (most recent call first):
  share/cmake-3.14/Modules/CheckTypeSize.cmake:247 (__check_type_size_impl)
  CMakeLists.txt:362 (check_type_size)

--- SNIP ---

The problem is that the binary created by try_compile is located at 
libjpegturbo_library-ext-build/CMakeFiles/CMakeTmp/cmTC_3f58e.app, where 
cmake doesn't look. This happens with both the Unix Makefile and Ninja 
generators (since I don't use the Xcode generator I have no idea if it 
works there). The following patch to cmake fixes the problem:


--- SNIP ---

diff -uNr cmake-3.14.2.orig/Source/cmCoreTryCompile.cxx 
cmake-3.14.2/Source/cmCoreTryCompile.cxx
--- cmake-3.14.2.orig/Source/cmCoreTryCompile.cxx    2019-04-12 
14:10:08.0 +0200
+++ cmake-3.14.2/Source/cmCoreTryCompile.cxx    2019-04-15 
14:54:32.466161185 +0200

@@ -1040,8 +1040,12 @@
   }
   searchDirs.emplace_back("/Debug");
 #if defined(__APPLE__)
-  std::string app = "/Debug/" + targetName + ".app";
+  // When building for Darwin, iOS, etc., the test program may be an .app
+  // bundle, so look for those as well.
+  std::string app = "/" + targetName + ".app";
   searchDirs.push_back(std::move(app));
+  std::string appd = "/Debug/" + targetName + ".app";
+  searchDirs.push_back(std::move(appd));
 #endif
   searchDirs.emplace_back("/Development");

--- SNIP ---

So my question - is this a bug in CMake (the documentation says the 
Xcode generator is recommended, so I presume the other generators do not 
receive as much testing for iOS targets), or I am doing something 
fundamentally wrong ?


With kind regards,

Eric

--

*Dr. Eric Dönges *
Senior Software Engineer

MVTec Software GmbH | Arnulfstr. 205 | 80634 Munich | Germany
doen...@mvtec.com  | Tel: +49 89 457 695-0 | 
www.mvtec.com 


Sign up  for our MVTec Newsletter!

Geschäftsführer: Dr. Wolfgang Eckstein, Dr. Olaf Munkelt
Amtsgericht München HRB 114695

MVTec Software GmbH Logo
-- 

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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] Question about running C code from within cmake

[Eric Doenges]

The easiest way to get the number of cores on your Windows build machine 
from within CMake is to get the value of the NUMBER_OF_PROCESSORS 
environment variable using $ENV{NUMBER_OF_PROCESSORS}.


Am 02.06.19 um 14:16 schrieb Steven Truppe:


Hi everyone,


i'm trying to search for a way for win32 to get the cpu core count. i 
found the c code:


|SYSTEM_INFO sysinfo;GetSystemInfo();intnumCPU 
=sysinfo.dwNumberOfProcessors; Is there a way i can get the return 
value numCPU and create a variable out of it ? for apple and linux i 
allready have a solution only win32 is left. best regards! |



--

*Dr. Eric Dönges *
Senior Software Engineer

MVTec Software GmbH | Arnulfstr. 205 | 80634 Munich | Germany
doen...@mvtec.com  | Tel: +49 89 457 695-0 | 
www.mvtec.com 


Sign up  for our MVTec Newsletter!

Geschäftsführer: Dr. Wolfgang Eckstein, Dr. Olaf Munkelt
Amtsgericht München HRB 114695

MVTec Software GmbH Logo
-- 

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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] Troubles compiling llvm

[Eric Doenges]

To answer myself:

I just saw that you already set CMAKE_INSTALL_PREFIX, so ignore that 
part of my answer. Unfortunately, as far as I am aware it is not 
possible to split building with ExternalProject_Add into separate build 
and install steps, so your options essentially boil down to:


1) Give yourself write permissions for ${OUTPUT_PATH} and run the build. 
You should then probably remove write access for ${OUTPUT_PATH} again 
once you are done.


2) Run the entire build as root.

Since you should be doing as little as possible as root, I would 
strongly suggest option 1.


Am 23.05.19 um 11:28 schrieb Eric Doenges:


Hi Steven,

I would assume the problem is that you do not have write permissions 
for /usr/lib. You either need to give yourself the appropriate rights, 
our run the build as root (which is probably a very bad idea). If you 
don't want to actually install to /usr/lib, you can pass a different 
CMAKE_INSTALL_PREFIX to the build via ExternalProject_Add's CMAKE_ARGS 
argument, i.e. something like


ExternalProject_Add(xxx
  ...
  CMAKE_ARGS -DCMAKE_INSTALL_PREFIX=
  ...


Am 23.05.19 um 10:40 schrieb Steven Truppe:

Hi everyone,

i'm trying to compile llvm with ExternalProject_Add and get the
following error:

-- Installing: /usr/lib/ocaml/llvm/llvm.mli
CMake Error at bindings/ocaml/llvm/cmake_install.cmake:49 (file):
  file INSTALL cannot copy file
"/home/stuv/linux-projects/programming/bsEdit/build_files/Release/llvm/src/external_llvm-build/bindings/ocaml/llvm/llvm.mli" 


  to "/usr/lib/ocaml/llvm/llvm.mli".
Call Stack (most recent call first):
  bindings/ocaml/cmake_install.cmake:42 (include)
  cmake_install.cmake:64 (include)


Makefile:128: die Regel für Ziel „install“ scheiterte
make[3]: *** [install] Fehler 1
CMakeFiles/external_llvm.dir/build.make:73: die Regel für Ziel
„../build_files/Release/llvm/src/external_llvm-stamp/external_llvm-install“ 


scheiterte
make[2]: ***
[../build_files/Release/llvm/src/external_llvm-stamp/external_llvm-install] 


Fehler 2
CMakeFiles/Makefile2:72: die Regel für Ziel
„CMakeFiles/external_llvm.dir/all“ scheiterte
make[1]: *** [CMakeFiles/external_llvm.dir/all] Fehler 2
Makefile:83: die Regel für Ziel „all“ scheiterte
make: *** [all] Fehler 2

set(LLVM_EXTRA_ARGS
    -DLLVM_USE_CRT_RELEASE=MT
    -DLLVM_USE_CRT_DEBUG=MTd
    -DLLVM_INCLUDE_TESTS=OFF
    -DLLVM_TARGETS_TO_BUILD=X86
    -DLLVM_INCLUDE_EXAMPLES=OFF
    -DLLVM_ENABLE_TERMINFO=OFF
    -DLLVM_BUILD_EXAMPLES=ON
)

set(LLVM_GENERATOR "Unix Makefiles")


ExternalProject_Add(external_llvm
    URL ${LLVM_URL}
    DOWNLOAD_DIR download/llvm
    URL_HASH MD5=${LLVM_HASH}
    CMAKE_GENERATOR ${LLVM_GENERATOR}
    PREFIX ${OUTPUT_PATH}/llvm
    CMAKE_ARGS -DCMAKE_INSTALL_PREFIX=${OUTPUT_PATH}/llvm
${DEFAULT_CMAKE_FLAGS} ${LLVM_EXTRA_ARGS}
    INSTALL_DIR ${OUTPUT_PATH}/llvm
)

I followed the instructions from llvm.org but i still get this error
during installation (the build process works fine but during install i
get this error).


best regards!


--

*Dr. Eric Dönges *
Senior Software Engineer

MVTec Software GmbH | Arnulfstr. 205 | 80634 Munich | Germany
doen...@mvtec.com <mailto:doen...@mvtec.com> | Tel: +49 89 457 695-0 | 
www.mvtec.com <http://www.mvtec.com>


Sign up <http://www.mvtec.com/newsletter> for our MVTec Newsletter!

Geschäftsführer: Dr. Wolfgang Eckstein, Dr. Olaf Munkelt
Amtsgericht München HRB 114695

MVTec Software GmbH Logo


--

*Dr. Eric Dönges *
Senior Software Engineer

MVTec Software GmbH | Arnulfstr. 205 | 80634 Munich | Germany
doen...@mvtec.com <mailto:doen...@mvtec.com> | Tel: +49 89 457 695-0 | 
www.mvtec.com <http://www.mvtec.com>


Sign up <http://www.mvtec.com/newsletter> for our MVTec Newsletter!

Geschäftsführer: Dr. Wolfgang Eckstein, Dr. Olaf Munkelt
Amtsgericht München HRB 114695

MVTec Software GmbH Logo
-- 

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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] Troubles compiling llvm

[Eric Doenges]

Hi Steven,

I would assume the problem is that you do not have write permissions for 
/usr/lib. You either need to give yourself the appropriate rights, our 
run the build as root (which is probably a very bad idea). If you don't 
want to actually install to /usr/lib, you can pass a different 
CMAKE_INSTALL_PREFIX to the build via ExternalProject_Add's CMAKE_ARGS 
argument, i.e. something like


ExternalProject_Add(xxx
  ...
  CMAKE_ARGS -DCMAKE_INSTALL_PREFIX=
  ...


Am 23.05.19 um 10:40 schrieb Steven Truppe:

Hi everyone,

i'm trying to compile llvm with ExternalProject_Add and get the
following error:

-- Installing: /usr/lib/ocaml/llvm/llvm.mli
CMake Error at bindings/ocaml/llvm/cmake_install.cmake:49 (file):
  file INSTALL cannot copy file
"/home/stuv/linux-projects/programming/bsEdit/build_files/Release/llvm/src/external_llvm-build/bindings/ocaml/llvm/llvm.mli" 


  to "/usr/lib/ocaml/llvm/llvm.mli".
Call Stack (most recent call first):
  bindings/ocaml/cmake_install.cmake:42 (include)
  cmake_install.cmake:64 (include)


Makefile:128: die Regel für Ziel „install“ scheiterte
make[3]: *** [install] Fehler 1
CMakeFiles/external_llvm.dir/build.make:73: die Regel für Ziel
„../build_files/Release/llvm/src/external_llvm-stamp/external_llvm-install“ 


scheiterte
make[2]: ***
[../build_files/Release/llvm/src/external_llvm-stamp/external_llvm-install] 


Fehler 2
CMakeFiles/Makefile2:72: die Regel für Ziel
„CMakeFiles/external_llvm.dir/all“ scheiterte
make[1]: *** [CMakeFiles/external_llvm.dir/all] Fehler 2
Makefile:83: die Regel für Ziel „all“ scheiterte
make: *** [all] Fehler 2

set(LLVM_EXTRA_ARGS
    -DLLVM_USE_CRT_RELEASE=MT
    -DLLVM_USE_CRT_DEBUG=MTd
    -DLLVM_INCLUDE_TESTS=OFF
    -DLLVM_TARGETS_TO_BUILD=X86
    -DLLVM_INCLUDE_EXAMPLES=OFF
    -DLLVM_ENABLE_TERMINFO=OFF
    -DLLVM_BUILD_EXAMPLES=ON
)

set(LLVM_GENERATOR "Unix Makefiles")


ExternalProject_Add(external_llvm
    URL ${LLVM_URL}
    DOWNLOAD_DIR download/llvm
    URL_HASH MD5=${LLVM_HASH}
    CMAKE_GENERATOR ${LLVM_GENERATOR}
    PREFIX ${OUTPUT_PATH}/llvm
    CMAKE_ARGS -DCMAKE_INSTALL_PREFIX=${OUTPUT_PATH}/llvm
${DEFAULT_CMAKE_FLAGS} ${LLVM_EXTRA_ARGS}
    INSTALL_DIR ${OUTPUT_PATH}/llvm
)

I followed the instructions from llvm.org but i still get this error
during installation (the build process works fine but during install i
get this error).


best regards!


--

*Dr. Eric Dönges *
Senior Software Engineer

MVTec Software GmbH | Arnulfstr. 205 | 80634 Munich | Germany
doen...@mvtec.com  | Tel: +49 89 457 695-0 | 
www.mvtec.com 


Sign up  for our MVTec Newsletter!

Geschäftsführer: Dr. Wolfgang Eckstein, Dr. Olaf Munkelt
Amtsgericht München HRB 114695

MVTec Software GmbH Logo
-- 

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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] Embedded build using ExternalProject

[Eric Doenges]

Am 26.06.19 um 15:53 schrieb Torsten Robitzki:

A third issue that I have is, that changes to the CMakeLists.txt files in the 
Project are not reflected by the super build. If I make a change to one of the 
CMake files under ${CMAKE_CURRENT_LIST_DIR}/source, I usually have to delete 
the whole build folder and start from scratch with the build. Is there an other 
way to force the super build to recognize the changes? (Note: 
${CMAKE_CURRENT_LIST_DIR}/source is not added as subdirectory to the top level 
(super build) CMakeLists.txt).


I can't help you with your other issues, but I believe the solution to 
this problem is to specify "BUILD_ALWAYS TRUE" in your 
ExternalProject_Add. From the documentation for ExternalProject_Add:


Enabling this option forces the build step to always be run. This can be 
the easiest way to robustly ensure that the external project’s own build 
dependencies are evaluated rather than relying on the default success 
timestamp-based method. This option is not normally needed unless 
developers are expected to modify something the external project’s build 
depends on in a way that is not detectable via the step target 
dependencies (e.g. |SOURCE_DIR| is used without a download method and 
developers might modify the sources in |SOURCE_DIR|).


--

*Dr. Eric Dönges *
Senior Software Engineer

MVTec Software GmbH | Arnulfstr. 205 | 80634 Munich | Germany
doen...@mvtec.com  | Tel: +49 89 457 695-0 | 
www.mvtec.com 


Sign up  for our MVTec Newsletter!

Geschäftsführer: Dr. Wolfgang Eckstein, Dr. Olaf Munkelt
Amtsgericht München HRB 114695

MVTec Software GmbH Logo
-- 

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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] modify cmake build arguments

[Eric Doenges]

  
  
On 29.08.2019 22:38, fdk17 wrote:


  
  
  
  On Thu, Aug 29, 2019, at 2:52 PM, Kyle Edwards via CMake
wrote:
  
  
On Thu, 2019-08-29 at 18:27 +0100, hex wrote:

> hello community,

> 

> CMake builds a C project with gcc -o target_name. I
  have a compiler

> very similar to GCC and I am trying configure CMake C
  language for

> it.

> 

> The compiler does not support the -o argument when
  linking objects. I

> wonder if there is a way to remove or modify this
  argument, maybe

> through one of the properties on targets?

> 

> thank you



Your best bet would be to modify the CMake source code to
  support your

compiler. (Upstreaming your changes would be welcome.)



As a matter of interest, what does it use instead of -o?



Kyle

  
  
  
  If you are using the Makefile generator then try:
  
  https://cmake.org/cmake/help/latest/variable/CMAKE_USER_MAKE_RULES_OVERRIDE.html
  
  You may then be able to provide the rules needed, refer to
"Modules/CMakeCInformation.cmake".
  
  The way I understand it is that the rule templates are used
by the Makefile generator.
  
  
  
  
  

The way I understand the documentation,
  CMAKE_USER_MAKE_RULES_OVERRIDE applies for all generators, not
  just the Makefile one. What you are apparently supposed to do is
  create a file that sets all the "rule variables" as required (in
  this case, CMAKE_C_COMPILE_OBJECT), and then include that file via
  CMAKE_USER_MAKE_RULES_OVERRIDE. I'm not sure if these 'rule
  variables' are documented anywhere - but you can look into
  "/share/cmake-/Modules/Compiler" for
  inspiration. Another good starting point would be
"<...>/share/cmake-/Modules/CMakeCInformation.cmake".

With kind regards,
  Eric

  

Dr. Eric Dönges
  
  Senior Software Engineer

MVTec Software
  GmbH | Arnulfstr. 205 | 80634 Munich | Germany
  doen...@mvtec.com
  | Tel: +49 89 457 695-0 | www.mvtec.com

 Sign up for our
  MVTec Newsletter!
Geschäftsführer:
  Dr. Wolfgang Eckstein, Dr. Olaf Munkelt
  Amtsgericht München HRB 114695
 


  

-- 

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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] external project CONFIGURE_COMMAND adds quotation to arguments

[Eric Doenges]

  
  
On 04.09.2019 11:55, Edoardo Pasca wrote:

  
  Dear all, 


I'm using ExternalProjectAdd to build an
  external package. 


On the CONFIGURE_COMMAND I have to pass
  some variables to the configure script in this form:


configure CPPFLAGS="-I/dir/include
  -L/dir/lib" 


To do this I use 


CONFIGURE_COMMAND ${CMAKE_COMMAND} -E
  env ${CMAKE_BINARY_DIR}/configure CPPFLAGS="-I/dir/include
  -L/dir/lib" 


However, when cmake issues that command
  (you can see that with make VERBOSE=1) it wraps the CPPFLAGS
  parameters with quotation marks (as below) and the configure
  script fails

  
configure
  "CPPFLAGS=\"-I/dir/include -L/dir/lib\""


Below you can find
  a minimal CMakeLists.txt to test this. 


I'd appreciate any
  help on how I'd remove those quotation marks.
 
Thanks


Edo
  

  



What I do is let CMake handle this
  itself by defining a (list) variable for the configure command:



set(cmd
  "${CMAKE_BINARY_DIR}/configure")
list(APPEND cmd
  "CPPFLAGS=-I/dir/include -L/dir/lib")
ExternalProject_Add(...
  CONFIGURE_COMMAND ${CMAKE_COMMAND} -E
  env ${cmd}
  ...)


Since cmd is a list, CMake knows that
  the -L/dir/lib belongs to the CPPFLAGS=-I/dir/include part, and
  puts double quotes around the entire thing, e.g. the actual
  command line will look something like this:

/configure "CPPFLAG=-Idir/include -L/dir/lib"

This works with GNU autoconf. I've
  found that in general, dealing with quoting in ExternalProject_Add
  is a gigantic pain, so if the method above is not sufficient, I
  use configure_file or file(WRITE) to generate a shell script
  (Linux) or batch file (Windows) with the correct parameters and
  call that instead.

With kind regards,
  Eric Dönges


  
Dr. Eric Dönges
  
  Senior Software Engineer

MVTec Software
  GmbH | Arnulfstr. 205 | 80634 Munich | Germany
  doen...@mvtec.com
  | Tel: +49 89 457 695-0 | www.mvtec.com

 Sign up for our
  MVTec Newsletter!
Geschäftsführer:
  Dr. Wolfgang Eckstein, Dr. Olaf Munkelt
  Amtsgericht München HRB 114695
 


  

-- 

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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] toolchain file - cross-compiling windows-amd64->windows-x86

[Eric Doenges]

We use ninja for building on Windows. Our toolchain file for the MSVC 
compiler is really simple (this is for MSVC 18.0, 32 bits):


--- SNIP ---

set(CMAKE_SYSTEM_NAME Windows)
set(CMAKE_SYSTEM_PROCESSOR "x86")
set(CMAKE_SYSTEM_VERSION 1)

# Microsoft MSVC compiler
set(CMAKE_C_COMPILER cl.exe)
set(CMAKE_CXX_COMPILER cl.exe)

# Unfortunatly CMake doesn't seem to know anything about the MSVC compiler,
# so tell CMake that cl.exe supports C99
set(CMAKE_C_COMPILE_FEATURES c_std_99)

# If Visual Studio is selected as generator, only allow VS 2013
if(CMAKE_GENERATOR MATCHES "Visual Studio")
  if(NOT CMAKE_GENERATOR MATCHES "Visual Studio 12 2013")
    message(FATAL_ERROR "Visual Studio generator requires Visual Studio 
12 2013"

  " for this configuration")
  else()
    # Enable parallel builds for Visual Studio Projects with the /MP flag
    set(_MP_FLAG "/MP")
  endif()
endif()

set(CMAKE_C_FLAGS_INIT   "/arch:SSE2 ${_MP_FLAG} /EHsc")
set(CMAKE_CXX_FLAGS_INIT "/arch:SSE2 ${_MP_FLAG}")

--- SNIP ---

However, there is a major snag (naturally, since we're talking about 
Windows here) - in order for the Microsoft compiler to work from the 
command line, you need to set the correct environment, and CMake doesn't 
really give you a good way to do this. You can set environment variables 
from CMake, but as the documentation says "This command affects only the 
current CMake process, not the process from which CMake was called, nor 
the system environment at large, nor the environment of subsequent build 
or test processes.".


The solution we use is instead of calling cmake directly, we call a Perl 
script that sets up the environment correctly and then calls cmake for 
configuration or building. An alternative solution would be to write a 
batch script wrapper for cl.exe, something like.


@ECHO OFF
"C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\vcvarsall.bat" x86
cl.exe %*

and then set this batch script as the C and C++ compiler in CMake (note 
that this is untested - I think it should work, but it may need some 
extra work).


With kind regards,
Eric

Am 17.09.19 um 21:46 schrieb fdk17:
As I recall for myself, simply using the Visual Studio Generator with 
the -A option was all that was needed to build for Win32.
You don't need a toolchain file because the generator already knows 
how to setup a Visual Studio Project to target Win32.
Even the documentation for cross-compiling doesn't show a need to 
setup toolchain file for cross compiling in this case.


I personally never seen anyone try to use the Ninja generator via 
command line CMake and use the cl.exe compiler.
I've only seen that using Visual Studio to open a CMakeLists.txt file 
it can produce a Ninja project.  But even MS documentation states that 
it doesn't always work.


https://stackoverflow.com/questions/31262342/cmake-g-ninja-on-windows-specify-x64
This says you should be able to open the proper development window and 
use Ninja.


The output shows that in the environment you are using it doesn't even 
know how to use cl.exe to even determine with compiler it is.  Maybe 
not all the proper environment variables and paths are being set 
correctly when using the compiler.


--
F

--

*Dr. Eric Dönges*
Senior Software Engineer

MVTec Software GmbH | Arnulfstr. 205 | 80634 Munich | Germany
doen...@mvtec.com  | Tel: +49 89 457 695-0 
| www.mvtec.com 


Find our privacy policy here .

Sign up  for our MVTec Newsletter!

Geschäftsführer: Dr. Wolfgang Eckstein, Dr. Olaf Munkelt
Amtsgericht München HRB 114695

MVTec Software GmbH Logo
-- 

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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] toolchain file - cross-compiling windows-amd64->windows-x86

[Eric Doenges]

If the environment is set up correctly, the MSVC tools should be able to 
find the correct versions of the runtime libraries automatically. If you 
are using the wrapper script approach, the problem is most likely that 
when using MSVC, linking is done by calling the linker directly instead 
of indirectly via the compiler driver (as is common on Unix-like 
systems). So you also need a wrapper for link.exe that sets up the 
environment, and tell CMake to use that by setting CMAKE_LINKER to the 
name of the wrapper script.


With kind regards,
Eric

Am 18.09.19 um 18:39 schrieb Joao Pedro Abreu De Souza:
Cool. I try using this toolchain in a toy project, just to test, and 
execute the cmake inside cross-compiling x64_x86 from visual studio 
2017 and all work as expected, except the linking from ninja, that 
break because cannot find printf.
Is absolutely cool, better than my last toolchain. Do you know how Can 
I link with libc from visual studio 2013(that was your example)? From 
location on 2013, the 2017 can be deduced, I think.


To make clear, when I said how to link with libc, is literally the 
path that I don't know , I know that must use libpath(or set LIB 
env variable) with the path, but what path? kkk


Em qua, 18 de set de 2019 às 02:50, Eric Doenges <mailto:doen...@mvtec.com>> escreveu:


We use ninja for building on Windows. Our toolchain file for the
MSVC compiler is really simple (this is for MSVC 18.0, 32 bits):

--- SNIP ---

set(CMAKE_SYSTEM_NAME Windows)
set(CMAKE_SYSTEM_PROCESSOR "x86")
set(CMAKE_SYSTEM_VERSION 1)

# Microsoft MSVC compiler
set(CMAKE_C_COMPILER cl.exe)
set(CMAKE_CXX_COMPILER cl.exe)

# Unfortunatly CMake doesn't seem to know anything about the MSVC
compiler,
# so tell CMake that cl.exe supports C99
set(CMAKE_C_COMPILE_FEATURES c_std_99)

# If Visual Studio is selected as generator, only allow VS 2013
if(CMAKE_GENERATOR MATCHES "Visual Studio")
  if(NOT CMAKE_GENERATOR MATCHES "Visual Studio 12 2013")
    message(FATAL_ERROR "Visual Studio generator requires Visual
Studio 12 2013"
  " for this configuration")
  else()
    # Enable parallel builds for Visual Studio Projects with the
/MP flag
    set(_MP_FLAG "/MP")
  endif()
endif()

set(CMAKE_C_FLAGS_INIT   "/arch:SSE2 ${_MP_FLAG} /EHsc")
set(CMAKE_CXX_FLAGS_INIT "/arch:SSE2 ${_MP_FLAG}")

--- SNIP ---

However, there is a major snag (naturally, since we're talking
about Windows here) - in order for the Microsoft compiler to work
from the command line, you need to set the correct environment,
and CMake doesn't really give you a good way to do this. You can
set environment variables from CMake, but as the documentation
says "This command affects only the current CMake process, not the
process from which CMake was called, nor the system environment at
large, nor the environment of subsequent build or test processes.".

The solution we use is instead of calling cmake directly, we call
a Perl script that sets up the environment correctly and then
calls cmake for configuration or building. An alternative solution
would be to write a batch script wrapper for cl.exe, something like.

@ECHO OFF
"C:\Program Files (x86)\Microsoft Visual Studio
12.0\VC\vcvarsall.bat" x86
cl.exe %*

and then set this batch script as the C and C++ compiler in CMake
(note that this is untested - I think it should work, but it may
need some extra work).

With kind regards,
Eric

Am 17.09.19 um 21:46 schrieb fdk17:

As I recall for myself, simply using the Visual Studio Generator
with the -A option was all that was needed to build for Win32.
You don't need a toolchain file because the generator already
knows how to setup a Visual Studio Project to target Win32.
Even the documentation for cross-compiling doesn't show a need to
setup toolchain file for cross compiling in this case.

I personally never seen anyone try to use the Ninja generator via
command line CMake and use the cl.exe compiler.
I've only seen that using Visual Studio to open a CMakeLists.txt
file it can produce a Ninja project.  But even MS documentation
states that it doesn't always work.


https://stackoverflow.com/questions/31262342/cmake-g-ninja-on-windows-specify-x64
This says you should be able to open the proper development
window and use Ninja.

The output shows that in the environment you are using it doesn't
even know how to use cl.exe to even determine with compiler it
is.  Maybe not all the proper environment variables and paths are
being set correctly when using the compiler.

--
F
-- 


*Dr. Eric Dönges*
Senior Software Engineer

MVTec Software GmbH | Arnulfstr.

Re: [CMake] find_file - strange behavior when using Android toolchain

[Eric Doenges]

Am 31.07.19 um 08:20 schrieb Stephan Menzel:

Hello all,

I'm trying to adapt my CMake based toolchain to Android and I'm 
noticing very strange behavior that I'd like to ask about.
My toolchain is C++ based with some dependencies such as Boost, 
OpenSSL or protobuf. So far it works on a variety of platforms such as 
Windows (MSVC), several Linuxes, including Raspbian on ARM. So I 
considered myself well prepared for Android, thinking it can't be that 
different. How wrong I was... I'm cross compiling from a Linux system, 
which is able to build the source in question just fine with clang and 
gcc. Most recent Android SDK and bundled NDK.


As soon as I started building and finding my 3rd party dependencies I 
noticed that many commands in my own scripts or others that try to 
find a file (like a header) or a lib fail despite the file being there.
Like here in this case for example (randomly taken from the AWS SDK 
installed CMake finders):


My experience has been that find_file and friends behave in unexpected 
ways when you set CMAKE_SYSROOT. In our toolchain files, we set


set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY)

as suggested in the cmake-toolchains(7) documentation. We then add the 
path to the top-level directory where we keep all our thirdparty 
dependencies to CMAKE_FIND_ROOT_PATH, as otherwise find_package and 
find_path cannot find anything even when we give them the absolute path 
where to search (the find_file documentation suggests that the elements 
of the CMAKE_FIND_ROOT_PATH are prepended to the paths specified in the 
find_file arguments, but that does not seem to happen if the search 
paths are subpaths of the CMAKE_FIND_ROOT_PATH). My guess would be that 
the NDK does something similar, meaning you would need to add the path 
where to look for AWS to CMAKE_FIND_ROOT_PATH.


CMake feature request: it would be real nice to have a verbose mode for 
the find_XXX functions that tell you exactly where CMake is looking for 
stuff and why to help debug problems like this.


With kind regards,
Eric

--

*Dr. Eric Dönges *
Senior Software Engineer

MVTec Software GmbH | Arnulfstr. 205 | 80634 Munich | Germany
doen...@mvtec.com  | Tel: +49 89 457 695-0 | 
www.mvtec.com 


Sign up  for our MVTec Newsletter!

Geschäftsführer: Dr. Wolfgang Eckstein, Dr. Olaf Munkelt
Amtsgericht München HRB 114695

MVTec Software GmbH Logo
-- 

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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] question about version details in source code

[Eric Doenges]

Am 17.07.19 um 15:38 schrieb hex:


hello community,

I am receiving a|fatal error: foobar_version.h: No such file or 
directory|for|foobar_version.h|. The reason is that the source file is 
generated in|${CMAKE_CURRENT_BINARY_DIR}/foobar_version.cpp|while the 
header file is in|${CMAKE_CURRENT_SOURCE_DIR}|as seen here:


1234|configure_file(foobar_version.cpp.in foobar_version.cpp @ONLY) # 
configure_file(foobar_version.h foobar_version.h @ONLY) 
add_library(foobar_version STATIC 
${CMAKE_CURRENT_BINARY_DIR}/foobar_version.cpp) |//


In the source I simply|#include "foobar_version.h"|but the file is in 
a different location.


Why is this|CMakeLists.txt|file placing the files in different 
locations? What should I do about it?


Nothing. You really want to keep source and build directories seperate, 
which means you do not want to generate files into the source directory. 
Instead, add the CMAKE_CURRENT_SOURCE_DIR to the include search path of 
any target that needs to include foobar_version.h using any one of:


1) the include_directories command
2) the target_include_directories command
3) the CMAKE_INCLUDE_CURRENT_DIR variable




also, what is the purpose of|mylib.cpp|, I had to create it otherwise 
I receive:|No SOURCES given to target: fooToolkit|. The build is 
successful but my file is currently empty. Here are all build steps:


123456789|configure_file(foobar_version.cpp.in foobar_version.cpp 
@ONLY) configure_file(foobar_version.h foobar_version.h @ONLY) 
add_library(foobar_version STATIC 
${CMAKE_CURRENT_BINARY_DIR}/foobar_version.cpp) add_executable(foobar 
main.cpp) target_link_libraries(foobar PRIVATE foobar_version) 
add_library(fooToolkit mylib.cpp) target_link_libraries(fooToolkit 
PRIVATE foobar_version) |//


I'm not sure what you are trying to accomplish with the fooToolkit 
target. If you want to create a library without sources for its 
properties (because you have a header-only library, for example), the 
correct way is to create an INTERFACE library, like so:


add_library(fooToolkit INTERFACE)

As a final note, I would strongly suggest you read the fine manual when 
you get errors from CMake - the documentation is actually pretty good 
when used as a reference and would have answered both of your questions.

--

*Dr. Eric Dönges *
Senior Software Engineer

MVTec Software GmbH | Arnulfstr. 205 | 80634 Munich | Germany
doen...@mvtec.com  | Tel: +49 89 457 695-0 | 
www.mvtec.com 


Sign up  for our MVTec Newsletter!

Geschäftsführer: Dr. Wolfgang Eckstein, Dr. Olaf Munkelt
Amtsgericht München HRB 114695

MVTec Software GmbH Logo
-- 

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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] file dependency not working in external projects

[Eric Doenges]

You're probably missing the BUILD_ALWAYS option to ExternalProject_Add:

|BUILD_ALWAYS |
   Enabling this option forces the build step to always be run. This
   can be the easiest way to robustly ensure that the external
   project’s own build dependencies are evaluated rather than relying
   on the default success timestamp-based method. This option is not
   normally needed unless developers are expected to modify something
   the external project’s build depends on in a way that is not
   detectable via the step target dependencies (e.g. |SOURCE_DIR| is
   used without a download method and developers might modify the
   sources in |SOURCE_DIR|).

Am 24.09.19 um 15:23 schrieb hex:

hello,

I have a problem with a build step.

The following command is run every time somefile changes:

add_custom_command( OUTPUT out.put
    COMMAND touch out.put
    DEPENDS somefile.txt
)

add_custom_target( sometarget DEPENDS out.put )


I move this snippet inside an external project (with 
ExternalProject_Add) and the custom command is only run once at build.


I am using absolute path to somefile, the command is not rebuild 
changing somefile.


I am using Gnu make generator and build with make all


What am I missing?


--

*Dr. Eric Dönges*
Senior Software Engineer

MVTec Software GmbH | Arnulfstr. 205 | 80634 Munich | Germany
doen...@mvtec.com  | Tel: +49 89 457 695-0 
| www.mvtec.com 


Find our privacy policy here .

Sign up  for our MVTec Newsletter!

Geschäftsführer: Dr. Wolfgang Eckstein, Dr. Olaf Munkelt
Amtsgericht München HRB 114695

MVTec Software GmbH Logo
-- 

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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] printing CMAKE_CXX_FLAGS_* based on build type

[Eric Doenges]

Unfortunately, the standard values for CMAKE_BUILD_TYPE only have their 
first letter capitalized, i.e. for a release build CMAKE_BUILD_TYPE will 
normally be "Release". To use it like you want to, it would need to be 
"RELEASE". To get around this problem, we define an all upper-case 
BUILD_TYPE in our projects, i.e.:


string(TOUPPER ${CMAKE_BUILD_TYPE} BUILD_TYPE)
message(STATUS "CXX compiler ${CMAKE_BUILD_TYPE} build options: 
${CMAKE_CXX_FLAGS_${CMAKE_BUILD_TYPE}}")


If you do this, keep in mind what fdk17 said - CMAKE_BUILD_TYPE may not 
be set depending on the generator you use.


Am 27.09.19 um 22:18 schrieb Zdenko Podobny:

Hello,

I try to print CMAKE_CXX_FLAGS_DEBUG/CMAKE_CXX_FLAGS_RELEASE as one 
line statement but is does not work for me:


message( STATUS "CXX compiler ${CMAKE_BUILD_TYPE} build options: 
${CMAKE_CXX_FLAGS_${CMAKE_BUILD_TYPE}}")


Produce empy result, but
message( STATUS "CXX compiler  Release build options: 
${CMAKE_CXX_FLAGS_RELEASE}")

works as expected.
Is it possible to do it in one line or I have to use if/elseif ?

Zdenko


--

*Dr. Eric Dönges*
Senior Software Engineer

MVTec Software GmbH | Arnulfstr. 205 | 80634 Munich | Germany
doen...@mvtec.com  | Tel: +49 89 457 695-0 
| www.mvtec.com 


Find our privacy policy here .

Sign up  for our MVTec Newsletter!

Geschäftsführer: Dr. Wolfgang Eckstein, Dr. Olaf Munkelt
Amtsgericht München HRB 114695

MVTec Software GmbH Logo
-- 

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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] FindBLAS + MKL + Ctest fails on MacOS (SIP)

[Eric Doenges]

The simplest way to do this is to use the BUILD_RPATH and/or 
INSTALL_RPATH properties, i.e. something like:


list(GET BLAS_LIBRARIES 0 _BLAS_FIRSTLIB)
get_filename_component(_BLAS_LIBDIR "${_BLAS_FIRSTLIB}" DIRECTORY
set_target_properties(test_blas PROPERTIES BUILD_RPATH "${_BLAS_LIBDIR}")

This assumes BLAS_LIBRARIES is a list of libraries specified with 
absolute paths; if this assumption is incorrect, you must figure out the 
directory to specify to BUILD_RPATH some other way. If the tests are run 
using the installed binary (or you build your binaries using the install 
rpath from the start, like we do), then you must set INSTALL_RPATH 
instead of BUILD_RPATH. For a detailed description, see the CMake wiki 
page on RPATH handling 
.


Also note that while I think this should work, I haven't actually tested 
it myself.


Am 09.07.19 um 16:22 schrieb Luke D'Alessandro:

Hi all,

I have one of those complex interactions that results in an issue 
where it’s not clear to me which component is responsible.


I have unit tests written using CTest that depend on Intel's MKL 
BLAS implementation. I use find_package(BLAS) and link the test 
executables to ${BLAS_LIBRARIES}. The test executables depend on 
the DYLD_LIBRARY_PATH to find the mkl libraries, rather than an 
embedded LC_RPATH.


Unfortunately, because of Apple’s SIP, the DYLD_LIBRARY_PATH is not 
propagated to the ctest environment, so when it tries to run the tests 
it fails to link the MKL libraries.


I need to get CMake to embed an external LC_PATH for test executables 
in the build directory.


Here's a basic test executable (test.cpp)


|#includeintmain(){return_dgemm !=nullptr;}|

and here is the associated CMakeLists.txt

|cmake_minimum_required(VERSION 3.14.5) project(blas LANGUAGES CXX) 
include(CTest) set(BLA_VENDOR Intel10_64lp_seq) find_package(BLAS 
REQUIRED) add_executable(test_blas test.cpp) 
target_link_libraries(test_blas ${BLAS_LIBRARIES}) add_test(NAME 
test_direct COMMAND test_blas)|
This finds MKL and builds and links the executable without any 
problem, and I can run it manually from my shell. But when I run 
with CTest I have the SIP issue because MacOS won’t propagate the 
necessary DYLD_LIBRARY_PATH into CTest’s environment.


|Lukes-MacBook:test ldalessa$ make test Running tests... Test project 
/Users/ldalessa/test Start 1: test_direct 1/1 Test #1: test_direct 
..Child aborted***Exception: 0.01 sec 0% tests 
passed, 1 tests failed out of 1 Total Test time (real) = 0.01 sec The 
following tests FAILED: 1 - test_direct (Child aborted) Errors while 
running CTest make: *** [test] Error 8 |


|Lukes-MacBook:test ldalessa$ cat Testing/Temporary/LastTest.log 
Start testing: Jun 10 03:35 PDT 
-- 1/1 
Testing: test_direct 1/1 Test: test_direct Command: 
"/Users/ldalessa/test/test_blas" Directory: /Users/ldalessa/test 
"test_direct" start time: Jun 10 03:35 PDT Output: 
-- dyld: 
Library not loaded: @rpath/libmkl_intel_lp64.dylib Referenced from: 
/Users/ldalessa/test/test_blas Reason: image not found output> Test time = 0.01 sec 
-- Test 
Failed. "test_direct" end time: Jun 10 03:35 PDT "test_direct" time 
elapsed: 00:00:00 
-- End 
testing: Jun 10 03:35 PDT Lukes-MacBook:test ldalessa$ |
My temporary workaround for this is currently to use Apple's 
Accelerate framework instead of MKL, which links using an embedded 
LC_PATH properly. The reason this isn’t adequate is that it is an 
intrusive solution. Intel's MKL uses different headers (|mkl_blas.h|, 
|mkl_lapack.h|) and symbol names which are explicitly used in the 
source code, so I have to have extra configure-time and configured 
header changes to adapt the code base to Accelerate. We also don’t 
(and won’t) have verified and validated code with Accelerate so it’s 
not a long term solution to our issues. Disabling SIP is also a 
non-starter.


Thanks,
Luke

(https://stackoverflow.com/questions/56524774/how-to-use-ctest-on-macos-without-disabling-sip-no-lc-path-is-set)



--

*Dr. Eric Dönges *
Senior Software Engineer

MVTec Software GmbH | Arnulfstr. 205 | 80634 Munich | Germany
doen...@mvtec.com  | Tel: +49 89 457 695-0 | 
www.mvtec.com 


Sign up  for our MVTec Newsletter!

Geschäftsführer: Dr. Wolfgang Eckstein, Dr. Olaf Munkelt
Amtsgericht München HRB 114695

MVTec Software GmbH Logo
-- 

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: 

Re: [CMake] Using CMake with TI armcl and armar

[Eric Doenges]

Am 09.11.19 um 00:15 schrieb Samyukta Ramnath:
I want to add a CC1352P1_LAUNCHXL_TIRTOS.cmd  file, which has been 
added in the CCS linker command, but I am unable to include It in my 
linker command. I tried the following things :


set(LINKER_SCRIPT "${LWIP_DIR}/CC1352P1_LAUNCHXL_TIRTOS.cmd")

set_target_properties(test.out PROPERTIES LINK_DEPENDS 
${LWIP_DIR}/CC1352P1_LAUNCHXL_TIRTOS.cmd)


I have also tried passing it in with the cmake command as

>> cmake -DCMAKE_TOOLCHAIN_FILE=../Toolchain_ticomp.cmake 
-DCMAKE_LINKER=../CC1352P1_LAUNCHXL_TIRTOS.cmd ..


None of these options helped.

This .cmd file has details about stack size, heap size, entry point etc.

As I said, the project using cgtools never went anywhere, so I never got 
to the point that I needed to worry about linker command files, so I can 
only give general hints, not a specific solution. That being said, 
setting CMAKE_LINKER will not work, because that specifies the 
executable to use as the linker. You could try adding 
CC11352P1_LAUNCHXL_TIRTOS.cmd with add_link_options() or 
target_link_options() like so:


target_link_options( )


cmake should simply pass the command file through to the linker.

I would also like some clarification on where to add the linker 
command --rom_model as when I add it to the CMAKE_EXE_LINKER_FLAGS 
variable in the Toolchain.cmake file, my cmake hangs at “Detecting CXX 
compiler ABI info”


CMAKE_EXE_LINKER_FLAGS should be the correct place to do this if you 
want any target you build with this toolchain to use --rom_model. 
However, if you are going to set this in the toolchain file, you should 
set CMAKE_EXE_LINKER_FLAGS_INIT instead. This is because cmake will set 
CMAKE_EXE_LINKER_FLAGS based on the contents of 
CMAKE_EXE_LINKER_FLAGS_INIT and compiler-specific knowledge when it 
encounters the project() command after reading the toolchain file.


Alternatively, you could try adding the --rom_model using the 
add_link_options or target_link_options commands


--

*Dr. Eric Dönges*
Senior Software Engineer

MVTec Software GmbH | Arnulfstr. 205 | 80634 Munich | Germany
doen...@mvtec.com  | Tel: +49 89 457 695-0 
| www.mvtec.com 


Find our privacy policy here .

Sign up  for our MVTec Newsletter!

Geschäftsführer: Dr. Wolfgang Eckstein, Dr. Olaf Munkelt
Amtsgericht München HRB 114695

MVTec Software GmbH Logo
-- 

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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] Using CMake with TI armcl and armar

[Eric Doenges]

Am 07.11.19 um 18:01 schrieb samyuktar:

SET(CMAKE_C_LINK_EXECUTABLE "${CMAKE_C_COMPILER}  ${CMAKE_C_FLAGS}
--c_file=../main.c -z --map_file=${TARGET_NAME}.map
--output_file=${TARGET_NAME} ${PLATFORM_CONFIG_L_FLAGS} ${CMD_SRCS}   ${LIB}
--include_path ${LWIP_INCLUDE_DIR} --verbose "  CACHE STRING
"linker executable")


As far as I can tell, you are trying to combine the compile and link 
steps, but CMake expects these to be separate steps. Furthermore, cmake 
knows about the TI compiler (see 
<...>/share/cmake-3.xx/Modules/Compiler/TI-C.cmake and friends), so you 
shouldn't need to mess around with CMAKE_C_LINK_EXECUTABLE - let cmake 
handle that for you. The flags you need for linking that cmake doesn't 
already add for you by default should go into 
CMAKE_EXE_LINKER_FLAGS__INIT (see the cmake documenation for 
details), or be set using the add_link_options and/or 
target_link_options commands (again, see the cmake documentation for 
details).



[ 50%] Building C object CMakeFiles/test.dir/main.c.o
/Applications/ti_ccs9/ccs9/ccs/tools/compiler/ti-cgt-arm_18.12.2.LTS/bin/armcl
-I/Applications/ti_ccs9/ccs9/ccs/tools/compiler/ti-cgt-arm_18.12.2.LTS/include
-isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk   -o
CMakeFiles/test.dir/main.c.o   -c /Users/sramnath/lwip_blinky/lwip/main.c

WARNING: object file specified, but linking not enabled


That compiler invocation looks wrong - I'm pretty sure the TI compiler 
doesn't use the MacOS10.14.sdk sysroot. I think what's happening here is 
that you set your toolchain settings (CMAKE_C_COMPILER and friends) 
after the project() command - but the project() command tells cmake to 
check what compiler you are using to figure out how it must be called, 
and it is using your host system's compiler (probably Apple's clang) to 
do so. You should put the toolchain definitions into a toolchain file as 
described in the cmake-toolchains(7) documentation and tell cmake to use 
it my specifying -DCMAKE_TOOLCHAIN_FILE= on 
the cmake command line.


I once played around a bit with cgtools 5.2.9 for Arm using the 
following toolchain file:


--- SNIP ---

# TI cgt-arm_5.2.9 cmake toolchain script
#
# This file is based on the cmake-toolchains(7) documentation.

# Set the operating system and processor architecture
set(CMAKE_SYSTEM_NAME Generic)
set(CMAKE_SYSTEM_PROCESSOR arm)
set(CMAKE_SYSTEM_VERSION 1)

# Setup CMake's rules for using the CMAKE_FIND_ROOT_PATH for 
cross-compilation

set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY)

# TI cgtools command line programs
set(SDK_PATH "/proj/he/opt/ti/ti-cgt-arm_5.2.9")
set(SDK_BIN "${SDK_PATH}/bin")

# This compiler doesn't work with CMAKE_SYSROOT, but we do need to set our
# CMAKE_FIND_ROOT_PATH. Note that setting a variable will override the 
value in
# the cache if the CACHE option was not used, so if we want to be able 
to use a
# CMAKE_FIND_ROOT_PATH passed to cmake via the command line, we must 
make sure

# not to overwrite any value that was already set.
if(NOT CMAKE_FIND_ROOT_PATH)
  set(CMAKE_FIND_ROOT_PATH ${SDK_PATH})
endif()

set(CMAKE_C_COMPILER "${SDK_BIN}/armcl")
set(CMAKE_CXX_COMPILER "${SDK_BIN}/armcl")
set(CMAKE_ASM_COMPILER "${SDK_BIN}/armasm")
set(CMAKE_AR "${SDK_BIN}/armar")
set(CMAKE_LINKER "${SDK_BIN}/armlnk")

string(CONCAT ARCH_C_FLAGS
  "-mv=7A8 --abi=eabi -me --float_support=VFPv3 --neon 
--printf_support=full")

set(CMAKE_C_FLAGS_INIT "${ARCH_C_FLAGS}")
set(CMAKE_CXX_FLAGS_INIT "${ARCH_C_FLAGS}")

# Normally, cmake checks if the compiler can compile and link programs. For
# TI's cgtools the link step doesn't work, and there seems to be no easy way
# to fix this. Instead, we simply disable the compiler checks for C and C++.
set(CMAKE_C_COMPILER_WORKS 1)
set(CMAKE_CXX_COMPILER_WORKS 1)

--- SNIP ---

Note that the project this was intended for thankfully never got 
anywhere so I didn't pursue this much further than being able to compile 
libz with it ("thankfully" because the TI compiler is pretty awful).


--

*Dr. Eric Dönges*
Senior Software Engineer

MVTec Software GmbH | Arnulfstr. 205 | 80634 Munich | Germany
doen...@mvtec.com  | Tel: +49 89 457 695-0 
| www.mvtec.com 


Find our privacy policy here .

Sign up  for our MVTec Newsletter!

Geschäftsführer: Dr. Wolfgang Eckstein, Dr. Olaf Munkelt
Amtsgericht München HRB 114695

MVTec Software GmbH Logo
-- 

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: 

Re: [CMake] Accessing -fPIC and -std settings within CMake definitions

[Eric Doenges]

Am 01.11.19 um 11:02 schrieb Stephen Morris:

I'm setting up a custom build step to build a precompiled header in gcc (yes I 
know that native support is coming with CMake 3.16, but I need to get something 
working on an older version).

My approach is basically to set up a custom command thus:

set_target_properties(mytarget PRIVATE CXX_STANDARD 17)
set_target_properties(mytarget PRIVATE  POSITION_INDEPENDENT CODE_1)
set(CMAKE_VERBOSE_MAKEFILE TRUE)
...
...
set(CXX_FLAGS ${CMAKE_CXX_FLAGS} ${CMAKE_CXX_FLAGS_DEBUG})   .. or whatever, 
depending on the current configuration..
get_target_property(compile_options, mytarget, COMPILE_OPTIONS)
add_custom_command(OUTPUT myheader.h.gch
COMMAND ${CMAKE_CXX_COMPILER} 
${CXX_FLAGS} ${compile_options} -fPIC -std=gnu++17 -c myheader.h -o 
myheader.h.gch
DEPENDS myheader.h)
add_custom_target(BuildMyPCH
  DEPENDS myheader.h.gch)
add_dependencies(mytarget, BuildMyPCH)

You'll note that in my custom command I've had to specify -fPIC and 
-std-gnu++17 explicitly, because they aren't included among either CXX_FLAGS or 
COMPILE_OPTIONS. I've looked for them among the  COMPILE_DEFINITIONS, 
COMPILE_FEATURES and COMPILE_FLAGS properties of my target as well, but there's 
no sign of them. And yet if I look at the verbose output when gcc builds other 
files using the CMake-generated makefile, I see that they are being included 
automatically.

So, my question: where is CMake storing these settings, and how can I apply 
them in my custom command without having to do so manually?


As far as I am aware, there is no way of querying the entirety of the 
command line arguments applied by CMake - you will need to recreate 
CMake's behavior manually. In case of -fPIC, this could look like this 
(not tested, so there may be syntax errors, but the principle should work):


...
get_target_property(_tmp mytarget POSITION_INDEPENDENT_CODE)
if(_tmp AND CMAKE_CXX_COMPILE_OPTIONS_PIC)
  string(APPEND CXX_FLAGS " ${CMAKE_CXX_COMPILE_OPTIONS_PIC}")
endif()
...

If you have multiple targets that may have different compile options you 
will probably want to put this in a function that takes a target as 
input and returns the compiler flags as output.


To figure out the names of the variables CMake uses to hold flags to 
pass to the compiler, search the <...>/share/cmake-3.xx/Modules/Compiler 
directory.


--

*Dr. Eric Dönges*
Senior Software Engineer

MVTec Software GmbH | Arnulfstr. 205 | 80634 Munich | Germany
doen...@mvtec.com  | Tel: +49 89 457 695-0 
| www.mvtec.com 


Find our privacy policy here .

Sign up  for our MVTec Newsletter!

Geschäftsführer: Dr. Wolfgang Eckstein, Dr. Olaf Munkelt
Amtsgericht München HRB 114695

MVTec Software GmbH Logo
-- 

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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] Stray backslash appearing when CMAKE_CXX_FLAGS_RELEASE used in custom command

[Eric Doenges]

Am 01.11.19 um 17:24 schrieb Stephen Morris:

On 1 November at 10:02, Stephen Morris wrote:


My approach is basically to set up a custom command thus:
set(CXX_FLAGS ${CMAKE_CXX_FLAGS} ${CMAKE_CXX_FLAGS_DEBUG})   .. or whatever, 
depending on the current configuration..
get_target_property(compile_options, mytarget, COMPILE_OPTIONS) 
add_custom_command(OUTPUT myheader.h.gch
  COMMAND ${CMAKE_CXX_COMPILER} 
${CXX_FLAGS} ${compile_options} -fPIC -std=gnu++17 -c myheader.h -o 
myheader.h.gch
   DEPENDS myheader.h) 
add_custom_target(BuildMyPCH
 DEPENDS myheader.h.gch) 
add_dependencies(mytarget, BuildMyPCH)

My earlier question still stands, but at the time I wrote it I had only tested 
it for Debug builds where ${CMAKE_CXX_FLAGS_DEBUG} consisted of a single item, 
'-g'.

I've since tried doing the same thing for a Release build, and this failed because 
${CMAKE_CXX_FLAGS_RELEASE} has two items, '-O3 -DNDEBUG'. When the custom command is 
executed, this somehow becomes "-O3\ -DNDEBUG" on the command line, and the 
presence of the stray backslash causes the compilation to fail with the message,

"cc1plus: error: argument to '-O' should be a non-negative integer. 'g', 's' or 
'fast'"

So why isn't the cmake variable placed properly onto the command line, and what 
can I do to prevent this behaviour?


Welcome to the wonderful world of lists and their interaction with 
quoting in CMake ! Since space is used as a list item separator outside 
of double quoted strings, CMake is escaping the space within CXX_FLAGS 
to keep it as a single element within the list of arguments passed to 
add_custom_command. To avoid this, you need to turn CXX_FLAGS into a 
list prior to using it in add_custom_command:


string(REGEX REPLACE " " ";" CXX_FLAGS "${CXX_FLAGS}")

Of course, this will not work if you want to pass a double quoted string 
as an actual command line argument ...


--

*Dr. Eric Dönges*
Senior Software Engineer

MVTec Software GmbH | Arnulfstr. 205 | 80634 Munich | Germany
doen...@mvtec.com  | Tel: +49 89 457 695-0 
| www.mvtec.com 


Find our privacy policy here .

Sign up  for our MVTec Newsletter!

Geschäftsführer: Dr. Wolfgang Eckstein, Dr. Olaf Munkelt
Amtsgericht München HRB 114695

MVTec Software GmbH Logo
-- 

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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] Got Weird Error When Trying to Configure LLVM Version 10

[Eric Doenges]

MSBuild is complaining that the generated project file doesn't contain a 
32 bit debug target - which is no surprise, because you told CMake to 
generate a project for a release build. You will probably need to tell 
msbuild.exe that you want to build a release build with the 
"/p:Configuration=Release" command line option.



Am 26.10.19 um 18:38 schrieb Osman Zakir:

I want to build LLVM 10 so that I can see if having the same version 
of LLVM installed that my EMSDK version is using will help.  I want to 
do this so I can build the Qt Documentation as well when I build Qt 
for WebAssembly. Building the Documentation requires LLVM and I want 
to avoid conflicts caused by having different versions of LLVM.


Anyway, the command I ran was:
"cmake -DCMAKE_INSTALL_PREFIX=../install -G"Visual Studio 16 2019" 
-Thost=x64 -A x86 
-DLLVM_ENABLE_PROJECTS="clang;clang-tools-extra;lld;lldb;libcxx;libcxxabi" 
-DCMAKE_BUILD-TYPE=Release -MSVC_RUNTIME_TYPE=/MT 
-DLLVM_TARGETS_TO_BUILD=all -DLLVM_ENABLE_THREADS=On 
-DLLVM_CXX_STD="c++17" -DLLVM_ENABLE_PEDANTIC=On 
-DCMAKE_CXX_FLAGS="/std:c++17;/permissive-;/MT;/EHsc" ../llvm"


I put the error message I got in the .log file I'm attaching to this 
message.  Any help is appreciated.  Thanks.



--

*Dr. Eric Dönges*
Senior Software Engineer

MVTec Software GmbH | Arnulfstr. 205 | 80634 Munich | Germany
doen...@mvtec.com  | Tel: +49 89 457 695-0 
| www.mvtec.com 


Find our privacy policy here .

Sign up  for our MVTec Newsletter!

Geschäftsführer: Dr. Wolfgang Eckstein, Dr. Olaf Munkelt
Amtsgericht München HRB 114695

MVTec Software GmbH Logo
-- 

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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] How to Switch to Static Runtime on Command Line?

[Eric Doenges]

I think it is worth adding to what Mateusz wrote that the 
MSVC_RUNTIME_LIBRARY property / CMAKE_MSVC_RUNTIME_LIBRARY variable are 
only available if policy CMP0091 is set to NEW, which it will not be 
because LLVM's CMakeLists.txt only requires CMake 3.4.3 or later (and 
thus all policies introduced after 3.4.3 are set to OLD for 
compatibility). So if you do not want to edit LLVM's CMakeLists.txt, you 
need to use the options provided by LLVM's CMake project to control the 
build.


We select the CRT LLVM's libraries will use with the LLVM_USE_CRT_DEBUG 
and LLVM_USE_CRT_RELEASE options, i.e. to build with a static MSVC 
runtime we use


-DLLVM_USE_CRT_DEBUG=MTd -DLLVM_USE_CRT_RELEASE=MT

These options are not documented on the "Building LLVM with CMake" page, 
but can be found by looking into LLVM's cmake directory.


Am 28.10.19 um 12:53 schrieb Mateusz Loskot:

On Mon, 28 Oct 2019 at 12:22, Osman Zakir  wrote:

And I should do "-DCMAKE_MSVC_RUNTIME_LIBRARY=/MT"

Man, read the docs I pasted!!!
https://cmake.org/cmake/help/v3.15/prop_tgt/MSVC_RUNTIME_LIBRARY.html

Best regards,

--

*Dr. Eric Dönges*
Senior Software Engineer

MVTec Software GmbH | Arnulfstr. 205 | 80634 Munich | Germany
doen...@mvtec.com  | Tel: +49 89 457 695-0 
| www.mvtec.com 


Find our privacy policy here .

Sign up  for our MVTec Newsletter!

Geschäftsführer: Dr. Wolfgang Eckstein, Dr. Olaf Munkelt
Amtsgericht München HRB 114695

MVTec Software GmbH Logo
-- 

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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] How to Switch to Static Runtime on Command Line?

[Eric Doenges]

By default, CMake will use /EHsc when compiling for the Windows 
platform, with no option to change this that I am aware of. If a project 
wants different settings, it needs to handle this itself. And in fact, 
LLVM 3.4.2 conditionally modifies /EHsc to /EHs-c- in 
cmake/modules/LLVMProcessSources.cmake, so I wouldn't be surprised if 
LLVM 10.0.0 does something similar (I don't have a more recent version 
of LLVM lying about, so I can't check).



To figure out what option(s) you need to set or what files you need to 
modify, you either need to ask the LLVM developers, or dig through the 
LLVM cmake project to figure out what it is doing with the /EHsc option.



Am 28.10.19 um 13:33 schrieb Osman Zakir:
Alright, thanks.  What about enabling C++ exceptions?  I tried setting 
LLVM_ENABLE_EH to On, but it didn't help.  Setting CMAKE_CXX_FLAGS to 
/EHsc doesn't help either.

--

*Dr. Eric Dönges*
Senior Software Engineer

MVTec Software GmbH | Arnulfstr. 205 | 80634 Munich | Germany
doen...@mvtec.com  | Tel: +49 89 457 695-0 
| www.mvtec.com 


Find our privacy policy here .

Sign up  for our MVTec Newsletter!

Geschäftsführer: Dr. Wolfgang Eckstein, Dr. Olaf Munkelt
Amtsgericht München HRB 114695

MVTec Software GmbH Logo
-- 

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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] CMake 3.15 fails to install on OS X

[Eric Doenges]

System Integrity Protection (SIP, introduced with macOS 10.11) prevents 
you from writing into various system directories (like /usr) even as the 
root user. You can either install cmake to a different location (like 
/usr/local, which apparently is not protected), or disable SIP entirely 
(which is not recommended). See this Wikipedia article 
 for more 
information on SIP.


Am 15.10.19 um 07:05 schrieb Jeffrey Walton:

I'm building CMake cmake-3.15.4.tar.gz on OS X 10.12. The machine is
stripped down, and only has the COmmand Line tools. No Xcode and
friends.

I configured with:

 ./configure --prefix=/usr

Configure appears OK. Make appears OK. Install is failing:

 $ sudo make install VERBOSE=1
 ...
[100%] Built target foo
/Users/jwalton/cmake-3.15.4/Bootstrap.cmk/cmake -E
cmake_progress_start /Users/jwalton/cmake-3.15.4/CMakeFiles 0
/Library/Developer/CommandLineTools/usr/bin/make -f
CMakeFiles/Makefile2 preinstall
make[1]: Nothing to be done for `preinstall'.
Install the project...
bin/cmake -P cmake_install.cmake
-- Install configuration: ""
CMake Error at Source/kwsys/cmake_install.cmake:36 (file):
   file cannot create directory: /usr/doc/cmake-3.15/cmsys.  Maybe need
   administrative privileges.
Call Stack (most recent call first):
   cmake_install.cmake:37 (include)

make: *** [install] Error 1

--

*Dr. Eric Dönges*
Senior Software Engineer

MVTec Software GmbH | Arnulfstr. 205 | 80634 Munich | Germany
doen...@mvtec.com  | Tel: +49 89 457 695-0 
| www.mvtec.com 


Find our privacy policy here .

Sign up  for our MVTec Newsletter!

Geschäftsführer: Dr. Wolfgang Eckstein, Dr. Olaf Munkelt
Amtsgericht München HRB 114695

MVTec Software GmbH Logo
-- 

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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] modifying cmake_build_type cflags per target

[Eric Doenges]

Am 19.11.19 um 22:51 schrieb Craig Scott:



On Tue, Nov 19, 2019 at 10:36 PM Eric Doenges <mailto:doen...@mvtec.com>> wrote:


Am 19.11.19 um 12:09 schrieb Stéphane Ancelot:


Hi,

I have a particular target (using swig / jni) that must not have
-O3 -NDEBUG flags from Relase build type

How can I overload this target flags ?


Since CMAKE__FLAGS_RELEASE does not map to a user-visible
target property, you cannot override it directly (anything added
to the COMPILE_FLAGS property is appended to the command line and
does not replace any of the compiler flags CMake sets by itself).
However, you can redefine this variable before you create your
special target(s), and then restore it so that other targets are
not affected:

set(_CMAKE_CXX_FLAGS_RELEASE_SAVE ${CMAKE_CXX_FLAGS_RELEASE})
set(CMAKE_CXX_FLAGS_RELEASE)
< add your target(s) here >
set(CMAKE_CXX_FLAGS_RELEASE ${_CMAKE_CXX_FLAGS_RELEASE_SAVE})

This assumes your target is C++; if it is C, simply replace the
_CXX_ with _C_.


Actually, no, that's not how it works. This is actually a great 
example of why projects shouldn't generally try to avoid manipulating 
CMAKE_CXX_FLAGS and should instead prefer to modify target or 
directory properties instead (not possible here for the original 
problem, but worth highlighting nonetheless). The (often surprising) 
behavior at play in the proposed example above is that it is not the 
value of the CMAKE_CXX_FLAGS_RELEASE variable at the time the target 
is created that matters, it's the variable's value /at the end of the 
directory scope/. You can change the variable's value as much as you 
like along the way before or after creating targets, but only the 
final value at the end of the scope will actually be used in the build 
command lines for targets created in that directory scope. This is 
rarely what developers expect, but that's how it works, for better or 
worse. When you start adding in calls to add_subdirectory(), it can 
get really confusing what value is getting used where, so take great 
care if your project really must modify these variables.


Very interesting, thanks for pointing that out. In our case things work 
because all the actual targets are in fact created in subdirectories. I 
think CMake really needs some straightforward way to allow you to 
override flags on a per-target and per-file basis (in our case, we need 
to be able to reduce the optimization level for individual source files 
to work around bugs in the Intel compiler's optimizer).


--

*Dr. Eric Dönges*
Senior Software Engineer

MVTec Software GmbH | Arnulfstr. 205 | 80634 Munich | Germany
doen...@mvtec.com <mailto:musterm...@mvtec.com> | Tel: +49 89 457 695-0 
| www.mvtec.com <http://www.mvtec.com>


Find our privacy policy here <https://www.mvtec.com/imprint>.

Sign up <https://www.mvtec.com/newsletter> for our MVTec Newsletter!

Geschäftsführer: Dr. Wolfgang Eckstein, Dr. Olaf Munkelt
Amtsgericht München HRB 114695

MVTec Software GmbH Logo
-- 

Powered by kitware.com/cmake

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit https://cmake.org/services

Visit other Kitware open-source projects at https://www.kitware.com/platforms

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

This mailing list is deprecated in favor of https://discourse.cmake.org

Re: [CMake] modifying cmake_build_type cflags per target

[Eric Doenges]

Am 19.11.19 um 12:09 schrieb Stéphane Ancelot:


Hi,

I have a particular target (using swig / jni) that must not have -O3 
-NDEBUG flags from Relase build type


How can I overload this target flags ?

Since CMAKE__FLAGS_RELEASE does not map to a user-visible target 
property, you cannot override it directly (anything added to the 
COMPILE_FLAGS property is appended to the command line and does not 
replace any of the compiler flags CMake sets by itself). However, you 
can redefine this variable before you create your special target(s), and 
then restore it so that other targets are not affected:


set(_CMAKE_CXX_FLAGS_RELEASE_SAVE ${CMAKE_CXX_FLAGS_RELEASE})
set(CMAKE_CXX_FLAGS_RELEASE)
< add your target(s) here >
set(CMAKE_CXX_FLAGS_RELEASE ${_CMAKE_CXX_FLAGS_RELEASE_SAVE})

This assumes your target is C++; if it is C, simply replace the _CXX_ 
with _C_.


--

*Dr. Eric Dönges*
Senior Software Engineer

MVTec Software GmbH | Arnulfstr. 205 | 80634 Munich | Germany
doen...@mvtec.com  | Tel: +49 89 457 695-0 
| www.mvtec.com 


Find our privacy policy here .

Sign up  for our MVTec Newsletter!

Geschäftsführer: Dr. Wolfgang Eckstein, Dr. Olaf Munkelt
Amtsgericht München HRB 114695

MVTec Software GmbH Logo
-- 

Powered by kitware.com/cmake

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit https://cmake.org/services

Visit other Kitware open-source projects at https://www.kitware.com/platforms

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

This mailing list is deprecated in favor of https://discourse.cmake.org

Re: [CMake] Question about list ordering

[Eric Doenges]

The list  command 
is what you want. Specifically, list(GET ...) will return the index of a 
string in the list, and list(INSERT ...) and list(REMOVE_ITEM ...) or 
list(REMOVE_AT ...) to insert and remove items.


Am 13.11.19 um 00:56 schrieb Unnamed User:

Hello everyone,

i'm relative new to CMake and i need a function that does change the
order of a list. So for example when i have a list like

set(LIBS_TO_BUILD "BOOST;EIGEN;PYTHON;GLUT;GLFW;NLOHMANNJSON")

i need a function to swap places like

listSwapString("GLUT", "GLFW", ${LIBS_TO_BUILD}).


The base code for the function look like this, but i don't even know how
to get the index of a string inside of a list or how to insert a string
at a certain position and move the other strings to the back.

function(bsListInsertBefore)
    set(options)
    set(oneValueArgs SEARCH INSERT RESULT)
    set(multiValueArgs LIST)
    cmake_parse_arguments(var
    "${options}"
    "${oneValueArgs}"
    "${multiValueArgs}"
    "${ARGN}"
    )
endfunction()


I hope i can count on you, for me as a CMake newbie this is a great
task, i stil have a bit of a problem with the syntax.


best regards,

Steven Truppe


--

*Dr. Eric Dönges*
Senior Software Engineer

MVTec Software GmbH | Arnulfstr. 205 | 80634 Munich | Germany
doen...@mvtec.com  | Tel: +49 89 457 695-0 
| www.mvtec.com 


Find our privacy policy here .

Sign up  for our MVTec Newsletter!

Geschäftsführer: Dr. Wolfgang Eckstein, Dr. Olaf Munkelt
Amtsgericht München HRB 114695

MVTec Software GmbH Logo
-- 

Powered by kitware.com/cmake

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit https://cmake.org/services

Visit other Kitware open-source projects at https://www.kitware.com/platforms

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

This mailing list is deprecated in favor of https://discourse.cmake.org

Re: [CMake] Debug logging of items

[Eric Doenges]

I don't know about the targets, but you can get all variables currently 
defined for a directory by reading the VARIABLES property, e.g.


get_property(_variables DIRECTORY "${CMAKE_SOURCE_DIR}" PROPERTY VARIABLES)

I use this to dump the variables into a file so I can see with which 
variable settings my build directory was configured with.


With kind regards,
Eric

Am 20.09.19 um 14:49 schrieb Cornelis Bockemühl:


Right now I am fighting my way through large amounts of CMake code 
(actually working on a ParaView custom application with many own 
plugins, views, domains, property widgets etc. etc.), and it is 
sometimes really not easy not to lose track completely! Sometimes I am 
happy to be back into complex C++ programming - because I see much 
more logic in the entire thing. And it is of course no news that CMake 
code is not famous for being easy to debug.


Anyway, I am dreaming of some "simple" features that would sometimes 
help a lot, and it is all about "dumping" some kind of data. Actually 
this is for me often also the favorite way to debug C++ code: just 
print out the values of variables, arrays, etc. - e.g. if setting a 
breakpoint in the debugger is difficult because you are interested 
only in the 928773th occurrence of a certain piece of code (without 
even knowing that number...).


Accordingly in CMake code I am working a lot with the message() 
function - but within that code the problem is often that you do not 
even know which variables would be available at all!


Thus functions like would be really great to have:

    “give me a list of all currently known targets”
    “give me a list of all properties of a target”
    “give me a list of all currently defined variables”
    etc.

What I do not know is: Are this things that already exist - in which 
case I would be happy if somebody could tell me how to find them! -, 
or are these functions rather "feature requests"?


In fact I can hardly believe that I am the first with such kind of 
dreams, so my hope is still that they already exist somewhere...


--
Cornelis Bockemühl
mail: corne...@bockemuehl.ch
phone: +41 79 644 9943
Basel, Switzerland
https://cobo.bockemuehl.ch




--

*Dr. Eric Dönges*
Senior Software Engineer

MVTec Software GmbH | Arnulfstr. 205 | 80634 Munich | Germany
doen...@mvtec.com  | Tel: +49 89 457 695-0 
| www.mvtec.com 


Find our privacy policy here .

Sign up  for our MVTec Newsletter!

Geschäftsführer: Dr. Wolfgang Eckstein, Dr. Olaf Munkelt
Amtsgericht München HRB 114695

MVTec Software GmbH Logo
-- 

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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] MacOS and shared libraries from imported targets

[Eric Doenges]

As far as I am aware, the macOS linker simply records the install name 
of the dynamic library you link against in your executable (similar to 
how the Linux linker records the Elf SONAME, if present). So, the first 
step would be to check the install name of the external dynamic library 
by running 'otool -L' on it (the install name should be at the top of 
the output). You can change the install name using the install_name_tool 
(but if you build the external dynamic library yourself I think it is 
better to build the library with the correct install name in the first 
place).


Am 24.09.19 um 18:02 schrieb Michael Welsh Duggan:

I have a project that links against an external dynamic library for
which I have written a Find module that creates an import target.  I do
this, in part, by setting the IMPORTED_LOCATION property of the target
to the location of the dynamic library.

Unfortunately, on OSX the library shows up in the executable load
commands as an LC_LOAD_DYLIB of the raw filename (no directory) of the
shared library.  I expected it to use the whole path.  I tried setting
the INSTALL_NAME_DIR property to the directory containing the shared
library, but this changed nothing.

I will note that this is all still in the build location, as opposed to
post-install.  I am using the following settings currently:

set(CMAKE_SKIP_BUILD_RPATH false)
set(CMAKE_BUILD_WITH_INSTALL_RPATH false)
set(CMAKE_INSTALL_RPATH_USE_LINK_PATH true)
set(CMAKE_MACOSX_RPATH true)

I'm not 100% confident with how these options interact, so I am more
than prepared for someone to tell me that I am doing something wrong.
Any hints would be appreciated.


--

*Dr. Eric Dönges*
Senior Software Engineer

MVTec Software GmbH | Arnulfstr. 205 | 80634 Munich | Germany
doen...@mvtec.com  | Tel: +49 89 457 695-0 
| www.mvtec.com 


Find our privacy policy here .

Sign up  for our MVTec Newsletter!

Geschäftsführer: Dr. Wolfgang Eckstein, Dr. Olaf Munkelt
Amtsgericht München HRB 114695

MVTec Software GmbH Logo
-- 

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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] find_package to find Cygwin versions of Flex and Bison in Windows

[Eric Doenges]

You can prepend C:\cygwin64\bin to the CMAKE_PROGRAM_PATH variable so 
that it looks there first.  While the find_package documentation does 
not mention CMAKE_PROGRAM_PATH, I know this works for bison and flex 
because that is what we do in our project (presumably, find_program is 
used internally within the find_package, explaining why 
CMAKE_PROGRAM_PATH is considered).


You could also try setting the FLEX_ROOT and BISON_ROOT variables to 
C:\cygwin64\bin or perhaps C:\cygwin64. According to the find_package 
documentation, this should allow you to set the search location on a 
per-package basis. However, I have not had this work for me, so your 
mileage may vary.


Am 05.03.20 um 12:12 schrieb Stephen Morris:

To compile my application I need to use the Flex and Bison applications. To 
compile under Linux, all I need to do in my CMakeLists.txt file to find them is

 find_package(FLEX REQUIRED)
 find_package(BISON REQUIRED)

...and everything works as expected.

In Windows, however, I'm using the Cygwin versions of Flex and Bison which are 
installed in C:\cygwin64\bin. This doesn't seem to be on the path that 
find_package searches in Module Mode, so the search returns unsuccessfully.

However, if I try to tell find_package where to look, viz.

 find_package(FLEX REQUIRED PATHS C:/cygwin64/bin NO_DEFAULT_PATH)
 find_package(BISON REQUIRED PATHS C:/cygwin64/bin NO_DEFAULT_PATH)

...then by adding the PATHS keyword I've invoked Config mode and I get an error 
message saying:

 Could not find a package configuration file provided by "FLEX" with any of
 the following names

 FLEXConfig.cmake
 flex-config.cmake

...because sure enough Cygwin does not provide these files.

So what can I do? Ideally I'd like to use Module Mode but provide a path hint; 
but there seems no way to do that.

At the moment I can only think of:
(a) Hard-coding add_custom_target commands to invoke flex and bison entirely 
manually when they're needed, or
(b) Writing my own FLEXConfig.cmake and BISONConfig.cmake files for use in 
Config Mode.

Both of these seem disproportionately difficult for what seems to me like it 
ought to be a common and simple problem. So is there a better solution that I'm 
missing?


*Dr. Eric Dönges*
Senior Software Engineer

MVTec Software GmbH | Arnulfstr. 205 | 80634 Munich | Germany
doen...@mvtec.com  | Tel: +49 89 457 695-0 | 
www.mvtec.com 


Find our privacy policy here .

Sign up  for our MVTec Newsletter!

Geschäftsführer: Dr. Olaf Munkelt
Amtsgericht München HRB 114695

MVTec Software GmbH Logo
-- 

Powered by kitware.com/cmake

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit https://cmake.org/services

Visit other Kitware open-source projects at https://www.kitware.com/platforms

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

This mailing list is deprecated in favor of https://discourse.cmake.org

Re: [CMake] build step is not thread-safe for CMake

[Eric Doenges]

Am 10.02.20 um 14:23 schrieb Kyle Edwards via CMake:

On Mon, 2020-02-10 at 12:49 +, hex wrote:

hello,

My build step is not thread-safe (the instruction in the COMMAND
part). Every build step depends on one source file:

add_custom_command(
     DEPENDS on_source.file
     OUTPUT
     object_file_for_source_file
     COMMAND not-thread-safe-compiler --build on_source.file
     COMMENT
             "Building Source object"
)

add_custom_target DEPENDS on OUTPUT from all custom command's, but in
order to prevent parallel execution when cmake is called:

cmake --build . --target all -j30

I need to build each step in any order, but still not as a dependency
as this would trigger unnecessary recompilation. Using
MAIN_DEPENDENCY defines hierarchical dependency, but this won't help
in this situation.

I cannot figure out how to prevent parallel execution of COMMAND in
CMake. The only option I see is a single command

add_custom_target(tgt
     DEPENDS on_all_source.files
     COMMAND not-thread-safe-compiler --build on_source1.file
     COMMAND not-thread-safe-compiler --build on_source2.file
     COMMAND not-thread-safe-compiler --build on_source3.file
     . . .
     COMMENT
             "Building target"
)

this would rebuild every source, though.

How do I set this up?

thank you

It sounds like you want order-only dependencies: dependencies the
command waits for before building, but whose changes do not actually
trigger a rebuild. As far as I know, add_custom_command() doesn't have
support for this - perhaps it could be added.


Actually, I think it kind of does, at least with the Ninja generator. If 
you do something like


add_custom_output(OUTPUT fileA COMMAND ...)
add_custom_target(fileA_target DEPENDS fileA)

add_custom_output(OUTPUT fileB DEPENDS fileA COMMAND ...)
add_custom_output(OUTPUT fileC DEPENDS fileA_target COMMAND ...)

then both fileB and fileC will depend on fileA existing, but fileC will 
not be rebuilt if fileA changes, while fileB will be.


Disclaimer - I couldn't find this behavior described in the 
documentation, but it is what I've observed after spending extensive 
amounts of time messing about with add_custom_command() and 
add_custom_target() to build the documentation to our product with CMake 
3.16. Also, I've only tested this with the Ninja generator, so it may 
behave differently with other generators.


With kind regards,
Eric Dönges

*Dr. Eric Dönges*
Senior Software Engineer

MVTec Software GmbH | Arnulfstr. 205 | 80634 Munich | Germany
doen...@mvtec.com  | Tel: +49 89 457 695-0 | 
www.mvtec.com 


Find our privacy policy here .

Sign up  for our MVTec Newsletter!

Geschäftsführer: Dr. Olaf Munkelt
Amtsgericht München HRB 114695

MVTec Software GmbH Logo
-- 

Powered by kitware.com/cmake

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit https://cmake.org/services

Visit other Kitware open-source projects at https://www.kitware.com/platforms

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

This mailing list is deprecated in favor of https://discourse.cmake.org