From a.neundorf-work at gmx.net Sun Oct 1 11:45:51 2017 From: a.neundorf-work at gmx.net (Alexander Neundorf) Date: Sun, 01 Oct 2017 17:45:51 +0200 Subject: [CMake] Best practice for modifying search path for find_package() In-Reply-To: References: Message-ID: <2921622.uMGk36INDg@linux-l7nd> On 2017 M08 24, Thu 13:36:45 CEST Robert Dailey wrote: > 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. You have one install dir for your external-package libraries and then want to use them ? IMO using CMAKE_PREFIX_PATH is just fine for this. Alex From a.neundorf-work at gmx.net Sun Oct 1 11:52:48 2017 From: a.neundorf-work at gmx.net (Alexander Neundorf) Date: Sun, 01 Oct 2017 17:52:48 +0200 Subject: [CMake] [cmake-developers] Debugging find_package() search behavior? In-Reply-To: References: Message-ID: <3355582.XmfnQRD5oj@linux-l7nd> On 2017 M08 29, Tue 11:33:15 CEST David Cole via cmake-developers wrote: > That's correct: > > find modules do what they want, and most do not pay attention to > CMAKE_PREFIX_PATH. are you sure ? As long as NO_DEFAULT_PATH is not used in the find_*() calls, CMAKE_PREFIX_PATH is used automatically by them. Alex From DLRdave at aol.com Sun Oct 1 12:38:43 2017 From: DLRdave at aol.com (David Cole) Date: Sun, 1 Oct 2017 12:38:43 -0400 Subject: [CMake] [cmake-developers] Debugging find_package() search behavior? In-Reply-To: <3355582.XmfnQRD5oj@linux-l7nd> References: <3355582.XmfnQRD5oj@linux-l7nd> Message-ID: No, I was already promptly corrected by Brad, too. I was not accounting for the fact that the other find_* calls used inside of find modules also use CMAKE_PREFIX_PATH. I was thinking of its use to find a project's config file from the find_package config mode. I stand corrected. Again. ;-) However, I stand by my assertion that find modules do what they want. It's still a bit of a wild wild west, and people make their own find modules that live inside their own project's source trees. Config files should be the preferred/primary mechanism for find_package calls (going on something like 5 or 6 years now...), but still people write new find modules. Thanks, David C. On Sun, Oct 1, 2017 at 11:52 AM, Alexander Neundorf wrote: > On 2017 M08 29, Tue 11:33:15 CEST David Cole via cmake-developers wrote: >> That's correct: >> >> find modules do what they want, and most do not pay attention to >> CMAKE_PREFIX_PATH. > > are you sure ? > As long as NO_DEFAULT_PATH is not used in the find_*() calls, CMAKE_PREFIX_PATH > is used automatically by them. > > Alex > From aluaces at udc.es Mon Oct 2 05:13:02 2017 From: aluaces at udc.es (Alberto Luaces) Date: Mon, 02 Oct 2017 11:13:02 +0200 Subject: [CMake] Transitive dependencies of header libraries References: <87fub5spfv.fsf@eps142.cdf.udc.es> <1506713211.3965.261.camel@yahoo.com> Message-ID: <873771syjl.fsf@eps142.cdf.udc.es> Ok, I see. Thanks a lot, Paul! paul via CMake writes: > You need to do add the dependencies in the config.cmake file, which means you > need to seperate the config and export file. So in your CMakeLists.txt, you > would do: > > install(TARGETS myheaderonlylib EXPORT myheaderonlylib-targets DESTINATION > include) > install(EXPORT myheaderonlylib-targets DESTINATION > share/myheaderonlylib/cmake) > install(FILES myheaderonlylib-config.cmake DESTINATION > share/myheaderonlylib/cmake) > > And then in myheaderonlylib-config.cmake you would write: > > include(CMakeFindDependencyMacro) > find_dependency(Eigen) > include("${CMAKE_CURRENT_LIST_DIR}/myheaderonlylib-targets.cmake") > > This calls `find_dependency`, which is just a wrapper around `find_package` > that makes it more friendly inside of package config cmake file. This the user > just needs to call `find_package(myheaderonlylib)` and Eigen will be found > automatically. > > > On Fri, 2017-09-29 at 13:40 +0200, Alberto Luaces wrote: >> Hi, I have a header-only library which itself depends on another >> header-only library: >> >> ``` >> add_library(myheaderonlylib INTERFACE) >> >> target_include_directories(myheaderonlylib INTERFACE >> ? $ >> ? ) >> >> target_link_libraries(myheaderonlylib INTERFACE Eigen3::Eigen) >> >> install(TARGETS myheaderonlylib EXPORT myheaderonlylib-config DESTINATION >> include) >> >> install(EXPORT myheaderonlylib-config DESTINATION >> share/myheaderonlylib/cmake) >> ``` >> >> When a third library links to "myheaderonlylib", cmake adds the target >> ?Eigen3::Eigen, but since it is not known there, the configuration step >> ?fails. >> >> I understand this is a difficult one, but I wonder if there is any other >> way instead of finding Eigen3::Eigen from the client package. >> >> Thanks! >> >> --? >> Alberto >> > > . -- Alberto From mwpowellhtx at gmail.com Mon Oct 2 14:34:45 2017 From: mwpowellhtx at gmail.com (Michael Powell) Date: Mon, 2 Oct 2017 14:34:45 -0400 Subject: [CMake] Building Boost as an ExternalProject Message-ID: Hello, This question has been raised from time to time I think. I am trying to build Boost as an ExternalProject, but I am ending up with an error: 'cmd.exe' returned with exit code 1. Along these lines. Perhaps I have involved one too many variables, but I doubt it. Ignore the cross-plat stuff, this is building on Windows for the purposes of this conversation. I tried to configure ExternalProject_Add with as much verbosity as possible, but unfortunately the process is not especially talkative as it turns out. But for the EC 1. set (BOOST_VERSION 1.65.1) message (STATUS "Adding Boost ${BOOST_VERSION} as an external project.") set (BOOST_BOOTSTRAP_PREFIX ${CMAKE_CURRENT_SOURCE_DIR}/boostbuild) set (BOOST_INSTALL_PREFIX ${CMAKE_CURRENT_SOURCE_DIR}/boostbuild) set (BOOST_BUILD_PREFIX ${BOOST_BOOTSTRAP_PREFIX}/boost) set (BOOST_GIT_REPO_DIR ${CMAKE_CURRENT_SOURCE_DIR}/repos/boost) if (WIN32) set (BOOST_BOOTSTRAP_CMD ${BOOST_GIT_REPO_DIR}/bootstrap.bat) # It was bjam at one point; it is now b2 set (BOOST_BUILD_CMD ${BOOST_GIT_REPO_DIR}/b2.exe) elseif (UNIX) set (BOOST_BOOTSTRAP_CMD ./${BOOST_GIT_REPO_DIR}/bootstrap.sh) set (BOOST_BUILD_CMD ./${BOOST_GIT_REPO_DIR}/b2) endif () # TODO: TBD: For now, assuming only 64-bit address models. set (BOOST_ADDR_MODEL 64) # TODO: TBD: align with the toolchain that we want to build through the CMake here... For now assuming: if (MSVC_VERSION EQUAL 1900) set (BOOST_TOOLSET msvc-14.0) endif () ExternalProject_Add (boost # PREFIX ${CMAKE_CURRENT_SOURCE_DIR}/repos/boost GIT_REPOSITORY git at github.com:boostorg/boost.git GIT_TAG boost-${BOOST_VERSION} GIT_PROGRESS ON CMAKE_ARGS -DCMAKE_INSTALL_PREFIX:STRING=${BOOST_INSTALL_PREFIX} SOURCE_DIR ${CMAKE_CURRENT_SOURCE_DIR}/repos/boost CONFIGURE_COMMAND ${BOOST_BOOTSTRAP_CMD} --prefix=${BOOST_BOOTSTRAP_PREFIX} # I do not necessarily care about any other Boost build options; but that could change the further I get into unit testing, at least so long as I will be adopting the test library for usage. BUILD_COMMAND ${BOOST_BUILD_CMD} --with-test toolset=${BOOST_TOOLSET} variant=debug link=static stage --prefix=${BOOST_BUILD_PREFIX} LOG_DOWNLOAD ON LOG_UPDATE ON LOG_CONFIGURE ON LOG_BUILD ON LOG_INSTALL ON ) Cheers, Michael Powell From a.neundorf-work at gmx.net Mon Oct 2 15:02:50 2017 From: a.neundorf-work at gmx.net (Alexander Neundorf) Date: Mon, 02 Oct 2017 21:02:50 +0200 Subject: [CMake] debugging CMAKE_PREFIX_PATH In-Reply-To: <20170913085048.GA1864@quark> References: <20170912112116.GA27289@quartz> <20170912231440.GB900@quark> <20170913085048.GA1864@quark> Message-ID: <2150603.iL5cdQvjJD@linux-l7nd> On 2017 M09 13, Wed 09:50:48 CEST Patrick Welche wrote: > I think I am confused by the following: > > 1) CMAKE_PREFIX_PATH; > > Problematic (scribus) CMakeLists.txt: > > set(CMAKE_PREFIX_PATH "${QT_PREFIX}/lib/cmake") This looks wrong to me. In general CMAKE_PREFIX_PATH should contain only the base install directory of packages, and not point into the library dir etc. So it should more look something like this: set(CMAKE_PREFIX_PATH "${QT_PREFIX}") But actually this should be left to the user, since he knows where Qt is used (or is supposed to know). > CMakeCache.txt: > > //No help, variable specified on the command line. > CMAKE_PREFIX_PATH:PATH=/usr/pkg/qt5 > > So the problem was that CMakeLists.txt overwrote the command line. > Removing the set() line made things work Yes. A "normal" set() call overrides values coming from the cache. > 2) CMAKE_MODULE_PATH > > CMakeLists.txt (with extras to debug): > > set (CMAKE_MODULE_PATH > "/usr/obj/pkgsrc/print/scribus5/work.x86_64/.buildlink/cmake-Modules" "one" > "two" "/usr/obj/pkgsrc/print/scribus5/work.x86_64/.buildlink/cmake-Modules" > "${CMAKE_SOURCE_DIR}/cmake/modules") set(testpath ${CMAKE_MODULE_PATH} > CACHE PATH "testing path") > > CMakeCache.txt: > > //No help, variable specified on the command line. > > CMAKE_MODULE_PATH:PATH=/usr/obj/pkgsrc/print/scribus5/work.x86_64/.buildlin > k/cmake-Modules > > //testing path > > testpath:PATH=/usr/obj/pkgsrc/print/scribus5/work.x86_64/.buildlink/cmake-M > odules;one;two;/usr/obj/pkgsrc/print/scribus5/work.x86_64/.buildlink/cmake-M > odules;/usr/obj/pkgsrc/print/scribus5/work.x86_64/scribus-1.5.3/cmake/module > s > > So here, it seems the command line overwrites CMakeLists.txt ?! Ehm, doesn't testpath in the CMakeCache.txt have the contents of CMAKE_MODULE_PATH from the CMakeLists.txt ? Alex From mwpowellhtx at gmail.com Mon Oct 2 15:06:01 2017 From: mwpowellhtx at gmail.com (Michael Powell) Date: Mon, 2 Oct 2017 15:06:01 -0400 Subject: [CMake] Building Boost as an ExternalProject In-Reply-To: References: Message-ID: On Mon, Oct 2, 2017 at 2:34 PM, Michael Powell wrote: > Hello, > > This question has been raised from time to time I think. I am trying > to build Boost as an ExternalProject, but I am ending up with an > error: 'cmd.exe' returned with exit code 1. Along these lines. >From the Boost VC project file: setlocal C:\Dev\CMake\bin\cmake.exe -E make_directory G:/Source/Spikes/nanomsg/cppnngswig-working/repos/boost if %errorlevel% neq 0 goto :cmEnd C:\Dev\CMake\bin\cmake.exe -E make_directory G:/Source/Spikes/nanomsg/cppnngswig-working/build/boost-prefix/src/boost-build if %errorlevel% neq 0 goto :cmEnd C:\Dev\CMake\bin\cmake.exe -E make_directory G:/Source/Spikes/nanomsg/cppnngswig-working/build/boost-prefix if %errorlevel% neq 0 goto :cmEnd C:\Dev\CMake\bin\cmake.exe -E make_directory G:/Source/Spikes/nanomsg/cppnngswig-working/build/boost-prefix/tmp if %errorlevel% neq 0 goto :cmEnd ** C:\Dev\CMake\bin\cmake.exe -E make_directory G:/Source/Spikes/nanomsg/cppnngswig-working/build/boost-prefix/src/boost-stamp/$(Configuration) ** if %errorlevel% neq 0 goto :cmEnd C:\Dev\CMake\bin\cmake.exe -E make_directory G:/Source/Spikes/nanomsg/cppnngswig-working/build/boost-prefix/src if %errorlevel% neq 0 goto :cmEnd C:\Dev\CMake\bin\cmake.exe -E touch G:/Source/Spikes/nanomsg/cppnngswig-working/build/boost-prefix/src/boost-stamp/$(Configuration)/boost-mkdir if %errorlevel% neq 0 goto :cmEnd :cmEnd ** endlocal & call :cmErrorLevel %errorlevel% & goto :cmDone :cmErrorLevel exit /b %1 :cmDone if %errorlevel% neq 0 goto :VCEnd ** which line number was the error Honestly, that does not make much sense since the directories do in fact exist. The boost-configure-err.log shows this result: The system cannot find the path specified. '.\build.bat' is not recognized as an internal or external command, operable program or batch file. Which leads me to believe that possibly I need to tell the target to operate in a more appropriate working directory? > Perhaps I have involved one too many variables, but I doubt it. Ignore > the cross-plat stuff, this is building on Windows for the purposes of > this conversation. > > I tried to configure ExternalProject_Add with as much verbosity as > possible, but unfortunately the process is not especially talkative as > it turns out. But for the EC 1. > > set (BOOST_VERSION 1.65.1) > > message (STATUS "Adding Boost ${BOOST_VERSION} as an external project.") > > set (BOOST_BOOTSTRAP_PREFIX ${CMAKE_CURRENT_SOURCE_DIR}/boostbuild) > set (BOOST_INSTALL_PREFIX ${CMAKE_CURRENT_SOURCE_DIR}/boostbuild) > set (BOOST_BUILD_PREFIX ${BOOST_BOOTSTRAP_PREFIX}/boost) > set (BOOST_GIT_REPO_DIR ${CMAKE_CURRENT_SOURCE_DIR}/repos/boost) > > if (WIN32) > set (BOOST_BOOTSTRAP_CMD ${BOOST_GIT_REPO_DIR}/bootstrap.bat) > # It was bjam at one point; it is now b2 > set (BOOST_BUILD_CMD ${BOOST_GIT_REPO_DIR}/b2.exe) > elseif (UNIX) > set (BOOST_BOOTSTRAP_CMD ./${BOOST_GIT_REPO_DIR}/bootstrap.sh) > set (BOOST_BUILD_CMD ./${BOOST_GIT_REPO_DIR}/b2) > endif () > > # TODO: TBD: For now, assuming only 64-bit address models. > set (BOOST_ADDR_MODEL 64) > > # TODO: TBD: align with the toolchain that we want to build through > the CMake here... For now assuming: > if (MSVC_VERSION EQUAL 1900) > set (BOOST_TOOLSET msvc-14.0) > endif () > > ExternalProject_Add (boost > # PREFIX ${CMAKE_CURRENT_SOURCE_DIR}/repos/boost > GIT_REPOSITORY git at github.com:boostorg/boost.git > GIT_TAG boost-${BOOST_VERSION} > GIT_PROGRESS ON > CMAKE_ARGS -DCMAKE_INSTALL_PREFIX:STRING=${BOOST_INSTALL_PREFIX} > SOURCE_DIR ${CMAKE_CURRENT_SOURCE_DIR}/repos/boost > CONFIGURE_COMMAND ${BOOST_BOOTSTRAP_CMD} --prefix=${BOOST_BOOTSTRAP_PREFIX} > # I do not necessarily care about any other Boost build options; > but that could change the further I get into unit testing, at least so > long as I will be adopting the test library for usage. > BUILD_COMMAND ${BOOST_BUILD_CMD} --with-test > toolset=${BOOST_TOOLSET} variant=debug link=static stage > --prefix=${BOOST_BUILD_PREFIX} > LOG_DOWNLOAD ON > LOG_UPDATE ON > LOG_CONFIGURE ON > LOG_BUILD ON > LOG_INSTALL ON > ) > > Cheers, > > Michael Powell From a.neundorf-work at gmx.net Mon Oct 2 15:07:41 2017 From: a.neundorf-work at gmx.net (Alexander Neundorf) Date: Mon, 02 Oct 2017 21:07:41 +0200 Subject: [CMake] Advice on converting legacy project to modern CMake In-Reply-To: References: Message-ID: <2627794.pGNfb6ZPD4@linux-l7nd> On 2017 M08 10, Thu 17:15:00 CEST Robert Maynard wrote: > > 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. it starts to be a bit different once you want to use also cmake-gui, then the requirements a a bit higher. I think at 3.7 or something it defaults to Qt5 and xcb, and that is not available on really old systems (RHEL5). Alex From a.neundorf-work at gmx.net Mon Oct 2 15:08:55 2017 From: a.neundorf-work at gmx.net (Alexander Neundorf) Date: Mon, 02 Oct 2017 21:08:55 +0200 Subject: [CMake] [cmake-developers] Debugging find_package() search behavior? In-Reply-To: References: <3355582.XmfnQRD5oj@linux-l7nd> Message-ID: <1603342.cxqPHe9aOz@linux-l7nd> On 2017 M10 1, Sun 12:38:43 CEST David Cole via CMake wrote: > No, I was already promptly corrected by Brad, too. I was not > accounting for the fact that the other find_* calls used inside of > find modules also use CMAKE_PREFIX_PATH. I was thinking of its use to > find a project's config file from the find_package config mode. > > I stand corrected. Again. ;-) yeah, sorry, I had problems with receiving mail from the cmake list since August and was catching up yesterday.... and replied too quickly. Alex From a.neundorf-work at gmx.net Mon Oct 2 15:31:43 2017 From: a.neundorf-work at gmx.net (Alexander Neundorf) Date: Mon, 02 Oct 2017 21:31:43 +0200 Subject: [CMake] rebuild externalprojects In-Reply-To: References: Message-ID: <2623247.SzC8l6mk70@linux-l7nd> On 2017 M09 21, Thu 07:18:46 CEST David Cole via CMake wrote: > By manually deleting (or touching) the stamp file associated with the > earliest step you need to re-run. > > ExternalProject is not for auto-detecting changes to stuff and > minimally re-running build steps. It's for static stuff that doesn't > change much. > > Find the "-build" stamp file that's associated with the project > containing the source you changed and delete it. > > Then run the build from the top and that one and everything that > depends on it afterwards should rebuild. so, if I have an "external project" as sources in my project (i.e. it is not updated from some other repository or something), and if then that package is upgraded to the next version, what's the recommended way to enforce a rebuild of it ? I have only found two clunky work-arounds: if it's a cmake-based project, I just add --no-warn-unused-cli -DREBUILD_FLAG=123 to CMAKE_ARGS, and increase this "REBUILD_FLAG" whenever a rebuild is necessary. What also seems to work is to misuse the URL_MD5, and set it to the date of the last update, e.g. URL_MD5=20171002 Alex -------------- next part -------------- An HTML attachment was scrubbed... URL: From mwpowellhtx at gmail.com Mon Oct 2 15:37:43 2017 From: mwpowellhtx at gmail.com (Michael Powell) Date: Mon, 2 Oct 2017 15:37:43 -0400 Subject: [CMake] Building Boost as an ExternalProject In-Reply-To: References: Message-ID: On Mon, Oct 2, 2017 at 3:06 PM, Michael Powell wrote: > On Mon, Oct 2, 2017 at 2:34 PM, Michael Powell wrote: >> Hello, >> >> This question has been raised from time to time I think. I am trying >> to build Boost as an ExternalProject, but I am ending up with an >> error: 'cmd.exe' returned with exit code 1. Along these lines. This is the line from the Microsoft.CppCommon.targets that was failing. And the output message is this: 2> CMake Error at G:/Source/Spikes/nanomsg/cppnngswig-working/build/boost-prefix/src/boost-stamp/boost-configure-Debug.cmake:16 (message): 2> Command failed: The system cannot find the file specified 2> 2> 'bootstrap.bat' '--prefix=G:/Source/Spikes/nanomsg/cppnngswig-working/boostbuild' 2> 2> See also 2> 2> G:/Source/Spikes/nanomsg/cppnngswig-working/build/boost-prefix/src/boost-stamp/boost-configure-*.log However, I've set the Working Directory to the bootstrap.bat location, so I do not know how that could be missed. > From the Boost VC project file: > > setlocal > C:\Dev\CMake\bin\cmake.exe -E make_directory > G:/Source/Spikes/nanomsg/cppnngswig-working/repos/boost > if %errorlevel% neq 0 goto :cmEnd > C:\Dev\CMake\bin\cmake.exe -E make_directory > G:/Source/Spikes/nanomsg/cppnngswig-working/build/boost-prefix/src/boost-build > if %errorlevel% neq 0 goto :cmEnd > C:\Dev\CMake\bin\cmake.exe -E make_directory > G:/Source/Spikes/nanomsg/cppnngswig-working/build/boost-prefix > if %errorlevel% neq 0 goto :cmEnd > C:\Dev\CMake\bin\cmake.exe -E make_directory > G:/Source/Spikes/nanomsg/cppnngswig-working/build/boost-prefix/tmp > if %errorlevel% neq 0 goto :cmEnd > ** C:\Dev\CMake\bin\cmake.exe -E make_directory > G:/Source/Spikes/nanomsg/cppnngswig-working/build/boost-prefix/src/boost-stamp/$(Configuration) > ** if %errorlevel% neq 0 goto :cmEnd > C:\Dev\CMake\bin\cmake.exe -E make_directory > G:/Source/Spikes/nanomsg/cppnngswig-working/build/boost-prefix/src > if %errorlevel% neq 0 goto :cmEnd > C:\Dev\CMake\bin\cmake.exe -E touch > G:/Source/Spikes/nanomsg/cppnngswig-working/build/boost-prefix/src/boost-stamp/$(Configuration)/boost-mkdir > if %errorlevel% neq 0 goto :cmEnd > :cmEnd > ** endlocal & call :cmErrorLevel %errorlevel% & goto :cmDone > :cmErrorLevel > exit /b %1 > :cmDone > if %errorlevel% neq 0 goto :VCEnd > > ** which line number was the error > > Honestly, that does not make much sense since the directories do in fact exist. > > The boost-configure-err.log shows this result: > > The system cannot find the path specified. > '.\build.bat' is not recognized as an internal or external command, > operable program or batch file. > > Which leads me to believe that possibly I need to tell the target to > operate in a more appropriate working directory? > >> Perhaps I have involved one too many variables, but I doubt it. Ignore >> the cross-plat stuff, this is building on Windows for the purposes of >> this conversation. >> >> I tried to configure ExternalProject_Add with as much verbosity as >> possible, but unfortunately the process is not especially talkative as >> it turns out. But for the EC 1. >> >> set (BOOST_VERSION 1.65.1) >> >> message (STATUS "Adding Boost ${BOOST_VERSION} as an external project.") >> >> set (BOOST_BOOTSTRAP_PREFIX ${CMAKE_CURRENT_SOURCE_DIR}/boostbuild) >> set (BOOST_INSTALL_PREFIX ${CMAKE_CURRENT_SOURCE_DIR}/boostbuild) >> set (BOOST_BUILD_PREFIX ${BOOST_BOOTSTRAP_PREFIX}/boost) >> set (BOOST_GIT_REPO_DIR ${CMAKE_CURRENT_SOURCE_DIR}/repos/boost) >> >> if (WIN32) >> set (BOOST_BOOTSTRAP_CMD ${BOOST_GIT_REPO_DIR}/bootstrap.bat) >> # It was bjam at one point; it is now b2 >> set (BOOST_BUILD_CMD ${BOOST_GIT_REPO_DIR}/b2.exe) >> elseif (UNIX) >> set (BOOST_BOOTSTRAP_CMD ./${BOOST_GIT_REPO_DIR}/bootstrap.sh) >> set (BOOST_BUILD_CMD ./${BOOST_GIT_REPO_DIR}/b2) >> endif () >> >> # TODO: TBD: For now, assuming only 64-bit address models. >> set (BOOST_ADDR_MODEL 64) >> >> # TODO: TBD: align with the toolchain that we want to build through >> the CMake here... For now assuming: >> if (MSVC_VERSION EQUAL 1900) >> set (BOOST_TOOLSET msvc-14.0) >> endif () >> >> ExternalProject_Add (boost >> # PREFIX ${CMAKE_CURRENT_SOURCE_DIR}/repos/boost >> GIT_REPOSITORY git at github.com:boostorg/boost.git >> GIT_TAG boost-${BOOST_VERSION} >> GIT_PROGRESS ON >> CMAKE_ARGS -DCMAKE_INSTALL_PREFIX:STRING=${BOOST_INSTALL_PREFIX} >> SOURCE_DIR ${CMAKE_CURRENT_SOURCE_DIR}/repos/boost >> CONFIGURE_COMMAND ${BOOST_BOOTSTRAP_CMD} --prefix=${BOOST_BOOTSTRAP_PREFIX} >> # I do not necessarily care about any other Boost build options; >> but that could change the further I get into unit testing, at least so >> long as I will be adopting the test library for usage. >> BUILD_COMMAND ${BOOST_BUILD_CMD} --with-test >> toolset=${BOOST_TOOLSET} variant=debug link=static stage >> --prefix=${BOOST_BUILD_PREFIX} >> LOG_DOWNLOAD ON >> LOG_UPDATE ON >> LOG_CONFIGURE ON >> LOG_BUILD ON >> LOG_INSTALL ON >> ) >> >> Cheers, >> >> Michael Powell From jbarrett at pivotal.io Mon Oct 2 15:58:33 2017 From: jbarrett at pivotal.io (Jacob Barrett) Date: Mon, 02 Oct 2017 19:58:33 +0000 Subject: [CMake] Building Boost as an ExternalProject In-Reply-To: References: Message-ID: The Apache Geode Native project is building Boost as an external project. You may want to look at our setup for inspiration. It builds correction on Windows with VS, Solaris x86 and SPARC with Solaris Studio, Linux with GCC and OS X with Xcode.Right now we are purely header only so if you need some libs you will have to tweak a little. https://github.com/apache/geode-native/blob/develop/dependencies/boost/CMakeLists.txt In our project the depends on boost we just add have: target_link_libraries(... boost) -Jake On Mon, Oct 2, 2017 at 12:38 PM Michael Powell wrote: > On Mon, Oct 2, 2017 at 3:06 PM, Michael Powell > wrote: > > On Mon, Oct 2, 2017 at 2:34 PM, Michael Powell > wrote: > >> Hello, > >> > >> This question has been raised from time to time I think. I am trying > >> to build Boost as an ExternalProject, but I am ending up with an > >> error: 'cmd.exe' returned with exit code 1. Along these lines. > > This is the line from the Microsoft.CppCommon.targets that was failing. > > Sources ="@(CustomBuild)" > BuildSuffix ="$(_BuildSuffix)" > > TrackerLogDirectory ="%(CustomBuild.TrackerLogDirectory)" > MinimalRebuildFromTracking > ="%(CustomBuild.MinimalRebuildFromTracking)" > > TLogReadFiles ="@(CustomBuildTLogReadFiles)" > TLogWriteFiles ="@(CustomBuildTLogWriteFiles)" > TrackFileAccess ="$(TrackFileAccess)" > ToolArchitecture ="$(CustomBuildToolArchitecture)" > TrackerFrameworkPath ="$(CustomBuildTrackerFrameworkPath)" > TrackerSdkPath ="$(CustomBuildTrackerSdkPath)" > > AcceptableNonZeroExitCodes > ="%(CustomBuild.AcceptableNonZeroExitCodes)" > > > > And the output message is this: > > 2> CMake Error at > > G:/Source/Spikes/nanomsg/cppnngswig-working/build/boost-prefix/src/boost-stamp/boost-configure-Debug.cmake:16 > (message): > 2> Command failed: The system cannot find the file specified > 2> > 2> 'bootstrap.bat' > '--prefix=G:/Source/Spikes/nanomsg/cppnngswig-working/boostbuild' > 2> > 2> See also > 2> > 2> > G:/Source/Spikes/nanomsg/cppnngswig-working/build/boost-prefix/src/boost-stamp/boost-configure-*.log > > However, I've set the Working Directory to the bootstrap.bat location, > so I do not know how that could be missed. > > > From the Boost VC project file: > > > > Condition="'$(Configuration)|$(Platform)'=='Debug|x64'">setlocal > > C:\Dev\CMake\bin\cmake.exe -E make_directory > > G:/Source/Spikes/nanomsg/cppnngswig-working/repos/boost > > if %errorlevel% neq 0 goto :cmEnd > > C:\Dev\CMake\bin\cmake.exe -E make_directory > > > G:/Source/Spikes/nanomsg/cppnngswig-working/build/boost-prefix/src/boost-build > > if %errorlevel% neq 0 goto :cmEnd > > C:\Dev\CMake\bin\cmake.exe -E make_directory > > G:/Source/Spikes/nanomsg/cppnngswig-working/build/boost-prefix > > if %errorlevel% neq 0 goto :cmEnd > > C:\Dev\CMake\bin\cmake.exe -E make_directory > > G:/Source/Spikes/nanomsg/cppnngswig-working/build/boost-prefix/tmp > > if %errorlevel% neq 0 goto :cmEnd > > ** C:\Dev\CMake\bin\cmake.exe -E make_directory > > > G:/Source/Spikes/nanomsg/cppnngswig-working/build/boost-prefix/src/boost-stamp/$(Configuration) > > ** if %errorlevel% neq 0 goto :cmEnd > > C:\Dev\CMake\bin\cmake.exe -E make_directory > > G:/Source/Spikes/nanomsg/cppnngswig-working/build/boost-prefix/src > > if %errorlevel% neq 0 goto :cmEnd > > C:\Dev\CMake\bin\cmake.exe -E touch > > > G:/Source/Spikes/nanomsg/cppnngswig-working/build/boost-prefix/src/boost-stamp/$(Configuration)/boost-mkdir > > if %errorlevel% neq 0 goto :cmEnd > > :cmEnd > > ** endlocal & call :cmErrorLevel %errorlevel% & goto :cmDone > > :cmErrorLevel > > exit /b %1 > > :cmDone > > if %errorlevel% neq 0 goto :VCEnd > > > > ** which line number was the error > > > > Honestly, that does not make much sense since the directories do in fact > exist. > > > > The boost-configure-err.log shows this result: > > > > The system cannot find the path specified. > > '.\build.bat' is not recognized as an internal or external command, > > operable program or batch file. > > > > Which leads me to believe that possibly I need to tell the target to > > operate in a more appropriate working directory? > > > >> Perhaps I have involved one too many variables, but I doubt it. Ignore > >> the cross-plat stuff, this is building on Windows for the purposes of > >> this conversation. > >> > >> I tried to configure ExternalProject_Add with as much verbosity as > >> possible, but unfortunately the process is not especially talkative as > >> it turns out. But for the EC 1. > >> > >> set (BOOST_VERSION 1.65.1) > >> > >> message (STATUS "Adding Boost ${BOOST_VERSION} as an external project.") > >> > >> set (BOOST_BOOTSTRAP_PREFIX ${CMAKE_CURRENT_SOURCE_DIR}/boostbuild) > >> set (BOOST_INSTALL_PREFIX ${CMAKE_CURRENT_SOURCE_DIR}/boostbuild) > >> set (BOOST_BUILD_PREFIX ${BOOST_BOOTSTRAP_PREFIX}/boost) > >> set (BOOST_GIT_REPO_DIR ${CMAKE_CURRENT_SOURCE_DIR}/repos/boost) > >> > >> if (WIN32) > >> set (BOOST_BOOTSTRAP_CMD ${BOOST_GIT_REPO_DIR}/bootstrap.bat) > >> # It was bjam at one point; it is now b2 > >> set (BOOST_BUILD_CMD ${BOOST_GIT_REPO_DIR}/b2.exe) > >> elseif (UNIX) > >> set (BOOST_BOOTSTRAP_CMD ./${BOOST_GIT_REPO_DIR}/bootstrap.sh) > >> set (BOOST_BUILD_CMD ./${BOOST_GIT_REPO_DIR}/b2) > >> endif () > >> > >> # TODO: TBD: For now, assuming only 64-bit address models. > >> set (BOOST_ADDR_MODEL 64) > >> > >> # TODO: TBD: align with the toolchain that we want to build through > >> the CMake here... For now assuming: > >> if (MSVC_VERSION EQUAL 1900) > >> set (BOOST_TOOLSET msvc-14.0) > >> endif () > >> > >> ExternalProject_Add (boost > >> # PREFIX ${CMAKE_CURRENT_SOURCE_DIR}/repos/boost > >> GIT_REPOSITORY git at github.com:boostorg/boost.git > >> GIT_TAG boost-${BOOST_VERSION} > >> GIT_PROGRESS ON > >> CMAKE_ARGS -DCMAKE_INSTALL_PREFIX:STRING=${BOOST_INSTALL_PREFIX} > >> SOURCE_DIR ${CMAKE_CURRENT_SOURCE_DIR}/repos/boost > >> CONFIGURE_COMMAND ${BOOST_BOOTSTRAP_CMD} > --prefix=${BOOST_BOOTSTRAP_PREFIX} > >> # I do not necessarily care about any other Boost build options; > >> but that could change the further I get into unit testing, at least so > >> long as I will be adopting the test library for usage. > >> BUILD_COMMAND ${BOOST_BUILD_CMD} --with-test > >> toolset=${BOOST_TOOLSET} variant=debug link=static stage > >> --prefix=${BOOST_BUILD_PREFIX} > >> LOG_DOWNLOAD ON > >> LOG_UPDATE ON > >> LOG_CONFIGURE ON > >> LOG_BUILD ON > >> LOG_INSTALL ON > >> ) > >> > >> Cheers, > >> > >> Michael Powell > -- > > 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 mwpowellhtx at gmail.com Mon Oct 2 16:17:55 2017 From: mwpowellhtx at gmail.com (Michael Powell) Date: Mon, 2 Oct 2017 16:17:55 -0400 Subject: [CMake] Building Boost as an ExternalProject In-Reply-To: References: Message-ID: On Mon, Oct 2, 2017 at 3:58 PM, Jacob Barrett wrote: > The Apache Geode Native project is building Boost as an external project. > You may want to look at our setup for inspiration. It builds correction on > Windows with VS, Solaris x86 and SPARC with Solaris Studio, Linux with GCC > and OS X with Xcode.Right now we are purely header only so if you need some > libs you will have to tweak a little. > > https://github.com/apache/geode-native/blob/develop/dependencies/boost/CMakeLists.txt Thank you for the heads up Jacob. I could not find anything appreciably different that would make a difference. It seems like EP_Add is ignoring the Working Directory. It also does not seem to matter if I specify the full path for either bootstrap and/or b2. It seems to be making a little more progress, only sort of... I get the following two messages: output: Building Boost.Build engine Failed to build Boost.Build engine. Please consult bootstrap.log for further diagnostics. You can try to obtain a prebuilt binary from http://sf.net/project/showfiles.php?group_id=7586&package_id=72941 Also, you can file an issue at http://svn.boost.org Please attach bootstrap.log in that case. error: The system cannot find the path specified. '.\build.bat' is not recognized as an internal or external command, operable program or batch file. With the output from the build in Visual Studio: 2> Performing build step for 'boost' 2> CMake Error at G:/Source/Spikes/nanomsg/cppnngswig-working/build/boost-prefix/src/boost-stamp/boost-build-Debug.cmake:16 (message): 2> Command failed: The system cannot find the file specified 2> 2> 'b2.exe' '--with-test' 'toolset=msvc-14.0' 'variant=debug' 'link=static' 'stage' '--prefix=G:/Source/Spikes/nanomsg/cppnngswig-working/boostbuild' > In our project the depends on boost we just add have: > target_link_libraries(... boost) > > -Jake > > > > On Mon, Oct 2, 2017 at 12:38 PM Michael Powell > wrote: >> >> On Mon, Oct 2, 2017 at 3:06 PM, Michael Powell >> wrote: >> > On Mon, Oct 2, 2017 at 2:34 PM, Michael Powell >> > wrote: >> >> Hello, >> >> >> >> This question has been raised from time to time I think. I am trying >> >> to build Boost as an ExternalProject, but I am ending up with an >> >> error: 'cmd.exe' returned with exit code 1. Along these lines. >> >> This is the line from the Microsoft.CppCommon.targets that was failing. >> >> > Sources ="@(CustomBuild)" >> BuildSuffix ="$(_BuildSuffix)" >> >> TrackerLogDirectory ="%(CustomBuild.TrackerLogDirectory)" >> MinimalRebuildFromTracking >> ="%(CustomBuild.MinimalRebuildFromTracking)" >> >> TLogReadFiles ="@(CustomBuildTLogReadFiles)" >> TLogWriteFiles ="@(CustomBuildTLogWriteFiles)" >> TrackFileAccess ="$(TrackFileAccess)" >> ToolArchitecture ="$(CustomBuildToolArchitecture)" >> TrackerFrameworkPath ="$(CustomBuildTrackerFrameworkPath)" >> TrackerSdkPath ="$(CustomBuildTrackerSdkPath)" >> >> AcceptableNonZeroExitCodes >> ="%(CustomBuild.AcceptableNonZeroExitCodes)" >> > >> >> And the output message is this: >> >> 2> CMake Error at >> >> G:/Source/Spikes/nanomsg/cppnngswig-working/build/boost-prefix/src/boost-stamp/boost-configure-Debug.cmake:16 >> (message): >> 2> Command failed: The system cannot find the file specified >> 2> >> 2> 'bootstrap.bat' >> '--prefix=G:/Source/Spikes/nanomsg/cppnngswig-working/boostbuild' >> 2> >> 2> See also >> 2> >> 2> >> G:/Source/Spikes/nanomsg/cppnngswig-working/build/boost-prefix/src/boost-stamp/boost-configure-*.log >> >> However, I've set the Working Directory to the bootstrap.bat location, >> so I do not know how that could be missed. >> >> > From the Boost VC project file: >> > >> > > > Condition="'$(Configuration)|$(Platform)'=='Debug|x64'">setlocal >> > C:\Dev\CMake\bin\cmake.exe -E make_directory >> > G:/Source/Spikes/nanomsg/cppnngswig-working/repos/boost >> > if %errorlevel% neq 0 goto :cmEnd >> > C:\Dev\CMake\bin\cmake.exe -E make_directory >> > >> > G:/Source/Spikes/nanomsg/cppnngswig-working/build/boost-prefix/src/boost-build >> > if %errorlevel% neq 0 goto :cmEnd >> > C:\Dev\CMake\bin\cmake.exe -E make_directory >> > G:/Source/Spikes/nanomsg/cppnngswig-working/build/boost-prefix >> > if %errorlevel% neq 0 goto :cmEnd >> > C:\Dev\CMake\bin\cmake.exe -E make_directory >> > G:/Source/Spikes/nanomsg/cppnngswig-working/build/boost-prefix/tmp >> > if %errorlevel% neq 0 goto :cmEnd >> > ** C:\Dev\CMake\bin\cmake.exe -E make_directory >> > >> > G:/Source/Spikes/nanomsg/cppnngswig-working/build/boost-prefix/src/boost-stamp/$(Configuration) >> > ** if %errorlevel% neq 0 goto :cmEnd >> > C:\Dev\CMake\bin\cmake.exe -E make_directory >> > G:/Source/Spikes/nanomsg/cppnngswig-working/build/boost-prefix/src >> > if %errorlevel% neq 0 goto :cmEnd >> > C:\Dev\CMake\bin\cmake.exe -E touch >> > >> > G:/Source/Spikes/nanomsg/cppnngswig-working/build/boost-prefix/src/boost-stamp/$(Configuration)/boost-mkdir >> > if %errorlevel% neq 0 goto :cmEnd >> > :cmEnd >> > ** endlocal & call :cmErrorLevel %errorlevel% & goto :cmDone >> > :cmErrorLevel >> > exit /b %1 >> > :cmDone >> > if %errorlevel% neq 0 goto :VCEnd >> > >> > ** which line number was the error >> > >> > Honestly, that does not make much sense since the directories do in fact >> > exist. >> > >> > The boost-configure-err.log shows this result: >> > >> > The system cannot find the path specified. >> > '.\build.bat' is not recognized as an internal or external command, >> > operable program or batch file. >> > >> > Which leads me to believe that possibly I need to tell the target to >> > operate in a more appropriate working directory? >> > >> >> Perhaps I have involved one too many variables, but I doubt it. Ignore >> >> the cross-plat stuff, this is building on Windows for the purposes of >> >> this conversation. >> >> >> >> I tried to configure ExternalProject_Add with as much verbosity as >> >> possible, but unfortunately the process is not especially talkative as >> >> it turns out. But for the EC 1. >> >> >> >> set (BOOST_VERSION 1.65.1) >> >> >> >> message (STATUS "Adding Boost ${BOOST_VERSION} as an external >> >> project.") >> >> >> >> set (BOOST_BOOTSTRAP_PREFIX ${CMAKE_CURRENT_SOURCE_DIR}/boostbuild) >> >> set (BOOST_INSTALL_PREFIX ${CMAKE_CURRENT_SOURCE_DIR}/boostbuild) >> >> set (BOOST_BUILD_PREFIX ${BOOST_BOOTSTRAP_PREFIX}/boost) >> >> set (BOOST_GIT_REPO_DIR ${CMAKE_CURRENT_SOURCE_DIR}/repos/boost) >> >> >> >> if (WIN32) >> >> set (BOOST_BOOTSTRAP_CMD ${BOOST_GIT_REPO_DIR}/bootstrap.bat) >> >> # It was bjam at one point; it is now b2 >> >> set (BOOST_BUILD_CMD ${BOOST_GIT_REPO_DIR}/b2.exe) >> >> elseif (UNIX) >> >> set (BOOST_BOOTSTRAP_CMD ./${BOOST_GIT_REPO_DIR}/bootstrap.sh) >> >> set (BOOST_BUILD_CMD ./${BOOST_GIT_REPO_DIR}/b2) >> >> endif () >> >> >> >> # TODO: TBD: For now, assuming only 64-bit address models. >> >> set (BOOST_ADDR_MODEL 64) >> >> >> >> # TODO: TBD: align with the toolchain that we want to build through >> >> the CMake here... For now assuming: >> >> if (MSVC_VERSION EQUAL 1900) >> >> set (BOOST_TOOLSET msvc-14.0) >> >> endif () >> >> >> >> ExternalProject_Add (boost >> >> # PREFIX ${CMAKE_CURRENT_SOURCE_DIR}/repos/boost >> >> GIT_REPOSITORY git at github.com:boostorg/boost.git >> >> GIT_TAG boost-${BOOST_VERSION} >> >> GIT_PROGRESS ON >> >> CMAKE_ARGS -DCMAKE_INSTALL_PREFIX:STRING=${BOOST_INSTALL_PREFIX} >> >> SOURCE_DIR ${CMAKE_CURRENT_SOURCE_DIR}/repos/boost >> >> CONFIGURE_COMMAND ${BOOST_BOOTSTRAP_CMD} >> >> --prefix=${BOOST_BOOTSTRAP_PREFIX} >> >> # I do not necessarily care about any other Boost build options; >> >> but that could change the further I get into unit testing, at least so >> >> long as I will be adopting the test library for usage. >> >> BUILD_COMMAND ${BOOST_BUILD_CMD} --with-test >> >> toolset=${BOOST_TOOLSET} variant=debug link=static stage >> >> --prefix=${BOOST_BUILD_PREFIX} >> >> LOG_DOWNLOAD ON >> >> LOG_UPDATE ON >> >> LOG_CONFIGURE ON >> >> LOG_BUILD ON >> >> LOG_INSTALL ON >> >> ) >> >> >> >> Cheers, >> >> >> >> Michael Powell >> -- >> >> 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 pfultz2 at yahoo.com Mon Oct 2 16:54:35 2017 From: pfultz2 at yahoo.com (paul) Date: Mon, 02 Oct 2017 15:54:35 -0500 Subject: [CMake] Building Boost as an ExternalProject In-Reply-To: References: Message-ID: <1506977675.3965.327.camel@yahoo.com> For building boost with cmake you can use this cmake script: https://github.com/pfultz2/cget/blob/master/cget/cmake/boost.cmake You can drop it in at the top of the boost tree and it will build Boost.Build and then build boost with b2. This will map the cmake toolchain to the boost toolchain so the builds are consistent. On Mon, 2017-10-02 at 14:34 -0400, Michael Powell wrote: > Hello, > > This question has been raised from time to time I think. I am trying > to build Boost as an ExternalProject, but I am ending up with an > error: 'cmd.exe' returned with exit code 1. Along these lines. > > Perhaps I have involved one too many variables, but I doubt it. Ignore > the cross-plat stuff, this is building on Windows for the purposes of > this conversation. > > I tried to configure ExternalProject_Add with as much verbosity as > possible, but unfortunately the process is not especially talkative as > it turns out. But for the EC 1. > > set (BOOST_VERSION??1.65.1) > > message (STATUS "Adding Boost ${BOOST_VERSION} as an external project.") > > set (BOOST_BOOTSTRAP_PREFIX ${CMAKE_CURRENT_SOURCE_DIR}/boostbuild) > set (BOOST_INSTALL_PREFIX ${CMAKE_CURRENT_SOURCE_DIR}/boostbuild) > set (BOOST_BUILD_PREFIX ${BOOST_BOOTSTRAP_PREFIX}/boost) > set (BOOST_GIT_REPO_DIR ${CMAKE_CURRENT_SOURCE_DIR}/repos/boost) > > if (WIN32) > ????set (BOOST_BOOTSTRAP_CMD ${BOOST_GIT_REPO_DIR}/bootstrap.bat) > ????# It was bjam at one point; it is now b2 > ????set (BOOST_BUILD_CMD ${BOOST_GIT_REPO_DIR}/b2.exe) > elseif (UNIX) > ????set (BOOST_BOOTSTRAP_CMD ./${BOOST_GIT_REPO_DIR}/bootstrap.sh) > ????set (BOOST_BUILD_CMD ./${BOOST_GIT_REPO_DIR}/b2) > endif () > > #??TODO: TBD: For now, assuming only 64-bit address models. > set (BOOST_ADDR_MODEL 64) > > # TODO: TBD: align with the toolchain that we want to build through > the CMake here... For now assuming: > if (MSVC_VERSION EQUAL 1900) > ????set (BOOST_TOOLSET msvc-14.0) > endif () > > ExternalProject_Add (boost > ????# PREFIX ${CMAKE_CURRENT_SOURCE_DIR}/repos/boost > ????GIT_REPOSITORY git at github.com:boostorg/boost.git > ????GIT_TAG boost-${BOOST_VERSION} > ????GIT_PROGRESS ON > ????CMAKE_ARGS -DCMAKE_INSTALL_PREFIX:STRING=${BOOST_INSTALL_PREFIX} > ????SOURCE_DIR ${CMAKE_CURRENT_SOURCE_DIR}/repos/boost > ????CONFIGURE_COMMAND ${BOOST_BOOTSTRAP_CMD} -- > prefix=${BOOST_BOOTSTRAP_PREFIX} > ????# I do not necessarily care about any other Boost build options; > but that could change the further I get into unit testing, at least so > long as I will be adopting the test library for usage. > ????BUILD_COMMAND ${BOOST_BUILD_CMD} --with-test > toolset=${BOOST_TOOLSET} variant=debug link=static stage > --prefix=${BOOST_BUILD_PREFIX} > ????LOG_DOWNLOAD ON > ????LOG_UPDATE ON > ????LOG_CONFIGURE ON > ????LOG_BUILD ON > ????LOG_INSTALL ON > ) > > Cheers, > > Michael Powell . From mwpowellhtx at gmail.com Mon Oct 2 17:36:43 2017 From: mwpowellhtx at gmail.com (Michael Powell) Date: Mon, 2 Oct 2017 17:36:43 -0400 Subject: [CMake] Building Boost as an ExternalProject In-Reply-To: <1506977675.3965.327.camel@yahoo.com> References: <1506977675.3965.327.camel@yahoo.com> Message-ID: On Mon, Oct 2, 2017 at 4:54 PM, paul wrote: > For building boost with cmake you can use this cmake script: > > https://github.com/pfultz2/cget/blob/master/cget/cmake/boost.cmake > > You can drop it in at the top of the boost tree and it will build Boost.Build > and then build boost with b2. This will map the cmake toolchain to the boost > toolchain so the builds are consistent. That does seem to be the rub, at least on a Windows build. Something about ExternalProject_Add ain't quite kosher with what the Boost build system expects and it needs a little help. Using ExternalProject_Add, it succeeds, to a point. Then it falls over looking for b2 no matter how I try to persuade it: ExternalProject_Add (boost PREFIX ${CMAKE_CURRENT_BINARY_DIR}/boost GIT_REPOSITORY git at github.com:boostorg/boost.git GIT_TAG boost-${BOOST_VERSION} GIT_PROGRESS 1 UPDATE_COMMAND ${BOOST_BOOTSTRAP_CMD} CONFIGURE_COMMAND "" BUILD_COMMAND ${BOOST_BUILD_CMD} stage INSTALL_COMMAND "" LOG_DOWNLOAD 1 LOG_UPDATE 1 LOG_CONFIGURE 1 LOG_BUILD 1 LOG_INSTALL 1 ) It seems to use PREFIX a bit over zealously IMO, and not WORKING_DIRECTORY one iota. I did have one breakthrough; at least bootstrap.bat is building b2.exe, so that's something. With the update step being a straight 'bootstrap.bat' invocation, then: 'b2.exe' '--prefix=G:/Source/Spikes/nanomsg/cppnngswig-working/boostbuild' '-std=c++11' '--with-test' 'address-model=64' 'toolset=msvc-14.0' 'variant=debug' 'link=static' 'stage' I'm really at a loss how folks are succeeding with that, maybe on *nix systems, that is a different story, I don't know, I'm not aware. So with this, it is a key departure from EP_Add in that it "helps" the build system along. That was going to be my next approach. I still think EP_Add should work, but I'm not sure what it is missing. Maybe a simple \b2 ? > On Mon, 2017-10-02 at 14:34 -0400, Michael Powell wrote: >> Hello, >> >> This question has been raised from time to time I think. I am trying >> to build Boost as an ExternalProject, but I am ending up with an >> error: 'cmd.exe' returned with exit code 1. Along these lines. >> >> Perhaps I have involved one too many variables, but I doubt it. Ignore >> the cross-plat stuff, this is building on Windows for the purposes of >> this conversation. >> >> I tried to configure ExternalProject_Add with as much verbosity as >> possible, but unfortunately the process is not especially talkative as >> it turns out. But for the EC 1. >> >> set (BOOST_VERSION 1.65.1) >> >> message (STATUS "Adding Boost ${BOOST_VERSION} as an external project.") >> >> set (BOOST_BOOTSTRAP_PREFIX ${CMAKE_CURRENT_SOURCE_DIR}/boostbuild) >> set (BOOST_INSTALL_PREFIX ${CMAKE_CURRENT_SOURCE_DIR}/boostbuild) >> set (BOOST_BUILD_PREFIX ${BOOST_BOOTSTRAP_PREFIX}/boost) >> set (BOOST_GIT_REPO_DIR ${CMAKE_CURRENT_SOURCE_DIR}/repos/boost) >> >> if (WIN32) >> set (BOOST_BOOTSTRAP_CMD ${BOOST_GIT_REPO_DIR}/bootstrap.bat) >> # It was bjam at one point; it is now b2 >> set (BOOST_BUILD_CMD ${BOOST_GIT_REPO_DIR}/b2.exe) >> elseif (UNIX) >> set (BOOST_BOOTSTRAP_CMD ./${BOOST_GIT_REPO_DIR}/bootstrap.sh) >> set (BOOST_BUILD_CMD ./${BOOST_GIT_REPO_DIR}/b2) >> endif () >> >> # TODO: TBD: For now, assuming only 64-bit address models. >> set (BOOST_ADDR_MODEL 64) >> >> # TODO: TBD: align with the toolchain that we want to build through >> the CMake here... For now assuming: >> if (MSVC_VERSION EQUAL 1900) >> set (BOOST_TOOLSET msvc-14.0) >> endif () >> >> ExternalProject_Add (boost >> # PREFIX ${CMAKE_CURRENT_SOURCE_DIR}/repos/boost >> GIT_REPOSITORY git at github.com:boostorg/boost.git >> GIT_TAG boost-${BOOST_VERSION} >> GIT_PROGRESS ON >> CMAKE_ARGS -DCMAKE_INSTALL_PREFIX:STRING=${BOOST_INSTALL_PREFIX} >> SOURCE_DIR ${CMAKE_CURRENT_SOURCE_DIR}/repos/boost >> CONFIGURE_COMMAND ${BOOST_BOOTSTRAP_CMD} -- >> prefix=${BOOST_BOOTSTRAP_PREFIX} >> # I do not necessarily care about any other Boost build options; >> but that could change the further I get into unit testing, at least so >> long as I will be adopting the test library for usage. >> BUILD_COMMAND ${BOOST_BUILD_CMD} --with-test >> toolset=${BOOST_TOOLSET} variant=debug link=static stage >> --prefix=${BOOST_BUILD_PREFIX} >> LOG_DOWNLOAD ON >> LOG_UPDATE ON >> LOG_CONFIGURE ON >> LOG_BUILD ON >> LOG_INSTALL ON >> ) >> >> Cheers, >> >> Michael Powell > > . From csiga.biga at aol.com Tue Oct 3 09:54:22 2017 From: csiga.biga at aol.com (=?utf-8?Q?Nagy-Egri_M=C3=A1t=C3=A9_Ferenc?=) Date: Tue, 3 Oct 2017 15:54:22 +0200 Subject: [CMake] Generate headers and inherit include_directories Message-ID: Hi! I am a seasoned Cmake user but cannot solve a fairly simple problem, so I might be mistaking the forest for the trees. I have a project in which there is a custom_command/custom_target pair that creates a header file as part of a (currently) header-only target. I want to create an imported target (or really, any kind of target), which is responsible for triggering header generation at build time AND relaying the include directory so consumers need not worry about the location where the generated header files go. My problem is: - I cannot invoke target_include_directories on a custom_target - Imported targets cannot have source files (for proper depending on the result header file) - Imported targets cannot link to a custom_target - Interface and Unkown libraries cannot be non-imported - All other library types result in objects/libraries (which I don?t need) How can I create the dependency graph where my custom_command is invoked if the inputs to it change (or if its output doesn?t exist yet) and depending targets are rebuilt accordingly AND I also inherit build properties (include directories)? Cheers, M?t? -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcdailey.lists at gmail.com Tue Oct 3 11:17:40 2017 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Tue, 3 Oct 2017 10:17:40 -0500 Subject: [CMake] project() with ASM fails with MSVC 19 In-Reply-To: References: Message-ID: I haven't; the bigger issue here is that the way we specify ASM changes depending on platform. But prior to the project() call, you can't really use CMake to its fullest since project() serves as practically an "initialize CMake" function. So there's a catch 22 situation here. My expectation was that you specify the LANGUAGE, i.e. "ASM" and the platform cmake scripts within CMake's module directory would deduce "Ok I'm on Windows, so I know it's really MASM". On Tue, Sep 19, 2017 at 3:35 PM, Robert Maynard wrote: > Have you tried setting the project call of project(libpng VERSION > 1.6.33 LANGUAGES ASM_MASM C) > > On Tue, Sep 12, 2017 at 2:34 PM, Robert Dailey wrote: >> Also, I am using the "Visual Studio 15 2017" generator with no other >> options (generating through cmake-gui on Windows) >> >> On Tue, Sep 12, 2017 at 1:33 PM, Robert Dailey wrote: >>> Using CMake 3.9, I do this: >>> >>> cmake_minimum_required(VERSION 3.9) >>> project(libpng VERSION 1.6.33 LANGUAGES ASM C) >>> >>> I get the following error: >>> >>> -- The ASM compiler identification is unknown >>> -- Didn't find assembler >>> -- The C compiler identification is MSVC 19.11.25507.1 >>> CMake Error at CMakeLists.txt:16 (project): >>> No CMAKE_ASM_COMPILER could be found. >>> >>> >>> Why doesn't this work? >> -- >> >> 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 petr.kmoch at gmail.com Tue Oct 3 11:47:22 2017 From: petr.kmoch at gmail.com (Petr Kmoch) Date: Tue, 3 Oct 2017 17:47:22 +0200 Subject: [CMake] project() with ASM fails with MSVC 19 In-Reply-To: References: Message-ID: Hi Robert. You might try leaving ASM out of project() and using enable_language() after your call to project() (potentially in conditional branches). It can only (reliably) be used from the toplevel CMakeList, but that sounds like it could be good enough for you. https://cmake.org/cmake/help/latest/command/enable_language.html Petr On 3 October 2017 at 17:17, Robert Dailey wrote: > I haven't; the bigger issue here is that the way we specify ASM > changes depending on platform. But prior to the project() call, you > can't really use CMake to its fullest since project() serves as > practically an "initialize CMake" function. So there's a catch 22 > situation here. > > My expectation was that you specify the LANGUAGE, i.e. "ASM" and the > platform cmake scripts within CMake's module directory would deduce > "Ok I'm on Windows, so I know it's really MASM". > > On Tue, Sep 19, 2017 at 3:35 PM, Robert Maynard > wrote: > > Have you tried setting the project call of project(libpng VERSION > > 1.6.33 LANGUAGES ASM_MASM C) > > > > On Tue, Sep 12, 2017 at 2:34 PM, Robert Dailey > wrote: > >> Also, I am using the "Visual Studio 15 2017" generator with no other > >> options (generating through cmake-gui on Windows) > >> > >> On Tue, Sep 12, 2017 at 1:33 PM, Robert Dailey < > rcdailey.lists at gmail.com> wrote: > >>> Using CMake 3.9, I do this: > >>> > >>> cmake_minimum_required(VERSION 3.9) > >>> project(libpng VERSION 1.6.33 LANGUAGES ASM C) > >>> > >>> I get the following error: > >>> > >>> -- The ASM compiler identification is unknown > >>> -- Didn't find assembler > >>> -- The C compiler identification is MSVC 19.11.25507.1 > >>> CMake Error at CMakeLists.txt:16 (project): > >>> No CMAKE_ASM_COMPILER could be found. > >>> > >>> > >>> Why doesn't this work? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mellery451 at gmail.com Tue Oct 3 13:02:57 2017 From: mellery451 at gmail.com (Michael Ellery) Date: Tue, 3 Oct 2017 10:02:57 -0700 Subject: [CMake] Generate headers and inherit include_directories In-Reply-To: <20171003135415.3E43FFD638@public.kitware.com> References: <20171003135415.3E43FFD638@public.kitware.com> Message-ID: <30B49ABF-D65A-4CB1-BC90-FB5285CF3C72@gmail.com> maybe a CMake snippet of what you are trying would help clarify, but are you using an interface library for your header-only? I would assume yes - and then have to tried add_dependency() for that library to trigger the file generation? The dependency will only be resolved when the library is used by an exe or installed (I think), but that should be sufficient? -Mike > On Oct 3, 2017, at 6:54 AM, Nagy-Egri M?t? Ferenc via CMake wrote: > > Hi! > > I am a seasoned Cmake user but cannot solve a fairly simple problem, so I might be mistaking the forest for the trees. > > I have a project in which there is a custom_command/custom_target pair that creates a header file as part of a (currently) header-only target. I want to create an imported target (or really, any kind of target), which is responsible for triggering header generation at build time AND relaying the include directory so consumers need not worry about the location where the generated header files go. My problem is: > > ? I cannot invoke target_include_directories on a custom_target > ? Imported targets cannot have source files (for proper depending on the result header file) > ? Imported targets cannot link to a custom_target > ? Interface and Unkown libraries cannot be non-imported > ? All other library types result in objects/libraries (which I don?t need) > > How can I create the dependency graph where my custom_command is invoked if the inputs to it change (or if its output doesn?t exist yet) and depending targets are rebuilt accordingly AND I also inherit build properties (include directories)? > > Cheers, > M?t? > -- > > 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 -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP URL: From Kent.Knox at amd.com Tue Oct 3 15:12:01 2017 From: Kent.Knox at amd.com (Knox, Kent) Date: Tue, 3 Oct 2017 19:12:01 +0000 Subject: [CMake] Building Boost as an ExternalProject Message-ID: Hi Michael~ > That does seem to be the rub, at least on a Windows build. Something about ExternalProject_Add ain't quite kosher with what the Boost build system expects and it needs a little help. > Using ExternalProject_Add, it succeeds, to a point. Then it falls over looking for b2 no matter how I try to persuade it: > ExternalProject_Add (boost > PREFIX ${CMAKE_CURRENT_BINARY_DIR}/boost > GIT_REPOSITORY git at github.com:boostorg/boost.git > GIT_TAG boost-${BOOST_VERSION} > GIT_PROGRESS 1 > UPDATE_COMMAND ${BOOST_BOOTSTRAP_CMD} > CONFIGURE_COMMAND "" > BUILD_COMMAND ${BOOST_BUILD_CMD} stage > INSTALL_COMMAND "" > LOG_DOWNLOAD 1 > LOG_UPDATE 1 > LOG_CONFIGURE 1 > LOG_BUILD 1 > LOG_INSTALL 1 > ) I think you need to add the following to your ExternalProject_Add () BUILD_IN_SOURCE 1 From robert.maynard at kitware.com Wed Oct 4 10:21:28 2017 From: robert.maynard at kitware.com (Robert Maynard) Date: Wed, 4 Oct 2017 10:21:28 -0400 Subject: [CMake] [ANNOUNCE] CMake 3.9.4 available for download Message-ID: We are pleased to announce that CMake 3.9.4 is now available for download. Please use the latest release from our download page: https://cmake.org/download/ Thanks for your support! ------------------------------------------------------------------------- Changes in 3.9.4 since 3.9.3: Brad King (2): FindBoost: Finish reverting "Simplify search in lists" for 3.9 CMake 3.9.4 From randy.heiland at gmail.com Wed Oct 4 15:16:12 2017 From: randy.heiland at gmail.com (Randy Heiland) Date: Wed, 4 Oct 2017 15:16:12 -0400 Subject: [CMake] cmake buried in subdirectory? Message-ID: Hello, Simple question... can I/how can I keep my top-level cmake-related stuff in a subdirectory of my main project directory? E.g.: /myproj /cmake CMakeLists.txt and then in the /cmake, I create a /build from which I attempt: cmake .. I tried something as simple as this in my CMakeLists.txt, but it didn't seem to work: project (../myproj) The primary reason I'd like to do this is to hide/make optional the cmake build approach (and keep in place an existing/traditional Makefile in the parent directory). Play along... thanks, Randy -------------- next part -------------- An HTML attachment was scrubbed... URL: From calebwherry at gmail.com Wed Oct 4 16:30:32 2017 From: calebwherry at gmail.com (J. Caleb Wherry) Date: Wed, 4 Oct 2017 16:30:32 -0400 Subject: [CMake] cmake buried in subdirectory? In-Reply-To: References: Message-ID: There is no reason why this shouldn't work, I do something similar where everything except my top-level CMakeLists is shoved into a subdirectory (away from the src code location). You don't have to muck with the project macro at all, not sure what you are trying to accomplish with that? That just sets the name of the project. All you have to be aware of is all the paths are now with respect to both the CMakeLists and where ever you put your binary dir. So doing something like the below allows you to reference things in your source tree (depending on how far you away form the root, obviously): get_filename_component(SourceRoot "${CMAKE_CURRENT_SOURCE_DIR}/../../" ABSOLUTE) The normal structure of the CMake file doesn't change, nothing special has to be done with the project macro. Unless you have a more specific error, that's about all the advice I have. -Caleb On Wed, Oct 4, 2017 at 3:16 PM, Randy Heiland wrote: > Hello, > > Simple question... can I/how can I keep my top-level cmake-related stuff > in a subdirectory of my main project directory? E.g.: > > /myproj > /cmake > CMakeLists.txt > > and then in the /cmake, I create a /build from which I attempt: cmake .. > > I tried something as simple as this in my CMakeLists.txt, but it didn't > seem to work: > project (../myproj) > > > The primary reason I'd like to do this is to hide/make optional the cmake > build approach (and keep in place an existing/traditional Makefile in the > parent directory). Play along... > > thanks, Randy > > -- > > 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 > -- J. Caleb Wherry *Scientific Software Engineer* http://www.calebwherry.com +1 (615) 708-5651 calebwherry at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From randy.heiland at gmail.com Wed Oct 4 21:22:52 2017 From: randy.heiland at gmail.com (Randy Heiland) Date: Wed, 4 Oct 2017 21:22:52 -0400 Subject: [CMake] cmake buried in subdirectory? In-Reply-To: References: Message-ID: Thanks for the reply. In my case, I didn't even want the CMakeLists in the top-level dir. I didn't want to contaminate my top-level dir with anything related to CMake. This would avoid, for example, an accidental overwrite of an existing Makefile if one was to do a 'cmake .' in the the top dir. It's quite possible I'm over-thinking this; I was just curious if it's even possible. Seems like it should be. -Randy On Wed, Oct 4, 2017 at 4:30 PM, J. Caleb Wherry wrote: > There is no reason why this shouldn't work, I do something similar where > everything except my top-level CMakeLists is shoved into a subdirectory > (away from the src code location). > > You don't have to muck with the project macro at all, not sure what you > are trying to accomplish with that? That just sets the name of the project. > > All you have to be aware of is all the paths are now with respect to both > the CMakeLists and where ever you put your binary dir. So doing something > like the below allows you to reference things in your source tree > (depending on how far you away form the root, obviously): > > get_filename_component(SourceRoot "${CMAKE_CURRENT_SOURCE_DIR}/../../" > ABSOLUTE) > > The normal structure of the CMake file doesn't change, nothing special has > to be done with the project macro. Unless you have a more specific error, > that's about all the advice I have. > > -Caleb > > > On Wed, Oct 4, 2017 at 3:16 PM, Randy Heiland > wrote: > >> Hello, >> >> Simple question... can I/how can I keep my top-level cmake-related stuff >> in a subdirectory of my main project directory? E.g.: >> >> /myproj >> /cmake >> CMakeLists.txt >> >> and then in the /cmake, I create a /build from which I attempt: cmake .. >> >> I tried something as simple as this in my CMakeLists.txt, but it didn't >> seem to work: >> project (../myproj) >> >> >> The primary reason I'd like to do this is to hide/make optional the cmake >> build approach (and keep in place an existing/traditional Makefile in the >> parent directory). Play along... >> >> thanks, Randy >> >> -- >> >> 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 >> > > > > -- > J. Caleb Wherry > *Scientific Software Engineer* > > > http://www.calebwherry.com > +1 (615) 708-5651 <(615)%20708-5651> > calebwherry at gmail.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From d3ck0r at gmail.com Wed Oct 4 21:36:51 2017 From: d3ck0r at gmail.com (J Decker) Date: Wed, 4 Oct 2017 18:36:51 -0700 Subject: [CMake] cmake buried in subdirectory? In-Reply-To: References: Message-ID: On Wed, Oct 4, 2017 at 6:22 PM, Randy Heiland wrote: > Thanks for the reply. In my case, I didn't even want the CMakeLists in the > top-level dir. I didn't want to contaminate my top-level dir with anything > related to CMake. This would avoid, for example, an accidental overwrite of > an existing Makefile if one was to do a 'cmake .' in the the top dir. > > :) they could still 'cmake cmake' in the top dir :) you could add something like if( ${CMAKE_BINARY_DIR} STREQUAL ${CMAKE_SOURCE_DIR} ) message( FATAL_ERROR "dont' run cmake in this directory" ) # or something endif() but you don't need to add the .. in the project() just in the sources added to add_library() or add_executable() I'd probably SET( SOURCE_ROOT ${CMAKE_SOURCE_DIR}/.. ) if it was in a location where you were... and then add sources as... add_executable ( mySimpleProgram ${SOURCE_ROOT}/main.c ) > It's quite possible I'm over-thinking this; I was just curious if it's > even possible. Seems like it should be. > > > -Randy > > On Wed, Oct 4, 2017 at 4:30 PM, J. Caleb Wherry > wrote: > >> There is no reason why this shouldn't work, I do something similar where >> everything except my top-level CMakeLists is shoved into a subdirectory >> (away from the src code location). >> >> You don't have to muck with the project macro at all, not sure what you >> are trying to accomplish with that? That just sets the name of the project. >> >> All you have to be aware of is all the paths are now with respect to both >> the CMakeLists and where ever you put your binary dir. So doing something >> like the below allows you to reference things in your source tree >> (depending on how far you away form the root, obviously): >> >> get_filename_component(SourceRoot "${CMAKE_CURRENT_SOURCE_DIR}/../../" >> ABSOLUTE) >> >> The normal structure of the CMake file doesn't change, nothing special >> has to be done with the project macro. Unless you have a more specific >> error, that's about all the advice I have. >> >> -Caleb >> >> >> On Wed, Oct 4, 2017 at 3:16 PM, Randy Heiland >> wrote: >> >>> Hello, >>> >>> Simple question... can I/how can I keep my top-level cmake-related stuff >>> in a subdirectory of my main project directory? E.g.: >>> >>> /myproj >>> /cmake >>> CMakeLists.txt >>> >>> and then in the /cmake, I create a /build from which I attempt: cmake .. >>> >>> I tried something as simple as this in my CMakeLists.txt, but it didn't >>> seem to work: >>> project (../myproj) >>> >>> >>> The primary reason I'd like to do this is to hide/make optional the >>> cmake build approach (and keep in place an existing/traditional Makefile in >>> the parent directory). Play along... >>> >>> thanks, Randy >>> >>> -- >>> >>> 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 >>> >> >> >> >> -- >> J. Caleb Wherry >> *Scientific Software Engineer* >> >> >> http://www.calebwherry.com >> +1 (615) 708-5651 <(615)%20708-5651> >> calebwherry at gmail.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 h.sorby at auckland.ac.nz Wed Oct 4 23:32:09 2017 From: h.sorby at auckland.ac.nz (Hugh Sorby) Date: Thu, 5 Oct 2017 03:32:09 +0000 Subject: [CMake] Using CheckFortranFunctionExists Message-ID: <1507174329528.96005@auckland.ac.nz> Hi All, I'm trying to use CheckFortranFunctionExists? to test for getarg which is failing on an Ubuntu 16.04 test machine and OS X test machine. The test I have put together is provided below in text form. The test for getarg fails, the executable 'bob' fails to link but the executable 'dave' links and runs as expected. The error from 'bob' is [ 75%] Linking Fortran executable bob Undefined symbols for architecture x86_64: "_getarg_", referenced from: _MAIN__ in src.f.o ld: symbol(s) not found for architecture x86_64 collect2: error: ld returned 1 exit status make[2]: *** [bob] Error 1 make[1]: *** [CMakeFiles/bob.dir/all] Error 2 make: *** [all] Error 2? The files used in text form: ================== CMakeLists.txt ===================== cmake_minimum_required(VERSION 3.4) project(getarg_prog VERSION 1.0.0 LANGUAGES Fortran) include(CheckFortranFunctionExists) check_fortran_function_exists(getarg HAVE_GETARG) add_executable(bob src.f) add_executable(dave dave.f) ====================================================== =================== src.f ========================= program TESTFortran external getarg call getarg() end program TESTFortran ================================================ ======================== dave.f ========================== PROGRAM test_getarg INTEGER :: i CHARACTER(len=32) :: arg DO i = 1, iargc() CALL getarg(i, arg) WRITE (*,*) arg END DO ======================================================== Can anyone explain why this is happening and how I would go about testing for the getarg function if I am doing it wrong. Thanks, -------------- next part -------------- An HTML attachment was scrubbed... URL: From csiga.biga at aol.com Thu Oct 5 06:50:17 2017 From: csiga.biga at aol.com (=?utf-8?Q?Nagy-Egri_M=C3=A1t=C3=A9_Ferenc?=) Date: Thu, 5 Oct 2017 12:50:17 +0200 Subject: [CMake] Generate headers and inherit include_directories In-Reply-To: <30B49ABF-D65A-4CB1-BC90-FB5285CF3C72@gmail.com> References: <20171003135415.3E43FFD638@public.kitware.com> <30B49ABF-D65A-4CB1-BC90-FB5285CF3C72@gmail.com> Message-ID: Hi Michael! This is what I wanted to do (only relevant parts showing): /// top-level CMakeLists.txt add_subdirectory(Gripper) add_subdirectory(examples) /// Gripper/CmakeLists.txt set(RESULT ${CMAKE_CURRENT_BINARY_DIR}/inc/Gripper/stl/stlYlms_dynamic.hpp) add_custom_command(COMMAND ... ARGS ... OUTPUT ${RESULT}) add_custom_target(Ylms DEPENDS ${RESULT}) # What comes from HERE add_library(Gripper::Ylms INTERFACE IMPORTED GLOBAL) target_include_directories(Gripper::Ylms INTERFACE ${CMAKE_CURRENT_SOURCE_DIR}/inc ${CMAKE_CURRENT_BINARY_DIR}/inc) add_dependencies(Gripper::Ylms Ylms) # to HERE? (Note, example does not work) /// examples/CmakeLists.txt add_executable(example1 main.cpp) target_link_libraries(example1 Gripper::Ylms) When specifying Gripper::Ylms as a link target for example1, I would like to pick up both the dependency of Ylms being processed first and also the include directory marking the location of the generated header file. Note, the closes I got was using set_target_properties (Gripper::Ylms PROPERTIES INTERFACE_INCLUDE_DIRECTORIES "${CMAKE_CURRENT_SOURCE_DIR}/inc ${CMAKE_CURRENT_BINARY_DIR}/inc") instead of target_include_directories(Gripper::Ylms INTERFACE ${CMAKE_CURRENT_SOURCE_DIR}/inc ${CMAKE_CURRENT_BINARY_DIR}/inc) because set_target_properties wouldn?t let me specify multiple entries, but target_include_directories is not allowed on IMPORTED targets (but simple INTERFACE libraries cannot be global)? no combination of commands seem to work. Felad?: Michael Ellery Elk?ldve: 2017. okt?ber 3., kedd 19:04 C?mzett: Nagy-Egri M?t? Ferenc M?solatot kap: Cmake Mailing List T?rgy: Re: [CMake] Generate headers and inherit include_directories maybe a CMake snippet of what you are trying would help clarify, but are you using an interface library for your header-only? I would assume yes - and then have to tried add_dependency() for that library to trigger the file generation? The dependency will only be resolved when the library is used by an exe or installed (I think), but that should be sufficient? -Mike > On Oct 3, 2017, at 6:54 AM, Nagy-Egri M?t? Ferenc via CMake wrote: > > Hi! > > I am a seasoned Cmake user but cannot solve a fairly simple problem, so I might be mistaking the forest for the trees. > > I have a project in which there is a custom_command/custom_target pair that creates a header file as part of a (currently) header-only target. I want to create an imported target (or really, any kind of target), which is responsible for triggering header generation at build time AND relaying the include directory so consumers need not worry about the location where the generated header files go. My problem is: > > ? I cannot invoke target_include_directories on a custom_target > ? Imported targets cannot have source files (for proper depending on the result header file) > ? Imported targets cannot link to a custom_target > ? Interface and Unkown libraries cannot be non-imported > ? All other library types result in objects/libraries (which I don?t need) > > How can I create the dependency graph where my custom_command is invoked if the inputs to it change (or if its output doesn?t exist yet) and depending targets are rebuilt accordingly AND I also inherit build properties (include directories)? > > Cheers, > M?t? > -- > > 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 xl64100 at gmail.com Thu Oct 5 08:16:49 2017 From: xl64100 at gmail.com (xavier lacoste) Date: Thu, 5 Oct 2017 14:16:49 +0200 Subject: [CMake] CMAKE_RULE_LAUNCH_LINK separate link binary and archive Message-ID: Hello, I would like to use CMAKE_RULE_LAUNCH_LINK/CMAKE_RULE_LAUNCH_COMPILE for using score-p. scorep should be added in compile and link line before compiler (eg. scorep gcc). Thus I setted CMAKE_RULE_LAUNCH_COMPILE to scorep and same for CMAKE_RULE_LAUNCH_LINK. (set_property(GLOBAL PROPERTY RULE_LAUNCH_LINK scorep)) (set_property(GLOBAL PROPERTY RULE_LAUNCH_COMPILE scorep)) The issue is that scorep is also added for ARCHIVE creation with "ar" which is not supported by score-p. Do you have a solution to prefix link for an executable and not for an archive ? Regards, XL -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.clapham at bt.com Thu Oct 5 08:39:34 2017 From: philip.clapham at bt.com (philip.clapham at bt.com) Date: Thu, 5 Oct 2017 12:39:34 +0000 Subject: [CMake] CPack DebugInfo RPM depend on runtime RPM Message-ID: <53cee0192d1f45cdae5aaa1bd7044756@tpw09926dag03f.domain1.systemhost.net> Hi, I'm successfully using Cmake version 3.9.1 (on CentOS 6.9) to build a C++ project, and then using CPack (from CMake) to build two RPMs, a RUNTIME and a DEVEL. I have set the DEVEL to depend upon the RUNTIME using: SET(CPACK_RPM_DEVEL_PACKAGE_REQUIRES "${PROJECT_NAME} == ${FULL_VERSION}-${RELEASE_STRING}%{?dist}") This works exactly how I want it to; requiring that the DEVEL package have the exact same release version of RUNTIME installed. I also use: SET(CPACK_RPM_RUNTIME_DEBUGINFO_PACKAGE ON) To make a separate debuginfo RPM for the code in my runtime RPM. This also works as intended, to a point. If a user has all three RPMs installed, then everything is fine. They then learn an update (of all three RPMs) has been placed in the repo, so they run 'sudo yum update myRpm-devel', knowing that this will also update the runtime package. Unfortunately this doesn't update the debuginfo package, so they are no longer in-sync. I searched around and tried to use a "CPACK_RPM__DEBUGINFO_PACKAGE_REQUIRES" variable from CMake, but it didn't work, and as I'm using CPack to generate my SPEC files I can't see another way to modify them. CPack only generates two SPEC files, one for the DEVEL and one for the RUNTIME, and the additional instructions to generate the debuginfo are in the RUNTIME's SPEC file. Is there a way to set package-requires for debuginfo RPMs? Thanks, Phil -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 7994 bytes Desc: not available URL: From mike.jackson at bluequartz.net Thu Oct 5 09:14:32 2017 From: mike.jackson at bluequartz.net (Michael Jackson) Date: Thu, 05 Oct 2017 09:14:32 -0400 Subject: [CMake] cmake buried in subdirectory? In-Reply-To: References: Message-ID: <1B2230AA-E60C-48EB-8B1C-659E879EEEDE@bluequartz.net> You are over thinking it. As someone else stated, check if the build directory and the source directory are the same and if they are you FATAL_ERROR with a message. Otherwise you can put a single CMakeLists.txt file in the top level to kick things off. Plus, I think it is starting to become fairly understood that using the source dir as the build dir is a "bad idea" at this point in software engineering. You are just complicating things. -- Mike Jackson -----Original Message----- From: CMake on behalf of Randy Heiland Date: Wednesday, October 4, 2017 at 9:23 PM To: "J. Caleb Wherry" Cc: "cmake at cmake.org" Subject: Re: [CMake] cmake buried in subdirectory? Thanks for the reply. In my case, I didn't even want the CMakeLists in the top-level dir. I didn't want to contaminate my top-level dir with anything related to CMake. This would avoid, for example, an accidental overwrite of an existing Makefile if one was to do a 'cmake .' in the the top dir. It's quite possible I'm over-thinking this; I was just curious if it's even possible. Seems like it should be. -Randy On Wed, Oct 4, 2017 at 4:30 PM, J. Caleb Wherry wrote: There is no reason why this shouldn't work, I do something similar where everything except my top-level CMakeLists is shoved into a subdirectory (away from the src code location). You don't have to muck with the project macro at all, not sure what you are trying to accomplish with that? That just sets the name of the project. All you have to be aware of is all the paths are now with respect to both the CMakeLists and where ever you put your binary dir. So doing something like the below allows you to reference things in your source tree (depending on how far you away form the root, obviously): get_filename_component(SourceRoot "${CMAKE_CURRENT_SOURCE_DIR}/../../" ABSOLUTE) The normal structure of the CMake file doesn't change, nothing special has to be done with the project macro. Unless you have a more specific error, that's about all the advice I have. -Caleb On Wed, Oct 4, 2017 at 3:16 PM, Randy Heiland wrote: Hello, Simple question... can I/how can I keep my top-level cmake-related stuff in a subdirectory of my main project directory? E.g.: /myproj /cmake CMakeLists.txt and then in the /cmake, I create a /build from which I attempt: cmake .. I tried something as simple as this in my CMakeLists.txt, but it didn't seem to work: project (../myproj) The primary reason I'd like to do this is to hide/make optional the cmake build approach (and keep in place an existing/traditional Makefile in the parent directory). Play along... thanks, Randy -- 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 -- J. Caleb Wherry Scientific Software Engineer http://www.calebwherry.com +1 (615) 708-5651 calebwherry at gmail.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 mellery451 at gmail.com Thu Oct 5 12:33:34 2017 From: mellery451 at gmail.com (Michael Ellery) Date: Thu, 5 Oct 2017 09:33:34 -0700 Subject: [CMake] Generate headers and inherit include_directories In-Reply-To: <59d60e65.85c8370a.c245.7bbeSMTPIN_ADDED_MISSING@mx.google.com> References: <20171003135415.3E43FFD638@public.kitware.com> <30B49ABF-D65A-4CB1-BC90-FB5285CF3C72@gmail.com> <59d60e65.85c8370a.c245.7bbeSMTPIN_ADDED_MISSING@mx.google.com> Message-ID: <360E301F-7417-4B57-BE8B-744C28BDB438@gmail.com> > On Oct 5, 2017, at 3:50 AM, Nagy-Egri M?t? Ferenc wrote: > > Hi Michael! > > This is what I wanted to do (only relevant parts showing): > > /// top-level CMakeLists.txt > add_subdirectory(Gripper) > add_subdirectory(examples) > > > /// Gripper/CmakeLists.txt > set(RESULT ${CMAKE_CURRENT_BINARY_DIR}/inc/Gripper/stl/stlYlms_dynamic.hpp) > add_custom_command(COMMAND ... ARGS ... > OUTPUT ${RESULT}) > add_custom_target(Ylms > DEPENDS ${RESULT}) > > # What comes from HERE > add_library(Gripper::Ylms INTERFACE IMPORTED GLOBAL) > target_include_directories(Gripper::Ylms INTERFACE ${CMAKE_CURRENT_SOURCE_DIR}/inc > ${CMAKE_CURRENT_BINARY_DIR}/inc) > add_dependencies(Gripper::Ylms Ylms) > # to HERE? (Note, example does not work) > > /// examples/CmakeLists.txt > add_executable(example1 main.cpp) > > target_link_libraries(example1 Gripper::Ylms) > > When specifying Gripper::Ylms as a link target for example1, I would like to pick up both the dependency of Ylms being processed first and also the include directory marking the location of the generated header file. > > Note, the closes I got was using > > set_target_properties (Gripper::Ylms PROPERTIES INTERFACE_INCLUDE_DIRECTORIES "${CMAKE_CURRENT_SOURCE_DIR}/inc ${CMAKE_CURRENT_BINARY_DIR}/inc") > > instead of > > target_include_directories(Gripper::Ylms INTERFACE ${CMAKE_CURRENT_SOURCE_DIR}/inc > ${CMAKE_CURRENT_BINARY_DIR}/inc) > > because set_target_properties wouldn?t let me specify multiple entries, but target_include_directories is not allowed on IMPORTED targets (but simple INTERFACE libraries cannot be global)? no combination of commands seem to work. > I think ?IMPORTED? on your header library might be part of the problem?I would remove that. I have an example I will send you privately that does what you want I think? -Mike -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From robert.maynard at kitware.com Thu Oct 5 16:57:37 2017 From: robert.maynard at kitware.com (Robert Maynard) Date: Thu, 5 Oct 2017 16:57:37 -0400 Subject: [CMake] [ANNOUNCE] CMake 3.10.0-rc1 is now ready for testing Message-ID: I am proud to announce the first CMake 3.10 release candidate. https://cmake.org/download/ Documentation is available at: https://cmake.org/cmake/help/v3.10 Release notes appear below and are also published at https://cmake.org/cmake/help/v3.10/release/3.10.html Some of the more significant changes in CMake 3.10 are: * The flang Fortran compiler is now supported, with compiler id "Flang". * Support for the MSVC ARM64 architecture was added. Visual Studio 2017 Update 4 and above offer an ARM64 toolchain. * The "include_guard()" command was introduced to allow guarding CMake scripts from being included more than once. The command supports "DIRECTORY" and "GLOBAL" options to adjust the corresponding include guard scope. If no options given, include guard is similar to basic variable-based check. * "FindMPI" received a major overhaul. It now features language specific components, better Fortran support, and support for statically linked MPI implementations. * A "FindOpenACC" module was added to detect compiler support for OpenACC. Currently only supports PGI, GNU and Cray compilers. * The "FindOpenGL" module underwent numerous improvements. It has gained support for GLVND and EGL on Linux. It now has import targets that separate the OpenGL library and OpenGL contexts. * The "GoogleTest" module gained a new command "gtest_discover_tests()" implementing dynamic (build-time) test discovery. * When using "AUTOMOC" or "AUTOUIC", source files that are "GENERATED" will be processed as well. They were ignored by "AUTOMOC" and "AUTOUIC" in earlier releases. See policy "CMP0071". * A "CTEST_LABELS_FOR_SUBPROJECTS" CTest module variable and CTest script variable were added to specify a list of labels that should be treated as subprojects by CDash. To use this value in both the CTest module and the ctest command line Dashboard Client mode (e.g. "ctest -S") set it in the "CTestConfig.cmake" config file. * CPack gained a "FREEBSD" generator for FreeBSD "pkg(8)", configured by the "CPackFreeBSD" module. * The CPack "DEB" generator, configured by the "CPackDeb" module, was enabled on Windows. While not fully featured (due to the lack of external UNIX tools) this will allow building basic cross- platform Debian packages. * The "cmake(1)" "-E" mode gained support for "sha1sum", "sha224sum", "sha256sum", "sha384sum", and "sha512sum". * The "file(GENERATE)" command now interprets relative paths given to its "OUTPUT" and "INPUT" arguments with respect to the caller's current binary and source directories, respectively. See policy "CMP0070". CMake 3.10 Release Notes ************************ Changes made since CMake 3.9 include the following. New Features ============ Platforms --------- * The flang Fortran compiler is now supported, with compiler id "Flang". * A new minimal platform file for "Midipix" was added. * Support for the MSVC ARM64 architecture was added. Visual Studio 2017 Update 4 and above offer an ARM64 toolchain. * Support for the IAR ARM Compiler was improved. Generators ---------- * The Makefile Generators and the "Ninja" generator learned to add compiler launcher tools like ccache along with the compiler for the "CUDA" language ("C" and "CXX" were supported previously). See the "CMAKE__COMPILER_LAUNCHER" variable and "_COMPILER_LAUNCHER" target property for details. * The "CodeBlocks" extra generator learned to optionally exclude files from outside the project root directory from the generated project. See the "CMAKE_CODEBLOCKS_EXCLUDE_EXTERNAL_FILES" variable. Commands -------- * The "cmake_host_system_information()" command learned more keys to get information about the processor capabilities and the host OS version. * The "configure_file()" command learned to support indented "# cmakedefine" and "# cmakedefine01". Spaces and/or tabs between the "#" character and the "cmakedefine"/"cmakedefine01" words are now understood and preserved in the output. * The "execute_process()" command gained a "RESULTS_VARIABLE" option to collect a list of results from all children in a pipeline of processes when multiple "COMMAND" arguments are given. * The "include_guard()" command was introduced to allow guarding CMake scripts from being included more than once. The command supports "DIRECTORY" and "GLOBAL" options to adjust the corresponding include guard scope. If no options given, include guard is similar to basic variable-based check. * The "string()" command learned a new "PREPEND" subcommand. * The "string(TIMESTAMP)" command now supports "%A" for full weekday name and "%B" for full month name. Variables --------- * A "CMAKE_DIRECTORY_LABELS" variable was added to specify labels for all tests in a directory. Properties ---------- * A "_CPPCHECK" target property and supporting "CMAKE__CPPCHECK" variable were introduced to tell the Makefile Generators and the "Ninja" generator to run "cppcheck" with the compiler for "C" and "CXX" languages. * A "LABELS" directory property was added to specify labels for all targets and tests in a directory. * A "TEST_INCLUDE_FILES" directory property was added to list any number of files to be included when running tests with "ctest(1)". This generalizes the "TEST_INCLUDE_FILE" property. * The "VS_DOTNET_REFERENCEPROP__TAG_" target property was added to support custom XML tags for reference assemblies in C# targets. * Source file properties "VS_SHADER_OUTPUT_HEADER_FILE" and "VS_SHADER_VARIABLE_NAME" have been added to specify more details of ".hlsl" sources with Visual Studio Generators. Modules ------- * The "FindCurses" module gained a "CURSES_NEED_WIDE" option to request the wide-character variant. * The "FindEXPAT" module now provides imported targets. * The "FindFreetype" module now provides imported targets. * "FindMPI" gained a number of new features, including: * Language-specific components have been added to the module. * Many more MPI environments are now supported. * The environmental support for Fortran has been improved. * A user now has fine-grained control over the MPI selection process, including passing custom parameters to the MPI compiler. * The version of the implemented MPI standard is now being exposed. * MPI-2 C++ bindings can now be detected and also suppressed if so desired. * The available Fortran bindings are now being detected and verified. * Various MPI-3 information can be requested, including the library version and Fortran capabilities of the individual bindings. * Statically linked MPI implementations are supported. * A "FindOpenACC" module was added to detect compiler support for OpenACC. Currently only supports PGI, GNU and Cray compilers. * The "FindOpenGL" module gained support for GLVND on Linux. * The "FindOpenMP" module gained support for language-specific components. * A "FindPatch" module was added to find the "patch" command-line executable. * The "FindProtobuf" module "protobuf_generate_cpp()" command gained a "DESCRIPTORS" option to generate descriptor files. * The "GoogleTest" module gained a new command "gtest_discover_tests()" implementing dynamic (build-time) test discovery. Unlike the source parsing approach, dynamic discovery executes the test (in 'list available tests' mode) at build time to discover tests. This is robust against unusual ways of labeling tests, provides much better support for advanced features such as parameterized tests, and does not require re-running CMake to discover added or removed tests within a test executable. * The "InstallRequiredSystemLibraries" module gained support for installing Intel compiler runtimes. Autogen ------- * When using "AUTOMOC" or "AUTOUIC" with a multi configuration generator (e.g. "Xcode"), included "*.moc", "moc_*.cpp" and "ui_*.h" files are generated in "/include_" instead of "/include". * When using "AUTOMOC" or "AUTOUIC", source files that are "GENERATED" will be processed as well. They were ignored by "AUTOMOC" and "AUTOUIC" in earlier releases. See policy "CMP0071". * When using "AUTOMOC", CMake searches for the strings "Q_OBJECT", "Q_GADGET" or "Q_NAMESPACE" in a source file to determine if it needs to be "moc" processed. The new variable "CMAKE_AUTOMOC_MACRO_NAMES" allows to register additional strings (macro names) so search for. * When using "AUTOMOC", CMake searches for the strings "Q_OBJECT", "Q_GADGET" or "Q_NAMESPACE" in a source file to determine if it needs to be "moc" processed. The new target property "AUTOMOC_MACRO_NAMES" allows to register additional strings (macro names) so search for. * When using "AUTOMOC", the new variable "CMAKE_AUTOMOC_COMPILER_PREDEFINES" allows to default enable or disable the generation of the compiler pre definitions file "moc_predefs.h". * When using "AUTOMOC", the new boolean target property "AUTOMOC_COMPILER_PREDEFINES" allows to enable or disable the generation of the compiler pre definitions file "moc_predefs.h". CTest ----- * A "CTEST_LABELS_FOR_SUBPROJECTS" CTest module variable and CTest script variable were added to specify a list of labels that should be treated as subprojects by CDash. To use this value in both the CTest module and the ctest command line Dashboard Client mode (e.g. "ctest -S") set it in the "CTestConfig.cmake" config file. CPack ----- * CPack gained a "FREEBSD" generator for FreeBSD "pkg(8)", configured by the "CPackFreeBSD" module. * The CPack "DEB" generator, configured by the "CPackDeb" module, was enabled on Windows. While not fully featured (due to the lack of external UNIX tools) this will allow building basic cross- platform Debian packages. * The "CPackDeb" module learned to set package release version in "Version" info property. See the "CPACK_DEBIAN_PACKAGE_RELEASE" variable. * The "CPackDeb" module learned more strict package version checking that complies with Debian rules. * The "CPackIFW" module "cpack_ifw_configure_component()" and "cpack_ifw_configure_component_group()" commands gained a new "REPLACES" and "CHECKABLE" options. * The "CPackIFW" module gained new "CPACK_IFW_PACKAGE_FILE_EXTENSION" variable to customize target binary format. * The "CPackIFW" module gained new "CPACK_IFW_REPOSITORIES_DIRECTORIES" variable to specify additional repositories dirs that will be used to resolve and repack dependent components. This feature available only since QtIFW 3.1. * Modules "CPackRPM" and "CPackDeb" learned to set package epoch version. See "CPACK_RPM_PACKAGE_EPOCH" and "CPACK_DEBIAN_PACKAGE_EPOCH" variables. Other ----- * The "cmake(1)" "-E" mode gained support for "sha1sum", "sha224sum", "sha256sum", "sha384sum", and "sha512sum". * The graphviz output now distinguishes among the different dependency types "PUBLIC", "PRIVATE" and "INTERFACE" and represents them in the output graph as solid, dashed and dotted edges. Deprecated and Removed Features =============================== * Support for building CMake itself with C++98 compilers was dropped. CMake is now implemented using C++11. * Support for building CMake on HP-UX has been dropped pending better support for C++11 and a port of libuv. See CMake Issue 17137. Use CMake 3.9 or lower instead for HP-UX support. Other Changes ============= * On FreeBSD the C++ compiler named "c++" is now the preferred default. * The "file(GENERATE)" command now interprets relative paths given to its "OUTPUT" and "INPUT" arguments with respect to the caller's current binary and source directories, respectively. See policy "CMP0070". * The "get_filename_component()" "PROGRAM" mode semantics have been revised to not tolerate unquoted spaces in the path to the program while also accepting arguments. While technically incompatible with the old behavior, it is expected that behavior under typical use cases with properly-quoted command-lines has not changed. From senat.alaric at gmail.com Fri Oct 6 05:48:33 2017 From: senat.alaric at gmail.com (Alaric Senat) Date: Fri, 6 Oct 2017 11:48:33 +0200 Subject: [CMake] Finding ${prefix}install_name_tool in cross compilation Message-ID: Hello, I'm currently trying to compile a library from Linux to Darwin 13 with clang and I am facing a strange issue. When CMake is trying to find the tools it needs in addition to clang (ar, ranlib, etc.) CMake can't find the install_name_tool binary just because it has a prefix like all the other tool. The way Cmake search for *install_name_tool *in the *CMakeFindBinUtils.cmake *file looks like this: *find_program(CMAKE_INSTALL_NAME_TOOL NAMES install_name_tool HINTS ${_CMAKE_TOOLCHAIN_LOCATION})* And for *ranlib* for example: *find_program(CMAKE_RANLIB NAMES ${_CMAKE_TOOLCHAIN_PREFIX}ranlib HINTS ${_CMAKE_TOOLCHAIN_LOCATION})* So, to find install_name_tool, cmake is not adding the prefix before, and that's a big issue for me, each compilators tools has a prefix in my '.../bin' directory ! Do you think that this prefix missing in the finding of install_name_tool is intended or is it just an oversight ? Sincerely, Aalric SENAT -------------- next part -------------- An HTML attachment was scrubbed... URL: From annulen at yandex.ru Sat Oct 7 07:10:13 2017 From: annulen at yandex.ru (Konstantin Tokarev) Date: Sat, 07 Oct 2017 14:10:13 +0300 Subject: [CMake] CMP0071 Message-ID: <1660941507374613@web49g.yandex.ru> Hello, I've just learned about CMP0071 introduced in upcoming 3.10 release. Is it possible to replace new policy with new global variable/per-target property to avoid need setting of SKIP_AUTOMOC OFF on each generated file separately? Thanks. -- Regards, Konstantin From annulen at yandex.ru Sat Oct 7 10:13:20 2017 From: annulen at yandex.ru (Konstantin Tokarev) Date: Sat, 07 Oct 2017 17:13:20 +0300 Subject: [CMake] CMP0071 In-Reply-To: <1660941507374613@web49g.yandex.ru> References: <1660941507374613@web49g.yandex.ru> Message-ID: <947671507385600@web25g.yandex.ru> 07.10.2017, 14:18, "Konstantin Tokarev" : > Hello, > > I've just learned about CMP0071 introduced in upcoming 3.10 release. > > Is it possible to replace new policy with new global variable/per-target property to avoid need setting of SKIP_AUTOMOC OFF on each generated file separately? > > Thanks. Also, I've found following issue: setting CMP0071 to OLD in the top-level project does not suppress warnings, unless I set CMP0071 to OLD in each subdirectory. cmake_policy(GET CMP0071 var) in subdir's CMakeLists.txt returns OLD, but warning is suppressed only if I set it to OLD once again. > > -- > Regards, > Konstantin > -- > > 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 craig.scott at crascit.com Sun Oct 8 16:30:16 2017 From: craig.scott at crascit.com (Craig Scott) Date: Mon, 9 Oct 2017 07:30:16 +1100 Subject: [CMake] CMP0071 In-Reply-To: <947671507385600@web25g.yandex.ru> References: <1660941507374613@web49g.yandex.ru> <947671507385600@web25g.yandex.ru> Message-ID: On Sun, Oct 8, 2017 at 1:13 AM, Konstantin Tokarev wrote: > > > 07.10.2017, 14:18, "Konstantin Tokarev" : > > Hello, > > > > I've just learned about CMP0071 introduced in upcoming 3.10 release. > > > > Is it possible to replace new policy with new global variable/per-target > property to avoid need setting of SKIP_AUTOMOC OFF on each generated file > separately? > > > > Thanks. > > Also, I've found following issue: setting CMP0071 to OLD in the top-level > project does not suppress warnings, unless I set CMP0071 to OLD in each > subdirectory. cmake_policy(GET CMP0071 var) in subdir's CMakeLists.txt > returns OLD, but warning is suppressed only if I set it to OLD once again. > Just a thought, do you have calls to cmake_minimum_required(VERSION ...) or cmake_policy(VERSION ...) in your subdirs? These reset the policy settings to match the specified version. -- Craig Scott Melbourne, Australia https://crascit.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From heavy.watal at gmail.com Mon Oct 9 02:29:24 2017 From: heavy.watal at gmail.com (Watal M. Iwasaki) Date: Mon, 9 Oct 2017 15:29:24 +0900 Subject: [CMake] How to suppress symlink resolution for CMAKE_COMMAND Message-ID: Hi all, I am using CMake installed via Homebrew. The actual file is placed at `/usr/local/Cellar/cmake/3.9.4/bin/cmake`, and its symlink `/usr/local/bin/cmake` is in my PATH. CMake resolves the symlink and creates Makefile with CMAKE_COMMAND pointing the actual file. Because of this behavior, every time CMake is upgraded, I have to re-run cmake or encounter an error like `/usr/local/Cellar/cmake/3.9.2/bin/cmake: No such file or directory`. Is there any way to suppress symlink resolution and let CMAKE_COMMAND just store the symlink in the PATH? Best, Watal M. Iwasaki -------------- next part -------------- An HTML attachment was scrubbed... URL: From annulen at yandex.ru Mon Oct 9 06:54:13 2017 From: annulen at yandex.ru (Konstantin Tokarev) Date: Mon, 09 Oct 2017 13:54:13 +0300 Subject: [CMake] CMP0071 In-Reply-To: References: <1660941507374613@web49g.yandex.ru> <947671507385600@web25g.yandex.ru> Message-ID: <12391507546453@web23o.yandex.ru> 08.10.2017, 23:30, "Craig Scott" : > On Sun, Oct 8, 2017 at 1:13 AM, Konstantin Tokarev wrote: > >> 07.10.2017, 14:18, "Konstantin Tokarev" : >>> Hello, >>> >>> I've just learned about CMP0071 introduced in upcoming 3.10 release. >>> >>> Is it possible to replace new policy with new global variable/per-target property to avoid need setting of SKIP_AUTOMOC OFF on each generated file separately? >>> >>> Thanks. >> >> Also, I've found following issue: setting CMP0071 to OLD in the top-level project does not suppress warnings, unless I set CMP0071 to OLD in each subdirectory. cmake_policy(GET CMP0071 var) in subdir's CMakeLists.txt returns OLD, but warning is suppressed only if I set it to OLD once again. > > Just a thought, do you have calls to cmake_minimum_required(VERSION ...) or cmake_policy(VERSION ...) in your subdirs? These reset the policy settings to match the specified version. That was the case, thanks! > > -- > Craig Scott > Melbourne, Australia > https://crascit.com --? Regards, Konstantin From james.turner at kdab.com Mon Oct 9 10:05:12 2017 From: james.turner at kdab.com (James Turner) Date: Mon, 9 Oct 2017 16:05:12 +0200 Subject: [CMake] Setting global default for a target property (DEBUG_POSTFIX) Message-ID: <25CAB931-C8B5-4172-9A57-16DC274DF484@kdab.com> Hi, Some of the windows developers for FlightGear would like to set a build-type suffix for executables, which they can do like this: set_target_properties( ourexetarget PROPERTIES DEBUG_POSTFIX d ) We already set the suffix for shared libraries with: set(CMAKE_DEBUG_POSTFIX "d" CACHE STRING "add a postfix, usually d on windows?) The problem is for executables, we seem to need to set the POSTFIX separately each time. Setting DEBUG_POSTFIX as a GLOBAL property doesn?t seem to work. Is this possible, to set the default value for a target property? Or is there something special about executable targets for this? Kind regards, James Turner From pgnet.dev at gmail.com Wed Oct 11 19:37:59 2017 From: pgnet.dev at gmail.com (pgndev) Date: Wed, 11 Oct 2017 16:37:59 -0700 Subject: [CMake] =?utf-8?q?Cpack_generating_hundreds_of_=22=E2=80=8BUnsupp?= =?utf-8?q?orted_ioctl=3A_cmd=3D0xffffffff80046601_=284=29=3B_0x800?= =?utf-8?b?ODY2MDEgLT4gRlNfSU9DX0dFVEZMQUdTICg4KSIgbWVzc2FnZXM/?= Message-ID: I'm building an app addon that uses Cpack to package up a zip, invoked from a makefile. At Cpack exec, it *does* package the zip, but also returns 300+ "Unsupported ioctl" messages. They appear to be non-fatal, but are clearly indicating some problem: /usr/bin/cpack --config ./CPackConfig.cmake CPack: Create package using ZIP CPack: Install projects CPack: - Run preinstall target for: pvr.iptvsimple CPack: - Install project: pvr.iptvsimple CPack: - Install component: pvr.iptvsimple-3.3.1 CPack: Create package Unsupported ioctl: cmd=0xffffffff80046601 (4) 0x80086601 -> FS_IOC_GETFLAGS (8) Unsupported ioctl: cmd=0xffffffff80046601 (4) 0x80086601 -> FS_IOC_GETFLAGS (8) ... ( 300 + repetitions ) ... 0x80086601 -> FS_IOC_GETFLAGS (8) Unsupported ioctl: cmd=0xffffffff80046601 (4) 0x80086601 -> FS_IOC_GETFLAGS (8) CPack: - package: /usr/local/src/pvr.iptvsimple/build/addon-pvr.iptvsimple-3.3.1.zip generated. cmake here is cmake --version cmake version 3.7.2 CMake suite maintained and supported by Kitware (kitware.com/cmake). running in a Raspbian9 chroot. It's not just this addon; it's occurring on all addon's zipped -- within this parent app, on this box. What's causing these messages? Some missing dependency? Is there a fix/workaround? For reference, cat ./CPackConfig.cmake # This file will be configured to contain variables for CPack. These variables # should be set in the CMake list file of the project before CPack module is # included. The list of available CPACK_xxx variables and their associated # documentation may be obtained using # cpack --help-variable-list # # Some variables are common to all generators (e.g. CPACK_PACKAGE_NAME) # and some are specific to a generator # (e.g. CPACK_NSIS_EXTRA_INSTALL_COMMANDS). The generator specific variables # usually begin with CPACK__xxxx. SET(CPACK_ARCHIVE_COMPONENT_INSTALL "ON") SET(CPACK_BINARY_7Z "") SET(CPACK_BINARY_BUNDLE "") SET(CPACK_BINARY_CYGWIN "") SET(CPACK_BINARY_DEB "") SET(CPACK_BINARY_DRAGNDROP "") SET(CPACK_BINARY_IFW "") SET(CPACK_BINARY_NSIS "") SET(CPACK_BINARY_OSXX11 "") SET(CPACK_BINARY_PACKAGEMAKER "") SET(CPACK_BINARY_PRODUCTBUILD "") SET(CPACK_BINARY_RPM "") SET(CPACK_BINARY_STGZ "") SET(CPACK_BINARY_TBZ2 "") SET(CPACK_BINARY_TGZ "") SET(CPACK_BINARY_TXZ "") SET(CPACK_BINARY_TZ "") SET(CPACK_BINARY_WIX "") SET(CPACK_BINARY_ZIP "") SET(CPACK_BUILD_SOURCE_DIRS "/usr/local/src/pvr.iptvsimple;/usr/local/src/pvr.iptvsimple/build") SET(CPACK_CMAKE_GENERATOR "Unix Makefiles") SET(CPACK_COMPONENTS_ALL "pvr.iptvsimple-3.3.1") SET(CPACK_COMPONENTS_ALL_SET_BY_USER "TRUE") SET(CPACK_COMPONENTS_IGNORE_GROUPS "1") SET(CPACK_COMPONENT_UNSPECIFIED_HIDDEN "TRUE") SET(CPACK_COMPONENT_UNSPECIFIED_REQUIRED "TRUE") SET(CPACK_GENERATOR "ZIP") SET(CPACK_INCLUDE_TOPLEVEL_DIRECTORY "OFF") SET(CPACK_INSTALL_CMAKE_PROJECTS "/usr/local/src/pvr.iptvsimple/build;pvr.iptvsimple;ALL;/") SET(CPACK_INSTALL_PREFIX "/usr/local") SET(CPACK_MODULE_PATH "/usr/local/kodi/lib/kodi;/usr/local/kodi/share/kodi/cmake") SET(CPACK_NSIS_DISPLAY_NAME "pvr.iptvsimple 0.1.1") SET(CPACK_NSIS_INSTALLER_ICON_CODE "") SET(CPACK_NSIS_INSTALLER_MUI_ICON_CODE "") SET(CPACK_NSIS_INSTALL_ROOT "$PROGRAMFILES") SET(CPACK_NSIS_PACKAGE_NAME "pvr.iptvsimple 0.1.1") SET(CPACK_OUTPUT_CONFIG_FILE "/usr/local/src/pvr.iptvsimple/build/CPackConfig.cmake") SET(CPACK_PACKAGE_DEFAULT_LOCATION "/") SET(CPACK_PACKAGE_DESCRIPTION_FILE "/usr/share/cmake-3.7/Templates/CPack.GenericDescription.txt") SET(CPACK_PACKAGE_DESCRIPTION_SUMMARY "pvr.iptvsimple built using CMake") SET(CPACK_PACKAGE_DIRECTORY "/usr/local/src/pvr.iptvsimple/build") SET(CPACK_PACKAGE_FILE_NAME "addon") SET(CPACK_PACKAGE_INSTALL_DIRECTORY "pvr.iptvsimple 0.1.1") SET(CPACK_PACKAGE_INSTALL_REGISTRY_KEY "pvr.iptvsimple 0.1.1") SET(CPACK_PACKAGE_NAME "pvr.iptvsimple") SET(CPACK_PACKAGE_RELOCATABLE "true") SET(CPACK_PACKAGE_VENDOR "Humanity") SET(CPACK_PACKAGE_VERSION "0.1.1") SET(CPACK_PACKAGE_VERSION_MAJOR "0") SET(CPACK_PACKAGE_VERSION_MINOR "1") SET(CPACK_PACKAGE_VERSION_PATCH "1") SET(CPACK_RESOURCE_FILE_LICENSE "/usr/share/cmake-3.7/Templates/CPack.GenericLicense.txt") SET(CPACK_RESOURCE_FILE_README "/usr/share/cmake-3.7/Templates/CPack.GenericDescription.txt") SET(CPACK_RESOURCE_FILE_WELCOME "/usr/share/cmake-3.7/Templates/CPack.GenericWelcome.txt") SET(CPACK_SET_DESTDIR "OFF") SET(CPACK_SOURCE_7Z "") SET(CPACK_SOURCE_CYGWIN "") SET(CPACK_SOURCE_GENERATOR "TBZ2;TGZ;TXZ;TZ") SET(CPACK_SOURCE_OUTPUT_CONFIG_FILE "/usr/local/src/pvr.iptvsimple/build/CPackSourceConfig.cmake") SET(CPACK_SOURCE_RPM "OFF") SET(CPACK_SOURCE_TBZ2 "ON") SET(CPACK_SOURCE_TGZ "ON") SET(CPACK_SOURCE_TXZ "ON") SET(CPACK_SOURCE_TZ "ON") SET(CPACK_SOURCE_ZIP "OFF") SET(CPACK_SYSTEM_NAME "Linux") SET(CPACK_TOPLEVEL_TAG "Linux") SET(CPACK_WIX_SIZEOF_VOID_P "4") if(NOT CPACK_PROPERTIES_FILE) set(CPACK_PROPERTIES_FILE "/usr/local/src/pvr.iptvsimple/build/CPackProperties.cmake") endif() if(EXISTS ${CPACK_PROPERTIES_FILE}) include(${CPACK_PROPERTIES_FILE}) endif() and the full --debug output of the pack step, /usr/bin/cpack --debug --config ./CPackConfig.cmake CPack: /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cpack.cxx:175 Enable Debug /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:891 cmCPackZIPGenerator::SetOption(CPACK_GENERATOR, ZIP) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:1082 Warning, GetOption return NULL for: CPACK_PROJECT_CONFIG_FILE /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:891 cmCPackZIPGenerator::SetOption(CPACK_PACKAGING_INSTALL_PREFIX, /) CPack: /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:898 Create package using ZIP /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:55 Create temp directory. /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:891 cmCPackZIPGenerator::SetOption(CPACK_OUTPUT_FILE_PREFIX, /usr/local/src/pvr.iptvsimple/build) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:891 cmCPackZIPGenerator::SetOption(CPACK_TOPLEVEL_DIRECTORY, /usr/local/src/pvr.iptvsimple/build/_CPack_Packages/Linux/ZIP) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:891 cmCPackZIPGenerator::SetOption(CPACK_TEMPORARY_DIRECTORY, /usr/local/src/pvr.iptvsimple/build/_CPack_Packages/Linux/ZIP/addon) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:891 cmCPackZIPGenerator::SetOption(CPACK_OUTPUT_FILE_NAME, addon.zip) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:891 cmCPackZIPGenerator::SetOption(CPACK_OUTPUT_FILE_PATH, /usr/local/src/pvr.iptvsimple/build/addon.zip) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:891 cmCPackZIPGenerator::SetOption(CPACK_TEMPORARY_PACKAGE_FILE_NAME, /usr/local/src/pvr.iptvsimple/build/_CPack_Packages/Linux/ZIP/addon.zip) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:891 cmCPackZIPGenerator::SetOption(CPACK_INSTALL_DIRECTORY, /usr/local/) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:891 cmCPackZIPGenerator::SetOption(CPACK_NATIVE_INSTALL_DIRECTORY, /usr/local/) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:891 cmCPackZIPGenerator::SetOption(CPACK_TEMPORARY_INSTALL_DIRECTORY, /usr/local/src/pvr.iptvsimple/build/_CPack_Packages/Linux/ZIP/addon) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:121 Look for: CPACK_PACKAGE_DESCRIPTION_FILE /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:125 Look for: /usr/share/cmake-3.7/Templates/CPack.GenericDescription.txt /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:891 cmCPackZIPGenerator::SetOption(CPACK_PACKAGE_DESCRIPTION, DESCRIPTION =========== This is an installer created using CPack (https://cmake.org). No additional installation instructions provided. ) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:1082 Warning, GetOption return NULL for: CPACK_PACKAGE_CHECKSUM /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:891 cmCPackZIPGenerator::SetOption(CPACK_REMOVE_TOPLEVEL_DIRECTORY, 1) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:1082 Warning, GetOption return NULL for: CPACK_COMPONENTS_ALL_IN_ONE_PACKAGE /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:1082 Warning, GetOption return NULL for: CPACK_COMPONENTS_ONE_PACKAGE_PER_GROUP /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:1082 Warning, GetOption return NULL for: CPACK_COMPONENTS_GROUPING /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:927 About to install project CPack: /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:173 Install projects /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:1135 GetPackagingInstallPrefix: '/' /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:1082 Warning, GetOption return NULL for: CPACK_INSTALL_COMMANDS /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:1082 Warning, GetOption return NULL for: CPACK_INSTALL_SCRIPT /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:1082 Warning, GetOption return NULL for: CPACK_IGNORE_FILES /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:1082 Warning, GetOption return NULL for: CPACK_INSTALLED_DIRECTORIES /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:1082 Warning, GetOption return NULL for: CPACK_MONOLITHIC_INSTALL /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:1082 Warning, GetOption return NULL for: CPACK_ALL_INSTALL_TYPES /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:1082 Warning, GetOption return NULL for: CPACK_COMPONENT_PVR.IPTVSIMPLE-3.3.1_DISPLAY_NAME /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:1082 Warning, GetOption return NULL for: CPACK_COMPONENT_PVR.IPTVSIMPLE-3.3.1_HIDDEN /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:1082 Warning, GetOption return NULL for: CPACK_COMPONENT_PVR.IPTVSIMPLE-3.3.1_REQUIRED /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:1082 Warning, GetOption return NULL for: CPACK_COMPONENT_PVR.IPTVSIMPLE-3.3.1_DISABLED /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:1082 Warning, GetOption return NULL for: CPACK_COMPONENT_PVR.IPTVSIMPLE-3.3.1_DOWNLOADED /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:1082 Warning, GetOption return NULL for: CPACK_DOWNLOAD_ALL /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:1082 Warning, GetOption return NULL for: CPACK_COMPONENT_PVR.IPTVSIMPLE-3.3.1_ARCHIVE_FILE /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:1082 Warning, GetOption return NULL for: CPACK_COMPONENT_PVR.IPTVSIMPLE-3.3.1_GROUP /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:1082 Warning, GetOption return NULL for: CPACK_COMPONENT_PVR.IPTVSIMPLE-3.3.1_DESCRIPTION /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:1082 Warning, GetOption return NULL for: CPACK_COMPONENT_PVR.IPTVSIMPLE-3.3.1_INSTALL_TYPES /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:1082 Warning, GetOption return NULL for: CPACK_COMPONENT_PVR.IPTVSIMPLE-3.3.1_DEPENDS /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:1082 Warning, GetOption return NULL for: CPACK_BUILD_CONFIG /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:584 - Install command: /usr/bin/cmake --build . --target "preinstall" CPack: /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:586 - Run preinstall target for: pvr.iptvsimple CPack: /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:610 - Install project: pvr.iptvsimple CPack: /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:620 - Install component: pvr.iptvsimple-3.3.1 /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:1082 Warning, GetOption return NULL for: CPACK_COMPONENT_INCLUDE_TOPLEVEL_DIRECTORY /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:1135 GetPackagingInstallPrefix: '/' /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:731 - Using non-DESTDIR install... (mf->AddDefinition) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:734 - Setting CMAKE_INSTALL_PREFIX to '/usr/local/src/pvr.iptvsimple/build/_CPack_Packages/Linux/ZIP/addon/pvr.iptvsimple-3.3.1/' /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:1082 Warning, GetOption return NULL for: CPACK_STRIP_FILES /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:1082 Warning, GetOption return NULL for: CPACK_WARN_ON_ABSOLUTE_INSTALL_DESTINATION /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:1082 Warning, GetOption return NULL for: CPACK_ERROR_ON_ABSOLUTE_INSTALL_DESTINATION /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:818 Adding file to component /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:818 Adding file to component /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:818 Adding file to component /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:818 Adding file to component /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:818 Adding file to component /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:818 Adding file to component /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:818 Adding file to component /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:818 Adding file to component /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:818 Adding file to component /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:818 Adding file to component /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:818 Adding file to component /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:818 Adding file to component /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:818 Adding file to component /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:818 Adding file to component /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:818 Adding file to component /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:818 Adding file to component /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:818 Adding file to component /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:818 Adding file to component /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:818 Adding file to component /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:818 Adding file to component /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:818 Adding file to component /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:818 Adding file to component /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:818 Adding file to component /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:818 Adding file to component /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:818 Adding file to component /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:818 Adding file to component /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:818 Adding file to component /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:818 Adding file to component /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:818 Adding file to component /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:818 Adding file to component /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:818 Adding file to component /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:818 Adding file to component /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:818 Adding file to component /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:818 Adding file to component /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:818 Adding file to component /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:818 Adding file to component /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:818 Adding file to component /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:818 Adding file to component /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:818 Adding file to component /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:818 Adding file to component /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:818 Adding file to component /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:818 Adding file to component /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:818 Adding file to component /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:818 Adding file to component /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:818 Adding file to component /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:818 Adding file to component /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:818 Adding file to component /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:818 Adding file to component /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:818 Adding file to component /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:818 Adding file to component /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:818 Adding file to component /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:818 Adding file to component /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:818 Adding file to component /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:818 Adding file to component /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:818 Adding file to component /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:818 Adding file to component /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:818 Adding file to component /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:818 Adding file to component /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:818 Adding file to component /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:818 Adding file to component /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:818 Adding file to component /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:818 Adding file to component /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:818 Adding file to component /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:818 Adding file to component /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:818 Adding file to component /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:818 Adding file to component /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:818 Adding file to component /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:818 Adding file to component /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:818 Adding file to component /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:818 Adding file to component /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:818 Adding file to component /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:818 Adding file to component /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:818 Adding file to component /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:818 Adding file to component /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:818 Adding file to component /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:818 Adding file to component /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:818 Adding file to component /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:818 Adding file to component /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:818 Adding file to component /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:818 Adding file to component /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:818 Adding file to component /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:818 Adding file to component /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:818 Adding file to component /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:818 Adding file to component /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:818 Adding file to component /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:818 Adding file to component /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:818 Adding file to component /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:818 Adding file to component /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:818 Adding file to component /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:818 Adding file to component /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:818 Adding file to component /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:818 Adding file to component /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:818 Adding file to component /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:818 Adding file to component /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:818 Adding file to component /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:818 Adding file to component /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:818 Adding file to component /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:818 Adding file to component /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:818 Adding file to component /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:818 Adding file to component /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:818 Adding file to component /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:818 Adding file to component /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:818 Adding file to component /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:818 Adding file to component /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:818 Adding file to component /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:818 Adding file to component /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:818 Adding file to component /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:818 Adding file to component /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:818 Adding file to component /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:818 Adding file to component /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:818 Adding file to component /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:818 Adding file to component /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:818 Adding file to component /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:818 Adding file to component /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:818 Adding file to component /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:818 Adding file to component /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:818 Adding file to component /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:818 Adding file to component /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:818 Adding file to component /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:818 Adding file to component /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:818 Adding file to component /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:818 Adding file to component /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:818 Adding file to component /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:818 Adding file to component /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:818 Adding file to component /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:818 Adding file to component /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:818 Adding file to component /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:818 Adding file to component /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:818 Adding file to component /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:818 Adding file to component /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:818 Adding file to component /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:818 Adding file to component /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:818 Adding file to component /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:818 Adding file to component /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:818 Adding file to component /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:818 Adding file to component /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:818 Adding file to component /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:818 Adding file to component /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:818 Adding file to component /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:818 Adding file to component /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:818 Adding file to component /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:818 Adding file to component /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:818 Adding file to component /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:818 Adding file to component /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:818 Adding file to component /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:818 Adding file to component /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:818 Adding file to component /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:818 Adding file to component /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:818 Adding file to component /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:818 Adding file to component /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:818 Adding file to component /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:818 Adding file to component /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:818 Adding file to component /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:818 Adding file to component /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:818 Adding file to component /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:818 Adding file to component /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:818 Adding file to component /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:818 Adding file to component /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:891 cmCPackZIPGenerator::SetOption(CPACK_ABSOLUTE_DESTINATION_FILES, ) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:932 Done install project /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:938 Find files CPack: /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:951 Create package /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackArchiveGenerator.cxx:210 Toplevel: /usr/local/src/pvr.iptvsimple/build/_CPack_Packages/Linux/ZIP/addon /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:1082 Warning, GetOption return NULL for: CPACK_MONOLITHIC_INSTALL /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:1082 Warning, GetOption return NULL for: CPACK_ZIP_USE_DISPLAY_NAME_IN_FILENAME /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:1082 Warning, GetOption return NULL for: CPACK_COMPONENT_INCLUDE_TOPLEVEL_DIRECTORY /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackArchiveGenerator.cxx:59 Adding file: pvr.iptvsimple Unsupported ioctl: cmd=0xffffffff80046601 (4) 0x80086601 -> FS_IOC_GETFLAGS (8) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackArchiveGenerator.cxx:59 Adding file: pvr.iptvsimple/addon.xml Unsupported ioctl: cmd=0xffffffff80046601 (4) 0x80086601 -> FS_IOC_GETFLAGS (8) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackArchiveGenerator.cxx:59 Adding file: pvr.iptvsimple/changelog.txt Unsupported ioctl: cmd=0xffffffff80046601 (4) 0x80086601 -> FS_IOC_GETFLAGS (8) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackArchiveGenerator.cxx:59 Adding file: pvr.iptvsimple/icon.png Unsupported ioctl: cmd=0xffffffff80046601 (4) 0x80086601 -> FS_IOC_GETFLAGS (8) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackArchiveGenerator.cxx:59 Adding file: pvr.iptvsimple/pvr.iptvsimple.so /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackArchiveGenerator.cxx:59 Adding file: pvr.iptvsimple/pvr.iptvsimple.so.18.0 /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackArchiveGenerator.cxx:59 Adding file: pvr.iptvsimple/pvr.iptvsimple.so.3.3.1 Unsupported ioctl: cmd=0xffffffff80046601 (4) 0x80086601 -> FS_IOC_GETFLAGS (8) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackArchiveGenerator.cxx:59 Adding file: pvr.iptvsimple/resources Unsupported ioctl: cmd=0xffffffff80046601 (4) 0x80086601 -> FS_IOC_GETFLAGS (8) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackArchiveGenerator.cxx:59 Adding file: pvr.iptvsimple/resources/language Unsupported ioctl: cmd=0xffffffff80046601 (4) 0x80086601 -> FS_IOC_GETFLAGS (8) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackArchiveGenerator.cxx:59 Adding file: pvr.iptvsimple/resources/language/resource.language.af_za Unsupported ioctl: cmd=0xffffffff80046601 (4) 0x80086601 -> FS_IOC_GETFLAGS (8) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackArchiveGenerator.cxx:59 Adding file: pvr.iptvsimple/resources/language/resource.language.af_za/strings.po Unsupported ioctl: cmd=0xffffffff80046601 (4) 0x80086601 -> FS_IOC_GETFLAGS (8) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackArchiveGenerator.cxx:59 Adding file: pvr.iptvsimple/resources/language/resource.language.am_et Unsupported ioctl: cmd=0xffffffff80046601 (4) 0x80086601 -> FS_IOC_GETFLAGS (8) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackArchiveGenerator.cxx:59 Adding file: pvr.iptvsimple/resources/language/resource.language.am_et/strings.po Unsupported ioctl: cmd=0xffffffff80046601 (4) 0x80086601 -> FS_IOC_GETFLAGS (8) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackArchiveGenerator.cxx:59 Adding file: pvr.iptvsimple/resources/language/resource.language.ar_sa Unsupported ioctl: cmd=0xffffffff80046601 (4) 0x80086601 -> FS_IOC_GETFLAGS (8) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackArchiveGenerator.cxx:59 Adding file: pvr.iptvsimple/resources/language/resource.language.ar_sa/strings.po Unsupported ioctl: cmd=0xffffffff80046601 (4) 0x80086601 -> FS_IOC_GETFLAGS (8) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackArchiveGenerator.cxx:59 Adding file: pvr.iptvsimple/resources/language/resource.language.az_az Unsupported ioctl: cmd=0xffffffff80046601 (4) 0x80086601 -> FS_IOC_GETFLAGS (8) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackArchiveGenerator.cxx:59 Adding file: pvr.iptvsimple/resources/language/resource.language.az_az/strings.po Unsupported ioctl: cmd=0xffffffff80046601 (4) 0x80086601 -> FS_IOC_GETFLAGS (8) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackArchiveGenerator.cxx:59 Adding file: pvr.iptvsimple/resources/language/resource.language.be_by Unsupported ioctl: cmd=0xffffffff80046601 (4) 0x80086601 -> FS_IOC_GETFLAGS (8) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackArchiveGenerator.cxx:59 Adding file: pvr.iptvsimple/resources/language/resource.language.be_by/strings.po Unsupported ioctl: cmd=0xffffffff80046601 (4) 0x80086601 -> FS_IOC_GETFLAGS (8) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackArchiveGenerator.cxx:59 Adding file: pvr.iptvsimple/resources/language/resource.language.bg_bg Unsupported ioctl: cmd=0xffffffff80046601 (4) 0x80086601 -> FS_IOC_GETFLAGS (8) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackArchiveGenerator.cxx:59 Adding file: pvr.iptvsimple/resources/language/resource.language.bg_bg/strings.po Unsupported ioctl: cmd=0xffffffff80046601 (4) 0x80086601 -> FS_IOC_GETFLAGS (8) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackArchiveGenerator.cxx:59 Adding file: pvr.iptvsimple/resources/language/resource.language.bs_ba Unsupported ioctl: cmd=0xffffffff80046601 (4) 0x80086601 -> FS_IOC_GETFLAGS (8) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackArchiveGenerator.cxx:59 Adding file: pvr.iptvsimple/resources/language/resource.language.bs_ba/strings.po Unsupported ioctl: cmd=0xffffffff80046601 (4) 0x80086601 -> FS_IOC_GETFLAGS (8) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackArchiveGenerator.cxx:59 Adding file: pvr.iptvsimple/resources/language/resource.language.ca_es Unsupported ioctl: cmd=0xffffffff80046601 (4) 0x80086601 -> FS_IOC_GETFLAGS (8) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackArchiveGenerator.cxx:59 Adding file: pvr.iptvsimple/resources/language/resource.language.ca_es/strings.po Unsupported ioctl: cmd=0xffffffff80046601 (4) 0x80086601 -> FS_IOC_GETFLAGS (8) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackArchiveGenerator.cxx:59 Adding file: pvr.iptvsimple/resources/language/resource.language.cs_cz Unsupported ioctl: cmd=0xffffffff80046601 (4) 0x80086601 -> FS_IOC_GETFLAGS (8) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackArchiveGenerator.cxx:59 Adding file: pvr.iptvsimple/resources/language/resource.language.cs_cz/strings.po Unsupported ioctl: cmd=0xffffffff80046601 (4) 0x80086601 -> FS_IOC_GETFLAGS (8) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackArchiveGenerator.cxx:59 Adding file: pvr.iptvsimple/resources/language/resource.language.cy_gb Unsupported ioctl: cmd=0xffffffff80046601 (4) 0x80086601 -> FS_IOC_GETFLAGS (8) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackArchiveGenerator.cxx:59 Adding file: pvr.iptvsimple/resources/language/resource.language.cy_gb/strings.po Unsupported ioctl: cmd=0xffffffff80046601 (4) 0x80086601 -> FS_IOC_GETFLAGS (8) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackArchiveGenerator.cxx:59 Adding file: pvr.iptvsimple/resources/language/resource.language.da_dk Unsupported ioctl: cmd=0xffffffff80046601 (4) 0x80086601 -> FS_IOC_GETFLAGS (8) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackArchiveGenerator.cxx:59 Adding file: pvr.iptvsimple/resources/language/resource.language.da_dk/strings.po Unsupported ioctl: cmd=0xffffffff80046601 (4) 0x80086601 -> FS_IOC_GETFLAGS (8) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackArchiveGenerator.cxx:59 Adding file: pvr.iptvsimple/resources/language/resource.language.de_de Unsupported ioctl: cmd=0xffffffff80046601 (4) 0x80086601 -> FS_IOC_GETFLAGS (8) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackArchiveGenerator.cxx:59 Adding file: pvr.iptvsimple/resources/language/resource.language.de_de/strings.po Unsupported ioctl: cmd=0xffffffff80046601 (4) 0x80086601 -> FS_IOC_GETFLAGS (8) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackArchiveGenerator.cxx:59 Adding file: pvr.iptvsimple/resources/language/resource.language.el_gr Unsupported ioctl: cmd=0xffffffff80046601 (4) 0x80086601 -> FS_IOC_GETFLAGS (8) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackArchiveGenerator.cxx:59 Adding file: pvr.iptvsimple/resources/language/resource.language.el_gr/strings.po Unsupported ioctl: cmd=0xffffffff80046601 (4) 0x80086601 -> FS_IOC_GETFLAGS (8) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackArchiveGenerator.cxx:59 Adding file: pvr.iptvsimple/resources/language/resource.language.en_au Unsupported ioctl: cmd=0xffffffff80046601 (4) 0x80086601 -> FS_IOC_GETFLAGS (8) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackArchiveGenerator.cxx:59 Adding file: pvr.iptvsimple/resources/language/resource.language.en_au/strings.po Unsupported ioctl: cmd=0xffffffff80046601 (4) 0x80086601 -> FS_IOC_GETFLAGS (8) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackArchiveGenerator.cxx:59 Adding file: pvr.iptvsimple/resources/language/resource.language.en_gb Unsupported ioctl: cmd=0xffffffff80046601 (4) 0x80086601 -> FS_IOC_GETFLAGS (8) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackArchiveGenerator.cxx:59 Adding file: pvr.iptvsimple/resources/language/resource.language.en_gb/strings.po Unsupported ioctl: cmd=0xffffffff80046601 (4) 0x80086601 -> FS_IOC_GETFLAGS (8) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackArchiveGenerator.cxx:59 Adding file: pvr.iptvsimple/resources/language/resource.language.en_nz Unsupported ioctl: cmd=0xffffffff80046601 (4) 0x80086601 -> FS_IOC_GETFLAGS (8) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackArchiveGenerator.cxx:59 Adding file: pvr.iptvsimple/resources/language/resource.language.en_nz/strings.po Unsupported ioctl: cmd=0xffffffff80046601 (4) 0x80086601 -> FS_IOC_GETFLAGS (8) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackArchiveGenerator.cxx:59 Adding file: pvr.iptvsimple/resources/language/resource.language.en_us Unsupported ioctl: cmd=0xffffffff80046601 (4) 0x80086601 -> FS_IOC_GETFLAGS (8) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackArchiveGenerator.cxx:59 Adding file: pvr.iptvsimple/resources/language/resource.language.en_us/strings.po Unsupported ioctl: cmd=0xffffffff80046601 (4) 0x80086601 -> FS_IOC_GETFLAGS (8) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackArchiveGenerator.cxx:59 Adding file: pvr.iptvsimple/resources/language/resource.language.eo Unsupported ioctl: cmd=0xffffffff80046601 (4) 0x80086601 -> FS_IOC_GETFLAGS (8) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackArchiveGenerator.cxx:59 Adding file: pvr.iptvsimple/resources/language/resource.language.eo/strings.po Unsupported ioctl: cmd=0xffffffff80046601 (4) 0x80086601 -> FS_IOC_GETFLAGS (8) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackArchiveGenerator.cxx:59 Adding file: pvr.iptvsimple/resources/language/resource.language.es_ar Unsupported ioctl: cmd=0xffffffff80046601 (4) 0x80086601 -> FS_IOC_GETFLAGS (8) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackArchiveGenerator.cxx:59 Adding file: pvr.iptvsimple/resources/language/resource.language.es_ar/strings.po Unsupported ioctl: cmd=0xffffffff80046601 (4) 0x80086601 -> FS_IOC_GETFLAGS (8) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackArchiveGenerator.cxx:59 Adding file: pvr.iptvsimple/resources/language/resource.language.es_es Unsupported ioctl: cmd=0xffffffff80046601 (4) 0x80086601 -> FS_IOC_GETFLAGS (8) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackArchiveGenerator.cxx:59 Adding file: pvr.iptvsimple/resources/language/resource.language.es_es/strings.po Unsupported ioctl: cmd=0xffffffff80046601 (4) 0x80086601 -> FS_IOC_GETFLAGS (8) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackArchiveGenerator.cxx:59 Adding file: pvr.iptvsimple/resources/language/resource.language.es_mx Unsupported ioctl: cmd=0xffffffff80046601 (4) 0x80086601 -> FS_IOC_GETFLAGS (8) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackArchiveGenerator.cxx:59 Adding file: pvr.iptvsimple/resources/language/resource.language.es_mx/strings.po Unsupported ioctl: cmd=0xffffffff80046601 (4) 0x80086601 -> FS_IOC_GETFLAGS (8) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackArchiveGenerator.cxx:59 Adding file: pvr.iptvsimple/resources/language/resource.language.et_ee Unsupported ioctl: cmd=0xffffffff80046601 (4) 0x80086601 -> FS_IOC_GETFLAGS (8) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackArchiveGenerator.cxx:59 Adding file: pvr.iptvsimple/resources/language/resource.language.et_ee/strings.po Unsupported ioctl: cmd=0xffffffff80046601 (4) 0x80086601 -> FS_IOC_GETFLAGS (8) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackArchiveGenerator.cxx:59 Adding file: pvr.iptvsimple/resources/language/resource.language.eu_es Unsupported ioctl: cmd=0xffffffff80046601 (4) 0x80086601 -> FS_IOC_GETFLAGS (8) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackArchiveGenerator.cxx:59 Adding file: pvr.iptvsimple/resources/language/resource.language.eu_es/strings.po Unsupported ioctl: cmd=0xffffffff80046601 (4) 0x80086601 -> FS_IOC_GETFLAGS (8) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackArchiveGenerator.cxx:59 Adding file: pvr.iptvsimple/resources/language/resource.language.fa_af Unsupported ioctl: cmd=0xffffffff80046601 (4) 0x80086601 -> FS_IOC_GETFLAGS (8) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackArchiveGenerator.cxx:59 Adding file: pvr.iptvsimple/resources/language/resource.language.fa_af/strings.po Unsupported ioctl: cmd=0xffffffff80046601 (4) 0x80086601 -> FS_IOC_GETFLAGS (8) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackArchiveGenerator.cxx:59 Adding file: pvr.iptvsimple/resources/language/resource.language.fa_ir Unsupported ioctl: cmd=0xffffffff80046601 (4) 0x80086601 -> FS_IOC_GETFLAGS (8) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackArchiveGenerator.cxx:59 Adding file: pvr.iptvsimple/resources/language/resource.language.fa_ir/strings.po Unsupported ioctl: cmd=0xffffffff80046601 (4) 0x80086601 -> FS_IOC_GETFLAGS (8) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackArchiveGenerator.cxx:59 Adding file: pvr.iptvsimple/resources/language/resource.language.fi_fi Unsupported ioctl: cmd=0xffffffff80046601 (4) 0x80086601 -> FS_IOC_GETFLAGS (8) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackArchiveGenerator.cxx:59 Adding file: pvr.iptvsimple/resources/language/resource.language.fi_fi/strings.po Unsupported ioctl: cmd=0xffffffff80046601 (4) 0x80086601 -> FS_IOC_GETFLAGS (8) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackArchiveGenerator.cxx:59 Adding file: pvr.iptvsimple/resources/language/resource.language.fo_fo Unsupported ioctl: cmd=0xffffffff80046601 (4) 0x80086601 -> FS_IOC_GETFLAGS (8) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackArchiveGenerator.cxx:59 Adding file: pvr.iptvsimple/resources/language/resource.language.fo_fo/strings.po Unsupported ioctl: cmd=0xffffffff80046601 (4) 0x80086601 -> FS_IOC_GETFLAGS (8) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackArchiveGenerator.cxx:59 Adding file: pvr.iptvsimple/resources/language/resource.language.fr_ca Unsupported ioctl: cmd=0xffffffff80046601 (4) 0x80086601 -> FS_IOC_GETFLAGS (8) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackArchiveGenerator.cxx:59 Adding file: pvr.iptvsimple/resources/language/resource.language.fr_ca/strings.po Unsupported ioctl: cmd=0xffffffff80046601 (4) 0x80086601 -> FS_IOC_GETFLAGS (8) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackArchiveGenerator.cxx:59 Adding file: pvr.iptvsimple/resources/language/resource.language.fr_fr Unsupported ioctl: cmd=0xffffffff80046601 (4) 0x80086601 -> FS_IOC_GETFLAGS (8) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackArchiveGenerator.cxx:59 Adding file: pvr.iptvsimple/resources/language/resource.language.fr_fr/strings.po Unsupported ioctl: cmd=0xffffffff80046601 (4) 0x80086601 -> FS_IOC_GETFLAGS (8) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackArchiveGenerator.cxx:59 Adding file: pvr.iptvsimple/resources/language/resource.language.gl_es Unsupported ioctl: cmd=0xffffffff80046601 (4) 0x80086601 -> FS_IOC_GETFLAGS (8) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackArchiveGenerator.cxx:59 Adding file: pvr.iptvsimple/resources/language/resource.language.gl_es/strings.po Unsupported ioctl: cmd=0xffffffff80046601 (4) 0x80086601 -> FS_IOC_GETFLAGS (8) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackArchiveGenerator.cxx:59 Adding file: pvr.iptvsimple/resources/language/resource.language.he_il Unsupported ioctl: cmd=0xffffffff80046601 (4) 0x80086601 -> FS_IOC_GETFLAGS (8) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackArchiveGenerator.cxx:59 Adding file: pvr.iptvsimple/resources/language/resource.language.he_il/strings.po Unsupported ioctl: cmd=0xffffffff80046601 (4) 0x80086601 -> FS_IOC_GETFLAGS (8) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackArchiveGenerator.cxx:59 Adding file: pvr.iptvsimple/resources/language/resource.language.hi_in Unsupported ioctl: cmd=0xffffffff80046601 (4) 0x80086601 -> FS_IOC_GETFLAGS (8) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackArchiveGenerator.cxx:59 Adding file: pvr.iptvsimple/resources/language/resource.language.hi_in/strings.po Unsupported ioctl: cmd=0xffffffff80046601 (4) 0x80086601 -> FS_IOC_GETFLAGS (8) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackArchiveGenerator.cxx:59 Adding file: pvr.iptvsimple/resources/language/resource.language.hr_hr Unsupported ioctl: cmd=0xffffffff80046601 (4) 0x80086601 -> FS_IOC_GETFLAGS (8) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackArchiveGenerator.cxx:59 Adding file: pvr.iptvsimple/resources/language/resource.language.hr_hr/strings.po Unsupported ioctl: cmd=0xffffffff80046601 (4) 0x80086601 -> FS_IOC_GETFLAGS (8) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackArchiveGenerator.cxx:59 Adding file: pvr.iptvsimple/resources/language/resource.language.hu_hu Unsupported ioctl: cmd=0xffffffff80046601 (4) 0x80086601 -> FS_IOC_GETFLAGS (8) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackArchiveGenerator.cxx:59 Adding file: pvr.iptvsimple/resources/language/resource.language.hu_hu/strings.po Unsupported ioctl: cmd=0xffffffff80046601 (4) 0x80086601 -> FS_IOC_GETFLAGS (8) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackArchiveGenerator.cxx:59 Adding file: pvr.iptvsimple/resources/language/resource.language.hy_am Unsupported ioctl: cmd=0xffffffff80046601 (4) 0x80086601 -> FS_IOC_GETFLAGS (8) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackArchiveGenerator.cxx:59 Adding file: pvr.iptvsimple/resources/language/resource.language.hy_am/strings.po Unsupported ioctl: cmd=0xffffffff80046601 (4) 0x80086601 -> FS_IOC_GETFLAGS (8) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackArchiveGenerator.cxx:59 Adding file: pvr.iptvsimple/resources/language/resource.language.id_id Unsupported ioctl: cmd=0xffffffff80046601 (4) 0x80086601 -> FS_IOC_GETFLAGS (8) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackArchiveGenerator.cxx:59 Adding file: pvr.iptvsimple/resources/language/resource.language.id_id/strings.po Unsupported ioctl: cmd=0xffffffff80046601 (4) 0x80086601 -> FS_IOC_GETFLAGS (8) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackArchiveGenerator.cxx:59 Adding file: pvr.iptvsimple/resources/language/resource.language.is_is Unsupported ioctl: cmd=0xffffffff80046601 (4) 0x80086601 -> FS_IOC_GETFLAGS (8) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackArchiveGenerator.cxx:59 Adding file: pvr.iptvsimple/resources/language/resource.language.is_is/strings.po Unsupported ioctl: cmd=0xffffffff80046601 (4) 0x80086601 -> FS_IOC_GETFLAGS (8) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackArchiveGenerator.cxx:59 Adding file: pvr.iptvsimple/resources/language/resource.language.it_it Unsupported ioctl: cmd=0xffffffff80046601 (4) 0x80086601 -> FS_IOC_GETFLAGS (8) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackArchiveGenerator.cxx:59 Adding file: pvr.iptvsimple/resources/language/resource.language.it_it/strings.po Unsupported ioctl: cmd=0xffffffff80046601 (4) 0x80086601 -> FS_IOC_GETFLAGS (8) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackArchiveGenerator.cxx:59 Adding file: pvr.iptvsimple/resources/language/resource.language.ja_jp Unsupported ioctl: cmd=0xffffffff80046601 (4) 0x80086601 -> FS_IOC_GETFLAGS (8) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackArchiveGenerator.cxx:59 Adding file: pvr.iptvsimple/resources/language/resource.language.ja_jp/strings.po Unsupported ioctl: cmd=0xffffffff80046601 (4) 0x80086601 -> FS_IOC_GETFLAGS (8) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackArchiveGenerator.cxx:59 Adding file: pvr.iptvsimple/resources/language/resource.language.ko_kr Unsupported ioctl: cmd=0xffffffff80046601 (4) 0x80086601 -> FS_IOC_GETFLAGS (8) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackArchiveGenerator.cxx:59 Adding file: pvr.iptvsimple/resources/language/resource.language.ko_kr/strings.po Unsupported ioctl: cmd=0xffffffff80046601 (4) 0x80086601 -> FS_IOC_GETFLAGS (8) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackArchiveGenerator.cxx:59 Adding file: pvr.iptvsimple/resources/language/resource.language.lt_lt Unsupported ioctl: cmd=0xffffffff80046601 (4) 0x80086601 -> FS_IOC_GETFLAGS (8) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackArchiveGenerator.cxx:59 Adding file: pvr.iptvsimple/resources/language/resource.language.lt_lt/strings.po Unsupported ioctl: cmd=0xffffffff80046601 (4) 0x80086601 -> FS_IOC_GETFLAGS (8) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackArchiveGenerator.cxx:59 Adding file: pvr.iptvsimple/resources/language/resource.language.lv_lv Unsupported ioctl: cmd=0xffffffff80046601 (4) 0x80086601 -> FS_IOC_GETFLAGS (8) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackArchiveGenerator.cxx:59 Adding file: pvr.iptvsimple/resources/language/resource.language.lv_lv/strings.po Unsupported ioctl: cmd=0xffffffff80046601 (4) 0x80086601 -> FS_IOC_GETFLAGS (8) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackArchiveGenerator.cxx:59 Adding file: pvr.iptvsimple/resources/language/resource.language.mi Unsupported ioctl: cmd=0xffffffff80046601 (4) 0x80086601 -> FS_IOC_GETFLAGS (8) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackArchiveGenerator.cxx:59 Adding file: pvr.iptvsimple/resources/language/resource.language.mi/strings.po Unsupported ioctl: cmd=0xffffffff80046601 (4) 0x80086601 -> FS_IOC_GETFLAGS (8) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackArchiveGenerator.cxx:59 Adding file: pvr.iptvsimple/resources/language/resource.language.mk_mk Unsupported ioctl: cmd=0xffffffff80046601 (4) 0x80086601 -> FS_IOC_GETFLAGS (8) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackArchiveGenerator.cxx:59 Adding file: pvr.iptvsimple/resources/language/resource.language.mk_mk/strings.po Unsupported ioctl: cmd=0xffffffff80046601 (4) 0x80086601 -> FS_IOC_GETFLAGS (8) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackArchiveGenerator.cxx:59 Adding file: pvr.iptvsimple/resources/language/resource.language.ml_in Unsupported ioctl: cmd=0xffffffff80046601 (4) 0x80086601 -> FS_IOC_GETFLAGS (8) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackArchiveGenerator.cxx:59 Adding file: pvr.iptvsimple/resources/language/resource.language.ml_in/strings.po Unsupported ioctl: cmd=0xffffffff80046601 (4) 0x80086601 -> FS_IOC_GETFLAGS (8) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackArchiveGenerator.cxx:59 Adding file: pvr.iptvsimple/resources/language/resource.language.mn_mn Unsupported ioctl: cmd=0xffffffff80046601 (4) 0x80086601 -> FS_IOC_GETFLAGS (8) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackArchiveGenerator.cxx:59 Adding file: pvr.iptvsimple/resources/language/resource.language.mn_mn/strings.po Unsupported ioctl: cmd=0xffffffff80046601 (4) 0x80086601 -> FS_IOC_GETFLAGS (8) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackArchiveGenerator.cxx:59 Adding file: pvr.iptvsimple/resources/language/resource.language.ms_my Unsupported ioctl: cmd=0xffffffff80046601 (4) 0x80086601 -> FS_IOC_GETFLAGS (8) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackArchiveGenerator.cxx:59 Adding file: pvr.iptvsimple/resources/language/resource.language.ms_my/strings.po Unsupported ioctl: cmd=0xffffffff80046601 (4) 0x80086601 -> FS_IOC_GETFLAGS (8) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackArchiveGenerator.cxx:59 Adding file: pvr.iptvsimple/resources/language/resource.language.mt_mt Unsupported ioctl: cmd=0xffffffff80046601 (4) 0x80086601 -> FS_IOC_GETFLAGS (8) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackArchiveGenerator.cxx:59 Adding file: pvr.iptvsimple/resources/language/resource.language.mt_mt/strings.po Unsupported ioctl: cmd=0xffffffff80046601 (4) 0x80086601 -> FS_IOC_GETFLAGS (8) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackArchiveGenerator.cxx:59 Adding file: pvr.iptvsimple/resources/language/resource.language.my_mm Unsupported ioctl: cmd=0xffffffff80046601 (4) 0x80086601 -> FS_IOC_GETFLAGS (8) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackArchiveGenerator.cxx:59 Adding file: pvr.iptvsimple/resources/language/resource.language.my_mm/strings.po Unsupported ioctl: cmd=0xffffffff80046601 (4) 0x80086601 -> FS_IOC_GETFLAGS (8) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackArchiveGenerator.cxx:59 Adding file: pvr.iptvsimple/resources/language/resource.language.nb_no Unsupported ioctl: cmd=0xffffffff80046601 (4) 0x80086601 -> FS_IOC_GETFLAGS (8) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackArchiveGenerator.cxx:59 Adding file: pvr.iptvsimple/resources/language/resource.language.nb_no/strings.po Unsupported ioctl: cmd=0xffffffff80046601 (4) 0x80086601 -> FS_IOC_GETFLAGS (8) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackArchiveGenerator.cxx:59 Adding file: pvr.iptvsimple/resources/language/resource.language.nl_nl Unsupported ioctl: cmd=0xffffffff80046601 (4) 0x80086601 -> FS_IOC_GETFLAGS (8) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackArchiveGenerator.cxx:59 Adding file: pvr.iptvsimple/resources/language/resource.language.nl_nl/strings.po Unsupported ioctl: cmd=0xffffffff80046601 (4) 0x80086601 -> FS_IOC_GETFLAGS (8) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackArchiveGenerator.cxx:59 Adding file: pvr.iptvsimple/resources/language/resource.language.pl_pl Unsupported ioctl: cmd=0xffffffff80046601 (4) 0x80086601 -> FS_IOC_GETFLAGS (8) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackArchiveGenerator.cxx:59 Adding file: pvr.iptvsimple/resources/language/resource.language.pl_pl/strings.po Unsupported ioctl: cmd=0xffffffff80046601 (4) 0x80086601 -> FS_IOC_GETFLAGS (8) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackArchiveGenerator.cxx:59 Adding file: pvr.iptvsimple/resources/language/resource.language.pt_br Unsupported ioctl: cmd=0xffffffff80046601 (4) 0x80086601 -> FS_IOC_GETFLAGS (8) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackArchiveGenerator.cxx:59 Adding file: pvr.iptvsimple/resources/language/resource.language.pt_br/strings.po Unsupported ioctl: cmd=0xffffffff80046601 (4) 0x80086601 -> FS_IOC_GETFLAGS (8) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackArchiveGenerator.cxx:59 Adding file: pvr.iptvsimple/resources/language/resource.language.pt_pt Unsupported ioctl: cmd=0xffffffff80046601 (4) 0x80086601 -> FS_IOC_GETFLAGS (8) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackArchiveGenerator.cxx:59 Adding file: pvr.iptvsimple/resources/language/resource.language.pt_pt/strings.po Unsupported ioctl: cmd=0xffffffff80046601 (4) 0x80086601 -> FS_IOC_GETFLAGS (8) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackArchiveGenerator.cxx:59 Adding file: pvr.iptvsimple/resources/language/resource.language.ro_ro Unsupported ioctl: cmd=0xffffffff80046601 (4) 0x80086601 -> FS_IOC_GETFLAGS (8) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackArchiveGenerator.cxx:59 Adding file: pvr.iptvsimple/resources/language/resource.language.ro_ro/strings.po Unsupported ioctl: cmd=0xffffffff80046601 (4) 0x80086601 -> FS_IOC_GETFLAGS (8) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackArchiveGenerator.cxx:59 Adding file: pvr.iptvsimple/resources/language/resource.language.ru_ru Unsupported ioctl: cmd=0xffffffff80046601 (4) 0x80086601 -> FS_IOC_GETFLAGS (8) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackArchiveGenerator.cxx:59 Adding file: pvr.iptvsimple/resources/language/resource.language.ru_ru/strings.po Unsupported ioctl: cmd=0xffffffff80046601 (4) 0x80086601 -> FS_IOC_GETFLAGS (8) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackArchiveGenerator.cxx:59 Adding file: pvr.iptvsimple/resources/language/resource.language.si_lk Unsupported ioctl: cmd=0xffffffff80046601 (4) 0x80086601 -> FS_IOC_GETFLAGS (8) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackArchiveGenerator.cxx:59 Adding file: pvr.iptvsimple/resources/language/resource.language.si_lk/strings.po Unsupported ioctl: cmd=0xffffffff80046601 (4) 0x80086601 -> FS_IOC_GETFLAGS (8) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackArchiveGenerator.cxx:59 Adding file: pvr.iptvsimple/resources/language/resource.language.sk_sk Unsupported ioctl: cmd=0xffffffff80046601 (4) 0x80086601 -> FS_IOC_GETFLAGS (8) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackArchiveGenerator.cxx:59 Adding file: pvr.iptvsimple/resources/language/resource.language.sk_sk/strings.po Unsupported ioctl: cmd=0xffffffff80046601 (4) 0x80086601 -> FS_IOC_GETFLAGS (8) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackArchiveGenerator.cxx:59 Adding file: pvr.iptvsimple/resources/language/resource.language.sl_si Unsupported ioctl: cmd=0xffffffff80046601 (4) 0x80086601 -> FS_IOC_GETFLAGS (8) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackArchiveGenerator.cxx:59 Adding file: pvr.iptvsimple/resources/language/resource.language.sl_si/strings.po Unsupported ioctl: cmd=0xffffffff80046601 (4) 0x80086601 -> FS_IOC_GETFLAGS (8) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackArchiveGenerator.cxx:59 Adding file: pvr.iptvsimple/resources/language/resource.language.sq_al Unsupported ioctl: cmd=0xffffffff80046601 (4) 0x80086601 -> FS_IOC_GETFLAGS (8) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackArchiveGenerator.cxx:59 Adding file: pvr.iptvsimple/resources/language/resource.language.sq_al/strings.po Unsupported ioctl: cmd=0xffffffff80046601 (4) 0x80086601 -> FS_IOC_GETFLAGS (8) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackArchiveGenerator.cxx:59 Adding file: pvr.iptvsimple/resources/language/resource.language.sr_rs Unsupported ioctl: cmd=0xffffffff80046601 (4) 0x80086601 -> FS_IOC_GETFLAGS (8) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackArchiveGenerator.cxx:59 Adding file: pvr.iptvsimple/resources/language/resource.language.sr_rs/strings.po Unsupported ioctl: cmd=0xffffffff80046601 (4) 0x80086601 -> FS_IOC_GETFLAGS (8) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackArchiveGenerator.cxx:59 Adding file: pvr.iptvsimple/resources/language/resource.language.sr_rs at latin Unsupported ioctl: cmd=0xffffffff80046601 (4) 0x80086601 -> FS_IOC_GETFLAGS (8) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackArchiveGenerator.cxx:59 Adding file: pvr.iptvsimple/resources/language/resource.language.sr_rs at latin /strings.po Unsupported ioctl: cmd=0xffffffff80046601 (4) 0x80086601 -> FS_IOC_GETFLAGS (8) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackArchiveGenerator.cxx:59 Adding file: pvr.iptvsimple/resources/language/resource.language.sv_se Unsupported ioctl: cmd=0xffffffff80046601 (4) 0x80086601 -> FS_IOC_GETFLAGS (8) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackArchiveGenerator.cxx:59 Adding file: pvr.iptvsimple/resources/language/resource.language.sv_se/strings.po Unsupported ioctl: cmd=0xffffffff80046601 (4) 0x80086601 -> FS_IOC_GETFLAGS (8) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackArchiveGenerator.cxx:59 Adding file: pvr.iptvsimple/resources/language/resource.language.szl Unsupported ioctl: cmd=0xffffffff80046601 (4) 0x80086601 -> FS_IOC_GETFLAGS (8) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackArchiveGenerator.cxx:59 Adding file: pvr.iptvsimple/resources/language/resource.language.szl/strings.po Unsupported ioctl: cmd=0xffffffff80046601 (4) 0x80086601 -> FS_IOC_GETFLAGS (8) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackArchiveGenerator.cxx:59 Adding file: pvr.iptvsimple/resources/language/resource.language.ta_in Unsupported ioctl: cmd=0xffffffff80046601 (4) 0x80086601 -> FS_IOC_GETFLAGS (8) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackArchiveGenerator.cxx:59 Adding file: pvr.iptvsimple/resources/language/resource.language.ta_in/strings.po Unsupported ioctl: cmd=0xffffffff80046601 (4) 0x80086601 -> FS_IOC_GETFLAGS (8) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackArchiveGenerator.cxx:59 Adding file: pvr.iptvsimple/resources/language/resource.language.te_in Unsupported ioctl: cmd=0xffffffff80046601 (4) 0x80086601 -> FS_IOC_GETFLAGS (8) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackArchiveGenerator.cxx:59 Adding file: pvr.iptvsimple/resources/language/resource.language.te_in/strings.po Unsupported ioctl: cmd=0xffffffff80046601 (4) 0x80086601 -> FS_IOC_GETFLAGS (8) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackArchiveGenerator.cxx:59 Adding file: pvr.iptvsimple/resources/language/resource.language.tg_tj Unsupported ioctl: cmd=0xffffffff80046601 (4) 0x80086601 -> FS_IOC_GETFLAGS (8) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackArchiveGenerator.cxx:59 Adding file: pvr.iptvsimple/resources/language/resource.language.tg_tj/strings.po Unsupported ioctl: cmd=0xffffffff80046601 (4) 0x80086601 -> FS_IOC_GETFLAGS (8) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackArchiveGenerator.cxx:59 Adding file: pvr.iptvsimple/resources/language/resource.language.th_th Unsupported ioctl: cmd=0xffffffff80046601 (4) 0x80086601 -> FS_IOC_GETFLAGS (8) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackArchiveGenerator.cxx:59 Adding file: pvr.iptvsimple/resources/language/resource.language.th_th/strings.po Unsupported ioctl: cmd=0xffffffff80046601 (4) 0x80086601 -> FS_IOC_GETFLAGS (8) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackArchiveGenerator.cxx:59 Adding file: pvr.iptvsimple/resources/language/resource.language.tr_tr Unsupported ioctl: cmd=0xffffffff80046601 (4) 0x80086601 -> FS_IOC_GETFLAGS (8) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackArchiveGenerator.cxx:59 Adding file: pvr.iptvsimple/resources/language/resource.language.tr_tr/strings.po Unsupported ioctl: cmd=0xffffffff80046601 (4) 0x80086601 -> FS_IOC_GETFLAGS (8) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackArchiveGenerator.cxx:59 Adding file: pvr.iptvsimple/resources/language/resource.language.uk_ua Unsupported ioctl: cmd=0xffffffff80046601 (4) 0x80086601 -> FS_IOC_GETFLAGS (8) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackArchiveGenerator.cxx:59 Adding file: pvr.iptvsimple/resources/language/resource.language.uk_ua/strings.po Unsupported ioctl: cmd=0xffffffff80046601 (4) 0x80086601 -> FS_IOC_GETFLAGS (8) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackArchiveGenerator.cxx:59 Adding file: pvr.iptvsimple/resources/language/resource.language.uz_uz Unsupported ioctl: cmd=0xffffffff80046601 (4) 0x80086601 -> FS_IOC_GETFLAGS (8) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackArchiveGenerator.cxx:59 Adding file: pvr.iptvsimple/resources/language/resource.language.uz_uz/strings.po Unsupported ioctl: cmd=0xffffffff80046601 (4) 0x80086601 -> FS_IOC_GETFLAGS (8) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackArchiveGenerator.cxx:59 Adding file: pvr.iptvsimple/resources/language/resource.language.vi_vn Unsupported ioctl: cmd=0xffffffff80046601 (4) 0x80086601 -> FS_IOC_GETFLAGS (8) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackArchiveGenerator.cxx:59 Adding file: pvr.iptvsimple/resources/language/resource.language.vi_vn/strings.po Unsupported ioctl: cmd=0xffffffff80046601 (4) 0x80086601 -> FS_IOC_GETFLAGS (8) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackArchiveGenerator.cxx:59 Adding file: pvr.iptvsimple/resources/language/resource.language.zh_cn Unsupported ioctl: cmd=0xffffffff80046601 (4) 0x80086601 -> FS_IOC_GETFLAGS (8) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackArchiveGenerator.cxx:59 Adding file: pvr.iptvsimple/resources/language/resource.language.zh_cn/strings.po Unsupported ioctl: cmd=0xffffffff80046601 (4) 0x80086601 -> FS_IOC_GETFLAGS (8) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackArchiveGenerator.cxx:59 Adding file: pvr.iptvsimple/resources/language/resource.language.zh_tw Unsupported ioctl: cmd=0xffffffff80046601 (4) 0x80086601 -> FS_IOC_GETFLAGS (8) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackArchiveGenerator.cxx:59 Adding file: pvr.iptvsimple/resources/language/resource.language.zh_tw/strings.po Unsupported ioctl: cmd=0xffffffff80046601 (4) 0x80086601 -> FS_IOC_GETFLAGS (8) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackArchiveGenerator.cxx:59 Adding file: pvr.iptvsimple/resources/settings.xml Unsupported ioctl: cmd=0xffffffff80046601 (4) 0x80086601 -> FS_IOC_GETFLAGS (8) /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:1082 Warning, GetOption return NULL for: CPACK_PACKAGE_CHECKSUM /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:1005 Copy final package(s): /usr/local/src/pvr.iptvsimple/build/_CPack_Packages/Linux/ZIP/addon/addon-pvr.iptvsimple-3.3.1.zip to /usr/local/src/pvr.iptvsimple/build/addon-pvr.iptvsimple-3.3.1.zip CPack: /build/cmake-1PHRnX/cmake-3.7.2/Source/CPack/cmCPackGenerator.cxx:1015 - package: /usr/local/src/pvr.iptvsimple/build/addon-pvr.iptvsimple-3.3.1.zip generated. -------------- next part -------------- An HTML attachment was scrubbed... URL: From guy at alum.mit.edu Wed Oct 11 21:28:13 2017 From: guy at alum.mit.edu (Guy Harris) Date: Wed, 11 Oct 2017 18:28:13 -0700 Subject: [CMake] =?utf-8?q?Cpack_generating_hundreds_of_=22=E2=80=8BUnsupp?= =?utf-8?q?orted_ioctl=3A_cmd=3D0xffffffff80046601_=284=29=3B_0x80086601_-?= =?utf-8?b?PiBGU19JT0NfR0VURkxBR1MgKDgpIiBtZXNzYWdlcz8=?= In-Reply-To: References: Message-ID: On Oct 11, 2017, at 4:37 PM, pgndev wrote: > Unsupported ioctl: cmd=0xffffffff80046601 (4) > 0x80086601 -> FS_IOC_GETFLAGS (8) > Unsupported ioctl: cmd=0xffffffff80046601 (4) > 0x80086601 -> FS_IOC_GETFLAGS (8) > ... ( 300 + repetitions ) ... > 0x80086601 -> FS_IOC_GETFLAGS (8) > Unsupported ioctl: cmd=0xffffffff80046601 (4) > 0x80086601 -> FS_IOC_GETFLAGS (8) > CPack: - package: /usr/local/src/pvr.iptvsimple/build/addon-pvr.iptvsimple-3.3.1.zip generated. ... > running in a Raspbian9 chroot. ...under QEMU's ARM emulator, on some other box, right? That's a QEMU error message, it appears. QEMU 2.9.1 *looks* as if it supports FS_IOC_GETFLAGS, so maybe you need a newer version of QEMU on which to run Raspbian8. What's happening is probably that whatever program is building the zip file is making FS_IOC_GETFLAGS ioctls to get additional file flags for the files it's putting into the zipball. That program probably has no problem with FS_IOC_GETFLAGS being unsupported, as it's not supported by all file systems on Linux, so it *has* to be able to handle not being able to get those additional file flags. > What's causing these messages? Probably an older version of QEMU that doesn't support FS_IOC_GETFLAGS. > Some missing dependency? Yes, you depend on having a newer version of QEMU. :-) > Is there a fix/workaround? Get a newer version of QEMU? From pgnet.dev at gmail.com Wed Oct 11 21:39:54 2017 From: pgnet.dev at gmail.com (pgndev) Date: Wed, 11 Oct 2017 18:39:54 -0700 Subject: [CMake] =?utf-8?q?Cpack_generating_hundreds_of_=22=E2=80=8BUnsupp?= =?utf-8?q?orted_ioctl=3A_cmd=3D0xffffffff80046601_=284=29=3B_0x800?= =?utf-8?b?ODY2MDEgLT4gRlNfSU9DX0dFVEZMQUdTICg4KSIgbWVzc2FnZXM/?= In-Reply-To: References: Message-ID: On 10/11/17 6:28 PM, Guy Harris wrote:> On Oct 11, 2017, at 4:37 PM, pgndev wrote: > >> Unsupported ioctl: cmd=0xffffffff80046601 (4) >> 0x80086601 -> FS_IOC_GETFLAGS (8) >> Unsupported ioctl: cmd=0xffffffff80046601 (4) >> 0x80086601 -> FS_IOC_GETFLAGS (8) >> ... ( 300 + repetitions ) ... >> 0x80086601 -> FS_IOC_GETFLAGS (8) >> Unsupported ioctl: cmd=0xffffffff80046601 (4) >> 0x80086601 -> FS_IOC_GETFLAGS (8) >> CPack: - package: /usr/local/src/pvr.iptvsimple/build/addon-pvr.iptvsimple-3.3.1.zip generated. > > ... > >> running in a Raspbian9 chroot. > > ...under QEMU's ARM emulator, on some other box, right? Yep. chroot launched as QEMU_CPU=cortex-a15 LC_ALL=C /usr/sbin/qemu-binfmt-conf.sh chroot ${CHROOT} /bin/bash ps ax | grep qemu | grep pts 15193 pts/1 Sl+ 0:09 /usr/bin/qemu-arm -0 /bin/bash /bin/bash on lsb_release -rd Description: openSUSE Leap 42.3 Release: 42.3 uname -m x86_64 uname -rm 4.13.5-4.g7034d64-default x86_64 where rpm -q --whatprovides /usr/bin/qemu-arm qemu-linux-user-2.10.1-407.2.x86_64 > That's a QEMU error message, it appears. QEMU 2.9.1 *looks* as if it supports FS_IOC_GETFLAGS, so maybe you need a newer version of QEMU on which to run Raspbian8. As per above, I *do* have a newer version ... 2.10.1 > What's happening is probably that whatever program is building the zip file is making FS_IOC_GETFLAGS ioctls to get additional file flags for the files it's putting into the zipball. That program probably has no problem with FS_IOC_GETFLAGS being unsupported, as it's not supported by all file systems on Linux, so it *has* to be able to handle not being able to get those additional file flags. > >> What's causing these messages? > > Probably an older version of QEMU that doesn't support FS_IOC_GETFLAGS. > >> Some missing dependency? > > Yes, you depend on having a newer version of QEMU. :-) > >> Is there a fix/workaround? > > Get a newer version of QEMU? Considering that 2.10.1 is, per https://www.qemu.org/, the latest release as of Oct 2nd 2017, options for newer are a bit thin atm ... -------------- next part -------------- An HTML attachment was scrubbed... URL: From guy at alum.mit.edu Wed Oct 11 21:56:04 2017 From: guy at alum.mit.edu (Guy Harris) Date: Wed, 11 Oct 2017 18:56:04 -0700 Subject: [CMake] =?utf-8?q?Cpack_generating_hundreds_of_=22=E2=80=8BUnsupp?= =?utf-8?q?orted_ioctl=3A_cmd=3D0xffffffff80046601_=284=29=3B_0x80086601_-?= =?utf-8?b?PiBGU19JT0NfR0VURkxBR1MgKDgpIiBtZXNzYWdlcz8=?= In-Reply-To: References: Message-ID: <5377BFBE-9169-4AF9-BA3B-68EA7D12ABAA@alum.mit.edu> On Oct 11, 2017, at 6:39 PM, pgndev wrote: > As per above, I *do* have a newer version ... 2.10.1 Then file a bug with the QEMU developers, saying the support for FS_IOC_GETFLAGS isn't working in your configuration. From robert.maynard at kitware.com Thu Oct 12 12:14:40 2017 From: robert.maynard at kitware.com (Robert Maynard) Date: Thu, 12 Oct 2017 12:14:40 -0400 Subject: [CMake] [ANNOUNCE] CMake 3.10.0-rc2 is now ready for testing Message-ID: I am proud to announce the second CMake 3.10 release candidate. https://cmake.org/download/ Documentation is available at: https://cmake.org/cmake/help/v3.10 Release notes appear below and are also published at https://cmake.org/cmake/help/v3.10/release/3.10.html Some of the more significant changes in CMake 3.10 are: * The flang Fortran compiler is now supported, with compiler id "Flang". * Support for the MSVC ARM64 architecture was added. Visual Studio 2017 Update 4 and above offer an ARM64 toolchain. * The "include_guard()" command was introduced to allow guarding CMake scripts from being included more than once. The command supports "DIRECTORY" and "GLOBAL" options to adjust the corresponding include guard scope. If no options given, include guard is similar to basic variable-based check. * "FindMPI" received a major overhaul. It now features language specific components, better Fortran support, and support for statically linked MPI implementations. * A "FindOpenACC" module was added to detect compiler support for OpenACC. Currently only supports PGI, GNU and Cray compilers. * The "FindOpenGL" module underwent numerous improvements. It has gained support for GLVND and EGL on Linux. It now has import targets that separate the OpenGL library and OpenGL contexts. * The "GoogleTest" module gained a new command "gtest_discover_tests()" implementing dynamic (build-time) test discovery. * When using "AUTOMOC" or "AUTOUIC", source files that are "GENERATED" will be processed as well. They were ignored by "AUTOMOC" and "AUTOUIC" in earlier releases. See policy "CMP0071". * A "CTEST_LABELS_FOR_SUBPROJECTS" CTest module variable and CTest script variable were added to specify a list of labels that should be treated as subprojects by CDash. To use this value in both the CTest module and the ctest command line Dashboard Client mode (e.g. "ctest -S") set it in the "CTestConfig.cmake" config file. * CPack gained a "FREEBSD" generator for FreeBSD "pkg(8)", configured by the "CPackFreeBSD" module. * The CPack "DEB" generator, configured by the "CPackDeb" module, was enabled on Windows. While not fully featured (due to the lack of external UNIX tools) this will allow building basic cross- platform Debian packages. * The "cmake(1)" "-E" mode gained support for "sha1sum", "sha224sum", "sha256sum", "sha384sum", and "sha512sum". * The "file(GENERATE)" command now interprets relative paths given to its "OUTPUT" and "INPUT" arguments with respect to the caller's current binary and source directories, respectively. See policy "CMP0070". CMake 3.10 Release Notes ************************ Changes made since CMake 3.9 include the following. New Features ============ Platforms --------- * The flang Fortran compiler is now supported, with compiler id "Flang". * A new minimal platform file for "Midipix" was added. * Support for the MSVC ARM64 architecture was added. Visual Studio 2017 Update 4 and above offer an ARM64 toolchain. * Support for the IAR ARM Compiler was improved. Generators ---------- * The Makefile Generators and the "Ninja" generator learned to add compiler launcher tools like ccache along with the compiler for the "CUDA" language ("C" and "CXX" were supported previously). See the "CMAKE__COMPILER_LAUNCHER" variable and "_COMPILER_LAUNCHER" target property for details. * The "CodeBlocks" extra generator learned to optionally exclude files from outside the project root directory from the generated project. See the "CMAKE_CODEBLOCKS_EXCLUDE_EXTERNAL_FILES" variable. Commands -------- * The "cmake_host_system_information()" command learned more keys to get information about the processor capabilities and the host OS version. * The "configure_file()" command learned to support indented "# cmakedefine" and "# cmakedefine01". Spaces and/or tabs between the "#" character and the "cmakedefine"/"cmakedefine01" words are now understood and preserved in the output. * The "execute_process()" command gained a "RESULTS_VARIABLE" option to collect a list of results from all children in a pipeline of processes when multiple "COMMAND" arguments are given. * The "include_guard()" command was introduced to allow guarding CMake scripts from being included more than once. The command supports "DIRECTORY" and "GLOBAL" options to adjust the corresponding include guard scope. If no options given, include guard is similar to basic variable-based check. * The "string()" command learned a new "PREPEND" subcommand. * The "string(TIMESTAMP)" command now supports "%A" for full weekday name and "%B" for full month name. Variables --------- * A "CMAKE_DIRECTORY_LABELS" variable was added to specify labels for all tests in a directory. Properties ---------- * A "_CPPCHECK" target property and supporting "CMAKE__CPPCHECK" variable were introduced to tell the Makefile Generators and the "Ninja" generator to run "cppcheck" with the compiler for "C" and "CXX" languages. * A "LABELS" directory property was added to specify labels for all targets and tests in a directory. * A "TEST_INCLUDE_FILES" directory property was added to list any number of files to be included when running tests with "ctest(1)". This generalizes the "TEST_INCLUDE_FILE" property. * The "VS_DOTNET_REFERENCEPROP__TAG_" target property was added to support custom XML tags for reference assemblies in C# targets. * Source file properties "VS_SHADER_OUTPUT_HEADER_FILE" and "VS_SHADER_VARIABLE_NAME" have been added to specify more details of ".hlsl" sources with Visual Studio Generators. Modules ------- * The "FindCurses" module gained a "CURSES_NEED_WIDE" option to request the wide-character variant. * The "FindEXPAT" module now provides imported targets. * The "FindFreetype" module now provides imported targets. * "FindMPI" gained a number of new features, including: * Language-specific components have been added to the module. * Many more MPI environments are now supported. * The environmental support for Fortran has been improved. * A user now has fine-grained control over the MPI selection process, including passing custom parameters to the MPI compiler. * The version of the implemented MPI standard is now being exposed. * MPI-2 C++ bindings can now be detected and also suppressed if so desired. * The available Fortran bindings are now being detected and verified. * Various MPI-3 information can be requested, including the library version and Fortran capabilities of the individual bindings. * Statically linked MPI implementations are supported. * A "FindOpenACC" module was added to detect compiler support for OpenACC. Currently only supports PGI, GNU and Cray compilers. * The "FindOpenGL" module gained support for GLVND on Linux. * The "FindOpenMP" module gained support for language-specific components. * A "FindPatch" module was added to find the "patch" command-line executable. * The "FindProtobuf" module "protobuf_generate_cpp()" command gained a "DESCRIPTORS" option to generate descriptor files. * The "GoogleTest" module gained a new command "gtest_discover_tests()" implementing dynamic (build-time) test discovery. Unlike the source parsing approach, dynamic discovery executes the test (in 'list available tests' mode) at build time to discover tests. This is robust against unusual ways of labeling tests, provides much better support for advanced features such as parameterized tests, and does not require re-running CMake to discover added or removed tests within a test executable. * The "InstallRequiredSystemLibraries" module gained support for installing Intel compiler runtimes. Autogen ------- * When using "AUTOMOC" or "AUTOUIC" with a multi configuration generator (e.g. "Xcode"), included "*.moc", "moc_*.cpp" and "ui_*.h" files are generated in "/include_" instead of "/include". * When using "AUTOMOC" or "AUTOUIC", source files that are "GENERATED" will be processed as well. They were ignored by "AUTOMOC" and "AUTOUIC" in earlier releases. See policy "CMP0071". * When using "AUTOMOC", CMake searches for the strings "Q_OBJECT", "Q_GADGET" or "Q_NAMESPACE" in a source file to determine if it needs to be "moc" processed. The new "CMAKE_AUTOMOC_MACRO_NAMES" variable and "AUTOMOC_MACRO_NAMES" target property may be set to register additional strings (macro names) to search for. * When using "AUTOMOC", the new "CMAKE_AUTOMOC_COMPILER_PREDEFINES" variable and "AUTOMOC_COMPILER_PREDEFINES" target property specify whether to enable or disable the generation of the compiler pre definitions file "moc_predefs.h". CTest ----- * A "CTEST_LABELS_FOR_SUBPROJECTS" CTest module variable and CTest script variable were added to specify a list of labels that should be treated as subprojects by CDash. To use this value in both the CTest module and the ctest command line Dashboard Client mode (e.g. "ctest -S") set it in the "CTestConfig.cmake" config file. CPack ----- * CPack gained a "FREEBSD" generator for FreeBSD "pkg(8)", configured by the "CPackFreeBSD" module. * The CPack "DEB" generator, configured by the "CPackDeb" module, was enabled on Windows. While not fully featured (due to the lack of external UNIX tools) this will allow building basic cross- platform Debian packages. * The "CPackDeb" module learned to set package release version in "Version" info property. See the "CPACK_DEBIAN_PACKAGE_RELEASE" variable. * The "CPackDeb" module learned more strict package version checking that complies with Debian rules. * The "CPackIFW" module "cpack_ifw_configure_component()" and "cpack_ifw_configure_component_group()" commands gained a new "REPLACES" and "CHECKABLE" options. * The "CPackIFW" module gained new "CPACK_IFW_PACKAGE_FILE_EXTENSION" variable to customize target binary format. * The "CPackIFW" module gained new "CPACK_IFW_REPOSITORIES_DIRECTORIES" variable to specify additional repositories dirs that will be used to resolve and repack dependent components. This feature is only available when using QtIFW 3.1 or later. * Modules "CPackRPM" and "CPackDeb" learned to set package epoch version. See "CPACK_RPM_PACKAGE_EPOCH" and "CPACK_DEBIAN_PACKAGE_EPOCH" variables. Other ----- * The "cmake(1)" "-E" mode gained support for "sha1sum", "sha224sum", "sha256sum", "sha384sum", and "sha512sum". * The graphviz output now distinguishes among the different dependency types "PUBLIC", "PRIVATE" and "INTERFACE" and represents them in the output graph as solid, dashed and dotted edges. Deprecated and Removed Features =============================== * Support for building CMake itself with C++98 compilers was dropped. CMake is now implemented using C++11. * Support for building CMake on HP-UX has been dropped pending better support for C++11 and a port of libuv. See CMake Issue 17137. Use CMake 3.9 or lower instead for HP-UX support. Other Changes ============= * On FreeBSD the C++ compiler named "c++" is now the preferred default. * The "file(GENERATE)" command now interprets relative paths given to its "OUTPUT" and "INPUT" arguments with respect to the caller's current binary and source directories, respectively. See policy "CMP0070". * The "get_filename_component()" "PROGRAM" mode semantics have been revised to not tolerate unquoted spaces in the path to the program while also accepting arguments. While technically incompatible with the old behavior, it is expected that behavior under typical use cases with properly-quoted command-lines has not changed. ---------------------------------------------------------------------------- Changes made since CMake 3.9.0-rc1: Andr? Apitzsch (1): FindProtobuf: fix documentation typo Brad King (10): Help: Revise 3.10 release notes FindJava: Revise version parsing to support Java 9 curl: Update script to get curl 7.56.0 curl: Update build within CMake to account for 7.56 changes Help: Minor text clarifications in cmake-language(7) manual Clang: Diagnose unsupported GNU-like clang targeting MSVC ABI ExternalProject: Avoid if() auto-dereferene in quoted arguments FindXMLRPC: Drop unnecessary exec_program code paths FindXMLRPC: Tolerate no include directories CMake 3.10.0-rc2 Christian Pfeiffer (1): FindOpenMP: Fix link flags being used for compile Craig Scott (2): Help: Fix Example appearing in target property list of contents Help: Fix wrong property reference for an app bundle's Info.plist Curl Upstream (1): curl 2017-10-04 (3ea76790) Domen Vrankar (2): CPack/Deb: CPACK_DEBIAN_PACKAGE_VERSION regex testing exception CPack/Deb: fix for regex passing even if invalid characters are present Gregor Jasny (2): Revert "Xcode: Adjust tests to drop of 32bit iOS architectures" Xcode 9: Lower iOS deployment version to get armv7 builds Matthias Maennich (4): cmcmd: let operator<< for NumberFormatter reset the stream's format flags cmGeneratorTarget: remove dead code cmProcessTools: fix minor issue introduced by 595feb3 cmInstallCommandArguments: do not access static members through `this` Robert Maynard (1): FindCUDA: Update for CUDA 9 breakup of nppi into multiple libraries Sebastian Holtermann (3): Autogen: Allow setting SKIP_AUTOUIC/GEN on .ui files not in the sources Autogen: Docs: Add examples for AUTORCC_OPTIONS and AUTOUIC_OPTIONS Autogen: Docs: Extend SKIP_AUTOUIC documentation Thomas Stenersen (1): IPO: Fix support for spaces in path to archive tools From greenc at fnal.gov Thu Oct 12 19:21:17 2017 From: greenc at fnal.gov (Chris Green) Date: Thu, 12 Oct 2017 18:21:17 -0500 Subject: [CMake] Help: erroneous '-ltbb' getting injected into link command implicitly Message-ID: Hi, Using CMake 3.9.2, I'm trying to ascertain where an instance of '-ltbb' is getting injected into the link command line of some of our executables. This is bad because we can't find it anywhere in our source (we have a config CMake that uses the full path to the library), and the system TBB library is being picked up which is wrong (old version compiled with wrong compiler to wrong C++ standard). I have verified that we have no explicit use of '-ltbb' anywhere, and also that LIBRARY_PATH is not being set in the environment. Two questions arise: 1. How can I trace what is going into the link.txt files, and whence? 2. Are there any remaining mechanisms for explicit conversion from X/Y/Z/libQ.so to -lQ that I'm unaware of? It should be noted as a matter of form that the link.txt contains a *whole* lot of stuff that wasn't explicitly put there by the target_link_libraries() command, and that turns out to be superfluous. Any help in this matter would be gratefully received, because too much of this is currently a black box to me and I'm lost. Thanks, Chris. -------------- next part -------------- An HTML attachment was scrubbed... URL: From julius.caro at gmail.com Fri Oct 13 04:06:17 2017 From: julius.caro at gmail.com (Luis Caro Campos) Date: Fri, 13 Oct 2017 09:06:17 +0100 Subject: [CMake] Help: erroneous '-ltbb' getting injected into link command implicitly In-Reply-To: References: Message-ID: Hi Chris, Are you, by any chance, using (via find_package), another library that may have been built with tbb support? I've had the exact same problem you describe with OpenCV, when my own targets link against the opencv ones. Regards, Luis On 13 Oct 2017 01:21, "Chris Green" wrote: > Hi, > > Using CMake 3.9.2, I'm trying to ascertain where an instance of '-ltbb' is > getting injected into the link command line of some of our executables. > This is bad because we can't find it anywhere in our source (we have a > config CMake that uses the full path to the library), and the system TBB > library is being picked up which is wrong (old version compiled with wrong > compiler to wrong C++ standard). I have verified that we have no explicit > use of '-ltbb' anywhere, and also that LIBRARY_PATH is not being set in the > environment. Two questions arise: > > 1. How can I trace what is going into the link.txt files, and whence? > 2. Are there any remaining mechanisms for explicit conversion from > X/Y/Z/libQ.so to -lQ that I'm unaware of? > > It should be noted as a matter of form that the link.txt contains a > *whole* lot of stuff that wasn't explicitly put there by the > target_link_libraries() command, and that turns out to be superfluous. > > Any help in this matter would be gratefully received, because too much of > this is currently a black box to me and I'm lost. > > Thanks, > > Chris. > > -- > > 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 greenc at fnal.gov Fri Oct 13 09:22:00 2017 From: greenc at fnal.gov (Chris Green) Date: Fri, 13 Oct 2017 08:22:00 -0500 Subject: [CMake] Help: erroneous '-ltbb' getting injected into link command implicitly In-Reply-To: References: Message-ID: <320a0636-f486-a84e-cfbe-9baa3843568f@fnal.gov> On 10/13/17 3:06 AM, Luis Caro Campos wrote: > Hi Chris, > > Are you, by any chance, using (via find_package), another library that > may have been built with tbb support? We using libraries from another package that depends on them, but I didn't think we were using CMake mechanisms to find them. Regardless, I've no idea how to fix it when I do find it. I thought making sure LIBRARY_PATH wasn't set would do the trick, but apparently not. > I've had the exact same problem you describe with OpenCV, when my own > targets link against the opencv ones. If you're able to let me know how you solved the problem and stopped CMake doing the translation, I'd be grateful. Thanks, Chris. > Regards, > Luis > > On 13 Oct 2017 01:21, "Chris Green" > wrote: > > Hi, > > Using CMake 3.9.2, I'm trying to ascertain where an instance of > '-ltbb' is getting injected into the link command line of some of > our executables. This is bad because we can't find it anywhere in > our source (we have a config CMake that uses the full path to the > library), and the system TBB library is being picked up which is > wrong (old version compiled with wrong compiler to wrong C++ > standard). I have verified that we have no explicit use of '-ltbb' > anywhere, and also that LIBRARY_PATH is not being set in the > environment. Two questions arise: > > 1. How can I trace what is going into the link.txt files, and whence? > 2. Are there any remaining mechanisms for explicit conversion > from X/Y/Z/libQ.so to -lQ that I'm unaware of? > > It should be noted as a matter of form that the link.txt contains > a *whole* lot of stuff that wasn't explicitly put there by the > target_link_libraries() command, and that turns out to be superfluous. > > Any help in this matter would be gratefully received, because too > much of this is currently a black box to me and I'm lost. > > Thanks, > > Chris. > > > -- > > 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 julius.caro at gmail.com Fri Oct 13 10:02:29 2017 From: julius.caro at gmail.com (Luis Caro Campos) Date: Fri, 13 Oct 2017 15:02:29 +0100 Subject: [CMake] Help: erroneous '-ltbb' getting injected into link command implicitly In-Reply-To: References: <320a0636-f486-a84e-cfbe-9baa3843568f@fnal.gov> Message-ID: Hi, In my case, I don't think I was ever able to "remove" the "-ltbb" from the linker statement. However, by doing a target_link_libraries against the actually file with the pull path, that seemed to do the job and the linker picked that one instead of the system one. Please note that in my case, I made sure tbb was not installed by the system packager manager, so "-ltbb" caused a linker error as it couldn't find what it needed. I would try one of these 3 things: target_link_libraries(Mytarget "/path/to/libtbb.so") #full path link_directories("/path/to/tbblib") #somewhere in the source tree that affects your target The third alternative would be to use rpath-link linker argument, and pass the path to tbb. This would work if the implicit dependency is because of a dependency expressed in another library you link against. In the build tree, "ldd" tool on Linux should help you determine whether your tbb or the system one is picked. On the install tree, depends on the rpath ! Regards, Luis On 13 Oct 2017 15:22, "Chris Green" wrote: On 10/13/17 3:06 AM, Luis Caro Campos wrote: Hi Chris, Are you, by any chance, using (via find_package), another library that may have been built with tbb support? We using libraries from another package that depends on them, but I didn't think we were using CMake mechanisms to find them. Regardless, I've no idea how to fix it when I do find it. I thought making sure LIBRARY_PATH wasn't set would do the trick, but apparently not. I've had the exact same problem you describe with OpenCV, when my own targets link against the opencv ones. If you're able to let me know how you solved the problem and stopped CMake doing the translation, I'd be grateful. Thanks, Chris. Regards, Luis On 13 Oct 2017 01:21, "Chris Green" wrote: > Hi, > > Using CMake 3.9.2, I'm trying to ascertain where an instance of '-ltbb' is > getting injected into the link command line of some of our executables. > This is bad because we can't find it anywhere in our source (we have a > config CMake that uses the full path to the library), and the system TBB > library is being picked up which is wrong (old version compiled with wrong > compiler to wrong C++ standard). I have verified that we have no explicit > use of '-ltbb' anywhere, and also that LIBRARY_PATH is not being set in the > environment. Two questions arise: > > 1. How can I trace what is going into the link.txt files, and whence? > 2. Are there any remaining mechanisms for explicit conversion from > X/Y/Z/libQ.so to -lQ that I'm unaware of? > > It should be noted as a matter of form that the link.txt contains a > *whole* lot of stuff that wasn't explicitly put there by the > target_link_libraries() command, and that turns out to be superfluous. > > Any help in this matter would be gratefully received, because too much of > this is currently a black box to me and I'm lost. > > Thanks, > > Chris. > > -- > > 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 bmorgan.warwick at gmail.com Mon Oct 16 05:55:26 2017 From: bmorgan.warwick at gmail.com (Ben Morgan) Date: Mon, 16 Oct 2017 10:55:26 +0100 Subject: [CMake] Help: erroneous '-ltbb' getting injected into link command implicitly In-Reply-To: References: Message-ID: Hi Chris, Is ?tbb? used as a target name and direct link anywhere? e.g. add_library(tbb IMPORTED ?) then somewhere else target_link_libraries(foo PUBLIC tbb) (you mentioned use of a config Cmake file)? One thing that bit me a while ago (but I don?t think it?s a CMake bug per se) is that if the target name doesn?t exist (e.g. package wasn?t found), then ?-l? is used. If that is the case, then the solution is to namespace the target: add_library(tbb::tbb IMPORTED ?) ? target_link_libraries(foo PUBLIC tbb::tbb) That ensures full paths are used and that a diagnostic is emitted if the package/target wasn?t found. Cheers, Ben. > On 13 Oct 2017, at 00:21, Chris Green wrote: > > Hi, > > Using CMake 3.9.2, I'm trying to ascertain where an instance of '-ltbb' is getting injected into the link command line of some of our executables. This is bad because we can't find it anywhere in our source (we have a config CMake that uses the full path to the library), and the system TBB library is being picked up which is wrong (old version compiled with wrong compiler to wrong C++ standard). I have verified that we have no explicit use of '-ltbb' anywhere, and also that LIBRARY_PATH is not being set in the environment. Two questions arise: > > How can I trace what is going into the link.txt files, and whence? > Are there any remaining mechanisms for explicit conversion from X/Y/Z/libQ.so to -lQ that I'm unaware of? > It should be noted as a matter of form that the link.txt contains a *whole* lot of stuff that wasn't explicitly put there by the target_link_libraries() command, and that turns out to be superfluous. > > Any help in this matter would be gratefully received, because too much of this is currently a black box to me and I'm lost. > > Thanks, > > Chris. > -- > > 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 greenc at fnal.gov Mon Oct 16 09:54:24 2017 From: greenc at fnal.gov (Chris Green) Date: Mon, 16 Oct 2017 08:54:24 -0500 Subject: [CMake] Help: erroneous '-ltbb' getting injected into link command implicitly In-Reply-To: References: Message-ID: <34e7be93-de57-c6be-462d-90857c0a477e@fnal.gov> On 10/16/17 4:55 AM, Ben Morgan wrote: > Hi Chris, > > Is ?tbb? used as a target name and direct link anywhere? e.g. Ding ding! Found it late Friday, thanks: I was fooled by previous experience into thinking that CMake was translating an external package's dependency on TBB from the explicit full path to the library into a -ltbb, but it turned out to be a mistake in one of our own CMakeLists.txt files listing "tbb" instead of the expected "${TBB}." Thanks to everyone who weighed in. Best, Chris. From preed at releng-approaches.com Mon Oct 16 17:45:04 2017 From: preed at releng-approaches.com (J. Paul Reed) Date: Mon, 16 Oct 2017 14:45:04 -0700 Subject: [CMake] Creating two distinct packages w/ CPack from a single project Message-ID: <20171016214504.GA17257@release-approaches.com> Hey all, I have a (potentially?) odd situation: I need to generate multiple packages using CPack from the same CMake project. I'm aware of the component-based installers and methodology, but I don't believe that's what I want here: I want entirely different package names/versions/etc., containing different artifacts created from a single CMake project. I have currently implemented this by setting the various CPack configuration variables, and then include()ing CPack in different directories. I then have custom targets that call cpack with --config, pointed to a non-default-named CPack configuration file. This seems to work just fine, except during the cmake configuration run, we get warnings about CPack.cmake having already been included. I see where this message() gets emitted (https://gitlab.kitware.com/cmake/cmake/blob/master/Modules/CPack.cmake#L298-302); perusing that file, it seems to do things I basically want/need (setting various defaults, etc.) if I want to use cpack with a different config file. I can suppress the warning by unsetting CPack_CMake_INCLUDED, which is what I'm planning to do... but I wanted to ask: a) whether there are any technical problems or concerns by subverting that warning message and including CPack.cmake multiple times, and b) if there's another solution entirely that is better suited. (Again, I'm aware of component based installs; I don't think they'll do what I want here.) thanks, preed -- J. Paul Reed From motto at transip.nl Tue Oct 17 04:53:17 2017 From: motto at transip.nl (Martijn Otto) Date: Tue, 17 Oct 2017 10:53:17 +0200 Subject: [CMake] check_cxx_symbol_exists for std::literals works in one project, not in another Message-ID: <1508230397.5886.9.camel@transip.nl> Hi, I'm struggling to understand the following behaviour. I need to test whether std::literals is available in my project, for which I have the following test: SET(CMAKE_REQUIRED_FLAGS "-std=c++14") check_cxx_symbol_exists("std::literals::string_literals::operator\"\"s( const char*, std::size_t)" "string" HAVE_STD_LITERALS) I then use the resulting HAVE_STD_LITERALS to configure an include file. In one project this works well, in another it does not. The project where it does work generates the following test file: #include int main() { #ifndef std::literals::string_literals::operator""s ? const char* arg0; ? std::size_t arg1; ? (void)std::literals::string_literals::operator""s(arg0, arg1); #endif ? return 0; } This compiles with only a warning about extra tokens after the #ifndef directive. In another project I try to use the same and it never detects support, because it generates different test-code, that doesn't compile at all: /* */ #include int main(int argc, char** argv) { ? (void)argv; #ifndef std::literals::string_literals::operator""s(const char*, std::size_t) ? return ((int*)(&std::literals::string_literals::operator""s(const char*, std::size_t)))[argc]; #else ? (void)argc; ? return 0; #endif } Can anybody explain why different code is generated and how I can avoid generating this incorrect code? With regards, Martijn Otto From Robert.Bielik at dirac.com Tue Oct 17 05:12:20 2017 From: Robert.Bielik at dirac.com (Robert Bielik) Date: Tue, 17 Oct 2017 09:12:20 +0000 Subject: [CMake] Protobuf on iOS Message-ID: <0c300f472a2e418380eac3659397243b@hosted3-mb02.itm.host> Hi all, CMake version: 3.9.4 Trying to build protobuf on iOS via the toolchains @ https://github.com/ruslo/polly (ios-10-2.cmake). With some additional tricks in my wrapper CMakeLists file: if (IOS) set(CMAKE_MACOSX_BUNDLE OFF) find_package(Threads REQUIRED) endif () add_subdirectory(protobuf/cmake) it works fine up til the point where protoc is compiled. CMake files are generated like so: cmake -GXcode -DCMAKE_TOOLCHAIN_FILE=$TOOLCHAINS/polly/ios-10-2.cmake The error produced is: target specifies product type 'com.apple.product-type.tool', but there's no such product type for the 'iphoneos' platform Granted, I won't really need the protoc target during cross building, but I'd rather stay clear of the CMake files of protobuf. Ideas ? TIA /Robert From craig.scott at crascit.com Tue Oct 17 05:59:38 2017 From: craig.scott at crascit.com (Craig Scott) Date: Tue, 17 Oct 2017 20:59:38 +1100 Subject: [CMake] Protobuf on iOS In-Reply-To: <0c300f472a2e418380eac3659397243b@hosted3-mb02.itm.host> References: <0c300f472a2e418380eac3659397243b@hosted3-mb02.itm.host> Message-ID: As a starting point, you can try this as your toolchain file rather than the one from polly if you want to pare things down to help investigate what's going on: set(CMAKE_MACOSX_BUNDLE YES) set(CMAKE_XCODE_ATTRIBUTE_CODE_SIGNING_REQUIRED NO) set(CMAKE_OSX_SYSROOT iphoneos) This should be the minimal required toolchain with a reasonably recent Xcode. Note that this doesn't set any search paths for the various find_...() commands, if that matters to you, but it should get you past the try_compile() stage in the first project() command (which I think is where you're getting your error message from). It will also allow you to switch between device and simulator builds at build time (Xcode handles that for you, even though you only specified iphoneos as the sysroot). You can also choose the architecture at build time too. What you need to do after that in terms of setting up code signing depends on what Xcode version you're using and whether you want to use automatic signing and provisioning or whether you want full manual control. For more info than you probably care about for this last point, a detailed write-up can be found here (not specific to CMake though): https://pewpewthespells.com/blog/migrating_code_signing.html If you're happy using Xcode 8 or later and automatic signing/provisioning, you only need to set two things (three if you want to specify the deployment target, which you probably do). Put something like this after the first project() command: set(CMAKE_XCODE_ATTRIBUTE_IPHONEOS_DEPLOYMENT_TARGET 10.0) set(CMAKE_XCODE_ATTRIBUTE_DEVELOPMENT_TEAM xxxxxxxxxx CACHE STRING "") set(CMAKE_XCODE_ATTRIBUTE_CODE_SIGN_IDENTITY "iPhone Developer" CACHE STRING "") Replace xxxxxxxxxx with your development team ID. Even for distribution builds, you want the code signing identity set to "iPhone Developer" - see the above code signing link for the reasons why. Chances are your project wants a specific deployment target, but developers may have a need to override the development team ID and/or the signing identity in certain circumstances, hence why these two have been defined as cache variables in the above example but the deployment target hasn't. See if that enables you to make some progress. On Tue, Oct 17, 2017 at 8:12 PM, Robert Bielik wrote: > Hi all, > > CMake version: 3.9.4 > > Trying to build protobuf on iOS via the toolchains @ > https://github.com/ruslo/polly (ios-10-2.cmake). With some additional > tricks in my wrapper CMakeLists file: > > if (IOS) > set(CMAKE_MACOSX_BUNDLE OFF) > find_package(Threads REQUIRED) > endif () > add_subdirectory(protobuf/cmake) > > it works fine up til the point where protoc is compiled. CMake files are > generated like so: > > cmake -GXcode -DCMAKE_TOOLCHAIN_FILE=$TOOLCHAINS/polly/ios-10-2.cmake > > > The error produced is: > > target specifies product type 'com.apple.product-type.tool', but there's > no such product type for the 'iphoneos' platform > > Granted, I won't really need the protoc target during cross building, but > I'd rather stay clear of the CMake files of protobuf. > > Ideas ? > > TIA > /Robert > > -- > > 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.Bielik at dirac.com Tue Oct 17 06:48:03 2017 From: Robert.Bielik at dirac.com (Robert Bielik) Date: Tue, 17 Oct 2017 10:48:03 +0000 Subject: [CMake] Protobuf on iOS In-Reply-To: References: <0c300f472a2e418380eac3659397243b@hosted3-mb02.itm.host> Message-ID: <076e95f32a034ac19ac91b18cfd7dd6e@hosted3-mb02.itm.host> Thanks Craig, For your thorough answer! > set(CMAKE_MACOSX_BUNDLE YES) I did set this so that the protoc app would get through compilation, but since the protobuf cmake/install.cmake file contains the following: install(TARGETS protoc ... RUNTIME DESTINATION ...) it chokes since BUNDLE DESTINATION is not defined, so I had to add that. The targets are all static libs so code signing is not a problem at this point. All the best, /Robert From dzenan.zukic at kitware.com Tue Oct 17 19:20:04 2017 From: dzenan.zukic at kitware.com (Dzenan Zukic) Date: Tue, 17 Oct 2017 19:20:04 -0400 Subject: [CMake] Windows crash dialog for tests Message-ID: Hi everybody, I am trying to debug a thread pool class in ITK. Some of the tests crash "at random". When a program crashes in Windows, normally a dialog pops up with options "report, debug, close". When a test crashes while being invoked by cmake, there is no pop-up dialog which would allow me to attach a debugger and see why it crashed, it is rather reported like this: 179/181 Test #303: itkImportImageTest .........................................***Exception: SegFault 0.61 sec ThreadPool constructor "ThreadPool constructor" is the test's debug output, written before the crash occurred. Can I disable this somehow and let the normal Windows crash dialog appear? Option *--interactive-debug-mode 1* sounded like what I wanted, but it did not have the desired effect. Regards, D?enan -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.yoshizawa at khomp.com Wed Oct 18 13:03:37 2017 From: daniel.yoshizawa at khomp.com (Daniel Yoshizawa) Date: Wed, 18 Oct 2017 15:03:37 -0200 Subject: [CMake] [CMAKE] Checking if a file exist at the installing process Message-ID: Hello everyone, I have a problem and couldn't find a solution over the internet, the situation is that I must copy some files at make install, the trick is, I must check if the files exists at install time if they don't, I must copy the files, otherwise do nothing. It doesn't feel anywhere near fine to me, but this is what are asking me to do, so there is no other way. My initial solution was to check if the file don't exist, if so I create a INSTALL command for it, the problem is that it runs at the configuration phase and I need something at install or post install, this files have nothing to do with the build, are just configuration files or other non-related stuff, so no target for them. One more thing, I know just the cmake basics, so please any help is welcome. Below is my original code that create the INSTALL commands at configuration phase. ------------------------------------------------------------------------------------------------------------------------------------------------------------- ########################################################################################## # # Desc : Files installation script, checks if the file exist on destination folder, # if so, doesn't overwrite the files. # # Params : input_file - File path with : # must be one entry per line following the model above. # # Obs : It is advised create .in files using ${CMAKE_SOURCE_DIR} to describe the path, # calling configure_file to generate the correct path. # # Ref : https://cmake.org/cmake/help/v3.2/command/configure_file.html # ########################################################################################## function (install_files input_file) MESSAGE("Files to be installed.") file(STRINGS ${input_file} contents) foreach(tuple ${contents}) string(REPLACE ":" ";" tuple_list ${tuple}) list(GET tuple_list 0 source) list(GET tuple_list 1 destination) if(IS_DIRECTORY ${source}) install_directory(${source} ${destination}) else(IS_DIRECTORY ${source}) install_file(${source} ${destination}) endif() endforeach() endfunction(install_files input_file) function (install_directory path_to_dir path_to_destination) file(GLOB folder_files "${path_to_dir}/*") foreach(filename ${folder_files}) if(IS_DIRECTORY ${filename}) get_filename_component( dir ${filename} NAME ) install_directory(${filename} ${path_to_destination}/${dir}) else(IS_DIRECTORY ${filename}) install_file(${filename} ${path_to_destination}) endif() endforeach(filename) endfunction(install_directory path_to_dir path_to_destination) function (install_file path_to_file path_to_destination) get_filename_component( filename ${path_to_file} NAME ) if (NOT EXISTS ${path_to_destination}/${filename}) MESSAGE("source path : ${path_to_file}") MESSAGE("destination path : ${path_to_destination}") install (FILES "${path_to_file}" DESTINATION "${path_to_destination}" PERMISSIONS OWNER_READ OWNER_WRITE OWNER_EXECUTE GROUP_READ GROUP_EXECUTE WORLD_READ WORLD_EXECUTE ) endif() endfunction (install_file path_to_file path_to_destination) ------------------------------------------------------------------------------------------------------------------------------------------------------------- Sorry for any mistakes and many thanks in advance, Daniel Yoshizawa. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pfultz2 at yahoo.com Wed Oct 18 18:36:55 2017 From: pfultz2 at yahoo.com (paul) Date: Wed, 18 Oct 2017 17:36:55 -0500 Subject: [CMake] [CMAKE] Checking if a file exist at the installing process In-Reply-To: References: Message-ID: <1508366215.3965.464.camel@yahoo.com> You can use install(CODE) or install(SCRIPT) to run custom cmake code at install time. The only caveat is the install location is actually `$ENV{DESTDIR}${CMAKE_INSTALL_PREFIX}` instead of just `${CMAKE_INSTALL_PREFIX}`. This can happen when the user calls `make DESTDIR=` or during cpack. On Wed, 2017-10-18 at 15:03 -0200, Daniel Yoshizawa wrote: > Hello everyone, > > I have a problem and couldn't find a solution over the internet, the > situation is that I must copy some files at make install, the trick is, I > must check if the files exists at install time if they don't, I must copy > the files, otherwise do nothing. > > It doesn't feel anywhere near fine to me, but this is what are asking me to > do, so there is no other way. > > My initial solution was to check if the file don't exist, if so I create a > INSTALL command for it, the problem is that it runs at the configuration > phase and I need something at install or post install, this files have > nothing to do with the build, are just configuration files or other non- > related stuff, so no target for them. > > One more thing, I know just the cmake basics, so please any help is welcome. > > Below is my original code that create the INSTALL commands at configuration > phase. > > ---------------------------------------------------------------------------- > ---------------------------------------------------------------------------- > ----- > > ############################################################################ > ############## > # > #?? Desc : Files installation script, checks if the file exist on > destination folder, > #????????? if so, doesn't overwrite the files. > # > #?? Params : input_file - File path with : > #??????????? must be one entry per line following the model above. > # > #?? Obs : It is advised create .in files using ${CMAKE_SOURCE_DIR} to > describe the path, > #???????? calling configure_file to generate the correct path. > # > #?? Ref : https://cmake.org/cmake/help/v3.2/command/configure_file.html > # > ############################################################################ > ############## > > function (install_files input_file) > > ??? MESSAGE("Files to be installed.") > > ??? file(STRINGS ${input_file} contents) > > ??? foreach(tuple ${contents}) > ??????? string(REPLACE ":" ";" tuple_list ${tuple}) > ??????? list(GET tuple_list 0 source) > ??????? list(GET tuple_list 1 destination) > > ??????? if(IS_DIRECTORY ${source}) > ??????????? install_directory(${source} ${destination}) > ??????? else(IS_DIRECTORY ${source}) > ??????????? install_file(${source} ${destination}) > ??????? endif() > > ??? endforeach() > > endfunction(install_files input_file) > > function (install_directory path_to_dir path_to_destination) > > ??? file(GLOB folder_files "${path_to_dir}/*") > > ??? foreach(filename ${folder_files}) > > ??????? if(IS_DIRECTORY ${filename}) > ??????????? get_filename_component( dir ${filename} NAME ) > ??????????? install_directory(${filename} ${path_to_destination}/${dir}) > ??????? else(IS_DIRECTORY ${filename}) > ??????????? install_file(${filename} ${path_to_destination}) > ??????? endif() > > ??? endforeach(filename) > > endfunction(install_directory path_to_dir path_to_destination) > > function (install_file path_to_file path_to_destination) > > ??? get_filename_component( filename ${path_to_file} NAME ) > ???? > ??? if (NOT EXISTS ${path_to_destination}/${filename}) > ??????? MESSAGE("source path????? : ${path_to_file}") > ??????? MESSAGE("destination path : ${path_to_destination}") > > ??????? install (FILES "${path_to_file}" > ??????????????????? DESTINATION "${path_to_destination}" > ??????????????????? PERMISSIONS OWNER_READ OWNER_WRITE OWNER_EXECUTE > GROUP_READ GROUP_EXECUTE WORLD_READ WORLD_EXECUTE > ??????????????? ) > ??? endif() > > endfunction (install_file path_to_file path_to_destination) > > ---------------------------------------------------------------------------- > ---------------------------------------------------------------------------- > ----- > > Sorry for any mistakes and many thanks in advance, > Daniel Yoshizawa. > --? > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.o > rg/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/opensourc > e/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake From daniel.yoshizawa at khomp.com Thu Oct 19 06:59:20 2017 From: daniel.yoshizawa at khomp.com (Daniel Yoshizawa) Date: Thu, 19 Oct 2017 08:59:20 -0200 Subject: [CMake] [CMAKE] Checking if a file exist at the installing process In-Reply-To: <1508366215.3965.464.camel@yahoo.com> References: <1508366215.3965.464.camel@yahoo.com> Message-ID: Hello Paul, Many thanks, seems a better solution than mine. I created a custom target calling my script but doing this way I had to do make install && make install_files, it doesn't look good. Also had to change install(FILES) to file( COPY ). I will try install(SCRIPT) later today. Once again, thanks for the answer. Daniel Yoshizawa. 2017-10-18 20:36 GMT-02:00 paul : > You can use install(CODE) or install(SCRIPT) to run custom cmake code at > install time. The only caveat is the install location is actually > `$ENV{DESTDIR}${CMAKE_INSTALL_PREFIX}` instead of just > `${CMAKE_INSTALL_PREFIX}`. This can happen when the user calls `make > DESTDIR=` or during cpack. > > On Wed, 2017-10-18 at 15:03 -0200, Daniel Yoshizawa wrote: > > Hello everyone, > > > > I have a problem and couldn't find a solution over the internet, the > > situation is that I must copy some files at make install, the trick is, I > > must check if the files exists at install time if they don't, I must copy > > the files, otherwise do nothing. > > > > It doesn't feel anywhere near fine to me, but this is what are asking me > to > > do, so there is no other way. > > > > My initial solution was to check if the file don't exist, if so I create > a > > INSTALL command for it, the problem is that it runs at the configuration > > phase and I need something at install or post install, this files have > > nothing to do with the build, are just configuration files or other non- > > related stuff, so no target for them. > > > > One more thing, I know just the cmake basics, so please any help is > welcome. > > > > Below is my original code that create the INSTALL commands at > configuration > > phase. > > > > ------------------------------------------------------------ > ---------------- > > ------------------------------------------------------------ > ---------------- > > ----- > > > > ############################################################ > ################ > > ############## > > # > > # Desc : Files installation script, checks if the file exist on > > destination folder, > > # if so, doesn't overwrite the files. > > # > > # Params : input_file - File path with : > > # must be one entry per line following the model above. > > # > > # Obs : It is advised create .in files using ${CMAKE_SOURCE_DIR} to > > describe the path, > > # calling configure_file to generate the correct path. > > # > > # Ref : https://cmake.org/cmake/help/v3.2/command/configure_file.html > > # > > ############################################################ > ################ > > ############## > > > > function (install_files input_file) > > > > MESSAGE("Files to be installed.") > > > > file(STRINGS ${input_file} contents) > > > > foreach(tuple ${contents}) > > string(REPLACE ":" ";" tuple_list ${tuple}) > > list(GET tuple_list 0 source) > > list(GET tuple_list 1 destination) > > > > if(IS_DIRECTORY ${source}) > > install_directory(${source} ${destination}) > > else(IS_DIRECTORY ${source}) > > install_file(${source} ${destination}) > > endif() > > > > endforeach() > > > > endfunction(install_files input_file) > > > > function (install_directory path_to_dir path_to_destination) > > > > file(GLOB folder_files "${path_to_dir}/*") > > > > foreach(filename ${folder_files}) > > > > if(IS_DIRECTORY ${filename}) > > get_filename_component( dir ${filename} NAME ) > > install_directory(${filename} ${path_to_destination}/${dir}) > > else(IS_DIRECTORY ${filename}) > > install_file(${filename} ${path_to_destination}) > > endif() > > > > endforeach(filename) > > > > endfunction(install_directory path_to_dir path_to_destination) > > > > function (install_file path_to_file path_to_destination) > > > > get_filename_component( filename ${path_to_file} NAME ) > > > > if (NOT EXISTS ${path_to_destination}/${filename}) > > MESSAGE("source path : ${path_to_file}") > > MESSAGE("destination path : ${path_to_destination}") > > > > install (FILES "${path_to_file}" > > DESTINATION "${path_to_destination}" > > PERMISSIONS OWNER_READ OWNER_WRITE OWNER_EXECUTE > > GROUP_READ GROUP_EXECUTE WORLD_READ WORLD_EXECUTE > > ) > > endif() > > > > endfunction (install_file path_to_file path_to_destination) > > > > ------------------------------------------------------------ > ---------------- > > ------------------------------------------------------------ > ---------------- > > ----- > > > > Sorry for any mistakes and many thanks in advance, > > Daniel Yoshizawa. > > -- > > > > Powered by www.kitware.com > > > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.o > > rg/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/ > opensourc > > e/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.Bielik at dirac.com Thu Oct 19 10:09:14 2017 From: Robert.Bielik at dirac.com (Robert Bielik) Date: Thu, 19 Oct 2017 14:09:14 +0000 Subject: [CMake] Install rpath handling for iOS frameworks Message-ID: I'm trying to package an iOS framework, and with the target setting: XCODE_ATTRIBUTE_LD_DYLIB_INSTALL_NAME "@rpath/$(EXECUTABLE_PATH)" I get the framework built nicely. otool -L dummy.framework/dummy shows @rpath/dummy.framework/dummy Just as it should. Now I have a install directive: install(TARGETS dummy FRAMEWORK DESTINATION "./" COMPONENTS frameworks) Then I do cpack -G ZIP, and it all packages together without a hitch. But when I do otool -L of the dummy.framework/dummy from where the package is built I get: dummy.framework/dummy i.e. @rpath has been removed during the install process ? What am I doing wrong ? TIA /Robert From Robert.Bielik at dirac.com Thu Oct 19 10:14:26 2017 From: Robert.Bielik at dirac.com (Robert Bielik) Date: Thu, 19 Oct 2017 14:14:26 +0000 Subject: [CMake] Install rpath handling for iOS frameworks In-Reply-To: References: Message-ID: Oh, and I just added: SET(CMAKE_INSTALL_RPATH_USE_LINK_PATH TRUE) But it doesn't change anything. /R > -----Original Message----- > From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Robert > Bielik > Sent: den 19 oktober 2017 16:09 > To: Cmake at cmake.org > Subject: [CMake] Install rpath handling for iOS frameworks > > I'm trying to package an iOS framework, and with the target setting: > > XCODE_ATTRIBUTE_LD_DYLIB_INSTALL_NAME > "@rpath/$(EXECUTABLE_PATH)" > > I get the framework built nicely. otool -L dummy.framework/dummy shows > > @rpath/dummy.framework/dummy > > Just as it should. Now I have a install directive: > > install(TARGETS dummy > FRAMEWORK DESTINATION "./" COMPONENTS frameworks) > > Then I do cpack -G ZIP, and it all packages together without a hitch. But when > I do otool -L of the dummy.framework/dummy from where the package is > built I get: > > dummy.framework/dummy > > i.e. @rpath has been removed during the install process ? > > What am I doing wrong ? > > TIA > /Robert > > -- > > 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 edo.paskino at gmail.com Thu Oct 19 11:53:34 2017 From: edo.paskino at gmail.com (Edoardo Pasca) Date: Thu, 19 Oct 2017 16:53:34 +0100 Subject: [CMake] conda recipe generator Message-ID: Hi everyone, we switched the build of some packages with conda-build. Ideally I'd like to have CMake setting up the conda recipe. Is there something like a conda recipe generator? If not, how do I proceed? A lot of configure_file I presume? Thanks for any suggestions Edo -- Edo I know you think you understand what you thought I said, but I'm not sure you realize that what you heard is not what I meant (prob. Alan Greenspan) :wq -------------- next part -------------- An HTML attachment was scrubbed... URL: From pfultz2 at yahoo.com Thu Oct 19 12:39:31 2017 From: pfultz2 at yahoo.com (paul) Date: Thu, 19 Oct 2017 11:39:31 -0500 Subject: [CMake] conda recipe generator In-Reply-To: References: Message-ID: <1508431171.18503.15.camel@yahoo.com> I am not sure it makes sense to generate a conda-recipe. You could have it a generate the meta.yaml file, but whats the point as you already got the source code and running cmake? Also, for the `build.sh` scripts, it should always be the same for every cmake project, something like: mkdir build cd build cmake -G $CMAKE_GENERATOR -DCMAKE_INSTALL_PREFIX=$PREFIX -DCMAKE_BUILD_TYPE=Release $SRC_DIR cmake --build . cmake --build . --target install Changing dollar sign variables to percent variables, this should work for windows as well. Ideally, it would be nice if an attribute could be added to the `meta.yaml` file to tell it to use the standard cmake installation instead of copying the same build scripts over and over. Also, if your dependencies are mainly using cmake, you could look into using `cget` which does package management using the standard cmake?installation, and it can even handle cross-compilation fairly easily as well. On Thu, 2017-10-19 at 16:53 +0100, Edoardo Pasca wrote: > Hi everyone,? > > we switched the build of some packages with conda-build. > > Ideally I'd like to have CMake setting up the conda recipe.? > > Is there something like a conda recipe generator? > If not, how do I proceed? > A lot of configure_file I presume? > > Thanks for any suggestions > > Edo > > > --? > Edo > I know you think you understand what you thought I said, but I'm not sure > you realize that what you heard is not what I meant (prob. Alan Greenspan) > :wq > --? > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.o > rg/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/opensourc > e/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake From robert.maynard at kitware.com Thu Oct 19 15:40:04 2017 From: robert.maynard at kitware.com (Robert Maynard) Date: Thu, 19 Oct 2017 15:40:04 -0400 Subject: [CMake] [ANNOUNCE] CMake 3.10.0-rc3 is now ready for testing Message-ID: I am proud to announce the third CMake 3.10 release candidate. https://cmake.org/download/ Documentation is available at: https://cmake.org/cmake/help/v3.10 Release notes appear below and are also published at https://cmake.org/cmake/help/v3.10/release/3.10.html Some of the more significant changes in CMake 3.10 are: * The flang Fortran compiler is now supported, with compiler id "Flang". * Support for the MSVC ARM64 architecture was added. Visual Studio 2017 Update 4 and above offer an ARM64 toolchain. * The "include_guard()" command was introduced to allow guarding CMake scripts from being included more than once. The command supports "DIRECTORY" and "GLOBAL" options to adjust the corresponding include guard scope. If no options given, include guard is similar to basic variable-based check. * "FindMPI" received a major overhaul. It now features language specific components, better Fortran support, and support for statically linked MPI implementations. * A "FindOpenACC" module was added to detect compiler support for OpenACC. Currently only supports PGI, GNU and Cray compilers. * The "FindOpenGL" module underwent numerous improvements. It has gained support for GLVND and EGL on Linux. It now has import targets that separate the OpenGL library and OpenGL contexts. * The "GoogleTest" module gained a new command "gtest_discover_tests()" implementing dynamic (build-time) test discovery. * When using "AUTOMOC" or "AUTOUIC", source files that are "GENERATED" will be processed as well. They were ignored by "AUTOMOC" and "AUTOUIC" in earlier releases. See policy "CMP0071". * A "CTEST_LABELS_FOR_SUBPROJECTS" CTest module variable and CTest script variable were added to specify a list of labels that should be treated as subprojects by CDash. To use this value in both the CTest module and the ctest command line Dashboard Client mode (e.g. "ctest -S") set it in the "CTestConfig.cmake" config file. * CPack gained a "FREEBSD" generator for FreeBSD "pkg(8)", configured by the "CPackFreeBSD" module. * The CPack "DEB" generator, configured by the "CPackDeb" module, was enabled on Windows. While not fully featured (due to the lack of external UNIX tools) this will allow building basic cross- platform Debian packages. * The "cmake(1)" "-E" mode gained support for "sha1sum", "sha224sum", "sha256sum", "sha384sum", and "sha512sum". * The "file(GENERATE)" command now interprets relative paths given to its "OUTPUT" and "INPUT" arguments with respect to the caller's current binary and source directories, respectively. See policy "CMP0070". CMake 3.10 Release Notes ************************ Changes made since CMake 3.9 include the following. New Features ============ Platforms --------- * The flang Fortran compiler is now supported, with compiler id "Flang". * A new minimal platform file for "Midipix" was added. * Support for the MSVC ARM64 architecture was added. Visual Studio 2017 Update 4 and above offer an ARM64 toolchain. * Support for the IAR ARM Compiler was improved. Generators ---------- * The Makefile Generators and the "Ninja" generator learned to add compiler launcher tools like ccache along with the compiler for the "CUDA" language ("C" and "CXX" were supported previously). See the "CMAKE__COMPILER_LAUNCHER" variable and "_COMPILER_LAUNCHER" target property for details. * The "CodeBlocks" extra generator learned to optionally exclude files from outside the project root directory from the generated project. See the "CMAKE_CODEBLOCKS_EXCLUDE_EXTERNAL_FILES" variable. Commands -------- * The "cmake_host_system_information()" command learned more keys to get information about the processor capabilities and the host OS version. * The "configure_file()" command learned to support indented "# cmakedefine" and "# cmakedefine01". Spaces and/or tabs between the "#" character and the "cmakedefine"/"cmakedefine01" words are now understood and preserved in the output. * The "execute_process()" command gained a "RESULTS_VARIABLE" option to collect a list of results from all children in a pipeline of processes when multiple "COMMAND" arguments are given. * The "include_guard()" command was introduced to allow guarding CMake scripts from being included more than once. The command supports "DIRECTORY" and "GLOBAL" options to adjust the corresponding include guard scope. If no options given, include guard is similar to basic variable-based check. * The "string()" command learned a new "PREPEND" subcommand. * The "string(TIMESTAMP)" command now supports "%A" for full weekday name and "%B" for full month name. Variables --------- * A "CMAKE_DIRECTORY_LABELS" variable was added to specify labels for all tests in a directory. Properties ---------- * A "_CPPCHECK" target property and supporting "CMAKE__CPPCHECK" variable were introduced to tell the Makefile Generators and the "Ninja" generator to run "cppcheck" with the compiler for "C" and "CXX" languages. * A "LABELS" directory property was added to specify labels for all targets and tests in a directory. * A "TEST_INCLUDE_FILES" directory property was added to list any number of files to be included when running tests with "ctest(1)". This generalizes the "TEST_INCLUDE_FILE" property. * The "VS_DOTNET_REFERENCEPROP__TAG_" target property was added to support custom XML tags for reference assemblies in C# targets. * Source file properties "VS_SHADER_OUTPUT_HEADER_FILE" and "VS_SHADER_VARIABLE_NAME" have been added to specify more details of ".hlsl" sources with Visual Studio Generators. Modules ------- * The "FindCurses" module gained a "CURSES_NEED_WIDE" option to request the wide-character variant. * The "FindEXPAT" module now provides imported targets. * The "FindFreetype" module now provides imported targets. * "FindMPI" gained a number of new features, including: * Language-specific components have been added to the module. * Many more MPI environments are now supported. * The environmental support for Fortran has been improved. * A user now has fine-grained control over the MPI selection process, including passing custom parameters to the MPI compiler. * The version of the implemented MPI standard is now being exposed. * MPI-2 C++ bindings can now be detected and also suppressed if so desired. * The available Fortran bindings are now being detected and verified. * Various MPI-3 information can be requested, including the library version and Fortran capabilities of the individual bindings. * Statically linked MPI implementations are supported. * A "FindOpenACC" module was added to detect compiler support for OpenACC. Currently only supports PGI, GNU and Cray compilers. * The "FindOpenGL" module gained support for GLVND on Linux. * The "FindOpenMP" module gained support for language-specific components. * A "FindPatch" module was added to find the "patch" command-line executable. * The "FindProtobuf" module "protobuf_generate_cpp()" command gained a "DESCRIPTORS" option to generate descriptor files. * The "GoogleTest" module gained a new command "gtest_discover_tests()" implementing dynamic (build-time) test discovery. Unlike the source parsing approach, dynamic discovery executes the test (in 'list available tests' mode) at build time to discover tests. This is robust against unusual ways of labeling tests, provides much better support for advanced features such as parameterized tests, and does not require re-running CMake to discover added or removed tests within a test executable. * The "InstallRequiredSystemLibraries" module gained support for installing Intel compiler runtimes. Autogen ------- * When using "AUTOMOC" or "AUTOUIC" with a multi configuration generator (e.g. "Xcode"), included "*.moc", "moc_*.cpp" and "ui_*.h" files are generated in "/include_" instead of "/include". * When using "AUTOMOC" or "AUTOUIC", source files that are "GENERATED" will be processed as well. They were ignored by "AUTOMOC" and "AUTOUIC" in earlier releases. See policy "CMP0071". * When using "AUTOMOC", CMake searches for the strings "Q_OBJECT", "Q_GADGET" or "Q_NAMESPACE" in a source file to determine if it needs to be "moc" processed. The new "CMAKE_AUTOMOC_MACRO_NAMES" variable and "AUTOMOC_MACRO_NAMES" target property may be set to register additional strings (macro names) to search for. * When using "AUTOMOC", the new "CMAKE_AUTOMOC_COMPILER_PREDEFINES" variable and "AUTOMOC_COMPILER_PREDEFINES" target property specify whether to enable or disable the generation of the compiler pre definitions file "moc_predefs.h". CTest ----- * A "CTEST_LABELS_FOR_SUBPROJECTS" CTest module variable and CTest script variable were added to specify a list of labels that should be treated as subprojects by CDash. To use this value in both the CTest module and the ctest command line Dashboard Client mode (e.g. "ctest -S") set it in the "CTestConfig.cmake" config file. CPack ----- * CPack gained a "FREEBSD" generator for FreeBSD "pkg(8)", configured by the "CPackFreeBSD" module. * The CPack "DEB" generator, configured by the "CPackDeb" module, was enabled on Windows. While not fully featured (due to the lack of external UNIX tools) this will allow building basic cross- platform Debian packages. * The "CPackDeb" module learned to set package release version in "Version" info property. See the "CPACK_DEBIAN_PACKAGE_RELEASE" variable. * The "CPackDeb" module learned more strict package version checking that complies with Debian rules. * The "CPackIFW" module "cpack_ifw_configure_component()" and "cpack_ifw_configure_component_group()" commands gained a new "REPLACES" and "CHECKABLE" options. * The "CPackIFW" module gained new "CPACK_IFW_PACKAGE_FILE_EXTENSION" variable to customize target binary format. * The "CPackIFW" module gained new "CPACK_IFW_REPOSITORIES_DIRECTORIES" variable to specify additional repositories dirs that will be used to resolve and repack dependent components. This feature is only available when using QtIFW 3.1 or later. * Modules "CPackRPM" and "CPackDeb" learned to set package epoch version. See "CPACK_RPM_PACKAGE_EPOCH" and "CPACK_DEBIAN_PACKAGE_EPOCH" variables. Other ----- * The "cmake(1)" "-E" mode gained support for "sha1sum", "sha224sum", "sha256sum", "sha384sum", and "sha512sum". * The graphviz output now distinguishes among the different dependency types "PUBLIC", "PRIVATE" and "INTERFACE" and represents them in the output graph as solid, dashed and dotted edges. Deprecated and Removed Features =============================== * Support for building CMake itself with C++98 compilers was dropped. CMake is now implemented using C++11. * Support for building CMake on HP-UX has been dropped pending better support for C++11 and a port of libuv. See CMake Issue 17137. Use CMake 3.9 or lower instead for HP-UX support. Other Changes ============= * On FreeBSD the C++ compiler named "c++" is now the preferred default. * The "file(GENERATE)" command now interprets relative paths given to its "OUTPUT" and "INPUT" arguments with respect to the caller's current binary and source directories, respectively. See policy "CMP0070". * The "get_filename_component()" "PROGRAM" mode semantics have been revised to not tolerate unquoted spaces in the path to the program while also accepting arguments. While technically incompatible with the old behavior, it is expected that behavior under typical use cases with properly-quoted command-lines has not changed. ---------------------------------------------------------------------------- Changes made since CMake 3.10.0-rc2: Brad King (7): Do not initialize NO_SYSTEM_FROM_IMPORTED on INTERFACE libraries Help: Clarify documentation of NO_SYSTEM_FROM_IMPORTED cmVSSetupHelper: Factor out install location string construction cmVSSetupHelper: Fix install location encoding conversion VS: Detect compiler component in VS 2017 instances more reliably VS: Set CUDA TargetMachinePlatform explicitly on x64 CMake 3.10.0-rc3 Christian Pfeiffer (1): FindOpenMP: Improve OMP libraries search From Robert.Bielik at dirac.com Fri Oct 20 02:31:32 2017 From: Robert.Bielik at dirac.com (Robert Bielik) Date: Fri, 20 Oct 2017 06:31:32 +0000 Subject: [CMake] Install rpath handling for iOS frameworks In-Reply-To: References: Message-ID: <4e7e1558f9ac4f15a5f17c21802d81b7@hosted3-mb02.itm.host> Running 3.9.4 I see that behavior related to RPATH on macOS has changed: https://cmake.org/cmake/help/v3.9/policy/CMP0068.html I've tried setting the policy to OLD, but I'm just not able to get @rpath/... to propagate to the install ? Ideas, please ? /R > -----Original Message----- > From: Robert Bielik > Sent: den 19 oktober 2017 16:14 > To: Robert Bielik ; Cmake at cmake.org > Subject: RE: Install rpath handling for iOS frameworks > > Oh, and I just added: > > SET(CMAKE_INSTALL_RPATH_USE_LINK_PATH TRUE) > > But it doesn't change anything. > > /R > > > -----Original Message----- > > From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Robert > > Bielik > > Sent: den 19 oktober 2017 16:09 > > To: Cmake at cmake.org > > Subject: [CMake] Install rpath handling for iOS frameworks > > > > I'm trying to package an iOS framework, and with the target setting: > > > > XCODE_ATTRIBUTE_LD_DYLIB_INSTALL_NAME > > "@rpath/$(EXECUTABLE_PATH)" > > > > I get the framework built nicely. otool -L dummy.framework/dummy > shows > > > > @rpath/dummy.framework/dummy > > > > Just as it should. Now I have a install directive: > > > > install(TARGETS dummy > > FRAMEWORK DESTINATION "./" COMPONENTS frameworks) > > > > Then I do cpack -G ZIP, and it all packages together without a hitch. > > But when I do otool -L of the dummy.framework/dummy from where the > > package is built I get: > > > > dummy.framework/dummy > > > > i.e. @rpath has been removed during the install process ? > > > > What am I doing wrong ? > > > > TIA > > /Robert > > > > -- > > > > 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.Bielik at dirac.com Fri Oct 20 04:40:30 2017 From: Robert.Bielik at dirac.com (Robert Bielik) Date: Fri, 20 Oct 2017 08:40:30 +0000 Subject: [CMake] Install rpath handling for iOS frameworks [solved-ish] Message-ID: Ok, this is most certainly not the way to do it, but I added two install steps: install(CODE "SET(FRAMEWORK_SO \"dummy.framework/dummy\")") install(SCRIPT add_rpath.cmake COMPONENT frameworks) add_rpath.cmake: ############ # Adds @rpath to the SO in the framework because CMake install removes it (!!!) EXECUTE_PROCESS( COMMAND install_name_tool -id "@rpath/${FRAMEWORK_SO}" ${FRAMEWORK_SO} WORKING_DIRECTORY ${CMAKE_INSTALL_PREFIX} ) ############# And this works with install target and packaging. But it is ugly. /R > -----Original Message----- > From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Robert > Bielik > Sent: den 20 oktober 2017 08:32 > To: Cmake at cmake.org > Subject: Re: [CMake] Install rpath handling for iOS frameworks > > Running 3.9.4 I see that behavior related to RPATH on macOS has changed: > > https://cmake.org/cmake/help/v3.9/policy/CMP0068.html > > I've tried setting the policy to OLD, but I'm just not able to get @rpath/... to > propagate to the install ? > > Ideas, please ? > /R > > > -----Original Message----- > > From: Robert Bielik > > Sent: den 19 oktober 2017 16:14 > > To: Robert Bielik ; Cmake at cmake.org > > Subject: RE: Install rpath handling for iOS frameworks > > > > Oh, and I just added: > > > > SET(CMAKE_INSTALL_RPATH_USE_LINK_PATH TRUE) > > > > But it doesn't change anything. > > > > /R > > > > > -----Original Message----- > > > From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Robert > > > Bielik > > > Sent: den 19 oktober 2017 16:09 > > > To: Cmake at cmake.org > > > Subject: [CMake] Install rpath handling for iOS frameworks > > > > > > I'm trying to package an iOS framework, and with the target setting: > > > > > > XCODE_ATTRIBUTE_LD_DYLIB_INSTALL_NAME > > > "@rpath/$(EXECUTABLE_PATH)" > > > > > > I get the framework built nicely. otool -L dummy.framework/dummy > > shows > > > > > > @rpath/dummy.framework/dummy > > > > > > Just as it should. Now I have a install directive: > > > > > > install(TARGETS dummy > > > FRAMEWORK DESTINATION "./" COMPONENTS frameworks) > > > > > > Then I do cpack -G ZIP, and it all packages together without a hitch. > > > But when I do otool -L of the dummy.framework/dummy from where > the > > > package is built I get: > > > > > > dummy.framework/dummy > > > > > > i.e. @rpath has been removed during the install process ? > > > > > > What am I doing wrong ? > > > > > > TIA > > > /Robert > > > > > > -- > > > > > > 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 clinton at elemtech.com Fri Oct 20 08:27:37 2017 From: clinton at elemtech.com (clinton at elemtech.com) Date: Fri, 20 Oct 2017 06:27:37 -0600 (MDT) Subject: [CMake] Install rpath handling for iOS frameworks [solved-ish] In-Reply-To: References: Message-ID: <1537897193.37806092.1508502457912.JavaMail.zimbra@elemtech.com> It looks like you want the default behavior, but from what you show, I don't know what is disabling it. The default behavior does not require you to set the XCODE_ATTRIBUTE_LD_DYLIB_INSTALL_NAME, nor does it require you to call install_name_tool yourself at install time to get @rpath. Not getting @rpath could be from the old behavior of CMP0042, setting MACOSX_RPATH = 0, or setting INSTALL_NAME_DIR = "". I think those are the only 3 factors, but in older versions of CMake, before CMP0068, there were more variables which could affect it. If you are doing cross compiling with a toolchain file, maybe its something else, such as the setting of CMAKE_SHARED_LIBRARY_RUNTIME_C_FLAG. Clint ----- On Oct 20, 2017, at 2:40 AM, Robert Bielik Robert.Bielik at dirac.com wrote: > Ok, this is most certainly not the way to do it, but I added two install steps: > > install(CODE "SET(FRAMEWORK_SO \"dummy.framework/dummy\")") > install(SCRIPT add_rpath.cmake COMPONENT frameworks) > > add_rpath.cmake: > ############ > # Adds @rpath to the SO in the framework because CMake install removes it (!!!) > EXECUTE_PROCESS( > COMMAND install_name_tool -id "@rpath/${FRAMEWORK_SO}" ${FRAMEWORK_SO} > WORKING_DIRECTORY ${CMAKE_INSTALL_PREFIX} > ) > ############# > > And this works with install target and packaging. But it is ugly. > /R > >> -----Original Message----- >> From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Robert >> Bielik >> Sent: den 20 oktober 2017 08:32 >> To: Cmake at cmake.org >> Subject: Re: [CMake] Install rpath handling for iOS frameworks >> >> Running 3.9.4 I see that behavior related to RPATH on macOS has changed: >> >> https://cmake.org/cmake/help/v3.9/policy/CMP0068.html >> >> I've tried setting the policy to OLD, but I'm just not able to get @rpath/... to >> propagate to the install ? >> >> Ideas, please ? >> /R >> >> > -----Original Message----- >> > From: Robert Bielik >> > Sent: den 19 oktober 2017 16:14 >> > To: Robert Bielik ; Cmake at cmake.org >> > Subject: RE: Install rpath handling for iOS frameworks >> > >> > Oh, and I just added: >> > >> > SET(CMAKE_INSTALL_RPATH_USE_LINK_PATH TRUE) >> > >> > But it doesn't change anything. >> > >> > /R >> > >> > > -----Original Message----- >> > > From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Robert >> > > Bielik >> > > Sent: den 19 oktober 2017 16:09 >> > > To: Cmake at cmake.org >> > > Subject: [CMake] Install rpath handling for iOS frameworks >> > > >> > > I'm trying to package an iOS framework, and with the target setting: >> > > >> > > XCODE_ATTRIBUTE_LD_DYLIB_INSTALL_NAME >> > > "@rpath/$(EXECUTABLE_PATH)" >> > > >> > > I get the framework built nicely. otool -L dummy.framework/dummy >> > shows >> > > >> > > @rpath/dummy.framework/dummy >> > > >> > > Just as it should. Now I have a install directive: >> > > >> > > install(TARGETS dummy >> > > FRAMEWORK DESTINATION "./" COMPONENTS frameworks) >> > > >> > > Then I do cpack -G ZIP, and it all packages together without a hitch. >> > > But when I do otool -L of the dummy.framework/dummy from where >> the >> > > package is built I get: >> > > >> > > dummy.framework/dummy >> > > >> > > i.e. @rpath has been removed during the install process ? >> > > >> > > What am I doing wrong ? >> > > >> > > TIA >> > > /Robert >> > > >> > > -- >> > > >> > > 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 > -- > > 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 wesley.hoke at gmail.com Sat Oct 21 17:11:23 2017 From: wesley.hoke at gmail.com (Wesley Smith) Date: Sat, 21 Oct 2017 14:11:23 -0700 Subject: [CMake] CSharp and NuGet Package Message-ID: Hi, I'm using CMake 3.10.0-rc3. I'm trying to figure out how to add NuGet packages to my CSharp target. In particular, I'm trying to add PostSharp. I know the usual CMake way is to add a FindPackage for each library. However, NuGet being a package manager with many packages in it, I was wondering if there was a facility for finding packages with NuGet built into CMake. What's the best way to add a library to a Csharp target from NuGet? thanks, wes -------------- next part -------------- An HTML attachment was scrubbed... URL: From d3ck0r at gmail.com Sun Oct 22 09:38:23 2017 From: d3ck0r at gmail.com (J Decker) Date: Sun, 22 Oct 2017 06:38:23 -0700 Subject: [CMake] externalproject_add install_dir doesn't work Message-ID: A smiple cmakelists like this. Without specifying the CMAKE_ARGS CMAKE_INSTALL_PREFIX this tries to install into c:\program files. ----- cmake_minimum_required(VERSION 3.6) include( ExternalProject ) ExternalProject_Add( external PREFIX ${CMAKE_BINARY_DIR}/tmpout SOURCE_DIR ${CMAKE_SOURCE_DIR}/extern INSTALL_DIR ${CMAKE_BINARY_DIR}/output CMAKE_ARGS -DCMAKE_INSTALL_PREFIX=${CMAKE_BINARY_DIR}/output ) ---- ./extern/cmakelists.txt cmake_minimum_required(VERSION 3.6) INSTALL( FILES tmp.bat DESTINATION data ) -------- I was trying to figure out why the install is failing on another project, it says (using vs 2015 generator) MSBUILD : error MSB1009: Project file does not exist. [M:\javascript\vfs\native\build\sack.vcxproj] Switch: install in which the rule that runs C:\tools\unix\cmake\bin\cmake.exe --build . --config Debug --target install is failling... to work it would have to be INSTALL. but my simple case isn't causing the same failure ---- Been tinkering with this for a couple hours trying to make the example more close to the full case, but cannot; if I edit the rule and make the '--target INSTALL' then it works in the actual case... although the same thing works fine in the simplified example.... -------- Line 1766 of ExternalProject in latest cmake download list(APPEND args --target install) should(could) be if( MSVC ) list(APPEND args --target INSTALL) else( MSVC ) list(APPEND args --target install) endif( MSVC ) which fixes my issue. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mwpowellhtx at gmail.com Mon Oct 23 08:21:05 2017 From: mwpowellhtx at gmail.com (Michael Powell) Date: Mon, 23 Oct 2017 08:21:05 -0400 Subject: [CMake] HELP: CMake "cache" stuck after renaming project path Message-ID: HELP! As the subject says, I renamed the project folder to a saner location (for me anyway), which is now causing CMake to complain about its "cache". Somehow or another it is stuck on the previous path. This in spite of the fact I have CLEARED the out of place "build" location. The cache does indeed reflect the old path. In spite of the fact I am telling CMake the correct path where the source code is. I am running v3.9.2 on Windows 7. Muy frustrated! HELP! Cheers, Michael Powell From oleksii.vilchanskyi at gmail.com Mon Oct 23 08:25:49 2017 From: oleksii.vilchanskyi at gmail.com (Oleksii Vilchanskyi) Date: Mon, 23 Oct 2017 14:25:49 +0200 Subject: [CMake] HELP: CMake "cache" stuck after renaming project path In-Reply-To: References: Message-ID: <776ac544-9a6d-a95c-644e-39177189548f@gmail.com> It would help if you have posted the exact error message you receive. Otherwise it's just guessing. Speaking of guessing, if you use Ninja, it leaves `.ninja` files in the binary directory, so if you haven't removed the directory directly, you might want to remove hidden files, too. On 23.10.2017 14:21, Michael Powell wrote: > HELP! > > As the subject says, I renamed the project folder to a saner location > (for me anyway), which is now causing CMake to complain about its > "cache". Somehow or another it is stuck on the previous path. > > This in spite of the fact I have CLEARED the out of place "build" > location. The cache does indeed reflect the old path. In spite of the > fact I am telling CMake the correct path where the source code is. > > I am running v3.9.2 on Windows 7. > > Muy frustrated! HELP! > > Cheers, > > Michael Powell > -- Regards, Oleksii Vilchanskyi PGP:0x8D3A0E046BDE941F2A53867CE3FD952D48C0B338 From noflaco at gmail.com Mon Oct 23 08:30:04 2017 From: noflaco at gmail.com (Carlton Banks) Date: Mon, 23 Oct 2017 14:30:04 +0200 Subject: [CMake] How to include Portaudio to my project? Message-ID: also posted on SO: https://stackoverflow.com/questions/46886033/paerror-not-a-class-or-namespace I seem to have some problems including portaudio to my project, I guess my error is caused be me not including portaudio accurately to my project. My project source tree looks like this audio$ tree . ??? audio.cbp ??? CMakeCache.txt ??? CMakeFiles ? ??? 3.2.2 ? ? ??? CMakeCCompiler.cmake ? ? ??? CMakeCXXCompiler.cmake ? ? ??? CMakeDetermineCompilerABI_C.bin ? ? ??? CMakeDetermineCompilerABI_CXX.bin ? ? ??? CMakeSystem.cmake ? ? ??? CompilerIdC ? ? ? ??? a.out ? ? ? ??? CMakeCCompilerId.c ? ? ??? CompilerIdCXX ? ? ??? a.out ? ? ??? CMakeCXXCompilerId.cpp ? ??? audio.dir ? ? ??? build.make ? ? ??? cmake_clean.cmake ? ? ??? CXX.includecache ? ? ??? DependInfo.cmake ? ? ??? depend.internal ? ? ??? depend.make ? ? ??? flags.make ? ? ??? link.txt ? ? ??? progress.make ? ??? cmake.check_cache ? ??? CMakeDirectoryInformation.cmake ? ??? CMakeOutput.log ? ??? CMakeTmp ? ??? feature_tests.bin ? ??? feature_tests.c ? ??? feature_tests.cxx ? ??? Makefile2 ? ??? Makefile.cmake ? ??? progress.marks ? ??? TargetDirectories.txt ??? cmake_install.cmake ??? CMakeLists.txt ??? CMakeLists.txt.user ??? database.cpp ??? database.h ??? main.cpp ??? Makefile ??? match.cpp ??? match.h ??? portaudio ? ??? libportaudio.a ? ??? portaudio.h ??? record.cpp ??? record.h ??? spectogram.cpp ??? spectogram.h 7 directories, 45 files In which I have, as suggested by the portaudio guide, copy pasted the libportaudio.a and portaudio.h into my project folder. My cmakelist looks like this project(audio) cmake_minimum_required(VERSION 2.8) aux_source_directory(. SRC_LIST) add_executable(${PROJECT_NAME} ${SRC_LIST}) So it should include all the files.. but defining a function as such void record::example() { std::cout << "In example!" << std::endl; std::cout << Pa_GetVersion() << std::endl; } Is not possible.. , I get an compile error stating that undefined reference to Pa_GetVersion().. As if it doesn?t know the existence of this. How do i fix that? -------------- next part -------------- An HTML attachment was scrubbed... URL: From mwpowellhtx at gmail.com Mon Oct 23 08:35:36 2017 From: mwpowellhtx at gmail.com (Michael Powell) Date: Mon, 23 Oct 2017 08:35:36 -0400 Subject: [CMake] HELP: CMake "cache" stuck after renaming project path In-Reply-To: References: Message-ID: On Mon, Oct 23, 2017 at 8:21 AM, Michael Powell wrote: > HELP! > > As the subject says, I renamed the project folder to a saner location > (for me anyway), which is now causing CMake to complain about its > "cache". Somehow or another it is stuck on the previous path. It is not enough apparently to delete the out of place files. So what I ended up doing was deleting the catch from the UI and reconfiguring. Then all was well. > This in spite of the fact I have CLEARED the out of place "build" > location. The cache does indeed reflect the old path. In spite of the > fact I am telling CMake the correct path where the source code is. > > I am running v3.9.2 on Windows 7. > > Muy frustrated! HELP! > > Cheers, > > Michael Powell From Markus.Liebe at de.bosch.com Mon Oct 23 08:46:58 2017 From: Markus.Liebe at de.bosch.com (Liebe Markus (RtP2/TEF72)) Date: Mon, 23 Oct 2017 12:46:58 +0000 Subject: [CMake] cmake 3.5.2: automoc ignores headers with the suffix .H (upper case h) Message-ID: <9cbf230c855143d3a64434dca20dde34@de.bosch.com> Hello, using cmake version 3.5.2 on Linux I have observed, that automoc does not process header files if they have the suffix ".H" (uppercase h) At the moment I am porting our code base from qmake to cmake. Our quite large code base uses the .H suffix in tons of places instead of .h for cpp header files. At the moment I am forced to rename all headers that need to be processed using automoc to use a .h suffix. Is this a known issue? (Perhaps already adressed in later cmake releases?) Is there a way to tell cmake that it should treat the .H suffix as if it were .h? Mit freundlichen Gr??en / Best regards Markus Liebe Robert Bosch GmbH Automotive Electronics, Software Development (RtP2/TEF72) Postfach 13 42 72703 Reutlingen GERMANY www.bosch.com Tel. +49(7121)35-35246 Fax +49(711)811-51435246 markus.liebe at de.bosch.com Sitz: Stuttgart, Registergericht: Amtsgericht Stuttgart, HRB 14000; Aufsichtsratsvorsitzender: Franz Fehrenbach; Gesch?ftsf?hrung: Dr. Volkmar Denner, Dr. Stefan Asenkerschbaumer, Dr. Rolf Bulander, Dr. Stefan Hartung, Dr. Dirk Hoheisel, Christoph K?bel, Uwe Raschke, Wolf-Henning Scheider, Dr. Werner Struth, Peter Tyroller -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric.noulard at gmail.com Tue Oct 24 03:33:44 2017 From: eric.noulard at gmail.com (Eric Noulard) Date: Tue, 24 Oct 2017 09:33:44 +0200 Subject: [CMake] Creating two distinct packages w/ CPack from a single project In-Reply-To: <20171016214504.GA17257@release-approaches.com> References: <20171016214504.GA17257@release-approaches.com> Message-ID: Le 16 oct. 2017 23:54, "J. Paul Reed" a ?crit : Hey all, I have a (potentially?) odd situation: I need to generate multiple packages using CPack from the same CMake project. I'm aware of the component-based installers and methodology, but I don't believe that's what I want here: I want entirely different package names/versions/etc., containing different artifacts created from a single CMake project. I have currently implemented this by setting the various CPack configuration variables, and then include()ing CPack in different directories. I then have custom targets that call cpack with --config, pointed to a non-default-named CPack configuration file. This seems to work just fine, except during the cmake configuration run, we get warnings about CPack.cmake having already been included. I see where this message() gets emitted (https://gitlab.kitware.com/cmake/cmake/blob/master/ Modules/CPack.cmake#L298-302); perusing that file, it seems to do things I basically want/need (setting various defaults, etc.) if I want to use cpack with a different config file. Hi there, As you already discovered I was the author of this warning some years ago when I was actively working on CPack. The reason for this was to make it clear that even include(CPack) may look (and somehow behave) like a function call creating a CPack config set of files. It is not. It wasn't designed for that usage and it may generate weird content on a second (or more) inclusion. Some people were occasionally bitten by that. e.g. since it inspects variable (in the current scope which was initially global) beginning with CPACK_ prefix for doing its work, when you use it twice it does not ensure or cleanup variables that may be there due to the first inclusion. This would be up to the user to clean leftover before successive inclusion. To summarize, this is a pure macro processing, not a function call. It would be nice to have a cpack_xxx function which safely implements the behaviour you seek. That was on my wishlist some time but I never get the time to implement it. (There may be some old mantis bug report for that wish, I'll dig into it and come back here if I find something interesting). I can suppress the warning by unsetting CPack_CMake_INCLUDED, which is what I'm planning to do... but I wanted to ask: a) whether there are any technical problems or concerns by subverting that warning message and including CPack.cmake multiple times, and You can now that you know the story. If I would have to do that I would: 1. Delete **all** CPACK_ variable from current scope 2. Unset CPack_CMake_INCLUDED 3. setup the new CPACK_xxx value set 4. include(CPack) b) if there's another solution entirely that is better suited. (Again, I'm aware of component based installs; I don't think they'll do what I want here.) Yep, contribute a "real" CMake function that do the right job. Ideally this function should replace current include(CPack) usage. CPack.cmake should be kept for backward compatibility legacy reason but it's content should be replaced by the appropriate new function call. thanks, preed -- J. Paul Reed -- 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 edo.paskino at gmail.com Tue Oct 24 05:15:55 2017 From: edo.paskino at gmail.com (Edoardo Pasca) Date: Tue, 24 Oct 2017 10:15:55 +0100 Subject: [CMake] string MATCHALL Message-ID: Dear all, I'm trying to determine the active conda environment (name and path) at cmake runtime. To do that I issue the command conda env list, which yields lines with the active environment highlighted with an asterisk: something similar to this: env1 /path/to/env1 env2 / path/to/env2 env3 * /path/to/env3 It is a perfect task for a match of REGEX but I cannot get it right and I defaulted to using brute force to achieve my goal. My brute force method is 1) splitting the lines by replacing \n with ; 2) now that I have a LIST (or I think that is a list) I can run a foreach to see if line-by-line I match the following string(REGEX MATCHALL "(.+)[*](.+)" match ${line}) Now, I'd expect to find in ${match} a list with the captured strings, i.e. env3;/path/to/env3. However that's not the case ${match} contains the whole line. So now I REPLACE "*" with ";" and now I have a almost LIST. Actually I do this: string(REPLACE "*" ";" ENV_DIR ${match}) list (APPEND cc "") foreach(conda ${ENV_DIR}) string(STRIP ${conda} stripped) list(APPEND cc ${stripped}) endforeach() Finally I've got my list ${cc} with the name and path of the environment as first and second element. The question is, how would I use MATCHALL to achieve my goal (if possible)? for the record I attach here the whole script. Thanks for your help Edo execute_process(COMMAND "conda" "env" "list" OUTPUT_VARIABLE _CONDA_ENVS RESULT_VARIABLE _CONDA_RESULT ERROR_VARIABLE _CONDA_ERR) if(NOT _CONDA_RESULT) string(REPLACE "\n" ";" ENV_LIST ${_CONDA_ENVS}) foreach(line ${ENV_LIST}) string(REGEX MATCHALL "(.+)[*](.+)" match ${line}) if (NOT ${match} EQUAL "") string(REPLACE "*" ";" ENV_DIR ${match}) list (APPEND cc "") foreach(conda ${ENV_DIR}) string(STRIP ${conda} stripped) list(APPEND cc ${stripped}) endforeach() list(LENGTH cc Ns) if (${Ns} EQUAL 2) list(GET cc 0 CONDA_ENVIRONMENT) list(GET cc 1 CONDA_ENVIRONMENT_PATH) endif() endif() endforeach() else() message(FATAL_ERROR "ERROR with conda command " ${_CONDA_ERR}) endif() -- Edo I know you think you understand what you thought I said, but I'm not sure you realize that what you heard is not what I meant (prob. Alan Greenspan) :wq -------------- next part -------------- An HTML attachment was scrubbed... URL: From hborcher at illinois.edu Tue Oct 24 13:19:18 2017 From: hborcher at illinois.edu (Borchers, Henry Samuel) Date: Tue, 24 Oct 2017 17:19:18 +0000 Subject: [CMake] Passing properties between External Projects Message-ID: <8C52DF5253CC3C409DD300B13F8DF1F010B2FFB4@CITESMBX4.ad.uillinois.edu> Is there an easier way to pass properties from one ExternalProject_Add command to another? The only way I've got it to work is.. 1) Use the command "ExternalProject_Add(myExternalDependencyA ...)" 2) Use "add_library(imported_myExternalDependencyA STATIC IMPORTED)" 3) Get "ExternalProject_Get_Property(myExternalDependencyA install_dir)" 4) Use "set_target_properties(imported_myExternalDependencyA INCLUDE_DIRECTORIES ${install_dir}/include" and any other properties etc.. 5) Use the command "ExternalProject_Add(myExternalDependencyB ... CMAKE_ARGS -DMY_EXTERNAL_DEPENDENCY_A_INCLUDE= $)" It seems to work but it also seems excessive. Is there a better way that doesn't require using an imported library? $ doesn't seem to work with ExternalProjects. Henry Borchers Digital Library Technical Coordinator 1408 W Gregory Dr, Room 413 Urbana, IL 61801 (217) 244-2110 -------------- next part -------------- An HTML attachment was scrubbed... URL: From gjasny at googlemail.com Tue Oct 24 16:52:43 2017 From: gjasny at googlemail.com (Gregor Jasny) Date: Tue, 24 Oct 2017 22:52:43 +0200 Subject: [CMake] string MATCHALL In-Reply-To: References: Message-ID: In case it helps: the GUI can contains a regex explorer where you can play with rexexes. But beware: there are some corner cases around quoting special things. I'd suggest to use if( ... MATCHES ...) And read the match from the CMAKE_MATCH_ variables. On Oct 24, 2017 11:16, "Edoardo Pasca" wrote: Dear all, I'm trying to determine the active conda environment (name and path) at cmake runtime. To do that I issue the command conda env list, which yields lines with the active environment highlighted with an asterisk: something similar to this: env1 /path/to/env1 env2 / path/to/env2 env3 * /path/to/env3 It is a perfect task for a match of REGEX but I cannot get it right and I defaulted to using brute force to achieve my goal. My brute force method is 1) splitting the lines by replacing \n with ; 2) now that I have a LIST (or I think that is a list) I can run a foreach to see if line-by-line I match the following string(REGEX MATCHALL "(.+)[*](.+)" match ${line}) Now, I'd expect to find in ${match} a list with the captured strings, i.e. env3;/path/to/env3. However that's not the case ${match} contains the whole line. So now I REPLACE "*" with ";" and now I have a almost LIST. Actually I do this: string(REPLACE "*" ";" ENV_DIR ${match}) list (APPEND cc "") foreach(conda ${ENV_DIR}) string(STRIP ${conda} stripped) list(APPEND cc ${stripped}) endforeach() Finally I've got my list ${cc} with the name and path of the environment as first and second element. The question is, how would I use MATCHALL to achieve my goal (if possible)? for the record I attach here the whole script. Thanks for your help Edo execute_process(COMMAND "conda" "env" "list" OUTPUT_VARIABLE _CONDA_ENVS RESULT_VARIABLE _CONDA_RESULT ERROR_VARIABLE _CONDA_ERR) if(NOT _CONDA_RESULT) string(REPLACE "\n" ";" ENV_LIST ${_CONDA_ENVS}) foreach(line ${ENV_LIST}) string(REGEX MATCHALL "(.+)[*](.+)" match ${line}) if (NOT ${match} EQUAL "") string(REPLACE "*" ";" ENV_DIR ${match}) list (APPEND cc "") foreach(conda ${ENV_DIR}) string(STRIP ${conda} stripped) list(APPEND cc ${stripped}) endforeach() list(LENGTH cc Ns) if (${Ns} EQUAL 2) list(GET cc 0 CONDA_ENVIRONMENT) list(GET cc 1 CONDA_ENVIRONMENT_PATH) endif() endif() endforeach() else() message(FATAL_ERROR "ERROR with conda command " ${_CONDA_ERR}) endif() -- Edo I know you think you understand what you thought I said, but I'm not sure you realize that what you heard is not what I meant (prob. Alan Greenspan) :wq -- 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 smeenai at fb.com Tue Oct 24 18:37:01 2017 From: smeenai at fb.com (Shoaib Meenai) Date: Tue, 24 Oct 2017 22:37:01 +0000 Subject: [CMake] Resource compiler issues for cross-compiling Message-ID: Hi all, I'm cross-compiling from Linux to Windows using clang-cl and the Windows SDK (i.e. emulating an MSVC environment), and I'm attempting to use llvm-rc (which is new in LLVM 6.0) as the resource compiler. cmake automatically enables the RC language for MSVC. However, it also sets `CMAKE_NINJA_CMCLDEPS_RC` to 1, which causes the ninja generator to require cmcldeps, but that program is only built on Windows. I've only looked at cmcldeps briefly, but it seems to have a bunch of Windows- specific code, and I'm not sure how easy it would be to build it for other platforms. I'm also not really sure what cmcldeps does or how necessary it is for a cross-compilation scenario, however. In particular, the RC files I'm attempting to compile are quite simple and don't contain any `#include`s. Unfortunately, I don't see how to get around the cmcldeps requirement, since the Windows-MSVC platform sets CMAKE_NINJA_CMCLDEPS_RC unconditionally. I've worked around it temporarily by disabling resource file usage on non-Windows build hosts, but I'd like to be able to use llvm-rc eventually. What's the best path forward here? Thanks, Shoaib From irwin at beluga.phys.uvic.ca Wed Oct 25 04:10:25 2017 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Wed, 25 Oct 2017 01:10:25 -0700 (PDT) Subject: [CMake] How to find dll's on Cygwin? Message-ID: What CMake logic should be used to find the Cygwin dll /usr/bin/cyggnat-6.dll ? I don't have access to Cygwin myself, but my PLplot colleague, Arjen Markus who does have such access has reported to me off-list that find_library(GNAT_LIB NAMES gnat gnat-${GNAT_VERSION} gnat-${GNAT_MAJOR_VERSION} cyggnat-${GNAT_MAJOR_VERSION}) does not find /usr/bin/cyggnat-6.dll when GNAT_MAJOR_VERSION is 6. Note that find was a failure even when he included /usr/bin in CMAKE_LIBRARY_PATH . To find dll's this way (rather than import libraries) do I have to use find_file instead, e.g., # Take care of non-Cygwin cases: find_library(GNAT_LIB NAMES gnat gnat-${GNAT_VERSION} gnat-${GNAT_MAJOR_VERSION}) # Take care of Cygwin case. (Note /usr/bin does not have to be added to # CMAKE_LIBRARY_PATH for this case.) find_file(GNAT_LIB NAMES cyggnat-${GNAT_MAJOR_VERSION}.dll) ? Or is there some slick way to accommodate both non-Cygwin and Cygwin platforms with one call to find_library? 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 eric.noulard at gmail.com Wed Oct 25 05:34:16 2017 From: eric.noulard at gmail.com (Eric Noulard) Date: Wed, 25 Oct 2017 11:34:16 +0200 Subject: [CMake] Creating two distinct packages w/ CPack from a single project In-Reply-To: References: <20171016214504.GA17257@release-approaches.com> Message-ID: 2017-10-24 9:33 GMT+02:00 Eric Noulard : > > > Le 16 oct. 2017 23:54, "J. Paul Reed" a > ?crit : > > > Hey all, > > I have a (potentially?) odd situation: I need to generate multiple packages > using CPack from the same CMake project. > > [...] > > I see where this message() gets emitted > (https://gitlab.kitware.com/cmake/cmake/blob/master/Modules/ > CPack.cmake#L298-302); > perusing that file, it seems to do things I basically want/need (setting > various defaults, etc.) if I want to use cpack with a different config > file. > > > Hi there, > As you already discovered I was the author of this warning some years ago > when I was actively working on CPack. The reason for this was to make it > clear that even include(CPack) may look (and somehow behave) like a > function call creating a CPack config set of files. It is not. It wasn't > designed for that usage and it may generate weird content on a second (or > more) inclusion. > Some people were occasionally bitten by that. > e.g. since it inspects variable (in the current scope which was initially > global) beginning with CPACK_ prefix for doing its work, when you use it > twice it does not ensure or cleanup variables that may be there due to the > first inclusion. This would be up to the user to clean leftover before > successive inclusion. > > To summarize, this is a pure macro processing, not a function call. > > It would be nice to have a cpack_xxx function which safely implements the > behaviour you seek. That was on my wishlist some time but I never get the > time to implement it. (There may be some old mantis bug report for that > wish, I'll dig into it and come back here if I find something interesting). > After some digging I found that the issue on gitlab is this one, https://gitlab.kitware.com/cmake/cmake/issues/1075. It refers to the original Mantis issue years ago. I guess that the feature (multiple CPack calls) may be useful to some CPack users. I have no time to work on this but I put the ref here in order to make the reference accessible. -- Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From noflaco at gmail.com Wed Oct 25 05:36:17 2017 From: noflaco at gmail.com (Carlton Banks) Date: Wed, 25 Oct 2017 11:36:17 +0200 Subject: [CMake] About structuring cmake for big project? Message-ID: Is there some literature that desbribes how cmakelist has to be defined a big system, that involve multiple smaller modules within the big module. From edo.paskino at gmail.com Wed Oct 25 05:54:51 2017 From: edo.paskino at gmail.com (Edoardo Pasca) Date: Wed, 25 Oct 2017 10:54:51 +0100 Subject: [CMake] string MATCHALL In-Reply-To: References: Message-ID: Gregor big thanks! I had not understood that the matched string are stored in CMAKE_MATCH_ variables with: n=0 for the whole string n=1 the first match n=2 the second match etc My script has now simplified consistently string(REGEX MATCHALL "(.+)[*](.+)" match ${line}) if (NOT ${match} EQUAL "") string(STRIP ${CMAKE_MATCH_1} CONDA_ENVIRONMENT) string(STRIP ${CMAKE_MATCH_2} CONDA_ENVIRONMENT_PATH) endif() Thanks again Edo On Tue, Oct 24, 2017 at 9:52 PM, Gregor Jasny wrote: > In case it helps: the GUI can contains a regex explorer where you can play > with rexexes. But beware: there are some corner cases around quoting > special things. > > I'd suggest to use if( ... MATCHES ...) And read the match from > the CMAKE_MATCH_ variables. > > > On Oct 24, 2017 11:16, "Edoardo Pasca" wrote: > > Dear all, > > I'm trying to determine the active conda environment (name and path) at > cmake runtime. > > To do that I issue the command > conda env list, which yields lines with the active environment highlighted > with an asterisk: something similar to this: > > env1 /path/to/env1 > env2 / path/to/env2 > env3 * /path/to/env3 > > It is a perfect task for a match of REGEX but I cannot get it right and I > defaulted to using brute force to achieve my goal. > > My brute force method is > 1) splitting the lines by replacing \n with ; > 2) now that I have a LIST (or I think that is a list) I can run a foreach > to see if line-by-line I match the following string(REGEX MATCHALL > "(.+)[*](.+)" match ${line}) > > Now, I'd expect to find in ${match} a list with the captured strings, i.e. > env3;/path/to/env3. However that's not the case ${match} contains the whole > line. So now I REPLACE "*" with ";" and now I have a almost LIST. Actually > I do this: > > string(REPLACE "*" ";" ENV_DIR ${match}) > list (APPEND cc "") > foreach(conda ${ENV_DIR}) > string(STRIP ${conda} stripped) > list(APPEND cc ${stripped}) > endforeach() > > Finally I've got my list ${cc} with the name and path of the environment > as first and second element. > > The question is, how would I use MATCHALL to achieve my goal (if possible)? > > for the record I attach here the whole script. > > Thanks for your help > > Edo > > > execute_process(COMMAND "conda" "env" "list" > OUTPUT_VARIABLE _CONDA_ENVS > RESULT_VARIABLE _CONDA_RESULT > ERROR_VARIABLE _CONDA_ERR) > if(NOT _CONDA_RESULT) > string(REPLACE "\n" ";" ENV_LIST ${_CONDA_ENVS}) > foreach(line ${ENV_LIST}) > string(REGEX MATCHALL "(.+)[*](.+)" match ${line}) > if (NOT ${match} EQUAL "") > string(REPLACE "*" ";" ENV_DIR ${match}) > list (APPEND cc "") > foreach(conda ${ENV_DIR}) > string(STRIP ${conda} stripped) > list(APPEND cc ${stripped}) > endforeach() > list(LENGTH cc Ns) > if (${Ns} EQUAL 2) > list(GET cc 0 CONDA_ENVIRONMENT) > list(GET cc 1 CONDA_ENVIRONMENT_PATH) > endif() > endif() > endforeach() > else() > message(FATAL_ERROR "ERROR with conda command " ${_CONDA_ERR}) > endif() > > > -- > Edo > I know you think you understand what you thought I said, but I'm not sure > you realize that what you heard is not what I meant (prob. Alan Greenspan) > :wq > > -- > > 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 > > > -- Edo I know you think you understand what you thought I said, but I'm not sure you realize that what you heard is not what I meant (prob. Alan Greenspan) :wq -------------- next part -------------- An HTML attachment was scrubbed... URL: From sergey.nikulov at gmail.com Wed Oct 25 06:35:49 2017 From: sergey.nikulov at gmail.com (Sergei Nikulov) Date: Wed, 25 Oct 2017 13:35:49 +0300 Subject: [CMake] About structuring cmake for big project? In-Reply-To: References: Message-ID: 2017-10-25 12:36 GMT+03:00 Carlton Banks : > Is there some literature that desbribes how cmakelist has to be defined a big system, that involve multiple smaller modules within the big module. > IMHO, this is not CMake specific question. There is no single recipe which fits all your needs. You'll be able to describe any big system in CMake, but project code base representation should be based on agreements within your team. -- Best Regards, Sergei Nikulov From d3ck0r at gmail.com Wed Oct 25 07:31:35 2017 From: d3ck0r at gmail.com (J Decker) Date: Wed, 25 Oct 2017 04:31:35 -0700 Subject: [CMake] Silent crash on infinite recursion Message-ID: If a script recursively calls itself (ir indirectly causes a infinite recursion of includes) cmake silently exits, and does not tell why. I finally managed to get cmake --trace-expand --debug-output .. to show some useful information. --debug-output with --build causes cmake to try to run in configure mode instead of building... ----- CMakeLists.txt --------- cmake_minimum_required(VERSION 3.6) include( brokenScript ) -------------------- ----- brokenScript --------- include( brokenScript ) ------------------- (Yes, this shouldn't be done in the first place; but I ended up generating a script over another script of the same name that was expecting originally to be built into a separate directory) having the above two files, and making a build directory and from the build directory doing 'cmake ..' does compiler detection then exits with an error code. Cmake-gui (on windows) trying to do a generate crashes with an exception. -------------- next part -------------- An HTML attachment was scrubbed... URL: From volker.enderlein at ifm-chemnitz.de Wed Oct 25 07:22:59 2017 From: volker.enderlein at ifm-chemnitz.de (Volker Enderlein) Date: Wed, 25 Oct 2017 13:22:59 +0200 Subject: [CMake] About structuring cmake for big project? In-Reply-To: References: Message-ID: <620828ab-9990-4bb1-a870-b41d909570c0@ifm-chemnitz.de> Am 25/10/2017 um 11:36 schrieb Carlton Banks: > Is there some literature that desbribes how cmakelist has to be defined a big system, that involve multiple smaller modules within the big module. > > It depends, but maybe Mathieu Roperts presentation from CPPCON 2017 gives you some insights. https://www.youtube.com/watch?v=eC9-iRN2b04 Cheers Volker From ndevenish at gmail.com Wed Oct 25 07:53:24 2017 From: ndevenish at gmail.com (Nicholas Devenish) Date: Wed, 25 Oct 2017 12:53:24 +0100 Subject: [CMake] About structuring cmake for big project? In-Reply-To: References: Message-ID: On Wed, Oct 25, 2017 at 10:36 AM, Carlton Banks wrote: > Is there some literature that desbribes how cmakelist has to be defined a > big system, that involve multiple smaller modules within the big module. Unfortunately, written documentation of structuring larger projects with CMake seems to be as rare and hard to find as documentation on CMake "Best practices". I suspect that the individual uniqueness of each large project combined with "once it is working don't touch it" means that developers settle on something that "works" rather than something they are happy with, and so don't show it off. If you have anything beyond a fixed repository of code with simple dependencies then you seem to be pretty much on your own. As a start, I'd suggest looking for other large projects that transitioned to using CMake - I've found LLVM useful in particular as a large but tightly-bound set of modular, but optional components. KDE is using CMake, but I've yet to find a good place to start digging - the ecosystem is so intimidatingly large that I'm not sure their solutions are applicable to anyone else except them. Hopefully Boost will move to CMake (as is currently proposed) and give another well known library example. Nick -------------- next part -------------- An HTML attachment was scrubbed... URL: From noflaco at gmail.com Wed Oct 25 07:59:39 2017 From: noflaco at gmail.com (Carlton Banks) Date: Wed, 25 Oct 2017 13:59:39 +0200 Subject: [CMake] About structuring cmake for big project? In-Reply-To: References: Message-ID: <6BE8721E-A5C6-40CE-9007-76CFA3339F85@gmail.com> I am currently entering the stages of building a bigger project, at which multiple submodules has to be involved. I am a noob when it comes to cmake, and never worked with it in a big project scale. My idea was to make each submodule buildable, such that they could be tested independently (testing each submodule )and all together (In the top module)? The idea seem simple, and the project on which i am currently testing it on is not that big (each module = class). So I don?t understand why there isn?t a easy guide or some form documentation clarifying the use of cmake of module cmake? > Den 25. okt. 2017 kl. 13.53 skrev Nicholas Devenish : > > On Wed, Oct 25, 2017 at 10:36 AM, Carlton Banks > wrote: > Is there some literature that desbribes how cmakelist has to be defined a big system, that involve multiple smaller modules within the big module. > > Unfortunately, written documentation of structuring larger projects with CMake seems to be as rare and hard to find as documentation on CMake "Best practices". I suspect that the individual uniqueness of each large project combined with "once it is working don't touch it" means that developers settle on something that "works" rather than something they are happy with, and so don't show it off. > > If you have anything beyond a fixed repository of code with simple dependencies then you seem to be pretty much on your own. > > As a start, I'd suggest looking for other large projects that transitioned to using CMake - I've found LLVM useful in particular as a large but tightly-bound set of modular, but optional components. KDE is using CMake, but I've yet to find a good place to start digging - the ecosystem is so intimidatingly large that I'm not sure their solutions are applicable to anyone else except them. Hopefully Boost will move to CMake (as is currently proposed) and give another well known library example. > > Nick -------------- next part -------------- An HTML attachment was scrubbed... URL: From boud at valdyas.org Wed Oct 25 08:19:30 2017 From: boud at valdyas.org (Boudewijn Rempt) Date: Wed, 25 Oct 2017 14:19:30 +0200 (CEST) Subject: [CMake] About structuring cmake for big project? In-Reply-To: References: Message-ID: On Wed, 25 Oct 2017, Nicholas Devenish wrote: > As a start, I'd suggest looking for other large projects that transitioned > to using CMake - I've found LLVM useful in particular as a large but > tightly-bound set of modular, but optional components. KDE is using CMake, > but I've yet to find a good place to start digging - the ecosystem is so > intimidatingly large that I'm not sure their solutions are applicable to > anyone else except them. Hopefully Boost will move to CMake (as is > currently proposed) and give another well known library example. Well, there's a lot in the KDE community, but when starting out with cmake for a large project, it really might help to take a look at extra-cmake-modules first (https://api.kde.org/ecm/) because it contains a lot of useful stuff, and then at just one large KDE project, like my own, Krita. Krita actually contains two cmake systems: one to build Krita (which consists of several executables, a bunch of libraries and a host of plugins), and one to download and build all dependencies using cmake external projects. I'm sure it can and should be improved and modernized, but it's at least an example :-) -- Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org From pfultz2 at yahoo.com Wed Oct 25 18:40:22 2017 From: pfultz2 at yahoo.com (paul) Date: Wed, 25 Oct 2017 17:40:22 -0500 Subject: [CMake] About structuring cmake for big project? In-Reply-To: References: Message-ID: <1508971222.4001.11.camel@yahoo.com> Daniel Pfeifer's Effective CMake talk is a really great resource: https://www.youtube.com/watch?v=bsXLMQ6WgIk There is also this wiki that goes over best practices and guidelines based on two of Daniel's cmake talks: https://github.com/boost-cmake/bcm/wiki/Cmake-best-practices-and-guidelines Also, this goes over the structure that boost is planning on using with cmake: http://bcm.readthedocs.io/en/latest/src/Building.html Although it leans towards using its own set of modules called BCM, it does explain the structure without using BCM as well. On Wed, 2017-10-25 at 11:36 +0200, Carlton Banks wrote: > Is there some literature that desbribes how cmakelist has to be defined a > big system, that involve multiple smaller modules within the big module.? > > From boxerab at gmail.com Thu Oct 26 10:51:23 2017 From: boxerab at gmail.com (Aaron Boxer) Date: Thu, 26 Oct 2017 10:51:23 -0400 Subject: [CMake] Setting different compiler for certain files Message-ID: I am working on a project where most files can use standard gcc compiler, but a few need to use a different one. How can I specify that these files should be compiled with this other compiler ? Thanks. Aaron -------------- next part -------------- An HTML attachment was scrubbed... URL: From irwin at beluga.phys.uvic.ca Fri Oct 27 03:32:42 2017 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Fri, 27 Oct 2017 00:32:42 -0700 (PDT) Subject: [CMake] How to find dll's on Cygwin? (fwd) Message-ID: I am pretty sure there are a non-zero number of CMake users here who have had CMake experience finding dll's on Cygwin (since it appears from the quote below that import libraries can be replaced by dll's for the purposes of linking on that platform). So if you are one with such experience, I would really appreciate an answer to (or commment on) the specific question below concerning finding cyggnat-6.dll on Cygwin or if you prefer to frame your response to the more general question of finding dll's on that platform, that would be great as well. 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 __________________________ ---------- Forwarded message ---------- Date: Wed, 25 Oct 2017 01:10:25 -0700 (PDT) From: Alan W. Irwin To: cmake at cmake.org Subject: [CMake] How to find dll's on Cygwin? What CMake logic should be used to find the Cygwin dll /usr/bin/cyggnat-6.dll ? I don't have access to Cygwin myself, but my PLplot colleague, Arjen Markus who does have such access has reported to me off-list that find_library(GNAT_LIB NAMES gnat gnat-${GNAT_VERSION} gnat-${GNAT_MAJOR_VERSION} cyggnat-${GNAT_MAJOR_VERSION}) does not find /usr/bin/cyggnat-6.dll [for the case tested where ${GNAT_MAJOR_VERSION} was confirmed to be 6]. Note that find was a failure even when he included /usr/bin in CMAKE_LIBRARY_PATH . To find dll's this way (rather than import libraries) do I have to use find_file instead, e.g., # Take care of non-Cygwin cases: find_library(GNAT_LIB NAMES gnat gnat-${GNAT_VERSION} gnat-${GNAT_MAJOR_VERSION}) # Take care of Cygwin case. (Note /usr/bin does not have to be added to # CMAKE_LIBRARY_PATH for this case.) find_file(GNAT_LIB NAMES cyggnat-${GNAT_MAJOR_VERSION}.dll) ? Or is there some slick way to accommodate both non-Cygwin and Cygwin platforms with one call to find_library? 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 wesley.hoke at gmail.com Fri Oct 27 15:22:17 2017 From: wesley.hoke at gmail.com (Wesley Smith) Date: Fri, 27 Oct 2017 12:22:17 -0700 Subject: [CMake] Boost's CMAKE approach and the BUILD_INTERFACE generator expression Message-ID: Boost's CMAKE page (http://bcm.readthedocs.io/en/latest/src/Building.html) says: So this will build the library named boost_filesystem, however, we need to supply the dependencies to boost_filesystem and add the include directories. To add the include directory we use target_include_directories. For this, we tell cmake to use local include directory, but since this is only valid during build and not after installation, we use the BUILD_INTERFACE generator expression so that cmake will only use it during build and not installation: target_include_directories(boost_filesystem PUBLIC $ ) Is is necessary to use a BUILD_INTERFACE here? Couldn't you use PUBLIC/PRIVATE/INTERFACE to achieve the same effect? What are the use cases over for BUILD_INTERFACE that setting include dirs as PUBLIC/PRIVATE/INTERFACE doesn't cover? thanks, wes -------------- next part -------------- An HTML attachment was scrubbed... URL: From marco.atzeri at gmail.com Fri Oct 27 16:31:35 2017 From: marco.atzeri at gmail.com (Marco Atzeri) Date: Fri, 27 Oct 2017 22:31:35 +0200 Subject: [CMake] How to find dll's on Cygwin? (fwd) In-Reply-To: References: Message-ID: <579c4959-c483-a747-2454-613711b1e03c@gmail.com> On 27/10/2017 09:32, Alan W. Irwin wrote: > I am pretty sure there are a non-zero number of CMake users here who > have had CMake experience finding dll's on Cygwin (since it appears > from the quote below that import libraries can be replaced by dll's > for the purposes of linking on that platform).? So if you are one with > such experience, I would really appreciate an answer to (or commment > on) the specific question below concerning finding cyggnat-6.dll on > Cygwin or if you prefer to frame your response to the more general > question of finding dll's on that platform, that would be great as > well. > > Alan using the import library is the standard way for linking, looking for the shared library is surely unusual. I am not a user of ADA, but the import libraries seems the one on /usr/lib/gcc/x86_64-pc-cygwin/6.4.0/adalib/ Marco From pfultz2 at yahoo.com Fri Oct 27 19:16:07 2017 From: pfultz2 at yahoo.com (paul) Date: Fri, 27 Oct 2017 18:16:07 -0500 Subject: [CMake] Boost's CMAKE approach and the BUILD_INTERFACE generator expression In-Reply-To: References: Message-ID: <1509146167.4001.60.camel@yahoo.com> On Fri, 2017-10-27 at 12:22 -0700, Wesley Smith wrote: > Boost's CMAKE page (http://bcm.readthedocs.io/en/latest/src/Building.html)? > says: > > So this will build the library named boost_filesystem, however, we need to > supply the dependencies to boost_filesystem and add the include directories. > To add the include directory we use target_include_directories. For this, we > tell cmake to use local include directory, but since this is only valid > during build and not after installation, we use the BUILD_INTERFACE > generator expression so that cmake will only use it during build and not > installation: > > target_include_directories(boost_filesystem PUBLIC > ? ? $ > ) > > > Is is necessary to use a BUILD_INTERFACE here?? Couldn't you use > PUBLIC/PRIVATE/INTERFACE to achieve the same effect?? What are the use cases > over for BUILD_INTERFACE that setting include dirs as > PUBLIC/PRIVATE/INTERFACE doesn't cover? You don't need `BUILD_INTERFACE` if it is set to `PRIVATE`, as none of the downstream users will use the include. However, when using `PUBLIC` or `INTERFACE` you will need `BUILD_INTERFACE`, and in the example above it using `PUBLIC`. This is because there are two types of consumers using the target. One is a target within the build. This will use the include directory from the source(or build) directory. The `BUILD_INTERFACE` ensures that this is only used for this type of consumer. The other type of consumer is the what is used after installation. In this case the include directory is different and most likely points to the directory in installation directory like `${CMAKE_INSTALL_PREFIX}/include`. The `INSTALL_INTERFACE` ensures that this is only used for this type of consumer. So for this case, you setup the includes something like this: target_include_directories(boost_filesystem PUBLIC ????$ ? ? $ ) This will ensure that each type of consumer get the correct include directory. Ultimately, you don't want the user to add an include to a local source directory, as this could have surprising side effect. Fortunately, cmake ensures that this won't happen either, by producing an error if the installations include paths that point to directories in the source or build directory. At the same token, you also don't want the build to point to the installation include as well as this may include headers you don't want to use. Finally, in the example above it didn't use the `INSTALL_PREFIX`. This is because the install sets it correctly when using the `INCLUDES DESTINATION` statement: install(TARGETS boost_filesystem EXPORT boost_filesystem-targets ????RUNTIME DESTINATION bin ????LIBRARY DESTINATION lib ????ARCHIVE DESTINATION lib ????INCLUDES DESTINATION include ) Paul From irwin at beluga.phys.uvic.ca Fri Oct 27 23:38:19 2017 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Fri, 27 Oct 2017 20:38:19 -0700 (PDT) Subject: [CMake] How to find dll's on Cygwin? (fwd) In-Reply-To: <579c4959-c483-a747-2454-613711b1e03c@gmail.com> References: <579c4959-c483-a747-2454-613711b1e03c@gmail.com> Message-ID: On 2017-10-27 22:31+0200 Marco Atzeri wrote: > On 27/10/2017 09:32, Alan W. Irwin wrote: >> I am pretty sure there are a non-zero number of CMake users here who >> have had CMake experience finding dll's on Cygwin (since it appears >> from the quote below that import libraries can be replaced by dll's >> for the purposes of linking on that platform).? So if you are one with >> such experience, I would really appreciate an answer to (or commment >> on) the specific question below concerning finding cyggnat-6.dll on >> Cygwin or if you prefer to frame your response to the more general >> question of finding dll's on that platform, that would be great as >> well. >> >> Alan > > using the import library is the standard way for linking, > looking for the shared library is surely unusual. > > I am not a user of ADA, but the import libraries seems > the one on /usr/lib/gcc/x86_64-pc-cygwin/6.4.0/adalib/ Hi Marco: Thanks for your input to the discussion. I believe you are referring to /usr/lib/gcc/x86_64-pc-cygwin/6.4.0/adalib/libgnat.a (at least that appears to be the only library candidate I can come up with by searching for the RE "usr/lib/gcc/x86_64-pc-cygwin/6.4.0/adalib/.*gnat" using the package search engine.) Our understanding is the Cygwin naming convention for the various kinds of libraries would be (in the gnat library case) dll cyggnat-6.dll import library libgnat-6.dll.a static library libgnat.a If you use the above search engine to search for the RE "gnat.*dll" it only finds the above dll and no corresponding import library. We are pretty sure from its name that libgnat.a is just a static library. Anyhow, when we link our test_ada library against libgnat.a that link does appear to work, but afterward when linking Ada executables against our Ada library (which involves a gnatlink step with hidden link to one form of the gnat library but likely also cyggnat-6.dll) we get multiple symbol definition errors. That linking inconsistency does not happen if we link our Ada library against cyggnat-6.dll so it appears that is the library CMake needs to find in this case. Which neatly ( :-) ) leads back to my original question which is what is the best CMake logic to find that dll? 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 anonymous.maarten at gmail.com Sat Oct 28 01:59:06 2017 From: anonymous.maarten at gmail.com (Maarten Anonymous) Date: Sat, 28 Oct 2017 07:59:06 +0200 Subject: [CMake] Problem measuring coverage in CTest scripts Message-ID: Hey, I have a question about using CMake+CTest+CTest scripts for coverage tests. If I manually build the project and run "make ExperimantalCoverage" in a build folder, the coverage succeeds. If I run the coverage from within a CTest script, it fails. Am I forgetting something? A minimum example that exhibits my problem can be found at https://gist.github.com/madebr/07ebd0de59e789cd819643b58db25df9. This works: mkdir build && cd build && cmake .. && make && make test && make ExperimentalCoverage && cd .. This fails: ctest -S test.ctest Source listing: ################### #CMakeLists.txt: ################### cmake_minimum_required(VERSION 3.9) project(cmake_coverage) file(WRITE "${CMAKE_CURRENT_BINARY_DIR}/main.c" "int main() {return 0;}") add_executable(main main.c ) target_compile_options(main PUBLIC "-O0" "-fprofile-arcs" "-ftest-coverage" ) target_link_libraries(main gcov ) include(CTest) enable_testing() add_test(NAME test COMMAND main ) ############## # test.ctest: ############## set(CTEST_SOURCE_DIRECTORY "${CTEST_SCRIPT_DIRECTORY}") set(CTEST_BINARY_DIRECTORY "${CTEST_SCRIPT_DIRECTORY}/build/ctest") ctest_empty_binary_directory("${CTEST_BINARY_DIRECTORY}") set(CTEST_SITE "${CMAKE_SYSTEM_NAME}") set(CTEST_BUILD_NAME "experimental build") set(CTEST_CMAKE_GENERATOR "Ninja") set(CTEST_COVERAGE_COMMAND "gcov") ctest_start("Experimental") ctest_configure() ctest_build() ctest_test() ctest_coverage() ############## # CTestConfig.cmake: ############## set(CTEST_PROJECT_NAME "Simple ctest_coverage project") -------------- next part -------------- An HTML attachment was scrubbed... URL: From post at hendrik-sattler.de Sat Oct 28 02:08:23 2017 From: post at hendrik-sattler.de (Hendrik Sattler) Date: Sat, 28 Oct 2017 08:08:23 +0200 Subject: [CMake] How to find dll's on Cygwin? (fwd) In-Reply-To: References: <579c4959-c483-a747-2454-613711b1e03c@gmail.com> Message-ID: <271AD292-72B6-4941-A880-FE93BA1D7373@hendrik-sattler.de> Hi, looking at the location of the gnat static library, it seems to be a compiler library like libm. You usually do not use find_package on those but directly use -lgnat and the compiler knows how to find it. Requesting static linking will also work then. HS Am 28. Oktober 2017 05:38:19 MESZ schrieb "Alan W. Irwin" : >On 2017-10-27 22:31+0200 Marco Atzeri wrote: > >> On 27/10/2017 09:32, Alan W. Irwin wrote: >>> I am pretty sure there are a non-zero number of CMake users here who >>> have had CMake experience finding dll's on Cygwin (since it appears >>> from the quote below that import libraries can be replaced by dll's >>> for the purposes of linking on that platform).? So if you are one >with >>> such experience, I would really appreciate an answer to (or commment >>> on) the specific question below concerning finding cyggnat-6.dll on >>> Cygwin or if you prefer to frame your response to the more general >>> question of finding dll's on that platform, that would be great as >>> well. >>> >>> Alan >> >> using the import library is the standard way for linking, >> looking for the shared library is surely unusual. >> >> I am not a user of ADA, but the import libraries seems >> the one on /usr/lib/gcc/x86_64-pc-cygwin/6.4.0/adalib/ > >Hi Marco: > >Thanks for your input to the discussion. > >I believe you are referring to >/usr/lib/gcc/x86_64-pc-cygwin/6.4.0/adalib/libgnat.a > >(at least that appears to be the only library candidate I can come up >with >by searching for the RE > >"usr/lib/gcc/x86_64-pc-cygwin/6.4.0/adalib/.*gnat" > >using the package search >engine.) > >Our understanding is the Cygwin naming convention for the various >kinds of libraries would be (in the gnat library case) > >dll cyggnat-6.dll >import library libgnat-6.dll.a >static library libgnat.a > >If you use the above search engine to search for the RE "gnat.*dll" it >only finds the above dll and no corresponding import library. > >We are pretty sure from its name that libgnat.a is just a static >library. Anyhow, when we link our test_ada library against libgnat.a >that link does appear to work, but afterward when linking Ada >executables against our Ada library (which involves a gnatlink step >with hidden link to one form of the gnat library but likely also >cyggnat-6.dll) we get multiple symbol definition errors. That linking >inconsistency does not happen if we link our Ada library against >cyggnat-6.dll so it appears that is the library CMake needs to find in >this case. > >Which neatly ( :-) ) leads back to my original question which is what >is the >best CMake logic to find that dll? > >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 -- Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet. From edo.paskino at gmail.com Sat Oct 28 02:30:04 2017 From: edo.paskino at gmail.com (Edoardo Pasca) Date: Sat, 28 Oct 2017 07:30:04 +0100 Subject: [CMake] Problem measuring coverage in CTest scripts In-Reply-To: References: Message-ID: Afaik, Ctest should be run in the build directory. From your command it seems you run it in the source. I'm not surprised it doesn't work. Edo On Oct 28, 2017 6:59 AM, "Maarten Anonymous" wrote: > Hey, > > I have a question about using CMake+CTest+CTest scripts for coverage tests. > > If I manually build the project and run "make ExperimantalCoverage" in a > build folder, > the coverage succeeds. > If I run the coverage from within a CTest script, > it fails. > > Am I forgetting something? > > A minimum example that exhibits my problem can be found at > https://gist.github.com/madebr/07ebd0de59e789cd819643b58db25df9. > > This works: > mkdir build && cd build && cmake .. && make && make test && make > ExperimentalCoverage && cd .. > This fails: > ctest -S test.ctest > > Source listing: > ################### > #CMakeLists.txt: > ################### > cmake_minimum_required(VERSION 3.9) > project(cmake_coverage) > > file(WRITE "${CMAKE_CURRENT_BINARY_DIR}/main.c" "int main() {return 0;}") > > add_executable(main > main.c > ) > > target_compile_options(main > PUBLIC > "-O0" > "-fprofile-arcs" > "-ftest-coverage" > ) > > target_link_libraries(main > gcov > ) > > include(CTest) > enable_testing() > > add_test(NAME test > COMMAND main > ) > > ############## > # test.ctest: > ############## > set(CTEST_SOURCE_DIRECTORY "${CTEST_SCRIPT_DIRECTORY}") > set(CTEST_BINARY_DIRECTORY "${CTEST_SCRIPT_DIRECTORY}/build/ctest") > > ctest_empty_binary_directory("${CTEST_BINARY_DIRECTORY}") > > set(CTEST_SITE "${CMAKE_SYSTEM_NAME}") > set(CTEST_BUILD_NAME "experimental build") > > set(CTEST_CMAKE_GENERATOR "Ninja") > set(CTEST_COVERAGE_COMMAND "gcov") > > ctest_start("Experimental") > ctest_configure() > ctest_build() > ctest_test() > ctest_coverage() > > ############## > # CTestConfig.cmake: > ############## > set(CTEST_PROJECT_NAME "Simple ctest_coverage project") > > > > -- > > 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 Sat Oct 28 03:24:36 2017 From: lectem at gmail.com (=?UTF-8?Q?Cl=C3=A9ment_Gregoire?=) Date: Sat, 28 Oct 2017 07:24:36 +0000 Subject: [CMake] Problem measuring coverage in CTest scripts In-Reply-To: References: Message-ID: No since the point of cmake scripts is to build the project (for CI basically). I'm not sure what happens but I remember people having issues when using ninja? I'm not sure. You can have a look at https://github.com/Lectem/cpp-boilerplate I use a Ctest script for my Travis coverage build. The script is the following : https://github.com/Lectem/cpp-boilerplate/blob/master/cmake/CI.CTestScript.cmake Le sam. 28 oct. 2017 ? 08:30, Edoardo Pasca a ?crit : > Afaik, Ctest should be run in the build directory. From your command it > seems you run it in the source. I'm not surprised it doesn't work. > > Edo > > On Oct 28, 2017 6:59 AM, "Maarten Anonymous" > wrote: > >> Hey, >> >> I have a question about using CMake+CTest+CTest scripts for coverage >> tests. >> >> If I manually build the project and run "make ExperimantalCoverage" in a >> build folder, >> the coverage succeeds. >> If I run the coverage from within a CTest script, >> it fails. >> >> Am I forgetting something? >> >> A minimum example that exhibits my problem can be found at >> https://gist.github.com/madebr/07ebd0de59e789cd819643b58db25df9. >> >> This works: >> mkdir build && cd build && cmake .. && make && make test && make >> ExperimentalCoverage && cd .. >> This fails: >> ctest -S test.ctest >> >> Source listing: >> ################### >> #CMakeLists.txt: >> ################### >> cmake_minimum_required(VERSION 3.9) >> project(cmake_coverage) >> >> file(WRITE "${CMAKE_CURRENT_BINARY_DIR}/main.c" "int main() {return 0;}") >> >> add_executable(main >> main.c >> ) >> >> target_compile_options(main >> PUBLIC >> "-O0" >> "-fprofile-arcs" >> "-ftest-coverage" >> ) >> >> target_link_libraries(main >> gcov >> ) >> >> include(CTest) >> enable_testing() >> >> add_test(NAME test >> COMMAND main >> ) >> >> ############## >> # test.ctest: >> ############## >> set(CTEST_SOURCE_DIRECTORY "${CTEST_SCRIPT_DIRECTORY}") >> set(CTEST_BINARY_DIRECTORY "${CTEST_SCRIPT_DIRECTORY}/build/ctest") >> >> ctest_empty_binary_directory("${CTEST_BINARY_DIRECTORY}") >> >> set(CTEST_SITE "${CMAKE_SYSTEM_NAME}") >> set(CTEST_BUILD_NAME "experimental build") >> >> set(CTEST_CMAKE_GENERATOR "Ninja") >> set(CTEST_COVERAGE_COMMAND "gcov") >> >> ctest_start("Experimental") >> ctest_configure() >> ctest_build() >> ctest_test() >> ctest_coverage() >> >> ############## >> # CTestConfig.cmake: >> ############## >> set(CTEST_PROJECT_NAME "Simple ctest_coverage project") >> >> >> >> -- >> >> 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 Sat Oct 28 03:27:49 2017 From: lectem at gmail.com (=?UTF-8?Q?Cl=C3=A9ment_Gregoire?=) Date: Sat, 28 Oct 2017 07:27:49 +0000 Subject: [CMake] How to find dll's on Cygwin? (fwd) In-Reply-To: <271AD292-72B6-4941-A880-FE93BA1D7373@hendrik-sattler.de> References: <579c4959-c483-a747-2454-613711b1e03c@gmail.com> <271AD292-72B6-4941-A880-FE93BA1D7373@hendrik-sattler.de> Message-ID: Hi, I think you are looking for fixup_bundle if you are missing DLLs at install. There's no real need to look for the DLLs yourself. Lectem Le sam. 28 oct. 2017 ? 08:18, Hendrik Sattler a ?crit : > Hi, > > looking at the location of the gnat static library, it seems to be a > compiler library like libm. You usually do not use find_package on those > but directly use -lgnat and the compiler knows how to find it. Requesting > static linking will also work then. > > HS > > > Am 28. Oktober 2017 05:38:19 MESZ schrieb "Alan W. Irwin" < > irwin at beluga.phys.uvic.ca>: > >On 2017-10-27 22:31+0200 Marco Atzeri wrote: > > > >> On 27/10/2017 09:32, Alan W. Irwin wrote: > >>> I am pretty sure there are a non-zero number of CMake users here who > >>> have had CMake experience finding dll's on Cygwin (since it appears > >>> from the quote below that import libraries can be replaced by dll's > >>> for the purposes of linking on that platform). So if you are one > >with > >>> such experience, I would really appreciate an answer to (or commment > >>> on) the specific question below concerning finding cyggnat-6.dll on > >>> Cygwin or if you prefer to frame your response to the more general > >>> question of finding dll's on that platform, that would be great as > >>> well. > >>> > >>> Alan > >> > >> using the import library is the standard way for linking, > >> looking for the shared library is surely unusual. > >> > >> I am not a user of ADA, but the import libraries seems > >> the one on /usr/lib/gcc/x86_64-pc-cygwin/6.4.0/adalib/ > > > >Hi Marco: > > > >Thanks for your input to the discussion. > > > >I believe you are referring to > >/usr/lib/gcc/x86_64-pc-cygwin/6.4.0/adalib/libgnat.a > > > >(at least that appears to be the only library candidate I can come up > >with > >by searching for the RE > > > >"usr/lib/gcc/x86_64-pc-cygwin/6.4.0/adalib/.*gnat" > > > >using the package search > >engine.) > > > >Our understanding is the Cygwin naming convention for the various > >kinds of libraries would be (in the gnat library case) > > > >dll cyggnat-6.dll > >import library libgnat-6.dll.a > >static library libgnat.a > > > >If you use the above search engine to search for the RE "gnat.*dll" it > >only finds the above dll and no corresponding import library. > > > >We are pretty sure from its name that libgnat.a is just a static > >library. Anyhow, when we link our test_ada library against libgnat.a > >that link does appear to work, but afterward when linking Ada > >executables against our Ada library (which involves a gnatlink step > >with hidden link to one form of the gnat library but likely also > >cyggnat-6.dll) we get multiple symbol definition errors. That linking > >inconsistency does not happen if we link our Ada library against > >cyggnat-6.dll so it appears that is the library CMake needs to find in > >this case. > > > >Which neatly ( :-) ) leads back to my original question which is what > >is the > >best CMake logic to find that dll? > > > >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 > > -- > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From anonymous.maarten at gmail.com Sat Oct 28 05:16:02 2017 From: anonymous.maarten at gmail.com (Anonymous Maarten) Date: Sat, 28 Oct 2017 11:16:02 +0200 Subject: [CMake] Problem measuring coverage in CTest scripts Message-ID: I've searched in the history of the mailing list and I think it's the same problem as this one: https://public.kitware.com/pipermail/cmake/2017-September/066176.html I cannot use the Ninja generator in my script. When I change the generator to 'Unix Makefiles', the coverage works. Thanks for responding! Maarten On 28 October 2017 at 09:24, Cl?ment Gregoire wrote: > No since the point of cmake scripts is to build the project (for CI > basically). > > I'm not sure what happens but I remember people having issues when using > ninja? I'm not sure. > > You can have a look at > https://github.com/Lectem/cpp-boilerplate > I use a Ctest script for my Travis coverage build. > > The script is the following : > https://github.com/Lectem/cpp-boilerplate/blob/master/cmake/CI.CTestScript.cmake > > > Le sam. 28 oct. 2017 ? 08:30, Edoardo Pasca a ?crit > : >> >> Afaik, Ctest should be run in the build directory. From your command it >> seems you run it in the source. I'm not surprised it doesn't work. >> >> Edo >> >> On Oct 28, 2017 6:59 AM, "Maarten Anonymous" >> wrote: >>> >>> Hey, >>> >>> I have a question about using CMake+CTest+CTest scripts for coverage >>> tests. >>> >>> If I manually build the project and run "make ExperimantalCoverage" in a >>> build folder, >>> the coverage succeeds. >>> If I run the coverage from within a CTest script, >>> it fails. >>> >>> Am I forgetting something? >>> >>> A minimum example that exhibits my problem can be found at >>> https://gist.github.com/madebr/07ebd0de59e789cd819643b58db25df9. >>> >>> This works: >>> mkdir build && cd build && cmake .. && make && make test && make >>> ExperimentalCoverage && cd .. >>> This fails: >>> ctest -S test.ctest >>> >>> Source listing: >>> ################### >>> #CMakeLists.txt: >>> ################### >>> cmake_minimum_required(VERSION 3.9) >>> project(cmake_coverage) >>> >>> file(WRITE "${CMAKE_CURRENT_BINARY_DIR}/main.c" "int main() {return 0;}") >>> >>> add_executable(main >>> main.c >>> ) >>> >>> target_compile_options(main >>> PUBLIC >>> "-O0" >>> "-fprofile-arcs" >>> "-ftest-coverage" >>> ) >>> >>> target_link_libraries(main >>> gcov >>> ) >>> >>> include(CTest) >>> enable_testing() >>> >>> add_test(NAME test >>> COMMAND main >>> ) >>> >>> ############## >>> # test.ctest: >>> ############## >>> set(CTEST_SOURCE_DIRECTORY "${CTEST_SCRIPT_DIRECTORY}") >>> set(CTEST_BINARY_DIRECTORY "${CTEST_SCRIPT_DIRECTORY}/build/ctest") >>> >>> ctest_empty_binary_directory("${CTEST_BINARY_DIRECTORY}") >>> >>> set(CTEST_SITE "${CMAKE_SYSTEM_NAME}") >>> set(CTEST_BUILD_NAME "experimental build") >>> >>> set(CTEST_CMAKE_GENERATOR "Ninja") >>> set(CTEST_COVERAGE_COMMAND "gcov") >>> >>> ctest_start("Experimental") >>> ctest_configure() >>> ctest_build() >>> ctest_test() >>> ctest_coverage() >>> >>> ############## >>> # CTestConfig.cmake: >>> ############## >>> set(CTEST_PROJECT_NAME "Simple ctest_coverage project") >>> >>> >>> >>> -- >>> >>> 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 marco.atzeri at gmail.com Sat Oct 28 10:44:02 2017 From: marco.atzeri at gmail.com (Marco Atzeri) Date: Sat, 28 Oct 2017 16:44:02 +0200 Subject: [CMake] How to find dll's on Cygwin? (fwd) In-Reply-To: References: <579c4959-c483-a747-2454-613711b1e03c@gmail.com> Message-ID: On 28/10/2017 05:38, Alan W. Irwin wrote: > On 2017-10-27 22:31+0200 Marco Atzeri wrote: > >> On 27/10/2017 09:32, Alan W. Irwin wrote: > > Our understanding is the Cygwin naming convention for the various > kinds of libraries would be (in the gnat library case) > > dll?????????????? cyggnat-6.dll > import library??? libgnat-6.dll.a > static library??? libgnat.a > Hi Alan, the understanding is correct, it should be libgnat-6.dll.a or libgnat.dll.a However as $ gnatlink -v -shared hello GNATLINK 6.4.0 Copyright (C) 1995-2016, Free Software Foundation, Inc. gcc -c -mtune=generic -march=x86-64 -gnatA -gnatWb -gnatiw -gnatws /tmp/ada/b~hello.adb /usr/bin/gcc.exe b~hello.o ./hello.o -shared -o hello.exe -L./ -L/usr/lib/gcc/x86_64-pc-cygwin/6.4.0/adalib/ -lgnat-6 -Wl,--stack=0x2000000 -shared-libgcc /usr/lib/gcc/x86_64-pc-cygwin/6.4.0/../../../../x86_64-pc-cygwin/bin/ld: cannot find -lgnat-6 collect2: error: ld returned 1 exit status gnatlink: error when calling /usr/bin/gcc.exe I suspect the ada package is incomplete, so I raised the attention of the package maintainer. https://cygwin.com/ml/cygwin/2017-10/msg00358.html Regards Marco From boxerab at gmail.com Sat Oct 28 10:50:32 2017 From: boxerab at gmail.com (Aaron Boxer) Date: Sat, 28 Oct 2017 10:50:32 -0400 Subject: [CMake] Change compiler for certain files in the project Message-ID: Hello, I have a cmake project on linux, and I would like to change the compiler for certain files from g++ to another, llvm-based compiler called hcc. (hcc is AMDs HIP compiler for GPGPU) Is there a way of doing this in my cmake file ? Thanks, Aaron -------------- next part -------------- An HTML attachment was scrubbed... URL: From pfultz2 at yahoo.com Sat Oct 28 11:22:20 2017 From: pfultz2 at yahoo.com (P F) Date: Sat, 28 Oct 2017 10:22:20 -0500 Subject: [CMake] Change compiler for certain files in the project In-Reply-To: References: Message-ID: <61E6AE4E-1A6B-4DA8-A3D1-56889E25A420@yahoo.com> > On Oct 28, 2017, at 9:50 AM, Aaron Boxer wrote: > > Hello, > > I have a cmake project on linux, and I would like to change the compiler > for certain files from g++ to another, llvm-based compiler called hcc. > (hcc is AMDs HIP compiler for GPGPU) > > > Is there a way of doing this in my cmake file ? There isn?t a simple way to do that. The FindCUDA and FindHIP cmake modules do that, but its not at all easy to follow, and brings its own set of issues. Of course, why do you need to use g++ to compile host code? Being clang-based hcc should be able to compile any g++ code. So you can just use hcc as the compiler for everything and then link with the `hccrt` cmake target(provided by `find_package(hcc)`) which will enable GPU compiling when you want to compile code for the device. From irwin at beluga.phys.uvic.ca Sat Oct 28 13:39:19 2017 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Sat, 28 Oct 2017 10:39:19 -0700 (PDT) Subject: [CMake] How to find dll's on Cygwin? (fwd) In-Reply-To: References: <579c4959-c483-a747-2454-613711b1e03c@gmail.com> Message-ID: On 2017-10-28 16:44+0200 Marco Atzeri wrote: > On 28/10/2017 05:38, Alan W. Irwin wrote: >> On 2017-10-27 22:31+0200 Marco Atzeri wrote: >> >>> On 27/10/2017 09:32, Alan W. Irwin wrote: >> >> Our understanding is the Cygwin naming convention for the various >> kinds of libraries would be (in the gnat library case) >> >> dll?????????????? cyggnat-6.dll >> import library??? libgnat-6.dll.a >> static library??? libgnat.a >> > > Hi Alan, > > the understanding is correct, it should be > libgnat-6.dll.a or libgnat.dll.a Thanks for that confirmation. > However as > > $ gnatlink -v -shared hello > GNATLINK 6.4.0 > Copyright (C) 1995-2016, Free Software Foundation, Inc. > gcc -c -mtune=generic -march=x86-64 -gnatA -gnatWb -gnatiw -gnatws > /tmp/ada/b~hello.adb > /usr/bin/gcc.exe b~hello.o ./hello.o -shared -o hello.exe -L./ > -L/usr/lib/gcc/x86_64-pc-cygwin/6.4.0/adalib/ -lgnat-6 -Wl,--stack=0x2000000 > -shared-libgcc > /usr/lib/gcc/x86_64-pc-cygwin/6.4.0/../../../../x86_64-pc-cygwin/bin/ld: > cannot find -lgnat-6 > collect2: error: ld returned 1 exit status > gnatlink: error when calling /usr/bin/gcc.exe > > I suspect the ada package is incomplete, so I raised > the attention of the package maintainer. > > https://cygwin.com/ml/cygwin/2017-10/msg00358.html Hi Marco: Many thanks (!) for your message to the Cygwin Ada package maintainer with a clear simple example of the problem. (We were unaware of that simple Ada example until now, and that is likely to prove useful for us in the future as well.) If that maintainer is on the ball, I am pretty confident the net result of your message will be a package fix that will make our workaround (linking to the dll) for the packaging issue redundant. However, until that Cygwin Ada package is fixed we would like to use that workaround (which so far we have only gotten to work by hand) from CMake. So my original general question remains concerning the best way to get CMake to find dll's. So far (although we haven't tried this yet) it appears our best bet is to use find_file (rather than find_library which appears to be unable to find dll's on the Cygwin platform) to find that dll for the Cygwin case. So if anyone here can suggest a better method of finding dll's on Cygwin, please let me know. 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 noflaco at gmail.com Sat Oct 28 19:36:53 2017 From: noflaco at gmail.com (Carlton Banks) Date: Sun, 29 Oct 2017 01:36:53 +0200 Subject: [CMake] does cmake scripts execute sequentially? Message-ID: <1E5CC791-6C72-42FC-B8BF-2EBBF4303330@gmail.com> I seem to have some problems executing one of my submodules cmakelist. MESSAGE(?In record CMAKELIST?) # Include externalproject {portaudio} if lib/portaudio don't exist. MESSAGE(?Download external project?) INCLUDE(ExternalProject) ExternalProject_Add(project_portaudio GIT_REPOSITORY https://git.assembla.com/portaudio.git PREFIX lib/portaudio CONFIGURE_COMMAND /configure BUILD_IN_SOURCE 1 BUILD_COMMAND make INSTALL_COMMAND sudo make install ) ExternalProject_Get_Property(project_portaudio BINARY_DIR) ExternalProject_Get_Property(project_portaudio SOURCE_DIR) SET(portaudio_lib_dir "${BINARY_DIR}/lib/.libs") SET(portaudio_inc_dir "${SOURCE_DIR}/include") add_library(record STATIC record.cpp record.h) add_library(libaudio libportaudio.a PATHS ${portaudio_lib_dir}) # # this makes sure we have compiler flags that allow class::class() = default (>= C++11) target_compile_features(record PUBLIC cxx_defaulted_functions) target_include_directories(record PUBLIC ${CMAKE_CURRENT_SOURCE_DIR} ${project_portaudio}) It cannot find libportaudio.a as externalproject_add() is not being executed, the command it executes add_library, which fails as the project has not been downloaded? what is wrong here? From craig.scott at crascit.com Sat Oct 28 20:19:57 2017 From: craig.scott at crascit.com (Craig Scott) Date: Sun, 29 Oct 2017 11:19:57 +1100 Subject: [CMake] does cmake scripts execute sequentially? In-Reply-To: <1E5CC791-6C72-42FC-B8BF-2EBBF4303330@gmail.com> References: <1E5CC791-6C72-42FC-B8BF-2EBBF4303330@gmail.com> Message-ID: On Sun, Oct 29, 2017 at 10:36 AM, Carlton Banks wrote: > I seem to have some problems executing one of my submodules cmakelist. > > MESSAGE(?In record CMAKELIST?) > > # Include externalproject {portaudio} if lib/portaudio don't exist. > MESSAGE(?Download external project?) > > INCLUDE(ExternalProject) > ExternalProject_Add(project_portaudio > GIT_REPOSITORY https://git.assembla.com/portaudio.git > PREFIX lib/portaudio > CONFIGURE_COMMAND /configure > BUILD_IN_SOURCE 1 > BUILD_COMMAND make > INSTALL_COMMAND sudo make install > ) > ExternalProject_Get_Property(project_portaudio BINARY_DIR) > ExternalProject_Get_Property(project_portaudio SOURCE_DIR) > > SET(portaudio_lib_dir "${BINARY_DIR}/lib/.libs") > SET(portaudio_inc_dir "${SOURCE_DIR}/include") > > add_library(record STATIC record.cpp record.h) > add_library(libaudio libportaudio.a PATHS ${portaudio_lib_dir}) > What is this second add_library() command intended to do? I'm guessing you probably instead want to be doing something like this (untested, but hopefully in the ballpark): add_library(portaudio STATIC IMPORTED) set_target_properties(portaudio PROPERTIES IMPORTED_LOCATION ${BINARY_DIR}/lib/.libs/libportaudio.a ) target_include_directories(portaudio INTERFACE ${SOURCE_DIR}/include ) add_dependencies(portaudio project_portaudio) # Not sure if this is allowed for imported targets though I don't recall off the top of my head whether STATIC IMPORTED or INTERFACE IMPORTED would be the right way to call add_library() in the above, so try the latter if the former doesn't work for you. > > > # > # this makes sure we have compiler flags that allow class::class() = > default (>= C++11) > target_compile_features(record PUBLIC cxx_defaulted_functions) > > > > > target_include_directories(record PUBLIC ${CMAKE_CURRENT_SOURCE_DIR} > ${project_portaudio}) > You won't need this if you define the portaudio imported library as per my example above. > > > It cannot find libportaudio.a as externalproject_add() is not being > executed, the command it executes add_library, which fails as the project > has not been downloaded? > > > what is wrong here? > The reason for this specific problem is that there's no dependency relationship between the project_portaudio target defined by the ExternalProject_Add() call and the record target. Such a relationship is only created through a suitable call to target_link_libraries() or add_dependencies(), or through arguments like DEPENDS for commands that offer such features (e.g. add_custom_target() and add_custom_command()). -- Craig Scott Melbourne, Australia https://crascit.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From noflaco at gmail.com Sat Oct 28 20:26:04 2017 From: noflaco at gmail.com (Carlton Banks) Date: Sun, 29 Oct 2017 02:26:04 +0200 Subject: [CMake] does cmake scripts execute sequentially? In-Reply-To: References: <1E5CC791-6C72-42FC-B8BF-2EBBF4303330@gmail.com> Message-ID: CMake Error at src/include/record/CMakeLists.txt:28 (target_include_directories): Cannot specify include directories for imported target "portaudio". is the problem that externalProject_add only is executed when make is executed and not when cmake is executed?? what is `portaudio` here referring to? > Den 29. okt. 2017 kl. 02.19 skrev Craig Scott : > > > > On Sun, Oct 29, 2017 at 10:36 AM, Carlton Banks > wrote: > I seem to have some problems executing one of my submodules cmakelist. > > MESSAGE(?In record CMAKELIST?) > > # Include externalproject {portaudio} if lib/portaudio don't exist. > MESSAGE(?Download external project?) > > INCLUDE(ExternalProject) > ExternalProject_Add(project_portaudio > GIT_REPOSITORY https://git.assembla.com/portaudio.git > PREFIX lib/portaudio > CONFIGURE_COMMAND /configure > BUILD_IN_SOURCE 1 > BUILD_COMMAND make > INSTALL_COMMAND sudo make install > ) > ExternalProject_Get_Property(project_portaudio BINARY_DIR) > ExternalProject_Get_Property(project_portaudio SOURCE_DIR) > > SET(portaudio_lib_dir "${BINARY_DIR}/lib/.libs") > SET(portaudio_inc_dir "${SOURCE_DIR}/include") > > add_library(record STATIC record.cpp record.h) > add_library(libaudio libportaudio.a PATHS ${portaudio_lib_dir}) > > What is this second add_library() command intended to do? I'm guessing you probably instead want to be doing something like this (untested, but hopefully in the ballpark): > > add_library(portaudio STATIC IMPORTED) > set_target_properties(portaudio PROPERTIES > IMPORTED_LOCATION ${BINARY_DIR}/lib/.libs/libportaudio.a > ) > target_include_directories(portaudio INTERFACE > ${SOURCE_DIR}/include > ) > add_dependencies(portaudio project_portaudio) # Not sure if this is allowed for imported targets though > > I don't recall off the top of my head whether STATIC IMPORTED or INTERFACE IMPORTED would be the right way to call add_library() in the above, so try the latter if the former doesn't work for you. > > > > > > # > # this makes sure we have compiler flags that allow class::class() = default (>= C++11) > target_compile_features(record PUBLIC cxx_defaulted_functions) > > > > > target_include_directories(record PUBLIC ${CMAKE_CURRENT_SOURCE_DIR} ${project_portaudio}) > > You won't need this if you define the portaudio imported library as per my example above. > > > > > It cannot find libportaudio.a as externalproject_add() is not being executed, the command it executes add_library, which fails as the project has not been downloaded? > > > what is wrong here? > > The reason for this specific problem is that there's no dependency relationship between the project_portaudio target defined by the ExternalProject_Add() call and the record target. Such a relationship is only created through a suitable call to target_link_libraries() or add_dependencies(), or through arguments like DEPENDS for commands that offer such features (e.g. add_custom_target() and add_custom_command()). > > > -- > Craig Scott > Melbourne, Australia > https://crascit.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From craig.scott at crascit.com Sat Oct 28 20:29:42 2017 From: craig.scott at crascit.com (Craig Scott) Date: Sun, 29 Oct 2017 11:29:42 +1100 Subject: [CMake] does cmake scripts execute sequentially? In-Reply-To: References: <1E5CC791-6C72-42FC-B8BF-2EBBF4303330@gmail.com> Message-ID: On Sun, Oct 29, 2017 at 11:26 AM, Carlton Banks wrote: > CMake Error at src/include/record/CMakeLists.txt:28 > (target_include_directories): > Cannot specify include directories for imported target "portaudio". > > > is the problem that externalProject_add only is executed when make is > executed and not when cmake is executed?? > what is `portaudio` here referring to? > The name "portaudio" is the target defined by the add_library() call in my example (the imported target that represents what the ExternalProject_Add() is going to create at build time). Did you also try the INTERFACE IMPORTED alternative? It would be more useful if you showed the full CMakeLists.txt rather than just the error message. > Den 29. okt. 2017 kl. 02.19 skrev Craig Scott : > > > > On Sun, Oct 29, 2017 at 10:36 AM, Carlton Banks wrote: > >> I seem to have some problems executing one of my submodules cmakelist. >> >> MESSAGE(?In record CMAKELIST?) >> >> # Include externalproject {portaudio} if lib/portaudio don't exist. >> MESSAGE(?Download external project?) >> >> INCLUDE(ExternalProject) >> ExternalProject_Add(project_portaudio >> GIT_REPOSITORY https://git.assembla.com/portaudio.git >> PREFIX lib/portaudio >> CONFIGURE_COMMAND /configure >> BUILD_IN_SOURCE 1 >> BUILD_COMMAND make >> INSTALL_COMMAND sudo make install >> ) >> ExternalProject_Get_Property(project_portaudio BINARY_DIR) >> ExternalProject_Get_Property(project_portaudio SOURCE_DIR) >> >> SET(portaudio_lib_dir "${BINARY_DIR}/lib/.libs") >> SET(portaudio_inc_dir "${SOURCE_DIR}/include") >> >> add_library(record STATIC record.cpp record.h) >> add_library(libaudio libportaudio.a PATHS ${portaudio_lib_dir}) >> > > What is this second add_library() command intended to do? I'm guessing you > probably instead want to be doing something like this (untested, but > hopefully in the ballpark): > > add_library(portaudio STATIC IMPORTED) > set_target_properties(portaudio PROPERTIES > IMPORTED_LOCATION ${BINARY_DIR}/lib/.libs/libportaudio.a > ) > target_include_directories(portaudio INTERFACE > ${SOURCE_DIR}/include > ) > > add_dependencies(portaudio project_portaudio) # Not sure if this is > allowed for imported targets though > > > I don't recall off the top of my head whether STATIC IMPORTED or INTERFACE > IMPORTED would be the right way to call add_library() in the above, so try > the latter if the former doesn't work for you. > > > >> >> >> # >> # this makes sure we have compiler flags that allow class::class() = >> default (>= C++11) >> target_compile_features(record PUBLIC cxx_defaulted_functions) >> >> >> >> >> target_include_directories(record PUBLIC ${CMAKE_CURRENT_SOURCE_DIR} >> ${project_portaudio}) >> > > You won't need this if you define the portaudio imported library as per my > example above. > > > >> >> >> It cannot find libportaudio.a as externalproject_add() is not being >> executed, the command it executes add_library, which fails as the project >> has not been downloaded? >> >> >> what is wrong here? >> > > The reason for this specific problem is that there's no dependency > relationship between the project_portaudio target defined by the > ExternalProject_Add() call and the record target. Such a relationship is > only created through a suitable call to target_link_libraries() or > add_dependencies(), or through arguments like DEPENDS for commands that > offer such features (e.g. add_custom_target() and add_custom_command()). > > > -- > Craig Scott > Melbourne, Australia > https://crascit.com > > > -- Craig Scott Melbourne, Australia https://crascit.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From noflaco at gmail.com Sat Oct 28 20:47:54 2017 From: noflaco at gmail.com (Carlton Banks) Date: Sun, 29 Oct 2017 02:47:54 +0200 Subject: [CMake] does cmake scripts execute sequentially? In-Reply-To: References: <1E5CC791-6C72-42FC-B8BF-2EBBF4303330@gmail.com> Message-ID: > Den 29. okt. 2017 kl. 02.29 skrev Craig Scott : > > > > On Sun, Oct 29, 2017 at 11:26 AM, Carlton Banks > wrote: > CMake Error at src/include/record/CMakeLists.txt:28 (target_include_directories): > Cannot specify include directories for imported target "portaudio". > > > is the problem that externalProject_add only is executed when make is executed and not when cmake is executed?? > what is `portaudio` here referring to? > > The name "portaudio" is the target defined by the add_library() call in my example (the imported target that represents what the ExternalProject_Add() is going to create at build time). ok. > Did you also try the INTERFACE IMPORTED alternative? Still the same.. > It would be more useful if you showed the full CMakeLists.txt rather than just the error message. > The submodule cmakelist: https://pastebin.com/x2WNhK56 tree structure https://pastebin.com/xhPNCkN2 The outer cmakelist includes the inner directories. > > >> Den 29. okt. 2017 kl. 02.19 skrev Craig Scott >: >> >> >> >> On Sun, Oct 29, 2017 at 10:36 AM, Carlton Banks > wrote: >> I seem to have some problems executing one of my submodules cmakelist. >> >> MESSAGE(?In record CMAKELIST?) >> >> # Include externalproject {portaudio} if lib/portaudio don't exist. >> MESSAGE(?Download external project?) >> >> INCLUDE(ExternalProject) >> ExternalProject_Add(project_portaudio >> GIT_REPOSITORY https://git.assembla.com/portaudio.git >> PREFIX lib/portaudio >> CONFIGURE_COMMAND /configure >> BUILD_IN_SOURCE 1 >> BUILD_COMMAND make >> INSTALL_COMMAND sudo make install >> ) >> ExternalProject_Get_Property(project_portaudio BINARY_DIR) >> ExternalProject_Get_Property(project_portaudio SOURCE_DIR) >> >> SET(portaudio_lib_dir "${BINARY_DIR}/lib/.libs") >> SET(portaudio_inc_dir "${SOURCE_DIR}/include") >> >> add_library(record STATIC record.cpp record.h) >> add_library(libaudio libportaudio.a PATHS ${portaudio_lib_dir}) >> >> What is this second add_library() command intended to do? I'm guessing you probably instead want to be doing something like this (untested, but hopefully in the ballpark): >> >> add_library(portaudio STATIC IMPORTED) >> set_target_properties(portaudio PROPERTIES >> IMPORTED_LOCATION ${BINARY_DIR}/lib/.libs/libportaudio.a >> ) >> target_include_directories(portaudio INTERFACE >> ${SOURCE_DIR}/include >> ) >> add_dependencies(portaudio project_portaudio) # Not sure if this is allowed for imported targets though >> >> I don't recall off the top of my head whether STATIC IMPORTED or INTERFACE IMPORTED would be the right way to call add_library() in the above, so try the latter if the former doesn't work for you. >> >> >> >> >> >> # >> # this makes sure we have compiler flags that allow class::class() = default (>= C++11) >> target_compile_features(record PUBLIC cxx_defaulted_functions) >> >> >> >> >> target_include_directories(record PUBLIC ${CMAKE_CURRENT_SOURCE_DIR} ${project_portaudio}) >> >> You won't need this if you define the portaudio imported library as per my example above. >> >> >> >> >> It cannot find libportaudio.a as externalproject_add() is not being executed, the command it executes add_library, which fails as the project has not been downloaded? >> >> >> what is wrong here? >> >> The reason for this specific problem is that there's no dependency relationship between the project_portaudio target defined by the ExternalProject_Add() call and the record target. Such a relationship is only created through a suitable call to target_link_libraries() or add_dependencies(), or through arguments like DEPENDS for commands that offer such features (e.g. add_custom_target() and add_custom_command()). >> >> >> -- >> Craig Scott >> Melbourne, Australia >> https://crascit.com > > > > > -- > Craig Scott > Melbourne, Australia > https://crascit.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From craig.scott at crascit.com Sat Oct 28 21:00:39 2017 From: craig.scott at crascit.com (Craig Scott) Date: Sun, 29 Oct 2017 12:00:39 +1100 Subject: [CMake] does cmake scripts execute sequentially? In-Reply-To: References: <1E5CC791-6C72-42FC-B8BF-2EBBF4303330@gmail.com> Message-ID: Ah, sorry. This particular problem has been fixed on CMake master, but it won't be in the 3.10 release (in release candidate stage), so that isn't going to help you right now. Possibly you might be able to modify the relevant target property directly rather than using target_include_directories() - again this is untested, but worth a try: set_property(TARGET portaudio APPEND PROPERTY INTERFACE_INCLUDE_DIRECTORIES ${SOURCE_DIR}/include ) If that doesn't work, then I guess modifying your original method to use the correct path may be an alternative workaround: target_include_directories(record PUBLIC ${CMAKE_CURRENT_SOURCE_DIR} ${SOURCE_DIR}/include) On Sun, Oct 29, 2017 at 11:47 AM, Carlton Banks wrote: > > Den 29. okt. 2017 kl. 02.29 skrev Craig Scott : > > > > On Sun, Oct 29, 2017 at 11:26 AM, Carlton Banks wrote: > >> CMake Error at src/include/record/CMakeLists.txt:28 >> (target_include_directories): >> Cannot specify include directories for imported target "portaudio". >> >> >> is the problem that externalProject_add only is executed when make is >> executed and not when cmake is executed?? >> what is `portaudio` here referring to? >> > > The name "portaudio" is the target defined by the add_library() call in my > example (the imported target that represents what the ExternalProject_Add() > is going to create at build time). > > ok. > > Did you also try the INTERFACE IMPORTED alternative? > > Still the same.. > > It would be more useful if you showed the full CMakeLists.txt rather than > just the error message. > > > The submodule cmakelist: > > https://pastebin.com/x2WNhK56 > > tree structure > > https://pastebin.com/xhPNCkN2 > > The outer cmakelist includes the inner directories. > > > > >> Den 29. okt. 2017 kl. 02.19 skrev Craig Scott : >> >> >> >> On Sun, Oct 29, 2017 at 10:36 AM, Carlton Banks >> wrote: >> >>> I seem to have some problems executing one of my submodules cmakelist. >>> >>> MESSAGE(?In record CMAKELIST?) >>> >>> # Include externalproject {portaudio} if lib/portaudio don't exist. >>> MESSAGE(?Download external project?) >>> >>> INCLUDE(ExternalProject) >>> ExternalProject_Add(project_portaudio >>> GIT_REPOSITORY https://git.assembla.com/portaudio.git >>> PREFIX lib/portaudio >>> CONFIGURE_COMMAND /configure >>> BUILD_IN_SOURCE 1 >>> BUILD_COMMAND make >>> INSTALL_COMMAND sudo make install >>> ) >>> ExternalProject_Get_Property(project_portaudio BINARY_DIR) >>> ExternalProject_Get_Property(project_portaudio SOURCE_DIR) >>> >>> SET(portaudio_lib_dir "${BINARY_DIR}/lib/.libs") >>> SET(portaudio_inc_dir "${SOURCE_DIR}/include") >>> >>> add_library(record STATIC record.cpp record.h) >>> add_library(libaudio libportaudio.a PATHS ${portaudio_lib_dir}) >>> >> >> What is this second add_library() command intended to do? I'm guessing >> you probably instead want to be doing something like this (untested, but >> hopefully in the ballpark): >> >> add_library(portaudio STATIC IMPORTED) >> set_target_properties(portaudio PROPERTIES >> IMPORTED_LOCATION ${BINARY_DIR}/lib/.libs/libportaudio.a >> ) >> target_include_directories(portaudio INTERFACE >> ${SOURCE_DIR}/include >> ) >> >> add_dependencies(portaudio project_portaudio) # Not sure if this is >> allowed for imported targets though >> >> >> I don't recall off the top of my head whether STATIC IMPORTED or >> INTERFACE IMPORTED would be the right way to call add_library() in the >> above, so try the latter if the former doesn't work for you. >> >> >> >>> >>> >>> # >>> # this makes sure we have compiler flags that allow class::class() = >>> default (>= C++11) >>> target_compile_features(record PUBLIC cxx_defaulted_functions) >>> >>> >>> >>> >>> target_include_directories(record PUBLIC ${CMAKE_CURRENT_SOURCE_DIR} >>> ${project_portaudio}) >>> >> >> You won't need this if you define the portaudio imported library as per >> my example above. >> >> >> >>> >>> >>> It cannot find libportaudio.a as externalproject_add() is not being >>> executed, the command it executes add_library, which fails as the project >>> has not been downloaded? >>> >>> >>> what is wrong here? >>> >> >> The reason for this specific problem is that there's no dependency >> relationship between the project_portaudio target defined by the >> ExternalProject_Add() call and the record target. Such a relationship is >> only created through a suitable call to target_link_libraries() or >> add_dependencies(), or through arguments like DEPENDS for commands that >> offer such features (e.g. add_custom_target() and add_custom_command()). >> >> >> -- >> Craig Scott >> Melbourne, Australia >> https://crascit.com >> >> >> > > > -- > Craig Scott > Melbourne, Australia > https://crascit.com > > > -- Craig Scott Melbourne, Australia https://crascit.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From d3ck0r at gmail.com Sat Oct 28 21:06:24 2017 From: d3ck0r at gmail.com (J Decker) Date: Sat, 28 Oct 2017 18:06:24 -0700 Subject: [CMake] does cmake scripts execute sequentially? In-Reply-To: References: <1E5CC791-6C72-42FC-B8BF-2EBBF4303330@gmail.com> Message-ID: I recently added externaproject_add() to download a library, but since it doesn't do the download until build, I had to put a conditional around the second part of the cmake that used the libraries it produced so it would do a cmake configure/generate, cmake build, cmake configure/generate and a final build and all was good... https://github.com/d3x0r/sack.vfs/blob/master/CMakeLists.gui.txt#L61 but I coudln't reference any directories that didn't exist yet in include_directories, or link_directories...until the project had been at least partially built. On Sat, Oct 28, 2017 at 6:00 PM, Craig Scott wrote: > Ah, sorry. This particular problem has been fixed > on CMake > master, but it won't be in the 3.10 release (in release candidate stage), > so that isn't going to help you right now. Possibly you might be able to > modify the relevant target property directly rather than using > target_include_directories() - again this is untested, but worth a try: > > set_property(TARGET portaudio APPEND PROPERTY > INTERFACE_INCLUDE_DIRECTORIES ${SOURCE_DIR}/include > ) > > > If that doesn't work, then I guess modifying your original method to use > the correct path may be an alternative workaround: > > target_include_directories(record PUBLIC ${CMAKE_CURRENT_SOURCE_DIR} ${ > SOURCE_DIR}/include) > > > > > > On Sun, Oct 29, 2017 at 11:47 AM, Carlton Banks wrote: > >> >> Den 29. okt. 2017 kl. 02.29 skrev Craig Scott : >> >> >> >> On Sun, Oct 29, 2017 at 11:26 AM, Carlton Banks >> wrote: >> >>> CMake Error at src/include/record/CMakeLists.txt:28 >>> (target_include_directories): >>> Cannot specify include directories for imported target "portaudio". >>> >>> >>> is the problem that externalProject_add only is executed when make is >>> executed and not when cmake is executed?? >>> what is `portaudio` here referring to? >>> >> >> The name "portaudio" is the target defined by the add_library() call in >> my example (the imported target that represents what the >> ExternalProject_Add() is going to create at build time). >> >> ok. >> >> Did you also try the INTERFACE IMPORTED alternative? >> >> Still the same.. >> >> It would be more useful if you showed the full CMakeLists.txt rather than >> just the error message. >> >> >> The submodule cmakelist: >> >> https://pastebin.com/x2WNhK56 >> >> tree structure >> >> https://pastebin.com/xhPNCkN2 >> >> The outer cmakelist includes the inner directories. >> >> >> >> >>> Den 29. okt. 2017 kl. 02.19 skrev Craig Scott : >>> >>> >>> >>> On Sun, Oct 29, 2017 at 10:36 AM, Carlton Banks >>> wrote: >>> >>>> I seem to have some problems executing one of my submodules cmakelist. >>>> >>>> MESSAGE(?In record CMAKELIST?) >>>> >>>> # Include externalproject {portaudio} if lib/portaudio don't exist. >>>> MESSAGE(?Download external project?) >>>> >>>> INCLUDE(ExternalProject) >>>> ExternalProject_Add(project_portaudio >>>> GIT_REPOSITORY https://git.assembla.com/portaudio.git >>>> PREFIX lib/portaudio >>>> CONFIGURE_COMMAND /configure >>>> BUILD_IN_SOURCE 1 >>>> BUILD_COMMAND make >>>> INSTALL_COMMAND sudo make install >>>> ) >>>> ExternalProject_Get_Property(project_portaudio BINARY_DIR) >>>> ExternalProject_Get_Property(project_portaudio SOURCE_DIR) >>>> >>>> SET(portaudio_lib_dir "${BINARY_DIR}/lib/.libs") >>>> SET(portaudio_inc_dir "${SOURCE_DIR}/include") >>>> >>>> add_library(record STATIC record.cpp record.h) >>>> add_library(libaudio libportaudio.a PATHS ${portaudio_lib_dir}) >>>> >>> >>> What is this second add_library() command intended to do? I'm guessing >>> you probably instead want to be doing something like this (untested, but >>> hopefully in the ballpark): >>> >>> add_library(portaudio STATIC IMPORTED) >>> set_target_properties(portaudio PROPERTIES >>> IMPORTED_LOCATION ${BINARY_DIR}/lib/.libs/libportaudio.a >>> ) >>> target_include_directories(portaudio INTERFACE >>> ${SOURCE_DIR}/include >>> ) >>> >>> add_dependencies(portaudio project_portaudio) # Not sure if this is >>> allowed for imported targets though >>> >>> >>> I don't recall off the top of my head whether STATIC IMPORTED or >>> INTERFACE IMPORTED would be the right way to call add_library() in the >>> above, so try the latter if the former doesn't work for you. >>> >>> >>> >>>> >>>> >>>> # >>>> # this makes sure we have compiler flags that allow class::class() = >>>> default (>= C++11) >>>> target_compile_features(record PUBLIC cxx_defaulted_functions) >>>> >>>> >>>> >>>> >>>> target_include_directories(record PUBLIC ${CMAKE_CURRENT_SOURCE_DIR} >>>> ${project_portaudio}) >>>> >>> >>> You won't need this if you define the portaudio imported library as per >>> my example above. >>> >>> >>> >>>> >>>> >>>> It cannot find libportaudio.a as externalproject_add() is not being >>>> executed, the command it executes add_library, which fails as the project >>>> has not been downloaded? >>>> >>>> >>>> what is wrong here? >>>> >>> >>> The reason for this specific problem is that there's no dependency >>> relationship between the project_portaudio target defined by the >>> ExternalProject_Add() call and the record target. Such a relationship is >>> only created through a suitable call to target_link_libraries() or >>> add_dependencies(), or through arguments like DEPENDS for commands that >>> offer such features (e.g. add_custom_target() and add_custom_command()). >>> >>> >>> -- >>> Craig Scott >>> Melbourne, Australia >>> https://crascit.com >>> >>> >>> >> >> >> -- >> Craig Scott >> Melbourne, Australia >> https://crascit.com >> >> >> > > > -- > 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 noflaco at gmail.com Sat Oct 28 21:10:49 2017 From: noflaco at gmail.com (Carlton Banks) Date: Sun, 29 Oct 2017 02:10:49 +0100 Subject: [CMake] does cmake scripts execute sequentially? In-Reply-To: References: <1E5CC791-6C72-42FC-B8BF-2EBBF4303330@gmail.com> Message-ID: <8B59394B-7F2F-4D48-AA95-B3C72D102B95@gmail.com> > Den 29. okt. 2017 kl. 02.06 skrev J Decker : > > I recently added externaproject_add() to download a library, but since it doesn't do the download until build, I had to put a conditional around the second part of the cmake that used the libraries it produced so it would do a cmake configure/generate, cmake build, cmake configure/generate and a final build and all was good... > Yes? that sound exactly like the problem I am currently facing.. > https://github.com/d3x0r/sack.vfs/blob/master/CMakeLists.gui.txt#L61 I am not sure I understand how your if statement fixes this?.. when does it download? > > but I coudln't reference any directories that didn't exist yet in include_directories, or link_directories...until the project had been at least partially built. > > On Sat, Oct 28, 2017 at 6:00 PM, Craig Scott > wrote: it still doesn?t work? I am bit unsure of what is being done here.. I need to include the libraryportaudio.a to include portaudio into the project. which causes an error as the download only occurs during build (make) and not during cmake. > Ah, sorry. This particular problem has been fixed on CMake master, but it won't be in the 3.10 release (in release candidate stage), so that isn't going to help you right now. Possibly you might be able to modify the relevant target property directly rather than using target_include_directories() - again this is untested, but worth a try: > > set_property(TARGET portaudio APPEND PROPERTY > INTERFACE_INCLUDE_DIRECTORIES ${SOURCE_DIR}/include > ) > > If that doesn't work, then I guess modifying your original method to use the correct path may be an alternative workaround: > > target_include_directories(record PUBLIC ${CMAKE_CURRENT_SOURCE_DIR} ${SOURCE_DIR}/include) > > > > > On Sun, Oct 29, 2017 at 11:47 AM, Carlton Banks > wrote: > >> Den 29. okt. 2017 kl. 02.29 skrev Craig Scott >: >> >> >> >> On Sun, Oct 29, 2017 at 11:26 AM, Carlton Banks > wrote: >> CMake Error at src/include/record/CMakeLists.txt:28 (target_include_directories): >> Cannot specify include directories for imported target "portaudio". >> >> >> is the problem that externalProject_add only is executed when make is executed and not when cmake is executed?? >> what is `portaudio` here referring to? >> >> The name "portaudio" is the target defined by the add_library() call in my example (the imported target that represents what the ExternalProject_Add() is going to create at build time). > > ok. > >> Did you also try the INTERFACE IMPORTED alternative? > > Still the same.. > >> It would be more useful if you showed the full CMakeLists.txt rather than just the error message. >> > > The submodule cmakelist: > > https://pastebin.com/x2WNhK56 > > tree structure > > https://pastebin.com/xhPNCkN2 > > The outer cmakelist includes the inner directories. > >> >> >>> Den 29. okt. 2017 kl. 02.19 skrev Craig Scott >: >>> >>> >>> >>> On Sun, Oct 29, 2017 at 10:36 AM, Carlton Banks > wrote: >>> I seem to have some problems executing one of my submodules cmakelist. >>> >>> MESSAGE(?In record CMAKELIST?) >>> >>> # Include externalproject {portaudio} if lib/portaudio don't exist. >>> MESSAGE(?Download external project?) >>> >>> INCLUDE(ExternalProject) >>> ExternalProject_Add(project_portaudio >>> GIT_REPOSITORY https://git.assembla.com/portaudio.git >>> PREFIX lib/portaudio >>> CONFIGURE_COMMAND /configure >>> BUILD_IN_SOURCE 1 >>> BUILD_COMMAND make >>> INSTALL_COMMAND sudo make install >>> ) >>> ExternalProject_Get_Property(project_portaudio BINARY_DIR) >>> ExternalProject_Get_Property(project_portaudio SOURCE_DIR) >>> >>> SET(portaudio_lib_dir "${BINARY_DIR}/lib/.libs") >>> SET(portaudio_inc_dir "${SOURCE_DIR}/include") >>> >>> add_library(record STATIC record.cpp record.h) >>> add_library(libaudio libportaudio.a PATHS ${portaudio_lib_dir}) >>> >>> What is this second add_library() command intended to do? I'm guessing you probably instead want to be doing something like this (untested, but hopefully in the ballpark): >>> >>> add_library(portaudio STATIC IMPORTED) >>> set_target_properties(portaudio PROPERTIES >>> IMPORTED_LOCATION ${BINARY_DIR}/lib/.libs/libportaudio.a >>> ) >>> target_include_directories(portaudio INTERFACE >>> ${SOURCE_DIR}/include >>> ) >>> add_dependencies(portaudio project_portaudio) # Not sure if this is allowed for imported targets though >>> >>> I don't recall off the top of my head whether STATIC IMPORTED or INTERFACE IMPORTED would be the right way to call add_library() in the above, so try the latter if the former doesn't work for you. >>> >>> >>> >>> >>> >>> # >>> # this makes sure we have compiler flags that allow class::class() = default (>= C++11) >>> target_compile_features(record PUBLIC cxx_defaulted_functions) >>> >>> >>> >>> >>> target_include_directories(record PUBLIC ${CMAKE_CURRENT_SOURCE_DIR} ${project_portaudio}) >>> >>> You won't need this if you define the portaudio imported library as per my example above. >>> >>> >>> >>> >>> It cannot find libportaudio.a as externalproject_add() is not being executed, the command it executes add_library, which fails as the project has not been downloaded? >>> >>> >>> what is wrong here? >>> >>> The reason for this specific problem is that there's no dependency relationship between the project_portaudio target defined by the ExternalProject_Add() call and the record target. Such a relationship is only created through a suitable call to target_link_libraries() or add_dependencies(), or through arguments like DEPENDS for commands that offer such features (e.g. add_custom_target() and add_custom_command()). >>> >>> >>> -- >>> Craig Scott >>> Melbourne, Australia >>> https://crascit.com >> >> >> >> >> -- >> Craig Scott >> Melbourne, Australia >> https://crascit.com > > > > > -- > 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 Sat Oct 28 21:15:15 2017 From: craig.scott at crascit.com (Craig Scott) Date: Sun, 29 Oct 2017 12:15:15 +1100 Subject: [CMake] does cmake scripts execute sequentially? In-Reply-To: References: <1E5CC791-6C72-42FC-B8BF-2EBBF4303330@gmail.com> Message-ID: On Sun, Oct 29, 2017 at 12:06 PM, J Decker wrote: > I recently added externaproject_add() to download a library, but since it > doesn't do the download until build, I had to put a conditional around the > second part of the cmake that used the libraries it produced so it would do > a cmake configure/generate, cmake build, cmake configure/generate and a > final build and all was good... > > https://github.com/d3x0r/sack.vfs/blob/master/CMakeLists.gui.txt#L61 > > but I coudln't reference any directories that didn't exist yet in > include_directories, or link_directories...until the project had been at > least partially built. > For the "directory must exist" problem, using file(MAKE_DIRECTORY) to force it to exist first is sometimes a viable workaround. > > On Sat, Oct 28, 2017 at 6:00 PM, Craig Scott > wrote: > >> Ah, sorry. This particular problem has been fixed >> on CMake >> master, but it won't be in the 3.10 release (in release candidate stage), >> so that isn't going to help you right now. Possibly you might be able to >> modify the relevant target property directly rather than using >> target_include_directories() - again this is untested, but worth a try: >> >> set_property(TARGET portaudio APPEND PROPERTY >> INTERFACE_INCLUDE_DIRECTORIES ${SOURCE_DIR}/include >> ) >> >> >> If that doesn't work, then I guess modifying your original method to use >> the correct path may be an alternative workaround: >> >> target_include_directories(record PUBLIC ${CMAKE_CURRENT_SOURCE_DIR} ${ >> SOURCE_DIR}/include) >> >> >> >> >> >> On Sun, Oct 29, 2017 at 11:47 AM, Carlton Banks >> wrote: >> >>> >>> Den 29. okt. 2017 kl. 02.29 skrev Craig Scott : >>> >>> >>> >>> On Sun, Oct 29, 2017 at 11:26 AM, Carlton Banks >>> wrote: >>> >>>> CMake Error at src/include/record/CMakeLists.txt:28 >>>> (target_include_directories): >>>> Cannot specify include directories for imported target "portaudio". >>>> >>>> >>>> is the problem that externalProject_add only is executed when make is >>>> executed and not when cmake is executed?? >>>> what is `portaudio` here referring to? >>>> >>> >>> The name "portaudio" is the target defined by the add_library() call in >>> my example (the imported target that represents what the >>> ExternalProject_Add() is going to create at build time). >>> >>> ok. >>> >>> Did you also try the INTERFACE IMPORTED alternative? >>> >>> Still the same.. >>> >>> It would be more useful if you showed the full CMakeLists.txt rather >>> than just the error message. >>> >>> >>> The submodule cmakelist: >>> >>> https://pastebin.com/x2WNhK56 >>> >>> tree structure >>> >>> https://pastebin.com/xhPNCkN2 >>> >>> The outer cmakelist includes the inner directories. >>> >>> >>> >>> >>>> Den 29. okt. 2017 kl. 02.19 skrev Craig Scott >>> >: >>>> >>>> >>>> >>>> On Sun, Oct 29, 2017 at 10:36 AM, Carlton Banks >>>> wrote: >>>> >>>>> I seem to have some problems executing one of my submodules cmakelist. >>>>> >>>>> MESSAGE(?In record CMAKELIST?) >>>>> >>>>> # Include externalproject {portaudio} if lib/portaudio don't exist. >>>>> MESSAGE(?Download external project?) >>>>> >>>>> INCLUDE(ExternalProject) >>>>> ExternalProject_Add(project_portaudio >>>>> GIT_REPOSITORY https://git.assembla.com/portaudio.git >>>>> PREFIX lib/portaudio >>>>> CONFIGURE_COMMAND /configure >>>>> BUILD_IN_SOURCE 1 >>>>> BUILD_COMMAND make >>>>> INSTALL_COMMAND sudo make install >>>>> ) >>>>> ExternalProject_Get_Property(project_portaudio BINARY_DIR) >>>>> ExternalProject_Get_Property(project_portaudio SOURCE_DIR) >>>>> >>>>> SET(portaudio_lib_dir "${BINARY_DIR}/lib/.libs") >>>>> SET(portaudio_inc_dir "${SOURCE_DIR}/include") >>>>> >>>>> add_library(record STATIC record.cpp record.h) >>>>> add_library(libaudio libportaudio.a PATHS ${portaudio_lib_dir}) >>>>> >>>> >>>> What is this second add_library() command intended to do? I'm guessing >>>> you probably instead want to be doing something like this (untested, but >>>> hopefully in the ballpark): >>>> >>>> add_library(portaudio STATIC IMPORTED) >>>> set_target_properties(portaudio PROPERTIES >>>> IMPORTED_LOCATION ${BINARY_DIR}/lib/.libs/libportaudio.a >>>> ) >>>> target_include_directories(portaudio INTERFACE >>>> ${SOURCE_DIR}/include >>>> ) >>>> >>>> add_dependencies(portaudio project_portaudio) # Not sure if this is >>>> allowed for imported targets though >>>> >>>> >>>> I don't recall off the top of my head whether STATIC IMPORTED or >>>> INTERFACE IMPORTED would be the right way to call add_library() in the >>>> above, so try the latter if the former doesn't work for you. >>>> >>>> >>>> >>>>> >>>>> >>>>> # >>>>> # this makes sure we have compiler flags that allow class::class() = >>>>> default (>= C++11) >>>>> target_compile_features(record PUBLIC cxx_defaulted_functions) >>>>> >>>>> >>>>> >>>>> >>>>> target_include_directories(record PUBLIC ${CMAKE_CURRENT_SOURCE_DIR} >>>>> ${project_portaudio}) >>>>> >>>> >>>> You won't need this if you define the portaudio imported library as per >>>> my example above. >>>> >>>> >>>> >>>>> >>>>> >>>>> It cannot find libportaudio.a as externalproject_add() is not being >>>>> executed, the command it executes add_library, which fails as the project >>>>> has not been downloaded? >>>>> >>>>> >>>>> what is wrong here? >>>>> >>>> >>>> The reason for this specific problem is that there's no dependency >>>> relationship between the project_portaudio target defined by the >>>> ExternalProject_Add() call and the record target. Such a relationship is >>>> only created through a suitable call to target_link_libraries() or >>>> add_dependencies(), or through arguments like DEPENDS for commands that >>>> offer such features (e.g. add_custom_target() and add_custom_command()). >>>> >>>> -- Craig Scott Melbourne, Australia https://crascit.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From noflaco at gmail.com Sat Oct 28 21:18:25 2017 From: noflaco at gmail.com (Carlton Banks) Date: Sun, 29 Oct 2017 02:18:25 +0100 Subject: [CMake] does cmake scripts execute sequentially? In-Reply-To: References: <1E5CC791-6C72-42FC-B8BF-2EBBF4303330@gmail.com> Message-ID: <26EA2D17-2688-4574-9C3F-4CD441398F02@gmail.com> > Den 29. okt. 2017 kl. 02.15 skrev Craig Scott : > > file(MAKE_DIRECTORY) Not sure about the workaround.. the problem here is that cmake does not download, and make does. So adding a workaround like that, would require to add a condition that differentiates between cmake and make.. -------------- next part -------------- An HTML attachment was scrubbed... URL: From craig.scott at crascit.com Sat Oct 28 21:20:34 2017 From: craig.scott at crascit.com (Craig Scott) Date: Sun, 29 Oct 2017 12:20:34 +1100 Subject: [CMake] does cmake scripts execute sequentially? In-Reply-To: <26EA2D17-2688-4574-9C3F-4CD441398F02@gmail.com> References: <1E5CC791-6C72-42FC-B8BF-2EBBF4303330@gmail.com> <26EA2D17-2688-4574-9C3F-4CD441398F02@gmail.com> Message-ID: On Sun, Oct 29, 2017 at 12:18 PM, Carlton Banks wrote: > > Den 29. okt. 2017 kl. 02.15 skrev Craig Scott : > > file(MAKE_DIRECTORY) > > Not sure about the workaround.. the problem here is that cmake does not > download, and make does. > So adding a workaround like that, would require to add a condition that > differentiates between cmake and make.. > No condition should be needed, simply add it to CMakeLists.txt before the command that adds the directory to the include path. The external make build shouldn't complain if the path already exists, it will just go ahead and populate it. At least, that's been my experience when I've used this workaround before for this very problem. -- Craig Scott Melbourne, Australia https://crascit.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From noflaco at gmail.com Sat Oct 28 21:27:04 2017 From: noflaco at gmail.com (Carlton Banks) Date: Sun, 29 Oct 2017 02:27:04 +0100 Subject: [CMake] does cmake scripts execute sequentially? In-Reply-To: References: <1E5CC791-6C72-42FC-B8BF-2EBBF4303330@gmail.com> <26EA2D17-2688-4574-9C3F-4CD441398F02@gmail.com> Message-ID: > Den 29. okt. 2017 kl. 02.20 skrev Craig Scott : > > > > On Sun, Oct 29, 2017 at 12:18 PM, Carlton Banks > wrote: > >> Den 29. okt. 2017 kl. 02.15 skrev Craig Scott >: >> >> file(MAKE_DIRECTORY) > Not sure about the workaround.. the problem here is that cmake does not download, and make does. > So adding a workaround like that, would require to add a condition that differentiates between cmake and make.. > > No condition should be needed, simply add it to CMakeLists.txt before the command that adds the directory to the include path. The external make build shouldn't complain if the path already exists, it will just go ahead and populate it. At least, that's been my experience when I've used this workaround before for this very problem. > It somehow still causes some problems.. https://pastebin.com/HqE5H95Q Gives me this error: cmake .. ?InsrcCMAKELIST? ?InincludeCMAKELIST? ?IndatabaseCMAKELIST? ?InmatchCMAKELIST? ?InrecordCMAKELIST? ?Downloadexternalproject? CMake Error at src/include/record/CMakeLists.txt:25 (file): file must be called with at least two arguments. CMake Error at src/include/record/CMakeLists.txt:32 (target_include_directories): Cannot specify include directories for imported target "portaudio". ?InspectogramCMAKELIST? -- Configuring incomplete, errors occurred! See also "/Users/keerthikanratnarajah/soundcloud/build/CMakeFiles/CMakeOutput.log". > > -- > Craig Scott > Melbourne, Australia > https://crascit.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From craig.scott at crascit.com Sat Oct 28 21:34:54 2017 From: craig.scott at crascit.com (Craig Scott) Date: Sun, 29 Oct 2017 12:34:54 +1100 Subject: [CMake] does cmake scripts execute sequentially? In-Reply-To: References: <1E5CC791-6C72-42FC-B8BF-2EBBF4303330@gmail.com> <26EA2D17-2688-4574-9C3F-4CD441398F02@gmail.com> Message-ID: Your line 25 is incorrect, you left out the MAKE_DIRECTORY part and the path you specified doesn't seem to be right. It should be something more like: file(MAKE_DIRECTORY ${SOURCE_DIR}/include) You also seem to have missed one of my other emails. Replace this: target_include_directories(portaudio INTERFACE ${portaudio_inc_dir} ) with this: set_property(TARGET portaudio APPEND PROPERTY INTERFACE_INCLUDE_DIRECTORIES ${SOURCE_DIR}/include ) If that doesn't work, still get rid of the target_include_directories() call above and also replace this: target_include_directories(record PUBLIC ${CMAKE_CURRENT_SOURCE_DIR} ${project_portaudio}) with this (as a last resort workaround): target_include_directories(record PUBLIC ${CMAKE_CURRENT_SOURCE_DIR} ${ SOURCE_DIR}/include) I'm going to have to leave it at that, gotta focus on other work now. Hopefully the above gets you further along. Otherwise, I'll have to leave it to others to continue to help you from here. On Sun, Oct 29, 2017 at 12:27 PM, Carlton Banks wrote: > > Den 29. okt. 2017 kl. 02.20 skrev Craig Scott : > > > > On Sun, Oct 29, 2017 at 12:18 PM, Carlton Banks wrote: > >> >> Den 29. okt. 2017 kl. 02.15 skrev Craig Scott : >> >> file(MAKE_DIRECTORY) >> >> Not sure about the workaround.. the problem here is that cmake does not >> download, and make does. >> So adding a workaround like that, would require to add a condition that >> differentiates between cmake and make.. >> > > No condition should be needed, simply add it to CMakeLists.txt before the > command that adds the directory to the include path. The external make > build shouldn't complain if the path already exists, it will just go ahead > and populate it. At least, that's been my experience when I've used this > workaround before for this very problem. > > It somehow still causes some problems.. > > > https://pastebin.com/HqE5H95Q > > Gives me this error: > > cmake .. > ?InsrcCMAKELIST? > ?InincludeCMAKELIST? > ?IndatabaseCMAKELIST? > ?InmatchCMAKELIST? > ?InrecordCMAKELIST? > ?Downloadexternalproject? > CMake Error at src/include/record/CMakeLists.txt:25 (file): > file must be called with at least two arguments. > > > CMake Error at src/include/record/CMakeLists.txt:32 > (target_include_directories): > Cannot specify include directories for imported target "portaudio". > > > ?InspectogramCMAKELIST? > -- Configuring incomplete, errors occurred! > See also "/Users/keerthikanratnarajah/soundcloud/build/CMakeFiles/ > CMakeOutput.log". > > > -- > Craig Scott > Melbourne, Australia > https://crascit.com > > > -- Craig Scott Melbourne, Australia https://crascit.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From noflaco at gmail.com Sat Oct 28 21:45:26 2017 From: noflaco at gmail.com (Carlton Banks) Date: Sun, 29 Oct 2017 02:45:26 +0100 Subject: [CMake] does cmake scripts execute sequentially? In-Reply-To: <0E215AEA-7B2D-46BF-B481-B98CB5C03222@gmail.com> References: <1E5CC791-6C72-42FC-B8BF-2EBBF4303330@gmail.com> <26EA2D17-2688-4574-9C3F-4CD441398F02@gmail.com> <0E215AEA-7B2D-46BF-B481-B98CB5C03222@gmail.com> Message-ID: <52246AC7-E6DB-4B69-9A2D-F2C03DE145D9@gmail.com> I might have been a tat too fast there.. It doesn?t seem to able to find the /configure script.. and I can?t seem to print the path it looking in.. [ 5%] Building CXX object src/include/spectogram/CMakeFiles/spectogram.dir/spectogram.cpp.o [ 11%] Linking CXX static library libspectogram.a [ 11%] Built target spectogram [ 16%] Building CXX object src/include/database/CMakeFiles/database.dir/database.cpp.o [ 22%] Linking CXX static library libdatabase.a [ 22%] Built target database [ 27%] Building CXX object src/include/match/CMakeFiles/match.dir/match.cpp.o [ 33%] Linking CXX static library libmatch.a [ 33%] Built target match [ 38%] Building CXX object src/include/record/CMakeFiles/record.dir/record.cpp.o [ 44%] Linking CXX static library librecord.a [ 44%] Built target record [ 50%] Building CXX object src/CMakeFiles/cmakeDemo.dir/main.cpp.o [ 55%] Linking CXX executable cmakeDemo [ 55%] Built target cmakeDemo [ 61%] Creating directories for 'project_portaudio' [ 66%] Performing download step (git clone) for 'project_portaudio' -- Avoiding repeated git clone, stamp file is up to date: '/Users/keerthikanratnarajah/soundcloud/build/src/include/record/lib/portaudio/src/project_portaudio-stamp/project_portaudio-gitclone-lastrun.txt' [ 72%] No patch step for 'project_portaudio' [ 77%] Performing update step for 'project_portaudio' Current branch master is up to date. [ 83%] Performing configure step for 'project_portaudio' /bin/sh: /configure: No such file or directory make[2]: *** [src/include/record/lib/portaudio/src/project_portaudio-stamp/project_portaudio-configure] Error 127 make[1]: *** [src/include/record/CMakeFiles/project_portaudio.dir/all] Error 2 make: *** [all] Error 2 > Den 29. okt. 2017 kl. 02.37 skrev Carlton Banks : > >> >> Den 29. okt. 2017 kl. 02.34 skrev Craig Scott >: >> >> Your line 25 is incorrect, you left out the MAKE_DIRECTORY part and the path you specified doesn't seem to be right. It should be something more like: >> >> file(MAKE_DIRECTORY ${SOURCE_DIR}/include) >> >> >> You also seem to have missed one of my other emails. Replace this: >> >> target_include_directories(portaudio INTERFACE >> ${portaudio_inc_dir} >> ) >> >> with this: >> >> set_property(TARGET portaudio APPEND PROPERTY >> INTERFACE_INCLUDE_DIRECTORIES ${SOURCE_DIR}/include >> ) >> > > Those fixes made it work.. thanks :) > >> If that doesn't work, still get rid of the target_include_directories() call above and also replace this: >> >> target_include_directories(record PUBLIC ${CMAKE_CURRENT_SOURCE_DIR} ${project_portaudio}) >> >> with this (as a last resort workaround): >> >> target_include_directories(record PUBLIC ${CMAKE_CURRENT_SOURCE_DIR} ${SOURCE_DIR}/include) >> >> >> I'm going to have to leave it at that, gotta focus on other work now. Hopefully the above gets you further along. Otherwise, I'll have to leave it to others to continue to help you from here. >> >> >> On Sun, Oct 29, 2017 at 12:27 PM, Carlton Banks > wrote: >> >>> Den 29. okt. 2017 kl. 02.20 skrev Craig Scott >: >>> >>> >>> >>> On Sun, Oct 29, 2017 at 12:18 PM, Carlton Banks > wrote: >>> >>>> Den 29. okt. 2017 kl. 02.15 skrev Craig Scott >: >>>> >>>> file(MAKE_DIRECTORY) >>> Not sure about the workaround.. the problem here is that cmake does not download, and make does. >>> So adding a workaround like that, would require to add a condition that differentiates between cmake and make.. >>> >>> No condition should be needed, simply add it to CMakeLists.txt before the command that adds the directory to the include path. The external make build shouldn't complain if the path already exists, it will just go ahead and populate it. At least, that's been my experience when I've used this workaround before for this very problem. >>> >> It somehow still causes some problems.. >> >> >> https://pastebin.com/HqE5H95Q >> >> Gives me this error: >> >> cmake .. >> ?InsrcCMAKELIST? >> ?InincludeCMAKELIST? >> ?IndatabaseCMAKELIST? >> ?InmatchCMAKELIST? >> ?InrecordCMAKELIST? >> ?Downloadexternalproject? >> CMake Error at src/include/record/CMakeLists.txt:25 (file): >> file must be called with at least two arguments. >> >> >> CMake Error at src/include/record/CMakeLists.txt:32 (target_include_directories): >> Cannot specify include directories for imported target "portaudio". >> >> >> ?InspectogramCMAKELIST? >> -- Configuring incomplete, errors occurred! >> See also "/Users/keerthikanratnarajah/soundcloud/build/CMakeFiles/CMakeOutput.log". >> >>> >>> -- >>> Craig Scott >>> Melbourne, Australia >>> https://crascit.com >> >> >> >> >> -- >> Craig Scott >> Melbourne, Australia >> https://crascit.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From d3ck0r at gmail.com Sat Oct 28 21:50:19 2017 From: d3ck0r at gmail.com (J Decker) Date: Sat, 28 Oct 2017 18:50:19 -0700 Subject: [CMake] does cmake scripts execute sequentially? In-Reply-To: References: <1E5CC791-6C72-42FC-B8BF-2EBBF4303330@gmail.com> Message-ID: On Sat, Oct 28, 2017 at 6:15 PM, Craig Scott wrote: > > > On Sun, Oct 29, 2017 at 12:06 PM, J Decker wrote: > >> I recently added externaproject_add() to download a library, but since it >> doesn't do the download until build, I had to put a conditional around the >> second part of the cmake that used the libraries it produced so it would do >> a cmake configure/generate, cmake build, cmake configure/generate and a >> final build and all was good... >> >> https://github.com/d3x0r/sack.vfs/blob/master/CMakeLists.gui.txt#L61 >> >> but I coudln't reference any directories that didn't exist yet in >> include_directories, or link_directories...until the project had been at >> least partially built. >> > > For the "directory must exist" problem, using file(MAKE_DIRECTORY) to > force it to exist first is sometimes a viable workaround. > > > (third time's the charm :) kept missing reply-all ) That would cause the git checkout to fail with 'directory already has content' or something like that. There is a second external project that builds another sub-project from the same source tree... it probably would work for expected install locations for a simpler project though. > > >> >> On Sat, Oct 28, 2017 at 6:00 PM, Craig Scott >> wrote: >> >>> Ah, sorry. This particular problem has been fixed >>> on CMake >>> master, but it won't be in the 3.10 release (in release candidate stage), >>> so that isn't going to help you right now. Possibly you might be able to >>> modify the relevant target property directly rather than using >>> target_include_directories() - again this is untested, but worth a try: >>> >>> set_property(TARGET portaudio APPEND PROPERTY >>> INTERFACE_INCLUDE_DIRECTORIES ${SOURCE_DIR}/include >>> ) >>> >>> >>> If that doesn't work, then I guess modifying your original method to use >>> the correct path may be an alternative workaround: >>> >>> target_include_directories(record PUBLIC ${CMAKE_CURRENT_SOURCE_DIR} ${ >>> SOURCE_DIR}/include) >>> >>> >>> >>> >>> >>> On Sun, Oct 29, 2017 at 11:47 AM, Carlton Banks >>> wrote: >>> >>>> >>>> Den 29. okt. 2017 kl. 02.29 skrev Craig Scott >>> >: >>>> >>>> >>>> >>>> On Sun, Oct 29, 2017 at 11:26 AM, Carlton Banks >>>> wrote: >>>> >>>>> CMake Error at src/include/record/CMakeLists.txt:28 >>>>> (target_include_directories): >>>>> Cannot specify include directories for imported target "portaudio". >>>>> >>>>> >>>>> is the problem that externalProject_add only is executed when make is >>>>> executed and not when cmake is executed?? >>>>> what is `portaudio` here referring to? >>>>> >>>> >>>> The name "portaudio" is the target defined by the add_library() call in >>>> my example (the imported target that represents what the >>>> ExternalProject_Add() is going to create at build time). >>>> >>>> ok. >>>> >>>> Did you also try the INTERFACE IMPORTED alternative? >>>> >>>> Still the same.. >>>> >>>> It would be more useful if you showed the full CMakeLists.txt rather >>>> than just the error message. >>>> >>>> >>>> The submodule cmakelist: >>>> >>>> https://pastebin.com/x2WNhK56 >>>> >>>> tree structure >>>> >>>> https://pastebin.com/xhPNCkN2 >>>> >>>> The outer cmakelist includes the inner directories. >>>> >>>> >>>> >>>> >>>>> Den 29. okt. 2017 kl. 02.19 skrev Craig Scott >>>> >: >>>>> >>>>> >>>>> >>>>> On Sun, Oct 29, 2017 at 10:36 AM, Carlton Banks >>>>> wrote: >>>>> >>>>>> I seem to have some problems executing one of my submodules cmakelist. >>>>>> >>>>>> MESSAGE(?In record CMAKELIST?) >>>>>> >>>>>> # Include externalproject {portaudio} if lib/portaudio don't exist. >>>>>> MESSAGE(?Download external project?) >>>>>> >>>>>> INCLUDE(ExternalProject) >>>>>> ExternalProject_Add(project_portaudio >>>>>> GIT_REPOSITORY https://git.assembla.com/portaudio.git >>>>>> PREFIX lib/portaudio >>>>>> CONFIGURE_COMMAND /configure >>>>>> BUILD_IN_SOURCE 1 >>>>>> BUILD_COMMAND make >>>>>> INSTALL_COMMAND sudo make install >>>>>> ) >>>>>> ExternalProject_Get_Property(project_portaudio BINARY_DIR) >>>>>> ExternalProject_Get_Property(project_portaudio SOURCE_DIR) >>>>>> >>>>>> SET(portaudio_lib_dir "${BINARY_DIR}/lib/.libs") >>>>>> SET(portaudio_inc_dir "${SOURCE_DIR}/include") >>>>>> >>>>>> add_library(record STATIC record.cpp record.h) >>>>>> add_library(libaudio libportaudio.a PATHS ${portaudio_lib_dir}) >>>>>> >>>>> >>>>> What is this second add_library() command intended to do? I'm guessing >>>>> you probably instead want to be doing something like this (untested, but >>>>> hopefully in the ballpark): >>>>> >>>>> add_library(portaudio STATIC IMPORTED) >>>>> set_target_properties(portaudio PROPERTIES >>>>> IMPORTED_LOCATION ${BINARY_DIR}/lib/.libs/libportaudio.a >>>>> ) >>>>> target_include_directories(portaudio INTERFACE >>>>> ${SOURCE_DIR}/include >>>>> ) >>>>> >>>>> add_dependencies(portaudio project_portaudio) # Not sure if this >>>>> is allowed for imported targets though >>>>> >>>>> >>>>> I don't recall off the top of my head whether STATIC IMPORTED or >>>>> INTERFACE IMPORTED would be the right way to call add_library() in the >>>>> above, so try the latter if the former doesn't work for you. >>>>> >>>>> >>>>> >>>>>> >>>>>> >>>>>> # >>>>>> # this makes sure we have compiler flags that allow class::class() = >>>>>> default (>= C++11) >>>>>> target_compile_features(record PUBLIC cxx_defaulted_functions) >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> target_include_directories(record PUBLIC ${CMAKE_CURRENT_SOURCE_DIR} >>>>>> ${project_portaudio}) >>>>>> >>>>> >>>>> You won't need this if you define the portaudio imported library as >>>>> per my example above. >>>>> >>>>> >>>>> >>>>>> >>>>>> >>>>>> It cannot find libportaudio.a as externalproject_add() is not being >>>>>> executed, the command it executes add_library, which fails as the project >>>>>> has not been downloaded? >>>>>> >>>>>> >>>>>> what is wrong here? >>>>>> >>>>> >>>>> The reason for this specific problem is that there's no dependency >>>>> relationship between the project_portaudio target defined by the >>>>> ExternalProject_Add() call and the record target. Such a relationship is >>>>> only created through a suitable call to target_link_libraries() or >>>>> add_dependencies(), or through arguments like DEPENDS for commands that >>>>> offer such features (e.g. add_custom_target() and add_custom_command()). >>>>> >>>>> > > -- > Craig Scott > Melbourne, Australia > https://crascit.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From d3ck0r at gmail.com Sat Oct 28 21:55:48 2017 From: d3ck0r at gmail.com (J Decker) Date: Sat, 28 Oct 2017 18:55:48 -0700 Subject: [CMake] does cmake scripts execute sequentially? In-Reply-To: <8B59394B-7F2F-4D48-AA95-B3C72D102B95@gmail.com> References: <1E5CC791-6C72-42FC-B8BF-2EBBF4303330@gmail.com> <8B59394B-7F2F-4D48-AA95-B3C72D102B95@gmail.com> Message-ID: On Sat, Oct 28, 2017 at 6:10 PM, Carlton Banks wrote: > > Den 29. okt. 2017 kl. 02.06 skrev J Decker : > > I recently added externaproject_add() to download a library, but since it > doesn't do the download until build, I had to put a conditional around the > second part of the cmake that used the libraries it produced so it would do > a cmake configure/generate, cmake build, cmake configure/generate and a > final build and all was good... > > Yes? that sound exactly like the problem I am currently facing.. > > https://github.com/d3x0r/sack.vfs/blob/master/CMakeLists.gui.txt#L61 > > I am not sure I understand how your if statement fixes this?.. when does > it download? > Sorry it's not a very simple project.... the first externalproject is here https://github.com/d3x0r/sack.vfs/blob/master/CMakeLists.gui.txt#L50 the second is immediately after the if that was fore-mentioned. and that first if( exists) linked goes from there until the end of the file.... And it's not just native cmake, it's actually a node module, that uses npm... https://github.com/d3x0r/sack.vfs/blob/master/package.json#L34 build_gui : npm run build-gui-config #cmake-js --CDMAKE_GUI=1 configure && npm run build-gui-run1 #cmake-js build && npm run build-gui-config # cmake-js --CDMAKE_GUI=1 configure && npm run build-gui-run2 #cmake-js build so I can just do 'num run build-gui' and it runs a sequence of steps... Yes, I hate including build scripts in simpler projects... should just be buildable with cmake. Make if you make your library also an externalproject_add() step, with just a SOURCE_DIR specified (or something) then you could probably do it all in one step. > but I coudln't reference any directories that didn't exist yet in > include_directories, or link_directories...until the project had been at > least partially built. > > On Sat, Oct 28, 2017 at 6:00 PM, Craig Scott > wrote: > > it still doesn?t work? > > I am bit unsure of what is being done here.. I need to include the > libraryportaudio.a to include portaudio into the project. > > which causes an error as the download only occurs during build (make) and > not during cmake. > > Ah, sorry. This particular problem has been fixed >> on CMake >> master, but it won't be in the 3.10 release (in release candidate stage), >> so that isn't going to help you right now. Possibly you might be able to >> modify the relevant target property directly rather than using >> target_include_directories() - again this is untested, but worth a try: >> >> set_property(TARGET portaudio APPEND PROPERTY >> INTERFACE_INCLUDE_DIRECTORIES ${SOURCE_DIR}/include >> ) >> >> >> If that doesn't work, then I guess modifying your original method to use >> the correct path may be an alternative workaround: >> >> target_include_directories(record PUBLIC ${CMAKE_CURRENT_SOURCE_DIR} ${ >> SOURCE_DIR}/include) >> >> >> >> >> >> On Sun, Oct 29, 2017 at 11:47 AM, Carlton Banks >> wrote: >> >>> >>> Den 29. okt. 2017 kl. 02.29 skrev Craig Scott : >>> >>> >>> >>> On Sun, Oct 29, 2017 at 11:26 AM, Carlton Banks >>> wrote: >>> >>>> CMake Error at src/include/record/CMakeLists.txt:28 >>>> (target_include_directories): >>>> Cannot specify include directories for imported target "portaudio". >>>> >>>> >>>> is the problem that externalProject_add only is executed when make is >>>> executed and not when cmake is executed?? >>>> what is `portaudio` here referring to? >>>> >>> >>> The name "portaudio" is the target defined by the add_library() call in >>> my example (the imported target that represents what the >>> ExternalProject_Add() is going to create at build time). >>> >>> ok. >>> >>> Did you also try the INTERFACE IMPORTED alternative? >>> >>> Still the same.. >>> >>> It would be more useful if you showed the full CMakeLists.txt rather >>> than just the error message. >>> >>> >>> The submodule cmakelist: >>> >>> https://pastebin.com/x2WNhK56 >>> >>> tree structure >>> >>> https://pastebin.com/xhPNCkN2 >>> >>> The outer cmakelist includes the inner directories. >>> >>> >>> >>> >>>> Den 29. okt. 2017 kl. 02.19 skrev Craig Scott >>> >: >>>> >>>> >>>> >>>> On Sun, Oct 29, 2017 at 10:36 AM, Carlton Banks >>>> wrote: >>>> >>>>> I seem to have some problems executing one of my submodules cmakelist. >>>>> >>>>> MESSAGE(?In record CMAKELIST?) >>>>> >>>>> # Include externalproject {portaudio} if lib/portaudio don't exist. >>>>> MESSAGE(?Download external project?) >>>>> >>>>> INCLUDE(ExternalProject) >>>>> ExternalProject_Add(project_portaudio >>>>> GIT_REPOSITORY https://git.assembla.com/portaudio.git >>>>> PREFIX lib/portaudio >>>>> CONFIGURE_COMMAND /configure >>>>> BUILD_IN_SOURCE 1 >>>>> BUILD_COMMAND make >>>>> INSTALL_COMMAND sudo make install >>>>> ) >>>>> ExternalProject_Get_Property(project_portaudio BINARY_DIR) >>>>> ExternalProject_Get_Property(project_portaudio SOURCE_DIR) >>>>> >>>>> SET(portaudio_lib_dir "${BINARY_DIR}/lib/.libs") >>>>> SET(portaudio_inc_dir "${SOURCE_DIR}/include") >>>>> >>>>> add_library(record STATIC record.cpp record.h) >>>>> add_library(libaudio libportaudio.a PATHS ${portaudio_lib_dir}) >>>>> >>>> >>>> What is this second add_library() command intended to do? I'm guessing >>>> you probably instead want to be doing something like this (untested, but >>>> hopefully in the ballpark): >>>> >>>> add_library(portaudio STATIC IMPORTED) >>>> set_target_properties(portaudio PROPERTIES >>>> IMPORTED_LOCATION ${BINARY_DIR}/lib/.libs/libportaudio.a >>>> ) >>>> target_include_directories(portaudio INTERFACE >>>> ${SOURCE_DIR}/include >>>> ) >>>> >>>> add_dependencies(portaudio project_portaudio) # Not sure if this is >>>> allowed for imported targets though >>>> >>>> >>>> I don't recall off the top of my head whether STATIC IMPORTED or >>>> INTERFACE IMPORTED would be the right way to call add_library() in the >>>> above, so try the latter if the former doesn't work for you. >>>> >>>> >>>> >>>>> >>>>> >>>>> # >>>>> # this makes sure we have compiler flags that allow class::class() = >>>>> default (>= C++11) >>>>> target_compile_features(record PUBLIC cxx_defaulted_functions) >>>>> >>>>> >>>>> >>>>> >>>>> target_include_directories(record PUBLIC ${CMAKE_CURRENT_SOURCE_DIR} >>>>> ${project_portaudio}) >>>>> >>>> >>>> You won't need this if you define the portaudio imported library as per >>>> my example above. >>>> >>>> >>>> >>>>> >>>>> >>>>> It cannot find libportaudio.a as externalproject_add() is not being >>>>> executed, the command it executes add_library, which fails as the project >>>>> has not been downloaded? >>>>> >>>>> >>>>> what is wrong here? >>>>> >>>> >>>> The reason for this specific problem is that there's no dependency >>>> relationship between the project_portaudio target defined by the >>>> ExternalProject_Add() call and the record target. Such a relationship is >>>> only created through a suitable call to target_link_libraries() or >>>> add_dependencies(), or through arguments like DEPENDS for commands that >>>> offer such features (e.g. add_custom_target() and add_custom_command()). >>>> >>>> >>>> -- >>>> Craig Scott >>>> Melbourne, Australia >>>> https://crascit.com >>>> >>>> >>>> >>> >>> >>> -- >>> Craig Scott >>> Melbourne, Australia >>> https://crascit.com >>> >>> >>> >> >> >> -- >> 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 r030t1 at gmail.com Sat Oct 28 23:44:16 2017 From: r030t1 at gmail.com (R0b0t1) Date: Sat, 28 Oct 2017 22:44:16 -0500 Subject: [CMake] Problems Building a Java Project Under Cygwin Message-ID: What fails is the compile step, like so: javac: file not found: \cygdrive\C\Users\R0b0t1\Documents\Code\project\build\CMakeFiles\project.dir\java_sources (The system cannot find the path specified) Is this due to a change in the path separator? On another note, are there any suggestions for building Java projects? Everything seems very confusing. I am not very smart. Respectfully, R0b0t1. From marco.atzeri at gmail.com Sun Oct 29 05:54:04 2017 From: marco.atzeri at gmail.com (Marco Atzeri) Date: Sun, 29 Oct 2017 10:54:04 +0100 Subject: [CMake] Problems Building a Java Project Under Cygwin In-Reply-To: References: Message-ID: <7881727f-602f-da38-aa3c-8753ae59f8ac@gmail.com> On 29/10/2017 04:44, R0b0t1 wrote: > What fails is the compile step, like so: > > javac: file not found: > \cygdrive\C\Users\R0b0t1\Documents\Code\project\build\CMakeFiles\project.dir\java_sources > (The system cannot find the path specified) > > Is this due to a change in the path separator? > > On another note, are there any suggestions for building Java projects? > Everything seems very confusing. I am not very smart. > > Respectfully, > R0b0t1. > the Java compiler is NOT a cygwin program, so it has no clue of \cygdrive. It will be more easy to use a windows cmake for your Java project From noflaco at gmail.com Sun Oct 29 07:06:14 2017 From: noflaco at gmail.com (Carlton Banks) Date: Sun, 29 Oct 2017 12:06:14 +0100 Subject: [CMake] make goes into stamp dir rather than using source dir? Message-ID: I am currently using externalproject_add to add portaudio, but for some reason am I not able to run the configure script, it does not use the correct directory, for some reason.. INCLUDE(ExternalProject) ExternalProject_Add(project_portaudio GIT_REPOSITORY https://git.assembla.com/portaudio.git PREFIX lib/portaudio CONFIGURE_COMMAND ${SOURCE_DIR}/configure BUILD_IN_SOURCE 1 BUILD_COMMAND make INSTALL_COMMAND sudo make install ) ExternalProject_Get_Property(project_portaudio BINARY_DIR) ExternalProject_Get_Property(project_portaudio SOURCE_DIR) As It can be seen here.. the configure step should be in the ${SOURCE_DIR} and not the ${stamp_dir} make [ 11%] Built target record [ 22%] Built target spectogram [ 33%] Built target database [ 44%] Built target match [ 55%] Built target cmakeDemo [ 61%] Performing update step for 'project_portaudio' Current branch master is up to date. [ 66%] Performing configure step for 'project_portaudio' /bin/sh: /configure: No such file or directory make[2]: *** [src/include/record/lib/portaudio/src/project_portaudio-stamp/project_portaudio-configure] Error 127 make[1]: *** [src/include/record/CMakeFiles/project_portaudio.dir/all] Error 2 make: *** [all] Error 2 Why is it looking in the stamp dir, and not the source dir? -------------- next part -------------- An HTML attachment was scrubbed... URL: From noflaco at gmail.com Sun Oct 29 08:02:56 2017 From: noflaco at gmail.com (Carlton Banks) Date: Sun, 29 Oct 2017 13:02:56 +0100 Subject: [CMake] print path variables within submodules? Message-ID: I am using submodule cmake, in which the relative paths becomes a bit more confusing that I would have hoped. Is there a way to print the path like ${source_dir} and so on within the CMAKElist, so I can keep track of the paths defined? I tried `message(${source_dir})` but the output is empty From r030t1 at gmail.com Sun Oct 29 18:56:16 2017 From: r030t1 at gmail.com (R0b0t1) Date: Sun, 29 Oct 2017 17:56:16 -0500 Subject: [CMake] Problems Building a Java Project Under Cygwin In-Reply-To: <7881727f-602f-da38-aa3c-8753ae59f8ac@gmail.com> References: <7881727f-602f-da38-aa3c-8753ae59f8ac@gmail.com> Message-ID: On Sun, Oct 29, 2017 at 4:54 AM, Marco Atzeri wrote: > On 29/10/2017 04:44, R0b0t1 wrote: >> >> What fails is the compile step, like so: >> >> javac: file not found: >> >> \cygdrive\C\Users\R0b0t1\Documents\Code\project\build\CMakeFiles\project.dir\java_sources >> (The system cannot find the path specified) >> >> Is this due to a change in the path separator? >> >> On another note, are there any suggestions for building Java projects? >> Everything seems very confusing. I am not very smart. >> >> Respectfully, >> R0b0t1. >> > > the Java compiler is NOT a cygwin program, so it has no clue of > \cygdrive. > > It will be more easy to use a windows cmake for your Java project It's really not going to be easier for me to do that. Are there no plans to fix this? I suppose I might file a bug against Cygwin for path translation, but that may be equally intractable. Cheers, R0b0t1 From mwpowellhtx at gmail.com Mon Oct 30 08:27:21 2017 From: mwpowellhtx at gmail.com (Michael Powell) Date: Mon, 30 Oct 2017 08:27:21 -0400 Subject: [CMake] SWIG out of place comprehension Message-ID: Hello, I've been working on some SWIG Interface (.i) files that are basically working and gen-ing up target language source. I've also got some complementary source that I want to incorporate into a target language target language library. >From what I understand CMake does offer SWIG support. But what exactly does it do? How do I need to present my source? For instance, if I've got my source arranged like this: /path/to/src /path/to/src/a /path/to/src/b Then I've also currently got my SWIG "in place" with the source as well, like this; /path/to/src/csharp /path/to/src/a/csharp /path/to/src/b/csharp In this case, my target language is C#. This is all working well enough in and of itself and I have the generated source landing in a directory parallel to "/path/to/src/", named "/path/to/gen/", as well as any predetermined modules presented in "/path/to/src/csharp/", in this case. This is also all pre-CMake, before CMake establishes any out of place contexts. All that being said, what does the CMake SWIG help do in terms of consuming/processing the SWIG interface files? It seems to me, things to consider are things like what the include directories ought to be. I've been identifying /path/to/ as the include directory, and using "src/...", "src/a/...", "src/b/..." as the includes within the interface files, for example. However, I wouldn't be surprised if I needed to do some SED to root those correctly with the CMake/SWIG working directory and/or include directory. Thoughts? Hints? Tips? Tricks? Thank you! Cheers, Michael Powell From ndevenish at gmail.com Mon Oct 30 09:39:41 2017 From: ndevenish at gmail.com (Nicholas Devenish) Date: Mon, 30 Oct 2017 13:39:41 +0000 Subject: [CMake] print path variables within submodules? In-Reply-To: References: Message-ID: Hi Carlton, On Sun, Oct 29, 2017 at 12:02 PM, Carlton Banks wrote: > > Is there a way to print the path like ${source_dir} and so on within the > CMAKElist, so I can keep track of the paths defined? I found understanding exactly what you are asking for a little unclear, but possibly you are looking for CMAKE_CURRENT_SOURCE_DIR - the path to the source directory currently being processed? This should work to display it: message(${CMAKE_CURRENT_SOURCE_DIR}) the problem probably being that cmake doesn't usually define a variable named "source_dir" - unless you've defined one yourself. Otherwise there's a list of everything CMake defines at https://cmake.org/cmake/help/latest/manual/cmake-variables.7.html Nick -------------- next part -------------- An HTML attachment was scrubbed... URL: From kgt at lanl.gov Mon Oct 30 11:18:30 2017 From: kgt at lanl.gov (Thompson, KT) Date: Mon, 30 Oct 2017 15:18:30 +0000 Subject: [CMake] Change compiler for certain files in the project In-Reply-To: <61E6AE4E-1A6B-4DA8-A3D1-56889E25A420@yahoo.com> References: <61E6AE4E-1A6B-4DA8-A3D1-56889E25A420@yahoo.com> Message-ID: Aaron, Another way to do this is by using external project, but it is very 'hacky'. A good place to look for examples is CMake's own AddCMakeFortranSubdirectory features. This is designed to allow Fortran to be compiled with MinGW when the main project uses a VisualStudio generator. The same general logic would work to allow you to process a subdirectory with a different toolchain. -kt -----Original Message----- From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of P F via CMake Sent: Saturday, October 28, 2017 9:22 AM To: Aaron Boxer Cc: cmake Subject: Re: [CMake] Change compiler for certain files in the project > On Oct 28, 2017, at 9:50 AM, Aaron Boxer wrote: > > Hello, > > I have a cmake project on linux, and I would like to change the compiler > for certain files from g++ to another, llvm-based compiler called hcc. > (hcc is AMDs HIP compiler for GPGPU) > > > Is there a way of doing this in my cmake file ? There isn?t a simple way to do that. The FindCUDA and FindHIP cmake modules do that, but its not at all easy to follow, and brings its own set of issues. Of course, why do you need to use g++ to compile host code? Being clang-based hcc should be able to compile any g++ code. So you can just use hcc as the compiler for everything and then link with the `hccrt` cmake target(provided by `find_package(hcc)`) which will enable GPU compiling when you want to compile code for the device. -- 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 ggarra13 at gmail.com Mon Oct 30 11:53:52 2017 From: ggarra13 at gmail.com (=?UTF-8?Q?Gonzalo_Garramu=c3=b1o?=) Date: Mon, 30 Oct 2017 12:53:52 -0300 Subject: [CMake] print path variables within submodules? In-Reply-To: References: Message-ID: El 29/10/17 a las 09:02, Carlton Banks escribi?: > I am using submodule cmake, in which the relative paths becomes a bit more confusing that I would have hoped. > > Is there a way to print the path like ${source_dir} and so on within the CMAKElist, so I can keep track of the paths defined? > > I tried `message(${source_dir})` but the output is empty > Try message( ${CMAKE_CURRENT_SOURCE_DIR} ) -- Gonzalo Garramu?o From noflaco at gmail.com Mon Oct 30 13:59:53 2017 From: noflaco at gmail.com (Carlton Banks) Date: Mon, 30 Oct 2017 18:59:53 +0100 Subject: [CMake] print path variables within submodules? In-Reply-To: References: Message-ID: <0AAA4424-583E-4E6F-B053-687296E0A414@gmail.com> > Den 30. okt. 2017 kl. 16.53 skrev Gonzalo Garramu?o : > > > > El 29/10/17 a las 09:02, Carlton Banks escribi?: >> I am using submodule cmake, in which the relative paths becomes a bit more confusing that I would have hoped. >> >> Is there a way to print the path like ${source_dir} and so on within the CMAKElist, so I can keep track of the paths defined? >> >> I tried `message(${source_dir})` but the output is empty >> > > Try message( ${CMAKE_CURRENT_SOURCE_DIR} ) That just output an empty message... > > -- > Gonzalo Garramu?o > From ggarra13 at gmail.com Mon Oct 30 17:25:32 2017 From: ggarra13 at gmail.com (=?UTF-8?Q?Gonzalo_Garramu=c3=b1o?=) Date: Mon, 30 Oct 2017 18:25:32 -0300 Subject: [CMake] print path variables within submodules? In-Reply-To: <0AAA4424-583E-4E6F-B053-687296E0A414@gmail.com> References: <0AAA4424-583E-4E6F-B053-687296E0A414@gmail.com> Message-ID: <9d55de7c-91d2-bfdb-ce14-a6451755076c@gmail.com> El 30/10/17 a las 14:59, Carlton Banks escribi?: >> Den 30. okt. 2017 kl. 16.53 skrev Gonzalo Garramu?o : >> >> >> >> El 29/10/17 a las 09:02, Carlton Banks escribi?: >>> I am using submodule cmake, in which the relative paths becomes a bit more confusing that I would have hoped. >>> >>> Is there a way to print the path like ${source_dir} and so on within the CMAKElist, so I can keep track of the paths defined? >>> >>> I tried `message(${source_dir})` but the output is empty >>> >> Try message( ${CMAKE_CURRENT_SOURCE_DIR} ) > That just output an empty message... > This works for me.? Try this simple CMakeLists.txt file: set( PROJECT tryme ) message( ${CMAKE_CURRENT_SOURCE_DIR} ) -- Gonzalo Garramu?o From noflaco at gmail.com Mon Oct 30 17:29:32 2017 From: noflaco at gmail.com (Carlton Banks) Date: Mon, 30 Oct 2017 22:29:32 +0100 Subject: [CMake] print path variables within submodules? In-Reply-To: <9d55de7c-91d2-bfdb-ce14-a6451755076c@gmail.com> References: <0AAA4424-583E-4E6F-B053-687296E0A414@gmail.com> <9d55de7c-91d2-bfdb-ce14-a6451755076c@gmail.com> Message-ID: <536E9497-BB30-4F48-A534-A9B93E9FC1B5@gmail.com> Hmm.. That worked.. I don?t know sometimes it does not work.. weird.. > Den 30. okt. 2017 kl. 22.25 skrev Gonzalo Garramu?o : > > > > El 30/10/17 a las 14:59, Carlton Banks escribi?: >>> Den 30. okt. 2017 kl. 16.53 skrev Gonzalo Garramu?o : >>> >>> >>> >>> El 29/10/17 a las 09:02, Carlton Banks escribi?: >>>> I am using submodule cmake, in which the relative paths becomes a bit more confusing that I would have hoped. >>>> >>>> Is there a way to print the path like ${source_dir} and so on within the CMAKElist, so I can keep track of the paths defined? >>>> >>>> I tried `message(${source_dir})` but the output is empty >>>> >>> Try message( ${CMAKE_CURRENT_SOURCE_DIR} ) >> That just output an empty message... >> > This works for me. Try this simple CMakeLists.txt file: > > set( PROJECT tryme ) > message( ${CMAKE_CURRENT_SOURCE_DIR} ) > > -- > Gonzalo Garramu?o > From matthias.goesswein at eeas.at Mon Oct 30 17:13:20 2017 From: matthias.goesswein at eeas.at (=?UTF-8?Q?G=c3=b6=c3=9fwein_Matthias_/_eeas_gmbh?=) Date: Mon, 30 Oct 2017 22:13:20 +0100 Subject: [CMake] Problem with forced response files (Ninja) Message-ID: Hello, I'm currently trying to add support for the Tasking Compiler to CMake. Actually i have a working solution (without response files), but if i want to use response files, then i have a problem. The Tasking compiler expects "-f" as a flag instead of "@". I use the ninja generator and have set the following variables: SET(CMAKE_C_USE_RESPONSE_FILE_FOR_OBJECTS 1) SET(CMAKE_C_RESPONSE_FILE_LINK_FLAG "-f") SET(CMAKE_NINJA_FORCE_RESPONSE_FILE 1) # I'd like to force it But during Compiler Detection phase i get an error because CMake uses still the "@" as a flog for the response files: -- Check for working C compiler: D:/Projects/Tools/Tasking/01_00_00/ctc/bin/cctc.exe -- broken CMake Error at D:/Projects/Tools/CMake/03_01_00/share/cmake-3.6/Modules/CMakeTestCCompiler.cmake:61 (message): The C compiler "D:/Projects/Tools/Tasking/01_00_00/ctc/bin/cctc.exe" is not able to compile a simple test program. It fails with the following output: Change Dir: D:/Projects/Software/Projects/EC23MA/Trunk/EC23MA/Gen/CMakeFiles/CMakeTmp Run Build Command:"D:/Projects/Tools/Ninja/01_00_00/ninja.exe" "cmTC_31d94" [1/2] Building C object CMakeFiles\cmTC_31d94.dir\testCCompiler.c.o FAILED: CMakeFiles/cmTC_31d94.dir/testCCompiler.c.o cmd.exe /C "D:\Projects\Tools\Tasking\01_00_00\ctc\bin\cctc.exe -c testCCompiler.c *@**CMakeFiles\cmTC_31d94.dir\testCCompiler.c.o.rsp* --dep-file=CMakeFiles\cmTC_31d94.dir\testCCompiler.c.o.d -Wc--make-target=CMakeFiles\cmTC_31d94.dir\testCCompiler.c.o -o CMakeFiles\cmTC_31d94.dir\testCCompiler.c.o && "d:/Projects/Tools/CMake/03_01_00/bin/cmake.exe" -DDEPFILE="CMakeFiles\cmTC_31d94.dir\testCCompiler.c.o.d" -DOBJECT="CMakeFiles\cmTC_31d94.dir\testCCompiler.c.o" -P "D:/Projects/Software/Projects/EC23MA/Trunk/EC23MA/Gen/CMakeFiles/CMakeTmp/ninja_tasking_depfile_workaround.cmake"" cctc E205: don't know what to do with @CMakeFiles\cmTC_31d94.dir\testCCompiler.c.o.rsp ninja: build stopped: subcommand failed. Is there any other variable which i should set or is this a CMake issue? Best regards, Matthias Goesswein -- Matthias Goesswein -------------- next part -------------- An HTML attachment was scrubbed... URL: From boxerab at gmail.com Mon Oct 30 21:34:38 2017 From: boxerab at gmail.com (Aaron Boxer) Date: Mon, 30 Oct 2017 21:34:38 -0400 Subject: [CMake] Change compiler for certain files in the project In-Reply-To: <61E6AE4E-1A6B-4DA8-A3D1-56889E25A420@yahoo.com> References: <61E6AE4E-1A6B-4DA8-A3D1-56889E25A420@yahoo.com> Message-ID: On Sat, Oct 28, 2017 at 11:22 AM, P F wrote: > > > On Oct 28, 2017, at 9:50 AM, Aaron Boxer wrote: > > > > Hello, > > > > I have a cmake project on linux, and I would like to change the compiler > > for certain files from g++ to another, llvm-based compiler called hcc. > > (hcc is AMDs HIP compiler for GPGPU) > > > > > > Is there a way of doing this in my cmake file ? > > There isn?t a simple way to do that. The FindCUDA and FindHIP cmake > modules do that, but its not at all easy to follow, and brings its own set > of issues. > > Of course, why do you need to use g++ to compile host code? Being > clang-based hcc should be able to compile any g++ code. So you can just use > hcc as the compiler for everything and then link with the `hccrt` cmake > target(provided by `find_package(hcc)`) which will enable GPU compiling > when you want to compile code for the device. > Yes, I just might do that. I didn't realize there was a find_package for hcc. So, how would I set hcc as the compiler for everything ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From boxerab at gmail.com Mon Oct 30 21:35:15 2017 From: boxerab at gmail.com (Aaron Boxer) Date: Mon, 30 Oct 2017 21:35:15 -0400 Subject: [CMake] Change compiler for certain files in the project In-Reply-To: References: <61E6AE4E-1A6B-4DA8-A3D1-56889E25A420@yahoo.com> Message-ID: On Mon, Oct 30, 2017 at 11:18 AM, Thompson, KT wrote: > Aaron, > > Another way to do this is by using external project, but it is very > 'hacky'. A good place to look for examples is CMake's own > AddCMakeFortranSubdirectory features. This is designed to allow Fortran to > be compiled with MinGW when the main project uses a VisualStudio generator. > The same general logic would work to allow you to process a subdirectory > with a different toolchain. > Thanks, I will look into this as one option. Aaron > -----Original Message----- > From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of P F via CMake > Sent: Saturday, October 28, 2017 9:22 AM > To: Aaron Boxer > Cc: cmake > Subject: Re: [CMake] Change compiler for certain files in the project > > > > On Oct 28, 2017, at 9:50 AM, Aaron Boxer wrote: > > > > Hello, > > > > I have a cmake project on linux, and I would like to change the compiler > > for certain files from g++ to another, llvm-based compiler called hcc. > > (hcc is AMDs HIP compiler for GPGPU) > > > > > > Is there a way of doing this in my cmake file ? > > There isn?t a simple way to do that. The FindCUDA and FindHIP cmake > modules do that, but its not at all easy to follow, and brings its own set > of issues. > > Of course, why do you need to use g++ to compile host code? Being > clang-based hcc should be able to compile any g++ code. So you can just use > hcc as the compiler for everything and then link with the `hccrt` cmake > target(provided by `find_package(hcc)`) which will enable GPU compiling > when you want to compile code for the device. > > > -- > > 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 briadam at sandia.gov Tue Oct 31 14:17:06 2017 From: briadam at sandia.gov (Adams, Brian M) Date: Tue, 31 Oct 2017 18:17:06 +0000 Subject: [CMake] Check if C++11 flag / standard was indeed found Message-ID: <31340603577c45c387e9d5faeed75355@ES06AMSNLNT.srn.sandia.gov> Longer term, I plan to follow better practice and include compiler language feature checks for specific C++11 features and let CMake deduce the necessary language standard. In the meantime, I'm trying to implement a stopgap solution to warn the user if CMake doesn't know how to add a C++11 flag for the CMAKE_CXX_COMPILER in use, so they can add it themselves. For example, CMake C++11 support for Intel wasn't added until 3.6, but a user could still use CMake 3.1 to build our software if they explicitly add the "-std=c++11" flag. I'm setting CMAKE_CXX_STANDARD=11 CMAKE_CXX_STANDARD_REQUIRED=TRUE My hope was that if the CMake version in use doesn't know how to add the necessary C++11 compile flag, that this would result in an error, but it doesn't seem to. Is there a way I can detect whether CMake was able to add the necessary C++11 flag, rather than letting the build run forward until a compile failure? My fallback plan might be some conditionals that check specific (CMAKE_CXX_COMPILER_ID, CMAKE_VERSION) pairs and warn the user for cases where that version of CMake doesn't have -CXX-FeatureTests.cmake (which I'm assuming is an indicator of being able to add the C++11 compile flags for that compiler ID...) Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From pfultz2 at yahoo.com Tue Oct 31 17:38:15 2017 From: pfultz2 at yahoo.com (paul) Date: Tue, 31 Oct 2017 16:38:15 -0500 Subject: [CMake] Change compiler for certain files in the project In-Reply-To: References: <61E6AE4E-1A6B-4DA8-A3D1-56889E25A420@yahoo.com> Message-ID: <1509485895.4001.69.camel@yahoo.com> On Mon, 2017-10-30 at 21:34 -0400, Aaron Boxer wrote: > > > On Sat, Oct 28, 2017 at 11:22 AM, P F wrote: > > > > > On Oct 28, 2017, at 9:50 AM, Aaron Boxer wrote: > > > > > > Hello, > > > > > > I have a cmake project on linux, and I would like to change the compiler > > > for certain files from g++ to? another, llvm-based compiler called hcc. > > > (hcc is AMDs HIP compiler for GPGPU) > > > > > > > > > Is there a way of doing this in my cmake file ? > > > > There isn?t a simple way to do that. The FindCUDA and FindHIP cmake > > modules do that, but its not at all easy to follow, and brings its own set > > of issues. > > > > Of course, why do you need to use g++ to compile host code? Being clang- > > based hcc should be able to compile any g++ code. So you can just use hcc > > as the compiler for everything and then link with the `hccrt` cmake > > target(provided by `find_package(hcc)`) which will enable GPU compiling > > when you want to compile code for the device. > Yes, I just might do that. I didn't realize there was a find_package for > hcc.? Yes there is. If you are using AMD's repo from repo.radeon.com, then you will need to call it with: `find_package(hcc PATHS /opt/rocm/hcc)` as its not installed in the standard /usr location. > So, how would I set hcc as the compiler for everything ? I usually set it like this when I first run cmake: CXX=hcc cmake .. From robert.maynard at kitware.com Tue Oct 31 19:27:23 2017 From: robert.maynard at kitware.com (Robert Maynard) Date: Tue, 31 Oct 2017 19:27:23 -0400 Subject: [CMake] Check if C++11 flag / standard was indeed found In-Reply-To: <31340603577c45c387e9d5faeed75355@ES06AMSNLNT.srn.sandia.gov> References: <31340603577c45c387e9d5faeed75355@ES06AMSNLNT.srn.sandia.gov> Message-ID: Hi, CMake itself does this kind of inspection inside the CompileFlags.cmake file ( https://gitlab.kitware.com/cmake/cmake/blob/v3.9.3/CompileFlags.cmake#L62 ). While this exact example is for sunpro, it should be a good example of how to make a similar check for Intel. On Tue, Oct 31, 2017 at 2:17 PM, Adams, Brian M wrote: > Longer term, I plan to follow better practice and include compiler language > feature checks for specific C++11 features and let CMake deduce the > necessary language standard. > > > > In the meantime, I?m trying to implement a stopgap solution to warn the user > if CMake doesn?t know how to add a C++11 flag for the CMAKE_CXX_COMPILER in > use, so they can add it themselves. For example, CMake C++11 support for > Intel wasn?t added until 3.6, but a user could still use CMake 3.1 to build > our software if they explicitly add the ?-std=c++11? flag. > > > > I?m setting > > CMAKE_CXX_STANDARD=11 > > CMAKE_CXX_STANDARD_REQUIRED=TRUE > > > > My hope was that if the CMake version in use doesn?t know how to add the > necessary C++11 compile flag, that this would result in an error, but it > doesn?t seem to. > > > > Is there a way I can detect whether CMake was able to add the necessary > C++11 flag, rather than letting the build run forward until a compile > failure? > > > > My fallback plan might be some conditionals that check specific > (CMAKE_CXX_COMPILER_ID, CMAKE_VERSION) pairs and warn the user for cases > where that version of CMake doesn?t have -CXX-FeatureTests.cmake (which > I?m assuming is an indicator of being able to add the C++11 compile flags > for that compiler ID?) > > > > 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