Problem with try_compile() for iOS

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

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.000000000 +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
[hidden email] | 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