From mellery451 at gmail.com Tue Aug 1 00:28:59 2017 From: mellery451 at gmail.com (Michael Ellery) Date: Mon, 31 Jul 2017 21:28:59 -0700 Subject: [CMake] What is the default build type? In-Reply-To: References: Message-ID: > On Jul 31, 2017, at 8:48 PM, Florian Lindner wrote: > > Hello > > ccmake shows CMAKE_BUILD_TYPE as unset. From the compile commands it looks like also nothing like Debug nor Release. > > Why is there no well-defined default set? How can I set a default? > > Thanks, > Florian > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake my recollection is that an unspecified build type results in a build that has no optimizations and no debug symbols generated. I?m not sure what the motivation for those default flags is. If you want to default to DEBUG, something like this should work: if (NOT CMAKE_BUILD_TYPE) set(CMAKE_BUILD_TYPE Debug) endif() -MIke From d3ck0r at gmail.com Tue Aug 1 04:59:04 2017 From: d3ck0r at gmail.com (J Decker) Date: Tue, 1 Aug 2017 01:59:04 -0700 Subject: [CMake] What is the default build type? In-Reply-To: References: Message-ID: I like having something like this.... defines CMAKE_BUILD_TYPE to be a droplist of choices... ---- if( NOT CMAKE_CONFIGURATION_TYPES ) set( CMAKE_CONFIGURATION_TYPES debug release ) endif( NOT CMAKE_CONFIGURATION_TYPES ) set( CMAKE_BUILD_TYPE release CACHE STRING "Cached cmake build type" ) set_property(CACHE CMAKE_BUILD_TYPE PROPERTY STRINGS ${CMAKE_CONFIGURATION_TYPES} ) ----- https://cmake.org/cmake/help/v3.0/variable/CMAKE_CONFIGURATION_TYPES.html On Mon, Jul 31, 2017 at 9:28 PM, Michael Ellery wrote: > > > > On Jul 31, 2017, at 8:48 PM, Florian Lindner > wrote: > > > > Hello > > > > ccmake shows CMAKE_BUILD_TYPE as unset. From the compile commands it > looks like also nothing like Debug nor Release. > > > > Why is there no well-defined default set? How can I set a default? > > > > Thanks, > > Florian > > -- > > > > Powered by www.kitware.com > > > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > > > CMake Support: http://cmake.org/cmake/help/support.html > > CMake Consulting: http://cmake.org/cmake/help/consulting.html > > CMake Training Courses: http://cmake.org/cmake/help/training.html > > > > Visit other Kitware open-source projects at http://www.kitware.com/ > opensource/opensource.html > > > > Follow this link to subscribe/unsubscribe: > > http://public.kitware.com/mailman/listinfo/cmake > > > my recollection is that an unspecified build type results in a build that > has no optimizations and no debug symbols generated. I?m not sure what the > motivation for those default flags is. If you want to default to DEBUG, > something like this should work: > > if (NOT CMAKE_BUILD_TYPE) > set(CMAKE_BUILD_TYPE Debug) > endif() > > > -MIke > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/ > opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mailinglists at xgm.de Tue Aug 1 05:18:56 2017 From: mailinglists at xgm.de (Florian Lindner) Date: Tue, 1 Aug 2017 17:18:56 +0800 Subject: [CMake] Source is not rebuild when header changes Message-ID: <86968525-1b36-d60e-e269-3016b705afcd@xgm.de> Hello, on my project, which I'm currently testing with cmake, I just noticed, that when I modify a header, the project is not rebuilt. The CMakeLists.txt in the root dir is here: https://pastebin.com/vfReTM1N The other CMakeLists.txt resides in root/src and lists all the source (*.cpp) files using GLOBS and adds them to the parent scope: set (sourcesAllNoMain ${sourcesAllNoMain} PARENT_SCOPE) set (sourcesTests ${sourcesTests} PARENT_SCOPE) set (sourcesTarchTests ${sourcesTarchTests} PARENT_SCOPE) the questionable header file was not added recently, so I don't think its related to the GLOBs. The header file is also not listed in depends.make file. What other information can I give? Thanks, Florian From DLRdave at aol.com Tue Aug 1 06:32:39 2017 From: DLRdave at aol.com (David Cole) Date: Tue, 1 Aug 2017 06:32:39 -0400 Subject: [CMake] Source is not rebuild when header changes In-Reply-To: <86968525-1b36-d60e-e269-3016b705afcd@xgm.de> References: <86968525-1b36-d60e-e269-3016b705afcd@xgm.de> Message-ID: What source files include the header? Is one of them listed as a file in your project? Does the **including** file exist at CMake configure time, or is it generated later by a build step? What do the lines of code that include the header look like? CMake uses its own analysis of the source files to determine the depends information, since it needs to generate it without invoking the compiler. This leads to a less-than-100% rate of correctness in the depends information, although usually, it is misses "in the other direction" due to depending on a header file which is included in some conditionally compiled block. (So the typical problem is an extra dependency, not a missing one...) Perhaps passing along the includers and the exact lines and context of being included will give us a hint about why the dependency is not generated properly in your case. HTH, David C. On Tue, Aug 1, 2017 at 5:18 AM, Florian Lindner wrote: > Hello, > > on my project, which I'm currently testing with cmake, I just noticed, that when I modify a header, the project is not > rebuilt. > > The CMakeLists.txt in the root dir is here: https://pastebin.com/vfReTM1N > > The other CMakeLists.txt resides in root/src and lists all the source (*.cpp) files using GLOBS and adds them to the > parent scope: > > set (sourcesAllNoMain ${sourcesAllNoMain} PARENT_SCOPE) > set (sourcesTests ${sourcesTests} PARENT_SCOPE) > set (sourcesTarchTests ${sourcesTarchTests} PARENT_SCOPE) > > > the questionable header file was not added recently, so I don't think its related to the GLOBs. > > The header file is also not listed in depends.make file. > > What other information can I give? > > Thanks, > Florian > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake From mailinglists at xgm.de Tue Aug 1 06:47:26 2017 From: mailinglists at xgm.de (Florian Lindner) Date: Tue, 1 Aug 2017 18:47:26 +0800 Subject: [CMake] Source is not rebuild when header changes In-Reply-To: References: <86968525-1b36-d60e-e269-3016b705afcd@xgm.de> Message-ID: <584a1c55-d5e9-8bb8-917a-45a892c1f6a9@xgm.de> Hi, Am 01.08.2017 um 18:32 schrieb David Cole via CMake: > What source files include the header? It's included by src/mapping/config/MappingConfiguration.cpp https://github.com/precice/precice/blob/develop/src/mapping/config/MappingConfiguration.cpp https://github.com/precice/precice/blob/develop/src/mapping/PetRadialBasisFctMapping.hpp > Is one of them listed as a file in your project? Yes, it's also in the CMakeFiles: % ll build/cmake-debug/CMakeFiles/precice.dir/src/mapping/config/MappingConfiguration.cpp.o -rw-r--r-- 1 florian florian 1517472 1. Aug 15:08 build/cmake-debug/CMakeFiles/precice.dir/src/mapping/config/MappingConfiguration.cpp.o > Does the **including** file exist at CMake configure time, or is it > generated later by a build step? No, it's a standard plain file. > What do the lines of code that include the header look like? #include "mapping/PetRadialBasisFctMapping.hpp" > > CMake uses its own analysis of the source files to determine the > depends information, since it needs to generate it without invoking > the compiler. This leads to a less-than-100% rate of correctness in > the depends information, although usually, it is misses "in the other > direction" due to depending on a header file which is included in some > conditionally compiled block. (So the typical problem is an extra > dependency, not a missing one...) The header file is (not the including file or the #include itself) is guarded by a define #ifndef PRECICE_NO_PETSC which is not set. The build also contains the functionality which is guarded thereof. > Perhaps passing along the includers and the exact lines and context of > being included will give us a hint about why the dependency is not > generated properly in your case. I'm happy to provide whatever information I can. If you want to download the entire source of the project, tell me. Right now the CMake files are not yet in the repository, but I can create a branch and add them there. My CMake version is 3.8.2. Best, Florian > > > > On Tue, Aug 1, 2017 at 5:18 AM, Florian Lindner wrote: >> Hello, >> >> on my project, which I'm currently testing with cmake, I just noticed, that when I modify a header, the project is not >> rebuilt. >> >> The CMakeLists.txt in the root dir is here: https://pastebin.com/vfReTM1N >> >> The other CMakeLists.txt resides in root/src and lists all the source (*.cpp) files using GLOBS and adds them to the >> parent scope: >> >> set (sourcesAllNoMain ${sourcesAllNoMain} PARENT_SCOPE) >> set (sourcesTests ${sourcesTests} PARENT_SCOPE) >> set (sourcesTarchTests ${sourcesTarchTests} PARENT_SCOPE) >> >> >> the questionable header file was not added recently, so I don't think its related to the GLOBs. >> >> The header file is also not listed in depends.make file. >> >> What other information can I give? >> >> Thanks, >> Florian >> -- >> >> Powered by www.kitware.com >> >> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ >> >> Kitware offers various services to support the CMake community. For more information on each offering, please visit: >> >> CMake Support: http://cmake.org/cmake/help/support.html >> CMake Consulting: http://cmake.org/cmake/help/consulting.html >> CMake Training Courses: http://cmake.org/cmake/help/training.html >> >> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/cmake From DLRdave at aol.com Tue Aug 1 09:18:20 2017 From: DLRdave at aol.com (David Cole) Date: Tue, 1 Aug 2017 09:18:20 -0400 Subject: [CMake] Source is not rebuild when header changes In-Reply-To: <584a1c55-d5e9-8bb8-917a-45a892c1f6a9@xgm.de> References: <86968525-1b36-d60e-e269-3016b705afcd@xgm.de> <584a1c55-d5e9-8bb8-917a-45a892c1f6a9@xgm.de> Message-ID: And in your file "src/CMakeLists.txt" do you add "${CMAKE_CURRENT_SOURCE_DIR}" (or anything else which resolves to the "src" directory) to your include directories? The line which includes the header is #include "mapping/..." but there is no local subdirectory "mapping" relative to that file (which is down in the mapping/config dir) On Tue, Aug 1, 2017 at 6:47 AM, Florian Lindner wrote: > Hi, > > Am 01.08.2017 um 18:32 schrieb David Cole via CMake: >> What source files include the header? > > It's included by src/mapping/config/MappingConfiguration.cpp > > https://github.com/precice/precice/blob/develop/src/mapping/config/MappingConfiguration.cpp > > https://github.com/precice/precice/blob/develop/src/mapping/PetRadialBasisFctMapping.hpp > >> Is one of them listed as a file in your project? > > Yes, it's also in the CMakeFiles: > > % ll build/cmake-debug/CMakeFiles/precice.dir/src/mapping/config/MappingConfiguration.cpp.o > > -rw-r--r-- 1 florian florian 1517472 1. Aug 15:08 > build/cmake-debug/CMakeFiles/precice.dir/src/mapping/config/MappingConfiguration.cpp.o > >> Does the **including** file exist at CMake configure time, or is it >> generated later by a build step? > > No, it's a standard plain file. > >> What do the lines of code that include the header look like? > > #include "mapping/PetRadialBasisFctMapping.hpp" > >> >> CMake uses its own analysis of the source files to determine the >> depends information, since it needs to generate it without invoking >> the compiler. This leads to a less-than-100% rate of correctness in >> the depends information, although usually, it is misses "in the other >> direction" due to depending on a header file which is included in some >> conditionally compiled block. (So the typical problem is an extra >> dependency, not a missing one...) > > The header file is (not the including file or the #include itself) is guarded by a define > > #ifndef PRECICE_NO_PETSC > > which is not set. The build also contains the functionality which is guarded thereof. > >> Perhaps passing along the includers and the exact lines and context of >> being included will give us a hint about why the dependency is not >> generated properly in your case. > > I'm happy to provide whatever information I can. > > If you want to download the entire source of the project, tell me. Right now the CMake files are not yet in the > repository, but I can create a branch and add them there. > > My CMake version is 3.8.2. > > Best, > Florian > > >> >> >> >> On Tue, Aug 1, 2017 at 5:18 AM, Florian Lindner wrote: >>> Hello, >>> >>> on my project, which I'm currently testing with cmake, I just noticed, that when I modify a header, the project is not >>> rebuilt. >>> >>> The CMakeLists.txt in the root dir is here: https://pastebin.com/vfReTM1N >>> >>> The other CMakeLists.txt resides in root/src and lists all the source (*.cpp) files using GLOBS and adds them to the >>> parent scope: >>> >>> set (sourcesAllNoMain ${sourcesAllNoMain} PARENT_SCOPE) >>> set (sourcesTests ${sourcesTests} PARENT_SCOPE) >>> set (sourcesTarchTests ${sourcesTarchTests} PARENT_SCOPE) >>> >>> >>> the questionable header file was not added recently, so I don't think its related to the GLOBs. >>> >>> The header file is also not listed in depends.make file. >>> >>> What other information can I give? >>> >>> Thanks, >>> Florian >>> -- >>> >>> Powered by www.kitware.com >>> >>> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ >>> >>> Kitware offers various services to support the CMake community. For more information on each offering, please visit: >>> >>> CMake Support: http://cmake.org/cmake/help/support.html >>> CMake Consulting: http://cmake.org/cmake/help/consulting.html >>> CMake Training Courses: http://cmake.org/cmake/help/training.html >>> >>> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html >>> >>> Follow this link to subscribe/unsubscribe: >>> http://public.kitware.com/mailman/listinfo/cmake From jchris.fillionr at kitware.com Tue Aug 1 15:57:51 2017 From: jchris.fillionr at kitware.com (Jean-Christophe Fillion-Robin) Date: Tue, 1 Aug 2017 15:57:51 -0400 Subject: [CMake] [ANNOUNCE] CMake 3.9.0 Python wheels available for download Message-ID: I am proud to announce that CMake 3.9.0 python wheels are now available for download using: pip install -U cmake See https://blog.kitware.com/cmake-python-wheels/ and https://pypi.python.org/pypi/cmake Documentation is available at: https://cmake.org/cmake/help/v3.9 Release notes are published at https://cmake.org/cmake/help/v3.9/release/3.9.html Documentation specific to the CMake python distribution at: http://cmake-python-distributions.readthedocs.io -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Tue Aug 1 16:52:09 2017 From: brad.king at kitware.com (Brad King) Date: Tue, 1 Aug 2017 16:52:09 -0400 Subject: [CMake] INTERPROCEDURAL_OPTIMIZATION still not using CMAKE__COMPILER_AR In-Reply-To: <597337ee.c7331c0a.1dac4.a299@mx.google.com> References: <597337ee.c7331c0a.1dac4.a299@mx.google.com> Message-ID: <1b51fca7-fc81-b9a3-213e-b9cdb93bc3d2@kitware.com> On 07/22/2017 07:33 AM, lectem at gmail.com wrote: > So I downloaded the 3.9 release and thought my LTO nightmares we over but > cmake still isn't using CMAKE__COMPILER_AR when linking on MSYS. The problem is that this code: https://gitlab.kitware.com/cmake/cmake/blob/v3.9.0/Modules/Platform/Windows-GNU.cmake#L117-127 inserts use of the archiver into the main linking process as a way to work around Windows command-line length limits. Since it is using the archiver as part of linking instead of just for creating a static library, our logic to switch to CMAKE__COMPILER_AR for LTO is not triggering. -Brad From post at hendrik-sattler.de Tue Aug 1 23:15:11 2017 From: post at hendrik-sattler.de (Hendrik Sattler) Date: Wed, 02 Aug 2017 05:15:11 +0200 Subject: [CMake] INTERPROCEDURAL_OPTIMIZATION still not using CMAKE__COMPILER_AR In-Reply-To: <1b51fca7-fc81-b9a3-213e-b9cdb93bc3d2@kitware.com> References: <597337ee.c7331c0a.1dac4.a299@mx.google.com> <1b51fca7-fc81-b9a3-213e-b9cdb93bc3d2@kitware.com> Message-ID: <7383BBAE-F301-45CB-8E45-EFE7BDC7D430@hendrik-sattler.de> Am 1. August 2017 22:52:09 MESZ schrieb Brad King : >On 07/22/2017 07:33 AM, lectem at gmail.com wrote: >> So I downloaded the 3.9 release and thought my LTO nightmares we over >but >> cmake still isn't using CMAKE__COMPILER_AR when linking on >MSYS. > >The problem is that this code: > >https://gitlab.kitware.com/cmake/cmake/blob/v3.9.0/Modules/Platform/Windows-GNU.cmake#L117-127 > >inserts use of the archiver into the main linking process as a way >to work around Windows command-line length limits. Since it is >using the archiver as part of linking instead of just for creating >a static library, our logic to switch to CMAKE__COMPILER_AR >for LTO is not triggering. And the code to detect that gcc uses GNU ld is broken as it does not check if gcc was actually built using the right configure flags! If it isn't configured for GNU ld, it does not forward the response file to the collect2 command and the command line length thing breaks it. This is independent of the actual ld binary. HS -- Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet. From mailinglists at xgm.de Wed Aug 2 00:17:36 2017 From: mailinglists at xgm.de (Florian Lindner) Date: Wed, 2 Aug 2017 12:17:36 +0800 Subject: [CMake] Source is not rebuild when header changes In-Reply-To: References: <86968525-1b36-d60e-e269-3016b705afcd@xgm.de> <584a1c55-d5e9-8bb8-917a-45a892c1f6a9@xgm.de> Message-ID: <304014bb-f0fc-4eee-5c6b-8fe8f91402d6@xgm.de> Am 01.08.2017 um 21:18 schrieb David Cole: > And in your file "src/CMakeLists.txt" do you add > "${CMAKE_CURRENT_SOURCE_DIR}" (or anything else which resolves to the > "src" directory) to your include directories? No, there is none. I do not added one, since it built correctly. I have no added include_directories(${CMAKE_CURRENT_SOURCE_DIR}), but it still does not get changes to the header. The complete src/CMakeLists.txt: https://pastebin.com/tnQPF2Gj Again, ./CMakeLists.txt: https://pastebin.com/vfReTM1N % grep PetRadial CMakeFiles/precice.dir/* CMakeFiles/precice.dir/CXX.includecache:mapping/PetRadialBasisFctMapping.hpp CMakeFiles/precice.dir/CXX.includecache:/home/florian/precice/src/mapping/config/mapping/PetRadialBasisFctMapping.hpp > > The line which includes the header is > #include "mapping/..." > but there is no local subdirectory "mapping" relative to that file > (which is down in the mapping/config dir) Yes, the include is relative to ./src. Best Thanks, Florian > > > > > On Tue, Aug 1, 2017 at 6:47 AM, Florian Lindner wrote: >> Hi, >> >> Am 01.08.2017 um 18:32 schrieb David Cole via CMake: >>> What source files include the header? >> >> It's included by src/mapping/config/MappingConfiguration.cpp >> >> https://github.com/precice/precice/blob/develop/src/mapping/config/MappingConfiguration.cpp >> >> https://github.com/precice/precice/blob/develop/src/mapping/PetRadialBasisFctMapping.hpp >> >>> Is one of them listed as a file in your project? >> >> Yes, it's also in the CMakeFiles: >> >> % ll build/cmake-debug/CMakeFiles/precice.dir/src/mapping/config/MappingConfiguration.cpp.o >> >> -rw-r--r-- 1 florian florian 1517472 1. Aug 15:08 >> build/cmake-debug/CMakeFiles/precice.dir/src/mapping/config/MappingConfiguration.cpp.o >> >>> Does the **including** file exist at CMake configure time, or is it >>> generated later by a build step? >> >> No, it's a standard plain file. >> >>> What do the lines of code that include the header look like? >> >> #include "mapping/PetRadialBasisFctMapping.hpp" >> >>> >>> CMake uses its own analysis of the source files to determine the >>> depends information, since it needs to generate it without invoking >>> the compiler. This leads to a less-than-100% rate of correctness in >>> the depends information, although usually, it is misses "in the other >>> direction" due to depending on a header file which is included in some >>> conditionally compiled block. (So the typical problem is an extra >>> dependency, not a missing one...) >> >> The header file is (not the including file or the #include itself) is guarded by a define >> >> #ifndef PRECICE_NO_PETSC >> >> which is not set. The build also contains the functionality which is guarded thereof. >> >>> Perhaps passing along the includers and the exact lines and context of >>> being included will give us a hint about why the dependency is not >>> generated properly in your case. >> >> I'm happy to provide whatever information I can. >> >> If you want to download the entire source of the project, tell me. Right now the CMake files are not yet in the >> repository, but I can create a branch and add them there. >> >> My CMake version is 3.8.2. >> >> Best, >> Florian >> >> >>> >>> >>> >>> On Tue, Aug 1, 2017 at 5:18 AM, Florian Lindner wrote: >>>> Hello, >>>> >>>> on my project, which I'm currently testing with cmake, I just noticed, that when I modify a header, the project is not >>>> rebuilt. >>>> >>>> The CMakeLists.txt in the root dir is here: https://pastebin.com/vfReTM1N >>>> >>>> The other CMakeLists.txt resides in root/src and lists all the source (*.cpp) files using GLOBS and adds them to the >>>> parent scope: >>>> >>>> set (sourcesAllNoMain ${sourcesAllNoMain} PARENT_SCOPE) >>>> set (sourcesTests ${sourcesTests} PARENT_SCOPE) >>>> set (sourcesTarchTests ${sourcesTarchTests} PARENT_SCOPE) >>>> >>>> >>>> the questionable header file was not added recently, so I don't think its related to the GLOBs. >>>> >>>> The header file is also not listed in depends.make file. >>>> >>>> What other information can I give? >>>> >>>> Thanks, >>>> Florian >>>> -- >>>> >>>> Powered by www.kitware.com >>>> >>>> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ >>>> >>>> Kitware offers various services to support the CMake community. For more information on each offering, please visit: >>>> >>>> CMake Support: http://cmake.org/cmake/help/support.html >>>> CMake Consulting: http://cmake.org/cmake/help/consulting.html >>>> CMake Training Courses: http://cmake.org/cmake/help/training.html >>>> >>>> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html >>>> >>>> Follow this link to subscribe/unsubscribe: >>>> http://public.kitware.com/mailman/listinfo/cmake From mailinglists at xgm.de Wed Aug 2 00:57:36 2017 From: mailinglists at xgm.de (Florian Lindner) Date: Wed, 2 Aug 2017 12:57:36 +0800 Subject: [CMake] What is the default build type? In-Reply-To: References: Message-ID: <9ee5b0f6-4272-8043-88ca-a020aab880a8@xgm.de> Hi, Am 01.08.2017 um 16:59 schrieb J Decker: > I like having something like this.... defines CMAKE_BUILD_TYPE to be a droplist of choices... > > ---- > > if( NOT CMAKE_CONFIGURATION_TYPES ) > set( CMAKE_CONFIGURATION_TYPES debug release ) > endif( NOT CMAKE_CONFIGURATION_TYPES ) > > set( CMAKE_BUILD_TYPE release CACHE STRING "Cached cmake build type" ) > set_property(CACHE CMAKE_BUILD_TYPE PROPERTY STRINGS ${CMAKE_CONFIGURATION_TYPES} ) The droplist is really cool! Can't understand why it's not the default this way. https://cmake.org/cmake/help/v3.0/variable/CMAKE_CONFIGURATION_TYPES.html says "This has reasonable defaults on most platforms...", but when I message(${CMAKE_CONFIGURATION_TYPES}) it is empty. Why that? That code also does not seem to set the default: if(NOT CMAKE_CONFIGURATION_TYPES) set(CMAKE_CONFIGURATION_TYPES Debug Release RelWithDebInfo) endif() set(CMAKE_BUILD_TYPE Debug CACHE STRING "Build Type") set_property(CACHE CMAKE_BUILD_TYPE PROPERTY STRINGS ${CMAKE_CONFIGURATION_TYPES} ) So the first commands set the cached value of the string "Build type". The second commands sets the property STRINGS of the variable CMAKE_BUILD_TYPE. Is that correct? # if (NOT CMAKE_BUILD_TYPE) # set(CMAKE_BUILD_TYPE Debug) Uncommenting this sets the default non builds with cmake, but not on ccmake (at least not in the GUI). # endif() message(STATUS "Build configuration: " ${CMAKE_BUILD_TYPE}) Best Thanks, Florian > > > ----- > > https://cmake.org/cmake/help/v3.0/variable/CMAKE_CONFIGURATION_TYPES.html > > On Mon, Jul 31, 2017 at 9:28 PM, Michael Ellery > wrote: > > > > > On Jul 31, 2017, at 8:48 PM, Florian Lindner > wrote: > > > > Hello > > > > ccmake shows CMAKE_BUILD_TYPE as unset. From the compile commands it looks like also nothing like Debug nor Release. > > > > Why is there no well-defined default set? How can I set a default? > > > > Thanks, > > Florian > > -- > > > > Powered by www.kitware.com > > > > Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ > > > > > Kitware offers various services to support the CMake community. For more information on each offering, please visit: > > > > CMake Support: http://cmake.org/cmake/help/support.html > > CMake Consulting: http://cmake.org/cmake/help/consulting.html > > CMake Training Courses: http://cmake.org/cmake/help/training.html > > > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > > > > Follow this link to subscribe/unsubscribe: > > http://public.kitware.com/mailman/listinfo/cmake > > > my recollection is that an unspecified build type results in a build that has no optimizations and no debug symbols > generated. I?m not sure what the motivation for those default flags is. If you want to default to DEBUG, something > like this should work: > > if (NOT CMAKE_BUILD_TYPE) > set(CMAKE_BUILD_TYPE Debug) > endif() > > > -MIke > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ > > > Kitware offers various services to support the CMake community. For more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake > > From bo.schwarzstein at gmail.com Wed Aug 2 03:03:58 2017 From: bo.schwarzstein at gmail.com (Bo Zhou) Date: Wed, 2 Aug 2017 16:03:58 +0900 Subject: [CMake] What is the default build type? In-Reply-To: <9ee5b0f6-4272-8043-88ca-a020aab880a8@xgm.de> References: <9ee5b0f6-4272-8043-88ca-a020aab880a8@xgm.de> Message-ID: It depends on the Generator. To the Makefile, the actual type was controlled by the compiler options. If you don't specific any type, usually it means non-debug and non-optimization because the CMAKE_CXX_FLAGS is empty as default. This is critical, so usually people should specific the actual type they want to build. To the generator of the IDE, such as Visual Studio and Xcode, the CMAKE_BUILD_TYPE doesn't make sense but we have to use CMAKE_CONFIGURATION_TYPES, then CMake will create the several configuration sets for the IDE from the CMAKE_C|CXX_FLAGS_{CONFIG} . On Wed, Aug 2, 2017 at 1:57 PM, Florian Lindner wrote: > Hi, > > Am 01.08.2017 um 16:59 schrieb J Decker: > > I like having something like this.... defines CMAKE_BUILD_TYPE to be a > droplist of choices... > > > > ---- > > > > if( NOT CMAKE_CONFIGURATION_TYPES ) > > set( CMAKE_CONFIGURATION_TYPES debug release ) > > endif( NOT CMAKE_CONFIGURATION_TYPES ) > > > > set( CMAKE_BUILD_TYPE release CACHE STRING "Cached cmake build type" ) > > set_property(CACHE CMAKE_BUILD_TYPE PROPERTY STRINGS > ${CMAKE_CONFIGURATION_TYPES} ) > > The droplist is really cool! Can't understand why it's not the default > this way. > > https://cmake.org/cmake/help/v3.0/variable/CMAKE_CONFIGURATION_TYPES.html > says "This has reasonable defaults on most > platforms...", but when I message(${CMAKE_CONFIGURATION_TYPES}) it is > empty. Why that? > > That code also does not seem to set the default: > > if(NOT CMAKE_CONFIGURATION_TYPES) > set(CMAKE_CONFIGURATION_TYPES Debug Release RelWithDebInfo) > endif() > > set(CMAKE_BUILD_TYPE Debug CACHE STRING "Build Type") > set_property(CACHE CMAKE_BUILD_TYPE PROPERTY STRINGS > ${CMAKE_CONFIGURATION_TYPES} ) > > So the first commands set the cached value of the string "Build type". The > second commands sets the property STRINGS of > the variable CMAKE_BUILD_TYPE. Is that correct? > > > # if (NOT CMAKE_BUILD_TYPE) > # set(CMAKE_BUILD_TYPE Debug) > > Uncommenting this sets the default non builds with cmake, but not on > ccmake (at least not in the GUI). > > # endif() > message(STATUS "Build configuration: " ${CMAKE_BUILD_TYPE}) > > > Best Thanks, > Florian > > > > > > > ----- > > > > https://cmake.org/cmake/help/v3.0/variable/CMAKE_ > CONFIGURATION_TYPES.html > > > > On Mon, Jul 31, 2017 at 9:28 PM, Michael Ellery > wrote: > > > > > > > > > On Jul 31, 2017, at 8:48 PM, Florian Lindner > wrote: > > > > > > Hello > > > > > > ccmake shows CMAKE_BUILD_TYPE as unset. From the compile commands > it looks like also nothing like Debug nor Release. > > > > > > Why is there no well-defined default set? How can I set a default? > > > > > > Thanks, > > > Florian > > > -- > > > > > > 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 < > http://cmake.org/cmake/help/support.html> > > > CMake Consulting: http://cmake.org/cmake/help/consulting.html < > http://cmake.org/cmake/help/consulting.html> > > > CMake Training Courses: http://cmake.org/cmake/help/training.html > > > > > > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > > > > > > > Follow this link to subscribe/unsubscribe: > > > http://public.kitware.com/mailman/listinfo/cmake < > http://public.kitware.com/mailman/listinfo/cmake> > > > > > > my recollection is that an unspecified build type results in a build > that has no optimizations and no debug symbols > > generated. I?m not sure what the motivation for those default flags > is. If you want to default to DEBUG, something > > like this should work: > > > > if (NOT CMAKE_BUILD_TYPE) > > set(CMAKE_BUILD_TYPE Debug) > > endif() > > > > > > -MIke > > > > -- > > > > 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 < > http://cmake.org/cmake/help/support.html> > > CMake Consulting: http://cmake.org/cmake/help/consulting.html < > http://cmake.org/cmake/help/consulting.html> > > CMake Training Courses: http://cmake.org/cmake/help/training.html < > http://cmake.org/cmake/help/training.html> > > > > Visit other Kitware open-source projects at http://www.kitware.com/ > opensource/opensource.html > > > > > > Follow this link to subscribe/unsubscribe: > > http://public.kitware.com/mailman/listinfo/cmake < > http://public.kitware.com/mailman/listinfo/cmake> > > > > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/ > opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake > -------------- next part -------------- An HTML attachment was scrubbed... URL: From davidklind at gmail.com Wed Aug 2 11:12:52 2017 From: davidklind at gmail.com (DKLind) Date: Wed, 2 Aug 2017 08:12:52 -0700 (MST) Subject: [CMake] Replace default "make all" with "make help" Message-ID: <1501686772673-7595988.post@n2.nabble.com> Is it possible to replace the default target of the "Unix Makefiles" generated Makefile of 'all' with 'help'? By default, I mean when no target is specified when invoking 'make', the 'all' target is assumed. -- View this message in context: http://cmake.3232098.n2.nabble.com/Replace-default-make-all-with-make-help-tp7595988.html Sent from the CMake mailing list archive at Nabble.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcus.hanwell at kitware.com Wed Aug 2 11:55:35 2017 From: marcus.hanwell at kitware.com (Marcus D. Hanwell) Date: Wed, 2 Aug 2017 11:55:35 -0400 Subject: [CMake] What is the default build type? In-Reply-To: References: <9ee5b0f6-4272-8043-88ca-a020aab880a8@xgm.de> Message-ID: On Wed, Aug 2, 2017 at 3:03 AM, Bo Zhou wrote: > It depends on the Generator. > > To the Makefile, the actual type was controlled by the compiler options. > If you don't specific any type, usually it means non-debug and > non-optimization because the CMAKE_CXX_FLAGS is empty as default. This is > critical, so usually people should specific the actual type they want to > build. > > To the generator of the IDE, such as Visual Studio and Xcode, the > CMAKE_BUILD_TYPE doesn't make sense but we have to use > CMAKE_CONFIGURATION_TYPES, then CMake will create the several configuration > sets for the IDE from the CMAKE_C|CXX_FLAGS_{CONFIG} . > This thread inspired me to write up how we have been doing it in some of the projects I work on for quite a while now, https://blog.kitware.com/cmake-and-the-default-build-type/ It certainly isn't the only way, but it provides an easy path to ensure things show up in the GUIs, respect build types passed in, etc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From DLRdave at aol.com Wed Aug 2 13:32:01 2017 From: DLRdave at aol.com (David Cole) Date: Wed, 2 Aug 2017 13:32:01 -0400 Subject: [CMake] What is the default build type? In-Reply-To: References: <9ee5b0f6-4272-8043-88ca-a020aab880a8@xgm.de> Message-ID: Very cool, Marcus. Thanks for the blog post. Florian, when you "message(${CMAKE_CONFIGURATION_TYPES})" it is empty because you are using a single-configuration CMake generator. Only Visual Studio and Xcode (and possibly other) **multi** config generators have a list of values in CMAKE_CONFIGURATION_TYPES. Contrary to the previous recommendation, I would NOT recommend setting it to a list in a single configuration generator. If you're using a multi-config generator, you can set up a subset for it to use with this, but in a single config generator, this variable SHOULD be empty, and you should not give it contents in that case. HTH, David C. On Wed, Aug 2, 2017 at 11:55 AM, Marcus D. Hanwell wrote: > On Wed, Aug 2, 2017 at 3:03 AM, Bo Zhou wrote: >> >> It depends on the Generator. >> >> To the Makefile, the actual type was controlled by the compiler options. >> If you don't specific any type, usually it means non-debug and >> non-optimization because the CMAKE_CXX_FLAGS is empty as default. This is >> critical, so usually people should specific the actual type they want to >> build. >> >> To the generator of the IDE, such as Visual Studio and Xcode, the >> CMAKE_BUILD_TYPE doesn't make sense but we have to use >> CMAKE_CONFIGURATION_TYPES, then CMake will create the several configuration >> sets for the IDE from the CMAKE_C|CXX_FLAGS_{CONFIG} . > > > This thread inspired me to write up how we have been doing it in some of the > projects I work on for quite a while now, > > https://blog.kitware.com/cmake-and-the-default-build-type/ > > It certainly isn't the only way, but it provides an easy path to ensure > things show up in the GUIs, respect build types passed in, etc. > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake From marcus.hanwell at kitware.com Wed Aug 2 14:36:34 2017 From: marcus.hanwell at kitware.com (Marcus D. Hanwell) Date: Wed, 2 Aug 2017 14:36:34 -0400 Subject: [CMake] What is the default build type? In-Reply-To: References: <9ee5b0f6-4272-8043-88ca-a020aab880a8@xgm.de> Message-ID: On Wed, Aug 2, 2017 at 1:32 PM, David Cole wrote: > > Very cool, Marcus. Thanks for the blog post. > > Florian, when you "message(${CMAKE_CONFIGURATION_TYPES})" it is empty > because you are using a single-configuration CMake generator. Only > Visual Studio and Xcode (and possibly other) **multi** config > generators have a list of values in CMAKE_CONFIGURATION_TYPES. > Contrary to the previous recommendation, I would NOT recommend setting > it to a list in a single configuration generator. If you're using a > multi-config generator, you can set up a subset for it to use with > this, but in a single config generator, this variable SHOULD be empty, > and you should not give it contents in that case. > Why you would not recommend setting it to a list for a single configuration generator. From marcus.hanwell at kitware.com Wed Aug 2 14:42:52 2017 From: marcus.hanwell at kitware.com (Marcus D. Hanwell) Date: Wed, 2 Aug 2017 14:42:52 -0400 Subject: [CMake] What is the default build type? In-Reply-To: References: <9ee5b0f6-4272-8043-88ca-a020aab880a8@xgm.de> Message-ID: On Wed, Aug 2, 2017 at 1:32 PM, David Cole wrote: > Very cool, Marcus. Thanks for the blog post. > > Florian, when you "message(${CMAKE_CONFIGURATION_TYPES})" it is empty > because you are using a single-configuration CMake generator. Only > Visual Studio and Xcode (and possibly other) **multi** config > generators have a list of values in CMAKE_CONFIGURATION_TYPES. > Contrary to the previous recommendation, I would NOT recommend setting > it to a list in a single configuration generator. If you're using a > multi-config generator, you can set up a subset for it to use with > this, but in a single config generator, this variable SHOULD be empty, > and you should not give it contents in that case. > Terrible English, try number two... Why would you not recommend setting it, and what do you mean by it? I was not setting CMAKE_CONFIGURATION_TYPES to anything, but the CMAKE_BUILD_TYPE property is manipulated to offer the list, and then the CMAKE_BUILD_TYPE variable is populated if it is empty in my example. From DLRdave at aol.com Wed Aug 2 14:50:22 2017 From: DLRdave at aol.com (David Cole) Date: Wed, 2 Aug 2017 14:50:22 -0400 Subject: [CMake] What is the default build type? In-Reply-To: References: <9ee5b0f6-4272-8043-88ca-a020aab880a8@xgm.de> Message-ID: Yes, your code is a good example Marcus. It was one of the previous suggestions on this thread which had example code setting CMAKE_CONFIGURATION_TYPES. I would recommend against setting this variable because in some places in CMake code, it is used as an approximate proxy for whether or not a multi-configuration generator is being used. For a few examples, see the CMake code base itself: $ git grep CMAKE_CONFIGURATION_TYPES | grep -Ev "Auxiliary/vim/syntax/cmake.vim|Help/|Tests/" CMakeCPack.cmake: if(CMAKE_CONFIGURATION_TYPES) Modules/CMakeExpandImportedTargets.cmake:# ${CMAKE_CONFIGURATION_TYPES} if set, otherwise ${CMAKE_BUILD_TYPE}. Modules/CMakeExpandImportedTargets.cmake: if(CMAKE_CONFIGURATION_TYPES) Modules/CMakeExpandImportedTargets.cmake: list(GET CMAKE_CONFIGURATION_TYPES 0 CEIT_CONFIGURATION) Modules/CTestTargets.cmake:if(CMAKE_CONFIGURATION_TYPES) Modules/DeployQt4.cmake: if(configurations AND (CMAKE_CONFIGURATION_TYPES OR CMAKE_BUILD_TYPE)) Modules/DeployQt4.cmake: if(CMAKE_CONFIGURATION_TYPES OR CMAKE_BUILD_TYPE) Modules/ExternalProject.cmake: if(CMAKE_CONFIGURATION_TYPES) Modules/ExternalProject.cmake: if(CMAKE_CONFIGURATION_TYPES) Modules/ExternalProject.cmake: if(CMAKE_CONFIGURATION_TYPES) Modules/ExternalProject.cmake: if(CMAKE_CONFIGURATION_TYPES) Modules/ExternalProject.cmake: foreach(cfg ${CMAKE_CONFIGURATION_TYPES}) Modules/FindBoost.cmake: if(CMAKE_CONFIGURATION_TYPES OR CMAKE_BUILD_TYPE) Modules/FindCUDA.cmake:# Makefile and similar generators don't define CMAKE_CONFIGURATION_TYPES, so we Modules/FindCUDA.cmake:set(CUDA_configuration_types ${CMAKE_CONFIGURATION_TYPES} ${CMAKE_BUILD_TYPE} Debug MinSizeRel Release RelWithDebInfo) Modules/FindQt4.cmake: if (CMAKE_CONFIGURATION_TYPES OR CMAKE_BUILD_TYPE) Modules/SelectLibraryConfigurations.cmake: ( CMAKE_CONFIGURATION_TYPES OR CMAKE_BUILD_TYPE ) ) Source/cmGlobalVisualStudio7Generator.cxx: if (!mf->GetDefinition("CMAKE_CONFIGURATION_TYPES")) { Source/cmGlobalVisualStudio7Generator.cxx: "CMAKE_CONFIGURATION_TYPES", "Debug;Release;MinSizeRel;RelWithDebInfo", Source/cmGlobalXCodeGenerator.cxx: if (!mf->GetDefinition("CMAKE_CONFIGURATION_TYPES")) { Source/cmGlobalXCodeGenerator.cxx: "CMAKE_CONFIGURATION_TYPES", "Debug;Release;MinSizeRel;RelWithDebInfo", Source/cmGlobalXCodeGenerator.cxx: this->CurrentMakefile->GetRequiredDefinition("CMAKE_CONFIGURATION_TYPES"); Source/cmMakefile.cxx: this->GetDefinition("CMAKE_CONFIGURATION_TYPES")) { Utilities/Release/WiX/CMakeLists.txt:if(CMAKE_CONFIGURATION_TYPES) On Wed, Aug 2, 2017 at 2:42 PM, Marcus D. Hanwell wrote: > On Wed, Aug 2, 2017 at 1:32 PM, David Cole wrote: >> Very cool, Marcus. Thanks for the blog post. >> >> Florian, when you "message(${CMAKE_CONFIGURATION_TYPES})" it is empty >> because you are using a single-configuration CMake generator. Only >> Visual Studio and Xcode (and possibly other) **multi** config >> generators have a list of values in CMAKE_CONFIGURATION_TYPES. >> Contrary to the previous recommendation, I would NOT recommend setting >> it to a list in a single configuration generator. If you're using a >> multi-config generator, you can set up a subset for it to use with >> this, but in a single config generator, this variable SHOULD be empty, >> and you should not give it contents in that case. >> > Terrible English, try number two... Why would you not recommend > setting it, and what do you mean by it? I was not setting > CMAKE_CONFIGURATION_TYPES to anything, but the CMAKE_BUILD_TYPE > property is manipulated to offer the list, and then the > CMAKE_BUILD_TYPE variable is populated if it is empty in my example. From marcus.hanwell at kitware.com Wed Aug 2 14:57:34 2017 From: marcus.hanwell at kitware.com (Marcus D. Hanwell) Date: Wed, 2 Aug 2017 14:57:34 -0400 Subject: [CMake] What is the default build type? In-Reply-To: References: <9ee5b0f6-4272-8043-88ca-a020aab880a8@xgm.de> Message-ID: On Wed, Aug 2, 2017 at 2:50 PM, David Cole wrote: > Yes, your code is a good example Marcus. It was one of the previous > suggestions on this thread which had example code setting > CMAKE_CONFIGURATION_TYPES. > > I would recommend against setting this variable because in some places > in CMake code, it is used as an approximate proxy for whether or not a > multi-configuration generator is being used. > Ah, thanks for clearing that up, it was unclear if there were issues you spotted with what I posted, now I reread it I see. I thought I had been pretty careful not to pollute variables meant for multi-configuration generators :-) I may have even asked you about this many moons ago, and possibly got the enum-style list from something you posted. From d3ck0r at gmail.com Wed Aug 2 15:47:50 2017 From: d3ck0r at gmail.com (J Decker) Date: Wed, 2 Aug 2017 12:47:50 -0700 Subject: [CMake] What is the default build type? In-Reply-To: References: <9ee5b0f6-4272-8043-88ca-a020aab880a8@xgm.de> Message-ID: On Wed, Aug 2, 2017 at 11:50 AM, David Cole via CMake wrote: > Yes, your code is a good example Marcus. It was one of the previous > suggestions on this thread which had example code setting > CMAKE_CONFIGURATION_TYPES. > > I would recommend against setting this variable because in some places > in CMake code, it is used as an approximate proxy for whether or not a > multi-configuration generator is being used. > > > For a few examples, see the CMake code base itself: > > MinGW Makefiles supports multiple configurations; one at a time. And reading a few of these... > $ git grep CMAKE_CONFIGURATION_TYPES | grep -Ev > "Auxiliary/vim/syntax/cmake.vim|Help/|Tests/" CMakeCPack.cmake: if(CMAKE_CONFIGURATION_TYPES) > this one is not distributed, and I don't have it. > Modules/CMakeExpandImportedTargets.cmake:# > ${CMAKE_CONFIGURATION_TYPES} if set, otherwise ${CMAKE_BUILD_TYPE}. > Modules/CMakeExpandImportedTargets.cmake: > if(CMAKE_CONFIGURATION_TYPES) > Modules/CMakeExpandImportedTargets.cmake: list(GET > CMAKE_CONFIGURATION_TYPES 0 CEIT_CONFIGURATION) > the whole point is to get a good setting list for CMAKE_BUILD TYPE so this is harmless because built type will override the default behavior... # CONFIGURATION is given, it uses the first configuration from # ${CMAKE_CONFIGURATION_TYPES} if set, otherwise ${CMAKE_BUILD_TYPE}. > Modules/CTestTargets.cmake:if(CMAKE_CONFIGURATION_TYPES) > I would want this to pass CONFIGURATION_TYPES to included external projects because it's missing otherwise anyway. > Modules/DeployQt4.cmake: if(configurations AND > (CMAKE_CONFIGURATION_TYPES OR CMAKE_BUILD_TYPE)) > Modules/DeployQt4.cmake: if(CMAKE_CONFIGURATION_TYPES > OR CMAKE_BUILD_TYPE) > This is used to use the argument passed to the macro if CMAKE_BUILD_TYPE (this is what we want set anyway) OR CMAKE_CONFIGUATION_TYPES is set. > Modules/ExternalProject.cmake: if(CMAKE_CONFIGURATION_TYPES) > Modules/ExternalProject.cmake: if(CMAKE_CONFIGURATION_TYPES) > Modules/ExternalProject.cmake: if(CMAKE_CONFIGURATION_TYPES) > Modules/ExternalProject.cmake: if(CMAKE_CONFIGURATION_TYPES) > Modules/ExternalProject.cmake: foreach(cfg > ${CMAKE_CONFIGURATION_TYPES}) > In these cases, it makes sure to pass the build configuration passed from the core project, otherwise it leaves it blank. Since I want to specify the build configuration anyway, this should always be set if externalproject is used. > Modules/FindBoost.cmake: if(CMAKE_CONFIGURATION_TYPES OR > CMAKE_BUILD_TYPE) > if neither of these are set it sets release output. and we're trying to make sure that CMAKE_BUILD_TYPE is set to something not blank anyway. > Modules/FindCUDA.cmake:# Makefile and similar generators don't define > CMAKE_CONFIGURATION_TYPES, so we > Modules/FindCUDA.cmake:set(CUDA_configuration_types > ${CMAKE_CONFIGURATION_TYPES} ${CMAKE_BUILD_TYPE} Debug MinSizeRel > Release RelWithDebInfo) > This one includes already set configuration types, and add capitalized versions; then builds a list and removes duplicate because it sets all configurations to UPPER(); so this is harmless. and is a better implementation than the below SelectLibraryConfigurations.cmake: (comment block in FindCUDA) # Makefile and similar generators don't define CMAKE_CONFIGURATION_TYPES, so we # need to add another entry for the CMAKE_BUILD_TYPE. We also need to add the # standerd set of 4 build types (Debug, MinSizeRel, Release, and RelWithDebInfo) # for completeness. We need run this loop in order to accomodate the addition # of extra configuration types. Duplicate entries will be removed by # REMOVE_DUPLICATES. ...and yet they[makefile and similar] should have configuration types; because they can build all of those configurations. > Modules/FindQt4.cmake: if (CMAKE_CONFIGURATION_TYPES OR > CMAKE_BUILD_TYPE) > again- cmake_build_type is being set, so don't default to Release > Modules/SelectLibraryConfigurations.cmake: ( > CMAKE_CONFIGURATION_TYPES OR CMAKE_BUILD_TYPE ) ) > Would be triggered because we're setting CMAKE_BUILD_TYPE anyway..; and also does not support minreldebinfo or MinSizeRel; and instead only checks _DEBUG and _RELEASE targets. > Source/cmGlobalVisualStudio7Generator.cxx: if > (!mf->GetDefinition("CMAKE_CONFIGURATION_TYPES")) { > Source/cmGlobalVisualStudio7Generator.cxx: > "CMAKE_CONFIGURATION_TYPES", > "Debug;Release;MinSizeRel;RelWithDebInfo", Source/cmGlobalXCodeGenerator.cxx: if > (!mf->GetDefinition("CMAKE_CONFIGURATION_TYPES")) { > Source/cmGlobalXCodeGenerator.cxx: "CMAKE_CONFIGURATION_TYPES", > "Debug;Release;MinSizeRel;RelWithDebInfo", > Source/cmGlobalXCodeGenerator.cxx: > this->CurrentMakefile->GetRequiredDefinition("CMAKE_CONFIGURATION_TYPES"); > Source/cmMakefile.cxx: > this->GetDefinition("CMAKE_CONFIGURATION_TYPES")) { > Utilities/Release/WiX/CMakeLists.txt:if(CMAKE_CONFIGURATION_TYPES) > These would be used, and would set cmake_configuration_types so we don't have to; they set it, not use it. So, all in all, it looks like it is either indifferent to being set, or SHOULD be set to make sure configuration types are propagate (externalProject). I asked a LONG time ago why this wasn't set by default anyway, and was told 'because makefiles'... and yet I built all sortf of projects using makefile generators and found that I HAD to get this set anyway because I was building Debug and Release modes continuously there (one so I could debug, the other so I could test optimal); otherwise the output behavior was inconsistent and would overlap release and debug configuration builds. I subsequently fixed THAT by making sure to build in .../build/debug_projects and output to ../build/debug_out (install target) and ..../build/release_projects and .../build/release_out so iteritive building wouldn't get mixed debug and release objects trying to build into a library/executable. > > > > > On Wed, Aug 2, 2017 at 2:42 PM, Marcus D. Hanwell > wrote: > > On Wed, Aug 2, 2017 at 1:32 PM, David Cole wrote: > >> Very cool, Marcus. Thanks for the blog post. > >> > >> Florian, when you "message(${CMAKE_CONFIGURATION_TYPES})" it is empty > >> because you are using a single-configuration CMake generator. Only > >> Visual Studio and Xcode (and possibly other) **multi** config > >> generators have a list of values in CMAKE_CONFIGURATION_TYPES. > >> Contrary to the previous recommendation, I would NOT recommend setting > >> it to a list in a single configuration generator. If you're using a > >> multi-config generator, you can set up a subset for it to use with > >> this, but in a single config generator, this variable SHOULD be empty, > >> and you should not give it contents in that case. > >> > > Terrible English, try number two... Why would you not recommend > > setting it, and what do you mean by it? I was not setting > > CMAKE_CONFIGURATION_TYPES to anything, but the CMAKE_BUILD_TYPE > > property is manipulated to offer the list, and then the > > CMAKE_BUILD_TYPE variable is populated if it is empty in my example. > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/ > opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake > -------------- next part -------------- An HTML attachment was scrubbed... URL: From d3ck0r at gmail.com Wed Aug 2 16:18:52 2017 From: d3ck0r at gmail.com (J Decker) Date: Wed, 2 Aug 2017 13:18:52 -0700 Subject: [CMake] What is the default build type? In-Reply-To: References: <9ee5b0f6-4272-8043-88ca-a020aab880a8@xgm.de> Message-ID: On Wed, Aug 2, 2017 at 8:55 AM, Marcus D. Hanwell < marcus.hanwell at kitware.com> wrote: > On Wed, Aug 2, 2017 at 3:03 AM, Bo Zhou wrote: > >> It depends on the Generator. >> >> To the Makefile, the actual type was controlled by the compiler options. >> If you don't specific any type, usually it means non-debug and >> non-optimization because the CMAKE_CXX_FLAGS is empty as default. This is >> critical, so usually people should specific the actual type they want to >> build. >> >> To the generator of the IDE, such as Visual Studio and Xcode, the >> CMAKE_BUILD_TYPE doesn't make sense but we have to use >> CMAKE_CONFIGURATION_TYPES, then CMake will create the several configuration >> sets for the IDE from the CMAKE_C|CXX_FLAGS_{CONFIG} . >> > > This thread inspired me to write up how we have been doing it in some of > the projects I work on for quite a while now, > > https://blog.kitware.com/cmake-and-the-default-build-type/ > > These should use lower case 'debug' 'release' etc. Because if it's not VS, it's probably also not windows, and case matters. > It certainly isn't the only way, but it provides an easy path to ensure > things show up in the GUIs, respect build types passed in, etc. > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/ > opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake > -------------- next part -------------- An HTML attachment was scrubbed... URL: From d3ck0r at gmail.com Wed Aug 2 16:35:26 2017 From: d3ck0r at gmail.com (J Decker) Date: Wed, 2 Aug 2017 13:35:26 -0700 Subject: [CMake] Replace default "make all" with "make help" In-Reply-To: <1501686772673-7595988.post@n2.nabble.com> References: <1501686772673-7595988.post@n2.nabble.com> Message-ID: On Wed, Aug 2, 2017 at 8:12 AM, DKLind wrote: > Is it possible to replace the default target of the "Unix Makefiles" > generated Makefile of 'all' with 'help'? By default, I mean when no target > is specified when invoking 'make', the 'all' target is assumed. Because cmake works with so many targets, it's unlikely this would be of much use; ninja itself has ability to specify default target, but that's not available from CMake; also generators like Visual Studio, et al. don't have 'all' they have ALL_BUILD and no 'help' target. https://cmake.org/cmake/help/v3.0/command/build_command.html I suppose you could wrap your CMakeLists in another that checks $ and if not set, then trigger cmake --build with --target help.... that's probably a really bad idea in general though. If someone is using cmake to build though; one would think they would just 'know' that make help is a thing to do... Or - why would you want your one project to behave any different than all the others in the world? (or perhaps a nicer phrasing) Why do you want to do this? > > ------------------------------ > View this message in context: Replace default "make all" with "make help" > > Sent from the CMake mailing list archive > at Nabble.com. > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/ > opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake > -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcus.hanwell at kitware.com Thu Aug 3 10:24:40 2017 From: marcus.hanwell at kitware.com (Marcus D. Hanwell) Date: Thu, 3 Aug 2017 10:24:40 -0400 Subject: [CMake] What is the default build type? In-Reply-To: References: <9ee5b0f6-4272-8043-88ca-a020aab880a8@xgm.de> Message-ID: On Wed, Aug 2, 2017 at 4:18 PM, J Decker wrote: > > On Wed, Aug 2, 2017 at 8:55 AM, Marcus D. Hanwell wrote: >> >> On Wed, Aug 2, 2017 at 3:03 AM, Bo Zhou wrote: >>> >>> It depends on the Generator. >>> >>> To the Makefile, the actual type was controlled by the compiler options. If you don't specific any type, usually it means non-debug and non-optimization because the CMAKE_CXX_FLAGS is empty as default. This is critical, so usually people should specific the actual type they want to build. >>> >>> To the generator of the IDE, such as Visual Studio and Xcode, the CMAKE_BUILD_TYPE doesn't make sense but we have to use CMAKE_CONFIGURATION_TYPES, then CMake will create the several configuration sets for the IDE from the CMAKE_C|CXX_FLAGS_{CONFIG} . >> >> >> This thread inspired me to write up how we have been doing it in some of the projects I work on for quite a while now, >> >> https://blog.kitware.com/cmake-and-the-default-build-type/ >> > These should use lower case 'debug' 'release' etc. Because if it's not VS, it's probably also not windows, and case matters. > No, camel case works just fine. I took a quick look and lowercase will work, as well as all caps. I have used this for many years on Linux builds with Makefile/Ninja without issue. From ben.boeckel at kitware.com Thu Aug 3 11:58:58 2017 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Thu, 3 Aug 2017 11:58:58 -0400 Subject: [CMake] CMake 3.9 change to dependencies of object compilation In-Reply-To: <74B7C9CD2B43054BA63CDE61908202D96648B196@EDXMB90.jdnet.deere.com> Message-ID: <20170803155858.GA4124@megas.kitware.com> > . The Ninja generator has loosened the dependencies of object > compilation. Object compilation now depends only on custom targets and > custom commands associated with libraries on which the object's target > depends and no longer depends on the libraries themselves. Source > files in dependent targets may now compile without waiting for their > targets' dependencies to link. Correct. > We have a few cases where the object compilation really does depend on > the TARGET_FILE itself, e.g. > 1. An RC compiler embedding the resulting file of a custom target (I > think this one may still work, since custom targets appear to have > been exempted from the change) Correct, though this issue: https://gitlab.kitware.com/cmake/cmake/issues/17097 requests that that be fixed as well (though that is backwards compatible since the solution will likely involve ). > 2. MSVC's #import construct which needs the indirect dependencies > (dependencies of the #import-ed dependency) be registered, which is > handled as part of the target using add_custom_command(TARGET foo > POST_BUILD COMMAND ...) So there's an issue here that there's a dependency between your build rules which CMake doesn't know about (though I don't know #import well enough, the docs don't state where the information *goes*). When adding this custom command, you may use the `BYPRODUCTS` argument (introduced in 3.2.0) to let CMake know what's going on here. It only affects Ninja, but the other generators do target-level dependencies anyways. That output can then be depended on via `OBJECT_DEPENDS` and the dependency should link up properly. If it instead gets registered somewhere in the aether (as far as CMake is concerned), adding support for generator expressions to `OBJECT_DEPENDS` so that `$` may be used there would be the next solution. Making `POST_BUILD` write out a stamp file would also work and then using `OBJECT_DEPENDS` on that would also work. --Ben From steffen.dettmer at gmail.com Thu Aug 3 11:59:04 2017 From: steffen.dettmer at gmail.com (Steffen Dettmer) Date: Thu, 3 Aug 2017 17:59:04 +0200 Subject: [CMake] find_package(Threads) leads to CMake Error: TRY_RUN() invoked in cross-compiling mode Message-ID: Hi, I tried to fix linux (p)thread usage on a proprietary, somewhat complex (300-400 cmake files, ca 30.000 lines) cmake project. We have CMAKE_TOOLCHAIN_FILEs for the cross compiling platforms. These set(CMAKE_SYSTEM_NAME Linux), CMAKE_C_FLAGS(....-D_REENTRANT... CACHE STRING "" FORCE)) and so on. I like to see -pthread on gcc (g++4 and g++5) and if needed -lphtread. I now spent almost two days without success and hope I can get a bit help here. I learned that someone is supposed to use find_package(Threads REQUIRED) instead of specifying CMAKE_C_FLAGS. This works fine for a minimal CMakeLists.txt example (cmake version 3.6.2): cmake_minimum_required(VERSION 3.6) project(phello C CXX) set(CMAKE_THREAD_PREFER_PTHREAD TRUE) set(THREADS_PREFER_PTHREAD_FLAG TRUE) find_package(Threads REQUIRED) add_executable(phello phello.c) target_link_libraries(phello Threads::Threads) but the same fails when cross compiling: -- Looking for pthread.h -- Looking for pthread.h - found -- Looking for pthread_create -- Looking for pthread_create - not found -- Check if compiler accepts -pthread CMake Error: TRY_RUN() invoked in cross-compiling mode, please set the following cache variables appropriately: THREADS_PTHREAD_ARG (advanced) For details see /local/users/sdettmer/work/cmake-toolchain-1.4/threadtest/b2/TryRunResults.cmake -- Check if compiler accepts -pthread - no -- Found Threads: TRUE -- Configuring incomplete, errors occurred! See also "/local/users/sdettmer/work/cmake-toolchain-1.4/threadtest/b2/CMakeFiles/CMakeOutput.log". See also "/local/users/sdettmer/work/cmake-toolchain-1.4/threadtest/b2/CMakeFiles/CMakeError.log". and then no Makefile as expected: $ make make: *** No targets specified and no makefile found. Stop. If then I run cmake again without any change: -- Configuring done -- Generating done -- Build files have been written to: /local/users/sdettmer/work/cmake-toolchain-1.4/threadtest/b2 suddenly no error and then it even works: $ make VERBOSE=1 [...] /opt/xyzcross/x86-linux2/bin/powerpc-linux-gnu-gcc \ --sysroot=/opt/xyzcross/1.2.0.0/sysroots/xyz/sysroot \ -L/opt/xyzcross/1.2.0.0/sysroots/sysroot/lib \ -L/opt/xyzcross/1.2.0.0/sysroots/sysroot/usr/lib \ CMakeFiles/phello.dir/phello.c.o -o phello -pthread a behavior I don't understand. I think this is incorrect. I think, first, cmake should not TRY_RUN when crosscompiling, second, running cmake again should not generate different results. What do I wrong? How can I get it working correctly on first run? In CMakeFiles/CMakeError.log I see that linking fails without -pthread (undefined reference to `pthread_create') and then works when using -pthread, so actually looks like expected when assuming find_package(Threads) tries to check first whether -pthread is needed at all and then if it is working. However, the second run may treated as error: Determining if compiler accepts -pthread returned PLEASE_FILL_OUT-FAILED_TO_RUN instead of 2. The compiler had the following output: Change Dir: /local/users/sdettmer/work/cmake-toolchain-1.4/threadtest/b2/CMakeFiles/CMakeTmp Run Build Command:"/usr/bin/make" "cmTC_47cd8/fast" /usr/bin/make -f CMakeFiles/cmTC_47cd8.dir/build.make CMakeFiles/cmTC_47cd8.dir/build make[1]: Entering directory '/srv/local/sdettmer/work/cmake-toolchain-1.4/threadtest/b2/CMakeFiles/CMakeTmp' Building C object CMakeFiles/cmTC_47cd8.dir/CheckForPthreads.c.o /opt/xyzcross/x86-linux2/bin/powerpc-linux-gnu-gcc --sysroot=... -o CMakeFiles/cmTC_47cd8.dir/CheckForPthreads.c.o -c /usr/local/share/cmake-3.6/Modules/CheckForPthreads.c Linking C executable cmTC_47cd8 /usr/local/bin/cmake -E cmake_link_script CMakeFiles/cmTC_47cd8.dir/link.txt --verbose=1 /opt/xyzcross/x86-linux2/bin/powerpc-linux-gnu-gcc [...] CMakeFiles/cmTC_47cd8.dir/CheckForP threads.c.o -o cmTC_47cd8 -pthread make[1]: Leaving directory '/srv/local/sdettmer/work/cmake-toolchain-1.4/threadtest/b2/CMakeFiles/CMakeTmp' (blank lines + line wraps added by me) If I copy the mentioned gcc command to a shell and change only the file name (CheckForPthreads does not exist anymore, so I use an own pthread_create() main test), it works as expected, no output to console but $ file cmTC_47cd8 cmTC_47cd8: ELF 32-bit MSB executable, PowerPC or cisco 4500, version 1 (SYSV), dynamically linked, interpreter /lib/ld.so.1, for GNU/Linux 2.6.10, not stripped so compiler seems to work fine. What does "-pthread returned PLEASE_FILL_OUT-FAILED_TO_RUN instead of 2." mean? That I'm supposed to run the test binary on target and put the result in a CMakeFiles.txt variable? Any hints appreciated, Steffen TryRunResults.cmake: # This file was generated by CMake because it detected TRY_RUN() commands # in crosscompiling mode. It will be overwritten by the next CMake run. # Copy it to a safe location, set the variables to appropriate values # and use it then to preset the CMake cache (using -C). # THREADS_PTHREAD_ARG # indicates whether the executable would have been able to run on its # target platform. If so, set THREADS_PTHREAD_ARG to # the exit code (in many cases 0 for success), otherwise enter "FAILED_TO_RUN". # The THREADS_HAVE_PTHREAD_ARG variable holds the build result for this TRY_RUN(). # # Source file : /usr/local/share/cmake-3.6/Modules/CheckForPthreads.c # Executable : /local/users/sdettmer/work/cmake-toolchain-1.4/threadtest/b2/CMakeFiles/cmTC_47cd8-THREADS_PTHREAD_ ARG # Run arguments : # Called from: [3] /usr/local/share/cmake-3.6/Modules/FindThreads.cmake # [2] /usr/local/share/cmake-3.6/Modules/FindThreads.cmake # [1] /local/users/sdettmer/work/cmake-toolchain-1.4/threadtest/CMakeLists.txt set( THREADS_PTHREAD_ARG "PLEASE_FILL_OUT-FAILED_TO_RUN" CACHE STRING "Result from TRY_RUN" FORCE) From steffen.dettmer at gmail.com Thu Aug 3 12:07:13 2017 From: steffen.dettmer at gmail.com (Steffen Dettmer) Date: Thu, 3 Aug 2017 18:07:13 +0200 Subject: [CMake] find_package(Threads) leads to CMake Error: TRY_RUN() invoked in cross-compiling mode In-Reply-To: References: Message-ID: a small correction: On Thu, Aug 3, 2017 at 5:59 PM, Steffen Dettmer wrote: > Building C object CMakeFiles/cmTC_47cd8.dir/CheckForPthreads.c.o > /opt/xyzcross/x86-linux2/bin/powerpc-linux-gnu-gcc --sysroot=... > -o CMakeFiles/cmTC_47cd8.dir/CheckForPthreads.c.o -c > /usr/local/share/cmake-3.6/Modules/CheckForPthreads.c > > If I copy the mentioned gcc command to a shell and change only > the file name (CheckForPthreads does not exist anymore Ohh, of course the .c file still exists, just the directory for the .o file had been removed. When I create it, the compile and link commands from the ErrorLog both work fine. Steffen From smithbreannan at gmail.com Fri Aug 4 00:02:27 2017 From: smithbreannan at gmail.com (Breannan Smith) Date: Thu, 3 Aug 2017 21:02:27 -0700 Subject: [CMake] Change LTO Type in CMake 3.9 with Clang? Message-ID: 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! -------------- next part -------------- An HTML attachment was scrubbed... URL: From cmpute at qq.com Fri Aug 4 00:05:03 2017 From: cmpute at qq.com (=?gb18030?B?1tPUqvbO?=) Date: Fri, 4 Aug 2017 12:05:03 +0800 Subject: [CMake] Not able to find boost with cmake Message-ID: I'm trying to build PCL which has boost as dependency. However, when I download boost and build it, cmake cannot find it through any way. I tried two version of boost, one is pre-build boost which was built by other person online and version is 1.61, another is one I downloaded whose version is 1.64. File structures of the two versions are the same: [XXX]/include/boost-1_64/boost is the include dir and [XXX]/lib is the bin dir I try to specify the Boost_INCLUDE_DIR to [XXX]/include/boost-1_64/boost, the messages in output window is attached (I turned Boost_DEBUG on). I'm on Window 10 and VS2017 Thanks, Jacob Zhong ------------------ ???? ??? Yuanxin Zhong ????????? Dept. of Automotive Engineering, Tsinghua Univ. Ad:Haidian District, Beijing, P.R.China 100084 Tel:+86 17888833119 E-mail?cmpute at foxmail.com / zhongyx14 at mails.tsinghua.edu.cn -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: EC7BE632 at 9C9BB14D.6FF28359.jpg Type: image/jpeg Size: 13551 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 475B1FF2 at DAF68473.6FF28359.jpg Type: image/jpeg Size: 11484 bytes Desc: not available URL: From bo.schwarzstein at gmail.com Fri Aug 4 00:19:53 2017 From: bo.schwarzstein at gmail.com (Bo Zhou) Date: Fri, 4 Aug 2017 13:19:53 +0900 Subject: [CMake] Not able to find boost with cmake In-Reply-To: References: Message-ID: It's better not to use downloaded pre-built libraries, always build by yourself locally. Before using Boost with CMake, please check https://cmake.org/cmake/help/v3.0/module/FindBoost.html If you're trying to use static boost libraries build by MSVC with shared runtime, please make sure the following statements exist in the PCL. set(Boost_USE_STATIC_LIBS ON) set(Boost_USE_MULTITHREADED ON) set(Boost_USE_STATIC_RUNTIME OFF) Then if you properly set the Boost_INCLUDE_DIR, all the libraries should be ready then. On Fri, Aug 4, 2017 at 1:05 PM, ??? wrote: > I'm trying to build PCL which has boost as dependency. However, when I > download boost and build it, cmake cannot find it through any way. > > I tried two version of boost, one is pre-build boost which was built by > other person online and version is 1.61, another is one I downloaded whose > version is 1.64. File structures of the two versions are the same: > [XXX]/include/boost-1_64/boost is the include dir and [XXX]/lib is the bin > dir > > I try to specify the Boost_INCLUDE_DIR to [XXX]/include/boost-1_64/boost, > the messages in output window is attached (I turned Boost_DEBUG on). > > I'm on Window 10 and VS2017 > > Thanks, > Jacob Zhong > > ------------------ > ???? > > ??? Yuanxin Zhong > ????????? Dept. of Automotive Engineering, Tsinghua Univ. > Ad:Haidian District, Beijing, P.R.China 100084 > Tel:+86 17888833119 <+86%20178%208883%203119> > E-mail?cmpute at foxmail.com / zhongyx > 14 at mails.tsinghua.edu.cn > > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/ > opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: EC7BE632 at 9C9BB14D.6FF28359.jpg Type: image/jpeg Size: 13551 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 475B1FF2 at DAF68473.6FF28359.jpg Type: image/jpeg Size: 11484 bytes Desc: not available URL: From lectem at gmail.com Fri Aug 4 02:56:38 2017 From: lectem at gmail.com (=?UTF-8?Q?Cl=C3=A9ment_Gregoire?=) Date: Fri, 04 Aug 2017 06:56:38 +0000 Subject: [CMake] Change LTO Type in CMake 3.9 with Clang? In-Reply-To: References: Message-ID: Not yet, but it is a known issue : https://gitlab.kitware.com/cmake/cmake/issues/16808 Le ven. 4 ao?t 2017 ? 06:03, Breannan Smith a ?crit : > Testing the new LTO support in CMake 3.9, it appears that > setting INTERPROCEDURAL_OPTIMIZATION to TRUE causes CMake to pass > '-flto=thin' to Clang. Is it possible to instead have CMake pass > '-flto=full' (or just '-flto') to Clang? > > Thanks! > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake -------------- next part -------------- An HTML attachment was scrubbed... URL: From Johannes.Sebastian.Mueller-Roemer at igd.fraunhofer.de Fri Aug 4 02:50:14 2017 From: Johannes.Sebastian.Mueller-Roemer at igd.fraunhofer.de (Mueller-Roemer, Johannes Sebastian) Date: Fri, 4 Aug 2017 06:50:14 +0000 Subject: [CMake] What is the default build type? In-Reply-To: References: <9ee5b0f6-4272-8043-88ca-a020aab880a8@xgm.de> Message-ID: <8D981219EEA621479C112DA9BDC39A8E7096DA9B@EXMBS1.ad.igd.fraunhofer.de> Exactly. Also, CMAKE_CONFIGURATION_TYPES uses the CamelCase Versions by default, so if your CMake code breaks with that spelling, your CMakeLists.txt can be considered broken anyways... Fraunhofer-Institut f?r Graphische Datenverarbeitung IGD Fraunhoferstr. 5? |? 64283 Darmstadt? |? Germany Tel +49 6151 155-606? |? Fax +49 6151 155-139 johannes.mueller-roemer at igd.fraunhofer.de | www.igd.fraunhofer.de -----Original Message----- From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Marcus D. Hanwell Sent: Thursday, August 3, 2017 16:25 To: J Decker Cc: cmake at cmake.org Subject: Re: [CMake] What is the default build type? On Wed, Aug 2, 2017 at 4:18 PM, J Decker wrote: > > On Wed, Aug 2, 2017 at 8:55 AM, Marcus D. Hanwell wrote: >> >> On Wed, Aug 2, 2017 at 3:03 AM, Bo Zhou wrote: >>> >>> It depends on the Generator. >>> >>> To the Makefile, the actual type was controlled by the compiler options. If you don't specific any type, usually it means non-debug and non-optimization because the CMAKE_CXX_FLAGS is empty as default. This is critical, so usually people should specific the actual type they want to build. >>> >>> To the generator of the IDE, such as Visual Studio and Xcode, the CMAKE_BUILD_TYPE doesn't make sense but we have to use CMAKE_CONFIGURATION_TYPES, then CMake will create the several configuration sets for the IDE from the CMAKE_C|CXX_FLAGS_{CONFIG} . >> >> >> This thread inspired me to write up how we have been doing it in some >> of the projects I work on for quite a while now, >> >> https://blog.kitware.com/cmake-and-the-default-build-type/ >> > These should use lower case 'debug' 'release' etc. Because if it's not VS, it's probably also not windows, and case matters. > No, camel case works just fine. I took a quick look and lowercase will work, as well as all caps. I have used this for many years on Linux builds with Makefile/Ninja without issue. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake From ben.boeckel at kitware.com Fri Aug 4 13:55:23 2017 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Fri, 4 Aug 2017 13:55:23 -0400 Subject: [CMake] CMake 3.9 change to dependencies of object compilation In-Reply-To: <74B7C9CD2B43054BA63CDE61908202D96648C99C@EDXMB90.jdnet.deere.com> References: <74B7C9CD2B43054BA63CDE61908202D96648B196@EDXMB90.jdnet.deere.com> <20170803155858.GA4124@megas.kitware.com> <74B7C9CD2B43054BA63CDE61908202D96648C99C@EDXMB90.jdnet.deere.com> Message-ID: <20170804175523.GA32083@megas.kitware.com> On Fri, Aug 04, 2017 at 17:35:53 +0000, Puetz Kevin A wrote: > Thanks for the reply, questions/clarifications below. > > requests that that be fixed as well (though that is backwards compatible > > since the solution will likely involve ). > > Sentence cut off? I assume you meant "will likely involve a new keyword"? Yep, sorry. > > > 2. MSVC's #import construct which needs the indirect dependencies > > > (dependencies of the #import-ed dependency) be registered, which is > > > handled as part of the target using add_custom_command(TARGET foo > > > POST_BUILD COMMAND ...) > > > > So there's an issue here that there's a dependency between your build rules > > which CMake doesn't know about (though I don't know #import well > > enough, the docs don't state where the information *goes*). > > #import will load a COM typelib during preprocessing, possibly > following registry keys to locate other typelibs which the specified > one refers to. It will have the byproduct of creating .tlh/.tli files > next to the other compiler outputs (e.g. .o file) Arguably the > .tlh/.tli files should be listed in OBJECT_OUTPUTS, but I can't > because I don't know their location; CMake doesn't have a > variable/property/generator expression that reveals where it's going > to place the object files (i.e. /Fo$out), so I don't know where they > will end up. Luckily the .tlh/.tli files aren't important to list for > dependency resolution anyway, because the #import also automatically > #includes the just-generated headers, (though this is not mentioned in > /showIncludes). So CMake is at least *consistently* unaware of these > files, and they get regenerated any time they would have been read so > it doesn't really need to know. OK, a genex for where object outputs may be useful anyways. I think there's something along those lines with Cuda's PTX file generation? > The important missing dependency is the one between > creating/regstering the typelib (we'll call this target COMServer) and > the #import that will read it in a source file in another target > (we'll call it COMClient). I have a call add_custom_command(TARGET > COMServer POST_BUILD COMMAND regsvr32 $), > which will create the registry keys under HKEY_CLASSES_ROOT. This > needs to happen before the source file in COMClient can preprocess the > #import successfully. Prior to CMake 3.9, I could inform CMake of this > by just using add_dependencies(COMClient COMServer) to tell CMake that > it couldn't build (any of) Client until Server had been built (and > thus its POST_BUILD had also run to register it). But in 3.9, > add_dependencies has changed in meaning; although the documentation > still says "to ensure that they build before does", in > practice this now only means "to ensure that they build before > *links*"; these edges do not apply to object compilation or > add_custom_command rules. > > add_custom_command is no problem; it already had a DEPENDS argument > that allows target-level dependencies, and arguably such dependencies > needed to be stated there anyway since an add_custom_command output > can get reused by multiple targets in the same subdir. But object > compilation is a problem because there's nowhere to add them > per-source, and add_dependencies doesn't work anymore to add them > per-target. It sounds like the logic may need fixing then. Do you have an example case where add_dependencies doesn't work anymore in Ninja? > > When adding > > this custom command, you may use the `BYPRODUCTS` argument > > (introduced in 3.2.0) to let CMake know what's going on here. It only affects > > Ninja, but the other generators do target-level dependencies anyways. That > > output can then be depended on via `OBJECT_DEPENDS` and the > > dependency should link up properly. > > There is not an explicit file output, though I could do the usual > workaround of a stamp/witness file listed in BYPRODUCTS to the > add_custom_command(TARGET ... POST_BUILD ...). But I don't think that > will work with most generators, since CMake doesn't generally allow > file-level depends to set the order in which targets are built. I > suppose it might work out in practice for ninja since that writes a > monolithic set of rules, but conditional code where I have to peek at > CMAKE_GENERATOR and use BYPRODUCTS/OBJECT_DEPENDS for ninja and > add_dependencies for other generators seems like the sort of thing > this list would tell me not to do :-) Well, other generators are generally target-ordered anyways. Ninja is the oddball here (which is why it's the only one to get the feature). I don't know the effect it'd have in other generators, but I feel like I'd be surprised if it *broke* them since excess dependencies (usually) only result in either slower builds or circular dependency loops and Ninja complains loudly about the latter. And since BYPRODUCTS only affects Ninja, if BYPRODUCTS is used, other generators shouldn't care anyways. > And even for ninja I think I'd have to be making undocumented > assumptions about the binary dir layout to refer to my witness file > that was generated in a different subdir's CMakelists.txt. There's nothing stopping the witness files couldn't all be under a single directory (such as ${CMAKE_BINARY_DIR}/CMakeFiles/tlb). > > If it instead gets registered somewhere in the aether (as far as CMake is > > concerned), adding support for generator expressions to `OBJECT_DEPENDS` > > so that `$` may be used there would be the next solution. > > Yes, the dependency in question for #import is on information > "somewhere in the aether" (or rather the Win32 registry). > > Supporting $ does in OBJECT_DEPENDS would be a great > solution for my first use case of a embedding that file in a resource. > But I don't think that helps with #import, since I don't actually want > to read the $, I just want the post-build that registers > it to have run. POST_BUILD rules are attached to the target, so depending on the target also guarantees that the POST_BUILD command(s) have run as well. > Also, in the cases of .tlb files that are *not* embedded in DLL > resources, the target in question is going to be an add_custom_target > from another subdirectory; the .tlb file is built by an > add_custom_command(OUTPUT...) but this rule gets emitted in an > add_custom_target that depends on this file to build it and then > registers it. If each subdir had the add_custom_command instead of > using an intermediate target, multiple targets would each end up with > their own copy of the rule to build the .tlb file, leading to race > conditions where they all try to build it at once and get file-in-use > errors (they can't just build individual copies, because it has to end > up with a unique key referencing the .tlb path in the win32 regist> > ry). Yeah, there should be just one .tlb rule writer. Usually I handle that by collecting information in global properties and writing a rule at the end to handle all of them. > You're not currently allowed to use $ on UTILITY > targets even if the LOCATION property has been set (it's blocked in > TargetFilesystemArtifact::Evaluate with "Target is not an > executable or library"). Maybe that could be changed as well (which > would be nice), but it seems like if one is adding support for > $ generator expressions in OBJECT_DEPENDS (which implies > supporting the generator context and context->DependTargets), it seems > like you as well go the rest of the way and just treat them completely > the same as the DEPENDS argument to add_custom_command, allowing both > file and target dependencies to be listed in the first place. That sounds like a likely path to follow when supporting genexes in OBJECT_DEPENDS. > > Making `POST_BUILD` write out a stamp file would also work and then using > > `OBJECT_DEPENDS` on that would also work. > > No, as above I don't think that would be legal across subdirs, at > least in the context of a CMake file that's supposed to work with > various generators. Feel free to correct me if I'm wrong about that... Experiments would be more useful. add_custom_* have some of the most complicated interaction semantics in CMake. I can't keep all of them straight all the time (usually I rediscover them when necessary; I should probably write up some docs next time I need to do so). --Ben From robert.maynard at kitware.com Fri Aug 4 14:02:31 2017 From: robert.maynard at kitware.com (Robert Maynard) Date: Fri, 4 Aug 2017 14:02:31 -0400 Subject: [CMake] CMake 3.9 change to dependencies of object compilation In-Reply-To: <20170804175523.GA32083@megas.kitware.com> References: <74B7C9CD2B43054BA63CDE61908202D96648B196@EDXMB90.jdnet.deere.com> <20170803155858.GA4124@megas.kitware.com> <74B7C9CD2B43054BA63CDE61908202D96648C99C@EDXMB90.jdnet.deere.com> <20170804175523.GA32083@megas.kitware.com> Message-ID: You can find the location for object files by using $. This can be used as the DEPENDS of a custom command. I would not try using OBJECT_OUTPUTS as IIRC that is only used by the makefile generator. On Fri, Aug 4, 2017 at 1:55 PM, Ben Boeckel wrote: > On Fri, Aug 04, 2017 at 17:35:53 +0000, Puetz Kevin A wrote: >> Thanks for the reply, questions/clarifications below. >> > requests that that be fixed as well (though that is backwards compatible >> > since the solution will likely involve ). >> >> Sentence cut off? I assume you meant "will likely involve a new keyword"? > > Yep, sorry. > >> > > 2. MSVC's #import construct which needs the indirect dependencies >> > > (dependencies of the #import-ed dependency) be registered, which is >> > > handled as part of the target using add_custom_command(TARGET foo >> > > POST_BUILD COMMAND ...) >> > >> > So there's an issue here that there's a dependency between your build rules >> > which CMake doesn't know about (though I don't know #import well >> > enough, the docs don't state where the information *goes*). >> >> #import will load a COM typelib during preprocessing, possibly >> following registry keys to locate other typelibs which the specified >> one refers to. It will have the byproduct of creating .tlh/.tli files >> next to the other compiler outputs (e.g. .o file) Arguably the >> .tlh/.tli files should be listed in OBJECT_OUTPUTS, but I can't >> because I don't know their location; CMake doesn't have a >> variable/property/generator expression that reveals where it's going >> to place the object files (i.e. /Fo$out), so I don't know where they >> will end up. Luckily the .tlh/.tli files aren't important to list for >> dependency resolution anyway, because the #import also automatically >> #includes the just-generated headers, (though this is not mentioned in >> /showIncludes). So CMake is at least *consistently* unaware of these >> files, and they get regenerated any time they would have been read so >> it doesn't really need to know. > > OK, a genex for where object outputs may be useful anyways. I think > there's something along those lines with Cuda's PTX file generation? > >> The important missing dependency is the one between >> creating/regstering the typelib (we'll call this target COMServer) and >> the #import that will read it in a source file in another target >> (we'll call it COMClient). I have a call add_custom_command(TARGET >> COMServer POST_BUILD COMMAND regsvr32 $), >> which will create the registry keys under HKEY_CLASSES_ROOT. This >> needs to happen before the source file in COMClient can preprocess the >> #import successfully. Prior to CMake 3.9, I could inform CMake of this >> by just using add_dependencies(COMClient COMServer) to tell CMake that >> it couldn't build (any of) Client until Server had been built (and >> thus its POST_BUILD had also run to register it). But in 3.9, >> add_dependencies has changed in meaning; although the documentation >> still says "to ensure that they build before does", in >> practice this now only means "to ensure that they build before >> *links*"; these edges do not apply to object compilation or >> add_custom_command rules. >> >> add_custom_command is no problem; it already had a DEPENDS argument >> that allows target-level dependencies, and arguably such dependencies >> needed to be stated there anyway since an add_custom_command output >> can get reused by multiple targets in the same subdir. But object >> compilation is a problem because there's nowhere to add them >> per-source, and add_dependencies doesn't work anymore to add them >> per-target. > > It sounds like the logic may need fixing then. Do you have an example > case where add_dependencies doesn't work anymore in Ninja? > >> > When adding >> > this custom command, you may use the `BYPRODUCTS` argument >> > (introduced in 3.2.0) to let CMake know what's going on here. It only affects >> > Ninja, but the other generators do target-level dependencies anyways. That >> > output can then be depended on via `OBJECT_DEPENDS` and the >> > dependency should link up properly. >> >> There is not an explicit file output, though I could do the usual >> workaround of a stamp/witness file listed in BYPRODUCTS to the >> add_custom_command(TARGET ... POST_BUILD ...). But I don't think that >> will work with most generators, since CMake doesn't generally allow >> file-level depends to set the order in which targets are built. I >> suppose it might work out in practice for ninja since that writes a >> monolithic set of rules, but conditional code where I have to peek at >> CMAKE_GENERATOR and use BYPRODUCTS/OBJECT_DEPENDS for ninja and >> add_dependencies for other generators seems like the sort of thing >> this list would tell me not to do :-) > > Well, other generators are generally target-ordered anyways. Ninja is > the oddball here (which is why it's the only one to get the feature). I > don't know the effect it'd have in other generators, but I feel like I'd > be surprised if it *broke* them since excess dependencies (usually) only > result in either slower builds or circular dependency loops and Ninja > complains loudly about the latter. And since BYPRODUCTS only affects > Ninja, if BYPRODUCTS is used, other generators shouldn't care anyways. > >> And even for ninja I think I'd have to be making undocumented >> assumptions about the binary dir layout to refer to my witness file >> that was generated in a different subdir's CMakelists.txt. > > There's nothing stopping the witness files couldn't all be under a > single directory (such as ${CMAKE_BINARY_DIR}/CMakeFiles/tlb). > >> > If it instead gets registered somewhere in the aether (as far as CMake is >> > concerned), adding support for generator expressions to `OBJECT_DEPENDS` >> > so that `$` may be used there would be the next solution. >> >> Yes, the dependency in question for #import is on information >> "somewhere in the aether" (or rather the Win32 registry). >> >> Supporting $ does in OBJECT_DEPENDS would be a great >> solution for my first use case of a embedding that file in a resource. >> But I don't think that helps with #import, since I don't actually want >> to read the $, I just want the post-build that registers >> it to have run. > > POST_BUILD rules are attached to the target, so depending on the target > also guarantees that the POST_BUILD command(s) have run as well. > >> Also, in the cases of .tlb files that are *not* embedded in DLL >> resources, the target in question is going to be an add_custom_target >> from another subdirectory; the .tlb file is built by an >> add_custom_command(OUTPUT...) but this rule gets emitted in an >> add_custom_target that depends on this file to build it and then >> registers it. If each subdir had the add_custom_command instead of >> using an intermediate target, multiple targets would each end up with >> their own copy of the rule to build the .tlb file, leading to race >> conditions where they all try to build it at once and get file-in-use >> errors (they can't just build individual copies, because it has to end >> up with a unique key referencing the .tlb path in the win32 regist> >> ry). > > Yeah, there should be just one .tlb rule writer. Usually I handle that > by collecting information in global properties and writing a rule at the > end to handle all of them. > >> You're not currently allowed to use $ on UTILITY >> targets even if the LOCATION property has been set (it's blocked in >> TargetFilesystemArtifact::Evaluate with "Target is not an >> executable or library"). Maybe that could be changed as well (which >> would be nice), but it seems like if one is adding support for >> $ generator expressions in OBJECT_DEPENDS (which implies >> supporting the generator context and context->DependTargets), it seems >> like you as well go the rest of the way and just treat them completely >> the same as the DEPENDS argument to add_custom_command, allowing both >> file and target dependencies to be listed in the first place. > > That sounds like a likely path to follow when supporting genexes in > OBJECT_DEPENDS. > >> > Making `POST_BUILD` write out a stamp file would also work and then using >> > `OBJECT_DEPENDS` on that would also work. >> >> No, as above I don't think that would be legal across subdirs, at >> least in the context of a CMake file that's supposed to work with >> various generators. Feel free to correct me if I'm wrong about that... > > Experiments would be more useful. add_custom_* have some of the most > complicated interaction semantics in CMake. I can't keep all of them > straight all the time (usually I rediscover them when necessary; I > should probably write up some docs next time I need to do so). > > --Ben From PuetzKevinA at JohnDeere.com Fri Aug 4 13:35:53 2017 From: PuetzKevinA at JohnDeere.com (Puetz Kevin A) Date: Fri, 4 Aug 2017 17:35:53 +0000 Subject: [CMake] CMake 3.9 change to dependencies of object compilation In-Reply-To: <20170803155858.GA4124@megas.kitware.com> References: <74B7C9CD2B43054BA63CDE61908202D96648B196@EDXMB90.jdnet.deere.com> <20170803155858.GA4124@megas.kitware.com> Message-ID: <74B7C9CD2B43054BA63CDE61908202D96648C99C@EDXMB90.jdnet.deere.com> Thanks for the reply, questions/clarifications below. > -----Original Message----- > From: Ben Boeckel [mailto:ben.boeckel at kitware.com] > Sent: Thursday, August 03, 2017 10:59 AM > To: cmake at cmake.org > Cc: Robert Maynard ; Puetz Kevin A > > Subject: Re: CMake 3.9 change to dependencies of object compilation > > > . The Ninja generator has loosened the dependencies of object > > compilation. Object compilation now depends only on custom targets and > > custom commands associated with libraries on which the object's target > > depends and no longer depends on the libraries themselves. Source > > files in dependent targets may now compile without waiting for their > > targets' dependencies to link. > > Correct. > > > We have a few cases where the object compilation really does depend on > > the TARGET_FILE itself, e.g. > > 1. An RC compiler embedding the resulting file of a custom target (I > > think this one may still work, since custom targets appear to have > > been exempted from the change) > > Correct, though this issue: > > https://gitlab.kitware.com/cmake/cmake/issues/17097 > > requests that that be fixed as well (though that is backwards compatible > since the solution will likely involve ). Sentence cut off? I assume you meant "will likely involve a new keyword"? > > 2. MSVC's #import construct which needs the indirect dependencies > > (dependencies of the #import-ed dependency) be registered, which is > > handled as part of the target using add_custom_command(TARGET foo > > POST_BUILD COMMAND ...) > > So there's an issue here that there's a dependency between your build rules > which CMake doesn't know about (though I don't know #import well > enough, the docs don't state where the information *goes*). #import will load a COM typelib during preprocessing, possibly following registry keys to locate other typelibs which the specified one refers to. It will have the byproduct of creating .tlh/.tli files next to the other compiler outputs (e.g. .o file) Arguably the .tlh/.tli files should be listed in OBJECT_OUTPUTS, but I can't because I don't know their location; CMake doesn't have a variable/property/generator expression that reveals where it's going to place the object files (i.e. /Fo$out), so I don't know where they will end up. Luckily the .tlh/.tli files aren't important to list for dependency resolution anyway, because the #import also automatically #includes the just-generated headers, (though this is not mentioned in /showIncludes). So CMake is at least *consistently* unaware of these files, and they get regenerated any time they would have been read so it doesn't really need to know. The important missing dependency is the one between creating/regstering the typelib (we'll call this target COMServer) and the #import that will read it in a source file in another target (we'll call it COMClient). I have a call add_custom_command(TARGET COMServer POST_BUILD COMMAND regsvr32 $), which will create the registry keys under HKEY_CLASSES_ROOT. This needs to happen before the source file in COMClient can preprocess the #import successfully. Prior to CMake 3.9, I could inform CMake of this by just using add_dependencies(COMClient COMServer) to tell CMake that it couldn't build (any of) Client until Server had been built (and thus its POST_BUILD had also run to register it). But in 3.9, add_dependencies has changed in meaning; although the documentation still says "to ensure that they build before does", in practice this now only means "to ensure that they build before *links*"; these edges do not apply to object compilation or add_custom_command rules. add_custom_command is no problem; it already had a DEPENDS argument that allows target-level dependencies, and arguably such dependencies needed to be stated there anyway since an add_custom_command output can get reused by multiple targets in the same subdir. But object compilation is a problem because there's nowhere to add them per-source, and add_dependencies doesn't work anymore to add them per-target. > When adding > this custom command, you may use the `BYPRODUCTS` argument > (introduced in 3.2.0) to let CMake know what's going on here. It only affects > Ninja, but the other generators do target-level dependencies anyways. That > output can then be depended on via `OBJECT_DEPENDS` and the > dependency should link up properly. There is not an explicit file output, though I could do the usual workaround of a stamp/witness file listed in BYPRODUCTS to the add_custom_command(TARGET ... POST_BUILD ...). But I don't think that will work with most generators, since CMake doesn't generally allow file-level depends to set the order in which targets are built. I suppose it might work out in practice for ninja since that writes a monolithic set of rules, but conditional code where I have to peek at CMAKE_GENERATOR and use BYPRODUCTS/OBJECT_DEPENDS for ninja and add_dependencies for other generators seems like the sort of thing this list would tell me not to do :-) And even for ninja I think I'd have to be making undocumented assumptions about the binary dir layout to refer to my witness file that was generated in a different subdir's CMakelists.txt. > If it instead gets registered somewhere in the aether (as far as CMake is > concerned), adding support for generator expressions to `OBJECT_DEPENDS` > so that `$` may be used there would be the next solution. Yes, the dependency in question for #import is on information "somewhere in the aether" (or rather the Win32 registry). Supporting $ does in OBJECT_DEPENDS would be a great solution for my first use case of a embedding that file in a resource. But I don't think that helps with #import, since I don't actually want to read the $, I just want the post-build that registers it to have run. Also, in the cases of .tlb files that are *not* embedded in DLL resources, the target in question is going to be an add_custom_target from another subdirectory; the .tlb file is built by an add_custom_command(OUTPUT...) but this rule gets emitted in an add_custom_target that depends on this file to build it and then registers it. If each subdir had the add_custom_command instead of using an intermediate target, multiple targets would each end up with their own copy of the rule to build the .tlb file, leading to race conditions where they all try to build it at once and get file-in-use errors (they can't just build individual copies, because it has to end up with a unique key referencing the .tlb path in the win32 registry). You're not currently allowed to use $ on UTILITY targets even if the LOCATION property has been set (it's blocked in TargetFilesystemArtifact::Evaluate with "Target is not an executable or library"). Maybe that could be changed as well (which would be nice), but it seems like if one is adding support for $ generator expressions in OBJECT_DEPENDS (which implies supporting the generator context and context->DependTargets), it seems like you as well go the rest of the way and just treat them completely the same as the DEPENDS argument to add_custom_command, allowing both file and target dependencies to be listed in the first place. > Making `POST_BUILD` write out a stamp file would also work and then using > `OBJECT_DEPENDS` on that would also work. No, as above I don't think that would be legal across subdirs, at least in the context of a CMake file that's supposed to work with various generators. Feel free to correct me if I'm wrong about that... > --Ben From PuetzKevinA at JohnDeere.com Fri Aug 4 14:59:46 2017 From: PuetzKevinA at JohnDeere.com (Puetz Kevin A) Date: Fri, 4 Aug 2017 18:59:46 +0000 Subject: [CMake] CMake 3.9 change to dependencies of object compilation In-Reply-To: References: <74B7C9CD2B43054BA63CDE61908202D96648B196@EDXMB90.jdnet.deere.com> <20170803155858.GA4124@megas.kitware.com> <74B7C9CD2B43054BA63CDE61908202D96648C99C@EDXMB90.jdnet.deere.com> <20170804175523.GA32083@megas.kitware.com> Message-ID: <74B7C9CD2B43054BA63CDE61908202D96648CA0D@EDXMB90.jdnet.deere.com> > -----Original Message----- > From: Robert Maynard [mailto:robert.maynard at kitware.com] > Sent: Friday, August 04, 2017 1:03 PM > To: Ben Boeckel > Cc: Puetz Kevin A ; cmake at cmake.org > Subject: Re: CMake 3.9 change to dependencies of object compilation > > You can find the location for object files by using > $. This can be used as the DEPENDS of a custom > command. I would not try using OBJECT_OUTPUTS as IIRC that is only used by > the makefile generator. Isn't TARGET_OBJECTS only for OBJECT libraries? I don't think it would give me a way to get the paths for the .o file that's going to result from a particular source file (in order to locate other files the compiler is going to generate alongside a .o file). But and in any case, this was a little bit of an aside, just because Ben asked what #import generated. It would feel *correct* to inform that the .tlh/.tli files were OBJECT_OUTPUTS, but nothing in the processing really *needs* to know. The problem I'm having with 3.9 is the input dependency on registry keys (previously modeled as a dependency on the target whose POST_BUILD would create them), not on the outputs. From PuetzKevinA at JohnDeere.com Fri Aug 4 15:46:37 2017 From: PuetzKevinA at JohnDeere.com (Puetz Kevin A) Date: Fri, 4 Aug 2017 19:46:37 +0000 Subject: [CMake] CMake 3.9 change to dependencies of object compilation In-Reply-To: <20170804175523.GA32083@megas.kitware.com> References: <74B7C9CD2B43054BA63CDE61908202D96648B196@EDXMB90.jdnet.deere.com> <20170803155858.GA4124@megas.kitware.com> <74B7C9CD2B43054BA63CDE61908202D96648C99C@EDXMB90.jdnet.deere.com> <20170804175523.GA32083@megas.kitware.com> Message-ID: <74B7C9CD2B43054BA63CDE61908202D96648CA31@EDXMB90.jdnet.deere.com> > -----Original Message----- > From: Ben Boeckel [mailto:ben.boeckel at kitware.com] > Sent: Friday, August 04, 2017 12:55 PM > To: Puetz Kevin A > Cc: cmake at cmake.org; Robert Maynard > Subject: Re: CMake 3.9 change to dependencies of object compilation > > On Fri, Aug 04, 2017 at 17:35:53 +0000, Puetz Kevin A wrote: > > > > 2. MSVC's #import construct which needs the indirect dependencies > > > > (dependencies of the #import-ed dependency) be registered, which > > > > is handled as part of the target using add_custom_command(TARGET > > > > foo POST_BUILD COMMAND ...) > > > > > > So there's an issue here that there's a dependency between your > > > build rules which CMake doesn't know about (though I don't know > > > #import well enough, the docs don't state where the information > *goes*). > > > > #import will load a COM typelib during preprocessing, possibly > > following registry keys to locate other typelibs which the specified > > one refers to. It will have the byproduct of creating .tlh/.tli files > > next to the other compiler outputs (e.g. .o file) Arguably the > > .tlh/.tli files should be listed in OBJECT_OUTPUTS, but I can't > > because I don't know their location; CMake doesn't have a > > variable/property/generator expression that reveals where it's going > > to place the object files (i.e. /Fo$out), so I don't know where they > > will end up. Luckily the .tlh/.tli files aren't important to list for > > dependency resolution anyway, because the #import also automatically > > #includes the just-generated headers, (though this is not mentioned in > > /showIncludes). So CMake is at least *consistently* unaware of these > > files, and they get regenerated any time they would have been read so > > it doesn't really need to know. > > OK, a genex for where object outputs may be useful anyways. I think there's > something along those lines with Cuda's PTX file generation? It would also be really nice for things like precompiled headers; I have some custom commands where it really feels right to put their outputs with the other object files for a target (this automatically getting things right for multi-configuration generators and such), but can't because there's no expression for that. Something like $ would be very welcome. > > The important missing dependency is the one between > > creating/regstering the typelib (we'll call this target COMServer) and > > the #import that will read it in a source file in another target > > (we'll call it COMClient). I have a call add_custom_command(TARGET > > COMServer POST_BUILD COMMAND regsvr32 $ COMServer>), > > which will create the registry keys under HKEY_CLASSES_ROOT. This > > needs to happen before the source file in COMClient can preprocess the > > #import successfully. Prior to CMake 3.9, I could inform CMake of this > > by just using add_dependencies(COMClient COMServer) to tell CMake that > > it couldn't build (any of) Client until Server had been built (and > > thus its POST_BUILD had also run to register it). But in 3.9, > > add_dependencies has changed in meaning; although the documentation > > still says "to ensure that they build before does", in > > practice this now only means "to ensure that they build before > > *links*"; these edges do not apply to object compilation or > > add_custom_command rules. > > > > add_custom_command is no problem; it already had a DEPENDS argument > > that allows target-level dependencies, and arguably such dependencies > > needed to be stated there anyway since an add_custom_command output > > can get reused by multiple targets in the same subdir. But object > > compilation is a problem because there's nowhere to add them > > per-source, and add_dependencies doesn't work anymore to add them > > per-target. > > It sounds like the logic may need fixing then. Do you have an example case > where add_dependencies doesn't work anymore in Ninja? CMakeLists.txt: cmake_minimum_required(VERSION 3.7) add_library(A SHARED a.c) add_custom_command(TARGET A POST_BUILD COMMENT "hello A" COMMAND ${CMAKE_COMMAND} -E sleep 3 COMMAND ${CMAKE_COMMAND} -E echo "hello A") add_custom_command(OUTPUT b.custom COMMENT "hello B" COMMAND ${CMAKE_COMMAND} -E touch b.custom) add_executable(B b.c b.custom) add_dependencies(B A) a.c: void foo() {} b.c: int main() { return 0; } In CMake 3.7: build cmake_order_depends_target_B: phony || A.dll b.custom build b.custom: CUSTOM_COMMAND || A.dll build CMakeFiles\B.dir\b.c.obj: C_COMPILER__B C$:\Users\re41236\Desktop\test\cmake\b.c || cmake_order_depends_target_B build B.exe: C_EXECUTABLE_LINKER__B CMakeFiles\B.dir\b.c.obj || A.dll In CMake 3.9: build cmake_object_order_depends_target_B: phony || b.custom cmake_object_order_depends_target_A build CMakeFiles\B.dir\b.c.obj: C_COMPILER__B C$:\Users\re41236\Desktop\test\cmake\b.c || cmake_object_order_depends_target_B build b.custom: CUSTOM_COMMAND || A.dll build B.exe: C_EXECUTABLE_LINKER__B CMakeFiles\B.dir\b.c.obj || A.dll So in 3.7, the add_dependencies(B A) put A.dll as an order-only dependency of all the rules that were part of B; nothing in B builds until everything in A does. In 3.9 only the custom commands and link rules get it, the object rules don't. And there doesn't seem to be a way to explicitly get an order-only target dependency into the object rules in the (rare) cases where it actually was needed, like #import. So not only is it a breaking change, it?s not readily fixed. Admittedly right now this is pretty much limited to weird compiler (mis-)features like MSVC's #import that reference input besides the source/headers. Although it might become more common if the C++ modules TS ever catches on (you'll need the .ifc file generated by compiling the dependency before compiling objects that use it) > > > When adding > > > this custom command, you may use the `BYPRODUCTS` argument > > > (introduced in 3.2.0) to let CMake know what's going on here. It > > > only affects Ninja, but the other generators do target-level > > > dependencies anyways. That output can then be depended on via > > > `OBJECT_DEPENDS` and the dependency should link up properly. > > > > There is not an explicit file output, though I could do the usual > > workaround of a stamp/witness file listed in BYPRODUCTS to the > > add_custom_command(TARGET ... POST_BUILD ...). But I don't think that > > will work with most generators, since CMake doesn't generally allow > > file-level depends to set the order in which targets are built. I > > suppose it might work out in practice for ninja since that writes a > > monolithic set of rules, but conditional code where I have to peek at > > CMAKE_GENERATOR and use BYPRODUCTS/OBJECT_DEPENDS for ninja > and > > add_dependencies for other generators seems like the sort of thing > > this list would tell me not to do :-) > > Well, other generators are generally target-ordered anyways. Ninja is the > oddball here (which is why it's the only one to get the feature). I don't know > the effect it'd have in other generators, but I feel like I'd be surprised if it > *broke* them since excess dependencies (usually) only result in either > slower builds or circular dependency loops and Ninja complains loudly about > the latter. And since BYPRODUCTS only affects Ninja, if BYPRODUCTS is used, > other generators shouldn't care anyways. True, I suppose I don?t need to peek at CMAKE_GENERATOR, I could just do it both ways all the time. As long as nobody comes up with a generator that can separate compile vs link dependencies, but still can't handle cross-subdir file dependencies. > > And even for ninja I think I'd have to be making undocumented > > assumptions about the binary dir layout to refer to my witness file > > that was generated in a different subdir's CMakelists.txt. > > There's nothing stopping the witness files couldn't all be under a single > directory (such as ${CMAKE_BINARY_DIR}/CMakeFiles/tlb). Ok, good point. They don't have to be alongside the target's other artifacts. > > > If it instead gets registered somewhere in the aether (as far as > > > CMake is concerned), adding support for generator expressions to > > > `OBJECT_DEPENDS` so that `$` may be used there > would be the next solution. > > > > Yes, the dependency in question for #import is on information > > "somewhere in the aether" (or rather the Win32 registry). > > > > Supporting $ does in OBJECT_DEPENDS would be a great > > solution for my first use case of a embedding that file in a resource. > > But I don't think that helps with #import, since I don't actually want > > to read the $, I just want the post-build that registers > > it to have run. > > POST_BUILD rules are attached to the target, so depending on the target also > guarantees that the POST_BUILD command(s) have run as well. Right, which is how I did it before. What I was saying (not very clearly) is that I only want the target to have been registered (so it's POST_BUILD has run), I don't care if it's newer. I only care if the .tlb file is newer, and I can do that with OBJECT_DEPENDS already. So the target part ought to be an order-only dependency (as it was in 3.8). Depending on $ is sufficient, but actually too strong. > > Also, in the cases of .tlb files that are *not* embedded in DLL > > resources, the target in question is going to be an add_custom_target > > from another subdirectory; the .tlb file is built by an > > add_custom_command(OUTPUT...) but this rule gets emitted in an > > add_custom_target that depends on this file to build it and then > > registers it. If each subdir had the add_custom_command instead of > > using an intermediate target, multiple targets would each end up with > > their own copy of the rule to build the .tlb file, leading to race > > conditions where they all try to build it at once and get file-in-use > > errors (they can't just build individual copies, because it has to end > > up with a unique key referencing the .tlb path in the win32 regist> > > ry). > > Yeah, there should be just one .tlb rule writer. Usually I handle that by > collecting information in global properties and writing a rule at the end to > handle all of them. Yeah. It would be really cool to have an end-of-input callback so include files that define their own commands could get a callback hook to write such "rule at the end" functions :-). > > You're not currently allowed to use $ on UTILITY > > targets even if the LOCATION property has been set (it's blocked in > > TargetFilesystemArtifact::Evaluate with "Target is not an > > executable or library"). Maybe that could be changed as well (which > > would be nice), but it seems like if one is adding support for > > $ generator expressions in OBJECT_DEPENDS (which > implies > > supporting the generator context and context->DependTargets), it seems > > like you as well go the rest of the way and just treat them completely > > the same as the DEPENDS argument to add_custom_command, allowing > both > > file and target dependencies to be listed in the first place. > > That sounds like a likely path to follow when supporting genexes in > OBJECT_DEPENDS. This would definitely solve my complaint; I'd be able to put target depends on an object rule in the (rare) case that it really needs them. > > > Making `POST_BUILD` write out a stamp file would also work and then > > > using `OBJECT_DEPENDS` on that would also work. > > > > No, as above I don't think that would be legal across subdirs, at > > least in the context of a CMake file that's supposed to work with > > various generators. Feel free to correct me if I'm wrong about that... > > Experiments would be more useful. add_custom_* have some of the most > complicated interaction semantics in CMake. I can't keep all of them straight > all the time (usually I rediscover them when necessary; I should probably > write up some docs next time I need to do so). > > --Ben From pfultz2 at yahoo.com Fri Aug 4 15:57:53 2017 From: pfultz2 at yahoo.com (paul) Date: Fri, 04 Aug 2017 14:57:53 -0500 Subject: [CMake] Interest in adding to CMake the CMakeGet module to get dependencies Message-ID: <1501876673.4133.158.camel@yahoo.com> Hi, I have a written a cmake module to get dependencies using the cget protocol here: https://github.com/pfultz2/cmake-get This is different than `ExternelProject`: * `ExternelProject` happens only during build, which allows this module to work in both in config and script mode.? * In config mode, the user can just do: cmake_get( PREFIX ${CMAKE_CURRENT_BINARY_DIR}/deps) find_package(?HINTS ${CMAKE_CURRENT_BINARY_DIR}/deps) Since the dependency is available at config time. * A script can be easily written to download the dependencies, which is much better approach to deal with toolchain transitivity, which is a problem that exists with both `ExternelProject` and config mode. * Recipes can be reused for building projects that don't use cmake, or don't follow the standard cmake installation flow. Furthermore, an existing cget recipe can be used as well. Is there interest in this project? Of course, the protocol for getting dependencies could be tweaked as based on feedback. I am the author of both this module and cget so it is possible to update cget to match feedback from the larger cmake community. Thanks, Paul From robert.maynard at kitware.com Fri Aug 4 16:09:15 2017 From: robert.maynard at kitware.com (Robert Maynard) Date: Fri, 4 Aug 2017 16:09:15 -0400 Subject: [CMake] CMake 3.9 change to dependencies of object compilation In-Reply-To: <74B7C9CD2B43054BA63CDE61908202D96648CA31@EDXMB90.jdnet.deere.com> References: <74B7C9CD2B43054BA63CDE61908202D96648B196@EDXMB90.jdnet.deere.com> <20170803155858.GA4124@megas.kitware.com> <74B7C9CD2B43054BA63CDE61908202D96648C99C@EDXMB90.jdnet.deere.com> <20170804175523.GA32083@megas.kitware.com> <74B7C9CD2B43054BA63CDE61908202D96648CA31@EDXMB90.jdnet.deere.com> Message-ID: I see no reason that we couldn't provide a TARGET_OBJ_DIR:tgt generator expression that states where the objects reside. Opening TARGET_OBJ_DIR and TARGET_OBJECTS to be evaluated for any target would require some work, and an interested CMake developer. FYI Due to XCode limitations we can't allow people to specify where object files should be placed for a library :( . On Fri, Aug 4, 2017 at 3:46 PM, Puetz Kevin A wrote: >> -----Original Message----- >> From: Ben Boeckel [mailto:ben.boeckel at kitware.com] >> Sent: Friday, August 04, 2017 12:55 PM >> To: Puetz Kevin A >> Cc: cmake at cmake.org; Robert Maynard >> Subject: Re: CMake 3.9 change to dependencies of object compilation >> >> On Fri, Aug 04, 2017 at 17:35:53 +0000, Puetz Kevin A wrote: > >> > > > 2. MSVC's #import construct which needs the indirect dependencies >> > > > (dependencies of the #import-ed dependency) be registered, which >> > > > is handled as part of the target using add_custom_command(TARGET >> > > > foo POST_BUILD COMMAND ...) >> > > >> > > So there's an issue here that there's a dependency between your >> > > build rules which CMake doesn't know about (though I don't know >> > > #import well enough, the docs don't state where the information >> *goes*). >> > >> > #import will load a COM typelib during preprocessing, possibly >> > following registry keys to locate other typelibs which the specified >> > one refers to. It will have the byproduct of creating .tlh/.tli files >> > next to the other compiler outputs (e.g. .o file) Arguably the >> > .tlh/.tli files should be listed in OBJECT_OUTPUTS, but I can't >> > because I don't know their location; CMake doesn't have a >> > variable/property/generator expression that reveals where it's going >> > to place the object files (i.e. /Fo$out), so I don't know where they >> > will end up. Luckily the .tlh/.tli files aren't important to list for >> > dependency resolution anyway, because the #import also automatically >> > #includes the just-generated headers, (though this is not mentioned in >> > /showIncludes). So CMake is at least *consistently* unaware of these >> > files, and they get regenerated any time they would have been read so >> > it doesn't really need to know. >> >> OK, a genex for where object outputs may be useful anyways. I think there's >> something along those lines with Cuda's PTX file generation? > > It would also be really nice for things like precompiled headers; I have some custom commands where it really feels right to put their outputs with the other object files for a target (this automatically getting things right for multi-configuration generators and such), but can't because there's no expression for that. Something like $ would be very welcome. > >> > The important missing dependency is the one between >> > creating/regstering the typelib (we'll call this target COMServer) and >> > the #import that will read it in a source file in another target >> > (we'll call it COMClient). I have a call add_custom_command(TARGET >> > COMServer POST_BUILD COMMAND regsvr32 $> COMServer>), >> > which will create the registry keys under HKEY_CLASSES_ROOT. This >> > needs to happen before the source file in COMClient can preprocess the >> > #import successfully. Prior to CMake 3.9, I could inform CMake of this >> > by just using add_dependencies(COMClient COMServer) to tell CMake that >> > it couldn't build (any of) Client until Server had been built (and >> > thus its POST_BUILD had also run to register it). But in 3.9, >> > add_dependencies has changed in meaning; although the documentation >> > still says "to ensure that they build before does", in >> > practice this now only means "to ensure that they build before >> > *links*"; these edges do not apply to object compilation or >> > add_custom_command rules. >> > >> > add_custom_command is no problem; it already had a DEPENDS argument >> > that allows target-level dependencies, and arguably such dependencies >> > needed to be stated there anyway since an add_custom_command output >> > can get reused by multiple targets in the same subdir. But object >> > compilation is a problem because there's nowhere to add them >> > per-source, and add_dependencies doesn't work anymore to add them >> > per-target. >> >> It sounds like the logic may need fixing then. Do you have an example case >> where add_dependencies doesn't work anymore in Ninja? > > CMakeLists.txt: > cmake_minimum_required(VERSION 3.7) > > add_library(A SHARED a.c) > > add_custom_command(TARGET A POST_BUILD > COMMENT "hello A" > COMMAND ${CMAKE_COMMAND} -E sleep 3 > COMMAND ${CMAKE_COMMAND} -E echo "hello A") > > add_custom_command(OUTPUT b.custom > COMMENT "hello B" > COMMAND ${CMAKE_COMMAND} -E touch b.custom) > > add_executable(B b.c b.custom) > add_dependencies(B A) > > a.c: > void foo() {} > > b.c: > int main() { return 0; } > > In CMake 3.7: > > build cmake_order_depends_target_B: phony || A.dll b.custom > build b.custom: CUSTOM_COMMAND || A.dll > build CMakeFiles\B.dir\b.c.obj: C_COMPILER__B C$:\Users\re41236\Desktop\test\cmake\b.c || cmake_order_depends_target_B > build B.exe: C_EXECUTABLE_LINKER__B CMakeFiles\B.dir\b.c.obj || A.dll > > In CMake 3.9: > build cmake_object_order_depends_target_B: phony || b.custom cmake_object_order_depends_target_A > build CMakeFiles\B.dir\b.c.obj: C_COMPILER__B C$:\Users\re41236\Desktop\test\cmake\b.c || cmake_object_order_depends_target_B > build b.custom: CUSTOM_COMMAND || A.dll > build B.exe: C_EXECUTABLE_LINKER__B CMakeFiles\B.dir\b.c.obj || A.dll > > So in 3.7, the add_dependencies(B A) put A.dll as an order-only dependency of all the rules that were part of B; nothing in B builds until everything in A does. > In 3.9 only the custom commands and link rules get it, the object rules don't. And there doesn't seem to be a way to explicitly get an order-only target dependency into the object rules in the (rare) cases where it actually was needed, like #import. So not only is it a breaking change, it?s not readily fixed. > > Admittedly right now this is pretty much limited to weird compiler (mis-)features like MSVC's #import that reference input besides the source/headers. Although it might become more common if the C++ modules TS ever catches on (you'll need the .ifc file generated by compiling the dependency before compiling objects that use it) > >> > > When adding >> > > this custom command, you may use the `BYPRODUCTS` argument >> > > (introduced in 3.2.0) to let CMake know what's going on here. It >> > > only affects Ninja, but the other generators do target-level >> > > dependencies anyways. That output can then be depended on via >> > > `OBJECT_DEPENDS` and the dependency should link up properly. >> > >> > There is not an explicit file output, though I could do the usual >> > workaround of a stamp/witness file listed in BYPRODUCTS to the >> > add_custom_command(TARGET ... POST_BUILD ...). But I don't think that >> > will work with most generators, since CMake doesn't generally allow >> > file-level depends to set the order in which targets are built. I >> > suppose it might work out in practice for ninja since that writes a >> > monolithic set of rules, but conditional code where I have to peek at >> > CMAKE_GENERATOR and use BYPRODUCTS/OBJECT_DEPENDS for ninja >> and >> > add_dependencies for other generators seems like the sort of thing >> > this list would tell me not to do :-) >> >> Well, other generators are generally target-ordered anyways. Ninja is the >> oddball here (which is why it's the only one to get the feature). I don't know >> the effect it'd have in other generators, but I feel like I'd be surprised if it >> *broke* them since excess dependencies (usually) only result in either >> slower builds or circular dependency loops and Ninja complains loudly about >> the latter. And since BYPRODUCTS only affects Ninja, if BYPRODUCTS is used, >> other generators shouldn't care anyways. > > True, I suppose I don?t need to peek at CMAKE_GENERATOR, I could just do it both ways all the time. As long as nobody comes up with a generator that can separate compile vs link dependencies, but still can't handle cross-subdir file dependencies. > >> > And even for ninja I think I'd have to be making undocumented >> > assumptions about the binary dir layout to refer to my witness file >> > that was generated in a different subdir's CMakelists.txt. >> >> There's nothing stopping the witness files couldn't all be under a single >> directory (such as ${CMAKE_BINARY_DIR}/CMakeFiles/tlb). > > Ok, good point. They don't have to be alongside the target's other artifacts. > >> > > If it instead gets registered somewhere in the aether (as far as >> > > CMake is concerned), adding support for generator expressions to >> > > `OBJECT_DEPENDS` so that `$` may be used there >> would be the next solution. >> > >> > Yes, the dependency in question for #import is on information >> > "somewhere in the aether" (or rather the Win32 registry). >> > >> > Supporting $ does in OBJECT_DEPENDS would be a great >> > solution for my first use case of a embedding that file in a resource. >> > But I don't think that helps with #import, since I don't actually want >> > to read the $, I just want the post-build that registers >> > it to have run. >> >> POST_BUILD rules are attached to the target, so depending on the target also >> guarantees that the POST_BUILD command(s) have run as well. > > Right, which is how I did it before. What I was saying (not very clearly) is that I only want the target to have been registered (so it's POST_BUILD has run), I don't care if it's newer. I only care if the .tlb file is newer, and I can do that with OBJECT_DEPENDS already. So the target part ought to be an order-only dependency (as it was in 3.8). Depending on $ is sufficient, but actually too strong. > >> > Also, in the cases of .tlb files that are *not* embedded in DLL >> > resources, the target in question is going to be an add_custom_target >> > from another subdirectory; the .tlb file is built by an >> > add_custom_command(OUTPUT...) but this rule gets emitted in an >> > add_custom_target that depends on this file to build it and then >> > registers it. If each subdir had the add_custom_command instead of >> > using an intermediate target, multiple targets would each end up with >> > their own copy of the rule to build the .tlb file, leading to race >> > conditions where they all try to build it at once and get file-in-use >> > errors (they can't just build individual copies, because it has to end >> > up with a unique key referencing the .tlb path in the win32 regist> >> > ry). >> >> Yeah, there should be just one .tlb rule writer. Usually I handle that by >> collecting information in global properties and writing a rule at the end to >> handle all of them. > > Yeah. It would be really cool to have an end-of-input callback so include files that define their own commands could get a callback hook to write such "rule at the end" functions :-). > >> > You're not currently allowed to use $ on UTILITY >> > targets even if the LOCATION property has been set (it's blocked in >> > TargetFilesystemArtifact::Evaluate with "Target is not an >> > executable or library"). Maybe that could be changed as well (which >> > would be nice), but it seems like if one is adding support for >> > $ generator expressions in OBJECT_DEPENDS (which >> implies >> > supporting the generator context and context->DependTargets), it seems >> > like you as well go the rest of the way and just treat them completely >> > the same as the DEPENDS argument to add_custom_command, allowing >> both >> > file and target dependencies to be listed in the first place. >> >> That sounds like a likely path to follow when supporting genexes in >> OBJECT_DEPENDS. > > This would definitely solve my complaint; I'd be able to put target depends on an object rule in the (rare) case that it really needs them. > >> > > Making `POST_BUILD` write out a stamp file would also work and then >> > > using `OBJECT_DEPENDS` on that would also work. >> > >> > No, as above I don't think that would be legal across subdirs, at >> > least in the context of a CMake file that's supposed to work with >> > various generators. Feel free to correct me if I'm wrong about that... >> >> Experiments would be more useful. add_custom_* have some of the most >> complicated interaction semantics in CMake. I can't keep all of them straight >> all the time (usually I rediscover them when necessary; I should probably >> write up some docs next time I need to do so). >> >> --Ben From cmpute at qq.com Fri Aug 4 20:14:29 2017 From: cmpute at qq.com (=?gb18030?B?1tPUqvbO?=) Date: Sat, 5 Aug 2017 08:14:29 +0800 Subject: [CMake] Not able to find boost with cmake Message-ID: Actually I have built boost from source with the version I downloaded, and I've run the install script given by boost. However, I just cannot let CMake find it. [ D:/Program Files/CMake/share/cmake-3.9/Modules/FindBoost.cmake:1450 ] _boost_LIBRARY_SEARCH_DIRS_RELEASE = D:/Program Files/PCL 1.8.0/3rdParty/Boost/include/boost-1_61/lib; ...(many other directories) [ D:/Program Files/CMake/share/cmake-3.9/Modules/FindBoost.cmake:1595 ] Searching for THREAD_LIBRARY_RELEASE: libboost_thread-vc141-mt-1_61;libboost_thread-vc141-mt;libboost_thread-vc140-mt-1_61;libboost_thread-vc140-mt;libboost_thread-mt-1_61;libboost_thread-mt;libboost_thread These are two lines in the output message, and I'm sure there is a file named "libboost_thread-vc141-mt-1_61.lib" in the lib directory listed in the first line where CMake will search for in. However, the error message told me: Could not find the following static Boost libraries: boost_thread I don't know how this happened since it seems that CMake had already found the lib files. The attached log file shows the detail. (PS: really sorry to reply again, I'm new to mailing list service) Thanks, Jacob Zhong ------------------ ???? ------------------ ???: "Bo Zhou";; ????: 2017?8?4?(???) ??12:19 ???: "???"; ??: "cmake"; ??: Re: [CMake] Not able to find boost with cmake It's better not to use downloaded pre-built libraries, always build by yourself locally. Before using Boost with CMake, please check https://cmake.org/cmake/help/v3.0/module/FindBoost.html If you're trying to use static boost libraries build by MSVC with shared runtime, please make sure the following statements exist in the PCL. set(Boost_USE_STATIC_LIBS ON) set(Boost_USE_MULTITHREADED ON) set(Boost_USE_STATIC_RUNTIME OFF) Then if you properly set the Boost_INCLUDE_DIR, all the libraries should be ready then. On Fri, Aug 4, 2017 at 1:05 PM, ??? wrote: I'm trying to build PCL which has boost as dependency. However, when I download boost and build it, cmake cannot find it through any way. I tried two version of boost, one is pre-build boost which was built by other person online and version is 1.61, another is one I downloaded whose version is 1.64. File structures of the two versions are the same: [XXX]/include/boost-1_64/boost is the include dir and [XXX]/lib is the bin dir I try to specify the Boost_INCLUDE_DIR to [XXX]/include/boost-1_64/boost, the messages in output window is attached (I turned Boost_DEBUG on). I'm on Window 10 and VS2017 Thanks, Jacob Zhong ------------------ ???? ??? Yuanxin Zhong ????????? Dept. of Automotive Engineering, Tsinghua Univ. Ad:Haidian District, Beijing, P.R.China 100084 Tel:+86 17888833119 E-mail?cmpute at foxmail.com / zhongyx14 at mails.tsinghua.edu.cn -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: A56076E6 at D317FD5B.E50D8559.jpg Type: image/jpeg Size: 13551 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 7DFA70E3 at D4E6C253.E50D8559.jpg Type: image/jpeg Size: 11484 bytes Desc: not available URL: From craig.scott at crascit.com Fri Aug 4 22:18:27 2017 From: craig.scott at crascit.com (Craig Scott) Date: Sat, 5 Aug 2017 12:18:27 +1000 Subject: [CMake] Interest in adding to CMake the CMakeGet module to get dependencies In-Reply-To: <1501876673.4133.158.camel@yahoo.com> References: <1501876673.4133.158.camel@yahoo.com> Message-ID: TLDR: There may be other work already covering similar capabilities (e.g. hunter and WIP that I'm uncloaking here). This response is mostly about providing broader discussion. Paul it seems you've been busy since you first asked about cget on this list last year. ;) In the interests of disclosure, this latest email of yours has prompted me to uncloak some of my own work which may be relevant. This work has been in development and testing on real world projects for the past 2 years or so. Without wanting to hijack your thread, let me give a little info about it and then see my responses to your comments at the end for how/why I think this may be relevant to your request for comments. ExternalProject can be used in a different way to allow it to perform downloads at configure time rather than build time. You can see a relatively straightforward implementation of this here: https://github.com/Crascit/DownloadProject This has the advantage of leveraging all of the various download methods ExternalProject already provides, meaning they are already fairly widely used and tested. Any improvements to ExternalProject also come for free and documentation for the various methods is also provided (I recently overhauled the ExternalProject docs and these will appear in the 3.10.0 release, but they can be viewed in the master docs in the meantime). ExternalProject also has the advantage that it supports updating after the initial download in the case of repository sources like git, svn, etc. The uncloaking part of my response is that I have been working on a full dependency download framework over the past year and half which is built on top of the above DownloadProject implementation. It supports hierarchical dependencies across complex project structures and makes it very easy for projects to pull in other projects, including support for higher level projects being able to override dependency details of projects lower in the dependency tree if they want to. I've been incubating this privately in a real world company environment to iron out the kinks and ensure the interface that projects interact with supports the right set of features and that less knowledgable users can understand it, etc. I'm planning on putting both DownloadProject and the dependency framework up for review to merge into CMake within the next few months, all going well. Whereas your work seems to focus on building and/or re-using an installed/binary result, my work focuses more on making external projects part of your main build. This has advantages like using the same compiler settings, toolchain details, etc. and all of the dependency targets are automatically available to the rest of the project if the dependency uses CMake as its build system. I'll postpone further details on it until it is ready for review, but that should be enough for context for my responses to your comments further below. There's also hunter , which you've already been made aware of and which is closer to your proposal in terms of the set of problems it tries to solve. Hunter has been around for a while, is reasonably well known and on the face of it, already seems to do all the things cmake-get is trying to do. It is also based on ExternalProject. It may be helpful if you could show how your work differs from what hunter already provides so that its value to the CMake community is clear. Hopefully that's not too overwhelming for background/context. See my responses in the remainder below. On Sat, Aug 5, 2017 at 5:57 AM, paul via CMake wrote: > Hi, > > I have a written a cmake module to get dependencies using the cget protocol > here: > > https://github.com/pfultz2/cmake-get > > This is different than `ExternelProject`: > > * `ExternelProject` happens only during build, which allows this module to > work in both in config and script mode. > As detailed above, you can use ExternalProject at configure time too and there's already a relatively simple, generic implementation available showing how to do it for the download case. > * In config mode, the user can just do: > > cmake_get( PREFIX ${CMAKE_CURRENT_BINARY_DIR}/deps) > find_package( HINTS ${CMAKE_CURRENT_BINARY_DIR}/deps) > > Since the dependency is available at config time. > This is a little naive. What if there is a complex hierarchy of projects and more than one wants to use a particular dependency, but they both want to specify different versions or repository details? How would that be resolved? The "get" functionality looks quite limited, both in terms of the supported methods and the ability to specify method-specific details. ExternalProject already has pretty good coverage for this. In the case of multiple projects wanting different dependency details, you need to decide how to choose one project's details over another, or if you want to allow both to be downloaded/built then how to prevent them from resulting in inconsistencies or clashes (e.g. if there's "A links to B", you really don't want to have to ask "which B?"). The find_package() call would also seem to rely on the dependent project implementing install(EXPORT) rules for all the things you want to use from it, or at least providing Config.cmake files or their equivalent to make targets, etc. available. Many projects will do this, but quite a few won't. You might be able to use find_library(), find_program() and find_file() in such cases, but these all require the dependency to have already been built. You generally don't want things building during the config stage if you can avoid it, as a slow config stage is pretty annoying as a developer. If I'm understanding your implementation correctly, it builds the dependency if it hasn't previously, which may make the config stage very slow when it can't used a cached build from earlier. I believe this is more or less what hunter does too (Ruslo, feel free to clarify/correct/call-me-nuts here!). Compare this with the approach my framework is taking where the build is still deferred to the build stage, only the download happens at config time. BTW, if you really need the external project built at config time, this stackoverflow question and answer may also be of interest (mentioned more for the benefit of others than for this discussion around cmake-get). > * A script can be easily written to download the dependencies, which is > much > better approach to deal with toolchain transitivity, which is a problem > that > exists with both `ExternelProject` and config mode. > You may want to consider separating out the downloading from the building. What I've found is that there are situations where all you want is to download some content at config time but perhaps not build it. Potentially you could just download and unpack a pre-built tarball directly, so there may be no need to build at all. Conversely, if you download the sources and make the external dependency part of your main project's build, then the whole toolchain, compiler settings, etc. problem largely goes away (if the dependency project uses CMake and doesn't do things which assume it is the top level of the build). There's also the matter of if you script something, what scripting language do you use? For cross-platform projects, unix shell scripts aren't always supported. Cross-platform languages like python come with their own dependencies (i.e. the python interpreter). You may find that you end up using cmake as your scripting language, since that's about the only common one that will work everywhere without requiring any further dependencies. Now you may find that the commands you would have put in such a cmake script could have been made part of the main project to begin with (or made available as a module). Again, this starts pointing back to building the project as part of the main build, especially when the toolchain and compiler flag consistency advantages are taken into consideration. > * Recipes can be reused for building projects that don't use cmake, or > don't > follow the standard cmake installation flow. Furthermore, an existing cget > recipe can be used as well. > This can be very useful for publicly accessible projects, especially for popular ones. I see that you've already got a collection of recipes for a variety of projects. I haven't looked deeply at your implementation, but I take it that it would support users working with private repos using their own private recipe stores too? I believe hunter offers similar functionality to this as well, but I could be wrong. Ruslo? Even for the approach I'm working on, non-CMake projects can be handled fairly easily with existing ExternalProject functionality. If I need files from the dependency at config time (e.g. headers so I can query for version details), I can use DownloadProject to download the source at configure time and then point ExternalProject at the downloaded source rather than specifying a download method and have ExternalProject trigger the relevant build commands (e.g. a Makefile-based project). Again, this leverages functionality already provided by CMake rather than reinventing the wheel formulating my own logic to manage external build steps. > Is there interest in this project? Of course, the protocol for getting > dependencies could be tweaked as based on feedback. I am the author of both > this module and cget so it is possible to update cget to match feedback > from > the larger cmake community. > My own experience is that there is quite a bit of interest among CMake users to have some sort of easy to use mechanism for handling project dependencies (which is in part why I'm intending to put up a potential solution soon myself). It starts getting hard when you consider that for a particular dependency, different projects may want to build it with different settings, flags, compilers, etc. which means you need to manage not only "A depends on B", but also "A depends on B built this way". The approach I'm taking is to make download easy, including specifying precisely the repository details and download methods of the dependency, but put the build of that dependency in the hands of the project. What you've encapsulated as "recipes" can be provided separately either as a collection of modules or whatever other way ends up being convenient and used once the dependency has been downloaded. Thus, the download part can be captured fairly generically and easy-to-use functionality be provided to facilitate it, but building is a different animal. From what I understand of your work, it seems like the two have been more closely coupled in a similar way to hunter, although the implementations are obviously very different. Again, apologies to yourself and Ruslo if I've misunderstood either one. So yes, there's definitely interest and to be honest, there isn't going to be one solution to rule them all. There's a place for the different approaches (I see hunter and my own work as solving related but different problems, for example), but my purpose here is to provide broader information for further consideration and discussion. Hopefully I haven't poured too much cold water on an otherwise very interesting area! -- Craig Scott Melbourne, Australia https://crascit.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From veikko_e at hotmail.com Sat Aug 5 05:51:44 2017 From: veikko_e at hotmail.com (Veikko Eeva) Date: Sat, 5 Aug 2017 09:51:44 +0000 Subject: [CMake] Interest in adding to CMake the CMakeGet module to get dependencies In-Reply-To: References: <1501876673.4133.158.camel@yahoo.com>, Message-ID: > TLDR: There may be other work already covering similar capabilities (e.g. hunter and WIP that I'm uncloaking here). This response is mostly about providing broader discussion. https://github.com/Microsoft/vcpkg https://github.com/conan-io/cmake-conan https://github.com/Microsoft/vcpkg/issues/478 Cheers, Veikko Eeva L?hett?j?: CMake k?ytt?j?n Craig Scott puolesta L?hetetty: 5. elokuuta 2017 5:18 Vastaanottaja: paul Kopio: cmake at cmake.org; Ruslan Baratov Aihe: Re: [CMake] Interest in adding to CMake the CMakeGet module to get dependencies ? TLDR: There may be other work already covering similar capabilities (e.g. hunter and WIP that I'm uncloaking here). This response is mostly about providing broader discussion. Paul it seems you've been busy since you first asked about cget on this list last year. ;) In the interests of disclosure, this latest email of yours has prompted me to uncloak some of my own work which may be relevant. This work has been in development and testing on real world projects for the past 2 years or so. Without wanting to hijack your thread, let me give a little info about it and then see my responses to your comments at the end for how/why I think this may be relevant to your request for comments. ExternalProject can be used in a different way to allow it to perform downloads at configure time rather than build time. You can see a relatively straightforward implementation of this here: ? ? https://github.com/Crascit/DownloadProject This has the advantage of leveraging all of the various download methods ExternalProject already provides, meaning they are already fairly widely used and tested. Any improvements to ExternalProject also come for free and documentation for the various methods is also provided (I recently overhauled the ExternalProject docs and these will appear in the 3.10.0 release, but they can be viewed in the master docs in the meantime). ExternalProject also has the advantage that it supports updating after the initial download in the case of repository sources like git, svn, etc. The uncloaking part of my response is that I have been working on a full dependency download framework over the past year and half which is built on top of the above DownloadProject implementation. It supports hierarchical dependencies across complex project structures and makes it very easy for projects to pull in other projects, including support for higher level projects being able to override dependency details of projects lower in the dependency tree if they want to. I've been incubating this privately in a real world company environment to iron out the kinks and ensure the interface that projects interact with supports the right set of features and that less knowledgable users can understand it, etc. I'm planning on putting both DownloadProject and the dependency framework up for review to merge into CMake within the next few months, all going well. Whereas your work seems to focus on building and/or re-using an installed/binary result, my work focuses more on making external projects part of your main build. This has advantages like using the same compiler settings, toolchain details, etc. and all of the dependency targets are automatically available to the rest of the project if the dependency uses CMake as its build system. I'll postpone further details on it until it is ready for review, but that should be enough for context for my responses to your comments further below. There's also hunter, which you've already been made aware of and which is closer to your proposal in terms of the set of problems it tries to solve. Hunter has been around for a while, is reasonably well known and on the face of it, already seems to do all the things cmake-get is trying to do. It is also based on ExternalProject. It may be helpful if you could show how your work differs from what hunter already provides so that its value to the CMake community is clear. Hopefully that's not too overwhelming for background/context. See my responses in the remainder below. On Sat, Aug 5, 2017 at 5:57 AM, paul via CMake wrote: Hi, I have a written a cmake module to get dependencies using the cget protocol here: https://github.com/pfultz2/cmake-get This is different than `ExternelProject`: * `ExternelProject` happens only during build, which allows this module to work in both in config and script mode.? As detailed above, you can use ExternalProject at configure time too and there's already a relatively simple, generic implementation available showing how to do it for the download case. ? * In config mode, the user can just do: cmake_get( PREFIX ${CMAKE_CURRENT_BINARY_DIR}/deps) find_package(?HINTS ${CMAKE_CURRENT_BINARY_DIR}/deps) Since the dependency is available at config time. This is a little naive. What if there is a complex hierarchy of projects and more than one wants to use a particular dependency, but they both want to specify different versions or repository details? How would that be resolved? The "get" functionality looks quite limited, both in terms of the supported methods and the ability to specify method-specific details. ExternalProject already has pretty good coverage for this. In the case of multiple projects wanting different dependency details, you need to decide how to choose one project's details over another, or if you want to allow both to be downloaded/built then how to prevent them from resulting in inconsistencies or clashes (e.g. if there's "A links to B", you really don't want to have to ask "which B?"). The find_package() call would also seem to rely on the dependent project implementing install(EXPORT) rules for all the things you want to use from it, or at least providing Config.cmake files or their equivalent to make targets, etc. available. Many projects will do this, but quite a few won't. You might be able to use find_library(), find_program() and find_file() in such cases, but these all require the dependency to have already been built. You generally don't want things building during the config stage if you can avoid it, as a slow config stage is pretty annoying as a developer. If I'm understanding your implementation correctly, it builds the dependency if it hasn't previously, which may make the config stage very slow when it can't used a cached build from earlier. I believe this is more or less what hunter does too (Ruslo, feel free to clarify/correct/call-me-nuts here!). Compare this with the approach my framework is taking where the build is still deferred to the build stage, only the download happens at config time. BTW, if you really need the external project built at config time, this stackoverflow question and answer may also be of interest (mentioned more for the benefit of others than for this discussion around cmake-get). ? * A script can be easily written to download the dependencies, which is much better approach to deal with toolchain transitivity, which is a problem that exists with both `ExternelProject` and config mode. You may want to consider separating out the downloading from the building. What I've found is that there are situations where all you want is to download some content at config time but perhaps not build it. Potentially you could just download and unpack a pre-built tarball directly, so there may be no need to build at all. Conversely, if you download the sources and make the external dependency part of your main project's build, then the whole toolchain, compiler settings, etc. problem largely goes away (if the dependency project uses CMake and doesn't do things which assume it is the top level of the build).? There's also the matter of if you script something, what scripting language do you use? For cross-platform projects, unix shell scripts aren't always supported. Cross-platform languages like python come with their own dependencies (i.e. the python interpreter). You may find that you end up using cmake as your scripting language, since that's about the only common one that will work everywhere without requiring any further dependencies. Now you may find that the commands you would have put in such a cmake script could have been made part of the main project to begin with (or made available as a module). Again, this starts pointing back to building the project as part of the main build, especially when the toolchain and compiler flag consistency advantages are taken into consideration. ? * Recipes can be reused for building projects that don't use cmake, or don't follow the standard cmake installation flow. Furthermore, an existing cget recipe can be used as well. This can be very useful for publicly accessible projects, especially for popular ones. I see that you've already got a collection of recipes for a variety of projects. I haven't looked deeply at your implementation, but I take it that it would support users working with private repos using their own private recipe stores too? I believe hunter offers similar functionality to this as well, but I could be wrong. Ruslo? Even for the approach I'm working on, non-CMake projects can be handled fairly easily with existing ExternalProject functionality. If I need files from the dependency at config time (e.g. headers so I can query for version details), I can use DownloadProject to download the source at configure time and then point ExternalProject at the downloaded source rather than specifying a download method and have ExternalProject trigger the relevant build commands (e.g. a Makefile-based project). Again, this leverages functionality already provided by CMake rather than reinventing the wheel formulating my own logic to manage external build steps. ? Is there interest in this project? Of course, the protocol for getting dependencies could be tweaked as based on feedback. I am the author of both this module and cget so it is possible to update cget to match feedback from the larger cmake community. My own experience is that there is quite a bit of interest among CMake users to have some sort of easy to use mechanism for handling project dependencies (which is in part why I'm intending to put up a potential solution soon myself). It starts getting hard when you consider that for a particular dependency, different projects may want to build it with different settings, flags, compilers, etc. which means you need to manage not only "A depends on B", but also "A depends on B built this way". The approach I'm taking is to make download easy, including specifying precisely the repository details and download methods of the dependency, but put the build of that dependency in the hands of the project. What you've encapsulated as "recipes" can be provided separately either as a collection of modules or whatever other way ends up being convenient and used once the dependency has been downloaded. Thus, the download part can be captured fairly generically and easy-to-use functionality be provided to facilitate it, but building is a different animal. From what I understand of your work, it seems like the two have been more closely coupled in a similar way to hunter, although the implementations are obviously very different. Again, apologies to yourself and Ruslo if I've misunderstood either one. So yes, there's definitely interest and to be honest, there isn't going to be one solution to rule them all. There's a place for the different approaches (I see hunter and my own work as solving related but different problems, for example), but my purpose here is to provide broader information for further consideration and discussion. Hopefully I haven't poured too much cold water on an otherwise very interesting area! -- Craig Scott Melbourne, Australia https://crascit.com From jupiter.hce at gmail.com Sat Aug 5 07:28:37 2017 From: jupiter.hce at gmail.com (jupiter) Date: Sat, 5 Aug 2017 21:28:37 +1000 Subject: [CMake] Failed to build C++ source with CMakeLists.txt Message-ID: Hi, I have built many open sources with gcc 4.9.1 on CentOS 6.8 platform, but I could not build this one and I have no idea what was wrong with this CMakeLists.txt, I have attached both CMakeLists.txt and CMakeError.log, appreciate any clues what was missing. Thank you. $ ls /usr/local/cppcms/1.1.0/include booster cppcms -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- cmake_minimum_required(VERSION 2.6) project(cppcms) include_directories(${CMAKE_SOURCE_DIR}) # Options option(STATIC_VIEW "Build Static View instead of dynamically loaded one" OFF) if(WIN32 OR CYGWIN) add_definitions(-DDLL_EXPORT) endif() # Dependencies find_library(LIB_BOOSTER booster) find_library(LIB_CPPCMS cppcms) find_library(LIB_CPPDB cppdb) find_program(EXE_TMPL_CC cppcms_tmpl_cc) find_program(EXE_MSGFMT msgfmt) find_program(EXE_SQLITE3 sqlite3) find_path(INC_BOOSTER booster/config.h) find_path(INC_CPPCMS cppcms/config.h) find_path(INC_CPPDB cppdb/frontend.h) # Sources set(VIEW_NAME simple) set(VIEW_TEMPLATES view/master.tmpl view/forums.tmpl view/thread.tmpl) set(MB_SRC apps/master.cpp apps/thread.cpp apps/forums.cpp apps/mb.cpp apps/main.cpp) set(MB_LANG he) # Actual Build include_directories(${INC_BOOSTER}) include_directories(${INC_CPPCMS}) include_directories(${INC_CPPDB}) set(VIEW_SRC "${CMAKE_CURRENT_BINARY_DIR}/${VIEW_NAME}.cpp") add_custom_command( OUTPUT ${VIEW_SRC} COMMAND ${EXE_TMPL_CC} -s "${VIEW_NAME}" ${TMPL_CC_PARAMS} -o ${VIEW_SRC} ${VIEW_TEMPLATES} WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR} DEPENDS ${VIEW_TEMPLATES}) if(STATIC_VIEW) set(MB_SRC ${MB_SRC} ${VIEW_SRC}) else() add_library(${VIEW_NAME} SHARED ${VIEW_SRC}) target_link_libraries(${VIEW_NAME} ${LIB_CPPCMS}) target_link_libraries(${VIEW_NAME} ${LIB_BOOSTER}) endif() add_executable(mb ${MB_SRC}) target_link_libraries(mb ${LIB_CPPCMS}) target_link_libraries(mb ${LIB_BOOSTER}) target_link_libraries(mb ${LIB_CPPDB}) if(EXE_MSGFMT) set(MO_FILES) foreach(LANG ${MB_LANG}) set(PO locale/${LANG}/LC_MESSAGES/mb.po) set(MO ${CMAKE_CURRENT_BINARY_DIR}/locale/${LANG}/LC_MESSAGES/mb.mo) file(MAKE_DIRECTORY "${CMAKE_CURRENT_BINARY_DIR}/locale/${LANG}/LC_MESSAGES") set(MO_FILES ${MO_FILES} ${MO}) add_custom_command( OUTPUT ${MO} COMMAND ${EXE_MSGFMT} ${PO} -o ${MO} WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR} DEPENDS ${PO}) endforeach() add_custom_target(create-mo ALL DEPENDS ${MO_FILES}) else() message("-- msgfmt not found, translations not generatied") endif() if(EXE_SQLITE3) add_custom_command( OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/mb.db COMMAND ${EXE_SQLITE3} < ${CMAKE_CURRENT_SOURCE_DIR}/model/sqlite3.sql ${CMAKE_CURRENT_BINARY_DIR}/mb.db) add_custom_target(sqlitedb ALL DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/mb.db) endif() -------------- next part -------------- A non-text attachment was scrubbed... Name: CMakeError.log Type: text/x-log Size: 2166 bytes Desc: not available URL: From pfultz2 at yahoo.com Sat Aug 5 23:29:25 2017 From: pfultz2 at yahoo.com (P F) Date: Sat, 5 Aug 2017 22:29:25 -0500 Subject: [CMake] Interest in adding to CMake the CMakeGet module to get dependencies In-Reply-To: References: <1501876673.4133.158.camel@yahoo.com> Message-ID: > On Aug 4, 2017, at 9:18 PM, Craig Scott wrote: > > TLDR: There may be other work already covering similar capabilities (e.g. hunter and WIP that I'm uncloaking here). This response is mostly about providing broader discussion. > > > Paul it seems you've been busy since you first asked about cget on this list last year. ;) Thanks, cget has improved a lot in the last year. > > In the interests of disclosure, this latest email of yours has prompted me to uncloak some of my own work which may be relevant. This work has been in development and testing on real world projects for the past 2 years or so. Without wanting to hijack your thread, let me give a little info about it and then see my responses to your comments at the end for how/why I think this may be relevant to your request for comments. > > ExternalProject can be used in a different way to allow it to perform downloads at configure time rather than build time. You can see a relatively straightforward implementation of this here: > > https://github.com/Crascit/DownloadProject > That seems to support the `add_subdirectory` workflow, but how would it work when using the `find_package` workflow? This workflow is useful to help package manager tools(including those which pulls binaries). > This has the advantage of leveraging all of the various download methods ExternalProject already provides, meaning they are already fairly widely used and tested. Any improvements to ExternalProject also come for free and documentation for the various methods is also provided (I recently overhauled the ExternalProject docs and these will appear in the 3.10.0 release, but they can be viewed in the master docs in the meantime). ExternalProject also has the advantage that it supports updating after the initial download in the case of repository sources like git, svn, etc. > > The uncloaking part of my response is that I have been working on a full dependency download framework over the past year and half which is built on top of the above DownloadProject implementation. It supports hierarchical dependencies across complex project structures and makes it very easy for projects to pull in other projects, including support for higher level projects being able to override dependency details of projects lower in the dependency tree if they want to. I've been incubating this privately in a real world company environment to iron out the kinks and ensure the interface that projects interact with supports the right set of features and that less knowledgable users can understand it, etc. I'm planning on putting both DownloadProject and the dependency framework up for review to merge into CMake within the next few months, all going well. Whereas your work seems to focus on building and/or re-using an installed/binary result, my work focuses more on making external projects part of your main build. This has advantages like using the same compiler settings, toolchain details, etc. and all of the dependency targets are automatically available to the rest of the project if the dependency uses CMake as its build system. I'll postpone further details on it until it is ready for review, but that should be enough for context for my responses to your comments further below. > > There's also hunter , which you've already been made aware of and which is closer to your proposal in terms of the set of problems it tries to solve. Hunter has been around for a while, is reasonably well known and on the face of it, already seems to do all the things cmake-get is trying to do. It is also based on ExternalProject. It may be helpful if you could show how your work differs from what hunter already provides so that its value to the CMake community is clear. > > Hopefully that's not too overwhelming for background/context. See my responses in the remainder below. > > > > On Sat, Aug 5, 2017 at 5:57 AM, paul via CMake > wrote: > Hi, > > I have a written a cmake module to get dependencies using the cget protocol > here: > > https://github.com/pfultz2/cmake-get > > This is different than `ExternelProject`: > > * `ExternelProject` happens only during build, which allows this module to > work in both in config and script mode. > > As detailed above, you can use ExternalProject at configure time too and there's already a relatively simple, generic implementation available showing how to do it for the download case. > > > * In config mode, the user can just do: > > cmake_get( PREFIX ${CMAKE_CURRENT_BINARY_DIR}/deps) > find_package( HINTS ${CMAKE_CURRENT_BINARY_DIR}/deps) > > Since the dependency is available at config time. > > This is a little naive. What if there is a complex hierarchy of projects and more than one wants to use a particular dependency, but they both want to specify different versions or repository details? How would that be resolved? There is no SAT solving, and having package manager with this would be useful. The focus of this is too just enable the dependencies for a given project. > The "get" functionality looks quite limited, both in terms of the supported methods and the ability to specify method-specific details. ExternalProject already has pretty good coverage for this. In the case of multiple projects wanting different dependency details, you need to decide how to choose one project's details over another, or if you want to allow both to be downloaded/built then how to prevent them from resulting in inconsistencies or clashes (e.g. if there's "A links to B", you really don't want to have to ask "which B?"). > > The find_package() call would also seem to rely on the dependent project implementing install(EXPORT) rules for all the things you want to use from it, or at least providing Config.cmake files or their equivalent to make targets, etc. available. Many projects will do this, but quite a few won't. You might be able to use find_library(), find_program() and find_file() in such cases Yes, in the example I use `find_package`, but if that isn?t available, then you will want to use cmake?s other `find_*` commands, which helps make your library package-manager friendly. > , but these all require the dependency to have already been built. You generally don't want things building during the config stage if you can avoid it, as a slow config stage is pretty annoying as a developer. If I'm understanding your implementation correctly, it builds the dependency if it hasn't previously, which may make the config stage very slow when it can't used a cached build from earlier. Yes, the config can be slow. The other problem is the toolchain is not transitive. So if the user has a special toolchain, it won?t invoke cmake the same way. This is why using a separate script is preferred. The purpose of this is to provide a way to get the dependencies when there is no dependency management tool. Perhaps, the user doesn?t want to install a dependency management tool or they don?t want to install each dependency manual. So this can help, but at the same time a user maybe using their own dependency management tool so it important not to interfere with the `find_*` commands in cmake. That why in config mode the user can disable getting dependencies with `BUILD_DEPS=Off`. > I believe this is more or less what hunter does too (Ruslo, feel free to clarify/correct/call-me-nuts here!). Compare this with the approach my framework is taking where the build is still deferred to the build stage, only the download happens at config time. That is because it uses `add_subdirectory`, which is not very package manager-friendly. Because if someone wants to install the dependencies themselves, it will download and build them again, which may not be want the user wants. This can be made to work but it requires creating a superproject which contains the project+dependencies. > BTW, if you really need the external project built at config time, this stackoverflow question and answer may also be of interest (mentioned more for the benefit of others than for this discussion around cmake-get). I dont see that using ExternalProject. > > > * A script can be easily written to download the dependencies, which is much > better approach to deal with toolchain transitivity, which is a problem that > exists with both `ExternelProject` and config mode. > > You may want to consider separating out the downloading from the building. What I've found is that there are situations where all you want is to download some content at config time but perhaps not build it. Potentially you could just download and unpack a pre-built tarball directly, so there may be no need to build at all. Conversely, if you download the sources and make the external dependency part of your main project's build, then the whole toolchain, compiler settings, etc. problem largely goes away (if the dependency project uses CMake and doesn't do things which assume it is the top level of the build). You can install binaries with `cmake_get( PREFIX ${CMAKE_CURRENT_BINARY_DIR}/deps CMAKE_FILE binary)`. > > There's also the matter of if you script something, what scripting language do you use? For cross-platform projects, unix shell scripts aren't always supported. Cross-platform languages like python come with their own dependencies (i.e. the python interpreter). You may find that you end up using cmake as your scripting language, since that's about the only common one that will work everywhere without requiring any further dependencies. Thats what cget basically does, it uses cmake as it scripting language. > Now you may find that the commands you would have put in such a cmake script could have been made part of the main project to begin with (or made available as a module). Which is why cget(or cmake-get) can install the dependencies by default by directly invoking `cmake` without any extra scripting. Of course, build scripts shouldn?t always build its dependencies as that would interfere with a dependency management tool. > Again, this starts pointing back to building the project as part of the main build, especially when the toolchain and compiler flag consistency advantages are taken into consideration. A dependency management tool will take care of invoking every package with the same toolchain settings. Cmake also makes this easy with toolchain files. > > > * Recipes can be reused for building projects that don't use cmake, or don't > follow the standard cmake installation flow. Furthermore, an existing cget > recipe can be used as well. > > This can be very useful for publicly accessible projects, especially for popular ones. I see that you've already got a collection of recipes for a variety of projects. I haven't looked deeply at your implementation, but I take it that it would support users working with private repos using their own private recipe stores too? Setting up a repo with private recipes is easy. It just a matter of pointing it to the private URL. > I believe hunter offers similar functionality to this as well, but I could be wrong. Ruslo? > > Even for the approach I'm working on, non-CMake projects can be handled fairly easily with existing ExternalProject functionality. If I need files from the dependency at config time (e.g. headers so I can query for version details), I can use DownloadProject to download the source at configure time and then point ExternalProject at the downloaded source rather than specifying a download method and have ExternalProject trigger the relevant build commands (e.g. a Makefile-based project). Again, this leverages functionality already provided by CMake rather than reinventing the wheel formulating my own logic to manage external build steps. > > > Is there interest in this project? Of course, the protocol for getting > dependencies could be tweaked as based on feedback. I am the author of both > this module and cget so it is possible to update cget to match feedback from > the larger cmake community. > > My own experience is that there is quite a bit of interest among CMake users to have some sort of easy to use mechanism for handling project dependencies (which is in part why I'm intending to put up a potential solution soon myself). It starts getting hard when you consider that for a particular dependency, different projects may want to build it with different settings, flags, compilers, etc. which means you need to manage not only "A depends on B", but also "A depends on B built this way?. Yes, a SAT solver would be needed to solve these types of problem. For now, cget just uses a first come, first serve, which pushes the issue on to the user to solve. > The approach I'm taking is to make download easy, including specifying precisely the repository details and download methods of the dependency, but put the build of that dependency in the hands of the project. Yes, your dependency management is built around the `add_subdirectory` workflow, whereas cget using the `find_package` workflow. > What you've encapsulated as "recipes" can be provided separately either as a collection of modules or whatever other way ends up being convenient and used once the dependency has been downloaded. The recipe encapsulates the URL to download as well. > Thus, the download part can be captured fairly generically and easy-to-use functionality be provided to facilitate it, but building is a different animal. From what I understand of your work, it seems like the two have been more closely coupled in a similar way to hunter, although the implementations are obviously very different. Again, apologies to yourself and Ruslo if I've misunderstood either one. The implementation is different, but I wonder if there is room for interoperability between hunter and cget. > > So yes, there's definitely interest and to be honest, there isn't going to be one solution to rule them all. No, there won?t be one solution, nor will there be a universal package manager for C/C++. This why it is important to have dependency management tool that can interoperate with other package managers, and build scripts which are orthogonal to the package manager. > There's a place for the different approaches (I see hunter and my own work as solving related but different problems, for example), but my purpose here is to provide broader information for further consideration and discussion. Yes, but when you want to install a dependency, it would be could to have some specification of how to get and install that dependency very likely built around cmake. Cget provides a simple protocol for this, but could possibly be tweaked for better flexibility. > Hopefully I haven't poured too much cold water on an otherwise very interesting area! Thanks for the reply. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bitminer at gmail.com Sun Aug 6 14:37:43 2017 From: bitminer at gmail.com (Brian Davis) Date: Sun, 6 Aug 2017 13:37:43 -0500 Subject: [CMake] CMake CUDA 3.8+/9 support as a first class language with out Visual Studio Support... err what? In-Reply-To: <150725ad-ac46-b99e-8fa1-e86bf8ee9175@gmail.com> References: <7ca86101-dfe0-957f-182f-cde17d4f83c4@wisc.edu> <150725ad-ac46-b99e-8fa1-e86bf8ee9175@gmail.com> Message-ID: Upon: wiping Dell 7559 (yes the weirdness has gotten this bad), reinstalling from Dell Factory image upgrading system to Latest Win 10 (now not in developer mode anymore) Dell update to get latest drivers and other goobly bits Removing all Virus Scanners to keep this from possibly interfering Installing Visual Studio 2013 Community Installing CUDA 7.5 and packaged driver Imagining with Clonezilla for posterity sake in case... uhhh... when windows acts up again. These statements: > Regarding 960M and CUDA 7.5/7.5, 8.0/7.5, and 7.7/9.0 > > Answer is: > > 960M was likely released post CUDA 7.5 driver and possibly post 8.0. > Seems that architecture differences do not allow old drivers to work on > newer arch cards. Once 9.0 driver was released... 7.5 run time worked > with 9.0 driver, but for some reason not 8.0. Seems CUDA and Nvidia > Runtime/Drivers have a dirty little secret much like Java and the runtimes. > > At this point I cannot get CMake 3.2 or 3.9 to work with CUDA 7.5/9.0, VS > 13, on Win10Pro/Enterprise. And from the state of doc it seems not worth > my effort to even try anymore. > Are NOT correct. The 7559 does work with CUDA 7.5 and runtime (all that is required is to wipe windows and start form scratch... no surprise there): C:\ProgramData\NVIDIA Corporation\CUDA Samples\v7.5\1_Utilities\deviceQuery\../../bin/win64/Debug/deviceQuery.exe Starting... CUDA Device Query (Runtime API) version (CUDART static linking) Detected 1 CUDA Capable device(s) Device 0: "GeForce GTX 960M" CUDA Driver Version / Runtime Version 7.5 / 7.5 CUDA Capability Major/Minor version number: 5.0 Total amount of global memory: 4096 MBytes (4294967296 bytes) ( 5) Multiprocessors, (128) CUDA Cores/MP: 640 CUDA Cores GPU Max Clock rate: 1176 MHz (1.18 GHz) Memory Clock rate: 2505 Mhz Memory Bus Width: 128-bit L2 Cache Size: 2097152 bytes Maximum Texture Dimension Size (x,y,z) 1D=(65536), 2D=(65536, 65536), 3D=(4096, 4096, 4096) Maximum Layered 1D Texture Size, (num) layers 1D=(16384), 2048 layers Maximum Layered 2D Texture Size, (num) layers 2D=(16384, 16384), 2048 layers Total amount of constant memory: 65536 bytes Total amount of shared memory per block: 49152 bytes Total number of registers available per block: 65536 Warp size: 32 Maximum number of threads per multiprocessor: 2048 Maximum number of threads per block: 1024 Max dimension size of a thread block (x,y,z): (1024, 1024, 64) Max dimension size of a grid size (x,y,z): (2147483647, 65535, 65535) Maximum memory pitch: 2147483647 bytes Texture alignment: 512 bytes Concurrent copy and kernel execution: Yes with 1 copy engine(s) Run time limit on kernels: Yes Integrated GPU sharing Host Memory: No Support host page-locked memory mapping: Yes Alignment requirement for Surfaces: Yes Device has ECC support: Disabled CUDA Device Driver Mode (TCC or WDDM): WDDM (Windows Display Driver Model) Device supports Unified Addressing (UVA): Yes Device PCI Domain ID / Bus ID / location ID: 0 / 2 / 0 Compute Mode: < Default (multiple host threads can use ::cudaSetDevice() with device simultaneously) > deviceQuery, CUDA Driver = CUDART, CUDA Driver Version = 7.5, CUDA Runtime Version = 7.5, NumDevs = 1, Device0 = GeForce GTX 960M Result = PASS I cannot however get a simple CUDA app to run that was generated with CMake 3.2 or 3.9. I can get it to compile, but I can't get it to run. Also previously CTest and some executables would just hang when run until I reinstalled Visual Studio 2013. This is what finally pushed me to wipe the machine. I cannot at this point explain what happened. I also cannot explain why after a clean wipe I still cannot get a ultra simple CUDA app compiled by CMake 3.2 or 3.9 to work on Windows 10 even though the SDK apps compile AND RUN now in 7.5/7.5 combo. Is there anyone out there that is able to get CMake to create a runnable CUDA executable that creates memory on the device to run on Win10 latest. Again SDK Apps compile and run but not CMake generated app.. App will compile and run, but is unable to communicate/create memory on the device. My app... as simple as I can make it is: #include "openglbasic.h" #include #include #include // includes cuda.h and cuda_runtime_api.h #include #include #ifdef USE_CUDA_OPTIMAL_DEVICE #include #include #endif #include #include int current = 0; int UniqueNumber() { return ++current; } int add(const float* A, const float* B, float* C); int main(int argc, char* argv[]){ int curr_cuda_device_id = 0; int cuda_device_id = 0; cuda_device_id = findCudaDevice(argc, (const char **)argv); // Need to initiialzie cuda and opengl interop here. checkCudaErrors(cudaGetDevice(&curr_cuda_device_id)); printf("Current device is [%d]\n", curr_cuda_device_id); checkCudaErrors(cudaSetDevice(cuda_device_id)); checkCudaErrors(cudaGLSetGLDevice(cuda_device_id)); printf("Current device is [%d]\n", curr_cuda_device_id); int x_dim = 256; int y_dim = 256; int z_dim = 196; float * d_volume; int size = x_dim * y_dim * z_dim * sizeof(float); //size = 5; checkCudaErrors(cudaMalloc((void **)&d_volume, size)); return 0; } Exits at: checkCudaErrors(cudaMalloc((void **)&d_volume, size)); In: check(): c:\ProgramData\NVIDIA Corporation\CUDA Samples\v7.5\common\inc\helper_cuda.h template< typename T > void check(T result, char const *const func, const char *const file, int const line) { if (result) { fprintf(stderr, "CUDA error at %s:%d code=%d(%s) \"%s\" \n", file, line, static_cast(result), _cudaGetErrorEnum(result), func); DEVICE_RESET // Make sure we call CUDA Device Reset before exiting exit(EXIT_FAILURE); } } With terminal output of: GPU Device 0: "GeForce GTX 960M" with compute capability 5.0 Current device is [0] Current device is [0] CUDA error at C:\projects\cmake\cmake_test\v3.2\cuda_basic\src\cuda_basic_test.cpp:67 code=46(cudaErrorDevicesUnavailable) "cudaMalloc((void **)&d_volume, size)" Is there something I am missing here. Above should work right? I am also told that CMake tests are successful on Win10. Do these test actually try and communicate with the device / create memory or are they written to just test compilation? Cuz that would certainly pass on my machine, but not actually work! As Stated by Robert Maynard "Unfortunately you are going to need to provide more information to help track down the issue. We currently have machines that verify 2015/8.0 and 2013/7.5 properly work ( https://open.cdash.org/index.php?project=CMake&filtercount=1&showfilters=1&field1=buildname&compare1=63&value1=CUDA " at http://cmake.3232098.n2.nabble.com/Visual-Studio-with-CUDA-does-not-work-in-3-9-td7595673.html Hmm curious the title there: "Visual-Studio-with-CUDA-does-not-work-in-3-9" How do I go about running that test on my machine? I started here: https://cmake.org/testing/ then on to: https://gitlab.kitware.com/cmake/cmake/blob/master/Help/dev/testing.rst that routed me to: https://gitlab.kitware.com/cmake/dashboard-scripts Where I read https://gitlab.kitware.com/cmake/dashboard-scripts/blob/master/cmake_common.cmake .... yeah ugh I know the internet is all about hyper links, but hyper use of hyper links? but anyway I do my own version of https://gitlab.kitware.com/cmake/cmake/blob/master/Help/dev/testing.rst (to relocate C:\projects\cmake_dev\Dashboards\CMakeScripts) $ mkdir -p ~/Dashboards $ cd ~/Dashboards $ git clone https://gitlab.kitware.com/cmake/dashboard-scripts.git CMakeScripts $ cd CMakeScripts So I create: C:\projects\cmake_dev\Dashboards\CMakeScripts\bjd_dashboard.cmake which reads (short version without comments) # Client maintainer: me at mydomain.net set(CTEST_SITE "bitbucket") set(CTEST_BUILD_NAME "Win10-Visual Studio 2013") set(CTEST_BUILD_CONFIGURATION Debug) set(CTEST_CMAKE_GENERATOR "Visual Studio 12 2013 Win64") #set( dashboard_model Experimental) set( dashboard_model Nightly) include(${CTEST_SCRIPT_DIRECTORY}/cmake_common.cmake) Question how do I configure this to run just 3.9 and CUDA tests? ... and preferably just the CUDA tests. Also during this I asked the CMake folk to create a kitware/ctest official docker image so I could just install it on my NAS.. but looks like I have to ansible it into existence. spectacularrrrg! -------------- next part -------------- An HTML attachment was scrubbed... URL: From Johannes.Sebastian.Mueller-Roemer at igd.fraunhofer.de Mon Aug 7 03:27:54 2017 From: Johannes.Sebastian.Mueller-Roemer at igd.fraunhofer.de (Mueller-Roemer, Johannes Sebastian) Date: Mon, 7 Aug 2017 07:27:54 +0000 Subject: [CMake] Yet another CMake 3.9 CUDA issue Message-ID: <8D981219EEA621479C112DA9BDC39A8E7096DE93@EXMBS1.ad.igd.fraunhofer.de> Hi, after solving a different issue (lack of .NET 3.5 Framework causing the CUDA MSBuild component to not work, discussion thread "Visual Studio with CUDA does not work in 3.9") and getting good results (parallel CUDA builds, yay!), I now wanted to try CMake 3.9 on a different machine, but no success :( The machine is running Windows Server 2012 R2 with Visual Studio 2015 (2012 is installed as well). The CUDA SDK is installed in versions 7.5 and 8.0. .Net 3.5 is installed as well. However, the following error is reported: CMake Error at E:/BuildTools/cmake/share/cmake-3.9/Modules/CMakeDetermineCompilerId.cmake:247 (message): No CUDA toolset found. Call Stack (most recent call first): E:/BuildTools/cmake/share/cmake-3.9/Modules/CMakeDetermineCompilerId.cmake:31 (CMAKE_DETERMINE_COMPILER_ID_BUILD) E:/BuildTools/cmake/share/cmake-3.9/Modules/CMakeDetermineCUDACompiler.cmake:73 (CMAKE_DETERMINE_COMPILER_ID) CMakeLists.txt:2 (project) -- Configuring incomplete, errors occurred! See also "C:/Users/buildbot/Desktop/test/build/CMakeFiles/CMakeOutput.log". The CMakeOutput.log is also not very informative and only contains: The system is: Windows - 6.3.9600 - AMD64 Regards Johannes Mueller-Roemer Fraunhofer-Institut f?r Graphische Datenverarbeitung IGD Fraunhoferstr. 5 | 64283 Darmstadt | Germany Tel +49 6151 155-606 | Fax +49 6151 155-139 johannes.mueller-roemer at igd.fraunhofer.de | www.igd.fraunhofer.de -------------- next part -------------- An HTML attachment was scrubbed... URL: From lectem at gmail.com Mon Aug 7 05:57:49 2017 From: lectem at gmail.com (=?UTF-8?Q?Cl=C3=A9ment_Gregoire?=) Date: Mon, 7 Aug 2017 11:57:49 +0200 Subject: [CMake] Coverage support Message-ID: Hi, I'm a bit stuck when trying to add coverage reports to Cmake (gcov + lcov) as I can't figure out what is the best (idiomatic) way to do it. So far here are the ways I know of : - setting the CMAKE_LANG_FLAGS based on a boolean + scan all files / run gcov on it : would like to avoid this - same but adding a new build type : seems to be way better but running gcov would still be a pain - same with a tool chain file for the flags : doesn't sound a good idea since coverage should only be ran in debug - some library to link with that propagates the flags : not possible because link flags are not transient - macro that adds the flags / does magic on a per target basis : many scripts do this but seems to be a pain to maintain. Also I would rather have all my test targets be set up automatically - any of the above for flags and Ctest ctest_coverage but all I need are the gcov/lcov reports, not the coverage.xml for the dashboard - using the command parameter of add_test - something I missed? I want the setup to be easy and compatible with codecov.io, sadly all the script I found are bad, undocumented, or old and using bad practices. Any help is welcome! Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From eike at sf-mail.de Mon Aug 7 06:49:48 2017 From: eike at sf-mail.de (Rolf Eike Beer) Date: Mon, 07 Aug 2017 10:49:48 +0000 Subject: [CMake] Coverage support In-Reply-To: References: Message-ID: <830e6f57fc2ac7c49c5180f96f99468d@sf-mail.de> Am 2017-08-07 09:57, schrieb Cl?ment Gregoire: > Hi, > I'm a bit stuck when trying to add coverage reports to Cmake (gcov + > lcov) > as I can't figure out what is the best (idiomatic) way to do it. > So far here are the ways I know of : > - setting the CMAKE_LANG_FLAGS based on a boolean + scan all files / > run > gcov on it : would like to avoid this > - same but adding a new build type : seems to be way better but running > gcov would still be a pain > - same with a tool chain file for the flags : doesn't sound a good idea > since coverage should only be ran in debug > - some library to link with that propagates the flags : not possible > because link flags are not transient > - macro that adds the flags / does magic on a per target basis : many > scripts do this but seems to be a pain to maintain. Also I would rather > have all my test targets be set up automatically > - any of the above for flags and Ctest ctest_coverage but all I need > are > the gcov/lcov reports, not the coverage.xml for the dashboard > - using the command parameter of add_test > - something I missed? > > I want the setup to be easy and compatible with codecov.io, sadly all > the > script I found are bad, undocumented, or old and using bad practices. What's wrong with this one: https://github.com/codecov/example-cpp11-cmake ? I use it for both Codecov.io and CDash at the same time, see https://github.com/osm2go/osm2go/blob/master/.travis.yml Eike From lectem at gmail.com Mon Aug 7 07:06:08 2017 From: lectem at gmail.com (=?UTF-8?Q?Cl=C3=A9ment_Gregoire?=) Date: Mon, 07 Aug 2017 11:06:08 +0000 Subject: [CMake] Coverage support In-Reply-To: <830e6f57fc2ac7c49c5180f96f99468d@sf-mail.de> References: <830e6f57fc2ac7c49c5180f96f99468d@sf-mail.de> Message-ID: I usually stop reading Cmakelists.txt as soon as I see this set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wall -pedantic -pthread -g -O0 -fprofile-arcs -ftest-coverage") Also you need to use the SETUP_TARGET_FOR_COVERAGE for every single test target, which seems to be a difficult to scale on big projects Le lun. 7 ao?t 2017 ? 12:50, Rolf Eike Beer a ?crit : > Am 2017-08-07 09:57, schrieb Cl?ment Gregoire: > > Hi, > > I'm a bit stuck when trying to add coverage reports to Cmake (gcov + > > lcov) > > as I can't figure out what is the best (idiomatic) way to do it. > > So far here are the ways I know of : > > - setting the CMAKE_LANG_FLAGS based on a boolean + scan all files / > > run > > gcov on it : would like to avoid this > > - same but adding a new build type : seems to be way better but running > > gcov would still be a pain > > - same with a tool chain file for the flags : doesn't sound a good idea > > since coverage should only be ran in debug > > - some library to link with that propagates the flags : not possible > > because link flags are not transient > > - macro that adds the flags / does magic on a per target basis : many > > scripts do this but seems to be a pain to maintain. Also I would rather > > have all my test targets be set up automatically > > - any of the above for flags and Ctest ctest_coverage but all I need > > are > > the gcov/lcov reports, not the coverage.xml for the dashboard > > - using the command parameter of add_test > > - something I missed? > > > > I want the setup to be easy and compatible with codecov.io, sadly all > > the > > script I found are bad, undocumented, or old and using bad practices. > > What's wrong with this one: > https://github.com/codecov/example-cpp11-cmake ? > > I use it for both Codecov.io and CDash at the same time, see > https://github.com/osm2go/osm2go/blob/master/.travis.yml > > Eike > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake -------------- next part -------------- An HTML attachment was scrubbed... URL: From bjorn.blissing at vti.se Mon Aug 7 07:35:47 2017 From: bjorn.blissing at vti.se (=?iso-8859-1?Q?Bj=F6rn_Blissing?=) Date: Mon, 7 Aug 2017 11:35:47 +0000 Subject: [CMake] Advice on converting legacy project to modern CMake Message-ID: Hi, I have some legacy projects which I intend to update to modern CMake. The documentation is good but do not really cover "best practices". So I have some questions which I hope some of you could help to answer: 1. Which version if CMake should I target? I.e. Which version should I require in my cmake_minimum_required() statement? 2. What are some best practices when choosing a namespace for my library export? For example, lets say that I have a library which handles interfacing with a piece of fictional hardware, lets call this hardware "Anvil". My library and project is then aptly named "Anvil". But what to name the namespace? 3. Some of my legacy projects have all source in the same directory, i.e. both source and header files are in the same directory. Others have both private and public headers in the same directory. How do I handle this with target_include_directories()? Preferably I would like to avoid reorganizing the file structure. Regards Bj?rn -------------- next part -------------- An HTML attachment was scrubbed... URL: From eike at sf-mail.de Mon Aug 7 07:37:33 2017 From: eike at sf-mail.de (Rolf Eike Beer) Date: Mon, 07 Aug 2017 11:37:33 +0000 Subject: [CMake] Coverage support In-Reply-To: References: <830e6f57fc2ac7c49c5180f96f99468d@sf-mail.de> Message-ID: Am 2017-08-07 11:06, schrieb Cl?ment Gregoire: > I usually stop reading Cmakelists.txt as soon as I see this > > set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wall -pedantic -pthread -g -O0 > -fprofile-arcs -ftest-coverage") The pthread thing there is likely wrong anyway, and the -Wall is entirely optional. The other things are needed, otherwise gcov will not produce any useful output. > Also you need to use the SETUP_TARGET_FOR_COVERAGE for every single > test > target, which seems to be a difficult to scale on big projects No, you don't. It's entirely fine if you just run "make test" as I do in OSM2go. Eike From eike at sf-mail.de Mon Aug 7 07:44:30 2017 From: eike at sf-mail.de (Rolf Eike Beer) Date: Mon, 07 Aug 2017 11:44:30 +0000 Subject: [CMake] Advice on converting legacy project to modern CMake In-Reply-To: References: Message-ID: Am 2017-08-07 11:35, schrieb Bj?rn Blissing: > Hi, > > I have some legacy projects which I intend to update to modern CMake. > The documentation is good but do not really cover "best practices". So > I have some questions which I hope some of you could help to answer: > > 1. Which version if CMake should I target? I.e. Which version should I > require in my cmake_minimum_required() statement? If you want to have support for compile feature (i.e. automatically selecting C++11 if needed), then you should use at least 3.1. I personally don't see a reason to start lower anyway, if someone wants to build your new software, getting a new CMake shouldn't a problem anyway. > 3. Some of my legacy projects have all source in the same directory, > i.e. both source and header files are in the same directory. Others > have both private and public headers in the same directory. How do I > handle this with target_include_directories()? Preferably I would like > to avoid reorganizing the file structure. If things are in the same directory you don't need target_include_directories(), as the header files will be found anyway if you use "" (probably also <>). If they are in a different directory it doesn't matter if the private and public things are mixed, you need to add that directory anyway. Greetings, Eike -- From eike at sf-mail.de Mon Aug 7 08:05:42 2017 From: eike at sf-mail.de (Rolf Eike Beer) Date: Mon, 07 Aug 2017 12:05:42 +0000 Subject: [CMake] Advice on converting legacy project to modern CMake In-Reply-To: References: Message-ID: <4c8868260351d0eddfa801ba9a46b40a@sf-mail.de> Am 2017-08-07 11:57, schrieb Bj?rn Blissing: > Hi Eike, > >>> 3. Some of my legacy projects have all source in the same directory, >>> i.e. both source and header files are in the same directory. Others >>> have both private and public headers in the same directory. How do I >>> handle this with target_include_directories()? Preferably I would >>> like >>> to avoid reorganizing the file structure. >> >> If things are in the same directory you don't need >> target_include_directories(), as the header files will be found anyway >> if you use "" (probably also <>). If they are in a different directory >> it doesn't matter if the private and public things are mixed, you need >> to add that directory anyway. > > Lets see if I understood what you are suggesting correctly: > > Alternative 1: If both source and headers are in the same directory. > =========== > Solution: Omit the target_include_directories() statement completely > and just add the private and public header files in the add_library() > statement and the public headers in the install(FILES ...) statement. > > > Alternative 2: If source and headers are separated but both private > and public headers are included in the same directory. > =========== > Solution: Add the private and public header files in the add_library() > statement . Then add a target_include_directories() statement such as: > target_include_directories(anvil_lib PUBLIC > $ > $ > ) > > Then add the public headers in the install(FILES ...) statement. Yes. > Is this correct? Follow up question: Since the directory include > contains both public and private headers should the > target_include_directories() be specified as PUBLIC or PRIVATE? I would make it public: less code, and the private headers will simply not exist when installed. Eike From steffen.dettmer at gmail.com Mon Aug 7 08:49:50 2017 From: steffen.dettmer at gmail.com (Steffen Dettmer) Date: Mon, 7 Aug 2017 14:49:50 +0200 Subject: [CMake] with cmake-3.9 my testprj breaks, I need to add "add_executable(Qt4::rcc IMPORTED)" Message-ID: Hi, I have a cmake test project that builds a "hello world" with our cross toolchain. There are selfmade TOOLCHAINFILES for the targets. They define QT variables like: set(BT_QT_4_7_3_PATH .../taget/Qt-4.7.3) set(QT_BINARY_DIR ${BT_QT_4_7_3_PATH}/bin) set(QT_LIBRARY_DIR ${BT_QT_4_7_3_PATH}/lib) set(QT_MOC_EXECUTABLE ${QT_BINARY_DIR}/moc) and so on. I tested a fix for [1] with master branch and then also v3.9.0, but my project suddenly gets errors: $ git clone $r/helloworld && cd helloworld && mkdir target4 && cd target4 && /local/users/sdettmer/work/cmake/b/bin/cmake \ -DCMAKE_TOOLCHAIN_FILE=$TC/$TARGET.cmake .. -- The C compiler identification is GNU 4.4.3 [...normal output...] -- Configuring done CMake Error: Qt4::rcc target not found hello_world CMake Error: Qt4::rcc target not found mylib1 CMake Error: Qt4::rcc target not found mylib2 -- Generating done -- Build files have been written to: /local/sdettmer/work/helloworld/target4 The "CMake Error:" lines are new. Please note, that I don't use QT rcc at all. I noticed that I can work around this by adding: set(QT_RCC_EXECUTABLE ${QT_BINARY_DIR}/rcc) if (NOT TARGET Qt4::rcc) add_executable(Qt4::rcc IMPORTED) endif() to my TOOLCHAINFILE, but I don't understand why. moc, for example, needs no such thing, but rcc does, but this one is not even used. The message seems to come from C++ part, could it be that some QT depenency slipped into the cmake (C++) code by accident? Also after the error it tells "Generating done". Does this mean the error actually is a warning I could ignore? Steffen [1] https://gitlab.kitware.com/cmake/cmake/issues/16920 From jhykes at gmail.com Mon Aug 7 09:00:39 2017 From: jhykes at gmail.com (Josh Hykes) Date: Mon, 07 Aug 2017 13:00:39 +0000 Subject: [CMake] nagfor, Ninja, and Missing variable is: CMAKE_Fortran_PREPROCESS_SOURCE Message-ID: Hello, I was trying to build my Fortran project with nagfor using the Ninja generator. I ran into the below error. I am using cmake version 3.9.0. I found a discussion of a similar error at http://public.kitware.com/pipermail/cmake/2016-December/064710.html If I add the following line for the NAG compiler, then the error goes away: set(CMAKE_Fortran_PREPROCESS_SOURCE " -fpp -F -o ") I thought I should mention this in case you wanted to add it to CMake. -Josh $ cmake ../test -GNinja -DCMAKE_BUILD_TYPE=DEBUG -DCMAKE_Fortran_COMPILER=nagfor -- The C compiler identification is GNU 4.5.1 -- The CXX compiler identification is GNU 4.5.1 -- Check for working C compiler: /usr/bin/cc -- Check for working C compiler: /usr/bin/cc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Detecting C compile features -- Detecting C compile features - done -- Check for working CXX compiler: /usr/bin/c++ -- Check for working CXX compiler: /usr/bin/c++ -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Detecting CXX compile features -- Detecting CXX compile features - done -- The Fortran compiler identification is NAG 6.1.6120 -- Detecting NAG Fortran directory -- Detecting NAG Fortran directory - /home/joshua/opt/nag/nagfor_6120/lib/NAG_Fortran -- Check for working Fortran compiler: /home/joshua/opt/nag/nagfor_6120/bin/nagfor CMake Error: Error required internal CMake variable not set, cmake may not be built correctly. Missing variable is: CMAKE_Fortran_PREPROCESS_SOURCE CMake Error at /home/joshua/opt/cmake/cmake-3.9.0-Linux-x86_64/share/cmake-3.9/Modules/CMakeTestFortranCompiler.cmake:30 (try_compile): Failed to generate test project build system. Call Stack (most recent call first): CMakeLists.txt:5 (enable_language) -- Configuring incomplete, errors occurred! -------------- next part -------------- An HTML attachment was scrubbed... URL: From steffen.dettmer at gmail.com Mon Aug 7 09:01:16 2017 From: steffen.dettmer at gmail.com (Steffen Dettmer) Date: Mon, 7 Aug 2017 15:01:16 +0200 Subject: [CMake] with 3.9 my testprj breaks: mylib_autogen/include: No such file or directory Message-ID: Hi, I made a fix for [1] and tested cmake master branch, but noticed that this cmake version does not compile my test project anymore (v.3.8.2: OK; v3.9.0: FAIL). There is an include path to $buildir/$subproject/mylib_autogen/include as -I for g++, but this directory does not exist and I get: cc1plus: error [...] No such file or directory. If I manually create this include directory it compiles. I guess it could be that the "mylib_autogen" directory (which is created automatically) and its subdirectory "include" (which, at least in my case, it not created automatically) are some new feature. I guess, the *.moc files were moved into the autogen diretories. In the autogen directory, I have only one file "mocs_compilation.cpp" with the soley contents: /* This file is autogenerated, do not edit*/ enum some_compilers { need_more_than_nothing }; which looks like a kind of dummy (it could be that this test lib does not need any moc compilation). We are using QT as described in [2]. Could it a bug that this include directory is not created in the special case it is empty? How to upgrade such projects to be compatible with cmake-3.9? Steffen [1] https://gitlab.kitware.com/cmake/cmake/issues/16920 [2] https://stackoverflow.com/questions/36570791/how-can-i-use-cmakes-automoc-feature-with-a-custom-qt-package From steffen.dettmer at gmail.com Mon Aug 7 09:15:51 2017 From: steffen.dettmer at gmail.com (Steffen Dettmer) Date: Mon, 7 Aug 2017 15:15:51 +0200 Subject: [CMake] HOWTO cmake compatiblity? Message-ID: Hi, I like to learn how you use cmake in environments were reproducibility is an issue. Background: We are used to simply install cmake in default $PATH, but I noticed cmake is not backward-compatible. Of course this is not surprising, it is really complex with many nice features and of course things evolve, so this is fine. As we are supposed to be reproducible (i.e. reproduce old versions in future), we need a way to maintain compatiblity. So far we use defined virtual machines, which have to be archived by each change, and inside install our compiler toolchains in versionized directories. So far this was simple because we just put the needed paths into the TOOLCHAINFILE.cmake files (cmake -DTOOLCHAIN=v1.0.0/target1.cmake -- which internally sets CC to v1.0.0/gcc-1.2.3/bin/a-b-c-gcc etc). This only works if the correct cmake version is called of course. To avoid depending on users PATH (we made bad experiences in the past with that), we like to have a dedicated way to call cmake. First thoughs: So far I think we need to install cmake into a versionized directory and invoke it: v1.0.0/bin/cmake -DTOOLCHAIN=v1.0.0/target1.cmake and maybe remove cmake from PATH to ensure a failure if accidentally calling "cmake". What do you think? >From autotools I know that via alternatives there are things like "autoconf-1.4" pointing to the appropriate autoconf version. This seems to be more comfortable to use. Is something like this possible with cmake? At least we could install cmake in a versionized directory and add an appropriate symbolic link into $PATH. What do you think? cmake internally has mechanisms to find the correct "Modules" etc, so multiple versions can be installed at the same time easily. Is there some standard way to select between these multiple versions? Any thoughts appreciated, Steffen From eike at sf-mail.de Mon Aug 7 09:44:18 2017 From: eike at sf-mail.de (Rolf Eike Beer) Date: Mon, 07 Aug 2017 13:44:18 +0000 Subject: [CMake] HOWTO cmake compatiblity? In-Reply-To: References: Message-ID: <7a4b678d2494f4b2ecc223d5f97725e1@sf-mail.de> Steffen Dettmer wrote: [?] > So far I think we need to install cmake into a versionized > directory and invoke it: > > v1.0.0/bin/cmake -DTOOLCHAIN=v1.0.0/target1.cmake > > and maybe remove cmake from PATH to ensure a failure if > accidentally calling "cmake". > > What do you think? Having multiple parallel versions of CMake in different directories works. Greetings, Eike -- From lectem at gmail.com Mon Aug 7 10:24:16 2017 From: lectem at gmail.com (=?UTF-8?Q?Cl=C3=A9ment_Gregoire?=) Date: Mon, 7 Aug 2017 16:24:16 +0200 Subject: [CMake] Coverage support In-Reply-To: References: <830e6f57fc2ac7c49c5180f96f99468d@sf-mail.de> Message-ID: > > I usually stop reading Cmakelists.txt as soon as I see this > > > > set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wall -pedantic -pthread -g -O0 > > > -fprofile-arcs -ftest-coverage") > > > > The pthread thing there is likely wrong anyway, and the -Wall is entirely > optional. The other things are needed, otherwise gcov will not produce any > useful output. > I don't have an issue with the flags per se, but with the usage of set(CMAKE_CXX_FLAGS). Setting flags like that should be banned from modern cmake scripts. Also you need to use the SETUP_TARGET_FOR_COVERAGE for every single test > > > target, which seems to be a difficult to scale on big projects > > > > No, you don't. It's entirely fine if you just run "make test" as I do in > OSM2go. > >From what I saw in the documentation of the script : # Param _testrunner The name of the target which runs the tests It seems to call directly the command named _testrunner, which is somehow confirmed from the cmakelists : # src/CMakelists.txt add_executable(tests ${TEST_FILES}) # Linking up all libraries target_link_libraries(tests complex) add_test(NAME example_test COMMAND tests) # CMakelists.txt setup_target_for_coverage(${PROJECT_NAME}_coverage tests coverage) >From this I deduce that you need to call setup_target_for_coverage for each different test executable. 2017-08-07 13:37 GMT+02:00 Rolf Eike Beer : > Am 2017-08-07 11:06, schrieb Cl?ment Gregoire: > >> I usually stop reading Cmakelists.txt as soon as I see this >> >> set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wall -pedantic -pthread -g -O0 >> -fprofile-arcs -ftest-coverage") >> > > The pthread thing there is likely wrong anyway, and the -Wall is entirely > optional. The other things are needed, otherwise gcov will not produce any > useful output. > > Also you need to use the SETUP_TARGET_FOR_COVERAGE for every single test >> target, which seems to be a difficult to scale on big projects >> > > No, you don't. It's entirely fine if you just run "make test" as I do in > OSM2go. > > > Eike > -- > > 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/opensou > rce/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake > -------------- next part -------------- An HTML attachment was scrubbed... URL: From steffen.dettmer at gmail.com Mon Aug 7 10:49:10 2017 From: steffen.dettmer at gmail.com (Steffen Dettmer) Date: Mon, 7 Aug 2017 16:49:10 +0200 Subject: [CMake] HOWTO cmake compatiblity? In-Reply-To: <7a4b678d2494f4b2ecc223d5f97725e1@sf-mail.de> References: <7a4b678d2494f4b2ecc223d5f97725e1@sf-mail.de> Message-ID: On Mon, Aug 7, 2017 at 3:44 PM, Rolf Eike Beer wrote: > Steffen Dettmer wrote: >> So far I think we need to install cmake into a versionized >> directory and invoke it: >> >> v1.0.0/bin/cmake -DTOOLCHAIN=v1.0.0/target1.cmake >> >> and maybe remove cmake from PATH to ensure a failure if >> accidentally calling "cmake". >> >> What do you think? > > Having multiple parallel versions of CMake in different directories works. Yes, it definetly works, I tested with 3.0.2 and 3.6.2. My question is how it is intended to be used, what works best. Steffen From annulen at yandex.ru Mon Aug 7 11:22:46 2017 From: annulen at yandex.ru (Konstantin Tokarev) Date: Mon, 07 Aug 2017 18:22:46 +0300 Subject: [CMake] Coverage support In-Reply-To: References: <830e6f57fc2ac7c49c5180f96f99468d@sf-mail.de> Message-ID: <921131502119366@web44g.yandex.ru> 07.08.2017, 17:24, "Cl?ment Gregoire" : >> I usually stop reading Cmakelists.txt as soon as I see this >> >> set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wall -pedantic -pthread -g -O0 >> -fprofile-arcs -ftest-coverage") >> >> The pthread thing there is likely wrong anyway, and the -Wall is entirely optional. The other things are needed, otherwise gcov will not produce any useful output. > > I don't have an issue with the flags per se, but with the usage of set(CMAKE_CXX_FLAGS). Setting flags like that should be banned from modern cmake scripts. How can one set global compiler flags without use of CMAKE_CXX_FLAGS or setting flags for each individual target? > >> Also you need to use the SETUP_TARGET_FOR_COVERAGE for every single test >> target, which seems to be a difficult to scale on big projects >> >> No, you don't. It's entirely fine if you just run "make test" as I do in OSM2go. > From what I saw in the documentation of the script : > >> # Param _testrunner The name of the target which runs the tests > > It seems to call directly the command named _testrunner, which is somehow confirmed from the cmakelists : > >> # src/CMakelists.txt >> add_executable(tests ${TEST_FILES}) >> >> # Linking up all libraries >> >> target_link_libraries(tests complex) >> >> add_test(NAME example_test COMMAND tests) >> # CMakelists.txt >> setup_target_for_coverage(${PROJECT_NAME}_coverage tests coverage) > From this I deduce that you need to call setup_target_for_coverage for each different test executable. > > 2017-08-07 13:37 GMT+02:00 Rolf Eike Beer : >> Am 2017-08-07 11:06, schrieb Cl?ment Gregoire: >> I usually stop reading Cmakelists.txt as soon as I see this >> >> set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wall -pedantic -pthread -g -O0 >> -fprofile-arcs -ftest-coverage") >> >> The pthread thing there is likely wrong anyway, and the -Wall is entirely optional. The other things are needed, otherwise gcov will not produce any useful output. >> >> Also you need to use the SETUP_TARGET_FOR_COVERAGE for every single test >> target, which seems to be a difficult to scale on big projects >> >> No, you don't. It's entirely fine if you just run "make test" as I do in OSM2go. >> >> Eike >> -- >> >> Powered by www.kitware.com >> >> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ >> >> Kitware offers various services to support the CMake community. For more information on each offering, please visit: >> >> CMake Support: http://cmake.org/cmake/help/support.html >> CMake Consulting: http://cmake.org/cmake/help/consulting.html >> CMake Training Courses: http://cmake.org/cmake/help/training.html >> >> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/cmake > ,-- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake --? Regards, Konstantin From robert.maynard at kitware.com Mon Aug 7 12:55:45 2017 From: robert.maynard at kitware.com (Robert Maynard) Date: Mon, 7 Aug 2017 12:55:45 -0400 Subject: [CMake] CMake CUDA 3.8+/9 support as a first class language with out Visual Studio Support... err what? In-Reply-To: References: <7ca86101-dfe0-957f-182f-cde17d4f83c4@wisc.edu> <150725ad-ac46-b99e-8fa1-e86bf8ee9175@gmail.com> Message-ID: It is great to hear that you have been able to resolve the compilation issues with CMake, though it is very weird and worry some that only formatting your machine would resolve the issue. 1) The error code you are getting (46-cudaErrorDevicesUnavailable ) generally means that another CUDA program is running and is either holding an exclusive lock on the GPU or maybe the GPU is configured to only run OpenGL or CUDA, and not both at the same time. My instinct is to run 'c:\Program Files\NVIDIA Corporation\NVSMI>nvidia-smi -q' and see if anything is using the GPU, but I don't remember if that ability is offered only for Quadro/Tesla cards. 2) To setup and run the CMake CUDA tests you are missing 2 lines, which are: set(ENV{PATH} "$ENV{PATH};C:/Program Files/NVIDIA GPU Computing Toolkit/CUDA/v7.5/bin") set(dashboard_cache "CMake_TEST_CUDA:BOOL=ON") These lines should be placed before the `include(${CTEST_SCRIPT_DIRECTORY}/cmake_common.cmake)`. For reference see: https://open.cdash.org/viewNotes.php?buildid=5008534 Now to run the dashboard you would do something like the following. This will build cmake, all the cmake tests, and upload the results: ctest -S C:\projects\cmake_dev\Dashboards\CMakeScripts\bjd_dashboard.cmake -VV On Sun, Aug 6, 2017 at 2:37 PM, Brian Davis wrote: > > Upon: > > wiping Dell 7559 (yes the weirdness has gotten this bad), reinstalling from > Dell Factory image > upgrading system to Latest Win 10 (now not in developer mode anymore) > Dell update to get latest drivers and other goobly bits > Removing all Virus Scanners to keep this from possibly interfering > Installing Visual Studio 2013 Community > Installing CUDA 7.5 and packaged driver > Imagining with Clonezilla for posterity sake in case... uhhh... when windows > acts up again. > > These statements: > >> >> Regarding 960M and CUDA 7.5/7.5, 8.0/7.5, and 7.7/9.0 >> >> Answer is: >> >> 960M was likely released post CUDA 7.5 driver and possibly post 8.0. >> Seems that architecture differences do not allow old drivers to work on >> newer arch cards. Once 9.0 driver was released... 7.5 run time worked with >> 9.0 driver, but for some reason not 8.0. Seems CUDA and Nvidia >> Runtime/Drivers have a dirty little secret much like Java and the runtimes. >> >> At this point I cannot get CMake 3.2 or 3.9 to work with CUDA 7.5/9.0, VS >> 13, on Win10Pro/Enterprise. And from the state of doc it seems not worth my >> effort to even try anymore. > > > Are NOT correct. The 7559 does work with CUDA 7.5 and runtime (all that is > required is to wipe windows and start form scratch... no surprise there): > > C:\ProgramData\NVIDIA Corporation\CUDA > Samples\v7.5\1_Utilities\deviceQuery\../../bin/win64/Debug/deviceQuery.exe > Starting... > > > CUDA Device Query (Runtime API) version (CUDART static linking) > > Detected 1 CUDA Capable device(s) > > Device 0: "GeForce GTX 960M" > CUDA Driver Version / Runtime Version 7.5 / 7.5 > CUDA Capability Major/Minor version number: 5.0 > Total amount of global memory: 4096 MBytes (4294967296 > bytes) > ( 5) Multiprocessors, (128) CUDA Cores/MP: 640 CUDA Cores > GPU Max Clock rate: 1176 MHz (1.18 GHz) > Memory Clock rate: 2505 Mhz > Memory Bus Width: 128-bit > L2 Cache Size: 2097152 bytes > Maximum Texture Dimension Size (x,y,z) 1D=(65536), 2D=(65536, > 65536), 3D=(4096, 4096, 4096) > Maximum Layered 1D Texture Size, (num) layers 1D=(16384), 2048 layers > Maximum Layered 2D Texture Size, (num) layers 2D=(16384, 16384), 2048 > layers > Total amount of constant memory: 65536 bytes > Total amount of shared memory per block: 49152 bytes > Total number of registers available per block: 65536 > Warp size: 32 > Maximum number of threads per multiprocessor: 2048 > Maximum number of threads per block: 1024 > Max dimension size of a thread block (x,y,z): (1024, 1024, 64) > Max dimension size of a grid size (x,y,z): (2147483647, 65535, 65535) > Maximum memory pitch: 2147483647 bytes > Texture alignment: 512 bytes > Concurrent copy and kernel execution: Yes with 1 copy engine(s) > Run time limit on kernels: Yes > Integrated GPU sharing Host Memory: No > Support host page-locked memory mapping: Yes > Alignment requirement for Surfaces: Yes > Device has ECC support: Disabled > CUDA Device Driver Mode (TCC or WDDM): WDDM (Windows Display > Driver Model) > Device supports Unified Addressing (UVA): Yes > Device PCI Domain ID / Bus ID / location ID: 0 / 2 / 0 > Compute Mode: > < Default (multiple host threads can use ::cudaSetDevice() with device > simultaneously) > > > deviceQuery, CUDA Driver = CUDART, CUDA Driver Version = 7.5, CUDA Runtime > Version = 7.5, NumDevs = 1, Device0 = GeForce GTX 960M > Result = PASS > > > I cannot however get a simple CUDA app to run that was generated with CMake > 3.2 or 3.9. I can get it to compile, but I can't get it to run. Also > previously CTest and some executables would just hang when run until I > reinstalled Visual Studio 2013. This is what finally pushed me to wipe the > machine. > > I cannot at this point explain what happened. I also cannot explain why > after a clean wipe I still cannot get a ultra simple CUDA app compiled by > CMake 3.2 or 3.9 to work on Windows 10 even though the SDK apps compile AND > RUN now in 7.5/7.5 combo. > > Is there anyone out there that is able to get CMake to create a runnable > CUDA executable that creates memory on the device to run on Win10 latest. > Again SDK Apps compile and run but not CMake generated app.. App will > compile and run, but is unable to communicate/create memory on the device. > > My app... as simple as I can make it is: > > #include "openglbasic.h" > > #include > #include > > #include // includes cuda.h and cuda_runtime_api.h > #include > #include > > #ifdef USE_CUDA_OPTIMAL_DEVICE > #include > #include > #endif > > > #include > #include > > int current = 0; > int UniqueNumber() { return ++current; } > > int add(const float* A, const float* B, float* C); > > int main(int argc, char* argv[]){ > > int curr_cuda_device_id = 0; > > int cuda_device_id = 0; > > > cuda_device_id = findCudaDevice(argc, (const char **)argv); > > > // Need to initiialzie cuda and opengl interop here. > checkCudaErrors(cudaGetDevice(&curr_cuda_device_id)); > printf("Current device is [%d]\n", curr_cuda_device_id); > checkCudaErrors(cudaSetDevice(cuda_device_id)); > checkCudaErrors(cudaGLSetGLDevice(cuda_device_id)); > printf("Current device is [%d]\n", curr_cuda_device_id); > > > int x_dim = 256; > int y_dim = 256; > int z_dim = 196; > float * d_volume; > int size = x_dim * y_dim * z_dim * sizeof(float); > //size = 5; > checkCudaErrors(cudaMalloc((void **)&d_volume, size)); > > return 0; > > } > > Exits at: > > checkCudaErrors(cudaMalloc((void **)&d_volume, size)); > > > In: check(): > > c:\ProgramData\NVIDIA Corporation\CUDA Samples\v7.5\common\inc\helper_cuda.h > > template< typename T > > void check(T result, char const *const func, const char *const file, int > const line) > { > if (result) > { > fprintf(stderr, "CUDA error at %s:%d code=%d(%s) \"%s\" \n", > file, line, static_cast(result), > _cudaGetErrorEnum(result), func); > DEVICE_RESET > // Make sure we call CUDA Device Reset before exiting > exit(EXIT_FAILURE); > } > } > > > With terminal output of: > > GPU Device 0: "GeForce GTX 960M" with compute capability 5.0 > > Current device is [0] > Current device is [0] > CUDA error at > C:\projects\cmake\cmake_test\v3.2\cuda_basic\src\cuda_basic_test.cpp:67 > code=46(cudaErrorDevicesUnavailable) "cudaMalloc((void **)&d_volume, size)" > > > Is there something I am missing here. Above should work right? > > I am also told that CMake tests are successful on Win10. Do these test > actually try and communicate with the device / create memory or are they > written to just test compilation? Cuz that would certainly pass on my > machine, but not actually work! > > As Stated by Robert Maynard > "Unfortunately you are going to need to provide more information to help > track down the issue. We currently have machines that verify > 2015/8.0 and 2013/7.5 properly work ( > https://open.cdash.org/index.php?project=CMake&filtercount=1&showfilters=1&field1=buildname&compare1=63&value1=CUDA" > > at > http://cmake.3232098.n2.nabble.com/Visual-Studio-with-CUDA-does-not-work-in-3-9-td7595673.html > > Hmm curious the title there: "Visual-Studio-with-CUDA-does-not-work-in-3-9" > > How do I go about running that test on my machine? > > I started here: > > https://cmake.org/testing/ > > then on to: > > https://gitlab.kitware.com/cmake/cmake/blob/master/Help/dev/testing.rst > > that routed me to: > > https://gitlab.kitware.com/cmake/dashboard-scripts > > Where I read > > https://gitlab.kitware.com/cmake/dashboard-scripts/blob/master/cmake_common.cmake > > .... yeah ugh I know the internet is all about hyper links, but hyper use of > hyper links? > > but anyway I do my own version of > https://gitlab.kitware.com/cmake/cmake/blob/master/Help/dev/testing.rst (to > relocate C:\projects\cmake_dev\Dashboards\CMakeScripts) > > $ mkdir -p ~/Dashboards > $ cd ~/Dashboards > $ git clone https://gitlab.kitware.com/cmake/dashboard-scripts.git > CMakeScripts > $ cd CMakeScripts > > So I create: > > > C:\projects\cmake_dev\Dashboards\CMakeScripts\bjd_dashboard.cmake > > which reads (short version without comments) > > # Client maintainer: me at mydomain.net > set(CTEST_SITE "bitbucket") > set(CTEST_BUILD_NAME "Win10-Visual Studio 2013") > set(CTEST_BUILD_CONFIGURATION Debug) > set(CTEST_CMAKE_GENERATOR "Visual Studio 12 2013 Win64") > > #set( dashboard_model Experimental) > set( dashboard_model Nightly) > > include(${CTEST_SCRIPT_DIRECTORY}/cmake_common.cmake) > > > Question how do I configure this to run just 3.9 and CUDA tests? ... and > preferably just the CUDA tests. > > Also during this I asked the CMake folk to create a kitware/ctest official > docker image so I could just install it on my NAS.. but looks like I have to > ansible it into existence. spectacularrrrg! > > > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake From lectem at gmail.com Mon Aug 7 13:50:20 2017 From: lectem at gmail.com (=?UTF-8?Q?Cl=C3=A9ment_Gregoire?=) Date: Mon, 07 Aug 2017 17:50:20 +0000 Subject: [CMake] Coverage support In-Reply-To: <921131502119366@web44g.yandex.ru> References: <830e6f57fc2ac7c49c5180f96f99468d@sf-mail.de> <921131502119366@web44g.yandex.ru> Message-ID: This is mainly why I started this thread, I want to know the best way to do this without using those variables. CMAKE_lang_FLAGS is a pain as soon as someone wants to use add_subdirectory (be it to add an external project or your project being used in another) or a user wants to change the value. Those variables should really only be set by the toolchain file or from the command-line. Other solutions were mentioned in my first mail, the easiest one being to add a new build type. The other option is to uses something like a special script that will set those variables before your Cmakelists.txt (ie a toolchain file). Le lun. 7 ao?t 2017 ? 17:22, Konstantin Tokarev a ?crit : > > > 07.08.2017, 17:24, "Cl?ment Gregoire" : > >> I usually stop reading Cmakelists.txt as soon as I see this > >> > >> set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wall -pedantic -pthread -g -O0 > >> -fprofile-arcs -ftest-coverage") > >> > >> The pthread thing there is likely wrong anyway, and the -Wall is > entirely optional. The other things are needed, otherwise gcov will not > produce any useful output. > > > > I don't have an issue with the flags per se, but with the usage of > set(CMAKE_CXX_FLAGS). Setting flags like that should be banned from modern > cmake scripts. > > How can one set global compiler flags without use of CMAKE_CXX_FLAGS or > setting flags for each individual target? > > > > >> Also you need to use the SETUP_TARGET_FOR_COVERAGE for every single test > >> target, which seems to be a difficult to scale on big projects > >> > >> No, you don't. It's entirely fine if you just run "make test" as I do > in OSM2go. > > From what I saw in the documentation of the script : > > > >> # Param _testrunner The name of the target which runs the tests > > > > It seems to call directly the command named _testrunner, which is > somehow confirmed from the cmakelists : > > > >> # src/CMakelists.txt > >> add_executable(tests ${TEST_FILES}) > >> > >> # Linking up all libraries > >> > >> target_link_libraries(tests complex) > >> > >> add_test(NAME example_test COMMAND tests) > >> # CMakelists.txt > >> setup_target_for_coverage(${PROJECT_NAME}_coverage tests coverage) > > From this I deduce that you need to call setup_target_for_coverage for > each different test executable. > > > > 2017-08-07 13:37 GMT+02:00 Rolf Eike Beer : > >> Am 2017-08-07 11:06, schrieb Cl?ment Gregoire: > >> I usually stop reading Cmakelists.txt as soon as I see this > >> > >> set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wall -pedantic -pthread -g -O0 > >> -fprofile-arcs -ftest-coverage") > >> > >> The pthread thing there is likely wrong anyway, and the -Wall is > entirely optional. The other things are needed, otherwise gcov will not > produce any useful output. > >> > >> Also you need to use the SETUP_TARGET_FOR_COVERAGE for every single test > >> target, which seems to be a difficult to scale on big projects > >> > >> No, you don't. It's entirely fine if you just run "make test" as I do > in OSM2go. > >> > >> Eike > >> -- > >> > >> Powered by www.kitware.com > >> > >> Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > >> > >> Kitware offers various services to support the CMake community. For > more information on each offering, please visit: > >> > >> CMake Support: http://cmake.org/cmake/help/support.html > >> CMake Consulting: http://cmake.org/cmake/help/consulting.html > >> CMake Training Courses: http://cmake.org/cmake/help/training.html > >> > >> Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > >> > >> Follow this link to subscribe/unsubscribe: > >> http://public.kitware.com/mailman/listinfo/cmake > > ,-- > > > > Powered by www.kitware.com > > > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > > > CMake Support: http://cmake.org/cmake/help/support.html > > CMake Consulting: http://cmake.org/cmake/help/consulting.html > > CMake Training Courses: http://cmake.org/cmake/help/training.html > > > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > > > Follow this link to subscribe/unsubscribe: > > http://public.kitware.com/mailman/listinfo/cmake > > > -- > Regards, > Konstantin > -------------- next part -------------- An HTML attachment was scrubbed... URL: From annulen at yandex.ru Mon Aug 7 13:52:02 2017 From: annulen at yandex.ru (Konstantin Tokarev) Date: Mon, 07 Aug 2017 20:52:02 +0300 Subject: [CMake] Coverage support In-Reply-To: References: <830e6f57fc2ac7c49c5180f96f99468d@sf-mail.de> <921131502119366@web44g.yandex.ru> Message-ID: <68681502128322@web48g.yandex.ru> An HTML attachment was scrubbed... URL: From robert.maynard at kitware.com Mon Aug 7 13:56:42 2017 From: robert.maynard at kitware.com (Robert Maynard) Date: Mon, 7 Aug 2017 13:56:42 -0400 Subject: [CMake] with cmake-3.9 my testprj breaks, I need to add "add_executable(Qt4::rcc IMPORTED)" In-Reply-To: References: Message-ID: Did this work pre CMake 3.9? On Mon, Aug 7, 2017 at 8:49 AM, Steffen Dettmer wrote: > Hi, > > I have a cmake test project that builds a "hello world" with our > cross toolchain. There are selfmade TOOLCHAINFILES for the > targets. They define QT variables like: > > set(BT_QT_4_7_3_PATH .../taget/Qt-4.7.3) > set(QT_BINARY_DIR ${BT_QT_4_7_3_PATH}/bin) > set(QT_LIBRARY_DIR ${BT_QT_4_7_3_PATH}/lib) > set(QT_MOC_EXECUTABLE ${QT_BINARY_DIR}/moc) > > and so on. I tested a fix for [1] with master branch and then > also v3.9.0, but my project suddenly gets errors: > > $ git clone $r/helloworld && cd helloworld && > mkdir target4 && cd target4 && > /local/users/sdettmer/work/cmake/b/bin/cmake \ > -DCMAKE_TOOLCHAIN_FILE=$TC/$TARGET.cmake .. > -- The C compiler identification is GNU 4.4.3 > [...normal output...] > -- Configuring done > CMake Error: Qt4::rcc target not found hello_world > CMake Error: Qt4::rcc target not found mylib1 > CMake Error: Qt4::rcc target not found mylib2 > -- Generating done > -- Build files have been written to: /local/sdettmer/work/helloworld/target4 > > The "CMake Error:" lines are new. Please note, that I don't use QT rcc at all. > > I noticed that I can work around this by adding: > > set(QT_RCC_EXECUTABLE ${QT_BINARY_DIR}/rcc) > if (NOT TARGET Qt4::rcc) > add_executable(Qt4::rcc IMPORTED) > endif() > > to my TOOLCHAINFILE, but I don't understand why. moc, for > example, needs no such thing, but rcc does, but this one is not > even used. > > The message seems to come from C++ part, could it be that some QT > depenency slipped into the cmake (C++) code by accident? > > Also after the error it tells "Generating done". Does this mean > the error actually is a warning I could ignore? > > Steffen > > > > > > [1] https://gitlab.kitware.com/cmake/cmake/issues/16920 > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake From brad.king at kitware.com Mon Aug 7 14:04:18 2017 From: brad.king at kitware.com (Brad King) Date: Mon, 7 Aug 2017 14:04:18 -0400 Subject: [CMake] with 3.9 my testprj breaks: mylib_autogen/include: No such file or directory In-Reply-To: References: Message-ID: <3f8e27bf-a643-2be5-6ffb-b43982ffd08b@kitware.com> On 08/07/2017 09:01 AM, Steffen Dettmer wrote: > this cmake version does not compile my test project anymore > (v.3.8.2: OK; v3.9.0: FAIL). There is an include path to > $buildir/$subproject/mylib_autogen/include as -I for g++, but > this directory does not exist and I get: > > cc1plus: error [...] No such file or directory. > > If I manually create this include directory it compiles. Please open an issue for this and provide a sample project showing the problem. Thanks, -Brad From rcdailey.lists at gmail.com Mon Aug 7 14:09:49 2017 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Mon, 7 Aug 2017 13:09:49 -0500 Subject: [CMake] CMake + Gradle for Android Message-ID: Right now I have custom targets set to execute the "ant release" command after my native targets are built. Part of that command involves copying *.so files to the libs/armeabi-v7a directory so they get packaged in an APK. When switching to gradle, I have two options: 1. Gradle drives CMake: This means using Android Studio and being locked down to Google's fork of CMake which is a few major releases behind. I see that as a negative. 2. CMake drives Gradle: This would be the same or similar to what I'm already doing: The custom targets I have would execute gradle as a separate build step, instead of running ant commands. I'm not too familiar with Gradle, so I'm not sure how you tell it where your shared libraries are for the APK packaging steps. Which does everyone recommend? Is anyone using one of these setups successfully? The downside to option 2 is probably no on-device native debugging since Android Studio probably can't handle gradle projects without any external CMake builds set up. Would like some general direction & advice before I move away from ANT. Thanks in advance. From irwin at beluga.phys.uvic.ca Mon Aug 7 16:53:41 2017 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Mon, 7 Aug 2017 13:53:41 -0700 (PDT) Subject: [CMake] Advice on converting legacy project to modern CMake In-Reply-To: References: Message-ID: On 2017-08-07 11:35-0000 Bj?rn Blissing wrote: > 1. Which version if CMake should I target? I.e. Which version should I require in my cmake_minimum_required() statement? I would suggest either cmake_minimum_required(VERSION 3.6.2 FATAL_ERROR) or cmake_minimum_required(VERSION 3.7.2 FATAL_ERROR) depending on whether the Cygwin platform (currently only making 3.6.2 available) is important to your users or not. Cygwin is important to PLplot so we recently adopted 3.6.2 as the minimum version choice as the compromise between two goals: (1) We wanted to maximize the version of policies (which are set by cmake_minimum_required) since the latest version of policies typically make a lot of sense to us in terms of eliminating subtle build-system bugs. (2) We wanted to minimize the minimum version to maximize the percentage of our users who will have that minimum version or higher available from the official binary CMake version that is supplied by their software distribution. 3.6.2 currently satisfies goal (1) reasonably well because it is not too far behind the latest version 3.9.0 in terms of policy. 3.6.2 also satisfies goal (2) reasonably well. The major exception here is the so-called Linux "enterprise-class" distributions who go out of their way to **only** support old versions of Linux software because their customers somehow feel more comfortable with that. For example, as far as I can tell from google searches, it looks like RedHat Linux Enterprise versions still only support CMake-2. Which leads to a question I have for the Kitware types here. What should I suggest to my Linux enterprise distribution users? Can they simply download and use the latest Linux binary version of CMake that is distributed by Kitware or are there library version incompatibilities that make that option non-viable? Alternatively, if such users want to build modern CMake for themselves can they do that or do system library incompatibilities stop them in that case as well? If we ignore the "enterprise-class" users, then Debian stable supports 3.7.2. Debian tends to be a bit of a late adopter so as far as I know every other non-enterprise Linux distribution and the various *BSD distributions supports that version of CMake or higher. And I know that is also true for MinGW-w64/MSYS2 and the Mac OS X distributions (Homebrew, MacPorts, and Fink). So I plan to bump the minimum version we support to 3.7.2 as soon as Cygwin (currently only supporting 3.6.2) falls into line with the rest. I haven't mentioned the Windows MSVC platform here yet which is also important to us. But those users are given no official choice of CMake as a binary download so they likely take another viable choice which is to download, install, and use a Kitware binary version of CMake for Windows, and as far as I know all released versions of CMake-3 (as well as CMake-2) are available that way. In any case, for whatever minimum version of CMake you adopt, you should test your build system for that version as well as at least the latest CMake version. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ From jomofisher at gmail.com Mon Aug 7 18:12:05 2017 From: jomofisher at gmail.com (Jom O'Fisher) Date: Mon, 7 Aug 2017 15:12:05 -0700 Subject: [CMake] CMake + Gradle for Android In-Reply-To: References: Message-ID: Either option can work fine. Disclosure: I work on Android Studio and was the one that added CMake support. Option (1) is the way it's designed to work and we're working toward getting rid of the need for the CMake fork. I can't really say when that will happen but if you can get away with an older CMake for now then I'd go this way. As you mentioned, option (1) will allow you to view your source file structure in Android Studio, edit files, and debug using the built-in debugging support. To get option (2) to work, you can use jniDirs setting to tell Android Gradle where to pick up your built .so files (see https://stackoverflow.com/questions/21255125/how-can-i-add-so-files-to-an-android-library-project-using-gradle-0-7). I'm not aware of any projects that use this approach but it should work in principal. I hope this helps, Jomo On Mon, Aug 7, 2017 at 11:09 AM, Robert Dailey wrote: > Right now I have custom targets set to execute the "ant release" > command after my native targets are built. Part of that command > involves copying *.so files to the libs/armeabi-v7a directory so they > get packaged in an APK. > > When switching to gradle, I have two options: > > 1. Gradle drives CMake: This means using Android Studio and being > locked down to Google's fork of CMake which is a few major releases > behind. I see that as a negative. > > 2. CMake drives Gradle: This would be the same or similar to what I'm > already doing: The custom targets I have would execute gradle as a > separate build step, instead of running ant commands. I'm not too > familiar with Gradle, so I'm not sure how you tell it where your > shared libraries are for the APK packaging steps. > > Which does everyone recommend? Is anyone using one of these setups > successfully? The downside to option 2 is probably no on-device native > debugging since Android Studio probably can't handle gradle projects > without any external CMake builds set up. > > Would like some general direction & advice before I move away from > ANT. Thanks in advance. > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/ > opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcdailey.lists at gmail.com Mon Aug 7 18:35:34 2017 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Mon, 7 Aug 2017 17:35:34 -0500 Subject: [CMake] CMake + Gradle for Android In-Reply-To: References: Message-ID: Thanks Jom Honestly, I prefer option 1 to work simply because that's how Google's officially supporting CMake. But it also has debugging which is the #1 reason for me. However, I'd like to understand a lot more about how the integration really happens. For example, I have these questions: 1) How, internally, are CMake build directories managed? Do you generate 1 per unique android project? What about for each specific platform (x86, armeabi-v7a, etc)? 2) Last time I looked into CMake integration, things defined inside the CMake scripts were ignored because they are specified at the command line. Namely, all of those settings that are driven by the Gradle configuration (CXX language level was one in particular I think; I specify C++14 support via CMake, but I recall this being overridden from outside)? 3) How redundant is it to configure individual libraries via the gradle scripts? In my previous attempts, I wanted to define common stuff for CMake / native code at the root gradle or settings file, and only define the differences in the actual gradle build files for each corresponding Java target (like, defining the name of the native (shared library) target in Gradle, but the command line invocation, -D CMake settings, etc would all be common and defined at the root). The TLDR is, the closer we can stay to CMake's way of doing things and keep CMake-related settings self-contained to the CMake scripts themselves, the better. This also makes cross-platform easier (we build the native code in Windows, for example, so having settings specified in the gradle files do not carry over to other platforms. Namely, settings that are not platform specific like the C++ language level). If there's a detailed document / wiki I can read on the intrinsics of CMake integration in Gradle / Android Studio, I'd love to read it. Otherwise, I hope you won't mind if I pick your brain as questions come up. I think I'm going to try option 1 for now and see how it goes. It's just black box for me because unlike option 2, I have very little control over what happens after building the shared libraries, and to make up for that I need to really get a deep understanding of how it works so I can make sure I code my CMake scripts properly for not only Android, but my other platforms as well (non-Android platforms). Thanks again. On Mon, Aug 7, 2017 at 5:12 PM, Jom O'Fisher wrote: > Either option can work fine. Disclosure: I work on Android Studio and was > the one that added CMake support. > > Option (1) is the way it's designed to work and we're working toward getting > rid of the need for the CMake fork. I can't really say when that will happen > but if you can get away with an older CMake for now then I'd go this way. > As you mentioned, option (1) will allow you to view your source file > structure in Android Studio, edit files, and debug using the built-in > debugging support. > > To get option (2) to work, you can use jniDirs setting to tell Android > Gradle where to pick up your built .so files (see > https://stackoverflow.com/questions/21255125/how-can-i-add-so-files-to-an-android-library-project-using-gradle-0-7). > I'm not aware of any projects that use this approach but it should work in > principal. > > I hope this helps, > Jomo > > > On Mon, Aug 7, 2017 at 11:09 AM, Robert Dailey > wrote: >> >> Right now I have custom targets set to execute the "ant release" >> command after my native targets are built. Part of that command >> involves copying *.so files to the libs/armeabi-v7a directory so they >> get packaged in an APK. >> >> When switching to gradle, I have two options: >> >> 1. Gradle drives CMake: This means using Android Studio and being >> locked down to Google's fork of CMake which is a few major releases >> behind. I see that as a negative. >> >> 2. CMake drives Gradle: This would be the same or similar to what I'm >> already doing: The custom targets I have would execute gradle as a >> separate build step, instead of running ant commands. I'm not too >> familiar with Gradle, so I'm not sure how you tell it where your >> shared libraries are for the APK packaging steps. >> >> Which does everyone recommend? Is anyone using one of these setups >> successfully? The downside to option 2 is probably no on-device native >> debugging since Android Studio probably can't handle gradle projects >> without any external CMake builds set up. >> >> Would like some general direction & advice before I move away from >> ANT. Thanks in advance. >> -- >> >> Powered by www.kitware.com >> >> Please keep messages on-topic and check the CMake FAQ at: >> http://www.cmake.org/Wiki/CMake_FAQ >> >> Kitware offers various services to support the CMake community. For more >> information on each offering, please visit: >> >> CMake Support: http://cmake.org/cmake/help/support.html >> CMake Consulting: http://cmake.org/cmake/help/consulting.html >> CMake Training Courses: http://cmake.org/cmake/help/training.html >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/cmake > > From jomofisher at gmail.com Mon Aug 7 19:16:31 2017 From: jomofisher at gmail.com (Jom O'Fisher) Date: Mon, 7 Aug 2017 16:16:31 -0700 Subject: [CMake] CMake + Gradle for Android In-Reply-To: References: Message-ID: 1) There is a folder created for each ABI under the project module folder (so unique per module per ABI) 2) Gradle doesn't specify language level though you can choose to specify it yourself from the build.gradle. This doc does a pretty good job of explaining which variables are set by Gradle: https://developer.android.com/ndk/guides/cmake.html#variables. Philosophically, we try to set as little as we can get away with. In particular, the section titled "Understanding the CMake build command" lays out exactly what we set. You can also see the folders we specify (one per module per ABI) 3) Not sure I understand this. The other document worth taking a look at (if you haven't already) is: https://developer.android.com/studio/projects/add-native-code.html On Mon, Aug 7, 2017 at 3:35 PM, Robert Dailey wrote: > Thanks Jom > > Honestly, I prefer option 1 to work simply because that's how Google's > officially supporting CMake. But it also has debugging which is the #1 > reason for me. > > However, I'd like to understand a lot more about how the integration > really happens. For example, I have these questions: > > 1) How, internally, are CMake build directories managed? Do you > generate 1 per unique android project? What about for each specific > platform (x86, armeabi-v7a, etc)? > 2) Last time I looked into CMake integration, things defined inside > the CMake scripts were ignored because they are specified at the > command line. Namely, all of those settings that are driven by the > Gradle configuration (CXX language level was one in particular I > think; I specify C++14 support via CMake, but I recall this being > overridden from outside)? > 3) How redundant is it to configure individual libraries via the > gradle scripts? In my previous attempts, I wanted to define common > stuff for CMake / native code at the root gradle or settings file, and > only define the differences in the actual gradle build files for each > corresponding Java target (like, defining the name of the native > (shared library) target in Gradle, but the command line invocation, -D > CMake settings, etc would all be common and defined at the root). > > The TLDR is, the closer we can stay to CMake's way of doing things and > keep CMake-related settings self-contained to the CMake scripts > themselves, the better. This also makes cross-platform easier (we > build the native code in Windows, for example, so having settings > specified in the gradle files do not carry over to other platforms. > Namely, settings that are not platform specific like the C++ language > level). > > If there's a detailed document / wiki I can read on the intrinsics of > CMake integration in Gradle / Android Studio, I'd love to read it. > Otherwise, I hope you won't mind if I pick your brain as questions > come up. I think I'm going to try option 1 for now and see how it > goes. It's just black box for me because unlike option 2, I have very > little control over what happens after building the shared libraries, > and to make up for that I need to really get a deep understanding of > how it works so I can make sure I code my CMake scripts properly for > not only Android, but my other platforms as well (non-Android > platforms). > > Thanks again. > > On Mon, Aug 7, 2017 at 5:12 PM, Jom O'Fisher wrote: > > Either option can work fine. Disclosure: I work on Android Studio and was > > the one that added CMake support. > > > > Option (1) is the way it's designed to work and we're working toward > getting > > rid of the need for the CMake fork. I can't really say when that will > happen > > but if you can get away with an older CMake for now then I'd go this way. > > As you mentioned, option (1) will allow you to view your source file > > structure in Android Studio, edit files, and debug using the built-in > > debugging support. > > > > To get option (2) to work, you can use jniDirs setting to tell Android > > Gradle where to pick up your built .so files (see > > https://stackoverflow.com/questions/21255125/how-can-i- > add-so-files-to-an-android-library-project-using-gradle-0-7). > > I'm not aware of any projects that use this approach but it should work > in > > principal. > > > > I hope this helps, > > Jomo > > > > > > On Mon, Aug 7, 2017 at 11:09 AM, Robert Dailey > > > wrote: > >> > >> Right now I have custom targets set to execute the "ant release" > >> command after my native targets are built. Part of that command > >> involves copying *.so files to the libs/armeabi-v7a directory so they > >> get packaged in an APK. > >> > >> When switching to gradle, I have two options: > >> > >> 1. Gradle drives CMake: This means using Android Studio and being > >> locked down to Google's fork of CMake which is a few major releases > >> behind. I see that as a negative. > >> > >> 2. CMake drives Gradle: This would be the same or similar to what I'm > >> already doing: The custom targets I have would execute gradle as a > >> separate build step, instead of running ant commands. I'm not too > >> familiar with Gradle, so I'm not sure how you tell it where your > >> shared libraries are for the APK packaging steps. > >> > >> Which does everyone recommend? Is anyone using one of these setups > >> successfully? The downside to option 2 is probably no on-device native > >> debugging since Android Studio probably can't handle gradle projects > >> without any external CMake builds set up. > >> > >> Would like some general direction & advice before I move away from > >> ANT. Thanks in advance. > >> -- > >> > >> Powered by www.kitware.com > >> > >> Please keep messages on-topic and check the CMake FAQ at: > >> http://www.cmake.org/Wiki/CMake_FAQ > >> > >> Kitware offers various services to support the CMake community. For more > >> information on each offering, please visit: > >> > >> CMake Support: http://cmake.org/cmake/help/support.html > >> CMake Consulting: http://cmake.org/cmake/help/consulting.html > >> CMake Training Courses: http://cmake.org/cmake/help/training.html > >> > >> Visit other Kitware open-source projects at > >> http://www.kitware.com/opensource/opensource.html > >> > >> Follow this link to subscribe/unsubscribe: > >> http://public.kitware.com/mailman/listinfo/cmake > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam.getchell at gmail.com Mon Aug 7 21:07:35 2017 From: adam.getchell at gmail.com (Adam Getchell) Date: Mon, 7 Aug 2017 18:07:35 -0700 Subject: [CMake] CMake 3.9.0 Windows zip file shows wrong version Message-ID: <1A1549EE-3C85-45E2-9977-61BE1CE331FF@gmail.com> Hi all, The CMake 3.9.0 Windows zip file gives the wrong version. Here?s a snippet from my AppVeyor logs [1]: set CMAKE_URL="https://cmake.org/files/v3.9/cmake-3.9.0-win64-x64.zip" appveyor DownloadFile %CMAKE_URL% -FileName cmake.zip Downloading cmake.zip (25,944,520 bytes)...100% 7z x cmake.zip -oC:\projects\dev 7-Zip [64] 16.04 : Copyright (c) 1999-2016 Igor Pavlov : 2016-10-04 Scanning the drive for archives: 1 file, 25944520 bytes (25 MiB) Extracting archive: cmake.zip -- Path = cmake.zip Type = zip Physical Size = 25944520 Everything is Ok Folders: 90 Files: 4922 Size: 66584952 Compressed: 25944520 set PATH=%PATH%;C:\projects\dev\cmake\bin cmake --version cmake version 3.8.2 CMake suite maintained and supported by Kitware (kitware.com/cmake). [1] https://ci.appveyor.com/project/acgetchell/cdt-plusplus -- Adam Getchell https://keybase.io/adamgetchell -------------- next part -------------- An HTML attachment was scrubbed... URL: From Johannes.Sebastian.Mueller-Roemer at igd.fraunhofer.de Tue Aug 8 02:28:15 2017 From: Johannes.Sebastian.Mueller-Roemer at igd.fraunhofer.de (Mueller-Roemer, Johannes Sebastian) Date: Tue, 8 Aug 2017 06:28:15 +0000 Subject: [CMake] Yet another CMake 3.9 CUDA issue In-Reply-To: <20170808055823.CB3861340D8@control02-haj2.antispameurope.com> References: <20170808055823.CB3861340D8@control02-haj2.antispameurope.com> Message-ID: <8D981219EEA621479C112DA9BDC39A8E7096F40F@EXMBS1.ad.igd.fraunhofer.de> I attached the -system-information output for the build. I was not able to glean anything useful from it though, as CMakeError.log is empty, as previously mentioned. Fraunhofer-Institut f?r Graphische Datenverarbeitung IGD Fraunhoferstr. 5 | 64283 Darmstadt | Germany Tel +49 6151 155-606 | Fax +49 6151 155-139 johannes.mueller-roemer at igd.fraunhofer.de | www.igd.fraunhofer.de From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Mueller-Roemer, Johannes Sebastian Sent: Monday, August 7, 2017 09:28 To: cmake at cmake.org Subject: [CMake] Yet another CMake 3.9 CUDA issue Hi, after solving a different issue (lack of .NET 3.5 Framework causing the CUDA MSBuild component to not work, discussion thread "Visual Studio with CUDA does not work in 3.9") and getting good results (parallel CUDA builds, yay!), I now wanted to try CMake 3.9 on a different machine, but no success :( The machine is running Windows Server 2012 R2 with Visual Studio 2015 (2012 is installed as well). The CUDA SDK is installed in versions 7.5 and 8.0. .Net 3.5 is installed as well. However, the following error is reported: CMake Error at E:/BuildTools/cmake/share/cmake-3.9/Modules/CMakeDetermineCompilerId.cmake:247 (message): No CUDA toolset found. Call Stack (most recent call first): E:/BuildTools/cmake/share/cmake-3.9/Modules/CMakeDetermineCompilerId.cmake:31 (CMAKE_DETERMINE_COMPILER_ID_BUILD) E:/BuildTools/cmake/share/cmake-3.9/Modules/CMakeDetermineCUDACompiler.cmake:73 (CMAKE_DETERMINE_COMPILER_ID) CMakeLists.txt:2 (project) -- Configuring incomplete, errors occurred! See also "C:/Users/buildbot/Desktop/test/build/CMakeFiles/CMakeOutput.log". The CMakeOutput.log is also not very informative and only contains: The system is: Windows - 6.3.9600 - AMD64 Regards Johannes Mueller-Roemer Fraunhofer-Institut f?r Graphische Datenverarbeitung IGD Fraunhoferstr. 5 | 64283 Darmstadt | Germany Tel +49 6151 155-606 | Fax +49 6151 155-139 johannes.mueller-roemer at igd.fraunhofer.de | www.igdfraunhofer.de -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: sysinfo.txt URL: From steffen.dettmer at gmail.com Tue Aug 8 03:45:19 2017 From: steffen.dettmer at gmail.com (Steffen Dettmer) Date: Tue, 8 Aug 2017 09:45:19 +0200 Subject: [CMake] with cmake-3.9 my testprj breaks, I need to add "add_executable(Qt4::rcc IMPORTED)" In-Reply-To: References: Message-ID: Hi! thanks for your quick reply. On Mon, Aug 7, 2017 at 7:56 PM, Robert Maynard wrote: > > CMake Error: Qt4::rcc target not found hello_world > > Did this work pre CMake 3.9? Yes, it did. However I missed that some of our CMakeLists.txt has "add_executable(Qt4::moc IMPORTED)". So the change seems only to be that before QT4::rcc was not checked, but supposed to be set since all the time. It is integral part of QT so there is no reason to have moc but not rcc. A team mate said that this is because we don't use find_lib(QT) which internally handles all that, and that cmake has to perform a lot of "magic" for QT, as it is not just "an ordinary library" but much more, formally even an own programming language. (and we don't use find_lib(QT) because once upon a time it was tried but not instantly found working for cross compiling). We're investigating whether we simply can switch to find_lib(QT) which should solve that. Does this make sense or am I mislead? Steffen From DLRdave at aol.com Tue Aug 8 04:33:38 2017 From: DLRdave at aol.com (David Cole) Date: Tue, 8 Aug 2017 04:33:38 -0400 Subject: [CMake] CMake 3.9.0 Windows zip file shows wrong version In-Reply-To: <1A1549EE-3C85-45E2-9977-61BE1CE331FF@gmail.com> References: <1A1549EE-3C85-45E2-9977-61BE1CE331FF@gmail.com> Message-ID: I suspect you are running a different cmake, not the one you've unzipped. Type "where cmake" instead of "cmake --version" and Windows will list the directories where it finds an executable named cmake. The first one it lists is the one it is running when you type "cmake --version"... If you want to force the one you've downloaded to run instead of that one, you could **prepend** to the PATH instead of appending to it. HTH, David C. On Mon, Aug 7, 2017 at 9:07 PM, Adam Getchell wrote: > Hi all, > > The CMake 3.9.0 Windows zip file gives the wrong version. Here?s a snippet > from my AppVeyor logs [1]: > > set CMAKE_URL="https://cmake.org/files/v3.9/cmake-3.9.0-win64-x64.zip" > appveyor DownloadFile %CMAKE_URL% -FileName cmake.zip > Downloading cmake.zip (25,944,520 bytes)...100% > 7z x cmake.zip -oC:\projects\dev > 7-Zip [64] 16.04 : Copyright (c) 1999-2016 Igor Pavlov : 2016-10-04 > Scanning the drive for archives: > 1 file, 25944520 bytes (25 MiB) > Extracting archive: cmake.zip > -- > Path = cmake.zip > Type = zip > Physical Size = 25944520 > Everything is Ok > Folders: 90 > Files: 4922 > Size: 66584952 > Compressed: 25944520 > set PATH=%PATH%;C:\projects\dev\cmake\bin > cmake --version > cmake version 3.8.2 > CMake suite maintained and supported by Kitware (kitware.com/cmake). > > [1] https://ci.appveyor.com/project/acgetchell/cdt-plusplus > -- > Adam Getchell > https://keybase.io/adamgetchell > > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake From steffen.dettmer at gmail.com Tue Aug 8 05:05:26 2017 From: steffen.dettmer at gmail.com (Steffen Dettmer) Date: Tue, 8 Aug 2017 11:05:26 +0200 Subject: [CMake] with 3.9 my testprj breaks: mylib_autogen/include: No such file or directory In-Reply-To: <3f8e27bf-a643-2be5-6ffb-b43982ffd08b@kitware.com> References: <3f8e27bf-a643-2be5-6ffb-b43982ffd08b@kitware.com> Message-ID: Hi, On Mon, Aug 7, 2017 at 8:04 PM, Brad King wrote: > On 08/07/2017 09:01 AM, Steffen Dettmer wrote: > > There is an include path to mylib_autogen/include as -I for g++, but > > this directory does not exist and I get: > > > > cc1plus: error [...] No such file or directory. > > Please open an issue for this and provide a sample project > showing the problem. thanks for your quick reply. With many iterations I was able to create a very small example and opened an issue: https://gitlab.kitware.com/cmake/cmake/issues/17147 for it. Steffen From eike at sf-mail.de Tue Aug 8 07:45:23 2017 From: eike at sf-mail.de (Rolf Eike Beer) Date: Tue, 08 Aug 2017 13:45:23 +0200 Subject: [CMake] with cmake-3.9 my testprj breaks, I need to add "add_executable(Qt4::rcc IMPORTED)" In-Reply-To: References: Message-ID: > (and we don't use find_lib(QT) because once upon a time it was > tried but not instantly found working for cross compiling). > > We're investigating whether we simply can switch to find_lib(QT) > which should solve that. > > Does this make sense or am I mislead? I have used it for crosscompiling in the CMake 3.x timeframe and it worked fine as long as qmake is properly set up (i.e. has it's qt.conf so it finds it's paths). Eike From jeanmichael.celerier at gmail.com Tue Aug 8 09:45:41 2017 From: jeanmichael.celerier at gmail.com (=?UTF-8?Q?Jean=2DMicha=C3=ABl_Celerier?=) Date: Tue, 8 Aug 2017 15:45:41 +0200 Subject: [CMake] Can't get CMake to link pthreads to my lib Message-ID: Here's my CMakeLists.txt : >>>>>>> cmake_minimum_required(VERSION 3.8 FATAL_ERROR) project(oscour) set(CMAKE_INCLUDE_CURRENT_DIR ON) set(CMAKE_CXX_FLAGS "-fconcepts -fsanitize=address -fsanitize=undefined") set(CMAKE_EXE_LINKER_FLAGS "-fconcepts -fsanitize=address -fsanitize=undefined") add_subdirectory(uWebSockets) find_package(Threads REQUIRED) add_library(oscour INTERFACE) target_sources(oscour INTERFACE ${CMAKE_CURRENT_SOURCE_DIR}/oscour/oscour.hpp) target_include_directories(oscour INTERFACE oscour/) target_link_libraries(oscour INTERFACE uWS Threads::Threads) target_compile_options(oscour INTERFACE -std=c++17) add_executable(udp examples/udp.cpp) target_link_libraries(udp PRIVATE oscour) add_executable(tcp examples/tcp.cpp) target_link_libraries(tcp PRIVATE oscour) <<<<<<<< As you can see, I call find_package(Threads REQUIRED) but at no point my example executables, named udp and tcp, link to -pthread (or -lpthread) (which of course makes my build fails). I also tried to link them explicitely to Threads::Threads. This did not work either. e.g. when doing make in verbose mode, the link invocation is : /usr/bin/g++ -fconcepts -fsanitize=address -fsanitize=undefined -std=c++17 -fconcepts -fsanitize=address -fsanitize=undefined CMakeFiles/complete.dir/examples/udp.cpp.o -o udp uWebSockets/libuWS.a /usr/lib/libssl.so /usr/lib/libcrypto.so /usr/lib/libz.so there is no hint of pthreads in there... what can I do ? Best Jean-Micha?l Celerier http://www.jcelerier.name -------------- next part -------------- An HTML attachment was scrubbed... URL: From eike at sf-mail.de Tue Aug 8 10:01:08 2017 From: eike at sf-mail.de (Rolf Eike Beer) Date: Tue, 08 Aug 2017 16:01:08 +0200 Subject: [CMake] Can't get CMake to link pthreads to my lib In-Reply-To: References: Message-ID: <5fe4afd4f233b4bde8513fcd8b0d13a4@sf-mail.de> Am 2017-08-08 15:45, schrieb Jean-Micha?l Celerier: > Here's my CMakeLists.txt : > >>>>>>>> > > cmake_minimum_required(VERSION 3.8 FATAL_ERROR) > project(oscour) > set(CMAKE_INCLUDE_CURRENT_DIR ON) > > set(CMAKE_CXX_FLAGS "-fconcepts -fsanitize=address > -fsanitize=undefined") > set(CMAKE_EXE_LINKER_FLAGS "-fconcepts -fsanitize=address > -fsanitize=undefined") > > add_subdirectory(uWebSockets) set(CMAKE_THREAD_PREFER_PTHREAD On) > find_package(Threads REQUIRED) Greetings, Eike -- From jeanmichael.celerier at gmail.com Tue Aug 8 10:31:30 2017 From: jeanmichael.celerier at gmail.com (=?UTF-8?Q?Jean=2DMicha=C3=ABl_Celerier?=) Date: Tue, 8 Aug 2017 16:31:30 +0200 Subject: [CMake] Can't get CMake to link pthreads to my lib In-Reply-To: <5fe4afd4f233b4bde8513fcd8b0d13a4@sf-mail.de> References: <5fe4afd4f233b4bde8513fcd8b0d13a4@sf-mail.de> Message-ID: I've tried this and also set(THREADS_PREFER_PTHREAD_FLAG TRUE) but this didn't work either. ------- Jean-Micha?l Celerier http://www.jcelerier.name On Tue, Aug 8, 2017 at 4:01 PM, Rolf Eike Beer wrote: > Am 2017-08-08 15:45, schrieb Jean-Micha?l Celerier: > >> Here's my CMakeLists.txt : >> >> >>>>>>>>> >> cmake_minimum_required(VERSION 3.8 FATAL_ERROR) >> project(oscour) >> set(CMAKE_INCLUDE_CURRENT_DIR ON) >> >> set(CMAKE_CXX_FLAGS "-fconcepts -fsanitize=address -fsanitize=undefined") >> set(CMAKE_EXE_LINKER_FLAGS "-fconcepts -fsanitize=address >> -fsanitize=undefined") >> >> add_subdirectory(uWebSockets) >> > > set(CMAKE_THREAD_PREFER_PTHREAD On) > > find_package(Threads REQUIRED) >> > > Greetings, > > Eike > -- > -- > > 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/opensou > rce/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake -------------- next part -------------- An HTML attachment was scrubbed... URL: From bitminer at gmail.com Tue Aug 8 14:08:53 2017 From: bitminer at gmail.com (Brian Davis) Date: Tue, 8 Aug 2017 13:08:53 -0500 Subject: [CMake] CMake equivalent to Boost.Build site-config.jam or user-config.jam Message-ID: Is there a CMake equivalent to a site-config.jam or user-config.jam http://www.boost.org/build/doc/html/bbv2/recipies/site-config.html basically a CMake file the user can put in a project directory that CMake will read first when using cmake-gui that allows user to specify stuff they don't want to have to keep specifying in cmake-gui each "delete cache" such as set( CMAKE_INSTALL_PREFIX ${CURRENT_LIST_DIR}/install CACHE STRING "" FORCE) set( CMAKE_DEBUG_POSTFIX d CACHE STRING "" FORCE ) There is cmake.exe -C but requires command line come to think of it would be nice if set( CMAKE_GENERATOR_PLATFORM "Visual Studio 12 2013 Win64" ) in desired user config file and CMake would just "make it so" on clicking Generate. I can do this with my own projects, by implementing it myself, but when checking out 3rd party projs they can be all over the map on config allowing a user-config.cmake would provide mechanism to tame the config problems. Desired workflow 1) Checkout 3rd party proj 2) put a CMakeUser.txt or whatever file per project 3) Run CMake GUI Generate 4) Click Open Project 5) Change whatever manual bits in in gui 6) Update project suing git witch branches versions 7) Delete Cache 8) Return to 3 9) Doopy doopy doo whatever else -------------- next part -------------- An HTML attachment was scrubbed... URL: From lectem at gmail.com Tue Aug 8 15:31:11 2017 From: lectem at gmail.com (Lectem) Date: Tue, 8 Aug 2017 21:31:11 +0200 Subject: [CMake] CMake equivalent to Boost.Build site-config.jam oruser-config.jam In-Reply-To: References: Message-ID: <598a1181.81131c0a.96200.21a2@mx.google.com> I think that you are looking for the toolchain files?: https://cmake.org/cmake/help/v3.0/manual/cmake-toolchains.7.html The other option is to use a cmake script to specify your variables which includes CMakelists.txt (or the other way around if you can modify the CMakelists.txt). This would be quite similar to ctests scripts. Some good examples are in Daniel Pfeifer?s ??Effective cmake?? talk https://github.com/boostcon/cppnow_presentations_2017/blob/master/05-19-2017_friday/effective_cmake__daniel_pfeifer__cppnow_05-19-2017.pdf De?: Brian Davis Envoy? le?:mardi 8 ao?t 2017 20:09 ??: cmake Mailing List Objet?:[CMake] CMake equivalent to Boost.Build site-config.jam oruser-config.jam Is there a CMake equivalent to a site-config.jam or user-config.jam http://www.boost.org/build/doc/html/bbv2/recipies/site-config.html basically a CMake file the user can put in a project directory that CMake will read first when using cmake-gui that allows user to specify stuff they don't want to have to keep specifying in cmake-gui each "delete cache" such as set( CMAKE_INSTALL_PREFIX ${CURRENT_LIST_DIR}/install CACHE STRING "" FORCE) set( CMAKE_DEBUG_POSTFIX d CACHE STRING "" FORCE ) There is cmake.exe -C but requires command line come to think of it would be nice if set( CMAKE_GENERATOR_PLATFORM "Visual Studio 12 2013 Win64" ) in desired user config file and CMake would just "make it so" on clicking Generate. I can do this with my own projects, by implementing it myself, but when checking out 3rd party projs they can be all over the map on config allowing a user-config.cmake would provide mechanism to tame the config problems. Desired workflow 1) Checkout 3rd party proj 2) put a CMakeUser.txt or whatever file per project 3) Run CMake GUI Generate 4) Click Open Project 5) Change whatever manual bits in in gui 6) Update project suing git witch branches versions 7) Delete Cache 8) Return to 3 9) Doopy doopy doo whatever else -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam.getchell at gmail.com Tue Aug 8 17:53:18 2017 From: adam.getchell at gmail.com (Adam Getchell) Date: Tue, 8 Aug 2017 14:53:18 -0700 Subject: [CMake] CMake 3.9.0 Windows zip file shows wrong version In-Reply-To: References: <1A1549EE-3C85-45E2-9977-61BE1CE331FF@gmail.com> Message-ID: <78334B01-20CC-433B-B097-02B910B2E55B@gmail.com> Yeah, that was it, lol. -- Adam Getchell https://keybase.io/adamgetchell > On Aug 8, 2017, at 1:33 AM, David Cole wrote: > > I suspect you are running a different cmake, not the one you've unzipped. > > Type "where cmake" instead of "cmake --version" and Windows will list > the directories where it finds an executable named cmake. The first > one it lists is the one it is running when you type "cmake > --version"... > > If you want to force the one you've downloaded to run instead of that > one, you could **prepend** to the PATH instead of appending to it. > > > HTH, > David C. > > > > On Mon, Aug 7, 2017 at 9:07 PM, Adam Getchell wrote: >> Hi all, >> >> The CMake 3.9.0 Windows zip file gives the wrong version. Here?s a snippet >> from my AppVeyor logs [1]: >> >> set CMAKE_URL="https://cmake.org/files/v3.9/cmake-3.9.0-win64-x64.zip" >> appveyor DownloadFile %CMAKE_URL% -FileName cmake.zip >> Downloading cmake.zip (25,944,520 bytes)...100% >> 7z x cmake.zip -oC:\projects\dev >> 7-Zip [64] 16.04 : Copyright (c) 1999-2016 Igor Pavlov : 2016-10-04 >> Scanning the drive for archives: >> 1 file, 25944520 bytes (25 MiB) >> Extracting archive: cmake.zip >> -- >> Path = cmake.zip >> Type = zip >> Physical Size = 25944520 >> Everything is Ok >> Folders: 90 >> Files: 4922 >> Size: 66584952 >> Compressed: 25944520 >> set PATH=%PATH%;C:\projects\dev\cmake\bin >> cmake --version >> cmake version 3.8.2 >> CMake suite maintained and supported by Kitware (kitware.com/cmake). >> >> [1] https://ci.appveyor.com/project/acgetchell/cdt-plusplus >> -- >> Adam Getchell >> https://keybase.io/adamgetchell >> >> >> -- >> >> Powered by www.kitware.com >> >> Please keep messages on-topic and check the CMake FAQ at: >> http://www.cmake.org/Wiki/CMake_FAQ >> >> Kitware offers various services to support the CMake community. For more >> information on each offering, please visit: >> >> CMake Support: http://cmake.org/cmake/help/support.html >> CMake Consulting: http://cmake.org/cmake/help/consulting.html >> CMake Training Courses: http://cmake.org/cmake/help/training.html >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/cmake -------------- next part -------------- An HTML attachment was scrubbed... URL: From ewmailing at gmail.com Tue Aug 8 20:21:08 2017 From: ewmailing at gmail.com (Eric Wing) Date: Tue, 8 Aug 2017 17:21:08 -0700 Subject: [CMake] CMake + Gradle for Android In-Reply-To: References: Message-ID: Hi Jom, I'm glad to hear Android's CMake will eventually catch up. But since you are here, can you add a feature that allows a user to specify an alternate location for where CMake is located? There are two useful cases for this. 1) Users daring or desperate enough to try using a more recent CMake while they wait (perhaps they could have merged with Google's branch manually) 2) In my case, I'm trying to implement new features into CMake (Swift compiler support). It's not going to be mainlined anytime soon since it is a long project, so even when you catch up, I still need to be able to call my fork of CMake. I don't want to overwrite anything in the Android distribution, and I have people using my stuff and helping me, so we need a way to collaborate. A simple gradle argument that lets me specify an alternative path to CMake would fix my problem. (The other things I need are specifying a toolchain file which I think you already support and an Initial Cache (-C switch) which maybe is implicitly supported since it is just a generic CMake command line argument. Right now, I am doing the alternative method of calling CMake myself through Gradle/Groovy scripts as people used to do. But I never figured out how to get debugger integration with Android Studio as a consequence. I would really like to move to the official Google/CMake support, but I can't do that unless I can invoke a different CMake. (I did pull the Google fork of CMake and I think my changes are mergable.) Thanks, Eric From jomofisher at gmail.com Tue Aug 8 20:32:25 2017 From: jomofisher at gmail.com (Jom O'Fisher) Date: Tue, 8 Aug 2017 17:32:25 -0700 Subject: [CMake] CMake + Gradle for Android In-Reply-To: References: Message-ID: Yeah, we'd like to support any CMake more recent than 3.7.0 (which is the first version to support server mode). So your fork would need to be based on a somewhat recent CMake. We probably wouldn't support a path directly in build.gradle since that is typically a source controlled artifact. We'd let you set a file path in local.properties and/or specify a CMake version number in build.gradle where we'd search for it in some well-known locations. On Tue, Aug 8, 2017 at 5:21 PM, Eric Wing wrote: > Hi Jom, > > I'm glad to hear Android's CMake will eventually catch up. > > But since you are here, can you add a feature that allows a user to > specify an alternate location for where CMake is located? There are > two useful cases for this. > > 1) Users daring or desperate enough to try using a more recent CMake > while they wait (perhaps they could have merged with Google's branch > manually) > > 2) In my case, I'm trying to implement new features into CMake (Swift > compiler support). It's not going to be mainlined anytime soon since > it is a long project, so even when you catch up, I still need to be > able to call my fork of CMake. > > I don't want to overwrite anything in the Android distribution, and I > have people using my stuff and helping me, so we need a way to > collaborate. A simple gradle argument that lets me specify an > alternative path to CMake would fix my problem. (The other things I > need are specifying a toolchain file which I think you already support > and an Initial Cache (-C switch) which maybe is implicitly supported > since it is just a generic CMake command line argument. > > > Right now, I am doing the alternative method of calling CMake myself > through Gradle/Groovy scripts as people used to do. But I never > figured out how to get debugger integration with Android Studio as a > consequence. I would really like to move to the official Google/CMake > support, but I can't do that unless I can invoke a different CMake. (I > did pull the Google fork of CMake and I think my changes are > mergable.) > > Thanks, > Eric > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ewmailing at gmail.com Tue Aug 8 20:43:12 2017 From: ewmailing at gmail.com (Eric Wing) Date: Tue, 8 Aug 2017 17:43:12 -0700 Subject: [CMake] CMake + Gradle for Android In-Reply-To: References: Message-ID: On 8/8/17, Jom O'Fisher wrote: > Yeah, we'd like to support any CMake more recent than 3.7.0 (which is the > first version to support server mode). So your fork would need to be based > on a somewhat recent CMake. We probably wouldn't support a path directly in > build.gradle since that is typically a source controlled artifact. We'd let > you set a file path in local.properties and/or specify a CMake version > number in build.gradle where we'd search for it in some well-known > locations. I think I could live with local.properties. Any chance you could fast track this and get it in soon? Somewhat coincidentally, my fork of CMake happened close to the time of where the Google fork seemed to happen. I tried the merge. I got tons of conflicts for other things, not my changes. I'm about half-way resolving them...but my changeset is relatively small so I've been thinking I might just manually repatch on yours or try the cherry-picking feature of Git. Thanks, Eric From xavier.besseron at uni.lu Wed Aug 9 05:27:50 2017 From: xavier.besseron at uni.lu (Xavier Besseron) Date: Wed, 9 Aug 2017 11:27:50 +0200 Subject: [CMake] CMake equivalent to Boost.Build site-config.jam oruser-config.jam In-Reply-To: <598a1181.81131c0a.96200.21a2@mx.google.com> References: <598a1181.81131c0a.96200.21a2@mx.google.com> Message-ID: Hi all, >From my understanding, the toolchain files are only inteneded for cross-compilation and I'm afraid you will run in some kind of troubles if you try to use it for something else. As far I know, this feature you describe does not exist in CMake. However I have a piece of CMake code that does what you want. Please find it below. Maybe this can help you. - By default, it loads the settings from file Local_Settings.cmake. It is ignored silently if it does not exist - You can use -DLOCAL_SETTINGS=My_Other_Local_Settings.cmake on the CMake command line to specify a different file In a separate file Load_Local_Settings.cmake: # Default name for Local Settings file set(DEFAULT_LOCAL_SETTINGS_FILE "${CMAKE_SOURCE_DIR}/Local_Settings.cmake") # CMake cache option set(LOCAL_SETTINGS "" CACHE FILEPATH "Path to a file containing Local Settings to load") # Set LOCAL_SETTINGS_FILE variable if(LOCAL_SETTINGS) # If cache variable is set, use it and fails if it is not valid if(EXISTS "${LOCAL_SETTINGS}" AND NOT IS_DIRECTORY "${LOCAL_SETTINGS}") set(LOCAL_SETTINGS_FILE "${LOCAL_SETTINGS}") else() message(FATAL_ERROR "'${LOCAL_SETTINGS}' is not a valid file for LOCAL_SETTINGS") endif() else() # Otherwise, try default filename, and ignore silently if it does not exist if(EXISTS "${DEFAULT_LOCAL_SETTINGS_FILE}" AND NOT IS_DIRECTORY "${DEFAULT_LOCAL_SETTINGS_FILE}") set(LOCAL_SETTINGS_FILE "${DEFAULT_LOCAL_SETTINGS_FILE}") else() set(LOCAL_SETTINGS_FILE "") endif() endif() # Load the settings from the file if variable is defined if(LOCAL_SETTINGS_FILE) message(STATUS "Using Local Settings from '${LOCAL_SETTINGS_FILE}'") include("${LOCAL_SETTINGS_FILE}") endif() Then, in your main CMakeLists.txt, just add: # Load Local Settings include( Load_Local_Settings.cmake ) For example, in my Local_Settings.cmake file, I put things like: set(EIGEN3_ROOT "/path/to/eigen/install" CACHE STRING "") # You can use environment variables too set(BOOST_ROOT "$ENV{EBROOTBOOST}" CACHE STRING "") I hope this helps. Best regards, Xavier On Tue, Aug 8, 2017 at 9:31 PM, Lectem wrote: > I think that you are looking for the toolchain files : > > https://cmake.org/cmake/help/v3.0/manual/cmake-toolchains.7.html > > > > The other option is to use a cmake script to specify your variables which > includes CMakelists.txt (or the other way around if you can modify the > CMakelists.txt). This would be quite similar to ctests scripts. > > Some good examples are in Daniel Pfeifer?s ? Effective cmake ? talk > https://github.com/boostcon/cppnow_presentations_2017/blob/ > master/05-19-2017_friday/effective_cmake__daniel_pfeifer__ > cppnow_05-19-2017.pdf > > > > > > *De : *Brian Davis > *Envoy? le :*mardi 8 ao?t 2017 20:09 > *? : *cmake Mailing List > *Objet :*[CMake] CMake equivalent to Boost.Build site-config.jam > oruser-config.jam > > > > > Is there a CMake equivalent to a site-config.jam or user-config.jam > > http://www.boost.org/build/doc/html/bbv2/recipies/site-config.html > > basically a CMake file the user can put in a project directory that CMake > will read first when using cmake-gui that allows user to specify stuff they > don't want to have to keep specifying in cmake-gui each "delete cache" > > such as > > set( CMAKE_INSTALL_PREFIX ${CURRENT_LIST_DIR}/install CACHE STRING "" > FORCE) > set( CMAKE_DEBUG_POSTFIX d CACHE STRING "" FORCE ) > > There is cmake.exe > > > > -C > > but requires command line > > come to think of it would be nice if > > set( CMAKE_GENERATOR_PLATFORM "Visual Studio 12 2013 Win64" ) > > in desired user config file and CMake would just "make it so" on clicking > Generate. > > I can do this with my own projects, by implementing it myself, but when > checking out 3rd party projs they can be all over the map on config > allowing a user-config.cmake would provide mechanism to tame the config > problems. > > Desired workflow > > 1) Checkout 3rd party proj > > 2) put a CMakeUser.txt or whatever file per project > > 3) Run CMake GUI Generate > > 4) Click Open Project > > 5) Change whatever manual bits in in gui > > 6) Update project suing git witch branches versions > > 7) Delete Cache > > 8) Return to 3 > > 9) Doopy doopy doo whatever else > > > > > > > > -- > > 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/opensou > rce/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake > -- Dr Xavier BESSERON Research associate FSTC, University of Luxembourg Campus Belval, Office MNO E04 0415-040 Phone: +352 46 66 44 5418 <+352%2046%2066%2044%205418> http://luxdem.uni.lu/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From cristian.adam at gmail.com Wed Aug 9 06:20:03 2017 From: cristian.adam at gmail.com (Cristian Adam) Date: Wed, 9 Aug 2017 12:20:03 +0200 Subject: [CMake] CMake equivalent to Boost.Build site-config.jam or user-config.jam In-Reply-To: References: Message-ID: On Tue, Aug 8, 2017 at 8:08 PM, Brian Davis wrote: > > Is there a CMake equivalent to a site-config.jam or user-config.jam > > http://www.boost.org/build/doc/html/bbv2/recipies/site-config.html > > basically a CMake file the user can put in a project directory that CMake > will read first when using cmake-gui that allows user to specify stuff they > don't want to have to keep specifying in cmake-gui each "delete cache" > > such as > > set( CMAKE_INSTALL_PREFIX ${CURRENT_LIST_DIR}/install CACHE STRING "" > FORCE) > set( CMAKE_DEBUG_POSTFIX d CACHE STRING "" FORCE ) > > > There is cmake.exe > > -C > > but requires command line > > come to think of it would be nice if > set( CMAKE_GENERATOR_PLATFORM "Visual Studio 12 2013 Win64" ) > > in desired user config file and CMake would just "make it so" on clicking > Generate. > > I can do this with my own projects, by implementing it myself, but when > checking out 3rd party projs they can be all over the map on config > allowing a user-config.cmake would provide mechanism to tame the config > problems. > > Desired workflow > > 1) Checkout 3rd party proj > > 2) put a CMakeUser.txt or whatever file per project > > 3) Run CMake GUI Generate > > 4) Click Open Project > > 5) Change whatever manual bits in in gui > > 6) Update project suing git witch branches versions > > 7) Delete Cache > > 8) Return to 3 > > 9) Doopy doopy doo whatever else > There is the (undocumented) PreLoad.cmake , which acts like giving a precache file with -C command line argument. But, as it turns out, it doesn't work with server mode :( Cheers, Cristian. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeanmichael.celerier at gmail.com Wed Aug 9 06:32:47 2017 From: jeanmichael.celerier at gmail.com (=?UTF-8?Q?Jean=2DMicha=C3=ABl_Celerier?=) Date: Wed, 9 Aug 2017 12:32:47 +0200 Subject: [CMake] CMake equivalent to Boost.Build site-config.jam or user-config.jam In-Reply-To: References: Message-ID: That's a very useful feature to have! Ideally CMake would also try to load it recursively up to the "/" folder just like for instance clang-format or clang-tidy look for their configuration folders upwards. This would allow for instance to easily build all the projects in a certain folder in release mode by default or stuff like this. ------- Jean-Micha?l Celerier http://www.jcelerier.name On Wed, Aug 9, 2017 at 12:20 PM, Cristian Adam wrote: > > > On Tue, Aug 8, 2017 at 8:08 PM, Brian Davis wrote: > >> >> Is there a CMake equivalent to a site-config.jam or user-config.jam >> >> http://www.boost.org/build/doc/html/bbv2/recipies/site-config.html >> >> basically a CMake file the user can put in a project directory that CMake >> will read first when using cmake-gui that allows user to specify stuff they >> don't want to have to keep specifying in cmake-gui each "delete cache" >> >> such as >> >> set( CMAKE_INSTALL_PREFIX ${CURRENT_LIST_DIR}/install CACHE STRING "" >> FORCE) >> set( CMAKE_DEBUG_POSTFIX d CACHE STRING "" FORCE ) >> >> >> There is cmake.exe >> >> -C >> >> but requires command line >> >> come to think of it would be nice if >> set( CMAKE_GENERATOR_PLATFORM "Visual Studio 12 2013 Win64" ) >> >> in desired user config file and CMake would just "make it so" on clicking >> Generate. >> >> I can do this with my own projects, by implementing it myself, but when >> checking out 3rd party projs they can be all over the map on config >> allowing a user-config.cmake would provide mechanism to tame the config >> problems. >> >> Desired workflow >> >> 1) Checkout 3rd party proj >> >> 2) put a CMakeUser.txt or whatever file per project >> >> 3) Run CMake GUI Generate >> >> 4) Click Open Project >> >> 5) Change whatever manual bits in in gui >> >> 6) Update project suing git witch branches versions >> >> 7) Delete Cache >> >> 8) Return to 3 >> >> 9) Doopy doopy doo whatever else >> > > There is the (undocumented) PreLoad.cmake > , > which acts like giving a precache file with -C command line argument. > > But, as it turns out, it doesn't work with server mode :( > > Cheers, > Cristian. > > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/ > opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake > -------------- next part -------------- An HTML attachment was scrubbed... URL: From craig.scott at crascit.com Wed Aug 9 08:30:38 2017 From: craig.scott at crascit.com (Craig Scott) Date: Wed, 9 Aug 2017 22:30:38 +1000 Subject: [CMake] CMake equivalent to Boost.Build site-config.jam or user-config.jam In-Reply-To: References: Message-ID: Something which may be helpful for projects which don't have direct support for optional config is to hook into their project() command. You can set the CMAKE_PROJECT__INCLUDE _INCLUDE> variable to the name of a file to pull in as though via an include() command right after the project() call that corresponds to. No need to modify the source code of the project in any way, since you're injecting another file from wherever you want to keep it. On Wed, Aug 9, 2017 at 8:32 PM, Jean-Micha?l Celerier < jeanmichael.celerier at gmail.com> wrote: > That's a very useful feature to have! Ideally CMake would also try to load > it recursively up to the "/" folder just like for instance clang-format or > clang-tidy look for their configuration folders upwards. This would allow > for instance to easily build all the projects in a certain folder in > release mode by default or stuff like this. > > > > ------- > Jean-Micha?l Celerier > http://www.jcelerier.name > > On Wed, Aug 9, 2017 at 12:20 PM, Cristian Adam > wrote: > >> >> >> On Tue, Aug 8, 2017 at 8:08 PM, Brian Davis wrote: >> >>> >>> Is there a CMake equivalent to a site-config.jam or user-config.jam >>> >>> http://www.boost.org/build/doc/html/bbv2/recipies/site-config.html >>> >>> basically a CMake file the user can put in a project directory that >>> CMake will read first when using cmake-gui that allows user to specify >>> stuff they don't want to have to keep specifying in cmake-gui each "delete >>> cache" >>> >>> such as >>> >>> set( CMAKE_INSTALL_PREFIX ${CURRENT_LIST_DIR}/install CACHE STRING "" >>> FORCE) >>> set( CMAKE_DEBUG_POSTFIX d CACHE STRING "" FORCE ) >>> >>> >>> There is cmake.exe >>> >>> -C >>> >>> but requires command line >>> >>> come to think of it would be nice if >>> set( CMAKE_GENERATOR_PLATFORM "Visual Studio 12 2013 Win64" ) >>> >>> in desired user config file and CMake would just "make it so" on >>> clicking Generate. >>> >>> I can do this with my own projects, by implementing it myself, but when >>> checking out 3rd party projs they can be all over the map on config >>> allowing a user-config.cmake would provide mechanism to tame the config >>> problems. >>> >>> Desired workflow >>> >>> 1) Checkout 3rd party proj >>> >>> 2) put a CMakeUser.txt or whatever file per project >>> >>> 3) Run CMake GUI Generate >>> >>> 4) Click Open Project >>> >>> 5) Change whatever manual bits in in gui >>> >>> 6) Update project suing git witch branches versions >>> >>> 7) Delete Cache >>> >>> 8) Return to 3 >>> >>> 9) Doopy doopy doo whatever else >>> >> >> There is the (undocumented) PreLoad.cmake >> , >> which acts like giving a precache file with -C command line argument. >> >> But, as it turns out, it doesn't work with server mode :( >> >> Cheers, >> Cristian. >> >> >> -- >> >> Powered by www.kitware.com >> >> Please keep messages on-topic and check the CMake FAQ at: >> http://www.cmake.org/Wiki/CMake_FAQ >> >> Kitware offers various services to support the CMake community. For more >> information on each offering, please visit: >> >> CMake Support: http://cmake.org/cmake/help/support.html >> CMake Consulting: http://cmake.org/cmake/help/consulting.html >> CMake Training Courses: http://cmake.org/cmake/help/training.html >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/cmake >> > > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/ > opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake > -- Craig Scott Melbourne, Australia https://crascit.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From ianmalcom at gmail.com Wed Aug 9 11:09:18 2017 From: ianmalcom at gmail.com (Manu) Date: Wed, 9 Aug 2017 17:09:18 +0200 Subject: [CMake] file timestamp with symbolic link under Windows Message-ID: Hello CMakers, I recently switched from CMake 2.8.12 to 3.8.2 and the behaviour of file(TIMESTAMP MyFile MyFileTimestamp) changed when MyFileis a symbolic link under Windows. In 2.8.12 the funtion was reporting of the actual file timestamp pointed by the symbolic link. In 3.8.2 the funcitons returns the symbolic link itself timpestamp. Has this behaviour changed intentionally? I do not find anything related in the change logs. Trying to workaround this issue, I stumbled upon get_filename_component function which I can use to get the realpath of a symbolic link but when I use it as: get_filename_component(MyFileRealPath ${MyFile} REALPATH) MyFileRealPath contains the symbolic link path, not the real path!. I am currently digging in cmake source code and considering reporting as a bug. Any comments will be warmly welcomed. Regards! -------------- next part -------------- An HTML attachment was scrubbed... URL: From steffen.dettmer at gmail.com Wed Aug 9 11:18:10 2017 From: steffen.dettmer at gmail.com (Steffen Dettmer) Date: Wed, 9 Aug 2017 17:18:10 +0200 Subject: [CMake] HOWTO cmake compatiblity? In-Reply-To: References: <7a4b678d2494f4b2ecc223d5f97725e1@sf-mail.de> Message-ID: Hi, > > > So far I think we need to install cmake into a versionized > > > directory and invoke it: I tested with versionized directory and it works really well. For example when having a symlink /opt/toolchain/1.0.0/bin/cmake -> /opt/cmake/3.6.2/bin/cmake it can be used as: $ export PATH=/opt/toolchain/1.0.0/bin/:$PATH $ cmake -DCMAKE_TOOLCHAIN_FILE=/opt/toolchain/1.0.0/targets/t1.cmake Very nice is that then generated files do not depend on PATH, i.e. when make calls cmake, it calls the initially used cmake by using the (resolved) full path, in the example /opt/cmake/3.6.2/bin/cmake. When calling with full path: $ /opt/toolchain/1.0.0/bin/cmake \ -DCMAKE_TOOLCHAIN_FILE=/opt/toolchain/1.0.0/targets/t2.cmake this full path is used (as it is). Also the correct ctest is executed by make test. This is just great, exactly what we need. Steffen From bitminer at gmail.com Wed Aug 9 14:27:00 2017 From: bitminer at gmail.com (Brian Davis) Date: Wed, 9 Aug 2017 13:27:00 -0500 Subject: [CMake] find_package( ITK ) with ITK version 4.8 and cmake 3.9.0-rc6 (3.1+ anyway) is like finding Dory Message-ID: I am so lost in CMB0054 errors I and internet searches I can't remember why I wanted Itk-4.8 in the first place. Here goes: When using CMake 3.9.0-rc6 or basically 3.1+ (onward) and trying: find_package( ITK ) with 4.8 built / installed and receiving: CMake Warning (dev) at install/lib/cmake/ITK-4.8/ITKTargets.cmake:28 (if): Policy CMP0054 is not set: Only interpret if() arguments as variables or keywords when unquoted. Run "cmake --help-policy CMP0054" for policy details. Use the cmake_policy command to set the policy and suppress this warning. Quoted variables like "" will no longer be dereferenced when the policy is set to NEW. Since the policy is not set the OLD behavior will be used. Call Stack (most recent call first): install/lib/cmake/ITK-4.8/ITKConfig.cmake:50 (include) subprojects/ctutil/CMake/ctutil/itk/itk_config.cmake:137 (find_package) subprojects/ctutil/CMake/ctutil/Findctutil.cmake:224 (itk_config) CMakeLists.txt:123 (find_package) This warning is for project developers. Use -Wno-dev to suppress it. CMake Warning (dev) at install/lib/cmake/ITK-4.8/ITKTargets.cmake:36 (if): Policy CMP0054 is not set: Only interpret if() arguments as variables or keywords when unquoted. Run "cmake --help-policy CMP0054" for policy details. Use the cmake_policy command to set the policy and suppress this warning. Quoted variables like "" will no longer be dereferenced when the policy is set to NEW. Since the policy is not set the OLD behavior will be used. Call Stack (most recent call first): install/lib/cmake/ITK-4.8/ITKConfig.cmake:50 (include) subprojects/ctutil/CMake/ctutil/itk/itk_config.cmake:137 (find_package) subprojects/ctutil/CMake/ctutil/Findctutil.cmake:224 (itk_config) CMakeLists.txt:123 (find_package) This warning is for project developers. Use -Wno-dev to suppress it. then looking at line 28 in install/lib/cmake/ITK-4.8/ITKTargets.cmake:28 if("${_targetsDefined}" STREQUAL "${_expectedTargets}") then reading: https://cmake.org/cmake/help/v3.1/policy/CMP0054.html I always new CMake was and is broken (language, use, and documentation), but never such a realization as now. and bits like https://cmake.org/pipermail/cmake/2014-December/059317.html https://cmake.org/cmake/help/v3.1/command/cmake_policy.html#command:cmake_policy then ...sigh... then trying: cmake_policy(PUSH) cmake_policy(SET CMP0054 OLD) find_package( ITK ) cmake_policy(POP) and still getting: CMake Warning (dev) at install/lib/cmake/ITK-4.8/ITKTargets.cmake:28 (if): Policy CMP0054 is not set: Only interpret if() arguments as variables or keywords when unquoted. Run "cmake --help-policy CMP0054" for policy details. Use the cmake_policy command to set the policy and suppress this warning. and wondering does the cmake_policy push, pop, set do anything here? I am left wondering who, what, why am I here? Maybe Sigourney Weaver can help (see title). from: https://en.wikipedia.org/wiki/CMake "CMake development began in 1999 in response to the need for a cross-platform build environment for the Insight Segmentation and Registration Toolkit (ITK)" If only I could get CMake to work with the package it was originally created to build. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bitminer at gmail.com Wed Aug 9 15:16:43 2017 From: bitminer at gmail.com (Brian Davis) Date: Wed, 9 Aug 2017 14:16:43 -0500 Subject: [CMake] CMake equivalent to Boost.Build site-config.jam or user-config.jam In-Reply-To: References: Message-ID: Yes PreLoad.cmake was/is exactly what I am looking for. I tested it and it works minus the bit about it not workging with: set( CMAKE_GENERATOR_PLATFORM "Visual Studio 12 2013 Win64" ) but hey it's 99.99 percent of what I need. Now only if I could find that say in the documentation! Thanks for the heads up on the feature. Nice! On Wed, Aug 9, 2017 at 5:20 AM, Cristian Adam wrote: > > > On Tue, Aug 8, 2017 at 8:08 PM, Brian Davis wrote: > >> >> Is there a CMake equivalent to a site-config.jam or user-config.jam >> >> http://www.boost.org/build/doc/html/bbv2/recipies/site-config.html >> >> basically a CMake file the user can put in a project directory that CMake >> will read first when using cmake-gui that allows user to specify stuff they >> don't want to have to keep specifying in cmake-gui each "delete cache" >> >> such as >> >> set( CMAKE_INSTALL_PREFIX ${CURRENT_LIST_DIR}/install CACHE STRING "" >> FORCE) >> set( CMAKE_DEBUG_POSTFIX d CACHE STRING "" FORCE ) >> >> >> There is cmake.exe >> >> -C >> >> but requires command line >> >> come to think of it would be nice if >> set( CMAKE_GENERATOR_PLATFORM "Visual Studio 12 2013 Win64" ) >> >> in desired user config file and CMake would just "make it so" on clicking >> Generate. >> >> I can do this with my own projects, by implementing it myself, but when >> checking out 3rd party projs they can be all over the map on config >> allowing a user-config.cmake would provide mechanism to tame the config >> problems. >> >> Desired workflow >> >> 1) Checkout 3rd party proj >> >> 2) put a CMakeUser.txt or whatever file per project >> >> 3) Run CMake GUI Generate >> >> 4) Click Open Project >> >> 5) Change whatever manual bits in in gui >> >> 6) Update project suing git witch branches versions >> >> 7) Delete Cache >> >> 8) Return to 3 >> >> 9) Doopy doopy doo whatever else >> > > There is the (undocumented) PreLoad.cmake > , > which acts like giving a precache file with -C command line argument. > > But, as it turns out, it doesn't work with server mode :( > > Cheers, > Cristian. > > -- Brian J. Davis -------------- next part -------------- An HTML attachment was scrubbed... URL: From julius.caro at gmail.com Wed Aug 9 16:58:43 2017 From: julius.caro at gmail.com (Luis Caro Campos) Date: Wed, 9 Aug 2017 21:58:43 +0100 Subject: [CMake] find_package( ITK ) with ITK version 4.8 and cmake 3.9.0-rc6 (3.1+ anyway) is like finding Dory In-Reply-To: References: Message-ID: Hi Brian, What is the version passed to cmake_minimum_required for your project? (Typically the first line in your top-level CMakeLists.txt). I suspect if you set it to a version higher than 3.1 the warnings will disappear (I believe it is set to a version older than that, hence the policy warnings). Regards On 9 Aug 2017 7:27 pm, "Brian Davis" wrote: > > I am so lost in CMB0054 errors I and internet searches I can't remember > why I wanted Itk-4.8 in the first place. Here goes: > > When using CMake 3.9.0-rc6 or basically 3.1+ (onward) and trying: > > find_package( ITK ) > > with 4.8 built / installed and receiving: > > CMake Warning (dev) at install/lib/cmake/ITK-4.8/ITKTargets.cmake:28 (if): > Policy CMP0054 is not set: Only interpret if() arguments as variables or > keywords when unquoted. Run "cmake --help-policy CMP0054" for policy > details. Use the cmake_policy command to set the policy and suppress this > warning. > > Quoted variables like "" will no longer be dereferenced when the policy is > set to NEW. Since the policy is not set the OLD behavior will be used. > Call Stack (most recent call first): > install/lib/cmake/ITK-4.8/ITKConfig.cmake:50 (include) > subprojects/ctutil/CMake/ctutil/itk/itk_config.cmake:137 (find_package) > subprojects/ctutil/CMake/ctutil/Findctutil.cmake:224 (itk_config) > CMakeLists.txt:123 (find_package) > This warning is for project developers. Use -Wno-dev to suppress it. > > CMake Warning (dev) at install/lib/cmake/ITK-4.8/ITKTargets.cmake:36 (if): > Policy CMP0054 is not set: Only interpret if() arguments as variables or > keywords when unquoted. Run "cmake --help-policy CMP0054" for policy > details. Use the cmake_policy command to set the policy and suppress this > warning. > > Quoted variables like "" will no longer be dereferenced when the policy is > set to NEW. Since the policy is not set the OLD behavior will be used. > Call Stack (most recent call first): > install/lib/cmake/ITK-4.8/ITKConfig.cmake:50 (include) > subprojects/ctutil/CMake/ctutil/itk/itk_config.cmake:137 (find_package) > subprojects/ctutil/CMake/ctutil/Findctutil.cmake:224 (itk_config) > CMakeLists.txt:123 (find_package) > This warning is for project developers. Use -Wno-dev to suppress it. > > > then looking at line 28 in install/lib/cmake/ITK-4.8/ITKTargets.cmake:28 > > if("${_targetsDefined}" STREQUAL "${_expectedTargets}") > > > then reading: > > https://cmake.org/cmake/help/v3.1/policy/CMP0054.html > > I always new CMake was and is broken (language, use, and documentation), > but never such a realization as now. > > and bits like > > https://cmake.org/pipermail/cmake/2014-December/059317.html > https://cmake.org/cmake/help/v3.1/command/cmake_policy. > html#command:cmake_policy > > then ...sigh... then trying: > > cmake_policy(PUSH) > cmake_policy(SET CMP0054 OLD) > find_package( ITK ) > cmake_policy(POP) > > and still getting: > > CMake Warning (dev) at install/lib/cmake/ITK-4.8/ITKTargets.cmake:28 (if): > Policy CMP0054 is not set: Only interpret if() arguments as variables or > keywords when unquoted. Run "cmake --help-policy CMP0054" for policy > details. Use the cmake_policy command to set the policy and suppress this > warning. > > and wondering does the cmake_policy push, pop, set do anything here? > > I am left wondering who, what, why am I here? Maybe Sigourney Weaver can > help (see title). > > from: > > https://en.wikipedia.org/wiki/CMake > > "CMake development began in 1999 in response to the need for a > cross-platform build environment for the Insight Segmentation and > Registration Toolkit (ITK)" > > If only I could get CMake to work with the package it was originally > created to build. > > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/ > opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bitminer at gmail.com Wed Aug 9 17:23:14 2017 From: bitminer at gmail.com (Brian Davis) Date: Wed, 9 Aug 2017 16:23:14 -0500 Subject: [CMake] CMake equivalent to Boost.Build site-config.jam oruser-config.jam In-Reply-To: <598a1181.81131c0a.96200.21a2@mx.google.com> References: <598a1181.81131c0a.96200.21a2@mx.google.com> Message-ID: On Tue, Aug 8, 2017 at 2:31 PM, Lectem wrote: > I think that you are looking for the toolchain files : > > https://cmake.org/cmake/help/v3.0/manual/cmake-toolchains.7.html > > > > The other option is to use a cmake script to specify your variables which > includes CMakelists.txt (or the other way around if you can modify the > CMakelists.txt). This would be quite similar to ctests scripts. > > Some good examples are in Daniel Pfeifer?s ? Effective cmake ? talk > https://github.com/boostcon/cppnow_presentations_2017/ > blob/master/05-19-2017_friday/effective_cmake__daniel_ > pfeifer__cppnow_05-19-2017.pdf > > > Wow that PDF is refreshing I have started to see some of these changes to CMake creep in over the years. Coming from Boost.Build pre 2009 I had always longed for CMake to model itself after Boost Build if only a little bit. I had long ago complained... ok and still do.. about the underlying design, scope, documentation (lack of in some cases and misleading/bad examples see such as), and language problems of CMake. such as: https://cmake.org/cmake/help/latest/manual/cmake-packages.7.html and https://cmake.org/cmake/help/latest/module/CMakePackageConfigHelpers.html#module:CMakePackageConfigHelpers which still leave the package developer to use or not use version, put package (find_package) files "wherever" project( proj_name VERSION 1.0) not having any bearing on CMAKE_INSTALL_PREFIX such as C:\Program Files\proj-name and not C:\Program Files\proj-name-1.0, cuz who doesn't want previous versions blasted away/written over by default? It got so bad that I wrapped CMake goop in my own macros (which I even posted as feature request at http://www.CMake.org/Bug/view.php?id=11807 but no longer in existence - CMake's Mantis tracker ) to give concise boost.build inheritable (such as now INTERFACE) like spec and in so doing probably violated or committed every bad practice in that pdf, but hey what choice did I have back then... in trying to keep previous projects building... not sure what choice I have now.. What I resorted to at the time was I rolled own macros add_project_executable, add_project_library, and add_project_configuration. Where add_project_configuration allowed project executables and libraries to inherit build properties from configurations: http://slideplayer.com/slide/6139853/ http://images.slideplayer.com/18/6139853/slides/slide_24.jpg http://images.slideplayer.com/18/6139853/slides/slide_25.jpg I know I'll build a Meta Meta (yes that's two Meta's) Build Spec Generator to take CMake Build Spec and generate a new updated CMake build spec to be used to generate the build spec to build the code.. eureka! add_library(Bar Interface) target_definitions(Bar IINTERFACE BAR = 1) might get around my need for my add_project_configuration macro and friends. Sadly the name "add_library" to say add only #defines or include dirs could more appropriately be add_configuration when not adding a "true" library. Rather inheriting/using config properties and the statement: INTERFACE libraries have no build specification They only give usage requirements Only adds to the affront on sensibilities, cuz if it's not a library and has no build spec... errr why the term "library". IMO: https://cmake.org/cmake/help/latest/release/3.0.html?highlight=interface#properties add_library should unlearn/forget interface and add_config, add_buildspec, or some other more appropriate name for this. I can understand the lazy logic where "libraries" are both inherited/consumed by libraries and exectuables so put it there kinda logic that must have resulted in this.. These changes still don't fix the cmake-package and ExternalProject_add problems and 3rd party developer cat herding I find myself doing these days on the internet. -------------- next part -------------- An HTML attachment was scrubbed... URL: From j.w.jones at swansea.ac.uk Thu Aug 10 04:50:09 2017 From: j.w.jones at swansea.ac.uk (Jones J.W.) Date: Thu, 10 Aug 2017 08:50:09 +0000 Subject: [CMake] FindIce module and C++11 Message-ID: I'm building my code on Linux using the g++ flags "-std=c++11". This means that I must link with the libIce++11 libraries instead of libIce. The FindIce module, however as no provision for choosing these libraries thus resulting in unresolved symbols at link time. I tried getting around the problem by simply listing Ice++11 as a COMPONENT which works in Linux but the same CMakeLists.txt file in Windows won't work as there is no Ice++11. Currently I have resolved this by having two calls to the FindIce module inside an IF( MSVC ) conditional. Would it be possible to add a flag to tell the FindIce module whether C++11 is being used or not? Thanks, Jason - Dr Jason W Jones Associate Professor College of Engineering Swansea University Singleton Park Swansea UK SA2 8PP Tel: +44-1792-295869 -------------- next part -------------- An HTML attachment was scrubbed... URL: From rleigh at codelibre.net Thu Aug 10 05:28:31 2017 From: rleigh at codelibre.net (rleigh at codelibre.net) Date: Thu, 10 Aug 2017 10:28:31 +0100 Subject: [CMake] FindIce module and C++11 In-Reply-To: References: Message-ID: On 2017-08-10 09:50, Jones J.W. wrote: > I'm building my code on Linux using the g++ flags "-std=c++11". This > means that I must link with the libIce++11 libraries instead of > libIce. > > The FindIce module, however as no provision for choosing these > libraries thus resulting in unresolved symbols at link time. > > I tried getting around the problem by simply listing Ice++11 as a > COMPONENT which works in Linux but the same CMakeLists.txt file in > Windows won't work as there is no Ice++11. Currently I have resolved > this by having two calls to the FindIce module inside an IF( MSVC ) > conditional. > > Would it be possible to add a flag to tell the FindIce module whether > C++11 is being used or not? FindIce certainly needs an update for Ice 3.7. Regarding C++11, their approach here is certainly a bit unorthodox as well as being inconsistent between platforms, and FindIce will need to deal with that unfortunate situation. Since the old and new APIs are incompatible, and you have to explicitly opt-in to using the new one, I don't think that using "-std=c++11" on its own is sufficient reason to select the C++11 library? Can you use the old API with a C++11 compiler? It might be best to have a set of C++11 component names, and map these to the appropriate library names on Linux (separate libs) and Windows (not separate), if that would make the intent of the user clear and unambiguous. I will try to look at this, but I'm a little busy with other things at the moment, and so it's not at top of my list. If you wanted to propose a change an/or open a merge request that would certainly be welcome. Kind regards, Roger Leigh From aborsic at gmail.com Thu Aug 10 05:49:32 2017 From: aborsic at gmail.com (Andrea Borsic) Date: Thu, 10 Aug 2017 11:49:32 +0200 Subject: [CMake] Possible bug/incompatibility FindCUDA with Visual Studio 2017 Message-ID: <34349be0-0c38-b897-925f-734760644c44@gmail.com> Hi All, I am working on this platform: * Windows 10 64bit * Visual Studio 2015 Community Edition * Visual Studio 2017 Community Edition * CUDA 8.0 * CMake 3.9 I am in the middle of switching from VS2015 to VS2017, but CUDA projects fail to properly compile under VS2017 as the compiler/linker fail to find tools on the path setup by CMake. I believe this is bug/incompatibly of the CMake FindCUDA module with VS2017. To reproduce the problem I am attaching a tiny project * main.cu is a minimal CUDA example from the web * CMakeLists.txt is a CMake file that leads to a successful build under VS2015 and unsuccessful under VS2017 * Output VS2015 is the output from building the project under VS2015 (all targets built OK) * Output VS2017 is the output from building the project under VS2015 (1 target OK one target fails) I have noticed also that oddly under VS2017 an "x64" and "main.dir" directories are created outside the build dir, and at the level of the source directory. I thought of reporting this to the list, and any help is welcome, Thank you and Best Regards, Andrea -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- PROJECT (Test) CMAKE_MINIMUM_REQUIRED(VERSION 3.1) FIND_PACKAGE(CUDA REQUIRED) SET(CUDA_NVCC_FLAGS "-arch=sm_35" CACHE STRING "nvcc flags" FORCE) CUDA_ADD_EXECUTABLE(main main.cu) -------------- next part -------------- #include // // Nearly minimal CUDA example. // Compile with: // // nvcc -o example example.cu // #define N 1000 // // A function marked __global__ // runs on the GPU but can be called from // the CPU. // // This function multiplies the elements of an array // of ints by 2. // // The entire computation can be thought of as running // with one thread per array element with blockIdx.x // identifying the thread. // // The comparison i>>(da, db); // // Copy output array from GPU back to CPU. // cudaMemcpy(hb, db, N*sizeof(int), cudaMemcpyDeviceToHost); for (int i = 0; i------ Build started: Project: ZERO_CHECK, Configuration: Debug x64 ------ 1> Checking Build System 1> CMake does not need to re-run because D:/Dropbox/NES_Projects_Technical/Active/HP-EIT/Test Cmake VS2017/build_win64_vs2015_cuda8/CMakeFiles/generate.stamp is up-to-date. 2>------ Build started: Project: main, Configuration: Debug x64 ------ 2> Building NVCC (Device) object CMakeFiles/main.dir/Debug/main_generated_main.cu.obj 2> main.cu 2> main.cu 2> Building Custom Rule D:/Dropbox/NES_Projects_Technical/Active/HP-EIT/Test Cmake VS2017/src/CMakeLists.txt 2> CMake is re-running because D:/Dropbox/NES_Projects_Technical/Active/HP-EIT/Test Cmake VS2017/build_win64_vs2015_cuda8/CMakeFiles/generate.stamp is out-of-date. 2> the file 'D:/Dropbox/NES_Projects_Technical/Active/HP-EIT/Test Cmake VS2017/build_win64_vs2015_cuda8/CMakeFiles/main.dir/main_generated_main.cu.obj.depend' 2> is newer than 'D:/Dropbox/NES_Projects_Technical/Active/HP-EIT/Test Cmake VS2017/build_win64_vs2015_cuda8/CMakeFiles/generate.stamp.depend' 2> result='-1' 2> -- Configuring done 2> -- Generating done 2> -- Build files have been written to: D:/Dropbox/NES_Projects_Technical/Active/HP-EIT/Test Cmake VS2017/build_win64_vs2015_cuda8 2> Creating library D:/Dropbox/NES_Projects_Technical/Active/HP-EIT/Test Cmake VS2017/build_win64_vs2015_cuda8/Debug/main.lib and object D:/Dropbox/NES_Projects_Technical/Active/HP-EIT/Test Cmake VS2017/build_win64_vs2015_cuda8/Debug/main.exp 2> main.vcxproj -> D:\Dropbox\NES_Projects_Technical\Active\HP-EIT\Test Cmake VS2017\build_win64_vs2015_cuda8\Debug\main.exe 2> main.vcxproj -> D:/Dropbox/NES_Projects_Technical/Active/HP-EIT/Test Cmake VS2017/build_win64_vs2015_cuda8/Debug/main.pdb (Full PDB) 3>------ Skipped Build: Project: ALL_BUILD, Configuration: Debug x64 ------ 3>Project not selected to build for this solution configuration ========== Build: 2 succeeded, 0 failed, 0 up-to-date, 1 skipped ========== -------------- next part -------------- 1>------ Build started: Project: ZERO_CHECK, Configuration: Debug x64 ------ 1>Checking Build System 1>CMake does not need to re-run because D:/Dropbox/NES_Projects_Technical/Active/HP-EIT/Test Cmake VS2017/build_win64_vs2017_cuda8/CMakeFiles/generate.stamp is up-to-date. 2>------ Build started: Project: main, Configuration: Debug x64 ------ 2>Building NVCC (Device) object CMakeFiles/main.dir/Debug/main_generated_main.cu.obj 2>Failed to run C:/Program Files (x86)/Microsoft Visual Studio/2017/Community/VC/bin (The system cannot find the file specified. 2> 2>). 2>CMake Error at main_generated_main.cu.obj.Debug.cmake:222 (message): 2> Error generating D:/Dropbox/NES_Projects_Technical/Active/HP-EIT/Test Cmake 2> VS2017/build_win64_vs2017_cuda8/CMakeFiles/main.dir//Debug/main_generated_main.cu.obj 2> 2> 2>C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\VC\VCTargets\Microsoft.CppCommon.targets(171,5): error MSB6006: "cmd.exe" exited with code 1. 2>Done building project "main.vcxproj" -- FAILED. 3>------ Skipped Build: Project: ALL_BUILD, Configuration: Debug x64 ------ 3>Project not selected to build for this solution configuration ========== Build: 1 succeeded, 1 failed, 0 up-to-date, 1 skipped ========== From robert.maynard at kitware.com Thu Aug 10 10:28:32 2017 From: robert.maynard at kitware.com (Robert Maynard) Date: Thu, 10 Aug 2017 10:28:32 -0400 Subject: [CMake] Possible bug/incompatibility FindCUDA with Visual Studio 2017 In-Reply-To: <34349be0-0c38-b897-925f-734760644c44@gmail.com> References: <34349be0-0c38-b897-925f-734760644c44@gmail.com> Message-ID: So you are going to have two issues. 1. The FindCUDA module has not been updated to handle VS2017. The issue is that the VCInstallDir variable now returns a different relative path to the compiler than it previously did. If you can determine the new logic a patch fixing this behavior be great. 2. It doesn't look like CUDA 8.0 supports VS2017 ( http://docs.nvidia.com/cuda/cuda-installation-guide-microsoft-windows/index.html#system-requirements ). 3. You could also look at using the new CMake 3.9 cuda support ( https://devblogs.nvidia.com/parallelforall/building-cuda-applications-cmake/ ). On Thu, Aug 10, 2017 at 5:49 AM, Andrea Borsic wrote: > Hi All, > > I am working on this platform: > > Windows 10 64bit > Visual Studio 2015 Community Edition > Visual Studio 2017 Community Edition > CUDA 8.0 > CMake 3.9 > > I am in the middle of switching from VS2015 to VS2017, but CUDA projects > fail to properly compile under VS2017 as the compiler/linker fail to find > tools on the path setup by CMake. I believe this is bug/incompatibly of the > CMake FindCUDA module with VS2017. > > To reproduce the problem I am attaching a tiny project > > main.cu is a minimal CUDA example from the web > CMakeLists.txt is a CMake file that leads to a successful build under VS2015 > and unsuccessful under VS2017 > Output VS2015 is the output from building the project under VS2015 (all > targets built OK) > Output VS2017 is the output from building the project under VS2015 (1 target > OK one target fails) > > I have noticed also that oddly under VS2017 an "x64" and "main.dir" > directories are created outside the build dir, and at the level of the > source directory. > > I thought of reporting this to the list, and any help is welcome, > > Thank you and Best Regards, > > Andrea > > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake From robert.maynard at kitware.com Thu Aug 10 12:17:33 2017 From: robert.maynard at kitware.com (Robert Maynard) Date: Thu, 10 Aug 2017 12:17:33 -0400 Subject: [CMake] [ANNOUNCE] CMake 3.9.1 available for download Message-ID: We are pleased to announce that CMake 3.9.1 is now available for download. Please use the latest release from our download page: https://cmake.org/download/ * The "find_" command "PACKAGE_ROOT" search path group added by CMake 3.9.0 has been removed for the 3.9 series due to regressions caused by new use of "_ROOT" variables. The behavior may be re-introduced in the future in a more-compatible way. Thanks for your support! ------------------------------------------------------------------------- Changes in 3.9.1 since 3.9.0: Bj?rn Esser (2): Utilities/Sphinx: Restore compatibility with Sphinx pre-1.2 Help: Silence warning about document not included in toctree Brad King (8): UseSWIG: Fix when Java is enabled as a language VS: Fix VCTargetsPath detection Android: Fix support for CMAKE_SYSROOT without CMAKE_SYSROOT_COMPILE expat: Update script to get Expat 2.2.3 expat: Update CMake build for 2.2.3 Tests: Simplify RunCMake.find_package PackageRoot case regexes find_*: Disable the PACKAGE_ROOT search path group for CMake 3.9 CMake 3.9.1 Chuck Atkins (3): find_package: Add missing PACKAGE_ROOT_PATH search path implementation. find_package: Fix PACKAGE_ROOT test to check find_pacakge(CONFIG) mode. find_package: Split PACKAGE_ROOT tests to work with smaller regex Craig Scott (1): FindJava: Allow early access version trailing string to be mixed case Cristian Adam (1): FindBoost: pop policy stack before returning Expat Upstream (1): expat 2017-08-02 (97c6bd01) Laurent Rineau (1): server: Fix crash on missing cache entries Rechi Rechi (1): FindJava: fix hint for windows jre 1.6 Ruslan Baratov (1): Help: Fix module and function names in CMP0069 examples Sebastian Holtermann (1): Autogen: Always create AUTOMOC/AUTOUIC include directory From robert.maynard at kitware.com Thu Aug 10 17:15:00 2017 From: robert.maynard at kitware.com (Robert Maynard) Date: Thu, 10 Aug 2017 17:15:00 -0400 Subject: [CMake] Advice on converting legacy project to modern CMake In-Reply-To: References: Message-ID: > Which leads to a question I have for the Kitware types here. What should I suggest to my Linux enterprise distribution users? Can they simply download and use the latest Linux binary version of CMake that is distributed by Kitware or are there library version incompatibilities that make that option non-viable? Alternatively, if such users want to build modern CMake for themselves can they do that or do system library incompatibilities stop them in that case as well? The official CMake binaries are built using a static libstdc++ and static glibc so they should be able to work on any x86_64 linux machine. On Mon, Aug 7, 2017 at 4:53 PM, Alan W. Irwin wrote: > On 2017-08-07 11:35-0000 Bj?rn Blissing wrote: > >> 1. Which version if CMake should I target? I.e. Which version should > > I require in my cmake_minimum_required() statement? > > I would suggest either > > cmake_minimum_required(VERSION 3.6.2 FATAL_ERROR) > > or > > cmake_minimum_required(VERSION 3.7.2 FATAL_ERROR) > > depending on whether the Cygwin platform (currently only making > 3.6.2 available) is important to your users or not. > > Cygwin is important to PLplot so we recently adopted 3.6.2 as the > minimum version choice as the compromise between two goals: > > (1) We wanted to maximize the version of policies > (which are set by cmake_minimum_required) since the latest > version of policies typically make a lot of sense to us > in terms of eliminating subtle build-system bugs. > > (2) We wanted to minimize the minimum version to maximize the > percentage of our users who will have that minimum version or higher > available from the official binary CMake version that is supplied by > their software distribution. > > 3.6.2 currently satisfies goal (1) reasonably well because it is not too far > behind the latest version 3.9.0 in terms of policy. > > 3.6.2 also satisfies goal (2) reasonably well. The major exception > here is the so-called Linux "enterprise-class" distributions who go > out of their way to **only** support old versions of Linux software > because their customers somehow feel more comfortable with that. For > example, as far as I can tell from google searches, it looks like > RedHat Linux Enterprise versions still only support CMake-2. > > Which leads to a question I have for the Kitware types here. What > should I suggest to my Linux enterprise distribution users? Can they > simply download and use the latest Linux binary version of CMake that > is distributed by Kitware or are there library version > incompatibilities that make that option non-viable? Alternatively, if > such users want to build modern CMake for themselves can they do that > or do system library incompatibilities stop them in that case as well? > > If we ignore the "enterprise-class" users, then Debian stable supports > 3.7.2. Debian tends to be a bit of a late adopter so as far as I know > every other non-enterprise Linux distribution and the various *BSD > distributions supports that version of CMake or higher. And I know > that is also true for MinGW-w64/MSYS2 and the Mac OS X distributions > (Homebrew, MacPorts, and Fink). So I plan to bump the minimum version > we support to 3.7.2 as soon as Cygwin (currently only supporting > 3.6.2) falls into line with the rest. > > I haven't mentioned the Windows MSVC platform here yet which is also > important to us. But those users are given no official choice of > CMake as a binary download so they likely take another viable choice > which is to download, install, and use a Kitware binary version of > CMake for Windows, and as far as I know all released versions of > CMake-3 (as well as CMake-2) are available that way. > > In any case, for whatever minimum version of CMake you adopt, you > should test your build system for that version as well as at least the > latest CMake version. > > Alan > __________________________ > Alan W. Irwin > > Astronomical research affiliation with Department of Physics and Astronomy, > University of Victoria (astrowww.phys.uvic.ca). > > Programming affiliations with the FreeEOS equation-of-state > implementation for stellar interiors (freeeos.sf.net); the Time > Ephemerides project (timeephem.sf.net); PLplot scientific plotting > software package (plplot.sf.net); the libLASi project > (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); > and the Linux Brochure Project (lbproject.sf.net). > __________________________ > > Linux-powered Science > __________________________ > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake From robin.verschueren at gmail.com Fri Aug 11 06:19:23 2017 From: robin.verschueren at gmail.com (Robin Verschueren) Date: Fri, 11 Aug 2017 10:19:23 +0000 Subject: [CMake] Platform dSPACE In-Reply-To: References: Message-ID: I've got a follow-up question about cross-compiling for dSpace. My Toolchain file so far: set(CMAKE_SYSTEM_NAME dSpace) list(APPEND CMAKE_MODULE_PATH ${CMAKE_CURRENT_LIST_DIR}) file(TO_CMAKE_PATH "C:\\Program Files\\dSPACE RCPHIL 2016-B" DSPACE_TOOLS) set(DSPACE_PPCTOOLS ${DSPACE_TOOLS}/Compiler/PPCTools) find_program(CMAKE_C_COMPILER NAMES ${DSPACE_PPCTOOLS}/bin/mccppc.exe) find_program(CMAKE_C_COMPILER NAMES ${DSPACE_PPCTOOLS}/bin/cccppc.exe) find_program(CMAKE_MAKE_PROGRAM ${DSPACE_TOOLS}/Exe/DSMAKE.EXE) set(CMAKE_FIND_ROOT_PATH ${DSPACE_PPCTOOLS}) set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER) set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY) set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY) CMake is actually able to locate the C compiler (called "mccppc.exe") and CMake thus tries to compile a test program ('CompilerIdC.c'). I can compile this source file 'by hand' with said compiler. However, from CMake (which automatically uses MSBuild.exe), I get the error output below. How can I circumvent MSBuild.exe and/or the attempted loading of the SDK? Do I forget to set some other important variables (e.g. CMAKE_MAKE_PROGRAM seems to be ignored?) The C compiler "C:/Program Files/dSPACE RCPHIL 2016-B/Compiler/PPCTools/bin/mccppc.exe" is not able to compile a simple test program. It fails with the following output: Compiling the C compiler identification source file "CMakeCCompilerId.c" failed. Compiler: C:/Program Files/dSPACE RCPHIL 2016-B/Compiler/PPCTools/bin/mccppc.exe Build flags: Id flags: The output was: 1 ? Microsoft (R) Build Engine version 15.1.1012.6693 Copyright (C) Microsoft Corporation. All rights reserved. Build started 8/11/2017 11:34:36 AM. Project "C:\Users\SYSCOP\Documents\GitHub\acados-master\build\CMakeFiles\3.8.2\CompilerIdC\CompilerIdC.vcxproj" on node 1 (default targets). C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\VC\VCTargets\Platforms\Win32\PlatformToolsets\v141\Toolset.targets(34,5): error MSB8036: The Windows SDK version 8.1 was not found. Install the required version of Windows SDK or change the SDK version in the project property pages or by right-clicking the solution and selecting "Retarget solution". [C:\Users\SYSCOP\Documents\GitHub\acados-master\build\CMakeFiles\3.8.2\CompilerIdC\CompilerIdC.vcxproj] Done Building Project "C:\Users\SYSCOP\Documents\GitHub\acados-master\build\CMakeFiles\3.8.2\CompilerIdC\CompilerIdC.vcxproj" (default targets) -- FAILED. Build FAILED. On Fri, 23 Jun 2017 at 22:37 Robin Verschueren wrote: > Dear Nils, > > Perfect! This was exactly what I was looking for. > It works, and the CMAKE_INCLUDE_FLAG_C > is not overwritten. > > Thanks, > Robin > > > On Fri, 23 Jun 2017 at 13:29 Nils Gladitz wrote: > >> On 23.06.2017 21:47, Robin Verschueren wrote: >> >> Dear CMake, >> >> We are trying to build our application for the dSPACE embedded system >> (www.dspace.com), more specifically their MicroAutobox-II. This makes >> use of a specific compiler called mccppc (Microtec C/C++ PowerPC >> compiler). >> >> I was following the instructions on this wiki page >> , when I got the following >> warning, >> when trying to use a custom 'Toolchain' file: >> >> System is unknown to cmake, create: >> >> Platform/dSPACE to use this system, please send your config file to >> >> cmake at www.cmake.org so it can be added to cmake >> >> We would be glad to send it to you when it is finished, but in the >> meantime, >> we cannot debug our toolchain file because of above warning. >> >> Is there a way of including it without having to include it in the >> official CMake >> distribution? I tried setting CMAKE_MODULE_PATH but that did not help.. >> >> >> In the Toolchain file: >> set(CMAKE_SYSTEM_NAME dSPACE) >> >> list(APPEND CMAKE_MODULE_PATH ${CMAKE_CURRENT_LIST_DIR}) >> >> ... >> >> Then having Platform/dSPACE.cmake next to your toolchain file should work >> (works for me). >> >> >> Nils >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From petr.kmoch at gmail.com Fri Aug 11 08:29:29 2017 From: petr.kmoch at gmail.com (Petr Kmoch) Date: Fri, 11 Aug 2017 14:29:29 +0200 Subject: [CMake] Referencing an OBJECT library In-Reply-To: References: Message-ID: Hi Edward. "the reference to that OBJECT library is through $" - that is not quite true. When you're referring to the object library target itself (e.g. reading its properties), you use its name just like with any other target: get_property(someVar TARGET xxx PROPERTY TYPE) However, the genex $ is used when you're specifying that the sources of another target yyy are to include the objects comprising the object library xxx: add_executable(yyy main.cpp $) Here, you're not dealing with the object library xxx itself, but with the objects from which it's composed, so you're referring to these objects explicitly. It's quite similar to how you'd use other properties of a target: target_sources(yyy $) would similarly add all sources of target xxx to the target yyy. Petr On 20 July 2017 at 22:57, Edward Diener wrote: > According to the CMake docs for an OBJECT library called, let's say, > 'xxx', the reference to that OBJECT library is through > $. I understand this but I am curious about the reason > for such syntax. After all a STATIC or SHARED library 'xxx' you can just > use xxx to refer to the library. Why the difference in CMake syntax > reference between OBJECT libraries added with the add_library command and > STATIC or SHARED libraries added with the add_library command ? > > -- > > 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/opensou > rce/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake > -------------- next part -------------- An HTML attachment was scrubbed... URL: From petr.kmoch at gmail.com Fri Aug 11 09:10:02 2017 From: petr.kmoch at gmail.com (Petr Kmoch) Date: Fri, 11 Aug 2017 15:10:02 +0200 Subject: [CMake] Append to property COMPILE_DEFINITIONS In-Reply-To: References: <54d1cf26-73f3-3fb1-9b17-ce459b7b6cb3@xgm.de> <5fb55910-c604-f279-4e07-9974724b72ce@xgm.de> <62824131-1bbb-72f0-b7d3-454223ad2f4c@xgm.de> Message-ID: On 24 July 2017 at 04:32, Florian Lindner wrote: > > > [snip] > > Still, I don't undertand what is wrong with: > > set_property(GLOBAL APPEND PROPERTY COMPILE_DEFINITIONS > $<$:-FOO>) > > ? > What's wrong is that there is no such global property. See the list of global properties: https://cmake.org/cmake/help/latest/manual/cmake-properties.7.html#properties-of-global-scope COMPILE_DEFINITIONS is not among them. You're therefore effectively creating a new user-defined global property, which of course has no effect on CMake's behaviour. Petr -------------- next part -------------- An HTML attachment was scrubbed... URL: From wesley.hoke at gmail.com Fri Aug 11 09:31:40 2017 From: wesley.hoke at gmail.com (Wesley Smith) Date: Fri, 11 Aug 2017 06:31:40 -0700 Subject: [CMake] OBJECT Libraries and linking against targets Message-ID: Hi, I understand vaguely why OBJECT libraries can't link against other targets, but I don't think the restriction in place needs to be so constrained. Consider the following: * A target is being create as an OBJECT library * A number of other targets are defined as INTERFACE target where they only set include paths, compiler options, etc. How is it possible to communicate the dependencies expressed in an INTERFACE target to an OBJECT library? So far the only method I've found that works is to use a handful of generator expressions, which seems like a lot of work for something that would just work if I could "link" the INTERFACE library against the OBJECT library. Here's what I have to do: target_compile_features(tgt PUBLIC $ ) target_include_directories(tgt PUBLIC $ ) target_compile_options(tgt PUBLIC $ $ ) target_compile_definitions(tgt PUBLIC $ ) thanks! wes -------------- next part -------------- An HTML attachment was scrubbed... URL: From aborsic at gmail.com Fri Aug 11 12:02:39 2017 From: aborsic at gmail.com (Andrea Borsic) Date: Fri, 11 Aug 2017 18:02:39 +0200 Subject: [CMake] Possible bug/incompatibility FindCUDA with Visual Studio 2017 In-Reply-To: References: <34349be0-0c38-b897-925f-734760644c44@gmail.com> Message-ID: <6ee40e5e-04dd-3f6f-0d44-4c512e9b8aa1@gmail.com> Hi, Thanks for your pointers, problem solved. I have upgraded to CMake 3.9.1 (I don't think this matters though) and I switched to using the new CUDA CMake support as at your point 3). I am also using CUDA 9 RC which supports VS2017 (I was testing under CUDA 8 / CUDA 9 earlier, but just forgot to mention this). Now all builds successfully. I am attaching the updated CMakeLists.txt file for the record. Thanks, Best Regards, Andrea On 8/10/2017 4:28 PM, Robert Maynard wrote: > So you are going to have two issues. > > 1. The FindCUDA module has not been updated to handle VS2017. The > issue is that the VCInstallDir variable now returns a different > relative path to the compiler than it previously did. If you can > determine the new logic a patch fixing this behavior be great. > > 2. It doesn't look like CUDA 8.0 supports VS2017 ( > http://docs.nvidia.com/cuda/cuda-installation-guide-microsoft-windows/index.html#system-requirements > ). > > 3. You could also look at using the new CMake 3.9 cuda support ( > https://devblogs.nvidia.com/parallelforall/building-cuda-applications-cmake/ > ). > > On Thu, Aug 10, 2017 at 5:49 AM, Andrea Borsic wrote: >> Hi All, >> >> I am working on this platform: >> >> Windows 10 64bit >> Visual Studio 2015 Community Edition >> Visual Studio 2017 Community Edition >> CUDA 8.0 >> CMake 3.9 >> >> I am in the middle of switching from VS2015 to VS2017, but CUDA projects >> fail to properly compile under VS2017 as the compiler/linker fail to find >> tools on the path setup by CMake. I believe this is bug/incompatibly of the >> CMake FindCUDA module with VS2017. >> >> To reproduce the problem I am attaching a tiny project >> >> main.cu is a minimal CUDA example from the web >> CMakeLists.txt is a CMake file that leads to a successful build under VS2015 >> and unsuccessful under VS2017 >> Output VS2015 is the output from building the project under VS2015 (all >> targets built OK) >> Output VS2017 is the output from building the project under VS2015 (1 target >> OK one target fails) >> >> I have noticed also that oddly under VS2017 an "x64" and "main.dir" >> directories are created outside the build dir, and at the level of the >> source directory. >> >> I thought of reporting this to the list, and any help is welcome, >> >> Thank you and Best Regards, >> >> Andrea >> >> >> -- >> >> Powered by www.kitware.com >> >> Please keep messages on-topic and check the CMake FAQ at: >> http://www.cmake.org/Wiki/CMake_FAQ >> >> Kitware offers various services to support the CMake community. For more >> information on each offering, please visit: >> >> CMake Support: http://cmake.org/cmake/help/support.html >> CMake Consulting: http://cmake.org/cmake/help/consulting.html >> CMake Training Courses: http://cmake.org/cmake/help/training.html >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/cmake -------------- next part -------------- #include // // Nearly minimal CUDA example. // Compile with: // // nvcc -o example example.cu // #define N 1000 // // A function marked __global__ // runs on the GPU but can be called from // the CPU. // // This function multiplies the elements of an array // of ints by 2. // // The entire computation can be thought of as running // with one thread per array element with blockIdx.x // identifying the thread. // // The comparison i>>(da, db); // // Copy output array from GPU back to CPU. // cudaMemcpy(hb, db, N*sizeof(int), cudaMemcpyDeviceToHost); for (int i = 0; i References: Message-ID: On 2017-08-10 10:28, rleigh at codelibre.net wrote: > On 2017-08-10 09:50, Jones J.W. wrote: >> I'm building my code on Linux using the g++ flags "-std=c++11". This >> means that I must link with the libIce++11 libraries instead of >> libIce. >> >> The FindIce module, however as no provision for choosing these >> libraries thus resulting in unresolved symbols at link time. >> >> I tried getting around the problem by simply listing Ice++11 as a >> COMPONENT which works in Linux but the same CMakeLists.txt file in >> Windows won't work as there is no Ice++11. Currently I have resolved >> this by having two calls to the FindIce module inside an IF( MSVC ) >> conditional. Looking at the NuGet packages, I can see Ice++11 on Windows; it's named Ice37++11[d].lib. Helpfully not following the existing conventions on the other platforms and previous Ice releases, but I think I've worked around this now. >> Would it be possible to add a flag to tell the FindIce module whether >> C++11 is being used or not? > > FindIce certainly needs an update for Ice 3.7. > > Regarding C++11, their approach here is certainly a bit unorthodox as > well as being inconsistent between platforms, and FindIce will need to > deal with that unfortunate situation. Since the old and new APIs are > incompatible, and you have to explicitly opt-in to using the new one, > I don't think that using "-std=c++11" on its own is sufficient reason > to select the C++11 library? Can you use the old API with a C++11 > compiler? It might be best to have a set of C++11 component names, > and map these to the appropriate library names on Linux (separate > libs) and Windows (not separate), if that would make the intent of the > user clear and unambiguous. > > I will try to look at this, but I'm a little busy with other things at > the moment, and so it's not at top of my list. If you wanted to > propose a change an/or open a merge request that would certainly be > welcome. I have done some preliminary work here: https://gitlab.kitware.com/rleigh/cmake/commits/ice-3.7.0 It's working on Linux, but not yet finding the libraries on Windows when using the NuGet distribution of the libraries. This is likely some minor bug which I need to identify; it's using all the correct paths and suffixes that I can see. If you would like to give this a go and help fix the detection on Windows, that would be really helpful. I've left some extra debugging messages in to trace how find_library is working. If you set CMAKE_PREFIX_PATH to the location where the NuGet packages live, it should automatically detect the package name. Do we have any existing conventions within CMake for finding libraries within such packages? Should the package be listed specifically on CMAKE_PREFIX_PATH, or is finding the package itself on the path acceptable? Or should both be supported? Regards, Roger From eike at sf-mail.de Fri Aug 11 15:15:34 2017 From: eike at sf-mail.de (Rolf Eike Beer) Date: Fri, 11 Aug 2017 21:15:34 +0200 Subject: [CMake] FindIce module and C++11 In-Reply-To: References: Message-ID: <1760717.VzMv5jAEb2@daneel.sf-tec.de> Am Donnerstag, 10. August 2017, 10:28:31 schrieb rleigh at codelibre.net: > On 2017-08-10 09:50, Jones J.W. wrote: > > I'm building my code on Linux using the g++ flags "-std=c++11". This > > means that I must link with the libIce++11 libraries instead of > > libIce. > > > > The FindIce module, however as no provision for choosing these > > libraries thus resulting in unresolved symbols at link time. > > > > I tried getting around the problem by simply listing Ice++11 as a > > COMPONENT which works in Linux but the same CMakeLists.txt file in > > Windows won't work as there is no Ice++11. Currently I have resolved > > this by having two calls to the FindIce module inside an IF( MSVC ) > > conditional. > > > > Would it be possible to add a flag to tell the FindIce module whether > > C++11 is being used or not? > > FindIce certainly needs an update for Ice 3.7. To me this smells like an imported target with a generator expression that uses the C++11 or other lib depending on the used interface of the target. No idea if that is possible, but that would be the direction I would search in. Greetings, Eike -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part. URL: From rleigh at codelibre.net Fri Aug 11 20:31:29 2017 From: rleigh at codelibre.net (Roger Leigh) Date: Sat, 12 Aug 2017 01:31:29 +0100 Subject: [CMake] FindIce module and C++11 In-Reply-To: <1760717.VzMv5jAEb2@daneel.sf-tec.de> References: <1760717.VzMv5jAEb2@daneel.sf-tec.de> Message-ID: On 11/08/17 20:15, Rolf Eike Beer wrote: > Am Donnerstag, 10. August 2017, 10:28:31 schrieb rleigh at codelibre.net: >> On 2017-08-10 09:50, Jones J.W. wrote: >>> I'm building my code on Linux using the g++ flags "-std=c++11". This >>> means that I must link with the libIce++11 libraries instead of >>> libIce. >>> >>> The FindIce module, however as no provision for choosing these >>> libraries thus resulting in unresolved symbols at link time. >>> >>> I tried getting around the problem by simply listing Ice++11 as a >>> COMPONENT which works in Linux but the same CMakeLists.txt file in >>> Windows won't work as there is no Ice++11. Currently I have resolved >>> this by having two calls to the FindIce module inside an IF( MSVC ) >>> conditional. >>> >>> Would it be possible to add a flag to tell the FindIce module whether >>> C++11 is being used or not? >> >> FindIce certainly needs an update for Ice 3.7. > > To me this smells like an imported target with a generator expression that > uses the C++11 or other lib depending on the used interface of the target. No > idea if that is possible, but that would be the direction I would search in. I'm unsure, but I suspect it's not appropriate. I'm currently treating them as separate libraries because whether C++11 is used by the compiler is orthogonal to whether you're using the C++11 Ice API (and code generator). Ice generates language-specific interfaces and implementations from abstract definitions, and it treats C++ and C++11 as essentially different languages. You need to explicitly opt into using C++11 in the interface definitions for code generation, and with respect to which libraries you link to. For anyone using Ice who would like to test, I've opened https://gitlab.kitware.com/cmake/cmake/merge_requests/1137for testing and review. Would be helpful if anyone wanting to use Ice 3.7 could give it a try, but equally if you're using 3.[3456] it would be great to know if there are any regressions. I'll be testing Ice 3.5, but no longer have any of the others lying around (3.3 can probably be removed, it's so old and unsupported). Regards, Roger From lectem at gmail.com Sat Aug 12 03:28:52 2017 From: lectem at gmail.com (=?UTF-8?Q?Cl=C3=A9ment_Gregoire?=) Date: Sat, 12 Aug 2017 07:28:52 +0000 Subject: [CMake] INTERPROCEDURAL_OPTIMIZATION still not using CMAKE__COMPILER_AR In-Reply-To: <1b51fca7-fc81-b9a3-213e-b9cdb93bc3d2@kitware.com> References: <597337ee.c7331c0a.1dac4.a299@mx.google.com> <1b51fca7-fc81-b9a3-213e-b9cdb93bc3d2@kitware.com> Message-ID: Should I file a bug report for this? Le mar. 1 ao?t 2017 ? 22:52, Brad King a ?crit : > On 07/22/2017 07:33 AM, lectem at gmail.com wrote: > > So I downloaded the 3.9 release and thought my LTO nightmares we over but > > cmake still isn't using CMAKE__COMPILER_AR when linking on MSYS. > > The problem is that this code: > > > https://gitlab.kitware.com/cmake/cmake/blob/v3.9.0/Modules/Platform/Windows-GNU.cmake#L117-127 > > inserts use of the archiver into the main linking process as a way > to work around Windows command-line length limits. Since it is > using the archiver as part of linking instead of just for creating > a static library, our logic to switch to CMAKE__COMPILER_AR > for LTO is not triggering. > > -Brad > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lectem at gmail.com Sat Aug 12 04:48:38 2017 From: lectem at gmail.com (=?UTF-8?Q?Cl=C3=A9ment_Gregoire?=) Date: Sat, 12 Aug 2017 08:48:38 +0000 Subject: [CMake] DLL handling under CMake In-Reply-To: References: <2114FB31-FF89-4461-8713-75FAA7179E4E@hendrik-sattler.de> <590add90.925c1c0a.632e2.33a2@mx.google.com> <612ed9d4-61ce-b3a2-2a39-887deeceb3b2@dynamixyz.com> Message-ID: Sorry for not answering before, cmake generator expressions do not work with "if". It mostly only work with target_*** stuff. That's why I'm using a custom target to evaluate the current target properties and run a cmake script with those values. Le lun. 17 juil. 2017 ? 10:47, Louis-Paul CORDIER a ?crit : > Hi, > > I bump this question again for DLL library handling. Still I have the > issue with my dependency "scanner" in my previous email that can't evaluate > if a target with a generator expression is a valid one or not. > > if(NOT TARGET "$<$:Foo_lib>") > # will never go into this statement > endif() > > Thanks, > > LP > Le 04/07/2017 ? 10:19, Louis-Paul CORDIER a ?crit : > > Hi, > > Thank you very much for this code snippet. However I don't like the > fixup_bundle function, as it takes the first dll that it found to be linked > against. > > I also did a try with a dependency scanning function. It is quiet long to > write, but I guess it is the cleanest way to handle DLL under Windows. > Note: I still have an issue with this function. Indeed, if user uses > Generator expressions for library dependencies, it will not work. > e.g: > add_library(Foo_lib IMPORTED GLOBAL) > # ... set location properties > target_link_libraries(${PROJECT_NAME} optimized > $<$:Foo_lib>) > > Any idea for a workaround? What do you think about this CMake code? > > Also, I would see a real benefit to add a LINK_DEPENDENT_LIBRARIES > property (inspired of IMPORTED_LINK_DEPENDENT_LIBRARIES) to each target > that could be automatically filled by each target_link_libraries() calls. > > > > # This function scan all dependencies of a project recursively, and > retrieve all shared > # library associated with it. > # Prerequisite: your upstream CMakeLists.txt must make use of > add_library(foo SHARED IMPORTED GLOBAL), > # and fill the following properties on the imported target: > # set_target_properties(foo PROPERTIES IMPORTED_IMPLIB "path_to_foo.lib") > # set_target_properties(foo PROPERTIES IMPORTED_LOCATION "path_to_foo.dll") > # set_target_properties(foo PROPERTIES IMPORTED_LINK_DEPENDENT_LIBRARIES > "path_to_dll_on_which_foo_depends.dll") > # GLOBAL keyword is important as it allows downstream CMakeLists.txt to > scan dependencies. > > # Input parameters: > # dep_to_scan: your downstream project > # config_to_scan: configuration to use for the scanning. > # output_variable: variable in which the function stores the result. > > # Usage: > # RECURSIVE_SCAN(my_app Release DLLS) > # install(FILES ${DLLS} > # DESTINATION release > # CONFIGURATIONS Release) > > set(COUNT 0) > function(RECURSIVE_SCAN dep_to_scan config_to_scan output_variable) > > MATH(EXPR COUNT "${COUNT}+1") > string(RANDOM LENGTH ${COUNT} ALPHABET "-" SPACES) > > message("${SPACES} Scanning ${dep_to_scan}") > if(NOT TARGET ${dep_to_scan}) > MATH(EXPR COUNT "${COUNT}-1") > #message("${dep_to_scan} Is not target") > return() > endif() > > > get_target_property(_is_imported ${dep_to_scan} IMPORTED) > if(_is_imported) > > # We need to check if the imported library rely on other shared > libraries. > get_target_property(_dependent_dll ${_lib} > IMPORTED_LINK_DEPENDENT_LIBRARIES_${config_to_scan}) > if(NOT _dependent_dll) > get_target_property(_dependent_dll ${_lib} > IMPORTED_LINK_DEPENDENT_LIBRARIES) > endif() > > if(_dependent_dll) > list(APPEND ${output_variable} ${_dependent_dll}) > endif() > > > #Otherwise, check if it is a shared library. (LOCATION variable can be > # either .lib or DLL regarding of the type of library.) > get_target_property(_TYPE ${dep_to_scan} TYPE) > > if(NOT _TYPE STREQUAL STATIC_LIBRARY) > get_target_property(_dll_found ${dep_to_scan} > LOCATION_${config_to_scan}) > if(_dll_found) > list(APPEND ${output_variable} ${_dll_found}) > endif() > > endif() > > message("${SPACES}- DLL found: (${${output_variable}})") > > endif(_is_imported) > > get_target_property(_libraries ${dep_to_scan} INTERFACE_LINK_LIBRARIES) > > if(_libraries) > foreach(_lib ${_libraries}) > RECURSIVE_SCAN(${_lib} ${config_to_scan} ${output_variable}) > endforeach() > endif() > > # If we reach our first recursion, we need to clean the list of > # DLL in order to remove duplicates. > MATH(EXPR COUNT "${COUNT}-1") > > if(${COUNT} EQUAL 0) > list(REMOVE_DUPLICATES ${output_variable}) > endif() > > set(${output_variable} ${${output_variable}} PARENT_SCOPE) > > endfunction(RECURSIVE_SCAN) > > > Best regards, > > Louis-Paul CORDIER > Le 04/05/2017 ? 09:51, lectem at gmail.com a ?crit : > > I managed to get it working by using an intermediate script. > > One might want to generate the script instead of using the ? RUN_IT ? > variable trick. > > This was only tested on Windows, but seems to work fine. > > Put the following code in a xxxxxx.cmake file, include it from your > CMakeLists.txt and enjoy. > > > > > > # This is a helper script to run BundleUtilities fixup_bundle as postbuild > > # for a target. The primary use case is to copy .DLLs to the build > directory for > > # the Windows platform. It allows generator expressions to be used to > determine > > # the binary location > > # > > # Usage : run_fixup(TARGET LIBS DIRS) > > # - TARGET : A cmake target > > # - See fixup_bundle for LIBS and DIRS arguments > > > > if(RUN_IT) > > # Script ran by the add_custom_command > > include(BundleUtilities) > > fixup_bundle("${TO_FIXUP_FILE}" "${TO_FIXUP_LIBS}" > "${TO_FIXUP_DIRS}") > > # End of script ran by the add_custom_command > > else() > > > > set(THIS_FILE ${CMAKE_CURRENT_LIST_FILE}) > > message(${THIS_FILE}) > > function(run_fixup _target _libs _dirs) > > message(${THIS_FILE}) > > add_custom_command( > > TARGET ${_target} POST_BUILD > > COMMAND ${CMAKE_COMMAND} -DRUN_IT:BOOL=ON > -DTO_FIXUP_FILE=$ -DTO_FIXUP_LIBS=${_libs} > -DTO_FIXUP_DIRS=${_dirs} -P ${THIS_FILE} > > COMMENT "Fixing up dependencies for > ${_target}" > > VERBATIM > > ) > > > > endfunction() > > > > endif() > > > > > > *De : *Cl?ment Gregoire > *Envoy? le :*jeudi 4 mai 2017 08:37 > *? : *Hendrik Sattler ; Louis-Paul CORDIER > ; Cmake Mailing List > *Objet :*Re: [CMake] DLL handling under CMake > > > > I'd also be interested in this. I saw an old mail in the ML about this, > but it seems fixup_bundle is old and cant use generator expressions, making > it hard to use (I don't want to hardcode the executable path). > > > > Do you have a sample for this ? > > CMake would really benefit from having those features made more accessible > instead of everyone having to write its own script > > Le sam. 29 avr. 2017 22:10, Hendrik Sattler a > ?crit : > > > > Am 27. April 2017 10:43:50 MESZ schrieb Louis-Paul CORDIER < > lp.cordier at dynamixyz.com>: > >This steps are tedious and I'm wondering if there is a mechanism that > >exists or that have to be imagined to make the DLL nightmare end. > > I use BundleUtilities to achieve the copying of DLL files to the > installation directory. The main problem for this is to enumerate the > needed directories. > > I use the same for copying DLL files to the output directory to ease > debugging. > > The advantage is the inspection of the exe for really needed DLL files. > This AUTOMATICALLY handles the case debug vs. release. > > HS > > -- > Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail > gesendet. > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake > > > > > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake -------------- next part -------------- An HTML attachment was scrubbed... URL: From lectem at gmail.com Sun Aug 13 18:48:46 2017 From: lectem at gmail.com (Lectem) Date: Mon, 14 Aug 2017 00:48:46 +0200 Subject: [CMake] Coverage support In-Reply-To: <68681502128322@web48g.yandex.ru> References: <830e6f57fc2ac7c49c5180f96f99468d@sf-mail.de> <921131502119366@web44g.yandex.ru> <68681502128322@web48g.yandex.ru> Message-ID: <5990d750.4aa8df0a.d4fbb.51ef@mx.google.com> OK so I ended up doing the following?: Use a cmake script to detect coverage support and set up a new build type + Let CTest run GCov for me Final result can be seen here?: https://github.com/Lectem/cpp-boilerplate link to the Coverage setup script?: https://github.com/Lectem/cpp-boilerplate/blob/master/cmake/Coverage.cmake This seems to be the best way to do it, it is non-intrusive (no CMAKE__FLAGS clobbering), plus it really does check that it is supported by the compiler, not assuming versions or anything. If the user wants to build with coverage support, he only needs to use the Coverage build type, and can change the flags from the cache if needed, just as he would do with any build type. Also not that since the codecov.io script runs GCov by default, using CTest is facultative. (but you need to make sure the gcov version matches the compiler used). De?: Konstantin Tokarev Envoy? le?:lundi 7 ao?t 2017 19:52 ??: Cl?ment Gregoire; Rolf Eike Beer Cc?: Cmake Mailing List Objet?:Re: [CMake] Coverage support ? ? 07.08.2017, 20:50, "Cl?ment Gregoire" : This is mainly why I started this thread, I want to know the best way to do this without using those variables. CMAKE_lang_FLAGS is a pain as soon as someone wants to use add_subdirectory (be it to add an external project or your project being used in another) or a user wants to change the value. Those variables should really only be set by the toolchain file or from the command-line. There's ExternalProject for this purpose ? Other solutions were mentioned in my first mail, the easiest one being to add a new build type. The other option is to uses something like a special script that will set those variables before your Cmakelists.txt (ie a toolchain file). ? ? Le lun. 7 ao?t 2017 ? 17:22, Konstantin Tokarev a ?crit?: ? 07.08.2017, 17:24, "Cl?ment Gregoire" : >> I usually stop reading Cmakelists.txt as soon as I see this >> >> set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wall -pedantic -pthread -g -O0 >> -fprofile-arcs -ftest-coverage") >> >> The pthread thing there is likely wrong anyway, and the -Wall is entirely optional. The other things are needed, otherwise gcov will not produce any useful output. > > I don't have an issue with the flags per se, but with the usage of set(CMAKE_CXX_FLAGS). Setting flags like that should be banned from modern cmake scripts. How can one set global compiler flags without use of CMAKE_CXX_FLAGS or setting flags for each individual target? > >> Also you need to use the SETUP_TARGET_FOR_COVERAGE for every single test >> target, which seems to be a difficult to scale on big projects >> >> No, you don't. It's entirely fine if you just run "make test" as I do in OSM2go. > From what I saw in the documentation of the script : > >> # Param _testrunner The name of the target which runs the tests > > It seems to call directly the command named _testrunner, which is somehow confirmed from the cmakelists : > >> # src/CMakelists.txt >> add_executable(tests ${TEST_FILES}) >> >> # Linking up all libraries >> >> target_link_libraries(tests complex) >> >> add_test(NAME example_test COMMAND tests) >> # CMakelists.txt >> setup_target_for_coverage(${PROJECT_NAME}_coverage tests coverage) > From this I deduce that you need to call setup_target_for_coverage for each different test executable. > > 2017-08-07 13:37 GMT+02:00 Rolf Eike Beer : >> Am 2017-08-07 11:06, schrieb Cl?ment Gregoire: >> I usually stop reading Cmakelists.txt as soon as I see this >> >> set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wall -pedantic -pthread -g -O0 >> -fprofile-arcs -ftest-coverage") >> >> The pthread thing there is likely wrong anyway, and the -Wall is entirely optional. The other things are needed, otherwise gcov will not produce any useful output. >> >> Also you need to use the SETUP_TARGET_FOR_COVERAGE for every single test >> target, which seems to be a difficult to scale on big projects >> >> No, you don't. It's entirely fine if you just run "make test" as I do in OSM2go. >> >> Eike >> -- >> >> Powered by www.kitware.com >> >> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ >> >> Kitware offers various services to support the CMake community. For more information on each offering, please visit: >> >> CMake Support: http://cmake.org/cmake/help/support.html >> CMake Consulting: http://cmake.org/cmake/help/consulting.html >> CMake Training Courses: http://cmake.org/cmake/help/training.html >> >> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/cmake > ,-- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake --? Regards, Konstantin ? ? --? Regards, Konstantin ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From Ch.Ehrlicher at gmx.de Mon Aug 14 04:22:55 2017 From: Ch.Ehrlicher at gmx.de (Christian Ehrlicher) Date: Mon, 14 Aug 2017 10:22:55 +0200 Subject: [CMake] cmake-gui on windows and qt5 dlls Message-ID: An HTML attachment was scrubbed... URL: From craig.scott at crascit.com Mon Aug 14 05:47:31 2017 From: craig.scott at crascit.com (Craig Scott) Date: Mon, 14 Aug 2017 19:47:31 +1000 Subject: [CMake] cmake-gui on windows and qt5 dlls In-Reply-To: References: Message-ID: This is a common problem, not just with CMake. I'm wondering if there's any real need for cmake-gui to be on the PATH at all, since it will usually be invoked by a desktop or menu icon. At the moment though, it is in the same directory as the cmake and ccmake executables which have a much stronger case for being on the PATH. There's a reasonable argument that cmake-gui should be in a different directory, then it wouldn't be an issue if shared Qt libs were used rather than static. I'll bring this up on the developer mailing list and see what discussions yield. On Mon, Aug 14, 2017 at 6:22 PM, Christian Ehrlicher wrote: > Hi, > > I recently upgraded from cmake 3.3 to 3.9 on windows and got some problems > during my build because it looks like the pre-compile binaries for windows > are now shipping Qt5 - dlls instead static compile libs (since 3.5 afaics). > The problem is, that I had the path to cmake *before* the path to my own > Qt5 libaries. So during the build / run of my application, the wrong > libraries were loaded and I got a symbol lookup error. > Would it be possible to use the static Qt5 libs instead or maybe prefix > the Qt5 libs shipped with cmake-gui somehow? > > Thx, > Christian > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/ > opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake > -- Craig Scott Melbourne, Australia https://crascit.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From lectem at gmail.com Mon Aug 14 07:05:19 2017 From: lectem at gmail.com (=?UTF-8?Q?Cl=C3=A9ment_Gregoire?=) Date: Mon, 14 Aug 2017 11:05:19 +0000 Subject: [CMake] cmake-gui on windows and qt5 dlls In-Reply-To: References: Message-ID: Wouldn't it be possible to move it to a subfolder with the DLLs and put a link next to cmake and ccmake? Executables look for DLLs in their directory and it wouldn't pollute the PATH I personally like to be able to launch it through the command line, it is faster than looking for it and then browse for the folder. Le lun. 14 ao?t 2017 ? 11:48, Craig Scott a ?crit : > This is a common problem, not just with CMake. I'm wondering if there's > any real need for cmake-gui to be on the PATH at all, since it will usually > be invoked by a desktop or menu icon. At the moment though, it is in the > same directory as the cmake and ccmake executables which have a much > stronger case for being on the PATH. There's a reasonable argument that > cmake-gui should be in a different directory, then it wouldn't be an issue > if shared Qt libs were used rather than static. I'll bring this up on the > developer mailing list and see what discussions yield. > > > On Mon, Aug 14, 2017 at 6:22 PM, Christian Ehrlicher > wrote: > >> Hi, >> >> I recently upgraded from cmake 3.3 to 3.9 on windows and got some >> problems during my build because it looks like the pre-compile binaries for >> windows are now shipping Qt5 - dlls instead static compile libs (since 3.5 >> afaics). >> The problem is, that I had the path to cmake *before* the path to my own >> Qt5 libaries. So during the build / run of my application, the wrong >> libraries were loaded and I got a symbol lookup error. >> Would it be possible to use the static Qt5 libs instead or maybe prefix >> the Qt5 libs shipped with cmake-gui somehow? >> >> Thx, >> Christian >> >> -- >> >> Powered by www.kitware.com >> >> Please keep messages on-topic and check the CMake FAQ at: >> http://www.cmake.org/Wiki/CMake_FAQ >> >> Kitware offers various services to support the CMake community. For more >> information on each offering, please visit: >> >> CMake Support: http://cmake.org/cmake/help/support.html >> CMake Consulting: http://cmake.org/cmake/help/consulting.html >> CMake Training Courses: http://cmake.org/cmake/help/training.html >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/cmake >> > > > > -- > Craig Scott > Melbourne, Australia > https://crascit.com > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake -------------- next part -------------- An HTML attachment was scrubbed... URL: From craig.scott at crascit.com Mon Aug 14 09:00:36 2017 From: craig.scott at crascit.com (Craig Scott) Date: Mon, 14 Aug 2017 23:00:36 +1000 Subject: [CMake] cmake-gui on windows and qt5 dlls In-Reply-To: References: Message-ID: On Mon, Aug 14, 2017 at 9:05 PM, Cl?ment Gregoire wrote: > Wouldn't it be possible to move it to a subfolder with the DLLs and put a > link next to cmake and ccmake? Executables look for DLLs in their directory > and it wouldn't pollute the PATH > Symlinks are available on NTFS filesystems from Vista onwards. If the user installed CMake on, say, a FAT filesystem instead or on an old XP box (CMake appears to still try to support that), then symlinks wouldn't be available from what I can make out. One could potentially use a forwarding script of some kind though to achieve essentially the same thing. I personally like to be able to launch it through the command line, it is > faster than looking for it and then browse for the folder. > > Le lun. 14 ao?t 2017 ? 11:48, Craig Scott a > ?crit : > >> This is a common problem, not just with CMake. I'm wondering if there's >> any real need for cmake-gui to be on the PATH at all, since it will usually >> be invoked by a desktop or menu icon. At the moment though, it is in the >> same directory as the cmake and ccmake executables which have a much >> stronger case for being on the PATH. There's a reasonable argument that >> cmake-gui should be in a different directory, then it wouldn't be an issue >> if shared Qt libs were used rather than static. I'll bring this up on the >> developer mailing list and see what discussions yield. >> >> >> On Mon, Aug 14, 2017 at 6:22 PM, Christian Ehrlicher > > wrote: >> >>> Hi, >>> >>> I recently upgraded from cmake 3.3 to 3.9 on windows and got some >>> problems during my build because it looks like the pre-compile binaries for >>> windows are now shipping Qt5 - dlls instead static compile libs (since 3.5 >>> afaics). >>> The problem is, that I had the path to cmake *before* the path to my own >>> Qt5 libaries. So during the build / run of my application, the wrong >>> libraries were loaded and I got a symbol lookup error. >>> Would it be possible to use the static Qt5 libs instead or maybe prefix >>> the Qt5 libs shipped with cmake-gui somehow? >>> >>> Thx, >>> Christian >>> >>> -- >>> >>> Powered by www.kitware.com >>> >>> Please keep messages on-topic and check the CMake FAQ at: >>> http://www.cmake.org/Wiki/CMake_FAQ >>> >>> Kitware offers various services to support the CMake community. For more >>> information on each offering, please visit: >>> >>> CMake Support: http://cmake.org/cmake/help/support.html >>> CMake Consulting: http://cmake.org/cmake/help/consulting.html >>> CMake Training Courses: http://cmake.org/cmake/help/training.html >>> >>> Visit other Kitware open-source projects at http://www.kitware.com/ >>> opensource/opensource.html >>> >>> Follow this link to subscribe/unsubscribe: >>> http://public.kitware.com/mailman/listinfo/cmake >>> >> >> >> >> -- >> Craig Scott >> Melbourne, Australia >> https://crascit.com >> -- >> >> Powered by www.kitware.com >> >> Please keep messages on-topic and check the CMake FAQ at: >> http://www.cmake.org/Wiki/CMake_FAQ >> >> Kitware offers various services to support the CMake community. For more >> information on each offering, please visit: >> >> CMake Support: http://cmake.org/cmake/help/support.html >> CMake Consulting: http://cmake.org/cmake/help/consulting.html >> CMake Training Courses: http://cmake.org/cmake/help/training.html >> >> Visit other Kitware open-source projects at http://www.kitware.com/ >> opensource/opensource.html >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/cmake > > -- Craig Scott Melbourne, Australia https://crascit.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.maynard at kitware.com Mon Aug 14 09:23:20 2017 From: robert.maynard at kitware.com (Robert Maynard) Date: Mon, 14 Aug 2017 09:23:20 -0400 Subject: [CMake] cmake-gui on windows and qt5 dlls In-Reply-To: References: Message-ID: More importantly symlinks are restricted to administrator accounts only in Windows Vista/7/8. Windows 10 with Developer Mode activated allows none-elevated accounts to create symlinks. This is important as CMake does ship non-installer windows binaries. On Mon, Aug 14, 2017 at 9:00 AM, Craig Scott wrote: > > > On Mon, Aug 14, 2017 at 9:05 PM, Cl?ment Gregoire wrote: >> >> Wouldn't it be possible to move it to a subfolder with the DLLs and put a >> link next to cmake and ccmake? Executables look for DLLs in their directory >> and it wouldn't pollute the PATH > > > Symlinks are available on NTFS filesystems from Vista onwards. If the user > installed CMake on, say, a FAT filesystem instead or on an old XP box (CMake > appears to still try to support that), then symlinks wouldn't be available > from what I can make out. One could potentially use a forwarding script of > some kind though to achieve essentially the same thing. > > >> I personally like to be able to launch it through the command line, it is >> faster than looking for it and then browse for the folder. >> >> >> Le lun. 14 ao?t 2017 ? 11:48, Craig Scott a >> ?crit : >>> >>> This is a common problem, not just with CMake. I'm wondering if there's >>> any real need for cmake-gui to be on the PATH at all, since it will usually >>> be invoked by a desktop or menu icon. At the moment though, it is in the >>> same directory as the cmake and ccmake executables which have a much >>> stronger case for being on the PATH. There's a reasonable argument that >>> cmake-gui should be in a different directory, then it wouldn't be an issue >>> if shared Qt libs were used rather than static. I'll bring this up on the >>> developer mailing list and see what discussions yield. >>> >>> >>> On Mon, Aug 14, 2017 at 6:22 PM, Christian Ehrlicher >>> wrote: >>>> >>>> Hi, >>>> >>>> I recently upgraded from cmake 3.3 to 3.9 on windows and got some >>>> problems during my build because it looks like the pre-compile binaries for >>>> windows are now shipping Qt5 - dlls instead static compile libs (since 3.5 >>>> afaics). >>>> The problem is, that I had the path to cmake *before* the path to my own >>>> Qt5 libaries. So during the build / run of my application, the wrong >>>> libraries were loaded and I got a symbol lookup error. >>>> Would it be possible to use the static Qt5 libs instead or maybe prefix >>>> the Qt5 libs shipped with cmake-gui somehow? >>>> >>>> Thx, >>>> Christian >>>> >>>> -- >>>> >>>> Powered by www.kitware.com >>>> >>>> Please keep messages on-topic and check the CMake FAQ at: >>>> http://www.cmake.org/Wiki/CMake_FAQ >>>> >>>> Kitware offers various services to support the CMake community. For more >>>> information on each offering, please visit: >>>> >>>> CMake Support: http://cmake.org/cmake/help/support.html >>>> CMake Consulting: http://cmake.org/cmake/help/consulting.html >>>> CMake Training Courses: http://cmake.org/cmake/help/training.html >>>> >>>> Visit other Kitware open-source projects at >>>> http://www.kitware.com/opensource/opensource.html >>>> >>>> Follow this link to subscribe/unsubscribe: >>>> http://public.kitware.com/mailman/listinfo/cmake >>> >>> >>> >>> >>> -- >>> Craig Scott >>> Melbourne, Australia >>> https://crascit.com >>> -- >>> >>> Powered by www.kitware.com >>> >>> Please keep messages on-topic and check the CMake FAQ at: >>> http://www.cmake.org/Wiki/CMake_FAQ >>> >>> Kitware offers various services to support the CMake community. For more >>> information on each offering, please visit: >>> >>> CMake Support: http://cmake.org/cmake/help/support.html >>> CMake Consulting: http://cmake.org/cmake/help/consulting.html >>> CMake Training Courses: http://cmake.org/cmake/help/training.html >>> >>> Visit other Kitware open-source projects at >>> http://www.kitware.com/opensource/opensource.html >>> >>> Follow this link to subscribe/unsubscribe: >>> http://public.kitware.com/mailman/listinfo/cmake > > > > > -- > Craig Scott > Melbourne, Australia > https://crascit.com > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake From annulen at yandex.ru Mon Aug 14 09:21:09 2017 From: annulen at yandex.ru (Konstantin Tokarev) Date: Mon, 14 Aug 2017 16:21:09 +0300 Subject: [CMake] cmake-gui on windows and qt5 dlls In-Reply-To: References: Message-ID: <384781502716869@web5o.yandex.ru> 14.08.2017, 16:01, "Craig Scott" : > On Mon, Aug 14, 2017 at 9:05 PM, Cl?ment Gregoire wrote: >> Wouldn't it be possible to move it to a subfolder with the DLLs and put a link next to cmake and ccmake? Executables look for DLLs in their directory and it wouldn't pollute the PATH > > Symlinks are available on NTFS filesystems from Vista onwards. If the user installed CMake on, say, a FAT filesystem instead or on an old XP box (CMake appears to still try to support that), then symlinks wouldn't be available from what I can make out. One could potentially use a forwarding script of some kind though to achieve essentially the same thing. This tool might be useful https://github.com/chocolatey/shimgen > >> I personally like to be able to launch it through the command line, it is faster than looking for it and then browse for the folder. >> >> Le lun. 14 ao?t 2017 ? 11:48, Craig Scott a ?crit?: >>> This is a common problem, not just with CMake. I'm wondering if there's any real need for cmake-gui to be on the PATH at all, since it will usually be invoked by a desktop or menu icon. At the moment though, it is in the same directory as the cmake and ccmake executables which have a much stronger case for being on the PATH. There's a reasonable argument that cmake-gui should be in a different directory, then it wouldn't be an issue if shared Qt libs were used rather than static. I'll bring this up on the developer mailing list and see what discussions yield. >>> >>> On Mon, Aug 14, 2017 at 6:22 PM, Christian Ehrlicher wrote: >>>> Hi, >>>> >>>> I recently upgraded from cmake 3.3 to 3.9 on windows and got some problems during my build because it looks like the pre-compile binaries for windows are now shipping Qt5 - dlls instead static compile libs (since 3.5 afaics). >>>> The problem is, that I had the path to cmake *before* the path to my own Qt5 libaries. So during the build / run of my application, the wrong libraries were loaded and I got a symbol lookup error. >>>> Would it be possible to use the static Qt5 libs instead or maybe prefix the Qt5 libs shipped with cmake-gui somehow? >>>> >>>> Thx, >>>> Christian >>>> >>>> -- >>>> >>>> Powered by www.kitware.com >>>> >>>> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ >>>> >>>> Kitware offers various services to support the CMake community. For more information on each offering, please visit: >>>> >>>> CMake Support: http://cmake.org/cmake/help/support.html >>>> CMake Consulting: http://cmake.org/cmake/help/consulting.html >>>> CMake Training Courses: http://cmake.org/cmake/help/training.html >>>> >>>> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html >>>> >>>> Follow this link to subscribe/unsubscribe: >>>> http://public.kitware.com/mailman/listinfo/cmake >>> >>> -- >>> Craig Scott >>> Melbourne, Australia >>> https://crascit.com >>> -- >>> >>> Powered by www.kitware.com >>> >>> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ >>> >>> Kitware offers various services to support the CMake community. For more information on each offering, please visit: >>> >>> CMake Support: http://cmake.org/cmake/help/support.html >>> CMake Consulting: http://cmake.org/cmake/help/consulting.html >>> CMake Training Courses: http://cmake.org/cmake/help/training.html >>> >>> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html >>> >>> Follow this link to subscribe/unsubscribe: >>> http://public.kitware.com/mailman/listinfo/cmake > > -- > Craig Scott > Melbourne, Australia > https://crascit.com > ,-- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake --? Regards, Konstantin From lectem at gmail.com Mon Aug 14 09:33:47 2017 From: lectem at gmail.com (Lectem) Date: Mon, 14 Aug 2017 15:33:47 +0200 Subject: [CMake] cmake-gui on windows and qt5 dlls In-Reply-To: References: Message-ID: <5991a6bd.d8a0df0a.adc85.7614@mx.google.com> Right, as mentionned by Craig Scott, a script might do the trick?? Just a cmake-gui.bat that calls cmake-gui.exe should work. De?: Robert Maynard Envoy? le?:lundi 14 ao?t 2017 15:24 ??: Craig Scott Cc?: Cl?ment Gregoire; CMake Objet?:Re: [CMake] cmake-gui on windows and qt5 dlls More importantly symlinks are restricted to administrator accounts only in Windows Vista/7/8. Windows 10 with Developer Mode activated allows none-elevated accounts to create symlinks. This is important as CMake does ship non-installer windows binaries. On Mon, Aug 14, 2017 at 9:00 AM, Craig Scott wrote: > > > On Mon, Aug 14, 2017 at 9:05 PM, Cl?ment Gregoire wrote: >> >> Wouldn't it be possible to move it to a subfolder with the DLLs and put a >> link next to cmake and ccmake? Executables look for DLLs in their directory >> and it wouldn't pollute the PATH > > > Symlinks are available on NTFS filesystems from Vista onwards. If the user > installed CMake on, say, a FAT filesystem instead or on an old XP box (CMake > appears to still try to support that), then symlinks wouldn't be available > from what I can make out. One could potentially use a forwarding script of > some kind though to achieve essentially the same thing. > > >> I personally like to be able to launch it through the command line, it is >> faster than looking for it and then browse for the folder. >> >> >> Le lun. 14 ao?t 2017 ? 11:48, Craig Scott a >> ?crit : >>> >>> This is a common problem, not just with CMake. I'm wondering if there's >>> any real need for cmake-gui to be on the PATH at all, since it will usually >>> be invoked by a desktop or menu icon. At the moment though, it is in the >>> same directory as the cmake and ccmake executables which have a much >>> stronger case for being on the PATH. There's a reasonable argument that >>> cmake-gui should be in a different directory, then it wouldn't be an issue >>> if shared Qt libs were used rather than static. I'll bring this up on the >>> developer mailing list and see what discussions yield. >>> >>> >>> On Mon, Aug 14, 2017 at 6:22 PM, Christian Ehrlicher >>> wrote: >>>> >>>> Hi, >>>> >>>> I recently upgraded from cmake 3.3 to 3.9 on windows and got some >>>> problems during my build because it looks like the pre-compile binaries for >>>> windows are now shipping Qt5 - dlls instead static compile libs (since 3.5 >>>> afaics). >>>> The problem is, that I had the path to cmake *before* the path to my own >>>> Qt5 libaries. So during the build / run of my application, the wrong >>>> libraries were loaded and I got a symbol lookup error. >>>> Would it be possible to use the static Qt5 libs instead or maybe prefix >>>> the Qt5 libs shipped with cmake-gui somehow? >>>> >>>> Thx, >>>> Christian >>>> >>>> -- >>>> >>>> Powered by www.kitware.com >>>> >>>> Please keep messages on-topic and check the CMake FAQ at: >>>> http://www.cmake.org/Wiki/CMake_FAQ >>>> >>>> Kitware offers various services to support the CMake community. For more >>>> information on each offering, please visit: >>>> >>>> CMake Support: http://cmake.org/cmake/help/support.html >>>> CMake Consulting: http://cmake.org/cmake/help/consulting.html >>>> CMake Training Courses: http://cmake.org/cmake/help/training.html >>>> >>>> Visit other Kitware open-source projects at >>>> http://www.kitware.com/opensource/opensource.html >>>> >>>> Follow this link to subscribe/unsubscribe: >>>> http://public.kitware.com/mailman/listinfo/cmake >>> >>> >>> >>> >>> -- >>> Craig Scott >>> Melbourne, Australia >>> https://crascit.com >>> -- >>> >>> Powered by www.kitware.com >>> >>> Please keep messages on-topic and check the CMake FAQ at: >>> http://www.cmake.org/Wiki/CMake_FAQ >>> >>> Kitware offers various services to support the CMake community. For more >>> information on each offering, please visit: >>> >>> CMake Support: http://cmake.org/cmake/help/support.html >>> CMake Consulting: http://cmake.org/cmake/help/consulting.html >>> CMake Training Courses: http://cmake.org/cmake/help/training.html >>> >>> Visit other Kitware open-source projects at >>> http://www.kitware.com/opensource/opensource.html >>> >>> Follow this link to subscribe/unsubscribe: >>> http://public.kitware.com/mailman/listinfo/cmake > > > > > -- > Craig Scott > Melbourne, Australia > https://crascit.com > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmh at ucar.edu Mon Aug 14 17:33:09 2017 From: dmh at ucar.edu (dmh at ucar.edu) Date: Mon, 14 Aug 2017 15:33:09 -0600 Subject: [CMake] Distinguish two header files with same name using cmake In-Reply-To: <5991a6bd.d8a0df0a.adc85.7614@mx.google.com> References: <5991a6bd.d8a0df0a.adc85.7614@mx.google.com> Message-ID: <9a19fc69-df4c-356c-7018-3a8550c5326c@ucar.edu> I have the following situation using cmake 1. Running windows 7 2. Both cygwin and visual studio (VS) community edition (version 14) installed. 3. I am building with visual studio as my compiler. 4. Cygwin has winsock2.h in /usr/include/w32api The VS community edition does not have winsock2.h 5. Note that some older (non community edition) versions of VS do have winsock2.h defined. 6. CHECK_INCLUDE_FILE("winsock2.h", HAVE_WINSOCK2_H) returns true because it is finding the cygwin version instead of the VS version. The question is how do I see if the installed VS has winsock2.h defined while ignoring any cygwin version. The reason I need to know this is that the presence of winsock2.h in VS is causing a conflict with another package (libcurl). I can work around the conflict if I know if the VS installation has winsock2.h (or not). I speculate that I need to prevent CMake from searching w32api. I considered using CMAKE_REQUIRED_INClUDES to remove a directory (/usr/include/w32api), but I can see no way to do that. Suggestions? From irwin at beluga.phys.uvic.ca Mon Aug 14 23:30:56 2017 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Mon, 14 Aug 2017 20:30:56 -0700 (PDT) Subject: [CMake] Distinguish two header files with same name using cmake In-Reply-To: <9a19fc69-df4c-356c-7018-3a8550c5326c@ucar.edu> References: <5991a6bd.d8a0df0a.adc85.7614@mx.google.com> <9a19fc69-df4c-356c-7018-3a8550c5326c@ucar.edu> Message-ID: On 2017-08-14 15:33-0600 dmh at ucar.edu wrote: > I have the following situation using cmake > 1. Running windows 7 > 2. Both cygwin and visual studio (VS) community edition (version 14) > installed. > 3. I am building with visual studio as my compiler. > 4. Cygwin has winsock2.h in /usr/include/w32api > The VS community edition does not have winsock2.h > 5. Note that some older (non community edition) versions of VS do have > winsock2.h defined. > 6. CHECK_INCLUDE_FILE("winsock2.h", HAVE_WINSOCK2_H) returns true > because it is finding the cygwin version instead of the VS version. > > The question is how do I see if the installed VS has winsock2.h defined while > ignoring any cygwin version. > > The reason I need to know this is that the presence of winsock2.h in VS is > causing a conflict with another package (libcurl). I can work around the > conflict if I know if the VS installation has winsock2.h (or not). > > I speculate that I need to prevent CMake from searching w32api. > I considered using CMAKE_REQUIRED_INClUDES to remove a directory > (/usr/include/w32api), but I can see no way to do that. > > Suggestions? CMake pays close attention to environment variables (e.g., PATH) when finding what it thinks are system files. See the documentation of find_path, find_file, find_library, etc. So make sure there are no mentions of Cygwin locations in any of your enviroment variables to reduce the chances that Cygwin locations contaminate your VS build. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ From brianlheim at gmail.com Tue Aug 15 08:53:42 2017 From: brianlheim at gmail.com (brian heim) Date: Tue, 15 Aug 2017 08:53:42 -0400 Subject: [CMake] [CPack] hdiutil error while executing cpack on macOS Message-ID: Hi all, I'm getting an error trying to use CPack to create a macOS DragNDrop package. I tried to search for this message in the ML archives and elsewhere but wasn't able to find any conclusive solution, so I'm hoping someone with more experience with CPack may be able to help. My environment is: macOS 10.13 cmake/cpack 3.9.1 The output I'm getting is: CPack: Create package using DragNDrop CPack: Install projects CPack: - Install project: SuperCollider CPack: - Install component: Runtime CPack: - Install component: Unspecified CPack: Create package CPack Error: Error executing: /usr/bin/hdiutil convert "/Users/brianheim/git/supercollider/build/_CPack_Packages/OSX/DragNDrop/temp.dmg" -format UDBZ -imagekey zlib-level=9 -o "/Users/brianheim/git/supercollider/build/_CPack_Packages/OSX/DragNDrop/SuperCollider-3.9.dev-OSX/SuperCollider-3.9.dev-OSX.dmg" CPack Error: Error compressing disk image. CPack Error: Problem compressing the directory CPack Error: Error when generating package: SuperCollider The output with --debug is here: https://gist.github.com/brianlheim/de692727fb0fc1ef629baf9f2c89d89b And the contents of my CPackConfig.cmake file are here: https://gist.github.com/brianlheim/6d40b5c6b047b1a18e1160715aa163c7 This is a somewhat legacy project, so it's possible this used to work on an earlier version of CMake. I wouldn't know what version to compare it to, though. Thanks in advance. -Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From chuck.atkins at kitware.com Tue Aug 15 11:42:57 2017 From: chuck.atkins at kitware.com (Chuck Atkins) Date: Tue, 15 Aug 2017 11:42:57 -0400 Subject: [CMake] Failed to build C++ source with CMakeLists.txt In-Reply-To: References: Message-ID: Hi Jupiter, Compiling the C compiler identification source file "CMakeCCompilerId.c" > failed. > Compiler: /usr/local/gcc/4.9.1/bin/gcc > Build flags: /usr/local/cppcms/1.1.0/include > It looks like you have an errant "/usr/local/cppcms/1.1.0/include" set in your CFLAGS environment variable, or otherwise specified as a default argument to the compiler, which is obviously not a valid flag. - Chuck -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Tue Aug 15 12:45:31 2017 From: brad.king at kitware.com (Brad King) Date: Tue, 15 Aug 2017 12:45:31 -0400 Subject: [CMake] INTERPROCEDURAL_OPTIMIZATION still not using CMAKE__COMPILER_AR In-Reply-To: References: <597337ee.c7331c0a.1dac4.a299@mx.google.com> <1b51fca7-fc81-b9a3-213e-b9cdb93bc3d2@kitware.com> Message-ID: <2dd026a5-a2da-c4f4-8072-f6d7ff438d9a@kitware.com> On 08/12/2017 03:28 AM, Cl?ment Gregoire wrote: > Should I file a bug report for this? Yes, please. Thanks, -Brad From pawel.veselov at gmail.com Tue Aug 15 14:14:30 2017 From: pawel.veselov at gmail.com (Pawel Veselov) Date: Tue, 15 Aug 2017 11:14:30 -0700 Subject: [CMake] perpetually executed custom commands and timestamps Message-ID: Hello. I'm trying something I don't think is unreasonable. I need to have an automatically generated file, let's say version.h I have to run a custom command to generate it. The contents of the file depend on some external forces, the custom command m ay or may not change it (but it will always generate it if it is there). That header is then included in bunch of other files, creating multiple targets So, I created a custom command that has declared output of version.h, and have version.h included as sources for other (multiple) targets. This worked, but, of course, if the version.h is already there, the command wouldn't run. I couldn't find any way to force the command to run, so after reading this SO post: https://stackoverflow.com/questions/13920072, I added a PHONY output to the command, and dependency to the targets. This forced the command to run every time. However, when the command runs, but doesn't change the output file, there is some target that forces the file to be updated (the touch_nocreate). This causes the targets to both recompile and relink for no reason. Questions: 1) Can I make a custom command run every time, even if its target is present (without creating a PHONY target)? I don't want the 2) Can I turn the touching off? I don't think using TARGET based custom command is right, as it's a pre-build target activity, and such is not supported for !VS. I don't think using an ALL custom target is right, because custom target has no output files, and target-to-target dependency wouldn't correctly determine that I need that .h file in time. I would love to know what's the point of touch_no_create, really, I can't imagine a good reason the file is refreshed when it wasn't touched, it seems that the point would be to "cheat" the dependency resolution that way, which may have valid use cases, but as a forced default? Thank you, Pawel. -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.maynard at kitware.com Tue Aug 15 16:37:18 2017 From: robert.maynard at kitware.com (Robert Maynard) Date: Tue, 15 Aug 2017 16:37:18 -0400 Subject: [CMake] [CPack] hdiutil error while executing cpack on macOS In-Reply-To: References: Message-ID: Do better understand why the hdutil command is failing you should run it manually and add in the -verbose option. On Tue, Aug 15, 2017 at 8:53 AM, brian heim wrote: > Hi all, > > I'm getting an error trying to use CPack to create a macOS DragNDrop > package. I tried to search for this message in the ML archives and elsewhere > but wasn't able to find any conclusive solution, so I'm hoping someone with > more experience with CPack may be able to help. My environment is: > > macOS 10.13 > cmake/cpack 3.9.1 > > The output I'm getting is: > > CPack: Create package using DragNDrop > CPack: Install projects > CPack: - Install project: SuperCollider > CPack: - Install component: Runtime > CPack: - Install component: Unspecified > CPack: Create package > CPack Error: Error executing: /usr/bin/hdiutil convert > "/Users/brianheim/git/supercollider/build/_CPack_Packages/OSX/DragNDrop/temp.dmg" > -format UDBZ -imagekey zlib-level=9 -o > "/Users/brianheim/git/supercollider/build/_CPack_Packages/OSX/DragNDrop/SuperCollider-3.9.dev-OSX/SuperCollider-3.9.dev-OSX.dmg" > CPack Error: Error compressing disk image. > CPack Error: Problem compressing the directory > CPack Error: Error when generating package: SuperCollider > > The output with --debug is here: > https://gist.github.com/brianlheim/de692727fb0fc1ef629baf9f2c89d89b > > And the contents of my CPackConfig.cmake file are here: > https://gist.github.com/brianlheim/6d40b5c6b047b1a18e1160715aa163c7 > > This is a somewhat legacy project, so it's possible this used to work on an > earlier version of CMake. I wouldn't know what version to compare it to, > though. > > Thanks in advance. > > -Brian > > > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake From matwey.kornilov at gmail.com Thu Aug 17 09:10:13 2017 From: matwey.kornilov at gmail.com (Matwey V. Kornilov) Date: Thu, 17 Aug 2017 16:10:13 +0300 Subject: [CMake] CPackWIX and MS Visual Studio Redistributable *.MSM Message-ID: Hello, What is recommended way to locate and merge MS redistributable *.msm file into final *.msi installer produced by CPack and WIX? It seems to be a quite common task but I cannot find any mention. From drgutek at o2.pl Thu Aug 17 09:25:24 2017 From: drgutek at o2.pl (=?UTF-8?Q?drgutek=40o2=2Epl?=) Date: Thu, 17 Aug 2017 15:25:24 +0200 Subject: [CMake] =?utf-8?q?Create_relocatable_package_with_proper_autogene?= =?utf-8?q?rated_config_cmake?= Message-ID: <2184734b3a804baf9c5d762861d8ec0b@grupawp.pl> Hi, I have created cmake target, say A , and want to install it and create a Config file, so that the installed package could be relocatable. My code is: install(EXPORT ${PROJECT_NAME}Targets FILE ${PROJECT_NAME}Targets.cmake NAMESPACE ${PROJECT_NAME}:: DESTINATION ??? ) Here, I am having a problem with the proper destination. I want the Config file to be installed where ${CMAKE_INSTALL_PREFIX} points to. But when I put ${CMAKE_INSTALL_PREFIX} at ??? , my resulting ATargets.cmake file contains the line: set(_IMPORT_PREFIX "C:/Libraries/...") which is the actual value of ${CMAKE_INSTALL_PREFIX} . This _IMPORT_PREFIX is later prepended to the parameters of set_target_properties() command inside the auto-generated ATargets.cmake , resulting in hard coded paths, valid only on the installation system. I tried to use some generator expressions like <$IMPORT_PREFIX> in place of ??? , but this gave me an error at cmake generation. I also tried to omit DESTINATION which in my opinion should place the file in the location relative to ${CMAKE_INSTALL_PREFIX} , but cmake complained about it too. I got a suggesion on StackOverflow to use . (a dot) as my DESTINATION. This worked partially, in the way that I no longer have absolute _IMPORT_PREFIX. Unfortunately, the produced paths are still invalid: The generated ATargets.cmake contains: get_filename_component(_IMPORT "${CMAKE_CURRENT_LIST_FILE}" PATH) get_filename_component(_IMPORT "${_IMPORT_PREFIX}" PATH) and the second line above is not necessary, it trims the path too much by one folder. Do you have any ideas how to solve it? Best regards, Piotr -------------- next part -------------- An HTML attachment was scrubbed... URL: From lectem at gmail.com Thu Aug 17 14:55:17 2017 From: lectem at gmail.com (=?UTF-8?Q?Cl=C3=A9ment_Gregoire?=) Date: Thu, 17 Aug 2017 20:55:17 +0200 Subject: [CMake] cmake-gui on windows and qt5 dlls In-Reply-To: <5991a6bd.d8a0df0a.adc85.7614@mx.google.com> References: <5991a6bd.d8a0df0a.adc85.7614@mx.google.com> Message-ID: So the following worked for me: move cmake-gui.exe, all dlls and qt.conf to a "cmkae/bin/gui" subfolder create a batch file named cmake-gui.bat with the following content @echo off start "" /B "%~dp0\gui\cmake-gui.exe" %* And modify qt.conf so that the plugin directory is correct : from Plugins = ../plugins to Plugins = ../../plugins I'm not (yet) on the dev mailing list, so feel free to transfer the solution there. 2017-08-14 15:33 GMT+02:00 Lectem : > Right, as mentionned by Craig Scott, a script might do the trick ? Just a > cmake-gui.bat that calls cmake-gui.exe should work. > > > > *De : *Robert Maynard > *Envoy? le :*lundi 14 ao?t 2017 15:24 > *? : *Craig Scott > *Cc : *Cl?ment Gregoire ; CMake > *Objet :*Re: [CMake] cmake-gui on windows and qt5 dlls > > > > More importantly symlinks are restricted to administrator accounts > > only in Windows Vista/7/8. Windows 10 with Developer Mode activated > > allows none-elevated accounts to create symlinks. > > > > This is important as CMake does ship non-installer windows binaries. > > > > On Mon, Aug 14, 2017 at 9:00 AM, Craig Scott > wrote: > > > > > > > > > On Mon, Aug 14, 2017 at 9:05 PM, Cl?ment Gregoire > wrote: > > >> > > >> Wouldn't it be possible to move it to a subfolder with the DLLs and put > a > > >> link next to cmake and ccmake? Executables look for DLLs in their > directory > > >> and it wouldn't pollute the PATH > > > > > > > > > Symlinks are available on NTFS filesystems from Vista onwards. If the > user > > > installed CMake on, say, a FAT filesystem instead or on an old XP box > (CMake > > > appears to still try to support that), then symlinks wouldn't be > available > > > from what I can make out. One could potentially use a forwarding script > of > > > some kind though to achieve essentially the same thing. > > > > > > > > >> I personally like to be able to launch it through the command line, it > is > > >> faster than looking for it and then browse for the folder. > > >> > > >> > > >> Le lun. 14 ao?t 2017 ? 11:48, Craig Scott a > > >> ?crit : > > >>> > > >>> This is a common problem, not just with CMake. I'm wondering if there's > > >>> any real need for cmake-gui to be on the PATH at all, since it will > usually > > >>> be invoked by a desktop or menu icon. At the moment though, it is in > the > > >>> same directory as the cmake and ccmake executables which have a much > > >>> stronger case for being on the PATH. There's a reasonable argument that > > >>> cmake-gui should be in a different directory, then it wouldn't be an > issue > > >>> if shared Qt libs were used rather than static. I'll bring this up on > the > > >>> developer mailing list and see what discussions yield. > > >>> > > >>> > > >>> On Mon, Aug 14, 2017 at 6:22 PM, Christian Ehrlicher > > >>> wrote: > > >>>> > > >>>> Hi, > > >>>> > > >>>> I recently upgraded from cmake 3.3 to 3.9 on windows and got some > > >>>> problems during my build because it looks like the pre-compile > binaries for > > >>>> windows are now shipping Qt5 - dlls instead static compile libs > (since 3.5 > > >>>> afaics). > > >>>> The problem is, that I had the path to cmake *before* the path to my > own > > >>>> Qt5 libaries. So during the build / run of my application, the wrong > > >>>> libraries were loaded and I got a symbol lookup error. > > >>>> Would it be possible to use the static Qt5 libs instead or maybe > prefix > > >>>> the Qt5 libs shipped with cmake-gui somehow? > > >>>> > > >>>> Thx, > > >>>> Christian > > >>>> > > >>>> -- > > >>>> > > >>>> Powered by www.kitware.com > > >>>> > > >>>> Please keep messages on-topic and check the CMake FAQ at: > > >>>> http://www.cmake.org/Wiki/CMake_FAQ > > >>>> > > >>>> Kitware offers various services to support the CMake community. For > more > > >>>> information on each offering, please visit: > > >>>> > > >>>> CMake Support: http://cmake.org/cmake/help/support.html > > >>>> CMake Consulting: http://cmake.org/cmake/help/consulting.html > > >>>> CMake Training Courses: http://cmake.org/cmake/help/training.html > > >>>> > > >>>> Visit other Kitware open-source projects at > > >>>> http://www.kitware.com/opensource/opensource.html > > >>>> > > >>>> Follow this link to subscribe/unsubscribe: > > >>>> http://public.kitware.com/mailman/listinfo/cmake > > >>> > > >>> > > >>> > > >>> > > >>> -- > > >>> Craig Scott > > >>> Melbourne, Australia > > >>> https://crascit.com > > >>> -- > > >>> > > >>> Powered by www.kitware.com > > >>> > > >>> Please keep messages on-topic and check the CMake FAQ at: > > >>> http://www.cmake.org/Wiki/CMake_FAQ > > >>> > > >>> Kitware offers various services to support the CMake community. For > more > > >>> information on each offering, please visit: > > >>> > > >>> CMake Support: http://cmake.org/cmake/help/support.html > > >>> CMake Consulting: http://cmake.org/cmake/help/consulting.html > > >>> CMake Training Courses: http://cmake.org/cmake/help/training.html > > >>> > > >>> Visit other Kitware open-source projects at > > >>> http://www.kitware.com/opensource/opensource.html > > >>> > > >>> Follow this link to subscribe/unsubscribe: > > >>> http://public.kitware.com/mailman/listinfo/cmake > > > > > > > > > > > > > > > -- > > > Craig Scott > > > Melbourne, Australia > > > https://crascit.com > > > > > > -- > > > > > > Powered by www.kitware.com > > > > > > Please keep messages on-topic and check the CMake FAQ at: > > > http://www.cmake.org/Wiki/CMake_FAQ > > > > > > Kitware offers various services to support the CMake community. For more > > > information on each offering, please visit: > > > > > > CMake Support: http://cmake.org/cmake/help/support.html > > > CMake Consulting: http://cmake.org/cmake/help/consulting.html > > > CMake Training Courses: http://cmake.org/cmake/help/training.html > > > > > > Visit other Kitware open-source projects at > > > http://www.kitware.com/opensource/opensource.html > > > > > > Follow this link to subscribe/unsubscribe: > > > http://public.kitware.com/mailman/listinfo/cmake > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From konstantin at podsvirov.pro Thu Aug 17 15:05:16 2017 From: konstantin at podsvirov.pro (Konstantin Podsvirov) Date: Thu, 17 Aug 2017 22:05:16 +0300 Subject: [CMake] cmake-gui on windows and qt5 dlls In-Reply-To: References: <5991a6bd.d8a0df0a.adc85.7614@mx.google.com> Message-ID: <245101502996716@web35o.yandex.ru> Hello Cl?ment Gregoire! 17.08.2017, 21:55, "Cl?ment Gregoire" : > So the following worked for me: > > move cmake-gui.exe, all dlls and qt.conf to a "cmkae/bin/gui" subfolder > > create a batch file named > > cmake-gui.bat > > with the following content > > @echo off > start "" /B "%~dp0\gui\cmake-gui.exe" %* > > And modify qt.conf so that the plugin directory is correct : > > from????? Plugins = ../plugins???? to??? Plugins = ../../plugins > > I'm not (yet) on the dev mailing list, so feel free to transfer the solution there. Please review dev mailing list archive too: http://public.kitware.com/pipermail/cmake-developers/2017-August/030228.html (may be I forgot /B option) > 2017-08-14 15:33 GMT+02:00 Lectem : >> Right, as mentionned by Craig Scott, a script might do the trick?? Just a cmake-gui.bat that calls cmake-gui.exe should work. >> >> De?: Robert Maynard >> Envoy? le?:lundi 14 ao?t 2017 15:24 >> ??: Craig Scott >> Cc?: Cl?ment Gregoire; CMake >> Objet?:Re: [CMake] cmake-gui on windows and qt5 dlls >> >> More importantly symlinks are restricted to administrator accounts >> >> only in Windows Vista/7/8. Windows 10 with Developer Mode activated >> >> allows none-elevated accounts to create symlinks. >> >> This is important as CMake does ship non-installer windows binaries. >> >> On Mon, Aug 14, 2017 at 9:00 AM, Craig Scott wrote: >> >>> >> >>> >> >>> On Mon, Aug 14, 2017 at 9:05 PM, Cl?ment Gregoire wrote: >> >>>> >> >>>> Wouldn't it be possible to move it to a subfolder with the DLLs and put a >> >>>> link next to cmake and ccmake? Executables look for DLLs in their directory >> >>>> and it wouldn't pollute the PATH >> >>> >> >>> >> >>> Symlinks are available on NTFS filesystems from Vista onwards. If the user >> >>> installed CMake on, say, a FAT filesystem instead or on an old XP box (CMake >> >>> appears to still try to support that), then symlinks wouldn't be available >> >>> from what I can make out. One could potentially use a forwarding script of >> >>> some kind though to achieve essentially the same thing. >> >>> >> >>> >> >>>> I personally like to be able to launch it through the command line, it is >> >>>> faster than looking for it and then browse for the folder. >> >>>> >> >>>> >> >>>> Le lun. 14 ao?t 2017 ? 11:48, Craig Scott a >> >>>> ?crit : >> >>>>> >> >>>>> This is a common problem, not just with CMake. I'm wondering if there's >> >>>>> any real need for cmake-gui to be on the PATH at all, since it will usually >> >>>>> be invoked by a desktop or menu icon. At the moment though, it is in the >> >>>>> same directory as the cmake and ccmake executables which have a much >> >>>>> stronger case for being on the PATH. There's a reasonable argument that >> >>>>> cmake-gui should be in a different directory, then it wouldn't be an issue >> >>>>> if shared Qt libs were used rather than static. I'll bring this up on the >> >>>>> developer mailing list and see what discussions yield. >> >>>>> >> >>>>> >> >>>>> On Mon, Aug 14, 2017 at 6:22 PM, Christian Ehrlicher >> >>>>> wrote: >> >>>>>> >> >>>>>> Hi, >> >>>>>> >> >>>>>> I recently upgraded from cmake 3.3 to 3.9 on windows and got some >> >>>>>> problems during my build because it looks like the pre-compile binaries for >> >>>>>> windows are now shipping Qt5 - dlls instead static compile libs (since 3.5 >> >>>>>> afaics). >> >>>>>> The problem is, that I had the path to cmake *before* the path to my own >> >>>>>> Qt5 libaries. So during the build / run of my application, the wrong >> >>>>>> libraries were loaded and I got a symbol lookup error. >> >>>>>> Would it be possible to use the static Qt5 libs instead or maybe prefix >> >>>>>> the Qt5 libs shipped with cmake-gui somehow? >> >>>>>> >> >>>>>> Thx, >> >>>>>> Christian >> >>>>>> >> >>>>>> -- >> >>>>>> >> >>>>>> Powered by www.kitware.com >> >>>>>> >> >>>>>> Please keep messages on-topic and check the CMake FAQ at: >> >>>>>> http://www.cmake.org/Wiki/CMake_FAQ >> >>>>>> >> >>>>>> Kitware offers various services to support the CMake community. For more >> >>>>>> information on each offering, please visit: >> >>>>>> >> >>>>>> CMake Support: http://cmake.org/cmake/help/support.html >> >>>>>> CMake Consulting: http://cmake.org/cmake/help/consulting.html >> >>>>>> CMake Training Courses: http://cmake.org/cmake/help/training.html >> >>>>>> >> >>>>>> Visit other Kitware open-source projects at >> >>>>>> http://www.kitware.com/opensource/opensource.html >> >>>>>> >> >>>>>> Follow this link to subscribe/unsubscribe: >> >>>>>> http://public.kitware.com/mailman/listinfo/cmake >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> -- >> >>>>> Craig Scott >> >>>>> Melbourne, Australia >> >>>>> https://crascit.com >> >>>>> -- >> >>>>> >> >>>>> Powered by www.kitware.com >> >>>>> >> >>>>> Please keep messages on-topic and check the CMake FAQ at: >> >>>>> http://www.cmake.org/Wiki/CMake_FAQ >> >>>>> >> >>>>> Kitware offers various services to support the CMake community. For more >> >>>>> information on each offering, please visit: >> >>>>> >> >>>>> CMake Support: http://cmake.org/cmake/help/support.html >> >>>>> CMake Consulting: http://cmake.org/cmake/help/consulting.html >> >>>>> CMake Training Courses: http://cmake.org/cmake/help/training.html >> >>>>> >> >>>>> Visit other Kitware open-source projects at >> >>>>> http://www.kitware.com/opensource/opensource.html >> >>>>> >> >>>>> Follow this link to subscribe/unsubscribe: >> >>>>> http://public.kitware.com/mailman/listinfo/cmake >> >>> >> >>> >> >>> >> >>> >> >>> -- >> >>> Craig Scott >> >>> Melbourne, Australia >> >>> https://crascit.com >> >>> >> >>> -- >> >>> >> >>> Powered by www.kitware.com >> >>> >> >>> Please keep messages on-topic and check the CMake FAQ at: >> >>> http://www.cmake.org/Wiki/CMake_FAQ >> >>> >> >>> Kitware offers various services to support the CMake community. For more >> >>> information on each offering, please visit: >> >>> >> >>> CMake Support: http://cmake.org/cmake/help/support.html >> >>> CMake Consulting: http://cmake.org/cmake/help/consulting.html >> >>> CMake Training Courses: http://cmake.org/cmake/help/training.html >> >>> >> >>> Visit other Kitware open-source projects at >> >>> http://www.kitware.com/opensource/opensource.html >> >>> >> >>> Follow this link to subscribe/unsubscribe: >> >>> http://public.kitware.com/mailman/listinfo/cmake > ,-- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake Regards, Konstantin Podsvirov From craig.scott at crascit.com Thu Aug 17 16:23:48 2017 From: craig.scott at crascit.com (Craig Scott) Date: Fri, 18 Aug 2017 06:23:48 +1000 Subject: [CMake] cmake-gui on windows and qt5 dlls In-Reply-To: <245101502996716@web35o.yandex.ru> References: <5991a6bd.d8a0df0a.adc85.7614@mx.google.com> <245101502996716@web35o.yandex.ru> Message-ID: On Fri, Aug 18, 2017 at 5:05 AM, Konstantin Podsvirov < konstantin at podsvirov.pro> wrote: > Hello Cl?ment Gregoire! > > 17.08.2017, 21:55, "Cl?ment Gregoire" : > > So the following worked for me: > > > > move cmake-gui.exe, all dlls and qt.conf to a "cmkae/bin/gui" subfolder > > > > create a batch file named > > > > cmake-gui.bat > > > > with the following content > > > > @echo off > > start "" /B "%~dp0\gui\cmake-gui.exe" %* > > > > And modify qt.conf so that the plugin directory is correct : > > > > from Plugins = ../plugins to Plugins = ../../plugins > > > > I'm not (yet) on the dev mailing list, so feel free to transfer the > solution there. > > Please review dev mailing list archive too: > http://public.kitware.com/pipermail/cmake-developers/2017- > August/030228.html > (may be I forgot /B option) > Side note: really weird, but that email you've linked to never made it to my inbox (can't explain it, checked my trash and spam folders too), so I never saw your request to ask to test! In the past, one problem I've run into with using simple batch files as launcher scripts is that they can flash up a console window briefly before starting the real app. This can look suspicious and distracting to the user, so it is something to avoid. I think at one past employer we ended up using something like wscript instead, which allowed us to avoid that problem and it worked on all Windows versions without any extra software dependencies. Maybe we just didn't have good enough batch-file-fu, maybe things work differently now, I don't know. Been a number of years since I've looked at that specific problem. Some context, but only basic extra info: https://stackoverflow.com/a/9062764/1938798 -- Craig Scott Melbourne, Australia https://crascit.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From craig.scott at crascit.com Thu Aug 17 17:03:58 2017 From: craig.scott at crascit.com (Craig Scott) Date: Fri, 18 Aug 2017 07:03:58 +1000 Subject: [CMake] cmake-gui on windows and qt5 dlls In-Reply-To: References: <5991a6bd.d8a0df0a.adc85.7614@mx.google.com> <245101502996716@web35o.yandex.ru> Message-ID: On Fri, Aug 18, 2017 at 6:23 AM, Craig Scott wrote: > > > On Fri, Aug 18, 2017 at 5:05 AM, Konstantin Podsvirov < > konstantin at podsvirov.pro> wrote: > >> Hello Cl?ment Gregoire! >> >> 17.08.2017, 21:55, "Cl?ment Gregoire" : >> > So the following worked for me: >> > >> > move cmake-gui.exe, all dlls and qt.conf to a "cmkae/bin/gui" subfolder >> > >> > create a batch file named >> > >> > cmake-gui.bat >> > >> > with the following content >> > >> > @echo off >> > start "" /B "%~dp0\gui\cmake-gui.exe" %* >> > >> > And modify qt.conf so that the plugin directory is correct : >> > >> > from Plugins = ../plugins to Plugins = ../../plugins >> > >> > I'm not (yet) on the dev mailing list, so feel free to transfer the >> solution there. >> >> Please review dev mailing list archive too: >> http://public.kitware.com/pipermail/cmake-developers/2017-Au >> gust/030228.html >> (may be I forgot /B option) >> > > Side note: really weird, but that email you've linked to never made it to > my inbox (can't explain it, checked my trash and spam folders too), so I > never saw your request to ask to test! > > In the past, one problem I've run into with using simple batch files as > launcher scripts is that they can flash up a console window briefly before > starting the real app. This can look suspicious and distracting to the > user, so it is something to avoid. I think at one past employer we ended up > using something like wscript instead, which allowed us to avoid that > problem and it worked on all Windows versions without any extra software > dependencies. Maybe we just didn't have good enough batch-file-fu, maybe > things work differently now, I don't know. Been a number of years since > I've looked at that specific problem. Some context, but only basic extra > info: > > https://stackoverflow.com/a/9062764/1938798 > Let me clarify the above (sorry, recalling more of the original problem we had years back). The flashing up of a console window would occur if you ran the launcher from somewhere other than an existing console window. For example, if you double-clicked the launcher in Windows Explorer or via a menu shortcut. In our case, we were using the script to set some environment variables before launching the real app, so you always wanted to use the launcher. In the discussion here about cmake-gui, you don't really need that, you just want a way to forward the call to start the app so you can avoid putting the real app and its DLLs on the PATH. So I guess a batch file would be okay in this instance, since we would only be expecting people to use it from a console window anyway (menu shortcuts, etc. could still invoke the real cmake-gui app directly). -- Craig Scott Melbourne, Australia https://crascit.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From nilsgladitz at gmail.com Fri Aug 18 02:46:41 2017 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Fri, 18 Aug 2017 08:46:41 +0200 Subject: [CMake] CPackWIX and MS Visual Studio Redistributable *.MSM In-Reply-To: References: Message-ID: On Thu, Aug 17, 2017 at 3:10 PM, Matwey V. Kornilov < matwey.kornilov at gmail.com> wrote: > Hello, > > What is recommended way to locate and merge MS redistributable *.msm file > into final *.msi installer produced by CPack and WIX? > > It seems to be a quite common task but I cannot find any mention. > I've never tried this myself. You probably already found: http://wixtoolset.org/documentation/manual/v3/howtos/redistributables_and_install_checks/install_vcredist.html Perhaps the patch mechanism in the WIX generator can be used to insert the required snippets into the generated XML: https://cmake.org/cmake/help/latest/module/CPackWIX.html#variable:CPACK_WIX_PATCH_FILE I don't outright know where the msm files are stored or what would be the best way to locate them. I suppose it might not be that common in a CMake context because it would be CPack generator and compiler specific while the competing https://cmake.org/cmake/help/latest/module/InstallRequiredSystemLibraries.html is both generator and compiler agnostic. Nils -------------- next part -------------- An HTML attachment was scrubbed... URL: From drgutek at o2.pl Fri Aug 18 03:29:19 2017 From: drgutek at o2.pl (=?UTF-8?Q?drgutek=40o2=2Epl?=) Date: Fri, 18 Aug 2017 09:29:19 +0200 Subject: [CMake] =?utf-8?q?install__DESTINATION_parameter_-_why_can=27t_be?= =?utf-8?q?_empty=3F_Workarounds_don=27t_work=2E?= Message-ID: <9bd008ef56f94a339fa8a84bd0313b68@grupawp.pl> Hi, In general, relative parameters of type PATH, like "lib" or "source/include" are resolved to an absolute path using current value of variables, like for instance: ${CMAKE_INSTALL_PREFIX} in case of command INSTALL(). This, however, does not work if I would like to use empty relative path (or not set it at all), so that the resulting absolute path was equal to ${CMAKE_INSTALL_PREFIX} - cmake generator would complain about non existing DESTINATION, although there is no reason why it couldn't be resolved. I know two workarounds to this issue, but the both have their flaws which prevent me from achieving my goal: 1. Use ${CMAKE_INSTALL_PREFIX} as the DESTINATION value. This correctly resolved the path, but in case of INSTALL(EXPORT), paths in generated Target.cmake are absolute, which makes the package not relocatable. 2. Use '.' as the DESTINATION. This at least generates relative paths inside Target.cmake, but the paths are incorrect. '.' is apparently considered as a regular folder, and in the process of Target.cmake generation, when _IMPORT_PREFIX is determined, cmake strips one folder component too much: # Compute the installation prefix relative to this file. get_filename_component(_IMPORT "${CMAKE_CURRENT_LIST_FILE}" PATH) get_filename_component(_IMPORT "${_IMPORT_PREFIX}" PATH) Do you know any other workaround? Do you think that lack of empty relative paths could be considered a bug? Piotr -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcdailey.lists at gmail.com Fri Aug 18 09:50:58 2017 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Fri, 18 Aug 2017 08:50:58 -0500 Subject: [CMake] RUN_TESTS does not rebuild targets? Message-ID: Why does the RUN_TESTS target in Visual Studio IDE not first build the unit tests before running them? If my tests are out of date, I expect the executables to be built first and then CTest to be invoked. From dictoon at gmail.com Sat Aug 19 05:31:47 2017 From: dictoon at gmail.com (=?UTF-8?Q?Fran=C3=A7ois_Beaune?=) Date: Sat, 19 Aug 2017 11:31:47 +0200 Subject: [CMake] MSVC compiler identification with CMake Message-ID: Hello, I'm trying to understand the discrepancy between the compiler version reported by Visual C++ and the compiler version reported by CMake. I've posted a question on Stack Overflow [1] but since I didn't get a satisfactory answer yet, I figured I would dig into CMake's sources to figure it out myself. After an hour of grepping the source code, I'm still puzzled so I figured I would ask directly here. FWIW, I'm using Visual Studio Enterprise 2017 version 15.3.0 and CMake version 3.8.1. When I run cmake -G "Visual Studio 11 2012 Win64" . I get: -- The C compiler identification is MSVC 17.0.60610.1 -- The CXX compiler identification is MSVC 17.0.60610.1 -- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio 11.0/VC/bin/x86_amd64/cl.exe -- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio 11.0/VC/bin/x86_amd64/cl.exe -- works i.e. the compiler version is 17.0.60610.1. But when I run C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\bin\x86_amd64\cl.exe I instead get: Microsoft (R) C/C++ Optimizing Compiler Version 17.00.50727.1 for x64 i.e. the compiler version is 17.00.50727.1. I'm assuming this is the correct version number, and I'm now wondering why CMake reports a different one. Any idea? Best, Franz [1] https://stackoverflow.com/questions/45763944/msvc-compiler-identification-with-cmake -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.tmatma at gmail.com Sat Aug 19 22:55:41 2017 From: m.tmatma at gmail.com (Masaru Tsuchiyama) Date: Sun, 20 Aug 2017 11:55:41 +0900 Subject: [CMake] 'cmake.exe -G Ninja' doesn't work for VS2017 with cmake ver 3.9.1 Message-ID: <84ce2ae4-99d2-c3d4-8bb0-82131019aa76@gmail.com> Hello I found a bug that cmake doesn't create 'rules.ninja' while the build process even though generated build.ninja has a line "include rules.ninja". Then running with -G Ninja fails with VS2017. cmake ver 3.7.1 doesn't happen . cmake ver 3.9.1 happens. cmake bb3647060cd8ddc4184687b64469d6a8554f49b3 happens. I found this for llvm first, but it happens with the other projects. example: HelloWorld in https://github.com/m-tmatma/cmake-sample.git HelloWorld is a very simple cmake project. This commands can reproduce this. ---------------------------------------------------------------- git clone https://github.com/m-tmatma/cmake-sample.git mkdir cmake-sample\HelloWorld\Build cd cmake-sample\HelloWorld\Build call "C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Auxiliary\Build\vcvarsall.bat" x86 cmake.exe -G Ninja .. ---------------------------------------------------------------- This is the output of cmake bb3647060cd8ddc4184687b64469d6a8554f49b3. ------------------------------------------------------------------- -- The C compiler identification is MSVC 19.11.25506.0 -- The CXX compiler identification is MSVC 19.11.25506.0 -- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio/2017/Community/VC/Tools/MSVC/14.11.25503/bin/HostX86/x86/cl.exe -- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio/2017/Community/VC/Tools/MSVC/14.11.25503/bin/HostX86/x86/cl.exe -- broken CMake Error at C:/gitwork/GitHub/cmake/cmake-tmatma/Modules/CMakeTestCCompiler.cmake:51 (message): The C compiler "C:/Program Files (x86)/Microsoft Visual Studio/2017/Community/VC/Tools/MSVC/14.11.25503/bin/HostX86/x86/cl.exe" is not able to compile a simple test program. It fails with the following output: Change Dir: C:/gitwork/test/test/cmake-sample/HelloWorld/Build/CMakeFiles/CMakeTmp Run Build Command:"C:/PROGRA~2/Ninja/ninja.exe" "cmTC_80f4d" ninja: error: build.ninja:30: loading 'rules.ninja': ?????????????????? include rules.ninja ^ near here CMake will not be able to correctly generate this project. Call Stack (most recent call first): CMakeLists.txt:10 (project) -- Configuring incomplete, errors occurred! See also "C:/gitwork/test/test/cmake-sample/HelloWorld/Build/CMakeFiles/CMakeOutput.log". See also "C:/gitwork/test/test/cmake-sample/HelloWorld/Build/CMakeFiles/CMakeError.log". ------------------------------------------------------------------- This is the output of cmake 3.7.1 for the same project. ------------------------------------------------------------------- -- The C compiler identification is MSVC 19.11.25506.0 -- The CXX compiler identification is MSVC 19.11.25506.0 -- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio/2017/Community/VC/Tools/MSVC/14.11.25503/bin/HostX86/x86/cl.exe -- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio/2017/Community/VC/Tools/MSVC/14.11.25503/bin/HostX86/x86/cl.exe -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual Studio/2017/Community/VC/Tools/MSVC/14.11.25503/bin/HostX86/x86/cl.exe -- Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual Studio/2017/Community/VC/Tools/MSVC/14.11.25503/bin/HostX86/x86/cl.exe -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Detecting CXX compile features -- Detecting CXX compile features - done -- Configuring done -- Generating done -- Build files have been written to: C:/gitwork/test/test/cmake-sample/HelloWorld/Build ------------------------------------------------------------------- -- Masaru Tsuchiyama From bitminer at gmail.com Sun Aug 20 18:54:25 2017 From: bitminer at gmail.com (Brian Davis) Date: Sun, 20 Aug 2017 17:54:25 -0500 Subject: [CMake] CMake CUDA 3.8+/9 support as a first class language with out Visual Studio Support... err what? In-Reply-To: References: <7ca86101-dfe0-957f-182f-cde17d4f83c4@wisc.edu> <150725ad-ac46-b99e-8fa1-e86bf8ee9175@gmail.com> Message-ID: Now that I have working machines and can create CUDA app (simple) successfully that will run ?While trying: message( "GPU_ARCH = ${GPU_ARCH}" ) target_compile_options( ${SOME_LIB_NAME} PRIVATE $<$:${GPU_ARCH}> ) with output of: GPU_ARCH = -gencode arch=compute_30,code="sm_30,compute_30" -gencode arch=compute_35,code="sm_35,compute_35" -gencode arch=compute_50,code="sm_50,compute_50" Configuring done CMake Error at subprojects/4d_fluro_prototype/endoscopic_view/src/CMakeLists.txt:92 (target_compile_options): Error evaluating generator expression: $ $ may not be used with Visual Studio generators. I think I may becoming fully aware of the meaning of these statements from CMake doc and from initial post of this thread: --snip-- CMake learned to support CUDA as a first-class language that can be enabled via the project() and enable_language() commands. CUDA is currently supported by the Makefile Generators and the Ninja generator on Linux, macOS, and Windows. *Support for the Visual Studio IDE is under development but not included in this release.* The NVIDIA CUDA Toolkit compiler (nvcc) is supported. --snip-- Or did I try and misuse and abuse CMake again. I am trying to learn the "new way" of doing things and converting my projects accordingly, but the doc leaves much to be desired. I can get CMAKE_CUDA_FLAGS (well actually it duplicates the args twice but at least they change in VS) to work but the bit about "Deprecate CMake Variables" here: https://github.com/boostcon/cppnow_presentations_2017/blob/ master/05-19-2017_friday/effective_cmake__daniel_pfeifer__ cppnow_05-19-2017.pdf as "Variables are so CMake 2.8.12 Modern CMake is about Targets and Properties!", I assume as emphasized in the true The Black Eyed Peas style... I am sure I am "so 2017 late" to upgrading my CMake... err well if only it was fully supportive of what I need... maybe it is... not that I have any hope on learning how it does ( from doc)... I think I am gonna blame "them Chickens jackin' my style" as there ain't nobody here but us chickens. -------------- next part -------------- An HTML attachment was scrubbed... URL: From anastasiya.ruzhanskaya at frtk.ru Mon Aug 21 04:25:15 2017 From: anastasiya.ruzhanskaya at frtk.ru (Anastasiya Ruzhanskaya) Date: Mon, 21 Aug 2017 10:25:15 +0200 Subject: [CMake] two llvm libraries. Message-ID: Hello, I am developing two llvm libraries (they should as MODULE .so at he end). Still , they are situated in one cmake project and at some point I want to use one pass (library) inside another. Simply including h files and getting the result of llvm analysis leads to errors: Error opening '../build/MyCFGPass/libMyCFGPass.so': ../build/MyCFGPass/libMyCFGPass.so: undefined symbol: _ZTVN8bitwidth16OptimizeBitwidthE - one pass does not see another at all. I can't link this library because it is MODULE but I also can't create a second static library as in this case the pass will try to register itself twice )(in .a and .so files). What can be the problem that I can't use one class inside another and what can be a solution to this? I have: passA.cpp <- includes "passB.h", passB.h, passB.cpp, I want to have passA.so, passB.so, passA uses the analysis from passB. Does the fact that I defined passB under namespace influence the problem? -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.tmatma at gmail.com Mon Aug 21 09:39:21 2017 From: m.tmatma at gmail.com (Masaru Tsuchiyama) Date: Mon, 21 Aug 2017 22:39:21 +0900 Subject: [CMake] 'cmake.exe -G Ninja' doesn't work for VS2017 with cmake ver 3.9.1 In-Reply-To: <84ce2ae4-99d2-c3d4-8bb0-82131019aa76@gmail.com> References: <84ce2ae4-99d2-c3d4-8bb0-82131019aa76@gmail.com> Message-ID: <6ddc295f-8cda-2f64-e6c2-3e33ec529e94@gmail.com> Hello I did git bisect. The problematic commit is https://gitlab.kitware.com/cmake/cmake/commit/690acadc17263621f5361d48057c6f938e698a58 cmake with Ninja Generator succeeds by reverting 690acadc17263621f5361d48057c6f938e698a58 > git checkout master > git checkout -b try-revert-690acadc17263621f5361d48057c6f938e698a58 > git revert 690acadc17263621f5361d48057c6f938e698a58 > git bisect log git bisect start # bad: [a1b84ac2a6eec367a8a56f4a0f811e78f5d60fab] CMake Nightly Date Stamp git bisect bad a1b84ac2a6eec367a8a56f4a0f811e78f5d60fab # good: [db3499df5d06ab2cacc61e9f7720a33456aeafe4] CMake 3.7.1 git bisect good db3499df5d06ab2cacc61e9f7720a33456aeafe4 # good: [f36eaf6a6eb8a7ef1127ad43e419896be89f0e39] Refactor WINDOWS_EXPORT_ALL_SYMBOLS implementation git bisect good f36eaf6a6eb8a7ef1127ad43e419896be89f0e39 # good: [80e0ef4082d999e629688e9a6639ac498634b5ed] Merge topic 'GNU-FindBinUtils-patterns' git bisect good 80e0ef4082d999e629688e9a6639ac498634b5ed # bad: [43c3afa74538fd7b78bcf534bfb3fa93c3c1f191] Merge topic 'fix-crash-on-non-enabled-language-features' git bisect bad 43c3afa74538fd7b78bcf534bfb3fa93c3c1f191 # bad: [2d3d88f3bb7076a26d9147f63453931595133aa1] Merge topic 'GoogleTest-disabled-tests' git bisect bad 2d3d88f3bb7076a26d9147f63453931595133aa1 # good: [256481499d56589e98659bd069d7f8a2fd653546] Merge topic 'update-kwsys' git bisect good 256481499d56589e98659bd069d7f8a2fd653546 # bad: [47281310bf610f3ab975d00831e9f3fe713ddde1] Merge topic 'minor-cleanups' git bisect bad 47281310bf610f3ab975d00831e9f3fe713ddde1 # bad: [f8642f953d3d8547bd31fcb35a4737fa91d9126f] Merge topic 'reduce-string-copying' git bisect bad f8642f953d3d8547bd31fcb35a4737fa91d9126f # bad: [bc341a9d5e3863dd80393144eae88f27883db764] Merge topic 'update-libuv' git bisect bad bc341a9d5e3863dd80393144eae88f27883db764 # good: [6f74bbaffec687dce755ee985b3bf69e915d3a8d] Merge topic 'findxmlrpc_fix' git bisect good 6f74bbaffec687dce755ee985b3bf69e915d3a8d # bad: [1ebb421bfc8eb21a4e5e56e501a62d000a9f59db] Merge branch 'upstream-libuv' into update-libuv git bisect bad 1ebb421bfc8eb21a4e5e56e501a62d000a9f59db # bad: [bc407ba6ba28293b5fc0025fa08e8fe71365eab8] Merge topic 'codecvt-revise' git bisect bad bc407ba6ba28293b5fc0025fa08e8fe71365eab8 # bad: [690acadc17263621f5361d48057c6f938e698a58] codecvt: Re-implement do_out and do_unshift git bisect bad 690acadc17263621f5361d48057c6f938e698a58 # first bad commit: [690acadc17263621f5361d48057c6f938e698a58] codecvt: Re-implement do_out and do_unshift This is the batch file which was used for 'git bisect'. I used https://github.com/m-tmatma/cmake-sample.git as the input of cmake. -------------------------------------------------------------------------- @echo on cd /d %~dp0 set CONFIGURATION=Debug set SRC_CMAKE=%~dp0 set SRC_HELLO=%~dp0..\cmake-sample\HelloWorld set OUTDIR_CMAKE=%~dp0build-cmake set OUTDIR_HELLO=%~dp0build-hello set BUILT_CMAKE=%OUTDIR_CMAKE%\bin\%CONFIGURATION%\cmake.exe set DEVENV="C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\devenv.com" if not exist %OUTDIR_CMAKE% mkdir %OUTDIR_CMAKE% cd /d %OUTDIR_CMAKE% cmake -G "Visual Studio 15 2017" -D CMAKE_INSTALL_PREFIX=c:\cmake %SRC_CMAKE% %DEVENV% CMake.sln /build "%CONFIGURATION%|Win32" /project cmake cd /d %~dp0 if not exist %OUTDIR_HELLO% mkdir %SRC_HELLO% cd /d %OUTDIR_HELLO% %BUILT_CMAKE% -G Ninja %SRC_HELLO% || ( echo error && cd /d %~dp0 && exit /b 1) cd /d %~dp0 exit /b 0 -------------------------------------------------------------------------- Masaru Tsuchiyama wrote: > Hello > > I found a bug that cmake doesn't create 'rules.ninja' while the build > process even though generated build.ninja has a line "include rules.ninja". > > > Then running with -G Ninja fails with VS2017. > > cmake ver 3.7.1 doesn't happen > . > cmake ver 3.9.1 happens. > cmake bb3647060cd8ddc4184687b64469d6a8554f49b3 happens. > > > > I found this for llvm first, but it happens with the other projects. > > example: HelloWorld in https://github.com/m-tmatma/cmake-sample.git > > HelloWorld is a very simple cmake project. > > This commands can reproduce this. > ---------------------------------------------------------------- > git clone https://github.com/m-tmatma/cmake-sample.git > mkdir cmake-sample\HelloWorld\Build > cd cmake-sample\HelloWorld\Build > call "C:\Program Files (x86)\Microsoft Visual > Studio\2017\Community\VC\Auxiliary\Build\vcvarsall.bat" x86 > cmake.exe -G Ninja .. > ---------------------------------------------------------------- > > This is the output of cmake bb3647060cd8ddc4184687b64469d6a8554f49b3. > ------------------------------------------------------------------- > -- The C compiler identification is MSVC 19.11.25506.0 > -- The CXX compiler identification is MSVC 19.11.25506.0 > -- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual > Studio/2017/Community/VC/Tools/MSVC/14.11.25503/bin/HostX86/x86/cl.exe > -- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual > Studio/2017/Community/VC/Tools/MSVC/14.11.25503/bin/HostX86/x86/cl.exe > -- broken > CMake Error at > C:/gitwork/GitHub/cmake/cmake-tmatma/Modules/CMakeTestCCompiler.cmake:51 > (message): > The C compiler "C:/Program Files (x86)/Microsoft Visual > > Studio/2017/Community/VC/Tools/MSVC/14.11.25503/bin/HostX86/x86/cl.exe" is > not able to compile a simple test program. > > It fails with the following output: > > Change Dir: > C:/gitwork/test/test/cmake-sample/HelloWorld/Build/CMakeFiles/CMakeTmp > > > > Run Build Command:"C:/PROGRA~2/Ninja/ninja.exe" "cmTC_80f4d" > > ninja: error: build.ninja:30: loading 'rules.ninja': > ?????????????????? > > > > include rules.ninja > > ^ near here > > > > > > CMake will not be able to correctly generate this project. > Call Stack (most recent call first): > CMakeLists.txt:10 (project) > > > -- Configuring incomplete, errors occurred! > See also > "C:/gitwork/test/test/cmake-sample/HelloWorld/Build/CMakeFiles/CMakeOutput.log". > > See also > "C:/gitwork/test/test/cmake-sample/HelloWorld/Build/CMakeFiles/CMakeError.log". > > ------------------------------------------------------------------- > > This is the output of cmake 3.7.1 for the same project. > ------------------------------------------------------------------- > -- The C compiler identification is MSVC 19.11.25506.0 > -- The CXX compiler identification is MSVC 19.11.25506.0 > -- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual > Studio/2017/Community/VC/Tools/MSVC/14.11.25503/bin/HostX86/x86/cl.exe > -- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual > Studio/2017/Community/VC/Tools/MSVC/14.11.25503/bin/HostX86/x86/cl.exe > -- works > -- Detecting C compiler ABI info > -- Detecting C compiler ABI info - done > -- Check for working CXX compiler: C:/Program Files (x86)/Microsoft > Visual > Studio/2017/Community/VC/Tools/MSVC/14.11.25503/bin/HostX86/x86/cl.exe > -- Check for working CXX compiler: C:/Program Files (x86)/Microsoft > Visual > Studio/2017/Community/VC/Tools/MSVC/14.11.25503/bin/HostX86/x86/cl.exe > -- works > -- Detecting CXX compiler ABI info > -- Detecting CXX compiler ABI info - done > -- Detecting CXX compile features > -- Detecting CXX compile features - done > -- Configuring done > -- Generating done > -- Build files have been written to: > C:/gitwork/test/test/cmake-sample/HelloWorld/Build > ------------------------------------------------------------------- > > -- Masaru Tsuchiyama From rcdailey.lists at gmail.com Mon Aug 21 10:30:22 2017 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Mon, 21 Aug 2017 09:30:22 -0500 Subject: [CMake] CMake + Gradle for Android In-Reply-To: References: Message-ID: How exactly does Gradle package *.so files in an APK? I know that ANT used to do this for any libs under "libs/". Does Gradle do some introspection into CMake targets to see if outputs are *.so, and copy those to some location if needed? What about libraries like libgnustl_shared.so that come with the NDK? I'd like to know if any manual copy steps are needed in CMake to put outputs in proper locations for the APK build step. I had to do this when using ANT. On Mon, Aug 7, 2017 at 6:16 PM, Jom O'Fisher wrote: > 1) There is a folder created for each ABI under the project module folder > (so unique per module per ABI) > 2) Gradle doesn't specify language level though you can choose to specify it > yourself from the build.gradle. This doc does a pretty good job of > explaining which variables are set by Gradle: > https://developer.android.com/ndk/guides/cmake.html#variables. > Philosophically, we try to set as little as we can get away with. In > particular, the section titled "Understanding the CMake build command" lays > out exactly what we set. You can also see the folders we specify (one per > module per ABI) > 3) Not sure I understand this. > > The other document worth taking a look at (if you haven't already) is: > https://developer.android.com/studio/projects/add-native-code.html > > > On Mon, Aug 7, 2017 at 3:35 PM, Robert Dailey > wrote: >> >> Thanks Jom >> >> Honestly, I prefer option 1 to work simply because that's how Google's >> officially supporting CMake. But it also has debugging which is the #1 >> reason for me. >> >> However, I'd like to understand a lot more about how the integration >> really happens. For example, I have these questions: >> >> 1) How, internally, are CMake build directories managed? Do you >> generate 1 per unique android project? What about for each specific >> platform (x86, armeabi-v7a, etc)? >> 2) Last time I looked into CMake integration, things defined inside >> the CMake scripts were ignored because they are specified at the >> command line. Namely, all of those settings that are driven by the >> Gradle configuration (CXX language level was one in particular I >> think; I specify C++14 support via CMake, but I recall this being >> overridden from outside)? >> 3) How redundant is it to configure individual libraries via the >> gradle scripts? In my previous attempts, I wanted to define common >> stuff for CMake / native code at the root gradle or settings file, and >> only define the differences in the actual gradle build files for each >> corresponding Java target (like, defining the name of the native >> (shared library) target in Gradle, but the command line invocation, -D >> CMake settings, etc would all be common and defined at the root). >> >> The TLDR is, the closer we can stay to CMake's way of doing things and >> keep CMake-related settings self-contained to the CMake scripts >> themselves, the better. This also makes cross-platform easier (we >> build the native code in Windows, for example, so having settings >> specified in the gradle files do not carry over to other platforms. >> Namely, settings that are not platform specific like the C++ language >> level). >> >> If there's a detailed document / wiki I can read on the intrinsics of >> CMake integration in Gradle / Android Studio, I'd love to read it. >> Otherwise, I hope you won't mind if I pick your brain as questions >> come up. I think I'm going to try option 1 for now and see how it >> goes. It's just black box for me because unlike option 2, I have very >> little control over what happens after building the shared libraries, >> and to make up for that I need to really get a deep understanding of >> how it works so I can make sure I code my CMake scripts properly for >> not only Android, but my other platforms as well (non-Android >> platforms). >> >> Thanks again. >> >> On Mon, Aug 7, 2017 at 5:12 PM, Jom O'Fisher wrote: >> > Either option can work fine. Disclosure: I work on Android Studio and >> > was >> > the one that added CMake support. >> > >> > Option (1) is the way it's designed to work and we're working toward >> > getting >> > rid of the need for the CMake fork. I can't really say when that will >> > happen >> > but if you can get away with an older CMake for now then I'd go this >> > way. >> > As you mentioned, option (1) will allow you to view your source file >> > structure in Android Studio, edit files, and debug using the built-in >> > debugging support. >> > >> > To get option (2) to work, you can use jniDirs setting to tell Android >> > Gradle where to pick up your built .so files (see >> > >> > https://stackoverflow.com/questions/21255125/how-can-i-add-so-files-to-an-android-library-project-using-gradle-0-7). >> > I'm not aware of any projects that use this approach but it should work >> > in >> > principal. >> > >> > I hope this helps, >> > Jomo >> > >> > >> > On Mon, Aug 7, 2017 at 11:09 AM, Robert Dailey >> > >> > wrote: >> >> >> >> Right now I have custom targets set to execute the "ant release" >> >> command after my native targets are built. Part of that command >> >> involves copying *.so files to the libs/armeabi-v7a directory so they >> >> get packaged in an APK. >> >> >> >> When switching to gradle, I have two options: >> >> >> >> 1. Gradle drives CMake: This means using Android Studio and being >> >> locked down to Google's fork of CMake which is a few major releases >> >> behind. I see that as a negative. >> >> >> >> 2. CMake drives Gradle: This would be the same or similar to what I'm >> >> already doing: The custom targets I have would execute gradle as a >> >> separate build step, instead of running ant commands. I'm not too >> >> familiar with Gradle, so I'm not sure how you tell it where your >> >> shared libraries are for the APK packaging steps. >> >> >> >> Which does everyone recommend? Is anyone using one of these setups >> >> successfully? The downside to option 2 is probably no on-device native >> >> debugging since Android Studio probably can't handle gradle projects >> >> without any external CMake builds set up. >> >> >> >> Would like some general direction & advice before I move away from >> >> ANT. Thanks in advance. >> >> -- >> >> >> >> Powered by www.kitware.com >> >> >> >> Please keep messages on-topic and check the CMake FAQ at: >> >> http://www.cmake.org/Wiki/CMake_FAQ >> >> >> >> Kitware offers various services to support the CMake community. For >> >> more >> >> information on each offering, please visit: >> >> >> >> CMake Support: http://cmake.org/cmake/help/support.html >> >> CMake Consulting: http://cmake.org/cmake/help/consulting.html >> >> CMake Training Courses: http://cmake.org/cmake/help/training.html >> >> >> >> Visit other Kitware open-source projects at >> >> http://www.kitware.com/opensource/opensource.html >> >> >> >> Follow this link to subscribe/unsubscribe: >> >> http://public.kitware.com/mailman/listinfo/cmake >> > >> > > > From jomofisher at gmail.com Mon Aug 21 10:37:04 2017 From: jomofisher at gmail.com (Jom O'Fisher) Date: Mon, 21 Aug 2017 07:37:04 -0700 Subject: [CMake] CMake + Gradle for Android In-Reply-To: References: Message-ID: Gradle does introspection on the CMake build to find .so targets and those get packaged. There is also a special case for stl/runtime .so files from the NDK. Any additional .so files need to specified in build.gradle using jniDirs On Mon, Aug 21, 2017 at 7:30 AM, Robert Dailey wrote: > How exactly does Gradle package *.so files in an APK? I know that ANT > used to do this for any libs under "libs/". Does Gradle do some > introspection into CMake targets to see if outputs are *.so, and copy > those to some location if needed? What about libraries like > libgnustl_shared.so that come with the NDK? I'd like to know if any > manual copy steps are needed in CMake to put outputs in proper > locations for the APK build step. I had to do this when using ANT. > > On Mon, Aug 7, 2017 at 6:16 PM, Jom O'Fisher wrote: > > 1) There is a folder created for each ABI under the project module folder > > (so unique per module per ABI) > > 2) Gradle doesn't specify language level though you can choose to > specify it > > yourself from the build.gradle. This doc does a pretty good job of > > explaining which variables are set by Gradle: > > https://developer.android.com/ndk/guides/cmake.html#variables. > > Philosophically, we try to set as little as we can get away with. In > > particular, the section titled "Understanding the CMake build command" > lays > > out exactly what we set. You can also see the folders we specify (one per > > module per ABI) > > 3) Not sure I understand this. > > > > The other document worth taking a look at (if you haven't already) is: > > https://developer.android.com/studio/projects/add-native-code.html > > > > > > On Mon, Aug 7, 2017 at 3:35 PM, Robert Dailey > > wrote: > >> > >> Thanks Jom > >> > >> Honestly, I prefer option 1 to work simply because that's how Google's > >> officially supporting CMake. But it also has debugging which is the #1 > >> reason for me. > >> > >> However, I'd like to understand a lot more about how the integration > >> really happens. For example, I have these questions: > >> > >> 1) How, internally, are CMake build directories managed? Do you > >> generate 1 per unique android project? What about for each specific > >> platform (x86, armeabi-v7a, etc)? > >> 2) Last time I looked into CMake integration, things defined inside > >> the CMake scripts were ignored because they are specified at the > >> command line. Namely, all of those settings that are driven by the > >> Gradle configuration (CXX language level was one in particular I > >> think; I specify C++14 support via CMake, but I recall this being > >> overridden from outside)? > >> 3) How redundant is it to configure individual libraries via the > >> gradle scripts? In my previous attempts, I wanted to define common > >> stuff for CMake / native code at the root gradle or settings file, and > >> only define the differences in the actual gradle build files for each > >> corresponding Java target (like, defining the name of the native > >> (shared library) target in Gradle, but the command line invocation, -D > >> CMake settings, etc would all be common and defined at the root). > >> > >> The TLDR is, the closer we can stay to CMake's way of doing things and > >> keep CMake-related settings self-contained to the CMake scripts > >> themselves, the better. This also makes cross-platform easier (we > >> build the native code in Windows, for example, so having settings > >> specified in the gradle files do not carry over to other platforms. > >> Namely, settings that are not platform specific like the C++ language > >> level). > >> > >> If there's a detailed document / wiki I can read on the intrinsics of > >> CMake integration in Gradle / Android Studio, I'd love to read it. > >> Otherwise, I hope you won't mind if I pick your brain as questions > >> come up. I think I'm going to try option 1 for now and see how it > >> goes. It's just black box for me because unlike option 2, I have very > >> little control over what happens after building the shared libraries, > >> and to make up for that I need to really get a deep understanding of > >> how it works so I can make sure I code my CMake scripts properly for > >> not only Android, but my other platforms as well (non-Android > >> platforms). > >> > >> Thanks again. > >> > >> On Mon, Aug 7, 2017 at 5:12 PM, Jom O'Fisher > wrote: > >> > Either option can work fine. Disclosure: I work on Android Studio and > >> > was > >> > the one that added CMake support. > >> > > >> > Option (1) is the way it's designed to work and we're working toward > >> > getting > >> > rid of the need for the CMake fork. I can't really say when that will > >> > happen > >> > but if you can get away with an older CMake for now then I'd go this > >> > way. > >> > As you mentioned, option (1) will allow you to view your source file > >> > structure in Android Studio, edit files, and debug using the built-in > >> > debugging support. > >> > > >> > To get option (2) to work, you can use jniDirs setting to tell Android > >> > Gradle where to pick up your built .so files (see > >> > > >> > https://stackoverflow.com/questions/21255125/how-can-i- > add-so-files-to-an-android-library-project-using-gradle-0-7). > >> > I'm not aware of any projects that use this approach but it should > work > >> > in > >> > principal. > >> > > >> > I hope this helps, > >> > Jomo > >> > > >> > > >> > On Mon, Aug 7, 2017 at 11:09 AM, Robert Dailey > >> > > >> > wrote: > >> >> > >> >> Right now I have custom targets set to execute the "ant release" > >> >> command after my native targets are built. Part of that command > >> >> involves copying *.so files to the libs/armeabi-v7a directory so they > >> >> get packaged in an APK. > >> >> > >> >> When switching to gradle, I have two options: > >> >> > >> >> 1. Gradle drives CMake: This means using Android Studio and being > >> >> locked down to Google's fork of CMake which is a few major releases > >> >> behind. I see that as a negative. > >> >> > >> >> 2. CMake drives Gradle: This would be the same or similar to what I'm > >> >> already doing: The custom targets I have would execute gradle as a > >> >> separate build step, instead of running ant commands. I'm not too > >> >> familiar with Gradle, so I'm not sure how you tell it where your > >> >> shared libraries are for the APK packaging steps. > >> >> > >> >> Which does everyone recommend? Is anyone using one of these setups > >> >> successfully? The downside to option 2 is probably no on-device > native > >> >> debugging since Android Studio probably can't handle gradle projects > >> >> without any external CMake builds set up. > >> >> > >> >> Would like some general direction & advice before I move away from > >> >> ANT. Thanks in advance. > >> >> -- > >> >> > >> >> Powered by www.kitware.com > >> >> > >> >> Please keep messages on-topic and check the CMake FAQ at: > >> >> http://www.cmake.org/Wiki/CMake_FAQ > >> >> > >> >> Kitware offers various services to support the CMake community. For > >> >> more > >> >> information on each offering, please visit: > >> >> > >> >> CMake Support: http://cmake.org/cmake/help/support.html > >> >> CMake Consulting: http://cmake.org/cmake/help/consulting.html > >> >> CMake Training Courses: http://cmake.org/cmake/help/training.html > >> >> > >> >> Visit other Kitware open-source projects at > >> >> http://www.kitware.com/opensource/opensource.html > >> >> > >> >> Follow this link to subscribe/unsubscribe: > >> >> http://public.kitware.com/mailman/listinfo/cmake > >> > > >> > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Mon Aug 21 11:11:54 2017 From: brad.king at kitware.com (Brad King) Date: Mon, 21 Aug 2017 11:11:54 -0400 Subject: [CMake] 'cmake.exe -G Ninja' doesn't work for VS2017 with cmake ver 3.9.1 In-Reply-To: <6ddc295f-8cda-2f64-e6c2-3e33ec529e94@gmail.com> References: <84ce2ae4-99d2-c3d4-8bb0-82131019aa76@gmail.com> <6ddc295f-8cda-2f64-e6c2-3e33ec529e94@gmail.com> Message-ID: On 08/21/2017 09:39 AM, Masaru Tsuchiyama wrote: > I did git bisect. > > The problematic commit is > https://gitlab.kitware.com/cmake/cmake/commit/690acadc17263621f5361d48057c6f938e698a58 > > cmake with Ninja Generator succeeds by reverting > 690acadc17263621f5361d48057c6f938e698a58 [snip] > ninja: error: build.ninja:30: loading 'rules.ninja': > ?????????????????? Thanks. Is that this issue? https://gitlab.kitware.com/cmake/cmake/issues/17191 Otherwise, please open a new issue. Thanks, -Brad From rcdailey.lists at gmail.com Mon Aug 21 12:00:19 2017 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Mon, 21 Aug 2017 11:00:19 -0500 Subject: [CMake] CMake + Gradle for Android In-Reply-To: References: Message-ID: Thanks this is very helpful. The other question I have is: Is there a place to centrally specify the root CMakeLists.txt? Basically, I want to specify the CMake root in 1 place, and have targets (defined further down in subdirectories) that require APK packaging to specify only the native target name that should be built & packaged. At the moment we specify the root CMakeLists.txt by walking up the tree, paths like "../../../../CMakeLists.txt". I think this should be put at the top-level build gradle file if possible. Is this doable at the moment? What is the recommended setup? On Mon, Aug 21, 2017 at 9:37 AM, Jom O'Fisher wrote: > Gradle does introspection on the CMake build to find .so targets and those > get packaged. > There is also a special case for stl/runtime .so files from the NDK. > Any additional .so files need to specified in build.gradle using jniDirs > > On Mon, Aug 21, 2017 at 7:30 AM, Robert Dailey > wrote: >> >> How exactly does Gradle package *.so files in an APK? I know that ANT >> used to do this for any libs under "libs/". Does Gradle do some >> introspection into CMake targets to see if outputs are *.so, and copy >> those to some location if needed? What about libraries like >> libgnustl_shared.so that come with the NDK? I'd like to know if any >> manual copy steps are needed in CMake to put outputs in proper >> locations for the APK build step. I had to do this when using ANT. >> >> On Mon, Aug 7, 2017 at 6:16 PM, Jom O'Fisher wrote: >> > 1) There is a folder created for each ABI under the project module >> > folder >> > (so unique per module per ABI) >> > 2) Gradle doesn't specify language level though you can choose to >> > specify it >> > yourself from the build.gradle. This doc does a pretty good job of >> > explaining which variables are set by Gradle: >> > https://developer.android.com/ndk/guides/cmake.html#variables. >> > Philosophically, we try to set as little as we can get away with. In >> > particular, the section titled "Understanding the CMake build command" >> > lays >> > out exactly what we set. You can also see the folders we specify (one >> > per >> > module per ABI) >> > 3) Not sure I understand this. >> > >> > The other document worth taking a look at (if you haven't already) is: >> > https://developer.android.com/studio/projects/add-native-code.html >> > >> > >> > On Mon, Aug 7, 2017 at 3:35 PM, Robert Dailey >> > wrote: >> >> >> >> Thanks Jom >> >> >> >> Honestly, I prefer option 1 to work simply because that's how Google's >> >> officially supporting CMake. But it also has debugging which is the #1 >> >> reason for me. >> >> >> >> However, I'd like to understand a lot more about how the integration >> >> really happens. For example, I have these questions: >> >> >> >> 1) How, internally, are CMake build directories managed? Do you >> >> generate 1 per unique android project? What about for each specific >> >> platform (x86, armeabi-v7a, etc)? >> >> 2) Last time I looked into CMake integration, things defined inside >> >> the CMake scripts were ignored because they are specified at the >> >> command line. Namely, all of those settings that are driven by the >> >> Gradle configuration (CXX language level was one in particular I >> >> think; I specify C++14 support via CMake, but I recall this being >> >> overridden from outside)? >> >> 3) How redundant is it to configure individual libraries via the >> >> gradle scripts? In my previous attempts, I wanted to define common >> >> stuff for CMake / native code at the root gradle or settings file, and >> >> only define the differences in the actual gradle build files for each >> >> corresponding Java target (like, defining the name of the native >> >> (shared library) target in Gradle, but the command line invocation, -D >> >> CMake settings, etc would all be common and defined at the root). >> >> >> >> The TLDR is, the closer we can stay to CMake's way of doing things and >> >> keep CMake-related settings self-contained to the CMake scripts >> >> themselves, the better. This also makes cross-platform easier (we >> >> build the native code in Windows, for example, so having settings >> >> specified in the gradle files do not carry over to other platforms. >> >> Namely, settings that are not platform specific like the C++ language >> >> level). >> >> >> >> If there's a detailed document / wiki I can read on the intrinsics of >> >> CMake integration in Gradle / Android Studio, I'd love to read it. >> >> Otherwise, I hope you won't mind if I pick your brain as questions >> >> come up. I think I'm going to try option 1 for now and see how it >> >> goes. It's just black box for me because unlike option 2, I have very >> >> little control over what happens after building the shared libraries, >> >> and to make up for that I need to really get a deep understanding of >> >> how it works so I can make sure I code my CMake scripts properly for >> >> not only Android, but my other platforms as well (non-Android >> >> platforms). >> >> >> >> Thanks again. >> >> >> >> On Mon, Aug 7, 2017 at 5:12 PM, Jom O'Fisher >> >> wrote: >> >> > Either option can work fine. Disclosure: I work on Android Studio and >> >> > was >> >> > the one that added CMake support. >> >> > >> >> > Option (1) is the way it's designed to work and we're working toward >> >> > getting >> >> > rid of the need for the CMake fork. I can't really say when that will >> >> > happen >> >> > but if you can get away with an older CMake for now then I'd go this >> >> > way. >> >> > As you mentioned, option (1) will allow you to view your source file >> >> > structure in Android Studio, edit files, and debug using the built-in >> >> > debugging support. >> >> > >> >> > To get option (2) to work, you can use jniDirs setting to tell >> >> > Android >> >> > Gradle where to pick up your built .so files (see >> >> > >> >> > >> >> > https://stackoverflow.com/questions/21255125/how-can-i-add-so-files-to-an-android-library-project-using-gradle-0-7). >> >> > I'm not aware of any projects that use this approach but it should >> >> > work >> >> > in >> >> > principal. >> >> > >> >> > I hope this helps, >> >> > Jomo >> >> > >> >> > >> >> > On Mon, Aug 7, 2017 at 11:09 AM, Robert Dailey >> >> > >> >> > wrote: >> >> >> >> >> >> Right now I have custom targets set to execute the "ant release" >> >> >> command after my native targets are built. Part of that command >> >> >> involves copying *.so files to the libs/armeabi-v7a directory so >> >> >> they >> >> >> get packaged in an APK. >> >> >> >> >> >> When switching to gradle, I have two options: >> >> >> >> >> >> 1. Gradle drives CMake: This means using Android Studio and being >> >> >> locked down to Google's fork of CMake which is a few major releases >> >> >> behind. I see that as a negative. >> >> >> >> >> >> 2. CMake drives Gradle: This would be the same or similar to what >> >> >> I'm >> >> >> already doing: The custom targets I have would execute gradle as a >> >> >> separate build step, instead of running ant commands. I'm not too >> >> >> familiar with Gradle, so I'm not sure how you tell it where your >> >> >> shared libraries are for the APK packaging steps. >> >> >> >> >> >> Which does everyone recommend? Is anyone using one of these setups >> >> >> successfully? The downside to option 2 is probably no on-device >> >> >> native >> >> >> debugging since Android Studio probably can't handle gradle projects >> >> >> without any external CMake builds set up. >> >> >> >> >> >> Would like some general direction & advice before I move away from >> >> >> ANT. Thanks in advance. >> >> >> -- >> >> >> >> >> >> Powered by www.kitware.com >> >> >> >> >> >> Please keep messages on-topic and check the CMake FAQ at: >> >> >> http://www.cmake.org/Wiki/CMake_FAQ >> >> >> >> >> >> Kitware offers various services to support the CMake community. For >> >> >> more >> >> >> information on each offering, please visit: >> >> >> >> >> >> CMake Support: http://cmake.org/cmake/help/support.html >> >> >> CMake Consulting: http://cmake.org/cmake/help/consulting.html >> >> >> CMake Training Courses: http://cmake.org/cmake/help/training.html >> >> >> >> >> >> Visit other Kitware open-source projects at >> >> >> http://www.kitware.com/opensource/opensource.html >> >> >> >> >> >> Follow this link to subscribe/unsubscribe: >> >> >> http://public.kitware.com/mailman/listinfo/cmake >> >> > >> >> > >> > >> > > > From jomofisher at gmail.com Mon Aug 21 12:11:05 2017 From: jomofisher at gmail.com (Jom O'Fisher) Date: Mon, 21 Aug 2017 09:11:05 -0700 Subject: [CMake] CMake + Gradle for Android In-Reply-To: References: Message-ID: What you're doing already sounds correct. You can't directly specify CMakeLists.txt from the top-level build.gradle. Recommendation is that it should be specified from the build.gradle of the module of the APK. Is the issue that you have multiple APK modules that all reference the same CMake libraries? On Mon, Aug 21, 2017 at 9:00 AM, Robert Dailey wrote: > Thanks this is very helpful. The other question I have is: Is there a > place to centrally specify the root CMakeLists.txt? Basically, I want > to specify the CMake root in 1 place, and have targets (defined > further down in subdirectories) that require APK packaging to specify > only the native target name that should be built & packaged. > > At the moment we specify the root CMakeLists.txt by walking up the > tree, paths like "../../../../CMakeLists.txt". I think this should be > put at the top-level build gradle file if possible. Is this doable at > the moment? What is the recommended setup? > > On Mon, Aug 21, 2017 at 9:37 AM, Jom O'Fisher > wrote: > > Gradle does introspection on the CMake build to find .so targets and > those > > get packaged. > > There is also a special case for stl/runtime .so files from the NDK. > > Any additional .so files need to specified in build.gradle using jniDirs > > > > On Mon, Aug 21, 2017 at 7:30 AM, Robert Dailey > > > wrote: > >> > >> How exactly does Gradle package *.so files in an APK? I know that ANT > >> used to do this for any libs under "libs/". Does Gradle do some > >> introspection into CMake targets to see if outputs are *.so, and copy > >> those to some location if needed? What about libraries like > >> libgnustl_shared.so that come with the NDK? I'd like to know if any > >> manual copy steps are needed in CMake to put outputs in proper > >> locations for the APK build step. I had to do this when using ANT. > >> > >> On Mon, Aug 7, 2017 at 6:16 PM, Jom O'Fisher > wrote: > >> > 1) There is a folder created for each ABI under the project module > >> > folder > >> > (so unique per module per ABI) > >> > 2) Gradle doesn't specify language level though you can choose to > >> > specify it > >> > yourself from the build.gradle. This doc does a pretty good job of > >> > explaining which variables are set by Gradle: > >> > https://developer.android.com/ndk/guides/cmake.html#variables. > >> > Philosophically, we try to set as little as we can get away with. In > >> > particular, the section titled "Understanding the CMake build command" > >> > lays > >> > out exactly what we set. You can also see the folders we specify (one > >> > per > >> > module per ABI) > >> > 3) Not sure I understand this. > >> > > >> > The other document worth taking a look at (if you haven't already) is: > >> > https://developer.android.com/studio/projects/add-native-code.html > >> > > >> > > >> > On Mon, Aug 7, 2017 at 3:35 PM, Robert Dailey < > rcdailey.lists at gmail.com> > >> > wrote: > >> >> > >> >> Thanks Jom > >> >> > >> >> Honestly, I prefer option 1 to work simply because that's how > Google's > >> >> officially supporting CMake. But it also has debugging which is the > #1 > >> >> reason for me. > >> >> > >> >> However, I'd like to understand a lot more about how the integration > >> >> really happens. For example, I have these questions: > >> >> > >> >> 1) How, internally, are CMake build directories managed? Do you > >> >> generate 1 per unique android project? What about for each specific > >> >> platform (x86, armeabi-v7a, etc)? > >> >> 2) Last time I looked into CMake integration, things defined inside > >> >> the CMake scripts were ignored because they are specified at the > >> >> command line. Namely, all of those settings that are driven by the > >> >> Gradle configuration (CXX language level was one in particular I > >> >> think; I specify C++14 support via CMake, but I recall this being > >> >> overridden from outside)? > >> >> 3) How redundant is it to configure individual libraries via the > >> >> gradle scripts? In my previous attempts, I wanted to define common > >> >> stuff for CMake / native code at the root gradle or settings file, > and > >> >> only define the differences in the actual gradle build files for each > >> >> corresponding Java target (like, defining the name of the native > >> >> (shared library) target in Gradle, but the command line invocation, > -D > >> >> CMake settings, etc would all be common and defined at the root). > >> >> > >> >> The TLDR is, the closer we can stay to CMake's way of doing things > and > >> >> keep CMake-related settings self-contained to the CMake scripts > >> >> themselves, the better. This also makes cross-platform easier (we > >> >> build the native code in Windows, for example, so having settings > >> >> specified in the gradle files do not carry over to other platforms. > >> >> Namely, settings that are not platform specific like the C++ language > >> >> level). > >> >> > >> >> If there's a detailed document / wiki I can read on the intrinsics of > >> >> CMake integration in Gradle / Android Studio, I'd love to read it. > >> >> Otherwise, I hope you won't mind if I pick your brain as questions > >> >> come up. I think I'm going to try option 1 for now and see how it > >> >> goes. It's just black box for me because unlike option 2, I have very > >> >> little control over what happens after building the shared libraries, > >> >> and to make up for that I need to really get a deep understanding of > >> >> how it works so I can make sure I code my CMake scripts properly for > >> >> not only Android, but my other platforms as well (non-Android > >> >> platforms). > >> >> > >> >> Thanks again. > >> >> > >> >> On Mon, Aug 7, 2017 at 5:12 PM, Jom O'Fisher > >> >> wrote: > >> >> > Either option can work fine. Disclosure: I work on Android Studio > and > >> >> > was > >> >> > the one that added CMake support. > >> >> > > >> >> > Option (1) is the way it's designed to work and we're working > toward > >> >> > getting > >> >> > rid of the need for the CMake fork. I can't really say when that > will > >> >> > happen > >> >> > but if you can get away with an older CMake for now then I'd go > this > >> >> > way. > >> >> > As you mentioned, option (1) will allow you to view your source > file > >> >> > structure in Android Studio, edit files, and debug using the > built-in > >> >> > debugging support. > >> >> > > >> >> > To get option (2) to work, you can use jniDirs setting to tell > >> >> > Android > >> >> > Gradle where to pick up your built .so files (see > >> >> > > >> >> > > >> >> > https://stackoverflow.com/questions/21255125/how-can-i- > add-so-files-to-an-android-library-project-using-gradle-0-7). > >> >> > I'm not aware of any projects that use this approach but it should > >> >> > work > >> >> > in > >> >> > principal. > >> >> > > >> >> > I hope this helps, > >> >> > Jomo > >> >> > > >> >> > > >> >> > On Mon, Aug 7, 2017 at 11:09 AM, Robert Dailey > >> >> > > >> >> > wrote: > >> >> >> > >> >> >> Right now I have custom targets set to execute the "ant release" > >> >> >> command after my native targets are built. Part of that command > >> >> >> involves copying *.so files to the libs/armeabi-v7a directory so > >> >> >> they > >> >> >> get packaged in an APK. > >> >> >> > >> >> >> When switching to gradle, I have two options: > >> >> >> > >> >> >> 1. Gradle drives CMake: This means using Android Studio and being > >> >> >> locked down to Google's fork of CMake which is a few major > releases > >> >> >> behind. I see that as a negative. > >> >> >> > >> >> >> 2. CMake drives Gradle: This would be the same or similar to what > >> >> >> I'm > >> >> >> already doing: The custom targets I have would execute gradle as a > >> >> >> separate build step, instead of running ant commands. I'm not too > >> >> >> familiar with Gradle, so I'm not sure how you tell it where your > >> >> >> shared libraries are for the APK packaging steps. > >> >> >> > >> >> >> Which does everyone recommend? Is anyone using one of these setups > >> >> >> successfully? The downside to option 2 is probably no on-device > >> >> >> native > >> >> >> debugging since Android Studio probably can't handle gradle > projects > >> >> >> without any external CMake builds set up. > >> >> >> > >> >> >> Would like some general direction & advice before I move away from > >> >> >> ANT. Thanks in advance. > >> >> >> -- > >> >> >> > >> >> >> Powered by www.kitware.com > >> >> >> > >> >> >> Please keep messages on-topic and check the CMake FAQ at: > >> >> >> http://www.cmake.org/Wiki/CMake_FAQ > >> >> >> > >> >> >> Kitware offers various services to support the CMake community. > For > >> >> >> more > >> >> >> information on each offering, please visit: > >> >> >> > >> >> >> CMake Support: http://cmake.org/cmake/help/support.html > >> >> >> CMake Consulting: http://cmake.org/cmake/help/consulting.html > >> >> >> CMake Training Courses: http://cmake.org/cmake/help/training.html > >> >> >> > >> >> >> Visit other Kitware open-source projects at > >> >> >> http://www.kitware.com/opensource/opensource.html > >> >> >> > >> >> >> Follow this link to subscribe/unsubscribe: > >> >> >> http://public.kitware.com/mailman/listinfo/cmake > >> >> > > >> >> > > >> > > >> > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcdailey.lists at gmail.com Mon Aug 21 12:33:05 2017 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Mon, 21 Aug 2017 11:33:05 -0500 Subject: [CMake] CMake + Gradle for Android In-Reply-To: References: Message-ID: Basically, yes. We have this sort of structure: / Applications/ App1/ build.gradle CMakeLists.txt App2/ build.gradle CMakeLists.txt App3/ build.gradle CMakeLists.txt CommonLib/ build.gradle CMakeLists.txt CMakeLists.txt The libs are defined as follows: * CommonLib is a static library (java code builds into a library) * No dependencies of its own * App1 is a shared library (java code builds into a library) * Dependencies (both java & native): CommonLib * App2 is a shared library (java code builds into an APK) * Dependencies (both java & native): App1, CommonLib * App3 is a shared library (java code builds into an APK) * Dependencies (both java & native): CommonLib In all cases, CMake must be invoked starting at the root CMakeLists.txt 1 time. Each target can be built from the same binary directory after that. Previously with ANT, I was building all native targets first, then moved libs to appropriate directories so that the 'ant' command would package the libs. For gradle, I wanted to avoid redundantly specifying the root directory in each leaf-level project directory. Using the example above, the leaf-level directories in this case would be App1, App2, App3, and CommonLib. However I think we only specify the native CMake stuff for the java targets that actually output an APK (that would be App2 and App3 only). The ultimate goal is to specify stuff that doesn't change per independent "module" of ours at the top level so it is transitive / inherited. Then only specify the differences (e.g. the native CMake target to build) in the leaf build gradle files. However you indicated this isn't possible. On Mon, Aug 21, 2017 at 11:11 AM, Jom O'Fisher wrote: > What you're doing already sounds correct. You can't directly specify > CMakeLists.txt from the top-level build.gradle. Recommendation is that it > should be specified from the build.gradle of the module of the APK. Is the > issue that you have multiple APK modules that all reference the same CMake > libraries? > > On Mon, Aug 21, 2017 at 9:00 AM, Robert Dailey > wrote: >> >> Thanks this is very helpful. The other question I have is: Is there a >> place to centrally specify the root CMakeLists.txt? Basically, I want >> to specify the CMake root in 1 place, and have targets (defined >> further down in subdirectories) that require APK packaging to specify >> only the native target name that should be built & packaged. >> >> At the moment we specify the root CMakeLists.txt by walking up the >> tree, paths like "../../../../CMakeLists.txt". I think this should be >> put at the top-level build gradle file if possible. Is this doable at >> the moment? What is the recommended setup? >> >> On Mon, Aug 21, 2017 at 9:37 AM, Jom O'Fisher >> wrote: >> > Gradle does introspection on the CMake build to find .so targets and >> > those >> > get packaged. >> > There is also a special case for stl/runtime .so files from the NDK. >> > Any additional .so files need to specified in build.gradle using jniDirs >> > >> > On Mon, Aug 21, 2017 at 7:30 AM, Robert Dailey >> > >> > wrote: >> >> >> >> How exactly does Gradle package *.so files in an APK? I know that ANT >> >> used to do this for any libs under "libs/". Does Gradle do some >> >> introspection into CMake targets to see if outputs are *.so, and copy >> >> those to some location if needed? What about libraries like >> >> libgnustl_shared.so that come with the NDK? I'd like to know if any >> >> manual copy steps are needed in CMake to put outputs in proper >> >> locations for the APK build step. I had to do this when using ANT. >> >> >> >> On Mon, Aug 7, 2017 at 6:16 PM, Jom O'Fisher >> >> wrote: >> >> > 1) There is a folder created for each ABI under the project module >> >> > folder >> >> > (so unique per module per ABI) >> >> > 2) Gradle doesn't specify language level though you can choose to >> >> > specify it >> >> > yourself from the build.gradle. This doc does a pretty good job of >> >> > explaining which variables are set by Gradle: >> >> > https://developer.android.com/ndk/guides/cmake.html#variables. >> >> > Philosophically, we try to set as little as we can get away with. In >> >> > particular, the section titled "Understanding the CMake build >> >> > command" >> >> > lays >> >> > out exactly what we set. You can also see the folders we specify (one >> >> > per >> >> > module per ABI) >> >> > 3) Not sure I understand this. >> >> > >> >> > The other document worth taking a look at (if you haven't already) >> >> > is: >> >> > https://developer.android.com/studio/projects/add-native-code.html >> >> > >> >> > >> >> > On Mon, Aug 7, 2017 at 3:35 PM, Robert Dailey >> >> > >> >> > wrote: >> >> >> >> >> >> Thanks Jom >> >> >> >> >> >> Honestly, I prefer option 1 to work simply because that's how >> >> >> Google's >> >> >> officially supporting CMake. But it also has debugging which is the >> >> >> #1 >> >> >> reason for me. >> >> >> >> >> >> However, I'd like to understand a lot more about how the integration >> >> >> really happens. For example, I have these questions: >> >> >> >> >> >> 1) How, internally, are CMake build directories managed? Do you >> >> >> generate 1 per unique android project? What about for each specific >> >> >> platform (x86, armeabi-v7a, etc)? >> >> >> 2) Last time I looked into CMake integration, things defined inside >> >> >> the CMake scripts were ignored because they are specified at the >> >> >> command line. Namely, all of those settings that are driven by the >> >> >> Gradle configuration (CXX language level was one in particular I >> >> >> think; I specify C++14 support via CMake, but I recall this being >> >> >> overridden from outside)? >> >> >> 3) How redundant is it to configure individual libraries via the >> >> >> gradle scripts? In my previous attempts, I wanted to define common >> >> >> stuff for CMake / native code at the root gradle or settings file, >> >> >> and >> >> >> only define the differences in the actual gradle build files for >> >> >> each >> >> >> corresponding Java target (like, defining the name of the native >> >> >> (shared library) target in Gradle, but the command line invocation, >> >> >> -D >> >> >> CMake settings, etc would all be common and defined at the root). >> >> >> >> >> >> The TLDR is, the closer we can stay to CMake's way of doing things >> >> >> and >> >> >> keep CMake-related settings self-contained to the CMake scripts >> >> >> themselves, the better. This also makes cross-platform easier (we >> >> >> build the native code in Windows, for example, so having settings >> >> >> specified in the gradle files do not carry over to other platforms. >> >> >> Namely, settings that are not platform specific like the C++ >> >> >> language >> >> >> level). >> >> >> >> >> >> If there's a detailed document / wiki I can read on the intrinsics >> >> >> of >> >> >> CMake integration in Gradle / Android Studio, I'd love to read it. >> >> >> Otherwise, I hope you won't mind if I pick your brain as questions >> >> >> come up. I think I'm going to try option 1 for now and see how it >> >> >> goes. It's just black box for me because unlike option 2, I have >> >> >> very >> >> >> little control over what happens after building the shared >> >> >> libraries, >> >> >> and to make up for that I need to really get a deep understanding of >> >> >> how it works so I can make sure I code my CMake scripts properly for >> >> >> not only Android, but my other platforms as well (non-Android >> >> >> platforms). >> >> >> >> >> >> Thanks again. >> >> >> >> >> >> On Mon, Aug 7, 2017 at 5:12 PM, Jom O'Fisher >> >> >> wrote: >> >> >> > Either option can work fine. Disclosure: I work on Android Studio >> >> >> > and >> >> >> > was >> >> >> > the one that added CMake support. >> >> >> > >> >> >> > Option (1) is the way it's designed to work and we're working >> >> >> > toward >> >> >> > getting >> >> >> > rid of the need for the CMake fork. I can't really say when that >> >> >> > will >> >> >> > happen >> >> >> > but if you can get away with an older CMake for now then I'd go >> >> >> > this >> >> >> > way. >> >> >> > As you mentioned, option (1) will allow you to view your source >> >> >> > file >> >> >> > structure in Android Studio, edit files, and debug using the >> >> >> > built-in >> >> >> > debugging support. >> >> >> > >> >> >> > To get option (2) to work, you can use jniDirs setting to tell >> >> >> > Android >> >> >> > Gradle where to pick up your built .so files (see >> >> >> > >> >> >> > >> >> >> > >> >> >> > https://stackoverflow.com/questions/21255125/how-can-i-add-so-files-to-an-android-library-project-using-gradle-0-7). >> >> >> > I'm not aware of any projects that use this approach but it should >> >> >> > work >> >> >> > in >> >> >> > principal. >> >> >> > >> >> >> > I hope this helps, >> >> >> > Jomo >> >> >> > >> >> >> > >> >> >> > On Mon, Aug 7, 2017 at 11:09 AM, Robert Dailey >> >> >> > >> >> >> > wrote: >> >> >> >> >> >> >> >> Right now I have custom targets set to execute the "ant release" >> >> >> >> command after my native targets are built. Part of that command >> >> >> >> involves copying *.so files to the libs/armeabi-v7a directory so >> >> >> >> they >> >> >> >> get packaged in an APK. >> >> >> >> >> >> >> >> When switching to gradle, I have two options: >> >> >> >> >> >> >> >> 1. Gradle drives CMake: This means using Android Studio and being >> >> >> >> locked down to Google's fork of CMake which is a few major >> >> >> >> releases >> >> >> >> behind. I see that as a negative. >> >> >> >> >> >> >> >> 2. CMake drives Gradle: This would be the same or similar to what >> >> >> >> I'm >> >> >> >> already doing: The custom targets I have would execute gradle as >> >> >> >> a >> >> >> >> separate build step, instead of running ant commands. I'm not too >> >> >> >> familiar with Gradle, so I'm not sure how you tell it where your >> >> >> >> shared libraries are for the APK packaging steps. >> >> >> >> >> >> >> >> Which does everyone recommend? Is anyone using one of these >> >> >> >> setups >> >> >> >> successfully? The downside to option 2 is probably no on-device >> >> >> >> native >> >> >> >> debugging since Android Studio probably can't handle gradle >> >> >> >> projects >> >> >> >> without any external CMake builds set up. >> >> >> >> >> >> >> >> Would like some general direction & advice before I move away >> >> >> >> from >> >> >> >> ANT. Thanks in advance. >> >> >> >> -- >> >> >> >> >> >> >> >> Powered by www.kitware.com >> >> >> >> >> >> >> >> Please keep messages on-topic and check the CMake FAQ at: >> >> >> >> http://www.cmake.org/Wiki/CMake_FAQ >> >> >> >> >> >> >> >> Kitware offers various services to support the CMake community. >> >> >> >> For >> >> >> >> more >> >> >> >> information on each offering, please visit: >> >> >> >> >> >> >> >> CMake Support: http://cmake.org/cmake/help/support.html >> >> >> >> CMake Consulting: http://cmake.org/cmake/help/consulting.html >> >> >> >> CMake Training Courses: http://cmake.org/cmake/help/training.html >> >> >> >> >> >> >> >> Visit other Kitware open-source projects at >> >> >> >> http://www.kitware.com/opensource/opensource.html >> >> >> >> >> >> >> >> Follow this link to subscribe/unsubscribe: >> >> >> >> http://public.kitware.com/mailman/listinfo/cmake >> >> >> > >> >> >> > >> >> > >> >> > >> > >> > > > From jomofisher at gmail.com Mon Aug 21 13:00:01 2017 From: jomofisher at gmail.com (Jom O'Fisher) Date: Mon, 21 Aug 2017 10:00:01 -0700 Subject: [CMake] CMake + Gradle for Android In-Reply-To: References: Message-ID: Would it work for your situation for the leaf CMakeLists.txt to include the root CMakeLists.txt? Then have the leaf-specific logic in the leaf CMakeLists.txt? On Mon, Aug 21, 2017 at 9:33 AM, Robert Dailey wrote: > Basically, yes. We have this sort of structure: > > / > Applications/ > App1/ > build.gradle > CMakeLists.txt > App2/ > build.gradle > CMakeLists.txt > App3/ > build.gradle > CMakeLists.txt > CommonLib/ > build.gradle > CMakeLists.txt > CMakeLists.txt > > The libs are defined as follows: > > * CommonLib is a static library (java code builds into a library) > * No dependencies of its own > * App1 is a shared library (java code builds into a library) > * Dependencies (both java & native): CommonLib > * App2 is a shared library (java code builds into an APK) > * Dependencies (both java & native): App1, CommonLib > * App3 is a shared library (java code builds into an APK) > * Dependencies (both java & native): CommonLib > > In all cases, CMake must be invoked starting at the root > CMakeLists.txt 1 time. Each target can be built from the same binary > directory after that. Previously with ANT, I was building all native > targets first, then moved libs to appropriate directories so that the > 'ant' command would package the libs. > > For gradle, I wanted to avoid redundantly specifying the root > directory in each leaf-level project directory. Using the example > above, the leaf-level directories in this case would be App1, App2, > App3, and CommonLib. However I think we only specify the native CMake > stuff for the java targets that actually output an APK (that would be > App2 and App3 only). > > The ultimate goal is to specify stuff that doesn't change per > independent "module" of ours at the top level so it is transitive / > inherited. Then only specify the differences (e.g. the native CMake > target to build) in the leaf build gradle files. However you indicated > this isn't possible. > > > > On Mon, Aug 21, 2017 at 11:11 AM, Jom O'Fisher > wrote: > > What you're doing already sounds correct. You can't directly specify > > CMakeLists.txt from the top-level build.gradle. Recommendation is that it > > should be specified from the build.gradle of the module of the APK. Is > the > > issue that you have multiple APK modules that all reference the same > CMake > > libraries? > > > > On Mon, Aug 21, 2017 at 9:00 AM, Robert Dailey > > > wrote: > >> > >> Thanks this is very helpful. The other question I have is: Is there a > >> place to centrally specify the root CMakeLists.txt? Basically, I want > >> to specify the CMake root in 1 place, and have targets (defined > >> further down in subdirectories) that require APK packaging to specify > >> only the native target name that should be built & packaged. > >> > >> At the moment we specify the root CMakeLists.txt by walking up the > >> tree, paths like "../../../../CMakeLists.txt". I think this should be > >> put at the top-level build gradle file if possible. Is this doable at > >> the moment? What is the recommended setup? > >> > >> On Mon, Aug 21, 2017 at 9:37 AM, Jom O'Fisher > >> wrote: > >> > Gradle does introspection on the CMake build to find .so targets and > >> > those > >> > get packaged. > >> > There is also a special case for stl/runtime .so files from the NDK. > >> > Any additional .so files need to specified in build.gradle using > jniDirs > >> > > >> > On Mon, Aug 21, 2017 at 7:30 AM, Robert Dailey > >> > > >> > wrote: > >> >> > >> >> How exactly does Gradle package *.so files in an APK? I know that ANT > >> >> used to do this for any libs under "libs/". Does Gradle do some > >> >> introspection into CMake targets to see if outputs are *.so, and copy > >> >> those to some location if needed? What about libraries like > >> >> libgnustl_shared.so that come with the NDK? I'd like to know if any > >> >> manual copy steps are needed in CMake to put outputs in proper > >> >> locations for the APK build step. I had to do this when using ANT. > >> >> > >> >> On Mon, Aug 7, 2017 at 6:16 PM, Jom O'Fisher > >> >> wrote: > >> >> > 1) There is a folder created for each ABI under the project module > >> >> > folder > >> >> > (so unique per module per ABI) > >> >> > 2) Gradle doesn't specify language level though you can choose to > >> >> > specify it > >> >> > yourself from the build.gradle. This doc does a pretty good job of > >> >> > explaining which variables are set by Gradle: > >> >> > https://developer.android.com/ndk/guides/cmake.html#variables. > >> >> > Philosophically, we try to set as little as we can get away with. > In > >> >> > particular, the section titled "Understanding the CMake build > >> >> > command" > >> >> > lays > >> >> > out exactly what we set. You can also see the folders we specify > (one > >> >> > per > >> >> > module per ABI) > >> >> > 3) Not sure I understand this. > >> >> > > >> >> > The other document worth taking a look at (if you haven't already) > >> >> > is: > >> >> > https://developer.android.com/studio/projects/add-native-code.html > >> >> > > >> >> > > >> >> > On Mon, Aug 7, 2017 at 3:35 PM, Robert Dailey > >> >> > > >> >> > wrote: > >> >> >> > >> >> >> Thanks Jom > >> >> >> > >> >> >> Honestly, I prefer option 1 to work simply because that's how > >> >> >> Google's > >> >> >> officially supporting CMake. But it also has debugging which is > the > >> >> >> #1 > >> >> >> reason for me. > >> >> >> > >> >> >> However, I'd like to understand a lot more about how the > integration > >> >> >> really happens. For example, I have these questions: > >> >> >> > >> >> >> 1) How, internally, are CMake build directories managed? Do you > >> >> >> generate 1 per unique android project? What about for each > specific > >> >> >> platform (x86, armeabi-v7a, etc)? > >> >> >> 2) Last time I looked into CMake integration, things defined > inside > >> >> >> the CMake scripts were ignored because they are specified at the > >> >> >> command line. Namely, all of those settings that are driven by the > >> >> >> Gradle configuration (CXX language level was one in particular I > >> >> >> think; I specify C++14 support via CMake, but I recall this being > >> >> >> overridden from outside)? > >> >> >> 3) How redundant is it to configure individual libraries via the > >> >> >> gradle scripts? In my previous attempts, I wanted to define common > >> >> >> stuff for CMake / native code at the root gradle or settings file, > >> >> >> and > >> >> >> only define the differences in the actual gradle build files for > >> >> >> each > >> >> >> corresponding Java target (like, defining the name of the native > >> >> >> (shared library) target in Gradle, but the command line > invocation, > >> >> >> -D > >> >> >> CMake settings, etc would all be common and defined at the root). > >> >> >> > >> >> >> The TLDR is, the closer we can stay to CMake's way of doing things > >> >> >> and > >> >> >> keep CMake-related settings self-contained to the CMake scripts > >> >> >> themselves, the better. This also makes cross-platform easier (we > >> >> >> build the native code in Windows, for example, so having settings > >> >> >> specified in the gradle files do not carry over to other > platforms. > >> >> >> Namely, settings that are not platform specific like the C++ > >> >> >> language > >> >> >> level). > >> >> >> > >> >> >> If there's a detailed document / wiki I can read on the intrinsics > >> >> >> of > >> >> >> CMake integration in Gradle / Android Studio, I'd love to read it. > >> >> >> Otherwise, I hope you won't mind if I pick your brain as questions > >> >> >> come up. I think I'm going to try option 1 for now and see how it > >> >> >> goes. It's just black box for me because unlike option 2, I have > >> >> >> very > >> >> >> little control over what happens after building the shared > >> >> >> libraries, > >> >> >> and to make up for that I need to really get a deep understanding > of > >> >> >> how it works so I can make sure I code my CMake scripts properly > for > >> >> >> not only Android, but my other platforms as well (non-Android > >> >> >> platforms). > >> >> >> > >> >> >> Thanks again. > >> >> >> > >> >> >> On Mon, Aug 7, 2017 at 5:12 PM, Jom O'Fisher < > jomofisher at gmail.com> > >> >> >> wrote: > >> >> >> > Either option can work fine. Disclosure: I work on Android > Studio > >> >> >> > and > >> >> >> > was > >> >> >> > the one that added CMake support. > >> >> >> > > >> >> >> > Option (1) is the way it's designed to work and we're working > >> >> >> > toward > >> >> >> > getting > >> >> >> > rid of the need for the CMake fork. I can't really say when that > >> >> >> > will > >> >> >> > happen > >> >> >> > but if you can get away with an older CMake for now then I'd go > >> >> >> > this > >> >> >> > way. > >> >> >> > As you mentioned, option (1) will allow you to view your source > >> >> >> > file > >> >> >> > structure in Android Studio, edit files, and debug using the > >> >> >> > built-in > >> >> >> > debugging support. > >> >> >> > > >> >> >> > To get option (2) to work, you can use jniDirs setting to tell > >> >> >> > Android > >> >> >> > Gradle where to pick up your built .so files (see > >> >> >> > > >> >> >> > > >> >> >> > > >> >> >> > https://stackoverflow.com/questions/21255125/how-can-i- > add-so-files-to-an-android-library-project-using-gradle-0-7). > >> >> >> > I'm not aware of any projects that use this approach but it > should > >> >> >> > work > >> >> >> > in > >> >> >> > principal. > >> >> >> > > >> >> >> > I hope this helps, > >> >> >> > Jomo > >> >> >> > > >> >> >> > > >> >> >> > On Mon, Aug 7, 2017 at 11:09 AM, Robert Dailey > >> >> >> > > >> >> >> > wrote: > >> >> >> >> > >> >> >> >> Right now I have custom targets set to execute the "ant > release" > >> >> >> >> command after my native targets are built. Part of that command > >> >> >> >> involves copying *.so files to the libs/armeabi-v7a directory > so > >> >> >> >> they > >> >> >> >> get packaged in an APK. > >> >> >> >> > >> >> >> >> When switching to gradle, I have two options: > >> >> >> >> > >> >> >> >> 1. Gradle drives CMake: This means using Android Studio and > being > >> >> >> >> locked down to Google's fork of CMake which is a few major > >> >> >> >> releases > >> >> >> >> behind. I see that as a negative. > >> >> >> >> > >> >> >> >> 2. CMake drives Gradle: This would be the same or similar to > what > >> >> >> >> I'm > >> >> >> >> already doing: The custom targets I have would execute gradle > as > >> >> >> >> a > >> >> >> >> separate build step, instead of running ant commands. I'm not > too > >> >> >> >> familiar with Gradle, so I'm not sure how you tell it where > your > >> >> >> >> shared libraries are for the APK packaging steps. > >> >> >> >> > >> >> >> >> Which does everyone recommend? Is anyone using one of these > >> >> >> >> setups > >> >> >> >> successfully? The downside to option 2 is probably no on-device > >> >> >> >> native > >> >> >> >> debugging since Android Studio probably can't handle gradle > >> >> >> >> projects > >> >> >> >> without any external CMake builds set up. > >> >> >> >> > >> >> >> >> Would like some general direction & advice before I move away > >> >> >> >> from > >> >> >> >> ANT. Thanks in advance. > >> >> >> >> -- > >> >> >> >> > >> >> >> >> Powered by www.kitware.com > >> >> >> >> > >> >> >> >> Please keep messages on-topic and check the CMake FAQ at: > >> >> >> >> http://www.cmake.org/Wiki/CMake_FAQ > >> >> >> >> > >> >> >> >> Kitware offers various services to support the CMake community. > >> >> >> >> For > >> >> >> >> more > >> >> >> >> information on each offering, please visit: > >> >> >> >> > >> >> >> >> CMake Support: http://cmake.org/cmake/help/support.html > >> >> >> >> CMake Consulting: http://cmake.org/cmake/help/consulting.html > >> >> >> >> CMake Training Courses: http://cmake.org/cmake/help/ > training.html > >> >> >> >> > >> >> >> >> Visit other Kitware open-source projects at > >> >> >> >> http://www.kitware.com/opensource/opensource.html > >> >> >> >> > >> >> >> >> Follow this link to subscribe/unsubscribe: > >> >> >> >> http://public.kitware.com/mailman/listinfo/cmake > >> >> >> > > >> >> >> > > >> >> > > >> >> > > >> > > >> > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcdailey.lists at gmail.com Mon Aug 21 14:20:03 2017 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Mon, 21 Aug 2017 13:20:03 -0500 Subject: [CMake] CMake + Gradle for Android In-Reply-To: References: Message-ID: I wouldn't want to do that, it's too convoluted. I have other platforms that use these CMake scripts as well. For example, I run on Windows and Linux platforms as well to build the native code. Normal CMake behavior is designed to work at a root then go downwards to find targets. However it seems Gradle wants to start at a subdirectory and work its way up to the root, which is opposite of CMake's intended behavior IMHO. Not only that but I want to avoid special-casing behavior in CMake just for Android's use. At the moment it feels like (again referring back to my previous example structure) that both App2 and App3 each run CMake in independent binary directories instead of sharing 1 binary directory and building 2 targets inside of it. I prefer this behavior instead, especially since it allows CMake to operate as it was intended. I think it's a common case that projects will define multiple targets starting from a single root, and expect multiple APKs or java dependencies to be built within it. If I'm misunderstanding or making false assumptions please let me know. On Mon, Aug 21, 2017 at 12:00 PM, Jom O'Fisher wrote: > Would it work for your situation for the leaf CMakeLists.txt to include the > root CMakeLists.txt? Then have the leaf-specific logic in the leaf > CMakeLists.txt? > > > > On Mon, Aug 21, 2017 at 9:33 AM, Robert Dailey > wrote: >> >> Basically, yes. We have this sort of structure: >> >> / >> Applications/ >> App1/ >> build.gradle >> CMakeLists.txt >> App2/ >> build.gradle >> CMakeLists.txt >> App3/ >> build.gradle >> CMakeLists.txt >> CommonLib/ >> build.gradle >> CMakeLists.txt >> CMakeLists.txt >> >> The libs are defined as follows: >> >> * CommonLib is a static library (java code builds into a library) >> * No dependencies of its own >> * App1 is a shared library (java code builds into a library) >> * Dependencies (both java & native): CommonLib >> * App2 is a shared library (java code builds into an APK) >> * Dependencies (both java & native): App1, CommonLib >> * App3 is a shared library (java code builds into an APK) >> * Dependencies (both java & native): CommonLib >> >> In all cases, CMake must be invoked starting at the root >> CMakeLists.txt 1 time. Each target can be built from the same binary >> directory after that. Previously with ANT, I was building all native >> targets first, then moved libs to appropriate directories so that the >> 'ant' command would package the libs. >> >> For gradle, I wanted to avoid redundantly specifying the root >> directory in each leaf-level project directory. Using the example >> above, the leaf-level directories in this case would be App1, App2, >> App3, and CommonLib. However I think we only specify the native CMake >> stuff for the java targets that actually output an APK (that would be >> App2 and App3 only). >> >> The ultimate goal is to specify stuff that doesn't change per >> independent "module" of ours at the top level so it is transitive / >> inherited. Then only specify the differences (e.g. the native CMake >> target to build) in the leaf build gradle files. However you indicated >> this isn't possible. >> >> >> >> On Mon, Aug 21, 2017 at 11:11 AM, Jom O'Fisher >> wrote: >> > What you're doing already sounds correct. You can't directly specify >> > CMakeLists.txt from the top-level build.gradle. Recommendation is that >> > it >> > should be specified from the build.gradle of the module of the APK. Is >> > the >> > issue that you have multiple APK modules that all reference the same >> > CMake >> > libraries? >> > >> > On Mon, Aug 21, 2017 at 9:00 AM, Robert Dailey >> > >> > wrote: >> >> >> >> Thanks this is very helpful. The other question I have is: Is there a >> >> place to centrally specify the root CMakeLists.txt? Basically, I want >> >> to specify the CMake root in 1 place, and have targets (defined >> >> further down in subdirectories) that require APK packaging to specify >> >> only the native target name that should be built & packaged. >> >> >> >> At the moment we specify the root CMakeLists.txt by walking up the >> >> tree, paths like "../../../../CMakeLists.txt". I think this should be >> >> put at the top-level build gradle file if possible. Is this doable at >> >> the moment? What is the recommended setup? >> >> >> >> On Mon, Aug 21, 2017 at 9:37 AM, Jom O'Fisher >> >> wrote: >> >> > Gradle does introspection on the CMake build to find .so targets and >> >> > those >> >> > get packaged. >> >> > There is also a special case for stl/runtime .so files from the NDK. >> >> > Any additional .so files need to specified in build.gradle using >> >> > jniDirs >> >> > >> >> > On Mon, Aug 21, 2017 at 7:30 AM, Robert Dailey >> >> > >> >> > wrote: >> >> >> >> >> >> How exactly does Gradle package *.so files in an APK? I know that >> >> >> ANT >> >> >> used to do this for any libs under "libs/". Does Gradle do some >> >> >> introspection into CMake targets to see if outputs are *.so, and >> >> >> copy >> >> >> those to some location if needed? What about libraries like >> >> >> libgnustl_shared.so that come with the NDK? I'd like to know if any >> >> >> manual copy steps are needed in CMake to put outputs in proper >> >> >> locations for the APK build step. I had to do this when using ANT. >> >> >> >> >> >> On Mon, Aug 7, 2017 at 6:16 PM, Jom O'Fisher >> >> >> wrote: >> >> >> > 1) There is a folder created for each ABI under the project module >> >> >> > folder >> >> >> > (so unique per module per ABI) >> >> >> > 2) Gradle doesn't specify language level though you can choose to >> >> >> > specify it >> >> >> > yourself from the build.gradle. This doc does a pretty good job of >> >> >> > explaining which variables are set by Gradle: >> >> >> > https://developer.android.com/ndk/guides/cmake.html#variables. >> >> >> > Philosophically, we try to set as little as we can get away with. >> >> >> > In >> >> >> > particular, the section titled "Understanding the CMake build >> >> >> > command" >> >> >> > lays >> >> >> > out exactly what we set. You can also see the folders we specify >> >> >> > (one >> >> >> > per >> >> >> > module per ABI) >> >> >> > 3) Not sure I understand this. >> >> >> > >> >> >> > The other document worth taking a look at (if you haven't already) >> >> >> > is: >> >> >> > https://developer.android.com/studio/projects/add-native-code.html >> >> >> > >> >> >> > >> >> >> > On Mon, Aug 7, 2017 at 3:35 PM, Robert Dailey >> >> >> > >> >> >> > wrote: >> >> >> >> >> >> >> >> Thanks Jom >> >> >> >> >> >> >> >> Honestly, I prefer option 1 to work simply because that's how >> >> >> >> Google's >> >> >> >> officially supporting CMake. But it also has debugging which is >> >> >> >> the >> >> >> >> #1 >> >> >> >> reason for me. >> >> >> >> >> >> >> >> However, I'd like to understand a lot more about how the >> >> >> >> integration >> >> >> >> really happens. For example, I have these questions: >> >> >> >> >> >> >> >> 1) How, internally, are CMake build directories managed? Do you >> >> >> >> generate 1 per unique android project? What about for each >> >> >> >> specific >> >> >> >> platform (x86, armeabi-v7a, etc)? >> >> >> >> 2) Last time I looked into CMake integration, things defined >> >> >> >> inside >> >> >> >> the CMake scripts were ignored because they are specified at the >> >> >> >> command line. Namely, all of those settings that are driven by >> >> >> >> the >> >> >> >> Gradle configuration (CXX language level was one in particular I >> >> >> >> think; I specify C++14 support via CMake, but I recall this being >> >> >> >> overridden from outside)? >> >> >> >> 3) How redundant is it to configure individual libraries via the >> >> >> >> gradle scripts? In my previous attempts, I wanted to define >> >> >> >> common >> >> >> >> stuff for CMake / native code at the root gradle or settings >> >> >> >> file, >> >> >> >> and >> >> >> >> only define the differences in the actual gradle build files for >> >> >> >> each >> >> >> >> corresponding Java target (like, defining the name of the native >> >> >> >> (shared library) target in Gradle, but the command line >> >> >> >> invocation, >> >> >> >> -D >> >> >> >> CMake settings, etc would all be common and defined at the root). >> >> >> >> >> >> >> >> The TLDR is, the closer we can stay to CMake's way of doing >> >> >> >> things >> >> >> >> and >> >> >> >> keep CMake-related settings self-contained to the CMake scripts >> >> >> >> themselves, the better. This also makes cross-platform easier (we >> >> >> >> build the native code in Windows, for example, so having settings >> >> >> >> specified in the gradle files do not carry over to other >> >> >> >> platforms. >> >> >> >> Namely, settings that are not platform specific like the C++ >> >> >> >> language >> >> >> >> level). >> >> >> >> >> >> >> >> If there's a detailed document / wiki I can read on the >> >> >> >> intrinsics >> >> >> >> of >> >> >> >> CMake integration in Gradle / Android Studio, I'd love to read >> >> >> >> it. >> >> >> >> Otherwise, I hope you won't mind if I pick your brain as >> >> >> >> questions >> >> >> >> come up. I think I'm going to try option 1 for now and see how it >> >> >> >> goes. It's just black box for me because unlike option 2, I have >> >> >> >> very >> >> >> >> little control over what happens after building the shared >> >> >> >> libraries, >> >> >> >> and to make up for that I need to really get a deep understanding >> >> >> >> of >> >> >> >> how it works so I can make sure I code my CMake scripts properly >> >> >> >> for >> >> >> >> not only Android, but my other platforms as well (non-Android >> >> >> >> platforms). >> >> >> >> >> >> >> >> Thanks again. >> >> >> >> >> >> >> >> On Mon, Aug 7, 2017 at 5:12 PM, Jom O'Fisher >> >> >> >> >> >> >> >> wrote: >> >> >> >> > Either option can work fine. Disclosure: I work on Android >> >> >> >> > Studio >> >> >> >> > and >> >> >> >> > was >> >> >> >> > the one that added CMake support. >> >> >> >> > >> >> >> >> > Option (1) is the way it's designed to work and we're working >> >> >> >> > toward >> >> >> >> > getting >> >> >> >> > rid of the need for the CMake fork. I can't really say when >> >> >> >> > that >> >> >> >> > will >> >> >> >> > happen >> >> >> >> > but if you can get away with an older CMake for now then I'd go >> >> >> >> > this >> >> >> >> > way. >> >> >> >> > As you mentioned, option (1) will allow you to view your source >> >> >> >> > file >> >> >> >> > structure in Android Studio, edit files, and debug using the >> >> >> >> > built-in >> >> >> >> > debugging support. >> >> >> >> > >> >> >> >> > To get option (2) to work, you can use jniDirs setting to tell >> >> >> >> > Android >> >> >> >> > Gradle where to pick up your built .so files (see >> >> >> >> > >> >> >> >> > >> >> >> >> > >> >> >> >> > >> >> >> >> > https://stackoverflow.com/questions/21255125/how-can-i-add-so-files-to-an-android-library-project-using-gradle-0-7). >> >> >> >> > I'm not aware of any projects that use this approach but it >> >> >> >> > should >> >> >> >> > work >> >> >> >> > in >> >> >> >> > principal. >> >> >> >> > >> >> >> >> > I hope this helps, >> >> >> >> > Jomo >> >> >> >> > >> >> >> >> > >> >> >> >> > On Mon, Aug 7, 2017 at 11:09 AM, Robert Dailey >> >> >> >> > >> >> >> >> > wrote: >> >> >> >> >> >> >> >> >> >> Right now I have custom targets set to execute the "ant >> >> >> >> >> release" >> >> >> >> >> command after my native targets are built. Part of that >> >> >> >> >> command >> >> >> >> >> involves copying *.so files to the libs/armeabi-v7a directory >> >> >> >> >> so >> >> >> >> >> they >> >> >> >> >> get packaged in an APK. >> >> >> >> >> >> >> >> >> >> When switching to gradle, I have two options: >> >> >> >> >> >> >> >> >> >> 1. Gradle drives CMake: This means using Android Studio and >> >> >> >> >> being >> >> >> >> >> locked down to Google's fork of CMake which is a few major >> >> >> >> >> releases >> >> >> >> >> behind. I see that as a negative. >> >> >> >> >> >> >> >> >> >> 2. CMake drives Gradle: This would be the same or similar to >> >> >> >> >> what >> >> >> >> >> I'm >> >> >> >> >> already doing: The custom targets I have would execute gradle >> >> >> >> >> as >> >> >> >> >> a >> >> >> >> >> separate build step, instead of running ant commands. I'm not >> >> >> >> >> too >> >> >> >> >> familiar with Gradle, so I'm not sure how you tell it where >> >> >> >> >> your >> >> >> >> >> shared libraries are for the APK packaging steps. >> >> >> >> >> >> >> >> >> >> Which does everyone recommend? Is anyone using one of these >> >> >> >> >> setups >> >> >> >> >> successfully? The downside to option 2 is probably no >> >> >> >> >> on-device >> >> >> >> >> native >> >> >> >> >> debugging since Android Studio probably can't handle gradle >> >> >> >> >> projects >> >> >> >> >> without any external CMake builds set up. >> >> >> >> >> >> >> >> >> >> Would like some general direction & advice before I move away >> >> >> >> >> from >> >> >> >> >> ANT. Thanks in advance. >> >> >> >> >> -- >> >> >> >> >> >> >> >> >> >> Powered by www.kitware.com >> >> >> >> >> >> >> >> >> >> Please keep messages on-topic and check the CMake FAQ at: >> >> >> >> >> http://www.cmake.org/Wiki/CMake_FAQ >> >> >> >> >> >> >> >> >> >> Kitware offers various services to support the CMake >> >> >> >> >> community. >> >> >> >> >> For >> >> >> >> >> more >> >> >> >> >> information on each offering, please visit: >> >> >> >> >> >> >> >> >> >> CMake Support: http://cmake.org/cmake/help/support.html >> >> >> >> >> CMake Consulting: http://cmake.org/cmake/help/consulting.html >> >> >> >> >> CMake Training Courses: >> >> >> >> >> http://cmake.org/cmake/help/training.html >> >> >> >> >> >> >> >> >> >> Visit other Kitware open-source projects at >> >> >> >> >> http://www.kitware.com/opensource/opensource.html >> >> >> >> >> >> >> >> >> >> Follow this link to subscribe/unsubscribe: >> >> >> >> >> http://public.kitware.com/mailman/listinfo/cmake >> >> >> >> > >> >> >> >> > >> >> >> > >> >> >> > >> >> > >> >> > >> > >> > > > From jomofisher at gmail.com Mon Aug 21 15:35:39 2017 From: jomofisher at gmail.com (Jom O'Fisher) Date: Mon, 21 Aug 2017 12:35:39 -0700 Subject: [CMake] CMake + Gradle for Android In-Reply-To: References: Message-ID: Would it work for your scenario to provide properties in the root build.gradle: ext { cmakePath = file "CMakeLists.txt" } And then consume them in the leaf app/build.gradle like this? externalNativeBuild { cmake { path cmakePath } } It doesn't fully hide the details but it does centralize the information. On Mon, Aug 21, 2017 at 11:20 AM, Robert Dailey wrote: > I wouldn't want to do that, it's too convoluted. I have other > platforms that use these CMake scripts as well. For example, I run on > Windows and Linux platforms as well to build the native code. Normal > CMake behavior is designed to work at a root then go downwards to find > targets. However it seems Gradle wants to start at a subdirectory and > work its way up to the root, which is opposite of CMake's intended > behavior IMHO. Not only that but I want to avoid special-casing > behavior in CMake just for Android's use. > > At the moment it feels like (again referring back to my previous > example structure) that both App2 and App3 each run CMake in > independent binary directories instead of sharing 1 binary directory > and building 2 targets inside of it. I prefer this behavior instead, > especially since it allows CMake to operate as it was intended. I > think it's a common case that projects will define multiple targets > starting from a single root, and expect multiple APKs or java > dependencies to be built within it. > > If I'm misunderstanding or making false assumptions please let me know. > > > > On Mon, Aug 21, 2017 at 12:00 PM, Jom O'Fisher > wrote: > > Would it work for your situation for the leaf CMakeLists.txt to include > the > > root CMakeLists.txt? Then have the leaf-specific logic in the leaf > > CMakeLists.txt? > > > > > > > > On Mon, Aug 21, 2017 at 9:33 AM, Robert Dailey > > > wrote: > >> > >> Basically, yes. We have this sort of structure: > >> > >> / > >> Applications/ > >> App1/ > >> build.gradle > >> CMakeLists.txt > >> App2/ > >> build.gradle > >> CMakeLists.txt > >> App3/ > >> build.gradle > >> CMakeLists.txt > >> CommonLib/ > >> build.gradle > >> CMakeLists.txt > >> CMakeLists.txt > >> > >> The libs are defined as follows: > >> > >> * CommonLib is a static library (java code builds into a library) > >> * No dependencies of its own > >> * App1 is a shared library (java code builds into a library) > >> * Dependencies (both java & native): CommonLib > >> * App2 is a shared library (java code builds into an APK) > >> * Dependencies (both java & native): App1, CommonLib > >> * App3 is a shared library (java code builds into an APK) > >> * Dependencies (both java & native): CommonLib > >> > >> In all cases, CMake must be invoked starting at the root > >> CMakeLists.txt 1 time. Each target can be built from the same binary > >> directory after that. Previously with ANT, I was building all native > >> targets first, then moved libs to appropriate directories so that the > >> 'ant' command would package the libs. > >> > >> For gradle, I wanted to avoid redundantly specifying the root > >> directory in each leaf-level project directory. Using the example > >> above, the leaf-level directories in this case would be App1, App2, > >> App3, and CommonLib. However I think we only specify the native CMake > >> stuff for the java targets that actually output an APK (that would be > >> App2 and App3 only). > >> > >> The ultimate goal is to specify stuff that doesn't change per > >> independent "module" of ours at the top level so it is transitive / > >> inherited. Then only specify the differences (e.g. the native CMake > >> target to build) in the leaf build gradle files. However you indicated > >> this isn't possible. > >> > >> > >> > >> On Mon, Aug 21, 2017 at 11:11 AM, Jom O'Fisher > >> wrote: > >> > What you're doing already sounds correct. You can't directly specify > >> > CMakeLists.txt from the top-level build.gradle. Recommendation is that > >> > it > >> > should be specified from the build.gradle of the module of the APK. Is > >> > the > >> > issue that you have multiple APK modules that all reference the same > >> > CMake > >> > libraries? > >> > > >> > On Mon, Aug 21, 2017 at 9:00 AM, Robert Dailey > >> > > >> > wrote: > >> >> > >> >> Thanks this is very helpful. The other question I have is: Is there a > >> >> place to centrally specify the root CMakeLists.txt? Basically, I want > >> >> to specify the CMake root in 1 place, and have targets (defined > >> >> further down in subdirectories) that require APK packaging to specify > >> >> only the native target name that should be built & packaged. > >> >> > >> >> At the moment we specify the root CMakeLists.txt by walking up the > >> >> tree, paths like "../../../../CMakeLists.txt". I think this should be > >> >> put at the top-level build gradle file if possible. Is this doable at > >> >> the moment? What is the recommended setup? > >> >> > >> >> On Mon, Aug 21, 2017 at 9:37 AM, Jom O'Fisher > >> >> wrote: > >> >> > Gradle does introspection on the CMake build to find .so targets > and > >> >> > those > >> >> > get packaged. > >> >> > There is also a special case for stl/runtime .so files from the > NDK. > >> >> > Any additional .so files need to specified in build.gradle using > >> >> > jniDirs > >> >> > > >> >> > On Mon, Aug 21, 2017 at 7:30 AM, Robert Dailey > >> >> > > >> >> > wrote: > >> >> >> > >> >> >> How exactly does Gradle package *.so files in an APK? I know that > >> >> >> ANT > >> >> >> used to do this for any libs under "libs/". Does Gradle do > some > >> >> >> introspection into CMake targets to see if outputs are *.so, and > >> >> >> copy > >> >> >> those to some location if needed? What about libraries like > >> >> >> libgnustl_shared.so that come with the NDK? I'd like to know if > any > >> >> >> manual copy steps are needed in CMake to put outputs in proper > >> >> >> locations for the APK build step. I had to do this when using ANT. > >> >> >> > >> >> >> On Mon, Aug 7, 2017 at 6:16 PM, Jom O'Fisher < > jomofisher at gmail.com> > >> >> >> wrote: > >> >> >> > 1) There is a folder created for each ABI under the project > module > >> >> >> > folder > >> >> >> > (so unique per module per ABI) > >> >> >> > 2) Gradle doesn't specify language level though you can choose > to > >> >> >> > specify it > >> >> >> > yourself from the build.gradle. This doc does a pretty good job > of > >> >> >> > explaining which variables are set by Gradle: > >> >> >> > https://developer.android.com/ndk/guides/cmake.html#variables. > >> >> >> > Philosophically, we try to set as little as we can get away > with. > >> >> >> > In > >> >> >> > particular, the section titled "Understanding the CMake build > >> >> >> > command" > >> >> >> > lays > >> >> >> > out exactly what we set. You can also see the folders we specify > >> >> >> > (one > >> >> >> > per > >> >> >> > module per ABI) > >> >> >> > 3) Not sure I understand this. > >> >> >> > > >> >> >> > The other document worth taking a look at (if you haven't > already) > >> >> >> > is: > >> >> >> > https://developer.android.com/studio/projects/add-native- > code.html > >> >> >> > > >> >> >> > > >> >> >> > On Mon, Aug 7, 2017 at 3:35 PM, Robert Dailey > >> >> >> > > >> >> >> > wrote: > >> >> >> >> > >> >> >> >> Thanks Jom > >> >> >> >> > >> >> >> >> Honestly, I prefer option 1 to work simply because that's how > >> >> >> >> Google's > >> >> >> >> officially supporting CMake. But it also has debugging which is > >> >> >> >> the > >> >> >> >> #1 > >> >> >> >> reason for me. > >> >> >> >> > >> >> >> >> However, I'd like to understand a lot more about how the > >> >> >> >> integration > >> >> >> >> really happens. For example, I have these questions: > >> >> >> >> > >> >> >> >> 1) How, internally, are CMake build directories managed? Do you > >> >> >> >> generate 1 per unique android project? What about for each > >> >> >> >> specific > >> >> >> >> platform (x86, armeabi-v7a, etc)? > >> >> >> >> 2) Last time I looked into CMake integration, things defined > >> >> >> >> inside > >> >> >> >> the CMake scripts were ignored because they are specified at > the > >> >> >> >> command line. Namely, all of those settings that are driven by > >> >> >> >> the > >> >> >> >> Gradle configuration (CXX language level was one in particular > I > >> >> >> >> think; I specify C++14 support via CMake, but I recall this > being > >> >> >> >> overridden from outside)? > >> >> >> >> 3) How redundant is it to configure individual libraries via > the > >> >> >> >> gradle scripts? In my previous attempts, I wanted to define > >> >> >> >> common > >> >> >> >> stuff for CMake / native code at the root gradle or settings > >> >> >> >> file, > >> >> >> >> and > >> >> >> >> only define the differences in the actual gradle build files > for > >> >> >> >> each > >> >> >> >> corresponding Java target (like, defining the name of the > native > >> >> >> >> (shared library) target in Gradle, but the command line > >> >> >> >> invocation, > >> >> >> >> -D > >> >> >> >> CMake settings, etc would all be common and defined at the > root). > >> >> >> >> > >> >> >> >> The TLDR is, the closer we can stay to CMake's way of doing > >> >> >> >> things > >> >> >> >> and > >> >> >> >> keep CMake-related settings self-contained to the CMake scripts > >> >> >> >> themselves, the better. This also makes cross-platform easier > (we > >> >> >> >> build the native code in Windows, for example, so having > settings > >> >> >> >> specified in the gradle files do not carry over to other > >> >> >> >> platforms. > >> >> >> >> Namely, settings that are not platform specific like the C++ > >> >> >> >> language > >> >> >> >> level). > >> >> >> >> > >> >> >> >> If there's a detailed document / wiki I can read on the > >> >> >> >> intrinsics > >> >> >> >> of > >> >> >> >> CMake integration in Gradle / Android Studio, I'd love to read > >> >> >> >> it. > >> >> >> >> Otherwise, I hope you won't mind if I pick your brain as > >> >> >> >> questions > >> >> >> >> come up. I think I'm going to try option 1 for now and see how > it > >> >> >> >> goes. It's just black box for me because unlike option 2, I > have > >> >> >> >> very > >> >> >> >> little control over what happens after building the shared > >> >> >> >> libraries, > >> >> >> >> and to make up for that I need to really get a deep > understanding > >> >> >> >> of > >> >> >> >> how it works so I can make sure I code my CMake scripts > properly > >> >> >> >> for > >> >> >> >> not only Android, but my other platforms as well (non-Android > >> >> >> >> platforms). > >> >> >> >> > >> >> >> >> Thanks again. > >> >> >> >> > >> >> >> >> On Mon, Aug 7, 2017 at 5:12 PM, Jom O'Fisher > >> >> >> >> > >> >> >> >> wrote: > >> >> >> >> > Either option can work fine. Disclosure: I work on Android > >> >> >> >> > Studio > >> >> >> >> > and > >> >> >> >> > was > >> >> >> >> > the one that added CMake support. > >> >> >> >> > > >> >> >> >> > Option (1) is the way it's designed to work and we're working > >> >> >> >> > toward > >> >> >> >> > getting > >> >> >> >> > rid of the need for the CMake fork. I can't really say when > >> >> >> >> > that > >> >> >> >> > will > >> >> >> >> > happen > >> >> >> >> > but if you can get away with an older CMake for now then I'd > go > >> >> >> >> > this > >> >> >> >> > way. > >> >> >> >> > As you mentioned, option (1) will allow you to view your > source > >> >> >> >> > file > >> >> >> >> > structure in Android Studio, edit files, and debug using the > >> >> >> >> > built-in > >> >> >> >> > debugging support. > >> >> >> >> > > >> >> >> >> > To get option (2) to work, you can use jniDirs setting to > tell > >> >> >> >> > Android > >> >> >> >> > Gradle where to pick up your built .so files (see > >> >> >> >> > > >> >> >> >> > > >> >> >> >> > > >> >> >> >> > > >> >> >> >> > https://stackoverflow.com/questions/21255125/how-can-i- > add-so-files-to-an-android-library-project-using-gradle-0-7). > >> >> >> >> > I'm not aware of any projects that use this approach but it > >> >> >> >> > should > >> >> >> >> > work > >> >> >> >> > in > >> >> >> >> > principal. > >> >> >> >> > > >> >> >> >> > I hope this helps, > >> >> >> >> > Jomo > >> >> >> >> > > >> >> >> >> > > >> >> >> >> > On Mon, Aug 7, 2017 at 11:09 AM, Robert Dailey > >> >> >> >> > > >> >> >> >> > wrote: > >> >> >> >> >> > >> >> >> >> >> Right now I have custom targets set to execute the "ant > >> >> >> >> >> release" > >> >> >> >> >> command after my native targets are built. Part of that > >> >> >> >> >> command > >> >> >> >> >> involves copying *.so files to the libs/armeabi-v7a > directory > >> >> >> >> >> so > >> >> >> >> >> they > >> >> >> >> >> get packaged in an APK. > >> >> >> >> >> > >> >> >> >> >> When switching to gradle, I have two options: > >> >> >> >> >> > >> >> >> >> >> 1. Gradle drives CMake: This means using Android Studio and > >> >> >> >> >> being > >> >> >> >> >> locked down to Google's fork of CMake which is a few major > >> >> >> >> >> releases > >> >> >> >> >> behind. I see that as a negative. > >> >> >> >> >> > >> >> >> >> >> 2. CMake drives Gradle: This would be the same or similar to > >> >> >> >> >> what > >> >> >> >> >> I'm > >> >> >> >> >> already doing: The custom targets I have would execute > gradle > >> >> >> >> >> as > >> >> >> >> >> a > >> >> >> >> >> separate build step, instead of running ant commands. I'm > not > >> >> >> >> >> too > >> >> >> >> >> familiar with Gradle, so I'm not sure how you tell it where > >> >> >> >> >> your > >> >> >> >> >> shared libraries are for the APK packaging steps. > >> >> >> >> >> > >> >> >> >> >> Which does everyone recommend? Is anyone using one of these > >> >> >> >> >> setups > >> >> >> >> >> successfully? The downside to option 2 is probably no > >> >> >> >> >> on-device > >> >> >> >> >> native > >> >> >> >> >> debugging since Android Studio probably can't handle gradle > >> >> >> >> >> projects > >> >> >> >> >> without any external CMake builds set up. > >> >> >> >> >> > >> >> >> >> >> Would like some general direction & advice before I move > away > >> >> >> >> >> from > >> >> >> >> >> ANT. Thanks in advance. > >> >> >> >> >> -- > >> >> >> >> >> > >> >> >> >> >> Powered by www.kitware.com > >> >> >> >> >> > >> >> >> >> >> Please keep messages on-topic and check the CMake FAQ at: > >> >> >> >> >> http://www.cmake.org/Wiki/CMake_FAQ > >> >> >> >> >> > >> >> >> >> >> Kitware offers various services to support the CMake > >> >> >> >> >> community. > >> >> >> >> >> For > >> >> >> >> >> more > >> >> >> >> >> information on each offering, please visit: > >> >> >> >> >> > >> >> >> >> >> CMake Support: http://cmake.org/cmake/help/support.html > >> >> >> >> >> CMake Consulting: http://cmake.org/cmake/help/ > consulting.html > >> >> >> >> >> CMake Training Courses: > >> >> >> >> >> http://cmake.org/cmake/help/training.html > >> >> >> >> >> > >> >> >> >> >> Visit other Kitware open-source projects at > >> >> >> >> >> http://www.kitware.com/opensource/opensource.html > >> >> >> >> >> > >> >> >> >> >> Follow this link to subscribe/unsubscribe: > >> >> >> >> >> http://public.kitware.com/mailman/listinfo/cmake > >> >> >> >> > > >> >> >> >> > > >> >> >> > > >> >> >> > > >> >> > > >> >> > > >> > > >> > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcdailey.lists at gmail.com Mon Aug 21 17:41:44 2017 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Mon, 21 Aug 2017 16:41:44 -0500 Subject: [CMake] CMake + Gradle for Android In-Reply-To: References: Message-ID: This definitely a bit better, but still requires the boilerplate in each leaf gradle file. But I can't seriously complain too much. I think I'm more concerned with the implications this has underneath. First, let me ask just to make sure I'm not misunderstanding: Does each `externalNativeBuild` entry essentially mean 1 CMAKE_BINARY_DIR? How many binary dirs do you manage internally and what determines when they get created? On Mon, Aug 21, 2017 at 2:35 PM, Jom O'Fisher wrote: > Would it work for your scenario to provide properties in the root > build.gradle: > > ext { > cmakePath = file "CMakeLists.txt" > } > > And then consume them in the leaf app/build.gradle like this? > > externalNativeBuild { > cmake { > path cmakePath > } > } > > It doesn't fully hide the details but it does centralize the information. > > > On Mon, Aug 21, 2017 at 11:20 AM, Robert Dailey > wrote: >> >> I wouldn't want to do that, it's too convoluted. I have other >> platforms that use these CMake scripts as well. For example, I run on >> Windows and Linux platforms as well to build the native code. Normal >> CMake behavior is designed to work at a root then go downwards to find >> targets. However it seems Gradle wants to start at a subdirectory and >> work its way up to the root, which is opposite of CMake's intended >> behavior IMHO. Not only that but I want to avoid special-casing >> behavior in CMake just for Android's use. >> >> At the moment it feels like (again referring back to my previous >> example structure) that both App2 and App3 each run CMake in >> independent binary directories instead of sharing 1 binary directory >> and building 2 targets inside of it. I prefer this behavior instead, >> especially since it allows CMake to operate as it was intended. I >> think it's a common case that projects will define multiple targets >> starting from a single root, and expect multiple APKs or java >> dependencies to be built within it. >> >> If I'm misunderstanding or making false assumptions please let me know. >> >> >> >> On Mon, Aug 21, 2017 at 12:00 PM, Jom O'Fisher >> wrote: >> > Would it work for your situation for the leaf CMakeLists.txt to include >> > the >> > root CMakeLists.txt? Then have the leaf-specific logic in the leaf >> > CMakeLists.txt? >> > >> > >> > >> > On Mon, Aug 21, 2017 at 9:33 AM, Robert Dailey >> > >> > wrote: >> >> >> >> Basically, yes. We have this sort of structure: >> >> >> >> / >> >> Applications/ >> >> App1/ >> >> build.gradle >> >> CMakeLists.txt >> >> App2/ >> >> build.gradle >> >> CMakeLists.txt >> >> App3/ >> >> build.gradle >> >> CMakeLists.txt >> >> CommonLib/ >> >> build.gradle >> >> CMakeLists.txt >> >> CMakeLists.txt >> >> >> >> The libs are defined as follows: >> >> >> >> * CommonLib is a static library (java code builds into a library) >> >> * No dependencies of its own >> >> * App1 is a shared library (java code builds into a library) >> >> * Dependencies (both java & native): CommonLib >> >> * App2 is a shared library (java code builds into an APK) >> >> * Dependencies (both java & native): App1, CommonLib >> >> * App3 is a shared library (java code builds into an APK) >> >> * Dependencies (both java & native): CommonLib >> >> >> >> In all cases, CMake must be invoked starting at the root >> >> CMakeLists.txt 1 time. Each target can be built from the same binary >> >> directory after that. Previously with ANT, I was building all native >> >> targets first, then moved libs to appropriate directories so that the >> >> 'ant' command would package the libs. >> >> >> >> For gradle, I wanted to avoid redundantly specifying the root >> >> directory in each leaf-level project directory. Using the example >> >> above, the leaf-level directories in this case would be App1, App2, >> >> App3, and CommonLib. However I think we only specify the native CMake >> >> stuff for the java targets that actually output an APK (that would be >> >> App2 and App3 only). >> >> >> >> The ultimate goal is to specify stuff that doesn't change per >> >> independent "module" of ours at the top level so it is transitive / >> >> inherited. Then only specify the differences (e.g. the native CMake >> >> target to build) in the leaf build gradle files. However you indicated >> >> this isn't possible. >> >> >> >> >> >> >> >> On Mon, Aug 21, 2017 at 11:11 AM, Jom O'Fisher >> >> wrote: >> >> > What you're doing already sounds correct. You can't directly specify >> >> > CMakeLists.txt from the top-level build.gradle. Recommendation is >> >> > that >> >> > it >> >> > should be specified from the build.gradle of the module of the APK. >> >> > Is >> >> > the >> >> > issue that you have multiple APK modules that all reference the same >> >> > CMake >> >> > libraries? >> >> > >> >> > On Mon, Aug 21, 2017 at 9:00 AM, Robert Dailey >> >> > >> >> > wrote: >> >> >> >> >> >> Thanks this is very helpful. The other question I have is: Is there >> >> >> a >> >> >> place to centrally specify the root CMakeLists.txt? Basically, I >> >> >> want >> >> >> to specify the CMake root in 1 place, and have targets (defined >> >> >> further down in subdirectories) that require APK packaging to >> >> >> specify >> >> >> only the native target name that should be built & packaged. >> >> >> >> >> >> At the moment we specify the root CMakeLists.txt by walking up the >> >> >> tree, paths like "../../../../CMakeLists.txt". I think this should >> >> >> be >> >> >> put at the top-level build gradle file if possible. Is this doable >> >> >> at >> >> >> the moment? What is the recommended setup? >> >> >> >> >> >> On Mon, Aug 21, 2017 at 9:37 AM, Jom O'Fisher >> >> >> wrote: >> >> >> > Gradle does introspection on the CMake build to find .so targets >> >> >> > and >> >> >> > those >> >> >> > get packaged. >> >> >> > There is also a special case for stl/runtime .so files from the >> >> >> > NDK. >> >> >> > Any additional .so files need to specified in build.gradle using >> >> >> > jniDirs >> >> >> > >> >> >> > On Mon, Aug 21, 2017 at 7:30 AM, Robert Dailey >> >> >> > >> >> >> > wrote: >> >> >> >> >> >> >> >> How exactly does Gradle package *.so files in an APK? I know that >> >> >> >> ANT >> >> >> >> used to do this for any libs under "libs/". Does Gradle do >> >> >> >> some >> >> >> >> introspection into CMake targets to see if outputs are *.so, and >> >> >> >> copy >> >> >> >> those to some location if needed? What about libraries like >> >> >> >> libgnustl_shared.so that come with the NDK? I'd like to know if >> >> >> >> any >> >> >> >> manual copy steps are needed in CMake to put outputs in proper >> >> >> >> locations for the APK build step. I had to do this when using >> >> >> >> ANT. >> >> >> >> >> >> >> >> On Mon, Aug 7, 2017 at 6:16 PM, Jom O'Fisher >> >> >> >> >> >> >> >> wrote: >> >> >> >> > 1) There is a folder created for each ABI under the project >> >> >> >> > module >> >> >> >> > folder >> >> >> >> > (so unique per module per ABI) >> >> >> >> > 2) Gradle doesn't specify language level though you can choose >> >> >> >> > to >> >> >> >> > specify it >> >> >> >> > yourself from the build.gradle. This doc does a pretty good job >> >> >> >> > of >> >> >> >> > explaining which variables are set by Gradle: >> >> >> >> > https://developer.android.com/ndk/guides/cmake.html#variables. >> >> >> >> > Philosophically, we try to set as little as we can get away >> >> >> >> > with. >> >> >> >> > In >> >> >> >> > particular, the section titled "Understanding the CMake build >> >> >> >> > command" >> >> >> >> > lays >> >> >> >> > out exactly what we set. You can also see the folders we >> >> >> >> > specify >> >> >> >> > (one >> >> >> >> > per >> >> >> >> > module per ABI) >> >> >> >> > 3) Not sure I understand this. >> >> >> >> > >> >> >> >> > The other document worth taking a look at (if you haven't >> >> >> >> > already) >> >> >> >> > is: >> >> >> >> > >> >> >> >> > https://developer.android.com/studio/projects/add-native-code.html >> >> >> >> > >> >> >> >> > >> >> >> >> > On Mon, Aug 7, 2017 at 3:35 PM, Robert Dailey >> >> >> >> > >> >> >> >> > wrote: >> >> >> >> >> >> >> >> >> >> Thanks Jom >> >> >> >> >> >> >> >> >> >> Honestly, I prefer option 1 to work simply because that's how >> >> >> >> >> Google's >> >> >> >> >> officially supporting CMake. But it also has debugging which >> >> >> >> >> is >> >> >> >> >> the >> >> >> >> >> #1 >> >> >> >> >> reason for me. >> >> >> >> >> >> >> >> >> >> However, I'd like to understand a lot more about how the >> >> >> >> >> integration >> >> >> >> >> really happens. For example, I have these questions: >> >> >> >> >> >> >> >> >> >> 1) How, internally, are CMake build directories managed? Do >> >> >> >> >> you >> >> >> >> >> generate 1 per unique android project? What about for each >> >> >> >> >> specific >> >> >> >> >> platform (x86, armeabi-v7a, etc)? >> >> >> >> >> 2) Last time I looked into CMake integration, things defined >> >> >> >> >> inside >> >> >> >> >> the CMake scripts were ignored because they are specified at >> >> >> >> >> the >> >> >> >> >> command line. Namely, all of those settings that are driven by >> >> >> >> >> the >> >> >> >> >> Gradle configuration (CXX language level was one in particular >> >> >> >> >> I >> >> >> >> >> think; I specify C++14 support via CMake, but I recall this >> >> >> >> >> being >> >> >> >> >> overridden from outside)? >> >> >> >> >> 3) How redundant is it to configure individual libraries via >> >> >> >> >> the >> >> >> >> >> gradle scripts? In my previous attempts, I wanted to define >> >> >> >> >> common >> >> >> >> >> stuff for CMake / native code at the root gradle or settings >> >> >> >> >> file, >> >> >> >> >> and >> >> >> >> >> only define the differences in the actual gradle build files >> >> >> >> >> for >> >> >> >> >> each >> >> >> >> >> corresponding Java target (like, defining the name of the >> >> >> >> >> native >> >> >> >> >> (shared library) target in Gradle, but the command line >> >> >> >> >> invocation, >> >> >> >> >> -D >> >> >> >> >> CMake settings, etc would all be common and defined at the >> >> >> >> >> root). >> >> >> >> >> >> >> >> >> >> The TLDR is, the closer we can stay to CMake's way of doing >> >> >> >> >> things >> >> >> >> >> and >> >> >> >> >> keep CMake-related settings self-contained to the CMake >> >> >> >> >> scripts >> >> >> >> >> themselves, the better. This also makes cross-platform easier >> >> >> >> >> (we >> >> >> >> >> build the native code in Windows, for example, so having >> >> >> >> >> settings >> >> >> >> >> specified in the gradle files do not carry over to other >> >> >> >> >> platforms. >> >> >> >> >> Namely, settings that are not platform specific like the C++ >> >> >> >> >> language >> >> >> >> >> level). >> >> >> >> >> >> >> >> >> >> If there's a detailed document / wiki I can read on the >> >> >> >> >> intrinsics >> >> >> >> >> of >> >> >> >> >> CMake integration in Gradle / Android Studio, I'd love to read >> >> >> >> >> it. >> >> >> >> >> Otherwise, I hope you won't mind if I pick your brain as >> >> >> >> >> questions >> >> >> >> >> come up. I think I'm going to try option 1 for now and see how >> >> >> >> >> it >> >> >> >> >> goes. It's just black box for me because unlike option 2, I >> >> >> >> >> have >> >> >> >> >> very >> >> >> >> >> little control over what happens after building the shared >> >> >> >> >> libraries, >> >> >> >> >> and to make up for that I need to really get a deep >> >> >> >> >> understanding >> >> >> >> >> of >> >> >> >> >> how it works so I can make sure I code my CMake scripts >> >> >> >> >> properly >> >> >> >> >> for >> >> >> >> >> not only Android, but my other platforms as well (non-Android >> >> >> >> >> platforms). >> >> >> >> >> >> >> >> >> >> Thanks again. >> >> >> >> >> >> >> >> >> >> On Mon, Aug 7, 2017 at 5:12 PM, Jom O'Fisher >> >> >> >> >> >> >> >> >> >> wrote: >> >> >> >> >> > Either option can work fine. Disclosure: I work on Android >> >> >> >> >> > Studio >> >> >> >> >> > and >> >> >> >> >> > was >> >> >> >> >> > the one that added CMake support. >> >> >> >> >> > >> >> >> >> >> > Option (1) is the way it's designed to work and we're >> >> >> >> >> > working >> >> >> >> >> > toward >> >> >> >> >> > getting >> >> >> >> >> > rid of the need for the CMake fork. I can't really say when >> >> >> >> >> > that >> >> >> >> >> > will >> >> >> >> >> > happen >> >> >> >> >> > but if you can get away with an older CMake for now then I'd >> >> >> >> >> > go >> >> >> >> >> > this >> >> >> >> >> > way. >> >> >> >> >> > As you mentioned, option (1) will allow you to view your >> >> >> >> >> > source >> >> >> >> >> > file >> >> >> >> >> > structure in Android Studio, edit files, and debug using the >> >> >> >> >> > built-in >> >> >> >> >> > debugging support. >> >> >> >> >> > >> >> >> >> >> > To get option (2) to work, you can use jniDirs setting to >> >> >> >> >> > tell >> >> >> >> >> > Android >> >> >> >> >> > Gradle where to pick up your built .so files (see >> >> >> >> >> > >> >> >> >> >> > >> >> >> >> >> > >> >> >> >> >> > >> >> >> >> >> > >> >> >> >> >> > https://stackoverflow.com/questions/21255125/how-can-i-add-so-files-to-an-android-library-project-using-gradle-0-7). >> >> >> >> >> > I'm not aware of any projects that use this approach but it >> >> >> >> >> > should >> >> >> >> >> > work >> >> >> >> >> > in >> >> >> >> >> > principal. >> >> >> >> >> > >> >> >> >> >> > I hope this helps, >> >> >> >> >> > Jomo >> >> >> >> >> > >> >> >> >> >> > >> >> >> >> >> > On Mon, Aug 7, 2017 at 11:09 AM, Robert Dailey >> >> >> >> >> > >> >> >> >> >> > wrote: >> >> >> >> >> >> >> >> >> >> >> >> Right now I have custom targets set to execute the "ant >> >> >> >> >> >> release" >> >> >> >> >> >> command after my native targets are built. Part of that >> >> >> >> >> >> command >> >> >> >> >> >> involves copying *.so files to the libs/armeabi-v7a >> >> >> >> >> >> directory >> >> >> >> >> >> so >> >> >> >> >> >> they >> >> >> >> >> >> get packaged in an APK. >> >> >> >> >> >> >> >> >> >> >> >> When switching to gradle, I have two options: >> >> >> >> >> >> >> >> >> >> >> >> 1. Gradle drives CMake: This means using Android Studio and >> >> >> >> >> >> being >> >> >> >> >> >> locked down to Google's fork of CMake which is a few major >> >> >> >> >> >> releases >> >> >> >> >> >> behind. I see that as a negative. >> >> >> >> >> >> >> >> >> >> >> >> 2. CMake drives Gradle: This would be the same or similar >> >> >> >> >> >> to >> >> >> >> >> >> what >> >> >> >> >> >> I'm >> >> >> >> >> >> already doing: The custom targets I have would execute >> >> >> >> >> >> gradle >> >> >> >> >> >> as >> >> >> >> >> >> a >> >> >> >> >> >> separate build step, instead of running ant commands. I'm >> >> >> >> >> >> not >> >> >> >> >> >> too >> >> >> >> >> >> familiar with Gradle, so I'm not sure how you tell it where >> >> >> >> >> >> your >> >> >> >> >> >> shared libraries are for the APK packaging steps. >> >> >> >> >> >> >> >> >> >> >> >> Which does everyone recommend? Is anyone using one of these >> >> >> >> >> >> setups >> >> >> >> >> >> successfully? The downside to option 2 is probably no >> >> >> >> >> >> on-device >> >> >> >> >> >> native >> >> >> >> >> >> debugging since Android Studio probably can't handle gradle >> >> >> >> >> >> projects >> >> >> >> >> >> without any external CMake builds set up. >> >> >> >> >> >> >> >> >> >> >> >> Would like some general direction & advice before I move >> >> >> >> >> >> away >> >> >> >> >> >> from >> >> >> >> >> >> ANT. Thanks in advance. >> >> >> >> >> >> -- >> >> >> >> >> >> >> >> >> >> >> >> Powered by www.kitware.com >> >> >> >> >> >> >> >> >> >> >> >> Please keep messages on-topic and check the CMake FAQ at: >> >> >> >> >> >> http://www.cmake.org/Wiki/CMake_FAQ >> >> >> >> >> >> >> >> >> >> >> >> Kitware offers various services to support the CMake >> >> >> >> >> >> community. >> >> >> >> >> >> For >> >> >> >> >> >> more >> >> >> >> >> >> information on each offering, please visit: >> >> >> >> >> >> >> >> >> >> >> >> CMake Support: http://cmake.org/cmake/help/support.html >> >> >> >> >> >> CMake Consulting: >> >> >> >> >> >> http://cmake.org/cmake/help/consulting.html >> >> >> >> >> >> CMake Training Courses: >> >> >> >> >> >> http://cmake.org/cmake/help/training.html >> >> >> >> >> >> >> >> >> >> >> >> Visit other Kitware open-source projects at >> >> >> >> >> >> http://www.kitware.com/opensource/opensource.html >> >> >> >> >> >> >> >> >> >> >> >> Follow this link to subscribe/unsubscribe: >> >> >> >> >> >> http://public.kitware.com/mailman/listinfo/cmake >> >> >> >> >> > >> >> >> >> >> > >> >> >> >> > >> >> >> >> > >> >> >> > >> >> >> > >> >> > >> >> > >> > >> > > > From m.tmatma at gmail.com Mon Aug 21 17:56:37 2017 From: m.tmatma at gmail.com (masaru tsuchiyama) Date: Mon, 21 Aug 2017 21:56:37 +0000 Subject: [CMake] 'cmake.exe -G Ninja' doesn't work for VS2017 with cmake ver 3.9.1 In-Reply-To: References: <84ce2ae4-99d2-c3d4-8bb0-82131019aa76@gmail.com> <6ddc295f-8cda-2f64-e6c2-3e33ec529e94@gmail.com> Message-ID: I think it is same as the issue. I use Japanese version of Win10 Pro. Regards. Masaru. 2017?8?22?(?) 0:11 Brad King : > On 08/21/2017 09:39 AM, Masaru Tsuchiyama wrote: > > I did git bisect. > > > > The problematic commit is > > > https://gitlab.kitware.com/cmake/cmake/commit/690acadc17263621f5361d48057c6f938e698a58 > > > > cmake with Ninja Generator succeeds by reverting > > 690acadc17263621f5361d48057c6f938e698a58 > [snip] > > ninja: error: build.ninja:30: loading 'rules.ninja': > > ?????????????????? > > Thanks. Is that this issue? > > https://gitlab.kitware.com/cmake/cmake/issues/17191 > > Otherwise, please open a new issue. > > Thanks, > -Brad > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jomofisher at gmail.com Mon Aug 21 18:11:38 2017 From: jomofisher at gmail.com (Jom O'Fisher) Date: Mon, 21 Aug 2017 15:11:38 -0700 Subject: [CMake] CMake + Gradle for Android In-Reply-To: References: Message-ID: You can find that number like this: - x = number of externalNativeBuild.cmake.path in your build.gradle files - y = number of gradle configurations (like debug and release) - z = number of ABIs that you build The result is x * y * z. To be more accurate, you should consider y and z to be functions of each build.gradle file since these can vary. There is a second set of folders that hold the stripped versions of the .so files that is purely managed by the android gradle plugin, so you might consider the answer to be 2 * x * y * z. Hope this helps. On Mon, Aug 21, 2017 at 2:41 PM, Robert Dailey wrote: > This definitely a bit better, but still requires the boilerplate in > each leaf gradle file. But I can't seriously complain too much. I > think I'm more concerned with the implications this has underneath. > First, let me ask just to make sure I'm not misunderstanding: Does > each `externalNativeBuild` entry essentially mean 1 CMAKE_BINARY_DIR? > How many binary dirs do you manage internally and what determines when > they get created? > > On Mon, Aug 21, 2017 at 2:35 PM, Jom O'Fisher > wrote: > > Would it work for your scenario to provide properties in the root > > build.gradle: > > > > ext { > > cmakePath = file "CMakeLists.txt" > > } > > > > And then consume them in the leaf app/build.gradle like this? > > > > externalNativeBuild { > > cmake { > > path cmakePath > > } > > } > > > > It doesn't fully hide the details but it does centralize the information. > > > > > > On Mon, Aug 21, 2017 at 11:20 AM, Robert Dailey < > rcdailey.lists at gmail.com> > > wrote: > >> > >> I wouldn't want to do that, it's too convoluted. I have other > >> platforms that use these CMake scripts as well. For example, I run on > >> Windows and Linux platforms as well to build the native code. Normal > >> CMake behavior is designed to work at a root then go downwards to find > >> targets. However it seems Gradle wants to start at a subdirectory and > >> work its way up to the root, which is opposite of CMake's intended > >> behavior IMHO. Not only that but I want to avoid special-casing > >> behavior in CMake just for Android's use. > >> > >> At the moment it feels like (again referring back to my previous > >> example structure) that both App2 and App3 each run CMake in > >> independent binary directories instead of sharing 1 binary directory > >> and building 2 targets inside of it. I prefer this behavior instead, > >> especially since it allows CMake to operate as it was intended. I > >> think it's a common case that projects will define multiple targets > >> starting from a single root, and expect multiple APKs or java > >> dependencies to be built within it. > >> > >> If I'm misunderstanding or making false assumptions please let me know. > >> > >> > >> > >> On Mon, Aug 21, 2017 at 12:00 PM, Jom O'Fisher > >> wrote: > >> > Would it work for your situation for the leaf CMakeLists.txt to > include > >> > the > >> > root CMakeLists.txt? Then have the leaf-specific logic in the leaf > >> > CMakeLists.txt? > >> > > >> > > >> > > >> > On Mon, Aug 21, 2017 at 9:33 AM, Robert Dailey > >> > > >> > wrote: > >> >> > >> >> Basically, yes. We have this sort of structure: > >> >> > >> >> / > >> >> Applications/ > >> >> App1/ > >> >> build.gradle > >> >> CMakeLists.txt > >> >> App2/ > >> >> build.gradle > >> >> CMakeLists.txt > >> >> App3/ > >> >> build.gradle > >> >> CMakeLists.txt > >> >> CommonLib/ > >> >> build.gradle > >> >> CMakeLists.txt > >> >> CMakeLists.txt > >> >> > >> >> The libs are defined as follows: > >> >> > >> >> * CommonLib is a static library (java code builds into a library) > >> >> * No dependencies of its own > >> >> * App1 is a shared library (java code builds into a library) > >> >> * Dependencies (both java & native): CommonLib > >> >> * App2 is a shared library (java code builds into an APK) > >> >> * Dependencies (both java & native): App1, CommonLib > >> >> * App3 is a shared library (java code builds into an APK) > >> >> * Dependencies (both java & native): CommonLib > >> >> > >> >> In all cases, CMake must be invoked starting at the root > >> >> CMakeLists.txt 1 time. Each target can be built from the same binary > >> >> directory after that. Previously with ANT, I was building all native > >> >> targets first, then moved libs to appropriate directories so that the > >> >> 'ant' command would package the libs. > >> >> > >> >> For gradle, I wanted to avoid redundantly specifying the root > >> >> directory in each leaf-level project directory. Using the example > >> >> above, the leaf-level directories in this case would be App1, App2, > >> >> App3, and CommonLib. However I think we only specify the native CMake > >> >> stuff for the java targets that actually output an APK (that would be > >> >> App2 and App3 only). > >> >> > >> >> The ultimate goal is to specify stuff that doesn't change per > >> >> independent "module" of ours at the top level so it is transitive / > >> >> inherited. Then only specify the differences (e.g. the native CMake > >> >> target to build) in the leaf build gradle files. However you > indicated > >> >> this isn't possible. > >> >> > >> >> > >> >> > >> >> On Mon, Aug 21, 2017 at 11:11 AM, Jom O'Fisher > > >> >> wrote: > >> >> > What you're doing already sounds correct. You can't directly > specify > >> >> > CMakeLists.txt from the top-level build.gradle. Recommendation is > >> >> > that > >> >> > it > >> >> > should be specified from the build.gradle of the module of the APK. > >> >> > Is > >> >> > the > >> >> > issue that you have multiple APK modules that all reference the > same > >> >> > CMake > >> >> > libraries? > >> >> > > >> >> > On Mon, Aug 21, 2017 at 9:00 AM, Robert Dailey > >> >> > > >> >> > wrote: > >> >> >> > >> >> >> Thanks this is very helpful. The other question I have is: Is > there > >> >> >> a > >> >> >> place to centrally specify the root CMakeLists.txt? Basically, I > >> >> >> want > >> >> >> to specify the CMake root in 1 place, and have targets (defined > >> >> >> further down in subdirectories) that require APK packaging to > >> >> >> specify > >> >> >> only the native target name that should be built & packaged. > >> >> >> > >> >> >> At the moment we specify the root CMakeLists.txt by walking up the > >> >> >> tree, paths like "../../../../CMakeLists.txt". I think this should > >> >> >> be > >> >> >> put at the top-level build gradle file if possible. Is this doable > >> >> >> at > >> >> >> the moment? What is the recommended setup? > >> >> >> > >> >> >> On Mon, Aug 21, 2017 at 9:37 AM, Jom O'Fisher < > jomofisher at gmail.com> > >> >> >> wrote: > >> >> >> > Gradle does introspection on the CMake build to find .so targets > >> >> >> > and > >> >> >> > those > >> >> >> > get packaged. > >> >> >> > There is also a special case for stl/runtime .so files from the > >> >> >> > NDK. > >> >> >> > Any additional .so files need to specified in build.gradle using > >> >> >> > jniDirs > >> >> >> > > >> >> >> > On Mon, Aug 21, 2017 at 7:30 AM, Robert Dailey > >> >> >> > > >> >> >> > wrote: > >> >> >> >> > >> >> >> >> How exactly does Gradle package *.so files in an APK? I know > that > >> >> >> >> ANT > >> >> >> >> used to do this for any libs under "libs/". Does Gradle do > >> >> >> >> some > >> >> >> >> introspection into CMake targets to see if outputs are *.so, > and > >> >> >> >> copy > >> >> >> >> those to some location if needed? What about libraries like > >> >> >> >> libgnustl_shared.so that come with the NDK? I'd like to know if > >> >> >> >> any > >> >> >> >> manual copy steps are needed in CMake to put outputs in proper > >> >> >> >> locations for the APK build step. I had to do this when using > >> >> >> >> ANT. > >> >> >> >> > >> >> >> >> On Mon, Aug 7, 2017 at 6:16 PM, Jom O'Fisher > >> >> >> >> > >> >> >> >> wrote: > >> >> >> >> > 1) There is a folder created for each ABI under the project > >> >> >> >> > module > >> >> >> >> > folder > >> >> >> >> > (so unique per module per ABI) > >> >> >> >> > 2) Gradle doesn't specify language level though you can > choose > >> >> >> >> > to > >> >> >> >> > specify it > >> >> >> >> > yourself from the build.gradle. This doc does a pretty good > job > >> >> >> >> > of > >> >> >> >> > explaining which variables are set by Gradle: > >> >> >> >> > https://developer.android.com/ndk/guides/cmake.html# > variables. > >> >> >> >> > Philosophically, we try to set as little as we can get away > >> >> >> >> > with. > >> >> >> >> > In > >> >> >> >> > particular, the section titled "Understanding the CMake build > >> >> >> >> > command" > >> >> >> >> > lays > >> >> >> >> > out exactly what we set. You can also see the folders we > >> >> >> >> > specify > >> >> >> >> > (one > >> >> >> >> > per > >> >> >> >> > module per ABI) > >> >> >> >> > 3) Not sure I understand this. > >> >> >> >> > > >> >> >> >> > The other document worth taking a look at (if you haven't > >> >> >> >> > already) > >> >> >> >> > is: > >> >> >> >> > > >> >> >> >> > https://developer.android.com/studio/projects/add-native- > code.html > >> >> >> >> > > >> >> >> >> > > >> >> >> >> > On Mon, Aug 7, 2017 at 3:35 PM, Robert Dailey > >> >> >> >> > > >> >> >> >> > wrote: > >> >> >> >> >> > >> >> >> >> >> Thanks Jom > >> >> >> >> >> > >> >> >> >> >> Honestly, I prefer option 1 to work simply because that's > how > >> >> >> >> >> Google's > >> >> >> >> >> officially supporting CMake. But it also has debugging which > >> >> >> >> >> is > >> >> >> >> >> the > >> >> >> >> >> #1 > >> >> >> >> >> reason for me. > >> >> >> >> >> > >> >> >> >> >> However, I'd like to understand a lot more about how the > >> >> >> >> >> integration > >> >> >> >> >> really happens. For example, I have these questions: > >> >> >> >> >> > >> >> >> >> >> 1) How, internally, are CMake build directories managed? Do > >> >> >> >> >> you > >> >> >> >> >> generate 1 per unique android project? What about for each > >> >> >> >> >> specific > >> >> >> >> >> platform (x86, armeabi-v7a, etc)? > >> >> >> >> >> 2) Last time I looked into CMake integration, things defined > >> >> >> >> >> inside > >> >> >> >> >> the CMake scripts were ignored because they are specified at > >> >> >> >> >> the > >> >> >> >> >> command line. Namely, all of those settings that are driven > by > >> >> >> >> >> the > >> >> >> >> >> Gradle configuration (CXX language level was one in > particular > >> >> >> >> >> I > >> >> >> >> >> think; I specify C++14 support via CMake, but I recall this > >> >> >> >> >> being > >> >> >> >> >> overridden from outside)? > >> >> >> >> >> 3) How redundant is it to configure individual libraries via > >> >> >> >> >> the > >> >> >> >> >> gradle scripts? In my previous attempts, I wanted to define > >> >> >> >> >> common > >> >> >> >> >> stuff for CMake / native code at the root gradle or settings > >> >> >> >> >> file, > >> >> >> >> >> and > >> >> >> >> >> only define the differences in the actual gradle build files > >> >> >> >> >> for > >> >> >> >> >> each > >> >> >> >> >> corresponding Java target (like, defining the name of the > >> >> >> >> >> native > >> >> >> >> >> (shared library) target in Gradle, but the command line > >> >> >> >> >> invocation, > >> >> >> >> >> -D > >> >> >> >> >> CMake settings, etc would all be common and defined at the > >> >> >> >> >> root). > >> >> >> >> >> > >> >> >> >> >> The TLDR is, the closer we can stay to CMake's way of doing > >> >> >> >> >> things > >> >> >> >> >> and > >> >> >> >> >> keep CMake-related settings self-contained to the CMake > >> >> >> >> >> scripts > >> >> >> >> >> themselves, the better. This also makes cross-platform > easier > >> >> >> >> >> (we > >> >> >> >> >> build the native code in Windows, for example, so having > >> >> >> >> >> settings > >> >> >> >> >> specified in the gradle files do not carry over to other > >> >> >> >> >> platforms. > >> >> >> >> >> Namely, settings that are not platform specific like the C++ > >> >> >> >> >> language > >> >> >> >> >> level). > >> >> >> >> >> > >> >> >> >> >> If there's a detailed document / wiki I can read on the > >> >> >> >> >> intrinsics > >> >> >> >> >> of > >> >> >> >> >> CMake integration in Gradle / Android Studio, I'd love to > read > >> >> >> >> >> it. > >> >> >> >> >> Otherwise, I hope you won't mind if I pick your brain as > >> >> >> >> >> questions > >> >> >> >> >> come up. I think I'm going to try option 1 for now and see > how > >> >> >> >> >> it > >> >> >> >> >> goes. It's just black box for me because unlike option 2, I > >> >> >> >> >> have > >> >> >> >> >> very > >> >> >> >> >> little control over what happens after building the shared > >> >> >> >> >> libraries, > >> >> >> >> >> and to make up for that I need to really get a deep > >> >> >> >> >> understanding > >> >> >> >> >> of > >> >> >> >> >> how it works so I can make sure I code my CMake scripts > >> >> >> >> >> properly > >> >> >> >> >> for > >> >> >> >> >> not only Android, but my other platforms as well > (non-Android > >> >> >> >> >> platforms). > >> >> >> >> >> > >> >> >> >> >> Thanks again. > >> >> >> >> >> > >> >> >> >> >> On Mon, Aug 7, 2017 at 5:12 PM, Jom O'Fisher > >> >> >> >> >> > >> >> >> >> >> wrote: > >> >> >> >> >> > Either option can work fine. Disclosure: I work on Android > >> >> >> >> >> > Studio > >> >> >> >> >> > and > >> >> >> >> >> > was > >> >> >> >> >> > the one that added CMake support. > >> >> >> >> >> > > >> >> >> >> >> > Option (1) is the way it's designed to work and we're > >> >> >> >> >> > working > >> >> >> >> >> > toward > >> >> >> >> >> > getting > >> >> >> >> >> > rid of the need for the CMake fork. I can't really say > when > >> >> >> >> >> > that > >> >> >> >> >> > will > >> >> >> >> >> > happen > >> >> >> >> >> > but if you can get away with an older CMake for now then > I'd > >> >> >> >> >> > go > >> >> >> >> >> > this > >> >> >> >> >> > way. > >> >> >> >> >> > As you mentioned, option (1) will allow you to view your > >> >> >> >> >> > source > >> >> >> >> >> > file > >> >> >> >> >> > structure in Android Studio, edit files, and debug using > the > >> >> >> >> >> > built-in > >> >> >> >> >> > debugging support. > >> >> >> >> >> > > >> >> >> >> >> > To get option (2) to work, you can use jniDirs setting to > >> >> >> >> >> > tell > >> >> >> >> >> > Android > >> >> >> >> >> > Gradle where to pick up your built .so files (see > >> >> >> >> >> > > >> >> >> >> >> > > >> >> >> >> >> > > >> >> >> >> >> > > >> >> >> >> >> > > >> >> >> >> >> > https://stackoverflow.com/questions/21255125/how-can-i- > add-so-files-to-an-android-library-project-using-gradle-0-7). > >> >> >> >> >> > I'm not aware of any projects that use this approach but > it > >> >> >> >> >> > should > >> >> >> >> >> > work > >> >> >> >> >> > in > >> >> >> >> >> > principal. > >> >> >> >> >> > > >> >> >> >> >> > I hope this helps, > >> >> >> >> >> > Jomo > >> >> >> >> >> > > >> >> >> >> >> > > >> >> >> >> >> > On Mon, Aug 7, 2017 at 11:09 AM, Robert Dailey > >> >> >> >> >> > > >> >> >> >> >> > wrote: > >> >> >> >> >> >> > >> >> >> >> >> >> Right now I have custom targets set to execute the "ant > >> >> >> >> >> >> release" > >> >> >> >> >> >> command after my native targets are built. Part of that > >> >> >> >> >> >> command > >> >> >> >> >> >> involves copying *.so files to the libs/armeabi-v7a > >> >> >> >> >> >> directory > >> >> >> >> >> >> so > >> >> >> >> >> >> they > >> >> >> >> >> >> get packaged in an APK. > >> >> >> >> >> >> > >> >> >> >> >> >> When switching to gradle, I have two options: > >> >> >> >> >> >> > >> >> >> >> >> >> 1. Gradle drives CMake: This means using Android Studio > and > >> >> >> >> >> >> being > >> >> >> >> >> >> locked down to Google's fork of CMake which is a few > major > >> >> >> >> >> >> releases > >> >> >> >> >> >> behind. I see that as a negative. > >> >> >> >> >> >> > >> >> >> >> >> >> 2. CMake drives Gradle: This would be the same or similar > >> >> >> >> >> >> to > >> >> >> >> >> >> what > >> >> >> >> >> >> I'm > >> >> >> >> >> >> already doing: The custom targets I have would execute > >> >> >> >> >> >> gradle > >> >> >> >> >> >> as > >> >> >> >> >> >> a > >> >> >> >> >> >> separate build step, instead of running ant commands. I'm > >> >> >> >> >> >> not > >> >> >> >> >> >> too > >> >> >> >> >> >> familiar with Gradle, so I'm not sure how you tell it > where > >> >> >> >> >> >> your > >> >> >> >> >> >> shared libraries are for the APK packaging steps. > >> >> >> >> >> >> > >> >> >> >> >> >> Which does everyone recommend? Is anyone using one of > these > >> >> >> >> >> >> setups > >> >> >> >> >> >> successfully? The downside to option 2 is probably no > >> >> >> >> >> >> on-device > >> >> >> >> >> >> native > >> >> >> >> >> >> debugging since Android Studio probably can't handle > gradle > >> >> >> >> >> >> projects > >> >> >> >> >> >> without any external CMake builds set up. > >> >> >> >> >> >> > >> >> >> >> >> >> Would like some general direction & advice before I move > >> >> >> >> >> >> away > >> >> >> >> >> >> from > >> >> >> >> >> >> ANT. Thanks in advance. > >> >> >> >> >> >> -- > >> >> >> >> >> >> > >> >> >> >> >> >> Powered by www.kitware.com > >> >> >> >> >> >> > >> >> >> >> >> >> Please keep messages on-topic and check the CMake FAQ at: > >> >> >> >> >> >> http://www.cmake.org/Wiki/CMake_FAQ > >> >> >> >> >> >> > >> >> >> >> >> >> Kitware offers various services to support the CMake > >> >> >> >> >> >> community. > >> >> >> >> >> >> For > >> >> >> >> >> >> more > >> >> >> >> >> >> information on each offering, please visit: > >> >> >> >> >> >> > >> >> >> >> >> >> CMake Support: http://cmake.org/cmake/help/support.html > >> >> >> >> >> >> CMake Consulting: > >> >> >> >> >> >> http://cmake.org/cmake/help/consulting.html > >> >> >> >> >> >> CMake Training Courses: > >> >> >> >> >> >> http://cmake.org/cmake/help/training.html > >> >> >> >> >> >> > >> >> >> >> >> >> Visit other Kitware open-source projects at > >> >> >> >> >> >> http://www.kitware.com/opensource/opensource.html > >> >> >> >> >> >> > >> >> >> >> >> >> Follow this link to subscribe/unsubscribe: > >> >> >> >> >> >> http://public.kitware.com/mailman/listinfo/cmake > >> >> >> >> >> > > >> >> >> >> >> > > >> >> >> >> > > >> >> >> >> > > >> >> >> > > >> >> >> > > >> >> > > >> >> > > >> > > >> > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jomofisher at gmail.com Mon Aug 21 18:34:32 2017 From: jomofisher at gmail.com (Jom O'Fisher) Date: Mon, 21 Aug 2017 15:34:32 -0700 Subject: [CMake] CMake + Gradle for Android In-Reply-To: References: Message-ID: + a colleague On Mon, Aug 21, 2017 at 3:11 PM, Jom O'Fisher wrote: > You can find that number like this: > - x = number of externalNativeBuild.cmake.path in your build.gradle files > - y = number of gradle configurations (like debug and release) > - z = number of ABIs that you build > > The result is x * y * z. To be more accurate, you should consider y and z > to be functions of each build.gradle file since these can vary. > > There is a second set of folders that hold the stripped versions of the > .so files that is purely managed by the android gradle plugin, so you might > consider the answer to be 2 * x * y * z. > > Hope this helps. > > > > > > > On Mon, Aug 21, 2017 at 2:41 PM, Robert Dailey > wrote: > >> This definitely a bit better, but still requires the boilerplate in >> each leaf gradle file. But I can't seriously complain too much. I >> think I'm more concerned with the implications this has underneath. >> First, let me ask just to make sure I'm not misunderstanding: Does >> each `externalNativeBuild` entry essentially mean 1 CMAKE_BINARY_DIR? >> How many binary dirs do you manage internally and what determines when >> they get created? >> >> On Mon, Aug 21, 2017 at 2:35 PM, Jom O'Fisher >> wrote: >> > Would it work for your scenario to provide properties in the root >> > build.gradle: >> > >> > ext { >> > cmakePath = file "CMakeLists.txt" >> > } >> > >> > And then consume them in the leaf app/build.gradle like this? >> > >> > externalNativeBuild { >> > cmake { >> > path cmakePath >> > } >> > } >> > >> > It doesn't fully hide the details but it does centralize the >> information. >> > >> > >> > On Mon, Aug 21, 2017 at 11:20 AM, Robert Dailey < >> rcdailey.lists at gmail.com> >> > wrote: >> >> >> >> I wouldn't want to do that, it's too convoluted. I have other >> >> platforms that use these CMake scripts as well. For example, I run on >> >> Windows and Linux platforms as well to build the native code. Normal >> >> CMake behavior is designed to work at a root then go downwards to find >> >> targets. However it seems Gradle wants to start at a subdirectory and >> >> work its way up to the root, which is opposite of CMake's intended >> >> behavior IMHO. Not only that but I want to avoid special-casing >> >> behavior in CMake just for Android's use. >> >> >> >> At the moment it feels like (again referring back to my previous >> >> example structure) that both App2 and App3 each run CMake in >> >> independent binary directories instead of sharing 1 binary directory >> >> and building 2 targets inside of it. I prefer this behavior instead, >> >> especially since it allows CMake to operate as it was intended. I >> >> think it's a common case that projects will define multiple targets >> >> starting from a single root, and expect multiple APKs or java >> >> dependencies to be built within it. >> >> >> >> If I'm misunderstanding or making false assumptions please let me know. >> >> >> >> >> >> >> >> On Mon, Aug 21, 2017 at 12:00 PM, Jom O'Fisher >> >> wrote: >> >> > Would it work for your situation for the leaf CMakeLists.txt to >> include >> >> > the >> >> > root CMakeLists.txt? Then have the leaf-specific logic in the leaf >> >> > CMakeLists.txt? >> >> > >> >> > >> >> > >> >> > On Mon, Aug 21, 2017 at 9:33 AM, Robert Dailey >> >> > >> >> > wrote: >> >> >> >> >> >> Basically, yes. We have this sort of structure: >> >> >> >> >> >> / >> >> >> Applications/ >> >> >> App1/ >> >> >> build.gradle >> >> >> CMakeLists.txt >> >> >> App2/ >> >> >> build.gradle >> >> >> CMakeLists.txt >> >> >> App3/ >> >> >> build.gradle >> >> >> CMakeLists.txt >> >> >> CommonLib/ >> >> >> build.gradle >> >> >> CMakeLists.txt >> >> >> CMakeLists.txt >> >> >> >> >> >> The libs are defined as follows: >> >> >> >> >> >> * CommonLib is a static library (java code builds into a library) >> >> >> * No dependencies of its own >> >> >> * App1 is a shared library (java code builds into a library) >> >> >> * Dependencies (both java & native): CommonLib >> >> >> * App2 is a shared library (java code builds into an APK) >> >> >> * Dependencies (both java & native): App1, CommonLib >> >> >> * App3 is a shared library (java code builds into an APK) >> >> >> * Dependencies (both java & native): CommonLib >> >> >> >> >> >> In all cases, CMake must be invoked starting at the root >> >> >> CMakeLists.txt 1 time. Each target can be built from the same binary >> >> >> directory after that. Previously with ANT, I was building all native >> >> >> targets first, then moved libs to appropriate directories so that >> the >> >> >> 'ant' command would package the libs. >> >> >> >> >> >> For gradle, I wanted to avoid redundantly specifying the root >> >> >> directory in each leaf-level project directory. Using the example >> >> >> above, the leaf-level directories in this case would be App1, App2, >> >> >> App3, and CommonLib. However I think we only specify the native >> CMake >> >> >> stuff for the java targets that actually output an APK (that would >> be >> >> >> App2 and App3 only). >> >> >> >> >> >> The ultimate goal is to specify stuff that doesn't change per >> >> >> independent "module" of ours at the top level so it is transitive / >> >> >> inherited. Then only specify the differences (e.g. the native CMake >> >> >> target to build) in the leaf build gradle files. However you >> indicated >> >> >> this isn't possible. >> >> >> >> >> >> >> >> >> >> >> >> On Mon, Aug 21, 2017 at 11:11 AM, Jom O'Fisher < >> jomofisher at gmail.com> >> >> >> wrote: >> >> >> > What you're doing already sounds correct. You can't directly >> specify >> >> >> > CMakeLists.txt from the top-level build.gradle. Recommendation is >> >> >> > that >> >> >> > it >> >> >> > should be specified from the build.gradle of the module of the >> APK. >> >> >> > Is >> >> >> > the >> >> >> > issue that you have multiple APK modules that all reference the >> same >> >> >> > CMake >> >> >> > libraries? >> >> >> > >> >> >> > On Mon, Aug 21, 2017 at 9:00 AM, Robert Dailey >> >> >> > >> >> >> > wrote: >> >> >> >> >> >> >> >> Thanks this is very helpful. The other question I have is: Is >> there >> >> >> >> a >> >> >> >> place to centrally specify the root CMakeLists.txt? Basically, I >> >> >> >> want >> >> >> >> to specify the CMake root in 1 place, and have targets (defined >> >> >> >> further down in subdirectories) that require APK packaging to >> >> >> >> specify >> >> >> >> only the native target name that should be built & packaged. >> >> >> >> >> >> >> >> At the moment we specify the root CMakeLists.txt by walking up >> the >> >> >> >> tree, paths like "../../../../CMakeLists.txt". I think this >> should >> >> >> >> be >> >> >> >> put at the top-level build gradle file if possible. Is this >> doable >> >> >> >> at >> >> >> >> the moment? What is the recommended setup? >> >> >> >> >> >> >> >> On Mon, Aug 21, 2017 at 9:37 AM, Jom O'Fisher < >> jomofisher at gmail.com> >> >> >> >> wrote: >> >> >> >> > Gradle does introspection on the CMake build to find .so >> targets >> >> >> >> > and >> >> >> >> > those >> >> >> >> > get packaged. >> >> >> >> > There is also a special case for stl/runtime .so files from the >> >> >> >> > NDK. >> >> >> >> > Any additional .so files need to specified in build.gradle >> using >> >> >> >> > jniDirs >> >> >> >> > >> >> >> >> > On Mon, Aug 21, 2017 at 7:30 AM, Robert Dailey >> >> >> >> > >> >> >> >> > wrote: >> >> >> >> >> >> >> >> >> >> How exactly does Gradle package *.so files in an APK? I know >> that >> >> >> >> >> ANT >> >> >> >> >> used to do this for any libs under "libs/". Does Gradle >> do >> >> >> >> >> some >> >> >> >> >> introspection into CMake targets to see if outputs are *.so, >> and >> >> >> >> >> copy >> >> >> >> >> those to some location if needed? What about libraries like >> >> >> >> >> libgnustl_shared.so that come with the NDK? I'd like to know >> if >> >> >> >> >> any >> >> >> >> >> manual copy steps are needed in CMake to put outputs in proper >> >> >> >> >> locations for the APK build step. I had to do this when using >> >> >> >> >> ANT. >> >> >> >> >> >> >> >> >> >> On Mon, Aug 7, 2017 at 6:16 PM, Jom O'Fisher >> >> >> >> >> >> >> >> >> >> wrote: >> >> >> >> >> > 1) There is a folder created for each ABI under the project >> >> >> >> >> > module >> >> >> >> >> > folder >> >> >> >> >> > (so unique per module per ABI) >> >> >> >> >> > 2) Gradle doesn't specify language level though you can >> choose >> >> >> >> >> > to >> >> >> >> >> > specify it >> >> >> >> >> > yourself from the build.gradle. This doc does a pretty good >> job >> >> >> >> >> > of >> >> >> >> >> > explaining which variables are set by Gradle: >> >> >> >> >> > https://developer.android.com/ >> ndk/guides/cmake.html#variables. >> >> >> >> >> > Philosophically, we try to set as little as we can get away >> >> >> >> >> > with. >> >> >> >> >> > In >> >> >> >> >> > particular, the section titled "Understanding the CMake >> build >> >> >> >> >> > command" >> >> >> >> >> > lays >> >> >> >> >> > out exactly what we set. You can also see the folders we >> >> >> >> >> > specify >> >> >> >> >> > (one >> >> >> >> >> > per >> >> >> >> >> > module per ABI) >> >> >> >> >> > 3) Not sure I understand this. >> >> >> >> >> > >> >> >> >> >> > The other document worth taking a look at (if you haven't >> >> >> >> >> > already) >> >> >> >> >> > is: >> >> >> >> >> > >> >> >> >> >> > https://developer.android.com/ >> studio/projects/add-native-code.html >> >> >> >> >> > >> >> >> >> >> > >> >> >> >> >> > On Mon, Aug 7, 2017 at 3:35 PM, Robert Dailey >> >> >> >> >> > >> >> >> >> >> > wrote: >> >> >> >> >> >> >> >> >> >> >> >> Thanks Jom >> >> >> >> >> >> >> >> >> >> >> >> Honestly, I prefer option 1 to work simply because that's >> how >> >> >> >> >> >> Google's >> >> >> >> >> >> officially supporting CMake. But it also has debugging >> which >> >> >> >> >> >> is >> >> >> >> >> >> the >> >> >> >> >> >> #1 >> >> >> >> >> >> reason for me. >> >> >> >> >> >> >> >> >> >> >> >> However, I'd like to understand a lot more about how the >> >> >> >> >> >> integration >> >> >> >> >> >> really happens. For example, I have these questions: >> >> >> >> >> >> >> >> >> >> >> >> 1) How, internally, are CMake build directories managed? Do >> >> >> >> >> >> you >> >> >> >> >> >> generate 1 per unique android project? What about for each >> >> >> >> >> >> specific >> >> >> >> >> >> platform (x86, armeabi-v7a, etc)? >> >> >> >> >> >> 2) Last time I looked into CMake integration, things >> defined >> >> >> >> >> >> inside >> >> >> >> >> >> the CMake scripts were ignored because they are specified >> at >> >> >> >> >> >> the >> >> >> >> >> >> command line. Namely, all of those settings that are >> driven by >> >> >> >> >> >> the >> >> >> >> >> >> Gradle configuration (CXX language level was one in >> particular >> >> >> >> >> >> I >> >> >> >> >> >> think; I specify C++14 support via CMake, but I recall this >> >> >> >> >> >> being >> >> >> >> >> >> overridden from outside)? >> >> >> >> >> >> 3) How redundant is it to configure individual libraries >> via >> >> >> >> >> >> the >> >> >> >> >> >> gradle scripts? In my previous attempts, I wanted to define >> >> >> >> >> >> common >> >> >> >> >> >> stuff for CMake / native code at the root gradle or >> settings >> >> >> >> >> >> file, >> >> >> >> >> >> and >> >> >> >> >> >> only define the differences in the actual gradle build >> files >> >> >> >> >> >> for >> >> >> >> >> >> each >> >> >> >> >> >> corresponding Java target (like, defining the name of the >> >> >> >> >> >> native >> >> >> >> >> >> (shared library) target in Gradle, but the command line >> >> >> >> >> >> invocation, >> >> >> >> >> >> -D >> >> >> >> >> >> CMake settings, etc would all be common and defined at the >> >> >> >> >> >> root). >> >> >> >> >> >> >> >> >> >> >> >> The TLDR is, the closer we can stay to CMake's way of doing >> >> >> >> >> >> things >> >> >> >> >> >> and >> >> >> >> >> >> keep CMake-related settings self-contained to the CMake >> >> >> >> >> >> scripts >> >> >> >> >> >> themselves, the better. This also makes cross-platform >> easier >> >> >> >> >> >> (we >> >> >> >> >> >> build the native code in Windows, for example, so having >> >> >> >> >> >> settings >> >> >> >> >> >> specified in the gradle files do not carry over to other >> >> >> >> >> >> platforms. >> >> >> >> >> >> Namely, settings that are not platform specific like the >> C++ >> >> >> >> >> >> language >> >> >> >> >> >> level). >> >> >> >> >> >> >> >> >> >> >> >> If there's a detailed document / wiki I can read on the >> >> >> >> >> >> intrinsics >> >> >> >> >> >> of >> >> >> >> >> >> CMake integration in Gradle / Android Studio, I'd love to >> read >> >> >> >> >> >> it. >> >> >> >> >> >> Otherwise, I hope you won't mind if I pick your brain as >> >> >> >> >> >> questions >> >> >> >> >> >> come up. I think I'm going to try option 1 for now and see >> how >> >> >> >> >> >> it >> >> >> >> >> >> goes. It's just black box for me because unlike option 2, I >> >> >> >> >> >> have >> >> >> >> >> >> very >> >> >> >> >> >> little control over what happens after building the shared >> >> >> >> >> >> libraries, >> >> >> >> >> >> and to make up for that I need to really get a deep >> >> >> >> >> >> understanding >> >> >> >> >> >> of >> >> >> >> >> >> how it works so I can make sure I code my CMake scripts >> >> >> >> >> >> properly >> >> >> >> >> >> for >> >> >> >> >> >> not only Android, but my other platforms as well >> (non-Android >> >> >> >> >> >> platforms). >> >> >> >> >> >> >> >> >> >> >> >> Thanks again. >> >> >> >> >> >> >> >> >> >> >> >> On Mon, Aug 7, 2017 at 5:12 PM, Jom O'Fisher >> >> >> >> >> >> >> >> >> >> >> >> wrote: >> >> >> >> >> >> > Either option can work fine. Disclosure: I work on >> Android >> >> >> >> >> >> > Studio >> >> >> >> >> >> > and >> >> >> >> >> >> > was >> >> >> >> >> >> > the one that added CMake support. >> >> >> >> >> >> > >> >> >> >> >> >> > Option (1) is the way it's designed to work and we're >> >> >> >> >> >> > working >> >> >> >> >> >> > toward >> >> >> >> >> >> > getting >> >> >> >> >> >> > rid of the need for the CMake fork. I can't really say >> when >> >> >> >> >> >> > that >> >> >> >> >> >> > will >> >> >> >> >> >> > happen >> >> >> >> >> >> > but if you can get away with an older CMake for now then >> I'd >> >> >> >> >> >> > go >> >> >> >> >> >> > this >> >> >> >> >> >> > way. >> >> >> >> >> >> > As you mentioned, option (1) will allow you to view your >> >> >> >> >> >> > source >> >> >> >> >> >> > file >> >> >> >> >> >> > structure in Android Studio, edit files, and debug using >> the >> >> >> >> >> >> > built-in >> >> >> >> >> >> > debugging support. >> >> >> >> >> >> > >> >> >> >> >> >> > To get option (2) to work, you can use jniDirs setting to >> >> >> >> >> >> > tell >> >> >> >> >> >> > Android >> >> >> >> >> >> > Gradle where to pick up your built .so files (see >> >> >> >> >> >> > >> >> >> >> >> >> > >> >> >> >> >> >> > >> >> >> >> >> >> > >> >> >> >> >> >> > >> >> >> >> >> >> > https://stackoverflow.com/ques >> tions/21255125/how-can-i-add-so-files-to-an-android-library >> -project-using-gradle-0-7). >> >> >> >> >> >> > I'm not aware of any projects that use this approach but >> it >> >> >> >> >> >> > should >> >> >> >> >> >> > work >> >> >> >> >> >> > in >> >> >> >> >> >> > principal. >> >> >> >> >> >> > >> >> >> >> >> >> > I hope this helps, >> >> >> >> >> >> > Jomo >> >> >> >> >> >> > >> >> >> >> >> >> > >> >> >> >> >> >> > On Mon, Aug 7, 2017 at 11:09 AM, Robert Dailey >> >> >> >> >> >> > >> >> >> >> >> >> > wrote: >> >> >> >> >> >> >> >> >> >> >> >> >> >> Right now I have custom targets set to execute the "ant >> >> >> >> >> >> >> release" >> >> >> >> >> >> >> command after my native targets are built. Part of that >> >> >> >> >> >> >> command >> >> >> >> >> >> >> involves copying *.so files to the libs/armeabi-v7a >> >> >> >> >> >> >> directory >> >> >> >> >> >> >> so >> >> >> >> >> >> >> they >> >> >> >> >> >> >> get packaged in an APK. >> >> >> >> >> >> >> >> >> >> >> >> >> >> When switching to gradle, I have two options: >> >> >> >> >> >> >> >> >> >> >> >> >> >> 1. Gradle drives CMake: This means using Android Studio >> and >> >> >> >> >> >> >> being >> >> >> >> >> >> >> locked down to Google's fork of CMake which is a few >> major >> >> >> >> >> >> >> releases >> >> >> >> >> >> >> behind. I see that as a negative. >> >> >> >> >> >> >> >> >> >> >> >> >> >> 2. CMake drives Gradle: This would be the same or >> similar >> >> >> >> >> >> >> to >> >> >> >> >> >> >> what >> >> >> >> >> >> >> I'm >> >> >> >> >> >> >> already doing: The custom targets I have would execute >> >> >> >> >> >> >> gradle >> >> >> >> >> >> >> as >> >> >> >> >> >> >> a >> >> >> >> >> >> >> separate build step, instead of running ant commands. >> I'm >> >> >> >> >> >> >> not >> >> >> >> >> >> >> too >> >> >> >> >> >> >> familiar with Gradle, so I'm not sure how you tell it >> where >> >> >> >> >> >> >> your >> >> >> >> >> >> >> shared libraries are for the APK packaging steps. >> >> >> >> >> >> >> >> >> >> >> >> >> >> Which does everyone recommend? Is anyone using one of >> these >> >> >> >> >> >> >> setups >> >> >> >> >> >> >> successfully? The downside to option 2 is probably no >> >> >> >> >> >> >> on-device >> >> >> >> >> >> >> native >> >> >> >> >> >> >> debugging since Android Studio probably can't handle >> gradle >> >> >> >> >> >> >> projects >> >> >> >> >> >> >> without any external CMake builds set up. >> >> >> >> >> >> >> >> >> >> >> >> >> >> Would like some general direction & advice before I move >> >> >> >> >> >> >> away >> >> >> >> >> >> >> from >> >> >> >> >> >> >> ANT. Thanks in advance. >> >> >> >> >> >> >> -- >> >> >> >> >> >> >> >> >> >> >> >> >> >> Powered by www.kitware.com >> >> >> >> >> >> >> >> >> >> >> >> >> >> Please keep messages on-topic and check the CMake FAQ >> at: >> >> >> >> >> >> >> http://www.cmake.org/Wiki/CMake_FAQ >> >> >> >> >> >> >> >> >> >> >> >> >> >> Kitware offers various services to support the CMake >> >> >> >> >> >> >> community. >> >> >> >> >> >> >> For >> >> >> >> >> >> >> more >> >> >> >> >> >> >> information on each offering, please visit: >> >> >> >> >> >> >> >> >> >> >> >> >> >> CMake Support: http://cmake.org/cmake/help/support.html >> >> >> >> >> >> >> CMake Consulting: >> >> >> >> >> >> >> http://cmake.org/cmake/help/consulting.html >> >> >> >> >> >> >> CMake Training Courses: >> >> >> >> >> >> >> http://cmake.org/cmake/help/training.html >> >> >> >> >> >> >> >> >> >> >> >> >> >> Visit other Kitware open-source projects at >> >> >> >> >> >> >> http://www.kitware.com/opensource/opensource.html >> >> >> >> >> >> >> >> >> >> >> >> >> >> Follow this link to subscribe/unsubscribe: >> >> >> >> >> >> >> http://public.kitware.com/mailman/listinfo/cmake >> >> >> >> >> >> > >> >> >> >> >> >> > >> >> >> >> >> > >> >> >> >> >> > >> >> >> >> > >> >> >> >> > >> >> >> > >> >> >> > >> >> > >> >> > >> > >> > >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bitminer at gmail.com Mon Aug 21 20:17:25 2017 From: bitminer at gmail.com (Brian Davis) Date: Mon, 21 Aug 2017 19:17:25 -0500 Subject: [CMake] Interface Libraries allow include directories but not link directories.. Why? Message-ID: Why does: Interface Libraries https://cmake.org/cmake/help/latest/command/add_library.html?highlight=add_library#id3 allow include directories via target_include_directories(INTERFACE) but not link_directories https://cmake.org/cmake/help/latest/prop_dir/LINK_DIRECTORIES.html?highlight=link_directories which if we look at property scope: https://cmake.org/cmake/help/latest/manual/cmake-properties.7.html Why is include_directories at target resolution while link_directories is at directory resolution. link_directories is a property on a directory which if I recalled correctly I complained about many many moons ago (circa 2009) when I first realized this. I did not understand this logic then and don't understand this logic now. Someone what to give me the recipe for the CMake cool-aid so I can mix that up, drink it down, and re-read the doc and finally come to terms with this. Or could the powers that be redesign CMake to make sense. At the time I wrapped this nonsense in a macro and pretended it did not happen ... now I am rewriting my project for "new" CMake and still don't get this. -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.maynard at kitware.com Tue Aug 22 09:01:16 2017 From: robert.maynard at kitware.com (Robert Maynard) Date: Tue, 22 Aug 2017 09:01:16 -0400 Subject: [CMake] Interface Libraries allow include directories but not link directories.. Why? In-Reply-To: References: Message-ID: Usage of link_directories is discouraged, and was part of the reason why a target based option was not added. As the documentation for link_directories states "Note that this command is rarely necessary. Library locations returned by find_package() and find_library() are absolute paths. Pass these absolute library file paths directly to the target_link_libraries() command. CMake will ensure the linker finds them." On Mon, Aug 21, 2017 at 8:17 PM, Brian Davis wrote: > Why does: > > Interface Libraries > https://cmake.org/cmake/help/latest/command/add_library.html?highlight=add_library#id3 > > allow include directories via > > target_include_directories(INTERFACE) > > but not link_directories > > https://cmake.org/cmake/help/latest/prop_dir/LINK_DIRECTORIES.html?highlight=link_directories > > which if we look at property scope: > > https://cmake.org/cmake/help/latest/manual/cmake-properties.7.html > > Why is include_directories at target resolution while link_directories is at > directory resolution. > > link_directories is a property on a directory which if I recalled correctly > I complained about many many moons ago (circa 2009) when I first realized > this. I did not understand this logic then and don't understand this logic > now. Someone what to give me the recipe for the CMake cool-aid so I can mix > that up, drink it down, and re-read the doc and finally come to terms with > this. Or could the powers that be redesign CMake to make sense. At the > time I wrapped this nonsense in a macro and pretended it did not happen ... > now I am rewriting my project for "new" CMake and still don't get this. > > > > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake From rcdailey.lists at gmail.com Tue Aug 22 10:25:29 2017 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Tue, 22 Aug 2017 09:25:29 -0500 Subject: [CMake] CMake + Gradle for Android In-Reply-To: References: Message-ID: Thanks to both of you for responding. First, to Jom's reply: The "x" part is what I was worried about. Each "path" resulting in a single binary dir. This is the part that I think could be optimized. I'll explain more on this later. Note also that this optimization might only benefit my specific structure, but I'd also like to talk about that a bit more to understand if the structure itself should be changed (of course any changes I can do will be limited and might be very involved, but still we can hash out different ideas). So by "cross platform" here I mean that we build our C++ code (using CMake to facilitate the build) on 4 different platforms at the moment: - Windows using MSVC 2015 (We manage a "simulator" for our Android apps via Win32 apps) - Linux x86 (Ubuntu) using system Clang compiler (we use this to run our unit tests) - Android x86 - Android ARM All of our android apps are basically games. They are probably 95% C++ code. We limit logic to java as much as possible because we want behavior to be as cross platform as possible. Java code pretty much is the minimum required. Enough to load our SO library files and do some basic activity management (like going into background, setting up opengl, etc) Our root CMakeLists.txt does just a few things: * Include our common CMake modules (that we manage) that set up a few convenient CMake functions for creating targets, setting up unit tests, including third party libs, etc. * Runs add_subdirectory() to start including the sub-projects in our tree The root CMakeLists.txt is extremely important because it sets up our "CMake Environment", if you will, but doesn't actually define any targets by itself. All CMakeLists.txt below it depend on the root script being executed first, because they depend on the functions & such that it defines. Once CMake steps into "Applications", there is another CMakeLists.txt that includes more directories. Each sibling directory represents the root of a gradle project. Each of these has its own build.gradle inside it. We use gradle to manage dependencies across applications for Java dependencies. CMake maintains dependencies across apps for dependencies on the native side. Using App2 as an example, here is how the behavior differs per platform: * Windows: Includes certain Windows-only CPP files (e.g. win32main.cpp). This will set up the Win32 window, WinMain entry point, etc. Basically everything required to run this code on Windows (game will render to a window using OpenGL). Output is an executable target (.exe). * Android: Include Android-only CPP files (e.g. androidmain.cpp). This defines functions like JNI_OnLoad(), android_main(), sets up JNI bindings, and whatever else is required for our game to run on Android. Output is a shared library target (.so) for packaging into APK by gradle. * Linux: Include linux-only files, mainly for running unit tests specific to App2. Output is an executable target that runs various test cases. Most apps follow this pattern shown above. Each App# has mostly CPP files that are built common to all platforms. Note that this way of managing applications and libraries is how we keep our code base modular. We do not structure anything specific to a particular platform, we chose this structure because (up until gradle) it worked well between our various build platforms. Ideally, now that I understand how CMake is being managed by Gradle, I'd like CMake to be managed as follows: * The root build.gradle points to the "entry point" script for CMake (this is our root CMakeLists.txt that does not define any targets). This yields 1 binary directory per platform + configuration combination (y * z) but does not duplicate it per sub-project (this gets rid of 'x'). Example of what would be in the root build.gradle (or gradle settings?) (note that this would not yield an actual java target in gradle, it's just some property definition used by leaf build gradle files; so i'm not sure if this is the appropriate way to define that): externalNativeBuild { cmake { path CMakeLists.txt } } * Each sub-project build.gradle has a new property under externalNativeBuild called "cmake_target" or something, where I specify the native target that should be built in the single binary directory for that platform & configuration. So for App2's build.gradle this would be: externalNativeBuild { cmake { target App2 } } This would error out if a `path` has not been defined at this or some ancestor gradle script (assuming that gradle properties are transitive like CMake's) This structure seems a lot better to be. Again, it definitely benefits our specific structure but I also am not sure if we're an exception to the rule. It seems difficult to decompose and modularize a code base without doing things this way, especially when it needs to work for platforms other than Android itself. On Mon, Aug 21, 2017 at 6:20 PM, Raymond Chiu wrote: > Hi Robert, > > I work with Jom on the Android Studio team, and I would like to clarify a > few things to better understand your situation. > You mentioned the project is intend to be cross platform. Normally, in such > situation, we expect there to be a single CMake root project to be imported > into one of the Android library/application. However, in your case, there > are subprojects with Java code. > > Are the CMake code in App1/2/3 intended to be cross platform too? Or are > they Android specific code? If they are meant to be cross platform, how > does the Java code works on other platforms? Or perhaps you added Java > binding in those subprojects just for Android? > > The build.gradle in CommonLib, what kind of Gradle project is that? From > your description, it doesn't look like an Android library project. Or am I > mistaken and it also applies the android library plugin? > > Raymond > > On Mon, Aug 21, 2017 at 3:34 PM, Jom O'Fisher wrote: >> >> + a colleague >> >> On Mon, Aug 21, 2017 at 3:11 PM, Jom O'Fisher >> wrote: >>> >>> You can find that number like this: >>> - x = number of externalNativeBuild.cmake.path in your build.gradle files >>> - y = number of gradle configurations (like debug and release) >>> - z = number of ABIs that you build >>> >>> The result is x * y * z. To be more accurate, you should consider y and z >>> to be functions of each build.gradle file since these can vary. >>> >>> There is a second set of folders that hold the stripped versions of the >>> .so files that is purely managed by the android gradle plugin, so you might >>> consider the answer to be 2 * x * y * z. >>> >>> Hope this helps. >>> >>> >>> >>> >>> >>> >>> On Mon, Aug 21, 2017 at 2:41 PM, Robert Dailey >>> wrote: >>>> >>>> This definitely a bit better, but still requires the boilerplate in >>>> each leaf gradle file. But I can't seriously complain too much. I >>>> think I'm more concerned with the implications this has underneath. >>>> First, let me ask just to make sure I'm not misunderstanding: Does >>>> each `externalNativeBuild` entry essentially mean 1 CMAKE_BINARY_DIR? >>>> How many binary dirs do you manage internally and what determines when >>>> they get created? >>>> >>>> On Mon, Aug 21, 2017 at 2:35 PM, Jom O'Fisher >>>> wrote: >>>> > Would it work for your scenario to provide properties in the root >>>> > build.gradle: >>>> > >>>> > ext { >>>> > cmakePath = file "CMakeLists.txt" >>>> > } >>>> > >>>> > And then consume them in the leaf app/build.gradle like this? >>>> > >>>> > externalNativeBuild { >>>> > cmake { >>>> > path cmakePath >>>> > } >>>> > } >>>> > >>>> > It doesn't fully hide the details but it does centralize the >>>> > information. >>>> > >>>> > >>>> > On Mon, Aug 21, 2017 at 11:20 AM, Robert Dailey >>>> > >>>> > wrote: >>>> >> >>>> >> I wouldn't want to do that, it's too convoluted. I have other >>>> >> platforms that use these CMake scripts as well. For example, I run on >>>> >> Windows and Linux platforms as well to build the native code. Normal >>>> >> CMake behavior is designed to work at a root then go downwards to >>>> >> find >>>> >> targets. However it seems Gradle wants to start at a subdirectory and >>>> >> work its way up to the root, which is opposite of CMake's intended >>>> >> behavior IMHO. Not only that but I want to avoid special-casing >>>> >> behavior in CMake just for Android's use. >>>> >> >>>> >> At the moment it feels like (again referring back to my previous >>>> >> example structure) that both App2 and App3 each run CMake in >>>> >> independent binary directories instead of sharing 1 binary directory >>>> >> and building 2 targets inside of it. I prefer this behavior instead, >>>> >> especially since it allows CMake to operate as it was intended. I >>>> >> think it's a common case that projects will define multiple targets >>>> >> starting from a single root, and expect multiple APKs or java >>>> >> dependencies to be built within it. >>>> >> >>>> >> If I'm misunderstanding or making false assumptions please let me >>>> >> know. >>>> >> >>>> >> >>>> >> >>>> >> On Mon, Aug 21, 2017 at 12:00 PM, Jom O'Fisher >>>> >> wrote: >>>> >> > Would it work for your situation for the leaf CMakeLists.txt to >>>> >> > include >>>> >> > the >>>> >> > root CMakeLists.txt? Then have the leaf-specific logic in the leaf >>>> >> > CMakeLists.txt? >>>> >> > >>>> >> > >>>> >> > >>>> >> > On Mon, Aug 21, 2017 at 9:33 AM, Robert Dailey >>>> >> > >>>> >> > wrote: >>>> >> >> >>>> >> >> Basically, yes. We have this sort of structure: >>>> >> >> >>>> >> >> / >>>> >> >> Applications/ >>>> >> >> App1/ >>>> >> >> build.gradle >>>> >> >> CMakeLists.txt >>>> >> >> App2/ >>>> >> >> build.gradle >>>> >> >> CMakeLists.txt >>>> >> >> App3/ >>>> >> >> build.gradle >>>> >> >> CMakeLists.txt >>>> >> >> CommonLib/ >>>> >> >> build.gradle >>>> >> >> CMakeLists.txt >>>> >> >> CMakeLists.txt >>>> >> >> >>>> >> >> The libs are defined as follows: >>>> >> >> >>>> >> >> * CommonLib is a static library (java code builds into a library) >>>> >> >> * No dependencies of its own >>>> >> >> * App1 is a shared library (java code builds into a library) >>>> >> >> * Dependencies (both java & native): CommonLib >>>> >> >> * App2 is a shared library (java code builds into an APK) >>>> >> >> * Dependencies (both java & native): App1, CommonLib >>>> >> >> * App3 is a shared library (java code builds into an APK) >>>> >> >> * Dependencies (both java & native): CommonLib >>>> >> >> >>>> >> >> In all cases, CMake must be invoked starting at the root >>>> >> >> CMakeLists.txt 1 time. Each target can be built from the same >>>> >> >> binary >>>> >> >> directory after that. Previously with ANT, I was building all >>>> >> >> native >>>> >> >> targets first, then moved libs to appropriate directories so that >>>> >> >> the >>>> >> >> 'ant' command would package the libs. >>>> >> >> >>>> >> >> For gradle, I wanted to avoid redundantly specifying the root >>>> >> >> directory in each leaf-level project directory. Using the example >>>> >> >> above, the leaf-level directories in this case would be App1, >>>> >> >> App2, >>>> >> >> App3, and CommonLib. However I think we only specify the native >>>> >> >> CMake >>>> >> >> stuff for the java targets that actually output an APK (that would >>>> >> >> be >>>> >> >> App2 and App3 only). >>>> >> >> >>>> >> >> The ultimate goal is to specify stuff that doesn't change per >>>> >> >> independent "module" of ours at the top level so it is transitive >>>> >> >> / >>>> >> >> inherited. Then only specify the differences (e.g. the native >>>> >> >> CMake >>>> >> >> target to build) in the leaf build gradle files. However you >>>> >> >> indicated >>>> >> >> this isn't possible. >>>> >> >> >>>> >> >> >>>> >> >> >>>> >> >> On Mon, Aug 21, 2017 at 11:11 AM, Jom O'Fisher >>>> >> >> >>>> >> >> wrote: >>>> >> >> > What you're doing already sounds correct. You can't directly >>>> >> >> > specify >>>> >> >> > CMakeLists.txt from the top-level build.gradle. Recommendation >>>> >> >> > is >>>> >> >> > that >>>> >> >> > it >>>> >> >> > should be specified from the build.gradle of the module of the >>>> >> >> > APK. >>>> >> >> > Is >>>> >> >> > the >>>> >> >> > issue that you have multiple APK modules that all reference the >>>> >> >> > same >>>> >> >> > CMake >>>> >> >> > libraries? >>>> >> >> > >>>> >> >> > On Mon, Aug 21, 2017 at 9:00 AM, Robert Dailey >>>> >> >> > >>>> >> >> > wrote: >>>> >> >> >> >>>> >> >> >> Thanks this is very helpful. The other question I have is: Is >>>> >> >> >> there >>>> >> >> >> a >>>> >> >> >> place to centrally specify the root CMakeLists.txt? Basically, >>>> >> >> >> I >>>> >> >> >> want >>>> >> >> >> to specify the CMake root in 1 place, and have targets (defined >>>> >> >> >> further down in subdirectories) that require APK packaging to >>>> >> >> >> specify >>>> >> >> >> only the native target name that should be built & packaged. >>>> >> >> >> >>>> >> >> >> At the moment we specify the root CMakeLists.txt by walking up >>>> >> >> >> the >>>> >> >> >> tree, paths like "../../../../CMakeLists.txt". I think this >>>> >> >> >> should >>>> >> >> >> be >>>> >> >> >> put at the top-level build gradle file if possible. Is this >>>> >> >> >> doable >>>> >> >> >> at >>>> >> >> >> the moment? What is the recommended setup? >>>> >> >> >> >>>> >> >> >> On Mon, Aug 21, 2017 at 9:37 AM, Jom O'Fisher >>>> >> >> >> >>>> >> >> >> wrote: >>>> >> >> >> > Gradle does introspection on the CMake build to find .so >>>> >> >> >> > targets >>>> >> >> >> > and >>>> >> >> >> > those >>>> >> >> >> > get packaged. >>>> >> >> >> > There is also a special case for stl/runtime .so files from >>>> >> >> >> > the >>>> >> >> >> > NDK. >>>> >> >> >> > Any additional .so files need to specified in build.gradle >>>> >> >> >> > using >>>> >> >> >> > jniDirs >>>> >> >> >> > >>>> >> >> >> > On Mon, Aug 21, 2017 at 7:30 AM, Robert Dailey >>>> >> >> >> > >>>> >> >> >> > wrote: >>>> >> >> >> >> >>>> >> >> >> >> How exactly does Gradle package *.so files in an APK? I know >>>> >> >> >> >> that >>>> >> >> >> >> ANT >>>> >> >> >> >> used to do this for any libs under "libs/". Does Gradle >>>> >> >> >> >> do >>>> >> >> >> >> some >>>> >> >> >> >> introspection into CMake targets to see if outputs are *.so, >>>> >> >> >> >> and >>>> >> >> >> >> copy >>>> >> >> >> >> those to some location if needed? What about libraries like >>>> >> >> >> >> libgnustl_shared.so that come with the NDK? I'd like to know >>>> >> >> >> >> if >>>> >> >> >> >> any >>>> >> >> >> >> manual copy steps are needed in CMake to put outputs in >>>> >> >> >> >> proper >>>> >> >> >> >> locations for the APK build step. I had to do this when >>>> >> >> >> >> using >>>> >> >> >> >> ANT. >>>> >> >> >> >> >>>> >> >> >> >> On Mon, Aug 7, 2017 at 6:16 PM, Jom O'Fisher >>>> >> >> >> >> >>>> >> >> >> >> wrote: >>>> >> >> >> >> > 1) There is a folder created for each ABI under the >>>> >> >> >> >> > project >>>> >> >> >> >> > module >>>> >> >> >> >> > folder >>>> >> >> >> >> > (so unique per module per ABI) >>>> >> >> >> >> > 2) Gradle doesn't specify language level though you can >>>> >> >> >> >> > choose >>>> >> >> >> >> > to >>>> >> >> >> >> > specify it >>>> >> >> >> >> > yourself from the build.gradle. This doc does a pretty >>>> >> >> >> >> > good job >>>> >> >> >> >> > of >>>> >> >> >> >> > explaining which variables are set by Gradle: >>>> >> >> >> >> > >>>> >> >> >> >> > https://developer.android.com/ndk/guides/cmake.html#variables. >>>> >> >> >> >> > Philosophically, we try to set as little as we can get >>>> >> >> >> >> > away >>>> >> >> >> >> > with. >>>> >> >> >> >> > In >>>> >> >> >> >> > particular, the section titled "Understanding the CMake >>>> >> >> >> >> > build >>>> >> >> >> >> > command" >>>> >> >> >> >> > lays >>>> >> >> >> >> > out exactly what we set. You can also see the folders we >>>> >> >> >> >> > specify >>>> >> >> >> >> > (one >>>> >> >> >> >> > per >>>> >> >> >> >> > module per ABI) >>>> >> >> >> >> > 3) Not sure I understand this. >>>> >> >> >> >> > >>>> >> >> >> >> > The other document worth taking a look at (if you haven't >>>> >> >> >> >> > already) >>>> >> >> >> >> > is: >>>> >> >> >> >> > >>>> >> >> >> >> > >>>> >> >> >> >> > https://developer.android.com/studio/projects/add-native-code.html >>>> >> >> >> >> > >>>> >> >> >> >> > >>>> >> >> >> >> > On Mon, Aug 7, 2017 at 3:35 PM, Robert Dailey >>>> >> >> >> >> > >>>> >> >> >> >> > wrote: >>>> >> >> >> >> >> >>>> >> >> >> >> >> Thanks Jom >>>> >> >> >> >> >> >>>> >> >> >> >> >> Honestly, I prefer option 1 to work simply because that's >>>> >> >> >> >> >> how >>>> >> >> >> >> >> Google's >>>> >> >> >> >> >> officially supporting CMake. But it also has debugging >>>> >> >> >> >> >> which >>>> >> >> >> >> >> is >>>> >> >> >> >> >> the >>>> >> >> >> >> >> #1 >>>> >> >> >> >> >> reason for me. >>>> >> >> >> >> >> >>>> >> >> >> >> >> However, I'd like to understand a lot more about how the >>>> >> >> >> >> >> integration >>>> >> >> >> >> >> really happens. For example, I have these questions: >>>> >> >> >> >> >> >>>> >> >> >> >> >> 1) How, internally, are CMake build directories managed? >>>> >> >> >> >> >> Do >>>> >> >> >> >> >> you >>>> >> >> >> >> >> generate 1 per unique android project? What about for >>>> >> >> >> >> >> each >>>> >> >> >> >> >> specific >>>> >> >> >> >> >> platform (x86, armeabi-v7a, etc)? >>>> >> >> >> >> >> 2) Last time I looked into CMake integration, things >>>> >> >> >> >> >> defined >>>> >> >> >> >> >> inside >>>> >> >> >> >> >> the CMake scripts were ignored because they are specified >>>> >> >> >> >> >> at >>>> >> >> >> >> >> the >>>> >> >> >> >> >> command line. Namely, all of those settings that are >>>> >> >> >> >> >> driven by >>>> >> >> >> >> >> the >>>> >> >> >> >> >> Gradle configuration (CXX language level was one in >>>> >> >> >> >> >> particular >>>> >> >> >> >> >> I >>>> >> >> >> >> >> think; I specify C++14 support via CMake, but I recall >>>> >> >> >> >> >> this >>>> >> >> >> >> >> being >>>> >> >> >> >> >> overridden from outside)? >>>> >> >> >> >> >> 3) How redundant is it to configure individual libraries >>>> >> >> >> >> >> via >>>> >> >> >> >> >> the >>>> >> >> >> >> >> gradle scripts? In my previous attempts, I wanted to >>>> >> >> >> >> >> define >>>> >> >> >> >> >> common >>>> >> >> >> >> >> stuff for CMake / native code at the root gradle or >>>> >> >> >> >> >> settings >>>> >> >> >> >> >> file, >>>> >> >> >> >> >> and >>>> >> >> >> >> >> only define the differences in the actual gradle build >>>> >> >> >> >> >> files >>>> >> >> >> >> >> for >>>> >> >> >> >> >> each >>>> >> >> >> >> >> corresponding Java target (like, defining the name of the >>>> >> >> >> >> >> native >>>> >> >> >> >> >> (shared library) target in Gradle, but the command line >>>> >> >> >> >> >> invocation, >>>> >> >> >> >> >> -D >>>> >> >> >> >> >> CMake settings, etc would all be common and defined at >>>> >> >> >> >> >> the >>>> >> >> >> >> >> root). >>>> >> >> >> >> >> >>>> >> >> >> >> >> The TLDR is, the closer we can stay to CMake's way of >>>> >> >> >> >> >> doing >>>> >> >> >> >> >> things >>>> >> >> >> >> >> and >>>> >> >> >> >> >> keep CMake-related settings self-contained to the CMake >>>> >> >> >> >> >> scripts >>>> >> >> >> >> >> themselves, the better. This also makes cross-platform >>>> >> >> >> >> >> easier >>>> >> >> >> >> >> (we >>>> >> >> >> >> >> build the native code in Windows, for example, so having >>>> >> >> >> >> >> settings >>>> >> >> >> >> >> specified in the gradle files do not carry over to other >>>> >> >> >> >> >> platforms. >>>> >> >> >> >> >> Namely, settings that are not platform specific like the >>>> >> >> >> >> >> C++ >>>> >> >> >> >> >> language >>>> >> >> >> >> >> level). >>>> >> >> >> >> >> >>>> >> >> >> >> >> If there's a detailed document / wiki I can read on the >>>> >> >> >> >> >> intrinsics >>>> >> >> >> >> >> of >>>> >> >> >> >> >> CMake integration in Gradle / Android Studio, I'd love to >>>> >> >> >> >> >> read >>>> >> >> >> >> >> it. >>>> >> >> >> >> >> Otherwise, I hope you won't mind if I pick your brain as >>>> >> >> >> >> >> questions >>>> >> >> >> >> >> come up. I think I'm going to try option 1 for now and >>>> >> >> >> >> >> see how >>>> >> >> >> >> >> it >>>> >> >> >> >> >> goes. It's just black box for me because unlike option 2, >>>> >> >> >> >> >> I >>>> >> >> >> >> >> have >>>> >> >> >> >> >> very >>>> >> >> >> >> >> little control over what happens after building the >>>> >> >> >> >> >> shared >>>> >> >> >> >> >> libraries, >>>> >> >> >> >> >> and to make up for that I need to really get a deep >>>> >> >> >> >> >> understanding >>>> >> >> >> >> >> of >>>> >> >> >> >> >> how it works so I can make sure I code my CMake scripts >>>> >> >> >> >> >> properly >>>> >> >> >> >> >> for >>>> >> >> >> >> >> not only Android, but my other platforms as well >>>> >> >> >> >> >> (non-Android >>>> >> >> >> >> >> platforms). >>>> >> >> >> >> >> >>>> >> >> >> >> >> Thanks again. >>>> >> >> >> >> >> >>>> >> >> >> >> >> On Mon, Aug 7, 2017 at 5:12 PM, Jom O'Fisher >>>> >> >> >> >> >> >>>> >> >> >> >> >> wrote: >>>> >> >> >> >> >> > Either option can work fine. Disclosure: I work on >>>> >> >> >> >> >> > Android >>>> >> >> >> >> >> > Studio >>>> >> >> >> >> >> > and >>>> >> >> >> >> >> > was >>>> >> >> >> >> >> > the one that added CMake support. >>>> >> >> >> >> >> > >>>> >> >> >> >> >> > Option (1) is the way it's designed to work and we're >>>> >> >> >> >> >> > working >>>> >> >> >> >> >> > toward >>>> >> >> >> >> >> > getting >>>> >> >> >> >> >> > rid of the need for the CMake fork. I can't really say >>>> >> >> >> >> >> > when >>>> >> >> >> >> >> > that >>>> >> >> >> >> >> > will >>>> >> >> >> >> >> > happen >>>> >> >> >> >> >> > but if you can get away with an older CMake for now >>>> >> >> >> >> >> > then I'd >>>> >> >> >> >> >> > go >>>> >> >> >> >> >> > this >>>> >> >> >> >> >> > way. >>>> >> >> >> >> >> > As you mentioned, option (1) will allow you to view >>>> >> >> >> >> >> > your >>>> >> >> >> >> >> > source >>>> >> >> >> >> >> > file >>>> >> >> >> >> >> > structure in Android Studio, edit files, and debug >>>> >> >> >> >> >> > using the >>>> >> >> >> >> >> > built-in >>>> >> >> >> >> >> > debugging support. >>>> >> >> >> >> >> > >>>> >> >> >> >> >> > To get option (2) to work, you can use jniDirs setting >>>> >> >> >> >> >> > to >>>> >> >> >> >> >> > tell >>>> >> >> >> >> >> > Android >>>> >> >> >> >> >> > Gradle where to pick up your built .so files (see >>>> >> >> >> >> >> > >>>> >> >> >> >> >> > >>>> >> >> >> >> >> > >>>> >> >> >> >> >> > >>>> >> >> >> >> >> > >>>> >> >> >> >> >> > >>>> >> >> >> >> >> > https://stackoverflow.com/questions/21255125/how-can-i-add-so-files-to-an-android-library-project-using-gradle-0-7). >>>> >> >> >> >> >> > I'm not aware of any projects that use this approach >>>> >> >> >> >> >> > but it >>>> >> >> >> >> >> > should >>>> >> >> >> >> >> > work >>>> >> >> >> >> >> > in >>>> >> >> >> >> >> > principal. >>>> >> >> >> >> >> > >>>> >> >> >> >> >> > I hope this helps, >>>> >> >> >> >> >> > Jomo >>>> >> >> >> >> >> > >>>> >> >> >> >> >> > >>>> >> >> >> >> >> > On Mon, Aug 7, 2017 at 11:09 AM, Robert Dailey >>>> >> >> >> >> >> > >>>> >> >> >> >> >> > wrote: >>>> >> >> >> >> >> >> >>>> >> >> >> >> >> >> Right now I have custom targets set to execute the >>>> >> >> >> >> >> >> "ant >>>> >> >> >> >> >> >> release" >>>> >> >> >> >> >> >> command after my native targets are built. Part of >>>> >> >> >> >> >> >> that >>>> >> >> >> >> >> >> command >>>> >> >> >> >> >> >> involves copying *.so files to the libs/armeabi-v7a >>>> >> >> >> >> >> >> directory >>>> >> >> >> >> >> >> so >>>> >> >> >> >> >> >> they >>>> >> >> >> >> >> >> get packaged in an APK. >>>> >> >> >> >> >> >> >>>> >> >> >> >> >> >> When switching to gradle, I have two options: >>>> >> >> >> >> >> >> >>>> >> >> >> >> >> >> 1. Gradle drives CMake: This means using Android >>>> >> >> >> >> >> >> Studio and >>>> >> >> >> >> >> >> being >>>> >> >> >> >> >> >> locked down to Google's fork of CMake which is a few >>>> >> >> >> >> >> >> major >>>> >> >> >> >> >> >> releases >>>> >> >> >> >> >> >> behind. I see that as a negative. >>>> >> >> >> >> >> >> >>>> >> >> >> >> >> >> 2. CMake drives Gradle: This would be the same or >>>> >> >> >> >> >> >> similar >>>> >> >> >> >> >> >> to >>>> >> >> >> >> >> >> what >>>> >> >> >> >> >> >> I'm >>>> >> >> >> >> >> >> already doing: The custom targets I have would execute >>>> >> >> >> >> >> >> gradle >>>> >> >> >> >> >> >> as >>>> >> >> >> >> >> >> a >>>> >> >> >> >> >> >> separate build step, instead of running ant commands. >>>> >> >> >> >> >> >> I'm >>>> >> >> >> >> >> >> not >>>> >> >> >> >> >> >> too >>>> >> >> >> >> >> >> familiar with Gradle, so I'm not sure how you tell it >>>> >> >> >> >> >> >> where >>>> >> >> >> >> >> >> your >>>> >> >> >> >> >> >> shared libraries are for the APK packaging steps. >>>> >> >> >> >> >> >> >>>> >> >> >> >> >> >> Which does everyone recommend? Is anyone using one of >>>> >> >> >> >> >> >> these >>>> >> >> >> >> >> >> setups >>>> >> >> >> >> >> >> successfully? The downside to option 2 is probably no >>>> >> >> >> >> >> >> on-device >>>> >> >> >> >> >> >> native >>>> >> >> >> >> >> >> debugging since Android Studio probably can't handle >>>> >> >> >> >> >> >> gradle >>>> >> >> >> >> >> >> projects >>>> >> >> >> >> >> >> without any external CMake builds set up. >>>> >> >> >> >> >> >> >>>> >> >> >> >> >> >> Would like some general direction & advice before I >>>> >> >> >> >> >> >> move >>>> >> >> >> >> >> >> away >>>> >> >> >> >> >> >> from >>>> >> >> >> >> >> >> ANT. Thanks in advance. >>>> >> >> >> >> >> >> -- >>>> >> >> >> >> >> >> >>>> >> >> >> >> >> >> Powered by www.kitware.com >>>> >> >> >> >> >> >> >>>> >> >> >> >> >> >> Please keep messages on-topic and check the CMake FAQ >>>> >> >> >> >> >> >> at: >>>> >> >> >> >> >> >> http://www.cmake.org/Wiki/CMake_FAQ >>>> >> >> >> >> >> >> >>>> >> >> >> >> >> >> Kitware offers various services to support the CMake >>>> >> >> >> >> >> >> community. >>>> >> >> >> >> >> >> For >>>> >> >> >> >> >> >> more >>>> >> >> >> >> >> >> information on each offering, please visit: >>>> >> >> >> >> >> >> >>>> >> >> >> >> >> >> CMake Support: >>>> >> >> >> >> >> >> http://cmake.org/cmake/help/support.html >>>> >> >> >> >> >> >> CMake Consulting: >>>> >> >> >> >> >> >> http://cmake.org/cmake/help/consulting.html >>>> >> >> >> >> >> >> CMake Training Courses: >>>> >> >> >> >> >> >> http://cmake.org/cmake/help/training.html >>>> >> >> >> >> >> >> >>>> >> >> >> >> >> >> Visit other Kitware open-source projects at >>>> >> >> >> >> >> >> http://www.kitware.com/opensource/opensource.html >>>> >> >> >> >> >> >> >>>> >> >> >> >> >> >> Follow this link to subscribe/unsubscribe: >>>> >> >> >> >> >> >> http://public.kitware.com/mailman/listinfo/cmake >>>> >> >> >> >> >> > >>>> >> >> >> >> >> > >>>> >> >> >> >> > >>>> >> >> >> >> > >>>> >> >> >> > >>>> >> >> >> > >>>> >> >> > >>>> >> >> > >>>> >> > >>>> >> > >>>> > >>>> > >>> >>> >> > From rcdailey.lists at gmail.com Tue Aug 22 10:26:52 2017 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Tue, 22 Aug 2017 09:26:52 -0500 Subject: [CMake] CMake + Gradle for Android In-Reply-To: References: Message-ID: Sorry I forgot to answer your last set of questions: CommonLib is indeed 2 things: * A common (static or shared) library for native code (most of our CMake targets specify CommonLib as a link dependency) * A common library for Java code (we do specify this as a dependency for most java targets in Gradle, specifically those under Applications/) On Mon, Aug 21, 2017 at 6:20 PM, Raymond Chiu wrote: > Hi Robert, > > I work with Jom on the Android Studio team, and I would like to clarify a > few things to better understand your situation. > You mentioned the project is intend to be cross platform. Normally, in such > situation, we expect there to be a single CMake root project to be imported > into one of the Android library/application. However, in your case, there > are subprojects with Java code. > > Are the CMake code in App1/2/3 intended to be cross platform too? Or are > they Android specific code? If they are meant to be cross platform, how > does the Java code works on other platforms? Or perhaps you added Java > binding in those subprojects just for Android? > > The build.gradle in CommonLib, what kind of Gradle project is that? From > your description, it doesn't look like an Android library project. Or am I > mistaken and it also applies the android library plugin? > > Raymond > > On Mon, Aug 21, 2017 at 3:34 PM, Jom O'Fisher wrote: >> >> + a colleague >> >> On Mon, Aug 21, 2017 at 3:11 PM, Jom O'Fisher >> wrote: >>> >>> You can find that number like this: >>> - x = number of externalNativeBuild.cmake.path in your build.gradle files >>> - y = number of gradle configurations (like debug and release) >>> - z = number of ABIs that you build >>> >>> The result is x * y * z. To be more accurate, you should consider y and z >>> to be functions of each build.gradle file since these can vary. >>> >>> There is a second set of folders that hold the stripped versions of the >>> .so files that is purely managed by the android gradle plugin, so you might >>> consider the answer to be 2 * x * y * z. >>> >>> Hope this helps. >>> >>> >>> >>> >>> >>> >>> On Mon, Aug 21, 2017 at 2:41 PM, Robert Dailey >>> wrote: >>>> >>>> This definitely a bit better, but still requires the boilerplate in >>>> each leaf gradle file. But I can't seriously complain too much. I >>>> think I'm more concerned with the implications this has underneath. >>>> First, let me ask just to make sure I'm not misunderstanding: Does >>>> each `externalNativeBuild` entry essentially mean 1 CMAKE_BINARY_DIR? >>>> How many binary dirs do you manage internally and what determines when >>>> they get created? >>>> >>>> On Mon, Aug 21, 2017 at 2:35 PM, Jom O'Fisher >>>> wrote: >>>> > Would it work for your scenario to provide properties in the root >>>> > build.gradle: >>>> > >>>> > ext { >>>> > cmakePath = file "CMakeLists.txt" >>>> > } >>>> > >>>> > And then consume them in the leaf app/build.gradle like this? >>>> > >>>> > externalNativeBuild { >>>> > cmake { >>>> > path cmakePath >>>> > } >>>> > } >>>> > >>>> > It doesn't fully hide the details but it does centralize the >>>> > information. >>>> > >>>> > >>>> > On Mon, Aug 21, 2017 at 11:20 AM, Robert Dailey >>>> > >>>> > wrote: >>>> >> >>>> >> I wouldn't want to do that, it's too convoluted. I have other >>>> >> platforms that use these CMake scripts as well. For example, I run on >>>> >> Windows and Linux platforms as well to build the native code. Normal >>>> >> CMake behavior is designed to work at a root then go downwards to >>>> >> find >>>> >> targets. However it seems Gradle wants to start at a subdirectory and >>>> >> work its way up to the root, which is opposite of CMake's intended >>>> >> behavior IMHO. Not only that but I want to avoid special-casing >>>> >> behavior in CMake just for Android's use. >>>> >> >>>> >> At the moment it feels like (again referring back to my previous >>>> >> example structure) that both App2 and App3 each run CMake in >>>> >> independent binary directories instead of sharing 1 binary directory >>>> >> and building 2 targets inside of it. I prefer this behavior instead, >>>> >> especially since it allows CMake to operate as it was intended. I >>>> >> think it's a common case that projects will define multiple targets >>>> >> starting from a single root, and expect multiple APKs or java >>>> >> dependencies to be built within it. >>>> >> >>>> >> If I'm misunderstanding or making false assumptions please let me >>>> >> know. >>>> >> >>>> >> >>>> >> >>>> >> On Mon, Aug 21, 2017 at 12:00 PM, Jom O'Fisher >>>> >> wrote: >>>> >> > Would it work for your situation for the leaf CMakeLists.txt to >>>> >> > include >>>> >> > the >>>> >> > root CMakeLists.txt? Then have the leaf-specific logic in the leaf >>>> >> > CMakeLists.txt? >>>> >> > >>>> >> > >>>> >> > >>>> >> > On Mon, Aug 21, 2017 at 9:33 AM, Robert Dailey >>>> >> > >>>> >> > wrote: >>>> >> >> >>>> >> >> Basically, yes. We have this sort of structure: >>>> >> >> >>>> >> >> / >>>> >> >> Applications/ >>>> >> >> App1/ >>>> >> >> build.gradle >>>> >> >> CMakeLists.txt >>>> >> >> App2/ >>>> >> >> build.gradle >>>> >> >> CMakeLists.txt >>>> >> >> App3/ >>>> >> >> build.gradle >>>> >> >> CMakeLists.txt >>>> >> >> CommonLib/ >>>> >> >> build.gradle >>>> >> >> CMakeLists.txt >>>> >> >> CMakeLists.txt >>>> >> >> >>>> >> >> The libs are defined as follows: >>>> >> >> >>>> >> >> * CommonLib is a static library (java code builds into a library) >>>> >> >> * No dependencies of its own >>>> >> >> * App1 is a shared library (java code builds into a library) >>>> >> >> * Dependencies (both java & native): CommonLib >>>> >> >> * App2 is a shared library (java code builds into an APK) >>>> >> >> * Dependencies (both java & native): App1, CommonLib >>>> >> >> * App3 is a shared library (java code builds into an APK) >>>> >> >> * Dependencies (both java & native): CommonLib >>>> >> >> >>>> >> >> In all cases, CMake must be invoked starting at the root >>>> >> >> CMakeLists.txt 1 time. Each target can be built from the same >>>> >> >> binary >>>> >> >> directory after that. Previously with ANT, I was building all >>>> >> >> native >>>> >> >> targets first, then moved libs to appropriate directories so that >>>> >> >> the >>>> >> >> 'ant' command would package the libs. >>>> >> >> >>>> >> >> For gradle, I wanted to avoid redundantly specifying the root >>>> >> >> directory in each leaf-level project directory. Using the example >>>> >> >> above, the leaf-level directories in this case would be App1, >>>> >> >> App2, >>>> >> >> App3, and CommonLib. However I think we only specify the native >>>> >> >> CMake >>>> >> >> stuff for the java targets that actually output an APK (that would >>>> >> >> be >>>> >> >> App2 and App3 only). >>>> >> >> >>>> >> >> The ultimate goal is to specify stuff that doesn't change per >>>> >> >> independent "module" of ours at the top level so it is transitive >>>> >> >> / >>>> >> >> inherited. Then only specify the differences (e.g. the native >>>> >> >> CMake >>>> >> >> target to build) in the leaf build gradle files. However you >>>> >> >> indicated >>>> >> >> this isn't possible. >>>> >> >> >>>> >> >> >>>> >> >> >>>> >> >> On Mon, Aug 21, 2017 at 11:11 AM, Jom O'Fisher >>>> >> >> >>>> >> >> wrote: >>>> >> >> > What you're doing already sounds correct. You can't directly >>>> >> >> > specify >>>> >> >> > CMakeLists.txt from the top-level build.gradle. Recommendation >>>> >> >> > is >>>> >> >> > that >>>> >> >> > it >>>> >> >> > should be specified from the build.gradle of the module of the >>>> >> >> > APK. >>>> >> >> > Is >>>> >> >> > the >>>> >> >> > issue that you have multiple APK modules that all reference the >>>> >> >> > same >>>> >> >> > CMake >>>> >> >> > libraries? >>>> >> >> > >>>> >> >> > On Mon, Aug 21, 2017 at 9:00 AM, Robert Dailey >>>> >> >> > >>>> >> >> > wrote: >>>> >> >> >> >>>> >> >> >> Thanks this is very helpful. The other question I have is: Is >>>> >> >> >> there >>>> >> >> >> a >>>> >> >> >> place to centrally specify the root CMakeLists.txt? Basically, >>>> >> >> >> I >>>> >> >> >> want >>>> >> >> >> to specify the CMake root in 1 place, and have targets (defined >>>> >> >> >> further down in subdirectories) that require APK packaging to >>>> >> >> >> specify >>>> >> >> >> only the native target name that should be built & packaged. >>>> >> >> >> >>>> >> >> >> At the moment we specify the root CMakeLists.txt by walking up >>>> >> >> >> the >>>> >> >> >> tree, paths like "../../../../CMakeLists.txt". I think this >>>> >> >> >> should >>>> >> >> >> be >>>> >> >> >> put at the top-level build gradle file if possible. Is this >>>> >> >> >> doable >>>> >> >> >> at >>>> >> >> >> the moment? What is the recommended setup? >>>> >> >> >> >>>> >> >> >> On Mon, Aug 21, 2017 at 9:37 AM, Jom O'Fisher >>>> >> >> >> >>>> >> >> >> wrote: >>>> >> >> >> > Gradle does introspection on the CMake build to find .so >>>> >> >> >> > targets >>>> >> >> >> > and >>>> >> >> >> > those >>>> >> >> >> > get packaged. >>>> >> >> >> > There is also a special case for stl/runtime .so files from >>>> >> >> >> > the >>>> >> >> >> > NDK. >>>> >> >> >> > Any additional .so files need to specified in build.gradle >>>> >> >> >> > using >>>> >> >> >> > jniDirs >>>> >> >> >> > >>>> >> >> >> > On Mon, Aug 21, 2017 at 7:30 AM, Robert Dailey >>>> >> >> >> > >>>> >> >> >> > wrote: >>>> >> >> >> >> >>>> >> >> >> >> How exactly does Gradle package *.so files in an APK? I know >>>> >> >> >> >> that >>>> >> >> >> >> ANT >>>> >> >> >> >> used to do this for any libs under "libs/". Does Gradle >>>> >> >> >> >> do >>>> >> >> >> >> some >>>> >> >> >> >> introspection into CMake targets to see if outputs are *.so, >>>> >> >> >> >> and >>>> >> >> >> >> copy >>>> >> >> >> >> those to some location if needed? What about libraries like >>>> >> >> >> >> libgnustl_shared.so that come with the NDK? I'd like to know >>>> >> >> >> >> if >>>> >> >> >> >> any >>>> >> >> >> >> manual copy steps are needed in CMake to put outputs in >>>> >> >> >> >> proper >>>> >> >> >> >> locations for the APK build step. I had to do this when >>>> >> >> >> >> using >>>> >> >> >> >> ANT. >>>> >> >> >> >> >>>> >> >> >> >> On Mon, Aug 7, 2017 at 6:16 PM, Jom O'Fisher >>>> >> >> >> >> >>>> >> >> >> >> wrote: >>>> >> >> >> >> > 1) There is a folder created for each ABI under the >>>> >> >> >> >> > project >>>> >> >> >> >> > module >>>> >> >> >> >> > folder >>>> >> >> >> >> > (so unique per module per ABI) >>>> >> >> >> >> > 2) Gradle doesn't specify language level though you can >>>> >> >> >> >> > choose >>>> >> >> >> >> > to >>>> >> >> >> >> > specify it >>>> >> >> >> >> > yourself from the build.gradle. This doc does a pretty >>>> >> >> >> >> > good job >>>> >> >> >> >> > of >>>> >> >> >> >> > explaining which variables are set by Gradle: >>>> >> >> >> >> > >>>> >> >> >> >> > https://developer.android.com/ndk/guides/cmake.html#variables. >>>> >> >> >> >> > Philosophically, we try to set as little as we can get >>>> >> >> >> >> > away >>>> >> >> >> >> > with. >>>> >> >> >> >> > In >>>> >> >> >> >> > particular, the section titled "Understanding the CMake >>>> >> >> >> >> > build >>>> >> >> >> >> > command" >>>> >> >> >> >> > lays >>>> >> >> >> >> > out exactly what we set. You can also see the folders we >>>> >> >> >> >> > specify >>>> >> >> >> >> > (one >>>> >> >> >> >> > per >>>> >> >> >> >> > module per ABI) >>>> >> >> >> >> > 3) Not sure I understand this. >>>> >> >> >> >> > >>>> >> >> >> >> > The other document worth taking a look at (if you haven't >>>> >> >> >> >> > already) >>>> >> >> >> >> > is: >>>> >> >> >> >> > >>>> >> >> >> >> > >>>> >> >> >> >> > https://developer.android.com/studio/projects/add-native-code.html >>>> >> >> >> >> > >>>> >> >> >> >> > >>>> >> >> >> >> > On Mon, Aug 7, 2017 at 3:35 PM, Robert Dailey >>>> >> >> >> >> > >>>> >> >> >> >> > wrote: >>>> >> >> >> >> >> >>>> >> >> >> >> >> Thanks Jom >>>> >> >> >> >> >> >>>> >> >> >> >> >> Honestly, I prefer option 1 to work simply because that's >>>> >> >> >> >> >> how >>>> >> >> >> >> >> Google's >>>> >> >> >> >> >> officially supporting CMake. But it also has debugging >>>> >> >> >> >> >> which >>>> >> >> >> >> >> is >>>> >> >> >> >> >> the >>>> >> >> >> >> >> #1 >>>> >> >> >> >> >> reason for me. >>>> >> >> >> >> >> >>>> >> >> >> >> >> However, I'd like to understand a lot more about how the >>>> >> >> >> >> >> integration >>>> >> >> >> >> >> really happens. For example, I have these questions: >>>> >> >> >> >> >> >>>> >> >> >> >> >> 1) How, internally, are CMake build directories managed? >>>> >> >> >> >> >> Do >>>> >> >> >> >> >> you >>>> >> >> >> >> >> generate 1 per unique android project? What about for >>>> >> >> >> >> >> each >>>> >> >> >> >> >> specific >>>> >> >> >> >> >> platform (x86, armeabi-v7a, etc)? >>>> >> >> >> >> >> 2) Last time I looked into CMake integration, things >>>> >> >> >> >> >> defined >>>> >> >> >> >> >> inside >>>> >> >> >> >> >> the CMake scripts were ignored because they are specified >>>> >> >> >> >> >> at >>>> >> >> >> >> >> the >>>> >> >> >> >> >> command line. Namely, all of those settings that are >>>> >> >> >> >> >> driven by >>>> >> >> >> >> >> the >>>> >> >> >> >> >> Gradle configuration (CXX language level was one in >>>> >> >> >> >> >> particular >>>> >> >> >> >> >> I >>>> >> >> >> >> >> think; I specify C++14 support via CMake, but I recall >>>> >> >> >> >> >> this >>>> >> >> >> >> >> being >>>> >> >> >> >> >> overridden from outside)? >>>> >> >> >> >> >> 3) How redundant is it to configure individual libraries >>>> >> >> >> >> >> via >>>> >> >> >> >> >> the >>>> >> >> >> >> >> gradle scripts? In my previous attempts, I wanted to >>>> >> >> >> >> >> define >>>> >> >> >> >> >> common >>>> >> >> >> >> >> stuff for CMake / native code at the root gradle or >>>> >> >> >> >> >> settings >>>> >> >> >> >> >> file, >>>> >> >> >> >> >> and >>>> >> >> >> >> >> only define the differences in the actual gradle build >>>> >> >> >> >> >> files >>>> >> >> >> >> >> for >>>> >> >> >> >> >> each >>>> >> >> >> >> >> corresponding Java target (like, defining the name of the >>>> >> >> >> >> >> native >>>> >> >> >> >> >> (shared library) target in Gradle, but the command line >>>> >> >> >> >> >> invocation, >>>> >> >> >> >> >> -D >>>> >> >> >> >> >> CMake settings, etc would all be common and defined at >>>> >> >> >> >> >> the >>>> >> >> >> >> >> root). >>>> >> >> >> >> >> >>>> >> >> >> >> >> The TLDR is, the closer we can stay to CMake's way of >>>> >> >> >> >> >> doing >>>> >> >> >> >> >> things >>>> >> >> >> >> >> and >>>> >> >> >> >> >> keep CMake-related settings self-contained to the CMake >>>> >> >> >> >> >> scripts >>>> >> >> >> >> >> themselves, the better. This also makes cross-platform >>>> >> >> >> >> >> easier >>>> >> >> >> >> >> (we >>>> >> >> >> >> >> build the native code in Windows, for example, so having >>>> >> >> >> >> >> settings >>>> >> >> >> >> >> specified in the gradle files do not carry over to other >>>> >> >> >> >> >> platforms. >>>> >> >> >> >> >> Namely, settings that are not platform specific like the >>>> >> >> >> >> >> C++ >>>> >> >> >> >> >> language >>>> >> >> >> >> >> level). >>>> >> >> >> >> >> >>>> >> >> >> >> >> If there's a detailed document / wiki I can read on the >>>> >> >> >> >> >> intrinsics >>>> >> >> >> >> >> of >>>> >> >> >> >> >> CMake integration in Gradle / Android Studio, I'd love to >>>> >> >> >> >> >> read >>>> >> >> >> >> >> it. >>>> >> >> >> >> >> Otherwise, I hope you won't mind if I pick your brain as >>>> >> >> >> >> >> questions >>>> >> >> >> >> >> come up. I think I'm going to try option 1 for now and >>>> >> >> >> >> >> see how >>>> >> >> >> >> >> it >>>> >> >> >> >> >> goes. It's just black box for me because unlike option 2, >>>> >> >> >> >> >> I >>>> >> >> >> >> >> have >>>> >> >> >> >> >> very >>>> >> >> >> >> >> little control over what happens after building the >>>> >> >> >> >> >> shared >>>> >> >> >> >> >> libraries, >>>> >> >> >> >> >> and to make up for that I need to really get a deep >>>> >> >> >> >> >> understanding >>>> >> >> >> >> >> of >>>> >> >> >> >> >> how it works so I can make sure I code my CMake scripts >>>> >> >> >> >> >> properly >>>> >> >> >> >> >> for >>>> >> >> >> >> >> not only Android, but my other platforms as well >>>> >> >> >> >> >> (non-Android >>>> >> >> >> >> >> platforms). >>>> >> >> >> >> >> >>>> >> >> >> >> >> Thanks again. >>>> >> >> >> >> >> >>>> >> >> >> >> >> On Mon, Aug 7, 2017 at 5:12 PM, Jom O'Fisher >>>> >> >> >> >> >> >>>> >> >> >> >> >> wrote: >>>> >> >> >> >> >> > Either option can work fine. Disclosure: I work on >>>> >> >> >> >> >> > Android >>>> >> >> >> >> >> > Studio >>>> >> >> >> >> >> > and >>>> >> >> >> >> >> > was >>>> >> >> >> >> >> > the one that added CMake support. >>>> >> >> >> >> >> > >>>> >> >> >> >> >> > Option (1) is the way it's designed to work and we're >>>> >> >> >> >> >> > working >>>> >> >> >> >> >> > toward >>>> >> >> >> >> >> > getting >>>> >> >> >> >> >> > rid of the need for the CMake fork. I can't really say >>>> >> >> >> >> >> > when >>>> >> >> >> >> >> > that >>>> >> >> >> >> >> > will >>>> >> >> >> >> >> > happen >>>> >> >> >> >> >> > but if you can get away with an older CMake for now >>>> >> >> >> >> >> > then I'd >>>> >> >> >> >> >> > go >>>> >> >> >> >> >> > this >>>> >> >> >> >> >> > way. >>>> >> >> >> >> >> > As you mentioned, option (1) will allow you to view >>>> >> >> >> >> >> > your >>>> >> >> >> >> >> > source >>>> >> >> >> >> >> > file >>>> >> >> >> >> >> > structure in Android Studio, edit files, and debug >>>> >> >> >> >> >> > using the >>>> >> >> >> >> >> > built-in >>>> >> >> >> >> >> > debugging support. >>>> >> >> >> >> >> > >>>> >> >> >> >> >> > To get option (2) to work, you can use jniDirs setting >>>> >> >> >> >> >> > to >>>> >> >> >> >> >> > tell >>>> >> >> >> >> >> > Android >>>> >> >> >> >> >> > Gradle where to pick up your built .so files (see >>>> >> >> >> >> >> > >>>> >> >> >> >> >> > >>>> >> >> >> >> >> > >>>> >> >> >> >> >> > >>>> >> >> >> >> >> > >>>> >> >> >> >> >> > >>>> >> >> >> >> >> > https://stackoverflow.com/questions/21255125/how-can-i-add-so-files-to-an-android-library-project-using-gradle-0-7). >>>> >> >> >> >> >> > I'm not aware of any projects that use this approach >>>> >> >> >> >> >> > but it >>>> >> >> >> >> >> > should >>>> >> >> >> >> >> > work >>>> >> >> >> >> >> > in >>>> >> >> >> >> >> > principal. >>>> >> >> >> >> >> > >>>> >> >> >> >> >> > I hope this helps, >>>> >> >> >> >> >> > Jomo >>>> >> >> >> >> >> > >>>> >> >> >> >> >> > >>>> >> >> >> >> >> > On Mon, Aug 7, 2017 at 11:09 AM, Robert Dailey >>>> >> >> >> >> >> > >>>> >> >> >> >> >> > wrote: >>>> >> >> >> >> >> >> >>>> >> >> >> >> >> >> Right now I have custom targets set to execute the >>>> >> >> >> >> >> >> "ant >>>> >> >> >> >> >> >> release" >>>> >> >> >> >> >> >> command after my native targets are built. Part of >>>> >> >> >> >> >> >> that >>>> >> >> >> >> >> >> command >>>> >> >> >> >> >> >> involves copying *.so files to the libs/armeabi-v7a >>>> >> >> >> >> >> >> directory >>>> >> >> >> >> >> >> so >>>> >> >> >> >> >> >> they >>>> >> >> >> >> >> >> get packaged in an APK. >>>> >> >> >> >> >> >> >>>> >> >> >> >> >> >> When switching to gradle, I have two options: >>>> >> >> >> >> >> >> >>>> >> >> >> >> >> >> 1. Gradle drives CMake: This means using Android >>>> >> >> >> >> >> >> Studio and >>>> >> >> >> >> >> >> being >>>> >> >> >> >> >> >> locked down to Google's fork of CMake which is a few >>>> >> >> >> >> >> >> major >>>> >> >> >> >> >> >> releases >>>> >> >> >> >> >> >> behind. I see that as a negative. >>>> >> >> >> >> >> >> >>>> >> >> >> >> >> >> 2. CMake drives Gradle: This would be the same or >>>> >> >> >> >> >> >> similar >>>> >> >> >> >> >> >> to >>>> >> >> >> >> >> >> what >>>> >> >> >> >> >> >> I'm >>>> >> >> >> >> >> >> already doing: The custom targets I have would execute >>>> >> >> >> >> >> >> gradle >>>> >> >> >> >> >> >> as >>>> >> >> >> >> >> >> a >>>> >> >> >> >> >> >> separate build step, instead of running ant commands. >>>> >> >> >> >> >> >> I'm >>>> >> >> >> >> >> >> not >>>> >> >> >> >> >> >> too >>>> >> >> >> >> >> >> familiar with Gradle, so I'm not sure how you tell it >>>> >> >> >> >> >> >> where >>>> >> >> >> >> >> >> your >>>> >> >> >> >> >> >> shared libraries are for the APK packaging steps. >>>> >> >> >> >> >> >> >>>> >> >> >> >> >> >> Which does everyone recommend? Is anyone using one of >>>> >> >> >> >> >> >> these >>>> >> >> >> >> >> >> setups >>>> >> >> >> >> >> >> successfully? The downside to option 2 is probably no >>>> >> >> >> >> >> >> on-device >>>> >> >> >> >> >> >> native >>>> >> >> >> >> >> >> debugging since Android Studio probably can't handle >>>> >> >> >> >> >> >> gradle >>>> >> >> >> >> >> >> projects >>>> >> >> >> >> >> >> without any external CMake builds set up. >>>> >> >> >> >> >> >> >>>> >> >> >> >> >> >> Would like some general direction & advice before I >>>> >> >> >> >> >> >> move >>>> >> >> >> >> >> >> away >>>> >> >> >> >> >> >> from >>>> >> >> >> >> >> >> ANT. Thanks in advance. >>>> >> >> >> >> >> >> -- >>>> >> >> >> >> >> >> >>>> >> >> >> >> >> >> Powered by www.kitware.com >>>> >> >> >> >> >> >> >>>> >> >> >> >> >> >> Please keep messages on-topic and check the CMake FAQ >>>> >> >> >> >> >> >> at: >>>> >> >> >> >> >> >> http://www.cmake.org/Wiki/CMake_FAQ >>>> >> >> >> >> >> >> >>>> >> >> >> >> >> >> Kitware offers various services to support the CMake >>>> >> >> >> >> >> >> community. >>>> >> >> >> >> >> >> For >>>> >> >> >> >> >> >> more >>>> >> >> >> >> >> >> information on each offering, please visit: >>>> >> >> >> >> >> >> >>>> >> >> >> >> >> >> CMake Support: >>>> >> >> >> >> >> >> http://cmake.org/cmake/help/support.html >>>> >> >> >> >> >> >> CMake Consulting: >>>> >> >> >> >> >> >> http://cmake.org/cmake/help/consulting.html >>>> >> >> >> >> >> >> CMake Training Courses: >>>> >> >> >> >> >> >> http://cmake.org/cmake/help/training.html >>>> >> >> >> >> >> >> >>>> >> >> >> >> >> >> Visit other Kitware open-source projects at >>>> >> >> >> >> >> >> http://www.kitware.com/opensource/opensource.html >>>> >> >> >> >> >> >> >>>> >> >> >> >> >> >> Follow this link to subscribe/unsubscribe: >>>> >> >> >> >> >> >> http://public.kitware.com/mailman/listinfo/cmake >>>> >> >> >> >> >> > >>>> >> >> >> >> >> > >>>> >> >> >> >> > >>>> >> >> >> >> > >>>> >> >> >> > >>>> >> >> >> > >>>> >> >> > >>>> >> >> > >>>> >> > >>>> >> > >>>> > >>>> > >>> >>> >> > From MillerHenry at JohnDeere.com Tue Aug 22 09:44:13 2017 From: MillerHenry at JohnDeere.com (Miller Henry) Date: Tue, 22 Aug 2017 13:44:13 +0000 Subject: [CMake] target_link_libraries - private public interface rules Message-ID: <35F6921410093E4CA40D524BD5C18D4C3E1594B4@EDXMB89.jdnet.deere.com> I've been playing with the private/public/interface keyword to target_link_libraries. It seems to me that WHAT they do is well documented, but nobody has ever actually documented what they correct rules of WHEN/WHY you should use any of them. After a lot of misstarts I think I've started to understand what the rules should be. I think they need to be written down someplace so that others don't have to make the mistakes I have. Also it would be nice if others would look this list over to see what else might be overlooking. Can somebody point me to a good place to do this? Sending to the mailing list seems like a poor solution as corrections will not be easily findable. A wiki seems ideal, but which? KDE in particular should probably have these rules in their official requirements, but I'm not sure if they are the correct ones to own them. -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.maynard at kitware.com Tue Aug 22 10:45:59 2017 From: robert.maynard at kitware.com (Robert Maynard) Date: Tue, 22 Aug 2017 10:45:59 -0400 Subject: [CMake] target_link_libraries - private public interface rules In-Reply-To: <35F6921410093E4CA40D524BD5C18D4C3E1594B4@EDXMB89.jdnet.deere.com> References: <35F6921410093E4CA40D524BD5C18D4C3E1594B4@EDXMB89.jdnet.deere.com> Message-ID: You could look at extending the official CMake documentation, specifically the build system documentation ( https://cmake.org/cmake/help/v3.9/manual/cmake-buildsystem.7.html ). The documentation is all in restructure text and we accept documentation changes through our gitlab instance. cmake gitlab: https://gitlab.kitware.com/cmake/cmake build-system restructure page: https://gitlab.kitware.com/cmake/cmake/blob/master/Help/manual/cmake-buildsystem.7.rst contribution guideline: https://gitlab.kitware.com/cmake/cmake/blob/master/CONTRIBUTING.rst On Tue, Aug 22, 2017 at 9:44 AM, Miller Henry wrote: > > I?ve been playing with the private/public/interface keyword to > target_link_libraries. It seems to me that WHAT they do is well documented, > but nobody has ever actually documented what they correct rules of WHEN/WHY > you should use any of them. After a lot of misstarts I think I?ve started to > understand what the rules should be. I think they need to be written down > someplace so that others don?t have to make the mistakes I have. Also it > would be nice if others would look this list over to see what else might be > overlooking. > > Can somebody point me to a good place to do this? Sending to the mailing > list seems like a poor solution as corrections will not be easily findable. > A wiki seems ideal, but which? KDE in particular should probably have these > rules in their official requirements, but I?m not sure if they are the > correct ones to own them. > > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake From haocheng.liu at kitware.com Tue Aug 22 10:50:14 2017 From: haocheng.liu at kitware.com (Haocheng Liu) Date: Tue, 22 Aug 2017 10:50:14 -0400 Subject: [CMake] target_link_libraries - private public interface rules In-Reply-To: References: <35F6921410093E4CA40D524BD5C18D4C3E1594B4@EDXMB89.jdnet.deere.com> Message-ID: On Tue, Aug 22, 2017 at 10:45 AM, Robert Maynard wrote: > You could look at extending the official CMake documentation, > specifically the build system documentation ( > https://cmake.org/cmake/help/v3.9/manual/cmake-buildsystem.7.html ). > > The documentation is all in restructure text and we accept > documentation changes through our gitlab instance. > > cmake gitlab: https://gitlab.kitware.com/cmake/cmake > > build-system restructure page: > https://gitlab.kitware.com/cmake/cmake/blob/master/Help/ > manual/cmake-buildsystem.7.rst > > contribution guideline: > https://gitlab.kitware.com/cmake/cmake/blob/master/CONTRIBUTING.rst > > As Rob has pointed out, you can start from this file as target_link_libraries.rst in CMake source code. > On Tue, Aug 22, 2017 at 9:44 AM, Miller Henry > wrote: > > > > I?ve been playing with the private/public/interface keyword to > > target_link_libraries. It seems to me that WHAT they do is well > documented, > > but nobody has ever actually documented what they correct rules of > WHEN/WHY > > you should use any of them. After a lot of misstarts I think I?ve > started to > > understand what the rules should be. I think they need to be written down > > someplace so that others don?t have to make the mistakes I have. Also it > > would be nice if others would look this list over to see what else might > be > > overlooking. > > > > Can somebody point me to a good place to do this? Sending to the mailing > > list seems like a poor solution as corrections will not be easily > findable. > > A wiki seems ideal, but which? KDE in particular should probably have > these > > rules in their official requirements, but I?m not sure if they are the > > correct ones to own them. > > > > > > -- > > > > Powered by www.kitware.com > > > > Please keep messages on-topic and check the CMake FAQ at: > > http://www.cmake.org/Wiki/CMake_FAQ > > > > Kitware offers various services to support the CMake community. For more > > information on each offering, please visit: > > > > CMake Support: http://cmake.org/cmake/help/support.html > > CMake Consulting: http://cmake.org/cmake/help/consulting.html > > CMake Training Courses: http://cmake.org/cmake/help/training.html > > > > Visit other Kitware open-source projects at > > http://www.kitware.com/opensource/opensource.html > > > > Follow this link to subscribe/unsubscribe: > > http://public.kitware.com/mailman/listinfo/cmake > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/ > opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake -- Best regards Haocheng Haocheng LIU Kitware, Inc. R&D Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4421 <(518)%20881-4421> -------------- next part -------------- An HTML attachment was scrubbed... URL: From bitminer at gmail.com Tue Aug 22 11:27:37 2017 From: bitminer at gmail.com (Brian Davis) Date: Tue, 22 Aug 2017 10:27:37 -0500 Subject: [CMake] Interface Libraries allow include directories but not link directories.. Why? In-Reply-To: References: Message-ID: C comments On Tue, Aug 22, 2017 at 8:01 AM, Robert Maynard wrote: > Usage of link_directories is discouraged, and was part of the reason > why a target based option was not added. As the documentation for > link_directories states "Note that this command is rarely necessary. > Library locations returned by find_package() and find_library() are > absolute paths. Pass these absolute library file paths directly to the > target_link_libraries() command. CMake will ensure the linker finds > them." > > Oh the horror. We are not expected to have abs paths to our libs to ensure "CMake finds them" vs supporting link library directories which all compilers support for some reason. I mean hey maybe CMake could support / expose functionality of the underlying tools to the user in a way and means that make sense and let them decide if abs paths or use of link libs dir is appropriate. I know which one I would choose. Is it really that difficult to make Link_directories a target specific property? It's as though tying a remote control to a grandmother so as to "ensure" she can turn on the TV is also a good idea. I hope I never understand this logic. Has any one read my post on ITK and use of abs paths where there is a 50 char limit imposed on where itk is built due to command line limitations on windows for the build. I am starting to understand how and why I now have to build itk at C:/itk... I asked ITK if I should just build at c:\ but they stated graciously something to the affect that I could use those extra 3 chars... boy was I happy then! I ask that kitware read: https://cmake.org/pipermail/cmake/2017-March/065227.html and reassess logic of abs paths Snips in line here for convenience: -- snip -- But ITK is no great example either as on windows has a limit due to path length limiting on where ITK can be build (build dir) I think it's something like 56 characters (resulting in build paths outside the project like C:\itk\src\ITK-4.8.1) and I have stated my aggravation regarding this on ITK's user forum. I must be joking right? well from ITK root CMakeLists.txt file: if( CMAKE_HOST_WIN32 ) string( LENGTH "${CMAKE_CURRENT_SOURCE_DIR}" n ) if( n GREATER 50 ) message( FATAL_ERROR "ITK source code directory path length is too long (${n} > 50)." "Please move the ITK source code directory to a directory with a shorter path." ) endif() Sadly no and .. ok so it's 50. -- snip -- I would certainly like to hear a defense of this "logic". I like to say that I discourage insanity. On Mon, Aug 21, 2017 at 8:17 PM, Brian Davis wrote: > > Why does: > > > > Interface Libraries > > https://cmake.org/cmake/help/latest/command/add_library. > html?highlight=add_library#id3 > > > > allow include directories via > > > > target_include_directories(INTERFACE) > > > > but not link_directories > > > > https://cmake.org/cmake/help/latest/prop_dir/LINK_ > DIRECTORIES.html?highlight=link_directories > > > > which if we look at property scope: > > > > https://cmake.org/cmake/help/latest/manual/cmake-properties.7.html > > > > Why is include_directories at target resolution while link_directories > is at > > directory resolution. > > > > link_directories is a property on a directory which if I recalled > correctly > > I complained about many many moons ago (circa 2009) when I first realized > > this. I did not understand this logic then and don't understand this > logic > > now. Someone what to give me the recipe for the CMake cool-aid so I can > mix > > that up, drink it down, and re-read the doc and finally come to terms > with > > this. Or could the powers that be redesign CMake to make sense. At the > > time I wrapped this nonsense in a macro and pretended it did not happen > ... > > now I am rewriting my project for "new" CMake and still don't get this. > > > > > > > > > > -- > > > > Powered by www.kitware.com > > > > Please keep messages on-topic and check the CMake FAQ at: > > http://www.cmake.org/Wiki/CMake_FAQ > > > > Kitware offers various services to support the CMake community. For more > > information on each offering, please visit: > > > > CMake Support: http://cmake.org/cmake/help/support.html > > CMake Consulting: http://cmake.org/cmake/help/consulting.html > > CMake Training Courses: http://cmake.org/cmake/help/training.html > > > > Visit other Kitware open-source projects at > > http://www.kitware.com/opensource/opensource.html > > > > Follow this link to subscribe/unsubscribe: > > http://public.kitware.com/mailman/listinfo/cmake > -- Brian J. Davis -------------- next part -------------- An HTML attachment was scrubbed... URL: From MillerHenry at JohnDeere.com Tue Aug 22 11:31:56 2017 From: MillerHenry at JohnDeere.com (Miller Henry) Date: Tue, 22 Aug 2017 15:31:56 +0000 Subject: [CMake] target_link_libraries - private public interface rules In-Reply-To: References: <35F6921410093E4CA40D524BD5C18D4C3E1594B4@EDXMB89.jdnet.deere.com> Message-ID: <35F6921410093E4CA40D524BD5C18D4C3E1595A1@EDXMB89.jdnet.deere.com> Is that the right place to say things like If a header file contains #include Then OtherLibrary is probably candidate for PUBLIC, if the header contains the predeclaration class OtherLibraryClass; then OtherLibrary should be PRIVATE? I'm not against putting that content in official cmake documentation, but it seems like something that has never been done before. -----Original Message----- From: Robert Maynard [mailto:robert.maynard at kitware.com] Sent: Tuesday, August 22, 2017 9:46 AM To: Miller Henry Cc: cmake at cmake.org Subject: Re: [CMake] target_link_libraries - private public interface rules You could look at extending the official CMake documentation, specifically the build system documentation ( https://cmake.org/cmake/help/v3.9/manual/cmake-buildsystem.7.html ). The documentation is all in restructure text and we accept documentation changes through our gitlab instance. cmake gitlab: https://gitlab.kitware.com/cmake/cmake build-system restructure page: https://gitlab.kitware.com/cmake/cmake/blob/master/Help/manual/cmake-buildsystem.7.rst contribution guideline: https://gitlab.kitware.com/cmake/cmake/blob/master/CONTRIBUTING.rst On Tue, Aug 22, 2017 at 9:44 AM, Miller Henry wrote: > > I?ve been playing with the private/public/interface keyword to > target_link_libraries. It seems to me that WHAT they do is well > documented, but nobody has ever actually documented what they correct > rules of WHEN/WHY you should use any of them. After a lot of misstarts > I think I?ve started to understand what the rules should be. I think > they need to be written down someplace so that others don?t have to > make the mistakes I have. Also it would be nice if others would look > this list over to see what else might be overlooking. > > Can somebody point me to a good place to do this? Sending to the > mailing list seems like a poor solution as corrections will not be easily findable. > A wiki seems ideal, but which? KDE in particular should probably have > these rules in their official requirements, but I?m not sure if they > are the correct ones to own them. > > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For > more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake From brad.king at kitware.com Tue Aug 22 11:36:38 2017 From: brad.king at kitware.com (Brad King) Date: Tue, 22 Aug 2017 11:36:38 -0400 Subject: [CMake] 'cmake.exe -G Ninja' doesn't work for VS2017 with cmake ver 3.9.1 In-Reply-To: References: <84ce2ae4-99d2-c3d4-8bb0-82131019aa76@gmail.com> <6ddc295f-8cda-2f64-e6c2-3e33ec529e94@gmail.com> Message-ID: On 08/21/2017 05:56 PM, masaru tsuchiyama wrote: >> https://gitlab.kitware.com/cmake/cmake/issues/17191 > I think it is same as the issue. > I use Japanese version of Win10 Pro. Thanks. Unfortunately I've not been able to reproduce it. See discussion in the issue. Since you have a local build you used for bisecting this, might you be able to debug it? The `rules.ninja` file is likely missing due to `codecvt::do_out` in `Source/cm_codecvt.cxx` returning `std::codecvt_base::error` somewhere, causing the stream state to be bad so cmGeneratedFileStream doesn't rename the temporary file to its final place. Thanks, -Brad From robert.maynard at kitware.com Tue Aug 22 11:36:51 2017 From: robert.maynard at kitware.com (Robert Maynard) Date: Tue, 22 Aug 2017 11:36:51 -0400 Subject: [CMake] target_link_libraries - private public interface rules In-Reply-To: <35F6921410093E4CA40D524BD5C18D4C3E1595A1@EDXMB89.jdnet.deere.com> References: <35F6921410093E4CA40D524BD5C18D4C3E1594B4@EDXMB89.jdnet.deere.com> <35F6921410093E4CA40D524BD5C18D4C3E1595A1@EDXMB89.jdnet.deere.com> Message-ID: The `Transitive Usage Requirements` section of the cmake-buildsystem documentation quickly covers this idea but it could be elaborated on. This might be a good place for a concrete example. Any thoughts Brad? On Tue, Aug 22, 2017 at 11:31 AM, Miller Henry wrote: > Is that the right place to say things like > > If a header file contains > #include > Then OtherLibrary is probably candidate for PUBLIC, if the header contains the predeclaration > class OtherLibraryClass; > then OtherLibrary should be PRIVATE? > > I'm not against putting that content in official cmake documentation, but it seems like something that has never been done before. > > -----Original Message----- > From: Robert Maynard [mailto:robert.maynard at kitware.com] > Sent: Tuesday, August 22, 2017 9:46 AM > To: Miller Henry > Cc: cmake at cmake.org > Subject: Re: [CMake] target_link_libraries - private public interface rules > > You could look at extending the official CMake documentation, specifically the build system documentation ( https://cmake.org/cmake/help/v3.9/manual/cmake-buildsystem.7.html ). > > The documentation is all in restructure text and we accept documentation changes through our gitlab instance. > > cmake gitlab: https://gitlab.kitware.com/cmake/cmake > > build-system restructure page: > https://gitlab.kitware.com/cmake/cmake/blob/master/Help/manual/cmake-buildsystem.7.rst > > contribution guideline: > https://gitlab.kitware.com/cmake/cmake/blob/master/CONTRIBUTING.rst > > On Tue, Aug 22, 2017 at 9:44 AM, Miller Henry wrote: >> >> I?ve been playing with the private/public/interface keyword to >> target_link_libraries. It seems to me that WHAT they do is well >> documented, but nobody has ever actually documented what they correct >> rules of WHEN/WHY you should use any of them. After a lot of misstarts >> I think I?ve started to understand what the rules should be. I think >> they need to be written down someplace so that others don?t have to >> make the mistakes I have. Also it would be nice if others would look >> this list over to see what else might be overlooking. >> >> Can somebody point me to a good place to do this? Sending to the >> mailing list seems like a poor solution as corrections will not be easily findable. >> A wiki seems ideal, but which? KDE in particular should probably have >> these rules in their official requirements, but I?m not sure if they >> are the correct ones to own them. >> >> >> -- >> >> Powered by www.kitware.com >> >> Please keep messages on-topic and check the CMake FAQ at: >> http://www.cmake.org/Wiki/CMake_FAQ >> >> Kitware offers various services to support the CMake community. For >> more information on each offering, please visit: >> >> CMake Support: http://cmake.org/cmake/help/support.html >> CMake Consulting: http://cmake.org/cmake/help/consulting.html >> CMake Training Courses: http://cmake.org/cmake/help/training.html >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/cmake From brad.king at kitware.com Tue Aug 22 11:39:55 2017 From: brad.king at kitware.com (Brad King) Date: Tue, 22 Aug 2017 11:39:55 -0400 Subject: [CMake] target_link_libraries - private public interface rules In-Reply-To: References: <35F6921410093E4CA40D524BD5C18D4C3E1594B4@EDXMB89.jdnet.deere.com> <35F6921410093E4CA40D524BD5C18D4C3E1595A1@EDXMB89.jdnet.deere.com> Message-ID: <54613016-6ec6-27e9-9052-3e861e8c6517@kitware.com> On 08/22/2017 11:36 AM, Robert Maynard wrote: > The `Transitive Usage Requirements` section of the cmake-buildsystem > documentation quickly covers this idea but it could be elaborated on. > This might be a good place for a concrete example. Yes. Showing the transitive header case as an example would be good to show when a dependency should be PUBLIC instead of PRIVATE. -Brad From bitminer at gmail.com Tue Aug 22 12:00:57 2017 From: bitminer at gmail.com (Brian Davis) Date: Tue, 22 Aug 2017 11:00:57 -0500 Subject: [CMake] Interface Libraries allow include directories but not link directories.. Why? In-Reply-To: References: Message-ID: Upon further reflection the abs paths for every lib is absolutely not defensible. 1) Pass only the short lib name to target_link_libraries 2) Add absolute path to future target_link_directories if you must Then it's one (1) long path on the command line string and not N long paths fore each lib I seriously can't believe in 2017 I am actually having this conversation. Did I miss something here or does Kitware really mean to have package maintainers spec target_link_libraries( targ INTERFACE C:\projects\lib1\install\lib\lib1 ? C:\projects\lib1\install\lib\lib2 ? C:\projects\lib1\install\lib\lib3 ) and not ?target_link_libraries( targ INTERFACE lib1 lib2 lib3 ) target_link_directories( targ INTERFACE C:\projects\lib1\install\lib ) Does Kitware understand the length problem on command line tools and get the difference I am trying to convey here? As far as cmd line would go "one of these is not like the other", but would have same effect. If implemented for projs like ITK maybe I could build is a place other than C:\ -------------- next part -------------- An HTML attachment was scrubbed... URL: From bitminer at gmail.com Tue Aug 22 13:05:07 2017 From: bitminer at gmail.com (Brian Davis) Date: Tue, 22 Aug 2017 12:05:07 -0500 Subject: [CMake] Interface Libraries allow include directories but not link directories.. Why? In-Reply-To: References: Message-ID: and provide future ?target_link_directories( targ INTERFACE debug ${TOP}/build/x64/Debug/Libraries/ optimized ${TOP}/build/x64/Release/Libraries/ ) with debug / optimized / general capability then targets could support multiple debug / release dirs even if CMake (CMAKE_INSTALL_PREFIX) can't (ie no CMAKE_INSTALL_PREFIX_ capability) If anyone is looking at those dirs and wondering *why* (as I often do)... I need CMake in mixed mode with CMake generated projs and imported existing vcxproj files. if provided I could then targ link dirs, include dirs, and interface the libs from a position of relative sanity or at least the white jacket with wrap around arms tied in the back would be a little looser to the fit. -------------- next part -------------- An HTML attachment was scrubbed... URL: From julius.caro at gmail.com Tue Aug 22 13:17:31 2017 From: julius.caro at gmail.com (Luis Caro Campos) Date: Tue, 22 Aug 2017 18:17:31 +0100 Subject: [CMake] target_link_libraries - private public interface rules In-Reply-To: <54613016-6ec6-27e9-9052-3e861e8c6517@kitware.com> References: <35F6921410093E4CA40D524BD5C18D4C3E1594B4@EDXMB89.jdnet.deere.com> <35F6921410093E4CA40D524BD5C18D4C3E1595A1@EDXMB89.jdnet.deere.com> <54613016-6ec6-27e9-9052-3e861e8c6517@kitware.com> Message-ID: I think the documentation also fails to mention that link dependencies propagate even when "PRIVATE" is used, if the target is a static library. On 22 Aug 2017 4:40 pm, "Brad King" wrote: > On 08/22/2017 11:36 AM, Robert Maynard wrote: > > The `Transitive Usage Requirements` section of the cmake-buildsystem > > documentation quickly covers this idea but it could be elaborated on. > > This might be a good place for a concrete example. > > Yes. Showing the transitive header case as an example would be good > to show when a dependency should be PUBLIC instead of PRIVATE. > > -Brad > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/ > opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcdailey.lists at gmail.com Tue Aug 22 13:27:45 2017 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Tue, 22 Aug 2017 12:27:45 -0500 Subject: [CMake] CMake + Gradle for Android In-Reply-To: References: Message-ID: Another reason to reduce the number of binary directories is that there are different ways of managing third party libraries. One in particular that we use is to clone a repository into the binary directory and build all third party libs in real time based on a toolchain file (Similar to the functionality provided by ExternalProject module in CMake). This is repeated from scratch only if the work hasn't already been done in the binary directory before. By having more binary dirs than needed, this work is being done an exponential amount of times which can result in a lot of wasted time waiting. There are 1 time operations that multiple targets can benefit from in a single binary tree, instead of 1 per unique target being invoked. Sorry to keep responding: I'm just thinking of things as I go and bringing them up, to shed light on some of the reasoning behind my suggestions. On Tue, Aug 22, 2017 at 9:26 AM, Robert Dailey wrote: > Sorry I forgot to answer your last set of questions: > > CommonLib is indeed 2 things: > > * A common (static or shared) library for native code (most of our > CMake targets specify CommonLib as a link dependency) > * A common library for Java code (we do specify this as a dependency > for most java targets in Gradle, specifically those under > Applications/) > > On Mon, Aug 21, 2017 at 6:20 PM, Raymond Chiu wrote: >> Hi Robert, >> >> I work with Jom on the Android Studio team, and I would like to clarify a >> few things to better understand your situation. >> You mentioned the project is intend to be cross platform. Normally, in such >> situation, we expect there to be a single CMake root project to be imported >> into one of the Android library/application. However, in your case, there >> are subprojects with Java code. >> >> Are the CMake code in App1/2/3 intended to be cross platform too? Or are >> they Android specific code? If they are meant to be cross platform, how >> does the Java code works on other platforms? Or perhaps you added Java >> binding in those subprojects just for Android? >> >> The build.gradle in CommonLib, what kind of Gradle project is that? From >> your description, it doesn't look like an Android library project. Or am I >> mistaken and it also applies the android library plugin? >> >> Raymond >> >> On Mon, Aug 21, 2017 at 3:34 PM, Jom O'Fisher wrote: >>> >>> + a colleague >>> >>> On Mon, Aug 21, 2017 at 3:11 PM, Jom O'Fisher >>> wrote: >>>> >>>> You can find that number like this: >>>> - x = number of externalNativeBuild.cmake.path in your build.gradle files >>>> - y = number of gradle configurations (like debug and release) >>>> - z = number of ABIs that you build >>>> >>>> The result is x * y * z. To be more accurate, you should consider y and z >>>> to be functions of each build.gradle file since these can vary. >>>> >>>> There is a second set of folders that hold the stripped versions of the >>>> .so files that is purely managed by the android gradle plugin, so you might >>>> consider the answer to be 2 * x * y * z. >>>> >>>> Hope this helps. >>>> >>>> >>>> >>>> >>>> >>>> >>>> On Mon, Aug 21, 2017 at 2:41 PM, Robert Dailey >>>> wrote: >>>>> >>>>> This definitely a bit better, but still requires the boilerplate in >>>>> each leaf gradle file. But I can't seriously complain too much. I >>>>> think I'm more concerned with the implications this has underneath. >>>>> First, let me ask just to make sure I'm not misunderstanding: Does >>>>> each `externalNativeBuild` entry essentially mean 1 CMAKE_BINARY_DIR? >>>>> How many binary dirs do you manage internally and what determines when >>>>> they get created? >>>>> >>>>> On Mon, Aug 21, 2017 at 2:35 PM, Jom O'Fisher >>>>> wrote: >>>>> > Would it work for your scenario to provide properties in the root >>>>> > build.gradle: >>>>> > >>>>> > ext { >>>>> > cmakePath = file "CMakeLists.txt" >>>>> > } >>>>> > >>>>> > And then consume them in the leaf app/build.gradle like this? >>>>> > >>>>> > externalNativeBuild { >>>>> > cmake { >>>>> > path cmakePath >>>>> > } >>>>> > } >>>>> > >>>>> > It doesn't fully hide the details but it does centralize the >>>>> > information. >>>>> > >>>>> > >>>>> > On Mon, Aug 21, 2017 at 11:20 AM, Robert Dailey >>>>> > >>>>> > wrote: >>>>> >> >>>>> >> I wouldn't want to do that, it's too convoluted. I have other >>>>> >> platforms that use these CMake scripts as well. For example, I run on >>>>> >> Windows and Linux platforms as well to build the native code. Normal >>>>> >> CMake behavior is designed to work at a root then go downwards to >>>>> >> find >>>>> >> targets. However it seems Gradle wants to start at a subdirectory and >>>>> >> work its way up to the root, which is opposite of CMake's intended >>>>> >> behavior IMHO. Not only that but I want to avoid special-casing >>>>> >> behavior in CMake just for Android's use. >>>>> >> >>>>> >> At the moment it feels like (again referring back to my previous >>>>> >> example structure) that both App2 and App3 each run CMake in >>>>> >> independent binary directories instead of sharing 1 binary directory >>>>> >> and building 2 targets inside of it. I prefer this behavior instead, >>>>> >> especially since it allows CMake to operate as it was intended. I >>>>> >> think it's a common case that projects will define multiple targets >>>>> >> starting from a single root, and expect multiple APKs or java >>>>> >> dependencies to be built within it. >>>>> >> >>>>> >> If I'm misunderstanding or making false assumptions please let me >>>>> >> know. >>>>> >> >>>>> >> >>>>> >> >>>>> >> On Mon, Aug 21, 2017 at 12:00 PM, Jom O'Fisher >>>>> >> wrote: >>>>> >> > Would it work for your situation for the leaf CMakeLists.txt to >>>>> >> > include >>>>> >> > the >>>>> >> > root CMakeLists.txt? Then have the leaf-specific logic in the leaf >>>>> >> > CMakeLists.txt? >>>>> >> > >>>>> >> > >>>>> >> > >>>>> >> > On Mon, Aug 21, 2017 at 9:33 AM, Robert Dailey >>>>> >> > >>>>> >> > wrote: >>>>> >> >> >>>>> >> >> Basically, yes. We have this sort of structure: >>>>> >> >> >>>>> >> >> / >>>>> >> >> Applications/ >>>>> >> >> App1/ >>>>> >> >> build.gradle >>>>> >> >> CMakeLists.txt >>>>> >> >> App2/ >>>>> >> >> build.gradle >>>>> >> >> CMakeLists.txt >>>>> >> >> App3/ >>>>> >> >> build.gradle >>>>> >> >> CMakeLists.txt >>>>> >> >> CommonLib/ >>>>> >> >> build.gradle >>>>> >> >> CMakeLists.txt >>>>> >> >> CMakeLists.txt >>>>> >> >> >>>>> >> >> The libs are defined as follows: >>>>> >> >> >>>>> >> >> * CommonLib is a static library (java code builds into a library) >>>>> >> >> * No dependencies of its own >>>>> >> >> * App1 is a shared library (java code builds into a library) >>>>> >> >> * Dependencies (both java & native): CommonLib >>>>> >> >> * App2 is a shared library (java code builds into an APK) >>>>> >> >> * Dependencies (both java & native): App1, CommonLib >>>>> >> >> * App3 is a shared library (java code builds into an APK) >>>>> >> >> * Dependencies (both java & native): CommonLib >>>>> >> >> >>>>> >> >> In all cases, CMake must be invoked starting at the root >>>>> >> >> CMakeLists.txt 1 time. Each target can be built from the same >>>>> >> >> binary >>>>> >> >> directory after that. Previously with ANT, I was building all >>>>> >> >> native >>>>> >> >> targets first, then moved libs to appropriate directories so that >>>>> >> >> the >>>>> >> >> 'ant' command would package the libs. >>>>> >> >> >>>>> >> >> For gradle, I wanted to avoid redundantly specifying the root >>>>> >> >> directory in each leaf-level project directory. Using the example >>>>> >> >> above, the leaf-level directories in this case would be App1, >>>>> >> >> App2, >>>>> >> >> App3, and CommonLib. However I think we only specify the native >>>>> >> >> CMake >>>>> >> >> stuff for the java targets that actually output an APK (that would >>>>> >> >> be >>>>> >> >> App2 and App3 only). >>>>> >> >> >>>>> >> >> The ultimate goal is to specify stuff that doesn't change per >>>>> >> >> independent "module" of ours at the top level so it is transitive >>>>> >> >> / >>>>> >> >> inherited. Then only specify the differences (e.g. the native >>>>> >> >> CMake >>>>> >> >> target to build) in the leaf build gradle files. However you >>>>> >> >> indicated >>>>> >> >> this isn't possible. >>>>> >> >> >>>>> >> >> >>>>> >> >> >>>>> >> >> On Mon, Aug 21, 2017 at 11:11 AM, Jom O'Fisher >>>>> >> >> >>>>> >> >> wrote: >>>>> >> >> > What you're doing already sounds correct. You can't directly >>>>> >> >> > specify >>>>> >> >> > CMakeLists.txt from the top-level build.gradle. Recommendation >>>>> >> >> > is >>>>> >> >> > that >>>>> >> >> > it >>>>> >> >> > should be specified from the build.gradle of the module of the >>>>> >> >> > APK. >>>>> >> >> > Is >>>>> >> >> > the >>>>> >> >> > issue that you have multiple APK modules that all reference the >>>>> >> >> > same >>>>> >> >> > CMake >>>>> >> >> > libraries? >>>>> >> >> > >>>>> >> >> > On Mon, Aug 21, 2017 at 9:00 AM, Robert Dailey >>>>> >> >> > >>>>> >> >> > wrote: >>>>> >> >> >> >>>>> >> >> >> Thanks this is very helpful. The other question I have is: Is >>>>> >> >> >> there >>>>> >> >> >> a >>>>> >> >> >> place to centrally specify the root CMakeLists.txt? Basically, >>>>> >> >> >> I >>>>> >> >> >> want >>>>> >> >> >> to specify the CMake root in 1 place, and have targets (defined >>>>> >> >> >> further down in subdirectories) that require APK packaging to >>>>> >> >> >> specify >>>>> >> >> >> only the native target name that should be built & packaged. >>>>> >> >> >> >>>>> >> >> >> At the moment we specify the root CMakeLists.txt by walking up >>>>> >> >> >> the >>>>> >> >> >> tree, paths like "../../../../CMakeLists.txt". I think this >>>>> >> >> >> should >>>>> >> >> >> be >>>>> >> >> >> put at the top-level build gradle file if possible. Is this >>>>> >> >> >> doable >>>>> >> >> >> at >>>>> >> >> >> the moment? What is the recommended setup? >>>>> >> >> >> >>>>> >> >> >> On Mon, Aug 21, 2017 at 9:37 AM, Jom O'Fisher >>>>> >> >> >> >>>>> >> >> >> wrote: >>>>> >> >> >> > Gradle does introspection on the CMake build to find .so >>>>> >> >> >> > targets >>>>> >> >> >> > and >>>>> >> >> >> > those >>>>> >> >> >> > get packaged. >>>>> >> >> >> > There is also a special case for stl/runtime .so files from >>>>> >> >> >> > the >>>>> >> >> >> > NDK. >>>>> >> >> >> > Any additional .so files need to specified in build.gradle >>>>> >> >> >> > using >>>>> >> >> >> > jniDirs >>>>> >> >> >> > >>>>> >> >> >> > On Mon, Aug 21, 2017 at 7:30 AM, Robert Dailey >>>>> >> >> >> > >>>>> >> >> >> > wrote: >>>>> >> >> >> >> >>>>> >> >> >> >> How exactly does Gradle package *.so files in an APK? I know >>>>> >> >> >> >> that >>>>> >> >> >> >> ANT >>>>> >> >> >> >> used to do this for any libs under "libs/". Does Gradle >>>>> >> >> >> >> do >>>>> >> >> >> >> some >>>>> >> >> >> >> introspection into CMake targets to see if outputs are *.so, >>>>> >> >> >> >> and >>>>> >> >> >> >> copy >>>>> >> >> >> >> those to some location if needed? What about libraries like >>>>> >> >> >> >> libgnustl_shared.so that come with the NDK? I'd like to know >>>>> >> >> >> >> if >>>>> >> >> >> >> any >>>>> >> >> >> >> manual copy steps are needed in CMake to put outputs in >>>>> >> >> >> >> proper >>>>> >> >> >> >> locations for the APK build step. I had to do this when >>>>> >> >> >> >> using >>>>> >> >> >> >> ANT. >>>>> >> >> >> >> >>>>> >> >> >> >> On Mon, Aug 7, 2017 at 6:16 PM, Jom O'Fisher >>>>> >> >> >> >> >>>>> >> >> >> >> wrote: >>>>> >> >> >> >> > 1) There is a folder created for each ABI under the >>>>> >> >> >> >> > project >>>>> >> >> >> >> > module >>>>> >> >> >> >> > folder >>>>> >> >> >> >> > (so unique per module per ABI) >>>>> >> >> >> >> > 2) Gradle doesn't specify language level though you can >>>>> >> >> >> >> > choose >>>>> >> >> >> >> > to >>>>> >> >> >> >> > specify it >>>>> >> >> >> >> > yourself from the build.gradle. This doc does a pretty >>>>> >> >> >> >> > good job >>>>> >> >> >> >> > of >>>>> >> >> >> >> > explaining which variables are set by Gradle: >>>>> >> >> >> >> > >>>>> >> >> >> >> > https://developer.android.com/ndk/guides/cmake.html#variables. >>>>> >> >> >> >> > Philosophically, we try to set as little as we can get >>>>> >> >> >> >> > away >>>>> >> >> >> >> > with. >>>>> >> >> >> >> > In >>>>> >> >> >> >> > particular, the section titled "Understanding the CMake >>>>> >> >> >> >> > build >>>>> >> >> >> >> > command" >>>>> >> >> >> >> > lays >>>>> >> >> >> >> > out exactly what we set. You can also see the folders we >>>>> >> >> >> >> > specify >>>>> >> >> >> >> > (one >>>>> >> >> >> >> > per >>>>> >> >> >> >> > module per ABI) >>>>> >> >> >> >> > 3) Not sure I understand this. >>>>> >> >> >> >> > >>>>> >> >> >> >> > The other document worth taking a look at (if you haven't >>>>> >> >> >> >> > already) >>>>> >> >> >> >> > is: >>>>> >> >> >> >> > >>>>> >> >> >> >> > >>>>> >> >> >> >> > https://developer.android.com/studio/projects/add-native-code.html >>>>> >> >> >> >> > >>>>> >> >> >> >> > >>>>> >> >> >> >> > On Mon, Aug 7, 2017 at 3:35 PM, Robert Dailey >>>>> >> >> >> >> > >>>>> >> >> >> >> > wrote: >>>>> >> >> >> >> >> >>>>> >> >> >> >> >> Thanks Jom >>>>> >> >> >> >> >> >>>>> >> >> >> >> >> Honestly, I prefer option 1 to work simply because that's >>>>> >> >> >> >> >> how >>>>> >> >> >> >> >> Google's >>>>> >> >> >> >> >> officially supporting CMake. But it also has debugging >>>>> >> >> >> >> >> which >>>>> >> >> >> >> >> is >>>>> >> >> >> >> >> the >>>>> >> >> >> >> >> #1 >>>>> >> >> >> >> >> reason for me. >>>>> >> >> >> >> >> >>>>> >> >> >> >> >> However, I'd like to understand a lot more about how the >>>>> >> >> >> >> >> integration >>>>> >> >> >> >> >> really happens. For example, I have these questions: >>>>> >> >> >> >> >> >>>>> >> >> >> >> >> 1) How, internally, are CMake build directories managed? >>>>> >> >> >> >> >> Do >>>>> >> >> >> >> >> you >>>>> >> >> >> >> >> generate 1 per unique android project? What about for >>>>> >> >> >> >> >> each >>>>> >> >> >> >> >> specific >>>>> >> >> >> >> >> platform (x86, armeabi-v7a, etc)? >>>>> >> >> >> >> >> 2) Last time I looked into CMake integration, things >>>>> >> >> >> >> >> defined >>>>> >> >> >> >> >> inside >>>>> >> >> >> >> >> the CMake scripts were ignored because they are specified >>>>> >> >> >> >> >> at >>>>> >> >> >> >> >> the >>>>> >> >> >> >> >> command line. Namely, all of those settings that are >>>>> >> >> >> >> >> driven by >>>>> >> >> >> >> >> the >>>>> >> >> >> >> >> Gradle configuration (CXX language level was one in >>>>> >> >> >> >> >> particular >>>>> >> >> >> >> >> I >>>>> >> >> >> >> >> think; I specify C++14 support via CMake, but I recall >>>>> >> >> >> >> >> this >>>>> >> >> >> >> >> being >>>>> >> >> >> >> >> overridden from outside)? >>>>> >> >> >> >> >> 3) How redundant is it to configure individual libraries >>>>> >> >> >> >> >> via >>>>> >> >> >> >> >> the >>>>> >> >> >> >> >> gradle scripts? In my previous attempts, I wanted to >>>>> >> >> >> >> >> define >>>>> >> >> >> >> >> common >>>>> >> >> >> >> >> stuff for CMake / native code at the root gradle or >>>>> >> >> >> >> >> settings >>>>> >> >> >> >> >> file, >>>>> >> >> >> >> >> and >>>>> >> >> >> >> >> only define the differences in the actual gradle build >>>>> >> >> >> >> >> files >>>>> >> >> >> >> >> for >>>>> >> >> >> >> >> each >>>>> >> >> >> >> >> corresponding Java target (like, defining the name of the >>>>> >> >> >> >> >> native >>>>> >> >> >> >> >> (shared library) target in Gradle, but the command line >>>>> >> >> >> >> >> invocation, >>>>> >> >> >> >> >> -D >>>>> >> >> >> >> >> CMake settings, etc would all be common and defined at >>>>> >> >> >> >> >> the >>>>> >> >> >> >> >> root). >>>>> >> >> >> >> >> >>>>> >> >> >> >> >> The TLDR is, the closer we can stay to CMake's way of >>>>> >> >> >> >> >> doing >>>>> >> >> >> >> >> things >>>>> >> >> >> >> >> and >>>>> >> >> >> >> >> keep CMake-related settings self-contained to the CMake >>>>> >> >> >> >> >> scripts >>>>> >> >> >> >> >> themselves, the better. This also makes cross-platform >>>>> >> >> >> >> >> easier >>>>> >> >> >> >> >> (we >>>>> >> >> >> >> >> build the native code in Windows, for example, so having >>>>> >> >> >> >> >> settings >>>>> >> >> >> >> >> specified in the gradle files do not carry over to other >>>>> >> >> >> >> >> platforms. >>>>> >> >> >> >> >> Namely, settings that are not platform specific like the >>>>> >> >> >> >> >> C++ >>>>> >> >> >> >> >> language >>>>> >> >> >> >> >> level). >>>>> >> >> >> >> >> >>>>> >> >> >> >> >> If there's a detailed document / wiki I can read on the >>>>> >> >> >> >> >> intrinsics >>>>> >> >> >> >> >> of >>>>> >> >> >> >> >> CMake integration in Gradle / Android Studio, I'd love to >>>>> >> >> >> >> >> read >>>>> >> >> >> >> >> it. >>>>> >> >> >> >> >> Otherwise, I hope you won't mind if I pick your brain as >>>>> >> >> >> >> >> questions >>>>> >> >> >> >> >> come up. I think I'm going to try option 1 for now and >>>>> >> >> >> >> >> see how >>>>> >> >> >> >> >> it >>>>> >> >> >> >> >> goes. It's just black box for me because unlike option 2, >>>>> >> >> >> >> >> I >>>>> >> >> >> >> >> have >>>>> >> >> >> >> >> very >>>>> >> >> >> >> >> little control over what happens after building the >>>>> >> >> >> >> >> shared >>>>> >> >> >> >> >> libraries, >>>>> >> >> >> >> >> and to make up for that I need to really get a deep >>>>> >> >> >> >> >> understanding >>>>> >> >> >> >> >> of >>>>> >> >> >> >> >> how it works so I can make sure I code my CMake scripts >>>>> >> >> >> >> >> properly >>>>> >> >> >> >> >> for >>>>> >> >> >> >> >> not only Android, but my other platforms as well >>>>> >> >> >> >> >> (non-Android >>>>> >> >> >> >> >> platforms). >>>>> >> >> >> >> >> >>>>> >> >> >> >> >> Thanks again. >>>>> >> >> >> >> >> >>>>> >> >> >> >> >> On Mon, Aug 7, 2017 at 5:12 PM, Jom O'Fisher >>>>> >> >> >> >> >> >>>>> >> >> >> >> >> wrote: >>>>> >> >> >> >> >> > Either option can work fine. Disclosure: I work on >>>>> >> >> >> >> >> > Android >>>>> >> >> >> >> >> > Studio >>>>> >> >> >> >> >> > and >>>>> >> >> >> >> >> > was >>>>> >> >> >> >> >> > the one that added CMake support. >>>>> >> >> >> >> >> > >>>>> >> >> >> >> >> > Option (1) is the way it's designed to work and we're >>>>> >> >> >> >> >> > working >>>>> >> >> >> >> >> > toward >>>>> >> >> >> >> >> > getting >>>>> >> >> >> >> >> > rid of the need for the CMake fork. I can't really say >>>>> >> >> >> >> >> > when >>>>> >> >> >> >> >> > that >>>>> >> >> >> >> >> > will >>>>> >> >> >> >> >> > happen >>>>> >> >> >> >> >> > but if you can get away with an older CMake for now >>>>> >> >> >> >> >> > then I'd >>>>> >> >> >> >> >> > go >>>>> >> >> >> >> >> > this >>>>> >> >> >> >> >> > way. >>>>> >> >> >> >> >> > As you mentioned, option (1) will allow you to view >>>>> >> >> >> >> >> > your >>>>> >> >> >> >> >> > source >>>>> >> >> >> >> >> > file >>>>> >> >> >> >> >> > structure in Android Studio, edit files, and debug >>>>> >> >> >> >> >> > using the >>>>> >> >> >> >> >> > built-in >>>>> >> >> >> >> >> > debugging support. >>>>> >> >> >> >> >> > >>>>> >> >> >> >> >> > To get option (2) to work, you can use jniDirs setting >>>>> >> >> >> >> >> > to >>>>> >> >> >> >> >> > tell >>>>> >> >> >> >> >> > Android >>>>> >> >> >> >> >> > Gradle where to pick up your built .so files (see >>>>> >> >> >> >> >> > >>>>> >> >> >> >> >> > >>>>> >> >> >> >> >> > >>>>> >> >> >> >> >> > >>>>> >> >> >> >> >> > >>>>> >> >> >> >> >> > >>>>> >> >> >> >> >> > https://stackoverflow.com/questions/21255125/how-can-i-add-so-files-to-an-android-library-project-using-gradle-0-7). >>>>> >> >> >> >> >> > I'm not aware of any projects that use this approach >>>>> >> >> >> >> >> > but it >>>>> >> >> >> >> >> > should >>>>> >> >> >> >> >> > work >>>>> >> >> >> >> >> > in >>>>> >> >> >> >> >> > principal. >>>>> >> >> >> >> >> > >>>>> >> >> >> >> >> > I hope this helps, >>>>> >> >> >> >> >> > Jomo >>>>> >> >> >> >> >> > >>>>> >> >> >> >> >> > >>>>> >> >> >> >> >> > On Mon, Aug 7, 2017 at 11:09 AM, Robert Dailey >>>>> >> >> >> >> >> > >>>>> >> >> >> >> >> > wrote: >>>>> >> >> >> >> >> >> >>>>> >> >> >> >> >> >> Right now I have custom targets set to execute the >>>>> >> >> >> >> >> >> "ant >>>>> >> >> >> >> >> >> release" >>>>> >> >> >> >> >> >> command after my native targets are built. Part of >>>>> >> >> >> >> >> >> that >>>>> >> >> >> >> >> >> command >>>>> >> >> >> >> >> >> involves copying *.so files to the libs/armeabi-v7a >>>>> >> >> >> >> >> >> directory >>>>> >> >> >> >> >> >> so >>>>> >> >> >> >> >> >> they >>>>> >> >> >> >> >> >> get packaged in an APK. >>>>> >> >> >> >> >> >> >>>>> >> >> >> >> >> >> When switching to gradle, I have two options: >>>>> >> >> >> >> >> >> >>>>> >> >> >> >> >> >> 1. Gradle drives CMake: This means using Android >>>>> >> >> >> >> >> >> Studio and >>>>> >> >> >> >> >> >> being >>>>> >> >> >> >> >> >> locked down to Google's fork of CMake which is a few >>>>> >> >> >> >> >> >> major >>>>> >> >> >> >> >> >> releases >>>>> >> >> >> >> >> >> behind. I see that as a negative. >>>>> >> >> >> >> >> >> >>>>> >> >> >> >> >> >> 2. CMake drives Gradle: This would be the same or >>>>> >> >> >> >> >> >> similar >>>>> >> >> >> >> >> >> to >>>>> >> >> >> >> >> >> what >>>>> >> >> >> >> >> >> I'm >>>>> >> >> >> >> >> >> already doing: The custom targets I have would execute >>>>> >> >> >> >> >> >> gradle >>>>> >> >> >> >> >> >> as >>>>> >> >> >> >> >> >> a >>>>> >> >> >> >> >> >> separate build step, instead of running ant commands. >>>>> >> >> >> >> >> >> I'm >>>>> >> >> >> >> >> >> not >>>>> >> >> >> >> >> >> too >>>>> >> >> >> >> >> >> familiar with Gradle, so I'm not sure how you tell it >>>>> >> >> >> >> >> >> where >>>>> >> >> >> >> >> >> your >>>>> >> >> >> >> >> >> shared libraries are for the APK packaging steps. >>>>> >> >> >> >> >> >> >>>>> >> >> >> >> >> >> Which does everyone recommend? Is anyone using one of >>>>> >> >> >> >> >> >> these >>>>> >> >> >> >> >> >> setups >>>>> >> >> >> >> >> >> successfully? The downside to option 2 is probably no >>>>> >> >> >> >> >> >> on-device >>>>> >> >> >> >> >> >> native >>>>> >> >> >> >> >> >> debugging since Android Studio probably can't handle >>>>> >> >> >> >> >> >> gradle >>>>> >> >> >> >> >> >> projects >>>>> >> >> >> >> >> >> without any external CMake builds set up. >>>>> >> >> >> >> >> >> >>>>> >> >> >> >> >> >> Would like some general direction & advice before I >>>>> >> >> >> >> >> >> move >>>>> >> >> >> >> >> >> away >>>>> >> >> >> >> >> >> from >>>>> >> >> >> >> >> >> ANT. Thanks in advance. >>>>> >> >> >> >> >> >> -- >>>>> >> >> >> >> >> >> >>>>> >> >> >> >> >> >> Powered by www.kitware.com >>>>> >> >> >> >> >> >> >>>>> >> >> >> >> >> >> Please keep messages on-topic and check the CMake FAQ >>>>> >> >> >> >> >> >> at: >>>>> >> >> >> >> >> >> http://www.cmake.org/Wiki/CMake_FAQ >>>>> >> >> >> >> >> >> >>>>> >> >> >> >> >> >> Kitware offers various services to support the CMake >>>>> >> >> >> >> >> >> community. >>>>> >> >> >> >> >> >> For >>>>> >> >> >> >> >> >> more >>>>> >> >> >> >> >> >> information on each offering, please visit: >>>>> >> >> >> >> >> >> >>>>> >> >> >> >> >> >> CMake Support: >>>>> >> >> >> >> >> >> http://cmake.org/cmake/help/support.html >>>>> >> >> >> >> >> >> CMake Consulting: >>>>> >> >> >> >> >> >> http://cmake.org/cmake/help/consulting.html >>>>> >> >> >> >> >> >> CMake Training Courses: >>>>> >> >> >> >> >> >> http://cmake.org/cmake/help/training.html >>>>> >> >> >> >> >> >> >>>>> >> >> >> >> >> >> Visit other Kitware open-source projects at >>>>> >> >> >> >> >> >> http://www.kitware.com/opensource/opensource.html >>>>> >> >> >> >> >> >> >>>>> >> >> >> >> >> >> Follow this link to subscribe/unsubscribe: >>>>> >> >> >> >> >> >> http://public.kitware.com/mailman/listinfo/cmake >>>>> >> >> >> >> >> > >>>>> >> >> >> >> >> > >>>>> >> >> >> >> > >>>>> >> >> >> >> > >>>>> >> >> >> > >>>>> >> >> >> > >>>>> >> >> > >>>>> >> >> > >>>>> >> > >>>>> >> > >>>>> > >>>>> > >>>> >>>> >>> >> From lectem at gmail.com Tue Aug 22 13:42:46 2017 From: lectem at gmail.com (=?UTF-8?Q?Cl=C3=A9ment_Gregoire?=) Date: Tue, 22 Aug 2017 17:42:46 +0000 Subject: [CMake] Interface Libraries allow include directories but not link directories.. Why? In-Reply-To: References: Message-ID: No you're not meant to specify paths yourself, you should just use find_library. Check how modules such as FindTIFF.cmake are implemented. Le mar. 22 ao?t 2017 ? 19:05, Brian Davis a ?crit : > > and provide future > > ?target_link_directories( > targ > INTERFACE > debug ${TOP}/build/x64/Debug/Libraries/ > optimized ${TOP}/build/x64/Release/Libraries/ > ) > > with debug / optimized / general capability > > then targets could support multiple debug / release dirs even if CMake > (CMAKE_INSTALL_PREFIX) can't (ie no CMAKE_INSTALL_PREFIX_ > capability) > > If anyone is looking at those dirs and wondering *why* (as I often do)... > I need CMake in mixed mode with CMake generated projs and imported existing > vcxproj files. > > if provided I could then targ link dirs, include dirs, and interface the > libs from a position of relative sanity or at least the white jacket with > wrap around arms tied in the back would be a little looser to the fit. > > > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.tmatma at gmail.com Tue Aug 22 18:34:33 2017 From: m.tmatma at gmail.com (masaru tsuchiyama) Date: Tue, 22 Aug 2017 22:34:33 +0000 Subject: [CMake] 'cmake.exe -G Ninja' doesn't work for VS2017 with cmake ver 3.9.1 In-Reply-To: References: <84ce2ae4-99d2-c3d4-8bb0-82131019aa76@gmail.com> <6ddc295f-8cda-2f64-e6c2-3e33ec529e94@gmail.com> Message-ID: Hello I'm busy today. So I'll try tomorrow or the day after tomorrow. Regards Masaru. 2017?8?23?(?) 0:36 Brad King : > On 08/21/2017 05:56 PM, masaru tsuchiyama wrote: > >> https://gitlab.kitware.com/cmake/cmake/issues/17191 > > I think it is same as the issue. > > I use Japanese version of Win10 Pro. > > Thanks. Unfortunately I've not been able to reproduce it. > See discussion in the issue. > > Since you have a local build you used for bisecting this, might you be > able to debug it? > > The `rules.ninja` file is likely missing due to `codecvt::do_out` > in `Source/cm_codecvt.cxx` returning `std::codecvt_base::error` > somewhere, causing the stream state to be bad so cmGeneratedFileStream > doesn't rename the temporary file to its final place. > > Thanks, > -Brad > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bitminer at gmail.com Tue Aug 22 20:14:08 2017 From: bitminer at gmail.com (Brian Davis) Date: Tue, 22 Aug 2017 19:14:08 -0500 Subject: [CMake] Interface Libraries allow include directories but not link directories.. Why? In-Reply-To: References: Message-ID: On Tue, Aug 22, 2017 at 12:42 PM, Cl?ment Gregoire wrote: > No you're not meant to specify paths yourself, you should just use > find_library. > Check how modules such as FindTIFF.cmake are implemented. > Please doc in CMake all the things I am "meant to" so as I can live inside that happy little bubble world. Did I not just provide a perfectly rational reason why a crazed end user may want set lib path... err.... themselves /LIBPATH: is there for a reason in the compiler / linker sadly it appears CMake does not get this. Clearly like the toolchain developers thought it was a good idea... hmm wonder it it had anything to do with the command line length problem? Ahh yes must be a pesky little throwback from the days of yore. Full paths eureka! Nope not buying it. It appears CMake wants to save me from myself by not allowing me to set LIBPATH. I mean do I got this right? If so who's going to save CMake from themselves? Hey why not completely save me from myself and take away target_include_directories. I find find_library (I tried it and had in the past) still yields full path for every library even if multiple libs are in same dir and is even documented as such: https://cmake.org/cmake/help/latest/command/find_library.html?highlight=find_library "If the library found is a framework, then will be set to the full path to the framework /A.framework. When a full path to a framework is used as a library, CMake will use a -framework A, and a -F to link the framework to the target." When these full lib dirs are chucked at the linker .... kerpow... if large paths are used where project is located. But hey if find_library or whatever insanity I should use would say use a parameterized variable other than what is currently: find_library( MY_LIB_DEBUG NAMES 4DFUtilities.lib HINTS C:/projects/4DRTProto/4DRTProto/build/x64/Debug ) FUORO4D_UTILITY_LIB_DEBUG = C:/projects/4DRTProto/4DRTProto/build/x64/Debug/Libraries/4DFUtilities.lib but rather generate a paramaterized version: FUORO4D_UTILITY_LIB_DEBUG = "LIBRARY_NAME;4DFUtilities.lib;LINK_DIRECTORY;C:/projects/4DRTProto/4DRTProto/build/x64/Debug/Libraries" (above is goop I have had to resort to in CMake and VARARG macros for some resemblance of inherited build properties prior to interface libraries) Then prior to command generation for linker *could* through the power of filtering for unique strings search all those LINK_DIRECTORY paths specifications and retain unique and set that crazy elusive, never to be gazed upon by human eyes, it-who-must-not-be-named /LIBPATH flag. Doesn't that little cursor have enough to do with out dancing all over the place printing out full paths to libraries... I mean give the little bugger a break will ya! Let me be clear. There are two problems here: 1) Abs paths to link libraries causing command line length issues such as in ITK 2) Inability to set lib dirs at target resolution. find_library which is suggested a solution to this could be *if* it did not force abs paths to libs and would rather gather up unique full paths and set /LIBPATH There may only be one problem here. If find_library worked as I suggest then there would be zero problems here... with the exception that CMAKE_VARIABLES such as what find_library generates are so 2.8.12 (ref: https://github.com/boostcon/cppnow_presentations_2017/blob/master/05-19-2017_friday/effective_cmake__daniel_pfeifer__cppnow_05-19-2017.pdf) and not "Targets" and "Properties" which if we had target_link_directories... would be! (CMake could even add find capability if desired) As per my new sense of sensibilities in the new CMake era frankly I find find_library to be the old backwards way of doing this... not that it does it correctly in the first pace... never has. And don't get me started on the FindWhatevers and CMake Packaging ... ohhh that's coming! Consider that worm can open.... I have already started to post some bits on that insanity, the lack of direction and features in CMake (project VERSION not appending to CMAKE_INSTALL_PREFIX so as not to blast away prior installed versions), inconsistent CMake documentation (lack of lib and include dir versioning and standard location of where to put .cmake package files), and 3rd party package devs do whatever they want mantra, and the end user experience. If CMake really wants to save me... save me from the 3rd party package developers miss use of CMake by fixing and better documenting CMake. 3rd party package devs only do what they think is right and what they can get away with based on poor doc and impl. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lectem at gmail.com Wed Aug 23 03:07:03 2017 From: lectem at gmail.com (=?UTF-8?Q?Cl=C3=A9ment_Gregoire?=) Date: Wed, 23 Aug 2017 07:07:03 +0000 Subject: [CMake] Interface Libraries allow include directories but not link directories.. Why? In-Reply-To: References: Message-ID: I can't argue too much why paths or absolute on cmake as I don't know the rationale behind it is. While your point about command line limit makes sense, I feel like a system limiting command line size to this extent is dumb if it doesn't allow reading more arguments through a file. (again, I don't know the system at all). I kinda understand your point about not being able to set the libdir per target but (might have missed it in your previous mails) I don't know what kind of project would need that. At best I would need one version of the library per configuration, which is supported. I entirely agree with for the rest. CMake badly documenting good practices or even giving tutorials is an issue. Probably the biggest issue I found. I myself still fight after years of using and experimenting with it. This lead to a plethora of badly written cmakelists.txt or module scripts, that even people in this list still advocates without understanding the problems behind it. Even some tutorial series found on github.com or used by coverage websites do it wrong. At the moment the only reference I trust is Daniel's presentation and some of the internal cmake scripts. While not solving your problem, I documented most of my findings in this small template /reference https://github.com/Lectem/cpp-boilerplate (which might still do things the wrong way) Le mer. 23 ao?t 2017 ? 02:14, Brian Davis a ?crit : > On Tue, Aug 22, 2017 at 12:42 PM, Cl?ment Gregoire > wrote: > >> No you're not meant to specify paths yourself, you should just use >> find_library. >> Check how modules such as FindTIFF.cmake are implemented. >> > > Please doc in CMake all the things I am "meant to" so as I can live inside > that happy little bubble world. > > Did I not just provide a perfectly rational reason why a crazed end user > may want set lib path... err.... themselves > > /LIBPATH: is there for a reason in the compiler / linker sadly it appears > CMake does not get this. Clearly like the toolchain developers thought it > was a good idea... hmm wonder it it had anything to do with the command > line length problem? Ahh yes must be a pesky little throwback from the > days of yore. Full paths eureka! Nope not buying it. > > It appears CMake wants to save me from myself by not allowing me to set > LIBPATH. I mean do I got this right? If so who's going to save CMake from > themselves? > > Hey why not completely save me from myself and take away > target_include_directories. > > I find find_library (I tried it and had in the past) still yields full > path for every library even if multiple libs are in same dir and is even > documented as such: > > > https://cmake.org/cmake/help/latest/command/find_library.html?highlight=find_library > > "If the library found is a framework, then will be set to the full > path to the framework /A.framework. When a full path to a > framework is used as a library, CMake will use a -framework A, and a > -F to link the framework to the target." > > When these full lib dirs are chucked at the linker .... kerpow... if large > paths are used where project is located. > > > But hey if find_library or whatever insanity I should use would say use a > parameterized variable other than what is currently: > > find_library( > MY_LIB_DEBUG > NAMES 4DFUtilities.lib > HINTS C:/projects/4DRTProto/4DRTProto/build/x64/Debug > ) > > FUORO4D_UTILITY_LIB_DEBUG = > C:/projects/4DRTProto/4DRTProto/build/x64/Debug/Libraries/4DFUtilities.lib > > but rather generate a paramaterized version: > > FUORO4D_UTILITY_LIB_DEBUG = > "LIBRARY_NAME;4DFUtilities.lib;LINK_DIRECTORY;C:/projects/4DRTProto/4DRTProto/build/x64/Debug/Libraries" > > (above is goop I have had to resort to in > CMake and VARARG macros for some resemblance of inherited build properties > prior to interface libraries) > > Then prior to command generation for linker *could* through the power of > filtering for unique strings search all those LINK_DIRECTORY paths > specifications and retain unique and set that crazy elusive, never to be > gazed upon by human eyes, it-who-must-not-be-named /LIBPATH flag. Doesn't > that little cursor have enough to do with out dancing all over the place > printing out full paths to libraries... I mean give the little bugger a > break will ya! > > Let me be clear. There are two problems here: > > 1) Abs paths to link libraries causing command line length issues such as > in ITK > 2) Inability to set lib dirs at target resolution. find_library which is > suggested a solution to this could be *if* it did not force abs paths to > libs and would rather gather up unique full paths and set /LIBPATH > > There may only be one problem here. If find_library worked as I suggest > then there would be zero problems here... with the exception that > CMAKE_VARIABLES such as what find_library generates are so 2.8.12 (ref: > https://github.com/boostcon/cppnow_presentations_2017/blob/master/05-19-2017_friday/effective_cmake__daniel_pfeifer__cppnow_05-19-2017.pdf) > and not "Targets" and "Properties" which if we had > target_link_directories... would be! (CMake could even add find capability > if desired) As per my new sense of sensibilities in the new CMake era > frankly I find find_library to be the old backwards way of doing this... > not that it does it correctly in the first pace... never has. > > And don't get me started on the FindWhatevers and CMake Packaging ... ohhh > that's coming! Consider that worm can open.... I have already started to > post some bits on that insanity, the lack of direction and features in > CMake (project VERSION not appending to CMAKE_INSTALL_PREFIX so as not to > blast away prior installed versions), inconsistent CMake documentation > (lack of lib and include dir versioning and standard location of where to > put .cmake package files), and 3rd party package devs do whatever they > want mantra, and the end user experience. If CMake really wants to save > me... save me from the 3rd party package developers miss use of CMake by > fixing and better documenting CMake. 3rd party package devs only do what > they think is right and what they can get away with based on poor doc and > impl. > > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake -------------- next part -------------- An HTML attachment was scrubbed... URL: From oelbox at gmail.com Wed Aug 23 04:55:55 2017 From: oelbox at gmail.com (Arne Kjetil Andersen) Date: Wed, 23 Aug 2017 10:55:55 +0200 Subject: [CMake] CMake, Mingw-w64 32 bit exception handling. Message-ID: Greetings. I'm a developer on a fairly large project where I'm using CMake version 3.9.1 I primarily work on linux, but also cross compiles for windows using Mingw-w64 on my linux box. I have encountered an issue which I'm having some trouble figuring out. Running through some of my tests where an exception is thrown (on purpose) the 32 bit version compiled with Mingw-w64-g++ version 7.1.1 just calls terminate even though there are try catch blocks. Now mind you, this all works fine on the native linux compiled version of my tests, and also the 64 bit windows version compiled with Mingw-w64-g++ version 7.1.1. Going through all the projects CMakeLists.txt I could not find any reason for this behavior, but tried to add -fexceptions as a compiler option in the top most CMakeLists.txt file for the 32 bit mingw-w64 compiler. Unfortunately this made no difference. So investigating some more I took a look at the linklibs.rsp file generated for that particular test executable, and noticed this entry: -lgcc_eh -lgcc_eh (yes it's twice, but that is not the issue, although that might be a cmake bug?). (also note - this option is also present for the 64 bit build files for mingw-w64, but there it works as expected). Now, removing those two library link options from the linklibs.rsp file makes the 32 bit windows version of test application work as expected. I am not sure what libgcc_eh.a actually does (tried searching for some information, but had little luck actually figuring that out), but clearly it has something to do with exception handling. Now I figured I would create a small minimal example that would reproduce this issue outside my projects source tree. So basically created a small program that throws an exception, and catches that. Created a CMakeLists.txt file with the same general options as my farily large project, and had cmake generate the build files for 32 bit mingw-w64. Inspecting the linklibs.rsp file I was surprised to see that "-lgcc_eh" were nowhere to be found, and as such the 32 bit version of this test worked fine. So, my question is, does anyone know under which circumstances cmake will add -lgcc_eh to linklibs.rsp, and is there any way I can prevent cmake from doing so for the 32 bit mingw-w64 compiler? Also, maybe I'm going about this issue the wrong way, and that my findings mentioned above is not a good way of handling this. Or maybe this might be a bug with the 32 bit mingw-w64 compiler? I should probably also mention that the 32 bit version of Mingw-w64 uses the sjlj exception handling mechanism. Any help and pointers would be greatly appreciated - cause adding a step in the developer documentation to go into the linklibs.rsp file to remove -lgcc_eh is kind of a last resort. Thanks for any input on this matter, and please let me know if attaching CMakeOutput.log or other files would be beneficial. Best Regards, Arne Kjetil Andersen -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.tmatma at gmail.com Wed Aug 23 05:07:44 2017 From: m.tmatma at gmail.com (masaru tsuchiyama) Date: Wed, 23 Aug 2017 09:07:44 +0000 Subject: [CMake] 'cmake.exe -G Ninja' doesn't work for VS2017 with cmake ver 3.9.1 In-Reply-To: References: <84ce2ae4-99d2-c3d4-8bb0-82131019aa76@gmail.com> <6ddc295f-8cda-2f64-e6c2-3e33ec529e94@gmail.com> Message-ID: Hello It seems your coworker can reproduce it and you can use the PC tomorrow. So I don't need to debug it, right? Ifyou want me to do anything, le me know. Regards Masaru 2017?8?23?(?) 7:34 masaru tsuchiyama : > Hello > > I'm busy today. > So I'll try tomorrow or the day after tomorrow. > > Regards > Masaru. > > > 2017?8?23?(?) 0:36 Brad King : > >> On 08/21/2017 05:56 PM, masaru tsuchiyama wrote: >> >> https://gitlab.kitware.com/cmake/cmake/issues/17191 >> > I think it is same as the issue. >> > I use Japanese version of Win10 Pro. >> >> Thanks. Unfortunately I've not been able to reproduce it. >> See discussion in the issue. >> >> Since you have a local build you used for bisecting this, might you be >> able to debug it? >> >> The `rules.ninja` file is likely missing due to `codecvt::do_out` >> in `Source/cm_codecvt.cxx` returning `std::codecvt_base::error` >> somewhere, causing the stream state to be bad so cmGeneratedFileStream >> doesn't rename the temporary file to its final place. >> >> Thanks, >> -Brad >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ndevenish at gmail.com Wed Aug 23 05:44:08 2017 From: ndevenish at gmail.com (Nicholas Devenish) Date: Wed, 23 Aug 2017 10:44:08 +0100 Subject: [CMake] Interface Libraries allow include directories but not link directories.. Why? In-Reply-To: References: Message-ID: On Wed, Aug 23, 2017 at 8:07 AM, Cl?ment Gregoire wrote: > I entirely agree with for the rest. CMake badly documenting good practices > or even giving tutorials is an issue. Probably the biggest issue I found. I > myself still fight after years of using and experimenting with it. This > lead to a plethora of badly written cmakelists.txt or module scripts, that > even people in this list still advocates without understanding the problems > behind it. Even some tutorial series found on github.com or used by > coverage websites do it wrong. > I definitely agree that it's extremely hard to find documentation on good ways to do things, and I've personally suspected for a while that the total lack of public information on good/proper/stable way of writing cmakelists is reflective of an internal situation where there isn't really agreement on the way things should be done, and that the notion of "Modern CMake" as something concrete is an entirely public mental construction. (even interface targets - see how very few FindX modules use them, and of those that do, the documentation is always buried right at the bottom. But then even basic FindX things like, how it should handle repeat-inclusion, seems to be left to discretion of single modules). Most of the (good/even existing) public documentation I've seen are on personal blogs, for people who've obviously come onto a project using CMake, built up required knowledge, and then moved on a year or two later. And I guess that in general people migrating large projects don't or can't publicly document the process. Maybe I'm wrong, and e.g. paying for consulting gives you the very best advice on the best way of using modern features in complex situations. But I haven't seen a lot of evidence for it. At the moment the only reference I trust is Daniel's presentation Whilst it gives a reasonable overview, even Daniel's presentation I find rather misleading and (intentionally?) vague on several points, e.g. off the top of my head: - Advocates scripts being usable standalone and also includable themselves. Gives almost no suggestion on how to do this or the many problems that can arise (I'd love this to be reasonable without writing completely unidiomatic code). - Says that custom functions such as add_{project}_library shouldn't be used and function definitions should be used as little as possible. Except this just leads to extremely verbose CMakeLists where repeated properties are defined again and again and again. - But simultaneously advocates rewriting internal functions using the (undocumented?) '_' feature to access "previous definitions". Uses this as one of the few examples of one of the steps as a method to allow a script to change behaviour if being included. - In general makes lots of mandates without providing any suggestions how/why they should be followed - His solution to complex external libraries being hard to use is for them to "just use CMake". This is really offputting. I'm certain his grasp of these problems is great, and appreciate it's just a single presentation, but *personally* (and I emphasise this is the way that *I* view it) find his presentation style hard to follow and it doesn't leave me with much confidence of the contents. I suspect this is just a side-effect of having only one real source for these things, that was never meant to end up as a communities single reference. Much of the rest of this thread seems to be undirected rhetorical rant, so I don't suspect expanding it would lead anywhere. Nick -------------- next part -------------- An HTML attachment was scrubbed... URL: From uwe.koloska at voiceinterconnect.de Wed Aug 23 07:30:11 2017 From: uwe.koloska at voiceinterconnect.de (Uwe Koloska) Date: Wed, 23 Aug 2017 13:30:11 +0200 Subject: [CMake] Interface Libraries allow include directories but not link directories.. Why? In-Reply-To: References: Message-ID: On 23.08.2017 11:44, Nicholas Devenish wrote: > - But simultaneously advocates rewriting internal functions using the > (undocumented?) '_' feature to access "previous definitions". Uses this > as one of the few examples of one of the steps as a method to allow a > script to change behaviour if being included. I have raised an issue on this undocumented behavior: https://gitlab.kitware.com/cmake/cmake/issues/17199 Regards Uwe -- Dipl.-Ing. Uwe Koloska Chief Software Evangelist voice INTER connect GmbH Tel +49 351 407 526 50 Ammonstra?e 35 Fax +49 351 407 526 55 01067 Dresden - Germany www.voiceinterconnect.de Gesch?ftsf?hrung: Dr.-Ing. Diane Hirschfeld, Ludwig Linkenheil Eingetragen im Handelsregister: Amtsgericht Dresden HRB 19466 voiceINTERconnect www.voiceinterconnect.de ... smart speech applications from Germany From jeanmichael.celerier at gmail.com Wed Aug 23 08:10:32 2017 From: jeanmichael.celerier at gmail.com (=?UTF-8?Q?Jean=2DMicha=C3=ABl_Celerier?=) Date: Wed, 23 Aug 2017 14:10:32 +0200 Subject: [CMake] Interface Libraries allow include directories but not link directories.. Why? In-Reply-To: References: Message-ID: > - Says that custom functions such as add_{project}_library shouldn't be used and function definitions should be used as little as possible. Except this just leads to extremely verbose CMakeLists where repeated properties are defined again and again and again. I also never understood how to handle this. I have a project where I want to define, say, -fsanitize=address, -DFOO_BAR and the SUFFIX property on a specific set of 25 targets amongst ~100 targets. What am I to do ? * set(CMAKE_CXX_FLAGS "-fsanitize=address") is "not modern CMake" (and also would be harder to set / unset on specific targets). * calling target_compile_options(...) 25 times ... well I mean, everyone knows it's bad to duplicate code. Especially if the change is meant to be only when a specific option() is enabled, or for debugging purposes * creating a function that would set the correct flags, etc and then call this function for each target is apparently "not modern CMake" either. * creating and linking to "dummy" INTERFACE targets with the flags and properties I want have an awful lot of limitations So what is the right course of actions here ? Ideally I'd like to add "groups" to targets; e.g. "target Foo is a plugin for $software", "target Bar is an integration test" and set per-group options, flags, properties, etc. Like add_group(PluginGroup) target_compile_definitions(PluginGroup -DBLAH) set_property(GROUP PluginGroup PROPERTIES /* whatever in cmake-properties*/) set_group(myTarget PluginGroup) // applies everything to the target Best, ------- Jean-Micha?l Celerier http://www.jcelerier.name On Wed, Aug 23, 2017 at 1:30 PM, Uwe Koloska wrote: > On 23.08.2017 11:44, Nicholas Devenish wrote: > > - But simultaneously advocates rewriting internal functions using the > > (undocumented?) '_' feature to access "previous definitions". Uses this > > as one of the few examples of one of the steps as a method to allow a > > script to change behaviour if being included. > > I have raised an issue on this undocumented behavior: > https://gitlab.kitware.com/cmake/cmake/issues/17199 > > Regards > Uwe > > -- > Dipl.-Ing. Uwe Koloska > Chief Software Evangelist > > voice INTER connect GmbH Tel +49 351 407 526 50 > Ammonstra?e 35 Fax +49 351 407 526 55 > 01067 Dresden - Germany www.voiceinterconnect.de > > Gesch?ftsf?hrung: Dr.-Ing. Diane Hirschfeld, Ludwig Linkenheil > Eingetragen im Handelsregister: Amtsgericht Dresden HRB 19466 > > voiceINTERconnect www.voiceinterconnect.de > ... smart speech applications from Germany > -- > > 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/opensou > rce/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric.noulard at gmail.com Wed Aug 23 08:51:55 2017 From: eric.noulard at gmail.com (Eric Noulard) Date: Wed, 23 Aug 2017 14:51:55 +0200 Subject: [CMake] Interface Libraries allow include directories but not link directories.. Why? In-Reply-To: References: Message-ID: 2017-08-23 14:10 GMT+02:00 Jean-Micha?l Celerier < jeanmichael.celerier at gmail.com>: > > - Says that custom functions such as add_{project}_library shouldn't be > used and function definitions should be used as little as possible. Except > this just leads to extremely verbose CMakeLists where repeated properties > are defined again and again and again. > > I also never understood how to handle this. > > I have a project where I want to define, say, -fsanitize=address, > -DFOO_BAR and the SUFFIX property on a specific set of 25 targets amongst > ~100 targets. What am I to do ? > I have some similar need. > > * set(CMAKE_CXX_FLAGS "-fsanitize=address") is "not modern CMake" (and > also would be harder to set / unset on specific targets). > * calling target_compile_options(...) 25 times ... well I mean, everyone > knows it's bad to duplicate code. Especially if the change is meant to be > only when a specific option() is enabled, or for debugging purposes > * creating a function that would set the correct flags, etc and then call > this function for each target is apparently "not modern CMake" either > Why is it not "modern" ? You can leverage meta-informations offered by CMake in DIRECTORY and TARGET properties. My solution is close to this one, I have written one macro (let's call it myproj_sanitize) which takes as input an inclusion REGEX for exe, an inclusion REGEX for lib, an exclusion REGEX for exe/lib. So that you only have a single call (near the end of the main CMakeLists.txt where I know every targets have been defined) myproj_sanitize( EXCLUDE_EXE_REGEX "" INCLUDE_EXE_REGEX "" EXCLUDE_LIB_REGEX "" INCLUDE_LIB_REGEX "" ) The algorihtm of this macros is simple: S1) collect all SHARED and STATUS LIBRARY and EXECUTABLES targets by examining the BUILDSYSTEM_TARGETS directory property and looping over all directories from the main one. At the end of this step I have 2 lists one for executable one for library S2) apply exclusion and inclusion regexes for the one which are not empty. S3) Call add_sanitizer (from https://github.com/arsenm/sanitizers-cmake) on the remaining targets. I can can easily share the code of the step S1 of the macro. Once we have a mean to get the list of concerned targets the remaining part is easy. I was afraid of the collect processing time because the concerned project has 500+ libraries and 800+ executables but this is done in a couple of seconds and this is only done when compiling in "sanitize" mode which is not ON by default. . > * creating and linking to "dummy" INTERFACE targets with the flags and > properties I want have an awful lot of limitations > > So what is the right course of actions here ? > > Ideally I'd like to add "groups" to targets; e.g. "target Foo is a plugin > for $software", "target Bar is an integration test" and set per-group > options, flags, properties, etc. Like > > add_group(PluginGroup) > target_compile_definitions(PluginGroup -DBLAH) > set_property(GROUP PluginGroup PROPERTIES /* whatever in > cmake-properties*/) > set_group(myTarget PluginGroup) // applies everything to the target > I think this approach is already possible with not so much CMake scripting: group_add(PluginGroup) --> create a bunch of global properties for internal group machinery. G_PluginGroup_targets --> the list of targets belonging to the group G_PluginGroup_compile_definitions G_PluginGroup_properties --> the list of (property,value) pairs for the group group_compile_definitions(PluginGroup -DBLAH) append to G_PluginGroup_compile_definitions group_set_properties(PluginGroup PROPERTIES /* whatever in cmake-properties*/) append to G_PluginGroup_properties group_set(TARGETS myTarget1 myTarget2) // applies previously defined group things to the concerned targets. The "only" limitation would be that you have to define the meta-informations for the groups before using group_set on any targets OR you need group_process macro called neat the end of the main CMakeLists.txt -- Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Wed Aug 23 10:15:20 2017 From: brad.king at kitware.com (Brad King) Date: Wed, 23 Aug 2017 10:15:20 -0400 Subject: [CMake] 'cmake.exe -G Ninja' doesn't work for VS2017 with cmake ver 3.9.1 In-Reply-To: References: <84ce2ae4-99d2-c3d4-8bb0-82131019aa76@gmail.com> <6ddc295f-8cda-2f64-e6c2-3e33ec529e94@gmail.com> Message-ID: <8cfd41b8-594f-cad2-eff2-1391d117ff0f@kitware.com> On 08/23/2017 05:07 AM, masaru tsuchiyama wrote: > It seems your coworker can reproduce it and you can use the PC tomorrow. > So I don't need to debug it, right? Correct, thanks. See issue for further updates. -Brad From eric.noulard at gmail.com Wed Aug 23 10:27:19 2017 From: eric.noulard at gmail.com (Eric Noulard) Date: Wed, 23 Aug 2017 16:27:19 +0200 Subject: [CMake] Interface Libraries allow include directories but not link directories.. Why? In-Reply-To: References: Message-ID: 2017-08-23 15:28 GMT+02:00 Cl?ment Gregoire : > set_property(GROUP PluginGroup PROPERTIES /* whatever in >> cmake-properties*/) >> >> set_group(myTarget PluginGroup) // applies everything to the target > > > Isn't it the same as having a custom target/library for the group and > linking it with transitive properties ? > You mean an INTERFACE library? For a simple set of targets properties like compile flags, probably yes. If the set of properties to be applied to the group (of targets) contains more information than the one conveyed through an INTERFACE library no. For example property "C_STANDARD" https://cmake.org/cmake/help/v3.7/prop_tgt/C_STANDARD.html is not conveyed by transitive linking/compiling. INTERFACE library convey "only" INTERFACE_xxxx properties to targets linking to them. Eric > > 2017-08-23 14:51 GMT+02:00 Eric Noulard : > >> >> >> 2017-08-23 14:10 GMT+02:00 Jean-Micha?l Celerier < >> jeanmichael.celerier at gmail.com>: >> >>> > - Says that custom functions such as add_{project}_library shouldn't >>> be used and function definitions should be used as little as possible. >>> Except this just leads to extremely verbose CMakeLists where repeated >>> properties are defined again and again and again. >>> >>> I also never understood how to handle this. >>> >>> I have a project where I want to define, say, -fsanitize=address, >>> -DFOO_BAR and the SUFFIX property on a specific set of 25 targets amongst >>> ~100 targets. What am I to do ? >>> >> >> I have some similar need. >> >> >>> >>> * set(CMAKE_CXX_FLAGS "-fsanitize=address") is "not modern CMake" (and >>> also would be harder to set / unset on specific targets). >>> * calling target_compile_options(...) 25 times ... well I mean, everyone >>> knows it's bad to duplicate code. Especially if the change is meant to be >>> only when a specific option() is enabled, or for debugging purposes >>> * creating a function that would set the correct flags, etc and then >>> call this function for each target is apparently "not modern CMake" either >>> >> >> Why is it not "modern" ? You can leverage meta-informations offered by >> CMake in DIRECTORY and TARGET properties. >> >> My solution is close to this one, I have written one macro (let's call it >> myproj_sanitize) which takes as input >> an inclusion REGEX for exe, an inclusion REGEX for lib, an exclusion >> REGEX for exe/lib. >> So that you only have a single call (near the end of the main >> CMakeLists.txt where I know every targets have been defined) >> >> myproj_sanitize( >> EXCLUDE_EXE_REGEX "" >> INCLUDE_EXE_REGEX "" >> EXCLUDE_LIB_REGEX "" >> INCLUDE_LIB_REGEX "" >> ) >> >> The algorihtm of this macros is simple: >> >> S1) collect all SHARED and STATUS LIBRARY and EXECUTABLES targets >> by >> examining the BUILDSYSTEM_TARGETS directory property >> and looping over all directories from the main one. >> At the end of this step I have 2 lists one for executable one for >> library >> >> S2) apply exclusion and inclusion regexes for the one which are not empty. >> >> S3) Call add_sanitizer (from https://github.com/arsenm/sanitizers-cmake) >> on the remaining targets. >> >> I can can easily share the code of the step S1 of the macro. Once we have >> a mean >> to get the list of concerned targets the remaining part is easy. >> >> I was afraid of the collect processing time because the concerned project >> has 500+ libraries >> and 800+ executables but this is done in a couple of seconds and this is >> only done >> when compiling in "sanitize" mode which is not ON by default. >> >> . >>> * creating and linking to "dummy" INTERFACE targets with the flags and >>> properties I want have an awful lot of limitations >>> >>> So what is the right course of actions here ? >>> >>> Ideally I'd like to add "groups" to targets; e.g. "target Foo is a >>> plugin for $software", "target Bar is an integration test" and set >>> per-group options, flags, properties, etc. Like >>> >>> add_group(PluginGroup) >>> target_compile_definitions(PluginGroup -DBLAH) >>> set_property(GROUP PluginGroup PROPERTIES /* whatever in >>> cmake-properties*/) >>> set_group(myTarget PluginGroup) // applies everything to the target >>> >> >> I think this approach is already possible with not so much CMake >> scripting: >> >> group_add(PluginGroup) --> create a bunch of global properties for >> internal group machinery. >> >> G_PluginGroup_targets --> the list of targets belonging to the group >> G_PluginGroup_compile_definitions >> G_PluginGroup_properties --> the list of (property,value) pairs for the >> group >> >> group_compile_definitions(PluginGroup -DBLAH) append >> to G_PluginGroup_compile_definitions >> group_set_properties(PluginGroup PROPERTIES /* whatever in >> cmake-properties*/) append to G_PluginGroup_properties >> >> group_set(TARGETS myTarget1 myTarget2) // applies previously defined >> group things to the concerned targets. >> >> The "only" limitation would be that you have to define the >> meta-informations for the groups before using group_set on any >> targets OR you need group_process macro called neat the end of the main >> CMakeLists.txt >> >> -- >> Eric >> >> -- >> >> Powered by www.kitware.com >> >> Please keep messages on-topic and check the CMake FAQ at: >> http://www.cmake.org/Wiki/CMake_FAQ >> >> Kitware offers various services to support the CMake community. For more >> information on each offering, please visit: >> >> CMake Support: http://cmake.org/cmake/help/support.html >> CMake Consulting: http://cmake.org/cmake/help/consulting.html >> CMake Training Courses: http://cmake.org/cmake/help/training.html >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/cmake >> > > -- Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From jomofisher at gmail.com Wed Aug 23 14:02:23 2017 From: jomofisher at gmail.com (Jom O'Fisher) Date: Wed, 23 Aug 2017 11:02:23 -0700 Subject: [CMake] CMake + Gradle for Android In-Reply-To: References: Message-ID: Thanks for the write-up Robert. Having thought about it, I don't believe we have a satisfying answer at the gradle level for this kind of organization. In the gradle model module projects are the unit of organization for configurations, C/C++ flags, etc. and that's something we're pretty much stuck with. Regarding just the redundant build issue, would something like ccache help? I know people have used it with ndk-build with success, I'm not sure about CMake but I don't see why that should make a difference. On Tue, Aug 22, 2017 at 10:27 AM, Robert Dailey wrote: > Another reason to reduce the number of binary directories is that > there are different ways of managing third party libraries. One in > particular that we use is to clone a repository into the binary > directory and build all third party libs in real time based on a > toolchain file (Similar to the functionality provided by > ExternalProject module in CMake). This is repeated from scratch only > if the work hasn't already been done in the binary directory before. > By having more binary dirs than needed, this work is being done an > exponential amount of times which can result in a lot of wasted time > waiting. There are 1 time operations that multiple targets can benefit > from in a single binary tree, instead of 1 per unique target being > invoked. > > Sorry to keep responding: I'm just thinking of things as I go and > bringing them up, to shed light on some of the reasoning behind my > suggestions. > > On Tue, Aug 22, 2017 at 9:26 AM, Robert Dailey > wrote: > > Sorry I forgot to answer your last set of questions: > > > > CommonLib is indeed 2 things: > > > > * A common (static or shared) library for native code (most of our > > CMake targets specify CommonLib as a link dependency) > > * A common library for Java code (we do specify this as a dependency > > for most java targets in Gradle, specifically those under > > Applications/) > > > > On Mon, Aug 21, 2017 at 6:20 PM, Raymond Chiu wrote: > >> Hi Robert, > >> > >> I work with Jom on the Android Studio team, and I would like to clarify > a > >> few things to better understand your situation. > >> You mentioned the project is intend to be cross platform. Normally, in > such > >> situation, we expect there to be a single CMake root project to be > imported > >> into one of the Android library/application. However, in your case, > there > >> are subprojects with Java code. > >> > >> Are the CMake code in App1/2/3 intended to be cross platform too? Or > are > >> they Android specific code? If they are meant to be cross platform, how > >> does the Java code works on other platforms? Or perhaps you added Java > >> binding in those subprojects just for Android? > >> > >> The build.gradle in CommonLib, what kind of Gradle project is that? > From > >> your description, it doesn't look like an Android library project. Or > am I > >> mistaken and it also applies the android library plugin? > >> > >> Raymond > >> > >> On Mon, Aug 21, 2017 at 3:34 PM, Jom O'Fisher > wrote: > >>> > >>> + a colleague > >>> > >>> On Mon, Aug 21, 2017 at 3:11 PM, Jom O'Fisher > >>> wrote: > >>>> > >>>> You can find that number like this: > >>>> - x = number of externalNativeBuild.cmake.path in your build.gradle > files > >>>> - y = number of gradle configurations (like debug and release) > >>>> - z = number of ABIs that you build > >>>> > >>>> The result is x * y * z. To be more accurate, you should consider y > and z > >>>> to be functions of each build.gradle file since these can vary. > >>>> > >>>> There is a second set of folders that hold the stripped versions of > the > >>>> .so files that is purely managed by the android gradle plugin, so you > might > >>>> consider the answer to be 2 * x * y * z. > >>>> > >>>> Hope this helps. > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> On Mon, Aug 21, 2017 at 2:41 PM, Robert Dailey < > rcdailey.lists at gmail.com> > >>>> wrote: > >>>>> > >>>>> This definitely a bit better, but still requires the boilerplate in > >>>>> each leaf gradle file. But I can't seriously complain too much. I > >>>>> think I'm more concerned with the implications this has underneath. > >>>>> First, let me ask just to make sure I'm not misunderstanding: Does > >>>>> each `externalNativeBuild` entry essentially mean 1 CMAKE_BINARY_DIR? > >>>>> How many binary dirs do you manage internally and what determines > when > >>>>> they get created? > >>>>> > >>>>> On Mon, Aug 21, 2017 at 2:35 PM, Jom O'Fisher > >>>>> wrote: > >>>>> > Would it work for your scenario to provide properties in the root > >>>>> > build.gradle: > >>>>> > > >>>>> > ext { > >>>>> > cmakePath = file "CMakeLists.txt" > >>>>> > } > >>>>> > > >>>>> > And then consume them in the leaf app/build.gradle like this? > >>>>> > > >>>>> > externalNativeBuild { > >>>>> > cmake { > >>>>> > path cmakePath > >>>>> > } > >>>>> > } > >>>>> > > >>>>> > It doesn't fully hide the details but it does centralize the > >>>>> > information. > >>>>> > > >>>>> > > >>>>> > On Mon, Aug 21, 2017 at 11:20 AM, Robert Dailey > >>>>> > > >>>>> > wrote: > >>>>> >> > >>>>> >> I wouldn't want to do that, it's too convoluted. I have other > >>>>> >> platforms that use these CMake scripts as well. For example, I > run on > >>>>> >> Windows and Linux platforms as well to build the native code. > Normal > >>>>> >> CMake behavior is designed to work at a root then go downwards to > >>>>> >> find > >>>>> >> targets. However it seems Gradle wants to start at a subdirectory > and > >>>>> >> work its way up to the root, which is opposite of CMake's intended > >>>>> >> behavior IMHO. Not only that but I want to avoid special-casing > >>>>> >> behavior in CMake just for Android's use. > >>>>> >> > >>>>> >> At the moment it feels like (again referring back to my previous > >>>>> >> example structure) that both App2 and App3 each run CMake in > >>>>> >> independent binary directories instead of sharing 1 binary > directory > >>>>> >> and building 2 targets inside of it. I prefer this behavior > instead, > >>>>> >> especially since it allows CMake to operate as it was intended. I > >>>>> >> think it's a common case that projects will define multiple > targets > >>>>> >> starting from a single root, and expect multiple APKs or java > >>>>> >> dependencies to be built within it. > >>>>> >> > >>>>> >> If I'm misunderstanding or making false assumptions please let me > >>>>> >> know. > >>>>> >> > >>>>> >> > >>>>> >> > >>>>> >> On Mon, Aug 21, 2017 at 12:00 PM, Jom O'Fisher < > jomofisher at gmail.com> > >>>>> >> wrote: > >>>>> >> > Would it work for your situation for the leaf CMakeLists.txt to > >>>>> >> > include > >>>>> >> > the > >>>>> >> > root CMakeLists.txt? Then have the leaf-specific logic in the > leaf > >>>>> >> > CMakeLists.txt? > >>>>> >> > > >>>>> >> > > >>>>> >> > > >>>>> >> > On Mon, Aug 21, 2017 at 9:33 AM, Robert Dailey > >>>>> >> > > >>>>> >> > wrote: > >>>>> >> >> > >>>>> >> >> Basically, yes. We have this sort of structure: > >>>>> >> >> > >>>>> >> >> / > >>>>> >> >> Applications/ > >>>>> >> >> App1/ > >>>>> >> >> build.gradle > >>>>> >> >> CMakeLists.txt > >>>>> >> >> App2/ > >>>>> >> >> build.gradle > >>>>> >> >> CMakeLists.txt > >>>>> >> >> App3/ > >>>>> >> >> build.gradle > >>>>> >> >> CMakeLists.txt > >>>>> >> >> CommonLib/ > >>>>> >> >> build.gradle > >>>>> >> >> CMakeLists.txt > >>>>> >> >> CMakeLists.txt > >>>>> >> >> > >>>>> >> >> The libs are defined as follows: > >>>>> >> >> > >>>>> >> >> * CommonLib is a static library (java code builds into a > library) > >>>>> >> >> * No dependencies of its own > >>>>> >> >> * App1 is a shared library (java code builds into a library) > >>>>> >> >> * Dependencies (both java & native): CommonLib > >>>>> >> >> * App2 is a shared library (java code builds into an APK) > >>>>> >> >> * Dependencies (both java & native): App1, CommonLib > >>>>> >> >> * App3 is a shared library (java code builds into an APK) > >>>>> >> >> * Dependencies (both java & native): CommonLib > >>>>> >> >> > >>>>> >> >> In all cases, CMake must be invoked starting at the root > >>>>> >> >> CMakeLists.txt 1 time. Each target can be built from the same > >>>>> >> >> binary > >>>>> >> >> directory after that. Previously with ANT, I was building all > >>>>> >> >> native > >>>>> >> >> targets first, then moved libs to appropriate directories so > that > >>>>> >> >> the > >>>>> >> >> 'ant' command would package the libs. > >>>>> >> >> > >>>>> >> >> For gradle, I wanted to avoid redundantly specifying the root > >>>>> >> >> directory in each leaf-level project directory. Using the > example > >>>>> >> >> above, the leaf-level directories in this case would be App1, > >>>>> >> >> App2, > >>>>> >> >> App3, and CommonLib. However I think we only specify the native > >>>>> >> >> CMake > >>>>> >> >> stuff for the java targets that actually output an APK (that > would > >>>>> >> >> be > >>>>> >> >> App2 and App3 only). > >>>>> >> >> > >>>>> >> >> The ultimate goal is to specify stuff that doesn't change per > >>>>> >> >> independent "module" of ours at the top level so it is > transitive > >>>>> >> >> / > >>>>> >> >> inherited. Then only specify the differences (e.g. the native > >>>>> >> >> CMake > >>>>> >> >> target to build) in the leaf build gradle files. However you > >>>>> >> >> indicated > >>>>> >> >> this isn't possible. > >>>>> >> >> > >>>>> >> >> > >>>>> >> >> > >>>>> >> >> On Mon, Aug 21, 2017 at 11:11 AM, Jom O'Fisher > >>>>> >> >> > >>>>> >> >> wrote: > >>>>> >> >> > What you're doing already sounds correct. You can't directly > >>>>> >> >> > specify > >>>>> >> >> > CMakeLists.txt from the top-level build.gradle. > Recommendation > >>>>> >> >> > is > >>>>> >> >> > that > >>>>> >> >> > it > >>>>> >> >> > should be specified from the build.gradle of the module of > the > >>>>> >> >> > APK. > >>>>> >> >> > Is > >>>>> >> >> > the > >>>>> >> >> > issue that you have multiple APK modules that all reference > the > >>>>> >> >> > same > >>>>> >> >> > CMake > >>>>> >> >> > libraries? > >>>>> >> >> > > >>>>> >> >> > On Mon, Aug 21, 2017 at 9:00 AM, Robert Dailey > >>>>> >> >> > > >>>>> >> >> > wrote: > >>>>> >> >> >> > >>>>> >> >> >> Thanks this is very helpful. The other question I have is: > Is > >>>>> >> >> >> there > >>>>> >> >> >> a > >>>>> >> >> >> place to centrally specify the root CMakeLists.txt? > Basically, > >>>>> >> >> >> I > >>>>> >> >> >> want > >>>>> >> >> >> to specify the CMake root in 1 place, and have targets > (defined > >>>>> >> >> >> further down in subdirectories) that require APK packaging > to > >>>>> >> >> >> specify > >>>>> >> >> >> only the native target name that should be built & packaged. > >>>>> >> >> >> > >>>>> >> >> >> At the moment we specify the root CMakeLists.txt by walking > up > >>>>> >> >> >> the > >>>>> >> >> >> tree, paths like "../../../../CMakeLists.txt". I think this > >>>>> >> >> >> should > >>>>> >> >> >> be > >>>>> >> >> >> put at the top-level build gradle file if possible. Is this > >>>>> >> >> >> doable > >>>>> >> >> >> at > >>>>> >> >> >> the moment? What is the recommended setup? > >>>>> >> >> >> > >>>>> >> >> >> On Mon, Aug 21, 2017 at 9:37 AM, Jom O'Fisher > >>>>> >> >> >> > >>>>> >> >> >> wrote: > >>>>> >> >> >> > Gradle does introspection on the CMake build to find .so > >>>>> >> >> >> > targets > >>>>> >> >> >> > and > >>>>> >> >> >> > those > >>>>> >> >> >> > get packaged. > >>>>> >> >> >> > There is also a special case for stl/runtime .so files > from > >>>>> >> >> >> > the > >>>>> >> >> >> > NDK. > >>>>> >> >> >> > Any additional .so files need to specified in build.gradle > >>>>> >> >> >> > using > >>>>> >> >> >> > jniDirs > >>>>> >> >> >> > > >>>>> >> >> >> > On Mon, Aug 21, 2017 at 7:30 AM, Robert Dailey > >>>>> >> >> >> > > >>>>> >> >> >> > wrote: > >>>>> >> >> >> >> > >>>>> >> >> >> >> How exactly does Gradle package *.so files in an APK? I > know > >>>>> >> >> >> >> that > >>>>> >> >> >> >> ANT > >>>>> >> >> >> >> used to do this for any libs under "libs/". Does > Gradle > >>>>> >> >> >> >> do > >>>>> >> >> >> >> some > >>>>> >> >> >> >> introspection into CMake targets to see if outputs are > *.so, > >>>>> >> >> >> >> and > >>>>> >> >> >> >> copy > >>>>> >> >> >> >> those to some location if needed? What about libraries > like > >>>>> >> >> >> >> libgnustl_shared.so that come with the NDK? I'd like to > know > >>>>> >> >> >> >> if > >>>>> >> >> >> >> any > >>>>> >> >> >> >> manual copy steps are needed in CMake to put outputs in > >>>>> >> >> >> >> proper > >>>>> >> >> >> >> locations for the APK build step. I had to do this when > >>>>> >> >> >> >> using > >>>>> >> >> >> >> ANT. > >>>>> >> >> >> >> > >>>>> >> >> >> >> On Mon, Aug 7, 2017 at 6:16 PM, Jom O'Fisher > >>>>> >> >> >> >> > >>>>> >> >> >> >> wrote: > >>>>> >> >> >> >> > 1) There is a folder created for each ABI under the > >>>>> >> >> >> >> > project > >>>>> >> >> >> >> > module > >>>>> >> >> >> >> > folder > >>>>> >> >> >> >> > (so unique per module per ABI) > >>>>> >> >> >> >> > 2) Gradle doesn't specify language level though you can > >>>>> >> >> >> >> > choose > >>>>> >> >> >> >> > to > >>>>> >> >> >> >> > specify it > >>>>> >> >> >> >> > yourself from the build.gradle. This doc does a pretty > >>>>> >> >> >> >> > good job > >>>>> >> >> >> >> > of > >>>>> >> >> >> >> > explaining which variables are set by Gradle: > >>>>> >> >> >> >> > > >>>>> >> >> >> >> > https://developer.android.com/ndk/guides/cmake.html# > variables. > >>>>> >> >> >> >> > Philosophically, we try to set as little as we can get > >>>>> >> >> >> >> > away > >>>>> >> >> >> >> > with. > >>>>> >> >> >> >> > In > >>>>> >> >> >> >> > particular, the section titled "Understanding the CMake > >>>>> >> >> >> >> > build > >>>>> >> >> >> >> > command" > >>>>> >> >> >> >> > lays > >>>>> >> >> >> >> > out exactly what we set. You can also see the folders > we > >>>>> >> >> >> >> > specify > >>>>> >> >> >> >> > (one > >>>>> >> >> >> >> > per > >>>>> >> >> >> >> > module per ABI) > >>>>> >> >> >> >> > 3) Not sure I understand this. > >>>>> >> >> >> >> > > >>>>> >> >> >> >> > The other document worth taking a look at (if you > haven't > >>>>> >> >> >> >> > already) > >>>>> >> >> >> >> > is: > >>>>> >> >> >> >> > > >>>>> >> >> >> >> > > >>>>> >> >> >> >> > https://developer.android.com/ > studio/projects/add-native-code.html > >>>>> >> >> >> >> > > >>>>> >> >> >> >> > > >>>>> >> >> >> >> > On Mon, Aug 7, 2017 at 3:35 PM, Robert Dailey > >>>>> >> >> >> >> > > >>>>> >> >> >> >> > wrote: > >>>>> >> >> >> >> >> > >>>>> >> >> >> >> >> Thanks Jom > >>>>> >> >> >> >> >> > >>>>> >> >> >> >> >> Honestly, I prefer option 1 to work simply because > that's > >>>>> >> >> >> >> >> how > >>>>> >> >> >> >> >> Google's > >>>>> >> >> >> >> >> officially supporting CMake. But it also has debugging > >>>>> >> >> >> >> >> which > >>>>> >> >> >> >> >> is > >>>>> >> >> >> >> >> the > >>>>> >> >> >> >> >> #1 > >>>>> >> >> >> >> >> reason for me. > >>>>> >> >> >> >> >> > >>>>> >> >> >> >> >> However, I'd like to understand a lot more about how > the > >>>>> >> >> >> >> >> integration > >>>>> >> >> >> >> >> really happens. For example, I have these questions: > >>>>> >> >> >> >> >> > >>>>> >> >> >> >> >> 1) How, internally, are CMake build directories > managed? > >>>>> >> >> >> >> >> Do > >>>>> >> >> >> >> >> you > >>>>> >> >> >> >> >> generate 1 per unique android project? What about for > >>>>> >> >> >> >> >> each > >>>>> >> >> >> >> >> specific > >>>>> >> >> >> >> >> platform (x86, armeabi-v7a, etc)? > >>>>> >> >> >> >> >> 2) Last time I looked into CMake integration, things > >>>>> >> >> >> >> >> defined > >>>>> >> >> >> >> >> inside > >>>>> >> >> >> >> >> the CMake scripts were ignored because they are > specified > >>>>> >> >> >> >> >> at > >>>>> >> >> >> >> >> the > >>>>> >> >> >> >> >> command line. Namely, all of those settings that are > >>>>> >> >> >> >> >> driven by > >>>>> >> >> >> >> >> the > >>>>> >> >> >> >> >> Gradle configuration (CXX language level was one in > >>>>> >> >> >> >> >> particular > >>>>> >> >> >> >> >> I > >>>>> >> >> >> >> >> think; I specify C++14 support via CMake, but I recall > >>>>> >> >> >> >> >> this > >>>>> >> >> >> >> >> being > >>>>> >> >> >> >> >> overridden from outside)? > >>>>> >> >> >> >> >> 3) How redundant is it to configure individual > libraries > >>>>> >> >> >> >> >> via > >>>>> >> >> >> >> >> the > >>>>> >> >> >> >> >> gradle scripts? In my previous attempts, I wanted to > >>>>> >> >> >> >> >> define > >>>>> >> >> >> >> >> common > >>>>> >> >> >> >> >> stuff for CMake / native code at the root gradle or > >>>>> >> >> >> >> >> settings > >>>>> >> >> >> >> >> file, > >>>>> >> >> >> >> >> and > >>>>> >> >> >> >> >> only define the differences in the actual gradle build > >>>>> >> >> >> >> >> files > >>>>> >> >> >> >> >> for > >>>>> >> >> >> >> >> each > >>>>> >> >> >> >> >> corresponding Java target (like, defining the name of > the > >>>>> >> >> >> >> >> native > >>>>> >> >> >> >> >> (shared library) target in Gradle, but the command > line > >>>>> >> >> >> >> >> invocation, > >>>>> >> >> >> >> >> -D > >>>>> >> >> >> >> >> CMake settings, etc would all be common and defined at > >>>>> >> >> >> >> >> the > >>>>> >> >> >> >> >> root). > >>>>> >> >> >> >> >> > >>>>> >> >> >> >> >> The TLDR is, the closer we can stay to CMake's way of > >>>>> >> >> >> >> >> doing > >>>>> >> >> >> >> >> things > >>>>> >> >> >> >> >> and > >>>>> >> >> >> >> >> keep CMake-related settings self-contained to the > CMake > >>>>> >> >> >> >> >> scripts > >>>>> >> >> >> >> >> themselves, the better. This also makes cross-platform > >>>>> >> >> >> >> >> easier > >>>>> >> >> >> >> >> (we > >>>>> >> >> >> >> >> build the native code in Windows, for example, so > having > >>>>> >> >> >> >> >> settings > >>>>> >> >> >> >> >> specified in the gradle files do not carry over to > other > >>>>> >> >> >> >> >> platforms. > >>>>> >> >> >> >> >> Namely, settings that are not platform specific like > the > >>>>> >> >> >> >> >> C++ > >>>>> >> >> >> >> >> language > >>>>> >> >> >> >> >> level). > >>>>> >> >> >> >> >> > >>>>> >> >> >> >> >> If there's a detailed document / wiki I can read on > the > >>>>> >> >> >> >> >> intrinsics > >>>>> >> >> >> >> >> of > >>>>> >> >> >> >> >> CMake integration in Gradle / Android Studio, I'd > love to > >>>>> >> >> >> >> >> read > >>>>> >> >> >> >> >> it. > >>>>> >> >> >> >> >> Otherwise, I hope you won't mind if I pick your brain > as > >>>>> >> >> >> >> >> questions > >>>>> >> >> >> >> >> come up. I think I'm going to try option 1 for now and > >>>>> >> >> >> >> >> see how > >>>>> >> >> >> >> >> it > >>>>> >> >> >> >> >> goes. It's just black box for me because unlike > option 2, > >>>>> >> >> >> >> >> I > >>>>> >> >> >> >> >> have > >>>>> >> >> >> >> >> very > >>>>> >> >> >> >> >> little control over what happens after building the > >>>>> >> >> >> >> >> shared > >>>>> >> >> >> >> >> libraries, > >>>>> >> >> >> >> >> and to make up for that I need to really get a deep > >>>>> >> >> >> >> >> understanding > >>>>> >> >> >> >> >> of > >>>>> >> >> >> >> >> how it works so I can make sure I code my CMake > scripts > >>>>> >> >> >> >> >> properly > >>>>> >> >> >> >> >> for > >>>>> >> >> >> >> >> not only Android, but my other platforms as well > >>>>> >> >> >> >> >> (non-Android > >>>>> >> >> >> >> >> platforms). > >>>>> >> >> >> >> >> > >>>>> >> >> >> >> >> Thanks again. > >>>>> >> >> >> >> >> > >>>>> >> >> >> >> >> On Mon, Aug 7, 2017 at 5:12 PM, Jom O'Fisher > >>>>> >> >> >> >> >> > >>>>> >> >> >> >> >> wrote: > >>>>> >> >> >> >> >> > Either option can work fine. Disclosure: I work on > >>>>> >> >> >> >> >> > Android > >>>>> >> >> >> >> >> > Studio > >>>>> >> >> >> >> >> > and > >>>>> >> >> >> >> >> > was > >>>>> >> >> >> >> >> > the one that added CMake support. > >>>>> >> >> >> >> >> > > >>>>> >> >> >> >> >> > Option (1) is the way it's designed to work and > we're > >>>>> >> >> >> >> >> > working > >>>>> >> >> >> >> >> > toward > >>>>> >> >> >> >> >> > getting > >>>>> >> >> >> >> >> > rid of the need for the CMake fork. I can't really > say > >>>>> >> >> >> >> >> > when > >>>>> >> >> >> >> >> > that > >>>>> >> >> >> >> >> > will > >>>>> >> >> >> >> >> > happen > >>>>> >> >> >> >> >> > but if you can get away with an older CMake for now > >>>>> >> >> >> >> >> > then I'd > >>>>> >> >> >> >> >> > go > >>>>> >> >> >> >> >> > this > >>>>> >> >> >> >> >> > way. > >>>>> >> >> >> >> >> > As you mentioned, option (1) will allow you to view > >>>>> >> >> >> >> >> > your > >>>>> >> >> >> >> >> > source > >>>>> >> >> >> >> >> > file > >>>>> >> >> >> >> >> > structure in Android Studio, edit files, and debug > >>>>> >> >> >> >> >> > using the > >>>>> >> >> >> >> >> > built-in > >>>>> >> >> >> >> >> > debugging support. > >>>>> >> >> >> >> >> > > >>>>> >> >> >> >> >> > To get option (2) to work, you can use jniDirs > setting > >>>>> >> >> >> >> >> > to > >>>>> >> >> >> >> >> > tell > >>>>> >> >> >> >> >> > Android > >>>>> >> >> >> >> >> > Gradle where to pick up your built .so files (see > >>>>> >> >> >> >> >> > > >>>>> >> >> >> >> >> > > >>>>> >> >> >> >> >> > > >>>>> >> >> >> >> >> > > >>>>> >> >> >> >> >> > > >>>>> >> >> >> >> >> > > >>>>> >> >> >> >> >> > https://stackoverflow.com/ > questions/21255125/how-can-i-add-so-files-to-an-android- > library-project-using-gradle-0-7). > >>>>> >> >> >> >> >> > I'm not aware of any projects that use this approach > >>>>> >> >> >> >> >> > but it > >>>>> >> >> >> >> >> > should > >>>>> >> >> >> >> >> > work > >>>>> >> >> >> >> >> > in > >>>>> >> >> >> >> >> > principal. > >>>>> >> >> >> >> >> > > >>>>> >> >> >> >> >> > I hope this helps, > >>>>> >> >> >> >> >> > Jomo > >>>>> >> >> >> >> >> > > >>>>> >> >> >> >> >> > > >>>>> >> >> >> >> >> > On Mon, Aug 7, 2017 at 11:09 AM, Robert Dailey > >>>>> >> >> >> >> >> > > >>>>> >> >> >> >> >> > wrote: > >>>>> >> >> >> >> >> >> > >>>>> >> >> >> >> >> >> Right now I have custom targets set to execute the > >>>>> >> >> >> >> >> >> "ant > >>>>> >> >> >> >> >> >> release" > >>>>> >> >> >> >> >> >> command after my native targets are built. Part of > >>>>> >> >> >> >> >> >> that > >>>>> >> >> >> >> >> >> command > >>>>> >> >> >> >> >> >> involves copying *.so files to the libs/armeabi-v7a > >>>>> >> >> >> >> >> >> directory > >>>>> >> >> >> >> >> >> so > >>>>> >> >> >> >> >> >> they > >>>>> >> >> >> >> >> >> get packaged in an APK. > >>>>> >> >> >> >> >> >> > >>>>> >> >> >> >> >> >> When switching to gradle, I have two options: > >>>>> >> >> >> >> >> >> > >>>>> >> >> >> >> >> >> 1. Gradle drives CMake: This means using Android > >>>>> >> >> >> >> >> >> Studio and > >>>>> >> >> >> >> >> >> being > >>>>> >> >> >> >> >> >> locked down to Google's fork of CMake which is a > few > >>>>> >> >> >> >> >> >> major > >>>>> >> >> >> >> >> >> releases > >>>>> >> >> >> >> >> >> behind. I see that as a negative. > >>>>> >> >> >> >> >> >> > >>>>> >> >> >> >> >> >> 2. CMake drives Gradle: This would be the same or > >>>>> >> >> >> >> >> >> similar > >>>>> >> >> >> >> >> >> to > >>>>> >> >> >> >> >> >> what > >>>>> >> >> >> >> >> >> I'm > >>>>> >> >> >> >> >> >> already doing: The custom targets I have would > execute > >>>>> >> >> >> >> >> >> gradle > >>>>> >> >> >> >> >> >> as > >>>>> >> >> >> >> >> >> a > >>>>> >> >> >> >> >> >> separate build step, instead of running ant > commands. > >>>>> >> >> >> >> >> >> I'm > >>>>> >> >> >> >> >> >> not > >>>>> >> >> >> >> >> >> too > >>>>> >> >> >> >> >> >> familiar with Gradle, so I'm not sure how you tell > it > >>>>> >> >> >> >> >> >> where > >>>>> >> >> >> >> >> >> your > >>>>> >> >> >> >> >> >> shared libraries are for the APK packaging steps. > >>>>> >> >> >> >> >> >> > >>>>> >> >> >> >> >> >> Which does everyone recommend? Is anyone using one > of > >>>>> >> >> >> >> >> >> these > >>>>> >> >> >> >> >> >> setups > >>>>> >> >> >> >> >> >> successfully? The downside to option 2 is probably > no > >>>>> >> >> >> >> >> >> on-device > >>>>> >> >> >> >> >> >> native > >>>>> >> >> >> >> >> >> debugging since Android Studio probably can't > handle > >>>>> >> >> >> >> >> >> gradle > >>>>> >> >> >> >> >> >> projects > >>>>> >> >> >> >> >> >> without any external CMake builds set up. > >>>>> >> >> >> >> >> >> > >>>>> >> >> >> >> >> >> Would like some general direction & advice before I > >>>>> >> >> >> >> >> >> move > >>>>> >> >> >> >> >> >> away > >>>>> >> >> >> >> >> >> from > >>>>> >> >> >> >> >> >> ANT. Thanks in advance. > >>>>> >> >> >> >> >> >> -- > >>>>> >> >> >> >> >> >> > >>>>> >> >> >> >> >> >> Powered by www.kitware.com > >>>>> >> >> >> >> >> >> > >>>>> >> >> >> >> >> >> Please keep messages on-topic and check the CMake > FAQ > >>>>> >> >> >> >> >> >> at: > >>>>> >> >> >> >> >> >> http://www.cmake.org/Wiki/CMake_FAQ > >>>>> >> >> >> >> >> >> > >>>>> >> >> >> >> >> >> Kitware offers various services to support the > CMake > >>>>> >> >> >> >> >> >> community. > >>>>> >> >> >> >> >> >> For > >>>>> >> >> >> >> >> >> more > >>>>> >> >> >> >> >> >> information on each offering, please visit: > >>>>> >> >> >> >> >> >> > >>>>> >> >> >> >> >> >> CMake Support: > >>>>> >> >> >> >> >> >> http://cmake.org/cmake/help/support.html > >>>>> >> >> >> >> >> >> CMake Consulting: > >>>>> >> >> >> >> >> >> http://cmake.org/cmake/help/consulting.html > >>>>> >> >> >> >> >> >> CMake Training Courses: > >>>>> >> >> >> >> >> >> http://cmake.org/cmake/help/training.html > >>>>> >> >> >> >> >> >> > >>>>> >> >> >> >> >> >> Visit other Kitware open-source projects at > >>>>> >> >> >> >> >> >> http://www.kitware.com/opensource/opensource.html > >>>>> >> >> >> >> >> >> > >>>>> >> >> >> >> >> >> Follow this link to subscribe/unsubscribe: > >>>>> >> >> >> >> >> >> http://public.kitware.com/mailman/listinfo/cmake > >>>>> >> >> >> >> >> > > >>>>> >> >> >> >> >> > > >>>>> >> >> >> >> > > >>>>> >> >> >> >> > > >>>>> >> >> >> > > >>>>> >> >> >> > > >>>>> >> >> > > >>>>> >> >> > > >>>>> >> > > >>>>> >> > > >>>>> > > >>>>> > > >>>> > >>>> > >>> > >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.maynard at kitware.com Wed Aug 23 15:57:51 2017 From: robert.maynard at kitware.com (Robert Maynard) Date: Wed, 23 Aug 2017 15:57:51 -0400 Subject: [CMake] CMake, Mingw-w64 32 bit exception handling. In-Reply-To: References: Message-ID: A quick scan of CMake source code shows that we don't have any references to gcc_eh anywhere. I way this could be occurring is through CMake detection of the implicit libraries that a compiler requires for each language. In particular it could be that C code for mingw by default uses gcc_eh while C++ doesn't. The culprit could also be a FindPackage* you are using. On Wed, Aug 23, 2017 at 4:55 AM, Arne Kjetil Andersen wrote: > Greetings. > > I'm a developer on a fairly large project where I'm using CMake version > 3.9.1 > > I primarily work on linux, but also cross compiles for windows using > Mingw-w64 on my linux box. > > I have encountered an issue which I'm having some trouble figuring out. > Running through some of my tests where an exception is thrown (on purpose) > the 32 bit version compiled with Mingw-w64-g++ version 7.1.1 just calls > terminate even though there are try catch blocks. Now mind you, this all > works fine on the native linux compiled version of my tests, and also the 64 > bit windows version compiled with Mingw-w64-g++ version 7.1.1. > > Going through all the projects CMakeLists.txt I could not find any reason > for this behavior, but tried to add -fexceptions as a compiler option in the > top most CMakeLists.txt file for the 32 bit mingw-w64 compiler. > Unfortunately this made no difference. > > So investigating some more I took a look at the linklibs.rsp file generated > for that particular test executable, and noticed this entry: > -lgcc_eh -lgcc_eh > > (yes it's twice, but that is not the issue, although that might be a cmake > bug?). > (also note - this option is also present for the 64 bit build files for > mingw-w64, but there it works as expected). > > Now, removing those two library link options from the linklibs.rsp file > makes the 32 bit windows version of test application work as expected. I am > not sure what libgcc_eh.a actually does (tried searching for some > information, but had little luck actually figuring that out), but clearly it > has something to do with exception handling. > > Now I figured I would create a small minimal example that would reproduce > this issue outside my projects source tree. So basically created a small > program that throws an exception, and catches that. Created a CMakeLists.txt > file with the same general options as my farily large project, and had cmake > generate the build files for 32 bit mingw-w64. Inspecting the linklibs.rsp > file I was surprised to see that "-lgcc_eh" were nowhere to be found, and as > such the 32 bit version of this test worked fine. > > So, my question is, does anyone know under which circumstances cmake will > add -lgcc_eh to linklibs.rsp, and is there any way I can prevent cmake from > doing so for the 32 bit mingw-w64 compiler? > > Also, maybe I'm going about this issue the wrong way, and that my findings > mentioned above is not a good way of handling this. Or maybe this might be a > bug with the 32 bit mingw-w64 compiler? > > I should probably also mention that the 32 bit version of Mingw-w64 uses the > sjlj exception handling mechanism. > > Any help and pointers would be greatly appreciated - cause adding a step in > the developer documentation to go into the linklibs.rsp file to remove > -lgcc_eh is kind of a last resort. > > Thanks for any input on this matter, and please let me know if attaching > CMakeOutput.log or other files would be beneficial. > > Best Regards, > Arne Kjetil Andersen > > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake From rcdailey.lists at gmail.com Wed Aug 23 16:03:41 2017 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Wed, 23 Aug 2017 15:03:41 -0500 Subject: [CMake] CMake + Gradle for Android In-Reply-To: References: Message-ID: I'm not sure what you mean by "gradle module projects", but maybe having some examples of what you mean by "configurations, C++ flags, etc" might make it more clear. Question: When specifying "path" for the CMakeLists.txt in the build.gradle file, how do you know which targets to build? For example, that run of CMake may generate 100 targets, but only 20 need to build and be packaged (*.so files) with the APK. Do you just build "all"? Is there a way to specify the target itself? Thanks again. I'd still like to know more about what the ideal organization is. I find it hard to believe that large android projects rarely break things up into multiple, separate "components" that are built independently. That's really the gist of what we're dealing with here. Your typical "hello world" project likely will have only 1 CMakeLists.txt that is pretty self-contained, but all the documentation I've looked at so far doesn't show the best way to handle native library dependencies across java projects between build.gradle files (or maybe I'm just not looking hard enough). On Wed, Aug 23, 2017 at 1:02 PM, Jom O'Fisher wrote: > Thanks for the write-up Robert. Having thought about it, I don't believe we > have a satisfying answer at the gradle level for this kind of organization. > In the gradle model module projects are the unit of organization for > configurations, C/C++ flags, etc. and that's something we're pretty much > stuck with. > Regarding just the redundant build issue, would something like ccache help? > I know people have used it with ndk-build with success, I'm not sure about > CMake but I don't see why that should make a difference. > > > > On Tue, Aug 22, 2017 at 10:27 AM, Robert Dailey > wrote: >> >> Another reason to reduce the number of binary directories is that >> there are different ways of managing third party libraries. One in >> particular that we use is to clone a repository into the binary >> directory and build all third party libs in real time based on a >> toolchain file (Similar to the functionality provided by >> ExternalProject module in CMake). This is repeated from scratch only >> if the work hasn't already been done in the binary directory before. >> By having more binary dirs than needed, this work is being done an >> exponential amount of times which can result in a lot of wasted time >> waiting. There are 1 time operations that multiple targets can benefit >> from in a single binary tree, instead of 1 per unique target being >> invoked. >> >> Sorry to keep responding: I'm just thinking of things as I go and >> bringing them up, to shed light on some of the reasoning behind my >> suggestions. >> >> On Tue, Aug 22, 2017 at 9:26 AM, Robert Dailey >> wrote: >> > Sorry I forgot to answer your last set of questions: >> > >> > CommonLib is indeed 2 things: >> > >> > * A common (static or shared) library for native code (most of our >> > CMake targets specify CommonLib as a link dependency) >> > * A common library for Java code (we do specify this as a dependency >> > for most java targets in Gradle, specifically those under >> > Applications/) >> > >> > On Mon, Aug 21, 2017 at 6:20 PM, Raymond Chiu wrote: >> >> Hi Robert, >> >> >> >> I work with Jom on the Android Studio team, and I would like to clarify >> >> a >> >> few things to better understand your situation. >> >> You mentioned the project is intend to be cross platform. Normally, in >> >> such >> >> situation, we expect there to be a single CMake root project to be >> >> imported >> >> into one of the Android library/application. However, in your case, >> >> there >> >> are subprojects with Java code. >> >> >> >> Are the CMake code in App1/2/3 intended to be cross platform too? Or >> >> are >> >> they Android specific code? If they are meant to be cross platform, >> >> how >> >> does the Java code works on other platforms? Or perhaps you added Java >> >> binding in those subprojects just for Android? >> >> >> >> The build.gradle in CommonLib, what kind of Gradle project is that? >> >> From >> >> your description, it doesn't look like an Android library project. Or >> >> am I >> >> mistaken and it also applies the android library plugin? >> >> >> >> Raymond >> >> >> >> On Mon, Aug 21, 2017 at 3:34 PM, Jom O'Fisher >> >> wrote: >> >>> >> >>> + a colleague >> >>> >> >>> On Mon, Aug 21, 2017 at 3:11 PM, Jom O'Fisher >> >>> wrote: >> >>>> >> >>>> You can find that number like this: >> >>>> - x = number of externalNativeBuild.cmake.path in your build.gradle >> >>>> files >> >>>> - y = number of gradle configurations (like debug and release) >> >>>> - z = number of ABIs that you build >> >>>> >> >>>> The result is x * y * z. To be more accurate, you should consider y >> >>>> and z >> >>>> to be functions of each build.gradle file since these can vary. >> >>>> >> >>>> There is a second set of folders that hold the stripped versions of >> >>>> the >> >>>> .so files that is purely managed by the android gradle plugin, so you >> >>>> might >> >>>> consider the answer to be 2 * x * y * z. >> >>>> >> >>>> Hope this helps. >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> On Mon, Aug 21, 2017 at 2:41 PM, Robert Dailey >> >>>> >> >>>> wrote: >> >>>>> >> >>>>> This definitely a bit better, but still requires the boilerplate in >> >>>>> each leaf gradle file. But I can't seriously complain too much. I >> >>>>> think I'm more concerned with the implications this has underneath. >> >>>>> First, let me ask just to make sure I'm not misunderstanding: Does >> >>>>> each `externalNativeBuild` entry essentially mean 1 >> >>>>> CMAKE_BINARY_DIR? >> >>>>> How many binary dirs do you manage internally and what determines >> >>>>> when >> >>>>> they get created? >> >>>>> >> >>>>> On Mon, Aug 21, 2017 at 2:35 PM, Jom O'Fisher >> >>>>> wrote: >> >>>>> > Would it work for your scenario to provide properties in the root >> >>>>> > build.gradle: >> >>>>> > >> >>>>> > ext { >> >>>>> > cmakePath = file "CMakeLists.txt" >> >>>>> > } >> >>>>> > >> >>>>> > And then consume them in the leaf app/build.gradle like this? >> >>>>> > >> >>>>> > externalNativeBuild { >> >>>>> > cmake { >> >>>>> > path cmakePath >> >>>>> > } >> >>>>> > } >> >>>>> > >> >>>>> > It doesn't fully hide the details but it does centralize the >> >>>>> > information. >> >>>>> > >> >>>>> > >> >>>>> > On Mon, Aug 21, 2017 at 11:20 AM, Robert Dailey >> >>>>> > >> >>>>> > wrote: >> >>>>> >> >> >>>>> >> I wouldn't want to do that, it's too convoluted. I have other >> >>>>> >> platforms that use these CMake scripts as well. For example, I >> >>>>> >> run on >> >>>>> >> Windows and Linux platforms as well to build the native code. >> >>>>> >> Normal >> >>>>> >> CMake behavior is designed to work at a root then go downwards to >> >>>>> >> find >> >>>>> >> targets. However it seems Gradle wants to start at a subdirectory >> >>>>> >> and >> >>>>> >> work its way up to the root, which is opposite of CMake's >> >>>>> >> intended >> >>>>> >> behavior IMHO. Not only that but I want to avoid special-casing >> >>>>> >> behavior in CMake just for Android's use. >> >>>>> >> >> >>>>> >> At the moment it feels like (again referring back to my previous >> >>>>> >> example structure) that both App2 and App3 each run CMake in >> >>>>> >> independent binary directories instead of sharing 1 binary >> >>>>> >> directory >> >>>>> >> and building 2 targets inside of it. I prefer this behavior >> >>>>> >> instead, >> >>>>> >> especially since it allows CMake to operate as it was intended. I >> >>>>> >> think it's a common case that projects will define multiple >> >>>>> >> targets >> >>>>> >> starting from a single root, and expect multiple APKs or java >> >>>>> >> dependencies to be built within it. >> >>>>> >> >> >>>>> >> If I'm misunderstanding or making false assumptions please let me >> >>>>> >> know. >> >>>>> >> >> >>>>> >> >> >>>>> >> >> >>>>> >> On Mon, Aug 21, 2017 at 12:00 PM, Jom O'Fisher >> >>>>> >> >> >>>>> >> wrote: >> >>>>> >> > Would it work for your situation for the leaf CMakeLists.txt to >> >>>>> >> > include >> >>>>> >> > the >> >>>>> >> > root CMakeLists.txt? Then have the leaf-specific logic in the >> >>>>> >> > leaf >> >>>>> >> > CMakeLists.txt? >> >>>>> >> > >> >>>>> >> > >> >>>>> >> > >> >>>>> >> > On Mon, Aug 21, 2017 at 9:33 AM, Robert Dailey >> >>>>> >> > >> >>>>> >> > wrote: >> >>>>> >> >> >> >>>>> >> >> Basically, yes. We have this sort of structure: >> >>>>> >> >> >> >>>>> >> >> / >> >>>>> >> >> Applications/ >> >>>>> >> >> App1/ >> >>>>> >> >> build.gradle >> >>>>> >> >> CMakeLists.txt >> >>>>> >> >> App2/ >> >>>>> >> >> build.gradle >> >>>>> >> >> CMakeLists.txt >> >>>>> >> >> App3/ >> >>>>> >> >> build.gradle >> >>>>> >> >> CMakeLists.txt >> >>>>> >> >> CommonLib/ >> >>>>> >> >> build.gradle >> >>>>> >> >> CMakeLists.txt >> >>>>> >> >> CMakeLists.txt >> >>>>> >> >> >> >>>>> >> >> The libs are defined as follows: >> >>>>> >> >> >> >>>>> >> >> * CommonLib is a static library (java code builds into a >> >>>>> >> >> library) >> >>>>> >> >> * No dependencies of its own >> >>>>> >> >> * App1 is a shared library (java code builds into a library) >> >>>>> >> >> * Dependencies (both java & native): CommonLib >> >>>>> >> >> * App2 is a shared library (java code builds into an APK) >> >>>>> >> >> * Dependencies (both java & native): App1, CommonLib >> >>>>> >> >> * App3 is a shared library (java code builds into an APK) >> >>>>> >> >> * Dependencies (both java & native): CommonLib >> >>>>> >> >> >> >>>>> >> >> In all cases, CMake must be invoked starting at the root >> >>>>> >> >> CMakeLists.txt 1 time. Each target can be built from the same >> >>>>> >> >> binary >> >>>>> >> >> directory after that. Previously with ANT, I was building all >> >>>>> >> >> native >> >>>>> >> >> targets first, then moved libs to appropriate directories so >> >>>>> >> >> that >> >>>>> >> >> the >> >>>>> >> >> 'ant' command would package the libs. >> >>>>> >> >> >> >>>>> >> >> For gradle, I wanted to avoid redundantly specifying the root >> >>>>> >> >> directory in each leaf-level project directory. Using the >> >>>>> >> >> example >> >>>>> >> >> above, the leaf-level directories in this case would be App1, >> >>>>> >> >> App2, >> >>>>> >> >> App3, and CommonLib. However I think we only specify the >> >>>>> >> >> native >> >>>>> >> >> CMake >> >>>>> >> >> stuff for the java targets that actually output an APK (that >> >>>>> >> >> would >> >>>>> >> >> be >> >>>>> >> >> App2 and App3 only). >> >>>>> >> >> >> >>>>> >> >> The ultimate goal is to specify stuff that doesn't change per >> >>>>> >> >> independent "module" of ours at the top level so it is >> >>>>> >> >> transitive >> >>>>> >> >> / >> >>>>> >> >> inherited. Then only specify the differences (e.g. the native >> >>>>> >> >> CMake >> >>>>> >> >> target to build) in the leaf build gradle files. However you >> >>>>> >> >> indicated >> >>>>> >> >> this isn't possible. >> >>>>> >> >> >> >>>>> >> >> >> >>>>> >> >> >> >>>>> >> >> On Mon, Aug 21, 2017 at 11:11 AM, Jom O'Fisher >> >>>>> >> >> >> >>>>> >> >> wrote: >> >>>>> >> >> > What you're doing already sounds correct. You can't directly >> >>>>> >> >> > specify >> >>>>> >> >> > CMakeLists.txt from the top-level build.gradle. >> >>>>> >> >> > Recommendation >> >>>>> >> >> > is >> >>>>> >> >> > that >> >>>>> >> >> > it >> >>>>> >> >> > should be specified from the build.gradle of the module of >> >>>>> >> >> > the >> >>>>> >> >> > APK. >> >>>>> >> >> > Is >> >>>>> >> >> > the >> >>>>> >> >> > issue that you have multiple APK modules that all reference >> >>>>> >> >> > the >> >>>>> >> >> > same >> >>>>> >> >> > CMake >> >>>>> >> >> > libraries? >> >>>>> >> >> > >> >>>>> >> >> > On Mon, Aug 21, 2017 at 9:00 AM, Robert Dailey >> >>>>> >> >> > >> >>>>> >> >> > wrote: >> >>>>> >> >> >> >> >>>>> >> >> >> Thanks this is very helpful. The other question I have is: >> >>>>> >> >> >> Is >> >>>>> >> >> >> there >> >>>>> >> >> >> a >> >>>>> >> >> >> place to centrally specify the root CMakeLists.txt? >> >>>>> >> >> >> Basically, >> >>>>> >> >> >> I >> >>>>> >> >> >> want >> >>>>> >> >> >> to specify the CMake root in 1 place, and have targets >> >>>>> >> >> >> (defined >> >>>>> >> >> >> further down in subdirectories) that require APK packaging >> >>>>> >> >> >> to >> >>>>> >> >> >> specify >> >>>>> >> >> >> only the native target name that should be built & >> >>>>> >> >> >> packaged. >> >>>>> >> >> >> >> >>>>> >> >> >> At the moment we specify the root CMakeLists.txt by walking >> >>>>> >> >> >> up >> >>>>> >> >> >> the >> >>>>> >> >> >> tree, paths like "../../../../CMakeLists.txt". I think this >> >>>>> >> >> >> should >> >>>>> >> >> >> be >> >>>>> >> >> >> put at the top-level build gradle file if possible. Is this >> >>>>> >> >> >> doable >> >>>>> >> >> >> at >> >>>>> >> >> >> the moment? What is the recommended setup? >> >>>>> >> >> >> >> >>>>> >> >> >> On Mon, Aug 21, 2017 at 9:37 AM, Jom O'Fisher >> >>>>> >> >> >> >> >>>>> >> >> >> wrote: >> >>>>> >> >> >> > Gradle does introspection on the CMake build to find .so >> >>>>> >> >> >> > targets >> >>>>> >> >> >> > and >> >>>>> >> >> >> > those >> >>>>> >> >> >> > get packaged. >> >>>>> >> >> >> > There is also a special case for stl/runtime .so files >> >>>>> >> >> >> > from >> >>>>> >> >> >> > the >> >>>>> >> >> >> > NDK. >> >>>>> >> >> >> > Any additional .so files need to specified in >> >>>>> >> >> >> > build.gradle >> >>>>> >> >> >> > using >> >>>>> >> >> >> > jniDirs >> >>>>> >> >> >> > >> >>>>> >> >> >> > On Mon, Aug 21, 2017 at 7:30 AM, Robert Dailey >> >>>>> >> >> >> > >> >>>>> >> >> >> > wrote: >> >>>>> >> >> >> >> >> >>>>> >> >> >> >> How exactly does Gradle package *.so files in an APK? I >> >>>>> >> >> >> >> know >> >>>>> >> >> >> >> that >> >>>>> >> >> >> >> ANT >> >>>>> >> >> >> >> used to do this for any libs under "libs/". Does >> >>>>> >> >> >> >> Gradle >> >>>>> >> >> >> >> do >> >>>>> >> >> >> >> some >> >>>>> >> >> >> >> introspection into CMake targets to see if outputs are >> >>>>> >> >> >> >> *.so, >> >>>>> >> >> >> >> and >> >>>>> >> >> >> >> copy >> >>>>> >> >> >> >> those to some location if needed? What about libraries >> >>>>> >> >> >> >> like >> >>>>> >> >> >> >> libgnustl_shared.so that come with the NDK? I'd like to >> >>>>> >> >> >> >> know >> >>>>> >> >> >> >> if >> >>>>> >> >> >> >> any >> >>>>> >> >> >> >> manual copy steps are needed in CMake to put outputs in >> >>>>> >> >> >> >> proper >> >>>>> >> >> >> >> locations for the APK build step. I had to do this when >> >>>>> >> >> >> >> using >> >>>>> >> >> >> >> ANT. >> >>>>> >> >> >> >> >> >>>>> >> >> >> >> On Mon, Aug 7, 2017 at 6:16 PM, Jom O'Fisher >> >>>>> >> >> >> >> >> >>>>> >> >> >> >> wrote: >> >>>>> >> >> >> >> > 1) There is a folder created for each ABI under the >> >>>>> >> >> >> >> > project >> >>>>> >> >> >> >> > module >> >>>>> >> >> >> >> > folder >> >>>>> >> >> >> >> > (so unique per module per ABI) >> >>>>> >> >> >> >> > 2) Gradle doesn't specify language level though you >> >>>>> >> >> >> >> > can >> >>>>> >> >> >> >> > choose >> >>>>> >> >> >> >> > to >> >>>>> >> >> >> >> > specify it >> >>>>> >> >> >> >> > yourself from the build.gradle. This doc does a pretty >> >>>>> >> >> >> >> > good job >> >>>>> >> >> >> >> > of >> >>>>> >> >> >> >> > explaining which variables are set by Gradle: >> >>>>> >> >> >> >> > >> >>>>> >> >> >> >> > >> >>>>> >> >> >> >> > https://developer.android.com/ndk/guides/cmake.html#variables. >> >>>>> >> >> >> >> > Philosophically, we try to set as little as we can get >> >>>>> >> >> >> >> > away >> >>>>> >> >> >> >> > with. >> >>>>> >> >> >> >> > In >> >>>>> >> >> >> >> > particular, the section titled "Understanding the >> >>>>> >> >> >> >> > CMake >> >>>>> >> >> >> >> > build >> >>>>> >> >> >> >> > command" >> >>>>> >> >> >> >> > lays >> >>>>> >> >> >> >> > out exactly what we set. You can also see the folders >> >>>>> >> >> >> >> > we >> >>>>> >> >> >> >> > specify >> >>>>> >> >> >> >> > (one >> >>>>> >> >> >> >> > per >> >>>>> >> >> >> >> > module per ABI) >> >>>>> >> >> >> >> > 3) Not sure I understand this. >> >>>>> >> >> >> >> > >> >>>>> >> >> >> >> > The other document worth taking a look at (if you >> >>>>> >> >> >> >> > haven't >> >>>>> >> >> >> >> > already) >> >>>>> >> >> >> >> > is: >> >>>>> >> >> >> >> > >> >>>>> >> >> >> >> > >> >>>>> >> >> >> >> > >> >>>>> >> >> >> >> > https://developer.android.com/studio/projects/add-native-code.html >> >>>>> >> >> >> >> > >> >>>>> >> >> >> >> > >> >>>>> >> >> >> >> > On Mon, Aug 7, 2017 at 3:35 PM, Robert Dailey >> >>>>> >> >> >> >> > >> >>>>> >> >> >> >> > wrote: >> >>>>> >> >> >> >> >> >> >>>>> >> >> >> >> >> Thanks Jom >> >>>>> >> >> >> >> >> >> >>>>> >> >> >> >> >> Honestly, I prefer option 1 to work simply because >> >>>>> >> >> >> >> >> that's >> >>>>> >> >> >> >> >> how >> >>>>> >> >> >> >> >> Google's >> >>>>> >> >> >> >> >> officially supporting CMake. But it also has >> >>>>> >> >> >> >> >> debugging >> >>>>> >> >> >> >> >> which >> >>>>> >> >> >> >> >> is >> >>>>> >> >> >> >> >> the >> >>>>> >> >> >> >> >> #1 >> >>>>> >> >> >> >> >> reason for me. >> >>>>> >> >> >> >> >> >> >>>>> >> >> >> >> >> However, I'd like to understand a lot more about how >> >>>>> >> >> >> >> >> the >> >>>>> >> >> >> >> >> integration >> >>>>> >> >> >> >> >> really happens. For example, I have these questions: >> >>>>> >> >> >> >> >> >> >>>>> >> >> >> >> >> 1) How, internally, are CMake build directories >> >>>>> >> >> >> >> >> managed? >> >>>>> >> >> >> >> >> Do >> >>>>> >> >> >> >> >> you >> >>>>> >> >> >> >> >> generate 1 per unique android project? What about for >> >>>>> >> >> >> >> >> each >> >>>>> >> >> >> >> >> specific >> >>>>> >> >> >> >> >> platform (x86, armeabi-v7a, etc)? >> >>>>> >> >> >> >> >> 2) Last time I looked into CMake integration, things >> >>>>> >> >> >> >> >> defined >> >>>>> >> >> >> >> >> inside >> >>>>> >> >> >> >> >> the CMake scripts were ignored because they are >> >>>>> >> >> >> >> >> specified >> >>>>> >> >> >> >> >> at >> >>>>> >> >> >> >> >> the >> >>>>> >> >> >> >> >> command line. Namely, all of those settings that are >> >>>>> >> >> >> >> >> driven by >> >>>>> >> >> >> >> >> the >> >>>>> >> >> >> >> >> Gradle configuration (CXX language level was one in >> >>>>> >> >> >> >> >> particular >> >>>>> >> >> >> >> >> I >> >>>>> >> >> >> >> >> think; I specify C++14 support via CMake, but I >> >>>>> >> >> >> >> >> recall >> >>>>> >> >> >> >> >> this >> >>>>> >> >> >> >> >> being >> >>>>> >> >> >> >> >> overridden from outside)? >> >>>>> >> >> >> >> >> 3) How redundant is it to configure individual >> >>>>> >> >> >> >> >> libraries >> >>>>> >> >> >> >> >> via >> >>>>> >> >> >> >> >> the >> >>>>> >> >> >> >> >> gradle scripts? In my previous attempts, I wanted to >> >>>>> >> >> >> >> >> define >> >>>>> >> >> >> >> >> common >> >>>>> >> >> >> >> >> stuff for CMake / native code at the root gradle or >> >>>>> >> >> >> >> >> settings >> >>>>> >> >> >> >> >> file, >> >>>>> >> >> >> >> >> and >> >>>>> >> >> >> >> >> only define the differences in the actual gradle >> >>>>> >> >> >> >> >> build >> >>>>> >> >> >> >> >> files >> >>>>> >> >> >> >> >> for >> >>>>> >> >> >> >> >> each >> >>>>> >> >> >> >> >> corresponding Java target (like, defining the name of >> >>>>> >> >> >> >> >> the >> >>>>> >> >> >> >> >> native >> >>>>> >> >> >> >> >> (shared library) target in Gradle, but the command >> >>>>> >> >> >> >> >> line >> >>>>> >> >> >> >> >> invocation, >> >>>>> >> >> >> >> >> -D >> >>>>> >> >> >> >> >> CMake settings, etc would all be common and defined >> >>>>> >> >> >> >> >> at >> >>>>> >> >> >> >> >> the >> >>>>> >> >> >> >> >> root). >> >>>>> >> >> >> >> >> >> >>>>> >> >> >> >> >> The TLDR is, the closer we can stay to CMake's way of >> >>>>> >> >> >> >> >> doing >> >>>>> >> >> >> >> >> things >> >>>>> >> >> >> >> >> and >> >>>>> >> >> >> >> >> keep CMake-related settings self-contained to the >> >>>>> >> >> >> >> >> CMake >> >>>>> >> >> >> >> >> scripts >> >>>>> >> >> >> >> >> themselves, the better. This also makes >> >>>>> >> >> >> >> >> cross-platform >> >>>>> >> >> >> >> >> easier >> >>>>> >> >> >> >> >> (we >> >>>>> >> >> >> >> >> build the native code in Windows, for example, so >> >>>>> >> >> >> >> >> having >> >>>>> >> >> >> >> >> settings >> >>>>> >> >> >> >> >> specified in the gradle files do not carry over to >> >>>>> >> >> >> >> >> other >> >>>>> >> >> >> >> >> platforms. >> >>>>> >> >> >> >> >> Namely, settings that are not platform specific like >> >>>>> >> >> >> >> >> the >> >>>>> >> >> >> >> >> C++ >> >>>>> >> >> >> >> >> language >> >>>>> >> >> >> >> >> level). >> >>>>> >> >> >> >> >> >> >>>>> >> >> >> >> >> If there's a detailed document / wiki I can read on >> >>>>> >> >> >> >> >> the >> >>>>> >> >> >> >> >> intrinsics >> >>>>> >> >> >> >> >> of >> >>>>> >> >> >> >> >> CMake integration in Gradle / Android Studio, I'd >> >>>>> >> >> >> >> >> love to >> >>>>> >> >> >> >> >> read >> >>>>> >> >> >> >> >> it. >> >>>>> >> >> >> >> >> Otherwise, I hope you won't mind if I pick your brain >> >>>>> >> >> >> >> >> as >> >>>>> >> >> >> >> >> questions >> >>>>> >> >> >> >> >> come up. I think I'm going to try option 1 for now >> >>>>> >> >> >> >> >> and >> >>>>> >> >> >> >> >> see how >> >>>>> >> >> >> >> >> it >> >>>>> >> >> >> >> >> goes. It's just black box for me because unlike >> >>>>> >> >> >> >> >> option 2, >> >>>>> >> >> >> >> >> I >> >>>>> >> >> >> >> >> have >> >>>>> >> >> >> >> >> very >> >>>>> >> >> >> >> >> little control over what happens after building the >> >>>>> >> >> >> >> >> shared >> >>>>> >> >> >> >> >> libraries, >> >>>>> >> >> >> >> >> and to make up for that I need to really get a deep >> >>>>> >> >> >> >> >> understanding >> >>>>> >> >> >> >> >> of >> >>>>> >> >> >> >> >> how it works so I can make sure I code my CMake >> >>>>> >> >> >> >> >> scripts >> >>>>> >> >> >> >> >> properly >> >>>>> >> >> >> >> >> for >> >>>>> >> >> >> >> >> not only Android, but my other platforms as well >> >>>>> >> >> >> >> >> (non-Android >> >>>>> >> >> >> >> >> platforms). >> >>>>> >> >> >> >> >> >> >>>>> >> >> >> >> >> Thanks again. >> >>>>> >> >> >> >> >> >> >>>>> >> >> >> >> >> On Mon, Aug 7, 2017 at 5:12 PM, Jom O'Fisher >> >>>>> >> >> >> >> >> >> >>>>> >> >> >> >> >> wrote: >> >>>>> >> >> >> >> >> > Either option can work fine. Disclosure: I work on >> >>>>> >> >> >> >> >> > Android >> >>>>> >> >> >> >> >> > Studio >> >>>>> >> >> >> >> >> > and >> >>>>> >> >> >> >> >> > was >> >>>>> >> >> >> >> >> > the one that added CMake support. >> >>>>> >> >> >> >> >> > >> >>>>> >> >> >> >> >> > Option (1) is the way it's designed to work and >> >>>>> >> >> >> >> >> > we're >> >>>>> >> >> >> >> >> > working >> >>>>> >> >> >> >> >> > toward >> >>>>> >> >> >> >> >> > getting >> >>>>> >> >> >> >> >> > rid of the need for the CMake fork. I can't really >> >>>>> >> >> >> >> >> > say >> >>>>> >> >> >> >> >> > when >> >>>>> >> >> >> >> >> > that >> >>>>> >> >> >> >> >> > will >> >>>>> >> >> >> >> >> > happen >> >>>>> >> >> >> >> >> > but if you can get away with an older CMake for now >> >>>>> >> >> >> >> >> > then I'd >> >>>>> >> >> >> >> >> > go >> >>>>> >> >> >> >> >> > this >> >>>>> >> >> >> >> >> > way. >> >>>>> >> >> >> >> >> > As you mentioned, option (1) will allow you to view >> >>>>> >> >> >> >> >> > your >> >>>>> >> >> >> >> >> > source >> >>>>> >> >> >> >> >> > file >> >>>>> >> >> >> >> >> > structure in Android Studio, edit files, and debug >> >>>>> >> >> >> >> >> > using the >> >>>>> >> >> >> >> >> > built-in >> >>>>> >> >> >> >> >> > debugging support. >> >>>>> >> >> >> >> >> > >> >>>>> >> >> >> >> >> > To get option (2) to work, you can use jniDirs >> >>>>> >> >> >> >> >> > setting >> >>>>> >> >> >> >> >> > to >> >>>>> >> >> >> >> >> > tell >> >>>>> >> >> >> >> >> > Android >> >>>>> >> >> >> >> >> > Gradle where to pick up your built .so files (see >> >>>>> >> >> >> >> >> > >> >>>>> >> >> >> >> >> > >> >>>>> >> >> >> >> >> > >> >>>>> >> >> >> >> >> > >> >>>>> >> >> >> >> >> > >> >>>>> >> >> >> >> >> > >> >>>>> >> >> >> >> >> > >> >>>>> >> >> >> >> >> > https://stackoverflow.com/questions/21255125/how-can-i-add-so-files-to-an-android-library-project-using-gradle-0-7). >> >>>>> >> >> >> >> >> > I'm not aware of any projects that use this >> >>>>> >> >> >> >> >> > approach >> >>>>> >> >> >> >> >> > but it >> >>>>> >> >> >> >> >> > should >> >>>>> >> >> >> >> >> > work >> >>>>> >> >> >> >> >> > in >> >>>>> >> >> >> >> >> > principal. >> >>>>> >> >> >> >> >> > >> >>>>> >> >> >> >> >> > I hope this helps, >> >>>>> >> >> >> >> >> > Jomo >> >>>>> >> >> >> >> >> > >> >>>>> >> >> >> >> >> > >> >>>>> >> >> >> >> >> > On Mon, Aug 7, 2017 at 11:09 AM, Robert Dailey >> >>>>> >> >> >> >> >> > >> >>>>> >> >> >> >> >> > wrote: >> >>>>> >> >> >> >> >> >> >> >>>>> >> >> >> >> >> >> Right now I have custom targets set to execute the >> >>>>> >> >> >> >> >> >> "ant >> >>>>> >> >> >> >> >> >> release" >> >>>>> >> >> >> >> >> >> command after my native targets are built. Part of >> >>>>> >> >> >> >> >> >> that >> >>>>> >> >> >> >> >> >> command >> >>>>> >> >> >> >> >> >> involves copying *.so files to the >> >>>>> >> >> >> >> >> >> libs/armeabi-v7a >> >>>>> >> >> >> >> >> >> directory >> >>>>> >> >> >> >> >> >> so >> >>>>> >> >> >> >> >> >> they >> >>>>> >> >> >> >> >> >> get packaged in an APK. >> >>>>> >> >> >> >> >> >> >> >>>>> >> >> >> >> >> >> When switching to gradle, I have two options: >> >>>>> >> >> >> >> >> >> >> >>>>> >> >> >> >> >> >> 1. Gradle drives CMake: This means using Android >> >>>>> >> >> >> >> >> >> Studio and >> >>>>> >> >> >> >> >> >> being >> >>>>> >> >> >> >> >> >> locked down to Google's fork of CMake which is a >> >>>>> >> >> >> >> >> >> few >> >>>>> >> >> >> >> >> >> major >> >>>>> >> >> >> >> >> >> releases >> >>>>> >> >> >> >> >> >> behind. I see that as a negative. >> >>>>> >> >> >> >> >> >> >> >>>>> >> >> >> >> >> >> 2. CMake drives Gradle: This would be the same or >> >>>>> >> >> >> >> >> >> similar >> >>>>> >> >> >> >> >> >> to >> >>>>> >> >> >> >> >> >> what >> >>>>> >> >> >> >> >> >> I'm >> >>>>> >> >> >> >> >> >> already doing: The custom targets I have would >> >>>>> >> >> >> >> >> >> execute >> >>>>> >> >> >> >> >> >> gradle >> >>>>> >> >> >> >> >> >> as >> >>>>> >> >> >> >> >> >> a >> >>>>> >> >> >> >> >> >> separate build step, instead of running ant >> >>>>> >> >> >> >> >> >> commands. >> >>>>> >> >> >> >> >> >> I'm >> >>>>> >> >> >> >> >> >> not >> >>>>> >> >> >> >> >> >> too >> >>>>> >> >> >> >> >> >> familiar with Gradle, so I'm not sure how you tell >> >>>>> >> >> >> >> >> >> it >> >>>>> >> >> >> >> >> >> where >> >>>>> >> >> >> >> >> >> your >> >>>>> >> >> >> >> >> >> shared libraries are for the APK packaging steps. >> >>>>> >> >> >> >> >> >> >> >>>>> >> >> >> >> >> >> Which does everyone recommend? Is anyone using one >> >>>>> >> >> >> >> >> >> of >> >>>>> >> >> >> >> >> >> these >> >>>>> >> >> >> >> >> >> setups >> >>>>> >> >> >> >> >> >> successfully? The downside to option 2 is probably >> >>>>> >> >> >> >> >> >> no >> >>>>> >> >> >> >> >> >> on-device >> >>>>> >> >> >> >> >> >> native >> >>>>> >> >> >> >> >> >> debugging since Android Studio probably can't >> >>>>> >> >> >> >> >> >> handle >> >>>>> >> >> >> >> >> >> gradle >> >>>>> >> >> >> >> >> >> projects >> >>>>> >> >> >> >> >> >> without any external CMake builds set up. >> >>>>> >> >> >> >> >> >> >> >>>>> >> >> >> >> >> >> Would like some general direction & advice before >> >>>>> >> >> >> >> >> >> I >> >>>>> >> >> >> >> >> >> move >> >>>>> >> >> >> >> >> >> away >> >>>>> >> >> >> >> >> >> from >> >>>>> >> >> >> >> >> >> ANT. Thanks in advance. >> >>>>> >> >> >> >> >> >> -- >> >>>>> >> >> >> >> >> >> >> >>>>> >> >> >> >> >> >> Powered by www.kitware.com >> >>>>> >> >> >> >> >> >> >> >>>>> >> >> >> >> >> >> Please keep messages on-topic and check the CMake >> >>>>> >> >> >> >> >> >> FAQ >> >>>>> >> >> >> >> >> >> at: >> >>>>> >> >> >> >> >> >> http://www.cmake.org/Wiki/CMake_FAQ >> >>>>> >> >> >> >> >> >> >> >>>>> >> >> >> >> >> >> Kitware offers various services to support the >> >>>>> >> >> >> >> >> >> CMake >> >>>>> >> >> >> >> >> >> community. >> >>>>> >> >> >> >> >> >> For >> >>>>> >> >> >> >> >> >> more >> >>>>> >> >> >> >> >> >> information on each offering, please visit: >> >>>>> >> >> >> >> >> >> >> >>>>> >> >> >> >> >> >> CMake Support: >> >>>>> >> >> >> >> >> >> http://cmake.org/cmake/help/support.html >> >>>>> >> >> >> >> >> >> CMake Consulting: >> >>>>> >> >> >> >> >> >> http://cmake.org/cmake/help/consulting.html >> >>>>> >> >> >> >> >> >> CMake Training Courses: >> >>>>> >> >> >> >> >> >> http://cmake.org/cmake/help/training.html >> >>>>> >> >> >> >> >> >> >> >>>>> >> >> >> >> >> >> Visit other Kitware open-source projects at >> >>>>> >> >> >> >> >> >> http://www.kitware.com/opensource/opensource.html >> >>>>> >> >> >> >> >> >> >> >>>>> >> >> >> >> >> >> Follow this link to subscribe/unsubscribe: >> >>>>> >> >> >> >> >> >> http://public.kitware.com/mailman/listinfo/cmake >> >>>>> >> >> >> >> >> > >> >>>>> >> >> >> >> >> > >> >>>>> >> >> >> >> > >> >>>>> >> >> >> >> > >> >>>>> >> >> >> > >> >>>>> >> >> >> > >> >>>>> >> >> > >> >>>>> >> >> > >> >>>>> >> > >> >>>>> >> > >> >>>>> > >> >>>>> > >> >>>> >> >>>> >> >>> >> >> > > From andrew.bell.ia at gmail.com Wed Aug 23 16:21:17 2017 From: andrew.bell.ia at gmail.com (Andrew Bell) Date: Wed, 23 Aug 2017 16:21:17 -0400 Subject: [CMake] Regex Matching Message-ID: Hi, Can someone please explain the cmake regex matching rules? The following returns true: if ("This is a test" MATCHES "test") I would have expected to have needed something like this to get a match: if ("This is a test" MATCHES ".*test") Does cmake always search for a subexpression? Is there some way to prevent this behaivor? Thanks, -- Andrew Bell andrew.bell.ia at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From nilsgladitz at gmail.com Wed Aug 23 16:27:36 2017 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Wed, 23 Aug 2017 22:27:36 +0200 Subject: [CMake] Regex Matching In-Reply-To: References: Message-ID: On 23.08.2017 22:21, Andrew Bell wrote: > Hi, > > Can someone please explain the cmake regex matching rules? > > The following returns true: > > if ("This is a test" MATCHES "test") > > I would have expected to have needed something like this to get a match: > > if ("This is a test" MATCHES ".*test") > > Does cmake always search for a subexpression? Is there some way to > prevent this behaivor? The regex syntax is documented here: https://cmake.org/cmake/help/latest/command/string.html#regex-specification if ("This is a test" MATCHES "^test") Would match "test" only at the beginning of the input. Nils From bitminer at gmail.com Wed Aug 23 16:50:21 2017 From: bitminer at gmail.com (Brian Davis) Date: Wed, 23 Aug 2017 15:50:21 -0500 Subject: [CMake] Interface Libraries allow include directories but not link directories.. Why? In-Reply-To: References: Message-ID: On Wed, Aug 23, 2017 at 2:07 AM, Cl?ment Gregoire wrote: > I can't argue too much why paths or absolute on cmake as I don't know the > rationale behind it is. While your point about command line limit makes > sense, I feel like a system limiting command line size to this extent is > dumb if it doesn't allow reading more arguments through a file. (again, I > don't know the system at all). > My command line problem experience stems from two problems: 1) building ITK as a superproject/superbuild within my project and from within VMTK which also used ITK in a superbuild.. well and building VMTK superbuild inside my superbuild project. Yes it's a Russian dolls/onion of superbuilds. Boy I would also like to comment on those problems, but that will be for a different post. 2) My somewhat successful (I say somewhat as appose to ideal) ExternalProject_Add build of boost from git repo where setting boost build command at the cmd prompt vs within VS studio. I had to resort to CMD prompt to eak out those last bits-o-chars. Ahh yes here it is from my CMake files: # Does not work as command path length is too long. # add_custom_target( # boost_build_target # "echo ${BUILD_BOOST_CMD}; ${BUILD_BOOST_CMD}" # WORKING_DIRECTORY ${BOOST_SOURCE_DIR} ) I kinda understand your point about not being able to set the libdir per > target but (might have missed it in your previous mails) I don't know what > kind of project would need that. At best I would need one version of the > library per configuration, which is supported. > Ok here goes as I would really like people to understand my problems with the current CMake impl then possibly I could be awed by the logic of CMake and stand corrected .... or possibly ... just possibly I am correct and CMake could change course. First off there is some inconsistencies in the logic of the design / impl of CMake from my perspective if we look at the new target/properties and statements from 3rd parties (pdf mentioned earlier) as to the direction /logic of CMake. 1) find_library forces user down a path of abs paths and does not allow the return of the path in the event the user wants to pass the path to LINK_DIRECTORIES. Which coupled with my path problems I chose/forced not to use find_library. Ok so like I said I could build of off C:\ so I'll give CMake that. CMake forces full abs paths for every lib specified even for those of us who don't want it / can't use it in find_library. Why not have find_library return two (2) VARS one for lib and other for path and provide option to user and state the WHY the user should choose abs paths. Then I could argue the WHY problem directly, but still have an out for LINK_DIRECTORIES/LIBPATH use. However CMake forced the abs full path on every lib issue and has not provide a *good* mechanism to the alternative. 2) find_library is as I am sure CMake would agree is not under the target/property new design. Say the target is targ and the property is the library path, but find_library is all or nothing and a CMake variable. Where CMake variables if pdf is to be believed is not under the new CMake "don't use variables" design philosophy. Not that I know what the actual Design of CMake is or should be and I would certainly like to hear that and have CMake resolve this discrepancy. 3) In VS (well in Linux for that matter) can set include paths and I can set LIBPATH(s) on targets. In CMake I can set include_directories on targets but not lib paths. However I can get around this and do by using LIBRARY_PATH which is at the directory level. CMake should expose always the underlying abilities of the tools to the user and guide to the best use for sure, but never force... and I am seemingly forced to do an illogical end-around (go to directory scope to set what should be a target property). As to: "I kinda understand your point about not being able to set the libdir per target but (might have missed it in your previous mails) I don't know what kind of project would need that" How about projects for which boost and find_package(Boost) (<- Beware of caps when using boost and find_package yes it's case sensitive) is used? #+----------------------------------------------------------------------------- set( BOOST_LIBS Boost::boost Boost::system Boost::date_time Boost::filesystem Boost::serialization ) add_library( boost_interface INTERFACE ) target_include_directories( boost_interface INTERFACE ${BOOST_INCLUDE_DIR} ) target_link_libraries( boost_interface INTERFACE ${BOOST_LIBS} ) #+----------------------------------------------------------------------------- And yes all my boost use needs at least those libs other opts to create another interface for inheritance based on other lib use is certainly possible. I have a mixed mode CMake generated vsprojs and existing vsprojs files where include_external_msproject is used for some projects: #------------------------------------------------------------------------------ add_library( 4duiplugin_interface INTERFACE ) target_include_directories( 4duiplugin_interface INTERFACE ${4DUI_PLUGIN_DIR} ) add_library( utilities_interface INTERFACE ) target_link_libraries( utilities_interface INTERFACE optimized ${TOP}/build/x64/Release/Libraries/Utilities.lib debug ${TOP}/build/x64/Debug/Libraries/Utilities.lib ) target_include_directories( utilities_interface INTERFACE ${4DFUTILITIES_INCLUDE_DIR} ) add_library( dicomreader_interface INTERFACE ) target_link_libraries( dicomreader_interface INTERFACE optimized ${TOP}/build/x64/Release/Libraries/DicomReader.lib debug ${TOP}/build/x64/Debug/Libraries/DicomReader.lib ) #------------------------------------------------------------------------------ Why cannot I set say: target_library_directories( utilities_interface INTERFACE optimized ${TOP}/build/x64/Release/Libraries debug ${TOP}/build/x64/Debug/Libraries ) Note use of only directories above and use of unavailable target_library_directory to set LIBPATH where it could search out duplicate paths before chucking at the linker. find_library certainly can't do it as is uses abs paths. While abs paths are used above and certainly could by target/property'izing LIB_DR this could give CMake an "out" to the command line length problem by filtering for unique before setting LIBPATH. Hey CMake could even provide an ABSOLUTE command in target_link_directories and state some gibberish as to how/why absolute long paths for every library is better... not that I buy it now and will not then either. Then used sometime later: target_link_libraries( ${SOME_LIB} 4dfutilities_interface 4dfdicomreader_interface cuda_sdk_interface boost_interface shaderslib_interface # vtk_interface vmtk_interface ) Also cmake 3.7/3.8//3.9 started to support CUDA as a first class language. Now the question: do I use: project( prjname CXX CUDA) or find_package(CUDA 9.0) or both? well I in the spirit of new CMake I chose project. But now the question... how does CMake 3.9 support finding the cudart.lib (or cudafft) or say libs in the SDK( such as gluts or glews or FreeImage). Well the answer as far as I can tell ... it does not. It's not documented and so I checked out the 3.9 source and I am reverse engineering it to figure out how it works or what works and does not and what is impled/not impled. So what's a CMake 3.+'er (me) to do? (well after crying as to the state of things) I could: # ----------------------------------------------------------------------------- add_library( cuda_toolkit_interface INTERFACE ) target_include_directories( cuda_toolkit_interface INTERFACE ${CUDA_TOOLKIT_LIB_DIR} ) target_link_libraries( cuda_toolkit_interface INTERFACE cuda_rt_static ) add_library( cuda_sdk_interface INTERFACE ) target_include_directories( cuda_sdk_interface INTERFACE ${CUDA_SDK_INCLUDE_DIR} ) # ----------------------------------------------------------------------------- then when linking a target that needs said inherited build properties I could: target_link_libraries( rendertest PRIVATE cuda_toolkit_interface cuda_sdk_interface boost_interface opengl_interface shaderslib ) say for any target needing cuda. I entirely agree with for the rest. CMake badly documenting good practices > or even giving tutorials is an issue. Probably the biggest issue I found. I > myself still fight after years of using and experimenting with it. This > lead to a plethora of badly written cmakelists.txt or module scripts, that > even people in this list still advocates without understanding the problems > behind it. Even some tutorial series found on github.com or used by > coverage websites do it wrong. > Yes glad and at the same time sorry to hear someone has had some of the same experience I have had and I say these things in hopes CMake will get fixed/better, but hey again maybe I am wrong. I have been rewriting my CMake files to support new target/properties and for the most part I no longer have to use my parameterized variables and custom project macros (add_project_config, add_project_executable, and add_project_library - which sadly had to use LINK_DIRECTORIES) with VAR ARGS parsing to get the concept of "inherited build properties" based on my jam experience from Boost.Build... so kudos to CMake for that if only for LIBPATH an hence the post. Sadly I knew the answer even before I asked the question based on using CMake since 2009 and even giving a teaching lecture on it to promote it's use where I also promoted inherited build properties even though CMake at at the time did not support it directly. > At the moment the only reference I trust is Daniel's presentation and some > of the internal cmake scripts. > > While not solving your problem, I documented most of my findings in this > small template /reference https://github.com/Lectem/cpp-boilerplate > (which might still do things the wrong way) > Yes just at line 22 I already have a problem.... that did not take long. 1) project does not specify VERSION and project name "CPP-BoilerPlate" does not incorporate ver string such as SET(MAJOR_VERSION 1) SET(MINOR_VERSION 2) SET(MAINTENANCE_VERSION 3) and then project( "CPP-BoilerPlate-${MAJOR_VERSION}.${MINOR_VERSION}.${MAINTENANCE _VERSION}" VERSION ${MAJOR_VERSION}.${MINOR_VERSION}.${MAINTENANCE_VERSION} C CXX) as what is CMAKE_INSTALL_PREFIX by default across versions? What does VERSION do in project? Well I know what it does not affect... yep CMAKE_INSTALL_PREFIX. Try compiling and installing on Windows multiple versions of this project see what you get. 3rd party package developers end up blasting away prior versions... maybe by design but who knows in my experience (IME). Again though not as though CMake discusses "best practices" here or make VERSION actually do something useful as say append to CMAKE_INSTALL_PREFIX ${MAJOR_VERSION}.${MINOR_VERSION}.${MAINTENANCE_VERSION}. Thanks for the link/resource I take form it any good bits I can use at 157 lines it is not all that realistic of a full blown project with multiple dependencies mixed mode VS projs and CMake gen projs and other real world shenanigans. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jomofisher at gmail.com Wed Aug 23 17:20:15 2017 From: jomofisher at gmail.com (Jom O'Fisher) Date: Wed, 23 Aug 2017 14:20:15 -0700 Subject: [CMake] CMake + Gradle for Android In-Reply-To: References: Message-ID: By gradle module projects, I just mean the leaf build.gradle files as opposed to the root build.gradle. By configurations, I mean Build Types (debug vs release) and Product Flavors (demo vs free vs paid). Hereafter I will use the term "variant" rather than "configuration" to be precise. See this write-up on build variants: https://developer.android.com/studio/build/build-variants.html#build-types This build matrix is constructed at the leaf build.gradle level. Native build in gradle allows you to set C/C++ flags individually for each variant so that you can define compiler flags (for example, -DFREE_VERSION). One thing to notice at this stage is that the same CMake target may be built with different compiler flags across different projects, build types, and product flavors. So in the general case, build outputs won't be the same. You asked which targets build when specifying path. By default, we build all targets that produce an .so. You can override this by setting externalNativeBuild.cmake.targets. For example, paid { ... externalNativeBuild { cmake { ... targets "native-lib-paid" } } } As for your last question, the model we generally see used is that the main CMakeLists.txt is next to the leaf build.gradle such that this CMakeLists.txt doesn't couple with peer APK project CMakeLists.txt (though they may share common dependencies and settings). Otherwise, multiple APK projects would perform pretty much similar to yours--they would build targets per-leaf project and not share build outputs. As far as I can see your organization is just as valid so long as you only build the targets you need. Regarding native dependencies between java projects. We generally try to avoid making the CMake build depend on the gradle build (you should be able to replicate the CMake build from the command-line if you set the right flags). At the moment I don't see a way we could make things better without violating that tenet but that could be lack of imagination on my part. We'll definitely be discussing this use case at our next C++ meeting and I'll also be checking for myself whether ccache will work in this CMake scenario. If ccache does work it seems like the natural level at which to fold identical builds. On Wed, Aug 23, 2017 at 1:03 PM, Robert Dailey wrote: > I'm not sure what you mean by "gradle module projects", but maybe > having some examples of what you mean by "configurations, C++ flags, > etc" might make it more clear. > > Question: When specifying "path" for the CMakeLists.txt in the > build.gradle file, how do you know which targets to build? For > example, that run of CMake may generate 100 targets, but only 20 need > to build and be packaged (*.so files) with the APK. Do you just build > "all"? Is there a way to specify the target itself? > > Thanks again. I'd still like to know more about what the ideal > organization is. I find it hard to believe that large android projects > rarely break things up into multiple, separate "components" that are > built independently. That's really the gist of what we're dealing with > here. Your typical "hello world" project likely will have only 1 > CMakeLists.txt that is pretty self-contained, but all the > documentation I've looked at so far doesn't show the best way to > handle native library dependencies across java projects between > build.gradle files (or maybe I'm just not looking hard enough). > > On Wed, Aug 23, 2017 at 1:02 PM, Jom O'Fisher > wrote: > > Thanks for the write-up Robert. Having thought about it, I don't believe > we > > have a satisfying answer at the gradle level for this kind of > organization. > > In the gradle model module projects are the unit of organization for > > configurations, C/C++ flags, etc. and that's something we're pretty much > > stuck with. > > Regarding just the redundant build issue, would something like ccache > help? > > I know people have used it with ndk-build with success, I'm not sure > about > > CMake but I don't see why that should make a difference. > > > > > > > > On Tue, Aug 22, 2017 at 10:27 AM, Robert Dailey < > rcdailey.lists at gmail.com> > > wrote: > >> > >> Another reason to reduce the number of binary directories is that > >> there are different ways of managing third party libraries. One in > >> particular that we use is to clone a repository into the binary > >> directory and build all third party libs in real time based on a > >> toolchain file (Similar to the functionality provided by > >> ExternalProject module in CMake). This is repeated from scratch only > >> if the work hasn't already been done in the binary directory before. > >> By having more binary dirs than needed, this work is being done an > >> exponential amount of times which can result in a lot of wasted time > >> waiting. There are 1 time operations that multiple targets can benefit > >> from in a single binary tree, instead of 1 per unique target being > >> invoked. > >> > >> Sorry to keep responding: I'm just thinking of things as I go and > >> bringing them up, to shed light on some of the reasoning behind my > >> suggestions. > >> > >> On Tue, Aug 22, 2017 at 9:26 AM, Robert Dailey < > rcdailey.lists at gmail.com> > >> wrote: > >> > Sorry I forgot to answer your last set of questions: > >> > > >> > CommonLib is indeed 2 things: > >> > > >> > * A common (static or shared) library for native code (most of our > >> > CMake targets specify CommonLib as a link dependency) > >> > * A common library for Java code (we do specify this as a dependency > >> > for most java targets in Gradle, specifically those under > >> > Applications/) > >> > > >> > On Mon, Aug 21, 2017 at 6:20 PM, Raymond Chiu > wrote: > >> >> Hi Robert, > >> >> > >> >> I work with Jom on the Android Studio team, and I would like to > clarify > >> >> a > >> >> few things to better understand your situation. > >> >> You mentioned the project is intend to be cross platform. Normally, > in > >> >> such > >> >> situation, we expect there to be a single CMake root project to be > >> >> imported > >> >> into one of the Android library/application. However, in your case, > >> >> there > >> >> are subprojects with Java code. > >> >> > >> >> Are the CMake code in App1/2/3 intended to be cross platform too? Or > >> >> are > >> >> they Android specific code? If they are meant to be cross platform, > >> >> how > >> >> does the Java code works on other platforms? Or perhaps you added > Java > >> >> binding in those subprojects just for Android? > >> >> > >> >> The build.gradle in CommonLib, what kind of Gradle project is that? > >> >> From > >> >> your description, it doesn't look like an Android library project. > Or > >> >> am I > >> >> mistaken and it also applies the android library plugin? > >> >> > >> >> Raymond > >> >> > >> >> On Mon, Aug 21, 2017 at 3:34 PM, Jom O'Fisher > >> >> wrote: > >> >>> > >> >>> + a colleague > >> >>> > >> >>> On Mon, Aug 21, 2017 at 3:11 PM, Jom O'Fisher > > >> >>> wrote: > >> >>>> > >> >>>> You can find that number like this: > >> >>>> - x = number of externalNativeBuild.cmake.path in your build.gradle > >> >>>> files > >> >>>> - y = number of gradle configurations (like debug and release) > >> >>>> - z = number of ABIs that you build > >> >>>> > >> >>>> The result is x * y * z. To be more accurate, you should consider y > >> >>>> and z > >> >>>> to be functions of each build.gradle file since these can vary. > >> >>>> > >> >>>> There is a second set of folders that hold the stripped versions of > >> >>>> the > >> >>>> .so files that is purely managed by the android gradle plugin, so > you > >> >>>> might > >> >>>> consider the answer to be 2 * x * y * z. > >> >>>> > >> >>>> Hope this helps. > >> >>>> > >> >>>> > >> >>>> > >> >>>> > >> >>>> > >> >>>> > >> >>>> On Mon, Aug 21, 2017 at 2:41 PM, Robert Dailey > >> >>>> > >> >>>> wrote: > >> >>>>> > >> >>>>> This definitely a bit better, but still requires the boilerplate > in > >> >>>>> each leaf gradle file. But I can't seriously complain too much. I > >> >>>>> think I'm more concerned with the implications this has > underneath. > >> >>>>> First, let me ask just to make sure I'm not misunderstanding: Does > >> >>>>> each `externalNativeBuild` entry essentially mean 1 > >> >>>>> CMAKE_BINARY_DIR? > >> >>>>> How many binary dirs do you manage internally and what determines > >> >>>>> when > >> >>>>> they get created? > >> >>>>> > >> >>>>> On Mon, Aug 21, 2017 at 2:35 PM, Jom O'Fisher < > jomofisher at gmail.com> > >> >>>>> wrote: > >> >>>>> > Would it work for your scenario to provide properties in the > root > >> >>>>> > build.gradle: > >> >>>>> > > >> >>>>> > ext { > >> >>>>> > cmakePath = file "CMakeLists.txt" > >> >>>>> > } > >> >>>>> > > >> >>>>> > And then consume them in the leaf app/build.gradle like this? > >> >>>>> > > >> >>>>> > externalNativeBuild { > >> >>>>> > cmake { > >> >>>>> > path cmakePath > >> >>>>> > } > >> >>>>> > } > >> >>>>> > > >> >>>>> > It doesn't fully hide the details but it does centralize the > >> >>>>> > information. > >> >>>>> > > >> >>>>> > > >> >>>>> > On Mon, Aug 21, 2017 at 11:20 AM, Robert Dailey > >> >>>>> > > >> >>>>> > wrote: > >> >>>>> >> > >> >>>>> >> I wouldn't want to do that, it's too convoluted. I have other > >> >>>>> >> platforms that use these CMake scripts as well. For example, I > >> >>>>> >> run on > >> >>>>> >> Windows and Linux platforms as well to build the native code. > >> >>>>> >> Normal > >> >>>>> >> CMake behavior is designed to work at a root then go downwards > to > >> >>>>> >> find > >> >>>>> >> targets. However it seems Gradle wants to start at a > subdirectory > >> >>>>> >> and > >> >>>>> >> work its way up to the root, which is opposite of CMake's > >> >>>>> >> intended > >> >>>>> >> behavior IMHO. Not only that but I want to avoid special-casing > >> >>>>> >> behavior in CMake just for Android's use. > >> >>>>> >> > >> >>>>> >> At the moment it feels like (again referring back to my > previous > >> >>>>> >> example structure) that both App2 and App3 each run CMake in > >> >>>>> >> independent binary directories instead of sharing 1 binary > >> >>>>> >> directory > >> >>>>> >> and building 2 targets inside of it. I prefer this behavior > >> >>>>> >> instead, > >> >>>>> >> especially since it allows CMake to operate as it was > intended. I > >> >>>>> >> think it's a common case that projects will define multiple > >> >>>>> >> targets > >> >>>>> >> starting from a single root, and expect multiple APKs or java > >> >>>>> >> dependencies to be built within it. > >> >>>>> >> > >> >>>>> >> If I'm misunderstanding or making false assumptions please let > me > >> >>>>> >> know. > >> >>>>> >> > >> >>>>> >> > >> >>>>> >> > >> >>>>> >> On Mon, Aug 21, 2017 at 12:00 PM, Jom O'Fisher > >> >>>>> >> > >> >>>>> >> wrote: > >> >>>>> >> > Would it work for your situation for the leaf CMakeLists.txt > to > >> >>>>> >> > include > >> >>>>> >> > the > >> >>>>> >> > root CMakeLists.txt? Then have the leaf-specific logic in the > >> >>>>> >> > leaf > >> >>>>> >> > CMakeLists.txt? > >> >>>>> >> > > >> >>>>> >> > > >> >>>>> >> > > >> >>>>> >> > On Mon, Aug 21, 2017 at 9:33 AM, Robert Dailey > >> >>>>> >> > > >> >>>>> >> > wrote: > >> >>>>> >> >> > >> >>>>> >> >> Basically, yes. We have this sort of structure: > >> >>>>> >> >> > >> >>>>> >> >> / > >> >>>>> >> >> Applications/ > >> >>>>> >> >> App1/ > >> >>>>> >> >> build.gradle > >> >>>>> >> >> CMakeLists.txt > >> >>>>> >> >> App2/ > >> >>>>> >> >> build.gradle > >> >>>>> >> >> CMakeLists.txt > >> >>>>> >> >> App3/ > >> >>>>> >> >> build.gradle > >> >>>>> >> >> CMakeLists.txt > >> >>>>> >> >> CommonLib/ > >> >>>>> >> >> build.gradle > >> >>>>> >> >> CMakeLists.txt > >> >>>>> >> >> CMakeLists.txt > >> >>>>> >> >> > >> >>>>> >> >> The libs are defined as follows: > >> >>>>> >> >> > >> >>>>> >> >> * CommonLib is a static library (java code builds into a > >> >>>>> >> >> library) > >> >>>>> >> >> * No dependencies of its own > >> >>>>> >> >> * App1 is a shared library (java code builds into a library) > >> >>>>> >> >> * Dependencies (both java & native): CommonLib > >> >>>>> >> >> * App2 is a shared library (java code builds into an APK) > >> >>>>> >> >> * Dependencies (both java & native): App1, CommonLib > >> >>>>> >> >> * App3 is a shared library (java code builds into an APK) > >> >>>>> >> >> * Dependencies (both java & native): CommonLib > >> >>>>> >> >> > >> >>>>> >> >> In all cases, CMake must be invoked starting at the root > >> >>>>> >> >> CMakeLists.txt 1 time. Each target can be built from the > same > >> >>>>> >> >> binary > >> >>>>> >> >> directory after that. Previously with ANT, I was building > all > >> >>>>> >> >> native > >> >>>>> >> >> targets first, then moved libs to appropriate directories so > >> >>>>> >> >> that > >> >>>>> >> >> the > >> >>>>> >> >> 'ant' command would package the libs. > >> >>>>> >> >> > >> >>>>> >> >> For gradle, I wanted to avoid redundantly specifying the > root > >> >>>>> >> >> directory in each leaf-level project directory. Using the > >> >>>>> >> >> example > >> >>>>> >> >> above, the leaf-level directories in this case would be > App1, > >> >>>>> >> >> App2, > >> >>>>> >> >> App3, and CommonLib. However I think we only specify the > >> >>>>> >> >> native > >> >>>>> >> >> CMake > >> >>>>> >> >> stuff for the java targets that actually output an APK (that > >> >>>>> >> >> would > >> >>>>> >> >> be > >> >>>>> >> >> App2 and App3 only). > >> >>>>> >> >> > >> >>>>> >> >> The ultimate goal is to specify stuff that doesn't change > per > >> >>>>> >> >> independent "module" of ours at the top level so it is > >> >>>>> >> >> transitive > >> >>>>> >> >> / > >> >>>>> >> >> inherited. Then only specify the differences (e.g. the > native > >> >>>>> >> >> CMake > >> >>>>> >> >> target to build) in the leaf build gradle files. However you > >> >>>>> >> >> indicated > >> >>>>> >> >> this isn't possible. > >> >>>>> >> >> > >> >>>>> >> >> > >> >>>>> >> >> > >> >>>>> >> >> On Mon, Aug 21, 2017 at 11:11 AM, Jom O'Fisher > >> >>>>> >> >> > >> >>>>> >> >> wrote: > >> >>>>> >> >> > What you're doing already sounds correct. You can't > directly > >> >>>>> >> >> > specify > >> >>>>> >> >> > CMakeLists.txt from the top-level build.gradle. > >> >>>>> >> >> > Recommendation > >> >>>>> >> >> > is > >> >>>>> >> >> > that > >> >>>>> >> >> > it > >> >>>>> >> >> > should be specified from the build.gradle of the module of > >> >>>>> >> >> > the > >> >>>>> >> >> > APK. > >> >>>>> >> >> > Is > >> >>>>> >> >> > the > >> >>>>> >> >> > issue that you have multiple APK modules that all > reference > >> >>>>> >> >> > the > >> >>>>> >> >> > same > >> >>>>> >> >> > CMake > >> >>>>> >> >> > libraries? > >> >>>>> >> >> > > >> >>>>> >> >> > On Mon, Aug 21, 2017 at 9:00 AM, Robert Dailey > >> >>>>> >> >> > > >> >>>>> >> >> > wrote: > >> >>>>> >> >> >> > >> >>>>> >> >> >> Thanks this is very helpful. The other question I have > is: > >> >>>>> >> >> >> Is > >> >>>>> >> >> >> there > >> >>>>> >> >> >> a > >> >>>>> >> >> >> place to centrally specify the root CMakeLists.txt? > >> >>>>> >> >> >> Basically, > >> >>>>> >> >> >> I > >> >>>>> >> >> >> want > >> >>>>> >> >> >> to specify the CMake root in 1 place, and have targets > >> >>>>> >> >> >> (defined > >> >>>>> >> >> >> further down in subdirectories) that require APK > packaging > >> >>>>> >> >> >> to > >> >>>>> >> >> >> specify > >> >>>>> >> >> >> only the native target name that should be built & > >> >>>>> >> >> >> packaged. > >> >>>>> >> >> >> > >> >>>>> >> >> >> At the moment we specify the root CMakeLists.txt by > walking > >> >>>>> >> >> >> up > >> >>>>> >> >> >> the > >> >>>>> >> >> >> tree, paths like "../../../../CMakeLists.txt". I think > this > >> >>>>> >> >> >> should > >> >>>>> >> >> >> be > >> >>>>> >> >> >> put at the top-level build gradle file if possible. Is > this > >> >>>>> >> >> >> doable > >> >>>>> >> >> >> at > >> >>>>> >> >> >> the moment? What is the recommended setup? > >> >>>>> >> >> >> > >> >>>>> >> >> >> On Mon, Aug 21, 2017 at 9:37 AM, Jom O'Fisher > >> >>>>> >> >> >> > >> >>>>> >> >> >> wrote: > >> >>>>> >> >> >> > Gradle does introspection on the CMake build to find > .so > >> >>>>> >> >> >> > targets > >> >>>>> >> >> >> > and > >> >>>>> >> >> >> > those > >> >>>>> >> >> >> > get packaged. > >> >>>>> >> >> >> > There is also a special case for stl/runtime .so files > >> >>>>> >> >> >> > from > >> >>>>> >> >> >> > the > >> >>>>> >> >> >> > NDK. > >> >>>>> >> >> >> > Any additional .so files need to specified in > >> >>>>> >> >> >> > build.gradle > >> >>>>> >> >> >> > using > >> >>>>> >> >> >> > jniDirs > >> >>>>> >> >> >> > > >> >>>>> >> >> >> > On Mon, Aug 21, 2017 at 7:30 AM, Robert Dailey > >> >>>>> >> >> >> > > >> >>>>> >> >> >> > wrote: > >> >>>>> >> >> >> >> > >> >>>>> >> >> >> >> How exactly does Gradle package *.so files in an APK? > I > >> >>>>> >> >> >> >> know > >> >>>>> >> >> >> >> that > >> >>>>> >> >> >> >> ANT > >> >>>>> >> >> >> >> used to do this for any libs under "libs/". Does > >> >>>>> >> >> >> >> Gradle > >> >>>>> >> >> >> >> do > >> >>>>> >> >> >> >> some > >> >>>>> >> >> >> >> introspection into CMake targets to see if outputs are > >> >>>>> >> >> >> >> *.so, > >> >>>>> >> >> >> >> and > >> >>>>> >> >> >> >> copy > >> >>>>> >> >> >> >> those to some location if needed? What about libraries > >> >>>>> >> >> >> >> like > >> >>>>> >> >> >> >> libgnustl_shared.so that come with the NDK? I'd like > to > >> >>>>> >> >> >> >> know > >> >>>>> >> >> >> >> if > >> >>>>> >> >> >> >> any > >> >>>>> >> >> >> >> manual copy steps are needed in CMake to put outputs > in > >> >>>>> >> >> >> >> proper > >> >>>>> >> >> >> >> locations for the APK build step. I had to do this > when > >> >>>>> >> >> >> >> using > >> >>>>> >> >> >> >> ANT. > >> >>>>> >> >> >> >> > >> >>>>> >> >> >> >> On Mon, Aug 7, 2017 at 6:16 PM, Jom O'Fisher > >> >>>>> >> >> >> >> > >> >>>>> >> >> >> >> wrote: > >> >>>>> >> >> >> >> > 1) There is a folder created for each ABI under the > >> >>>>> >> >> >> >> > project > >> >>>>> >> >> >> >> > module > >> >>>>> >> >> >> >> > folder > >> >>>>> >> >> >> >> > (so unique per module per ABI) > >> >>>>> >> >> >> >> > 2) Gradle doesn't specify language level though you > >> >>>>> >> >> >> >> > can > >> >>>>> >> >> >> >> > choose > >> >>>>> >> >> >> >> > to > >> >>>>> >> >> >> >> > specify it > >> >>>>> >> >> >> >> > yourself from the build.gradle. This doc does a > pretty > >> >>>>> >> >> >> >> > good job > >> >>>>> >> >> >> >> > of > >> >>>>> >> >> >> >> > explaining which variables are set by Gradle: > >> >>>>> >> >> >> >> > > >> >>>>> >> >> >> >> > > >> >>>>> >> >> >> >> > https://developer.android.com/ > ndk/guides/cmake.html#variables. > >> >>>>> >> >> >> >> > Philosophically, we try to set as little as we can > get > >> >>>>> >> >> >> >> > away > >> >>>>> >> >> >> >> > with. > >> >>>>> >> >> >> >> > In > >> >>>>> >> >> >> >> > particular, the section titled "Understanding the > >> >>>>> >> >> >> >> > CMake > >> >>>>> >> >> >> >> > build > >> >>>>> >> >> >> >> > command" > >> >>>>> >> >> >> >> > lays > >> >>>>> >> >> >> >> > out exactly what we set. You can also see the > folders > >> >>>>> >> >> >> >> > we > >> >>>>> >> >> >> >> > specify > >> >>>>> >> >> >> >> > (one > >> >>>>> >> >> >> >> > per > >> >>>>> >> >> >> >> > module per ABI) > >> >>>>> >> >> >> >> > 3) Not sure I understand this. > >> >>>>> >> >> >> >> > > >> >>>>> >> >> >> >> > The other document worth taking a look at (if you > >> >>>>> >> >> >> >> > haven't > >> >>>>> >> >> >> >> > already) > >> >>>>> >> >> >> >> > is: > >> >>>>> >> >> >> >> > > >> >>>>> >> >> >> >> > > >> >>>>> >> >> >> >> > > >> >>>>> >> >> >> >> > https://developer.android.com/ > studio/projects/add-native-code.html > >> >>>>> >> >> >> >> > > >> >>>>> >> >> >> >> > > >> >>>>> >> >> >> >> > On Mon, Aug 7, 2017 at 3:35 PM, Robert Dailey > >> >>>>> >> >> >> >> > > >> >>>>> >> >> >> >> > wrote: > >> >>>>> >> >> >> >> >> > >> >>>>> >> >> >> >> >> Thanks Jom > >> >>>>> >> >> >> >> >> > >> >>>>> >> >> >> >> >> Honestly, I prefer option 1 to work simply because > >> >>>>> >> >> >> >> >> that's > >> >>>>> >> >> >> >> >> how > >> >>>>> >> >> >> >> >> Google's > >> >>>>> >> >> >> >> >> officially supporting CMake. But it also has > >> >>>>> >> >> >> >> >> debugging > >> >>>>> >> >> >> >> >> which > >> >>>>> >> >> >> >> >> is > >> >>>>> >> >> >> >> >> the > >> >>>>> >> >> >> >> >> #1 > >> >>>>> >> >> >> >> >> reason for me. > >> >>>>> >> >> >> >> >> > >> >>>>> >> >> >> >> >> However, I'd like to understand a lot more about > how > >> >>>>> >> >> >> >> >> the > >> >>>>> >> >> >> >> >> integration > >> >>>>> >> >> >> >> >> really happens. For example, I have these > questions: > >> >>>>> >> >> >> >> >> > >> >>>>> >> >> >> >> >> 1) How, internally, are CMake build directories > >> >>>>> >> >> >> >> >> managed? > >> >>>>> >> >> >> >> >> Do > >> >>>>> >> >> >> >> >> you > >> >>>>> >> >> >> >> >> generate 1 per unique android project? What about > for > >> >>>>> >> >> >> >> >> each > >> >>>>> >> >> >> >> >> specific > >> >>>>> >> >> >> >> >> platform (x86, armeabi-v7a, etc)? > >> >>>>> >> >> >> >> >> 2) Last time I looked into CMake integration, > things > >> >>>>> >> >> >> >> >> defined > >> >>>>> >> >> >> >> >> inside > >> >>>>> >> >> >> >> >> the CMake scripts were ignored because they are > >> >>>>> >> >> >> >> >> specified > >> >>>>> >> >> >> >> >> at > >> >>>>> >> >> >> >> >> the > >> >>>>> >> >> >> >> >> command line. Namely, all of those settings that > are > >> >>>>> >> >> >> >> >> driven by > >> >>>>> >> >> >> >> >> the > >> >>>>> >> >> >> >> >> Gradle configuration (CXX language level was one in > >> >>>>> >> >> >> >> >> particular > >> >>>>> >> >> >> >> >> I > >> >>>>> >> >> >> >> >> think; I specify C++14 support via CMake, but I > >> >>>>> >> >> >> >> >> recall > >> >>>>> >> >> >> >> >> this > >> >>>>> >> >> >> >> >> being > >> >>>>> >> >> >> >> >> overridden from outside)? > >> >>>>> >> >> >> >> >> 3) How redundant is it to configure individual > >> >>>>> >> >> >> >> >> libraries > >> >>>>> >> >> >> >> >> via > >> >>>>> >> >> >> >> >> the > >> >>>>> >> >> >> >> >> gradle scripts? In my previous attempts, I wanted > to > >> >>>>> >> >> >> >> >> define > >> >>>>> >> >> >> >> >> common > >> >>>>> >> >> >> >> >> stuff for CMake / native code at the root gradle or > >> >>>>> >> >> >> >> >> settings > >> >>>>> >> >> >> >> >> file, > >> >>>>> >> >> >> >> >> and > >> >>>>> >> >> >> >> >> only define the differences in the actual gradle > >> >>>>> >> >> >> >> >> build > >> >>>>> >> >> >> >> >> files > >> >>>>> >> >> >> >> >> for > >> >>>>> >> >> >> >> >> each > >> >>>>> >> >> >> >> >> corresponding Java target (like, defining the name > of > >> >>>>> >> >> >> >> >> the > >> >>>>> >> >> >> >> >> native > >> >>>>> >> >> >> >> >> (shared library) target in Gradle, but the command > >> >>>>> >> >> >> >> >> line > >> >>>>> >> >> >> >> >> invocation, > >> >>>>> >> >> >> >> >> -D > >> >>>>> >> >> >> >> >> CMake settings, etc would all be common and defined > >> >>>>> >> >> >> >> >> at > >> >>>>> >> >> >> >> >> the > >> >>>>> >> >> >> >> >> root). > >> >>>>> >> >> >> >> >> > >> >>>>> >> >> >> >> >> The TLDR is, the closer we can stay to CMake's way > of > >> >>>>> >> >> >> >> >> doing > >> >>>>> >> >> >> >> >> things > >> >>>>> >> >> >> >> >> and > >> >>>>> >> >> >> >> >> keep CMake-related settings self-contained to the > >> >>>>> >> >> >> >> >> CMake > >> >>>>> >> >> >> >> >> scripts > >> >>>>> >> >> >> >> >> themselves, the better. This also makes > >> >>>>> >> >> >> >> >> cross-platform > >> >>>>> >> >> >> >> >> easier > >> >>>>> >> >> >> >> >> (we > >> >>>>> >> >> >> >> >> build the native code in Windows, for example, so > >> >>>>> >> >> >> >> >> having > >> >>>>> >> >> >> >> >> settings > >> >>>>> >> >> >> >> >> specified in the gradle files do not carry over to > >> >>>>> >> >> >> >> >> other > >> >>>>> >> >> >> >> >> platforms. > >> >>>>> >> >> >> >> >> Namely, settings that are not platform specific > like > >> >>>>> >> >> >> >> >> the > >> >>>>> >> >> >> >> >> C++ > >> >>>>> >> >> >> >> >> language > >> >>>>> >> >> >> >> >> level). > >> >>>>> >> >> >> >> >> > >> >>>>> >> >> >> >> >> If there's a detailed document / wiki I can read on > >> >>>>> >> >> >> >> >> the > >> >>>>> >> >> >> >> >> intrinsics > >> >>>>> >> >> >> >> >> of > >> >>>>> >> >> >> >> >> CMake integration in Gradle / Android Studio, I'd > >> >>>>> >> >> >> >> >> love to > >> >>>>> >> >> >> >> >> read > >> >>>>> >> >> >> >> >> it. > >> >>>>> >> >> >> >> >> Otherwise, I hope you won't mind if I pick your > brain > >> >>>>> >> >> >> >> >> as > >> >>>>> >> >> >> >> >> questions > >> >>>>> >> >> >> >> >> come up. I think I'm going to try option 1 for now > >> >>>>> >> >> >> >> >> and > >> >>>>> >> >> >> >> >> see how > >> >>>>> >> >> >> >> >> it > >> >>>>> >> >> >> >> >> goes. It's just black box for me because unlike > >> >>>>> >> >> >> >> >> option 2, > >> >>>>> >> >> >> >> >> I > >> >>>>> >> >> >> >> >> have > >> >>>>> >> >> >> >> >> very > >> >>>>> >> >> >> >> >> little control over what happens after building the > >> >>>>> >> >> >> >> >> shared > >> >>>>> >> >> >> >> >> libraries, > >> >>>>> >> >> >> >> >> and to make up for that I need to really get a deep > >> >>>>> >> >> >> >> >> understanding > >> >>>>> >> >> >> >> >> of > >> >>>>> >> >> >> >> >> how it works so I can make sure I code my CMake > >> >>>>> >> >> >> >> >> scripts > >> >>>>> >> >> >> >> >> properly > >> >>>>> >> >> >> >> >> for > >> >>>>> >> >> >> >> >> not only Android, but my other platforms as well > >> >>>>> >> >> >> >> >> (non-Android > >> >>>>> >> >> >> >> >> platforms). > >> >>>>> >> >> >> >> >> > >> >>>>> >> >> >> >> >> Thanks again. > >> >>>>> >> >> >> >> >> > >> >>>>> >> >> >> >> >> On Mon, Aug 7, 2017 at 5:12 PM, Jom O'Fisher > >> >>>>> >> >> >> >> >> > >> >>>>> >> >> >> >> >> wrote: > >> >>>>> >> >> >> >> >> > Either option can work fine. Disclosure: I work > on > >> >>>>> >> >> >> >> >> > Android > >> >>>>> >> >> >> >> >> > Studio > >> >>>>> >> >> >> >> >> > and > >> >>>>> >> >> >> >> >> > was > >> >>>>> >> >> >> >> >> > the one that added CMake support. > >> >>>>> >> >> >> >> >> > > >> >>>>> >> >> >> >> >> > Option (1) is the way it's designed to work and > >> >>>>> >> >> >> >> >> > we're > >> >>>>> >> >> >> >> >> > working > >> >>>>> >> >> >> >> >> > toward > >> >>>>> >> >> >> >> >> > getting > >> >>>>> >> >> >> >> >> > rid of the need for the CMake fork. I can't > really > >> >>>>> >> >> >> >> >> > say > >> >>>>> >> >> >> >> >> > when > >> >>>>> >> >> >> >> >> > that > >> >>>>> >> >> >> >> >> > will > >> >>>>> >> >> >> >> >> > happen > >> >>>>> >> >> >> >> >> > but if you can get away with an older CMake for > now > >> >>>>> >> >> >> >> >> > then I'd > >> >>>>> >> >> >> >> >> > go > >> >>>>> >> >> >> >> >> > this > >> >>>>> >> >> >> >> >> > way. > >> >>>>> >> >> >> >> >> > As you mentioned, option (1) will allow you to > view > >> >>>>> >> >> >> >> >> > your > >> >>>>> >> >> >> >> >> > source > >> >>>>> >> >> >> >> >> > file > >> >>>>> >> >> >> >> >> > structure in Android Studio, edit files, and > debug > >> >>>>> >> >> >> >> >> > using the > >> >>>>> >> >> >> >> >> > built-in > >> >>>>> >> >> >> >> >> > debugging support. > >> >>>>> >> >> >> >> >> > > >> >>>>> >> >> >> >> >> > To get option (2) to work, you can use jniDirs > >> >>>>> >> >> >> >> >> > setting > >> >>>>> >> >> >> >> >> > to > >> >>>>> >> >> >> >> >> > tell > >> >>>>> >> >> >> >> >> > Android > >> >>>>> >> >> >> >> >> > Gradle where to pick up your built .so files (see > >> >>>>> >> >> >> >> >> > > >> >>>>> >> >> >> >> >> > > >> >>>>> >> >> >> >> >> > > >> >>>>> >> >> >> >> >> > > >> >>>>> >> >> >> >> >> > > >> >>>>> >> >> >> >> >> > > >> >>>>> >> >> >> >> >> > > >> >>>>> >> >> >> >> >> > https://stackoverflow.com/ > questions/21255125/how-can-i-add-so-files-to-an-android- > library-project-using-gradle-0-7). > >> >>>>> >> >> >> >> >> > I'm not aware of any projects that use this > >> >>>>> >> >> >> >> >> > approach > >> >>>>> >> >> >> >> >> > but it > >> >>>>> >> >> >> >> >> > should > >> >>>>> >> >> >> >> >> > work > >> >>>>> >> >> >> >> >> > in > >> >>>>> >> >> >> >> >> > principal. > >> >>>>> >> >> >> >> >> > > >> >>>>> >> >> >> >> >> > I hope this helps, > >> >>>>> >> >> >> >> >> > Jomo > >> >>>>> >> >> >> >> >> > > >> >>>>> >> >> >> >> >> > > >> >>>>> >> >> >> >> >> > On Mon, Aug 7, 2017 at 11:09 AM, Robert Dailey > >> >>>>> >> >> >> >> >> > > >> >>>>> >> >> >> >> >> > wrote: > >> >>>>> >> >> >> >> >> >> > >> >>>>> >> >> >> >> >> >> Right now I have custom targets set to execute > the > >> >>>>> >> >> >> >> >> >> "ant > >> >>>>> >> >> >> >> >> >> release" > >> >>>>> >> >> >> >> >> >> command after my native targets are built. Part > of > >> >>>>> >> >> >> >> >> >> that > >> >>>>> >> >> >> >> >> >> command > >> >>>>> >> >> >> >> >> >> involves copying *.so files to the > >> >>>>> >> >> >> >> >> >> libs/armeabi-v7a > >> >>>>> >> >> >> >> >> >> directory > >> >>>>> >> >> >> >> >> >> so > >> >>>>> >> >> >> >> >> >> they > >> >>>>> >> >> >> >> >> >> get packaged in an APK. > >> >>>>> >> >> >> >> >> >> > >> >>>>> >> >> >> >> >> >> When switching to gradle, I have two options: > >> >>>>> >> >> >> >> >> >> > >> >>>>> >> >> >> >> >> >> 1. Gradle drives CMake: This means using Android > >> >>>>> >> >> >> >> >> >> Studio and > >> >>>>> >> >> >> >> >> >> being > >> >>>>> >> >> >> >> >> >> locked down to Google's fork of CMake which is a > >> >>>>> >> >> >> >> >> >> few > >> >>>>> >> >> >> >> >> >> major > >> >>>>> >> >> >> >> >> >> releases > >> >>>>> >> >> >> >> >> >> behind. I see that as a negative. > >> >>>>> >> >> >> >> >> >> > >> >>>>> >> >> >> >> >> >> 2. CMake drives Gradle: This would be the same > or > >> >>>>> >> >> >> >> >> >> similar > >> >>>>> >> >> >> >> >> >> to > >> >>>>> >> >> >> >> >> >> what > >> >>>>> >> >> >> >> >> >> I'm > >> >>>>> >> >> >> >> >> >> already doing: The custom targets I have would > >> >>>>> >> >> >> >> >> >> execute > >> >>>>> >> >> >> >> >> >> gradle > >> >>>>> >> >> >> >> >> >> as > >> >>>>> >> >> >> >> >> >> a > >> >>>>> >> >> >> >> >> >> separate build step, instead of running ant > >> >>>>> >> >> >> >> >> >> commands. > >> >>>>> >> >> >> >> >> >> I'm > >> >>>>> >> >> >> >> >> >> not > >> >>>>> >> >> >> >> >> >> too > >> >>>>> >> >> >> >> >> >> familiar with Gradle, so I'm not sure how you > tell > >> >>>>> >> >> >> >> >> >> it > >> >>>>> >> >> >> >> >> >> where > >> >>>>> >> >> >> >> >> >> your > >> >>>>> >> >> >> >> >> >> shared libraries are for the APK packaging > steps. > >> >>>>> >> >> >> >> >> >> > >> >>>>> >> >> >> >> >> >> Which does everyone recommend? Is anyone using > one > >> >>>>> >> >> >> >> >> >> of > >> >>>>> >> >> >> >> >> >> these > >> >>>>> >> >> >> >> >> >> setups > >> >>>>> >> >> >> >> >> >> successfully? The downside to option 2 is > probably > >> >>>>> >> >> >> >> >> >> no > >> >>>>> >> >> >> >> >> >> on-device > >> >>>>> >> >> >> >> >> >> native > >> >>>>> >> >> >> >> >> >> debugging since Android Studio probably can't > >> >>>>> >> >> >> >> >> >> handle > >> >>>>> >> >> >> >> >> >> gradle > >> >>>>> >> >> >> >> >> >> projects > >> >>>>> >> >> >> >> >> >> without any external CMake builds set up. > >> >>>>> >> >> >> >> >> >> > >> >>>>> >> >> >> >> >> >> Would like some general direction & advice > before > >> >>>>> >> >> >> >> >> >> I > >> >>>>> >> >> >> >> >> >> move > >> >>>>> >> >> >> >> >> >> away > >> >>>>> >> >> >> >> >> >> from > >> >>>>> >> >> >> >> >> >> ANT. Thanks in advance. > >> >>>>> >> >> >> >> >> >> -- > >> >>>>> >> >> >> >> >> >> > >> >>>>> >> >> >> >> >> >> Powered by www.kitware.com > >> >>>>> >> >> >> >> >> >> > >> >>>>> >> >> >> >> >> >> Please keep messages on-topic and check the > CMake > >> >>>>> >> >> >> >> >> >> FAQ > >> >>>>> >> >> >> >> >> >> at: > >> >>>>> >> >> >> >> >> >> http://www.cmake.org/Wiki/CMake_FAQ > >> >>>>> >> >> >> >> >> >> > >> >>>>> >> >> >> >> >> >> Kitware offers various services to support the > >> >>>>> >> >> >> >> >> >> CMake > >> >>>>> >> >> >> >> >> >> community. > >> >>>>> >> >> >> >> >> >> For > >> >>>>> >> >> >> >> >> >> more > >> >>>>> >> >> >> >> >> >> information on each offering, please visit: > >> >>>>> >> >> >> >> >> >> > >> >>>>> >> >> >> >> >> >> CMake Support: > >> >>>>> >> >> >> >> >> >> http://cmake.org/cmake/help/support.html > >> >>>>> >> >> >> >> >> >> CMake Consulting: > >> >>>>> >> >> >> >> >> >> http://cmake.org/cmake/help/consulting.html > >> >>>>> >> >> >> >> >> >> CMake Training Courses: > >> >>>>> >> >> >> >> >> >> http://cmake.org/cmake/help/training.html > >> >>>>> >> >> >> >> >> >> > >> >>>>> >> >> >> >> >> >> Visit other Kitware open-source projects at > >> >>>>> >> >> >> >> >> >> http://www.kitware.com/ > opensource/opensource.html > >> >>>>> >> >> >> >> >> >> > >> >>>>> >> >> >> >> >> >> Follow this link to subscribe/unsubscribe: > >> >>>>> >> >> >> >> >> >> http://public.kitware.com/ > mailman/listinfo/cmake > >> >>>>> >> >> >> >> >> > > >> >>>>> >> >> >> >> >> > > >> >>>>> >> >> >> >> > > >> >>>>> >> >> >> >> > > >> >>>>> >> >> >> > > >> >>>>> >> >> >> > > >> >>>>> >> >> > > >> >>>>> >> >> > > >> >>>>> >> > > >> >>>>> >> > > >> >>>>> > > >> >>>>> > > >> >>>> > >> >>>> > >> >>> > >> >> > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bitminer at gmail.com Wed Aug 23 17:23:21 2017 From: bitminer at gmail.com (Brian Davis) Date: Wed, 23 Aug 2017 16:23:21 -0500 Subject: [CMake] Interface Libraries allow include directories but not link directories.. Why? In-Reply-To: References: Message-ID: So there is some odd replies in the cmake mailing list possibly responses to wrong message, but this looked like a response to mine even if the initial reply to bit is not right from Nicholas. Anywho here goes: @Jean-Micha?l Celerier -- snip -- >* - Says that custom functions such as add_{project}_library shouldn't be *used and function definitions should be used as little as possible. Except this just leads to extremely verbose CMakeLists where repeated properties are defined again and again and again. -- snip -- Yes add_project_library were my own and in the process of being deprecated. These were geared directly at two problems in cmake. 1) They were used to get CMake to support the concept of "inherited build properties". 2) As you stated and is still a problem the verbosity of CMake. Where IMO much could be collaped into one call -- snip -- I also never understood how to handle this. -- snip -- I am afraid I don't ultimately have the answer either... I have do some ideas on possibly best course of action. -- snip -- I have a project where I want to define, say, -fsanitize=address, -DFOO_BAR and the SUFFIX property on a specific set of 25 targets amongst ~100 targets. What am I to do ? * set(CMAKE_CXX_FLAGS "-fsanitize=address") is "not modern CMake" (and also would be harder to set / unset on specific targets). * calling target_compile_options(...) 25 times ... well I mean, everyone knows it's bad to duplicate code. Especially if the change is meant to be only when a specific option() is enabled, or for debugging purposes * creating a function that would set the correct flags, etc and then call this function for each target is apparently "not modern CMake" either. * creating and linking to "dummy" INTERFACE targets with the flags and properties I want have an awful lot of limitations So what is the right course of actions here ? -- snip -- I have started using add_library( targ INTERFACE ) to imperilment inherited build properties. Yes the naming convention and use/reuse/misuse of add_library is horrid (library) I just posted this which may help: https://cmake.org/pipermail/cmake/2017-August/066119.html -- snip -- Ideally I'd like to add "groups" to targets; e.g. "target Foo is a plugin for $software", "target Bar is an integration test" and set per-group options, flags, properties, etc. Like add_group(PluginGroup) target_compile_definitions(PluginGroup -DBLAH) set_property(GROUP PluginGroup PROPERTIES /* whatever in cmake-properties*/) set_group(myTarget PluginGroup) // applies everything to the target -- snip -- I won't have all the syntax for what your trying but possibly try: add_library( PluginGroupInterface INTERFACE) target_compile_definitions(PluginGroupInterface -DBLAH) set_property(GROUP PluginGroup PROPERTIES /* whatever in cmake-properties*/) I add interface, Interface, or _interface to my interface targets I use like this. Note here library in add library does not actually have to have a library (hence my statements to the horrid miss reuse of add_library for this functionality). It can just have build properties that you want a target to later inherit as far as I understand it or as far as I am miss using it if it is meant to be used some other way. then... add_executable( myTarget ) target_link_libraries( myTarget PluginGroupInterface ) Does that work for your needs? -- snip -- Best, ------- Jean-Micha?l Celerier -- snip -- -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeanmichael.celerier at gmail.com Wed Aug 23 17:57:13 2017 From: jeanmichael.celerier at gmail.com (=?UTF-8?Q?Jean=2DMicha=C3=ABl_Celerier?=) Date: Wed, 23 Aug 2017 23:57:13 +0200 Subject: [CMake] Interface Libraries allow include directories but not link directories.. Why? In-Reply-To: References: Message-ID: > Does that work for your needs? Sadly, no (but thanks!). While this is enough for the arguably common use case of include directories, compile flags, etc... there are plenty of things that won't work with this approach. e.g. none of this works for instance: project(foo) add_library(blah INTERFACE) set_property(TARGET blah PROPERTY SUFFIX ".mxe") set_property(TARGET blah PROPERTY CXX_STANDARD 14) set_property(TARGET blah PROPERTY INSTALL_RPATH "@loader_path/whatever") ------- Jean-Micha?l Celerier http://www.jcelerier.name On Wed, Aug 23, 2017 at 11:23 PM, Brian Davis wrote: > So there is some odd replies in the cmake mailing list possibly responses to wrong message, but this looked like a response to mine even if the initial reply to bit is not right from Nicholas. Anywho here goes: > > @Jean-Micha?l Celerier > > -- snip -- > >* - Says that custom functions such as add_{project}_library shouldn't be > *used and function definitions should be used as little as possible. Except > this just leads to extremely verbose CMakeLists where repeated properties > are defined again and again and again. > -- snip -- > > Yes add_project_library were my own and in the process of being deprecated. These were geared directly at two problems in cmake. > > 1) They were used to get CMake to support the concept of "inherited build properties". > > 2) As you stated and is still a problem the verbosity of CMake. Where IMO much could be collaped into one call > > > -- snip -- > I also never understood how to handle this. > -- snip -- > > I am afraid I don't ultimately have the answer either... I have do some ideas on possibly best course of action. > > > -- snip -- > I have a project where I want to define, say, -fsanitize=address, -DFOO_BAR > and the SUFFIX property on a specific set of 25 targets amongst ~100 > targets. What am I to do ? > > * set(CMAKE_CXX_FLAGS "-fsanitize=address") is "not modern CMake" (and also > would be harder to set / unset on specific targets). > * calling target_compile_options(...) 25 times ... well I mean, everyone > knows it's bad to duplicate code. Especially if the change is meant to be > only when a specific option() is enabled, or for debugging purposes > * creating a function that would set the correct flags, etc and then call > this function for each target is apparently "not modern CMake" either. > * creating and linking to "dummy" INTERFACE targets with the flags and > properties I want have an awful lot of limitations > > So what is the right course of actions here ? > -- snip -- > > I have started using add_library( targ INTERFACE ) to imperilment inherited build properties. Yes the naming convention and use/reuse/misuse of add_library is horrid (library) > > I just posted this which may help: > > https://cmake.org/pipermail/cmake/2017-August/066119.html > > -- snip -- > Ideally I'd like to add "groups" to targets; e.g. "target Foo is a plugin > for $software", "target Bar is an integration test" and set per-group > options, flags, properties, etc. Like > > add_group(PluginGroup) > target_compile_definitions(PluginGroup -DBLAH) > set_property(GROUP PluginGroup PROPERTIES /* whatever in > cmake-properties*/) > set_group(myTarget PluginGroup) // applies everything to the target > -- snip -- > > I won't have all the syntax for what your trying but possibly try: > > add_library( PluginGroupInterface INTERFACE) > target_compile_definitions(PluginGroupInterface -DBLAH) > set_property(GROUP PluginGroup PROPERTIES /* whatever in > cmake-properties*/) > > I add interface, Interface, or _interface to my interface targets I use like this. Note here library in add library does not actually have to have a library (hence my statements to the horrid miss reuse of add_library for this functionality). It can just have build properties that you want a target to later inherit as far as I understand it or as far as I am miss using it if it is meant to be used some other way. > > then... > > add_executable( myTarget ) > > target_link_libraries( > myTarget > PluginGroupInterface > ) > > Does that work for your needs? > > > > -- snip -- > Best, > > ------- > Jean-Micha?l Celerier > > -- snip -- > > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/ > opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bitminer at gmail.com Wed Aug 23 18:21:01 2017 From: bitminer at gmail.com (Brian Davis) Date: Wed, 23 Aug 2017 17:21:01 -0500 Subject: [CMake] Interface Libraries allow include directories but not link directories.. Why? In-Reply-To: References: Message-ID: Ok got it sorry to hear that certainly because, as soon as I hear something that would be useful somehow I end up needing it the next day. So sorry for us both. >From what your are saying (and I will take your word for it) the CMake has a another problem in not implementing "inherited build properties" correctly. That is of course if that is what CMake is after with add_library( targ INTERFACE) in the first place. Thanks for the heads up on yet more CMake does not do correctly. I am now climbing upon my "inherited build properties" soap box. It's kinda slippery up here. On Wed, Aug 23, 2017 at 4:57 PM, Jean-Micha?l Celerier < jeanmichael.celerier at gmail.com> wrote: > > Does that work for your needs? > > Sadly, no (but thanks!). While this is enough for the arguably common use > case of include directories, compile flags, etc... there are plenty of > things that won't work with this approach. > > e.g. none of this works for instance: > > project(foo) > > add_library(blah INTERFACE) > set_property(TARGET blah PROPERTY SUFFIX ".mxe") > set_property(TARGET blah PROPERTY CXX_STANDARD 14) > set_property(TARGET blah PROPERTY INSTALL_RPATH "@loader_path/whatever") > > > > > ------- > Jean-Micha?l Celerier > http://www.jcelerier.name > > On Wed, Aug 23, 2017 at 11:23 PM, Brian Davis wrote: > >> So there is some odd replies in the cmake mailing list possibly responses to wrong message, but this looked like a response to mine even if the initial reply to bit is not right from Nicholas. Anywho here goes: >> >> @Jean-Micha?l Celerier >> >> -- snip -- >> >* - Says that custom functions such as add_{project}_library shouldn't be >> *used and function definitions should be used as little as possible. Except >> this just leads to extremely verbose CMakeLists where repeated properties >> are defined again and again and again. >> -- snip -- >> >> Yes add_project_library were my own and in the process of being deprecated. These were geared directly at two problems in cmake. >> >> 1) They were used to get CMake to support the concept of "inherited build properties". >> >> 2) As you stated and is still a problem the verbosity of CMake. Where IMO much could be collaped into one call >> >> >> -- snip -- >> I also never understood how to handle this. >> -- snip -- >> >> I am afraid I don't ultimately have the answer either... I have do some ideas on possibly best course of action. >> >> >> -- snip -- >> I have a project where I want to define, say, -fsanitize=address, -DFOO_BAR >> and the SUFFIX property on a specific set of 25 targets amongst ~100 >> targets. What am I to do ? >> >> * set(CMAKE_CXX_FLAGS "-fsanitize=address") is "not modern CMake" (and also >> would be harder to set / unset on specific targets). >> * calling target_compile_options(...) 25 times ... well I mean, everyone >> knows it's bad to duplicate code. Especially if the change is meant to be >> only when a specific option() is enabled, or for debugging purposes >> * creating a function that would set the correct flags, etc and then call >> this function for each target is apparently "not modern CMake" either. >> * creating and linking to "dummy" INTERFACE targets with the flags and >> properties I want have an awful lot of limitations >> >> So what is the right course of actions here ? >> -- snip -- >> >> I have started using add_library( targ INTERFACE ) to imperilment inherited build properties. Yes the naming convention and use/reuse/misuse of add_library is horrid (library) >> >> I just posted this which may help: >> >> https://cmake.org/pipermail/cmake/2017-August/066119.html >> >> -- snip -- >> Ideally I'd like to add "groups" to targets; e.g. "target Foo is a plugin >> for $software", "target Bar is an integration test" and set per-group >> options, flags, properties, etc. Like >> >> add_group(PluginGroup) >> target_compile_definitions(PluginGroup -DBLAH) >> set_property(GROUP PluginGroup PROPERTIES /* whatever in >> cmake-properties*/) >> set_group(myTarget PluginGroup) // applies everything to the target >> -- snip -- >> >> I won't have all the syntax for what your trying but possibly try: >> >> add_library( PluginGroupInterface INTERFACE) >> target_compile_definitions(PluginGroupInterface -DBLAH) >> set_property(GROUP PluginGroup PROPERTIES /* whatever in >> cmake-properties*/) >> >> I add interface, Interface, or _interface to my interface targets I use like this. Note here library in add library does not actually have to have a library (hence my statements to the horrid miss reuse of add_library for this functionality). It can just have build properties that you want a target to later inherit as far as I understand it or as far as I am miss using it if it is meant to be used some other way. >> >> then... >> >> add_executable( myTarget ) >> >> target_link_libraries( >> myTarget >> PluginGroupInterface >> ) >> >> Does that work for your needs? >> >> >> >> -- snip -- >> Best, >> >> ------- >> Jean-Micha?l Celerier >> >> -- snip -- >> >> >> -- >> >> Powered by www.kitware.com >> >> Please keep messages on-topic and check the CMake FAQ at: >> http://www.cmake.org/Wiki/CMake_FAQ >> >> Kitware offers various services to support the CMake community. For more >> information on each offering, please visit: >> >> CMake Support: http://cmake.org/cmake/help/support.html >> CMake Consulting: http://cmake.org/cmake/help/consulting.html >> CMake Training Courses: http://cmake.org/cmake/help/training.html >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/cmake >> > > -- Brian J. Davis -------------- next part -------------- An HTML attachment was scrubbed... URL: From craig.scott at crascit.com Wed Aug 23 19:37:00 2017 From: craig.scott at crascit.com (Craig Scott) Date: Thu, 24 Aug 2017 07:37:00 +0800 Subject: [CMake] CMake + Gradle for Android In-Reply-To: References: Message-ID: On Thu, Aug 24, 2017 at 5:20 AM, Jom O'Fisher wrote: > We'll definitely be discussing this use case at our next C++ meeting and > I'll also be checking for myself whether ccache will work in this CMake > scenario. If ccache does work it seems like the natural level at which to > fold identical builds. > In case it's helpful, the following article discusses how to set up a project for ccache without having to assume ccache has been installed with symlinks, etc. to replace the default compiler: https://crascit.com/2016/04/09/using-ccache-with-cmake/ This approach has saved us a huge amount of time in our builds, including some fairly complex hierarchical projects. -- Craig Scott Melbourne, Australia https://crascit.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From jomofisher at gmail.com Wed Aug 23 19:45:32 2017 From: jomofisher at gmail.com (Jom O'Fisher) Date: Wed, 23 Aug 2017 16:45:32 -0700 Subject: [CMake] CMake + Gradle for Android In-Reply-To: References: Message-ID: Thanks Craig, I hadn't found that article yet On Wed, Aug 23, 2017 at 4:37 PM, Craig Scott wrote: > > > On Thu, Aug 24, 2017 at 5:20 AM, Jom O'Fisher > wrote: > >> We'll definitely be discussing this use case at our next C++ meeting and >> I'll also be checking for myself whether ccache will work in this CMake >> scenario. If ccache does work it seems like the natural level at which to >> fold identical builds. >> > > In case it's helpful, the following article discusses how to set up a > project for ccache without having to assume ccache has been installed with > symlinks, etc. to replace the default compiler: > > https://crascit.com/2016/04/09/using-ccache-with-cmake/ > > This approach has saved us a huge amount of time in our builds, including > some fairly complex hierarchical projects. > > -- > Craig Scott > Melbourne, Australia > https://crascit.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Martin.LARCHER at ec.europa.eu Thu Aug 24 02:42:51 2017 From: Martin.LARCHER at ec.europa.eu (Martin.LARCHER at ec.europa.eu) Date: Thu, 24 Aug 2017 06:42:51 +0000 Subject: [CMake] CMAKE Fortran - error while coping modules Message-ID: Dear all, I'm quite new in CMAKE. The compilation of our sources (EUROPLEXUS) under Windows is running very well but under Linux I get an error while cmake is copying the module files. For one particular file, cmake uses a wrong filename. See the two bold lines below. Any idea? Many thanks Martin [ 17%] Building Fortran object source/CMakeFiles/epx.dir/m_failed_ghost_elem.f.o cd /home/larchma/cmake/_built/source && /opt/intel/composer_xe_2013_sp1.5.212/bin/intel64/ifort -O0 -traceback -fpp -LIBS:static -c -debug full -debug-parameters all -I/home/larchma/cmake/include -c /home/larchma/cmake/source/m_failed_ghost_elem.f -o CMakeFiles/epx.dir/m_failed_ghost_elem.f.o /usr/bin/cmake -E cmake_copy_f90_mod source/m_failed_ghost_elem source/CMakeFiles/epx.dir/m_failed_ghost_elem.mod.stamp Intel Fortran Compiler /usr/bin/cmake -E touch source/CMakeFiles/epx.dir/m_failed_ghost_elem.f.o.provides.build make[3]: Leaving directory '/home/larchma/cmake/_built' /usr/bin/make -f source/CMakeFiles/epx.dir/build.make source/CMakeFiles/epx.dir/m_material_mco_chg.f.o.provides.build make[3]: Entering directory '/home/larchma/cmake/_built' /usr/bin/cmake -E cmake_progress_report /home/larchma/cmake/_built/CMakeFiles [ 17%] Building Fortran object source/CMakeFiles/epx.dir/m_material_mco_chg.f.o cd /home/larchma/cmake/_built/source && /opt/intel/composer_xe_2013_sp1.5.212/bin/intel64/ifort -O0 -traceback -fpp -LIBS:static -c -debug full -debug-parameters all -I/home/larchma/cmake/include -c /home/larchma/cmake/source/m_material_mco_chg.f -o CMakeFiles/epx.dir/m_material_mco_chg.f.o /usr/bin/cmake -E cmake_copy_f90_mod source/d source/CMakeFiles/epx.dir/d.mod.stamp Intel Fortran Compiler Error copying Fortran module "source/d". Tried "source/D.mod" and "source/d.mod". source/CMakeFiles/epx.dir/depend.make:19476: recipe for target 'source/CMakeFiles/epx.dir/m_material_mco_chg.f.o.provides.build' failed make[3]: *** [source/CMakeFiles/epx.dir/m_material_mco_chg.f.o.provides.build] Error 1 make[3]: Leaving directory '/home/larchma/cmake/_built' source/CMakeFiles/epx.dir/build.make:7670: recipe for target 'source/CMakeFiles/epx.dir/m_material_mco_chg.f.o.provides' failed make[2]: *** [source/CMakeFiles/epx.dir/m_material_mco_chg.f.o.provides] Error 2 make[2]: Leaving directory '/home/larchma/cmake/_built' CMakeFiles/Makefile2:78: recipe for target 'source/CMakeFiles/epx.dir/all' failed make[1]: *** [source/CMakeFiles/epx.dir/all] Error 2 make[1]: Leaving directory '/home/larchma/cmake/_built' Makefile:120: recipe for target 'all' failed -- Dr.-Ing. Martin Larcher European Commission Joint Research Centre, T.P. 480 Directorate for Space, Security and Migration Safety and Security of Buildings I-21027 Ispra (VA) Italy Phone: +39-0332-789563 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: CMakeLists.txt URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: CMakeLists.txt URL: From jeanmichael.celerier at gmail.com Thu Aug 24 03:46:17 2017 From: jeanmichael.celerier at gmail.com (=?UTF-8?Q?Jean=2DMicha=C3=ABl_Celerier?=) Date: Thu, 24 Aug 2017 09:46:17 +0200 Subject: [CMake] Interface Libraries allow include directories but not link directories.. Why? In-Reply-To: References: Message-ID: > Ok got it sorry to hear that certainly because, as soon as I hear > something that would be useful somehow I end up needing it the next day. > So sorry for us both. > > From what your are saying (and I will take your word for it) the CMake has > a another problem in not implementing "inherited build properties" > correctly. That is of course if that is what CMake is after with > add_library( targ INTERFACE) in the first place. > > I think that there is just no mechanism for "inherited build properties". >From the docs ( https://cmake.org/cmake/help/v3.9/manual/cmake-buildsystem.7.html#interface-libraries), INTERFACE targets seems to be meant for header-only libraries. The "inheritance" mechanism in CMake is mainly setting variables in a given folder, but this is imho not flexible enough, and leads to problems when you want to use your library as a subfolder of another since you don't have an easy way to overwrite "child" variables from a parent scope unless the child scope carefully did set(CMAKE_CXX_FLAGS "-my-flags ${CMAKE_CXX_FLAGS}") every time. > Thanks for the heads up on yet more CMake does not do correctly. > > I am now climbing upon my "inherited build properties" soap box. It's > kinda slippery up here. > > On Wed, Aug 23, 2017 at 4:57 PM, Jean-Micha?l Celerier < > jeanmichael.celerier at gmail.com> wrote: > >> > Does that work for your needs? >> >> Sadly, no (but thanks!). While this is enough for the arguably common use >> case of include directories, compile flags, etc... there are plenty of >> things that won't work with this approach. >> >> e.g. none of this works for instance: >> >> project(foo) >> >> add_library(blah INTERFACE) >> set_property(TARGET blah PROPERTY SUFFIX ".mxe") >> set_property(TARGET blah PROPERTY CXX_STANDARD 14) >> set_property(TARGET blah PROPERTY INSTALL_RPATH "@loader_path/whatever") >> >> >> >> >> ------- >> Jean-Micha?l Celerier >> http://www.jcelerier.name >> >> On Wed, Aug 23, 2017 at 11:23 PM, Brian Davis wrote: >> >>> So there is some odd replies in the cmake mailing list possibly responses to wrong message, but this looked like a response to mine even if the initial reply to bit is not right from Nicholas. Anywho here goes: >>> >>> @Jean-Micha?l Celerier >>> >>> -- snip -- >>> >* - Says that custom functions such as add_{project}_library shouldn't be >>> *used and function definitions should be used as little as possible. Except >>> this just leads to extremely verbose CMakeLists where repeated properties >>> are defined again and again and again. >>> -- snip -- >>> >>> Yes add_project_library were my own and in the process of being deprecated. These were geared directly at two problems in cmake. >>> >>> 1) They were used to get CMake to support the concept of "inherited build properties". >>> >>> 2) As you stated and is still a problem the verbosity of CMake. Where IMO much could be collaped into one call >>> >>> >>> -- snip -- >>> I also never understood how to handle this. >>> -- snip -- >>> >>> I am afraid I don't ultimately have the answer either... I have do some ideas on possibly best course of action. >>> >>> >>> -- snip -- >>> I have a project where I want to define, say, -fsanitize=address, -DFOO_BAR >>> and the SUFFIX property on a specific set of 25 targets amongst ~100 >>> targets. What am I to do ? >>> >>> * set(CMAKE_CXX_FLAGS "-fsanitize=address") is "not modern CMake" (and also >>> would be harder to set / unset on specific targets). >>> * calling target_compile_options(...) 25 times ... well I mean, everyone >>> knows it's bad to duplicate code. Especially if the change is meant to be >>> only when a specific option() is enabled, or for debugging purposes >>> * creating a function that would set the correct flags, etc and then call >>> this function for each target is apparently "not modern CMake" either. >>> * creating and linking to "dummy" INTERFACE targets with the flags and >>> properties I want have an awful lot of limitations >>> >>> So what is the right course of actions here ? >>> -- snip -- >>> >>> I have started using add_library( targ INTERFACE ) to imperilment inherited build properties. Yes the naming convention and use/reuse/misuse of add_library is horrid (library) >>> >>> I just posted this which may help: >>> >>> https://cmake.org/pipermail/cmake/2017-August/066119.html >>> >>> -- snip -- >>> Ideally I'd like to add "groups" to targets; e.g. "target Foo is a plugin >>> for $software", "target Bar is an integration test" and set per-group >>> options, flags, properties, etc. Like >>> >>> add_group(PluginGroup) >>> target_compile_definitions(PluginGroup -DBLAH) >>> set_property(GROUP PluginGroup PROPERTIES /* whatever in >>> cmake-properties*/) >>> set_group(myTarget PluginGroup) // applies everything to the target >>> -- snip -- >>> >>> I won't have all the syntax for what your trying but possibly try: >>> >>> add_library( PluginGroupInterface INTERFACE) >>> target_compile_definitions(PluginGroupInterface -DBLAH) >>> set_property(GROUP PluginGroup PROPERTIES /* whatever in >>> cmake-properties*/) >>> >>> I add interface, Interface, or _interface to my interface targets I use like this. Note here library in add library does not actually have to have a library (hence my statements to the horrid miss reuse of add_library for this functionality). It can just have build properties that you want a target to later inherit as far as I understand it or as far as I am miss using it if it is meant to be used some other way. >>> >>> then... >>> >>> add_executable( myTarget ) >>> >>> target_link_libraries( >>> myTarget >>> PluginGroupInterface >>> ) >>> >>> Does that work for your needs? >>> >>> >>> >>> -- snip -- >>> Best, >>> >>> ------- >>> Jean-Micha?l Celerier >>> >>> -- snip -- >>> >>> >>> -- >>> >>> Powered by www.kitware.com >>> >>> Please keep messages on-topic and check the CMake FAQ at: >>> http://www.cmake.org/Wiki/CMake_FAQ >>> >>> Kitware offers various services to support the CMake community. For more >>> information on each offering, please visit: >>> >>> CMake Support: http://cmake.org/cmake/help/support.html >>> CMake Consulting: http://cmake.org/cmake/help/consulting.html >>> CMake Training Courses: http://cmake.org/cmake/help/training.html >>> >>> Visit other Kitware open-source projects at >>> http://www.kitware.com/opensource/opensource.html >>> >>> Follow this link to subscribe/unsubscribe: >>> http://public.kitware.com/mailman/listinfo/cmake >>> >> >> > > > -- > Brian J. Davis > -------------- next part -------------- An HTML attachment was scrubbed... URL: From oelbox at gmail.com Thu Aug 24 04:13:55 2017 From: oelbox at gmail.com (Arne Kjetil Andersen) Date: Thu, 24 Aug 2017 10:13:55 +0200 Subject: [CMake] CMake, Mingw-w64 32 bit exception handling. In-Reply-To: References: Message-ID: On Wed, Aug 23, 2017 at 9:57 PM, Robert Maynard wrote: > A quick scan of CMake source code shows that we don't have any > references to gcc_eh anywhere. I way this could be occurring is > through CMake detection of the implicit libraries that a compiler > requires for each language. In particular it could be that C code for > mingw by default uses gcc_eh while C++ doesn't. The culprit could also > be a FindPackage* you are using. > Hi Robert and thanks for your reply. Yes I also did a scan of the cmake source code before sending the mail to the mailing list, and found no reference to gcc_eh. But I do find reference to that in the CMakeOutput.log file, and it seems to come from detection of implicit libraries. So based on this i started by removing all 3rd party libraries in my project and thought of adding one by one until the -lgcc_eh appeared in the linklibs.rsp, and you are right, adding proj.4 3rd party library to the build system seems to result in -lgcc_eh being added... Now to figure out how to prevent that from occurring in linklibs.rsp file for the test application that does not even use that particular 3rd party library. Thanks again for pointing me in the right direction. Best Regards, Arne Kjetil Andersen > > On Wed, Aug 23, 2017 at 4:55 AM, Arne Kjetil Andersen > wrote: > > Greetings. > > > > I'm a developer on a fairly large project where I'm using CMake version > > 3.9.1 > > > > I primarily work on linux, but also cross compiles for windows using > > Mingw-w64 on my linux box. > > > > I have encountered an issue which I'm having some trouble figuring out. > > Running through some of my tests where an exception is thrown (on > purpose) > > the 32 bit version compiled with Mingw-w64-g++ version 7.1.1 just calls > > terminate even though there are try catch blocks. Now mind you, this all > > works fine on the native linux compiled version of my tests, and also > the 64 > > bit windows version compiled with Mingw-w64-g++ version 7.1.1. > > > > Going through all the projects CMakeLists.txt I could not find any reason > > for this behavior, but tried to add -fexceptions as a compiler option in > the > > top most CMakeLists.txt file for the 32 bit mingw-w64 compiler. > > Unfortunately this made no difference. > > > > So investigating some more I took a look at the linklibs.rsp file > generated > > for that particular test executable, and noticed this entry: > > -lgcc_eh -lgcc_eh > > > > (yes it's twice, but that is not the issue, although that might be a > cmake > > bug?). > > (also note - this option is also present for the 64 bit build files for > > mingw-w64, but there it works as expected). > > > > Now, removing those two library link options from the linklibs.rsp file > > makes the 32 bit windows version of test application work as expected. I > am > > not sure what libgcc_eh.a actually does (tried searching for some > > information, but had little luck actually figuring that out), but > clearly it > > has something to do with exception handling. > > > > Now I figured I would create a small minimal example that would reproduce > > this issue outside my projects source tree. So basically created a small > > program that throws an exception, and catches that. Created a > CMakeLists.txt > > file with the same general options as my farily large project, and had > cmake > > generate the build files for 32 bit mingw-w64. Inspecting the > linklibs.rsp > > file I was surprised to see that "-lgcc_eh" were nowhere to be found, > and as > > such the 32 bit version of this test worked fine. > > > > So, my question is, does anyone know under which circumstances cmake will > > add -lgcc_eh to linklibs.rsp, and is there any way I can prevent cmake > from > > doing so for the 32 bit mingw-w64 compiler? > > > > Also, maybe I'm going about this issue the wrong way, and that my > findings > > mentioned above is not a good way of handling this. Or maybe this might > be a > > bug with the 32 bit mingw-w64 compiler? > > > > I should probably also mention that the 32 bit version of Mingw-w64 uses > the > > sjlj exception handling mechanism. > > > > Any help and pointers would be greatly appreciated - cause adding a step > in > > the developer documentation to go into the linklibs.rsp file to remove > > -lgcc_eh is kind of a last resort. > > > > Thanks for any input on this matter, and please let me know if attaching > > CMakeOutput.log or other files would be beneficial. > > > > Best Regards, > > Arne Kjetil Andersen > > > > > > -- > > > > Powered by www.kitware.com > > > > Please keep messages on-topic and check the CMake FAQ at: > > http://www.cmake.org/Wiki/CMake_FAQ > > > > Kitware offers various services to support the CMake community. For more > > information on each offering, please visit: > > > > CMake Support: http://cmake.org/cmake/help/support.html > > CMake Consulting: http://cmake.org/cmake/help/consulting.html > > CMake Training Courses: http://cmake.org/cmake/help/training.html > > > > Visit other Kitware open-source projects at > > http://www.kitware.com/opensource/opensource.html > > > > Follow this link to subscribe/unsubscribe: > > http://public.kitware.com/mailman/listinfo/cmake > -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? -------------- next part -------------- An HTML attachment was scrubbed... URL: From volker.enderlein at ifm-chemnitz.de Thu Aug 24 08:03:02 2017 From: volker.enderlein at ifm-chemnitz.de (Volker Enderlein) Date: Thu, 24 Aug 2017 14:03:02 +0200 Subject: [CMake] CMAKE Fortran - error while coping modules In-Reply-To: References: Message-ID: Am 24/08/2017 um 08:42 schrieb Martin.LARCHER at ec.europa.eu: > */usr/bin/cmake -E cmake_copy_f90_mod source/d > source/CMakeFiles/epx.dir/d.mod.stamp Intel Fortran Compiler* > Error copying Fortran module "source/d". Tried "source/D.mod" and > "source/d.mod". what CMakeLists.txt does issue this line? Looks to me like a "*d source/*" was creeping into the middle of the string. I didn't found the command looking at the two files you provided. Especially the command */usr/bin/cmake -E cmake_copy_f90_mod* is of interest. Cheers Volker -- From volker.enderlein at ifm-chemnitz.de Thu Aug 24 08:26:12 2017 From: volker.enderlein at ifm-chemnitz.de (Volker Enderlein) Date: Thu, 24 Aug 2017 14:26:12 +0200 Subject: [CMake] CMAKE Fortran - error while coping modules In-Reply-To: References: Message-ID: <11d0472e-795d-d997-bd0d-463183bdee42@ifm-chemnitz.de> Am 24/08/2017 um 14:03 schrieb Volker Enderlein: > Am 24/08/2017 um 08:42 schrieb Martin.LARCHER at ec.europa.eu: >> */usr/bin/cmake -E cmake_copy_f90_mod source/d >> source/CMakeFiles/epx.dir/d.mod.stamp Intel Fortran Compiler* >> Error copying Fortran module "source/d". Tried "source/D.mod" and >> "source/d.mod". > > what CMakeLists.txt does issue this line? Looks to me like a "*d > source/*" was creeping into the middle of the string. I didn't found > the command looking at the two files you provided. Especially the command > > */usr/bin/cmake -E cmake_copy_f90_mod* > > is of interest. > > Cheers Volker > > It rather seems that "m_material_mco_chg" is replaced wth a "d" Cheers Volker -- From james.turner at kdab.com Thu Aug 24 10:08:08 2017 From: james.turner at kdab.com (James Turner) Date: Thu, 24 Aug 2017 15:08:08 +0100 Subject: [CMake] Understanding constraint graph cycles Message-ID: <66D554C8-05E2-40D5-B18E-05E3E93FE218@kdab.com> Hi, Since upgrading to a recent CMake, the FLightGear build system is now reporting this: ========== CMake Warning at utils/fgai/CMakeLists.txt:1 (add_executable): Cannot generate a safe runtime search path for target fgai because there is a cycle in the constraint graph: dir 0 is [/home/jenkins/workspace/FlightGear/dist/lib64] dir 1 must precede it due to runtime library [libosgText.so.130] dir 1 is [/home/jenkins/workspace/SimGear/dist/lib64] dir 0 must precede it due to runtime library [libosgText.so.130] Some of these libraries may not be found correctly. ============== I can guess various dumb things I might have done to cause this, but can anyone give me some context? This is about rpath setting in the executables? SimGear is a helper library for FlightGear, build as static libs, and imported into FlightGear directly. SimGear and FlightGear both depend on OpenSceneGraph, and on our buiuld server (but not commonly in real life) Simgear and FlightGear are being configured with different install prefixes (that?s the /home/jenkins/workspace/dist/lib64 part) Again rather than making ad-hoc changes to fix this, I?d like a bit more understanding about what is intended here, if anyone can suggest it. All this code is publicly visible on SourceForge BTW: https://sourceforge.net/p/flightgear/_list/git?source=navbar Kind regards, James From Martin.LARCHER at ec.europa.eu Thu Aug 24 10:17:54 2017 From: Martin.LARCHER at ec.europa.eu (Martin.LARCHER at ec.europa.eu) Date: Thu, 24 Aug 2017 14:17:54 +0000 Subject: [CMake] CMAKE Fortran - error while coping modules In-Reply-To: <11d0472e-795d-d997-bd0d-463183bdee42@ifm-chemnitz.de> References: , <11d0472e-795d-d997-bd0d-463183bdee42@ifm-chemnitz.de> Message-ID: Dear Volker, indeed the name of the file is replaced by "d". And I have no idea why. All the files before run smoothly. Is there any point where I can get n idea how the internal CMAKE commands are created? Martin -- Dr.-Ing. Martin Larcher European Commission Joint Research Centre, T.P. 480 Directorate for Space, Security and Migration Safety and Security of Buildings I-21027 Ispra (VA) Italy Phone: +39-0332-789563 ________________________________________ From: Volker Enderlein [volker.enderlein at ifm-chemnitz.de] Sent: 24 August 2017 14:26 To: LARCHER Martin (JRC-ISPRA); cmake at cmake.org Subject: Re: [CMake] CMAKE Fortran - error while coping modules Am 24/08/2017 um 14:03 schrieb Volker Enderlein: > Am 24/08/2017 um 08:42 schrieb Martin.LARCHER at ec.europa.eu: >> */usr/bin/cmake -E cmake_copy_f90_mod source/d >> source/CMakeFiles/epx.dir/d.mod.stamp Intel Fortran Compiler* >> Error copying Fortran module "source/d". Tried "source/D.mod" and >> "source/d.mod". > > what CMakeLists.txt does issue this line? Looks to me like a "*d > source/*" was creeping into the middle of the string. I didn't found > the command looking at the two files you provided. Especially the command > > */usr/bin/cmake -E cmake_copy_f90_mod* > > is of interest. > > Cheers Volker > > It rather seems that "m_material_mco_chg" is replaced wth a "d" Cheers Volker -- From volker.enderlein at ifm-chemnitz.de Thu Aug 24 10:47:50 2017 From: volker.enderlein at ifm-chemnitz.de (Volker Enderlein) Date: Thu, 24 Aug 2017 16:47:50 +0200 Subject: [CMake] CMAKE Fortran - error while coping modules In-Reply-To: References: <11d0472e-795d-d997-bd0d-463183bdee42@ifm-chemnitz.de> Message-ID: <8f0e17b7-0c21-75bf-99e9-af8f0352b630@ifm-chemnitz.de> Hi Martin, You can have a look into the makefiles CMake generates for you inside of your build directory. Search for the failing file name there, e.g. do a? find . -name Makefile -exec grep -H 'm_material_mco_chg' {} \; in the build directory. Hope that helps, Cheers Volker Am 24/08/2017 um 16:17 schrieb Martin.LARCHER at ec.europa.eu: > Dear Volker, > indeed the name of the file is replaced by "d". And I have no idea why. All the files before run smoothly. Is there any point where I can get n idea how the internal CMAKE commands are created? > Martin > > > -- > Dr.-Ing. Martin Larcher > European Commission > Joint Research Centre, T.P. 480 > Directorate for Space, Security and Migration > Safety and Security of Buildings > I-21027 Ispra (VA) Italy > Phone: +39-0332-789563 > > ________________________________________ > From: Volker Enderlein [volker.enderlein at ifm-chemnitz.de] > Sent: 24 August 2017 14:26 > To: LARCHER Martin (JRC-ISPRA); cmake at cmake.org > Subject: Re: [CMake] CMAKE Fortran - error while coping modules > > Am 24/08/2017 um 14:03 schrieb Volker Enderlein: >> Am 24/08/2017 um 08:42 schrieb Martin.LARCHER at ec.europa.eu: >>> */usr/bin/cmake -E cmake_copy_f90_mod source/d >>> source/CMakeFiles/epx.dir/d.mod.stamp Intel Fortran Compiler* >>> Error copying Fortran module "source/d". Tried "source/D.mod" and >>> "source/d.mod". >> what CMakeLists.txt does issue this line? Looks to me like a "*d >> source/*" was creeping into the middle of the string. I didn't found >> the command looking at the two files you provided. Especially the command >> >> */usr/bin/cmake -E cmake_copy_f90_mod* >> >> is of interest. >> >> Cheers Volker >> >> > It rather seems that "m_material_mco_chg" is replaced wth a "d" > > > Cheers Volker > > -- > From ycollette.nospam at free.fr Thu Aug 24 10:53:52 2017 From: ycollette.nospam at free.fr (ycollette.nospam at free.fr) Date: Thu, 24 Aug 2017 16:53:52 +0200 (CEST) Subject: [CMake] ExternalProject and Visual studio solutions In-Reply-To: <1182127053.132809955.1503585931288.JavaMail.root@zimbra35-e6> Message-ID: <44356252.132832500.1503586432445.JavaMail.root@zimbra35-e6> Hello, I use cmake 3.8.2 with visual studio 2013 64 bits. I wanted to compile a thirdparty library using ExternalProject When I do this, I meet errors: cmake is trying to read the download timestamp in the wrong directory: the thirdparty library id build in ${CMAKE_BINARY_DIR}/_dep/CoinMP-1.8.3/Debug But in the directory, I also see a ${CMAKE_BINARY_DIR}/_dep/CoinMP-1.8.3/$(Configuration) And cmake is looking at the download timestamp in the debug directory, but it's in the $(Configuration). How can I manage correctly the value of CMAKE_CFG_INTDIR in an ExternalProject ? I put here the part of code I use to compile this thirdparty lib: # ################################################# # ===> CoinMP # ################################################# if (KL_ENABLE_DOWNLOAD_COINMP) set(COINMP_VERSION "1.8.3") set(COINMP_URL "http://www.coin-or.org/download/source/CoinMP/CoinMP-${COINMP_VERSION}.zip") set(COINMP_COMPILATION_OPTIONS " -fPIC -DCOIN_COMPILE_STATIC=${KL_COMPILE_STATIC}") set(COINMP_COMPILATION_OPTIONS "${COINMP_COMPILATION_OPTIONS} -DCOIN_COMPILE_COVERAGE=${KL_COMPILE_COVERAGE}") set(COINMP_COMPILATION_OPTIONS "${COINMP_COMPILATION_OPTIONS} -DCOIN_COMPILE_PROFILE=${KL_COMPILE_PROFILE}") set(COINMP_COMPILATION_OPTIONS "${COINMP_COMPILATION_OPTIONS} -DCOIN_COMPILE_PROFILE_VALGRIND=${KL_COMPILE_PROFILE_VALGRIND}") set(COINMP_COMPILATION_OPTIONS "${COINMP_COMPILATION_OPTIONS} -DCOIN_COMPILE_LTO=${KL_COMPILE_LTO}") set(COINMP_COMPILATION_OPTIONS "${COINMP_COMPILATION_OPTIONS} -DCOIN_COMPILE_WHOPR=${KL_COMPILE_WHOPR}") if (WIN32) set(COINMP_COMPILATION_OPTIONS "${COINMP_COMPILATION_OPTIONS} -DCOIN_ENABLE_DOWNLOAD_PTHREAD_WIN32=ON") endif () set(COINMP_InstallDir "${EP_InstallDir}/CoinMP-${COINMP_VERSION}/${CMAKE_CFG_INTDIR}/") if (WIN32) ExternalProject_Add(EP_CoinMP PREFIX ${COINMP_InstallDir} DEPENDS ${COINMP_LAPACK_DEPENDS} URL ${COINMP_URL} UPDATE_COMMAND "" PATCH_COMMAND ${CMAKE_COMMAND} -E copy_directory ${CMAKE_SOURCE_DIR}/deps/Coin/CoinMP/ ${COINMP_InstallDir}/src/EP_CoinMP/ && ${CMAKE_COMMAND} -E copy ${CMAKE_SOURCE_DIR}/deps/Coin/CoinMP.h ${COINMP_InstallDir}/src/EP_CoinMP/CoinMP/src/ && ${CMAKE_COMMAND} -E make_directory ${COINMP_InstallDir}/src/EP_CoinMP/build/ CONFIGURE_COMMAND ${CMAKE_COMMAND} -E chdir ${COINMP_InstallDir}/src/EP_CoinMP/build ${CMAKE_COMMAND} -DCMAKE_BUILD_TYPE=${CMAKE_BUILD_TYPE} -DCMAKE_INSTALL_PREFIX=${EP_InstallDir}/install/ -DCOIN_HAS_ABC=${KL_USE_ABC} -DCOIN_ABC_LEVEL=${KL_ABC_LEVEL} ${COINMP_COMPILATION_OPTIONS} -DCMAKE_C_FLAGS=${CMAKE_C_FLAGS} -DCMAKE_CXX_FLAGS=${CMAKE_CXX_FLAGS} ${EP_COMPILER} -DCMAKE_TOOLCHAIN_FILE=${CMAKE_TOOLCHAIN_FILE} -G ${CMAKE_GENERATOR} .. BUILD_COMMAND ${CMAKE_COMMAND} -E chdir ${COINMP_InstallDir}/src/EP_CoinMP/build ${CMAKE_COMMAND} --build . --config ${CMAKE_CFG_INTDIR} INSTALL_COMMAND ${CMAKE_COMMAND} -E chdir ${COINMP_InstallDir}/src/EP_CoinMP/build ${CMAKE_COMMAND} --build . --config ${CMAKE_CFG_INTDIR} --target install ) else () ExternalProject_Add(EP_CoinMP PREFIX ${COINMP_InstallDir} DEPENDS ${COINMP_LAPACK_DEPENDS} URL ${COINMP_URL} UPDATE_COMMAND "" PATCH_COMMAND ${CMAKE_COMMAND} -E copy_directory ${CMAKE_SOURCE_DIR}/deps/Coin/CoinMP/ ${COINMP_InstallDir}/src/EP_CoinMP/ && ${CMAKE_COMMAND} -E make_directory ${COINMP_InstallDir}/src/EP_CoinMP/build/ CONFIGURE_COMMAND ${CMAKE_COMMAND} -E chdir ${COINMP_InstallDir}/src/EP_CoinMP/build ${CMAKE_COMMAND} -DCMAKE_BUILD_TYPE=${CMAKE_BUILD_TYPE} -DCMAKE_INSTALL_PREFIX=${EP_InstallDir}/install/ -DCOIN_HAS_ABC=${KL_USE_ABC} -DCOIN_ABC_LEVEL=${KL_ABC_LEVEL} ${COINMP_COMPILATION_OPTIONS} -DCMAKE_C_FLAGS=${CMAKE_C_FLAGS} -DCMAKE_CXX_FLAGS=${CMAKE_CXX_FLAGS} ${EP_COMPILER} -DCMAKE_TOOLCHAIN_FILE=${CMAKE_TOOLCHAIN_FILE} -G ${CMAKE_GENERATOR} .. BUILD_COMMAND ${CMAKE_COMMAND} -E chdir ${COINMP_InstallDir}/src/EP_CoinMP/build ${CMAKE_MAKE_PROGRAM} INSTALL_COMMAND ${CMAKE_COMMAND} -E chdir ${COINMP_InstallDir}/src/EP_CoinMP/build ${CMAKE_MAKE_PROGRAM} install ) endif () endif () # ################################################# # <=== CoinMP # ################################################# Best regards, YC From rcdailey.lists at gmail.com Thu Aug 24 11:33:02 2017 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Thu, 24 Aug 2017 10:33:02 -0500 Subject: [CMake] CMake + Gradle for Android In-Reply-To: References: Message-ID: Thanks for explaining, as usual your answers are making things much more clear. When it's all said and done and considering everything we've discussed up to this point, I'm fine with how you've architected the CMake integration with Gradle. I think the way things function is perfectly fine. My only concern is with a (should I say minor?) implementation detail: Trying to promote CMAKE_BINARY_DIR sharing where feasible to do so. Like I mentioned earlier, I believe that the code-behind for "externalNativeBuild" logic should detect when two "path" files refer to the same physical CMakeLists.txt file within the same build configuration and variant, and if true, reuse/share the same CMAKE_BINARY_DIR instead of generating another one. This seems safe to me since the only difference is possibly which targets get invoked. Optimistically, the best case scenario here is that the 2nd externalNativeBuild has to build nothing and just grab *.so files already built by the first externalNativeProject (so long as both point to the same "path" file on filesystem). Whether or not you decide to specify the "path" at the common ancestor build.gradle (to make managing the configuration in gradle easier since the properties will be transitive) or keep it as it is (require "path" at each leaf build.gradle), you can still check if the same physical CMakeLists.txt file is being used between multiple leaf gradle build files. If ccache is capable of reading build cache between multiple CMake binary dirs, I think it may solve some aspects of this problem: In particular, it might solve the build performance problems (you'd still be building the same libs only once, even across separate CMAKE_BINARY_DIR, if I understand correctly). But it does not solve other issues: In particular, custom_target or custom_command logic that depends on custom timestamp file or caching logic (like, checking if files already exist in CMAKE_BINARY_DIR, and if not, download them, install them, etc. (ExternalProject_Add is a prime example)). Also ccache won't reduce the disk space consumption that would exist due to having multiple CMAKE_BINARY_DIR instead of consolidating and sharing them. Sorry if I'm just repeating myself, but I'm just trying to summarize my thoughts. The situation is complex so I want to make sure I am not leaving out any details for when you do finally discuss this internally. Thanks and let me know how things end up after your C++ meeting! On Wed, Aug 23, 2017 at 4:20 PM, Jom O'Fisher wrote: > By gradle module projects, I just mean the leaf build.gradle files as > opposed to the root build.gradle. By configurations, I mean Build Types > (debug vs release) and Product Flavors (demo vs free vs paid). Hereafter I > will use the term "variant" rather than "configuration" to be precise. See > this write-up on build variants: > > https://developer.android.com/studio/build/build-variants.html#build-types > > This build matrix is constructed at the leaf build.gradle level. Native > build in gradle allows you to set C/C++ flags individually for each variant > so that you can define compiler flags (for example, -DFREE_VERSION). > > One thing to notice at this stage is that the same CMake target may be built > with different compiler flags across different projects, build types, and > product flavors. So in the general case, build outputs won't be the same. > > You asked which targets build when specifying path. By default, we build all > targets that produce an .so. You can override this by setting > externalNativeBuild.cmake.targets. For example, > > paid { > ... > externalNativeBuild { > cmake { > ... > targets "native-lib-paid" > } > } > } > > As for your last question, the model we generally see used is that the main > CMakeLists.txt is next to the leaf build.gradle such that this > CMakeLists.txt doesn't couple with peer APK project CMakeLists.txt (though > they may share common dependencies and settings). Otherwise, multiple APK > projects would perform pretty much similar to yours--they would build > targets per-leaf project and not share build outputs. As far as I can see > your organization is just as valid so long as you only build the targets you > need. > > Regarding native dependencies between java projects. We generally try to > avoid making the CMake build depend on the gradle build (you should be able > to replicate the CMake build from the command-line if you set the right > flags). At the moment I don't see a way we could make things better without > violating that tenet but that could be lack of imagination on my part. > > We'll definitely be discussing this use case at our next C++ meeting and > I'll also be checking for myself whether ccache will work in this CMake > scenario. If ccache does work it seems like the natural level at which to > fold identical builds. > > > > On Wed, Aug 23, 2017 at 1:03 PM, Robert Dailey > wrote: >> >> I'm not sure what you mean by "gradle module projects", but maybe >> having some examples of what you mean by "configurations, C++ flags, >> etc" might make it more clear. >> >> Question: When specifying "path" for the CMakeLists.txt in the >> build.gradle file, how do you know which targets to build? For >> example, that run of CMake may generate 100 targets, but only 20 need >> to build and be packaged (*.so files) with the APK. Do you just build >> "all"? Is there a way to specify the target itself? >> >> Thanks again. I'd still like to know more about what the ideal >> organization is. I find it hard to believe that large android projects >> rarely break things up into multiple, separate "components" that are >> built independently. That's really the gist of what we're dealing with >> here. Your typical "hello world" project likely will have only 1 >> CMakeLists.txt that is pretty self-contained, but all the >> documentation I've looked at so far doesn't show the best way to >> handle native library dependencies across java projects between >> build.gradle files (or maybe I'm just not looking hard enough). >> >> On Wed, Aug 23, 2017 at 1:02 PM, Jom O'Fisher >> wrote: >> > Thanks for the write-up Robert. Having thought about it, I don't believe >> > we >> > have a satisfying answer at the gradle level for this kind of >> > organization. >> > In the gradle model module projects are the unit of organization for >> > configurations, C/C++ flags, etc. and that's something we're pretty much >> > stuck with. >> > Regarding just the redundant build issue, would something like ccache >> > help? >> > I know people have used it with ndk-build with success, I'm not sure >> > about >> > CMake but I don't see why that should make a difference. >> > >> > >> > >> > On Tue, Aug 22, 2017 at 10:27 AM, Robert Dailey >> > >> > wrote: >> >> >> >> Another reason to reduce the number of binary directories is that >> >> there are different ways of managing third party libraries. One in >> >> particular that we use is to clone a repository into the binary >> >> directory and build all third party libs in real time based on a >> >> toolchain file (Similar to the functionality provided by >> >> ExternalProject module in CMake). This is repeated from scratch only >> >> if the work hasn't already been done in the binary directory before. >> >> By having more binary dirs than needed, this work is being done an >> >> exponential amount of times which can result in a lot of wasted time >> >> waiting. There are 1 time operations that multiple targets can benefit >> >> from in a single binary tree, instead of 1 per unique target being >> >> invoked. >> >> >> >> Sorry to keep responding: I'm just thinking of things as I go and >> >> bringing them up, to shed light on some of the reasoning behind my >> >> suggestions. >> >> >> >> On Tue, Aug 22, 2017 at 9:26 AM, Robert Dailey >> >> >> >> wrote: >> >> > Sorry I forgot to answer your last set of questions: >> >> > >> >> > CommonLib is indeed 2 things: >> >> > >> >> > * A common (static or shared) library for native code (most of our >> >> > CMake targets specify CommonLib as a link dependency) >> >> > * A common library for Java code (we do specify this as a dependency >> >> > for most java targets in Gradle, specifically those under >> >> > Applications/) >> >> > >> >> > On Mon, Aug 21, 2017 at 6:20 PM, Raymond Chiu >> >> > wrote: >> >> >> Hi Robert, >> >> >> >> >> >> I work with Jom on the Android Studio team, and I would like to >> >> >> clarify >> >> >> a >> >> >> few things to better understand your situation. >> >> >> You mentioned the project is intend to be cross platform. Normally, >> >> >> in >> >> >> such >> >> >> situation, we expect there to be a single CMake root project to be >> >> >> imported >> >> >> into one of the Android library/application. However, in your case, >> >> >> there >> >> >> are subprojects with Java code. >> >> >> >> >> >> Are the CMake code in App1/2/3 intended to be cross platform too? >> >> >> Or >> >> >> are >> >> >> they Android specific code? If they are meant to be cross platform, >> >> >> how >> >> >> does the Java code works on other platforms? Or perhaps you added >> >> >> Java >> >> >> binding in those subprojects just for Android? >> >> >> >> >> >> The build.gradle in CommonLib, what kind of Gradle project is that? >> >> >> From >> >> >> your description, it doesn't look like an Android library project. >> >> >> Or >> >> >> am I >> >> >> mistaken and it also applies the android library plugin? >> >> >> >> >> >> Raymond >> >> >> >> >> >> On Mon, Aug 21, 2017 at 3:34 PM, Jom O'Fisher >> >> >> wrote: >> >> >>> >> >> >>> + a colleague >> >> >>> >> >> >>> On Mon, Aug 21, 2017 at 3:11 PM, Jom O'Fisher >> >> >>> >> >> >>> wrote: >> >> >>>> >> >> >>>> You can find that number like this: >> >> >>>> - x = number of externalNativeBuild.cmake.path in your >> >> >>>> build.gradle >> >> >>>> files >> >> >>>> - y = number of gradle configurations (like debug and release) >> >> >>>> - z = number of ABIs that you build >> >> >>>> >> >> >>>> The result is x * y * z. To be more accurate, you should consider >> >> >>>> y >> >> >>>> and z >> >> >>>> to be functions of each build.gradle file since these can vary. >> >> >>>> >> >> >>>> There is a second set of folders that hold the stripped versions >> >> >>>> of >> >> >>>> the >> >> >>>> .so files that is purely managed by the android gradle plugin, so >> >> >>>> you >> >> >>>> might >> >> >>>> consider the answer to be 2 * x * y * z. >> >> >>>> >> >> >>>> Hope this helps. >> >> >>>> >> >> >>>> >> >> >>>> >> >> >>>> >> >> >>>> >> >> >>>> >> >> >>>> On Mon, Aug 21, 2017 at 2:41 PM, Robert Dailey >> >> >>>> >> >> >>>> wrote: >> >> >>>>> >> >> >>>>> This definitely a bit better, but still requires the boilerplate >> >> >>>>> in >> >> >>>>> each leaf gradle file. But I can't seriously complain too much. I >> >> >>>>> think I'm more concerned with the implications this has >> >> >>>>> underneath. >> >> >>>>> First, let me ask just to make sure I'm not misunderstanding: >> >> >>>>> Does >> >> >>>>> each `externalNativeBuild` entry essentially mean 1 >> >> >>>>> CMAKE_BINARY_DIR? >> >> >>>>> How many binary dirs do you manage internally and what determines >> >> >>>>> when >> >> >>>>> they get created? >> >> >>>>> >> >> >>>>> On Mon, Aug 21, 2017 at 2:35 PM, Jom O'Fisher >> >> >>>>> >> >> >>>>> wrote: >> >> >>>>> > Would it work for your scenario to provide properties in the >> >> >>>>> > root >> >> >>>>> > build.gradle: >> >> >>>>> > >> >> >>>>> > ext { >> >> >>>>> > cmakePath = file "CMakeLists.txt" >> >> >>>>> > } >> >> >>>>> > >> >> >>>>> > And then consume them in the leaf app/build.gradle like this? >> >> >>>>> > >> >> >>>>> > externalNativeBuild { >> >> >>>>> > cmake { >> >> >>>>> > path cmakePath >> >> >>>>> > } >> >> >>>>> > } >> >> >>>>> > >> >> >>>>> > It doesn't fully hide the details but it does centralize the >> >> >>>>> > information. >> >> >>>>> > >> >> >>>>> > >> >> >>>>> > On Mon, Aug 21, 2017 at 11:20 AM, Robert Dailey >> >> >>>>> > >> >> >>>>> > wrote: >> >> >>>>> >> >> >> >>>>> >> I wouldn't want to do that, it's too convoluted. I have other >> >> >>>>> >> platforms that use these CMake scripts as well. For example, I >> >> >>>>> >> run on >> >> >>>>> >> Windows and Linux platforms as well to build the native code. >> >> >>>>> >> Normal >> >> >>>>> >> CMake behavior is designed to work at a root then go downwards >> >> >>>>> >> to >> >> >>>>> >> find >> >> >>>>> >> targets. However it seems Gradle wants to start at a >> >> >>>>> >> subdirectory >> >> >>>>> >> and >> >> >>>>> >> work its way up to the root, which is opposite of CMake's >> >> >>>>> >> intended >> >> >>>>> >> behavior IMHO. Not only that but I want to avoid >> >> >>>>> >> special-casing >> >> >>>>> >> behavior in CMake just for Android's use. >> >> >>>>> >> >> >> >>>>> >> At the moment it feels like (again referring back to my >> >> >>>>> >> previous >> >> >>>>> >> example structure) that both App2 and App3 each run CMake in >> >> >>>>> >> independent binary directories instead of sharing 1 binary >> >> >>>>> >> directory >> >> >>>>> >> and building 2 targets inside of it. I prefer this behavior >> >> >>>>> >> instead, >> >> >>>>> >> especially since it allows CMake to operate as it was >> >> >>>>> >> intended. I >> >> >>>>> >> think it's a common case that projects will define multiple >> >> >>>>> >> targets >> >> >>>>> >> starting from a single root, and expect multiple APKs or java >> >> >>>>> >> dependencies to be built within it. >> >> >>>>> >> >> >> >>>>> >> If I'm misunderstanding or making false assumptions please let >> >> >>>>> >> me >> >> >>>>> >> know. >> >> >>>>> >> >> >> >>>>> >> >> >> >>>>> >> >> >> >>>>> >> On Mon, Aug 21, 2017 at 12:00 PM, Jom O'Fisher >> >> >>>>> >> >> >> >>>>> >> wrote: >> >> >>>>> >> > Would it work for your situation for the leaf CMakeLists.txt >> >> >>>>> >> > to >> >> >>>>> >> > include >> >> >>>>> >> > the >> >> >>>>> >> > root CMakeLists.txt? Then have the leaf-specific logic in >> >> >>>>> >> > the >> >> >>>>> >> > leaf >> >> >>>>> >> > CMakeLists.txt? >> >> >>>>> >> > >> >> >>>>> >> > >> >> >>>>> >> > >> >> >>>>> >> > On Mon, Aug 21, 2017 at 9:33 AM, Robert Dailey >> >> >>>>> >> > >> >> >>>>> >> > wrote: >> >> >>>>> >> >> >> >> >>>>> >> >> Basically, yes. We have this sort of structure: >> >> >>>>> >> >> >> >> >>>>> >> >> / >> >> >>>>> >> >> Applications/ >> >> >>>>> >> >> App1/ >> >> >>>>> >> >> build.gradle >> >> >>>>> >> >> CMakeLists.txt >> >> >>>>> >> >> App2/ >> >> >>>>> >> >> build.gradle >> >> >>>>> >> >> CMakeLists.txt >> >> >>>>> >> >> App3/ >> >> >>>>> >> >> build.gradle >> >> >>>>> >> >> CMakeLists.txt >> >> >>>>> >> >> CommonLib/ >> >> >>>>> >> >> build.gradle >> >> >>>>> >> >> CMakeLists.txt >> >> >>>>> >> >> CMakeLists.txt >> >> >>>>> >> >> >> >> >>>>> >> >> The libs are defined as follows: >> >> >>>>> >> >> >> >> >>>>> >> >> * CommonLib is a static library (java code builds into a >> >> >>>>> >> >> library) >> >> >>>>> >> >> * No dependencies of its own >> >> >>>>> >> >> * App1 is a shared library (java code builds into a >> >> >>>>> >> >> library) >> >> >>>>> >> >> * Dependencies (both java & native): CommonLib >> >> >>>>> >> >> * App2 is a shared library (java code builds into an APK) >> >> >>>>> >> >> * Dependencies (both java & native): App1, CommonLib >> >> >>>>> >> >> * App3 is a shared library (java code builds into an APK) >> >> >>>>> >> >> * Dependencies (both java & native): CommonLib >> >> >>>>> >> >> >> >> >>>>> >> >> In all cases, CMake must be invoked starting at the root >> >> >>>>> >> >> CMakeLists.txt 1 time. Each target can be built from the >> >> >>>>> >> >> same >> >> >>>>> >> >> binary >> >> >>>>> >> >> directory after that. Previously with ANT, I was building >> >> >>>>> >> >> all >> >> >>>>> >> >> native >> >> >>>>> >> >> targets first, then moved libs to appropriate directories >> >> >>>>> >> >> so >> >> >>>>> >> >> that >> >> >>>>> >> >> the >> >> >>>>> >> >> 'ant' command would package the libs. >> >> >>>>> >> >> >> >> >>>>> >> >> For gradle, I wanted to avoid redundantly specifying the >> >> >>>>> >> >> root >> >> >>>>> >> >> directory in each leaf-level project directory. Using the >> >> >>>>> >> >> example >> >> >>>>> >> >> above, the leaf-level directories in this case would be >> >> >>>>> >> >> App1, >> >> >>>>> >> >> App2, >> >> >>>>> >> >> App3, and CommonLib. However I think we only specify the >> >> >>>>> >> >> native >> >> >>>>> >> >> CMake >> >> >>>>> >> >> stuff for the java targets that actually output an APK >> >> >>>>> >> >> (that >> >> >>>>> >> >> would >> >> >>>>> >> >> be >> >> >>>>> >> >> App2 and App3 only). >> >> >>>>> >> >> >> >> >>>>> >> >> The ultimate goal is to specify stuff that doesn't change >> >> >>>>> >> >> per >> >> >>>>> >> >> independent "module" of ours at the top level so it is >> >> >>>>> >> >> transitive >> >> >>>>> >> >> / >> >> >>>>> >> >> inherited. Then only specify the differences (e.g. the >> >> >>>>> >> >> native >> >> >>>>> >> >> CMake >> >> >>>>> >> >> target to build) in the leaf build gradle files. However >> >> >>>>> >> >> you >> >> >>>>> >> >> indicated >> >> >>>>> >> >> this isn't possible. >> >> >>>>> >> >> >> >> >>>>> >> >> >> >> >>>>> >> >> >> >> >>>>> >> >> On Mon, Aug 21, 2017 at 11:11 AM, Jom O'Fisher >> >> >>>>> >> >> >> >> >>>>> >> >> wrote: >> >> >>>>> >> >> > What you're doing already sounds correct. You can't >> >> >>>>> >> >> > directly >> >> >>>>> >> >> > specify >> >> >>>>> >> >> > CMakeLists.txt from the top-level build.gradle. >> >> >>>>> >> >> > Recommendation >> >> >>>>> >> >> > is >> >> >>>>> >> >> > that >> >> >>>>> >> >> > it >> >> >>>>> >> >> > should be specified from the build.gradle of the module >> >> >>>>> >> >> > of >> >> >>>>> >> >> > the >> >> >>>>> >> >> > APK. >> >> >>>>> >> >> > Is >> >> >>>>> >> >> > the >> >> >>>>> >> >> > issue that you have multiple APK modules that all >> >> >>>>> >> >> > reference >> >> >>>>> >> >> > the >> >> >>>>> >> >> > same >> >> >>>>> >> >> > CMake >> >> >>>>> >> >> > libraries? >> >> >>>>> >> >> > >> >> >>>>> >> >> > On Mon, Aug 21, 2017 at 9:00 AM, Robert Dailey >> >> >>>>> >> >> > >> >> >>>>> >> >> > wrote: >> >> >>>>> >> >> >> >> >> >>>>> >> >> >> Thanks this is very helpful. The other question I have >> >> >>>>> >> >> >> is: >> >> >>>>> >> >> >> Is >> >> >>>>> >> >> >> there >> >> >>>>> >> >> >> a >> >> >>>>> >> >> >> place to centrally specify the root CMakeLists.txt? >> >> >>>>> >> >> >> Basically, >> >> >>>>> >> >> >> I >> >> >>>>> >> >> >> want >> >> >>>>> >> >> >> to specify the CMake root in 1 place, and have targets >> >> >>>>> >> >> >> (defined >> >> >>>>> >> >> >> further down in subdirectories) that require APK >> >> >>>>> >> >> >> packaging >> >> >>>>> >> >> >> to >> >> >>>>> >> >> >> specify >> >> >>>>> >> >> >> only the native target name that should be built & >> >> >>>>> >> >> >> packaged. >> >> >>>>> >> >> >> >> >> >>>>> >> >> >> At the moment we specify the root CMakeLists.txt by >> >> >>>>> >> >> >> walking >> >> >>>>> >> >> >> up >> >> >>>>> >> >> >> the >> >> >>>>> >> >> >> tree, paths like "../../../../CMakeLists.txt". I think >> >> >>>>> >> >> >> this >> >> >>>>> >> >> >> should >> >> >>>>> >> >> >> be >> >> >>>>> >> >> >> put at the top-level build gradle file if possible. Is >> >> >>>>> >> >> >> this >> >> >>>>> >> >> >> doable >> >> >>>>> >> >> >> at >> >> >>>>> >> >> >> the moment? What is the recommended setup? >> >> >>>>> >> >> >> >> >> >>>>> >> >> >> On Mon, Aug 21, 2017 at 9:37 AM, Jom O'Fisher >> >> >>>>> >> >> >> >> >> >>>>> >> >> >> wrote: >> >> >>>>> >> >> >> > Gradle does introspection on the CMake build to find >> >> >>>>> >> >> >> > .so >> >> >>>>> >> >> >> > targets >> >> >>>>> >> >> >> > and >> >> >>>>> >> >> >> > those >> >> >>>>> >> >> >> > get packaged. >> >> >>>>> >> >> >> > There is also a special case for stl/runtime .so files >> >> >>>>> >> >> >> > from >> >> >>>>> >> >> >> > the >> >> >>>>> >> >> >> > NDK. >> >> >>>>> >> >> >> > Any additional .so files need to specified in >> >> >>>>> >> >> >> > build.gradle >> >> >>>>> >> >> >> > using >> >> >>>>> >> >> >> > jniDirs >> >> >>>>> >> >> >> > >> >> >>>>> >> >> >> > On Mon, Aug 21, 2017 at 7:30 AM, Robert Dailey >> >> >>>>> >> >> >> > >> >> >>>>> >> >> >> > wrote: >> >> >>>>> >> >> >> >> >> >> >>>>> >> >> >> >> How exactly does Gradle package *.so files in an APK? >> >> >>>>> >> >> >> >> I >> >> >>>>> >> >> >> >> know >> >> >>>>> >> >> >> >> that >> >> >>>>> >> >> >> >> ANT >> >> >>>>> >> >> >> >> used to do this for any libs under "libs/". Does >> >> >>>>> >> >> >> >> Gradle >> >> >>>>> >> >> >> >> do >> >> >>>>> >> >> >> >> some >> >> >>>>> >> >> >> >> introspection into CMake targets to see if outputs >> >> >>>>> >> >> >> >> are >> >> >>>>> >> >> >> >> *.so, >> >> >>>>> >> >> >> >> and >> >> >>>>> >> >> >> >> copy >> >> >>>>> >> >> >> >> those to some location if needed? What about >> >> >>>>> >> >> >> >> libraries >> >> >>>>> >> >> >> >> like >> >> >>>>> >> >> >> >> libgnustl_shared.so that come with the NDK? I'd like >> >> >>>>> >> >> >> >> to >> >> >>>>> >> >> >> >> know >> >> >>>>> >> >> >> >> if >> >> >>>>> >> >> >> >> any >> >> >>>>> >> >> >> >> manual copy steps are needed in CMake to put outputs >> >> >>>>> >> >> >> >> in >> >> >>>>> >> >> >> >> proper >> >> >>>>> >> >> >> >> locations for the APK build step. I had to do this >> >> >>>>> >> >> >> >> when >> >> >>>>> >> >> >> >> using >> >> >>>>> >> >> >> >> ANT. >> >> >>>>> >> >> >> >> >> >> >>>>> >> >> >> >> On Mon, Aug 7, 2017 at 6:16 PM, Jom O'Fisher >> >> >>>>> >> >> >> >> >> >> >>>>> >> >> >> >> wrote: >> >> >>>>> >> >> >> >> > 1) There is a folder created for each ABI under the >> >> >>>>> >> >> >> >> > project >> >> >>>>> >> >> >> >> > module >> >> >>>>> >> >> >> >> > folder >> >> >>>>> >> >> >> >> > (so unique per module per ABI) >> >> >>>>> >> >> >> >> > 2) Gradle doesn't specify language level though you >> >> >>>>> >> >> >> >> > can >> >> >>>>> >> >> >> >> > choose >> >> >>>>> >> >> >> >> > to >> >> >>>>> >> >> >> >> > specify it >> >> >>>>> >> >> >> >> > yourself from the build.gradle. This doc does a >> >> >>>>> >> >> >> >> > pretty >> >> >>>>> >> >> >> >> > good job >> >> >>>>> >> >> >> >> > of >> >> >>>>> >> >> >> >> > explaining which variables are set by Gradle: >> >> >>>>> >> >> >> >> > >> >> >>>>> >> >> >> >> > >> >> >>>>> >> >> >> >> > >> >> >>>>> >> >> >> >> > https://developer.android.com/ndk/guides/cmake.html#variables. >> >> >>>>> >> >> >> >> > Philosophically, we try to set as little as we can >> >> >>>>> >> >> >> >> > get >> >> >>>>> >> >> >> >> > away >> >> >>>>> >> >> >> >> > with. >> >> >>>>> >> >> >> >> > In >> >> >>>>> >> >> >> >> > particular, the section titled "Understanding the >> >> >>>>> >> >> >> >> > CMake >> >> >>>>> >> >> >> >> > build >> >> >>>>> >> >> >> >> > command" >> >> >>>>> >> >> >> >> > lays >> >> >>>>> >> >> >> >> > out exactly what we set. You can also see the >> >> >>>>> >> >> >> >> > folders >> >> >>>>> >> >> >> >> > we >> >> >>>>> >> >> >> >> > specify >> >> >>>>> >> >> >> >> > (one >> >> >>>>> >> >> >> >> > per >> >> >>>>> >> >> >> >> > module per ABI) >> >> >>>>> >> >> >> >> > 3) Not sure I understand this. >> >> >>>>> >> >> >> >> > >> >> >>>>> >> >> >> >> > The other document worth taking a look at (if you >> >> >>>>> >> >> >> >> > haven't >> >> >>>>> >> >> >> >> > already) >> >> >>>>> >> >> >> >> > is: >> >> >>>>> >> >> >> >> > >> >> >>>>> >> >> >> >> > >> >> >>>>> >> >> >> >> > >> >> >>>>> >> >> >> >> > >> >> >>>>> >> >> >> >> > https://developer.android.com/studio/projects/add-native-code.html >> >> >>>>> >> >> >> >> > >> >> >>>>> >> >> >> >> > >> >> >>>>> >> >> >> >> > On Mon, Aug 7, 2017 at 3:35 PM, Robert Dailey >> >> >>>>> >> >> >> >> > >> >> >>>>> >> >> >> >> > wrote: >> >> >>>>> >> >> >> >> >> >> >> >>>>> >> >> >> >> >> Thanks Jom >> >> >>>>> >> >> >> >> >> >> >> >>>>> >> >> >> >> >> Honestly, I prefer option 1 to work simply because >> >> >>>>> >> >> >> >> >> that's >> >> >>>>> >> >> >> >> >> how >> >> >>>>> >> >> >> >> >> Google's >> >> >>>>> >> >> >> >> >> officially supporting CMake. But it also has >> >> >>>>> >> >> >> >> >> debugging >> >> >>>>> >> >> >> >> >> which >> >> >>>>> >> >> >> >> >> is >> >> >>>>> >> >> >> >> >> the >> >> >>>>> >> >> >> >> >> #1 >> >> >>>>> >> >> >> >> >> reason for me. >> >> >>>>> >> >> >> >> >> >> >> >>>>> >> >> >> >> >> However, I'd like to understand a lot more about >> >> >>>>> >> >> >> >> >> how >> >> >>>>> >> >> >> >> >> the >> >> >>>>> >> >> >> >> >> integration >> >> >>>>> >> >> >> >> >> really happens. For example, I have these >> >> >>>>> >> >> >> >> >> questions: >> >> >>>>> >> >> >> >> >> >> >> >>>>> >> >> >> >> >> 1) How, internally, are CMake build directories >> >> >>>>> >> >> >> >> >> managed? >> >> >>>>> >> >> >> >> >> Do >> >> >>>>> >> >> >> >> >> you >> >> >>>>> >> >> >> >> >> generate 1 per unique android project? What about >> >> >>>>> >> >> >> >> >> for >> >> >>>>> >> >> >> >> >> each >> >> >>>>> >> >> >> >> >> specific >> >> >>>>> >> >> >> >> >> platform (x86, armeabi-v7a, etc)? >> >> >>>>> >> >> >> >> >> 2) Last time I looked into CMake integration, >> >> >>>>> >> >> >> >> >> things >> >> >>>>> >> >> >> >> >> defined >> >> >>>>> >> >> >> >> >> inside >> >> >>>>> >> >> >> >> >> the CMake scripts were ignored because they are >> >> >>>>> >> >> >> >> >> specified >> >> >>>>> >> >> >> >> >> at >> >> >>>>> >> >> >> >> >> the >> >> >>>>> >> >> >> >> >> command line. Namely, all of those settings that >> >> >>>>> >> >> >> >> >> are >> >> >>>>> >> >> >> >> >> driven by >> >> >>>>> >> >> >> >> >> the >> >> >>>>> >> >> >> >> >> Gradle configuration (CXX language level was one >> >> >>>>> >> >> >> >> >> in >> >> >>>>> >> >> >> >> >> particular >> >> >>>>> >> >> >> >> >> I >> >> >>>>> >> >> >> >> >> think; I specify C++14 support via CMake, but I >> >> >>>>> >> >> >> >> >> recall >> >> >>>>> >> >> >> >> >> this >> >> >>>>> >> >> >> >> >> being >> >> >>>>> >> >> >> >> >> overridden from outside)? >> >> >>>>> >> >> >> >> >> 3) How redundant is it to configure individual >> >> >>>>> >> >> >> >> >> libraries >> >> >>>>> >> >> >> >> >> via >> >> >>>>> >> >> >> >> >> the >> >> >>>>> >> >> >> >> >> gradle scripts? In my previous attempts, I wanted >> >> >>>>> >> >> >> >> >> to >> >> >>>>> >> >> >> >> >> define >> >> >>>>> >> >> >> >> >> common >> >> >>>>> >> >> >> >> >> stuff for CMake / native code at the root gradle >> >> >>>>> >> >> >> >> >> or >> >> >>>>> >> >> >> >> >> settings >> >> >>>>> >> >> >> >> >> file, >> >> >>>>> >> >> >> >> >> and >> >> >>>>> >> >> >> >> >> only define the differences in the actual gradle >> >> >>>>> >> >> >> >> >> build >> >> >>>>> >> >> >> >> >> files >> >> >>>>> >> >> >> >> >> for >> >> >>>>> >> >> >> >> >> each >> >> >>>>> >> >> >> >> >> corresponding Java target (like, defining the name >> >> >>>>> >> >> >> >> >> of >> >> >>>>> >> >> >> >> >> the >> >> >>>>> >> >> >> >> >> native >> >> >>>>> >> >> >> >> >> (shared library) target in Gradle, but the command >> >> >>>>> >> >> >> >> >> line >> >> >>>>> >> >> >> >> >> invocation, >> >> >>>>> >> >> >> >> >> -D >> >> >>>>> >> >> >> >> >> CMake settings, etc would all be common and >> >> >>>>> >> >> >> >> >> defined >> >> >>>>> >> >> >> >> >> at >> >> >>>>> >> >> >> >> >> the >> >> >>>>> >> >> >> >> >> root). >> >> >>>>> >> >> >> >> >> >> >> >>>>> >> >> >> >> >> The TLDR is, the closer we can stay to CMake's way >> >> >>>>> >> >> >> >> >> of >> >> >>>>> >> >> >> >> >> doing >> >> >>>>> >> >> >> >> >> things >> >> >>>>> >> >> >> >> >> and >> >> >>>>> >> >> >> >> >> keep CMake-related settings self-contained to the >> >> >>>>> >> >> >> >> >> CMake >> >> >>>>> >> >> >> >> >> scripts >> >> >>>>> >> >> >> >> >> themselves, the better. This also makes >> >> >>>>> >> >> >> >> >> cross-platform >> >> >>>>> >> >> >> >> >> easier >> >> >>>>> >> >> >> >> >> (we >> >> >>>>> >> >> >> >> >> build the native code in Windows, for example, so >> >> >>>>> >> >> >> >> >> having >> >> >>>>> >> >> >> >> >> settings >> >> >>>>> >> >> >> >> >> specified in the gradle files do not carry over to >> >> >>>>> >> >> >> >> >> other >> >> >>>>> >> >> >> >> >> platforms. >> >> >>>>> >> >> >> >> >> Namely, settings that are not platform specific >> >> >>>>> >> >> >> >> >> like >> >> >>>>> >> >> >> >> >> the >> >> >>>>> >> >> >> >> >> C++ >> >> >>>>> >> >> >> >> >> language >> >> >>>>> >> >> >> >> >> level). >> >> >>>>> >> >> >> >> >> >> >> >>>>> >> >> >> >> >> If there's a detailed document / wiki I can read >> >> >>>>> >> >> >> >> >> on >> >> >>>>> >> >> >> >> >> the >> >> >>>>> >> >> >> >> >> intrinsics >> >> >>>>> >> >> >> >> >> of >> >> >>>>> >> >> >> >> >> CMake integration in Gradle / Android Studio, I'd >> >> >>>>> >> >> >> >> >> love to >> >> >>>>> >> >> >> >> >> read >> >> >>>>> >> >> >> >> >> it. >> >> >>>>> >> >> >> >> >> Otherwise, I hope you won't mind if I pick your >> >> >>>>> >> >> >> >> >> brain >> >> >>>>> >> >> >> >> >> as >> >> >>>>> >> >> >> >> >> questions >> >> >>>>> >> >> >> >> >> come up. I think I'm going to try option 1 for now >> >> >>>>> >> >> >> >> >> and >> >> >>>>> >> >> >> >> >> see how >> >> >>>>> >> >> >> >> >> it >> >> >>>>> >> >> >> >> >> goes. It's just black box for me because unlike >> >> >>>>> >> >> >> >> >> option 2, >> >> >>>>> >> >> >> >> >> I >> >> >>>>> >> >> >> >> >> have >> >> >>>>> >> >> >> >> >> very >> >> >>>>> >> >> >> >> >> little control over what happens after building >> >> >>>>> >> >> >> >> >> the >> >> >>>>> >> >> >> >> >> shared >> >> >>>>> >> >> >> >> >> libraries, >> >> >>>>> >> >> >> >> >> and to make up for that I need to really get a >> >> >>>>> >> >> >> >> >> deep >> >> >>>>> >> >> >> >> >> understanding >> >> >>>>> >> >> >> >> >> of >> >> >>>>> >> >> >> >> >> how it works so I can make sure I code my CMake >> >> >>>>> >> >> >> >> >> scripts >> >> >>>>> >> >> >> >> >> properly >> >> >>>>> >> >> >> >> >> for >> >> >>>>> >> >> >> >> >> not only Android, but my other platforms as well >> >> >>>>> >> >> >> >> >> (non-Android >> >> >>>>> >> >> >> >> >> platforms). >> >> >>>>> >> >> >> >> >> >> >> >>>>> >> >> >> >> >> Thanks again. >> >> >>>>> >> >> >> >> >> >> >> >>>>> >> >> >> >> >> On Mon, Aug 7, 2017 at 5:12 PM, Jom O'Fisher >> >> >>>>> >> >> >> >> >> >> >> >>>>> >> >> >> >> >> wrote: >> >> >>>>> >> >> >> >> >> > Either option can work fine. Disclosure: I work >> >> >>>>> >> >> >> >> >> > on >> >> >>>>> >> >> >> >> >> > Android >> >> >>>>> >> >> >> >> >> > Studio >> >> >>>>> >> >> >> >> >> > and >> >> >>>>> >> >> >> >> >> > was >> >> >>>>> >> >> >> >> >> > the one that added CMake support. >> >> >>>>> >> >> >> >> >> > >> >> >>>>> >> >> >> >> >> > Option (1) is the way it's designed to work and >> >> >>>>> >> >> >> >> >> > we're >> >> >>>>> >> >> >> >> >> > working >> >> >>>>> >> >> >> >> >> > toward >> >> >>>>> >> >> >> >> >> > getting >> >> >>>>> >> >> >> >> >> > rid of the need for the CMake fork. I can't >> >> >>>>> >> >> >> >> >> > really >> >> >>>>> >> >> >> >> >> > say >> >> >>>>> >> >> >> >> >> > when >> >> >>>>> >> >> >> >> >> > that >> >> >>>>> >> >> >> >> >> > will >> >> >>>>> >> >> >> >> >> > happen >> >> >>>>> >> >> >> >> >> > but if you can get away with an older CMake for >> >> >>>>> >> >> >> >> >> > now >> >> >>>>> >> >> >> >> >> > then I'd >> >> >>>>> >> >> >> >> >> > go >> >> >>>>> >> >> >> >> >> > this >> >> >>>>> >> >> >> >> >> > way. >> >> >>>>> >> >> >> >> >> > As you mentioned, option (1) will allow you to >> >> >>>>> >> >> >> >> >> > view >> >> >>>>> >> >> >> >> >> > your >> >> >>>>> >> >> >> >> >> > source >> >> >>>>> >> >> >> >> >> > file >> >> >>>>> >> >> >> >> >> > structure in Android Studio, edit files, and >> >> >>>>> >> >> >> >> >> > debug >> >> >>>>> >> >> >> >> >> > using the >> >> >>>>> >> >> >> >> >> > built-in >> >> >>>>> >> >> >> >> >> > debugging support. >> >> >>>>> >> >> >> >> >> > >> >> >>>>> >> >> >> >> >> > To get option (2) to work, you can use jniDirs >> >> >>>>> >> >> >> >> >> > setting >> >> >>>>> >> >> >> >> >> > to >> >> >>>>> >> >> >> >> >> > tell >> >> >>>>> >> >> >> >> >> > Android >> >> >>>>> >> >> >> >> >> > Gradle where to pick up your built .so files >> >> >>>>> >> >> >> >> >> > (see >> >> >>>>> >> >> >> >> >> > >> >> >>>>> >> >> >> >> >> > >> >> >>>>> >> >> >> >> >> > >> >> >>>>> >> >> >> >> >> > >> >> >>>>> >> >> >> >> >> > >> >> >>>>> >> >> >> >> >> > >> >> >>>>> >> >> >> >> >> > >> >> >>>>> >> >> >> >> >> > >> >> >>>>> >> >> >> >> >> > https://stackoverflow.com/questions/21255125/how-can-i-add-so-files-to-an-android-library-project-using-gradle-0-7). >> >> >>>>> >> >> >> >> >> > I'm not aware of any projects that use this >> >> >>>>> >> >> >> >> >> > approach >> >> >>>>> >> >> >> >> >> > but it >> >> >>>>> >> >> >> >> >> > should >> >> >>>>> >> >> >> >> >> > work >> >> >>>>> >> >> >> >> >> > in >> >> >>>>> >> >> >> >> >> > principal. >> >> >>>>> >> >> >> >> >> > >> >> >>>>> >> >> >> >> >> > I hope this helps, >> >> >>>>> >> >> >> >> >> > Jomo >> >> >>>>> >> >> >> >> >> > >> >> >>>>> >> >> >> >> >> > >> >> >>>>> >> >> >> >> >> > On Mon, Aug 7, 2017 at 11:09 AM, Robert Dailey >> >> >>>>> >> >> >> >> >> > >> >> >>>>> >> >> >> >> >> > wrote: >> >> >>>>> >> >> >> >> >> >> >> >> >>>>> >> >> >> >> >> >> Right now I have custom targets set to execute >> >> >>>>> >> >> >> >> >> >> the >> >> >>>>> >> >> >> >> >> >> "ant >> >> >>>>> >> >> >> >> >> >> release" >> >> >>>>> >> >> >> >> >> >> command after my native targets are built. Part >> >> >>>>> >> >> >> >> >> >> of >> >> >>>>> >> >> >> >> >> >> that >> >> >>>>> >> >> >> >> >> >> command >> >> >>>>> >> >> >> >> >> >> involves copying *.so files to the >> >> >>>>> >> >> >> >> >> >> libs/armeabi-v7a >> >> >>>>> >> >> >> >> >> >> directory >> >> >>>>> >> >> >> >> >> >> so >> >> >>>>> >> >> >> >> >> >> they >> >> >>>>> >> >> >> >> >> >> get packaged in an APK. >> >> >>>>> >> >> >> >> >> >> >> >> >>>>> >> >> >> >> >> >> When switching to gradle, I have two options: >> >> >>>>> >> >> >> >> >> >> >> >> >>>>> >> >> >> >> >> >> 1. Gradle drives CMake: This means using >> >> >>>>> >> >> >> >> >> >> Android >> >> >>>>> >> >> >> >> >> >> Studio and >> >> >>>>> >> >> >> >> >> >> being >> >> >>>>> >> >> >> >> >> >> locked down to Google's fork of CMake which is >> >> >>>>> >> >> >> >> >> >> a >> >> >>>>> >> >> >> >> >> >> few >> >> >>>>> >> >> >> >> >> >> major >> >> >>>>> >> >> >> >> >> >> releases >> >> >>>>> >> >> >> >> >> >> behind. I see that as a negative. >> >> >>>>> >> >> >> >> >> >> >> >> >>>>> >> >> >> >> >> >> 2. CMake drives Gradle: This would be the same >> >> >>>>> >> >> >> >> >> >> or >> >> >>>>> >> >> >> >> >> >> similar >> >> >>>>> >> >> >> >> >> >> to >> >> >>>>> >> >> >> >> >> >> what >> >> >>>>> >> >> >> >> >> >> I'm >> >> >>>>> >> >> >> >> >> >> already doing: The custom targets I have would >> >> >>>>> >> >> >> >> >> >> execute >> >> >>>>> >> >> >> >> >> >> gradle >> >> >>>>> >> >> >> >> >> >> as >> >> >>>>> >> >> >> >> >> >> a >> >> >>>>> >> >> >> >> >> >> separate build step, instead of running ant >> >> >>>>> >> >> >> >> >> >> commands. >> >> >>>>> >> >> >> >> >> >> I'm >> >> >>>>> >> >> >> >> >> >> not >> >> >>>>> >> >> >> >> >> >> too >> >> >>>>> >> >> >> >> >> >> familiar with Gradle, so I'm not sure how you >> >> >>>>> >> >> >> >> >> >> tell >> >> >>>>> >> >> >> >> >> >> it >> >> >>>>> >> >> >> >> >> >> where >> >> >>>>> >> >> >> >> >> >> your >> >> >>>>> >> >> >> >> >> >> shared libraries are for the APK packaging >> >> >>>>> >> >> >> >> >> >> steps. >> >> >>>>> >> >> >> >> >> >> >> >> >>>>> >> >> >> >> >> >> Which does everyone recommend? Is anyone using >> >> >>>>> >> >> >> >> >> >> one >> >> >>>>> >> >> >> >> >> >> of >> >> >>>>> >> >> >> >> >> >> these >> >> >>>>> >> >> >> >> >> >> setups >> >> >>>>> >> >> >> >> >> >> successfully? The downside to option 2 is >> >> >>>>> >> >> >> >> >> >> probably >> >> >>>>> >> >> >> >> >> >> no >> >> >>>>> >> >> >> >> >> >> on-device >> >> >>>>> >> >> >> >> >> >> native >> >> >>>>> >> >> >> >> >> >> debugging since Android Studio probably can't >> >> >>>>> >> >> >> >> >> >> handle >> >> >>>>> >> >> >> >> >> >> gradle >> >> >>>>> >> >> >> >> >> >> projects >> >> >>>>> >> >> >> >> >> >> without any external CMake builds set up. >> >> >>>>> >> >> >> >> >> >> >> >> >>>>> >> >> >> >> >> >> Would like some general direction & advice >> >> >>>>> >> >> >> >> >> >> before >> >> >>>>> >> >> >> >> >> >> I >> >> >>>>> >> >> >> >> >> >> move >> >> >>>>> >> >> >> >> >> >> away >> >> >>>>> >> >> >> >> >> >> from >> >> >>>>> >> >> >> >> >> >> ANT. Thanks in advance. >> >> >>>>> >> >> >> >> >> >> -- >> >> >>>>> >> >> >> >> >> >> >> >> >>>>> >> >> >> >> >> >> Powered by www.kitware.com >> >> >>>>> >> >> >> >> >> >> >> >> >>>>> >> >> >> >> >> >> Please keep messages on-topic and check the >> >> >>>>> >> >> >> >> >> >> CMake >> >> >>>>> >> >> >> >> >> >> FAQ >> >> >>>>> >> >> >> >> >> >> at: >> >> >>>>> >> >> >> >> >> >> http://www.cmake.org/Wiki/CMake_FAQ >> >> >>>>> >> >> >> >> >> >> >> >> >>>>> >> >> >> >> >> >> Kitware offers various services to support the >> >> >>>>> >> >> >> >> >> >> CMake >> >> >>>>> >> >> >> >> >> >> community. >> >> >>>>> >> >> >> >> >> >> For >> >> >>>>> >> >> >> >> >> >> more >> >> >>>>> >> >> >> >> >> >> information on each offering, please visit: >> >> >>>>> >> >> >> >> >> >> >> >> >>>>> >> >> >> >> >> >> CMake Support: >> >> >>>>> >> >> >> >> >> >> http://cmake.org/cmake/help/support.html >> >> >>>>> >> >> >> >> >> >> CMake Consulting: >> >> >>>>> >> >> >> >> >> >> http://cmake.org/cmake/help/consulting.html >> >> >>>>> >> >> >> >> >> >> CMake Training Courses: >> >> >>>>> >> >> >> >> >> >> http://cmake.org/cmake/help/training.html >> >> >>>>> >> >> >> >> >> >> >> >> >>>>> >> >> >> >> >> >> Visit other Kitware open-source projects at >> >> >>>>> >> >> >> >> >> >> >> >> >>>>> >> >> >> >> >> >> http://www.kitware.com/opensource/opensource.html >> >> >>>>> >> >> >> >> >> >> >> >> >>>>> >> >> >> >> >> >> Follow this link to subscribe/unsubscribe: >> >> >>>>> >> >> >> >> >> >> >> >> >>>>> >> >> >> >> >> >> http://public.kitware.com/mailman/listinfo/cmake >> >> >>>>> >> >> >> >> >> > >> >> >>>>> >> >> >> >> >> > >> >> >>>>> >> >> >> >> > >> >> >>>>> >> >> >> >> > >> >> >>>>> >> >> >> > >> >> >>>>> >> >> >> > >> >> >>>>> >> >> > >> >> >>>>> >> >> > >> >> >>>>> >> > >> >> >>>>> >> > >> >> >>>>> > >> >> >>>>> > >> >> >>>> >> >> >>>> >> >> >>> >> >> >> >> > >> > > > From bitminer at gmail.com Thu Aug 24 13:26:57 2017 From: bitminer at gmail.com (Brian Davis) Date: Thu, 24 Aug 2017 12:26:57 -0500 Subject: [CMake] Interface Libraries allow include directories but not link directories.. Why? In-Reply-To: References: Message-ID: On Thu, Aug 24, 2017 at 2:46 AM, Jean-Micha?l Celerier < jeanmichael.celerier at gmail.com> wrote: > > Ok got it sorry to hear that certainly because, as soon as I hear >> something that would be useful somehow I end up needing it the next day. >> So sorry for us both. >> >> From what your are saying (and I will take your word for it) the CMake >> has a another problem in not implementing "inherited build properties" >> correctly. That is of course if that is what CMake is after with >> add_library( targ INTERFACE) in the first place. >> >> > I think that there is just no mechanism for "inherited build properties". > From the docs (https://cmake.org/cmake/help/v3.9/manual/cmake-buildsystem. > 7.html#interface-libraries), INTERFACE targets seems to be meant for > header-only libraries. > > The "inheritance" mechanism in CMake is mainly setting variables in a > given folder, but this is imho not flexible enough, and leads to problems > when you want to use your library as a subfolder of another since you don't > have an easy way to overwrite "child" variables from a parent scope unless > the child scope carefully did set(CMAKE_CXX_FLAGS "-my-flags > ${CMAKE_CXX_FLAGS}") every time. > > Yes absolutely the inheritance mech is folder based and is the very problem. This is the very problem with LINK_DIRECTORIES, INCLUDE_DIRECTORIES, and flags I initial had in 2009 and from from the current state of things 8 years later it appears that not much is changed. I have been able to use the interface mech to get around what was my use-case for my "project/config" macros, but from what your saying I will only get so far before the CMake design rope around my ankle staked out at the start line ends in me falling flat on my face. It is refreshing to see there is at least someone else out there that understands this core problem in CMake, wish Kitware did, Boost.Build had/has no such problem. We as humans learn form our mistakes... over and over again... every generation... sadly they are the same mistakes. You state IMHO, but there are no opinions involved on my end... it is simply a FACT that CMake design is flawed. Personally I am way past opinions. It appears that I must begin Honey Badgering ;-) the devs until this is finally fixed or just fix it myself. If you have some CMake code that you now does now work say in a test proj I can test to see what fully does not work then I can add this to my issues when I begin the feature request / request for sanity. Also I will likely post another inherited build props specific post so that these problems and be discussed specifically and can be refereed to by devs for the why. I don't know if you have a current macro end-around solution, but if you want I could post my project/config macros on git hub. You would likely have to mod those to get add_project_configuration to accept all your build props to be inherited. Ideally I long for a core solution in CMake and thought / hoped I had it with interface. Thanks for crushing my hopes and dreams :-). At one time I did have a compiler_config in my code so your needs for CXX Flags may just work with below (it's commented out in my current proj, but the place holder is still there) add_project_configuration( compiler_config # CXX_FLAGS_INIT # "/DWIN32 /D_WINDOWS /W3 /Zm1000 /EHsc /GR " # CXX_FLAGS_DEBUG # "/D_DEBUG ${THREAD_DEBUG_OPT} /Zi /Ob0 /Od /Gm " # CXX_FLAGS_DEBUG_INIT # "/D_DEBUG ${THREAD_DEBUG_OPT} /Zi /Ob0 /Od " # # C_FLAGS_DEBUG # "/D_DEBUG /MDd /Zi /Ob0 /Od " # C_FLAGS_DEBUG_INIT # "/D_DEBUG /MDd /Zi /Ob0 /Od " # # CXX_FLAGS_MINSIZEREL_INIT # "/MD /O1 /Ob1 /D NDEBUG" # CXX_FLAGS_RELEASE_INIT # "/MD /O2 /Ob2 /D NDEBUG" # CXX_FLAGS_RELWITHDEBINFO_INIT # "/MD /Zi /O2 /Ob1 /D NDEBUG" # # C_FLAGS_INIT # "/DWIN32 /D_WINDOWS /W3 /Zm1000" # C_FLAGS_MINSIZEREL_INIT # "/MD /O1 /Ob1 /D NDEBUG" # C_FLAGS_RELEASE_INIT # "/MD /O2 /Ob2 /D NDEBUG" # C_FLAGS_RELWITHDEBINFO_INIT # "/MD /Zi /O2 /Ob1 /D NDEBUG" # # the following line should break the build when it is working!! Right now it is not as all FLAGS are not working. # C_STANDARD_LIBRARIES_INIT # "kernel32.lib user32.lib gdi32.lib winspool.lib shell32.lib ole32.lib oleaut32.lib uuid.lib comdlg32.lib advapi32.lib mylib.lib" # COMPILE_FLAGS /DGOOP_123 LINKER_LANGUAGE CXX ) Then the config props can be inherited as: add_project_library( GP_Loader INHERIT_CONFIGURATIONS compiler_config mex_config utility_config boost_config CPP_SOURCES GP_Loader.cpp ${GP_LINK} INSTALL_DIRECTORIES # ${CMAKE_CURRENT_SOURCE_DIR} bin ${TOP}/source/Matlab/lib LIB_SUFFIX ${MEX_LIB_EXT} ) Certainly much less verbose that vanilla CMake goop. If interested let me know, but like I said may require some work to get them to do what you need as I only exposed enough CMake to get what I needed and do not handle every CMake command. I refer to it as Super Awesome Projects (SAP), but like anything created in a vacuum I am certain once the seal it cracked and exposed to the community it sucks to some degree or another. I just could not come up with a working acronym for SUCKER ;-) Why oh why cruel world is this the state of things? Sigh -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcdailey.lists at gmail.com Thu Aug 24 14:36:45 2017 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Thu, 24 Aug 2017 13:36:45 -0500 Subject: [CMake] Best practice for modifying search path for find_package() Message-ID: So I have a "super build" CMake script that runs a series of ExternalProject_Add() functions to execute builds of various third party libraries and install them to a path relative to the parent project's CMAKE_BINARY_DIR. Once the parent project generation occurs, it is expected to do a series of find_package() commands to locate the packages installed by the previous super build. What is the best way to intercept the find_package() search paths to prioritize searching to the custom relative root directory managed by the super build? Based on the documentation for find_package()[1], seems like CMAKE_PREFIX_PATH might be the best way (set it as a normal variable, not a cache variable) inside the CMake scripts prior to the find_package() invocations (which are done indirectly by other CMake scripts I do not manage and cannot change). Although, the usage intent for CMAKE_PREFIX_PATH seems to be documented differently than how I plan to use it. Any advice? [1]: https://cmake.org/cmake/help/v3.6/command/find_package.html From bitminer at gmail.com Thu Aug 24 18:17:08 2017 From: bitminer at gmail.com (Brian Davis) Date: Thu, 24 Aug 2017 17:17:08 -0500 Subject: [CMake] Inherited Build Properties: Is this the intent of add_library Interface Libraries? Message-ID: Is the goal of add_library interface libraries to add the concept of inherited build properties not dependent on the directory project inheritance structure of CMake? This is to say attach any and all cmake properties, flags, etc to a "dummy" target that can then be used by other target to "inherit" the build config of the "dummy" target. Can it be used to get around the inherent folder inheritance mechanism in CMake? Does it support all properties, flags, defs? Say for example: from: https://cmake.org/pipermail/cmake/2017-August/066122.html add_library(blah INTERFACE) set_property(TARGET blah PROPERTY SUFFIX ".mxe") set_property(TARGET blah PROPERTY CXX_STANDARD 14) set_property(TARGET blah PROPERTY INSTALL_RPATH "@loader_path/whatever") without: CMake Error at CMakeLists.txt:4 (set_property): INTERFACE_LIBRARY targets may only have whitelisted properties. The property "SUFFIX" is not allowed. oh... I know my bad... lets try set_target_properties: set_target_properties( blah PROPERTIES SUFFIX ".mxe" CXX_STANDARD 14 INSTALL_RPATH "@loader_path/whatever" ) without say: CMake Error at CMakeLists.txt:20 (set_target_properties): INTERFACE_LIBRARY targets may only have whitelisted properties. The property "SUFFIX" is not allowed. CMake Error at CMakeLists.txt:20 (set_target_properties): INTERFACE_LIBRARY targets may only have whitelisted properties. The property "CXX_STANDARD" is not allowed. CMake Error at CMakeLists.txt:20 (set_target_properties): INTERFACE_LIBRARY targets may only have whitelisted properties. The property "INSTALL_RPATH" is not allowed. One might want to say create a template (add_project Interface Library) for all MATLAB mex libraries where say SUFFIX is .mex (above is example from others) but I would like same functionality for MATLAB Mex plugins then have plugin target inherit build props via say: add_library( mex_interface INTERFACE ) set_target_properties( mex_interface PROPERTIES SUFFIX ".mex64" LINK_FLAGS /export:mex_function ) target_link_libraries( targ mex_interface). But what do I get: CMake Error at CMakeLists.txt:31 (set_target_properties): INTERFACE_LIBRARY targets may only have whitelisted properties. The property "SUFFIX" is not allowed. CMake Error at CMakeLists.txt:31 (set_target_properties): INTERFACE_LIBRARY targets may only have whitelisted properties. The property "LINK_FLAGS" is not allowed. Hmmm I know lets look up whitelisted in CMake doc surely that will tell me something about INTERFACE whitlisted properties. https://cmake.org/cmake/help/latest/search.html?q=whitelisted&check_keywords=yes&area=default Yep... bubkis as expected... in true CMake style. Since I have the CMake 3.9 source checkout as it is the only way these days to figure out what CMake does/does not.. I search that for whitelist and I'll certainly report back on how that goes. In reading: https://cmake.org/cmake/help/latest/command/add_library.html?highlight=interface "An INTERFACE library target does not directly create build output, though it may have properties set on it and it may be installed, exported and imported. Typically the INTERFACE_* properties are populated on the interface target using the commands:" correction: "it may have WHITELISTED properties that we are not going to document what they are cuz it's like super secret ... good luck!, but if you can figure out what they are by trial and error and using eclipse ide search on the checked out source tree and set on it and it may be installed, exported and imported." Huh a library that is just a interface which is not actually a library and is not a build output... could a worse term "library" been used. how about add_interface or add_config or some such not library which I can understand as an easy hack as libs are consumable by both exe's and libs, but really... library? Are command name additions at a premium in CMake? So I'll ask again what is the intent of add_project interface libraries? I am getting a pretty good idea what it's not... well i guess better idea what it isn't once find that whitelist. -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.tmatma at gmail.com Fri Aug 25 09:04:40 2017 From: m.tmatma at gmail.com (Masaru Tsuchiyama) Date: Fri, 25 Aug 2017 22:04:40 +0900 Subject: [CMake] 'cmake.exe -G Ninja' doesn't work for VS2017 with cmake ver 3.9.1 In-Reply-To: <8cfd41b8-594f-cad2-eff2-1391d117ff0f@kitware.com> References: <84ce2ae4-99d2-c3d4-8bb0-82131019aa76@gmail.com> <6ddc295f-8cda-2f64-e6c2-3e33ec529e94@gmail.com> <8cfd41b8-594f-cad2-eff2-1391d117ff0f@kitware.com> Message-ID: <88f2ee77-6d9a-4e28-bc86-e95dd68e7cdc@gmail.com> Hello I confirmed this is fixed. I used 9538d22d955a0b101548019003f2d5c7ba833d77 for the check. Brad King wrote: > On 08/23/2017 05:07 AM, masaru tsuchiyama wrote: >> It seems your coworker can reproduce it and you can use the PC tomorrow. >> So I don't need to debug it, right? > > Correct, thanks. See issue for further updates. > > -Brad > -- Masaru Tsuchiyama From noloader at gmail.com Fri Aug 25 10:06:59 2017 From: noloader at gmail.com (Jeffrey Walton) Date: Fri, 25 Aug 2017 10:06:59 -0400 Subject: [CMake] Please update the documentation for execute_process Message-ID: The documentation for execute_process has some room for improvement. We recently got burned by a problem that has existed since at least 2011: https://stackoverflow.com/q/6797395/608639 . Once we learned the problem we could research a bit. The problem cost us over 8 man hours when it should not have been a problem in the first place. Considering there's nothing special about us, it has probably wasted thousands of man hours over the years. Here are the actionable items for the execute_process documentation task: * please clearly state the first argument is the command only, and not command + arguments * please clearly state whether arguments need to be quoted * please clearly state whether arguments need to be comma separated * please provide an example (or examples) to show how to specify multiple arguments for a command * please provide an example (or examples) to show how to redirect output when using a command Below is a typical case for us (https://github.com/weidai11/cryptopp/blob/master/CMakeLists.txt). If it looks pretty shitty, it probably is. That's the best we have been able to come up with based on the documentation. ********** From noloader at gmail.com Fri Aug 25 10:12:25 2017 From: noloader at gmail.com (Jeffrey Walton) Date: Fri, 25 Aug 2017 10:12:25 -0400 Subject: [CMake] Please update the documentation for execute_process In-Reply-To: References: Message-ID: > Below is a typical case for us > (https://github.com/weidai11/cryptopp/blob/master/CMakeLists.txt). If > it looks pretty shitty, it probably is. That's the best we have been > able to come up with based on the documentation. Below is the example code. We don't know whether it should be: set(SHELL_CMD sh) set(SHELL_ARGS -c) set(GREP_CMD egrep) set(GREP_ARGS -i -c) execute_process(COMMAND ${SHELL_CMD} ${SHELL_ARGS} "${CMAKE_CXX_COMPILER} -dumpmachine 2>&1" COMMAND ${GREP_CMD} ${GREP_ARGS} "amd64" OUTPUT_VARIABLE CRYPTOPP_AMD64 OUTPUT_STRIP_TRAILING_WHITESPACE) Or: COMMAND "${SHELL_CMD}", "${CMAKE_CXX_COMPILER}", "-dumpmachine", "2>&1" Or: COMMAND "${SHELL_CMD}" "${CMAKE_CXX_COMPILER}" "-dumpmachine" "2>&1" Or: set(SHELL_CMD sh) set(GREP_CMD egrep) execute_process(COMMAND ${SHELL_CMD} "-c" "${CMAKE_CXX_COMPILER} "-dumpmachine" "2>&1" COMMAND ${GREP_CMD} ${GREP_ARGS} "-i" "-c" "amd64" OUTPUT_VARIABLE CRYPTOPP_AMD64 OUTPUT_STRIP_TRAILING_WHITESPACE) And we certainly don't know what to do with "2>&1" because there is no example. Jeff ********** set(SHELL_CMD sh -c) set(GREP_CMD egrep -i -c) execute_process(COMMAND ${SHELL_CMD} "${CMAKE_CXX_COMPILER} -dumpmachine 2>&1" COMMAND ${GREP_CMD} "amd64" OUTPUT_VARIABLE CRYPTOPP_AMD64 OUTPUT_STRIP_TRAILING_WHITESPACE) execute_process(COMMAND ${SHELL_CMD} "${CMAKE_CXX_COMPILER} -dumpmachine 2>&1" COMMAND ${GREP_CMD} "x86_64" OUTPUT_VARIABLE CRYPTOPP_X86_64 OUTPUT_STRIP_TRAILING_WHITESPACE) execute_process(COMMAND ${SHELL_CMD} "${CMAKE_CXX_COMPILER} -dumpmachine 2>&1" COMMAND ${GREP_CMD} "i.86" OUTPUT_VARIABLE CRYPTOPP_I386 OUTPUT_STRIP_TRAILING_WHITESPACE) # http://github.com/weidai11/cryptopp/issues/466 execute_process(COMMAND ${SHELL_CMD} "${CMAKE_CXX_COMPILER} -dumpmachine 2>&1" COMMAND ${GREP_CMD} "mingw32" OUTPUT_VARIABLE CRYPTOPP_MINGW32 OUTPUT_STRIP_TRAILING_WHITESPACE) # http://github.com/weidai11/cryptopp/issues/466 execute_process(COMMAND ${SHELL_CMD} "${CMAKE_CXX_COMPILER} -dumpmachine 2>&1" COMMAND ${GREP_CMD} "w64-mingw32" OUTPUT_VARIABLE CRYPTOPP_MINGW64 OUTPUT_STRIP_TRAILING_WHITESPACE) execute_process(COMMAND ${SHELL_CMD} "${CMAKE_CXX_COMPILER} -dumpmachine 2>&1" COMMAND ${GREP_CMD} "x32" OUTPUT_VARIABLE CRYPTOPP_X32 OUTPUT_STRIP_TRAILING_WHITESPACE) execute_process(COMMAND ${SHELL_CMD} "${CMAKE_CXX_COMPILER} -dumpmachine 2>&1" COMMAND ${GREP_CMD} "Aarch32" OUTPUT_VARIABLE CRYPTOPP_AARCH32 OUTPUT_STRIP_TRAILING_WHITESPACE) execute_process(COMMAND ${SHELL_CMD} "${CMAKE_CXX_COMPILER} -dumpmachine 2>&1" COMMAND ${GREP_CMD} "Aarch64" OUTPUT_VARIABLE CRYPTOPP_AARCH64 OUTPUT_STRIP_TRAILING_WHITESPACE) # http://stackoverflow.com/q/12515462/608639 execute_process(COMMAND ${SHELL_CMD} "${CMAKE_CXX_COMPILER} -dumpmachine 2>&1" COMMAND ${GREP_CMD} "\\" OUTPUT_VARIABLE CRYPTOPP_ARM OUTPUT_STRIP_TRAILING_WHITESPACE) execute_process(COMMAND ${SHELL_CMD} "${CMAKE_CXX_COMPILER} -dumpmachine 2>&1" COMMAND ${GREP_CMD} "ARMHF" OUTPUT_VARIABLE CRYPTOPP_ARMHF OUTPUT_STRIP_TRAILING_WHITESPACE) execute_process(COMMAND ${SHELL_CMD} "${CMAKE_CXX_COMPILER} -dumpmachine 2>&1" COMMAND ${GREP_CMD} "ARM7L" OUTPUT_VARIABLE CRYPTOPP_ARM7L OUTPUT_STRIP_TRAILING_WHITESPACE) # Fixup? if ("${CRYPTOPP_MINGW64}" STREQUAL "1") unset(CRYPTOPP_MINGW32) endif() # MinGW32 if ("${CRYPTOPP_MINGW32}" STREQUAL "1") set(CRYPTOPP_I386 "1") endif() # OpenBSD and MinGW64 if ("${CRYPTOPP_X86_64}" STREQUAL "1" OR "${CRYPTOPP_MINGW64}" STREQUAL "1") set(CRYPTOPP_AMD64 "1") endif() # arm7l is another 32-bit hard float machine. RPI-3 is arm7l on 64-bit hardware if ("${CRYPTOPP_ARM}" STREQUAL "1" OR "${CRYPTOPP_ARM7L}" STREQUAL "1") set(CRYPTOPP_ARMHF "1") endif() From Andreas-Naumann at gmx.net Fri Aug 25 11:47:25 2017 From: Andreas-Naumann at gmx.net (Andreas Naumann) Date: Fri, 25 Aug 2017 17:47:25 +0200 Subject: [CMake] Please update the documentation for execute_process In-Reply-To: References: Message-ID: <0137770f-36ce-044e-6e56-8fc6a51ce062@gmx.net> Am 25.08.2017 um 16:12 schrieb Jeffrey Walton: >> Below is a typical case for us >> (https://github.com/weidai11/cryptopp/blob/master/CMakeLists.txt). If >> it looks pretty shitty, it probably is. That's the best we have been >> able to come up with based on the documentation. > Below is the example code. We don't know whether it should be: > > set(SHELL_CMD sh) > set(SHELL_ARGS -c) > set(GREP_CMD egrep) > set(GREP_ARGS -i -c) > > execute_process(COMMAND ${SHELL_CMD} ${SHELL_ARGS} > "${CMAKE_CXX_COMPILER} -dumpmachine 2>&1" > COMMAND ${GREP_CMD} ${GREP_ARGS} "amd64" > OUTPUT_VARIABLE CRYPTOPP_AMD64 > OUTPUT_STRIP_TRAILING_WHITESPACE) > > Or: > > COMMAND "${SHELL_CMD}", "${CMAKE_CXX_COMPILER}", "-dumpmachine", "2>&1" > > Or: > > COMMAND "${SHELL_CMD}" "${CMAKE_CXX_COMPILER}" "-dumpmachine" "2>&1" > > Or: > > set(SHELL_CMD sh) > set(GREP_CMD egrep) > > execute_process(COMMAND ${SHELL_CMD} "-c" "${CMAKE_CXX_COMPILER} > "-dumpmachine" "2>&1" > COMMAND ${GREP_CMD} ${GREP_ARGS} "-i" "-c" "amd64" > OUTPUT_VARIABLE CRYPTOPP_AMD64 > OUTPUT_STRIP_TRAILING_WHITESPACE) > > And we certainly don't know what to do with "2>&1" because there is no example. The documentation states "If OUTPUT_VARIABLE or ERROR_VARIABLE are given the variable named will be set with the contents of the standard output and standard error pipes respectively. If the same variable is named for both pipes their output will be merged in the order produced so I would suspect to use something like execute_process(COMMAND "${CMAKE_CXX_COMPILER}" "-dumpmachine" OUTPUT_VARIABLE output_dump ERROR_VARIABLE output_dump) and then use a if( output_dump MATCHES "amd64" ) .. endif() block Does that work? > > Jeff > > ********** > > set(SHELL_CMD sh -c) > set(GREP_CMD egrep -i -c) > > execute_process(COMMAND ${SHELL_CMD} "${CMAKE_CXX_COMPILER} -dumpmachine 2>&1" > COMMAND ${GREP_CMD} "amd64" > OUTPUT_VARIABLE CRYPTOPP_AMD64 > OUTPUT_STRIP_TRAILING_WHITESPACE) > > execute_process(COMMAND ${SHELL_CMD} "${CMAKE_CXX_COMPILER} -dumpmachine 2>&1" > COMMAND ${GREP_CMD} "x86_64" > OUTPUT_VARIABLE CRYPTOPP_X86_64 > OUTPUT_STRIP_TRAILING_WHITESPACE) > > execute_process(COMMAND ${SHELL_CMD} "${CMAKE_CXX_COMPILER} -dumpmachine 2>&1" > COMMAND ${GREP_CMD} "i.86" > OUTPUT_VARIABLE CRYPTOPP_I386 > OUTPUT_STRIP_TRAILING_WHITESPACE) > > # http://github.com/weidai11/cryptopp/issues/466 > execute_process(COMMAND ${SHELL_CMD} "${CMAKE_CXX_COMPILER} -dumpmachine 2>&1" > COMMAND ${GREP_CMD} "mingw32" > OUTPUT_VARIABLE CRYPTOPP_MINGW32 > OUTPUT_STRIP_TRAILING_WHITESPACE) > > # http://github.com/weidai11/cryptopp/issues/466 > execute_process(COMMAND ${SHELL_CMD} "${CMAKE_CXX_COMPILER} -dumpmachine 2>&1" > COMMAND ${GREP_CMD} "w64-mingw32" > OUTPUT_VARIABLE CRYPTOPP_MINGW64 > OUTPUT_STRIP_TRAILING_WHITESPACE) > > execute_process(COMMAND ${SHELL_CMD} "${CMAKE_CXX_COMPILER} -dumpmachine 2>&1" > COMMAND ${GREP_CMD} "x32" > OUTPUT_VARIABLE CRYPTOPP_X32 > OUTPUT_STRIP_TRAILING_WHITESPACE) > > execute_process(COMMAND ${SHELL_CMD} "${CMAKE_CXX_COMPILER} -dumpmachine 2>&1" > COMMAND ${GREP_CMD} "Aarch32" > OUTPUT_VARIABLE CRYPTOPP_AARCH32 > OUTPUT_STRIP_TRAILING_WHITESPACE) > > execute_process(COMMAND ${SHELL_CMD} "${CMAKE_CXX_COMPILER} -dumpmachine 2>&1" > COMMAND ${GREP_CMD} "Aarch64" > OUTPUT_VARIABLE CRYPTOPP_AARCH64 > OUTPUT_STRIP_TRAILING_WHITESPACE) > > # http://stackoverflow.com/q/12515462/608639 > execute_process(COMMAND ${SHELL_CMD} "${CMAKE_CXX_COMPILER} -dumpmachine 2>&1" > COMMAND ${GREP_CMD} "\\" > OUTPUT_VARIABLE CRYPTOPP_ARM > OUTPUT_STRIP_TRAILING_WHITESPACE) > > execute_process(COMMAND ${SHELL_CMD} "${CMAKE_CXX_COMPILER} -dumpmachine 2>&1" > COMMAND ${GREP_CMD} "ARMHF" > OUTPUT_VARIABLE CRYPTOPP_ARMHF > OUTPUT_STRIP_TRAILING_WHITESPACE) > > execute_process(COMMAND ${SHELL_CMD} "${CMAKE_CXX_COMPILER} -dumpmachine 2>&1" > COMMAND ${GREP_CMD} "ARM7L" > OUTPUT_VARIABLE CRYPTOPP_ARM7L > OUTPUT_STRIP_TRAILING_WHITESPACE) > > # Fixup? > if ("${CRYPTOPP_MINGW64}" STREQUAL "1") > unset(CRYPTOPP_MINGW32) > endif() > > # MinGW32 > if ("${CRYPTOPP_MINGW32}" STREQUAL "1") > set(CRYPTOPP_I386 "1") > endif() > # OpenBSD and MinGW64 > if ("${CRYPTOPP_X86_64}" STREQUAL "1" OR "${CRYPTOPP_MINGW64}" STREQUAL "1") > set(CRYPTOPP_AMD64 "1") > endif() > # arm7l is another 32-bit hard float machine. RPI-3 is arm7l on 64-bit hardware > if ("${CRYPTOPP_ARM}" STREQUAL "1" OR "${CRYPTOPP_ARM7L}" STREQUAL "1") > set(CRYPTOPP_ARMHF "1") > endif() From rcdailey.lists at gmail.com Fri Aug 25 12:21:50 2017 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Fri, 25 Aug 2017 11:21:50 -0500 Subject: [CMake] Should configuration package files define module package variables? Message-ID: So I've been studying the find_package[1] and "creating packages"[2] documentation, as well as the CMakePackageConfigHelpers[3] page. Based on the current offerings of configuration packages, I do not understand the need for the relocatable config.cmake file when all it really contains is: include(${CMAKE_CURRENT_LIST_DIR}/foo-config.cmake) However, what I'm wondering is even though the import targets should contain all information about include directories, libraries, etc, should I still define the typical Foo_INCLUDE_DIRS, Foo_LIBRARIES variables? Example of what foo-config.cmake would be like: include(${CMAKE_CURRENT_LIST_DIR}/foo-config.cmake) set( Foo_INCLUDE_DIRS "... path here...." ) set( Foo_LIBRARIES "List of libraries here..." ) Is this necessary? Honestly the learning curve for creating packages for find_package is very steep. I did not see any general advice on this kind of stuff. It seems like Module packages are being deprecated in favor of Config packages, because it puts the responsibility of maintaining find package logic on the upstream maintainer (config package) instead of on CMake (module packages it ships with). Thanks in advance for any help. From rcdailey.lists at gmail.com Fri Aug 25 12:22:52 2017 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Fri, 25 Aug 2017 11:22:52 -0500 Subject: [CMake] Should configuration package files define module package variables? In-Reply-To: References: Message-ID: Doh, forgot the links I intended to reference in my original email: [1]: https://cmake.org/cmake/help/v3.6/command/find_package.html [2]: https://cmake.org/cmake/help/v3.6/manual/cmake-packages.7.html#creating-packages [3]: https://cmake.org/cmake/help/v3.6/module/CMakePackageConfigHelpers.html On Fri, Aug 25, 2017 at 11:21 AM, Robert Dailey wrote: > So I've been studying the find_package[1] and "creating packages"[2] > documentation, as well as the CMakePackageConfigHelpers[3] page. > > Based on the current offerings of configuration packages, I do not > understand the need for the relocatable config.cmake file when all it > really contains is: > > include(${CMAKE_CURRENT_LIST_DIR}/foo-config.cmake) > > However, what I'm wondering is even though the import targets should > contain all information about include directories, libraries, etc, > should I still define the typical Foo_INCLUDE_DIRS, Foo_LIBRARIES > variables? Example of what foo-config.cmake would be like: > > include(${CMAKE_CURRENT_LIST_DIR}/foo-config.cmake) > set( Foo_INCLUDE_DIRS "... path here...." ) > set( Foo_LIBRARIES "List of libraries here..." ) > > > Is this necessary? Honestly the learning curve for creating packages > for find_package is very steep. I did not see any general advice on > this kind of stuff. It seems like Module packages are being deprecated > in favor of Config packages, because it puts the responsibility of > maintaining find package logic on the upstream maintainer (config > package) instead of on CMake (module packages it ships with). > > Thanks in advance for any help. From rcdailey.lists at gmail.com Fri Aug 25 17:42:33 2017 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Fri, 25 Aug 2017 16:42:33 -0500 Subject: [CMake] CMake + Gradle for Android In-Reply-To: References: Message-ID: By the way when I try to use "targets", I get a failure. Basically Gradle doesn't recognize that keyword. I tried singular form as well ("target"), no luck. I'm running canary build of everything possible. What am I missing? On Wed, Aug 23, 2017 at 4:20 PM, Jom O'Fisher wrote: > By gradle module projects, I just mean the leaf build.gradle files as > opposed to the root build.gradle. By configurations, I mean Build Types > (debug vs release) and Product Flavors (demo vs free vs paid). Hereafter I > will use the term "variant" rather than "configuration" to be precise. See > this write-up on build variants: > > https://developer.android.com/studio/build/build-variants.html#build-types > > This build matrix is constructed at the leaf build.gradle level. Native > build in gradle allows you to set C/C++ flags individually for each variant > so that you can define compiler flags (for example, -DFREE_VERSION). > > One thing to notice at this stage is that the same CMake target may be built > with different compiler flags across different projects, build types, and > product flavors. So in the general case, build outputs won't be the same. > > You asked which targets build when specifying path. By default, we build all > targets that produce an .so. You can override this by setting > externalNativeBuild.cmake.targets. For example, > > paid { > ... > externalNativeBuild { > cmake { > ... > targets "native-lib-paid" > } > } > } > > As for your last question, the model we generally see used is that the main > CMakeLists.txt is next to the leaf build.gradle such that this > CMakeLists.txt doesn't couple with peer APK project CMakeLists.txt (though > they may share common dependencies and settings). Otherwise, multiple APK > projects would perform pretty much similar to yours--they would build > targets per-leaf project and not share build outputs. As far as I can see > your organization is just as valid so long as you only build the targets you > need. > > Regarding native dependencies between java projects. We generally try to > avoid making the CMake build depend on the gradle build (you should be able > to replicate the CMake build from the command-line if you set the right > flags). At the moment I don't see a way we could make things better without > violating that tenet but that could be lack of imagination on my part. > > We'll definitely be discussing this use case at our next C++ meeting and > I'll also be checking for myself whether ccache will work in this CMake > scenario. If ccache does work it seems like the natural level at which to > fold identical builds. > > > > On Wed, Aug 23, 2017 at 1:03 PM, Robert Dailey > wrote: >> >> I'm not sure what you mean by "gradle module projects", but maybe >> having some examples of what you mean by "configurations, C++ flags, >> etc" might make it more clear. >> >> Question: When specifying "path" for the CMakeLists.txt in the >> build.gradle file, how do you know which targets to build? For >> example, that run of CMake may generate 100 targets, but only 20 need >> to build and be packaged (*.so files) with the APK. Do you just build >> "all"? Is there a way to specify the target itself? >> >> Thanks again. I'd still like to know more about what the ideal >> organization is. I find it hard to believe that large android projects >> rarely break things up into multiple, separate "components" that are >> built independently. That's really the gist of what we're dealing with >> here. Your typical "hello world" project likely will have only 1 >> CMakeLists.txt that is pretty self-contained, but all the >> documentation I've looked at so far doesn't show the best way to >> handle native library dependencies across java projects between >> build.gradle files (or maybe I'm just not looking hard enough). >> >> On Wed, Aug 23, 2017 at 1:02 PM, Jom O'Fisher >> wrote: >> > Thanks for the write-up Robert. Having thought about it, I don't believe >> > we >> > have a satisfying answer at the gradle level for this kind of >> > organization. >> > In the gradle model module projects are the unit of organization for >> > configurations, C/C++ flags, etc. and that's something we're pretty much >> > stuck with. >> > Regarding just the redundant build issue, would something like ccache >> > help? >> > I know people have used it with ndk-build with success, I'm not sure >> > about >> > CMake but I don't see why that should make a difference. >> > >> > >> > >> > On Tue, Aug 22, 2017 at 10:27 AM, Robert Dailey >> > >> > wrote: >> >> >> >> Another reason to reduce the number of binary directories is that >> >> there are different ways of managing third party libraries. One in >> >> particular that we use is to clone a repository into the binary >> >> directory and build all third party libs in real time based on a >> >> toolchain file (Similar to the functionality provided by >> >> ExternalProject module in CMake). This is repeated from scratch only >> >> if the work hasn't already been done in the binary directory before. >> >> By having more binary dirs than needed, this work is being done an >> >> exponential amount of times which can result in a lot of wasted time >> >> waiting. There are 1 time operations that multiple targets can benefit >> >> from in a single binary tree, instead of 1 per unique target being >> >> invoked. >> >> >> >> Sorry to keep responding: I'm just thinking of things as I go and >> >> bringing them up, to shed light on some of the reasoning behind my >> >> suggestions. >> >> >> >> On Tue, Aug 22, 2017 at 9:26 AM, Robert Dailey >> >> >> >> wrote: >> >> > Sorry I forgot to answer your last set of questions: >> >> > >> >> > CommonLib is indeed 2 things: >> >> > >> >> > * A common (static or shared) library for native code (most of our >> >> > CMake targets specify CommonLib as a link dependency) >> >> > * A common library for Java code (we do specify this as a dependency >> >> > for most java targets in Gradle, specifically those under >> >> > Applications/) >> >> > >> >> > On Mon, Aug 21, 2017 at 6:20 PM, Raymond Chiu >> >> > wrote: >> >> >> Hi Robert, >> >> >> >> >> >> I work with Jom on the Android Studio team, and I would like to >> >> >> clarify >> >> >> a >> >> >> few things to better understand your situation. >> >> >> You mentioned the project is intend to be cross platform. Normally, >> >> >> in >> >> >> such >> >> >> situation, we expect there to be a single CMake root project to be >> >> >> imported >> >> >> into one of the Android library/application. However, in your case, >> >> >> there >> >> >> are subprojects with Java code. >> >> >> >> >> >> Are the CMake code in App1/2/3 intended to be cross platform too? >> >> >> Or >> >> >> are >> >> >> they Android specific code? If they are meant to be cross platform, >> >> >> how >> >> >> does the Java code works on other platforms? Or perhaps you added >> >> >> Java >> >> >> binding in those subprojects just for Android? >> >> >> >> >> >> The build.gradle in CommonLib, what kind of Gradle project is that? >> >> >> From >> >> >> your description, it doesn't look like an Android library project. >> >> >> Or >> >> >> am I >> >> >> mistaken and it also applies the android library plugin? >> >> >> >> >> >> Raymond >> >> >> >> >> >> On Mon, Aug 21, 2017 at 3:34 PM, Jom O'Fisher >> >> >> wrote: >> >> >>> >> >> >>> + a colleague >> >> >>> >> >> >>> On Mon, Aug 21, 2017 at 3:11 PM, Jom O'Fisher >> >> >>> >> >> >>> wrote: >> >> >>>> >> >> >>>> You can find that number like this: >> >> >>>> - x = number of externalNativeBuild.cmake.path in your >> >> >>>> build.gradle >> >> >>>> files >> >> >>>> - y = number of gradle configurations (like debug and release) >> >> >>>> - z = number of ABIs that you build >> >> >>>> >> >> >>>> The result is x * y * z. To be more accurate, you should consider >> >> >>>> y >> >> >>>> and z >> >> >>>> to be functions of each build.gradle file since these can vary. >> >> >>>> >> >> >>>> There is a second set of folders that hold the stripped versions >> >> >>>> of >> >> >>>> the >> >> >>>> .so files that is purely managed by the android gradle plugin, so >> >> >>>> you >> >> >>>> might >> >> >>>> consider the answer to be 2 * x * y * z. >> >> >>>> >> >> >>>> Hope this helps. >> >> >>>> >> >> >>>> >> >> >>>> >> >> >>>> >> >> >>>> >> >> >>>> >> >> >>>> On Mon, Aug 21, 2017 at 2:41 PM, Robert Dailey >> >> >>>> >> >> >>>> wrote: >> >> >>>>> >> >> >>>>> This definitely a bit better, but still requires the boilerplate >> >> >>>>> in >> >> >>>>> each leaf gradle file. But I can't seriously complain too much. I >> >> >>>>> think I'm more concerned with the implications this has >> >> >>>>> underneath. >> >> >>>>> First, let me ask just to make sure I'm not misunderstanding: >> >> >>>>> Does >> >> >>>>> each `externalNativeBuild` entry essentially mean 1 >> >> >>>>> CMAKE_BINARY_DIR? >> >> >>>>> How many binary dirs do you manage internally and what determines >> >> >>>>> when >> >> >>>>> they get created? >> >> >>>>> >> >> >>>>> On Mon, Aug 21, 2017 at 2:35 PM, Jom O'Fisher >> >> >>>>> >> >> >>>>> wrote: >> >> >>>>> > Would it work for your scenario to provide properties in the >> >> >>>>> > root >> >> >>>>> > build.gradle: >> >> >>>>> > >> >> >>>>> > ext { >> >> >>>>> > cmakePath = file "CMakeLists.txt" >> >> >>>>> > } >> >> >>>>> > >> >> >>>>> > And then consume them in the leaf app/build.gradle like this? >> >> >>>>> > >> >> >>>>> > externalNativeBuild { >> >> >>>>> > cmake { >> >> >>>>> > path cmakePath >> >> >>>>> > } >> >> >>>>> > } >> >> >>>>> > >> >> >>>>> > It doesn't fully hide the details but it does centralize the >> >> >>>>> > information. >> >> >>>>> > >> >> >>>>> > >> >> >>>>> > On Mon, Aug 21, 2017 at 11:20 AM, Robert Dailey >> >> >>>>> > >> >> >>>>> > wrote: >> >> >>>>> >> >> >> >>>>> >> I wouldn't want to do that, it's too convoluted. I have other >> >> >>>>> >> platforms that use these CMake scripts as well. For example, I >> >> >>>>> >> run on >> >> >>>>> >> Windows and Linux platforms as well to build the native code. >> >> >>>>> >> Normal >> >> >>>>> >> CMake behavior is designed to work at a root then go downwards >> >> >>>>> >> to >> >> >>>>> >> find >> >> >>>>> >> targets. However it seems Gradle wants to start at a >> >> >>>>> >> subdirectory >> >> >>>>> >> and >> >> >>>>> >> work its way up to the root, which is opposite of CMake's >> >> >>>>> >> intended >> >> >>>>> >> behavior IMHO. Not only that but I want to avoid >> >> >>>>> >> special-casing >> >> >>>>> >> behavior in CMake just for Android's use. >> >> >>>>> >> >> >> >>>>> >> At the moment it feels like (again referring back to my >> >> >>>>> >> previous >> >> >>>>> >> example structure) that both App2 and App3 each run CMake in >> >> >>>>> >> independent binary directories instead of sharing 1 binary >> >> >>>>> >> directory >> >> >>>>> >> and building 2 targets inside of it. I prefer this behavior >> >> >>>>> >> instead, >> >> >>>>> >> especially since it allows CMake to operate as it was >> >> >>>>> >> intended. I >> >> >>>>> >> think it's a common case that projects will define multiple >> >> >>>>> >> targets >> >> >>>>> >> starting from a single root, and expect multiple APKs or java >> >> >>>>> >> dependencies to be built within it. >> >> >>>>> >> >> >> >>>>> >> If I'm misunderstanding or making false assumptions please let >> >> >>>>> >> me >> >> >>>>> >> know. >> >> >>>>> >> >> >> >>>>> >> >> >> >>>>> >> >> >> >>>>> >> On Mon, Aug 21, 2017 at 12:00 PM, Jom O'Fisher >> >> >>>>> >> >> >> >>>>> >> wrote: >> >> >>>>> >> > Would it work for your situation for the leaf CMakeLists.txt >> >> >>>>> >> > to >> >> >>>>> >> > include >> >> >>>>> >> > the >> >> >>>>> >> > root CMakeLists.txt? Then have the leaf-specific logic in >> >> >>>>> >> > the >> >> >>>>> >> > leaf >> >> >>>>> >> > CMakeLists.txt? >> >> >>>>> >> > >> >> >>>>> >> > >> >> >>>>> >> > >> >> >>>>> >> > On Mon, Aug 21, 2017 at 9:33 AM, Robert Dailey >> >> >>>>> >> > >> >> >>>>> >> > wrote: >> >> >>>>> >> >> >> >> >>>>> >> >> Basically, yes. We have this sort of structure: >> >> >>>>> >> >> >> >> >>>>> >> >> / >> >> >>>>> >> >> Applications/ >> >> >>>>> >> >> App1/ >> >> >>>>> >> >> build.gradle >> >> >>>>> >> >> CMakeLists.txt >> >> >>>>> >> >> App2/ >> >> >>>>> >> >> build.gradle >> >> >>>>> >> >> CMakeLists.txt >> >> >>>>> >> >> App3/ >> >> >>>>> >> >> build.gradle >> >> >>>>> >> >> CMakeLists.txt >> >> >>>>> >> >> CommonLib/ >> >> >>>>> >> >> build.gradle >> >> >>>>> >> >> CMakeLists.txt >> >> >>>>> >> >> CMakeLists.txt >> >> >>>>> >> >> >> >> >>>>> >> >> The libs are defined as follows: >> >> >>>>> >> >> >> >> >>>>> >> >> * CommonLib is a static library (java code builds into a >> >> >>>>> >> >> library) >> >> >>>>> >> >> * No dependencies of its own >> >> >>>>> >> >> * App1 is a shared library (java code builds into a >> >> >>>>> >> >> library) >> >> >>>>> >> >> * Dependencies (both java & native): CommonLib >> >> >>>>> >> >> * App2 is a shared library (java code builds into an APK) >> >> >>>>> >> >> * Dependencies (both java & native): App1, CommonLib >> >> >>>>> >> >> * App3 is a shared library (java code builds into an APK) >> >> >>>>> >> >> * Dependencies (both java & native): CommonLib >> >> >>>>> >> >> >> >> >>>>> >> >> In all cases, CMake must be invoked starting at the root >> >> >>>>> >> >> CMakeLists.txt 1 time. Each target can be built from the >> >> >>>>> >> >> same >> >> >>>>> >> >> binary >> >> >>>>> >> >> directory after that. Previously with ANT, I was building >> >> >>>>> >> >> all >> >> >>>>> >> >> native >> >> >>>>> >> >> targets first, then moved libs to appropriate directories >> >> >>>>> >> >> so >> >> >>>>> >> >> that >> >> >>>>> >> >> the >> >> >>>>> >> >> 'ant' command would package the libs. >> >> >>>>> >> >> >> >> >>>>> >> >> For gradle, I wanted to avoid redundantly specifying the >> >> >>>>> >> >> root >> >> >>>>> >> >> directory in each leaf-level project directory. Using the >> >> >>>>> >> >> example >> >> >>>>> >> >> above, the leaf-level directories in this case would be >> >> >>>>> >> >> App1, >> >> >>>>> >> >> App2, >> >> >>>>> >> >> App3, and CommonLib. However I think we only specify the >> >> >>>>> >> >> native >> >> >>>>> >> >> CMake >> >> >>>>> >> >> stuff for the java targets that actually output an APK >> >> >>>>> >> >> (that >> >> >>>>> >> >> would >> >> >>>>> >> >> be >> >> >>>>> >> >> App2 and App3 only). >> >> >>>>> >> >> >> >> >>>>> >> >> The ultimate goal is to specify stuff that doesn't change >> >> >>>>> >> >> per >> >> >>>>> >> >> independent "module" of ours at the top level so it is >> >> >>>>> >> >> transitive >> >> >>>>> >> >> / >> >> >>>>> >> >> inherited. Then only specify the differences (e.g. the >> >> >>>>> >> >> native >> >> >>>>> >> >> CMake >> >> >>>>> >> >> target to build) in the leaf build gradle files. However >> >> >>>>> >> >> you >> >> >>>>> >> >> indicated >> >> >>>>> >> >> this isn't possible. >> >> >>>>> >> >> >> >> >>>>> >> >> >> >> >>>>> >> >> >> >> >>>>> >> >> On Mon, Aug 21, 2017 at 11:11 AM, Jom O'Fisher >> >> >>>>> >> >> >> >> >>>>> >> >> wrote: >> >> >>>>> >> >> > What you're doing already sounds correct. You can't >> >> >>>>> >> >> > directly >> >> >>>>> >> >> > specify >> >> >>>>> >> >> > CMakeLists.txt from the top-level build.gradle. >> >> >>>>> >> >> > Recommendation >> >> >>>>> >> >> > is >> >> >>>>> >> >> > that >> >> >>>>> >> >> > it >> >> >>>>> >> >> > should be specified from the build.gradle of the module >> >> >>>>> >> >> > of >> >> >>>>> >> >> > the >> >> >>>>> >> >> > APK. >> >> >>>>> >> >> > Is >> >> >>>>> >> >> > the >> >> >>>>> >> >> > issue that you have multiple APK modules that all >> >> >>>>> >> >> > reference >> >> >>>>> >> >> > the >> >> >>>>> >> >> > same >> >> >>>>> >> >> > CMake >> >> >>>>> >> >> > libraries? >> >> >>>>> >> >> > >> >> >>>>> >> >> > On Mon, Aug 21, 2017 at 9:00 AM, Robert Dailey >> >> >>>>> >> >> > >> >> >>>>> >> >> > wrote: >> >> >>>>> >> >> >> >> >> >>>>> >> >> >> Thanks this is very helpful. The other question I have >> >> >>>>> >> >> >> is: >> >> >>>>> >> >> >> Is >> >> >>>>> >> >> >> there >> >> >>>>> >> >> >> a >> >> >>>>> >> >> >> place to centrally specify the root CMakeLists.txt? >> >> >>>>> >> >> >> Basically, >> >> >>>>> >> >> >> I >> >> >>>>> >> >> >> want >> >> >>>>> >> >> >> to specify the CMake root in 1 place, and have targets >> >> >>>>> >> >> >> (defined >> >> >>>>> >> >> >> further down in subdirectories) that require APK >> >> >>>>> >> >> >> packaging >> >> >>>>> >> >> >> to >> >> >>>>> >> >> >> specify >> >> >>>>> >> >> >> only the native target name that should be built & >> >> >>>>> >> >> >> packaged. >> >> >>>>> >> >> >> >> >> >>>>> >> >> >> At the moment we specify the root CMakeLists.txt by >> >> >>>>> >> >> >> walking >> >> >>>>> >> >> >> up >> >> >>>>> >> >> >> the >> >> >>>>> >> >> >> tree, paths like "../../../../CMakeLists.txt". I think >> >> >>>>> >> >> >> this >> >> >>>>> >> >> >> should >> >> >>>>> >> >> >> be >> >> >>>>> >> >> >> put at the top-level build gradle file if possible. Is >> >> >>>>> >> >> >> this >> >> >>>>> >> >> >> doable >> >> >>>>> >> >> >> at >> >> >>>>> >> >> >> the moment? What is the recommended setup? >> >> >>>>> >> >> >> >> >> >>>>> >> >> >> On Mon, Aug 21, 2017 at 9:37 AM, Jom O'Fisher >> >> >>>>> >> >> >> >> >> >>>>> >> >> >> wrote: >> >> >>>>> >> >> >> > Gradle does introspection on the CMake build to find >> >> >>>>> >> >> >> > .so >> >> >>>>> >> >> >> > targets >> >> >>>>> >> >> >> > and >> >> >>>>> >> >> >> > those >> >> >>>>> >> >> >> > get packaged. >> >> >>>>> >> >> >> > There is also a special case for stl/runtime .so files >> >> >>>>> >> >> >> > from >> >> >>>>> >> >> >> > the >> >> >>>>> >> >> >> > NDK. >> >> >>>>> >> >> >> > Any additional .so files need to specified in >> >> >>>>> >> >> >> > build.gradle >> >> >>>>> >> >> >> > using >> >> >>>>> >> >> >> > jniDirs >> >> >>>>> >> >> >> > >> >> >>>>> >> >> >> > On Mon, Aug 21, 2017 at 7:30 AM, Robert Dailey >> >> >>>>> >> >> >> > >> >> >>>>> >> >> >> > wrote: >> >> >>>>> >> >> >> >> >> >> >>>>> >> >> >> >> How exactly does Gradle package *.so files in an APK? >> >> >>>>> >> >> >> >> I >> >> >>>>> >> >> >> >> know >> >> >>>>> >> >> >> >> that >> >> >>>>> >> >> >> >> ANT >> >> >>>>> >> >> >> >> used to do this for any libs under "libs/". Does >> >> >>>>> >> >> >> >> Gradle >> >> >>>>> >> >> >> >> do >> >> >>>>> >> >> >> >> some >> >> >>>>> >> >> >> >> introspection into CMake targets to see if outputs >> >> >>>>> >> >> >> >> are >> >> >>>>> >> >> >> >> *.so, >> >> >>>>> >> >> >> >> and >> >> >>>>> >> >> >> >> copy >> >> >>>>> >> >> >> >> those to some location if needed? What about >> >> >>>>> >> >> >> >> libraries >> >> >>>>> >> >> >> >> like >> >> >>>>> >> >> >> >> libgnustl_shared.so that come with the NDK? I'd like >> >> >>>>> >> >> >> >> to >> >> >>>>> >> >> >> >> know >> >> >>>>> >> >> >> >> if >> >> >>>>> >> >> >> >> any >> >> >>>>> >> >> >> >> manual copy steps are needed in CMake to put outputs >> >> >>>>> >> >> >> >> in >> >> >>>>> >> >> >> >> proper >> >> >>>>> >> >> >> >> locations for the APK build step. I had to do this >> >> >>>>> >> >> >> >> when >> >> >>>>> >> >> >> >> using >> >> >>>>> >> >> >> >> ANT. >> >> >>>>> >> >> >> >> >> >> >>>>> >> >> >> >> On Mon, Aug 7, 2017 at 6:16 PM, Jom O'Fisher >> >> >>>>> >> >> >> >> >> >> >>>>> >> >> >> >> wrote: >> >> >>>>> >> >> >> >> > 1) There is a folder created for each ABI under the >> >> >>>>> >> >> >> >> > project >> >> >>>>> >> >> >> >> > module >> >> >>>>> >> >> >> >> > folder >> >> >>>>> >> >> >> >> > (so unique per module per ABI) >> >> >>>>> >> >> >> >> > 2) Gradle doesn't specify language level though you >> >> >>>>> >> >> >> >> > can >> >> >>>>> >> >> >> >> > choose >> >> >>>>> >> >> >> >> > to >> >> >>>>> >> >> >> >> > specify it >> >> >>>>> >> >> >> >> > yourself from the build.gradle. This doc does a >> >> >>>>> >> >> >> >> > pretty >> >> >>>>> >> >> >> >> > good job >> >> >>>>> >> >> >> >> > of >> >> >>>>> >> >> >> >> > explaining which variables are set by Gradle: >> >> >>>>> >> >> >> >> > >> >> >>>>> >> >> >> >> > >> >> >>>>> >> >> >> >> > >> >> >>>>> >> >> >> >> > https://developer.android.com/ndk/guides/cmake.html#variables. >> >> >>>>> >> >> >> >> > Philosophically, we try to set as little as we can >> >> >>>>> >> >> >> >> > get >> >> >>>>> >> >> >> >> > away >> >> >>>>> >> >> >> >> > with. >> >> >>>>> >> >> >> >> > In >> >> >>>>> >> >> >> >> > particular, the section titled "Understanding the >> >> >>>>> >> >> >> >> > CMake >> >> >>>>> >> >> >> >> > build >> >> >>>>> >> >> >> >> > command" >> >> >>>>> >> >> >> >> > lays >> >> >>>>> >> >> >> >> > out exactly what we set. You can also see the >> >> >>>>> >> >> >> >> > folders >> >> >>>>> >> >> >> >> > we >> >> >>>>> >> >> >> >> > specify >> >> >>>>> >> >> >> >> > (one >> >> >>>>> >> >> >> >> > per >> >> >>>>> >> >> >> >> > module per ABI) >> >> >>>>> >> >> >> >> > 3) Not sure I understand this. >> >> >>>>> >> >> >> >> > >> >> >>>>> >> >> >> >> > The other document worth taking a look at (if you >> >> >>>>> >> >> >> >> > haven't >> >> >>>>> >> >> >> >> > already) >> >> >>>>> >> >> >> >> > is: >> >> >>>>> >> >> >> >> > >> >> >>>>> >> >> >> >> > >> >> >>>>> >> >> >> >> > >> >> >>>>> >> >> >> >> > >> >> >>>>> >> >> >> >> > https://developer.android.com/studio/projects/add-native-code.html >> >> >>>>> >> >> >> >> > >> >> >>>>> >> >> >> >> > >> >> >>>>> >> >> >> >> > On Mon, Aug 7, 2017 at 3:35 PM, Robert Dailey >> >> >>>>> >> >> >> >> > >> >> >>>>> >> >> >> >> > wrote: >> >> >>>>> >> >> >> >> >> >> >> >>>>> >> >> >> >> >> Thanks Jom >> >> >>>>> >> >> >> >> >> >> >> >>>>> >> >> >> >> >> Honestly, I prefer option 1 to work simply because >> >> >>>>> >> >> >> >> >> that's >> >> >>>>> >> >> >> >> >> how >> >> >>>>> >> >> >> >> >> Google's >> >> >>>>> >> >> >> >> >> officially supporting CMake. But it also has >> >> >>>>> >> >> >> >> >> debugging >> >> >>>>> >> >> >> >> >> which >> >> >>>>> >> >> >> >> >> is >> >> >>>>> >> >> >> >> >> the >> >> >>>>> >> >> >> >> >> #1 >> >> >>>>> >> >> >> >> >> reason for me. >> >> >>>>> >> >> >> >> >> >> >> >>>>> >> >> >> >> >> However, I'd like to understand a lot more about >> >> >>>>> >> >> >> >> >> how >> >> >>>>> >> >> >> >> >> the >> >> >>>>> >> >> >> >> >> integration >> >> >>>>> >> >> >> >> >> really happens. For example, I have these >> >> >>>>> >> >> >> >> >> questions: >> >> >>>>> >> >> >> >> >> >> >> >>>>> >> >> >> >> >> 1) How, internally, are CMake build directories >> >> >>>>> >> >> >> >> >> managed? >> >> >>>>> >> >> >> >> >> Do >> >> >>>>> >> >> >> >> >> you >> >> >>>>> >> >> >> >> >> generate 1 per unique android project? What about >> >> >>>>> >> >> >> >> >> for >> >> >>>>> >> >> >> >> >> each >> >> >>>>> >> >> >> >> >> specific >> >> >>>>> >> >> >> >> >> platform (x86, armeabi-v7a, etc)? >> >> >>>>> >> >> >> >> >> 2) Last time I looked into CMake integration, >> >> >>>>> >> >> >> >> >> things >> >> >>>>> >> >> >> >> >> defined >> >> >>>>> >> >> >> >> >> inside >> >> >>>>> >> >> >> >> >> the CMake scripts were ignored because they are >> >> >>>>> >> >> >> >> >> specified >> >> >>>>> >> >> >> >> >> at >> >> >>>>> >> >> >> >> >> the >> >> >>>>> >> >> >> >> >> command line. Namely, all of those settings that >> >> >>>>> >> >> >> >> >> are >> >> >>>>> >> >> >> >> >> driven by >> >> >>>>> >> >> >> >> >> the >> >> >>>>> >> >> >> >> >> Gradle configuration (CXX language level was one >> >> >>>>> >> >> >> >> >> in >> >> >>>>> >> >> >> >> >> particular >> >> >>>>> >> >> >> >> >> I >> >> >>>>> >> >> >> >> >> think; I specify C++14 support via CMake, but I >> >> >>>>> >> >> >> >> >> recall >> >> >>>>> >> >> >> >> >> this >> >> >>>>> >> >> >> >> >> being >> >> >>>>> >> >> >> >> >> overridden from outside)? >> >> >>>>> >> >> >> >> >> 3) How redundant is it to configure individual >> >> >>>>> >> >> >> >> >> libraries >> >> >>>>> >> >> >> >> >> via >> >> >>>>> >> >> >> >> >> the >> >> >>>>> >> >> >> >> >> gradle scripts? In my previous attempts, I wanted >> >> >>>>> >> >> >> >> >> to >> >> >>>>> >> >> >> >> >> define >> >> >>>>> >> >> >> >> >> common >> >> >>>>> >> >> >> >> >> stuff for CMake / native code at the root gradle >> >> >>>>> >> >> >> >> >> or >> >> >>>>> >> >> >> >> >> settings >> >> >>>>> >> >> >> >> >> file, >> >> >>>>> >> >> >> >> >> and >> >> >>>>> >> >> >> >> >> only define the differences in the actual gradle >> >> >>>>> >> >> >> >> >> build >> >> >>>>> >> >> >> >> >> files >> >> >>>>> >> >> >> >> >> for >> >> >>>>> >> >> >> >> >> each >> >> >>>>> >> >> >> >> >> corresponding Java target (like, defining the name >> >> >>>>> >> >> >> >> >> of >> >> >>>>> >> >> >> >> >> the >> >> >>>>> >> >> >> >> >> native >> >> >>>>> >> >> >> >> >> (shared library) target in Gradle, but the command >> >> >>>>> >> >> >> >> >> line >> >> >>>>> >> >> >> >> >> invocation, >> >> >>>>> >> >> >> >> >> -D >> >> >>>>> >> >> >> >> >> CMake settings, etc would all be common and >> >> >>>>> >> >> >> >> >> defined >> >> >>>>> >> >> >> >> >> at >> >> >>>>> >> >> >> >> >> the >> >> >>>>> >> >> >> >> >> root). >> >> >>>>> >> >> >> >> >> >> >> >>>>> >> >> >> >> >> The TLDR is, the closer we can stay to CMake's way >> >> >>>>> >> >> >> >> >> of >> >> >>>>> >> >> >> >> >> doing >> >> >>>>> >> >> >> >> >> things >> >> >>>>> >> >> >> >> >> and >> >> >>>>> >> >> >> >> >> keep CMake-related settings self-contained to the >> >> >>>>> >> >> >> >> >> CMake >> >> >>>>> >> >> >> >> >> scripts >> >> >>>>> >> >> >> >> >> themselves, the better. This also makes >> >> >>>>> >> >> >> >> >> cross-platform >> >> >>>>> >> >> >> >> >> easier >> >> >>>>> >> >> >> >> >> (we >> >> >>>>> >> >> >> >> >> build the native code in Windows, for example, so >> >> >>>>> >> >> >> >> >> having >> >> >>>>> >> >> >> >> >> settings >> >> >>>>> >> >> >> >> >> specified in the gradle files do not carry over to >> >> >>>>> >> >> >> >> >> other >> >> >>>>> >> >> >> >> >> platforms. >> >> >>>>> >> >> >> >> >> Namely, settings that are not platform specific >> >> >>>>> >> >> >> >> >> like >> >> >>>>> >> >> >> >> >> the >> >> >>>>> >> >> >> >> >> C++ >> >> >>>>> >> >> >> >> >> language >> >> >>>>> >> >> >> >> >> level). >> >> >>>>> >> >> >> >> >> >> >> >>>>> >> >> >> >> >> If there's a detailed document / wiki I can read >> >> >>>>> >> >> >> >> >> on >> >> >>>>> >> >> >> >> >> the >> >> >>>>> >> >> >> >> >> intrinsics >> >> >>>>> >> >> >> >> >> of >> >> >>>>> >> >> >> >> >> CMake integration in Gradle / Android Studio, I'd >> >> >>>>> >> >> >> >> >> love to >> >> >>>>> >> >> >> >> >> read >> >> >>>>> >> >> >> >> >> it. >> >> >>>>> >> >> >> >> >> Otherwise, I hope you won't mind if I pick your >> >> >>>>> >> >> >> >> >> brain >> >> >>>>> >> >> >> >> >> as >> >> >>>>> >> >> >> >> >> questions >> >> >>>>> >> >> >> >> >> come up. I think I'm going to try option 1 for now >> >> >>>>> >> >> >> >> >> and >> >> >>>>> >> >> >> >> >> see how >> >> >>>>> >> >> >> >> >> it >> >> >>>>> >> >> >> >> >> goes. It's just black box for me because unlike >> >> >>>>> >> >> >> >> >> option 2, >> >> >>>>> >> >> >> >> >> I >> >> >>>>> >> >> >> >> >> have >> >> >>>>> >> >> >> >> >> very >> >> >>>>> >> >> >> >> >> little control over what happens after building >> >> >>>>> >> >> >> >> >> the >> >> >>>>> >> >> >> >> >> shared >> >> >>>>> >> >> >> >> >> libraries, >> >> >>>>> >> >> >> >> >> and to make up for that I need to really get a >> >> >>>>> >> >> >> >> >> deep >> >> >>>>> >> >> >> >> >> understanding >> >> >>>>> >> >> >> >> >> of >> >> >>>>> >> >> >> >> >> how it works so I can make sure I code my CMake >> >> >>>>> >> >> >> >> >> scripts >> >> >>>>> >> >> >> >> >> properly >> >> >>>>> >> >> >> >> >> for >> >> >>>>> >> >> >> >> >> not only Android, but my other platforms as well >> >> >>>>> >> >> >> >> >> (non-Android >> >> >>>>> >> >> >> >> >> platforms). >> >> >>>>> >> >> >> >> >> >> >> >>>>> >> >> >> >> >> Thanks again. >> >> >>>>> >> >> >> >> >> >> >> >>>>> >> >> >> >> >> On Mon, Aug 7, 2017 at 5:12 PM, Jom O'Fisher >> >> >>>>> >> >> >> >> >> >> >> >>>>> >> >> >> >> >> wrote: >> >> >>>>> >> >> >> >> >> > Either option can work fine. Disclosure: I work >> >> >>>>> >> >> >> >> >> > on >> >> >>>>> >> >> >> >> >> > Android >> >> >>>>> >> >> >> >> >> > Studio >> >> >>>>> >> >> >> >> >> > and >> >> >>>>> >> >> >> >> >> > was >> >> >>>>> >> >> >> >> >> > the one that added CMake support. >> >> >>>>> >> >> >> >> >> > >> >> >>>>> >> >> >> >> >> > Option (1) is the way it's designed to work and >> >> >>>>> >> >> >> >> >> > we're >> >> >>>>> >> >> >> >> >> > working >> >> >>>>> >> >> >> >> >> > toward >> >> >>>>> >> >> >> >> >> > getting >> >> >>>>> >> >> >> >> >> > rid of the need for the CMake fork. I can't >> >> >>>>> >> >> >> >> >> > really >> >> >>>>> >> >> >> >> >> > say >> >> >>>>> >> >> >> >> >> > when >> >> >>>>> >> >> >> >> >> > that >> >> >>>>> >> >> >> >> >> > will >> >> >>>>> >> >> >> >> >> > happen >> >> >>>>> >> >> >> >> >> > but if you can get away with an older CMake for >> >> >>>>> >> >> >> >> >> > now >> >> >>>>> >> >> >> >> >> > then I'd >> >> >>>>> >> >> >> >> >> > go >> >> >>>>> >> >> >> >> >> > this >> >> >>>>> >> >> >> >> >> > way. >> >> >>>>> >> >> >> >> >> > As you mentioned, option (1) will allow you to >> >> >>>>> >> >> >> >> >> > view >> >> >>>>> >> >> >> >> >> > your >> >> >>>>> >> >> >> >> >> > source >> >> >>>>> >> >> >> >> >> > file >> >> >>>>> >> >> >> >> >> > structure in Android Studio, edit files, and >> >> >>>>> >> >> >> >> >> > debug >> >> >>>>> >> >> >> >> >> > using the >> >> >>>>> >> >> >> >> >> > built-in >> >> >>>>> >> >> >> >> >> > debugging support. >> >> >>>>> >> >> >> >> >> > >> >> >>>>> >> >> >> >> >> > To get option (2) to work, you can use jniDirs >> >> >>>>> >> >> >> >> >> > setting >> >> >>>>> >> >> >> >> >> > to >> >> >>>>> >> >> >> >> >> > tell >> >> >>>>> >> >> >> >> >> > Android >> >> >>>>> >> >> >> >> >> > Gradle where to pick up your built .so files >> >> >>>>> >> >> >> >> >> > (see >> >> >>>>> >> >> >> >> >> > >> >> >>>>> >> >> >> >> >> > >> >> >>>>> >> >> >> >> >> > >> >> >>>>> >> >> >> >> >> > >> >> >>>>> >> >> >> >> >> > >> >> >>>>> >> >> >> >> >> > >> >> >>>>> >> >> >> >> >> > >> >> >>>>> >> >> >> >> >> > >> >> >>>>> >> >> >> >> >> > https://stackoverflow.com/questions/21255125/how-can-i-add-so-files-to-an-android-library-project-using-gradle-0-7). >> >> >>>>> >> >> >> >> >> > I'm not aware of any projects that use this >> >> >>>>> >> >> >> >> >> > approach >> >> >>>>> >> >> >> >> >> > but it >> >> >>>>> >> >> >> >> >> > should >> >> >>>>> >> >> >> >> >> > work >> >> >>>>> >> >> >> >> >> > in >> >> >>>>> >> >> >> >> >> > principal. >> >> >>>>> >> >> >> >> >> > >> >> >>>>> >> >> >> >> >> > I hope this helps, >> >> >>>>> >> >> >> >> >> > Jomo >> >> >>>>> >> >> >> >> >> > >> >> >>>>> >> >> >> >> >> > >> >> >>>>> >> >> >> >> >> > On Mon, Aug 7, 2017 at 11:09 AM, Robert Dailey >> >> >>>>> >> >> >> >> >> > >> >> >>>>> >> >> >> >> >> > wrote: >> >> >>>>> >> >> >> >> >> >> >> >> >>>>> >> >> >> >> >> >> Right now I have custom targets set to execute >> >> >>>>> >> >> >> >> >> >> the >> >> >>>>> >> >> >> >> >> >> "ant >> >> >>>>> >> >> >> >> >> >> release" >> >> >>>>> >> >> >> >> >> >> command after my native targets are built. Part >> >> >>>>> >> >> >> >> >> >> of >> >> >>>>> >> >> >> >> >> >> that >> >> >>>>> >> >> >> >> >> >> command >> >> >>>>> >> >> >> >> >> >> involves copying *.so files to the >> >> >>>>> >> >> >> >> >> >> libs/armeabi-v7a >> >> >>>>> >> >> >> >> >> >> directory >> >> >>>>> >> >> >> >> >> >> so >> >> >>>>> >> >> >> >> >> >> they >> >> >>>>> >> >> >> >> >> >> get packaged in an APK. >> >> >>>>> >> >> >> >> >> >> >> >> >>>>> >> >> >> >> >> >> When switching to gradle, I have two options: >> >> >>>>> >> >> >> >> >> >> >> >> >>>>> >> >> >> >> >> >> 1. Gradle drives CMake: This means using >> >> >>>>> >> >> >> >> >> >> Android >> >> >>>>> >> >> >> >> >> >> Studio and >> >> >>>>> >> >> >> >> >> >> being >> >> >>>>> >> >> >> >> >> >> locked down to Google's fork of CMake which is >> >> >>>>> >> >> >> >> >> >> a >> >> >>>>> >> >> >> >> >> >> few >> >> >>>>> >> >> >> >> >> >> major >> >> >>>>> >> >> >> >> >> >> releases >> >> >>>>> >> >> >> >> >> >> behind. I see that as a negative. >> >> >>>>> >> >> >> >> >> >> >> >> >>>>> >> >> >> >> >> >> 2. CMake drives Gradle: This would be the same >> >> >>>>> >> >> >> >> >> >> or >> >> >>>>> >> >> >> >> >> >> similar >> >> >>>>> >> >> >> >> >> >> to >> >> >>>>> >> >> >> >> >> >> what >> >> >>>>> >> >> >> >> >> >> I'm >> >> >>>>> >> >> >> >> >> >> already doing: The custom targets I have would >> >> >>>>> >> >> >> >> >> >> execute >> >> >>>>> >> >> >> >> >> >> gradle >> >> >>>>> >> >> >> >> >> >> as >> >> >>>>> >> >> >> >> >> >> a >> >> >>>>> >> >> >> >> >> >> separate build step, instead of running ant >> >> >>>>> >> >> >> >> >> >> commands. >> >> >>>>> >> >> >> >> >> >> I'm >> >> >>>>> >> >> >> >> >> >> not >> >> >>>>> >> >> >> >> >> >> too >> >> >>>>> >> >> >> >> >> >> familiar with Gradle, so I'm not sure how you >> >> >>>>> >> >> >> >> >> >> tell >> >> >>>>> >> >> >> >> >> >> it >> >> >>>>> >> >> >> >> >> >> where >> >> >>>>> >> >> >> >> >> >> your >> >> >>>>> >> >> >> >> >> >> shared libraries are for the APK packaging >> >> >>>>> >> >> >> >> >> >> steps. >> >> >>>>> >> >> >> >> >> >> >> >> >>>>> >> >> >> >> >> >> Which does everyone recommend? Is anyone using >> >> >>>>> >> >> >> >> >> >> one >> >> >>>>> >> >> >> >> >> >> of >> >> >>>>> >> >> >> >> >> >> these >> >> >>>>> >> >> >> >> >> >> setups >> >> >>>>> >> >> >> >> >> >> successfully? The downside to option 2 is >> >> >>>>> >> >> >> >> >> >> probably >> >> >>>>> >> >> >> >> >> >> no >> >> >>>>> >> >> >> >> >> >> on-device >> >> >>>>> >> >> >> >> >> >> native >> >> >>>>> >> >> >> >> >> >> debugging since Android Studio probably can't >> >> >>>>> >> >> >> >> >> >> handle >> >> >>>>> >> >> >> >> >> >> gradle >> >> >>>>> >> >> >> >> >> >> projects >> >> >>>>> >> >> >> >> >> >> without any external CMake builds set up. >> >> >>>>> >> >> >> >> >> >> >> >> >>>>> >> >> >> >> >> >> Would like some general direction & advice >> >> >>>>> >> >> >> >> >> >> before >> >> >>>>> >> >> >> >> >> >> I >> >> >>>>> >> >> >> >> >> >> move >> >> >>>>> >> >> >> >> >> >> away >> >> >>>>> >> >> >> >> >> >> from >> >> >>>>> >> >> >> >> >> >> ANT. Thanks in advance. >> >> >>>>> >> >> >> >> >> >> -- >> >> >>>>> >> >> >> >> >> >> >> >> >>>>> >> >> >> >> >> >> Powered by www.kitware.com >> >> >>>>> >> >> >> >> >> >> >> >> >>>>> >> >> >> >> >> >> Please keep messages on-topic and check the >> >> >>>>> >> >> >> >> >> >> CMake >> >> >>>>> >> >> >> >> >> >> FAQ >> >> >>>>> >> >> >> >> >> >> at: >> >> >>>>> >> >> >> >> >> >> http://www.cmake.org/Wiki/CMake_FAQ >> >> >>>>> >> >> >> >> >> >> >> >> >>>>> >> >> >> >> >> >> Kitware offers various services to support the >> >> >>>>> >> >> >> >> >> >> CMake >> >> >>>>> >> >> >> >> >> >> community. >> >> >>>>> >> >> >> >> >> >> For >> >> >>>>> >> >> >> >> >> >> more >> >> >>>>> >> >> >> >> >> >> information on each offering, please visit: >> >> >>>>> >> >> >> >> >> >> >> >> >>>>> >> >> >> >> >> >> CMake Support: >> >> >>>>> >> >> >> >> >> >> http://cmake.org/cmake/help/support.html >> >> >>>>> >> >> >> >> >> >> CMake Consulting: >> >> >>>>> >> >> >> >> >> >> http://cmake.org/cmake/help/consulting.html >> >> >>>>> >> >> >> >> >> >> CMake Training Courses: >> >> >>>>> >> >> >> >> >> >> http://cmake.org/cmake/help/training.html >> >> >>>>> >> >> >> >> >> >> >> >> >>>>> >> >> >> >> >> >> Visit other Kitware open-source projects at >> >> >>>>> >> >> >> >> >> >> >> >> >>>>> >> >> >> >> >> >> http://www.kitware.com/opensource/opensource.html >> >> >>>>> >> >> >> >> >> >> >> >> >>>>> >> >> >> >> >> >> Follow this link to subscribe/unsubscribe: >> >> >>>>> >> >> >> >> >> >> >> >> >>>>> >> >> >> >> >> >> http://public.kitware.com/mailman/listinfo/cmake >> >> >>>>> >> >> >> >> >> > >> >> >>>>> >> >> >> >> >> > >> >> >>>>> >> >> >> >> > >> >> >>>>> >> >> >> >> > >> >> >>>>> >> >> >> > >> >> >>>>> >> >> >> > >> >> >>>>> >> >> > >> >> >>>>> >> >> > >> >> >>>>> >> > >> >> >>>>> >> > >> >> >>>>> > >> >> >>>>> > >> >> >>>> >> >> >>>> >> >> >>> >> >> >> >> > >> > > > From jomofisher at gmail.com Fri Aug 25 17:46:40 2017 From: jomofisher at gmail.com (Jom O'Fisher) Date: Fri, 25 Aug 2017 14:46:40 -0700 Subject: [CMake] CMake + Gradle for Android In-Reply-To: References: Message-ID: Targets are specified per-Variation so they need to go under the variation-specific section. Probably something like this: defaultConfig { externalNativeBuild { cmake { targets "library1", "library2" } } } That should work for you. Let me know. On Fri, Aug 25, 2017 at 2:42 PM, Robert Dailey wrote: > By the way when I try to use "targets", I get a failure. Basically > Gradle doesn't recognize that keyword. I tried singular form as well > ("target"), no luck. > > I'm running canary build of everything possible. What am I missing? > > On Wed, Aug 23, 2017 at 4:20 PM, Jom O'Fisher > wrote: > > By gradle module projects, I just mean the leaf build.gradle files as > > opposed to the root build.gradle. By configurations, I mean Build Types > > (debug vs release) and Product Flavors (demo vs free vs paid). Hereafter > I > > will use the term "variant" rather than "configuration" to be precise. > See > > this write-up on build variants: > > > > https://developer.android.com/studio/build/build-variants. > html#build-types > > > > This build matrix is constructed at the leaf build.gradle level. Native > > build in gradle allows you to set C/C++ flags individually for each > variant > > so that you can define compiler flags (for example, -DFREE_VERSION). > > > > One thing to notice at this stage is that the same CMake target may be > built > > with different compiler flags across different projects, build types, and > > product flavors. So in the general case, build outputs won't be the same. > > > > You asked which targets build when specifying path. By default, we build > all > > targets that produce an .so. You can override this by setting > > externalNativeBuild.cmake.targets. For example, > > > > paid { > > ... > > externalNativeBuild { > > cmake { > > ... > > targets "native-lib-paid" > > } > > } > > } > > > > As for your last question, the model we generally see used is that the > main > > CMakeLists.txt is next to the leaf build.gradle such that this > > CMakeLists.txt doesn't couple with peer APK project CMakeLists.txt > (though > > they may share common dependencies and settings). Otherwise, multiple APK > > projects would perform pretty much similar to yours--they would build > > targets per-leaf project and not share build outputs. As far as I can see > > your organization is just as valid so long as you only build the targets > you > > need. > > > > Regarding native dependencies between java projects. We generally try to > > avoid making the CMake build depend on the gradle build (you should be > able > > to replicate the CMake build from the command-line if you set the right > > flags). At the moment I don't see a way we could make things better > without > > violating that tenet but that could be lack of imagination on my part. > > > > We'll definitely be discussing this use case at our next C++ meeting and > > I'll also be checking for myself whether ccache will work in this CMake > > scenario. If ccache does work it seems like the natural level at which to > > fold identical builds. > > > > > > > > On Wed, Aug 23, 2017 at 1:03 PM, Robert Dailey > > > wrote: > >> > >> I'm not sure what you mean by "gradle module projects", but maybe > >> having some examples of what you mean by "configurations, C++ flags, > >> etc" might make it more clear. > >> > >> Question: When specifying "path" for the CMakeLists.txt in the > >> build.gradle file, how do you know which targets to build? For > >> example, that run of CMake may generate 100 targets, but only 20 need > >> to build and be packaged (*.so files) with the APK. Do you just build > >> "all"? Is there a way to specify the target itself? > >> > >> Thanks again. I'd still like to know more about what the ideal > >> organization is. I find it hard to believe that large android projects > >> rarely break things up into multiple, separate "components" that are > >> built independently. That's really the gist of what we're dealing with > >> here. Your typical "hello world" project likely will have only 1 > >> CMakeLists.txt that is pretty self-contained, but all the > >> documentation I've looked at so far doesn't show the best way to > >> handle native library dependencies across java projects between > >> build.gradle files (or maybe I'm just not looking hard enough). > >> > >> On Wed, Aug 23, 2017 at 1:02 PM, Jom O'Fisher > >> wrote: > >> > Thanks for the write-up Robert. Having thought about it, I don't > believe > >> > we > >> > have a satisfying answer at the gradle level for this kind of > >> > organization. > >> > In the gradle model module projects are the unit of organization for > >> > configurations, C/C++ flags, etc. and that's something we're pretty > much > >> > stuck with. > >> > Regarding just the redundant build issue, would something like ccache > >> > help? > >> > I know people have used it with ndk-build with success, I'm not sure > >> > about > >> > CMake but I don't see why that should make a difference. > >> > > >> > > >> > > >> > On Tue, Aug 22, 2017 at 10:27 AM, Robert Dailey > >> > > >> > wrote: > >> >> > >> >> Another reason to reduce the number of binary directories is that > >> >> there are different ways of managing third party libraries. One in > >> >> particular that we use is to clone a repository into the binary > >> >> directory and build all third party libs in real time based on a > >> >> toolchain file (Similar to the functionality provided by > >> >> ExternalProject module in CMake). This is repeated from scratch only > >> >> if the work hasn't already been done in the binary directory before. > >> >> By having more binary dirs than needed, this work is being done an > >> >> exponential amount of times which can result in a lot of wasted time > >> >> waiting. There are 1 time operations that multiple targets can > benefit > >> >> from in a single binary tree, instead of 1 per unique target being > >> >> invoked. > >> >> > >> >> Sorry to keep responding: I'm just thinking of things as I go and > >> >> bringing them up, to shed light on some of the reasoning behind my > >> >> suggestions. > >> >> > >> >> On Tue, Aug 22, 2017 at 9:26 AM, Robert Dailey > >> >> > >> >> wrote: > >> >> > Sorry I forgot to answer your last set of questions: > >> >> > > >> >> > CommonLib is indeed 2 things: > >> >> > > >> >> > * A common (static or shared) library for native code (most of our > >> >> > CMake targets specify CommonLib as a link dependency) > >> >> > * A common library for Java code (we do specify this as a > dependency > >> >> > for most java targets in Gradle, specifically those under > >> >> > Applications/) > >> >> > > >> >> > On Mon, Aug 21, 2017 at 6:20 PM, Raymond Chiu > >> >> > wrote: > >> >> >> Hi Robert, > >> >> >> > >> >> >> I work with Jom on the Android Studio team, and I would like to > >> >> >> clarify > >> >> >> a > >> >> >> few things to better understand your situation. > >> >> >> You mentioned the project is intend to be cross platform. > Normally, > >> >> >> in > >> >> >> such > >> >> >> situation, we expect there to be a single CMake root project to be > >> >> >> imported > >> >> >> into one of the Android library/application. However, in your > case, > >> >> >> there > >> >> >> are subprojects with Java code. > >> >> >> > >> >> >> Are the CMake code in App1/2/3 intended to be cross platform too? > >> >> >> Or > >> >> >> are > >> >> >> they Android specific code? If they are meant to be cross > platform, > >> >> >> how > >> >> >> does the Java code works on other platforms? Or perhaps you added > >> >> >> Java > >> >> >> binding in those subprojects just for Android? > >> >> >> > >> >> >> The build.gradle in CommonLib, what kind of Gradle project is > that? > >> >> >> From > >> >> >> your description, it doesn't look like an Android library project. > >> >> >> Or > >> >> >> am I > >> >> >> mistaken and it also applies the android library plugin? > >> >> >> > >> >> >> Raymond > >> >> >> > >> >> >> On Mon, Aug 21, 2017 at 3:34 PM, Jom O'Fisher < > jomofisher at gmail.com> > >> >> >> wrote: > >> >> >>> > >> >> >>> + a colleague > >> >> >>> > >> >> >>> On Mon, Aug 21, 2017 at 3:11 PM, Jom O'Fisher > >> >> >>> > >> >> >>> wrote: > >> >> >>>> > >> >> >>>> You can find that number like this: > >> >> >>>> - x = number of externalNativeBuild.cmake.path in your > >> >> >>>> build.gradle > >> >> >>>> files > >> >> >>>> - y = number of gradle configurations (like debug and release) > >> >> >>>> - z = number of ABIs that you build > >> >> >>>> > >> >> >>>> The result is x * y * z. To be more accurate, you should > consider > >> >> >>>> y > >> >> >>>> and z > >> >> >>>> to be functions of each build.gradle file since these can vary. > >> >> >>>> > >> >> >>>> There is a second set of folders that hold the stripped versions > >> >> >>>> of > >> >> >>>> the > >> >> >>>> .so files that is purely managed by the android gradle plugin, > so > >> >> >>>> you > >> >> >>>> might > >> >> >>>> consider the answer to be 2 * x * y * z. > >> >> >>>> > >> >> >>>> Hope this helps. > >> >> >>>> > >> >> >>>> > >> >> >>>> > >> >> >>>> > >> >> >>>> > >> >> >>>> > >> >> >>>> On Mon, Aug 21, 2017 at 2:41 PM, Robert Dailey > >> >> >>>> > >> >> >>>> wrote: > >> >> >>>>> > >> >> >>>>> This definitely a bit better, but still requires the > boilerplate > >> >> >>>>> in > >> >> >>>>> each leaf gradle file. But I can't seriously complain too > much. I > >> >> >>>>> think I'm more concerned with the implications this has > >> >> >>>>> underneath. > >> >> >>>>> First, let me ask just to make sure I'm not misunderstanding: > >> >> >>>>> Does > >> >> >>>>> each `externalNativeBuild` entry essentially mean 1 > >> >> >>>>> CMAKE_BINARY_DIR? > >> >> >>>>> How many binary dirs do you manage internally and what > determines > >> >> >>>>> when > >> >> >>>>> they get created? > >> >> >>>>> > >> >> >>>>> On Mon, Aug 21, 2017 at 2:35 PM, Jom O'Fisher > >> >> >>>>> > >> >> >>>>> wrote: > >> >> >>>>> > Would it work for your scenario to provide properties in the > >> >> >>>>> > root > >> >> >>>>> > build.gradle: > >> >> >>>>> > > >> >> >>>>> > ext { > >> >> >>>>> > cmakePath = file "CMakeLists.txt" > >> >> >>>>> > } > >> >> >>>>> > > >> >> >>>>> > And then consume them in the leaf app/build.gradle like this? > >> >> >>>>> > > >> >> >>>>> > externalNativeBuild { > >> >> >>>>> > cmake { > >> >> >>>>> > path cmakePath > >> >> >>>>> > } > >> >> >>>>> > } > >> >> >>>>> > > >> >> >>>>> > It doesn't fully hide the details but it does centralize the > >> >> >>>>> > information. > >> >> >>>>> > > >> >> >>>>> > > >> >> >>>>> > On Mon, Aug 21, 2017 at 11:20 AM, Robert Dailey > >> >> >>>>> > > >> >> >>>>> > wrote: > >> >> >>>>> >> > >> >> >>>>> >> I wouldn't want to do that, it's too convoluted. I have > other > >> >> >>>>> >> platforms that use these CMake scripts as well. For > example, I > >> >> >>>>> >> run on > >> >> >>>>> >> Windows and Linux platforms as well to build the native > code. > >> >> >>>>> >> Normal > >> >> >>>>> >> CMake behavior is designed to work at a root then go > downwards > >> >> >>>>> >> to > >> >> >>>>> >> find > >> >> >>>>> >> targets. However it seems Gradle wants to start at a > >> >> >>>>> >> subdirectory > >> >> >>>>> >> and > >> >> >>>>> >> work its way up to the root, which is opposite of CMake's > >> >> >>>>> >> intended > >> >> >>>>> >> behavior IMHO. Not only that but I want to avoid > >> >> >>>>> >> special-casing > >> >> >>>>> >> behavior in CMake just for Android's use. > >> >> >>>>> >> > >> >> >>>>> >> At the moment it feels like (again referring back to my > >> >> >>>>> >> previous > >> >> >>>>> >> example structure) that both App2 and App3 each run CMake in > >> >> >>>>> >> independent binary directories instead of sharing 1 binary > >> >> >>>>> >> directory > >> >> >>>>> >> and building 2 targets inside of it. I prefer this behavior > >> >> >>>>> >> instead, > >> >> >>>>> >> especially since it allows CMake to operate as it was > >> >> >>>>> >> intended. I > >> >> >>>>> >> think it's a common case that projects will define multiple > >> >> >>>>> >> targets > >> >> >>>>> >> starting from a single root, and expect multiple APKs or > java > >> >> >>>>> >> dependencies to be built within it. > >> >> >>>>> >> > >> >> >>>>> >> If I'm misunderstanding or making false assumptions please > let > >> >> >>>>> >> me > >> >> >>>>> >> know. > >> >> >>>>> >> > >> >> >>>>> >> > >> >> >>>>> >> > >> >> >>>>> >> On Mon, Aug 21, 2017 at 12:00 PM, Jom O'Fisher > >> >> >>>>> >> > >> >> >>>>> >> wrote: > >> >> >>>>> >> > Would it work for your situation for the leaf > CMakeLists.txt > >> >> >>>>> >> > to > >> >> >>>>> >> > include > >> >> >>>>> >> > the > >> >> >>>>> >> > root CMakeLists.txt? Then have the leaf-specific logic in > >> >> >>>>> >> > the > >> >> >>>>> >> > leaf > >> >> >>>>> >> > CMakeLists.txt? > >> >> >>>>> >> > > >> >> >>>>> >> > > >> >> >>>>> >> > > >> >> >>>>> >> > On Mon, Aug 21, 2017 at 9:33 AM, Robert Dailey > >> >> >>>>> >> > > >> >> >>>>> >> > wrote: > >> >> >>>>> >> >> > >> >> >>>>> >> >> Basically, yes. We have this sort of structure: > >> >> >>>>> >> >> > >> >> >>>>> >> >> / > >> >> >>>>> >> >> Applications/ > >> >> >>>>> >> >> App1/ > >> >> >>>>> >> >> build.gradle > >> >> >>>>> >> >> CMakeLists.txt > >> >> >>>>> >> >> App2/ > >> >> >>>>> >> >> build.gradle > >> >> >>>>> >> >> CMakeLists.txt > >> >> >>>>> >> >> App3/ > >> >> >>>>> >> >> build.gradle > >> >> >>>>> >> >> CMakeLists.txt > >> >> >>>>> >> >> CommonLib/ > >> >> >>>>> >> >> build.gradle > >> >> >>>>> >> >> CMakeLists.txt > >> >> >>>>> >> >> CMakeLists.txt > >> >> >>>>> >> >> > >> >> >>>>> >> >> The libs are defined as follows: > >> >> >>>>> >> >> > >> >> >>>>> >> >> * CommonLib is a static library (java code builds into a > >> >> >>>>> >> >> library) > >> >> >>>>> >> >> * No dependencies of its own > >> >> >>>>> >> >> * App1 is a shared library (java code builds into a > >> >> >>>>> >> >> library) > >> >> >>>>> >> >> * Dependencies (both java & native): CommonLib > >> >> >>>>> >> >> * App2 is a shared library (java code builds into an APK) > >> >> >>>>> >> >> * Dependencies (both java & native): App1, CommonLib > >> >> >>>>> >> >> * App3 is a shared library (java code builds into an APK) > >> >> >>>>> >> >> * Dependencies (both java & native): CommonLib > >> >> >>>>> >> >> > >> >> >>>>> >> >> In all cases, CMake must be invoked starting at the root > >> >> >>>>> >> >> CMakeLists.txt 1 time. Each target can be built from the > >> >> >>>>> >> >> same > >> >> >>>>> >> >> binary > >> >> >>>>> >> >> directory after that. Previously with ANT, I was building > >> >> >>>>> >> >> all > >> >> >>>>> >> >> native > >> >> >>>>> >> >> targets first, then moved libs to appropriate directories > >> >> >>>>> >> >> so > >> >> >>>>> >> >> that > >> >> >>>>> >> >> the > >> >> >>>>> >> >> 'ant' command would package the libs. > >> >> >>>>> >> >> > >> >> >>>>> >> >> For gradle, I wanted to avoid redundantly specifying the > >> >> >>>>> >> >> root > >> >> >>>>> >> >> directory in each leaf-level project directory. Using the > >> >> >>>>> >> >> example > >> >> >>>>> >> >> above, the leaf-level directories in this case would be > >> >> >>>>> >> >> App1, > >> >> >>>>> >> >> App2, > >> >> >>>>> >> >> App3, and CommonLib. However I think we only specify the > >> >> >>>>> >> >> native > >> >> >>>>> >> >> CMake > >> >> >>>>> >> >> stuff for the java targets that actually output an APK > >> >> >>>>> >> >> (that > >> >> >>>>> >> >> would > >> >> >>>>> >> >> be > >> >> >>>>> >> >> App2 and App3 only). > >> >> >>>>> >> >> > >> >> >>>>> >> >> The ultimate goal is to specify stuff that doesn't change > >> >> >>>>> >> >> per > >> >> >>>>> >> >> independent "module" of ours at the top level so it is > >> >> >>>>> >> >> transitive > >> >> >>>>> >> >> / > >> >> >>>>> >> >> inherited. Then only specify the differences (e.g. the > >> >> >>>>> >> >> native > >> >> >>>>> >> >> CMake > >> >> >>>>> >> >> target to build) in the leaf build gradle files. However > >> >> >>>>> >> >> you > >> >> >>>>> >> >> indicated > >> >> >>>>> >> >> this isn't possible. > >> >> >>>>> >> >> > >> >> >>>>> >> >> > >> >> >>>>> >> >> > >> >> >>>>> >> >> On Mon, Aug 21, 2017 at 11:11 AM, Jom O'Fisher > >> >> >>>>> >> >> > >> >> >>>>> >> >> wrote: > >> >> >>>>> >> >> > What you're doing already sounds correct. You can't > >> >> >>>>> >> >> > directly > >> >> >>>>> >> >> > specify > >> >> >>>>> >> >> > CMakeLists.txt from the top-level build.gradle. > >> >> >>>>> >> >> > Recommendation > >> >> >>>>> >> >> > is > >> >> >>>>> >> >> > that > >> >> >>>>> >> >> > it > >> >> >>>>> >> >> > should be specified from the build.gradle of the module > >> >> >>>>> >> >> > of > >> >> >>>>> >> >> > the > >> >> >>>>> >> >> > APK. > >> >> >>>>> >> >> > Is > >> >> >>>>> >> >> > the > >> >> >>>>> >> >> > issue that you have multiple APK modules that all > >> >> >>>>> >> >> > reference > >> >> >>>>> >> >> > the > >> >> >>>>> >> >> > same > >> >> >>>>> >> >> > CMake > >> >> >>>>> >> >> > libraries? > >> >> >>>>> >> >> > > >> >> >>>>> >> >> > On Mon, Aug 21, 2017 at 9:00 AM, Robert Dailey > >> >> >>>>> >> >> > > >> >> >>>>> >> >> > wrote: > >> >> >>>>> >> >> >> > >> >> >>>>> >> >> >> Thanks this is very helpful. The other question I have > >> >> >>>>> >> >> >> is: > >> >> >>>>> >> >> >> Is > >> >> >>>>> >> >> >> there > >> >> >>>>> >> >> >> a > >> >> >>>>> >> >> >> place to centrally specify the root CMakeLists.txt? > >> >> >>>>> >> >> >> Basically, > >> >> >>>>> >> >> >> I > >> >> >>>>> >> >> >> want > >> >> >>>>> >> >> >> to specify the CMake root in 1 place, and have targets > >> >> >>>>> >> >> >> (defined > >> >> >>>>> >> >> >> further down in subdirectories) that require APK > >> >> >>>>> >> >> >> packaging > >> >> >>>>> >> >> >> to > >> >> >>>>> >> >> >> specify > >> >> >>>>> >> >> >> only the native target name that should be built & > >> >> >>>>> >> >> >> packaged. > >> >> >>>>> >> >> >> > >> >> >>>>> >> >> >> At the moment we specify the root CMakeLists.txt by > >> >> >>>>> >> >> >> walking > >> >> >>>>> >> >> >> up > >> >> >>>>> >> >> >> the > >> >> >>>>> >> >> >> tree, paths like "../../../../CMakeLists.txt". I think > >> >> >>>>> >> >> >> this > >> >> >>>>> >> >> >> should > >> >> >>>>> >> >> >> be > >> >> >>>>> >> >> >> put at the top-level build gradle file if possible. Is > >> >> >>>>> >> >> >> this > >> >> >>>>> >> >> >> doable > >> >> >>>>> >> >> >> at > >> >> >>>>> >> >> >> the moment? What is the recommended setup? > >> >> >>>>> >> >> >> > >> >> >>>>> >> >> >> On Mon, Aug 21, 2017 at 9:37 AM, Jom O'Fisher > >> >> >>>>> >> >> >> > >> >> >>>>> >> >> >> wrote: > >> >> >>>>> >> >> >> > Gradle does introspection on the CMake build to find > >> >> >>>>> >> >> >> > .so > >> >> >>>>> >> >> >> > targets > >> >> >>>>> >> >> >> > and > >> >> >>>>> >> >> >> > those > >> >> >>>>> >> >> >> > get packaged. > >> >> >>>>> >> >> >> > There is also a special case for stl/runtime .so > files > >> >> >>>>> >> >> >> > from > >> >> >>>>> >> >> >> > the > >> >> >>>>> >> >> >> > NDK. > >> >> >>>>> >> >> >> > Any additional .so files need to specified in > >> >> >>>>> >> >> >> > build.gradle > >> >> >>>>> >> >> >> > using > >> >> >>>>> >> >> >> > jniDirs > >> >> >>>>> >> >> >> > > >> >> >>>>> >> >> >> > On Mon, Aug 21, 2017 at 7:30 AM, Robert Dailey > >> >> >>>>> >> >> >> > > >> >> >>>>> >> >> >> > wrote: > >> >> >>>>> >> >> >> >> > >> >> >>>>> >> >> >> >> How exactly does Gradle package *.so files in an > APK? > >> >> >>>>> >> >> >> >> I > >> >> >>>>> >> >> >> >> know > >> >> >>>>> >> >> >> >> that > >> >> >>>>> >> >> >> >> ANT > >> >> >>>>> >> >> >> >> used to do this for any libs under "libs/". > Does > >> >> >>>>> >> >> >> >> Gradle > >> >> >>>>> >> >> >> >> do > >> >> >>>>> >> >> >> >> some > >> >> >>>>> >> >> >> >> introspection into CMake targets to see if outputs > >> >> >>>>> >> >> >> >> are > >> >> >>>>> >> >> >> >> *.so, > >> >> >>>>> >> >> >> >> and > >> >> >>>>> >> >> >> >> copy > >> >> >>>>> >> >> >> >> those to some location if needed? What about > >> >> >>>>> >> >> >> >> libraries > >> >> >>>>> >> >> >> >> like > >> >> >>>>> >> >> >> >> libgnustl_shared.so that come with the NDK? I'd > like > >> >> >>>>> >> >> >> >> to > >> >> >>>>> >> >> >> >> know > >> >> >>>>> >> >> >> >> if > >> >> >>>>> >> >> >> >> any > >> >> >>>>> >> >> >> >> manual copy steps are needed in CMake to put > outputs > >> >> >>>>> >> >> >> >> in > >> >> >>>>> >> >> >> >> proper > >> >> >>>>> >> >> >> >> locations for the APK build step. I had to do this > >> >> >>>>> >> >> >> >> when > >> >> >>>>> >> >> >> >> using > >> >> >>>>> >> >> >> >> ANT. > >> >> >>>>> >> >> >> >> > >> >> >>>>> >> >> >> >> On Mon, Aug 7, 2017 at 6:16 PM, Jom O'Fisher > >> >> >>>>> >> >> >> >> > >> >> >>>>> >> >> >> >> wrote: > >> >> >>>>> >> >> >> >> > 1) There is a folder created for each ABI under > the > >> >> >>>>> >> >> >> >> > project > >> >> >>>>> >> >> >> >> > module > >> >> >>>>> >> >> >> >> > folder > >> >> >>>>> >> >> >> >> > (so unique per module per ABI) > >> >> >>>>> >> >> >> >> > 2) Gradle doesn't specify language level though > you > >> >> >>>>> >> >> >> >> > can > >> >> >>>>> >> >> >> >> > choose > >> >> >>>>> >> >> >> >> > to > >> >> >>>>> >> >> >> >> > specify it > >> >> >>>>> >> >> >> >> > yourself from the build.gradle. This doc does a > >> >> >>>>> >> >> >> >> > pretty > >> >> >>>>> >> >> >> >> > good job > >> >> >>>>> >> >> >> >> > of > >> >> >>>>> >> >> >> >> > explaining which variables are set by Gradle: > >> >> >>>>> >> >> >> >> > > >> >> >>>>> >> >> >> >> > > >> >> >>>>> >> >> >> >> > > >> >> >>>>> >> >> >> >> > https://developer.android.com/ > ndk/guides/cmake.html#variables. > >> >> >>>>> >> >> >> >> > Philosophically, we try to set as little as we > can > >> >> >>>>> >> >> >> >> > get > >> >> >>>>> >> >> >> >> > away > >> >> >>>>> >> >> >> >> > with. > >> >> >>>>> >> >> >> >> > In > >> >> >>>>> >> >> >> >> > particular, the section titled "Understanding the > >> >> >>>>> >> >> >> >> > CMake > >> >> >>>>> >> >> >> >> > build > >> >> >>>>> >> >> >> >> > command" > >> >> >>>>> >> >> >> >> > lays > >> >> >>>>> >> >> >> >> > out exactly what we set. You can also see the > >> >> >>>>> >> >> >> >> > folders > >> >> >>>>> >> >> >> >> > we > >> >> >>>>> >> >> >> >> > specify > >> >> >>>>> >> >> >> >> > (one > >> >> >>>>> >> >> >> >> > per > >> >> >>>>> >> >> >> >> > module per ABI) > >> >> >>>>> >> >> >> >> > 3) Not sure I understand this. > >> >> >>>>> >> >> >> >> > > >> >> >>>>> >> >> >> >> > The other document worth taking a look at (if you > >> >> >>>>> >> >> >> >> > haven't > >> >> >>>>> >> >> >> >> > already) > >> >> >>>>> >> >> >> >> > is: > >> >> >>>>> >> >> >> >> > > >> >> >>>>> >> >> >> >> > > >> >> >>>>> >> >> >> >> > > >> >> >>>>> >> >> >> >> > > >> >> >>>>> >> >> >> >> > https://developer.android.com/ > studio/projects/add-native-code.html > >> >> >>>>> >> >> >> >> > > >> >> >>>>> >> >> >> >> > > >> >> >>>>> >> >> >> >> > On Mon, Aug 7, 2017 at 3:35 PM, Robert Dailey > >> >> >>>>> >> >> >> >> > > >> >> >>>>> >> >> >> >> > wrote: > >> >> >>>>> >> >> >> >> >> > >> >> >>>>> >> >> >> >> >> Thanks Jom > >> >> >>>>> >> >> >> >> >> > >> >> >>>>> >> >> >> >> >> Honestly, I prefer option 1 to work simply > because > >> >> >>>>> >> >> >> >> >> that's > >> >> >>>>> >> >> >> >> >> how > >> >> >>>>> >> >> >> >> >> Google's > >> >> >>>>> >> >> >> >> >> officially supporting CMake. But it also has > >> >> >>>>> >> >> >> >> >> debugging > >> >> >>>>> >> >> >> >> >> which > >> >> >>>>> >> >> >> >> >> is > >> >> >>>>> >> >> >> >> >> the > >> >> >>>>> >> >> >> >> >> #1 > >> >> >>>>> >> >> >> >> >> reason for me. > >> >> >>>>> >> >> >> >> >> > >> >> >>>>> >> >> >> >> >> However, I'd like to understand a lot more about > >> >> >>>>> >> >> >> >> >> how > >> >> >>>>> >> >> >> >> >> the > >> >> >>>>> >> >> >> >> >> integration > >> >> >>>>> >> >> >> >> >> really happens. For example, I have these > >> >> >>>>> >> >> >> >> >> questions: > >> >> >>>>> >> >> >> >> >> > >> >> >>>>> >> >> >> >> >> 1) How, internally, are CMake build directories > >> >> >>>>> >> >> >> >> >> managed? > >> >> >>>>> >> >> >> >> >> Do > >> >> >>>>> >> >> >> >> >> you > >> >> >>>>> >> >> >> >> >> generate 1 per unique android project? What > about > >> >> >>>>> >> >> >> >> >> for > >> >> >>>>> >> >> >> >> >> each > >> >> >>>>> >> >> >> >> >> specific > >> >> >>>>> >> >> >> >> >> platform (x86, armeabi-v7a, etc)? > >> >> >>>>> >> >> >> >> >> 2) Last time I looked into CMake integration, > >> >> >>>>> >> >> >> >> >> things > >> >> >>>>> >> >> >> >> >> defined > >> >> >>>>> >> >> >> >> >> inside > >> >> >>>>> >> >> >> >> >> the CMake scripts were ignored because they are > >> >> >>>>> >> >> >> >> >> specified > >> >> >>>>> >> >> >> >> >> at > >> >> >>>>> >> >> >> >> >> the > >> >> >>>>> >> >> >> >> >> command line. Namely, all of those settings that > >> >> >>>>> >> >> >> >> >> are > >> >> >>>>> >> >> >> >> >> driven by > >> >> >>>>> >> >> >> >> >> the > >> >> >>>>> >> >> >> >> >> Gradle configuration (CXX language level was one > >> >> >>>>> >> >> >> >> >> in > >> >> >>>>> >> >> >> >> >> particular > >> >> >>>>> >> >> >> >> >> I > >> >> >>>>> >> >> >> >> >> think; I specify C++14 support via CMake, but I > >> >> >>>>> >> >> >> >> >> recall > >> >> >>>>> >> >> >> >> >> this > >> >> >>>>> >> >> >> >> >> being > >> >> >>>>> >> >> >> >> >> overridden from outside)? > >> >> >>>>> >> >> >> >> >> 3) How redundant is it to configure individual > >> >> >>>>> >> >> >> >> >> libraries > >> >> >>>>> >> >> >> >> >> via > >> >> >>>>> >> >> >> >> >> the > >> >> >>>>> >> >> >> >> >> gradle scripts? In my previous attempts, I > wanted > >> >> >>>>> >> >> >> >> >> to > >> >> >>>>> >> >> >> >> >> define > >> >> >>>>> >> >> >> >> >> common > >> >> >>>>> >> >> >> >> >> stuff for CMake / native code at the root gradle > >> >> >>>>> >> >> >> >> >> or > >> >> >>>>> >> >> >> >> >> settings > >> >> >>>>> >> >> >> >> >> file, > >> >> >>>>> >> >> >> >> >> and > >> >> >>>>> >> >> >> >> >> only define the differences in the actual gradle > >> >> >>>>> >> >> >> >> >> build > >> >> >>>>> >> >> >> >> >> files > >> >> >>>>> >> >> >> >> >> for > >> >> >>>>> >> >> >> >> >> each > >> >> >>>>> >> >> >> >> >> corresponding Java target (like, defining the > name > >> >> >>>>> >> >> >> >> >> of > >> >> >>>>> >> >> >> >> >> the > >> >> >>>>> >> >> >> >> >> native > >> >> >>>>> >> >> >> >> >> (shared library) target in Gradle, but the > command > >> >> >>>>> >> >> >> >> >> line > >> >> >>>>> >> >> >> >> >> invocation, > >> >> >>>>> >> >> >> >> >> -D > >> >> >>>>> >> >> >> >> >> CMake settings, etc would all be common and > >> >> >>>>> >> >> >> >> >> defined > >> >> >>>>> >> >> >> >> >> at > >> >> >>>>> >> >> >> >> >> the > >> >> >>>>> >> >> >> >> >> root). > >> >> >>>>> >> >> >> >> >> > >> >> >>>>> >> >> >> >> >> The TLDR is, the closer we can stay to CMake's > way > >> >> >>>>> >> >> >> >> >> of > >> >> >>>>> >> >> >> >> >> doing > >> >> >>>>> >> >> >> >> >> things > >> >> >>>>> >> >> >> >> >> and > >> >> >>>>> >> >> >> >> >> keep CMake-related settings self-contained to > the > >> >> >>>>> >> >> >> >> >> CMake > >> >> >>>>> >> >> >> >> >> scripts > >> >> >>>>> >> >> >> >> >> themselves, the better. This also makes > >> >> >>>>> >> >> >> >> >> cross-platform > >> >> >>>>> >> >> >> >> >> easier > >> >> >>>>> >> >> >> >> >> (we > >> >> >>>>> >> >> >> >> >> build the native code in Windows, for example, > so > >> >> >>>>> >> >> >> >> >> having > >> >> >>>>> >> >> >> >> >> settings > >> >> >>>>> >> >> >> >> >> specified in the gradle files do not carry over > to > >> >> >>>>> >> >> >> >> >> other > >> >> >>>>> >> >> >> >> >> platforms. > >> >> >>>>> >> >> >> >> >> Namely, settings that are not platform specific > >> >> >>>>> >> >> >> >> >> like > >> >> >>>>> >> >> >> >> >> the > >> >> >>>>> >> >> >> >> >> C++ > >> >> >>>>> >> >> >> >> >> language > >> >> >>>>> >> >> >> >> >> level). > >> >> >>>>> >> >> >> >> >> > >> >> >>>>> >> >> >> >> >> If there's a detailed document / wiki I can read > >> >> >>>>> >> >> >> >> >> on > >> >> >>>>> >> >> >> >> >> the > >> >> >>>>> >> >> >> >> >> intrinsics > >> >> >>>>> >> >> >> >> >> of > >> >> >>>>> >> >> >> >> >> CMake integration in Gradle / Android Studio, > I'd > >> >> >>>>> >> >> >> >> >> love to > >> >> >>>>> >> >> >> >> >> read > >> >> >>>>> >> >> >> >> >> it. > >> >> >>>>> >> >> >> >> >> Otherwise, I hope you won't mind if I pick your > >> >> >>>>> >> >> >> >> >> brain > >> >> >>>>> >> >> >> >> >> as > >> >> >>>>> >> >> >> >> >> questions > >> >> >>>>> >> >> >> >> >> come up. I think I'm going to try option 1 for > now > >> >> >>>>> >> >> >> >> >> and > >> >> >>>>> >> >> >> >> >> see how > >> >> >>>>> >> >> >> >> >> it > >> >> >>>>> >> >> >> >> >> goes. It's just black box for me because unlike > >> >> >>>>> >> >> >> >> >> option 2, > >> >> >>>>> >> >> >> >> >> I > >> >> >>>>> >> >> >> >> >> have > >> >> >>>>> >> >> >> >> >> very > >> >> >>>>> >> >> >> >> >> little control over what happens after building > >> >> >>>>> >> >> >> >> >> the > >> >> >>>>> >> >> >> >> >> shared > >> >> >>>>> >> >> >> >> >> libraries, > >> >> >>>>> >> >> >> >> >> and to make up for that I need to really get a > >> >> >>>>> >> >> >> >> >> deep > >> >> >>>>> >> >> >> >> >> understanding > >> >> >>>>> >> >> >> >> >> of > >> >> >>>>> >> >> >> >> >> how it works so I can make sure I code my CMake > >> >> >>>>> >> >> >> >> >> scripts > >> >> >>>>> >> >> >> >> >> properly > >> >> >>>>> >> >> >> >> >> for > >> >> >>>>> >> >> >> >> >> not only Android, but my other platforms as well > >> >> >>>>> >> >> >> >> >> (non-Android > >> >> >>>>> >> >> >> >> >> platforms). > >> >> >>>>> >> >> >> >> >> > >> >> >>>>> >> >> >> >> >> Thanks again. > >> >> >>>>> >> >> >> >> >> > >> >> >>>>> >> >> >> >> >> On Mon, Aug 7, 2017 at 5:12 PM, Jom O'Fisher > >> >> >>>>> >> >> >> >> >> > >> >> >>>>> >> >> >> >> >> wrote: > >> >> >>>>> >> >> >> >> >> > Either option can work fine. Disclosure: I > work > >> >> >>>>> >> >> >> >> >> > on > >> >> >>>>> >> >> >> >> >> > Android > >> >> >>>>> >> >> >> >> >> > Studio > >> >> >>>>> >> >> >> >> >> > and > >> >> >>>>> >> >> >> >> >> > was > >> >> >>>>> >> >> >> >> >> > the one that added CMake support. > >> >> >>>>> >> >> >> >> >> > > >> >> >>>>> >> >> >> >> >> > Option (1) is the way it's designed to work > and > >> >> >>>>> >> >> >> >> >> > we're > >> >> >>>>> >> >> >> >> >> > working > >> >> >>>>> >> >> >> >> >> > toward > >> >> >>>>> >> >> >> >> >> > getting > >> >> >>>>> >> >> >> >> >> > rid of the need for the CMake fork. I can't > >> >> >>>>> >> >> >> >> >> > really > >> >> >>>>> >> >> >> >> >> > say > >> >> >>>>> >> >> >> >> >> > when > >> >> >>>>> >> >> >> >> >> > that > >> >> >>>>> >> >> >> >> >> > will > >> >> >>>>> >> >> >> >> >> > happen > >> >> >>>>> >> >> >> >> >> > but if you can get away with an older CMake > for > >> >> >>>>> >> >> >> >> >> > now > >> >> >>>>> >> >> >> >> >> > then I'd > >> >> >>>>> >> >> >> >> >> > go > >> >> >>>>> >> >> >> >> >> > this > >> >> >>>>> >> >> >> >> >> > way. > >> >> >>>>> >> >> >> >> >> > As you mentioned, option (1) will allow you to > >> >> >>>>> >> >> >> >> >> > view > >> >> >>>>> >> >> >> >> >> > your > >> >> >>>>> >> >> >> >> >> > source > >> >> >>>>> >> >> >> >> >> > file > >> >> >>>>> >> >> >> >> >> > structure in Android Studio, edit files, and > >> >> >>>>> >> >> >> >> >> > debug > >> >> >>>>> >> >> >> >> >> > using the > >> >> >>>>> >> >> >> >> >> > built-in > >> >> >>>>> >> >> >> >> >> > debugging support. > >> >> >>>>> >> >> >> >> >> > > >> >> >>>>> >> >> >> >> >> > To get option (2) to work, you can use jniDirs > >> >> >>>>> >> >> >> >> >> > setting > >> >> >>>>> >> >> >> >> >> > to > >> >> >>>>> >> >> >> >> >> > tell > >> >> >>>>> >> >> >> >> >> > Android > >> >> >>>>> >> >> >> >> >> > Gradle where to pick up your built .so files > >> >> >>>>> >> >> >> >> >> > (see > >> >> >>>>> >> >> >> >> >> > > >> >> >>>>> >> >> >> >> >> > > >> >> >>>>> >> >> >> >> >> > > >> >> >>>>> >> >> >> >> >> > > >> >> >>>>> >> >> >> >> >> > > >> >> >>>>> >> >> >> >> >> > > >> >> >>>>> >> >> >> >> >> > > >> >> >>>>> >> >> >> >> >> > > >> >> >>>>> >> >> >> >> >> > https://stackoverflow.com/ > questions/21255125/how-can-i-add-so-files-to-an-android- > library-project-using-gradle-0-7). > >> >> >>>>> >> >> >> >> >> > I'm not aware of any projects that use this > >> >> >>>>> >> >> >> >> >> > approach > >> >> >>>>> >> >> >> >> >> > but it > >> >> >>>>> >> >> >> >> >> > should > >> >> >>>>> >> >> >> >> >> > work > >> >> >>>>> >> >> >> >> >> > in > >> >> >>>>> >> >> >> >> >> > principal. > >> >> >>>>> >> >> >> >> >> > > >> >> >>>>> >> >> >> >> >> > I hope this helps, > >> >> >>>>> >> >> >> >> >> > Jomo > >> >> >>>>> >> >> >> >> >> > > >> >> >>>>> >> >> >> >> >> > > >> >> >>>>> >> >> >> >> >> > On Mon, Aug 7, 2017 at 11:09 AM, Robert Dailey > >> >> >>>>> >> >> >> >> >> > > >> >> >>>>> >> >> >> >> >> > wrote: > >> >> >>>>> >> >> >> >> >> >> > >> >> >>>>> >> >> >> >> >> >> Right now I have custom targets set to > execute > >> >> >>>>> >> >> >> >> >> >> the > >> >> >>>>> >> >> >> >> >> >> "ant > >> >> >>>>> >> >> >> >> >> >> release" > >> >> >>>>> >> >> >> >> >> >> command after my native targets are built. > Part > >> >> >>>>> >> >> >> >> >> >> of > >> >> >>>>> >> >> >> >> >> >> that > >> >> >>>>> >> >> >> >> >> >> command > >> >> >>>>> >> >> >> >> >> >> involves copying *.so files to the > >> >> >>>>> >> >> >> >> >> >> libs/armeabi-v7a > >> >> >>>>> >> >> >> >> >> >> directory > >> >> >>>>> >> >> >> >> >> >> so > >> >> >>>>> >> >> >> >> >> >> they > >> >> >>>>> >> >> >> >> >> >> get packaged in an APK. > >> >> >>>>> >> >> >> >> >> >> > >> >> >>>>> >> >> >> >> >> >> When switching to gradle, I have two options: > >> >> >>>>> >> >> >> >> >> >> > >> >> >>>>> >> >> >> >> >> >> 1. Gradle drives CMake: This means using > >> >> >>>>> >> >> >> >> >> >> Android > >> >> >>>>> >> >> >> >> >> >> Studio and > >> >> >>>>> >> >> >> >> >> >> being > >> >> >>>>> >> >> >> >> >> >> locked down to Google's fork of CMake which > is > >> >> >>>>> >> >> >> >> >> >> a > >> >> >>>>> >> >> >> >> >> >> few > >> >> >>>>> >> >> >> >> >> >> major > >> >> >>>>> >> >> >> >> >> >> releases > >> >> >>>>> >> >> >> >> >> >> behind. I see that as a negative. > >> >> >>>>> >> >> >> >> >> >> > >> >> >>>>> >> >> >> >> >> >> 2. CMake drives Gradle: This would be the > same > >> >> >>>>> >> >> >> >> >> >> or > >> >> >>>>> >> >> >> >> >> >> similar > >> >> >>>>> >> >> >> >> >> >> to > >> >> >>>>> >> >> >> >> >> >> what > >> >> >>>>> >> >> >> >> >> >> I'm > >> >> >>>>> >> >> >> >> >> >> already doing: The custom targets I have > would > >> >> >>>>> >> >> >> >> >> >> execute > >> >> >>>>> >> >> >> >> >> >> gradle > >> >> >>>>> >> >> >> >> >> >> as > >> >> >>>>> >> >> >> >> >> >> a > >> >> >>>>> >> >> >> >> >> >> separate build step, instead of running ant > >> >> >>>>> >> >> >> >> >> >> commands. > >> >> >>>>> >> >> >> >> >> >> I'm > >> >> >>>>> >> >> >> >> >> >> not > >> >> >>>>> >> >> >> >> >> >> too > >> >> >>>>> >> >> >> >> >> >> familiar with Gradle, so I'm not sure how you > >> >> >>>>> >> >> >> >> >> >> tell > >> >> >>>>> >> >> >> >> >> >> it > >> >> >>>>> >> >> >> >> >> >> where > >> >> >>>>> >> >> >> >> >> >> your > >> >> >>>>> >> >> >> >> >> >> shared libraries are for the APK packaging > >> >> >>>>> >> >> >> >> >> >> steps. > >> >> >>>>> >> >> >> >> >> >> > >> >> >>>>> >> >> >> >> >> >> Which does everyone recommend? Is anyone > using > >> >> >>>>> >> >> >> >> >> >> one > >> >> >>>>> >> >> >> >> >> >> of > >> >> >>>>> >> >> >> >> >> >> these > >> >> >>>>> >> >> >> >> >> >> setups > >> >> >>>>> >> >> >> >> >> >> successfully? The downside to option 2 is > >> >> >>>>> >> >> >> >> >> >> probably > >> >> >>>>> >> >> >> >> >> >> no > >> >> >>>>> >> >> >> >> >> >> on-device > >> >> >>>>> >> >> >> >> >> >> native > >> >> >>>>> >> >> >> >> >> >> debugging since Android Studio probably can't > >> >> >>>>> >> >> >> >> >> >> handle > >> >> >>>>> >> >> >> >> >> >> gradle > >> >> >>>>> >> >> >> >> >> >> projects > >> >> >>>>> >> >> >> >> >> >> without any external CMake builds set up. > >> >> >>>>> >> >> >> >> >> >> > >> >> >>>>> >> >> >> >> >> >> Would like some general direction & advice > >> >> >>>>> >> >> >> >> >> >> before > >> >> >>>>> >> >> >> >> >> >> I > >> >> >>>>> >> >> >> >> >> >> move > >> >> >>>>> >> >> >> >> >> >> away > >> >> >>>>> >> >> >> >> >> >> from > >> >> >>>>> >> >> >> >> >> >> ANT. Thanks in advance. > >> >> >>>>> >> >> >> >> >> >> -- > >> >> >>>>> >> >> >> >> >> >> > >> >> >>>>> >> >> >> >> >> >> Powered by www.kitware.com > >> >> >>>>> >> >> >> >> >> >> > >> >> >>>>> >> >> >> >> >> >> Please keep messages on-topic and check the > >> >> >>>>> >> >> >> >> >> >> CMake > >> >> >>>>> >> >> >> >> >> >> FAQ > >> >> >>>>> >> >> >> >> >> >> at: > >> >> >>>>> >> >> >> >> >> >> http://www.cmake.org/Wiki/CMake_FAQ > >> >> >>>>> >> >> >> >> >> >> > >> >> >>>>> >> >> >> >> >> >> Kitware offers various services to support > the > >> >> >>>>> >> >> >> >> >> >> CMake > >> >> >>>>> >> >> >> >> >> >> community. > >> >> >>>>> >> >> >> >> >> >> For > >> >> >>>>> >> >> >> >> >> >> more > >> >> >>>>> >> >> >> >> >> >> information on each offering, please visit: > >> >> >>>>> >> >> >> >> >> >> > >> >> >>>>> >> >> >> >> >> >> CMake Support: > >> >> >>>>> >> >> >> >> >> >> http://cmake.org/cmake/help/support.html > >> >> >>>>> >> >> >> >> >> >> CMake Consulting: > >> >> >>>>> >> >> >> >> >> >> http://cmake.org/cmake/help/consulting.html > >> >> >>>>> >> >> >> >> >> >> CMake Training Courses: > >> >> >>>>> >> >> >> >> >> >> http://cmake.org/cmake/help/training.html > >> >> >>>>> >> >> >> >> >> >> > >> >> >>>>> >> >> >> >> >> >> Visit other Kitware open-source projects at > >> >> >>>>> >> >> >> >> >> >> > >> >> >>>>> >> >> >> >> >> >> http://www.kitware.com/ > opensource/opensource.html > >> >> >>>>> >> >> >> >> >> >> > >> >> >>>>> >> >> >> >> >> >> Follow this link to subscribe/unsubscribe: > >> >> >>>>> >> >> >> >> >> >> > >> >> >>>>> >> >> >> >> >> >> http://public.kitware.com/ > mailman/listinfo/cmake > >> >> >>>>> >> >> >> >> >> > > >> >> >>>>> >> >> >> >> >> > > >> >> >>>>> >> >> >> >> > > >> >> >>>>> >> >> >> >> > > >> >> >>>>> >> >> >> > > >> >> >>>>> >> >> >> > > >> >> >>>>> >> >> > > >> >> >>>>> >> >> > > >> >> >>>>> >> > > >> >> >>>>> >> > > >> >> >>>>> > > >> >> >>>>> > > >> >> >>>> > >> >> >>>> > >> >> >>> > >> >> >> > >> > > >> > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jomofisher at gmail.com Fri Aug 25 20:20:01 2017 From: jomofisher at gmail.com (Jom O'Fisher) Date: Fri, 25 Aug 2017 17:20:01 -0700 Subject: [CMake] CMake + Gradle for Android In-Reply-To: References: Message-ID: Hi again Robert, Would you be able to give me an estimate of how many APK projects you have, roughly which open source projects you reference via CMake add_subdirectories, and whether you have any variants beyond the default Debug and Release? If possible I'd like to approximate your project layout so we can study it in more closely with an eye toward making the experience better for this kind of layout. On Fri, Aug 25, 2017 at 2:46 PM, Jom O'Fisher wrote: > Targets are specified per-Variation so they need to go under the > variation-specific section. Probably something like this: > > defaultConfig { > externalNativeBuild { > cmake { > targets "library1", "library2" > } > } > } > > That should work for you. Let me know. > > On Fri, Aug 25, 2017 at 2:42 PM, Robert Dailey > wrote: > >> By the way when I try to use "targets", I get a failure. Basically >> Gradle doesn't recognize that keyword. I tried singular form as well >> ("target"), no luck. >> >> I'm running canary build of everything possible. What am I missing? >> >> On Wed, Aug 23, 2017 at 4:20 PM, Jom O'Fisher >> wrote: >> > By gradle module projects, I just mean the leaf build.gradle files as >> > opposed to the root build.gradle. By configurations, I mean Build Types >> > (debug vs release) and Product Flavors (demo vs free vs paid). >> Hereafter I >> > will use the term "variant" rather than "configuration" to be precise. >> See >> > this write-up on build variants: >> > >> > https://developer.android.com/studio/build/build-variants.ht >> ml#build-types >> > >> > This build matrix is constructed at the leaf build.gradle level. Native >> > build in gradle allows you to set C/C++ flags individually for each >> variant >> > so that you can define compiler flags (for example, -DFREE_VERSION). >> > >> > One thing to notice at this stage is that the same CMake target may be >> built >> > with different compiler flags across different projects, build types, >> and >> > product flavors. So in the general case, build outputs won't be the >> same. >> > >> > You asked which targets build when specifying path. By default, we >> build all >> > targets that produce an .so. You can override this by setting >> > externalNativeBuild.cmake.targets. For example, >> > >> > paid { >> > ... >> > externalNativeBuild { >> > cmake { >> > ... >> > targets "native-lib-paid" >> > } >> > } >> > } >> > >> > As for your last question, the model we generally see used is that the >> main >> > CMakeLists.txt is next to the leaf build.gradle such that this >> > CMakeLists.txt doesn't couple with peer APK project CMakeLists.txt >> (though >> > they may share common dependencies and settings). Otherwise, multiple >> APK >> > projects would perform pretty much similar to yours--they would build >> > targets per-leaf project and not share build outputs. As far as I can >> see >> > your organization is just as valid so long as you only build the >> targets you >> > need. >> > >> > Regarding native dependencies between java projects. We generally try to >> > avoid making the CMake build depend on the gradle build (you should be >> able >> > to replicate the CMake build from the command-line if you set the right >> > flags). At the moment I don't see a way we could make things better >> without >> > violating that tenet but that could be lack of imagination on my part. >> > >> > We'll definitely be discussing this use case at our next C++ meeting and >> > I'll also be checking for myself whether ccache will work in this CMake >> > scenario. If ccache does work it seems like the natural level at which >> to >> > fold identical builds. >> > >> > >> > >> > On Wed, Aug 23, 2017 at 1:03 PM, Robert Dailey < >> rcdailey.lists at gmail.com> >> > wrote: >> >> >> >> I'm not sure what you mean by "gradle module projects", but maybe >> >> having some examples of what you mean by "configurations, C++ flags, >> >> etc" might make it more clear. >> >> >> >> Question: When specifying "path" for the CMakeLists.txt in the >> >> build.gradle file, how do you know which targets to build? For >> >> example, that run of CMake may generate 100 targets, but only 20 need >> >> to build and be packaged (*.so files) with the APK. Do you just build >> >> "all"? Is there a way to specify the target itself? >> >> >> >> Thanks again. I'd still like to know more about what the ideal >> >> organization is. I find it hard to believe that large android projects >> >> rarely break things up into multiple, separate "components" that are >> >> built independently. That's really the gist of what we're dealing with >> >> here. Your typical "hello world" project likely will have only 1 >> >> CMakeLists.txt that is pretty self-contained, but all the >> >> documentation I've looked at so far doesn't show the best way to >> >> handle native library dependencies across java projects between >> >> build.gradle files (or maybe I'm just not looking hard enough). >> >> >> >> On Wed, Aug 23, 2017 at 1:02 PM, Jom O'Fisher >> >> wrote: >> >> > Thanks for the write-up Robert. Having thought about it, I don't >> believe >> >> > we >> >> > have a satisfying answer at the gradle level for this kind of >> >> > organization. >> >> > In the gradle model module projects are the unit of organization for >> >> > configurations, C/C++ flags, etc. and that's something we're pretty >> much >> >> > stuck with. >> >> > Regarding just the redundant build issue, would something like ccache >> >> > help? >> >> > I know people have used it with ndk-build with success, I'm not sure >> >> > about >> >> > CMake but I don't see why that should make a difference. >> >> > >> >> > >> >> > >> >> > On Tue, Aug 22, 2017 at 10:27 AM, Robert Dailey >> >> > >> >> > wrote: >> >> >> >> >> >> Another reason to reduce the number of binary directories is that >> >> >> there are different ways of managing third party libraries. One in >> >> >> particular that we use is to clone a repository into the binary >> >> >> directory and build all third party libs in real time based on a >> >> >> toolchain file (Similar to the functionality provided by >> >> >> ExternalProject module in CMake). This is repeated from scratch only >> >> >> if the work hasn't already been done in the binary directory before. >> >> >> By having more binary dirs than needed, this work is being done an >> >> >> exponential amount of times which can result in a lot of wasted time >> >> >> waiting. There are 1 time operations that multiple targets can >> benefit >> >> >> from in a single binary tree, instead of 1 per unique target being >> >> >> invoked. >> >> >> >> >> >> Sorry to keep responding: I'm just thinking of things as I go and >> >> >> bringing them up, to shed light on some of the reasoning behind my >> >> >> suggestions. >> >> >> >> >> >> On Tue, Aug 22, 2017 at 9:26 AM, Robert Dailey >> >> >> >> >> >> wrote: >> >> >> > Sorry I forgot to answer your last set of questions: >> >> >> > >> >> >> > CommonLib is indeed 2 things: >> >> >> > >> >> >> > * A common (static or shared) library for native code (most of our >> >> >> > CMake targets specify CommonLib as a link dependency) >> >> >> > * A common library for Java code (we do specify this as a >> dependency >> >> >> > for most java targets in Gradle, specifically those under >> >> >> > Applications/) >> >> >> > >> >> >> > On Mon, Aug 21, 2017 at 6:20 PM, Raymond Chiu >> >> >> > wrote: >> >> >> >> Hi Robert, >> >> >> >> >> >> >> >> I work with Jom on the Android Studio team, and I would like to >> >> >> >> clarify >> >> >> >> a >> >> >> >> few things to better understand your situation. >> >> >> >> You mentioned the project is intend to be cross platform. >> Normally, >> >> >> >> in >> >> >> >> such >> >> >> >> situation, we expect there to be a single CMake root project to >> be >> >> >> >> imported >> >> >> >> into one of the Android library/application. However, in your >> case, >> >> >> >> there >> >> >> >> are subprojects with Java code. >> >> >> >> >> >> >> >> Are the CMake code in App1/2/3 intended to be cross platform too? >> >> >> >> Or >> >> >> >> are >> >> >> >> they Android specific code? If they are meant to be cross >> platform, >> >> >> >> how >> >> >> >> does the Java code works on other platforms? Or perhaps you >> added >> >> >> >> Java >> >> >> >> binding in those subprojects just for Android? >> >> >> >> >> >> >> >> The build.gradle in CommonLib, what kind of Gradle project is >> that? >> >> >> >> From >> >> >> >> your description, it doesn't look like an Android library >> project. >> >> >> >> Or >> >> >> >> am I >> >> >> >> mistaken and it also applies the android library plugin? >> >> >> >> >> >> >> >> Raymond >> >> >> >> >> >> >> >> On Mon, Aug 21, 2017 at 3:34 PM, Jom O'Fisher < >> jomofisher at gmail.com> >> >> >> >> wrote: >> >> >> >>> >> >> >> >>> + a colleague >> >> >> >>> >> >> >> >>> On Mon, Aug 21, 2017 at 3:11 PM, Jom O'Fisher >> >> >> >>> >> >> >> >>> wrote: >> >> >> >>>> >> >> >> >>>> You can find that number like this: >> >> >> >>>> - x = number of externalNativeBuild.cmake.path in your >> >> >> >>>> build.gradle >> >> >> >>>> files >> >> >> >>>> - y = number of gradle configurations (like debug and release) >> >> >> >>>> - z = number of ABIs that you build >> >> >> >>>> >> >> >> >>>> The result is x * y * z. To be more accurate, you should >> consider >> >> >> >>>> y >> >> >> >>>> and z >> >> >> >>>> to be functions of each build.gradle file since these can vary. >> >> >> >>>> >> >> >> >>>> There is a second set of folders that hold the stripped >> versions >> >> >> >>>> of >> >> >> >>>> the >> >> >> >>>> .so files that is purely managed by the android gradle plugin, >> so >> >> >> >>>> you >> >> >> >>>> might >> >> >> >>>> consider the answer to be 2 * x * y * z. >> >> >> >>>> >> >> >> >>>> Hope this helps. >> >> >> >>>> >> >> >> >>>> >> >> >> >>>> >> >> >> >>>> >> >> >> >>>> >> >> >> >>>> >> >> >> >>>> On Mon, Aug 21, 2017 at 2:41 PM, Robert Dailey >> >> >> >>>> >> >> >> >>>> wrote: >> >> >> >>>>> >> >> >> >>>>> This definitely a bit better, but still requires the >> boilerplate >> >> >> >>>>> in >> >> >> >>>>> each leaf gradle file. But I can't seriously complain too >> much. I >> >> >> >>>>> think I'm more concerned with the implications this has >> >> >> >>>>> underneath. >> >> >> >>>>> First, let me ask just to make sure I'm not misunderstanding: >> >> >> >>>>> Does >> >> >> >>>>> each `externalNativeBuild` entry essentially mean 1 >> >> >> >>>>> CMAKE_BINARY_DIR? >> >> >> >>>>> How many binary dirs do you manage internally and what >> determines >> >> >> >>>>> when >> >> >> >>>>> they get created? >> >> >> >>>>> >> >> >> >>>>> On Mon, Aug 21, 2017 at 2:35 PM, Jom O'Fisher >> >> >> >>>>> >> >> >> >>>>> wrote: >> >> >> >>>>> > Would it work for your scenario to provide properties in the >> >> >> >>>>> > root >> >> >> >>>>> > build.gradle: >> >> >> >>>>> > >> >> >> >>>>> > ext { >> >> >> >>>>> > cmakePath = file "CMakeLists.txt" >> >> >> >>>>> > } >> >> >> >>>>> > >> >> >> >>>>> > And then consume them in the leaf app/build.gradle like >> this? >> >> >> >>>>> > >> >> >> >>>>> > externalNativeBuild { >> >> >> >>>>> > cmake { >> >> >> >>>>> > path cmakePath >> >> >> >>>>> > } >> >> >> >>>>> > } >> >> >> >>>>> > >> >> >> >>>>> > It doesn't fully hide the details but it does centralize the >> >> >> >>>>> > information. >> >> >> >>>>> > >> >> >> >>>>> > >> >> >> >>>>> > On Mon, Aug 21, 2017 at 11:20 AM, Robert Dailey >> >> >> >>>>> > >> >> >> >>>>> > wrote: >> >> >> >>>>> >> >> >> >> >>>>> >> I wouldn't want to do that, it's too convoluted. I have >> other >> >> >> >>>>> >> platforms that use these CMake scripts as well. For >> example, I >> >> >> >>>>> >> run on >> >> >> >>>>> >> Windows and Linux platforms as well to build the native >> code. >> >> >> >>>>> >> Normal >> >> >> >>>>> >> CMake behavior is designed to work at a root then go >> downwards >> >> >> >>>>> >> to >> >> >> >>>>> >> find >> >> >> >>>>> >> targets. However it seems Gradle wants to start at a >> >> >> >>>>> >> subdirectory >> >> >> >>>>> >> and >> >> >> >>>>> >> work its way up to the root, which is opposite of CMake's >> >> >> >>>>> >> intended >> >> >> >>>>> >> behavior IMHO. Not only that but I want to avoid >> >> >> >>>>> >> special-casing >> >> >> >>>>> >> behavior in CMake just for Android's use. >> >> >> >>>>> >> >> >> >> >>>>> >> At the moment it feels like (again referring back to my >> >> >> >>>>> >> previous >> >> >> >>>>> >> example structure) that both App2 and App3 each run CMake >> in >> >> >> >>>>> >> independent binary directories instead of sharing 1 binary >> >> >> >>>>> >> directory >> >> >> >>>>> >> and building 2 targets inside of it. I prefer this behavior >> >> >> >>>>> >> instead, >> >> >> >>>>> >> especially since it allows CMake to operate as it was >> >> >> >>>>> >> intended. I >> >> >> >>>>> >> think it's a common case that projects will define multiple >> >> >> >>>>> >> targets >> >> >> >>>>> >> starting from a single root, and expect multiple APKs or >> java >> >> >> >>>>> >> dependencies to be built within it. >> >> >> >>>>> >> >> >> >> >>>>> >> If I'm misunderstanding or making false assumptions please >> let >> >> >> >>>>> >> me >> >> >> >>>>> >> know. >> >> >> >>>>> >> >> >> >> >>>>> >> >> >> >> >>>>> >> >> >> >> >>>>> >> On Mon, Aug 21, 2017 at 12:00 PM, Jom O'Fisher >> >> >> >>>>> >> >> >> >> >>>>> >> wrote: >> >> >> >>>>> >> > Would it work for your situation for the leaf >> CMakeLists.txt >> >> >> >>>>> >> > to >> >> >> >>>>> >> > include >> >> >> >>>>> >> > the >> >> >> >>>>> >> > root CMakeLists.txt? Then have the leaf-specific logic in >> >> >> >>>>> >> > the >> >> >> >>>>> >> > leaf >> >> >> >>>>> >> > CMakeLists.txt? >> >> >> >>>>> >> > >> >> >> >>>>> >> > >> >> >> >>>>> >> > >> >> >> >>>>> >> > On Mon, Aug 21, 2017 at 9:33 AM, Robert Dailey >> >> >> >>>>> >> > >> >> >> >>>>> >> > wrote: >> >> >> >>>>> >> >> >> >> >> >>>>> >> >> Basically, yes. We have this sort of structure: >> >> >> >>>>> >> >> >> >> >> >>>>> >> >> / >> >> >> >>>>> >> >> Applications/ >> >> >> >>>>> >> >> App1/ >> >> >> >>>>> >> >> build.gradle >> >> >> >>>>> >> >> CMakeLists.txt >> >> >> >>>>> >> >> App2/ >> >> >> >>>>> >> >> build.gradle >> >> >> >>>>> >> >> CMakeLists.txt >> >> >> >>>>> >> >> App3/ >> >> >> >>>>> >> >> build.gradle >> >> >> >>>>> >> >> CMakeLists.txt >> >> >> >>>>> >> >> CommonLib/ >> >> >> >>>>> >> >> build.gradle >> >> >> >>>>> >> >> CMakeLists.txt >> >> >> >>>>> >> >> CMakeLists.txt >> >> >> >>>>> >> >> >> >> >> >>>>> >> >> The libs are defined as follows: >> >> >> >>>>> >> >> >> >> >> >>>>> >> >> * CommonLib is a static library (java code builds into a >> >> >> >>>>> >> >> library) >> >> >> >>>>> >> >> * No dependencies of its own >> >> >> >>>>> >> >> * App1 is a shared library (java code builds into a >> >> >> >>>>> >> >> library) >> >> >> >>>>> >> >> * Dependencies (both java & native): CommonLib >> >> >> >>>>> >> >> * App2 is a shared library (java code builds into an >> APK) >> >> >> >>>>> >> >> * Dependencies (both java & native): App1, CommonLib >> >> >> >>>>> >> >> * App3 is a shared library (java code builds into an >> APK) >> >> >> >>>>> >> >> * Dependencies (both java & native): CommonLib >> >> >> >>>>> >> >> >> >> >> >>>>> >> >> In all cases, CMake must be invoked starting at the root >> >> >> >>>>> >> >> CMakeLists.txt 1 time. Each target can be built from the >> >> >> >>>>> >> >> same >> >> >> >>>>> >> >> binary >> >> >> >>>>> >> >> directory after that. Previously with ANT, I was >> building >> >> >> >>>>> >> >> all >> >> >> >>>>> >> >> native >> >> >> >>>>> >> >> targets first, then moved libs to appropriate >> directories >> >> >> >>>>> >> >> so >> >> >> >>>>> >> >> that >> >> >> >>>>> >> >> the >> >> >> >>>>> >> >> 'ant' command would package the libs. >> >> >> >>>>> >> >> >> >> >> >>>>> >> >> For gradle, I wanted to avoid redundantly specifying the >> >> >> >>>>> >> >> root >> >> >> >>>>> >> >> directory in each leaf-level project directory. Using >> the >> >> >> >>>>> >> >> example >> >> >> >>>>> >> >> above, the leaf-level directories in this case would be >> >> >> >>>>> >> >> App1, >> >> >> >>>>> >> >> App2, >> >> >> >>>>> >> >> App3, and CommonLib. However I think we only specify the >> >> >> >>>>> >> >> native >> >> >> >>>>> >> >> CMake >> >> >> >>>>> >> >> stuff for the java targets that actually output an APK >> >> >> >>>>> >> >> (that >> >> >> >>>>> >> >> would >> >> >> >>>>> >> >> be >> >> >> >>>>> >> >> App2 and App3 only). >> >> >> >>>>> >> >> >> >> >> >>>>> >> >> The ultimate goal is to specify stuff that doesn't >> change >> >> >> >>>>> >> >> per >> >> >> >>>>> >> >> independent "module" of ours at the top level so it is >> >> >> >>>>> >> >> transitive >> >> >> >>>>> >> >> / >> >> >> >>>>> >> >> inherited. Then only specify the differences (e.g. the >> >> >> >>>>> >> >> native >> >> >> >>>>> >> >> CMake >> >> >> >>>>> >> >> target to build) in the leaf build gradle files. However >> >> >> >>>>> >> >> you >> >> >> >>>>> >> >> indicated >> >> >> >>>>> >> >> this isn't possible. >> >> >> >>>>> >> >> >> >> >> >>>>> >> >> >> >> >> >>>>> >> >> >> >> >> >>>>> >> >> On Mon, Aug 21, 2017 at 11:11 AM, Jom O'Fisher >> >> >> >>>>> >> >> >> >> >> >>>>> >> >> wrote: >> >> >> >>>>> >> >> > What you're doing already sounds correct. You can't >> >> >> >>>>> >> >> > directly >> >> >> >>>>> >> >> > specify >> >> >> >>>>> >> >> > CMakeLists.txt from the top-level build.gradle. >> >> >> >>>>> >> >> > Recommendation >> >> >> >>>>> >> >> > is >> >> >> >>>>> >> >> > that >> >> >> >>>>> >> >> > it >> >> >> >>>>> >> >> > should be specified from the build.gradle of the >> module >> >> >> >>>>> >> >> > of >> >> >> >>>>> >> >> > the >> >> >> >>>>> >> >> > APK. >> >> >> >>>>> >> >> > Is >> >> >> >>>>> >> >> > the >> >> >> >>>>> >> >> > issue that you have multiple APK modules that all >> >> >> >>>>> >> >> > reference >> >> >> >>>>> >> >> > the >> >> >> >>>>> >> >> > same >> >> >> >>>>> >> >> > CMake >> >> >> >>>>> >> >> > libraries? >> >> >> >>>>> >> >> > >> >> >> >>>>> >> >> > On Mon, Aug 21, 2017 at 9:00 AM, Robert Dailey >> >> >> >>>>> >> >> > >> >> >> >>>>> >> >> > wrote: >> >> >> >>>>> >> >> >> >> >> >> >>>>> >> >> >> Thanks this is very helpful. The other question I >> have >> >> >> >>>>> >> >> >> is: >> >> >> >>>>> >> >> >> Is >> >> >> >>>>> >> >> >> there >> >> >> >>>>> >> >> >> a >> >> >> >>>>> >> >> >> place to centrally specify the root CMakeLists.txt? >> >> >> >>>>> >> >> >> Basically, >> >> >> >>>>> >> >> >> I >> >> >> >>>>> >> >> >> want >> >> >> >>>>> >> >> >> to specify the CMake root in 1 place, and have >> targets >> >> >> >>>>> >> >> >> (defined >> >> >> >>>>> >> >> >> further down in subdirectories) that require APK >> >> >> >>>>> >> >> >> packaging >> >> >> >>>>> >> >> >> to >> >> >> >>>>> >> >> >> specify >> >> >> >>>>> >> >> >> only the native target name that should be built & >> >> >> >>>>> >> >> >> packaged. >> >> >> >>>>> >> >> >> >> >> >> >>>>> >> >> >> At the moment we specify the root CMakeLists.txt by >> >> >> >>>>> >> >> >> walking >> >> >> >>>>> >> >> >> up >> >> >> >>>>> >> >> >> the >> >> >> >>>>> >> >> >> tree, paths like "../../../../CMakeLists.txt". I >> think >> >> >> >>>>> >> >> >> this >> >> >> >>>>> >> >> >> should >> >> >> >>>>> >> >> >> be >> >> >> >>>>> >> >> >> put at the top-level build gradle file if possible. >> Is >> >> >> >>>>> >> >> >> this >> >> >> >>>>> >> >> >> doable >> >> >> >>>>> >> >> >> at >> >> >> >>>>> >> >> >> the moment? What is the recommended setup? >> >> >> >>>>> >> >> >> >> >> >> >>>>> >> >> >> On Mon, Aug 21, 2017 at 9:37 AM, Jom O'Fisher >> >> >> >>>>> >> >> >> >> >> >> >>>>> >> >> >> wrote: >> >> >> >>>>> >> >> >> > Gradle does introspection on the CMake build to >> find >> >> >> >>>>> >> >> >> > .so >> >> >> >>>>> >> >> >> > targets >> >> >> >>>>> >> >> >> > and >> >> >> >>>>> >> >> >> > those >> >> >> >>>>> >> >> >> > get packaged. >> >> >> >>>>> >> >> >> > There is also a special case for stl/runtime .so >> files >> >> >> >>>>> >> >> >> > from >> >> >> >>>>> >> >> >> > the >> >> >> >>>>> >> >> >> > NDK. >> >> >> >>>>> >> >> >> > Any additional .so files need to specified in >> >> >> >>>>> >> >> >> > build.gradle >> >> >> >>>>> >> >> >> > using >> >> >> >>>>> >> >> >> > jniDirs >> >> >> >>>>> >> >> >> > >> >> >> >>>>> >> >> >> > On Mon, Aug 21, 2017 at 7:30 AM, Robert Dailey >> >> >> >>>>> >> >> >> > >> >> >> >>>>> >> >> >> > wrote: >> >> >> >>>>> >> >> >> >> >> >> >> >>>>> >> >> >> >> How exactly does Gradle package *.so files in an >> APK? >> >> >> >>>>> >> >> >> >> I >> >> >> >>>>> >> >> >> >> know >> >> >> >>>>> >> >> >> >> that >> >> >> >>>>> >> >> >> >> ANT >> >> >> >>>>> >> >> >> >> used to do this for any libs under "libs/". >> Does >> >> >> >>>>> >> >> >> >> Gradle >> >> >> >>>>> >> >> >> >> do >> >> >> >>>>> >> >> >> >> some >> >> >> >>>>> >> >> >> >> introspection into CMake targets to see if outputs >> >> >> >>>>> >> >> >> >> are >> >> >> >>>>> >> >> >> >> *.so, >> >> >> >>>>> >> >> >> >> and >> >> >> >>>>> >> >> >> >> copy >> >> >> >>>>> >> >> >> >> those to some location if needed? What about >> >> >> >>>>> >> >> >> >> libraries >> >> >> >>>>> >> >> >> >> like >> >> >> >>>>> >> >> >> >> libgnustl_shared.so that come with the NDK? I'd >> like >> >> >> >>>>> >> >> >> >> to >> >> >> >>>>> >> >> >> >> know >> >> >> >>>>> >> >> >> >> if >> >> >> >>>>> >> >> >> >> any >> >> >> >>>>> >> >> >> >> manual copy steps are needed in CMake to put >> outputs >> >> >> >>>>> >> >> >> >> in >> >> >> >>>>> >> >> >> >> proper >> >> >> >>>>> >> >> >> >> locations for the APK build step. I had to do this >> >> >> >>>>> >> >> >> >> when >> >> >> >>>>> >> >> >> >> using >> >> >> >>>>> >> >> >> >> ANT. >> >> >> >>>>> >> >> >> >> >> >> >> >>>>> >> >> >> >> On Mon, Aug 7, 2017 at 6:16 PM, Jom O'Fisher >> >> >> >>>>> >> >> >> >> >> >> >> >>>>> >> >> >> >> wrote: >> >> >> >>>>> >> >> >> >> > 1) There is a folder created for each ABI under >> the >> >> >> >>>>> >> >> >> >> > project >> >> >> >>>>> >> >> >> >> > module >> >> >> >>>>> >> >> >> >> > folder >> >> >> >>>>> >> >> >> >> > (so unique per module per ABI) >> >> >> >>>>> >> >> >> >> > 2) Gradle doesn't specify language level though >> you >> >> >> >>>>> >> >> >> >> > can >> >> >> >>>>> >> >> >> >> > choose >> >> >> >>>>> >> >> >> >> > to >> >> >> >>>>> >> >> >> >> > specify it >> >> >> >>>>> >> >> >> >> > yourself from the build.gradle. This doc does a >> >> >> >>>>> >> >> >> >> > pretty >> >> >> >>>>> >> >> >> >> > good job >> >> >> >>>>> >> >> >> >> > of >> >> >> >>>>> >> >> >> >> > explaining which variables are set by Gradle: >> >> >> >>>>> >> >> >> >> > >> >> >> >>>>> >> >> >> >> > >> >> >> >>>>> >> >> >> >> > >> >> >> >>>>> >> >> >> >> > https://developer.android.com/ >> ndk/guides/cmake.html#variables. >> >> >> >>>>> >> >> >> >> > Philosophically, we try to set as little as we >> can >> >> >> >>>>> >> >> >> >> > get >> >> >> >>>>> >> >> >> >> > away >> >> >> >>>>> >> >> >> >> > with. >> >> >> >>>>> >> >> >> >> > In >> >> >> >>>>> >> >> >> >> > particular, the section titled "Understanding >> the >> >> >> >>>>> >> >> >> >> > CMake >> >> >> >>>>> >> >> >> >> > build >> >> >> >>>>> >> >> >> >> > command" >> >> >> >>>>> >> >> >> >> > lays >> >> >> >>>>> >> >> >> >> > out exactly what we set. You can also see the >> >> >> >>>>> >> >> >> >> > folders >> >> >> >>>>> >> >> >> >> > we >> >> >> >>>>> >> >> >> >> > specify >> >> >> >>>>> >> >> >> >> > (one >> >> >> >>>>> >> >> >> >> > per >> >> >> >>>>> >> >> >> >> > module per ABI) >> >> >> >>>>> >> >> >> >> > 3) Not sure I understand this. >> >> >> >>>>> >> >> >> >> > >> >> >> >>>>> >> >> >> >> > The other document worth taking a look at (if >> you >> >> >> >>>>> >> >> >> >> > haven't >> >> >> >>>>> >> >> >> >> > already) >> >> >> >>>>> >> >> >> >> > is: >> >> >> >>>>> >> >> >> >> > >> >> >> >>>>> >> >> >> >> > >> >> >> >>>>> >> >> >> >> > >> >> >> >>>>> >> >> >> >> > >> >> >> >>>>> >> >> >> >> > https://developer.android.com/ >> studio/projects/add-native-code.html >> >> >> >>>>> >> >> >> >> > >> >> >> >>>>> >> >> >> >> > >> >> >> >>>>> >> >> >> >> > On Mon, Aug 7, 2017 at 3:35 PM, Robert Dailey >> >> >> >>>>> >> >> >> >> > >> >> >> >>>>> >> >> >> >> > wrote: >> >> >> >>>>> >> >> >> >> >> >> >> >> >>>>> >> >> >> >> >> Thanks Jom >> >> >> >>>>> >> >> >> >> >> >> >> >> >>>>> >> >> >> >> >> Honestly, I prefer option 1 to work simply >> because >> >> >> >>>>> >> >> >> >> >> that's >> >> >> >>>>> >> >> >> >> >> how >> >> >> >>>>> >> >> >> >> >> Google's >> >> >> >>>>> >> >> >> >> >> officially supporting CMake. But it also has >> >> >> >>>>> >> >> >> >> >> debugging >> >> >> >>>>> >> >> >> >> >> which >> >> >> >>>>> >> >> >> >> >> is >> >> >> >>>>> >> >> >> >> >> the >> >> >> >>>>> >> >> >> >> >> #1 >> >> >> >>>>> >> >> >> >> >> reason for me. >> >> >> >>>>> >> >> >> >> >> >> >> >> >>>>> >> >> >> >> >> However, I'd like to understand a lot more >> about >> >> >> >>>>> >> >> >> >> >> how >> >> >> >>>>> >> >> >> >> >> the >> >> >> >>>>> >> >> >> >> >> integration >> >> >> >>>>> >> >> >> >> >> really happens. For example, I have these >> >> >> >>>>> >> >> >> >> >> questions: >> >> >> >>>>> >> >> >> >> >> >> >> >> >>>>> >> >> >> >> >> 1) How, internally, are CMake build directories >> >> >> >>>>> >> >> >> >> >> managed? >> >> >> >>>>> >> >> >> >> >> Do >> >> >> >>>>> >> >> >> >> >> you >> >> >> >>>>> >> >> >> >> >> generate 1 per unique android project? What >> about >> >> >> >>>>> >> >> >> >> >> for >> >> >> >>>>> >> >> >> >> >> each >> >> >> >>>>> >> >> >> >> >> specific >> >> >> >>>>> >> >> >> >> >> platform (x86, armeabi-v7a, etc)? >> >> >> >>>>> >> >> >> >> >> 2) Last time I looked into CMake integration, >> >> >> >>>>> >> >> >> >> >> things >> >> >> >>>>> >> >> >> >> >> defined >> >> >> >>>>> >> >> >> >> >> inside >> >> >> >>>>> >> >> >> >> >> the CMake scripts were ignored because they are >> >> >> >>>>> >> >> >> >> >> specified >> >> >> >>>>> >> >> >> >> >> at >> >> >> >>>>> >> >> >> >> >> the >> >> >> >>>>> >> >> >> >> >> command line. Namely, all of those settings >> that >> >> >> >>>>> >> >> >> >> >> are >> >> >> >>>>> >> >> >> >> >> driven by >> >> >> >>>>> >> >> >> >> >> the >> >> >> >>>>> >> >> >> >> >> Gradle configuration (CXX language level was >> one >> >> >> >>>>> >> >> >> >> >> in >> >> >> >>>>> >> >> >> >> >> particular >> >> >> >>>>> >> >> >> >> >> I >> >> >> >>>>> >> >> >> >> >> think; I specify C++14 support via CMake, but I >> >> >> >>>>> >> >> >> >> >> recall >> >> >> >>>>> >> >> >> >> >> this >> >> >> >>>>> >> >> >> >> >> being >> >> >> >>>>> >> >> >> >> >> overridden from outside)? >> >> >> >>>>> >> >> >> >> >> 3) How redundant is it to configure individual >> >> >> >>>>> >> >> >> >> >> libraries >> >> >> >>>>> >> >> >> >> >> via >> >> >> >>>>> >> >> >> >> >> the >> >> >> >>>>> >> >> >> >> >> gradle scripts? In my previous attempts, I >> wanted >> >> >> >>>>> >> >> >> >> >> to >> >> >> >>>>> >> >> >> >> >> define >> >> >> >>>>> >> >> >> >> >> common >> >> >> >>>>> >> >> >> >> >> stuff for CMake / native code at the root >> gradle >> >> >> >>>>> >> >> >> >> >> or >> >> >> >>>>> >> >> >> >> >> settings >> >> >> >>>>> >> >> >> >> >> file, >> >> >> >>>>> >> >> >> >> >> and >> >> >> >>>>> >> >> >> >> >> only define the differences in the actual >> gradle >> >> >> >>>>> >> >> >> >> >> build >> >> >> >>>>> >> >> >> >> >> files >> >> >> >>>>> >> >> >> >> >> for >> >> >> >>>>> >> >> >> >> >> each >> >> >> >>>>> >> >> >> >> >> corresponding Java target (like, defining the >> name >> >> >> >>>>> >> >> >> >> >> of >> >> >> >>>>> >> >> >> >> >> the >> >> >> >>>>> >> >> >> >> >> native >> >> >> >>>>> >> >> >> >> >> (shared library) target in Gradle, but the >> command >> >> >> >>>>> >> >> >> >> >> line >> >> >> >>>>> >> >> >> >> >> invocation, >> >> >> >>>>> >> >> >> >> >> -D >> >> >> >>>>> >> >> >> >> >> CMake settings, etc would all be common and >> >> >> >>>>> >> >> >> >> >> defined >> >> >> >>>>> >> >> >> >> >> at >> >> >> >>>>> >> >> >> >> >> the >> >> >> >>>>> >> >> >> >> >> root). >> >> >> >>>>> >> >> >> >> >> >> >> >> >>>>> >> >> >> >> >> The TLDR is, the closer we can stay to CMake's >> way >> >> >> >>>>> >> >> >> >> >> of >> >> >> >>>>> >> >> >> >> >> doing >> >> >> >>>>> >> >> >> >> >> things >> >> >> >>>>> >> >> >> >> >> and >> >> >> >>>>> >> >> >> >> >> keep CMake-related settings self-contained to >> the >> >> >> >>>>> >> >> >> >> >> CMake >> >> >> >>>>> >> >> >> >> >> scripts >> >> >> >>>>> >> >> >> >> >> themselves, the better. This also makes >> >> >> >>>>> >> >> >> >> >> cross-platform >> >> >> >>>>> >> >> >> >> >> easier >> >> >> >>>>> >> >> >> >> >> (we >> >> >> >>>>> >> >> >> >> >> build the native code in Windows, for example, >> so >> >> >> >>>>> >> >> >> >> >> having >> >> >> >>>>> >> >> >> >> >> settings >> >> >> >>>>> >> >> >> >> >> specified in the gradle files do not carry >> over to >> >> >> >>>>> >> >> >> >> >> other >> >> >> >>>>> >> >> >> >> >> platforms. >> >> >> >>>>> >> >> >> >> >> Namely, settings that are not platform specific >> >> >> >>>>> >> >> >> >> >> like >> >> >> >>>>> >> >> >> >> >> the >> >> >> >>>>> >> >> >> >> >> C++ >> >> >> >>>>> >> >> >> >> >> language >> >> >> >>>>> >> >> >> >> >> level). >> >> >> >>>>> >> >> >> >> >> >> >> >> >>>>> >> >> >> >> >> If there's a detailed document / wiki I can >> read >> >> >> >>>>> >> >> >> >> >> on >> >> >> >>>>> >> >> >> >> >> the >> >> >> >>>>> >> >> >> >> >> intrinsics >> >> >> >>>>> >> >> >> >> >> of >> >> >> >>>>> >> >> >> >> >> CMake integration in Gradle / Android Studio, >> I'd >> >> >> >>>>> >> >> >> >> >> love to >> >> >> >>>>> >> >> >> >> >> read >> >> >> >>>>> >> >> >> >> >> it. >> >> >> >>>>> >> >> >> >> >> Otherwise, I hope you won't mind if I pick your >> >> >> >>>>> >> >> >> >> >> brain >> >> >> >>>>> >> >> >> >> >> as >> >> >> >>>>> >> >> >> >> >> questions >> >> >> >>>>> >> >> >> >> >> come up. I think I'm going to try option 1 for >> now >> >> >> >>>>> >> >> >> >> >> and >> >> >> >>>>> >> >> >> >> >> see how >> >> >> >>>>> >> >> >> >> >> it >> >> >> >>>>> >> >> >> >> >> goes. It's just black box for me because unlike >> >> >> >>>>> >> >> >> >> >> option 2, >> >> >> >>>>> >> >> >> >> >> I >> >> >> >>>>> >> >> >> >> >> have >> >> >> >>>>> >> >> >> >> >> very >> >> >> >>>>> >> >> >> >> >> little control over what happens after building >> >> >> >>>>> >> >> >> >> >> the >> >> >> >>>>> >> >> >> >> >> shared >> >> >> >>>>> >> >> >> >> >> libraries, >> >> >> >>>>> >> >> >> >> >> and to make up for that I need to really get a >> >> >> >>>>> >> >> >> >> >> deep >> >> >> >>>>> >> >> >> >> >> understanding >> >> >> >>>>> >> >> >> >> >> of >> >> >> >>>>> >> >> >> >> >> how it works so I can make sure I code my CMake >> >> >> >>>>> >> >> >> >> >> scripts >> >> >> >>>>> >> >> >> >> >> properly >> >> >> >>>>> >> >> >> >> >> for >> >> >> >>>>> >> >> >> >> >> not only Android, but my other platforms as >> well >> >> >> >>>>> >> >> >> >> >> (non-Android >> >> >> >>>>> >> >> >> >> >> platforms). >> >> >> >>>>> >> >> >> >> >> >> >> >> >>>>> >> >> >> >> >> Thanks again. >> >> >> >>>>> >> >> >> >> >> >> >> >> >>>>> >> >> >> >> >> On Mon, Aug 7, 2017 at 5:12 PM, Jom O'Fisher >> >> >> >>>>> >> >> >> >> >> >> >> >> >>>>> >> >> >> >> >> wrote: >> >> >> >>>>> >> >> >> >> >> > Either option can work fine. Disclosure: I >> work >> >> >> >>>>> >> >> >> >> >> > on >> >> >> >>>>> >> >> >> >> >> > Android >> >> >> >>>>> >> >> >> >> >> > Studio >> >> >> >>>>> >> >> >> >> >> > and >> >> >> >>>>> >> >> >> >> >> > was >> >> >> >>>>> >> >> >> >> >> > the one that added CMake support. >> >> >> >>>>> >> >> >> >> >> > >> >> >> >>>>> >> >> >> >> >> > Option (1) is the way it's designed to work >> and >> >> >> >>>>> >> >> >> >> >> > we're >> >> >> >>>>> >> >> >> >> >> > working >> >> >> >>>>> >> >> >> >> >> > toward >> >> >> >>>>> >> >> >> >> >> > getting >> >> >> >>>>> >> >> >> >> >> > rid of the need for the CMake fork. I can't >> >> >> >>>>> >> >> >> >> >> > really >> >> >> >>>>> >> >> >> >> >> > say >> >> >> >>>>> >> >> >> >> >> > when >> >> >> >>>>> >> >> >> >> >> > that >> >> >> >>>>> >> >> >> >> >> > will >> >> >> >>>>> >> >> >> >> >> > happen >> >> >> >>>>> >> >> >> >> >> > but if you can get away with an older CMake >> for >> >> >> >>>>> >> >> >> >> >> > now >> >> >> >>>>> >> >> >> >> >> > then I'd >> >> >> >>>>> >> >> >> >> >> > go >> >> >> >>>>> >> >> >> >> >> > this >> >> >> >>>>> >> >> >> >> >> > way. >> >> >> >>>>> >> >> >> >> >> > As you mentioned, option (1) will allow you >> to >> >> >> >>>>> >> >> >> >> >> > view >> >> >> >>>>> >> >> >> >> >> > your >> >> >> >>>>> >> >> >> >> >> > source >> >> >> >>>>> >> >> >> >> >> > file >> >> >> >>>>> >> >> >> >> >> > structure in Android Studio, edit files, and >> >> >> >>>>> >> >> >> >> >> > debug >> >> >> >>>>> >> >> >> >> >> > using the >> >> >> >>>>> >> >> >> >> >> > built-in >> >> >> >>>>> >> >> >> >> >> > debugging support. >> >> >> >>>>> >> >> >> >> >> > >> >> >> >>>>> >> >> >> >> >> > To get option (2) to work, you can use >> jniDirs >> >> >> >>>>> >> >> >> >> >> > setting >> >> >> >>>>> >> >> >> >> >> > to >> >> >> >>>>> >> >> >> >> >> > tell >> >> >> >>>>> >> >> >> >> >> > Android >> >> >> >>>>> >> >> >> >> >> > Gradle where to pick up your built .so files >> >> >> >>>>> >> >> >> >> >> > (see >> >> >> >>>>> >> >> >> >> >> > >> >> >> >>>>> >> >> >> >> >> > >> >> >> >>>>> >> >> >> >> >> > >> >> >> >>>>> >> >> >> >> >> > >> >> >> >>>>> >> >> >> >> >> > >> >> >> >>>>> >> >> >> >> >> > >> >> >> >>>>> >> >> >> >> >> > >> >> >> >>>>> >> >> >> >> >> > >> >> >> >>>>> >> >> >> >> >> > https://stackoverflow.com/ques >> tions/21255125/how-can-i-add-so-files-to-an-android-library >> -project-using-gradle-0-7). >> >> >> >>>>> >> >> >> >> >> > I'm not aware of any projects that use this >> >> >> >>>>> >> >> >> >> >> > approach >> >> >> >>>>> >> >> >> >> >> > but it >> >> >> >>>>> >> >> >> >> >> > should >> >> >> >>>>> >> >> >> >> >> > work >> >> >> >>>>> >> >> >> >> >> > in >> >> >> >>>>> >> >> >> >> >> > principal. >> >> >> >>>>> >> >> >> >> >> > >> >> >> >>>>> >> >> >> >> >> > I hope this helps, >> >> >> >>>>> >> >> >> >> >> > Jomo >> >> >> >>>>> >> >> >> >> >> > >> >> >> >>>>> >> >> >> >> >> > >> >> >> >>>>> >> >> >> >> >> > On Mon, Aug 7, 2017 at 11:09 AM, Robert >> Dailey >> >> >> >>>>> >> >> >> >> >> > >> >> >> >>>>> >> >> >> >> >> > wrote: >> >> >> >>>>> >> >> >> >> >> >> >> >> >> >>>>> >> >> >> >> >> >> Right now I have custom targets set to >> execute >> >> >> >>>>> >> >> >> >> >> >> the >> >> >> >>>>> >> >> >> >> >> >> "ant >> >> >> >>>>> >> >> >> >> >> >> release" >> >> >> >>>>> >> >> >> >> >> >> command after my native targets are built. >> Part >> >> >> >>>>> >> >> >> >> >> >> of >> >> >> >>>>> >> >> >> >> >> >> that >> >> >> >>>>> >> >> >> >> >> >> command >> >> >> >>>>> >> >> >> >> >> >> involves copying *.so files to the >> >> >> >>>>> >> >> >> >> >> >> libs/armeabi-v7a >> >> >> >>>>> >> >> >> >> >> >> directory >> >> >> >>>>> >> >> >> >> >> >> so >> >> >> >>>>> >> >> >> >> >> >> they >> >> >> >>>>> >> >> >> >> >> >> get packaged in an APK. >> >> >> >>>>> >> >> >> >> >> >> >> >> >> >>>>> >> >> >> >> >> >> When switching to gradle, I have two >> options: >> >> >> >>>>> >> >> >> >> >> >> >> >> >> >>>>> >> >> >> >> >> >> 1. Gradle drives CMake: This means using >> >> >> >>>>> >> >> >> >> >> >> Android >> >> >> >>>>> >> >> >> >> >> >> Studio and >> >> >> >>>>> >> >> >> >> >> >> being >> >> >> >>>>> >> >> >> >> >> >> locked down to Google's fork of CMake which >> is >> >> >> >>>>> >> >> >> >> >> >> a >> >> >> >>>>> >> >> >> >> >> >> few >> >> >> >>>>> >> >> >> >> >> >> major >> >> >> >>>>> >> >> >> >> >> >> releases >> >> >> >>>>> >> >> >> >> >> >> behind. I see that as a negative. >> >> >> >>>>> >> >> >> >> >> >> >> >> >> >>>>> >> >> >> >> >> >> 2. CMake drives Gradle: This would be the >> same >> >> >> >>>>> >> >> >> >> >> >> or >> >> >> >>>>> >> >> >> >> >> >> similar >> >> >> >>>>> >> >> >> >> >> >> to >> >> >> >>>>> >> >> >> >> >> >> what >> >> >> >>>>> >> >> >> >> >> >> I'm >> >> >> >>>>> >> >> >> >> >> >> already doing: The custom targets I have >> would >> >> >> >>>>> >> >> >> >> >> >> execute >> >> >> >>>>> >> >> >> >> >> >> gradle >> >> >> >>>>> >> >> >> >> >> >> as >> >> >> >>>>> >> >> >> >> >> >> a >> >> >> >>>>> >> >> >> >> >> >> separate build step, instead of running ant >> >> >> >>>>> >> >> >> >> >> >> commands. >> >> >> >>>>> >> >> >> >> >> >> I'm >> >> >> >>>>> >> >> >> >> >> >> not >> >> >> >>>>> >> >> >> >> >> >> too >> >> >> >>>>> >> >> >> >> >> >> familiar with Gradle, so I'm not sure how >> you >> >> >> >>>>> >> >> >> >> >> >> tell >> >> >> >>>>> >> >> >> >> >> >> it >> >> >> >>>>> >> >> >> >> >> >> where >> >> >> >>>>> >> >> >> >> >> >> your >> >> >> >>>>> >> >> >> >> >> >> shared libraries are for the APK packaging >> >> >> >>>>> >> >> >> >> >> >> steps. >> >> >> >>>>> >> >> >> >> >> >> >> >> >> >>>>> >> >> >> >> >> >> Which does everyone recommend? Is anyone >> using >> >> >> >>>>> >> >> >> >> >> >> one >> >> >> >>>>> >> >> >> >> >> >> of >> >> >> >>>>> >> >> >> >> >> >> these >> >> >> >>>>> >> >> >> >> >> >> setups >> >> >> >>>>> >> >> >> >> >> >> successfully? The downside to option 2 is >> >> >> >>>>> >> >> >> >> >> >> probably >> >> >> >>>>> >> >> >> >> >> >> no >> >> >> >>>>> >> >> >> >> >> >> on-device >> >> >> >>>>> >> >> >> >> >> >> native >> >> >> >>>>> >> >> >> >> >> >> debugging since Android Studio probably >> can't >> >> >> >>>>> >> >> >> >> >> >> handle >> >> >> >>>>> >> >> >> >> >> >> gradle >> >> >> >>>>> >> >> >> >> >> >> projects >> >> >> >>>>> >> >> >> >> >> >> without any external CMake builds set up. >> >> >> >>>>> >> >> >> >> >> >> >> >> >> >>>>> >> >> >> >> >> >> Would like some general direction & advice >> >> >> >>>>> >> >> >> >> >> >> before >> >> >> >>>>> >> >> >> >> >> >> I >> >> >> >>>>> >> >> >> >> >> >> move >> >> >> >>>>> >> >> >> >> >> >> away >> >> >> >>>>> >> >> >> >> >> >> from >> >> >> >>>>> >> >> >> >> >> >> ANT. Thanks in advance. >> >> >> >>>>> >> >> >> >> >> >> -- >> >> >> >>>>> >> >> >> >> >> >> >> >> >> >>>>> >> >> >> >> >> >> 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/opensou >> rce/opensource.html >> >> >> >>>>> >> >> >> >> >> >> >> >> >> >>>>> >> >> >> >> >> >> Follow this link to subscribe/unsubscribe: >> >> >> >>>>> >> >> >> >> >> >> >> >> >> >>>>> >> >> >> >> >> >> http://public.kitware.com/mail >> man/listinfo/cmake >> >> >> >>>>> >> >> >> >> >> > >> >> >> >>>>> >> >> >> >> >> > >> >> >> >>>>> >> >> >> >> > >> >> >> >>>>> >> >> >> >> > >> >> >> >>>>> >> >> >> > >> >> >> >>>>> >> >> >> > >> >> >> >>>>> >> >> > >> >> >> >>>>> >> >> > >> >> >> >>>>> >> > >> >> >> >>>>> >> > >> >> >> >>>>> > >> >> >> >>>>> > >> >> >> >>>> >> >> >> >>>> >> >> >> >>> >> >> >> >> >> >> > >> >> > >> > >> > >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bitminer at gmail.com Sat Aug 26 12:21:28 2017 From: bitminer at gmail.com (Brian Davis) Date: Sat, 26 Aug 2017 11:21:28 -0500 Subject: [CMake] Inherited Build Properties: Is this the intent of add_library Interface Libraries? In-Reply-To: References: Message-ID: The answer to what parameters can be specified the "whitelist" as it is refereed to is documented (thanks to Raul's help): https://cmake.org/cmake/help/v3.9/command/add_library.html?highlight=interface_#interface-libraries with these key bits: "Details about the imported library are specified by setting properties whose names begin in IMPORTED_ and INTERFACE_. The most important such property is IMPORTED_LOCATION (and its per-configuration variant IMPORTED_LOCATION_ ) which specifies the location of the main library file on disk. See documentation of the IMPORTED_* and INTERFACE_* properties for more information." Then searching https://cmake.org/cmake/help/v3.9/manual/cmake-properties.7.html?highlight=property grep'in for IMPORTED_ or INTERFACE_ yields the full white list. What I have found to be: IMPORTED_CONFIGURATIONS IMPORTED_IMPLIB_ IMPORTED_IMPLIB IMPORTED_LIBNAME_ IMPORTED_LIBNAME IMPORTED_LINK_DEPENDENT_LIBRARIES_ IMPORTED_LINK_DEPENDENT_LIBRARIES IMPORTED_LINK_INTERFACE_LANGUAGES_ IMPORTED_LINK_INTERFACE_LANGUAGES IMPORTED_LINK_INTERFACE_LIBRARIES_ IMPORTED_LINK_INTERFACE_LIBRARIES IMPORTED_LINK_INTERFACE_MULTIPLICITY_ IMPORTED_LINK_INTERFACE_MULTIPLICITY IMPORTED_LOCATION_ IMPORTED_LOCATION IMPORTED_NO_SONAME_ IMPORTED_NO_SONAME IMPORTED_OBJECTS_ IMPORTED_OBJECTS IMPORTED IMPORTED_SONAME_ IMPORTED_SONAME INTERFACE_AUTOUIC_OPTIONS INTERFACE_COMPILE_DEFINITIONS INTERFACE_COMPILE_FEATURES INTERFACE_COMPILE_OPTIONS INTERFACE_INCLUDE_DIRECTORIES INTERFACE_LINK_LIBRARIES INTERFACE_POSITION_INDEPENDENT_CODE INTERFACE_SOURCES INTERFACE_SYSTEM_INCLUDE_DIRECTORIES Read -> as maps to and X as nothing, zip, zilch, nadahey, bubkis, etc. So: SUFFIX to -> X INSTALL_RPATH -> X LINK_FLAGS -> X I am sure this is useful for some use case I an quite baffled as to what it is and I have request clarification from devs at: https://gitlab.kitware.com/cmake/cmake/issues/17216 I clearly don't get something here. I am interested to figure out what it is designed for. I have also asked that the error: CMake Error at CMakeLists.txt:45 (set_target_properties): INTERFACE_LIBRARY targets may only have whitelisted properties. The property "SUFFIX" is not allowed. provide better direction to user. https://gitlab.kitware.com/cmake/cmake/issues/17217 Possibly: e << "INTERFACE_LIBRARY targets may only have properties beginning with INTERFACE_* or IMPORTED_*. See cmake-properties for more information." "The property \"" << prop << "\" is not allowed."; -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcdailey.lists at gmail.com Sun Aug 27 15:55:04 2017 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Sun, 27 Aug 2017 14:55:04 -0500 Subject: [CMake] Debugging find_package() search behavior? Message-ID: So I'm trying to get CMake to find a package, and it isn't finding it. I am setting CMAKE_PREFIX_PATH to try to get it to find it. Is there a way I can view the search paths & prefixes that CMake is using with each find_package() call? I tried enabling debug and trace output, but neither of these seem to show any detail of what happens internally with find_package() searches. Thanks in advance. From rcdailey.lists at gmail.com Sun Aug 27 15:57:46 2017 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Sun, 27 Aug 2017 14:57:46 -0500 Subject: [CMake] CMake + Gradle for Android In-Reply-To: References: Message-ID: I could probably do you one better, and just give you a stripped-down version of our repository. Basically, I'd remove all our C++ and Java source code but leave the CMake scripts and such intact somehow. It would take me some time to do this, though. Would this be helpful for you? In the meantime, when I get into the office tomorrow I'll answer your questions directly with as much detail as possible. Would you like me to contact you personally from this point on or should we keep the conversation on the CMake list? On Fri, Aug 25, 2017 at 7:20 PM, Jom O'Fisher wrote: > Hi again Robert, > Would you be able to give me an estimate of how many APK projects you have, > roughly which open source projects you reference via CMake > add_subdirectories, and whether you have any variants beyond the default > Debug and Release? If possible I'd like to approximate your project layout > so we can study it in more closely with an eye toward making the experience > better for this kind of layout. > > > > > > On Fri, Aug 25, 2017 at 2:46 PM, Jom O'Fisher wrote: >> >> Targets are specified per-Variation so they need to go under the >> variation-specific section. Probably something like this: >> >> defaultConfig { >> externalNativeBuild { >> cmake { >> targets "library1", "library2" >> } >> } >> } >> >> That should work for you. Let me know. >> >> On Fri, Aug 25, 2017 at 2:42 PM, Robert Dailey >> wrote: >>> >>> By the way when I try to use "targets", I get a failure. Basically >>> Gradle doesn't recognize that keyword. I tried singular form as well >>> ("target"), no luck. >>> >>> I'm running canary build of everything possible. What am I missing? >>> >>> On Wed, Aug 23, 2017 at 4:20 PM, Jom O'Fisher >>> wrote: >>> > By gradle module projects, I just mean the leaf build.gradle files as >>> > opposed to the root build.gradle. By configurations, I mean Build Types >>> > (debug vs release) and Product Flavors (demo vs free vs paid). >>> > Hereafter I >>> > will use the term "variant" rather than "configuration" to be precise. >>> > See >>> > this write-up on build variants: >>> > >>> > >>> > https://developer.android.com/studio/build/build-variants.html#build-types >>> > >>> > This build matrix is constructed at the leaf build.gradle level. Native >>> > build in gradle allows you to set C/C++ flags individually for each >>> > variant >>> > so that you can define compiler flags (for example, -DFREE_VERSION). >>> > >>> > One thing to notice at this stage is that the same CMake target may be >>> > built >>> > with different compiler flags across different projects, build types, >>> > and >>> > product flavors. So in the general case, build outputs won't be the >>> > same. >>> > >>> > You asked which targets build when specifying path. By default, we >>> > build all >>> > targets that produce an .so. You can override this by setting >>> > externalNativeBuild.cmake.targets. For example, >>> > >>> > paid { >>> > ... >>> > externalNativeBuild { >>> > cmake { >>> > ... >>> > targets "native-lib-paid" >>> > } >>> > } >>> > } >>> > >>> > As for your last question, the model we generally see used is that the >>> > main >>> > CMakeLists.txt is next to the leaf build.gradle such that this >>> > CMakeLists.txt doesn't couple with peer APK project CMakeLists.txt >>> > (though >>> > they may share common dependencies and settings). Otherwise, multiple >>> > APK >>> > projects would perform pretty much similar to yours--they would build >>> > targets per-leaf project and not share build outputs. As far as I can >>> > see >>> > your organization is just as valid so long as you only build the >>> > targets you >>> > need. >>> > >>> > Regarding native dependencies between java projects. We generally try >>> > to >>> > avoid making the CMake build depend on the gradle build (you should be >>> > able >>> > to replicate the CMake build from the command-line if you set the right >>> > flags). At the moment I don't see a way we could make things better >>> > without >>> > violating that tenet but that could be lack of imagination on my part. >>> > >>> > We'll definitely be discussing this use case at our next C++ meeting >>> > and >>> > I'll also be checking for myself whether ccache will work in this CMake >>> > scenario. If ccache does work it seems like the natural level at which >>> > to >>> > fold identical builds. >>> > >>> > >>> > >>> > On Wed, Aug 23, 2017 at 1:03 PM, Robert Dailey >>> > >>> > wrote: >>> >> >>> >> I'm not sure what you mean by "gradle module projects", but maybe >>> >> having some examples of what you mean by "configurations, C++ flags, >>> >> etc" might make it more clear. >>> >> >>> >> Question: When specifying "path" for the CMakeLists.txt in the >>> >> build.gradle file, how do you know which targets to build? For >>> >> example, that run of CMake may generate 100 targets, but only 20 need >>> >> to build and be packaged (*.so files) with the APK. Do you just build >>> >> "all"? Is there a way to specify the target itself? >>> >> >>> >> Thanks again. I'd still like to know more about what the ideal >>> >> organization is. I find it hard to believe that large android projects >>> >> rarely break things up into multiple, separate "components" that are >>> >> built independently. That's really the gist of what we're dealing with >>> >> here. Your typical "hello world" project likely will have only 1 >>> >> CMakeLists.txt that is pretty self-contained, but all the >>> >> documentation I've looked at so far doesn't show the best way to >>> >> handle native library dependencies across java projects between >>> >> build.gradle files (or maybe I'm just not looking hard enough). >>> >> >>> >> On Wed, Aug 23, 2017 at 1:02 PM, Jom O'Fisher >>> >> wrote: >>> >> > Thanks for the write-up Robert. Having thought about it, I don't >>> >> > believe >>> >> > we >>> >> > have a satisfying answer at the gradle level for this kind of >>> >> > organization. >>> >> > In the gradle model module projects are the unit of organization for >>> >> > configurations, C/C++ flags, etc. and that's something we're pretty >>> >> > much >>> >> > stuck with. >>> >> > Regarding just the redundant build issue, would something like >>> >> > ccache >>> >> > help? >>> >> > I know people have used it with ndk-build with success, I'm not sure >>> >> > about >>> >> > CMake but I don't see why that should make a difference. >>> >> > >>> >> > >>> >> > >>> >> > On Tue, Aug 22, 2017 at 10:27 AM, Robert Dailey >>> >> > >>> >> > wrote: >>> >> >> >>> >> >> Another reason to reduce the number of binary directories is that >>> >> >> there are different ways of managing third party libraries. One in >>> >> >> particular that we use is to clone a repository into the binary >>> >> >> directory and build all third party libs in real time based on a >>> >> >> toolchain file (Similar to the functionality provided by >>> >> >> ExternalProject module in CMake). This is repeated from scratch >>> >> >> only >>> >> >> if the work hasn't already been done in the binary directory >>> >> >> before. >>> >> >> By having more binary dirs than needed, this work is being done an >>> >> >> exponential amount of times which can result in a lot of wasted >>> >> >> time >>> >> >> waiting. There are 1 time operations that multiple targets can >>> >> >> benefit >>> >> >> from in a single binary tree, instead of 1 per unique target being >>> >> >> invoked. >>> >> >> >>> >> >> Sorry to keep responding: I'm just thinking of things as I go and >>> >> >> bringing them up, to shed light on some of the reasoning behind my >>> >> >> suggestions. >>> >> >> >>> >> >> On Tue, Aug 22, 2017 at 9:26 AM, Robert Dailey >>> >> >> >>> >> >> wrote: >>> >> >> > Sorry I forgot to answer your last set of questions: >>> >> >> > >>> >> >> > CommonLib is indeed 2 things: >>> >> >> > >>> >> >> > * A common (static or shared) library for native code (most of >>> >> >> > our >>> >> >> > CMake targets specify CommonLib as a link dependency) >>> >> >> > * A common library for Java code (we do specify this as a >>> >> >> > dependency >>> >> >> > for most java targets in Gradle, specifically those under >>> >> >> > Applications/) >>> >> >> > >>> >> >> > On Mon, Aug 21, 2017 at 6:20 PM, Raymond Chiu >>> >> >> > wrote: >>> >> >> >> Hi Robert, >>> >> >> >> >>> >> >> >> I work with Jom on the Android Studio team, and I would like to >>> >> >> >> clarify >>> >> >> >> a >>> >> >> >> few things to better understand your situation. >>> >> >> >> You mentioned the project is intend to be cross platform. >>> >> >> >> Normally, >>> >> >> >> in >>> >> >> >> such >>> >> >> >> situation, we expect there to be a single CMake root project to >>> >> >> >> be >>> >> >> >> imported >>> >> >> >> into one of the Android library/application. However, in your >>> >> >> >> case, >>> >> >> >> there >>> >> >> >> are subprojects with Java code. >>> >> >> >> >>> >> >> >> Are the CMake code in App1/2/3 intended to be cross platform >>> >> >> >> too? >>> >> >> >> Or >>> >> >> >> are >>> >> >> >> they Android specific code? If they are meant to be cross >>> >> >> >> platform, >>> >> >> >> how >>> >> >> >> does the Java code works on other platforms? Or perhaps you >>> >> >> >> added >>> >> >> >> Java >>> >> >> >> binding in those subprojects just for Android? >>> >> >> >> >>> >> >> >> The build.gradle in CommonLib, what kind of Gradle project is >>> >> >> >> that? >>> >> >> >> From >>> >> >> >> your description, it doesn't look like an Android library >>> >> >> >> project. >>> >> >> >> Or >>> >> >> >> am I >>> >> >> >> mistaken and it also applies the android library plugin? >>> >> >> >> >>> >> >> >> Raymond >>> >> >> >> >>> >> >> >> On Mon, Aug 21, 2017 at 3:34 PM, Jom O'Fisher >>> >> >> >> >>> >> >> >> wrote: >>> >> >> >>> >>> >> >> >>> + a colleague >>> >> >> >>> >>> >> >> >>> On Mon, Aug 21, 2017 at 3:11 PM, Jom O'Fisher >>> >> >> >>> >>> >> >> >>> wrote: >>> >> >> >>>> >>> >> >> >>>> You can find that number like this: >>> >> >> >>>> - x = number of externalNativeBuild.cmake.path in your >>> >> >> >>>> build.gradle >>> >> >> >>>> files >>> >> >> >>>> - y = number of gradle configurations (like debug and release) >>> >> >> >>>> - z = number of ABIs that you build >>> >> >> >>>> >>> >> >> >>>> The result is x * y * z. To be more accurate, you should >>> >> >> >>>> consider >>> >> >> >>>> y >>> >> >> >>>> and z >>> >> >> >>>> to be functions of each build.gradle file since these can >>> >> >> >>>> vary. >>> >> >> >>>> >>> >> >> >>>> There is a second set of folders that hold the stripped >>> >> >> >>>> versions >>> >> >> >>>> of >>> >> >> >>>> the >>> >> >> >>>> .so files that is purely managed by the android gradle plugin, >>> >> >> >>>> so >>> >> >> >>>> you >>> >> >> >>>> might >>> >> >> >>>> consider the answer to be 2 * x * y * z. >>> >> >> >>>> >>> >> >> >>>> Hope this helps. >>> >> >> >>>> >>> >> >> >>>> >>> >> >> >>>> >>> >> >> >>>> >>> >> >> >>>> >>> >> >> >>>> >>> >> >> >>>> On Mon, Aug 21, 2017 at 2:41 PM, Robert Dailey >>> >> >> >>>> >>> >> >> >>>> wrote: >>> >> >> >>>>> >>> >> >> >>>>> This definitely a bit better, but still requires the >>> >> >> >>>>> boilerplate >>> >> >> >>>>> in >>> >> >> >>>>> each leaf gradle file. But I can't seriously complain too >>> >> >> >>>>> much. I >>> >> >> >>>>> think I'm more concerned with the implications this has >>> >> >> >>>>> underneath. >>> >> >> >>>>> First, let me ask just to make sure I'm not misunderstanding: >>> >> >> >>>>> Does >>> >> >> >>>>> each `externalNativeBuild` entry essentially mean 1 >>> >> >> >>>>> CMAKE_BINARY_DIR? >>> >> >> >>>>> How many binary dirs do you manage internally and what >>> >> >> >>>>> determines >>> >> >> >>>>> when >>> >> >> >>>>> they get created? >>> >> >> >>>>> >>> >> >> >>>>> On Mon, Aug 21, 2017 at 2:35 PM, Jom O'Fisher >>> >> >> >>>>> >>> >> >> >>>>> wrote: >>> >> >> >>>>> > Would it work for your scenario to provide properties in >>> >> >> >>>>> > the >>> >> >> >>>>> > root >>> >> >> >>>>> > build.gradle: >>> >> >> >>>>> > >>> >> >> >>>>> > ext { >>> >> >> >>>>> > cmakePath = file "CMakeLists.txt" >>> >> >> >>>>> > } >>> >> >> >>>>> > >>> >> >> >>>>> > And then consume them in the leaf app/build.gradle like >>> >> >> >>>>> > this? >>> >> >> >>>>> > >>> >> >> >>>>> > externalNativeBuild { >>> >> >> >>>>> > cmake { >>> >> >> >>>>> > path cmakePath >>> >> >> >>>>> > } >>> >> >> >>>>> > } >>> >> >> >>>>> > >>> >> >> >>>>> > It doesn't fully hide the details but it does centralize >>> >> >> >>>>> > the >>> >> >> >>>>> > information. >>> >> >> >>>>> > >>> >> >> >>>>> > >>> >> >> >>>>> > On Mon, Aug 21, 2017 at 11:20 AM, Robert Dailey >>> >> >> >>>>> > >>> >> >> >>>>> > wrote: >>> >> >> >>>>> >> >>> >> >> >>>>> >> I wouldn't want to do that, it's too convoluted. I have >>> >> >> >>>>> >> other >>> >> >> >>>>> >> platforms that use these CMake scripts as well. For >>> >> >> >>>>> >> example, I >>> >> >> >>>>> >> run on >>> >> >> >>>>> >> Windows and Linux platforms as well to build the native >>> >> >> >>>>> >> code. >>> >> >> >>>>> >> Normal >>> >> >> >>>>> >> CMake behavior is designed to work at a root then go >>> >> >> >>>>> >> downwards >>> >> >> >>>>> >> to >>> >> >> >>>>> >> find >>> >> >> >>>>> >> targets. However it seems Gradle wants to start at a >>> >> >> >>>>> >> subdirectory >>> >> >> >>>>> >> and >>> >> >> >>>>> >> work its way up to the root, which is opposite of CMake's >>> >> >> >>>>> >> intended >>> >> >> >>>>> >> behavior IMHO. Not only that but I want to avoid >>> >> >> >>>>> >> special-casing >>> >> >> >>>>> >> behavior in CMake just for Android's use. >>> >> >> >>>>> >> >>> >> >> >>>>> >> At the moment it feels like (again referring back to my >>> >> >> >>>>> >> previous >>> >> >> >>>>> >> example structure) that both App2 and App3 each run CMake >>> >> >> >>>>> >> in >>> >> >> >>>>> >> independent binary directories instead of sharing 1 binary >>> >> >> >>>>> >> directory >>> >> >> >>>>> >> and building 2 targets inside of it. I prefer this >>> >> >> >>>>> >> behavior >>> >> >> >>>>> >> instead, >>> >> >> >>>>> >> especially since it allows CMake to operate as it was >>> >> >> >>>>> >> intended. I >>> >> >> >>>>> >> think it's a common case that projects will define >>> >> >> >>>>> >> multiple >>> >> >> >>>>> >> targets >>> >> >> >>>>> >> starting from a single root, and expect multiple APKs or >>> >> >> >>>>> >> java >>> >> >> >>>>> >> dependencies to be built within it. >>> >> >> >>>>> >> >>> >> >> >>>>> >> If I'm misunderstanding or making false assumptions please >>> >> >> >>>>> >> let >>> >> >> >>>>> >> me >>> >> >> >>>>> >> know. >>> >> >> >>>>> >> >>> >> >> >>>>> >> >>> >> >> >>>>> >> >>> >> >> >>>>> >> On Mon, Aug 21, 2017 at 12:00 PM, Jom O'Fisher >>> >> >> >>>>> >> >>> >> >> >>>>> >> wrote: >>> >> >> >>>>> >> > Would it work for your situation for the leaf >>> >> >> >>>>> >> > CMakeLists.txt >>> >> >> >>>>> >> > to >>> >> >> >>>>> >> > include >>> >> >> >>>>> >> > the >>> >> >> >>>>> >> > root CMakeLists.txt? Then have the leaf-specific logic >>> >> >> >>>>> >> > in >>> >> >> >>>>> >> > the >>> >> >> >>>>> >> > leaf >>> >> >> >>>>> >> > CMakeLists.txt? >>> >> >> >>>>> >> > >>> >> >> >>>>> >> > >>> >> >> >>>>> >> > >>> >> >> >>>>> >> > On Mon, Aug 21, 2017 at 9:33 AM, Robert Dailey >>> >> >> >>>>> >> > >>> >> >> >>>>> >> > wrote: >>> >> >> >>>>> >> >> >>> >> >> >>>>> >> >> Basically, yes. We have this sort of structure: >>> >> >> >>>>> >> >> >>> >> >> >>>>> >> >> / >>> >> >> >>>>> >> >> Applications/ >>> >> >> >>>>> >> >> App1/ >>> >> >> >>>>> >> >> build.gradle >>> >> >> >>>>> >> >> CMakeLists.txt >>> >> >> >>>>> >> >> App2/ >>> >> >> >>>>> >> >> build.gradle >>> >> >> >>>>> >> >> CMakeLists.txt >>> >> >> >>>>> >> >> App3/ >>> >> >> >>>>> >> >> build.gradle >>> >> >> >>>>> >> >> CMakeLists.txt >>> >> >> >>>>> >> >> CommonLib/ >>> >> >> >>>>> >> >> build.gradle >>> >> >> >>>>> >> >> CMakeLists.txt >>> >> >> >>>>> >> >> CMakeLists.txt >>> >> >> >>>>> >> >> >>> >> >> >>>>> >> >> The libs are defined as follows: >>> >> >> >>>>> >> >> >>> >> >> >>>>> >> >> * CommonLib is a static library (java code builds into >>> >> >> >>>>> >> >> a >>> >> >> >>>>> >> >> library) >>> >> >> >>>>> >> >> * No dependencies of its own >>> >> >> >>>>> >> >> * App1 is a shared library (java code builds into a >>> >> >> >>>>> >> >> library) >>> >> >> >>>>> >> >> * Dependencies (both java & native): CommonLib >>> >> >> >>>>> >> >> * App2 is a shared library (java code builds into an >>> >> >> >>>>> >> >> APK) >>> >> >> >>>>> >> >> * Dependencies (both java & native): App1, CommonLib >>> >> >> >>>>> >> >> * App3 is a shared library (java code builds into an >>> >> >> >>>>> >> >> APK) >>> >> >> >>>>> >> >> * Dependencies (both java & native): CommonLib >>> >> >> >>>>> >> >> >>> >> >> >>>>> >> >> In all cases, CMake must be invoked starting at the >>> >> >> >>>>> >> >> root >>> >> >> >>>>> >> >> CMakeLists.txt 1 time. Each target can be built from >>> >> >> >>>>> >> >> the >>> >> >> >>>>> >> >> same >>> >> >> >>>>> >> >> binary >>> >> >> >>>>> >> >> directory after that. Previously with ANT, I was >>> >> >> >>>>> >> >> building >>> >> >> >>>>> >> >> all >>> >> >> >>>>> >> >> native >>> >> >> >>>>> >> >> targets first, then moved libs to appropriate >>> >> >> >>>>> >> >> directories >>> >> >> >>>>> >> >> so >>> >> >> >>>>> >> >> that >>> >> >> >>>>> >> >> the >>> >> >> >>>>> >> >> 'ant' command would package the libs. >>> >> >> >>>>> >> >> >>> >> >> >>>>> >> >> For gradle, I wanted to avoid redundantly specifying >>> >> >> >>>>> >> >> the >>> >> >> >>>>> >> >> root >>> >> >> >>>>> >> >> directory in each leaf-level project directory. Using >>> >> >> >>>>> >> >> the >>> >> >> >>>>> >> >> example >>> >> >> >>>>> >> >> above, the leaf-level directories in this case would be >>> >> >> >>>>> >> >> App1, >>> >> >> >>>>> >> >> App2, >>> >> >> >>>>> >> >> App3, and CommonLib. However I think we only specify >>> >> >> >>>>> >> >> the >>> >> >> >>>>> >> >> native >>> >> >> >>>>> >> >> CMake >>> >> >> >>>>> >> >> stuff for the java targets that actually output an APK >>> >> >> >>>>> >> >> (that >>> >> >> >>>>> >> >> would >>> >> >> >>>>> >> >> be >>> >> >> >>>>> >> >> App2 and App3 only). >>> >> >> >>>>> >> >> >>> >> >> >>>>> >> >> The ultimate goal is to specify stuff that doesn't >>> >> >> >>>>> >> >> change >>> >> >> >>>>> >> >> per >>> >> >> >>>>> >> >> independent "module" of ours at the top level so it is >>> >> >> >>>>> >> >> transitive >>> >> >> >>>>> >> >> / >>> >> >> >>>>> >> >> inherited. Then only specify the differences (e.g. the >>> >> >> >>>>> >> >> native >>> >> >> >>>>> >> >> CMake >>> >> >> >>>>> >> >> target to build) in the leaf build gradle files. >>> >> >> >>>>> >> >> However >>> >> >> >>>>> >> >> you >>> >> >> >>>>> >> >> indicated >>> >> >> >>>>> >> >> this isn't possible. >>> >> >> >>>>> >> >> >>> >> >> >>>>> >> >> >>> >> >> >>>>> >> >> >>> >> >> >>>>> >> >> On Mon, Aug 21, 2017 at 11:11 AM, Jom O'Fisher >>> >> >> >>>>> >> >> >>> >> >> >>>>> >> >> wrote: >>> >> >> >>>>> >> >> > What you're doing already sounds correct. You can't >>> >> >> >>>>> >> >> > directly >>> >> >> >>>>> >> >> > specify >>> >> >> >>>>> >> >> > CMakeLists.txt from the top-level build.gradle. >>> >> >> >>>>> >> >> > Recommendation >>> >> >> >>>>> >> >> > is >>> >> >> >>>>> >> >> > that >>> >> >> >>>>> >> >> > it >>> >> >> >>>>> >> >> > should be specified from the build.gradle of the >>> >> >> >>>>> >> >> > module >>> >> >> >>>>> >> >> > of >>> >> >> >>>>> >> >> > the >>> >> >> >>>>> >> >> > APK. >>> >> >> >>>>> >> >> > Is >>> >> >> >>>>> >> >> > the >>> >> >> >>>>> >> >> > issue that you have multiple APK modules that all >>> >> >> >>>>> >> >> > reference >>> >> >> >>>>> >> >> > the >>> >> >> >>>>> >> >> > same >>> >> >> >>>>> >> >> > CMake >>> >> >> >>>>> >> >> > libraries? >>> >> >> >>>>> >> >> > >>> >> >> >>>>> >> >> > On Mon, Aug 21, 2017 at 9:00 AM, Robert Dailey >>> >> >> >>>>> >> >> > >>> >> >> >>>>> >> >> > wrote: >>> >> >> >>>>> >> >> >> >>> >> >> >>>>> >> >> >> Thanks this is very helpful. The other question I >>> >> >> >>>>> >> >> >> have >>> >> >> >>>>> >> >> >> is: >>> >> >> >>>>> >> >> >> Is >>> >> >> >>>>> >> >> >> there >>> >> >> >>>>> >> >> >> a >>> >> >> >>>>> >> >> >> place to centrally specify the root CMakeLists.txt? >>> >> >> >>>>> >> >> >> Basically, >>> >> >> >>>>> >> >> >> I >>> >> >> >>>>> >> >> >> want >>> >> >> >>>>> >> >> >> to specify the CMake root in 1 place, and have >>> >> >> >>>>> >> >> >> targets >>> >> >> >>>>> >> >> >> (defined >>> >> >> >>>>> >> >> >> further down in subdirectories) that require APK >>> >> >> >>>>> >> >> >> packaging >>> >> >> >>>>> >> >> >> to >>> >> >> >>>>> >> >> >> specify >>> >> >> >>>>> >> >> >> only the native target name that should be built & >>> >> >> >>>>> >> >> >> packaged. >>> >> >> >>>>> >> >> >> >>> >> >> >>>>> >> >> >> At the moment we specify the root CMakeLists.txt by >>> >> >> >>>>> >> >> >> walking >>> >> >> >>>>> >> >> >> up >>> >> >> >>>>> >> >> >> the >>> >> >> >>>>> >> >> >> tree, paths like "../../../../CMakeLists.txt". I >>> >> >> >>>>> >> >> >> think >>> >> >> >>>>> >> >> >> this >>> >> >> >>>>> >> >> >> should >>> >> >> >>>>> >> >> >> be >>> >> >> >>>>> >> >> >> put at the top-level build gradle file if possible. >>> >> >> >>>>> >> >> >> Is >>> >> >> >>>>> >> >> >> this >>> >> >> >>>>> >> >> >> doable >>> >> >> >>>>> >> >> >> at >>> >> >> >>>>> >> >> >> the moment? What is the recommended setup? >>> >> >> >>>>> >> >> >> >>> >> >> >>>>> >> >> >> On Mon, Aug 21, 2017 at 9:37 AM, Jom O'Fisher >>> >> >> >>>>> >> >> >> >>> >> >> >>>>> >> >> >> wrote: >>> >> >> >>>>> >> >> >> > Gradle does introspection on the CMake build to >>> >> >> >>>>> >> >> >> > find >>> >> >> >>>>> >> >> >> > .so >>> >> >> >>>>> >> >> >> > targets >>> >> >> >>>>> >> >> >> > and >>> >> >> >>>>> >> >> >> > those >>> >> >> >>>>> >> >> >> > get packaged. >>> >> >> >>>>> >> >> >> > There is also a special case for stl/runtime .so >>> >> >> >>>>> >> >> >> > files >>> >> >> >>>>> >> >> >> > from >>> >> >> >>>>> >> >> >> > the >>> >> >> >>>>> >> >> >> > NDK. >>> >> >> >>>>> >> >> >> > Any additional .so files need to specified in >>> >> >> >>>>> >> >> >> > build.gradle >>> >> >> >>>>> >> >> >> > using >>> >> >> >>>>> >> >> >> > jniDirs >>> >> >> >>>>> >> >> >> > >>> >> >> >>>>> >> >> >> > On Mon, Aug 21, 2017 at 7:30 AM, Robert Dailey >>> >> >> >>>>> >> >> >> > >>> >> >> >>>>> >> >> >> > wrote: >>> >> >> >>>>> >> >> >> >> >>> >> >> >>>>> >> >> >> >> How exactly does Gradle package *.so files in an >>> >> >> >>>>> >> >> >> >> APK? >>> >> >> >>>>> >> >> >> >> I >>> >> >> >>>>> >> >> >> >> know >>> >> >> >>>>> >> >> >> >> that >>> >> >> >>>>> >> >> >> >> ANT >>> >> >> >>>>> >> >> >> >> used to do this for any libs under "libs/". >>> >> >> >>>>> >> >> >> >> Does >>> >> >> >>>>> >> >> >> >> Gradle >>> >> >> >>>>> >> >> >> >> do >>> >> >> >>>>> >> >> >> >> some >>> >> >> >>>>> >> >> >> >> introspection into CMake targets to see if >>> >> >> >>>>> >> >> >> >> outputs >>> >> >> >>>>> >> >> >> >> are >>> >> >> >>>>> >> >> >> >> *.so, >>> >> >> >>>>> >> >> >> >> and >>> >> >> >>>>> >> >> >> >> copy >>> >> >> >>>>> >> >> >> >> those to some location if needed? What about >>> >> >> >>>>> >> >> >> >> libraries >>> >> >> >>>>> >> >> >> >> like >>> >> >> >>>>> >> >> >> >> libgnustl_shared.so that come with the NDK? I'd >>> >> >> >>>>> >> >> >> >> like >>> >> >> >>>>> >> >> >> >> to >>> >> >> >>>>> >> >> >> >> know >>> >> >> >>>>> >> >> >> >> if >>> >> >> >>>>> >> >> >> >> any >>> >> >> >>>>> >> >> >> >> manual copy steps are needed in CMake to put >>> >> >> >>>>> >> >> >> >> outputs >>> >> >> >>>>> >> >> >> >> in >>> >> >> >>>>> >> >> >> >> proper >>> >> >> >>>>> >> >> >> >> locations for the APK build step. I had to do >>> >> >> >>>>> >> >> >> >> this >>> >> >> >>>>> >> >> >> >> when >>> >> >> >>>>> >> >> >> >> using >>> >> >> >>>>> >> >> >> >> ANT. >>> >> >> >>>>> >> >> >> >> >>> >> >> >>>>> >> >> >> >> On Mon, Aug 7, 2017 at 6:16 PM, Jom O'Fisher >>> >> >> >>>>> >> >> >> >> >>> >> >> >>>>> >> >> >> >> wrote: >>> >> >> >>>>> >> >> >> >> > 1) There is a folder created for each ABI under >>> >> >> >>>>> >> >> >> >> > the >>> >> >> >>>>> >> >> >> >> > project >>> >> >> >>>>> >> >> >> >> > module >>> >> >> >>>>> >> >> >> >> > folder >>> >> >> >>>>> >> >> >> >> > (so unique per module per ABI) >>> >> >> >>>>> >> >> >> >> > 2) Gradle doesn't specify language level though >>> >> >> >>>>> >> >> >> >> > you >>> >> >> >>>>> >> >> >> >> > can >>> >> >> >>>>> >> >> >> >> > choose >>> >> >> >>>>> >> >> >> >> > to >>> >> >> >>>>> >> >> >> >> > specify it >>> >> >> >>>>> >> >> >> >> > yourself from the build.gradle. This doc does a >>> >> >> >>>>> >> >> >> >> > pretty >>> >> >> >>>>> >> >> >> >> > good job >>> >> >> >>>>> >> >> >> >> > of >>> >> >> >>>>> >> >> >> >> > explaining which variables are set by Gradle: >>> >> >> >>>>> >> >> >> >> > >>> >> >> >>>>> >> >> >> >> > >>> >> >> >>>>> >> >> >> >> > >>> >> >> >>>>> >> >> >> >> > >>> >> >> >>>>> >> >> >> >> > https://developer.android.com/ndk/guides/cmake.html#variables. >>> >> >> >>>>> >> >> >> >> > Philosophically, we try to set as little as we >>> >> >> >>>>> >> >> >> >> > can >>> >> >> >>>>> >> >> >> >> > get >>> >> >> >>>>> >> >> >> >> > away >>> >> >> >>>>> >> >> >> >> > with. >>> >> >> >>>>> >> >> >> >> > In >>> >> >> >>>>> >> >> >> >> > particular, the section titled "Understanding >>> >> >> >>>>> >> >> >> >> > the >>> >> >> >>>>> >> >> >> >> > CMake >>> >> >> >>>>> >> >> >> >> > build >>> >> >> >>>>> >> >> >> >> > command" >>> >> >> >>>>> >> >> >> >> > lays >>> >> >> >>>>> >> >> >> >> > out exactly what we set. You can also see the >>> >> >> >>>>> >> >> >> >> > folders >>> >> >> >>>>> >> >> >> >> > we >>> >> >> >>>>> >> >> >> >> > specify >>> >> >> >>>>> >> >> >> >> > (one >>> >> >> >>>>> >> >> >> >> > per >>> >> >> >>>>> >> >> >> >> > module per ABI) >>> >> >> >>>>> >> >> >> >> > 3) Not sure I understand this. >>> >> >> >>>>> >> >> >> >> > >>> >> >> >>>>> >> >> >> >> > The other document worth taking a look at (if >>> >> >> >>>>> >> >> >> >> > you >>> >> >> >>>>> >> >> >> >> > haven't >>> >> >> >>>>> >> >> >> >> > already) >>> >> >> >>>>> >> >> >> >> > is: >>> >> >> >>>>> >> >> >> >> > >>> >> >> >>>>> >> >> >> >> > >>> >> >> >>>>> >> >> >> >> > >>> >> >> >>>>> >> >> >> >> > >>> >> >> >>>>> >> >> >> >> > >>> >> >> >>>>> >> >> >> >> > https://developer.android.com/studio/projects/add-native-code.html >>> >> >> >>>>> >> >> >> >> > >>> >> >> >>>>> >> >> >> >> > >>> >> >> >>>>> >> >> >> >> > On Mon, Aug 7, 2017 at 3:35 PM, Robert Dailey >>> >> >> >>>>> >> >> >> >> > >>> >> >> >>>>> >> >> >> >> > wrote: >>> >> >> >>>>> >> >> >> >> >> >>> >> >> >>>>> >> >> >> >> >> Thanks Jom >>> >> >> >>>>> >> >> >> >> >> >>> >> >> >>>>> >> >> >> >> >> Honestly, I prefer option 1 to work simply >>> >> >> >>>>> >> >> >> >> >> because >>> >> >> >>>>> >> >> >> >> >> that's >>> >> >> >>>>> >> >> >> >> >> how >>> >> >> >>>>> >> >> >> >> >> Google's >>> >> >> >>>>> >> >> >> >> >> officially supporting CMake. But it also has >>> >> >> >>>>> >> >> >> >> >> debugging >>> >> >> >>>>> >> >> >> >> >> which >>> >> >> >>>>> >> >> >> >> >> is >>> >> >> >>>>> >> >> >> >> >> the >>> >> >> >>>>> >> >> >> >> >> #1 >>> >> >> >>>>> >> >> >> >> >> reason for me. >>> >> >> >>>>> >> >> >> >> >> >>> >> >> >>>>> >> >> >> >> >> However, I'd like to understand a lot more >>> >> >> >>>>> >> >> >> >> >> about >>> >> >> >>>>> >> >> >> >> >> how >>> >> >> >>>>> >> >> >> >> >> the >>> >> >> >>>>> >> >> >> >> >> integration >>> >> >> >>>>> >> >> >> >> >> really happens. For example, I have these >>> >> >> >>>>> >> >> >> >> >> questions: >>> >> >> >>>>> >> >> >> >> >> >>> >> >> >>>>> >> >> >> >> >> 1) How, internally, are CMake build >>> >> >> >>>>> >> >> >> >> >> directories >>> >> >> >>>>> >> >> >> >> >> managed? >>> >> >> >>>>> >> >> >> >> >> Do >>> >> >> >>>>> >> >> >> >> >> you >>> >> >> >>>>> >> >> >> >> >> generate 1 per unique android project? What >>> >> >> >>>>> >> >> >> >> >> about >>> >> >> >>>>> >> >> >> >> >> for >>> >> >> >>>>> >> >> >> >> >> each >>> >> >> >>>>> >> >> >> >> >> specific >>> >> >> >>>>> >> >> >> >> >> platform (x86, armeabi-v7a, etc)? >>> >> >> >>>>> >> >> >> >> >> 2) Last time I looked into CMake integration, >>> >> >> >>>>> >> >> >> >> >> things >>> >> >> >>>>> >> >> >> >> >> defined >>> >> >> >>>>> >> >> >> >> >> inside >>> >> >> >>>>> >> >> >> >> >> the CMake scripts were ignored because they >>> >> >> >>>>> >> >> >> >> >> are >>> >> >> >>>>> >> >> >> >> >> specified >>> >> >> >>>>> >> >> >> >> >> at >>> >> >> >>>>> >> >> >> >> >> the >>> >> >> >>>>> >> >> >> >> >> command line. Namely, all of those settings >>> >> >> >>>>> >> >> >> >> >> that >>> >> >> >>>>> >> >> >> >> >> are >>> >> >> >>>>> >> >> >> >> >> driven by >>> >> >> >>>>> >> >> >> >> >> the >>> >> >> >>>>> >> >> >> >> >> Gradle configuration (CXX language level was >>> >> >> >>>>> >> >> >> >> >> one >>> >> >> >>>>> >> >> >> >> >> in >>> >> >> >>>>> >> >> >> >> >> particular >>> >> >> >>>>> >> >> >> >> >> I >>> >> >> >>>>> >> >> >> >> >> think; I specify C++14 support via CMake, but >>> >> >> >>>>> >> >> >> >> >> I >>> >> >> >>>>> >> >> >> >> >> recall >>> >> >> >>>>> >> >> >> >> >> this >>> >> >> >>>>> >> >> >> >> >> being >>> >> >> >>>>> >> >> >> >> >> overridden from outside)? >>> >> >> >>>>> >> >> >> >> >> 3) How redundant is it to configure individual >>> >> >> >>>>> >> >> >> >> >> libraries >>> >> >> >>>>> >> >> >> >> >> via >>> >> >> >>>>> >> >> >> >> >> the >>> >> >> >>>>> >> >> >> >> >> gradle scripts? In my previous attempts, I >>> >> >> >>>>> >> >> >> >> >> wanted >>> >> >> >>>>> >> >> >> >> >> to >>> >> >> >>>>> >> >> >> >> >> define >>> >> >> >>>>> >> >> >> >> >> common >>> >> >> >>>>> >> >> >> >> >> stuff for CMake / native code at the root >>> >> >> >>>>> >> >> >> >> >> gradle >>> >> >> >>>>> >> >> >> >> >> or >>> >> >> >>>>> >> >> >> >> >> settings >>> >> >> >>>>> >> >> >> >> >> file, >>> >> >> >>>>> >> >> >> >> >> and >>> >> >> >>>>> >> >> >> >> >> only define the differences in the actual >>> >> >> >>>>> >> >> >> >> >> gradle >>> >> >> >>>>> >> >> >> >> >> build >>> >> >> >>>>> >> >> >> >> >> files >>> >> >> >>>>> >> >> >> >> >> for >>> >> >> >>>>> >> >> >> >> >> each >>> >> >> >>>>> >> >> >> >> >> corresponding Java target (like, defining the >>> >> >> >>>>> >> >> >> >> >> name >>> >> >> >>>>> >> >> >> >> >> of >>> >> >> >>>>> >> >> >> >> >> the >>> >> >> >>>>> >> >> >> >> >> native >>> >> >> >>>>> >> >> >> >> >> (shared library) target in Gradle, but the >>> >> >> >>>>> >> >> >> >> >> command >>> >> >> >>>>> >> >> >> >> >> line >>> >> >> >>>>> >> >> >> >> >> invocation, >>> >> >> >>>>> >> >> >> >> >> -D >>> >> >> >>>>> >> >> >> >> >> CMake settings, etc would all be common and >>> >> >> >>>>> >> >> >> >> >> defined >>> >> >> >>>>> >> >> >> >> >> at >>> >> >> >>>>> >> >> >> >> >> the >>> >> >> >>>>> >> >> >> >> >> root). >>> >> >> >>>>> >> >> >> >> >> >>> >> >> >>>>> >> >> >> >> >> The TLDR is, the closer we can stay to CMake's >>> >> >> >>>>> >> >> >> >> >> way >>> >> >> >>>>> >> >> >> >> >> of >>> >> >> >>>>> >> >> >> >> >> doing >>> >> >> >>>>> >> >> >> >> >> things >>> >> >> >>>>> >> >> >> >> >> and >>> >> >> >>>>> >> >> >> >> >> keep CMake-related settings self-contained to >>> >> >> >>>>> >> >> >> >> >> the >>> >> >> >>>>> >> >> >> >> >> CMake >>> >> >> >>>>> >> >> >> >> >> scripts >>> >> >> >>>>> >> >> >> >> >> themselves, the better. This also makes >>> >> >> >>>>> >> >> >> >> >> cross-platform >>> >> >> >>>>> >> >> >> >> >> easier >>> >> >> >>>>> >> >> >> >> >> (we >>> >> >> >>>>> >> >> >> >> >> build the native code in Windows, for example, >>> >> >> >>>>> >> >> >> >> >> so >>> >> >> >>>>> >> >> >> >> >> having >>> >> >> >>>>> >> >> >> >> >> settings >>> >> >> >>>>> >> >> >> >> >> specified in the gradle files do not carry >>> >> >> >>>>> >> >> >> >> >> over to >>> >> >> >>>>> >> >> >> >> >> other >>> >> >> >>>>> >> >> >> >> >> platforms. >>> >> >> >>>>> >> >> >> >> >> Namely, settings that are not platform >>> >> >> >>>>> >> >> >> >> >> specific >>> >> >> >>>>> >> >> >> >> >> like >>> >> >> >>>>> >> >> >> >> >> the >>> >> >> >>>>> >> >> >> >> >> C++ >>> >> >> >>>>> >> >> >> >> >> language >>> >> >> >>>>> >> >> >> >> >> level). >>> >> >> >>>>> >> >> >> >> >> >>> >> >> >>>>> >> >> >> >> >> If there's a detailed document / wiki I can >>> >> >> >>>>> >> >> >> >> >> read >>> >> >> >>>>> >> >> >> >> >> on >>> >> >> >>>>> >> >> >> >> >> the >>> >> >> >>>>> >> >> >> >> >> intrinsics >>> >> >> >>>>> >> >> >> >> >> of >>> >> >> >>>>> >> >> >> >> >> CMake integration in Gradle / Android Studio, >>> >> >> >>>>> >> >> >> >> >> I'd >>> >> >> >>>>> >> >> >> >> >> love to >>> >> >> >>>>> >> >> >> >> >> read >>> >> >> >>>>> >> >> >> >> >> it. >>> >> >> >>>>> >> >> >> >> >> Otherwise, I hope you won't mind if I pick >>> >> >> >>>>> >> >> >> >> >> your >>> >> >> >>>>> >> >> >> >> >> brain >>> >> >> >>>>> >> >> >> >> >> as >>> >> >> >>>>> >> >> >> >> >> questions >>> >> >> >>>>> >> >> >> >> >> come up. I think I'm going to try option 1 for >>> >> >> >>>>> >> >> >> >> >> now >>> >> >> >>>>> >> >> >> >> >> and >>> >> >> >>>>> >> >> >> >> >> see how >>> >> >> >>>>> >> >> >> >> >> it >>> >> >> >>>>> >> >> >> >> >> goes. It's just black box for me because >>> >> >> >>>>> >> >> >> >> >> unlike >>> >> >> >>>>> >> >> >> >> >> option 2, >>> >> >> >>>>> >> >> >> >> >> I >>> >> >> >>>>> >> >> >> >> >> have >>> >> >> >>>>> >> >> >> >> >> very >>> >> >> >>>>> >> >> >> >> >> little control over what happens after >>> >> >> >>>>> >> >> >> >> >> building >>> >> >> >>>>> >> >> >> >> >> the >>> >> >> >>>>> >> >> >> >> >> shared >>> >> >> >>>>> >> >> >> >> >> libraries, >>> >> >> >>>>> >> >> >> >> >> and to make up for that I need to really get a >>> >> >> >>>>> >> >> >> >> >> deep >>> >> >> >>>>> >> >> >> >> >> understanding >>> >> >> >>>>> >> >> >> >> >> of >>> >> >> >>>>> >> >> >> >> >> how it works so I can make sure I code my >>> >> >> >>>>> >> >> >> >> >> CMake >>> >> >> >>>>> >> >> >> >> >> scripts >>> >> >> >>>>> >> >> >> >> >> properly >>> >> >> >>>>> >> >> >> >> >> for >>> >> >> >>>>> >> >> >> >> >> not only Android, but my other platforms as >>> >> >> >>>>> >> >> >> >> >> well >>> >> >> >>>>> >> >> >> >> >> (non-Android >>> >> >> >>>>> >> >> >> >> >> platforms). >>> >> >> >>>>> >> >> >> >> >> >>> >> >> >>>>> >> >> >> >> >> Thanks again. >>> >> >> >>>>> >> >> >> >> >> >>> >> >> >>>>> >> >> >> >> >> On Mon, Aug 7, 2017 at 5:12 PM, Jom O'Fisher >>> >> >> >>>>> >> >> >> >> >> >>> >> >> >>>>> >> >> >> >> >> wrote: >>> >> >> >>>>> >> >> >> >> >> > Either option can work fine. Disclosure: I >>> >> >> >>>>> >> >> >> >> >> > work >>> >> >> >>>>> >> >> >> >> >> > on >>> >> >> >>>>> >> >> >> >> >> > Android >>> >> >> >>>>> >> >> >> >> >> > Studio >>> >> >> >>>>> >> >> >> >> >> > and >>> >> >> >>>>> >> >> >> >> >> > was >>> >> >> >>>>> >> >> >> >> >> > the one that added CMake support. >>> >> >> >>>>> >> >> >> >> >> > >>> >> >> >>>>> >> >> >> >> >> > Option (1) is the way it's designed to work >>> >> >> >>>>> >> >> >> >> >> > and >>> >> >> >>>>> >> >> >> >> >> > we're >>> >> >> >>>>> >> >> >> >> >> > working >>> >> >> >>>>> >> >> >> >> >> > toward >>> >> >> >>>>> >> >> >> >> >> > getting >>> >> >> >>>>> >> >> >> >> >> > rid of the need for the CMake fork. I can't >>> >> >> >>>>> >> >> >> >> >> > really >>> >> >> >>>>> >> >> >> >> >> > say >>> >> >> >>>>> >> >> >> >> >> > when >>> >> >> >>>>> >> >> >> >> >> > that >>> >> >> >>>>> >> >> >> >> >> > will >>> >> >> >>>>> >> >> >> >> >> > happen >>> >> >> >>>>> >> >> >> >> >> > but if you can get away with an older CMake >>> >> >> >>>>> >> >> >> >> >> > for >>> >> >> >>>>> >> >> >> >> >> > now >>> >> >> >>>>> >> >> >> >> >> > then I'd >>> >> >> >>>>> >> >> >> >> >> > go >>> >> >> >>>>> >> >> >> >> >> > this >>> >> >> >>>>> >> >> >> >> >> > way. >>> >> >> >>>>> >> >> >> >> >> > As you mentioned, option (1) will allow you >>> >> >> >>>>> >> >> >> >> >> > to >>> >> >> >>>>> >> >> >> >> >> > view >>> >> >> >>>>> >> >> >> >> >> > your >>> >> >> >>>>> >> >> >> >> >> > source >>> >> >> >>>>> >> >> >> >> >> > file >>> >> >> >>>>> >> >> >> >> >> > structure in Android Studio, edit files, and >>> >> >> >>>>> >> >> >> >> >> > debug >>> >> >> >>>>> >> >> >> >> >> > using the >>> >> >> >>>>> >> >> >> >> >> > built-in >>> >> >> >>>>> >> >> >> >> >> > debugging support. >>> >> >> >>>>> >> >> >> >> >> > >>> >> >> >>>>> >> >> >> >> >> > To get option (2) to work, you can use >>> >> >> >>>>> >> >> >> >> >> > jniDirs >>> >> >> >>>>> >> >> >> >> >> > setting >>> >> >> >>>>> >> >> >> >> >> > to >>> >> >> >>>>> >> >> >> >> >> > tell >>> >> >> >>>>> >> >> >> >> >> > Android >>> >> >> >>>>> >> >> >> >> >> > Gradle where to pick up your built .so files >>> >> >> >>>>> >> >> >> >> >> > (see >>> >> >> >>>>> >> >> >> >> >> > >>> >> >> >>>>> >> >> >> >> >> > >>> >> >> >>>>> >> >> >> >> >> > >>> >> >> >>>>> >> >> >> >> >> > >>> >> >> >>>>> >> >> >> >> >> > >>> >> >> >>>>> >> >> >> >> >> > >>> >> >> >>>>> >> >> >> >> >> > >>> >> >> >>>>> >> >> >> >> >> > >>> >> >> >>>>> >> >> >> >> >> > >>> >> >> >>>>> >> >> >> >> >> > https://stackoverflow.com/questions/21255125/how-can-i-add-so-files-to-an-android-library-project-using-gradle-0-7). >>> >> >> >>>>> >> >> >> >> >> > I'm not aware of any projects that use this >>> >> >> >>>>> >> >> >> >> >> > approach >>> >> >> >>>>> >> >> >> >> >> > but it >>> >> >> >>>>> >> >> >> >> >> > should >>> >> >> >>>>> >> >> >> >> >> > work >>> >> >> >>>>> >> >> >> >> >> > in >>> >> >> >>>>> >> >> >> >> >> > principal. >>> >> >> >>>>> >> >> >> >> >> > >>> >> >> >>>>> >> >> >> >> >> > I hope this helps, >>> >> >> >>>>> >> >> >> >> >> > Jomo >>> >> >> >>>>> >> >> >> >> >> > >>> >> >> >>>>> >> >> >> >> >> > >>> >> >> >>>>> >> >> >> >> >> > On Mon, Aug 7, 2017 at 11:09 AM, Robert >>> >> >> >>>>> >> >> >> >> >> > Dailey >>> >> >> >>>>> >> >> >> >> >> > >>> >> >> >>>>> >> >> >> >> >> > wrote: >>> >> >> >>>>> >> >> >> >> >> >> >>> >> >> >>>>> >> >> >> >> >> >> Right now I have custom targets set to >>> >> >> >>>>> >> >> >> >> >> >> execute >>> >> >> >>>>> >> >> >> >> >> >> the >>> >> >> >>>>> >> >> >> >> >> >> "ant >>> >> >> >>>>> >> >> >> >> >> >> release" >>> >> >> >>>>> >> >> >> >> >> >> command after my native targets are built. >>> >> >> >>>>> >> >> >> >> >> >> Part >>> >> >> >>>>> >> >> >> >> >> >> of >>> >> >> >>>>> >> >> >> >> >> >> that >>> >> >> >>>>> >> >> >> >> >> >> command >>> >> >> >>>>> >> >> >> >> >> >> involves copying *.so files to the >>> >> >> >>>>> >> >> >> >> >> >> libs/armeabi-v7a >>> >> >> >>>>> >> >> >> >> >> >> directory >>> >> >> >>>>> >> >> >> >> >> >> so >>> >> >> >>>>> >> >> >> >> >> >> they >>> >> >> >>>>> >> >> >> >> >> >> get packaged in an APK. >>> >> >> >>>>> >> >> >> >> >> >> >>> >> >> >>>>> >> >> >> >> >> >> When switching to gradle, I have two >>> >> >> >>>>> >> >> >> >> >> >> options: >>> >> >> >>>>> >> >> >> >> >> >> >>> >> >> >>>>> >> >> >> >> >> >> 1. Gradle drives CMake: This means using >>> >> >> >>>>> >> >> >> >> >> >> Android >>> >> >> >>>>> >> >> >> >> >> >> Studio and >>> >> >> >>>>> >> >> >> >> >> >> being >>> >> >> >>>>> >> >> >> >> >> >> locked down to Google's fork of CMake which >>> >> >> >>>>> >> >> >> >> >> >> is >>> >> >> >>>>> >> >> >> >> >> >> a >>> >> >> >>>>> >> >> >> >> >> >> few >>> >> >> >>>>> >> >> >> >> >> >> major >>> >> >> >>>>> >> >> >> >> >> >> releases >>> >> >> >>>>> >> >> >> >> >> >> behind. I see that as a negative. >>> >> >> >>>>> >> >> >> >> >> >> >>> >> >> >>>>> >> >> >> >> >> >> 2. CMake drives Gradle: This would be the >>> >> >> >>>>> >> >> >> >> >> >> same >>> >> >> >>>>> >> >> >> >> >> >> or >>> >> >> >>>>> >> >> >> >> >> >> similar >>> >> >> >>>>> >> >> >> >> >> >> to >>> >> >> >>>>> >> >> >> >> >> >> what >>> >> >> >>>>> >> >> >> >> >> >> I'm >>> >> >> >>>>> >> >> >> >> >> >> already doing: The custom targets I have >>> >> >> >>>>> >> >> >> >> >> >> would >>> >> >> >>>>> >> >> >> >> >> >> execute >>> >> >> >>>>> >> >> >> >> >> >> gradle >>> >> >> >>>>> >> >> >> >> >> >> as >>> >> >> >>>>> >> >> >> >> >> >> a >>> >> >> >>>>> >> >> >> >> >> >> separate build step, instead of running ant >>> >> >> >>>>> >> >> >> >> >> >> commands. >>> >> >> >>>>> >> >> >> >> >> >> I'm >>> >> >> >>>>> >> >> >> >> >> >> not >>> >> >> >>>>> >> >> >> >> >> >> too >>> >> >> >>>>> >> >> >> >> >> >> familiar with Gradle, so I'm not sure how >>> >> >> >>>>> >> >> >> >> >> >> you >>> >> >> >>>>> >> >> >> >> >> >> tell >>> >> >> >>>>> >> >> >> >> >> >> it >>> >> >> >>>>> >> >> >> >> >> >> where >>> >> >> >>>>> >> >> >> >> >> >> your >>> >> >> >>>>> >> >> >> >> >> >> shared libraries are for the APK packaging >>> >> >> >>>>> >> >> >> >> >> >> steps. >>> >> >> >>>>> >> >> >> >> >> >> >>> >> >> >>>>> >> >> >> >> >> >> Which does everyone recommend? Is anyone >>> >> >> >>>>> >> >> >> >> >> >> using >>> >> >> >>>>> >> >> >> >> >> >> one >>> >> >> >>>>> >> >> >> >> >> >> of >>> >> >> >>>>> >> >> >> >> >> >> these >>> >> >> >>>>> >> >> >> >> >> >> setups >>> >> >> >>>>> >> >> >> >> >> >> successfully? The downside to option 2 is >>> >> >> >>>>> >> >> >> >> >> >> probably >>> >> >> >>>>> >> >> >> >> >> >> no >>> >> >> >>>>> >> >> >> >> >> >> on-device >>> >> >> >>>>> >> >> >> >> >> >> native >>> >> >> >>>>> >> >> >> >> >> >> debugging since Android Studio probably >>> >> >> >>>>> >> >> >> >> >> >> can't >>> >> >> >>>>> >> >> >> >> >> >> handle >>> >> >> >>>>> >> >> >> >> >> >> gradle >>> >> >> >>>>> >> >> >> >> >> >> projects >>> >> >> >>>>> >> >> >> >> >> >> without any external CMake builds set up. >>> >> >> >>>>> >> >> >> >> >> >> >>> >> >> >>>>> >> >> >> >> >> >> Would like some general direction & advice >>> >> >> >>>>> >> >> >> >> >> >> before >>> >> >> >>>>> >> >> >> >> >> >> I >>> >> >> >>>>> >> >> >> >> >> >> move >>> >> >> >>>>> >> >> >> >> >> >> away >>> >> >> >>>>> >> >> >> >> >> >> from >>> >> >> >>>>> >> >> >> >> >> >> ANT. Thanks in advance. >>> >> >> >>>>> >> >> >> >> >> >> -- >>> >> >> >>>>> >> >> >> >> >> >> >>> >> >> >>>>> >> >> >> >> >> >> Powered by www.kitware.com >>> >> >> >>>>> >> >> >> >> >> >> >>> >> >> >>>>> >> >> >> >> >> >> Please keep messages on-topic and check the >>> >> >> >>>>> >> >> >> >> >> >> CMake >>> >> >> >>>>> >> >> >> >> >> >> FAQ >>> >> >> >>>>> >> >> >> >> >> >> at: >>> >> >> >>>>> >> >> >> >> >> >> http://www.cmake.org/Wiki/CMake_FAQ >>> >> >> >>>>> >> >> >> >> >> >> >>> >> >> >>>>> >> >> >> >> >> >> Kitware offers various services to support >>> >> >> >>>>> >> >> >> >> >> >> the >>> >> >> >>>>> >> >> >> >> >> >> CMake >>> >> >> >>>>> >> >> >> >> >> >> community. >>> >> >> >>>>> >> >> >> >> >> >> For >>> >> >> >>>>> >> >> >> >> >> >> more >>> >> >> >>>>> >> >> >> >> >> >> information on each offering, please visit: >>> >> >> >>>>> >> >> >> >> >> >> >>> >> >> >>>>> >> >> >> >> >> >> CMake Support: >>> >> >> >>>>> >> >> >> >> >> >> http://cmake.org/cmake/help/support.html >>> >> >> >>>>> >> >> >> >> >> >> CMake Consulting: >>> >> >> >>>>> >> >> >> >> >> >> http://cmake.org/cmake/help/consulting.html >>> >> >> >>>>> >> >> >> >> >> >> CMake Training Courses: >>> >> >> >>>>> >> >> >> >> >> >> http://cmake.org/cmake/help/training.html >>> >> >> >>>>> >> >> >> >> >> >> >>> >> >> >>>>> >> >> >> >> >> >> Visit other Kitware open-source projects at >>> >> >> >>>>> >> >> >> >> >> >> >>> >> >> >>>>> >> >> >> >> >> >> >>> >> >> >>>>> >> >> >> >> >> >> http://www.kitware.com/opensource/opensource.html >>> >> >> >>>>> >> >> >> >> >> >> >>> >> >> >>>>> >> >> >> >> >> >> Follow this link to subscribe/unsubscribe: >>> >> >> >>>>> >> >> >> >> >> >> >>> >> >> >>>>> >> >> >> >> >> >> >>> >> >> >>>>> >> >> >> >> >> >> http://public.kitware.com/mailman/listinfo/cmake >>> >> >> >>>>> >> >> >> >> >> > >>> >> >> >>>>> >> >> >> >> >> > >>> >> >> >>>>> >> >> >> >> > >>> >> >> >>>>> >> >> >> >> > >>> >> >> >>>>> >> >> >> > >>> >> >> >>>>> >> >> >> > >>> >> >> >>>>> >> >> > >>> >> >> >>>>> >> >> > >>> >> >> >>>>> >> > >>> >> >> >>>>> >> > >>> >> >> >>>>> > >>> >> >> >>>>> > >>> >> >> >>>> >>> >> >> >>>> >>> >> >> >>> >>> >> >> >> >>> >> > >>> >> > >>> > >>> > >> >> > From johannes.zarl-zierl at jku.at Mon Aug 28 06:37:54 2017 From: johannes.zarl-zierl at jku.at (Johannes Zarl-Zierl) Date: Mon, 28 Aug 2017 12:37:54 +0200 Subject: [CMake] Should configuration package files define module package variables? In-Reply-To: References: Message-ID: <1608413.XtOvK6MiR6@ersa> Hi, On Freitag, 25. August 2017 11:21:50 CEST Robert Dailey wrote: > However, what I'm wondering is even though the import targets should > contain all information about include directories, libraries, etc, > should I still define the typical Foo_INCLUDE_DIRS, Foo_LIBRARIES > variables? This depends very much on the target audience of your config.cmake file. My personal opinion is that you can skip those variables entirely for new projects. (Somebody please correct me if I'm wrong!) > It seems like Module packages are being deprecated > in favor of Config packages, because it puts the responsibility of > maintaining find package logic on the upstream maintainer (config > package) instead of on CMake (module packages it ships with). Yes. This has been the case since cmake 2.8 or so. A general rule of thumb for module vs. config: If you are the upstream: create a config package. If the upstream is somebody else, but uses cmake: submit a patch and get them to provide a config package. If the upstream does not use cmake: they can still provide a config package. If all else fails: add a module to your project to find the upstream library. Cheers, Johannes P.S.: And yes: creating a config package has a steep learning curve. Link [2] has all the information you need, but it is hardly a nice tutorial... From rcdailey.lists at gmail.com Tue Aug 29 10:27:25 2017 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Tue, 29 Aug 2017 09:27:25 -0500 Subject: [CMake] Debugging find_package() search behavior? In-Reply-To: References: Message-ID: I want to clarify my post since I've spent some more time on this. find_package() doesn't seem to work intuitively on Windows. On Linux, for example, installation prefixes are like "/usr/local", so if I'm building & installing a library in linux, you'd get a structure like: /usr/local/include /usr/local/lib /usr/local/bin On Windows, if I make the prefix "C:/Program Files", then you get: C:/Program Files/include C:/Program Files/lib C:/Program Files/bin This is not the idiomatic way to install libraries on windows. Instead, it should be: C:/Program Files/MyLibrary/include C:/Program Files/MyLibrary/lib C:/Program Files/MyLibrary/bin I can achieve this during installation by setting my CMAKE_INSTALL_PREFIX to "C:/Program Files/MyLibrary", however CMAKE_INSTALL_PREFIX seems like it should be different when used with find_package(). After doing tons of reading, the search behavior for find_package() is very confusing outside of linux. Combined with CMAKE_FIND_ROOT_PATH, I have no idea what the heck these should be on Windows. Suppose I want to use a super build to build a lot of third party libraries and install them relative to my CMAKE_BINARY_DIR, and completely ignore system root paths for find_package() searching. My first instinct would be to do this: -D CMAKE_FIND_ROOT_PATH=${CMAKE_BINARY_DIR}/installed_libraries -D CMAKE_INSTALL_PREFIX=${name_of_library} Note that there are two goals: 1. The library being built must install its files to ${CMAKE_BINARY_DIR}/installed_libraries/${name_of_library} 2. Any find_package() invocations made by the library being built should search within ${CMAKE_BINARY_DIR}/installed_libraries I'm relying on the two variables above to control this behavior, but CMAKE_INSTALL_PREFIX doesn't work well for both purposes. I can't make it relative on Windows because it puts it somewhere random on my filesystem, I think in program files. I'm not sure what CMAKE_INSTALL_PREFIX does if it isn't an absolute path (but based on linux behavior it should just append to the end of CMAKE_FIND_ROOT_PATH I think?) How can I get the proper install & find_package behavior on Windows based on the requirements above? On Sun, Aug 27, 2017 at 2:55 PM, Robert Dailey wrote: > So I'm trying to get CMake to find a package, and it isn't finding it. > I am setting CMAKE_PREFIX_PATH to try to get it to find it. Is there a > way I can view the search paths & prefixes that CMake is using with > each find_package() call? I tried enabling debug and trace output, but > neither of these seem to show any detail of what happens internally > with find_package() searches. > > Thanks in advance. From brad.king at kitware.com Tue Aug 29 10:33:57 2017 From: brad.king at kitware.com (Brad King) Date: Tue, 29 Aug 2017 10:33:57 -0400 Subject: [CMake] [cmake-developers] Debugging find_package() search behavior? In-Reply-To: References: Message-ID: <510be935-cc46-76f4-42fd-eecb80d5c017@kitware.com> On 08/29/2017 10:27 AM, Robert Dailey wrote: > I'm relying on the two variables above to control this behavior, but > CMAKE_INSTALL_PREFIX doesn't work well for both purposes. Use CMAKE_PREFIX_PATH, not CMAKE_INSTALL_PREFIX, to control the set of prefixes that find commands search. -Brad From rcdailey.lists at gmail.com Tue Aug 29 10:48:54 2017 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Tue, 29 Aug 2017 09:48:54 -0500 Subject: [CMake] [cmake-developers] Debugging find_package() search behavior? In-Reply-To: <510be935-cc46-76f4-42fd-eecb80d5c017@kitware.com> References: <510be935-cc46-76f4-42fd-eecb80d5c017@kitware.com> Message-ID: I am doing that. Here is a live example: Library is zlib, installed here: E:\code\frontend\msvc_2015\third_party\installed\zlib (has include, lib, bin, share inside it) I set the following variables (Using the set() command (non-cache) inside my CMake script, before the find_package calls): CMAKE_PREFIX_PATH: E:/code/frontend/msvc_2015/third_party/installed CMAKE_FIND_ROOT_PATH: E:/code/frontend/msvc_2015/third_party/installed And then the find_package() command is executed: find_package( ZLIB 1.2.11 EXACT REQUIRED ) And fails with: CMake Error at E:/Program Files/CMake/share/cmake-3.9/Modules/FindPackageHandleStandardArgs.cmake:137 (message): Could NOT find ZLIB (missing: ZLIB_LIBRARY ZLIB_INCLUDE_DIR) (Required is exact version "1.2.11") Call Stack (most recent call first): E:/Program Files/CMake/share/cmake-3.9/Modules/FindPackageHandleStandardArgs.cmake:377 (_FPHSA_FAILURE_MESSAGE) E:/Program Files/CMake/share/cmake-3.9/Modules/FindZLIB.cmake:112 (FIND_PACKAGE_HANDLE_STANDARD_ARGS) Core/ThirdParty/zlib/CMakeLists.txt:6 (find_package) On Tue, Aug 29, 2017 at 9:33 AM, Brad King wrote: > On 08/29/2017 10:27 AM, Robert Dailey wrote: >> I'm relying on the two variables above to control this behavior, but >> CMAKE_INSTALL_PREFIX doesn't work well for both purposes. > > Use CMAKE_PREFIX_PATH, not CMAKE_INSTALL_PREFIX, to control > the set of prefixes that find commands search. > > -Brad From brad.king at kitware.com Tue Aug 29 10:55:28 2017 From: brad.king at kitware.com (Brad King) Date: Tue, 29 Aug 2017 10:55:28 -0400 Subject: [CMake] [cmake-developers] Debugging find_package() search behavior? In-Reply-To: References: <510be935-cc46-76f4-42fd-eecb80d5c017@kitware.com> Message-ID: <62660e7c-a1a5-8480-a2ee-4efeb46531cd@kitware.com> On 08/29/2017 10:48 AM, Robert Dailey wrote: > CMAKE_PREFIX_PATH: E:/code/frontend/msvc_2015/third_party/installed > CMAKE_FIND_ROOT_PATH: E:/code/frontend/msvc_2015/third_party/installed I'm not sure how CMAKE_FIND_ROOT_PATH's path re-rooting interacts with drive letters on Windows. -Brad From brad.king at kitware.com Tue Aug 29 10:56:34 2017 From: brad.king at kitware.com (Brad King) Date: Tue, 29 Aug 2017 10:56:34 -0400 Subject: [CMake] [cmake-developers] Debugging find_package() search behavior? In-Reply-To: <62660e7c-a1a5-8480-a2ee-4efeb46531cd@kitware.com> References: <510be935-cc46-76f4-42fd-eecb80d5c017@kitware.com> <62660e7c-a1a5-8480-a2ee-4efeb46531cd@kitware.com> Message-ID: On 08/29/2017 10:55 AM, Brad King wrote: > On 08/29/2017 10:48 AM, Robert Dailey wrote: >> CMAKE_PREFIX_PATH: E:/code/frontend/msvc_2015/third_party/installed >> CMAKE_FIND_ROOT_PATH: E:/code/frontend/msvc_2015/third_party/installed > > I'm not sure how CMAKE_FIND_ROOT_PATH's path re-rooting interacts with > drive letters on Windows. Oops, sent too soon. CMAKE_FIND_ROOT_PATH should not be necessary here. It's for cross-compiling to re-root paths like `/usr` into some prefix on the host. -Brad From rcdailey.lists at gmail.com Tue Aug 29 11:01:33 2017 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Tue, 29 Aug 2017 10:01:33 -0500 Subject: [CMake] [cmake-developers] Debugging find_package() search behavior? In-Reply-To: References: <510be935-cc46-76f4-42fd-eecb80d5c017@kitware.com> <62660e7c-a1a5-8480-a2ee-4efeb46531cd@kitware.com> Message-ID: On Tue, Aug 29, 2017 at 9:56 AM, Brad King wrote: > On 08/29/2017 10:55 AM, Brad King wrote: >> On 08/29/2017 10:48 AM, Robert Dailey wrote: >>> CMAKE_PREFIX_PATH: E:/code/frontend/msvc_2015/third_party/installed >>> CMAKE_FIND_ROOT_PATH: E:/code/frontend/msvc_2015/third_party/installed >> >> I'm not sure how CMAKE_FIND_ROOT_PATH's path re-rooting interacts with >> drive letters on Windows. > > Oops, sent too soon. > > CMAKE_FIND_ROOT_PATH should not be necessary here. It's for cross-compiling > to re-root paths like `/usr` into some prefix on the host. > > -Brad Ok but even if I remove that, find_package() still isn't working...... From DLRdave at aol.com Tue Aug 29 11:06:34 2017 From: DLRdave at aol.com (David Cole) Date: Tue, 29 Aug 2017 11:06:34 -0400 Subject: [CMake] [cmake-developers] Debugging find_package() search behavior? In-Reply-To: References: <510be935-cc46-76f4-42fd-eecb80d5c017@kitware.com> <62660e7c-a1a5-8480-a2ee-4efeb46531cd@kitware.com> Message-ID: Shouldn't the "/zlib" at the end be included in your CMAKE_PREFIX_PATH? On Tue, Aug 29, 2017 at 11:01 AM, Robert Dailey wrote: > On Tue, Aug 29, 2017 at 9:56 AM, Brad King wrote: >> On 08/29/2017 10:55 AM, Brad King wrote: >>> On 08/29/2017 10:48 AM, Robert Dailey wrote: >>>> CMAKE_PREFIX_PATH: E:/code/frontend/msvc_2015/third_party/installed >>>> CMAKE_FIND_ROOT_PATH: E:/code/frontend/msvc_2015/third_party/installed >>> >>> I'm not sure how CMAKE_FIND_ROOT_PATH's path re-rooting interacts with >>> drive letters on Windows. >> >> Oops, sent too soon. >> >> CMAKE_FIND_ROOT_PATH should not be necessary here. It's for cross-compiling >> to re-root paths like `/usr` into some prefix on the host. >> >> -Brad > > Ok but even if I remove that, find_package() still isn't working...... > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake From rcdailey.lists at gmail.com Tue Aug 29 11:11:36 2017 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Tue, 29 Aug 2017 10:11:36 -0500 Subject: [CMake] [cmake-developers] Debugging find_package() search behavior? In-Reply-To: References: <510be935-cc46-76f4-42fd-eecb80d5c017@kitware.com> <62660e7c-a1a5-8480-a2ee-4efeb46531cd@kitware.com> Message-ID: What I'm hoping for is that find_package() follows the rules it documents here: https://cmake.org/cmake/help/v3.6/command/find_package.html Specifically, it states it searches these paths (and that is treated case-insensitive): / (W) /(cmake|CMake)/ (W) /*/ (W) /*/(cmake|CMake)/ (W) /(lib/|lib|share)/cmake/*/ (U) /(lib/|lib|share)/*/ (U) /(lib/|lib|share)/*/(cmake|CMake)/ (U) If this is true, then the 3rd one from the top should be a match, because is set to: E:/code/frontend/msvc_2015/third_party/installed And is set to ZLIB in find_package() first argument, so it should be adding that to the end. I need to keep CMAKE_PREFIX_PATH pointing to the parent directory ("installed") because I have other libraries that get installed in that directory, each with their own directory to contain their installation files. If find_package() is appending to like it says it should, it should find each one of them without switching the value of CMAKE_PREFIX_PATH. Am I misunderstanding something? On Tue, Aug 29, 2017 at 10:06 AM, David Cole wrote: > Shouldn't the "/zlib" at the end be included in your CMAKE_PREFIX_PATH? > > On Tue, Aug 29, 2017 at 11:01 AM, Robert Dailey > wrote: >> On Tue, Aug 29, 2017 at 9:56 AM, Brad King wrote: >>> On 08/29/2017 10:55 AM, Brad King wrote: >>>> On 08/29/2017 10:48 AM, Robert Dailey wrote: >>>>> CMAKE_PREFIX_PATH: E:/code/frontend/msvc_2015/third_party/installed >>>>> CMAKE_FIND_ROOT_PATH: E:/code/frontend/msvc_2015/third_party/installed >>>> >>>> I'm not sure how CMAKE_FIND_ROOT_PATH's path re-rooting interacts with >>>> drive letters on Windows. >>> >>> Oops, sent too soon. >>> >>> CMAKE_FIND_ROOT_PATH should not be necessary here. It's for cross-compiling >>> to re-root paths like `/usr` into some prefix on the host. >>> >>> -Brad >> >> Ok but even if I remove that, find_package() still isn't working...... >> -- >> >> Powered by www.kitware.com >> >> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ >> >> Kitware offers various services to support the CMake community. For more information on each offering, please visit: >> >> CMake Support: http://cmake.org/cmake/help/support.html >> CMake Consulting: http://cmake.org/cmake/help/consulting.html >> CMake Training Courses: http://cmake.org/cmake/help/training.html >> >> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/cmake From rcdailey.lists at gmail.com Tue Aug 29 11:25:15 2017 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Tue, 29 Aug 2017 10:25:15 -0500 Subject: [CMake] [cmake-developers] Debugging find_package() search behavior? In-Reply-To: References: <510be935-cc46-76f4-42fd-eecb80d5c017@kitware.com> <62660e7c-a1a5-8480-a2ee-4efeb46531cd@kitware.com> Message-ID: I think the discrepancy here might be config vs module find mode. The documentation I linked seems to be for config mode only, however I'm utilizing the CMake-shipped FindZLIB.cmake module to find this particular library. Does this offer no guarantees on how CMAKE_PREFIX_PATH is used? On Tue, Aug 29, 2017 at 10:11 AM, Robert Dailey wrote: > What I'm hoping for is that find_package() follows the rules it > documents here: > https://cmake.org/cmake/help/v3.6/command/find_package.html > > Specifically, it states it searches these paths (and that is > treated case-insensitive): > > / (W) > /(cmake|CMake)/ (W) > /*/ (W) > /*/(cmake|CMake)/ (W) > /(lib/|lib|share)/cmake/*/ (U) > /(lib/|lib|share)/*/ (U) > /(lib/|lib|share)/*/(cmake|CMake)/ (U) > > If this is true, then the 3rd one from the top should be a match, > because is set to: > > E:/code/frontend/msvc_2015/third_party/installed > > And is set to ZLIB in find_package() first argument, so it > should be adding that to the end. > > I need to keep CMAKE_PREFIX_PATH pointing to the parent directory > ("installed") because I have other libraries that get installed in > that directory, each with their own directory to contain their > installation files. If find_package() is appending to > like it says it should, it should find each one of them without > switching the value of CMAKE_PREFIX_PATH. > > Am I misunderstanding something? > > > On Tue, Aug 29, 2017 at 10:06 AM, David Cole wrote: >> Shouldn't the "/zlib" at the end be included in your CMAKE_PREFIX_PATH? >> >> On Tue, Aug 29, 2017 at 11:01 AM, Robert Dailey >> wrote: >>> On Tue, Aug 29, 2017 at 9:56 AM, Brad King wrote: >>>> On 08/29/2017 10:55 AM, Brad King wrote: >>>>> On 08/29/2017 10:48 AM, Robert Dailey wrote: >>>>>> CMAKE_PREFIX_PATH: E:/code/frontend/msvc_2015/third_party/installed >>>>>> CMAKE_FIND_ROOT_PATH: E:/code/frontend/msvc_2015/third_party/installed >>>>> >>>>> I'm not sure how CMAKE_FIND_ROOT_PATH's path re-rooting interacts with >>>>> drive letters on Windows. >>>> >>>> Oops, sent too soon. >>>> >>>> CMAKE_FIND_ROOT_PATH should not be necessary here. It's for cross-compiling >>>> to re-root paths like `/usr` into some prefix on the host. >>>> >>>> -Brad >>> >>> Ok but even if I remove that, find_package() still isn't working...... >>> -- >>> >>> Powered by www.kitware.com >>> >>> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ >>> >>> Kitware offers various services to support the CMake community. For more information on each offering, please visit: >>> >>> CMake Support: http://cmake.org/cmake/help/support.html >>> CMake Consulting: http://cmake.org/cmake/help/consulting.html >>> CMake Training Courses: http://cmake.org/cmake/help/training.html >>> >>> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html >>> >>> Follow this link to subscribe/unsubscribe: >>> http://public.kitware.com/mailman/listinfo/cmake From DLRdave at aol.com Tue Aug 29 11:31:57 2017 From: DLRdave at aol.com (David Cole) Date: Tue, 29 Aug 2017 11:31:57 -0400 Subject: [CMake] [cmake-developers] Debugging find_package() search behavior? In-Reply-To: References: <510be935-cc46-76f4-42fd-eecb80d5c017@kitware.com> <62660e7c-a1a5-8480-a2ee-4efeb46531cd@kitware.com> Message-ID: Is there a ZLIBConfig.cmake file which find_package is searching for? (i.e. -- somewhere under that directory does that file exist?) On Windows the case won't matter, but on Linux, a find_package(ZLIB will expect a case-sensitive match on a ZLIBConfig.cmake file. If ZLIBConfig.cmake exists, it needs to exist in one of the locations on that find_package documentation snippet you sent. If it's not directly in the "zlib" folder, or one of the other folders listed, then it won't be found. The directory it is in, or something matching one of those in the list needs to be included in your CMAKE_PREFIX_PATH. If that file does not exist, then the CMake FindZLIB.cmake module will be used in an attempt to find your zlib... And the help for that speaks of setting a ZLIB_ROOT var if you want to direct it to find a given zlib. See the "HINTS" section here: https://cmake.org/cmake/help/v3.6/module/FindZLIB.html#hints One more hint regarding CMAKE_PREFIX_PATH : despite its name, it is a **list** of paths, and you can use multiple semi-colon separated values if necessary. So, if appending "/zlib" works, then you could always find zlib and all your other stuff too by using two directories as your CMAKE_PREFIX_PATH value. HTH, David C. On Tue, Aug 29, 2017 at 11:11 AM, Robert Dailey wrote: > What I'm hoping for is that find_package() follows the rules it > documents here: > https://cmake.org/cmake/help/v3.6/command/find_package.html > > Specifically, it states it searches these paths (and that is > treated case-insensitive): > > / (W) > /(cmake|CMake)/ (W) > /*/ (W) > /*/(cmake|CMake)/ (W) > /(lib/|lib|share)/cmake/*/ (U) > /(lib/|lib|share)/*/ (U) > /(lib/|lib|share)/*/(cmake|CMake)/ (U) > > If this is true, then the 3rd one from the top should be a match, > because is set to: > > E:/code/frontend/msvc_2015/third_party/installed > > And is set to ZLIB in find_package() first argument, so it > should be adding that to the end. > > I need to keep CMAKE_PREFIX_PATH pointing to the parent directory > ("installed") because I have other libraries that get installed in > that directory, each with their own directory to contain their > installation files. If find_package() is appending to > like it says it should, it should find each one of them without > switching the value of CMAKE_PREFIX_PATH. > > Am I misunderstanding something? > > > On Tue, Aug 29, 2017 at 10:06 AM, David Cole wrote: >> Shouldn't the "/zlib" at the end be included in your CMAKE_PREFIX_PATH? >> >> On Tue, Aug 29, 2017 at 11:01 AM, Robert Dailey >> wrote: >>> On Tue, Aug 29, 2017 at 9:56 AM, Brad King wrote: >>>> On 08/29/2017 10:55 AM, Brad King wrote: >>>>> On 08/29/2017 10:48 AM, Robert Dailey wrote: >>>>>> CMAKE_PREFIX_PATH: E:/code/frontend/msvc_2015/third_party/installed >>>>>> CMAKE_FIND_ROOT_PATH: E:/code/frontend/msvc_2015/third_party/installed >>>>> >>>>> I'm not sure how CMAKE_FIND_ROOT_PATH's path re-rooting interacts with >>>>> drive letters on Windows. >>>> >>>> Oops, sent too soon. >>>> >>>> CMAKE_FIND_ROOT_PATH should not be necessary here. It's for cross-compiling >>>> to re-root paths like `/usr` into some prefix on the host. >>>> >>>> -Brad >>> >>> Ok but even if I remove that, find_package() still isn't working...... >>> -- >>> >>> Powered by www.kitware.com >>> >>> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ >>> >>> Kitware offers various services to support the CMake community. For more information on each offering, please visit: >>> >>> CMake Support: http://cmake.org/cmake/help/support.html >>> CMake Consulting: http://cmake.org/cmake/help/consulting.html >>> CMake Training Courses: http://cmake.org/cmake/help/training.html >>> >>> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html >>> >>> Follow this link to subscribe/unsubscribe: >>> http://public.kitware.com/mailman/listinfo/cmake From DLRdave at aol.com Tue Aug 29 11:33:15 2017 From: DLRdave at aol.com (David Cole) Date: Tue, 29 Aug 2017 11:33:15 -0400 Subject: [CMake] [cmake-developers] Debugging find_package() search behavior? In-Reply-To: References: <510be935-cc46-76f4-42fd-eecb80d5c017@kitware.com> <62660e7c-a1a5-8480-a2ee-4efeb46531cd@kitware.com> Message-ID: That's correct: find modules do what they want, and most do not pay attention to CMAKE_PREFIX_PATH. It's better to use a config file, but when you have to use a find module, you have to dig in and figure out the right way to use each one. On Tue, Aug 29, 2017 at 11:25 AM, Robert Dailey wrote: > I think the discrepancy here might be config vs module find mode. The > documentation I linked seems to be for config mode only, however I'm > utilizing the CMake-shipped FindZLIB.cmake module to find this > particular library. Does this offer no guarantees on how > CMAKE_PREFIX_PATH is used? > > On Tue, Aug 29, 2017 at 10:11 AM, Robert Dailey > wrote: >> What I'm hoping for is that find_package() follows the rules it >> documents here: >> https://cmake.org/cmake/help/v3.6/command/find_package.html >> >> Specifically, it states it searches these paths (and that is >> treated case-insensitive): >> >> / (W) >> /(cmake|CMake)/ (W) >> /*/ (W) >> /*/(cmake|CMake)/ (W) >> /(lib/|lib|share)/cmake/*/ (U) >> /(lib/|lib|share)/*/ (U) >> /(lib/|lib|share)/*/(cmake|CMake)/ (U) >> >> If this is true, then the 3rd one from the top should be a match, >> because is set to: >> >> E:/code/frontend/msvc_2015/third_party/installed >> >> And is set to ZLIB in find_package() first argument, so it >> should be adding that to the end. >> >> I need to keep CMAKE_PREFIX_PATH pointing to the parent directory >> ("installed") because I have other libraries that get installed in >> that directory, each with their own directory to contain their >> installation files. If find_package() is appending to >> like it says it should, it should find each one of them without >> switching the value of CMAKE_PREFIX_PATH. >> >> Am I misunderstanding something? >> >> >> On Tue, Aug 29, 2017 at 10:06 AM, David Cole wrote: >>> Shouldn't the "/zlib" at the end be included in your CMAKE_PREFIX_PATH? >>> >>> On Tue, Aug 29, 2017 at 11:01 AM, Robert Dailey >>> wrote: >>>> On Tue, Aug 29, 2017 at 9:56 AM, Brad King wrote: >>>>> On 08/29/2017 10:55 AM, Brad King wrote: >>>>>> On 08/29/2017 10:48 AM, Robert Dailey wrote: >>>>>>> CMAKE_PREFIX_PATH: E:/code/frontend/msvc_2015/third_party/installed >>>>>>> CMAKE_FIND_ROOT_PATH: E:/code/frontend/msvc_2015/third_party/installed >>>>>> >>>>>> I'm not sure how CMAKE_FIND_ROOT_PATH's path re-rooting interacts with >>>>>> drive letters on Windows. >>>>> >>>>> Oops, sent too soon. >>>>> >>>>> CMAKE_FIND_ROOT_PATH should not be necessary here. It's for cross-compiling >>>>> to re-root paths like `/usr` into some prefix on the host. >>>>> >>>>> -Brad >>>> >>>> Ok but even if I remove that, find_package() still isn't working...... >>>> -- >>>> >>>> Powered by www.kitware.com >>>> >>>> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ >>>> >>>> Kitware offers various services to support the CMake community. For more information on each offering, please visit: >>>> >>>> CMake Support: http://cmake.org/cmake/help/support.html >>>> CMake Consulting: http://cmake.org/cmake/help/consulting.html >>>> CMake Training Courses: http://cmake.org/cmake/help/training.html >>>> >>>> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html >>>> >>>> Follow this link to subscribe/unsubscribe: >>>> http://public.kitware.com/mailman/listinfo/cmake From rcdailey.lists at gmail.com Tue Aug 29 11:43:03 2017 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Tue, 29 Aug 2017 10:43:03 -0500 Subject: [CMake] [cmake-developers] Debugging find_package() search behavior? In-Reply-To: References: <510be935-cc46-76f4-42fd-eecb80d5c017@kitware.com> <62660e7c-a1a5-8480-a2ee-4efeb46531cd@kitware.com> Message-ID: Thanks for your help, the problem is that I was expecting too much consistency between find module behavior. I'll treat them as if I have no guarantees. Last question: Are there guarantees with find modules and CMAKE_FIND_ROOT_PATH? I'm asking because on Android, when I use find_package(), behavior is different because the NDK's toolchain file sets: 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) list(APPEND CMAKE_FIND_ROOT_PATH "${ANDROID_NDK}") To try to "intercept" the search of NDK for libraries using find_package(), I try this: set( CMAKE_FIND_ROOT_PATH ${ZIOSK_THIRD_PARTY_INSTALL} ${CMAKE_FIND_ROOT_PATH} ) However, after running, it's always finding results in the NDK directory set by the toolchain file, even though I put mine first in the list. Furthermore, my install of zlib has the correct version, the NDK one does not, but it still says it founds the NDK version. On Tue, Aug 29, 2017 at 10:33 AM, David Cole wrote: > That's correct: > > find modules do what they want, and most do not pay attention to > CMAKE_PREFIX_PATH. > > It's better to use a config file, but when you have to use a find > module, you have to dig in and figure out the right way to use each > one. > > > > On Tue, Aug 29, 2017 at 11:25 AM, Robert Dailey > wrote: >> I think the discrepancy here might be config vs module find mode. The >> documentation I linked seems to be for config mode only, however I'm >> utilizing the CMake-shipped FindZLIB.cmake module to find this >> particular library. Does this offer no guarantees on how >> CMAKE_PREFIX_PATH is used? >> >> On Tue, Aug 29, 2017 at 10:11 AM, Robert Dailey >> wrote: >>> What I'm hoping for is that find_package() follows the rules it >>> documents here: >>> https://cmake.org/cmake/help/v3.6/command/find_package.html >>> >>> Specifically, it states it searches these paths (and that is >>> treated case-insensitive): >>> >>> / (W) >>> /(cmake|CMake)/ (W) >>> /*/ (W) >>> /*/(cmake|CMake)/ (W) >>> /(lib/|lib|share)/cmake/*/ (U) >>> /(lib/|lib|share)/*/ (U) >>> /(lib/|lib|share)/*/(cmake|CMake)/ (U) >>> >>> If this is true, then the 3rd one from the top should be a match, >>> because is set to: >>> >>> E:/code/frontend/msvc_2015/third_party/installed >>> >>> And is set to ZLIB in find_package() first argument, so it >>> should be adding that to the end. >>> >>> I need to keep CMAKE_PREFIX_PATH pointing to the parent directory >>> ("installed") because I have other libraries that get installed in >>> that directory, each with their own directory to contain their >>> installation files. If find_package() is appending to >>> like it says it should, it should find each one of them without >>> switching the value of CMAKE_PREFIX_PATH. >>> >>> Am I misunderstanding something? >>> >>> >>> On Tue, Aug 29, 2017 at 10:06 AM, David Cole wrote: >>>> Shouldn't the "/zlib" at the end be included in your CMAKE_PREFIX_PATH? >>>> >>>> On Tue, Aug 29, 2017 at 11:01 AM, Robert Dailey >>>> wrote: >>>>> On Tue, Aug 29, 2017 at 9:56 AM, Brad King wrote: >>>>>> On 08/29/2017 10:55 AM, Brad King wrote: >>>>>>> On 08/29/2017 10:48 AM, Robert Dailey wrote: >>>>>>>> CMAKE_PREFIX_PATH: E:/code/frontend/msvc_2015/third_party/installed >>>>>>>> CMAKE_FIND_ROOT_PATH: E:/code/frontend/msvc_2015/third_party/installed >>>>>>> >>>>>>> I'm not sure how CMAKE_FIND_ROOT_PATH's path re-rooting interacts with >>>>>>> drive letters on Windows. >>>>>> >>>>>> Oops, sent too soon. >>>>>> >>>>>> CMAKE_FIND_ROOT_PATH should not be necessary here. It's for cross-compiling >>>>>> to re-root paths like `/usr` into some prefix on the host. >>>>>> >>>>>> -Brad >>>>> >>>>> Ok but even if I remove that, find_package() still isn't working...... >>>>> -- >>>>> >>>>> Powered by www.kitware.com >>>>> >>>>> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ >>>>> >>>>> Kitware offers various services to support the CMake community. For more information on each offering, please visit: >>>>> >>>>> CMake Support: http://cmake.org/cmake/help/support.html >>>>> CMake Consulting: http://cmake.org/cmake/help/consulting.html >>>>> CMake Training Courses: http://cmake.org/cmake/help/training.html >>>>> >>>>> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html >>>>> >>>>> Follow this link to subscribe/unsubscribe: >>>>> http://public.kitware.com/mailman/listinfo/cmake From brad.king at kitware.com Tue Aug 29 11:49:17 2017 From: brad.king at kitware.com (Brad King) Date: Tue, 29 Aug 2017 11:49:17 -0400 Subject: [CMake] [cmake-developers] Debugging find_package() search behavior? In-Reply-To: References: <510be935-cc46-76f4-42fd-eecb80d5c017@kitware.com> <62660e7c-a1a5-8480-a2ee-4efeb46531cd@kitware.com> Message-ID: <6b08c4ed-17ec-0b07-2b9d-6b0ed170225b@kitware.com> On 08/29/2017 11:33 AM, David Cole wrote: > That's correct: > > find modules do what they want, and most do not pay attention to > CMAKE_PREFIX_PATH. CMAKE_PREFIX_PATH *is* used by find modules. The find modules use find_* commands, and those use CMAKE_PREFIX_PATH. See the documentation of find_library, find_path, etc. for details. Each command searches an appropriate `/` where `` is based on the kind of command doing the searching. -Brad From rcdailey.lists at gmail.com Tue Aug 29 11:50:37 2017 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Tue, 29 Aug 2017 10:50:37 -0500 Subject: [CMake] [cmake-developers] Debugging find_package() search behavior? In-Reply-To: References: <510be935-cc46-76f4-42fd-eecb80d5c017@kitware.com> <62660e7c-a1a5-8480-a2ee-4efeb46531cd@kitware.com> Message-ID: Wow even if I set ZLIB_ROOT, FindZLIB.cmake *still* won't find my zlib over the one provided by the Android NDK... Although I was able to get this working fine on Windows, it does not work with the NDK's toolchain file. On Tue, Aug 29, 2017 at 10:43 AM, Robert Dailey wrote: > Thanks for your help, the problem is that I was expecting too much > consistency between find module behavior. I'll treat them as if I have > no guarantees. > > Last question: Are there guarantees with find modules and > CMAKE_FIND_ROOT_PATH? I'm asking because on Android, when I use > find_package(), behavior is different because the NDK's toolchain file > sets: > > 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) > list(APPEND CMAKE_FIND_ROOT_PATH "${ANDROID_NDK}") > > To try to "intercept" the search of NDK for libraries using > find_package(), I try this: > > set( CMAKE_FIND_ROOT_PATH ${ZIOSK_THIRD_PARTY_INSTALL} ${CMAKE_FIND_ROOT_PATH} ) > > However, after running, it's always finding results in the NDK > directory set by the toolchain file, even though I put mine first in > the list. Furthermore, my install of zlib has the correct version, the > NDK one does not, but it still says it founds the NDK version. > > On Tue, Aug 29, 2017 at 10:33 AM, David Cole wrote: >> That's correct: >> >> find modules do what they want, and most do not pay attention to >> CMAKE_PREFIX_PATH. >> >> It's better to use a config file, but when you have to use a find >> module, you have to dig in and figure out the right way to use each >> one. >> >> >> >> On Tue, Aug 29, 2017 at 11:25 AM, Robert Dailey >> wrote: >>> I think the discrepancy here might be config vs module find mode. The >>> documentation I linked seems to be for config mode only, however I'm >>> utilizing the CMake-shipped FindZLIB.cmake module to find this >>> particular library. Does this offer no guarantees on how >>> CMAKE_PREFIX_PATH is used? >>> >>> On Tue, Aug 29, 2017 at 10:11 AM, Robert Dailey >>> wrote: >>>> What I'm hoping for is that find_package() follows the rules it >>>> documents here: >>>> https://cmake.org/cmake/help/v3.6/command/find_package.html >>>> >>>> Specifically, it states it searches these paths (and that is >>>> treated case-insensitive): >>>> >>>> / (W) >>>> /(cmake|CMake)/ (W) >>>> /*/ (W) >>>> /*/(cmake|CMake)/ (W) >>>> /(lib/|lib|share)/cmake/*/ (U) >>>> /(lib/|lib|share)/*/ (U) >>>> /(lib/|lib|share)/*/(cmake|CMake)/ (U) >>>> >>>> If this is true, then the 3rd one from the top should be a match, >>>> because is set to: >>>> >>>> E:/code/frontend/msvc_2015/third_party/installed >>>> >>>> And is set to ZLIB in find_package() first argument, so it >>>> should be adding that to the end. >>>> >>>> I need to keep CMAKE_PREFIX_PATH pointing to the parent directory >>>> ("installed") because I have other libraries that get installed in >>>> that directory, each with their own directory to contain their >>>> installation files. If find_package() is appending to >>>> like it says it should, it should find each one of them without >>>> switching the value of CMAKE_PREFIX_PATH. >>>> >>>> Am I misunderstanding something? >>>> >>>> >>>> On Tue, Aug 29, 2017 at 10:06 AM, David Cole wrote: >>>>> Shouldn't the "/zlib" at the end be included in your CMAKE_PREFIX_PATH? >>>>> >>>>> On Tue, Aug 29, 2017 at 11:01 AM, Robert Dailey >>>>> wrote: >>>>>> On Tue, Aug 29, 2017 at 9:56 AM, Brad King wrote: >>>>>>> On 08/29/2017 10:55 AM, Brad King wrote: >>>>>>>> On 08/29/2017 10:48 AM, Robert Dailey wrote: >>>>>>>>> CMAKE_PREFIX_PATH: E:/code/frontend/msvc_2015/third_party/installed >>>>>>>>> CMAKE_FIND_ROOT_PATH: E:/code/frontend/msvc_2015/third_party/installed >>>>>>>> >>>>>>>> I'm not sure how CMAKE_FIND_ROOT_PATH's path re-rooting interacts with >>>>>>>> drive letters on Windows. >>>>>>> >>>>>>> Oops, sent too soon. >>>>>>> >>>>>>> CMAKE_FIND_ROOT_PATH should not be necessary here. It's for cross-compiling >>>>>>> to re-root paths like `/usr` into some prefix on the host. >>>>>>> >>>>>>> -Brad >>>>>> >>>>>> Ok but even if I remove that, find_package() still isn't working...... >>>>>> -- >>>>>> >>>>>> Powered by www.kitware.com >>>>>> >>>>>> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ >>>>>> >>>>>> Kitware offers various services to support the CMake community. For more information on each offering, please visit: >>>>>> >>>>>> CMake Support: http://cmake.org/cmake/help/support.html >>>>>> CMake Consulting: http://cmake.org/cmake/help/consulting.html >>>>>> CMake Training Courses: http://cmake.org/cmake/help/training.html >>>>>> >>>>>> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html >>>>>> >>>>>> Follow this link to subscribe/unsubscribe: >>>>>> http://public.kitware.com/mailman/listinfo/cmake From brad.king at kitware.com Tue Aug 29 11:54:53 2017 From: brad.king at kitware.com (Brad King) Date: Tue, 29 Aug 2017 11:54:53 -0400 Subject: [CMake] [cmake-developers] Debugging find_package() search behavior? In-Reply-To: References: <510be935-cc46-76f4-42fd-eecb80d5c017@kitware.com> <62660e7c-a1a5-8480-a2ee-4efeb46531cd@kitware.com> Message-ID: On 08/29/2017 11:50 AM, Robert Dailey wrote: > Wow even if I set ZLIB_ROOT, FindZLIB.cmake *still* won't find my zlib > over the one provided by the Android NDK... > > Although I was able to get this working fine on Windows, it does not > work with the NDK's toolchain file. That's because the CMAKE_FIND_ROOT_PATH settings re-root all search paths to look only inside the NDK. This is one reason toolchain files should not be monolithic and should only be authored locally for the current machine. -Brad From rcdailey.lists at gmail.com Tue Aug 29 11:58:49 2017 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Tue, 29 Aug 2017 10:58:49 -0500 Subject: [CMake] [cmake-developers] Debugging find_package() search behavior? In-Reply-To: References: <510be935-cc46-76f4-42fd-eecb80d5c017@kitware.com> <62660e7c-a1a5-8480-a2ee-4efeb46531cd@kitware.com> Message-ID: On Tue, Aug 29, 2017 at 10:54 AM, Brad King wrote: > On 08/29/2017 11:50 AM, Robert Dailey wrote: >> Wow even if I set ZLIB_ROOT, FindZLIB.cmake *still* won't find my zlib >> over the one provided by the Android NDK... >> >> Although I was able to get this working fine on Windows, it does not >> work with the NDK's toolchain file. > > That's because the CMAKE_FIND_ROOT_PATH settings re-root all search > paths to look only inside the NDK. This is one reason toolchain files > should not be monolithic and should only be authored locally for the > current machine. But the documentation[1] says it's a list, so if I add my own directory to that list, it should search there right? [1]: https://cmake.org/cmake/help/v3.6/variable/CMAKE_FIND_ROOT_PATH.html From DLRdave at aol.com Tue Aug 29 12:02:48 2017 From: DLRdave at aol.com (David Cole) Date: Tue, 29 Aug 2017 12:02:48 -0400 Subject: [CMake] [cmake-developers] Debugging find_package() search behavior? In-Reply-To: <6b08c4ed-17ec-0b07-2b9d-6b0ed170225b@kitware.com> References: <510be935-cc46-76f4-42fd-eecb80d5c017@kitware.com> <62660e7c-a1a5-8480-a2ee-4efeb46531cd@kitware.com> <6b08c4ed-17ec-0b07-2b9d-6b0ed170225b@kitware.com> Message-ID: Sorry for the mis-statement. I stand corrected. However, it is true that there are many find modules with some differences in approach, and if you are using one, you need to read up on the individual documentation of that particular find module. Especially if you need to know how to tell it how to find the exact one you already know you have... On Tue, Aug 29, 2017 at 11:49 AM, Brad King wrote: > On 08/29/2017 11:33 AM, David Cole wrote: >> That's correct: >> >> find modules do what they want, and most do not pay attention to >> CMAKE_PREFIX_PATH. > > CMAKE_PREFIX_PATH *is* used by find modules. > > The find modules use find_* commands, and those use CMAKE_PREFIX_PATH. > See the documentation of find_library, find_path, etc. for details. > Each command searches an appropriate `/` where `` > is based on the kind of command doing the searching. > > -Brad From rcdailey.lists at gmail.com Tue Aug 29 12:21:42 2017 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Tue, 29 Aug 2017 11:21:42 -0500 Subject: [CMake] [cmake-developers] Debugging find_package() search behavior? In-Reply-To: References: <510be935-cc46-76f4-42fd-eecb80d5c017@kitware.com> <62660e7c-a1a5-8480-a2ee-4efeb46531cd@kitware.com> <6b08c4ed-17ec-0b07-2b9d-6b0ed170225b@kitware.com> Message-ID: Ok I debugged find_path() code in CMake and I determined the problem. First, let me explain what I'm doing a little more... I build third party libraries on demand during configure step in CMake. I do so via execute_process() to invoke another CMake instance, that builds and installs a library. This is similar to how ExternalProject_Add() works, but forces it to happen at configure time so I can use find_package() afterwards to find the library I just built. Each library first tries to be found, and if not found, I build it then try to find it again. Like so: ``` set( library_version 1.2.11 ) set( ZLIB_ROOT ${ZIOSK_THIRD_PARTY_INSTALL} ) find_package( ZLIB ${library_version} EXACT ) if( NOT ZLIB_FOUND OR NOT library_version VERSION_EQUAL ZLIB_VERSION_STRING ) build_third_party_library( CLEAN_BUILD ) find_package( ZLIB ${library_version} EXACT REQUIRED ) endif() ``` When Android's Toolchain is in use, this is what happens: 1. find_package() happens, it finds zlib under android NDK's root, but doesn't accept it because of a version mismatch (since I use the EXACT option) 2. I build the third party library with execute_process() 3. Second find_package() happens, but "AlreadyInCache" is true (line 28 in cmFindPathCommand.cxx) this time, so it doesn't search for it again. Hard to tell where the bug is here. I'd argue that AlreadyInCache shouldn't be set to true since an exact version was not found, and the next find_package() command should do a full path search. Is this a bug in the C++ code or the find module script? What determines the AlreadyInCache variable? On Tue, Aug 29, 2017 at 11:02 AM, David Cole wrote: > Sorry for the mis-statement. I stand corrected. > > However, it is true that there are many find modules with some > differences in approach, and if you are using one, you need to read up > on the individual documentation of that particular find module. > Especially if you need to know how to tell it how to find the exact > one you already know you have... > > > > > On Tue, Aug 29, 2017 at 11:49 AM, Brad King wrote: >> On 08/29/2017 11:33 AM, David Cole wrote: >>> That's correct: >>> >>> find modules do what they want, and most do not pay attention to >>> CMAKE_PREFIX_PATH. >> >> CMAKE_PREFIX_PATH *is* used by find modules. >> >> The find modules use find_* commands, and those use CMAKE_PREFIX_PATH. >> See the documentation of find_library, find_path, etc. for details. >> Each command searches an appropriate `/` where `` >> is based on the kind of command doing the searching. >> >> -Brad From brad.king at kitware.com Tue Aug 29 12:37:49 2017 From: brad.king at kitware.com (Brad King) Date: Tue, 29 Aug 2017 12:37:49 -0400 Subject: [CMake] [cmake-developers] Debugging find_package() search behavior? In-Reply-To: References: <510be935-cc46-76f4-42fd-eecb80d5c017@kitware.com> <62660e7c-a1a5-8480-a2ee-4efeb46531cd@kitware.com> <6b08c4ed-17ec-0b07-2b9d-6b0ed170225b@kitware.com> Message-ID: On 08/29/2017 12:21 PM, Robert Dailey wrote: > 3. Second find_package() happens, but "AlreadyInCache" is true (line > 28 in cmFindPathCommand.cxx) this time, so it doesn't search for it > again. > > Hard to tell where the bug is here. I'd argue that AlreadyInCache > shouldn't be set to true since an exact version was not found>, and the > next find_package() command should do a full path search. Is this a > bug in the C++ code or the find module script? What determines the > AlreadyInCache variable? This is one of the problems with find modules. The individual find_* call result *was* found and is already cached. There is no way to tell that apart from the user setting it explicitly in the cache. That it proved insufficient for FPHSA's version check is not the concern of the find_ command. The find_package "config" mode uses only a single result variable and performs a version check before setting it, so it can do multiple searches like that. Find modules can't do that because they need to search for things piecemeal. At most they can report at the end that whatever was found is not suitable. In typical use cases with only a single find_package call it is then up to the user to correct the cached settings. -Brad From jeanmichael.celerier at gmail.com Tue Aug 29 12:46:21 2017 From: jeanmichael.celerier at gmail.com (=?UTF-8?Q?Jean=2DMicha=C3=ABl_Celerier?=) Date: Tue, 29 Aug 2017 18:46:21 +0200 Subject: [CMake] [cmake-developers] Debugging find_package() search behavior? In-Reply-To: <6b08c4ed-17ec-0b07-2b9d-6b0ed170225b@kitware.com> References: <510be935-cc46-76f4-42fd-eecb80d5c017@kitware.com> <62660e7c-a1a5-8480-a2ee-4efeb46531cd@kitware.com> <6b08c4ed-17ec-0b07-2b9d-6b0ed170225b@kitware.com> Message-ID: > The find modules use find_* commands, and those use CMAKE_PREFIX_PATH. Not always, some people sometimes feel like doing it by hand from scratch with if(EXISTS ...). Sadly. On Tue, Aug 29, 2017 at 5:49 PM, Brad King wrote: > On 08/29/2017 11:33 AM, David Cole wrote: > > That's correct: > > > > find modules do what they want, and most do not pay attention to > > CMAKE_PREFIX_PATH. > > CMAKE_PREFIX_PATH *is* used by find modules. > > The find modules use find_* commands, and those use CMAKE_PREFIX_PATH. > See the documentation of find_library, find_path, etc. for details. > Each command searches an appropriate `/` where `` > is based on the kind of command doing the searching. > > -Brad > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/ > opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake-developers > -------------- next part -------------- An HTML attachment was scrubbed... URL: From me at shawnliu.me Wed Aug 30 01:04:43 2017 From: me at shawnliu.me (Siyuan Liu) Date: Wed, 30 Aug 2017 13:04:43 +0800 Subject: [CMake] Future direction for FindCUDA Message-ID: <1504069483.3443296.1089392080.7AED2035@webmail.messagingengine.com> Dear all, I've noticed the change to CUDA as a language in CMake 3.8. I've migrated to this new syntax, but this change leads to some difficulties for me with CMake. I think we should treat CUDA as not just a language but rather a language with some libraries. Now that the FindCUDA module is deprecated, I cannot compile a file with GCC while linking to a CUDA library (since the CUDA_xxx_LIBRARY variables are gone). The reason for not using NVCC is to save compilation time. Personally, I think FindCUDA should become a module for purely finding CUDA libraries for linking without anything related to the NVCC compiler (e.g. the cuda_add_executable macro). My questions in short: 1. Can I link to CUDA libraries with GCC while not using FindCUDA? 2. What's your opinion on my suggestion about FindCUDA? Regards, Siyuan From Johannes.Sebastian.Mueller-Roemer at igd.fraunhofer.de Wed Aug 30 05:06:00 2017 From: Johannes.Sebastian.Mueller-Roemer at igd.fraunhofer.de (Mueller-Roemer, Johannes Sebastian) Date: Wed, 30 Aug 2017 09:06:00 +0000 Subject: [CMake] Future direction for FindCUDA In-Reply-To: <1504069483.3443296.1089392080.7AED2035@webmail.messagingengine.com> References: <1504069483.3443296.1089392080.7AED2035@webmail.messagingengine.com> Message-ID: <8D981219EEA621479C112DA9BDC39A8E7098EED4@EXMBS2.ad.igd.fraunhofer.de> Hi, we have encountered this issue as well, in our case when using thrust on the host side. We currently solve this by still using FindCUDA, even when using CMake 3.8/3.9, but only using the CUDA_*_LIBRARY and CUDA_TOOLKIT_INCLUDE variables and nothing else. Instead of modifying what FindCUDA does, which would break backwards compatibility, FindCUDA could be split into FindCUDA and FindCUDALibraries or something like that. Regards Johannes Fraunhofer-Institut f?r Graphische Datenverarbeitung IGD Fraunhoferstr. 5? |? 64283 Darmstadt? |? Germany Tel +49 6151 155-606? |? Fax +49 6151 155-139 johannes.mueller-roemer at igd.fraunhofer.de | www.igd.fraunhofer.de -----Original Message----- From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Siyuan Liu Sent: Wednesday, August 30, 2017 07:05 To: cmake at cmake.org Subject: [CMake] Future direction for FindCUDA Dear all, I've noticed the change to CUDA as a language in CMake 3.8. I've migrated to this new syntax, but this change leads to some difficulties for me with CMake. I think we should treat CUDA as not just a language but rather a language with some libraries. Now that the FindCUDA module is deprecated, I cannot compile a file with GCC while linking to a CUDA library (since the CUDA_xxx_LIBRARY variables are gone). The reason for not using NVCC is to save compilation time. Personally, I think FindCUDA should become a module for purely finding CUDA libraries for linking without anything related to the NVCC compiler (e.g. the cuda_add_executable macro). My questions in short: 1. Can I link to CUDA libraries with GCC while not using FindCUDA? 2. What's your opinion on my suggestion about FindCUDA? Regards, Siyuan -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake From robert.maynard at kitware.com Wed Aug 30 13:37:29 2017 From: robert.maynard at kitware.com (Robert Maynard) Date: Wed, 30 Aug 2017 13:37:29 -0400 Subject: [CMake] Future direction for FindCUDA In-Reply-To: <8D981219EEA621479C112DA9BDC39A8E7098EED4@EXMBS2.ad.igd.fraunhofer.de> References: <1504069483.3443296.1089392080.7AED2035@webmail.messagingengine.com> <8D981219EEA621479C112DA9BDC39A8E7098EED4@EXMBS2.ad.igd.fraunhofer.de> Message-ID: > Can I link to CUDA libraries with GCC while not using FindCUDA Yes you can if you have enabled the CUDA language. You will need to use find_package and can use the CMAKE_CUDA_IMPLICIT_LINK_DIRECTORIES as the location(s) to search. > Instead of modifying what FindCUDA does, which would break backwards compatibility, FindCUDA could be split into FindCUDA and FindCUDALibraries or something like that. That is something I have wanted to do, but haven't had the time to formalize and finish. You can find my initial implementation at https://gitlab.kitware.com/robertmaynard/find_cuda_wrappers On Wed, Aug 30, 2017 at 5:06 AM, Mueller-Roemer, Johannes Sebastian wrote: > Hi, > > we have encountered this issue as well, in our case when using thrust on the host side. We currently solve this by still using FindCUDA, even when using CMake 3.8/3.9, but only using the CUDA_*_LIBRARY and CUDA_TOOLKIT_INCLUDE variables and nothing else. > > Instead of modifying what FindCUDA does, which would break backwards compatibility, FindCUDA could be split into FindCUDA and FindCUDALibraries or something like that. > > Regards > Johannes > > Fraunhofer-Institut f?r Graphische Datenverarbeitung IGD > Fraunhoferstr. 5 | 64283 Darmstadt | Germany > Tel +49 6151 155-606 | Fax +49 6151 155-139 > johannes.mueller-roemer at igd.fraunhofer.de | www.igd.fraunhofer.de > > > -----Original Message----- > From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Siyuan Liu > Sent: Wednesday, August 30, 2017 07:05 > To: cmake at cmake.org > Subject: [CMake] Future direction for FindCUDA > > Dear all, > > I've noticed the change to CUDA as a language in CMake 3.8. I've migrated to this new syntax, but this change leads to some difficulties for me with CMake. I think we should treat CUDA as not just a language but rather a language with some libraries. > > Now that the FindCUDA module is deprecated, I cannot compile a file with GCC while linking to a CUDA library (since the CUDA_xxx_LIBRARY variables are gone). The reason for not using NVCC is to save compilation time. Personally, I think FindCUDA should become a module for purely finding CUDA libraries for linking without anything related to the NVCC compiler (e.g. the cuda_add_executable macro). > > My questions in short: > 1. Can I link to CUDA libraries with GCC while not using FindCUDA? > 2. What's your opinion on my suggestion about FindCUDA? > > Regards, > Siyuan > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake From e-hermes at web.de Thu Aug 31 08:02:42 2017 From: e-hermes at web.de (Martin Herrmann) Date: Thu, 31 Aug 2017 14:02:42 +0200 Subject: [CMake] crosscompile for armclang Message-ID: An HTML attachment was scrubbed... URL: