From rcdailey.lists at gmail.com Tue Nov 1 09:38:38 2016 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Tue, 1 Nov 2016 08:38:38 -0500 Subject: [CMake] [cmake-developers] CMake integration in Gradle (Android Studio) In-Reply-To: <267ae9a6-d4bb-accc-7617-76d2ded27c46@gmail.com> References: <267ae9a6-d4bb-accc-7617-76d2ded27c46@gmail.com> Message-ID: Florent, I had the same thoughts. It seems that the CMake generate + build step happen silently as a prerequisite step when doing the 'gradle build' command somewhere. It makes it appear as if CMake is not running at all, but instead the Java piece of the build is just taking forever. Really I want to get away from ant / eclipse, but unlike Android Studio, at least in Eclipse I can view C++ code and edit it. I don't know of any other IDE I can use to edit both java & android code. My last shining hope is perhaps Visual Studio 2015 and their Android support. They have a fork of the CMake repository with some changes for generating Android IDE projects for VS, I have not tried it though. What a giant mess this has become... I have no idea what direction to go on this. Advice on tooling combinations you guys are using would be very helpful though. On Mon, Oct 31, 2016 at 5:04 PM, Florent Castelli wrote: > I tried the Gradle + CMake integration and I'm not really impressed. > I would recommend not using it right now until they fix the rough edges. > > The prime concern is that it is REALLY hard to get the CMake output and > compilation output, > even within Android Studio. If you compile from command line, you won't see > much. > This is a no go for CI environments where you need to see what went wrong > and also some > output once in a while (or builds are usually considered stuck and canceled > if they take too long). > See the issue: https://code.google.com/p/android/issues/detail?id=210930 > > Installing CMake within the SDK is not trivial. There's an open bug with a > proposed solution, > it's not pretty stuff but does the work: > https://code.google.com/p/android/issues/detail?id=221907 > An alternative would be to repackage your SDK folder after running Android > Studio and installing > everything you need and distribute that to your CI build machines / > developer machines. > > But essentially, what you want is probably just use their toolchain file, > which is much better > than the OpenCV one. You can find it bundled in the latest NDK and I guess > you could be using > that directly with CMake. If it is doing weird things, I guess you could > have a look at it and debug it. > It's not as complicated as the OpenCV one and I hope you'll find the > solution to your issues! > > As for CMake 3.7, when I asked about it in this mailing list, someone said > there will be > a compatibility layer to the toolchain to reuse the upstream support when > it's available > if I remember correctly. > > /Florent > > > On 25/10/2016 15:48, Robert Dailey wrote: >> >> I'm not sure if the CMake mailing lists are the right place to ask >> this question but I thought I'd ask just in case someone has gone down >> this path or has experience with what Google/Gradle is actually trying >> to accomplish with what seems to be a hand-built version of CMake with >> custom patches that are not in upstream repositories. >> >> Prior to switching to Android Studio / Gradle, I was using Eclipse / >> Ant. The way I did CMake integration was not really integration at >> all: I generated Ninja build scripts using CMake and implemented >> custom targets to run "ant release" after all the C++ projects were >> built. I made sure that CMake copied relevant *.so files to >> appropriate directories in the Ant structure so they are packaged with >> built APKs. That's how I did my Android development. >> >> Now that I'm integrating CMake into Gradle, first annoyance I noticed >> is that I can't use CMake 3.7 (or any external installation of CMake) >> with Android Studio. It requires a version of CMake installed through >> SDK Manager. This means I can't use the new Android toolchain >> functionality built into CMake 3.7 (sad face). But this is something I >> can work around... >> >> Next I found out that stuff I'm setting in my CMake scripts, such as >> CPP flags like `-std=c++14` and `-fexceptions` was not being applied. >> For whatever reason, Gradle is overriding these from the command line >> (I'm guessing?). So this requires me to duplicate the toolchain / >> compiler flag setup I already do in my CMake scripts now in the Gradle >> build scripts. This seems completely unnecessary and a maintenance >> burden. >> >> What I was expecting Gradle to do was essentially provide me some >> toolchain file so that CMake can find the compiler and linker to use >> and then the rest would be determined by CMake itself. >> >> Is there a way I can tell Gradle to not take so much control over >> compiler flags? I want my CMake scripts to do this. I can't imagine >> they had a good reason to do this. What have others done in this >> situation with their own Gradle + CMake integration? Looking for >> advice here, since information is sparse, especially since the Android >> Studio 2.2 CMake integration is relatively new stuff. > > > From congzhangzh at gmail.com Tue Nov 1 11:12:16 2016 From: congzhangzh at gmail.com (Cong Monkey) Date: Tue, 1 Nov 2016 23:12:16 +0800 Subject: [CMake] CMake integration in Gradle (Android Studio) In-Reply-To: References: Message-ID: My Android Studio Version Info: Android Studio 2.2.1 Build #AI-145.3330264, built on October 6, 2016 May be the more import part is cmake version, I have two which all works: ~/Android/Sdk/cmake/3.6.3155560 ~/Android/Sdk/cmake/3.6.3133135 hope this will be help:) 2016-10-31 22:13 GMT+08:00 Robert Dailey : > I'm sorry but that doesn't really answer my questions. > > On Mon, Oct 31, 2016 at 8:55 AM, Cong Monkey wrote: >> Try to update your Android SDK from android studio? >> >> >> 2016?10?31? 21:31?"Robert Dailey" ??? >> >> Which version of Android Studio? Latest stable is 2.2 IIRC. Are you >> talking about dev/beta builds? >> >> On Sun, Oct 30, 2016 at 9:04 AM, Cong Monkey wrote: >>> The latest release of android studio work with CMAKE well. >>> >>> you can create a new project with c++ support to test CMAKE support! >>> >>> You can follow https://code.google.com/p/android/issues/detail?id=212007 >>> to get the details. >>> >>> 2016-10-28 5:48 GMT+08:00 Robert Dailey : >>>> I'm at a bit of a loss on finding more information. Can anyone at >>>> least confirm that this isn't a reliable place to find the answers I'm >>>> looking for? Does anyone have real experience with android + gradle + >>>> cmake integration and can provide some pointers? >>>> >>>> On Tue, Oct 25, 2016 at 8:48 AM, Robert Dailey >>>> wrote: >>>>> I'm not sure if the CMake mailing lists are the right place to ask >>>>> this question but I thought I'd ask just in case someone has gone down >>>>> this path or has experience with what Google/Gradle is actually trying >>>>> to accomplish with what seems to be a hand-built version of CMake with >>>>> custom patches that are not in upstream repositories. >>>>> >>>>> Prior to switching to Android Studio / Gradle, I was using Eclipse / >>>>> Ant. The way I did CMake integration was not really integration at >>>>> all: I generated Ninja build scripts using CMake and implemented >>>>> custom targets to run "ant release" after all the C++ projects were >>>>> built. I made sure that CMake copied relevant *.so files to >>>>> appropriate directories in the Ant structure so they are packaged with >>>>> built APKs. That's how I did my Android development. >>>>> >>>>> Now that I'm integrating CMake into Gradle, first annoyance I noticed >>>>> is that I can't use CMake 3.7 (or any external installation of CMake) >>>>> with Android Studio. It requires a version of CMake installed through >>>>> SDK Manager. This means I can't use the new Android toolchain >>>>> functionality built into CMake 3.7 (sad face). But this is something I >>>>> can work around... >>>>> >>>>> Next I found out that stuff I'm setting in my CMake scripts, such as >>>>> CPP flags like `-std=c++14` and `-fexceptions` was not being applied. >>>>> For whatever reason, Gradle is overriding these from the command line >>>>> (I'm guessing?). So this requires me to duplicate the toolchain / >>>>> compiler flag setup I already do in my CMake scripts now in the Gradle >>>>> build scripts. This seems completely unnecessary and a maintenance >>>>> burden. >>>>> >>>>> What I was expecting Gradle to do was essentially provide me some >>>>> toolchain file so that CMake can find the compiler and linker to use >>>>> and then the rest would be determined by CMake itself. >>>>> >>>>> Is there a way I can tell Gradle to not take so much control over >>>>> compiler flags? I want my CMake scripts to do this. I can't imagine >>>>> they had a good reason to do this. What have others done in this >>>>> situation with their own Gradle + CMake integration? Looking for >>>>> advice here, since information is sparse, especially since the Android >>>>> Studio 2.2 CMake integration is relatively new stuff. >>>> -- >>>> >>>> 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 congzhangzh at gmail.com Tue Nov 1 11:30:03 2016 From: congzhangzh at gmail.com (Cong Monkey) Date: Tue, 1 Nov 2016 23:30:03 +0800 Subject: [CMake] [cmake-developers] CMake integration in Gradle (Android Studio) In-Reply-To: References: <267ae9a6-d4bb-accc-7617-76d2ded27c46@gmail.com> Message-ID: It's my experience which maybe help. I love Android Studio for its jetbrains style coding experience, but with some bad style I don't like, like so frequency update and so many experiment feature which sometimes is a good part like CMake support! I just love coding and focus my project, but the none product ready feature make me must fix some ide problem, SDK problem, config problem is really bad! So I use CLion to do most c++ related idea test which is mainly focus c++ native part, and test mix program in a simple java program, all the technology I use is CMake with CMake Swig support and CMake Java support which works well in CLion After the c++ part test is finish, I rewrite some code( mostly just copy from clion project) in Android Studio(this make c++ related works easy in the c++ unfriendly support environment), and then focus on java side. If c++ part has problem I will reenter the workflow to test idea in CLion again. My current working android project use CMake with CMake Swig support, it's really works great! Hope this help:) 2016-11-01 21:38 GMT+08:00 Robert Dailey : > Florent, I had the same thoughts. It seems that the CMake generate + > build step happen silently as a prerequisite step when doing the > 'gradle build' command somewhere. It makes it appear as if CMake is > not running at all, but instead the Java piece of the build is just > taking forever. > > Really I want to get away from ant / eclipse, but unlike Android > Studio, at least in Eclipse I can view C++ code and edit it. I don't > know of any other IDE I can use to edit both java & android code. My > last shining hope is perhaps Visual Studio 2015 and their Android > support. They have a fork of the CMake repository with some changes > for generating Android IDE projects for VS, I have not tried it > though. > > What a giant mess this has become... I have no idea what direction to > go on this. Advice on tooling combinations you guys are using would be > very helpful though. > > On Mon, Oct 31, 2016 at 5:04 PM, Florent Castelli > wrote: >> I tried the Gradle + CMake integration and I'm not really impressed. >> I would recommend not using it right now until they fix the rough edges. >> >> The prime concern is that it is REALLY hard to get the CMake output and >> compilation output, >> even within Android Studio. If you compile from command line, you won't see >> much. >> This is a no go for CI environments where you need to see what went wrong >> and also some >> output once in a while (or builds are usually considered stuck and canceled >> if they take too long). >> See the issue: https://code.google.com/p/android/issues/detail?id=210930 >> >> Installing CMake within the SDK is not trivial. There's an open bug with a >> proposed solution, >> it's not pretty stuff but does the work: >> https://code.google.com/p/android/issues/detail?id=221907 >> An alternative would be to repackage your SDK folder after running Android >> Studio and installing >> everything you need and distribute that to your CI build machines / >> developer machines. >> >> But essentially, what you want is probably just use their toolchain file, >> which is much better >> than the OpenCV one. You can find it bundled in the latest NDK and I guess >> you could be using >> that directly with CMake. If it is doing weird things, I guess you could >> have a look at it and debug it. >> It's not as complicated as the OpenCV one and I hope you'll find the >> solution to your issues! >> >> As for CMake 3.7, when I asked about it in this mailing list, someone said >> there will be >> a compatibility layer to the toolchain to reuse the upstream support when >> it's available >> if I remember correctly. >> >> /Florent >> >> >> On 25/10/2016 15:48, Robert Dailey wrote: >>> >>> I'm not sure if the CMake mailing lists are the right place to ask >>> this question but I thought I'd ask just in case someone has gone down >>> this path or has experience with what Google/Gradle is actually trying >>> to accomplish with what seems to be a hand-built version of CMake with >>> custom patches that are not in upstream repositories. >>> >>> Prior to switching to Android Studio / Gradle, I was using Eclipse / >>> Ant. The way I did CMake integration was not really integration at >>> all: I generated Ninja build scripts using CMake and implemented >>> custom targets to run "ant release" after all the C++ projects were >>> built. I made sure that CMake copied relevant *.so files to >>> appropriate directories in the Ant structure so they are packaged with >>> built APKs. That's how I did my Android development. >>> >>> Now that I'm integrating CMake into Gradle, first annoyance I noticed >>> is that I can't use CMake 3.7 (or any external installation of CMake) >>> with Android Studio. It requires a version of CMake installed through >>> SDK Manager. This means I can't use the new Android toolchain >>> functionality built into CMake 3.7 (sad face). But this is something I >>> can work around... >>> >>> Next I found out that stuff I'm setting in my CMake scripts, such as >>> CPP flags like `-std=c++14` and `-fexceptions` was not being applied. >>> For whatever reason, Gradle is overriding these from the command line >>> (I'm guessing?). So this requires me to duplicate the toolchain / >>> compiler flag setup I already do in my CMake scripts now in the Gradle >>> build scripts. This seems completely unnecessary and a maintenance >>> burden. >>> >>> What I was expecting Gradle to do was essentially provide me some >>> toolchain file so that CMake can find the compiler and linker to use >>> and then the rest would be determined by CMake itself. >>> >>> Is there a way I can tell Gradle to not take so much control over >>> compiler flags? I want my CMake scripts to do this. I can't imagine >>> they had a good reason to do this. What have others done in this >>> situation with their own Gradle + CMake integration? Looking for >>> advice here, since information is sparse, especially since the Android >>> Studio 2.2 CMake integration is relatively new stuff. >> >> >> > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake-developers From jack.stalnaker at gmail.com Tue Nov 1 14:12:22 2016 From: jack.stalnaker at gmail.com (Jack Stalnaker) Date: Tue, 1 Nov 2016 13:12:22 -0500 Subject: [CMake] Cannot generate a safe runtime search path with mex and matlab Message-ID: I am running into an error "Cannot generate a sage runtime search path for target xxxx because files in some directories may conflict with libraries in implicit directories." I understand from the error message why this is happening, but I'm not certain how to get around it. In my CMakeLists.txt file, I have: matlab_add_mex(NAME xxxx SRC xxxx.c LINK_TO foo baz) and the problem is that foo is a shared lib that links to the HDF5 library. However, matlab is bundled with its own copy of the HDF5 library, in a path automatically added by FindMatlab.cmake. Foo and baz are built elsewhere, and are imported using the config variant of find_package(). How can I get around this issue? Thanks, --Jack -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike.jackson at bluequartz.net Tue Nov 1 20:27:49 2016 From: mike.jackson at bluequartz.net (Michael Jackson) Date: Tue, 1 Nov 2016 20:27:49 -0400 Subject: [CMake] Visual Studio and Intel Fortran with Mixed C/F90 files not working Message-ID: I have a project that I am configuring with Visual Studio 12 2013 Win64 and Intel Fortran v16/v17. I have executables where there is both a .cpp file and a .f90 file. The .f90 file is not compiled when I compile the solution. If I use NMake Makefiles everything compiles, links and executes just fine. Has any seen anything like this? CMake 3.5.1 on Windows 10 environment. Thanks _________________________________________________________ Mike Jackson mike.jackson at bluequartz.net BlueQuartz Software www.bluequartz.net Principal Software Engineer Dayton, Ohio -------------- next part -------------- An HTML attachment was scrubbed... URL: From congzhangzh at gmail.com Tue Nov 1 23:08:56 2016 From: congzhangzh at gmail.com (Cong Monkey) Date: Wed, 2 Nov 2016 11:08:56 +0800 Subject: [CMake] CMake integration in Gradle (Android Studio) In-Reply-To: References: Message-ID: I have got many compliant that cmake support is not work with even the new Android Studio, but it is really works for me. I try ldd on cmake which Android SDK provided, all the so is resolved correct, which break before. So, I can imagine that maybe something related to my host environment , I use DEBIAN Stretch which updates very frequently. For debian Stretched, the libssl is 1.0.2 For debian Jessie, the libssl is 1.0.0 Is this the source problem? So why minor version change break it? As the upstream like cmake release fast, I really advice release static linked version to escape the library break problem which jetbrains product followed. Hope this help! 2016?10?31? 22:13?"Robert Dailey" ??? > I'm sorry but that doesn't really answer my questions. > > On Mon, Oct 31, 2016 at 8:55 AM, Cong Monkey > wrote: > > Try to update your Android SDK from android studio? > > > > > > 2016?10?31? 21:31?"Robert Dailey" ??? > > > > Which version of Android Studio? Latest stable is 2.2 IIRC. Are you > > talking about dev/beta builds? > > > > On Sun, Oct 30, 2016 at 9:04 AM, Cong Monkey > wrote: > >> The latest release of android studio work with CMAKE well. > >> > >> you can create a new project with c++ support to test CMAKE support! > >> > >> You can follow https://code.google.com/p/android/issues/detail?id= > 212007 > >> to get the details. > >> > >> 2016-10-28 5:48 GMT+08:00 Robert Dailey : > >>> I'm at a bit of a loss on finding more information. Can anyone at > >>> least confirm that this isn't a reliable place to find the answers I'm > >>> looking for? Does anyone have real experience with android + gradle + > >>> cmake integration and can provide some pointers? > >>> > >>> On Tue, Oct 25, 2016 at 8:48 AM, Robert Dailey < > rcdailey.lists at gmail.com> > >>> wrote: > >>>> I'm not sure if the CMake mailing lists are the right place to ask > >>>> this question but I thought I'd ask just in case someone has gone down > >>>> this path or has experience with what Google/Gradle is actually trying > >>>> to accomplish with what seems to be a hand-built version of CMake with > >>>> custom patches that are not in upstream repositories. > >>>> > >>>> Prior to switching to Android Studio / Gradle, I was using Eclipse / > >>>> Ant. The way I did CMake integration was not really integration at > >>>> all: I generated Ninja build scripts using CMake and implemented > >>>> custom targets to run "ant release" after all the C++ projects were > >>>> built. I made sure that CMake copied relevant *.so files to > >>>> appropriate directories in the Ant structure so they are packaged with > >>>> built APKs. That's how I did my Android development. > >>>> > >>>> Now that I'm integrating CMake into Gradle, first annoyance I noticed > >>>> is that I can't use CMake 3.7 (or any external installation of CMake) > >>>> with Android Studio. It requires a version of CMake installed through > >>>> SDK Manager. This means I can't use the new Android toolchain > >>>> functionality built into CMake 3.7 (sad face). But this is something I > >>>> can work around... > >>>> > >>>> Next I found out that stuff I'm setting in my CMake scripts, such as > >>>> CPP flags like `-std=c++14` and `-fexceptions` was not being applied. > >>>> For whatever reason, Gradle is overriding these from the command line > >>>> (I'm guessing?). So this requires me to duplicate the toolchain / > >>>> compiler flag setup I already do in my CMake scripts now in the Gradle > >>>> build scripts. This seems completely unnecessary and a maintenance > >>>> burden. > >>>> > >>>> What I was expecting Gradle to do was essentially provide me some > >>>> toolchain file so that CMake can find the compiler and linker to use > >>>> and then the rest would be determined by CMake itself. > >>>> > >>>> Is there a way I can tell Gradle to not take so much control over > >>>> compiler flags? I want my CMake scripts to do this. I can't imagine > >>>> they had a good reason to do this. What have others done in this > >>>> situation with their own Gradle + CMake integration? Looking for > >>>> advice here, since information is sparse, especially since the Android > >>>> Studio 2.2 CMake integration is relatively new stuff. > >>> -- > >>> > >>> 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 ramey at rrsd.com Wed Nov 2 01:01:57 2016 From: ramey at rrsd.com (Robert Ramey) Date: Tue, 1 Nov 2016 22:01:57 -0700 Subject: [CMake] CMake 3.6 and OSX In-Reply-To: References: Message-ID: Thanks for your help. I've managed to get past the original problem by editing FindBoost so that it checks for version 1.62. But I'm done yet! Now I'm getting compiler is AppleClang compiler is AppleClang [ /Applications/CMake.app/Contents/share/cmake-3.6/Modules/FindBoost.cmake:960 ] _boost_TEST_VERSIONS = 1.61.0;1.61;1.60.0;1.60;1.59.0;1.59;1.58.0;1.58;1.57.0;1.57;1.56.0;1.56;1.55.0;1.55;1.54.0;1.54;1.53.0;1.53;1.52.0;1.52;1.51.0;1.51;1.50.0;1.50;1.49.0;1.49;1.48.0;1.48;1.47.0;1.47;1.46.1;1.46.0;1.46;1.45.0;1.45;1.44.0;1.44;1.43.0;1.43;1.42.0;1.42;1.41.0;1.41;1.40.0;1.40;1.39.0;1.39;1.38.0;1.38;1.37.0;1.37;1.36.1;1.36.0;1.36;1.35.1;1.35.0;1.35;1.34.1;1.34.0;1.34;1.33.1;1.33.0;1.33 [ /Applications/CMake.app/Contents/share/cmake-3.6/Modules/FindBoost.cmake:962 ] Boost_USE_MULTITHREADED = ON [ /Applications/CMake.app/Contents/share/cmake-3.6/Modules/FindBoost.cmake:964 ] Boost_USE_STATIC_LIBS = ON [ /Applications/CMake.app/Contents/share/cmake-3.6/Modules/FindBoost.cmake:966 ] Boost_USE_STATIC_RUNTIME = [ /Applications/CMake.app/Contents/share/cmake-3.6/Modules/FindBoost.cmake:968 ] Boost_ADDITIONAL_VERSIONS = [ /Applications/CMake.app/Contents/share/cmake-3.6/Modules/FindBoost.cmake:970 ] Boost_NO_SYSTEM_PATHS = [ /Applications/CMake.app/Contents/share/cmake-3.6/Modules/FindBoost.cmake:1038 ] Declared as CMake or Environmental Variables: [ /Applications/CMake.app/Contents/share/cmake-3.6/Modules/FindBoost.cmake:1040 ] BOOST_ROOT = /Users/robertramey/WorkingProjects/modular-boost [ /Applications/CMake.app/Contents/share/cmake-3.6/Modules/FindBoost.cmake:1042 ] BOOST_INCLUDEDIR = [ /Applications/CMake.app/Contents/share/cmake-3.6/Modules/FindBoost.cmake:1044 ] BOOST_LIBRARYDIR = /Users/robertramey/WorkingProjects/modular-boost/stage/lib/Debug [ /Applications/CMake.app/Contents/share/cmake-3.6/Modules/FindBoost.cmake:1046 ] _boost_TEST_VERSIONS = 1.61.0;1.61;1.60.0;1.60;1.59.0;1.59;1.58.0;1.58;1.57.0;1.57;1.56.0;1.56;1.55.0;1.55;1.54.0;1.54;1.53.0;1.53;1.52.0;1.52;1.51.0;1.51;1.50.0;1.50;1.49.0;1.49;1.48.0;1.48;1.47.0;1.47;1.46.1;1.46.0;1.46;1.45.0;1.45;1.44.0;1.44;1.43.0;1.43;1.42.0;1.42;1.41.0;1.41;1.40.0;1.40;1.39.0;1.39;1.38.0;1.38;1.37.0;1.37;1.36.1;1.36.0;1.36;1.35.1;1.35.0;1.35;1.34.1;1.34.0;1.34;1.33.1;1.33.0;1.33 [ /Applications/CMake.app/Contents/share/cmake-3.6/Modules/FindBoost.cmake:1139 ] location of version.hpp: /Users/robertramey/WorkingProjects/modular-boost/boost/version.hpp [ /Applications/CMake.app/Contents/share/cmake-3.6/Modules/FindBoost.cmake:1163 ] version.hpp reveals boost 1.62.0 [ /Applications/CMake.app/Contents/share/cmake-3.6/Modules/FindBoost.cmake:1249 ] guessed _boost_COMPILER = [ /Applications/CMake.app/Contents/share/cmake-3.6/Modules/FindBoost.cmake:1259 ] _boost_MULTITHREADED = -mt [ /Applications/CMake.app/Contents/share/cmake-3.6/Modules/FindBoost.cmake:1302 ] _boost_RELEASE_ABI_TAG = - [ /Applications/CMake.app/Contents/share/cmake-3.6/Modules/FindBoost.cmake:1304 ] _boost_DEBUG_ABI_TAG = -d [ /Applications/CMake.app/Contents/share/cmake-3.6/Modules/FindBoost.cmake:1358 ] _boost_LIBRARY_SEARCH_DIRS_RELEASE = /Users/robertramey/WorkingProjects/modular-boost/stage/lib/Debug;/Users/robertramey/WorkingProjects/modular-boost/lib;/Users/robertramey/WorkingProjects/modular-boost/stage/lib;/Users/robertramey/WorkingProjects/modular-boost/lib;/Users/robertramey/WorkingProjects/modular-boost/../lib;/Users/robertramey/WorkingProjects/modular-boost/stage/lib;PATHS;C:/boost/lib;C:/boost;/sw/local/lib_boost_LIBRARY_SEARCH_DIRS_DEBUG = /Users/robertramey/WorkingProjects/modular-boost/stage/lib/Debug;/Users/robertramey/WorkingProjects/modular-boost/lib;/Users/robertramey/WorkingProjects/modular-boost/stage/lib;/Users/robertramey/WorkingProjects/modular-boost/lib;/Users/robertramey/WorkingProjects/modular-boost/../lib;/Users/robertramey/WorkingProjects/modular-boost/stage/lib;PATHS;C:/boost/lib;C:/boost;/sw/local/lib [ /Applications/CMake.app/Contents/share/cmake-3.6/Modules/FindBoost.cmake:1497 ] Searching for SYSTEM_LIBRARY_RELEASE: boost_system-mt-1_62;boost_system-mt;boost_system-mt-1_62;boost_system-mt;boost_system [ /Applications/CMake.app/Contents/share/cmake-3.6/Modules/FindBoost.cmake:1539 ] Searching for SYSTEM_LIBRARY_DEBUG: boost_system-mt-d-1_62;boost_system-mt-d;boost_system-mt-d-1_62;boost_system-mt-d;boost_system-mt;boost_system [ /Applications/CMake.app/Contents/share/cmake-3.6/Modules/FindBoost.cmake:1497 ] Searching for FILESYSTEM_LIBRARY_RELEASE: boost_filesystem-mt-1_62;boost_filesystem-mt;boost_filesystem-mt-1_62;boost_filesystem-mt;boost_filesystem [ /Applications/CMake.app/Contents/share/cmake-3.6/Modules/FindBoost.cmake:1539 ] Searching for FILESYSTEM_LIBRARY_DEBUG: boost_filesystem-mt-d-1_62;boost_filesystem-mt-d;boost_filesystem-mt-d-1_62;boost_filesystem-mt-d;boost_filesystem-mt;boost_filesystem [ /Applications/CMake.app/Contents/share/cmake-3.6/Modules/FindBoost.cmake:1609 ] Boost_FOUND = 1 CMake Error at /Applications/CMake.app/Contents/share/cmake-3.6/Modules/FindBoost.cmake:1767 (message): Unable to find the requested Boost libraries. Boost version: 1.62.0 Boost include path: /Users/robertramey/WorkingProjects/modular-boost Could not find the following static Boost libraries: boost_system boost_filesystem No Boost libraries were found. You may need to set BOOST_LIBRARYDIR to the directory containing Boost libraries or BOOST_ROOT to the location of Boost. Call Stack (most recent call first): CMakeLists.txt:113 (find_package) Boost_FOUND is 0 Boost NOT Found! The last messages is from my CMakelists.txt file which verifies that the variable Boost_USE_STATIC_LIBS is indeed set to true. Here is what I'm seeing: a) it looks like CMake is looking for boost_filesystem rather than libboost as I expect. (same for system). b) even if I tweak findBoost to force the system to look for libboost... it still fails b) If I follow the suggestion and set BOOST_ROOT to the boost root, it still doesn't work. The BOOST_ROOT variable is discarded when I invoke "Configure" So again, any suggestions you can offer will be appreciated. Robert Ramey From public at jayeshbadwaik.in Wed Nov 2 13:08:46 2016 From: public at jayeshbadwaik.in (Jayesh Badwaik) Date: Wed, 02 Nov 2016 18:08:46 +0100 Subject: [CMake] Building CMake without Curl Message-ID: <4483527.3k7gKi5Po5@wadner> Hi, Is there a way to build CMake without curl? I am currently in an environment where I have no openssl-dev packages nor libcurl-dev packages. So, if I want to build CMake, I will need to build openssl-dev myself which I do not want to do. I can ask my sysadmin for the packages, but I was wondering if there is another method. A follow up question would be, if this is not possible, why is libcurl essential to Cmake? -- Cheers Jayesh Badwaik https://www.jayeshbadwaik.in -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: This is a digitally signed message part. URL: From elizabeth.fischer at columbia.edu Wed Nov 2 13:57:41 2016 From: elizabeth.fischer at columbia.edu (Elizabeth A. Fischer) Date: Wed, 2 Nov 2016 13:57:41 -0400 Subject: [CMake] Building CMake without Curl In-Reply-To: <4483527.3k7gKi5Po5@wadner> References: <4483527.3k7gKi5Po5@wadner> Message-ID: Jayesh, Use Spack. Spack has no problem auto-building CMake for you, along with curl and whatever else it needs. https://github.com/llnl/spack/ -- Elizabeth On Wed, Nov 2, 2016 at 1:08 PM, Jayesh Badwaik wrote: > Hi, > > Is there a way to build CMake without curl? I am currently in an > environment > where I have no openssl-dev packages nor libcurl-dev packages. So, if I > want > to build CMake, I will need to build openssl-dev myself which I do not > want to > do. > > I can ask my sysadmin for the packages, but I was wondering if there is > another method. A follow up question would be, if this is not possible, > why is > libcurl essential to Cmake? > > > -- > Cheers > Jayesh Badwaik > https://www.jayeshbadwaik.in > -- > > 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 chuck.atkins at kitware.com Wed Nov 2 15:53:57 2016 From: chuck.atkins at kitware.com (Chuck Atkins) Date: Wed, 2 Nov 2016 15:53:57 -0400 Subject: [CMake] Building CMake without Curl In-Reply-To: <4483527.3k7gKi5Po5@wadner> References: <4483527.3k7gKi5Po5@wadner> Message-ID: Hi Jayesh, CMake includes internal versions of all the dependencies it needs to build. You have the option of using an external system-supplied version but it's certainly not required. Without OpenSSL you'll just have a cmake that can't use https, certainly not the end of the world. The default configuration of the ./bootstrap command should be using internal versions of all of CMake's dependencies. Is that causing problems for you? ---------- Chuck Atkins Staff R&D Engineer, Scientific Computing Kitware, Inc. On Wed, Nov 2, 2016 at 1:08 PM, Jayesh Badwaik wrote: > Hi, > > Is there a way to build CMake without curl? I am currently in an > environment > where I have no openssl-dev packages nor libcurl-dev packages. So, if I > want > to build CMake, I will need to build openssl-dev myself which I do not > want to > do. > > I can ask my sysadmin for the packages, but I was wondering if there is > another method. A follow up question would be, if this is not possible, > why is > libcurl essential to Cmake? > > > -- > Cheers > Jayesh Badwaik > https://www.jayeshbadwaik.in > -- > > 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 tiagomacarios at gmail.com Wed Nov 2 19:23:24 2016 From: tiagomacarios at gmail.com (Tiago Macarios) Date: Wed, 2 Nov 2016 16:23:24 -0700 Subject: [CMake] CPACK WIX shortcuts Message-ID: Hi, I am trying to create an installer with CPACK and WIX as generator. Everything works fine except that I cannot get start menu shortcuts to work. I was using almost the same code as the link below (which seems to be the unit tests for this feature), then I tried to build the unit test and I still don't see the shortcut directives on the wix files. Am I doing something wrong, or is this a regression? https://github.com/ngladitz/cmake-wix-testsuite/blob/d01013e2066e68088b4f56a8ab7750eb3cea7089/property_start_menu_shortcuts/CMakeLists.txt Tiago -------------- next part -------------- An HTML attachment was scrubbed... URL: From ramey at rrsd.com Thu Nov 3 01:12:25 2016 From: ramey at rrsd.com (Robert Ramey) Date: Wed, 2 Nov 2016 22:12:25 -0700 Subject: [CMake] How are modules tested? Message-ID: I've been having difficulties creating an Xcode project. In the course of this work, I've had occasion to investigate the FindBoost.cmake file. Looking at it - I don't see how it can possible work. On my system libraries are created libboost___abi.a and I don't see anything similar to this. Are there any test results I can look at to verify that this actually works? Robert Ramey From nilsgladitz at gmail.com Thu Nov 3 04:15:54 2016 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Thu, 3 Nov 2016 09:15:54 +0100 Subject: [CMake] CPACK WIX shortcuts In-Reply-To: References: Message-ID: On 11/03/2016 12:23 AM, Tiago Macarios wrote: > Hi, > > I am trying to create an installer with CPACK and WIX as generator. > Everything works fine except that I cannot get start menu shortcuts to > work. > > I was using almost the same code as the link below (which seems to be > the unit tests for this feature), then I tried to build the unit test > and I still don't see the shortcut directives on the wix files. > > Am I doing something wrong, or is this a regression? Which CMake version are you actually using? This feature was implemented in CMake 3.3.0. > > https://github.com/ngladitz/cmake-wix-testsuite/blob/d01013e2066e68088b4f56a8ab7750eb3cea7089/property_start_menu_shortcuts/CMakeLists.txt This still works for me using CMake 3.7.0-rc2. CMake 3.7.0-rc2's own windows installer uses the same feature for the start menu shortcut to the documentation which also seems to work for me. Nils From chuck.atkins at kitware.com Thu Nov 3 11:12:10 2016 From: chuck.atkins at kitware.com (Chuck Atkins) Date: Thu, 3 Nov 2016 11:12:10 -0400 Subject: [CMake] Building CMake without Curl In-Reply-To: <59131795.AUpKiImDiU@wadner> References: <4483527.3k7gKi5Po5@wadner> <59131795.AUpKiImDiU@wadner> Message-ID: It looks like you're using an existing configuration already set to use system installed libraries. Try from a clean source tree and an out-of-source (the recommend way to do all cmake things) build directory. Using the 3.6.2 tarball, I get: $ tar -xvf cmake-3.6.2.tar.gz ... lots of tar output ... $ mkdir cmake-3.6.2-build $ cd cmake-3.6.2-build $ ../cmake-3.6.2/bootstrap --prefix=../cmake-3.6.2-install --------------------------------------------- CMake 3.6.2, Copyright 2000-2016 Kitware, Inc. Found GNU toolchain C compiler on this system is: gcc C++ compiler on this system is: g++ Makefile processor on this system is: gmake g++ is GNU compiler g++ has setenv g++ has unsetenv g++ does not have environ in stdlib.h g++ has stl wstring --------------------------------------------- ... lots of compile output ... loading initial cache file /home/khq.kitware.com/chuck. atkins/Code/CMake/source/cmake-3.6.2-build/Bootstrap. cmk/InitialCacheFlags.cmake -- The C compiler identification is GNU 6.2.1 -- The CXX compiler identification is GNU 6.2.1 ... lots of cmake output ... --------------------------------------------- CMake has bootstrapped. Now run gmake. $ At this point, if you run "make help" then you'll get a list of available targets. In there, amongst others, you will see cmzlib, cmcurl, cmbzip2, cmliblzma, cmlibarchive, cmexpat, and cmjsoncpp. These are CMake's internal copies of the dependencies. When bootstrap is run with --system-libs then system versions of those dependencies will be used instead and the previously mentioned cm targets will not exist in the make help output. ---------- Chuck Atkins Staff R&D Engineer, Scientific Computing Kitware, Inc. On Thu, Nov 3, 2016 at 10:47 AM, Jayesh Badwaik wrote: > > CMake includes internal versions of all the dependencies it needs to > > build. You have the option of using an external system-supplied version > > but it's certainly not required. Without OpenSSL you'll just have a > cmake > > that can't use https, certainly not the end of the world. The default > > configuration of the ./bootstrap command should be using internal > versions > > of all of CMake's dependencies. Is that causing problems for you? > > Yes. The bootstrap command runs successfully, but after that it advises me > to > run gmake, which fails. I've attached the errors of the bootstrap command > and > the gmake command in this mail. > > -- > Cheers > Jayesh Badwaik > https://www.jayeshbadwaik.in > -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.maynard at kitware.com Thu Nov 3 12:32:38 2016 From: robert.maynard at kitware.com (Robert Maynard) Date: Thu, 3 Nov 2016 12:32:38 -0400 Subject: [CMake] [ANNOUNCE] CMake 3.6.3 available for download Message-ID: We are pleased to announce that CMake 3.6.3 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.6.3 since 3.6.2: Brad King (2): FindHDF5: Restore pre-3.6 behavior of finding only C by default CMake 3.6.3 Clinton Stimpson (1): cmake-gui: Do not remove library paths for Qt5 plugins. From tiagomacarios at gmail.com Thu Nov 3 14:32:47 2016 From: tiagomacarios at gmail.com (Tiago Macarios) Date: Thu, 3 Nov 2016 11:32:47 -0700 Subject: [CMake] CPACK WIX shortcuts In-Reply-To: References: Message-ID: Hi Nils, Here are all the versions of things involved: Windows10 1607 14393.351 cmake 3.6.3 wix 3.10.3 VS 2015 Update 3 14.0.25431.01 I modified the test to be self contained: ================================================== cmake_minimum_required(VERSION 3.6) add_executable(h-w hw.cpp) install(TARGETS h-w DESTINATION bin) install(FILES hw.cpp DESTINATION src) set_property(INSTALL "bin/$" PROPERTY CPACK_START_MENU_SHORTCUTS "Hello World" ) set_property(INSTALL "src/hw.cpp" PROPERTY CPACK_START_MENU_SHORTCUTS "Source Code" "Same Source Code" ) include(CPack) ================================================== And I am building it like so: mkdir build cd build cmake .. cmake --build . --config Release cpack -G WIX If I understood the test correctly I should have two folders in the start menu: - "Hello World" - "Source Code" I don't see any of them after installing. AFAICT no other new folders are created either. If I go into the folder with the WIX generated input I don't see any Shortcut directives http://wixtoolset.org/documentation/manual/v3/xsd/wix/shortcut.html cd _CPack_Packages/win32/WIX cat *wxs *wxi | grep Shortcut # Returns empty Also, if I open the msi with Orca I don't see the shortcut table. I am probably doing something wrong, if you could help me I would appreciate. Zip files with project + build folder is here: https://www.dropbox.com/s/4a889ijqnocllcb/wix.zip?dl=0 Tiago On Thu, Nov 3, 2016 at 1:15 AM, Nils Gladitz wrote: > On 11/03/2016 12:23 AM, Tiago Macarios wrote: > > Hi, >> >> I am trying to create an installer with CPACK and WIX as generator. >> Everything works fine except that I cannot get start menu shortcuts to work. >> >> I was using almost the same code as the link below (which seems to be the >> unit tests for this feature), then I tried to build the unit test and I >> still don't see the shortcut directives on the wix files. >> >> Am I doing something wrong, or is this a regression? >> > > Which CMake version are you actually using? > This feature was implemented in CMake 3.3.0. > > >> https://github.com/ngladitz/cmake-wix-testsuite/blob/d01013e >> 2066e68088b4f56a8ab7750eb3cea7089/property_start_menu_ >> shortcuts/CMakeLists.txt >> > > This still works for me using CMake 3.7.0-rc2. > > CMake 3.7.0-rc2's own windows installer uses the same feature for the > start menu shortcut to the documentation which also seems to work for me. > > Nils > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nilsgladitz at gmail.com Thu Nov 3 15:10:16 2016 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Thu, 3 Nov 2016 20:10:16 +0100 Subject: [CMake] CPACK WIX shortcuts In-Reply-To: References: Message-ID: <6a55131c-ccad-8a39-a0b8-81217e4b1da3@gmail.com> On 03.11.2016 19:32, Tiago Macarios wrote: > > > And I am building it like so: > mkdir build > cd build > cmake .. > cmake --build . --config Release > cpack -G WIX You are using a multi-configuration generator (Visual Studio). As you do in the build try specifying a configuration to be packaged when invoking cpack (the "PACKAGE" target that cmake generates does this by default): e.g. cpack -C Release -G WIX The install properties are only generated for the known configurations. Nils From drescherjm at gmail.com Thu Nov 3 18:04:10 2016 From: drescherjm at gmail.com (John Drescher) Date: Thu, 3 Nov 2016 18:04:10 -0400 Subject: [CMake] CMake 3.7.0-r2 Open Project sometimes picks wrong version of Visual Studio Message-ID: I opened a project in cmake-gui using the open project button from a vc 2010 build of a project. The open project opened the project in Visual Studio 2010. Later I opened the same project but a different build tree for Visual Studio 2013 CMake-gui had all of the correct information for the Visual Studio 2013 build but open project tried to open the Visual Studio 2013 solution in Visual Studio 2010 instead of the expected Visual Studio 2013. Is there a way to get/force this feature to reliably use the correct ide? Thanks, John From tiagomacarios at gmail.com Thu Nov 3 21:22:28 2016 From: tiagomacarios at gmail.com (Tiago Macarios) Date: Thu, 3 Nov 2016 18:22:28 -0700 Subject: [CMake] CPACK WIX shortcuts In-Reply-To: <6a55131c-ccad-8a39-a0b8-81217e4b1da3@gmail.com> References: <6a55131c-ccad-8a39-a0b8-81217e4b1da3@gmail.com> Message-ID: Yup that did it! Thanks! On Thu, Nov 3, 2016 at 12:10 PM, Nils Gladitz wrote: > On 03.11.2016 19:32, Tiago Macarios wrote: > >> >> >> And I am building it like so: >> mkdir build >> cd build >> cmake .. >> cmake --build . --config Release >> cpack -G WIX >> > > You are using a multi-configuration generator (Visual Studio). > > As you do in the build try specifying a configuration to be packaged when > invoking cpack (the "PACKAGE" target that cmake generates does this by > default): > e.g. cpack -C Release -G WIX > > The install properties are only generated for the known configurations. > > Nils > -------------- next part -------------- An HTML attachment was scrubbed... URL: From orcein at gmail.com Fri Nov 4 00:06:48 2016 From: orcein at gmail.com (B. Scott Harper) Date: Fri, 4 Nov 2016 13:06:48 +0900 Subject: [CMake] Change project name based on architecture Message-ID: I have a project where I manage multiple architectures and switch back and forth frequently for testing. Full disclosure, I'm using Visual Studio. And since I cannot generate a single solution with multiple architectures (per everything I've found searching Google and the mailing list), I have two separate solution files (one each for x86 and x64). I often open a solution using the recent solutions menu, and it would be a lot easier if I could name the solution (cmake's "project()" command) differently for each architecture I use. I tried simply if(${CMAKE_SIZEOF_VOID_P} EQUAL 8) set(PLATFORM_TARGET "x64") else() set(PLATFORM_TARGET "x86") endif() project(My_Project_${PLATFORM_TARGER}) ...however it seems that CMAKE_SIZEOF_VOID_P isn't filled out until AFTER the project command, so I can't use that variable as part of my project/solution name. Is there another way to accomplish this? Google only returns documentation on the project command in general and the above method seems to be the preferred means of detecting build architecture. Cheers, -- Scott -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric.noulard at gmail.com Fri Nov 4 02:50:37 2016 From: eric.noulard at gmail.com (Eric Noulard) Date: Fri, 4 Nov 2016 07:50:37 +0100 Subject: [CMake] Change project name based on architecture In-Reply-To: References: Message-ID: 2016-11-04 5:06 GMT+01:00 B. Scott Harper : > I have a project where I manage multiple architectures and switch back and > forth frequently for testing. Full disclosure, I'm using Visual Studio. And > since I cannot generate a single solution with multiple architectures (per > everything I've found searching Google and the mailing list), I have two > separate solution files (one each for x86 and x64). I often open a solution > using the recent solutions menu, and it would be a lot easier if I could > name the solution (cmake's "project()" command) differently for each > architecture I use. > > I tried simply > > if(${CMAKE_SIZEOF_VOID_P} EQUAL 8) > set(PLATFORM_TARGET "x64") > else() > set(PLATFORM_TARGET "x86") > endif() > > project(My_Project_${PLATFORM_TARGER}) > > ...however it seems that CMAKE_SIZEOF_VOID_P isn't filled out until AFTER > the project command, so I can't use that variable as part of my > project/solution name. > Yes this is a kind of chicken & eggs problem. The size of VOID_P may not be known before the arch+compiler is known and for that you need project (+ enable_langage) etc... Since you already use different CMake generator for your different may be you can check CMAKE_GENERATOR CMAKE_GENERATOR_PLATFORM CMAKE_GENERATOR_TOOLSET instead. I guess that those should be (I did not checked) defined before project command. > Is there another way to accomplish this? Google only returns documentation > on the project command in general and the above method seems to be the > preferred means of detecting build architecture. > This is a generator agnostic way to detect 32 vs 64 bits but You may have a look at CMAKE_SYSTEM_xxxx variables as well, but those may not be defined before enable language/project command as well. However CMAKE_GENERATOR_xxx matches should be enough to name your project properly I guess. -- Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.amaclean at gmail.com Fri Nov 4 02:57:13 2016 From: andrew.amaclean at gmail.com (Andrew Maclean) Date: Fri, 4 Nov 2016 17:57:13 +1100 Subject: [CMake] Building CMake using CMake 3.6.3 fails. Message-ID: Windows 10 64-bit using ninja, Qt 5.7 MSVC 2105. Building CMake with CMake 3.6.2 was OK. Now using CMake 3.6.3 I get the following message: CMake Error in Source/QtDialog/CMakeLists.txt: ------------------------- [0/1] Re-running CMake... -- cannot compile simplest ever MFC app, avoiding MFC test -- Configuring done CMake Error in Source/QtDialog/CMakeLists.txt: No known features for CXX compiler "MSVC" version 19.0.24215.1. CMake Error in Source/QtDialog/CMakeLists.txt: No known features for CXX compiler "MSVC" version 19.0.24215.1. ------------------------ -- ___________________________________________ Andrew J. P. Maclean ___________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.amaclean at gmail.com Fri Nov 4 03:23:31 2016 From: andrew.amaclean at gmail.com (Andrew Maclean) Date: Fri, 4 Nov 2016 18:23:31 +1100 Subject: [CMake] Building CMake using CMake 3.6.3 fails. In-Reply-To: References: Message-ID: To be more specific it only occurs when building the debug version of CMake. Release is OK. VTK builds and VTK Wiki examples are OK. On Fri, Nov 4, 2016 at 5:57 PM, Andrew Maclean wrote: > Windows 10 64-bit using ninja, Qt 5.7 MSVC 2105. > Building CMake with CMake 3.6.2 was OK. > Now using CMake 3.6.3 I get the following message: > CMake Error in Source/QtDialog/CMakeLists.txt: > ------------------------- > [0/1] Re-running CMake... > -- cannot compile simplest ever MFC app, avoiding MFC test > -- Configuring done > CMake Error in Source/QtDialog/CMakeLists.txt: > No known features for CXX compiler > > "MSVC" > > version 19.0.24215.1. > > > CMake Error in Source/QtDialog/CMakeLists.txt: > No known features for CXX compiler > > "MSVC" > > version 19.0.24215.1. > > ------------------------ > > -- > ___________________________________________ > Andrew J. P. Maclean > > ___________________________________________ > -- ___________________________________________ Andrew J. P. Maclean ___________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From mateusz.kijowski at gmail.com Fri Nov 4 06:49:59 2016 From: mateusz.kijowski at gmail.com (Mateusz Kijowski) Date: Fri, 4 Nov 2016 11:49:59 +0100 Subject: [CMake] License and copyright of https://cmake.org/Wiki/CMakeUserFindMySQL Message-ID: Hi, I am the maintainer of mydumper package in Debian. I want to include https://cmake.org/Wiki/CMakeUserFindMySQL in the package, but I would need to include copyright and licensing information for this file. Do you have some kind of policy for cases like this? Can I assume that Wiki content is also available under terms from https://gitlab.kitware.com/cmake/cmake/raw/master/Copyright.txt ? Please note that I have nomail enabled for list, so in order to reach me you will have to CC the message to me. Regards, Mateusz. From irwin at beluga.phys.uvic.ca Fri Nov 4 07:41:58 2016 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Fri, 4 Nov 2016 04:41:58 -0700 (PDT) Subject: [CMake] License and copyright of https://cmake.org/Wiki/CMakeUserFindMySQL In-Reply-To: References: Message-ID: On 2016-11-04 11:49+0100 Mateusz Kijowski wrote: > Hi, > > > I am the maintainer of mydumper package in Debian. I want to include > https://cmake.org/Wiki/CMakeUserFindMySQL in the package, but I would > need to include copyright and licensing information for this file. Do > you have some kind of policy for cases like this? Can I assume that > Wiki content is also available under terms from > https://gitlab.kitware.com/cmake/cmake/raw/master/Copyright.txt ? > > Please note that I have nomail enabled for list, so in order to > reach me you will have to CC the message to me. > > Regards, Hi Mateusz: I am not a license lawyer by any means, but your question concerning licensing aroused my curiosity so I took a look at that Wiki page. That page says "Content is available under Attribution2.5 unless otherwise noted", where "Attribution2.5" is a link to . The largely anonymous wiki creators (see history of that page where those that worked on this wiki item are mentioned by name with no further details) that created this CMakeUserFindMySQL content were apparently happy to abide by that default license for the Wiki content so if I were in your shoes, that particular Creative Commons license is the license I would mention for their work when you redistribute their work as part of a Debian package. 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 brad.king at kitware.com Fri Nov 4 14:55:33 2016 From: brad.king at kitware.com (Brad King) Date: Fri, 4 Nov 2016 14:55:33 -0400 Subject: [CMake] CMake 3.7.0-r2 Open Project sometimes picks wrong version of Visual Studio In-Reply-To: References: Message-ID: <63180e1a-32e1-8299-d4a9-c2e1578a53cb@kitware.com> On 11/03/2016 06:04 PM, John Drescher wrote: > I opened a project in cmake-gui using the open project button from a > vc 2010 build of a project. The open project opened the project in > Visual Studio 2010. Later I opened the same project but a different > build tree for Visual Studio 2013 CMake-gui had all of the correct > information for the Visual Studio 2013 build but open project tried to > open the Visual Studio 2013 solution in Visual Studio 2010 instead of > the expected Visual Studio 2013. Is there a way to get/force this > feature to reliably use the correct ide? The feature is new in 3.7 and was contributed here: cmake-gui: Add button to open the generated project https://gitlab.kitware.com/cmake/cmake/commit/1ca2d5d1 I'm not particularly familiar with how it works, but from a quick glance at the code it may be using file associations. If all that happened during a single cmake-gui session perhaps some state is not being cleaned up when changing build trees. -Brad From brad.king at kitware.com Fri Nov 4 14:58:11 2016 From: brad.king at kitware.com (Brad King) Date: Fri, 4 Nov 2016 14:58:11 -0400 Subject: [CMake] Building CMake using CMake 3.6.3 fails. In-Reply-To: References: Message-ID: <43dc245b-a8cd-1339-84c7-0fb5cf9b55e8@kitware.com> On 11/04/2016 03:23 AM, Andrew Maclean wrote: > To be more specific it only occurs when building the debug version of CMake. > Release is OK. VTK builds and VTK Wiki examples are OK. > > On Fri, Nov 4, 2016 at 5:57 PM, Andrew Maclean wrote: > > Windows 10 64-bit using ninja, Qt 5.7 MSVC 2105. > Building CMake with CMake 3.6.2 was OK. > Now using CMake 3.6.3 I get the following message: > CMake Error in Source/QtDialog/CMakeLists.txt: > ------------------------- > [0/1] Re-running CMake... > -- cannot compile simplest ever MFC app, avoiding MFC test > -- Configuring done > CMake Error in Source/QtDialog/CMakeLists.txt: > No known features for CXX compiler > > "MSVC" > > version 19.0.24215.1. Strange. There is almost no difference between 3.6.2 and 3.6.3: ``` $ git diff v3.6.2 v3.6.3 --stat |cat Modules/FindHDF5.cmake | 12 ++---------- Source/CMakeVersion.cmake | 2 +- Source/QtDialog/CMakeSetup.cxx | 2 ++ 3 files changed, 5 insertions(+), 11 deletions(-) ``` -Brad From robert.maynard at kitware.com Fri Nov 4 15:37:33 2016 From: robert.maynard at kitware.com (Robert Maynard) Date: Fri, 4 Nov 2016 15:37:33 -0400 Subject: [CMake] [ANNOUNCE] CMake 3.7.0-rc3 now ready for testing! Message-ID: I am proud to announce the third CMake 3.7 release candidate. https://cmake.org/download/ Documentation is available at: https://cmake.org/cmake/help/v3.7 Release notes appear below and are also published at https://cmake.org/cmake/help/v3.7/release/3.7.html Some of the more significant changes in CMake 3.7 are: * CMake now supports Cross Compiling for Android with simple toolchain files. * The "Ninja" generator learned to conditionally support Fortran when using a "ninja" tool that has the necessary features. See generator documentation for details. * The "if()" command gained new boolean comparison operations "LESS_EQUAL", "GREATER_EQUAL", "STRLESS_EQUAL", "STRGREATER_EQUAL", "VERSION_LESS_EQUAL", and "VERSION_GREATER_EQUAL". * The "try_compile()" command source file signature now honors configuration-specific flags (e.g. "CMAKE__FLAGS_DEBUG") in the generated test project. Previously only the default such flags for the current toolchain were used. See policy "CMP0066". * "Toolchain files" may now set "CMAKE_EXE_LINKER_FLAGS_INIT", "CMAKE_SHARED_LINKER_FLAGS_INIT", and "CMAKE_MODULE_LINKER_FLAGS_INIT" variables to initialize the "CMAKE_EXE_LINKER_FLAGS", "CMAKE_SHARED_LINKER_FLAGS", and "CMAKE_MODULE_LINKER_FLAGS" cache entries the first time a language is enabled in a build tree. * CTest now supports test fixtures through the new "FIXTURES_SETUP", "FIXTURES_CLEANUP" and "FIXTURES_REQUIRED" test properties. When using regular expressions or "--rerun-failed" to limit the tests to be run, a fixture's setup and cleanup tests will automatically be added to the execution set if any test requires that fixture. * We no longer provide Linux i386 binaries for download from "cmake.org" for new versions of CMake. * Vim support files "cmake-indent.vim", "cmake-syntax.vim", and "cmake-help.vim" have been removed in favor of the files now provided from the vim-cmake-syntax project. * Support for building CMake itself with some compilers was dropped: * Visual Studio 7.1 and 2005 -- superseded by VS 2008 and above * MinGW.org mingw32 -- superseded by MSYS2 mingw32 and mingw64 CMake still supports generating build systems for other projects using these compilers. CMake 3.7 Release Notes *********************** Changes made since CMake 3.6 include the following. New Features ============ Platforms --------- * CMake now supports Cross Compiling for Android with simple toolchain files. * The Clang compiler is now supported on AIX. Generators ---------- * The "Ninja" generator learned to conditionally support Fortran when using a "ninja" tool that has the necessary features. See generator documentation for details. * The "Ninja" generator learned to produce phony targets of the form "sub/dir/{test,install,package}" to drive the build of a subdirectory installation, test or packaging target. This is equivalent to "cd sub/dir; make {test,install,package}" with Makefile Generators. * The "Visual Studio 15" generator was added. This is experimental and based on Preview 4 because this version of VS has not been released. * Visual Studio Generators for VS 2010 and above learned to place ".natvis" source files into VS project files properly. * The "Xcode" generator's rudimentary Swift language support learned to honor a new "CMAKE_Swift_LANGUAGE_VERSION" variable to tell Xcode what version of Swift is used by the source. * The "CodeLite" generator gained a new "CMAKE_CODELITE_USE_TARGETS" option to change project creation from projects to targets. Commands -------- * The "add_custom_command()" command gained a new "DEPFILE" option that works with the "Ninja" generator to provide implicit dependency information to the build tool. * The "cmake_parse_arguments()" command gained a new "PARSE_ARGV" mode to read arguments directly from "ARGC" and "ARGV#" variables inside a "function()" body. * The "export()" command gained an "ANDROID_MK" option to generate "Android.mk" files referencing CMake-built libraries as prebuilts for the Android NDK build system. * The "file(DOWNLOAD)" and "file(UPLOAD)" commands gained "HTTPHEADER " and "USERPWD :" options. * The "find_library()" and "find_package()" commands learned to search in "lib32/" directories when the build targets a 32-bit architecture. See the "FIND_LIBRARY_USE_LIB32_PATHS" global property. * The "find_package()" command gained the possibility of sorting compatible libraries by "NAME" or by "NATURAL" sorting by setting the two new variables "CMAKE_FIND_PACKAGE_SORT_ORDER" and "CMAKE_FIND_PACKAGE_SORT_DIRECTION". * The "if()" command gained new boolean comparison operations "LESS_EQUAL", "GREATER_EQUAL", "STRLESS_EQUAL", "STRGREATER_EQUAL", "VERSION_LESS_EQUAL", and "VERSION_GREATER_EQUAL". * The "install()" command gained an "EXPORT_ANDROID_MK" subcommand to install "Android.mk" files referencing installed libraries as prebuilts for the Android NDK build system. * The "string(TIMESTAMP)" and "file(TIMESTAMP)" commands gained support for the "%a" and "%b" placeholders. These are the abbreviated weekday and month names. * The "try_compile()" command source file signature now honors configuration-specific flags (e.g. "CMAKE__FLAGS_DEBUG") in the generated test project. Previously only the default such flags for the current toolchain were used. See policy "CMP0066". Variables --------- * Variable "CMAKE_FIND_PACKAGE_SORT_ORDER" was added to control the sorting mode of the "find_package()" command. * Variable "CMAKE_FIND_PACKAGE_SORT_DIRECTION" was added to control the sorting direction the "find_package()" command. * "Toolchain files" may now set a "CMAKE__FLAGS_INIT" variable to initialize the "CMAKE__FLAGS" cache entry the first time a language is enabled in a build tree. * "Toolchain files" may now set "CMAKE_EXE_LINKER_FLAGS_INIT", "CMAKE_SHARED_LINKER_FLAGS_INIT", and "CMAKE_MODULE_LINKER_FLAGS_INIT" variables to initialize the "CMAKE_EXE_LINKER_FLAGS", "CMAKE_SHARED_LINKER_FLAGS", and "CMAKE_MODULE_LINKER_FLAGS" cache entries the first time a language is enabled in a build tree. Properties ---------- * On Apple platforms the "BUNDLE_EXTENSION" target property now also applies to Frameworks and App Bundles. * A "BINARY_DIR" directory property was added to get the absolute path to the binary directory corresponding to the source directory on which the property is read. * A "BUILDSYSTEM_TARGETS" directory property was added to get the list of logical buildsystem target names added by the project in a directory. * A "LINK_WHAT_YOU_USE" target property and supporting "CMAKE_LINK_WHAT_YOU_USE" variable were introduced to detect (on UNIX) shared libraries that are linked but not needed by running "ldd -r -u". * A "SOURCE_DIR" directory property was added to get the absolute path to the source directory associated with a directory. * A "SUBDIRECTORIES" directory property was added to get the list of subdirectories added by a project in a directory. * A "VS_SDK_REFERENCES" target property was added to tell Visual Studio Generators to reference the named SDKs. * A "VS_TOOL_OVERRIDE" source file property was created to tell Visual Studio Generators what tool to use for a source file. * The "WINDOWS_EXPORT_ALL_SYMBOLS" target property now applies to executable targets with the "ENABLE_EXPORTS" property set. * A "XCODE_FILE_ATTRIBUTES" source file property was added to tell the "Xcode" generator to generate custom content in the Xcode project attributes for the file. Modules ------- * An "AndroidTestUtilities" module was added to manage transfer of test data to an Android device. * The "CheckFortranSourceCompiles" module macro "CHECK_Fortran_SOURCE_COMPILES" gained a "SRC_EXT" option to specify a custom test Fortran source file extension. * The "ExternalProject" module gained "HTTP_USERNAME" and "HTTP_PASSWORD" options to set http download credentials. * The "ExternalProject" module gained a "HTTP_HEADER" option to add http download headers. * The "FindBISON" module "BISON_TARGET" macro learned a new "REPORT_FILE" option to specify the bison "--report-file=" option. * The "FindBZip2" module now provides imported targets. * A "FindICU" module was introduced to find the International Components for Unicode (ICU) libraries and programs. * The "FindMatlab" module learned to find the SIMULINK and MAT components. * The "FindMatlab" module "matlab_add_mex()" command learned to add executables and modules. * The "FindMatlab" module "matlab_add_unit_test()" command learned to support inline Matlab test code. * The "FindOpenCL" module now provides imported targets. * The "FindOpenMP" module learned to detect the OpenMP version (specification date) from the compiler. * A "FindVulkan" module was added. * The "GenerateExportHeader" module learned a new "CUSTOM_CONTENT_FROM_VARIABLE" option to specify a variable containing custom content for inclusion in the generated header. * The "GNUInstallDirs" module gained a new "GNUInstallDirs_get_absolute_install_dir()" command. * The "UseJava" module gained APIs to "export" jar targets for use by external CMake projects. See the "install_jar_exports" and "export_jars" functions. CTest ----- * CTest now supports test fixtures through the new "FIXTURES_SETUP", "FIXTURES_CLEANUP" and "FIXTURES_REQUIRED" test properties. When using regular expressions or "--rerun-failed" to limit the tests to be run, a fixture's setup and cleanup tests will automatically be added to the execution set if any test requires that fixture. * The "ctest_configure()", "ctest_build()", "ctest_test()", "ctest_coverage()", and "ctest_upload()" commands gained a new "CAPTURE_CMAKE_ERROR" option to capture any errors that occur as the commands run into a variable and avoid affecting the return code of the "ctest(1)" process. CPack ----- * CPack gained a "productbuild" generator on OS X, configured by the "CPackProductBuild" module. * CPack gained a new "CPACK_PACKAGE_CHECKSUM" variable to enable generation of a checksum file for each package file. * The "CPackDeb" module learned to support long file names when archive format is set to GNU tar. See "CPACK_DEBIAN_ARCHIVE_TYPE" * The "CPackIFW" module gained a new "cpack_ifw_add_package_resources()" command to include additional resources in the installer binary. * The "CPackIFW" module "cpack_ifw_configure_component()" and "cpack_ifw_configure_component_group()" commands gained a new "USER_INTERFACES" option to add a list of additonal pages to the IFW installer. * The "CPackRPM" module learned to generate debuginfo packages on demand. See "CPACK_RPM_DEBUGINFO_PACKAGE" and its per component version. * The "CPackRPM" module learned to generate source rpm (SRPM) packages on demand. See "CPACK_RPM_PACKAGE_SOURCES", "CPACK_RPM_SOURCE_PKG_BUILD_PARAMS" and "CPACK_RPM_SOURCE_PKG_PACKAGING_INSTALL_PREFIX". * The CPack NSIS generator now supports "CPACK_NSIS__INSTALL_DIRECTORY". This can be used to set component specific installation directories. * The CPack WIX generator now supports "CPACK_WIX_SKIP_PROGRAM_FOLDER" to allow specification of a custom absolute installation prefix outside of the ProgramFiles folders. * The CPack WIX generator now supports "CPACK_COMPONENT__DISABLED". This can be used to deselect a component from being installed by default. * The CPack WIX generator now supports "CPACK_WIX_PATCH_FILE" fragments for Feature elements. * The CPack WIX generator now supports "CPACK_WIX_ROOT_FEATURE_TITLE" and "CPACK_WIX_ROOT_FEATURE_DESCRIPTION" to allow the specification of a custom title and description for the root feature element. Other ----- * "cmake(1)" gained a "-E capabilities" option to provide a machine- readable (JSON) description of the capabilities of the cmake tool (available generators, etc.). * A new "cmake-server(7)" mode was added to provide semantic information about a CMake-generated buildsystem to clients through a JSON protocol. Currently all protocols are experimental and subject to change. * The "cmake(1)" command learned a "--trace-source=" option. * "ccmake(1)" learned to support vim-like navigation bindings. * "cmake-gui(1)" gained a button to open the generated project file for Visual Studio Generators and the "Xcode" generator. Deprecated and Removed Features =============================== * We no longer provide Linux i386 binaries for download from "cmake.org" for new versions of CMake. * Vim support files "cmake-indent.vim", "cmake-syntax.vim", and "cmake-help.vim" have been removed in favor of the files now provided from the vim-cmake-syntax project. * Support for building CMake itself with some compilers was dropped: * Visual Studio 7.1 and 2005 -- superseded by VS 2008 and above * MinGW.org mingw32 -- superseded by MSYS2 mingw32 and mingw64 CMake still supports generating build systems for other projects using these compilers. Other Changes ============= * The Fortran dependency scanner learned to support the syntax of Fortran Submodules. * Vim support files "indent/cmake.vim" and "syntax/cmake.vim" from the vim-cmake-syntax project are now distributed with CMake. ---------------------------------------------------------------------------- Changes made since CMake 3.7.0-rc2: Alex Turbov (3): CPackDeb: fix copy-n-paste typos in documentation CPackDeb: Fix incorrect variable name in documentation CPackRPM: Fix incorrect variable name in documentation Alexis Murzeau (1): Ninja: Use binary dir for `$subdir/all` targets Brad King (9): Android: Fix support for armeabi with c++_static Android: Add missing link flags for device executables Android: Set CMAKE_POSITION_INDEPENDENT_CODE automatically Android: Link position-independent executables with proper flags Intel: Fix compiler extension flags on Windows cmake-server: Change message wrapper to avoid ambiguity with content Features: Record features for Intel C++ 17 on UNIX FindHDF5: Restore pre-3.6 behavior of finding only C by default CMake 3.7.0-rc3 Francesco Romano (1): FindMatlab: Add support for Matlab 2016b (9.1) Gregor Jasny (2): Revert "Xcode: Convert maybe unversioned OSX sysroot into versioned SDK path" Darwin: Remove deployment target version check Konstantin Podsvirov (1): CPackIFW: Update search to find QtIFW distributed with QtSDK Marcus D. Hanwell (1): Help: Update example Qt 5 find_package call to use COMPONENTS Matthew Woehlke (1): FindMatlab: Fix typo in matlab_add_unit_test implementation Thiago M. de C. Marques (1): Help: Update example Qt 5 find_package call to add missing component Tobias Hunger (3): Help: Fix cmake-server documentation cmake-server: Better error reporting during handshake server-mode: Handle generator toolset and platform in handshake From gjasny at googlemail.com Fri Nov 4 16:57:44 2016 From: gjasny at googlemail.com (Gregor Jasny) Date: Fri, 4 Nov 2016 21:57:44 +0100 Subject: [CMake] CMake 3.6 and OSX In-Reply-To: References: Message-ID: <721927b3-44e7-3fbb-fb24-fc7d8a26a934@googlemail.com> Hello, On 02/11/2016 06:01, Robert Ramey wrote: > Here is what I'm seeing: > > a) it looks like CMake is looking for boost_filesystem rather than > libboost as I expect. (same for system). > > b) even if I tweak findBoost to force the system to look for libboost... > it still fails > > b) If I follow the suggestion and set BOOST_ROOT to the boost root, it > still doesn't work. The BOOST_ROOT variable is discarded when I invoke > "Configure" > > So again, any suggestions you can offer will be appreciated. It looks like you use a self-compiled boost library. I never did that but used homebrew instead. If you download the precompiled tarball from boost, does it work? (I'm asking because I see a 'Debug' in one of your paths). The next thing I would do is to run opensnoop and look what files CMake tries to access() / open() / stat(). Maybe that gives you a hint. Hope this helps, Gregor From andrew.amaclean at gmail.com Sun Nov 6 18:24:28 2016 From: andrew.amaclean at gmail.com (Andrew Maclean) Date: Mon, 7 Nov 2016 10:24:28 +1100 Subject: [CMake] Building CMake using CMake 3.6.3 fails. In-Reply-To: References: Message-ID: All is Ok. I deleted everything in the build directory and everything builds Ok now. Andrew On Fri, Nov 4, 2016 at 6:23 PM, Andrew Maclean wrote: > To be more specific it only occurs when building the debug version of > CMake. Release is OK. VTK builds and VTK Wiki examples are OK. > > On Fri, Nov 4, 2016 at 5:57 PM, Andrew Maclean > wrote: > >> Windows 10 64-bit using ninja, Qt 5.7 MSVC 2105. >> Building CMake with CMake 3.6.2 was OK. >> Now using CMake 3.6.3 I get the following message: >> CMake Error in Source/QtDialog/CMakeLists.txt: >> ------------------------- >> [0/1] Re-running CMake... >> -- cannot compile simplest ever MFC app, avoiding MFC test >> -- Configuring done >> CMake Error in Source/QtDialog/CMakeLists.txt: >> No known features for CXX compiler >> >> "MSVC" >> >> version 19.0.24215.1. >> >> >> CMake Error in Source/QtDialog/CMakeLists.txt: >> No known features for CXX compiler >> >> "MSVC" >> >> version 19.0.24215.1. >> >> ------------------------ >> >> -- >> ___________________________________________ >> Andrew J. P. Maclean >> >> ___________________________________________ >> > > > > -- > ___________________________________________ > Andrew J. P. Maclean > > ___________________________________________ > -- ___________________________________________ Andrew J. P. Maclean ___________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From stephan.menzel at gmail.com Mon Nov 7 03:37:15 2016 From: stephan.menzel at gmail.com (Stephan Menzel) Date: Mon, 7 Nov 2016 09:37:15 +0100 Subject: [CMake] Force MSVC runtime for debug builds Message-ID: Hello everyone, I'm looking for a way to force Debug configurations in generated MSVC solutions to use the Release runtime instead of the default "Debug". e.g. /MD rather than /MDd. My use case is an ever recurring problem of creating libraries that are linked in plug-in fashion against Release only applications. I want for my Debug configuration to have debug info and no optimization but still use the release runtime so I can link them. I tried replacing /MDd with /MD in CMAKE_CXX_FLAGS_DEBUG. This yielded objects built with /MD alright but failed to link into an executable with stuff like that: error LNK2038: mismatch detected for 'RuntimeLibrary': value 'MD_DynamicRelease' doesn't match value 'MDd_DynamicDebug' in Test.obj >From what I gather all the obj are actually compiled for Release runtime without optimization and Debug info just like I need it. But then the main obj is built and linked in Debug mode, causing the executable to not be created. Is there a way to solve this? Like a generic CMake executable flag or something that I can use to force the other runtime? Please note that using RelWithDebInfo and turning off optimization is not exactly what I need as I still want that mode much the way it is. Cheers, Stephan -------------- next part -------------- An HTML attachment was scrubbed... URL: From saadrustam at gmail.com Mon Nov 7 10:48:51 2016 From: saadrustam at gmail.com (Saad Khattak) Date: Mon, 07 Nov 2016 15:48:51 +0000 Subject: [CMake] Pointing CMAKE_AUTOMOC to a custom version of Qt and its moc.exe Message-ID: I am working on a plugin for Maya and it uses a customized version of Qt. Maya's SDK comes with everything to build Qt (headers, libraries and customized Qt tools such as moc.exe). I have the following issues: (1) With CMAKE_AUTOMOC set to ON, I am unable to figure out how to point CMake to pick Maya's version of moc.exe (and other Qt utils). The result is that I get linking errors since the moc did not run - which I expected. (2) Maya uses a modified version of Qt 5.6.1. There is currently no way to get that version from Autodesk. So I downloaded the official Qt 5.6.1 distribution. CMAKE_AUTOMOC now sets up my project correctly to be MOC'ed. However, it is using the official Qt moc utilities and NOT Maya's customized moc. The headers and libraries being used were still from Maya's custom Qt. The reason (2) worked is because I put "find_package(Qt5Widgets REQUIRED)" after installing the official version of Qt 5.6.1. However, I did NOT use the official Qt headers or libraries - instead, I used Maya's custom version of Qt 5.6.1. Using solution (2) I successfully compile and link my Qt enabled Maya plugin and load it in Maya. Things go smoothly until I either (a) unload the plugin or (b) delete any widget. I looked at the simplest code that is causing a heap corruption debug assertion: m_button = new QPushButton("MyButton"); // where m_button is a QPointer delete m_button; // causes heap corruption debug assertion to fire A few other people have gone through similar issues but since they didn't use CMake, they simply ran Maya's moc utilities in a build step. I would like a solution where I can get CMAKE_AUTOMOC to run the custom Qt version. Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From annulen at yandex.ru Mon Nov 7 10:54:16 2016 From: annulen at yandex.ru (Konstantin Tokarev) Date: Mon, 07 Nov 2016 18:54:16 +0300 Subject: [CMake] Pointing CMAKE_AUTOMOC to a custom version of Qt and its moc.exe In-Reply-To: References: Message-ID: <10046501478534056@web18h.yandex.ru> 07.11.2016, 18:49, "Saad Khattak" : > I am working on a plugin for Maya and it uses a customized version of Qt. Maya's SDK comes with everything to build Qt (headers, libraries and customized Qt tools such as moc.exe). > > I have the following issues: > > (1) With CMAKE_AUTOMOC set to ON, I am unable to figure out how to point CMake to pick Maya's version of moc.exe (and other Qt utils). The result is that I get linking errors since the moc did not run - which I expected. You should be able to use custom Qt installation by setting CMAKE_PREFIX_PATH to your Qt prefix > > (2) Maya uses a modified version of Qt 5.6.1. There is currently no way to get that version from Autodesk. So I downloaded the official Qt 5.6.1 distribution. CMAKE_AUTOMOC now sets up my project correctly to be MOC'ed. However, it is using the official Qt moc utilities and NOT Maya's customized moc. The headers and libraries being used were still from Maya's custom Qt. > > The reason (2) worked is because I put "find_package(Qt5Widgets REQUIRED)" after installing the official version of Qt 5.6.1. However, I did NOT use the official Qt headers or libraries - instead, I used Maya's custom version of Qt 5.6.1. > > Using solution (2) I successfully compile and link my Qt enabled Maya plugin and load it in Maya. Things go smoothly until I either (a) unload the plugin or (b) delete any widget. I looked at the simplest code that is causing a heap corruption debug assertion: > > m_button = new QPushButton("MyButton"); // where m_button is a QPointer > delete m_button; // causes heap corruption debug assertion to fire > > A few other people have gone through similar issues but since they didn't use CMake, they simply ran Maya's moc utilities in a build step. I would like a solution where I can get CMAKE_AUTOMOC to run the custom Qt version. > > Thanks. > > ,-- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake -- Regards, Konstantin From saadrustam at gmail.com Mon Nov 7 11:18:53 2016 From: saadrustam at gmail.com (Saad Khattak) Date: Mon, 07 Nov 2016 16:18:53 +0000 Subject: [CMake] Pointing CMAKE_AUTOMOC to a custom version of Qt and its moc.exe In-Reply-To: <10046501478534056@web18h.yandex.ru> References: <10046501478534056@web18h.yandex.ru> Message-ID: I did try that, unfortunately the Qt distribution that comes with Maya does not have the find_package CMake modules for it's version of Qt. They didn't exactly follow the folder structure of the official Qt release and they don't have any of the CMake modules. On Mon, Nov 7, 2016 at 10:54 AM Konstantin Tokarev wrote: > > > 07.11.2016, 18:49, "Saad Khattak" : > > I am working on a plugin for Maya and it uses a customized version of > Qt. Maya's SDK comes with everything to build Qt (headers, libraries and > customized Qt tools such as moc.exe). > > > > I have the following issues: > > > > (1) With CMAKE_AUTOMOC set to ON, I am unable to figure out how to point > CMake to pick Maya's version of moc.exe (and other Qt utils). The result is > that I get linking errors since the moc did not run - which I expected. > > You should be able to use custom Qt installation by setting > CMAKE_PREFIX_PATH to your Qt prefix > > > > > (2) Maya uses a modified version of Qt 5.6.1. There is currently no way > to get that version from Autodesk. So I downloaded the official Qt 5.6.1 > distribution. CMAKE_AUTOMOC now sets up my project correctly to be MOC'ed. > However, it is using the official Qt moc utilities and NOT Maya's > customized moc. The headers and libraries being used were still from Maya's > custom Qt. > > > > The reason (2) worked is because I put "find_package(Qt5Widgets > REQUIRED)" after installing the official version of Qt 5.6.1. However, I > did NOT use the official Qt headers or libraries - instead, I used Maya's > custom version of Qt 5.6.1. > > > > Using solution (2) I successfully compile and link my Qt enabled Maya > plugin and load it in Maya. Things go smoothly until I either (a) unload > the plugin or (b) delete any widget. I looked at the simplest code that is > causing a heap corruption debug assertion: > > > > m_button = new QPushButton("MyButton"); // where m_button is a > QPointer > > delete m_button; // causes heap corruption debug assertion to fire > > > > A few other people have gone through similar issues but since they > didn't use CMake, they simply ran Maya's moc utilities in a build step. I > would like a solution where I can get CMAKE_AUTOMOC to run the custom Qt > version. > > > > Thanks. > > > > ,-- > > > > Powered by www.kitware.com > > > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > > > CMake Support: http://cmake.org/cmake/help/support.html > > CMake Consulting: http://cmake.org/cmake/help/consulting.html > > CMake Training Courses: http://cmake.org/cmake/help/training.html > > > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > > > Follow this link to subscribe/unsubscribe: > > http://public.kitware.com/mailman/listinfo/cmake > > > -- > Regards, > Konstantin > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tiagomacarios at gmail.com Mon Nov 7 15:06:15 2016 From: tiagomacarios at gmail.com (Tiago Macarios) Date: Mon, 7 Nov 2016 12:06:15 -0800 Subject: [CMake] clang-format Message-ID: Hi, CMake has "built-in" support for clang_tidy and include-what-you-use. I was wondering why there is not support for clang_format. No one ever contributed, or people think this should not be part of CMake? Tiago -------------- next part -------------- An HTML attachment was scrubbed... URL: From lp.cordier at dynamixyz.com Tue Nov 8 04:57:33 2016 From: lp.cordier at dynamixyz.com (Louis-Paul CORDIER) Date: Tue, 8 Nov 2016 10:57:33 +0100 Subject: [CMake] Adding Cmake version in online documentation Message-ID: <81966572-ec61-cad5-489e-57f8e4b569f4@dynamixyz.com> Hi, This is a feature proposal for the documentation. Cmake is making use of cmake_minimum_required() command, that is very useful. Unfortunately it is very hard to identify commands that will work without browsing all version of cmake documentation for a given command. That said, adding a "since version" number for a feature/command would be great, like cplusplus.com does (example here: http://www.cplusplus.com/reference/unordered_map/unordered_map/?kw=unordered_map) For instance, the command list(FILTER ...) has been introduced in Cmake 3.6. Why not adding list(FILTER ...) (since 3.6) ? -- *Best Regards/ Louis-Paul CORDIER * -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike.jackson at bluequartz.net Tue Nov 8 08:28:37 2016 From: mike.jackson at bluequartz.net (Michael Jackson) Date: Tue, 08 Nov 2016 08:28:37 -0500 Subject: [CMake] Adding Cmake version in online documentation In-Reply-To: <81966572-ec61-cad5-489e-57f8e4b569f4@dynamixyz.com> References: <81966572-ec61-cad5-489e-57f8e4b569f4@dynamixyz.com> Message-ID: <5821D305.3040508@bluequartz.net> +1 -- Mike Jackson [mike.jackson at bluequartz.net] Louis-Paul CORDIER wrote: > Hi, > > This is a feature proposal for the documentation. Cmake is making use of > cmake_minimum_required() command, that is very useful. Unfortunately it > is very hard to identify commands that will work without browsing all > version of cmake documentation for a given command. > > That said, adding a "since version" number for a feature/command would > be great, like cplusplus.com does (example here: > http://www.cplusplus.com/reference/unordered_map/unordered_map/?kw=unordered_map) > > For instance, the command > > list(FILTER ...) > > has been introduced in Cmake 3.6. Why not adding > > list(FILTER ...) (since 3.6) > > ? > -- > > *Best Regards/ > Louis-Paul CORDIER > * > From nilsgladitz at gmail.com Tue Nov 8 08:37:17 2016 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Tue, 8 Nov 2016 14:37:17 +0100 Subject: [CMake] Adding Cmake version in online documentation In-Reply-To: <81966572-ec61-cad5-489e-57f8e4b569f4@dynamixyz.com> References: <81966572-ec61-cad5-489e-57f8e4b569f4@dynamixyz.com> Message-ID: <279329a8-6701-8629-5d5c-83a00c0c8f4a@gmail.com> On 11/08/2016 10:57 AM, Louis-Paul CORDIER wrote: > Hi, > > This is a feature proposal for the documentation. Cmake is making use > of cmake_minimum_required() command, that is very useful. > Unfortunately it is very hard to identify commands that will work > without browsing all version of cmake documentation for a given command. > This has been brought up for discussion more than once e.g.: https://public.kitware.com/Bug/view.php?id=15517 https://public.kitware.com/Bug/view.php?id=15222 http://public.kitware.com/pipermail/cmake/2016-April/063306.html Personally I still don't think this needs change. You don't have to browse all versions of the documentation ... you only have to work with the documentation that matches the version you declared in cmake_minimum_required(). Nils From Dvir.Yitzchaki at ceva-dsp.com Tue Nov 8 09:11:22 2016 From: Dvir.Yitzchaki at ceva-dsp.com (Dvir Yitzchaki) Date: Tue, 8 Nov 2016 14:11:22 +0000 Subject: [CMake] Adding Cmake version in online documentation In-Reply-To: <279329a8-6701-8629-5d5c-83a00c0c8f4a@gmail.com> References: <81966572-ec61-cad5-489e-57f8e4b569f4@dynamixyz.com> <279329a8-6701-8629-5d5c-83a00c0c8f4a@gmail.com> Message-ID: But how do you know which version to declare on cmake_minimum_required? If this feature will be added it won't be far from writing a script that scans the commands you use and outputs the first appropriate version. Regards, Dvir -----Original Message----- From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Nils Gladitz Sent: Tuesday, November 08, 2016 3:37 PM To: Louis-Paul CORDIER ; Cmake Mailing List Subject: Re: [CMake] Adding Cmake version in online documentation On 11/08/2016 10:57 AM, Louis-Paul CORDIER wrote: > Hi, > > This is a feature proposal for the documentation. Cmake is making use > of cmake_minimum_required() command, that is very useful. > Unfortunately it is very hard to identify commands that will work > without browsing all version of cmake documentation for a given command. > This has been brought up for discussion more than once e.g.: https://public.kitware.com/Bug/view.php?id=15517 https://public.kitware.com/Bug/view.php?id=15222 http://public.kitware.com/pipermail/cmake/2016-April/063306.html Personally I still don't think this needs change. You don't have to browse all versions of the documentation ... you only have to work with the documentation that matches the version you declared in cmake_minimum_required(). Nils -- 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 nilsgladitz at gmail.com Tue Nov 8 09:22:16 2016 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Tue, 8 Nov 2016 15:22:16 +0100 Subject: [CMake] Adding Cmake version in online documentation In-Reply-To: References: <81966572-ec61-cad5-489e-57f8e4b569f4@dynamixyz.com> <279329a8-6701-8629-5d5c-83a00c0c8f4a@gmail.com> Message-ID: <5ec9fa17-50c3-a523-416b-731c6aba64da@gmail.com> On 11/08/2016 03:11 PM, Dvir Yitzchaki wrote: > But how do you know which version to declare on cmake_minimum_required? > If this feature will be added it won't be far from writing a script that scans the commands you use and outputs the first appropriate version. > Strictly speaking cmake_minimum_required(VERSION) is not about command availability but rather about behavior (cmake policies). CMake does not diagnose or prevent use of commands that were introduced after the current policy version. No automation can detect which behaviors you might expect or require based on the commands you are using. I'd start by requesting the highest possible version I could justify (e.g. based on availability on target platforms and user convenience) and then start from there. For existing projects policy warnings help migrating to newer behaviors and versions as they become available / justifiable. Nils From taylor at braun-jones.org Tue Nov 8 10:13:59 2016 From: taylor at braun-jones.org (Taylor Braun-Jones) Date: Tue, 8 Nov 2016 10:13:59 -0500 Subject: [CMake] CMake 3.7.0-r2 Open Project sometimes picks wrong version of Visual Studio In-Reply-To: <63180e1a-32e1-8299-d4a9-c2e1578a53cb@kitware.com> References: <63180e1a-32e1-8299-d4a9-c2e1578a53cb@kitware.com> Message-ID: On Fri, Nov 4, 2016 at 2:55 PM, Brad King wrote: > > On 11/03/2016 06:04 PM, John Drescher wrote: > > I opened a project in cmake-gui using the open project button from a > > vc 2010 build of a project. The open project opened the project in > > Visual Studio 2010. Later I opened the same project but a different > > build tree for Visual Studio 2013 CMake-gui had all of the correct > > information for the Visual Studio 2013 build but open project tried to > > open the Visual Studio 2013 solution in Visual Studio 2010 instead of > > the expected Visual Studio 2013. I'm guessing you established MSVS2010 as the default application for opening .sln files the first time you used the open project button. What happens if you double click on that MSVS2013 .sln file? > The feature is new in 3.7 and was contributed here: > > cmake-gui: Add button to open the generated project > https://gitlab.kitware.com/cmake/cmake/commit/1ca2d5d1 > > I'm not particularly familiar with how it works, but from a quick > glance at the code it may be using file associations. Yes, it's just using Windows file file associations, but it shouldn't. Since it's possible (and fairly common) to have more than one version of Visual Studio installed on a system the Open Project button should be smarter and use ${CMAKE_VS_DEVENV_COMMAND} to open the .sln file. It should be something like this: MSVS2015: %VS140COMNTOOLS%..\IDE\devenv.com MSVS2013: %VS120COMNTOOLS%..\IDE\devenv.com MSVS2012: %VS110COMNTOOLS%..\IDE\devenv.com MSVS2010: %VS100COMNTOOLS%..\IDE\devenv.com If the correct devenv.exe path does not exist or can't be determined for some reason, then I guess it makes sense to fall back to using `QDesktopServices::openUrl` to try to open the .sln file with the Windows file associations. Taylor From ruslan_baratov at yahoo.com Tue Nov 8 10:17:42 2016 From: ruslan_baratov at yahoo.com (Ruslan Baratov) Date: Tue, 8 Nov 2016 23:17:42 +0800 Subject: [CMake] Adding Cmake version in online documentation In-Reply-To: References: <81966572-ec61-cad5-489e-57f8e4b569f4@dynamixyz.com> <279329a8-6701-8629-5d5c-83a00c0c8f4a@gmail.com> Message-ID: <38c1331b-6989-d2d7-3422-0ada60d9dac0@yahoo.com> On 08-Nov-16 22:11, Dvir Yitzchaki wrote: > But how do you know which version to declare on cmake_minimum_required? I do hit this too. This would be a very useful feature. Sometimes I have to manually "scan" the docs to figure out some simple facts about newly introduces variables/commands. On 08-Nov-16 22:22, Nils Gladitz wrote: > On 11/08/2016 03:11 PM, Dvir Yitzchaki wrote: > >> But how do you know which version to declare on cmake_minimum_required? >> If this feature will be added it won't be far from writing a script >> that scans the commands you use and outputs the first appropriate >> version. >> > > Strictly speaking cmake_minimum_required(VERSION) is not about command > availability but rather about behavior (cmake policies). Except it's exactly opposite :) `cmake_minimum_required` is about new features/commands, and policies is about behavior. If you have command `if(IN_LIST)` since 3.3 you can't manipulate policies in such way that it will work with CMake 2.8. However if you have warning about policy CMP0054 (since CMake 3.2) you can set policy to old without changing `cmake_minimum_required` (hence without forcing your CMake 2.8 users to upgrade to CMake 3.2). Ruslo From clinton at elemtech.com Tue Nov 8 10:28:05 2016 From: clinton at elemtech.com (clinton at elemtech.com) Date: Tue, 8 Nov 2016 08:28:05 -0700 (MST) Subject: [CMake] CMake 3.7.0-r2 Open Project sometimes picks wrong version of Visual Studio In-Reply-To: References: <63180e1a-32e1-8299-d4a9-c2e1578a53cb@kitware.com> Message-ID: <310578769.71417255.1478618885144.JavaMail.zimbra@elemtech.com> ----- On Nov 8, 2016, at 8:13 AM, Taylor Braun-Jones taylor at braun-jones.org wrote: > On Fri, Nov 4, 2016 at 2:55 PM, Brad King wrote: >> >> On 11/03/2016 06:04 PM, John Drescher wrote: >> > I opened a project in cmake-gui using the open project button from a >> > vc 2010 build of a project. The open project opened the project in >> > Visual Studio 2010. Later I opened the same project but a different >> > build tree for Visual Studio 2013 CMake-gui had all of the correct >> > information for the Visual Studio 2013 build but open project tried to >> > open the Visual Studio 2013 solution in Visual Studio 2010 instead of >> > the expected Visual Studio 2013. I'm unable to reproduce this problem. I have multiple Visual Studio installations of different versions. I'm not sure whether it could be specific to a project, or specific to installations of visual studio. > > I'm guessing you established MSVS2010 as the default application for > opening .sln files the first time you used the open project button. > What happens if you double click on that MSVS2013 .sln file? > >> The feature is new in 3.7 and was contributed here: >> >> cmake-gui: Add button to open the generated project >> https://gitlab.kitware.com/cmake/cmake/commit/1ca2d5d1 >> >> I'm not particularly familiar with how it works, but from a quick >> glance at the code it may be using file associations. > > Yes, it's just using Windows file file associations, but it shouldn't. > Since it's possible (and fairly common) to have more than one version > of Visual Studio installed on a system the Open Project button should > be smarter and use ${CMAKE_VS_DEVENV_COMMAND} to open the .sln file. > It should be something like this: > > MSVS2015: %VS140COMNTOOLS%..\IDE\devenv.com > MSVS2013: %VS120COMNTOOLS%..\IDE\devenv.com > MSVS2012: %VS110COMNTOOLS%..\IDE\devenv.com > MSVS2010: %VS100COMNTOOLS%..\IDE\devenv.com > > If the correct devenv.exe path does not exist or can't be determined > for some reason, then I guess it makes sense to fall back to using > `QDesktopServices::openUrl` to try to open the .sln file with the > Windows file associations. It is already using QDesktopServices::openUrl(QUrl::fromLocalFile(...)) AFAIK, that is the correct way to do it. The .sln file should already know what version of Visual Studio it wants to be opened in. Clint From nilsgladitz at gmail.com Tue Nov 8 10:33:01 2016 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Tue, 8 Nov 2016 16:33:01 +0100 Subject: [CMake] Adding Cmake version in online documentation In-Reply-To: <38c1331b-6989-d2d7-3422-0ada60d9dac0@yahoo.com> References: <81966572-ec61-cad5-489e-57f8e4b569f4@dynamixyz.com> <279329a8-6701-8629-5d5c-83a00c0c8f4a@gmail.com> <38c1331b-6989-d2d7-3422-0ada60d9dac0@yahoo.com> Message-ID: <2a0e1f85-6129-abe1-12d1-e85f2b8d16ce@gmail.com> On 11/08/2016 04:17 PM, Ruslan Baratov wrote: > On 08-Nov-16 22:22, Nils Gladitz wrote: >> Strictly speaking cmake_minimum_required(VERSION) is not about command >> availability but rather about behavior (cmake policies). > Except it's exactly opposite :) `cmake_minimum_required` is about new > features/commands, and policies is about behavior. I don't agree and you can not separate the two. cmake_minimum_required() initializes the policies based on the given version. > If you have command > `if(IN_LIST)` since 3.3 you can't manipulate policies in such way that > it will work with CMake 2.8. However if you have warning about policy > CMP0054 (since CMake 3.2) you can set policy to old without changing > `cmake_minimum_required` (hence without forcing your CMake 2.8 users to > upgrade to CMake 3.2). Coincidentally I implemented both of those policies :) Given your second example you likely shouldn't be touching the policy at all. A policy warning does not force your users to use a new CMake version. In fact all that setting it to OLD does is suppress the warning. CMake will use the old behavior in either case. The warnings guide developers when they do bump their cmake_minimum_required(VERSION). By just suppressing it behavior changes might go unnoticed when the bump does happen. Nils From mellery451 at gmail.com Tue Nov 8 11:20:11 2016 From: mellery451 at gmail.com (Michael Ellery) Date: Tue, 8 Nov 2016 08:20:11 -0800 Subject: [CMake] additional arguments with CMAKE_CXX_CLANG_TIDY variable Message-ID: I asked this question on SO and am repeating here with the hope someone knows the answer: http://stackoverflow.com/questions/40433573/how-can-i-specify-additional-arguments-for-use-with-cmake-cxx-clang-tidy-variabl ?? I'm trying to use make use of clang-tidy integration with cmake and I'd like to pass the -check argument. I've tried adding -DCMAKE_CXX_CLANG_TIDY="/usr/local/opt/llvm38/bin/clang-tidy-3.8;-checks=*" when invoking cmake, but my makefile commands end-up looking like: /usr/local/Cellar/cmake/3.6.2/bin/cmake -E __run_iwyu --tidy="/usr/local/opt/llvm38/bin/clang-tidy-3.8;-checks=*" --source=/Users/ellery/work/..... in other words, it seems like the ; separated args are not being parsed apart. I've also tried setting the target property CXX_CLANG_TIDY directly on my target with the same value and I get the same behavior. If I remove ?;checks=*? from the string, everything works fine, but I get default clang-tidy behavior. Has anyone succesfully invoked clang-tidy with additional args through cmake? ?? Thanks, Mike Ellery From clinton at elemtech.com Tue Nov 8 10:21:02 2016 From: clinton at elemtech.com (clinton at elemtech.com) Date: Tue, 8 Nov 2016 08:21:02 -0700 (MST) Subject: [CMake] Force MSVC runtime for debug builds In-Reply-To: References: Message-ID: <465919898.71405621.1478618462782.JavaMail.zimbra@elemtech.com> ----- On Nov 7, 2016, at 1:37 AM, Stephan Menzel wrote: > Hello everyone, > I'm looking for a way to force Debug configurations in generated MSVC solutions > to use the Release runtime instead of the default "Debug". e.g. /MD rather than > /MDd. > My use case is an ever recurring problem of creating libraries that are linked > in plug-in fashion against Release only applications. I want for my Debug > configuration to have debug info and no optimization but still use the release > runtime so I can link them. > I tried replacing /MDd with /MD in CMAKE_CXX_FLAGS_DEBUG. This yielded objects > built with /MD alright but failed to link into an executable with stuff like > that: > error LNK2038: mismatch detected for 'RuntimeLibrary': value 'MD_DynamicRelease' > doesn't match value 'MDd_DynamicDebug' in Test.obj > From what I gather all the obj are actually compiled for Release runtime without > optimization and Debug info just like I need it. But then the main obj is built > and linked in Debug mode, causing the executable to not be created. > Is there a way to solve this? Like a generic CMake executable flag or something > that I can use to force the other runtime? > Please note that using RelWithDebInfo and turning off optimization is not > exactly what I need as I still want that mode much the way it is. If you are going to use /MD instead of /MDd, then you probably also need to remove the _DEBUG preprocessor flag. IIRC, I've seen cases where defining _DEBUG includes symbols only defined by the debug runtimes. Clint -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.hoffman at kitware.com Tue Nov 8 13:06:00 2016 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Tue, 8 Nov 2016 13:06:00 -0500 Subject: [CMake] additional arguments with CMAKE_CXX_CLANG_TIDY variable In-Reply-To: References: Message-ID: <36800f78-96e5-a497-50dc-154f15696e94@kitware.com> On 11/8/2016 11:20 AM, Michael Ellery wrote: > /usr/local/Cellar/cmake/3.6.2/bin/cmake -E __run_iwyu > --tidy="/usr/local/opt/llvm38/bin/clang-tidy-3.8;-checks=*" > --source=/Users/ellery/work/..... That should still work. It is passing that to -E __run_iwyu which should expand the arguments. https://gitlab.kitware.com/cmake/cmake/blob/master/Source/cmcmd.cxx#L353 cmSystemTools::ExpandListArgument will separate out the arguments. My guess is the * might be causing the trouble somehow. -Bill From mellery451 at gmail.com Tue Nov 8 13:27:24 2016 From: mellery451 at gmail.com (Michael Ellery) Date: Tue, 8 Nov 2016 10:27:24 -0800 Subject: [CMake] additional arguments with CMAKE_CXX_CLANG_TIDY variable In-Reply-To: <36800f78-96e5-a497-50dc-154f15696e94@kitware.com> References: <36800f78-96e5-a497-50dc-154f15696e94@kitware.com> Message-ID: <12744FAD-C57C-4323-AD45-3756286ED5E8@gmail.com> > On Nov 8, 2016, at 10:06 AM, Bill Hoffman wrote: > > On 11/8/2016 11:20 AM, Michael Ellery wrote: >> /usr/local/Cellar/cmake/3.6.2/bin/cmake -E __run_iwyu >> --tidy="/usr/local/opt/llvm38/bin/clang-tidy-3.8;-checks=*" >> --source=/Users/ellery/work/..... > That should still work. It is passing that to -E __run_iwyu which should expand the arguments. > > https://gitlab.kitware.com/cmake/cmake/blob/master/Source/cmcmd.cxx#L353 > cmSystemTools::ExpandListArgument will separate out the arguments. My guess is the * might be causing the trouble somehow. > > -Bill > > Thanks - a quick test using `checks=google-runtime-memset` (for example) does NOT fail, so your speculation about * causing issues seems pretty likely. I?m not sure if this is a bug or if there is some other workaround for special arg characters... From mike.jackson at bluequartz.net Tue Nov 8 14:01:47 2016 From: mike.jackson at bluequartz.net (Michael Jackson) Date: Tue, 08 Nov 2016 14:01:47 -0500 Subject: [CMake] Force MSVC runtime for debug builds In-Reply-To: <465919898.71405621.1478618462782.JavaMail.zimbra@elemtech.com> References: <465919898.71405621.1478618462782.JavaMail.zimbra@elemtech.com> Message-ID: <5822211B.40905@bluequartz.net> I would agree. I don't know how many subtle runtime bugs I have had to figure out because our project mixed debug and release runtimes on MSVC. DON'T do it unless you REALLY have to. But even then I would never actually deploy that into production. YMMV -- Mike Jackson [mike.jackson at bluequartz.net] clinton at elemtech.com wrote: > > > ----- On Nov 7, 2016, at 1:37 AM, Stephan Menzel > wrote: > > Hello everyone, > I'm looking for a way to force Debug configurations in generated > MSVC solutions to use the Release runtime instead of the default > "Debug". e.g. /MD rather than /MDd. > > My use case is an ever recurring problem of creating libraries that > are linked in plug-in fashion against Release only applications. I > want for my Debug configuration to have debug info and no > optimization but still use the release runtime so I can link them. > > I tried replacing /MDd with /MD in CMAKE_CXX_FLAGS_DEBUG. This > yielded objects built with /MD alright but failed to link into an > executable with stuff like that: > > error LNK2038: mismatch detected for 'RuntimeLibrary': value > 'MD_DynamicRelease' doesn't match value 'MDd_DynamicDebug' in Test.obj > > From what I gather all the obj are actually compiled for Release > runtime without optimization and Debug info just like I need it. But > then the main obj is built and linked in Debug mode, causing the > executable to not be created. > > Is there a way to solve this? Like a generic CMake executable flag > or something that I can use to force the other runtime? > > Please note that using RelWithDebInfo and turning off optimization > is not exactly what I need as I still want that mode much the way it is. > > If you are going to use /MD instead of /MDd, then you probably also need > to remove the _DEBUG preprocessor flag. > IIRC, I've seen cases where defining _DEBUG includes symbols only > defined by the debug runtimes. > > Clint > From AlbrechtS.fltk at online.de Tue Nov 8 14:26:23 2016 From: AlbrechtS.fltk at online.de (Albrecht Schlosser) Date: Tue, 8 Nov 2016 20:26:23 +0100 Subject: [CMake] Adding Cmake version in online documentation In-Reply-To: <5ec9fa17-50c3-a523-416b-731c6aba64da@gmail.com> References: <81966572-ec61-cad5-489e-57f8e4b569f4@dynamixyz.com> <279329a8-6701-8629-5d5c-83a00c0c8f4a@gmail.com> <5ec9fa17-50c3-a523-416b-731c6aba64da@gmail.com> Message-ID: <1ac63c56-494b-fd5b-0ced-d133288a44e2@online.de> On 08.11.2016 15:22 Nils Gladitz wrote: > On 11/08/2016 03:11 PM, Dvir Yitzchaki wrote: > >> But how do you know which version to declare on cmake_minimum_required? >> If this feature will be added it won't be far from writing a script >> that scans the commands you use and outputs the first appropriate >> version. I'd also like such an addition to the documentation for reasons discussed below. > Strictly speaking cmake_minimum_required(VERSION) is not about command > availability but rather about behavior (cmake policies). [...] > I'd start by requesting the highest possible version I could justify > (e.g. based on availability on target platforms and user convenience) > and then start from there. And that's exactly the (my) point. How can I find out the "highest possible version I could justify"? I'm a developer of a public GUI library (FLTK). In this position you don't know anything about the availability of CMake versions on your target platforms. Our intention is to keep cmake_minimum_required() as low as possible. That said, whenever you change a CMakeLists.txt file you should be aware if the commands you use are compatible with the CMake version you "require". There should be an easy way to find out in which version a particular CMake command has been introduced. Only with this information you can decide if you should use this fine command or better find another way to do the task you're going to do. I'd like to have a list of release dates (I'm not sure if there is one) as well as the exact version a feature was introduced to write CMakeLists.txt files that run on really old CMake versions. Note: currently we have cmake_minimum_required(VERSION 2.6.3) (sic!), but we also have conditional code for some higher CMake versions: if(CMAKE_VERSION VERSION_GREATER 2.8.4) ... if(NOT CMAKE_VERSION VERSION_LESS 3.0.0) ... I'd appreciate such additions very much to be able to write more portable CMake files. TIA. From eric.noulard at gmail.com Tue Nov 8 16:23:03 2016 From: eric.noulard at gmail.com (Eric Noulard) Date: Tue, 8 Nov 2016 22:23:03 +0100 Subject: [CMake] Adding Cmake version in online documentation In-Reply-To: <1ac63c56-494b-fd5b-0ced-d133288a44e2@online.de> References: <81966572-ec61-cad5-489e-57f8e4b569f4@dynamixyz.com> <279329a8-6701-8629-5d5c-83a00c0c8f4a@gmail.com> <5ec9fa17-50c3-a523-416b-731c6aba64da@gmail.com> <1ac63c56-494b-fd5b-0ced-d133288a44e2@online.de> Message-ID: 2016-11-08 20:26 GMT+01:00 Albrecht Schlosser : > On 08.11.2016 15:22 Nils Gladitz wrote: > >> On 11/08/2016 03:11 PM, Dvir Yitzchaki wrote: >> >> But how do you know which version to declare on cmake_minimum_required? >>> If this feature will be added it won't be far from writing a script >>> that scans the commands you use and outputs the first appropriate >>> version. >>> >> > I'd also like such an addition to the documentation for reasons discussed > below. I think the need is recognized by most CMake user but... > > > Strictly speaking cmake_minimum_required(VERSION) is not about command >> availability but rather about behavior (cmake policies). >> > [...] > >> I'd start by requesting the highest possible version I could justify >> (e.g. based on availability on target platforms and user convenience) >> and then start from there. >> > > And that's exactly the (my) point. How can I find out the "highest > possible version I could justify"? > > I'm a developer of a public GUI library (FLTK). In this position you don't > know anything about the availability of CMake versions on your target > platforms. Our intention is to keep cmake_minimum_required() as low as > possible. > > That said, whenever you change a CMakeLists.txt file you should be aware > if the commands you use are compatible with the CMake version you > "require". There should be an easy way to find out in which version a > particular CMake command has been introduced. Only with this information > you can decide if you should use this fine command or better find another > way to do the task you're going to do. > > I'd like to have a list of release dates (I'm not sure if there is one) as > well as the exact version a feature was introduced to write CMakeLists.txt > files that run on really old CMake versions Some time ago people came up (dig the ML for the related discussion) with compatibility matrix idea: https://cmake.org/Wiki/CMake_Version_Compatibility_Matrix http://public.kitware.com/pipermail/cmake/2010-December/041202.html And it finally ends with cmake 3.0.0 http://public.kitware.com/pipermail/cmake/2015-March/059983.html Note that this is far more complicated than simply listing when one command appears because some command may get more options, or change their default semantic (using POLICY etc..) so the feature granularity leads to question like When did the 'string' cmake command support the UUID argument ? Before which version of CMake does get_target_property accept non-existent target argument without issuing any error or warning ? (see POLICY CMP0045) So basically, tracking all kind of behavior change is not as easy as it seems. How can we document the changes ? Or better extract them from the code or documentation? -- Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From craig.scott at crascit.com Tue Nov 8 16:33:44 2016 From: craig.scott at crascit.com (Craig Scott) Date: Wed, 9 Nov 2016 08:33:44 +1100 Subject: [CMake] Adding Cmake version in online documentation In-Reply-To: References: <81966572-ec61-cad5-489e-57f8e4b569f4@dynamixyz.com> <279329a8-6701-8629-5d5c-83a00c0c8f4a@gmail.com> <5ec9fa17-50c3-a523-416b-731c6aba64da@gmail.com> <1ac63c56-494b-fd5b-0ced-d133288a44e2@online.de> Message-ID: Rather than trying to do everything, perhaps there's value in tackling this in stages. At a high level, simply knowing in which CMake version a particular command, property, variable or module was added is a good start. >From there, if a command, etc. gained new options, then a note could be added with the text specific to that option to indicate when it was added. Obviously the more fine grained you go, the more time consuming and onerous it would become, but how about just starting with the coarse level? That already provides a big improvement over the current alternative of wading through past versions of documentation and/or source code. I'd also recommend that such version details be part of the actual CMake docs. While the separate compatibility matrix on the wiki is/was a useful resource, by not having it part of the CMake sources/docs, it is inherently a separate effort to try to keep it up to date with each CMake release. Making it part of CMake itself would seem to encourage documenting version details as part of the same merge requests, etc. that add/change things. I'll go out on a limb here and suggest that if a clear guideline was given for *how* version details should be documented, then the community itself would likely work towards populating that information over time. I don't think there is a (realistic) expectation that Kitware would do all the heavy lifting here. On Wed, Nov 9, 2016 at 8:23 AM, Eric Noulard wrote: > > > 2016-11-08 20:26 GMT+01:00 Albrecht Schlosser : > >> On 08.11.2016 15:22 Nils Gladitz wrote: >> >>> On 11/08/2016 03:11 PM, Dvir Yitzchaki wrote: >>> >>> But how do you know which version to declare on cmake_minimum_required? >>>> If this feature will be added it won't be far from writing a script >>>> that scans the commands you use and outputs the first appropriate >>>> version. >>>> >>> >> I'd also like such an addition to the documentation for reasons discussed >> below. > > > > I think the need is recognized by most CMake user but... > > >> >> >> Strictly speaking cmake_minimum_required(VERSION) is not about command >>> availability but rather about behavior (cmake policies). >>> >> [...] >> >>> I'd start by requesting the highest possible version I could justify >>> (e.g. based on availability on target platforms and user convenience) >>> and then start from there. >>> >> >> And that's exactly the (my) point. How can I find out the "highest >> possible version I could justify"? >> >> I'm a developer of a public GUI library (FLTK). In this position you >> don't know anything about the availability of CMake versions on your target >> platforms. Our intention is to keep cmake_minimum_required() as low as >> possible. >> >> That said, whenever you change a CMakeLists.txt file you should be aware >> if the commands you use are compatible with the CMake version you >> "require". There should be an easy way to find out in which version a >> particular CMake command has been introduced. Only with this information >> you can decide if you should use this fine command or better find another >> way to do the task you're going to do. >> >> I'd like to have a list of release dates (I'm not sure if there is one) >> as well as the exact version a feature was introduced to write >> CMakeLists.txt files that run on really old CMake versions > > > Some time ago people came up (dig the ML for the related discussion) with > compatibility matrix idea: > https://cmake.org/Wiki/CMake_Version_Compatibility_Matrix > http://public.kitware.com/pipermail/cmake/2010-December/041202.html > > And it finally ends with cmake 3.0.0 > http://public.kitware.com/pipermail/cmake/2015-March/059983.html > > Note that this is far more complicated than simply listing when one > command appears because some command may get more options, or change their > default semantic > (using POLICY etc..) so the feature granularity leads to question like > > When did the 'string' cmake command support the UUID argument ? > > Before which version of CMake does get_target_property > accept non-existent target argument without issuing any error or warning ? > (see POLICY CMP0045) > > So basically, tracking all kind of behavior change is not as easy as it > seems. > > How can we document the changes ? Or better extract them from the code or > documentation? > > -- > Eric > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/ > opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake > -- Craig Scott Melbourne, Australia https://crascit.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From nilsgladitz at gmail.com Tue Nov 8 17:01:05 2016 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Tue, 8 Nov 2016 23:01:05 +0100 Subject: [CMake] Adding Cmake version in online documentation In-Reply-To: <1ac63c56-494b-fd5b-0ced-d133288a44e2@online.de> References: <81966572-ec61-cad5-489e-57f8e4b569f4@dynamixyz.com> <279329a8-6701-8629-5d5c-83a00c0c8f4a@gmail.com> <5ec9fa17-50c3-a523-416b-731c6aba64da@gmail.com> <1ac63c56-494b-fd5b-0ced-d133288a44e2@online.de> Message-ID: <136407e6-7109-db65-a317-819d3b2e3ccd@gmail.com> On 08.11.2016 20:26, Albrecht Schlosser wrote: > On 08.11.2016 15:22 Nils Gladitz wrote: > >> Strictly speaking cmake_minimum_required(VERSION) is not about command >> availability but rather about behavior (cmake policies). > [...] >> I'd start by requesting the highest possible version I could justify >> (e.g. based on availability on target platforms and user convenience) >> and then start from there. > > And that's exactly the (my) point. How can I find out the "highest > possible version I could justify"? > > I'm a developer of a public GUI library (FLTK). In this position you > don't know anything about the availability of CMake versions on your > target platforms. Our intention is to keep cmake_minimum_required() as > low as possible. > If you are intending to keep the required version as low as possible you'll already have a justification / reason for doing so. I can only assume that the reason is that you need to support ancient platforms which ship equally ancient versions of CMake and you don't want to bother your users to build or install custom newer versions of CMake. It doesn't matter what your reasons or justifications for it are (though I would hope they are valid and verified) but you have to decide on a minimum version that you can life with in the end. > That said, whenever you change a CMakeLists.txt file you should be > aware if the commands you use are compatible with the CMake version > you "require". There should be an easy way to find out in which > version a particular CMake command has been introduced. Only with this > information you can decide if you should use this fine command or > better find another way to do the task you're going to do. At this point you only have to refer to the documentation that actually corresponds to the version you decided to require. You'll only find commands and behaviours in that documentation that'll actually be available in your minimum version. You will not find commands or behaviours that are unavailable in your version so you will not be tempted to use them nor will you have to asses them individually for their availability. > > I'd like to have a list of release dates (I'm not sure if there is > one) as well as the exact version a feature was introduced to write > CMakeLists.txt files that run on really old CMake versions. > I think the git tag creation dates should roughly equate release dates: https://cmake.org/gitweb?p=cmake.git;a=tags > Note: currently we have cmake_minimum_required(VERSION 2.6.3) (sic!), > but we also have conditional code for some higher CMake versions: 2.6.3's tag e.g. "Sat, 21 Feb 2009 19:43:45 +0000 (14:43 -0500)" would be over 7 years old now. > > if(CMAKE_VERSION VERSION_GREATER 2.8.4) ... > if(NOT CMAKE_VERSION VERSION_LESS 3.0.0) ... > There are exceptions to every rule but I'd personally avoid or at least try to minimize such constructs if possible. CMake's policy mechanism tries hard to preserve old behaviours so that existing projects depending on those old behaviours don't break with new versions of CMake. Given your minimum required version CMake 3.7 will still mostly try to behave like 2.6.3. With constructs like these this is no longer the case and you need an increasing number of CMake versions to get proper coverage. Developers that use one specific version of CMake can not longer be reasonably confident that their CMake script changes also work on other versions of CMake covered by distinct version specific conditionals. Nils From tiagomacarios at gmail.com Tue Nov 8 18:05:10 2016 From: tiagomacarios at gmail.com (Tiago Macarios) Date: Tue, 8 Nov 2016 15:05:10 -0800 Subject: [CMake] Get libraries from target Message-ID: Hi, Is there a way for me to get CMake libraries out of a target? For example: target_link_libraries(A B C) Can I get B and C from A? What I am trying to do: We are working on adding include-what-you-use into our build system and some of the libraries have their on mapping files. So I was wondering if I could somehow "attach" the mapping file to the target and then "reconstruct" a mapping file for each target. For example: Library B and C have their own mapping, so I would: set_target_properties(B PROPERTIES mapping /path/to/fileB) set_target_properties(C PROPERTIES mapping /path/to/fileC) Then a function would reconstruct a mapping for target A: set_target_properties(A PROPERTIES mapping /path/to/fileA) create_mapping_function(A): loop over dependencies of A get all mappings recreate a mapping file with all dependencies: { ref: "/path/to/fileA" }, { ref: "/path/to/fileB" } { ref: "/path/to/fileC" } -------------- next part -------------- An HTML attachment was scrubbed... URL: From AlbrechtS.fltk at online.de Tue Nov 8 18:27:10 2016 From: AlbrechtS.fltk at online.de (Albrecht Schlosser) Date: Wed, 9 Nov 2016 00:27:10 +0100 Subject: [CMake] Adding Cmake version in online documentation In-Reply-To: References: <81966572-ec61-cad5-489e-57f8e4b569f4@dynamixyz.com> <279329a8-6701-8629-5d5c-83a00c0c8f4a@gmail.com> <5ec9fa17-50c3-a523-416b-731c6aba64da@gmail.com> <1ac63c56-494b-fd5b-0ced-d133288a44e2@online.de> Message-ID: <68169f63-1ea8-2ebc-1821-05a5392f84f1@online.de> On 08.11.2016 22:23 Eric Noulard wrote: > > 2016-11-08 20:26 GMT+01:00 Albrecht Schlosser <...>: > > I'd also like such an addition to the documentation for reasons > discussed below. > > > > I think the need is recognized by most CMake user but... okay... > Strictly speaking cmake_minimum_required(VERSION) is not about > command > availability but rather about behavior (cmake policies). > > [...] > > I'd start by requesting the highest possible version I could justify > (e.g. based on availability on target platforms and user > convenience) > and then start from there. > > > And that's exactly the (my) point. How can I find out the "highest > possible version I could justify"? > > I'm a developer of a public GUI library (FLTK). In this position you > don't know anything about the availability of CMake versions on your > target platforms. Our intention is to keep cmake_minimum_required() > as low as possible. > > That said, whenever you change a CMakeLists.txt file you should be > aware if the commands you use are compatible with the CMake version > you "require". There should be an easy way to find out in which > version a particular CMake command has been introduced. Only with > this information you can decide if you should use this fine command > or better find another way to do the task you're going to do. > > I'd like to have a list of release dates (I'm not sure if there is > one) as well as the exact version a feature was introduced to write > CMakeLists.txt files that run on really old CMake versions > > > Some time ago people came up (dig the ML for the related discussion) > with compatibility matrix idea: > https://cmake.org/Wiki/CMake_Version_Compatibility_Matrix > http://public.kitware.com/pipermail/cmake/2010-December/041202.html > > And it finally ends with cmake 3.0.0 > http://public.kitware.com/pipermail/cmake/2015-March/059983.html > > Note that this is far more complicated than simply listing when one > command appears because some command may get more options, or change > their default semantic > (using POLICY etc..) so the feature granularity leads to question like > > When did the 'string' cmake command support the UUID argument ? > > Before which version of CMake does get_target_property > accept non-existent target argument without issuing any error or warning ? > (see POLICY CMP0045) > > So basically, tracking all kind of behavior change is not as easy as it > seems. Sure, I agree. Thanks for your elaborate comments. > How can we document the changes ? Or better extract them from the code > or documentation? A simple comment like "since 3.5.0" for the _first_ appearance of a command would be very helpful. Added keywords could be commented as well. I see that behavior changes would be more difficult to document, but documentation of policies seem to do a good job in their particular cases. From AlbrechtS.fltk at online.de Tue Nov 8 18:47:39 2016 From: AlbrechtS.fltk at online.de (Albrecht Schlosser) Date: Wed, 9 Nov 2016 00:47:39 +0100 Subject: [CMake] Adding Cmake version in online documentation In-Reply-To: <136407e6-7109-db65-a317-819d3b2e3ccd@gmail.com> References: <81966572-ec61-cad5-489e-57f8e4b569f4@dynamixyz.com> <279329a8-6701-8629-5d5c-83a00c0c8f4a@gmail.com> <5ec9fa17-50c3-a523-416b-731c6aba64da@gmail.com> <1ac63c56-494b-fd5b-0ced-d133288a44e2@online.de> <136407e6-7109-db65-a317-819d3b2e3ccd@gmail.com> Message-ID: <7dac1f34-1736-0e6b-96fa-1eeec1456e03@online.de> On 08.11.2016 23:01 Nils Gladitz wrote: > On 08.11.2016 20:26, Albrecht Schlosser wrote: >> >> I'm a developer of a public GUI library (FLTK). In this position you >> don't know anything about the availability of CMake versions on your >> target platforms. Our intention is to keep cmake_minimum_required() as >> low as possible. >> > > If you are intending to keep the required version as low as possible > you'll already have a justification / reason for doing so. > I can only assume that the reason is that you need to support ancient > platforms which ship equally ancient versions of CMake and you don't > want to bother your users to build or install custom newer versions of > CMake. > > It doesn't matter what your reasons or justifications for it are (though > I would hope they are valid and verified) but you have to decide on a > minimum version that you can life with in the end. Basically that's a floating target. We need to evaluate this from time to time and maybe adjust the required version. >> That said, whenever you change a CMakeLists.txt file you should be >> aware if the commands you use are compatible with the CMake version >> you "require". There should be an easy way to find out in which >> version a particular CMake command has been introduced. Only with this >> information you can decide if you should use this fine command or >> better find another way to do the task you're going to do. > > At this point you only have to refer to the documentation that actually > corresponds to the version you decided to require. > You'll only find commands and behaviours in that documentation that'll > actually be available in your minimum version. Yep, that's simple, of course. But if there is a (new) command you want to use it would be interesting to know the CMake version it was introduced to _decide_ if you can or want to do without it or raise the required version. I'm sure that we will raise the required version when CMake gets (or got) a new feature we need to use. But we need the facts to decide... >> I'd like to have a list of release dates (I'm not sure if there is >> one) as well as the exact version a feature was introduced to write >> CMakeLists.txt files that run on really old CMake versions. >> > > I think the git tag creation dates should roughly equate release dates: > https://cmake.org/gitweb?p=cmake.git;a=tags Thanks for this, I appreciate your help. >> Note: currently we have cmake_minimum_required(VERSION 2.6.3) (sic!), >> but we also have conditional code for some higher CMake versions: > > 2.6.3's tag e.g. "Sat, 21 Feb 2009 19:43:45 +0000 (14:43 -0500)" would > be over 7 years old now. As I said: this is a floating target. Since this version is so old we may decide to require a more recent version in the near future, but likely not yet 3.7 ;-) >> if(CMAKE_VERSION VERSION_GREATER 2.8.4) ... >> if(NOT CMAKE_VERSION VERSION_LESS 3.0.0) ... > > There are exceptions to every rule but I'd personally avoid or at least > try to minimize such constructs if possible. I think these two are the only special cases, and they are used for new features we use if available with a fallback (or not at all) if the CMake version is older. > CMake's policy mechanism tries hard to preserve old behaviours so that > existing projects depending on those old behaviours don't break with new > versions of CMake. > Given your minimum required version CMake 3.7 will still mostly try to > behave like 2.6.3. I'm not very familiar with CMake policies. Maybe I need some more RTFM. > With constructs like these this is no longer the case and you need an > increasing number of CMake versions to get proper coverage. > Developers that use one specific version of CMake can not longer be > reasonably confident that their CMake script changes also work on other > versions of CMake covered by distinct version specific conditionals. Good point, thanks for this as well. But as I said before, these constructs are only exceptions. BTW: Thanks to all CMake devs for this great tool! From ruslan_baratov at yahoo.com Tue Nov 8 21:47:53 2016 From: ruslan_baratov at yahoo.com (Ruslan Baratov) Date: Wed, 9 Nov 2016 10:47:53 +0800 Subject: [CMake] Adding Cmake version in online documentation In-Reply-To: <136407e6-7109-db65-a317-819d3b2e3ccd@gmail.com> References: <81966572-ec61-cad5-489e-57f8e4b569f4@dynamixyz.com> <279329a8-6701-8629-5d5c-83a00c0c8f4a@gmail.com> <5ec9fa17-50c3-a523-416b-731c6aba64da@gmail.com> <1ac63c56-494b-fd5b-0ced-d133288a44e2@online.de> <136407e6-7109-db65-a317-819d3b2e3ccd@gmail.com> Message-ID: <1c9af92e-0be6-8e51-3a24-f30d191212bf@yahoo.com> On 09-Nov-16 06:01, Nils Gladitz wrote: > On 08.11.2016 20:26, Albrecht Schlosser wrote: > >> >> I'd like to have a list of release dates (I'm not sure if there is >> one) as well as the exact version a feature was introduced to write >> CMakeLists.txt files that run on really old CMake versions. >> > > I think the git tag creation dates should roughly equate release dates: > https://cmake.org/gitweb?p=cmake.git;a=tags What about the future releases? There was a page https://cmake.org/Bug/changelog_page.php before but it's no longer valid as far as I understand. Ruslo From ruslan_baratov at yahoo.com Tue Nov 8 22:29:01 2016 From: ruslan_baratov at yahoo.com (Ruslan Baratov) Date: Wed, 9 Nov 2016 11:29:01 +0800 Subject: [CMake] Adding Cmake version in online documentation In-Reply-To: <2a0e1f85-6129-abe1-12d1-e85f2b8d16ce@gmail.com> References: <81966572-ec61-cad5-489e-57f8e4b569f4@dynamixyz.com> <279329a8-6701-8629-5d5c-83a00c0c8f4a@gmail.com> <38c1331b-6989-d2d7-3422-0ada60d9dac0@yahoo.com> <2a0e1f85-6129-abe1-12d1-e85f2b8d16ce@gmail.com> Message-ID: <98f9bbf7-0898-c249-3a1f-7b82b32d5912@yahoo.com> On 08-Nov-16 23:33, Nils Gladitz wrote: > On 11/08/2016 04:17 PM, Ruslan Baratov wrote: > >> On 08-Nov-16 22:22, Nils Gladitz wrote: >>> Strictly speaking cmake_minimum_required(VERSION) is not about command >>> availability but rather about behavior (cmake policies). >> Except it's exactly opposite :) `cmake_minimum_required` is about new >> features/commands, and policies is about behavior. > > I don't agree and you can not separate the two. > cmake_minimum_required() initializes the policies based on the given > version. So what? From the user's perspective the "initialization of policies" is like a syntactic sugar so you don't have to write endless `cmake_policy(SET CMP00xx NEW)`. Nothing to do how to deal with them further. > >> If you have command >> `if(IN_LIST)` since 3.3 you can't manipulate policies in such way that >> it will work with CMake 2.8. However if you have warning about policy >> CMP0054 (since CMake 3.2) you can set policy to old without changing >> `cmake_minimum_required` (hence without forcing your CMake 2.8 users to >> upgrade to CMake 3.2). > > Coincidentally I implemented both of those policies :) > > Given your second example you likely shouldn't be touching the policy > at all. I have to. If my code use features from CMake 2.8 I do set `cmake_minimum_required(VERSION 2.8)`. But some users may have CMake 3.2 installed. Do they must downgrade CMake? Of course not. But if I'm not touching policies there will be warnings around. If I'm good developer I will investigate the root of the warnings and fix them. Actually most of them will be about bugs in my code or dangerous behavior, so it does improve 2.8 too. > > A policy warning does not force your users to use a new CMake version. Well that's what I said. > In fact all that setting it to OLD does is suppress the warning. It's better than emitting zillion of warnings to the output, right? You can suppress one type and fix another, set TODOs, etc. > CMake will use the old behavior in either case. > > The warnings guide developers when they do bump their > cmake_minimum_required(VERSION). > By just suppressing it behavior changes might go unnoticed when the > bump does happen. There are 3 components in the equation: the **real** CMake version, the version in `cmake_minimum_required` and the default policies for such version. Can you provide an example of what you mean? Ruslo -------------- next part -------------- An HTML attachment was scrubbed... URL: From nilsgladitz at gmail.com Wed Nov 9 03:22:24 2016 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Wed, 9 Nov 2016 09:22:24 +0100 Subject: [CMake] Adding Cmake version in online documentation In-Reply-To: <98f9bbf7-0898-c249-3a1f-7b82b32d5912@yahoo.com> References: <81966572-ec61-cad5-489e-57f8e4b569f4@dynamixyz.com> <279329a8-6701-8629-5d5c-83a00c0c8f4a@gmail.com> <38c1331b-6989-d2d7-3422-0ada60d9dac0@yahoo.com> <2a0e1f85-6129-abe1-12d1-e85f2b8d16ce@gmail.com> <98f9bbf7-0898-c249-3a1f-7b82b32d5912@yahoo.com> Message-ID: On 09.11.2016 04:29, Ruslan Baratov wrote: > On 08-Nov-16 23:33, Nils Gladitz wrote: >> On 11/08/2016 04:17 PM, Ruslan Baratov wrote: >> >>> Except it's exactly opposite :) `cmake_minimum_required` is about new >>> features/commands, and policies is about behavior. >> >> I don't agree and you can not separate the two. >> cmake_minimum_required() initializes the policies based on the given >> version. > So what? From the user's perspective the "initialization of policies" > is like a syntactic sugar so you don't have to write endless > `cmake_policy(SET CMP00xx NEW)`. Nothing to do how to deal with them > further. You can't simultaneously argue that cmake_minimum_required() isn't about policies (behaviours) and at the same time syntactic sugar for those very same policies. > >> >>> If you have command >>> `if(IN_LIST)` since 3.3 you can't manipulate policies in such way that >>> it will work with CMake 2.8. However if you have warning about policy >>> CMP0054 (since CMake 3.2) you can set policy to old without changing >>> `cmake_minimum_required` (hence without forcing your CMake 2.8 users to >>> upgrade to CMake 3.2). >> >> Coincidentally I implemented both of those policies :) >> >> Given your second example you likely shouldn't be touching the policy >> at all. > I have to. If my code use features from CMake 2.8 I do set > `cmake_minimum_required(VERSION 2.8)`. But some users may have CMake > 3.2 installed. Do they must downgrade CMake? Of course not. But if I'm > not touching policies there will be warnings around. If I'm good > developer I will investigate the root of the warnings and fix them. > Actually most of them will be about bugs in my code or dangerous > behavior, so it does improve 2.8 too. Policy warnings aren't meant to indicate errors in your code but changes in behaviour that will happen if you were to increase your minimum required version. As such they can often be worked around by using behaviour that is consistent between versions but they are not meant to indicate errors to be fixed. Instead they are meant to encourage you to embrace the new behaviours and abandon the old (which will require porting work) since the old are by definition deprecated and may be removed in the future (though so far CMake has been very conservative about this). > >> >> A policy warning does not force your users to use a new CMake version. > Well that's what I said. You said you are not forcing your users to upgrade by setting a policy to OLD. Which implied that not setting the policy to OLD would force your users to upgrade ... which it doesn't. > >> In fact all that setting it to OLD does is suppress the warning. > It's better than emitting zillion of warnings to the output, right? > You can suppress one type and fix another, set TODOs, etc. Policy warnings are intended to encourage you to switch to new behaviours since the old ones are deprecated. In actively maintained projects they are not meant to be suppressed. > >> CMake will use the old behavior in either case. >> >> The warnings guide developers when they do bump their >> cmake_minimum_required(VERSION). >> By just suppressing it behavior changes might go unnoticed when the >> bump does happen. > There are 3 components in the equation: the **real** CMake version, > the version in `cmake_minimum_required` and the default policies for > such version. Can you provide an example of what you mean? cmake_minimum_required(VERSION 3.0) set(ONE 1) if(1 STREQUAL "ONE") message("FOO") else() message("BAR") endif() This code was designed for 3.0 (as indicated by the cmake_minimum_required(VERSION)) and is meant to output "FOO". When you use CMake 3.0 that is the behaviour you get (without warnings). When you use CMake >= 3.1 the behaviour of the code itself is still the same but you will get a CMP0054 warning telling you that the behaviour that you currently depend on in if() has been deprecated. Now you decide to bump your minimum required version from 3.0 to 3.1 and ignore or suppress the policy warning from before: cmake_minimum_required(VERSION 3.1) set(ONE 1) if(1 STREQUAL "ONE") message("FOO") else() message("BAR) endif() Now when you use CMake >= 3.1 to run this code you will not get any more warnings but it will also no longer behave like it used to. It will output "BAR" instead of "FOO". Nils -------------- next part -------------- An HTML attachment was scrubbed... URL: From nilsgladitz at gmail.com Wed Nov 9 03:22:41 2016 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Wed, 9 Nov 2016 09:22:41 +0100 Subject: [CMake] Adding Cmake version in online documentation In-Reply-To: <1c9af92e-0be6-8e51-3a24-f30d191212bf@yahoo.com> References: <81966572-ec61-cad5-489e-57f8e4b569f4@dynamixyz.com> <279329a8-6701-8629-5d5c-83a00c0c8f4a@gmail.com> <5ec9fa17-50c3-a523-416b-731c6aba64da@gmail.com> <1ac63c56-494b-fd5b-0ced-d133288a44e2@online.de> <136407e6-7109-db65-a317-819d3b2e3ccd@gmail.com> <1c9af92e-0be6-8e51-3a24-f30d191212bf@yahoo.com> Message-ID: <1bfcd0b6-aafc-92bb-ec9b-9adada91175d@gmail.com> On 09.11.2016 03:47, Ruslan Baratov wrote: > On 09-Nov-16 06:01, Nils Gladitz wrote: >> I think the git tag creation dates should roughly equate release dates: >> https://cmake.org/gitweb?p=cmake.git;a=tags > What about the future releases? There was a page > https://cmake.org/Bug/changelog_page.php before but it's no longer valid > as far as I understand. https://gitlab.kitware.com/cmake/cmake/milestones I wouldn't consider those dates to be anything but very rough estimates though. Nils From ruslan_baratov at yahoo.com Wed Nov 9 06:04:05 2016 From: ruslan_baratov at yahoo.com (Ruslan Baratov) Date: Wed, 9 Nov 2016 19:04:05 +0800 Subject: [CMake] Adding Cmake version in online documentation In-Reply-To: References: <81966572-ec61-cad5-489e-57f8e4b569f4@dynamixyz.com> <279329a8-6701-8629-5d5c-83a00c0c8f4a@gmail.com> <38c1331b-6989-d2d7-3422-0ada60d9dac0@yahoo.com> <2a0e1f85-6129-abe1-12d1-e85f2b8d16ce@gmail.com> <98f9bbf7-0898-c249-3a1f-7b82b32d5912@yahoo.com> Message-ID: <1b2026f0-5192-9873-46ce-219dd9d74534@yahoo.com> On 09-Nov-16 16:22, Nils Gladitz wrote: > On 09.11.2016 04:29, Ruslan Baratov wrote: >> On 08-Nov-16 23:33, Nils Gladitz wrote: >>> On 11/08/2016 04:17 PM, Ruslan Baratov wrote: >>> >>>> Except it's exactly opposite :) `cmake_minimum_required` is about new >>>> features/commands, and policies is about behavior. >>> >>> I don't agree and you can not separate the two. >>> cmake_minimum_required() initializes the policies based on the given >>> version. >> So what? From the user's perspective the "initialization of policies" >> is like a syntactic sugar so you don't have to write endless >> `cmake_policy(SET CMP00xx NEW)`. Nothing to do how to deal with them >> further. > > You can't simultaneously argue that cmake_minimum_required() isn't > about policies (behaviours) and at the same time syntactic sugar for > those very same policies. You're playing with words instead of using arguments. > >> >>> >>>> If you have command >>>> `if(IN_LIST)` since 3.3 you can't manipulate policies in such way that >>>> it will work with CMake 2.8. However if you have warning about policy >>>> CMP0054 (since CMake 3.2) you can set policy to old without changing >>>> `cmake_minimum_required` (hence without forcing your CMake 2.8 >>>> users to >>>> upgrade to CMake 3.2). >>> >>> Coincidentally I implemented both of those policies :) >>> >>> Given your second example you likely shouldn't be touching the >>> policy at all. >> I have to. If my code use features from CMake 2.8 I do set >> `cmake_minimum_required(VERSION 2.8)`. But some users may have CMake >> 3.2 installed. Do they must downgrade CMake? Of course not. But if >> I'm not touching policies there will be warnings around. If I'm good >> developer I will investigate the root of the warnings and fix them. >> Actually most of them will be about bugs in my code or dangerous >> behavior, so it does improve 2.8 too. > > Policy warnings aren't meant to indicate errors in your code but > changes in behaviour that will happen if you were to increase your > minimum required version. Policy CMP0038 doesn't agree with you: https://cmake.org/cmake/help/latest/policy/CMP0038.html > As such they can often be worked around by using behaviour that is > consistent between versions but they are not meant to indicate errors > to be fixed. > > Instead they are meant to encourage you to embrace the new behaviours > and abandon the old (which will require porting work) since the old > are by definition deprecated and may be removed in the future (though > so far CMake has been very conservative about this). > >> >>> >>> A policy warning does not force your users to use a new CMake version. >> Well that's what I said. > > You said you are not forcing your users to upgrade by setting a policy > to OLD. Yes, like this: cmake_minimum_required(VERSION 2.8) project(foo) if(POLICY CMP0038)cmake_policy(SET CMP0038 OLD) endif() Now CMake 3.0 users will not see the warning and CMake 2.8 users **don't have to upgrade**. > Which implied that not setting the policy to OLD would force your > users to upgrade ... which it doesn't. No, it doesn't imply this :) Not setting policy to OLD in this case produce warnings that I have to deal with. > >> >>> In fact all that setting it to OLD does is suppress the warning. Actually this statement is wrong. Take a look at this example: # CMakeLists.txt cmake_minimum_required(VERSION 3.0) project(fooVERSION 1.2.3) cmake_policy(SET CMP0038 OLD) # Do not remove this! add_library(foofoo.cpp) target_link_libraries(foofoo) if you remove `cmake_policy(SET CMP0038 OLD)` this example will produce **error**. It may happens when you want to use new **feature** `project(VERSION)` from 3.0, hence you set `cmake_minimum_required(VERSION 3.0)` and simultaneously you have code which produce warning about CMP0038. By setting `cmake_policy(SET CMP0038 OLD)` you suppress the error, i.e. change **behaviour**. >> It's better than emitting zillion of warnings to the output, right? >> You can suppress one type and fix another, set TODOs, etc. > > Policy warnings are intended to encourage you to switch to new > behaviours since the old ones are deprecated. > In actively maintained projects they are not meant to be suppressed. Why not? If you're not planning to fix them right now? I'm not saying you have to ignore them, you have to do fixes, but why not suppress and say work on other fixes? > >> >>> CMake will use the old behavior in either case. >>> >>> The warnings guide developers when they do bump their >>> cmake_minimum_required(VERSION). >>> By just suppressing it behavior changes might go unnoticed when the >>> bump does happen. >> There are 3 components in the equation: the **real** CMake version, >> the version in `cmake_minimum_required` and the default policies for >> such version. Can you provide an example of what you mean? > > cmake_minimum_required(VERSION 3.0) > > set(ONE 1) > > if(1 STREQUAL "ONE") > message("FOO") > else() > message("BAR") > endif() > > This code was designed for 3.0 (as indicated by the > cmake_minimum_required(VERSION)) and is meant to output "FOO". > When you use CMake 3.0 that is the behaviour you get (without warnings). > When you use CMake >= 3.1 the behaviour of the code itself is still > the same but you will get a CMP0054 warning telling you that the > behaviour that you currently depend on in if() has been deprecated. > > Now you decide to bump your minimum required version from 3.0 to 3.1 > and ignore or suppress the policy warning from before: > > cmake_minimum_required(VERSION 3.1) > > set(ONE 1) > > if(1 STREQUAL "ONE") > message("FOO") > else() > message("BAR) > endif() > > Now when you use CMake >= 3.1 to run this code you will not get any > more warnings but it will also no longer behave like it used to. > > It will output "BAR" instead of "FOO". > And this code will produce "FOO": cmake_minimum_required(VERSION 3.1) cmake_policy(SET CMP0054 OLD) # behave like 3.0 set(ONE 1) if(1 STREQUAL "ONE") message("FOO") else() message("BAR") endif() In this example by `cmake_minimum_required(VERSION 3.1)` you telling user that you're planning to use some **feature** from CMake 3.1. This feature may be about interpreting differently `if(1 STREQUAL "ONE")` and `if(1 STREQUAL ONE)` or may be about anything else. Note that CMake 3.0 **has no such feature** and commands `if(1 STREQUAL "ONE")` /`if(1 STREQUAL ONE)` is same for him always. Policy CMP0054 is about **behaviour**: "how we really should interpret `if(1 STREQUAL "ONE")`"? Yes, `cmake_minimum_required(VERSION 3.1)` set the policy **implicitly** to NEW. But you can control it yourself, like set it to NEW explicitly (which make no sense here but can be done), or set it to OLD. Ruslo -------------- next part -------------- An HTML attachment was scrubbed... URL: From ruslan_baratov at yahoo.com Wed Nov 9 06:05:20 2016 From: ruslan_baratov at yahoo.com (Ruslan Baratov) Date: Wed, 9 Nov 2016 19:05:20 +0800 Subject: [CMake] Adding Cmake version in online documentation In-Reply-To: <1bfcd0b6-aafc-92bb-ec9b-9adada91175d@gmail.com> References: <81966572-ec61-cad5-489e-57f8e4b569f4@dynamixyz.com> <279329a8-6701-8629-5d5c-83a00c0c8f4a@gmail.com> <5ec9fa17-50c3-a523-416b-731c6aba64da@gmail.com> <1ac63c56-494b-fd5b-0ced-d133288a44e2@online.de> <136407e6-7109-db65-a317-819d3b2e3ccd@gmail.com> <1c9af92e-0be6-8e51-3a24-f30d191212bf@yahoo.com> <1bfcd0b6-aafc-92bb-ec9b-9adada91175d@gmail.com> Message-ID: On 09-Nov-16 16:22, Nils Gladitz wrote: > On 09.11.2016 03:47, Ruslan Baratov wrote: >> On 09-Nov-16 06:01, Nils Gladitz wrote: >>> I think the git tag creation dates should roughly equate release dates: >>> https://cmake.org/gitweb?p=cmake.git;a=tags >> What about the future releases? There was a page >> https://cmake.org/Bug/changelog_page.php before but it's no longer valid >> as far as I understand. > > https://gitlab.kitware.com/cmake/cmake/milestones > > I wouldn't consider those dates to be anything but very rough > estimates though. > > Nils Ok, thanks. At least something :) Ruslo From nilsgladitz at gmail.com Wed Nov 9 06:51:10 2016 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Wed, 9 Nov 2016 12:51:10 +0100 Subject: [CMake] Adding Cmake version in online documentation In-Reply-To: <1b2026f0-5192-9873-46ce-219dd9d74534@yahoo.com> References: <81966572-ec61-cad5-489e-57f8e4b569f4@dynamixyz.com> <279329a8-6701-8629-5d5c-83a00c0c8f4a@gmail.com> <38c1331b-6989-d2d7-3422-0ada60d9dac0@yahoo.com> <2a0e1f85-6129-abe1-12d1-e85f2b8d16ce@gmail.com> <98f9bbf7-0898-c249-3a1f-7b82b32d5912@yahoo.com> <1b2026f0-5192-9873-46ce-219dd9d74534@yahoo.com> Message-ID: <3c46458b-e1bf-6914-acd2-0a9acb63d9ba@gmail.com> On 09.11.2016 12:04, Ruslan Baratov wrote: > On 09-Nov-16 16:22, Nils Gladitz wrote: >> On 09.11.2016 04:29, Ruslan Baratov wrote: >>> On 08-Nov-16 23:33, Nils Gladitz wrote: >>>> On 11/08/2016 04:17 PM, Ruslan Baratov wrote: >>>> >>>>> Except it's exactly opposite :) `cmake_minimum_required` is about new >>>>> features/commands, and policies is about behavior. >>>> >>>> I don't agree and you can not separate the two. >>>> cmake_minimum_required() initializes the policies based on the >>>> given version. >>> So what? From the user's perspective the "initialization of >>> policies" is like a syntactic sugar so you don't have to write >>> endless `cmake_policy(SET CMP00xx NEW)`. Nothing to do how to deal >>> with them further. >> >> You can't simultaneously argue that cmake_minimum_required() isn't >> about policies (behaviours) and at the same time syntactic sugar for >> those very same policies. > You're playing with words instead of using arguments. There was no word play involved. You say cmake_minimum_required() is not about behaviour yet it initializes all policies which are purely about behaviour. > >> >> Policy warnings aren't meant to indicate errors in your code but >> changes in behaviour that will happen if you were to increase your >> minimum required version. > Policy CMP0038 doesn't agree with you: > https://cmake.org/cmake/help/latest/policy/CMP0038.html No policies are still primarily about behaviour changes. That is true for CMP0038 as well. The old behaviour is to ignore this issue in user code. The new behaviour is to produce an error. When maintainers get this warning they are informed that their code will break as soon as they increase their minimum required version. The same is true for CMP0054. The policy warning did find many errors in user code but the warning is primarily about the change in behaviour. > Yes, like this: > > cmake_minimum_required(VERSION 2.8) > project(foo) > > if(POLICY CMP0038)cmake_policy(SET CMP0038 OLD) endif() > > Now CMake 3.0 users will not see the warning and CMake 2.8 users > **don't have to upgrade**. Yes but I don't see what point you are trying to make ... they didn't have to upgrade without the explicit policy set either. And the policy warnings aren't meant for users they are meant for maintainers. >>>> In fact all that setting it to OLD does is suppress the warning. > Actually this statement is wrong. Take a look at this example: > > # CMakeLists.txt > cmake_minimum_required(VERSION 3.0) > project(fooVERSION 1.2.3) > cmake_policy(SET CMP0038 OLD) # Do not remove this! > add_library(foofoo.cpp) > target_link_libraries(foofoo) > > if you remove `cmake_policy(SET CMP0038 OLD)` this example will > produce **error**. It may happens when you want to use new **feature** > `project(VERSION)` from 3.0, hence you set > `cmake_minimum_required(VERSION 3.0)` and simultaneously you have code > which produce warning about CMP0038. By setting `cmake_policy(SET > CMP0038 OLD)` you suppress the error, i.e. change **behaviour**. You took this out of context. I was talking about your second example about CMP0054 which was unset by cmake_minimum_required(VERSION 2.8) and then explicitly set to OLD by you. In this new case you have a policy that is initialized to NEW by cmake_minimum_required(VERSION 3.0) and then set to OLD by you. Policies are not meant to be feature toggles. You are explicitly asking CMake to use deprecated behaviour (that should no longer be used and might be removed in the future) over new behaviour. > >>> It's better than emitting zillion of warnings to the output, right? >>> You can suppress one type and fix another, set TODOs, etc. >> >> Policy warnings are intended to encourage you to switch to new >> behaviours since the old ones are deprecated. >> In actively maintained projects they are not meant to be suppressed. > Why not? If you're not planning to fix them right now? I'm not saying > you have to ignore them, you have to do fixes, but why not suppress > and say work on other fixes? Like I said policies are not primarily about fixing code. They are about migrating to new behaviours introduced by new versions of CMake. > > And this code will produce "FOO": > > cmake_minimum_required(VERSION 3.1) > > cmake_policy(SET CMP0054 OLD) # behave like 3.0 > > set(ONE 1) > > if(1 STREQUAL "ONE") > message("FOO") > else() > message("BAR") > endif() > > In this example by `cmake_minimum_required(VERSION 3.1)` you telling > user that you're planning to use some **feature** from CMake 3.1. Again I disagree. cmake_minimum_required(VERSION 3.1) tells CMake to behave like 3.1. It does not indicate that you want to use any 3.1 specific features. > This feature may be about interpreting differently `if(1 STREQUAL > "ONE")` and `if(1 STREQUAL ONE)` or may be about anything else. Note > that CMake 3.0 **has no such feature** and commands `if(1 STREQUAL > "ONE")` /`if(1 STREQUAL ONE)` is same for him always. Policy CMP0054 > is about **behaviour**: "how we really should interpret `if(1 STREQUAL > "ONE")`"? Yes, `cmake_minimum_required(VERSION 3.1)` set the policy > **implicitly** to NEW. But you can control it yourself, like set it to > NEW explicitly (which make no sense here but can be done), or set it > to OLD. Again policies are not meant to be feature toggles. You can do a lot of things and there may be valid use cases but in general policies are not meant to be used this way. This is made explicit in CMake's documentation on policies. They exist to preserve backwards compatibility not to pick and choose behaviours. Nils -------------- next part -------------- An HTML attachment was scrubbed... URL: From jsvanbethlehem at gmail.com Wed Nov 9 07:38:01 2016 From: jsvanbethlehem at gmail.com (Jakob van Bethlehem) Date: Wed, 9 Nov 2016 13:38:01 +0100 Subject: [CMake] Adding Cmake version in online documentation In-Reply-To: References: <81966572-ec61-cad5-489e-57f8e4b569f4@dynamixyz.com> <279329a8-6701-8629-5d5c-83a00c0c8f4a@gmail.com> <5ec9fa17-50c3-a523-416b-731c6aba64da@gmail.com> <1ac63c56-494b-fd5b-0ced-d133288a44e2@online.de> Message-ID: +1 for me too - sometime ago a college of mine spend quite some time to figure why he couldn't bootstrap our application - turns out he was using an (old) CMake version which didn't know about the 'continue' command. The error-messages coming out of CMake sometimes help, but more often don't really give the correct hint, unless you happen to be one of the local CMake gurus. Sincerely, Jakob On Tue, Nov 8, 2016 at 10:33 PM, Craig Scott wrote: > Rather than trying to do everything, perhaps there's value in tackling > this in stages. At a high level, simply knowing in which CMake version a > particular command, property, variable or module was added is a good start. > From there, if a command, etc. gained new options, then a note could be > added with the text specific to that option to indicate when it was added. > Obviously the more fine grained you go, the more time consuming and onerous > it would become, but how about just starting with the coarse level? That > already provides a big improvement over the current alternative of wading > through past versions of documentation and/or source code. > > I'd also recommend that such version details be part of the actual CMake > docs. While the separate compatibility matrix on the wiki is/was a useful > resource, by not having it part of the CMake sources/docs, it is inherently > a separate effort to try to keep it up to date with each CMake release. > Making it part of CMake itself would seem to encourage documenting version > details as part of the same merge requests, etc. that add/change things. > > I'll go out on a limb here and suggest that if a clear guideline was given > for *how* version details should be documented, then the community itself > would likely work towards populating that information over time. I don't > think there is a (realistic) expectation that Kitware would do all the > heavy lifting here. > > > > On Wed, Nov 9, 2016 at 8:23 AM, Eric Noulard > wrote: > >> >> >> 2016-11-08 20:26 GMT+01:00 Albrecht Schlosser : >> >>> On 08.11.2016 15:22 Nils Gladitz wrote: >>> >>>> On 11/08/2016 03:11 PM, Dvir Yitzchaki wrote: >>>> >>>> But how do you know which version to declare on cmake_minimum_required? >>>>> If this feature will be added it won't be far from writing a script >>>>> that scans the commands you use and outputs the first appropriate >>>>> version. >>>>> >>>> >>> I'd also like such an addition to the documentation for reasons >>> discussed below. >> >> >> >> I think the need is recognized by most CMake user but... >> >> >>> >>> >>> Strictly speaking cmake_minimum_required(VERSION) is not about command >>>> availability but rather about behavior (cmake policies). >>>> >>> [...] >>> >>>> I'd start by requesting the highest possible version I could justify >>>> (e.g. based on availability on target platforms and user convenience) >>>> and then start from there. >>>> >>> >>> And that's exactly the (my) point. How can I find out the "highest >>> possible version I could justify"? >>> >>> I'm a developer of a public GUI library (FLTK). In this position you >>> don't know anything about the availability of CMake versions on your target >>> platforms. Our intention is to keep cmake_minimum_required() as low as >>> possible. >>> >>> That said, whenever you change a CMakeLists.txt file you should be aware >>> if the commands you use are compatible with the CMake version you >>> "require". There should be an easy way to find out in which version a >>> particular CMake command has been introduced. Only with this information >>> you can decide if you should use this fine command or better find another >>> way to do the task you're going to do. >>> >>> I'd like to have a list of release dates (I'm not sure if there is one) >>> as well as the exact version a feature was introduced to write >>> CMakeLists.txt files that run on really old CMake versions >> >> >> Some time ago people came up (dig the ML for the related discussion) with >> compatibility matrix idea: >> https://cmake.org/Wiki/CMake_Version_Compatibility_Matrix >> http://public.kitware.com/pipermail/cmake/2010-December/041202.html >> >> And it finally ends with cmake 3.0.0 >> http://public.kitware.com/pipermail/cmake/2015-March/059983.html >> >> Note that this is far more complicated than simply listing when one >> command appears because some command may get more options, or change their >> default semantic >> (using POLICY etc..) so the feature granularity leads to question like >> >> When did the 'string' cmake command support the UUID argument ? >> >> Before which version of CMake does get_target_property >> accept non-existent target argument without issuing any error or warning ? >> (see POLICY CMP0045) >> >> So basically, tracking all kind of behavior change is not as easy as it >> seems. >> >> How can we document the changes ? Or better extract them from the code or >> documentation? >> >> -- >> Eric >> >> -- >> >> Powered by www.kitware.com >> >> Please keep messages on-topic and check the CMake FAQ at: >> http://www.cmake.org/Wiki/CMake_FAQ >> >> Kitware offers various services to support the CMake community. For more >> information on each offering, please visit: >> >> CMake Support: http://cmake.org/cmake/help/support.html >> CMake Consulting: http://cmake.org/cmake/help/consulting.html >> CMake Training Courses: http://cmake.org/cmake/help/training.html >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/cmake >> > > > > -- > 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 jsvanbethlehem at gmail.com Wed Nov 9 07:48:55 2016 From: jsvanbethlehem at gmail.com (Jakob van Bethlehem) Date: Wed, 9 Nov 2016 13:48:55 +0100 Subject: [CMake] Adding Cmake version in online documentation In-Reply-To: References: <81966572-ec61-cad5-489e-57f8e4b569f4@dynamixyz.com> <279329a8-6701-8629-5d5c-83a00c0c8f4a@gmail.com> <5ec9fa17-50c3-a523-416b-731c6aba64da@gmail.com> <1ac63c56-494b-fd5b-0ced-d133288a44e2@online.de> Message-ID: Oops, totally forgot to mention the crux: I happened to be the guy who apparently was the first to start using continue() - so by the time my college got to me, we quickly found out the issue. But before the college hit the problem, I didn't have the vaguest clue that I was typing code that would require an update of the minimum cmake version. Honestly, the fact that we don't have some strict policy in our team for setting version of 3rd parties like CMake, leading to different developers ending up with different versions, is questionable, yes, of course. It is the reality however, and my feeling is this is the reality for many more teams. Given the copious amount of traffic this issue has generated on this thread, and in the past(!), it seems no more than reasonable that at least *something* should happen. I do assume user feedback plays an important role in deciding where to go with CMake development? Sincerely, Jakob On Wed, Nov 9, 2016 at 1:38 PM, Jakob van Bethlehem < jsvanbethlehem at gmail.com> wrote: > +1 for me too - sometime ago a college of mine spend quite some time to > figure why he couldn't bootstrap our application - turns out he was using > an (old) CMake version which didn't know about the 'continue' command. The > error-messages coming out of CMake sometimes help, but more often don't > really give the correct hint, unless you happen to be one of the local > CMake gurus. > > Sincerely, > Jakob > > > On Tue, Nov 8, 2016 at 10:33 PM, Craig Scott > wrote: > >> Rather than trying to do everything, perhaps there's value in tackling >> this in stages. At a high level, simply knowing in which CMake version a >> particular command, property, variable or module was added is a good start. >> From there, if a command, etc. gained new options, then a note could be >> added with the text specific to that option to indicate when it was added. >> Obviously the more fine grained you go, the more time consuming and onerous >> it would become, but how about just starting with the coarse level? That >> already provides a big improvement over the current alternative of wading >> through past versions of documentation and/or source code. >> >> I'd also recommend that such version details be part of the actual CMake >> docs. While the separate compatibility matrix on the wiki is/was a useful >> resource, by not having it part of the CMake sources/docs, it is inherently >> a separate effort to try to keep it up to date with each CMake release. >> Making it part of CMake itself would seem to encourage documenting version >> details as part of the same merge requests, etc. that add/change things. >> >> I'll go out on a limb here and suggest that if a clear guideline was >> given for *how* version details should be documented, then the community >> itself would likely work towards populating that information over time. I >> don't think there is a (realistic) expectation that Kitware would do all >> the heavy lifting here. >> >> >> >> On Wed, Nov 9, 2016 at 8:23 AM, Eric Noulard >> wrote: >> >>> >>> >>> 2016-11-08 20:26 GMT+01:00 Albrecht Schlosser >>> : >>> >>>> On 08.11.2016 15:22 Nils Gladitz wrote: >>>> >>>>> On 11/08/2016 03:11 PM, Dvir Yitzchaki wrote: >>>>> >>>>> But how do you know which version to declare on cmake_minimum_required? >>>>>> If this feature will be added it won't be far from writing a script >>>>>> that scans the commands you use and outputs the first appropriate >>>>>> version. >>>>>> >>>>> >>>> I'd also like such an addition to the documentation for reasons >>>> discussed below. >>> >>> >>> >>> I think the need is recognized by most CMake user but... >>> >>> >>>> >>>> >>>> Strictly speaking cmake_minimum_required(VERSION) is not about command >>>>> availability but rather about behavior (cmake policies). >>>>> >>>> [...] >>>> >>>>> I'd start by requesting the highest possible version I could justify >>>>> (e.g. based on availability on target platforms and user convenience) >>>>> and then start from there. >>>>> >>>> >>>> And that's exactly the (my) point. How can I find out the "highest >>>> possible version I could justify"? >>>> >>>> I'm a developer of a public GUI library (FLTK). In this position you >>>> don't know anything about the availability of CMake versions on your target >>>> platforms. Our intention is to keep cmake_minimum_required() as low as >>>> possible. >>>> >>>> That said, whenever you change a CMakeLists.txt file you should be >>>> aware if the commands you use are compatible with the CMake version you >>>> "require". There should be an easy way to find out in which version a >>>> particular CMake command has been introduced. Only with this information >>>> you can decide if you should use this fine command or better find another >>>> way to do the task you're going to do. >>>> >>>> I'd like to have a list of release dates (I'm not sure if there is one) >>>> as well as the exact version a feature was introduced to write >>>> CMakeLists.txt files that run on really old CMake versions >>> >>> >>> Some time ago people came up (dig the ML for the related discussion) >>> with compatibility matrix idea: >>> https://cmake.org/Wiki/CMake_Version_Compatibility_Matrix >>> http://public.kitware.com/pipermail/cmake/2010-December/041202.html >>> >>> And it finally ends with cmake 3.0.0 >>> http://public.kitware.com/pipermail/cmake/2015-March/059983.html >>> >>> Note that this is far more complicated than simply listing when one >>> command appears because some command may get more options, or change their >>> default semantic >>> (using POLICY etc..) so the feature granularity leads to question like >>> >>> When did the 'string' cmake command support the UUID argument ? >>> >>> Before which version of CMake does get_target_property >>> accept non-existent target argument without issuing any error or warning ? >>> (see POLICY CMP0045) >>> >>> So basically, tracking all kind of behavior change is not as easy as it >>> seems. >>> >>> How can we document the changes ? Or better extract them from the code >>> or documentation? >>> >>> -- >>> Eric >>> >>> -- >>> >>> Powered by www.kitware.com >>> >>> Please keep messages on-topic and check the CMake FAQ at: >>> http://www.cmake.org/Wiki/CMake_FAQ >>> >>> Kitware offers various services to support the CMake community. For more >>> information on each offering, please visit: >>> >>> CMake Support: http://cmake.org/cmake/help/support.html >>> CMake Consulting: http://cmake.org/cmake/help/consulting.html >>> CMake Training Courses: http://cmake.org/cmake/help/training.html >>> >>> Visit other Kitware open-source projects at >>> http://www.kitware.com/opensource/opensource.html >>> >>> Follow this link to subscribe/unsubscribe: >>> http://public.kitware.com/mailman/listinfo/cmake >>> >> >> >> >> -- >> 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 jsvanbethlehem at gmail.com Wed Nov 9 07:53:09 2016 From: jsvanbethlehem at gmail.com (Jakob van Bethlehem) Date: Wed, 9 Nov 2016 13:53:09 +0100 Subject: [CMake] Get libraries from target In-Reply-To: References: Message-ID: Hej, You should be able to query the LINK_LIBRARIES (and maybe some related properties), see https://cmake.org/cmake/help/v3.6/prop_tgt/LINK_LIBRARIES.html Sincerely, Jakob On Wed, Nov 9, 2016 at 12:05 AM, Tiago Macarios wrote: > Hi, > > Is there a way for me to get CMake libraries out of a target? > > For example: > > target_link_libraries(A B C) > > Can I get B and C from A? > > What I am trying to do: > We are working on adding include-what-you-use into our build system and > some of the libraries have their on mapping files. So I was wondering if I > could somehow "attach" the mapping file to the target and then > "reconstruct" a mapping file for each target. > > For example: > > Library B and C have their own mapping, so I would: > set_target_properties(B > PROPERTIES mapping /path/to/fileB) > set_target_properties(C > PROPERTIES mapping /path/to/fileC) > > Then a function would reconstruct a mapping for target A: > set_target_properties(A > PROPERTIES mapping /path/to/fileA) > > create_mapping_function(A): > loop over dependencies of A > get all mappings > recreate a mapping file with all dependencies: > > { ref: "/path/to/fileA" }, > { ref: "/path/to/fileB" } > { ref: "/path/to/fileC" } > > > -- > > 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 jsvanbethlehem at gmail.com Wed Nov 9 07:56:17 2016 From: jsvanbethlehem at gmail.com (Jakob van Bethlehem) Date: Wed, 9 Nov 2016 13:56:17 +0100 Subject: [CMake] Pointing CMAKE_AUTOMOC to a custom version of Qt and its moc.exe In-Reply-To: References: Message-ID: Hej, On Mon, Nov 7, 2016 at 4:48 PM, Saad Khattak wrote: > I am working on a plugin for Maya and it uses a customized version of Qt. > Maya's SDK comes with everything to build Qt (headers, libraries and > customized Qt tools such as moc.exe). > > I have the following issues: > > (1) With CMAKE_AUTOMOC set to ON, I am unable to figure out how to point > CMake to pick Maya's version of moc.exe (and other Qt utils). The result is > that I get linking errors since the moc did not run - which I expected. > > (2) Maya uses a modified version of Qt 5.6.1. There is currently no way to > get that version from Autodesk. So I downloaded the official Qt 5.6.1 > distribution. CMAKE_AUTOMOC now sets up my project correctly to be MOC'ed. > However, it is using the official Qt moc utilities and NOT Maya's > customized moc. The headers and libraries being used were still from Maya's > custom Qt. > > The reason (2) worked is because I put "find_package(Qt5Widgets REQUIRED)" > after installing the official version of Qt 5.6.1. However, I did NOT use > the official Qt headers or libraries - instead, I used Maya's custom > version of Qt 5.6.1. > > Using solution (2) I successfully compile and link my Qt enabled Maya > plugin and load it in Maya. Things go smoothly until I either (a) unload > the plugin or (b) delete any widget. I looked at the simplest code that is > causing a heap corruption debug assertion: > > m_button = new QPushButton("MyButton"); // where m_button is a QPointer > > delete m_button; // causes heap corruption debug assertion to fire > > A few other people have gone through similar issues but since they didn't > use CMake, they simply ran Maya's moc utilities in a build step. I would > like a solution where I can get CMAKE_AUTOMOC to run the custom Qt version. > > Thanks. > > I see quite a lot usage of the word 'customized'..... to me it sounds like you may be asking on the wrong user list? Sincerely, Jakob -------------- next part -------------- An HTML attachment was scrubbed... URL: From ruslan_baratov at yahoo.com Wed Nov 9 08:57:47 2016 From: ruslan_baratov at yahoo.com (Ruslan Baratov) Date: Wed, 9 Nov 2016 21:57:47 +0800 Subject: [CMake] Adding Cmake version in online documentation In-Reply-To: <3c46458b-e1bf-6914-acd2-0a9acb63d9ba@gmail.com> References: <81966572-ec61-cad5-489e-57f8e4b569f4@dynamixyz.com> <279329a8-6701-8629-5d5c-83a00c0c8f4a@gmail.com> <38c1331b-6989-d2d7-3422-0ada60d9dac0@yahoo.com> <2a0e1f85-6129-abe1-12d1-e85f2b8d16ce@gmail.com> <98f9bbf7-0898-c249-3a1f-7b82b32d5912@yahoo.com> <1b2026f0-5192-9873-46ce-219dd9d74534@yahoo.com> <3c46458b-e1bf-6914-acd2-0a9acb63d9ba@gmail.com> Message-ID: <0a0ffaba-3b9d-fcf2-af0d-4cce42bf8184@yahoo.com> On 09-Nov-16 19:51, Nils Gladitz wrote: > On 09.11.2016 12:04, Ruslan Baratov wrote: >> On 09-Nov-16 16:22, Nils Gladitz wrote: >>> On 09.11.2016 04:29, Ruslan Baratov wrote: >>>> On 08-Nov-16 23:33, Nils Gladitz wrote: >>>>> On 11/08/2016 04:17 PM, Ruslan Baratov wrote: >>>>> >>>>>> Except it's exactly opposite :) `cmake_minimum_required` is about >>>>>> new >>>>>> features/commands, and policies is about behavior. >>>>> >>>>> I don't agree and you can not separate the two. >>>>> cmake_minimum_required() initializes the policies based on the >>>>> given version. >>>> So what? From the user's perspective the "initialization of >>>> policies" is like a syntactic sugar so you don't have to write >>>> endless `cmake_policy(SET CMP00xx NEW)`. Nothing to do how to deal >>>> with them further. >>> >>> You can't simultaneously argue that cmake_minimum_required() isn't >>> about policies (behaviours) and at the same time syntactic sugar for >>> those very same policies. >> You're playing with words instead of using arguments. > > There was no word play involved. > You say cmake_minimum_required() is not about behaviour yet it > initializes all policies which are purely about behaviour. >From documentation (https://cmake.org/cmake/help/latest/command/cmake_minimum_required.html): The |cmake_minimum_required(VERSION)| command implicitly invokes the |cmake_policy(VERSION)| command So this macro do implicitly invokes the cmake_policy comand: macro(printvar a) cmake_policy(VERSION 3.0) message("Variable a: ${a}") endmacro() Can we said that 'printvar' affect behaviour? Sure! But what is the point of this statement in the scope of this discussion? So similar to your statement: Strictly speaking cmake_minimum_required(VERSION) is not about command availability but rather about behavior (cmake policies). I can say now: Strictly speaking 'printvar' is not about printing variable but rather about behavior (cmake policies). It's hard to argue with this... > >> >>> >>> Policy warnings aren't meant to indicate errors in your code but >>> changes in behaviour that will happen if you were to increase your >>> minimum required version. >> Policy CMP0038 doesn't agree with you: >> https://cmake.org/cmake/help/latest/policy/CMP0038.html > > No policies are still primarily about behaviour changes. That is true > for CMP0038 as well. > > The old behaviour is to ignore this issue in user code. The new > behaviour is to produce an error. I said that "most of them will be about bugs in my code", so not all of them about bugs. However you said "warnings aren't meant to indicate errors" - this statement is wrong, and I have proved it with the link. The statement that "policies is all about behaviour" is 50% of what I'm trying to say here. > When maintainers get this warning they are informed that their code > will break as soon as they increase their minimum required version. No, it will not break always because they can control it with policies, in our case setting policy to OLD will do the trick. > > The same is true for CMP0054. The policy warning did find many errors > in user code but the warning is primarily about the change in behaviour. And why behaviour changed? Because the way how variables interpreted before CMP0054 was confusing, dangerous and depend on the value of unrelated variables from the current scope. > >> Yes, like this: >> >> cmake_minimum_required(VERSION 2.8) >> project(foo) >> >> if(POLICY CMP0038)cmake_policy(SET CMP0038 OLD) endif() >> >> Now CMake 3.0 users will not see the warning and CMake 2.8 users >> **don't have to upgrade**. > > Yes but I don't see what point you are trying to make ... they didn't > have to upgrade without the explicit policy set either. > And the policy warnings aren't meant for users they are meant for > maintainers. Originally you said that "Given your second example you likely shouldn't be touching the policy at all". I describe the example when it make sense and provide the reasons. If you're not interested about warnings and your users doesn't report the problems they see, then yes, probably it's fine for you to not to touch the policies. > >>>>> In fact all that setting it to OLD does is suppress the warning. >> Actually this statement is wrong. Take a look at this example: >> >> # CMakeLists.txt >> cmake_minimum_required(VERSION 3.0) >> project(fooVERSION 1.2.3) >> cmake_policy(SET CMP0038 OLD) # Do not remove this! >> add_library(foofoo.cpp) >> target_link_libraries(foofoo) >> >> if you remove `cmake_policy(SET CMP0038 OLD)` this example will >> produce **error**. It may happens when you want to use new >> **feature** `project(VERSION)` from 3.0, hence you set >> `cmake_minimum_required(VERSION 3.0)` and simultaneously you have >> code which produce warning about CMP0038. By setting >> `cmake_policy(SET CMP0038 OLD)` you suppress the error, i.e. change >> **behaviour**. > > You took this out of context. I was talking about your second example > about CMP0054 which was unset by cmake_minimum_required(VERSION 2.8) > and then explicitly set to OLD by you. > In this new case you have a policy that is initialized to NEW by > cmake_minimum_required(VERSION 3.0) and then set to OLD by you. > > Policies are not meant to be feature toggles. You are explicitly > asking CMake to use deprecated behaviour (that should no longer be > used and might be removed in the future) over new behaviour. If you're talking about CMP0054, cmake_minimum_required(VERSION 2.8) and running it with CMake 3.2 then yes, all it does is only suppress the warning. > >> >>>> It's better than emitting zillion of warnings to the output, right? >>>> You can suppress one type and fix another, set TODOs, etc. >>> >>> Policy warnings are intended to encourage you to switch to new >>> behaviours since the old ones are deprecated. >>> In actively maintained projects they are not meant to be suppressed. >> Why not? If you're not planning to fix them right now? I'm not saying >> you have to ignore them, you have to do fixes, but why not suppress >> and say work on other fixes? > > Like I said policies are not primarily about fixing code. They are > about migrating to new behaviours introduced by new versions of CMake. So what is the deal here? You don't like the word "fix"? Okay, reread it with 's/fix/apply migration/g'. My point here was about that you can control different kind of warnings instead of blindly ignoring everything. > >> >> And this code will produce "FOO": >> >> cmake_minimum_required(VERSION 3.1) >> >> cmake_policy(SET CMP0054 OLD) # behave like 3.0 >> >> set(ONE 1) >> >> if(1 STREQUAL "ONE") >> message("FOO") >> else() >> message("BAR") >> endif() >> >> In this example by `cmake_minimum_required(VERSION 3.1)` you telling >> user that you're planning to use some **feature** from CMake 3.1. > > Again I disagree. cmake_minimum_required(VERSION 3.1) tells CMake to > behave like 3.1. It does not indicate that you want to use any 3.1 > specific features. You can use it like this and it will work, however it doesn't make sense. What is the point of not using any feature from 3.1 and have `cmake_minimum_required(VERSION 3.1)`? Why not to set it to `cmake_minimum_required(VERSION 2.8)` and add some policy modification commands? Documentation is our friend (https://cmake.org/cmake/help/latest/manual/cmake-policies.7.html): To manage policies without increasing the minimum required CMake version, the |if(POLICY)| command may be used if(POLICYCMP0990) cmake_policy(SET CMP0990 NEW) endif() > >> This feature may be about interpreting differently `if(1 STREQUAL >> "ONE")` and `if(1 STREQUAL ONE)` or may be about anything else. Note >> that CMake 3.0 **has no such feature** and commands `if(1 STREQUAL >> "ONE")` /`if(1 STREQUAL ONE)` is same for him always. Policy CMP0054 >> is about **behaviour**: "how we really should interpret `if(1 >> STREQUAL "ONE")`"? Yes, `cmake_minimum_required(VERSION 3.1)` set the >> policy **implicitly** to NEW. But you can control it yourself, like >> set it to NEW explicitly (which make no sense here but can be done), >> or set it to OLD. > > Again policies are not meant to be feature toggles. > You can do a lot of things and there may be valid use cases but in > general policies are not meant to be used this way. > This is made explicit in CMake's documentation on policies. > They exist to preserve backwards compatibility not to pick and choose > behaviours. > So can you show an example of "valid" use of `cmake_policy` command? Ruslo -------------- next part -------------- An HTML attachment was scrubbed... URL: From nilsgladitz at gmail.com Wed Nov 9 09:14:26 2016 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Wed, 9 Nov 2016 15:14:26 +0100 Subject: [CMake] Adding Cmake version in online documentation In-Reply-To: <0a0ffaba-3b9d-fcf2-af0d-4cce42bf8184@yahoo.com> References: <81966572-ec61-cad5-489e-57f8e4b569f4@dynamixyz.com> <279329a8-6701-8629-5d5c-83a00c0c8f4a@gmail.com> <38c1331b-6989-d2d7-3422-0ada60d9dac0@yahoo.com> <2a0e1f85-6129-abe1-12d1-e85f2b8d16ce@gmail.com> <98f9bbf7-0898-c249-3a1f-7b82b32d5912@yahoo.com> <1b2026f0-5192-9873-46ce-219dd9d74534@yahoo.com> <3c46458b-e1bf-6914-acd2-0a9acb63d9ba@gmail.com> <0a0ffaba-3b9d-fcf2-af0d-4cce42bf8184@yahoo.com> Message-ID: On 09.11.2016 14:57, Ruslan Baratov wrote: > > Again policies are not meant to be feature toggles. > You can do a lot of things and there may be valid use cases but in > general policies are not meant to be used this way. > This is made explicit in CMake's documentation on policies. > They exist to preserve backwards compatibility not to pick and choose > behaviours. > > So can you show an example of "valid" use of `cmake_policy` command? > To quote the documentation: "A policy is a deprecation mechanism and not a reliable feature toggle. A policy should almost never be set to |OLD|, except to silence warnings in an otherwise frozen or stable codebase, or temporarily as part of a larger migration path." Beyond that valid use would be e.g. cmake's own testsuite which needs to be able to toggle individual policies to verify their behaviour. Nils -------------- next part -------------- An HTML attachment was scrubbed... URL: From saadrustam at gmail.com Wed Nov 9 09:48:42 2016 From: saadrustam at gmail.com (Saad Khattak) Date: Wed, 09 Nov 2016 14:48:42 +0000 Subject: [CMake] Pointing CMAKE_AUTOMOC to a custom version of Qt and its moc.exe In-Reply-To: References: Message-ID: Hmm, maybe...? I'm not sure. Customize may be the wrong word. What I'm asking in the question is similar to someone asking "how do I customize the output path for the binaries in CMake?". My hope was it was going to be a simple set variable for the utilities. On Wed, Nov 9, 2016, 7:56 AM Jakob van Bethlehem wrote: > Hej, > > On Mon, Nov 7, 2016 at 4:48 PM, Saad Khattak wrote: > > I am working on a plugin for Maya and it uses a customized version of Qt. > Maya's SDK comes with everything to build Qt (headers, libraries and > customized Qt tools such as moc.exe). > > I have the following issues: > > (1) With CMAKE_AUTOMOC set to ON, I am unable to figure out how to point > CMake to pick Maya's version of moc.exe (and other Qt utils). The result is > that I get linking errors since the moc did not run - which I expected. > > (2) Maya uses a modified version of Qt 5.6.1. There is currently no way to > get that version from Autodesk. So I downloaded the official Qt 5.6.1 > distribution. CMAKE_AUTOMOC now sets up my project correctly to be MOC'ed. > However, it is using the official Qt moc utilities and NOT Maya's > customized moc. The headers and libraries being used were still from Maya's > custom Qt. > > The reason (2) worked is because I put "find_package(Qt5Widgets REQUIRED)" > after installing the official version of Qt 5.6.1. However, I did NOT use > the official Qt headers or libraries - instead, I used Maya's custom > version of Qt 5.6.1. > > Using solution (2) I successfully compile and link my Qt enabled Maya > plugin and load it in Maya. Things go smoothly until I either (a) unload > the plugin or (b) delete any widget. I looked at the simplest code that is > causing a heap corruption debug assertion: > > m_button = new QPushButton("MyButton"); // where m_button is a QPointer > > delete m_button; // causes heap corruption debug assertion to fire > > A few other people have gone through similar issues but since they didn't > use CMake, they simply ran Maya's moc utilities in a build step. I would > like a solution where I can get CMAKE_AUTOMOC to run the custom Qt version. > > Thanks. > > > I see quite a lot usage of the word 'customized'..... to me it sounds like > you may be asking on the wrong user list? > > Sincerely, > Jakob > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ruslan_baratov at yahoo.com Wed Nov 9 09:52:52 2016 From: ruslan_baratov at yahoo.com (Ruslan Baratov) Date: Wed, 9 Nov 2016 22:52:52 +0800 Subject: [CMake] Adding Cmake version in online documentation In-Reply-To: References: <81966572-ec61-cad5-489e-57f8e4b569f4@dynamixyz.com> <279329a8-6701-8629-5d5c-83a00c0c8f4a@gmail.com> <38c1331b-6989-d2d7-3422-0ada60d9dac0@yahoo.com> <2a0e1f85-6129-abe1-12d1-e85f2b8d16ce@gmail.com> <98f9bbf7-0898-c249-3a1f-7b82b32d5912@yahoo.com> <1b2026f0-5192-9873-46ce-219dd9d74534@yahoo.com> <3c46458b-e1bf-6914-acd2-0a9acb63d9ba@gmail.com> <0a0ffaba-3b9d-fcf2-af0d-4cce42bf8184@yahoo.com> Message-ID: <944e46b0-ab21-afb2-1d07-3e1d87e56c6c@yahoo.com> Can you show the real code? The code that in your opinion doesn't violate the "right way of policy usage"? On 09-Nov-16 22:14, Nils Gladitz wrote: > On 09.11.2016 14:57, Ruslan Baratov wrote: >> >> Again policies are not meant to be feature toggles. >> You can do a lot of things and there may be valid use cases but in >> general policies are not meant to be used this way. >> This is made explicit in CMake's documentation on policies. >> They exist to preserve backwards compatibility not to pick and choose >> behaviours. >> >> So can you show an example of "valid" use of `cmake_policy` command? >> > > To quote the documentation: > "A policy is a deprecation mechanism and not a reliable feature > toggle. A policy should almost never be set to |OLD|, except to > silence warnings in an otherwise frozen or stable codebase, or > temporarily as part of a larger migration path." > > Beyond that valid use would be e.g. cmake's own testsuite which needs > to be able to toggle individual policies to verify their behaviour. > > Nils > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nilsgladitz at gmail.com Wed Nov 9 10:00:12 2016 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Wed, 9 Nov 2016 16:00:12 +0100 Subject: [CMake] Adding Cmake version in online documentation In-Reply-To: <944e46b0-ab21-afb2-1d07-3e1d87e56c6c@yahoo.com> References: <81966572-ec61-cad5-489e-57f8e4b569f4@dynamixyz.com> <279329a8-6701-8629-5d5c-83a00c0c8f4a@gmail.com> <38c1331b-6989-d2d7-3422-0ada60d9dac0@yahoo.com> <2a0e1f85-6129-abe1-12d1-e85f2b8d16ce@gmail.com> <98f9bbf7-0898-c249-3a1f-7b82b32d5912@yahoo.com> <1b2026f0-5192-9873-46ce-219dd9d74534@yahoo.com> <3c46458b-e1bf-6914-acd2-0a9acb63d9ba@gmail.com> <0a0ffaba-3b9d-fcf2-af0d-4cce42bf8184@yahoo.com> <944e46b0-ab21-afb2-1d07-3e1d87e56c6c@yahoo.com> Message-ID: On 09.11.2016 15:52, Ruslan Baratov wrote: > Can you show the real code? The code that in your opinion doesn't > violate the "right way of policy usage"? It is not a question about code. It is a question about context and use case. Valid context as the documentation states would e.g. be a project that is no longer maintained where you have no intention of ever migrating to a newer CMake version. Or as I said cmake's testsuite. If you insist on actual code e.g. this is part of the tests that I wrote for CMP0054: https://cmake.org/gitweb?p=cmake.git;a=blob;f=Tests/RunCMake/CMP0054/CMP0054-NEW.cmake;h=23a912476024ba09fcf741e04f999b64a6e91450;hb=refs/heads/master Again the code itself is irrelevant here; what matters is the context. Nils From public at jayeshbadwaik.in Wed Nov 9 10:05:01 2016 From: public at jayeshbadwaik.in (Jayesh Badwaik) Date: Wed, 09 Nov 2016 16:05:01 +0100 Subject: [CMake] Is there a default value for CMAKE_MODULE_PATH? Message-ID: <8045330.BrvOJs8lRZ@wadner> Hi, TL;DR Is there a default value for CMAKE_MODULE_PATH which allows me to use a module file from inside my PROJECT_SOURCE_DIR. Context: Over past few days, Boost has updated from version 1.61 to version 1.62. The latest version of CMake that I have (3.6.3) does not yet have the appropriate FindBoost.cmake and hence, issues warnings as shown in the postscript. As I see this is temporary, and there is a correct FindBoost.cmake in the git repository which works fine. So, I want to use this new module file till the time when the new version of CMake comes out and I won't have to use this special file anymore. All the solutions that I have found on internet require me to put a line setting the CMAKE_MODULE_PATH in my project source code. I don't want to do it since the change is supposed to be temporary anyway. So, I was wondering if there is a location inside the PROJECT_SOURCE_DIR which is scanned by default by cmake? If there is no such location, I can live with the warnings for a little while, but I was just curious. -- Cheers Jayesh Badwaik https://www.jayeshbadwaik.in ================= CMake Warnings ================= CMake Warning at /usr/share/cmake-3.6/Modules/FindBoost.cmake:743 (message): Imported targets not available for Boost version 106200 Call Stack (most recent call first): /usr/share/cmake-3.6/Modules/FindBoost.cmake:842 (_Boost_COMPONENT_DEPENDENCIES) /usr/share/cmake-3.6/Modules/FindBoost.cmake:1395 (_Boost_MISSING_DEPENDENCIES) CMakeLists.txt:48 (find_package) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: This is a digitally signed message part. URL: From carl.poirier.2 at gmail.com Wed Nov 9 10:04:53 2016 From: carl.poirier.2 at gmail.com (Carl Poirier) Date: Wed, 9 Nov 2016 10:04:53 -0500 Subject: [CMake] PDB_NAME with DEBUG_POSTFIX In-Reply-To: References: Message-ID: Hi folks, A few months later, would anyone have an explanation for this? Thank you, Carl On Fri, Feb 19, 2016 at 9:07 AM, Carl Poirier wrote: > Hi folks, > > I have a question here regarding the use of the DEBUG_POSTFIX. When I set > it as well as the property OUTPUT_NAME, the former is correctly applied to > the latter. Now when I try to do so with a library, the DEBUG_POSTFIX does > not get applied to the PDB filename. Here are the relevant lines of my > CMakeLists.txt: > > # Set the resulting filenames > set_target_properties(${PrjName1} PROPERTIES COMPILE_PDB_NAME mylib) > set_target_properties(${PrjName1} PROPERTIES OUTPUT_NAME mylib) > > # Add "D" postfix for the debug build > set_target_properties(${PrjName1} PROPERTIES DEBUG_POSTFIX "D") > > So is there a reason why it works (or doesn't) that way? The best > workaround I have now is set the names on a per-configuration basis. > > Regards, > > Carl > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.wagner at intel.com Wed Nov 9 12:09:47 2016 From: david.wagner at intel.com (Wagner, David) Date: Wed, 9 Nov 2016 18:09:47 +0100 Subject: [CMake] Is there a default value for CMAKE_MODULE_PATH? In-Reply-To: <8045330.BrvOJs8lRZ@wadner> References: <8045330.BrvOJs8lRZ@wadner> Message-ID: <5823585B.4030906@intel.com> On 09/11/2016 16:05, Jayesh Badwaik wrote: > Hi, > > TL;DR > Is there a default value for CMAKE_MODULE_PATH which allows me to use a module > file from inside my PROJECT_SOURCE_DIR. > > Context: > Over past few days, Boost has updated from version 1.61 to version 1.62. The > latest version of CMake that I have (3.6.3) does not yet have the appropriate > FindBoost.cmake and hence, issues warnings as shown in the postscript. > Have you tried setting Boost_ADDITIONAL_VERSIONS ? c.f FindBoost's documentation: > Boost_ADDITIONAL_VERSIONS > - List of Boost versions not known to this module > (Boost install locations may contain the version) I don't know what changed in Boost 1.62 but doing so may be enough for you. Alternatively, you can set CMAKE_MODULE_PATH by hand in your command line. BR David -- David Wagner complex != complicated --------------------------------------------------------------------- Intel Corporation SAS (French simplified joint stock company) Registered headquarters: "Les Montalets"- 2, rue de Paris, 92196 Meudon Cedex, France Registration Number: 302 456 199 R.C.S. NANTERRE Capital: 4,572,000 Euros This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. From ruslan_baratov at yahoo.com Wed Nov 9 15:06:11 2016 From: ruslan_baratov at yahoo.com (Ruslan Baratov) Date: Thu, 10 Nov 2016 04:06:11 +0800 Subject: [CMake] Adding Cmake version in online documentation In-Reply-To: References: <81966572-ec61-cad5-489e-57f8e4b569f4@dynamixyz.com> <279329a8-6701-8629-5d5c-83a00c0c8f4a@gmail.com> <38c1331b-6989-d2d7-3422-0ada60d9dac0@yahoo.com> <2a0e1f85-6129-abe1-12d1-e85f2b8d16ce@gmail.com> <98f9bbf7-0898-c249-3a1f-7b82b32d5912@yahoo.com> <1b2026f0-5192-9873-46ce-219dd9d74534@yahoo.com> <3c46458b-e1bf-6914-acd2-0a9acb63d9ba@gmail.com> <0a0ffaba-3b9d-fcf2-af0d-4cce42bf8184@yahoo.com> <944e46b0-ab21-afb2-1d07-3e1d87e56c6c@yahoo.com> Message-ID: <33ee3cd7-a278-2e7c-6503-c865758115e1@yahoo.com> On 09-Nov-16 23:00, Nils Gladitz wrote: > On 09.11.2016 15:52, Ruslan Baratov wrote: >> Can you show the real code? The code that in your opinion doesn't >> violate the "right way of policy usage"? > > It is not a question about code. It is a question about context and > use case. You just said that all the code I've showed is not correct and conflicts with policies nature. So I have to ask you about the real code, because looks like in your "world" there is no valid case of `cmake_policy` usage and the only correct way to set policies is to use `cmake_minimum_required` command. Hence it's not surprising that you can't distinguish `cmake_minimum_required` and behavior controlled by `cmake_policy`. > > Valid context as the documentation states would e.g. be a project that > is no longer maintained where you have no intention of ever migrating > to a newer CMake version. So why the project in the middle of the migration process is not a valid case? It is maintained but the exact migration step is paused, but I have an intention to improve the code in future. Anyway even if the project is no longer maintained, then what we have? We have `cmake_minimum_required` with the version that fits **features** the code has and `cmake_policy` to control the **behavior** of different cmake versions. > Or as I said cmake's testsuite. > > If you insist on actual code e.g. this is part of the tests that I > wrote for CMP0054: > https://cmake.org/gitweb?p=cmake.git;a=blob;f=Tests/RunCMake/CMP0054/CMP0054-NEW.cmake;h=23a912476024ba09fcf741e04f999b64a6e91450;hb=refs/heads/master > The internal CMake stuff is out of the scope of discussion. If policies are the internals why do we need them in the documentation? Ruslo From public at jayeshbadwaik.in Wed Nov 9 15:19:26 2016 From: public at jayeshbadwaik.in (Jayesh Badwaik) Date: Wed, 09 Nov 2016 21:19:26 +0100 Subject: [CMake] Is there a default value for CMAKE_MODULE_PATH? In-Reply-To: <5823585B.4030906@intel.com> References: <8045330.BrvOJs8lRZ@wadner> <5823585B.4030906@intel.com> Message-ID: <8089348.ZzMSBsXByx@wadner> All of these version work, but because of the various kinds of automated setups I use, the command line options seems the best compromise. However, I realized that I have a include file in my source code which is ignored from the source control since it is user/system dependent, and I have put my config there now. Thanks a lot for your help. -- Cheers Jayesh Badwaik https://www.jayeshbadwaik.in -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: This is a digitally signed message part. URL: From nilsgladitz at gmail.com Thu Nov 10 02:40:01 2016 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Thu, 10 Nov 2016 08:40:01 +0100 Subject: [CMake] Adding Cmake version in online documentation In-Reply-To: <33ee3cd7-a278-2e7c-6503-c865758115e1@yahoo.com> References: <81966572-ec61-cad5-489e-57f8e4b569f4@dynamixyz.com> <279329a8-6701-8629-5d5c-83a00c0c8f4a@gmail.com> <38c1331b-6989-d2d7-3422-0ada60d9dac0@yahoo.com> <2a0e1f85-6129-abe1-12d1-e85f2b8d16ce@gmail.com> <98f9bbf7-0898-c249-3a1f-7b82b32d5912@yahoo.com> <1b2026f0-5192-9873-46ce-219dd9d74534@yahoo.com> <3c46458b-e1bf-6914-acd2-0a9acb63d9ba@gmail.com> <0a0ffaba-3b9d-fcf2-af0d-4cce42bf8184@yahoo.com> <944e46b0-ab21-afb2-1d07-3e1d87e56c6c@yahoo.com> <33ee3cd7-a278-2e7c-6503-c865758115e1@yahoo.com> Message-ID: <133a4b34-56e1-6e57-5da8-4d91c3ded1ab@gmail.com> On 11/09/2016 09:06 PM, Ruslan Baratov wrote: > > So why the project in the middle of the migration process is not a valid > case? It is maintained but the exact migration step is paused, but I > have an intention to improve the code in future. Anyway even if the > project is no longer maintained, then what we have? We have > `cmake_minimum_required` with the version that fits **features** the > code has and `cmake_policy` to control the **behavior** of different > cmake versions. Temporary use during migration to a new CMake version is one of the use cases explicitly mentioned in the documentation. But when you say you might migrate some time in the future that makes it sound like you aren't actually in the process of migration but are rather looking for some loophole. > >> Or as I said cmake's testsuite. >> >> If you insist on actual code e.g. this is part of the tests that I >> wrote for CMP0054: >> https://cmake.org/gitweb?p=cmake.git;a=blob;f=Tests/RunCMake/CMP0054/CMP0054-NEW.cmake;h=23a912476024ba09fcf741e04f999b64a6e91450;hb=refs/heads/master >> > The internal CMake stuff is out of the scope of discussion. If policies > are the internals why do we need them in the documentation? Well you could have excluded the case when I brought it up initially preferably before asking for code. I don't have any unmaintained public projects in mind that I could link to. But then again as I said before the code itself is entirely irrelevant; what counts is the context. Nils From joubert.sy at gmail.com Thu Nov 10 04:57:00 2016 From: joubert.sy at gmail.com (Sylvain Joubert) Date: Thu, 10 Nov 2016 10:57:00 +0100 Subject: [CMake] Warnings with newer versions of Boost imported targets Message-ID: Hi, I'm using CMake 3.6.3 (so up-to-date version at this point). After updating my Boost libraries to the newest version (1.62 just landed on my Debian testing) I get a bunch of warnings: "Imported targets not available for Boost version 106200" There seems to be a fallback behavior working fine, so I'm not blocked but these warnings are very annoying. I see that support for version 1.62 has been added in CMake with 9bb8ac8 and a997cac and will be available in CMake 3.7 My questions would be: 1- Does this mean that CMake can't use imported targets on Boost versions it doesn't know explicitly? (the fallback behavior does not seem to have this problem) 2- Does that mean I can't update my boost version without also updating my CMake version? (which for this specific use case cannot be done until the next CMake version) 3- Is there a way to fix/disable these warnings in a proper way? Thanks, Sylvain -------------- next part -------------- An HTML attachment was scrubbed... URL: From demelier.david at gmail.com Fri Nov 11 02:54:41 2016 From: demelier.david at gmail.com (demelier.david at gmail.com) Date: Fri, 11 Nov 2016 08:54:41 +0100 Subject: [CMake] FindBoost warning but working Message-ID: <1478850881.1043.1.camel@localhost> Hi, with the following CMakeLists.txt: cmake_minimum_required(VERSION 3.6) project(point) find_package(Boost REQUIRED COMPONENTS system) I get this warning: $ cmake . CMake Warning at /usr/share/cmake-3.6/Modules/FindBoost.cmake:743 (message): ? Imported targets not available for Boost version 106200 Call Stack (most recent call first): ? /usr/share/cmake-3.6/Modules/FindBoost.cmake:842 (_Boost_COMPONENT_DEPENDENCIES) ? /usr/share/cmake-3.6/Modules/FindBoost.cmake:1395 (_Boost_MISSING_DEPENDENCIES) ? CMakeLists.txt:3 (find_package) -- Boost version: 1.62.0 -- Found the following Boost libraries: --???system -- Configuring done -- Generating done -- Build files have been written to: /home/markand/dev/point/build The code compiles and builds fine though, but I would like to know and fix this warning. cmake version is 3.6.3 and boost is 1.62.0. Regards, -- David From rleigh at codelibre.net Fri Nov 11 03:01:46 2016 From: rleigh at codelibre.net (Roger Leigh) Date: Fri, 11 Nov 2016 08:01:46 +0000 Subject: [CMake] FindBoost warning but working In-Reply-To: <1478850881.1043.1.camel@localhost> References: <1478850881.1043.1.camel@localhost> Message-ID: <2372fb18-d916-5db4-dc90-e09223026195@codelibre.net> On 11/11/2016 07:54, demelier.david at gmail.com wrote: > Hi, with the following CMakeLists.txt: > > cmake_minimum_required(VERSION 3.6) > project(point) > find_package(Boost REQUIRED COMPONENTS system) > CMake Warning at /usr/share/cmake-3.6/Modules/FindBoost.cmake:743 > (message): > Imported targets not available for Boost version 106200 > The code compiles and builds fine though, but I would like to know and > fix this warning. > > cmake version is 3.6.3 and boost is 1.62.0. The FindBoost provided by this version of cmake doesn't support imported targets for the new Boost 1.62 release, i.e. Boost::system. If you're not using imported targets, this won't cause you any problems, and you can ignore it. Hopefully one day we can get Boost to provide this information directly by providing cmake configuration files (it's on my long todo list). If anyone else wants to tackle this, it would certainly benefit a lot of people. Regards, Roger From orion at cora.nwra.com Fri Nov 11 09:18:02 2016 From: orion at cora.nwra.com (Orion Poplawski) Date: Fri, 11 Nov 2016 07:18:02 -0700 Subject: [CMake] Fwd: [Bug 1394152] New: WebKitGTK+ build fails with cmake 3.6.x and 3.7.0 if using icecream and ninja In-Reply-To: References: Message-ID: <9c92bcaf-925f-e8e6-af7b-9e81ca233331@cora.nwra.com> Does this issue seem familiar to anyone? -------- Forwarded Message -------- Subject: [Bug 1394152] New: WebKitGTK+ build fails with cmake 3.6.x and 3.7.0 if using icecream and ninja Date: Fri, 11 Nov 2016 08:12:13 +0000 From: bugzilla at redhat.com To: orion at cora.nwra.com https://bugzilla.redhat.com/show_bug.cgi?id=1394152 Bug ID: 1394152 Summary: WebKitGTK+ build fails with cmake 3.6.x and 3.7.0 if using icecream and ninja Product: Fedora Version: 25 Component: cmake Assignee: orion at cora.nwra.com Reporter: tpopela at redhat.com QA Contact: extras-qa at fedoraproject.org CC: fedora at besser82.io, helio at kde.org, jreznik at redhat.com, orion at cora.nwra.com, rdieter at math.unl.edu Created attachment 1219658 --> https://bugzilla.redhat.com/attachment.cgi?id=1219658&action=edit cmake generated files from the build directory Description of problem: I'm using icecream (distributed compilation) and ninja together with cmake to build WebKitGTK+ (webkitgtk4 package). After updating to F25 (where is cmake 3.6.x) I cannot build it successfully anymore. The thing is that even if the -fPIC is presented for every file in the generated build.ninja file, when the build is run then there is no -fPIC in the compilers (in this case gcc) arguments (observed by looking on gcc processes during the compilation) which in the end leads to bunch of the following errors: /usr/bin/ld.gold: error: Source/ThirdParty/gtest/CMakeFiles/gtest.dir/src/gtest-typed-test.cc.o: requires dynamic R_X86_64_PC32 reloc against '_ZN9__gnu_cxx13new_allocatorISt13_Rb_tree_nodeIN7testing8internal6StringEEE8allocateEmPKv' which may overflow at runtime; recompile with -fPIC /usr/bin/ld.gold: error: Source/ThirdParty/gtest/CMakeFiles/gtest.dir/src/gtest-typed-test.cc.o: requires dynamic R_X86_64_PC32 reloc against '_ZSt7forwardIRKN7testing8internal6StringEEOT_RNSt16remove_referenceIS5_E4typeE' which may overflow at runtime; recompile with -fPIC /usr/bin/ld.gold: error: Source/ThirdParty/gtest/CMakeFiles/gtest.dir/src/gtest-typed-test.cc.o: requires dynamic R_X86_64_PC32 reloc against '_ZNK9__gnu_cxx13new_allocatorISt13_Rb_tree_nodeIN7testing8internal6StringEEE8max_sizeEv' which may overflow at runtime; recompile with -fPIC /usr/bin/ld.gold: error: Source/ThirdParty/gtest/CMakeFiles/gtest.dir/src/gtest-typed-test.cc.o: requires dynamic R_X86_64_PC32 reloc against '_ZSt7forwardIRKN7testing8internal6StringEEOT_RNSt16remove_referenceIS5_E4typeE' which may overflow at runtime; recompile with -fPIC /usr/bin/ld.gold: error: Source/ThirdParty/gtest/CMakeFiles/gtest.dir/src/gtest-typed-test.cc.o: requires dynamic R_X86_64_32 reloc which may overflow at runtime; recompile with -fPIC I also tried the 3.7 (rc2 and rc3), but the build fails in the same way. I'm attaching the generated files from the build directory (the WebKit's cmake sources could be found on trac.webkit.org). Also a note that it's not a Fedora specific as the guys from WebKit' upstream running on Debian are having the same issue. In the meantime I had to rebuild the 3.5.x from F24, where it works. How reproducible: Always with 3.6.2 and 3.7.0 (rc2 and rc3). Not reproducible with 3.5.2. -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug. From stephan.menzel at gmail.com Fri Nov 11 09:42:11 2016 From: stephan.menzel at gmail.com (Stephan Menzel) Date: Fri, 11 Nov 2016 15:42:11 +0100 Subject: [CMake] Force MSVC runtime for debug builds In-Reply-To: <465919898.71405621.1478618462782.JavaMail.zimbra@elemtech.com> References: <465919898.71405621.1478618462782.JavaMail.zimbra@elemtech.com> Message-ID: On Tue, Nov 8, 2016 at 4:21 PM, wrote: > > If you are going to use /MD instead of /MDd, then you probably also need > to remove the _DEBUG preprocessor flag. > IIRC, I've seen cases where defining _DEBUG includes symbols only > defined by the debug runtimes. > > Clint > What a surprise. Removing _DEBUG did the trick. I was under the impression _DEBUG only controls Microsoft STL impl's debug iterator stuff but apparently it also makes the resulting exe link with /MD rather than /MDd. Guess that was wrong. So yes, problem solved. Thank you! Stephan -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.maynard at kitware.com Fri Nov 11 14:32:07 2016 From: robert.maynard at kitware.com (Robert Maynard) Date: Fri, 11 Nov 2016 14:32:07 -0500 Subject: [CMake] [ANNOUNCE] CMake 3.7.0 available for download Message-ID: I am proud to announce that CMake 3.7.0 is now available for download at: https://cmake.org/download/ Documentation is available at: https://cmake.org/cmake/help/v3.7 Release notes appear below and are also published at https://cmake.org/cmake/help/v3.7/release/3.7.html Some of the more significant changes in CMake 3.7 are: * CMake now supports Cross Compiling for Android with simple toolchain files. * The "Ninja" generator learned to conditionally support Fortran when using a "ninja" tool that has the necessary features. See generator documentation for details. * The "if()" command gained new boolean comparison operations "LESS_EQUAL", "GREATER_EQUAL", "STRLESS_EQUAL", "STRGREATER_EQUAL", "VERSION_LESS_EQUAL", and "VERSION_GREATER_EQUAL". * The "try_compile()" command source file signature now honors configuration-specific flags (e.g. "CMAKE__FLAGS_DEBUG") in the generated test project. Previously only the default such flags for the current toolchain were used. See policy "CMP0066". * "Toolchain files" may now set "CMAKE_EXE_LINKER_FLAGS_INIT", "CMAKE_SHARED_LINKER_FLAGS_INIT", and "CMAKE_MODULE_LINKER_FLAGS_INIT" variables to initialize the "CMAKE_EXE_LINKER_FLAGS", "CMAKE_SHARED_LINKER_FLAGS", and "CMAKE_MODULE_LINKER_FLAGS" cache entries the first time a language is enabled in a build tree. * CTest now supports test fixtures through the new "FIXTURES_SETUP", "FIXTURES_CLEANUP" and "FIXTURES_REQUIRED" test properties. When using regular expressions or "--rerun-failed" to limit the tests to be run, a fixture's setup and cleanup tests will automatically be added to the execution set if any test requires that fixture. * We no longer provide Linux i386 binaries for download from "cmake.org" for new versions of CMake. * Vim support files "cmake-indent.vim", "cmake-syntax.vim", and "cmake-help.vim" have been removed in favor of the files now provided from the vim-cmake-syntax project. * Support for building CMake itself with some compilers was dropped: * Visual Studio 7.1 and 2005 -- superseded by VS 2008 and above * MinGW.org mingw32 -- superseded by MSYS2 mingw32 and mingw64 CMake still supports generating build systems for other projects using these compilers. CMake 3.7 Release Notes *********************** Changes made since CMake 3.6 include the following. New Features ============ Platforms --------- * CMake now supports Cross Compiling for Android with simple toolchain files. * The Clang compiler is now supported on AIX. Generators ---------- * The "Ninja" generator learned to conditionally support Fortran when using a "ninja" tool that has the necessary features. See generator documentation for details. * The "Ninja" generator learned to produce phony targets of the form "sub/dir/{test,install,package}" to drive the build of a subdirectory installation, test or packaging target. This is equivalent to "cd sub/dir; make {test,install,package}" with Makefile Generators. * The "Visual Studio 15" generator was added. This is experimental and based on Preview 4 because this version of VS has not been released. * Visual Studio Generators for VS 2010 and above learned to place ".natvis" source files into VS project files properly. * The "Xcode" generator's rudimentary Swift language support learned to honor a new "CMAKE_Swift_LANGUAGE_VERSION" variable to tell Xcode what version of Swift is used by the source. * The "CodeLite" generator gained a new "CMAKE_CODELITE_USE_TARGETS" option to change project creation from projects to targets. Commands -------- * The "add_custom_command()" command gained a new "DEPFILE" option that works with the "Ninja" generator to provide implicit dependency information to the build tool. * The "cmake_parse_arguments()" command gained a new "PARSE_ARGV" mode to read arguments directly from "ARGC" and "ARGV#" variables inside a "function()" body. * The "export()" command gained an "ANDROID_MK" option to generate "Android.mk" files referencing CMake-built libraries as prebuilts for the Android NDK build system. * The "file(DOWNLOAD)" and "file(UPLOAD)" commands gained "HTTPHEADER " and "USERPWD :" options. * The "find_library()" and "find_package()" commands learned to search in "lib32/" directories when the build targets a 32-bit architecture. See the "FIND_LIBRARY_USE_LIB32_PATHS" global property. * The "find_package()" command gained the possibility of sorting compatible libraries by "NAME" or by "NATURAL" sorting by setting the two new variables "CMAKE_FIND_PACKAGE_SORT_ORDER" and "CMAKE_FIND_PACKAGE_SORT_DIRECTION". * The "if()" command gained new boolean comparison operations "LESS_EQUAL", "GREATER_EQUAL", "STRLESS_EQUAL", "STRGREATER_EQUAL", "VERSION_LESS_EQUAL", and "VERSION_GREATER_EQUAL". * The "install()" command gained an "EXPORT_ANDROID_MK" subcommand to install "Android.mk" files referencing installed libraries as prebuilts for the Android NDK build system. * The "string(TIMESTAMP)" and "file(TIMESTAMP)" commands gained support for the "%a" and "%b" placeholders. These are the abbreviated weekday and month names. * The "try_compile()" command source file signature now honors configuration-specific flags (e.g. "CMAKE__FLAGS_DEBUG") in the generated test project. Previously only the default such flags for the current toolchain were used. See policy "CMP0066". Variables --------- * Variable "CMAKE_FIND_PACKAGE_SORT_ORDER" was added to control the sorting mode of the "find_package()" command. * Variable "CMAKE_FIND_PACKAGE_SORT_DIRECTION" was added to control the sorting direction the "find_package()" command. * "Toolchain files" may now set a "CMAKE__FLAGS_INIT" variable to initialize the "CMAKE__FLAGS" cache entry the first time a language is enabled in a build tree. * "Toolchain files" may now set "CMAKE_EXE_LINKER_FLAGS_INIT", "CMAKE_SHARED_LINKER_FLAGS_INIT", and "CMAKE_MODULE_LINKER_FLAGS_INIT" variables to initialize the "CMAKE_EXE_LINKER_FLAGS", "CMAKE_SHARED_LINKER_FLAGS", and "CMAKE_MODULE_LINKER_FLAGS" cache entries the first time a language is enabled in a build tree. Properties ---------- * On Apple platforms the "BUNDLE_EXTENSION" target property now also applies to Frameworks and App Bundles. * A "BINARY_DIR" directory property was added to get the absolute path to the binary directory corresponding to the source directory on which the property is read. * A "BUILDSYSTEM_TARGETS" directory property was added to get the list of logical buildsystem target names added by the project in a directory. * A "LINK_WHAT_YOU_USE" target property and supporting "CMAKE_LINK_WHAT_YOU_USE" variable were introduced to detect (on UNIX) shared libraries that are linked but not needed by running "ldd -r -u". * A "SOURCE_DIR" directory property was added to get the absolute path to the source directory associated with a directory. * A "SUBDIRECTORIES" directory property was added to get the list of subdirectories added by a project in a directory. * A "VS_SDK_REFERENCES" target property was added to tell Visual Studio Generators to reference the named SDKs. * A "VS_TOOL_OVERRIDE" source file property was created to tell Visual Studio Generators what tool to use for a source file. * The "WINDOWS_EXPORT_ALL_SYMBOLS" target property now applies to executable targets with the "ENABLE_EXPORTS" property set. * A "XCODE_FILE_ATTRIBUTES" source file property was added to tell the "Xcode" generator to generate custom content in the Xcode project attributes for the file. Modules ------- * An "AndroidTestUtilities" module was added to manage transfer of test data to an Android device. * The "CheckFortranSourceCompiles" module macro "CHECK_Fortran_SOURCE_COMPILES" gained a "SRC_EXT" option to specify a custom test Fortran source file extension. * The "ExternalProject" module gained "HTTP_USERNAME" and "HTTP_PASSWORD" options to set http download credentials. * The "ExternalProject" module gained a "HTTP_HEADER" option to add http download headers. * The "FindBISON" module "BISON_TARGET" macro learned a new "REPORT_FILE" option to specify the bison "--report-file=" option. * The "FindBZip2" module now provides imported targets. * A "FindICU" module was introduced to find the International Components for Unicode (ICU) libraries and programs. * The "FindMatlab" module learned to find the SIMULINK and MAT components. * The "FindMatlab" module "matlab_add_mex()" command learned to add executables and modules. * The "FindMatlab" module "matlab_add_unit_test()" command learned to support inline Matlab test code. * The "FindOpenCL" module now provides imported targets. * The "FindOpenMP" module learned to detect the OpenMP version (specification date) from the compiler. * A "FindVulkan" module was added. * The "GenerateExportHeader" module learned a new "CUSTOM_CONTENT_FROM_VARIABLE" option to specify a variable containing custom content for inclusion in the generated header. * The "GNUInstallDirs" module gained a new "GNUInstallDirs_get_absolute_install_dir()" command. * The "UseJava" module gained APIs to "export" jar targets for use by external CMake projects. See the "install_jar_exports" and "export_jars" functions. CTest ----- * CTest now supports test fixtures through the new "FIXTURES_SETUP", "FIXTURES_CLEANUP" and "FIXTURES_REQUIRED" test properties. When using regular expressions or "--rerun-failed" to limit the tests to be run, a fixture's setup and cleanup tests will automatically be added to the execution set if any test requires that fixture. * The "ctest_configure()", "ctest_build()", "ctest_test()", "ctest_coverage()", and "ctest_upload()" commands gained a new "CAPTURE_CMAKE_ERROR" option to capture any errors that occur as the commands run into a variable and avoid affecting the return code of the "ctest(1)" process. CPack ----- * CPack gained a "productbuild" generator on OS X, configured by the "CPackProductBuild" module. * CPack gained a new "CPACK_PACKAGE_CHECKSUM" variable to enable generation of a checksum file for each package file. * The "CPackDeb" module learned to support long file names when archive format is set to GNU tar. See "CPACK_DEBIAN_ARCHIVE_TYPE" * The "CPackIFW" module gained a new "cpack_ifw_add_package_resources()" command to include additional resources in the installer binary. * The "CPackIFW" module "cpack_ifw_configure_component()" and "cpack_ifw_configure_component_group()" commands gained a new "USER_INTERFACES" option to add a list of additonal pages to the IFW installer. * The "CPackRPM" module learned to generate debuginfo packages on demand. See "CPACK_RPM_DEBUGINFO_PACKAGE" and its per component version. * The "CPackRPM" module learned to generate source rpm (SRPM) packages on demand. See "CPACK_RPM_PACKAGE_SOURCES", "CPACK_RPM_SOURCE_PKG_BUILD_PARAMS" and "CPACK_RPM_SOURCE_PKG_PACKAGING_INSTALL_PREFIX". * The CPack NSIS generator now supports "CPACK_NSIS__INSTALL_DIRECTORY". This can be used to set component specific installation directories. * The CPack WIX generator now supports "CPACK_WIX_SKIP_PROGRAM_FOLDER" to allow specification of a custom absolute installation prefix outside of the ProgramFiles folders. * The CPack WIX generator now supports "CPACK_COMPONENT__DISABLED". This can be used to deselect a component from being installed by default. * The CPack WIX generator now supports "CPACK_WIX_PATCH_FILE" fragments for Feature elements. * The CPack WIX generator now supports "CPACK_WIX_ROOT_FEATURE_TITLE" and "CPACK_WIX_ROOT_FEATURE_DESCRIPTION" to allow the specification of a custom title and description for the root feature element. Other ----- * "cmake(1)" gained a "-E capabilities" option to provide a machine- readable (JSON) description of the capabilities of the cmake tool (available generators, etc.). * A new "cmake-server(7)" mode was added to provide semantic information about a CMake-generated buildsystem to clients through a JSON protocol. Currently all protocols are experimental and subject to change. * The "cmake(1)" command learned a "--trace-source=" option. * "ccmake(1)" learned to support vim-like navigation bindings. * "cmake-gui(1)" gained a button to open the generated project file for Visual Studio Generators and the "Xcode" generator. Deprecated and Removed Features =============================== * We no longer provide Linux i386 binaries for download from "cmake.org" for new versions of CMake. * Vim support files "cmake-indent.vim", "cmake-syntax.vim", and "cmake-help.vim" have been removed in favor of the files now provided from the vim-cmake-syntax project. * Support for building CMake itself with some compilers was dropped: * Visual Studio 7.1 and 2005 -- superseded by VS 2008 and above * MinGW.org mingw32 -- superseded by MSYS2 mingw32 and mingw64 CMake still supports generating build systems for other projects using these compilers. Other Changes ============= * The Fortran dependency scanner learned to support the syntax of Fortran Submodules. * Vim support files "indent/cmake.vim" and "syntax/cmake.vim" from the vim-cmake-syntax project are now distributed with CMake. ---------------------------------------------------------------------------- Changes made since CMake 3.7.0-rc3: Brad King (2): QtAutogen: Do not re-generate AUTORCC outputs on every build CMake 3.7.0 Florent Castelli (1): PkgConfig: Fix FindPkgConfig imported target feature From a.neundorf-work at gmx.net Fri Nov 11 16:36:05 2016 From: a.neundorf-work at gmx.net (Alexander Neundorf) Date: Fri, 11 Nov 2016 22:36:05 +0100 Subject: [CMake] Adding Cmake version in online documentation In-Reply-To: <7dac1f34-1736-0e6b-96fa-1eeec1456e03@online.de> References: <81966572-ec61-cad5-489e-57f8e4b569f4@dynamixyz.com> <136407e6-7109-db65-a317-819d3b2e3ccd@gmail.com> <7dac1f34-1736-0e6b-96fa-1eeec1456e03@online.de> Message-ID: <1855599.3894QeZoZJ@tuxedo.neundorf.net> On Wednesday 09 November 2016 00:47:39 Albrecht Schlosser wrote: > On 08.11.2016 23:01 Nils Gladitz wrote: > > On 08.11.2016 20:26, Albrecht Schlosser wrote: > >> I'm a developer of a public GUI library (FLTK). In this position you > >> don't know anything about the availability of CMake versions on your > >> target platforms. Our intention is to keep cmake_minimum_required() as > >> low as possible. > > > > If you are intending to keep the required version as low as possible > > you'll already have a justification / reason for doing so. > > I can only assume that the reason is that you need to support ancient > > platforms which ship equally ancient versions of CMake and you don't > > want to bother your users to build or install custom newer versions of > > CMake. > > > > It doesn't matter what your reasons or justifications for it are (though > > I would hope they are valid and verified) but you have to decide on a > > minimum version that you can life with in the end. > > Basically that's a floating target. We need to evaluate this from time > to time and maybe adjust the required version. You could have a look at the major distributions and what they ship. The oldest I have to support is RHEL 5, released first 2007, and that feels really ancient. But there are people out there which still run such systems. Centos 5 comes with CMake 2.6.4, Centos 6 with 2.8.12. OTOH, installing additional versions of CMake is really easy, thanks to the binary packages provided by Kitware (... which IIRC are built in a Docker Centos 5 container). Btw. I really appreciate your idea to keep the requirements low. :-) > >> That said, whenever you change a CMakeLists.txt file you should be > >> aware if the commands you use are compatible with the CMake version > >> you "require". There should be an easy way to find out in which > >> version a particular CMake command has been introduced. Only with this > >> information you can decide if you should use this fine command or > >> better find another way to do the task you're going to do. > > > > At this point you only have to refer to the documentation that actually > > corresponds to the version you decided to require. > > You'll only find commands and behaviours in that documentation that'll > > actually be available in your minimum version. > > Yep, that's simple, of course. But if there is a (new) command you want > to use it would be interesting to know the CMake version it was > introduced to _decide_ if you can or want to do without it or raise the > required version. I'm sure that we will raise the required version when > CMake gets (or got) a new feature we need to use. But we need the facts > to decide... You can have a look here, there is the documentation for all cmake versions back to 2.6: https://cmake.org/documentation/ Alex From a.neundorf-work at gmx.net Fri Nov 11 16:36:15 2016 From: a.neundorf-work at gmx.net (Alexander Neundorf) Date: Fri, 11 Nov 2016 22:36:15 +0100 Subject: [CMake] Adding Cmake version in online documentation In-Reply-To: References: <81966572-ec61-cad5-489e-57f8e4b569f4@dynamixyz.com> <98f9bbf7-0898-c249-3a1f-7b82b32d5912@yahoo.com> Message-ID: <3092135.uLL3iCAWpE@tuxedo.neundorf.net> On Wednesday 09 November 2016 09:22:24 Nils Gladitz wrote: ... > You said you are not forcing your users to upgrade by setting a policy > to OLD. > Which implied that not setting the policy to OLD would force your users > to upgrade ... which it doesn't. > > >> In fact all that setting it to OLD does is suppress the warning. > > > > It's better than emitting zillion of warnings to the output, right? > > You can suppress one type and fix another, set TODOs, etc. > > Policy warnings are intended to encourage you to switch to new > behaviours since the old ones are deprecated. > In actively maintained projects they are not meant to be suppressed. I heard that argumentation several times, and still don't agree. "actively maintained" doesn't automatically mean to always require the newest versions of everything, see the mail from Albrecht Schlosser (FLTK) or how CMake requirements were handled during the KDE4 era. To make the software buildable on as many as possible systems, it helps to not to require new versions of any needed tools or libraries. So, Albrecht can absolutely actively maintain FLTK, and at the same time decide to require a relatively old cmake version (Ok, 2.6 is ancient). As long as he doesn't plan to update the required version for cmake, I would suppress all policy warnings about new behaviour. Is it guaranteed that changing the code so that the warning, which appeared e.g. in cmake 3.4, is fixed, still works correctly with the old, required version of cmake ? I think no. Once there is a plan to upgrade the cmake version, the warnings become useful, but IMO not before. Alex From foss at grueninger.de Sat Nov 12 08:38:06 2016 From: foss at grueninger.de (=?UTF-8?Q?Christoph_Gr=c3=bcninger?=) Date: Sat, 12 Nov 2016 14:38:06 +0100 Subject: [CMake] CMake 3.7: Test #379: RunCMake.CPack_RPM fails Message-ID: Dear CMake folks, I am trying to package CMake for openSuse. I was a bit surprised that the new dependency libuv was nowhere mentioned. Can it be disabled by a configure switch for older systems? CMake 3.7 compiles so far, but test #379 (RunCMake.CPack_RPM) fails, see the error below from OBS. I had a brief look at our patches and I am apt to think they are unrelated. Can someone have a look and give some hint? Sorry that I didn't test already the RCs. Bye Christoph > [ 1041s] 412/413 Test #413: CMake.GetPrerequisites ........................... Passed 0.61 sec > [ 1067s] 413/413 Test #379: RunCMake.CPack_RPM ...............................***Failed 48.75 sec > [ 1067s] -- MINIMAL - PASSED > [ 1067s] -- RPM/MINIMAL - PASSED > [ 1067s] -- SOURCE_PACKAGE - PASSED > [ 1067s] -- SOURCE_PACKAGE-Build - PASSED > [ 1067s] -- RPM/SOURCE_PACKAGE - PASSED > [ 1067s] -- PARTIALLY_RELOCATABLE_WARNING - PASSED > [ 1067s] -- RPM/PARTIALLY_RELOCATABLE_WARNING - PASSED > [ 1067s] -- DEPENDENCIES - PASSED > [ 1067s] -- DEPENDENCIES-Build - PASSED > [ 1067s] -- RPM/DEPENDENCIES - PASSED > [ 1067s] -- EMPTY_DIR - PASSED > [ 1067s] -- EMPTY_DIR-Build - PASSED > [ 1067s] -- RPM/EMPTY_DIR - PASSED > [ 1067s] -- COMPONENTS_EMPTY_DIR - PASSED > [ 1067s] -- COMPONENTS_EMPTY_DIR-Build - PASSED > [ 1067s] -- RPM/COMPONENTS_EMPTY_DIR - PASSED > [ 1067s] -- CUSTOM_NAMES - PASSED > [ 1067s] -- CUSTOM_NAMES-Build - PASSED > [ 1067s] -- RPM/CUSTOM_NAMES - PASSED > [ 1067s] -- PER_COMPONENT_FIELDS - PASSED > [ 1067s] -- RPM/PER_COMPONENT_FIELDS - PASSED > [ 1067s] -- RPM_DIST - PASSED > [ 1067s] -- RPM/RPM_DIST - PASSED > [ 1067s] -- INSTALL_SCRIPTS - PASSED > [ 1067s] -- RPM/INSTALL_SCRIPTS - PASSED > [ 1067s] -- DEBUGINFO - PASSED > [ 1067s] -- DEBUGINFO-Build - PASSED > [ 1067s] CMake Error at RunCMake.cmake:130 (message): > [ 1067s] RPM/DEBUGINFO - FAILED: > [ 1067s] > [ 1067s] Result is [1], not [0]. > [ 1067s] > [ 1067s] stderr does not match that expected. > [ 1067s] > [ 1067s] Command was: > [ 1067s] > [ 1067s] command> "/home/abuild/rpmbuild/BUILD/cmake-3.7.0/bin/cmake" "-DRunCMake_TEST=DEBUGINFO" "-DRunCMake_TEST_FILE_PREFIX=DEBUGINFO" "-DRunCMake_SUBTEST_SUFFIX=" "-DGENERATOR_TYPE=RPM" "-Dsrc_dir=/home/abuild/rpmbuild/BUILD/cmake-3.7.0/Tests/RunCMake/CPack" "-Dbin_dir=/home/abuild/rpmbuild/BUILD/cmake-3.7.0/Tests/RunCMake/RPM/CPack/DEBUGINFO-build" "-Dconfig_file=/home/abuild/rpmbuild/BUILD/cmake-3.7.0/Tests/RunCMake/CPack/conf/RPM_config.cmake" "-P" "/home/abuild/rpmbuild/BUILD/cmake-3.7.0/Tests/RunCMake/CPack/VerifyResult.cmake" > [ 1067s] > [ 1067s] Actual stdout: > [ 1067s] > [ 1067s] actual-out> > [ 1067s] > [ 1067s] Expected stderr to match: > [ 1067s] > [ 1067s] expect-err> ^CPackRPM: Will use GENERATED spec file: .*/Tests/RunCMake/RPM/CPack/DEBUGINFO-build/_CPack_Packages/.*/RPM/SPECS/debuginfo-applications.spec > [ 1067s] expect-err> CPackRPM: Will use GENERATED spec file: .*/Tests/RunCMake/RPM/CPack/DEBUGINFO-build/_CPack_Packages/.*/RPM/SPECS/debuginfo-headers.spec > [ 1067s] expect-err> CPackRPM: Will use GENERATED spec file: .*/Tests/RunCMake/RPM/CPack/DEBUGINFO-build/_CPack_Packages/.*/RPM/SPECS/debuginfo-libs.spec$ > [ 1067s] > [ 1067s] Actual stderr: > [ 1067s] > [ 1067s] actual-err> CMake Error at /home/abuild/rpmbuild/BUILD/cmake-3.7.0/Tests/RunCMake/CPack/VerifyResult.cmake:30 (message): > [ 1067s] actual-err> Unexpected file content for file No. '4'! > [ 1067s] actual-err> > [ 1067s] actual-err> Content: '/usr/lib/debug > [ 1067s] actual-err> > [ 1067s] actual-err> /usr/lib/debug/.build-id > [ 1067s] actual-err> > [ 1067s] actual-err> /usr/lib/debug/.build-id/66/e61cff8c1b481720b2f65873db6c559fe1138a > [ 1067s] actual-err> > [ 1067s] actual-err> /usr/lib/debug/.build-id/66/e61cff8c1b481720b2f65873db6c559fe1138a.debug > [ 1067s] actual-err> > [ 1067s] actual-err> /usr/lib/debug/usr/foo/test_prog.debug' > [ 1067s] actual-err> > [ 1067s] actual-err> > [ 1067s] actual-err> > [ 1067s] actual-err> Expected: '.*/src[ > [ 1067s] actual-err> > [ 1067s] actual-err> > ]*/src/src_1[ > [ 1067s] actual-err> > [ 1067s] actual-err> > ]*/src/src_1/main.cpp.*' > [ 1067s] actual-err> > [ 1067s] actual-err> CPack output: 'CPack: Create package using RPM > [ 1067s] actual-err> > [ 1067s] actual-err> CPack: Install projects > [ 1067s] actual-err> > [ 1067s] actual-err> CPack: - Run preinstall target for: DEBUGINFO > [ 1067s] actual-err> > [ 1067s] actual-err> CPack: - Install project: DEBUGINFO > [ 1067s] actual-err> > [ 1067s] actual-err> CPack: - Install component: applications > [ 1067s] actual-err> > [ 1067s] actual-err> CPack: - Install component: headers > [ 1067s] actual-err> > [ 1067s] actual-err> CPack: - Install component: libs > [ 1067s] actual-err> > [ 1067s] actual-err> CPack: Create package > [ 1067s] actual-err> > [ 1067s] actual-err> CPack: - package: > [ 1067s] actual-err> /home/abuild/rpmbuild/BUILD/cmake-3.7.0/Tests/RunCMake/RPM/CPack/DEBUGINFO-build/debuginfo-0.1.1-Linux-headers.rpm > [ 1067s] actual-err> generated. > [ 1067s] actual-err> > [ 1067s] actual-err> CPack: - package: > [ 1067s] actual-err> /home/abuild/rpmbuild/BUILD/cmake-3.7.0/Tests/RunCMake/RPM/CPack/DEBUGINFO-build/debuginfo-applications-0.1.1-1.x86_64.rpm > [ 1067s] actual-err> generated. > [ 1067s] actual-err> > [ 1067s] actual-err> CPack: - package: > [ 1067s] actual-err> /home/abuild/rpmbuild/BUILD/cmake-3.7.0/Tests/RunCMake/RPM/CPack/DEBUGINFO-build/debuginfo-applications-debuginfo-0.1.1-1.x86_64.rpm > [ 1067s] actual-err> generated. > [ 1067s] actual-err> > [ 1067s] actual-err> CPack: - package: > [ 1067s] actual-err> /home/abuild/rpmbuild/BUILD/cmake-3.7.0/Tests/RunCMake/RPM/CPack/DEBUGINFO-build/debuginfo-0.1.1-Linux-libs.rpm > [ 1067s] actual-err> generated. > [ 1067s] actual-err> > [ 1067s] actual-err> CPack: - package: > [ 1067s] actual-err> /home/abuild/rpmbuild/BUILD/cmake-3.7.0/Tests/RunCMake/RPM/CPack/DEBUGINFO-build/debuginfo-libs-debuginfo-0.1.1-1.x86_64.rpm > [ 1067s] actual-err> generated. > [ 1067s] actual-err> > [ 1067s] actual-err> ' > [ 1067s] actual-err> > [ 1067s] actual-err> CPack error: 'CPackRPM: Will use GENERATED spec file: > [ 1067s] actual-err> /home/abuild/rpmbuild/BUILD/cmake-3.7.0/Tests/RunCMake/RPM/CPack/DEBUGINFO-build/_CPack_Packages/Linux/RPM/SPECS/debuginfo-applications.spec > [ 1067s] actual-err> > [ 1067s] actual-err> > [ 1067s] actual-err> CPackRPM: Will use GENERATED spec file: > [ 1067s] actual-err> /home/abuild/rpmbuild/BUILD/cmake-3.7.0/Tests/RunCMake/RPM/CPack/DEBUGINFO-build/_CPack_Packages/Linux/RPM/SPECS/debuginfo-headers.spec > [ 1067s] actual-err> > [ 1067s] actual-err> > [ 1067s] actual-err> CPackRPM: Will use GENERATED spec file: > [ 1067s] actual-err> /home/abuild/rpmbuild/BUILD/cmake-3.7.0/Tests/RunCMake/RPM/CPack/DEBUGINFO-build/_CPack_Packages/Linux/RPM/SPECS/debuginfo-libs.spec > [ 1067s] actual-err> > [ 1067s] actual-err> > [ 1067s] actual-err> '; > [ 1067s] actual-err> > [ 1067s] actual-err> CPack result: ''; > [ 1067s] actual-err> > [ 1067s] actual-err> config file: 'set(RPM_EXECUTABLE "/bin/rpm") > [ 1067s] actual-err> > [ 1067s] actual-err> set(RPMBUILD_EXECUTABLE "/usr/bin/rpmbuild")' > [ 1067s] > [ 1067s] Call Stack (most recent call first): > [ 1067s] RunCMake.cmake:144 (run_cmake) > [ 1067s] CPack/CPackTestHelpers.cmake:69 (run_cmake_command) > [ 1067s] CPack/CPackTestHelpers.cmake:85 (run_cpack_test_common_) > [ 1067s] CPack/RunCMakeTest.cmake:20 (run_cpack_test) > [ 1067s] > [ 1067s] > [ 1067s] > [ 1067s] > [ 1067s] 99% tests passed, 1 tests failed out of 413 > [ 1067s] > [ 1067s] Label Time Summary: > [ 1067s] Label1 = 0.08 sec (1 test) > [ 1067s] Label2 = 0.08 sec (1 test) > [ 1067s] > [ 1067s] Total Test time (real) = 556.51 sec > [ 1067s] > [ 1067s] The following tests FAILED: > [ 1067s] 379 - RunCMake.CPack_RPM (Failed) > [ 1067s] Errors while running CTest > [ 1067s] error: Bad exit status from /var/tmp/rpm-tmp.YXAv4k (%check) From AlbrechtS.fltk at online.de Sat Nov 12 10:41:13 2016 From: AlbrechtS.fltk at online.de (Albrecht Schlosser) Date: Sat, 12 Nov 2016 16:41:13 +0100 Subject: [CMake] Adding Cmake version in online documentation In-Reply-To: <1855599.3894QeZoZJ@tuxedo.neundorf.net> References: <81966572-ec61-cad5-489e-57f8e4b569f4@dynamixyz.com> <136407e6-7109-db65-a317-819d3b2e3ccd@gmail.com> <7dac1f34-1736-0e6b-96fa-1eeec1456e03@online.de> <1855599.3894QeZoZJ@tuxedo.neundorf.net> Message-ID: On 11.11.2016 22:36 Alexander Neundorf wrote: > You could have a look at the major distributions and what they ship. Thanks for your comments. We do not only want to support the major distributions but also (maybe proprietary) cross compilation tools. That's why we still support autoconf/configure as well. > The oldest I have to support is RHEL 5, released first 2007, and that feels > really ancient. But there are people out there which still run such systems. > Centos 5 comes with CMake 2.6.4, Centos 6 with 2.8.12. > OTOH, installing additional versions of CMake is really easy, thanks to the > binary packages provided by Kitware (... which IIRC are built in a Docker > Centos 5 container). Even compilation of CMake is pretty easy. Thanks to its 'bootstrap' mode. > Btw. I really appreciate your idea to keep the requirements low. :-) You're welcome. See above why this is so essential for FLTK. > You can have a look here, there is the documentation for all cmake versions > back to 2.6: https://cmake.org/documentation/ Thanks for the link as well. I forgot about that because I was mostly searching with g**le and that seems to find random versions... > Alex Albrecht From AlbrechtS.fltk at online.de Sat Nov 12 10:52:49 2016 From: AlbrechtS.fltk at online.de (Albrecht Schlosser) Date: Sat, 12 Nov 2016 16:52:49 +0100 Subject: [CMake] Adding Cmake version in online documentation In-Reply-To: <3092135.uLL3iCAWpE@tuxedo.neundorf.net> References: <81966572-ec61-cad5-489e-57f8e4b569f4@dynamixyz.com> <98f9bbf7-0898-c249-3a1f-7b82b32d5912@yahoo.com> <3092135.uLL3iCAWpE@tuxedo.neundorf.net> Message-ID: On 11.11.2016 22:36 Alexander Neundorf wrote: > On Wednesday 09 November 2016 09:22:24 Nils Gladitz wrote: > ... >> >> Policy warnings are intended to encourage you to switch to new >> behaviours since the old ones are deprecated. >> In actively maintained projects they are not meant to be suppressed. > > > I heard that argumentation several times, and still don't agree. > > "actively maintained" doesn't automatically mean to always require the newest > versions of everything, see the mail from Albrecht Schlosser (FLTK) or how > CMake requirements were handled during the KDE4 era. > > To make the software buildable on as many as possible systems, it helps to not > to require new versions of any needed tools or libraries. > > So, Albrecht can absolutely actively maintain FLTK, and at the same time > decide to require a relatively old cmake version (Ok, 2.6 is ancient). I absolutely agree. (Surprise, surprise.) ;-) Thanks for supporting my arguments. > As long as he doesn't plan to update the required version for cmake, I would > suppress all policy warnings about new behaviour. > Is it guaranteed that changing the code so that the warning, which appeared > e.g. in cmake 3.4, is fixed, still works correctly with the old, required > version of cmake ? > I think no. Particularly not if you set any policy to NEW. I don't think that this is a valid setting because it would give different behaviour on older (pre-this-new-behaviour/policy version) and later versions. I can't think of a real usage case of any policy setting to NEW. Unless your code is conditional depending on the CMake version. > Once there is a plan to upgrade the cmake version, the warnings become useful, > but IMO not before. Nitpicking: should read "... upgrade the *required* cmake version ...". This free library case (FLTK) where the public is addressed with the least restrictions is different than a (maybe commercial) project where you can dictate the required versions and can control the build environment. From writeonce at midipix.org Sat Nov 12 11:09:45 2016 From: writeonce at midipix.org (writeonce at midipix.org) Date: Sat, 12 Nov 2016 09:09:45 -0700 Subject: [CMake] new system config file: Midipix.cmake Message-ID: <20161112090945.dc30d64f61e5ec441c34ffd4f788e58e.fbc79301c2.wbe@email15.godaddy.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Greetings, Attached is a patch for adding midipix[1] (cross-)host support to cmake. [1] www.midipix.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJYJznRAAoJENw9KTvtebDqwuUQAJE/UVxMQeFSDvrdQXT8hjap YoMYQpuQwkcbxQzpQ1Hiu4By/C1FlLI1M4hB/zoK874QPu9BHci7pkxtI1YnPrKL Afw8CStpOF6HxcSOKdJDvByrkDvkaMk0w7TuiLeZFCPBcR+IxCH4Fnj0uhls9Hy9 zf+l2w9TS3Onq7pOAiAO5xfk+snQAsPk37qWERhUfOG3hLzatKEZf/9wvnjeoUMX SBv+09y+g1dRfMQFhrBy4UzbR9hwpRfditw1MwGxuIv3xpQLcj9Ps3pooQxCK5/e EdreQN/Sx+Z5pkSyeZJePO9YqJw86TGA2rs8/n5FwEM5x/NrRqRZ/jHSfeFowXu4 JqZPGbb0jQSMn3ncOOrnMSh1CBIZT1uZIedpcshZ3OZZjUzWcCA2iBqJzx3mGYJj nS/VHXDlYFSnC2pZQW0OA713aHCs6PzfLrYGtX4PVTxpCJyI/Fc5KU3ZNNw1GiKg KZNNB8Wa+yGxGJf66I7LJRFW5zwB21HCNNYELwQdPbt5URdgTITgpaEZ9TkeemdY /alZ13jnPJFHEGdE7nzHpbxsMNMeUAmfRiyZv+piqSzCb9Aj0uWzArS2k1tobz9A tQcMZXqySzWL4ycyKbn2ZiB8IN2myH2QpgDUgcml4tw2MVsMQck4BjTgB/vjwhog iu0xipCDHic6TdzhvP8p =3ydC -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: Midipix.cmake.patch Type: text/x-diff Size: 589 bytes Desc: not available URL: From patrick.boettcher at posteo.de Mon Nov 14 02:08:00 2016 From: patrick.boettcher at posteo.de (Patrick Boettcher) Date: Mon, 14 Nov 2016 08:08:00 +0100 Subject: [CMake] clang-format In-Reply-To: References: Message-ID: <20161114080800.3309eb27@posteo.de> Hi, On Mon, 7 Nov 2016 12:06:15 -0800 Tiago Macarios wrote: > CMake has "built-in" support for clang_tidy and include-what-you-use. > I was wondering why there is not support for clang_format. No one ever > contributed, or people think this should not be part of CMake? First thought which came to my mind when reading your mail was that no automatic tool should change (source-)files during compilation which are, possibly, opened in an editor. But, it would, maybe, be nice to have a custom, optional target to run it on demand. If your editor supports it (mine does, even for selected code-lines, \o/ ) integrate clang-format as source-code-indentation-tool. regards -- Patrick. From domen.vrankar at gmail.com Mon Nov 14 03:10:45 2016 From: domen.vrankar at gmail.com (Domen Vrankar) Date: Mon, 14 Nov 2016 09:10:45 +0100 Subject: [CMake] CMake 3.7: Test #379: RunCMake.CPack_RPM fails In-Reply-To: References: Message-ID: 2016-11-12 14:38 GMT+01:00 Christoph Gr?ninger : > Dear CMake folks, > I am trying to package CMake for openSuse. I was a bit surprised that > the new dependency libuv was nowhere mentioned. Can it be disabled by a > configure switch for older systems? > If I remember correctly libuv is only used for cmake server mode so if you don't want libuv dependency you just loose that optional functionality but this would probably be better to ask in a separate mail as I'm not certain how many people will look into CPack/RPM specific mail. > CMake 3.7 compiles so far, but test #379 (RunCMake.CPack_RPM) fails, see > the error below from OBS. I had a brief look at our patches and I am apt > to think they are unrelated. > Can someone have a look and give some hint? > I'll test it today in the afternoon but for now since sources are missing from the package I'm guessing that debuginfo rpm packaging rpmbuild macro on openSUSE has some differences compared to the one in other distros. CPack/RPM overrides it to compensate for the fact that sources can be generated during build (rpmbuild debuginfo macro only supports packaging of sources located in source dir during packaging so that works only for insource builds...). Regards, Domen -------------- next part -------------- An HTML attachment was scrubbed... URL: From demelier.david at gmail.com Mon Nov 14 08:36:22 2016 From: demelier.david at gmail.com (David Demelier) Date: Mon, 14 Nov 2016 14:36:22 +0100 Subject: [CMake] FindBoost not finding MinGW libraries Message-ID: Hello, I've installed boost under C:\env\mingw64 so I basically have the following content: - C:\env\mingw64\include\boost-1_62\boost\* - C:\env\mingw64\lib\libboost_libname-mgw62-1_62.dll(.a) I've also set the following environment variables: - BOOST_INCLUDEDIR=C:\env\mingw64\include\boost-1_62 - BOOST_LIBRARYDIR=C:\env\mingw64\lib - BOOST_ROOT=C:\env\mingw64 The following CMakeLists could not find boost: cmake_minimum_required(VERSION 3.5) project(boosttest) find_package(Boost REQUIRED COMPONENTS system) running cmake -G"MinGW Makefiles" -DBoost_DEBUG=On ends with this: -- The C compiler identification is GNU 6.2.0 -- The CXX compiler identification is GNU 6.2.0 -- Check for working C compiler: C:/mingw64/bin/gcc.exe -- Check for working C compiler: C:/mingw64/bin/gcc.exe -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Detecting C compile features -- Detecting C compile features - done -- Check for working CXX compiler: C:/mingw64/bin/g++.exe -- Check for working CXX compiler: C:/mingw64/bin/g++.exe -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Detecting CXX compile features -- Detecting CXX compile features - done -- [ C:/Program Files/CMake/share/cmake-3.6/Modules/FindBoost.cmake:946 ] _boost_TEST_VERSIONS = 1.61.0;1.61;1.60.0;1.60;1.59.0;1.59;1.58.0;1.58;1.57.0;1.57;1.56.0;1.56;1.55.0;1.55;1.54.0;1.54;1.53.0;1.53;1.52.0;1.52;1.51.0;1.51;1.50.0;1.50;1.49.0;1.49;1.48.0;1.48;1.47.0;1.47;1.46.1;1.46.0;1.46;1.45.0;1.45;1.44.0;1.44;1.43.0;1.43;1.42.0;1.42;1.41.0;1.41;1.40.0;1.40;1.39.0;1.39;1.38.0;1.38;1.37.0;1.37;1.36.1;1.36.0;1.36;1.35.1;1.35.0;1.35;1.34.1;1.34.0;1.34;1.33.1;1.33.0;1.33 -- [ C:/Program Files/CMake/share/cmake-3.6/Modules/FindBoost.cmake:948 ] Boost_USE_MULTITHREADED = TRUE -- [ C:/Program Files/CMake/share/cmake-3.6/Modules/FindBoost.cmake:950 ] Boost_USE_STATIC_LIBS = -- [ C:/Program Files/CMake/share/cmake-3.6/Modules/FindBoost.cmake:952 ] Boost_USE_STATIC_RUNTIME = -- [ C:/Program Files/CMake/share/cmake-3.6/Modules/FindBoost.cmake:954 ] Boost_ADDITIONAL_VERSIONS = -- [ C:/Program Files/CMake/share/cmake-3.6/Modules/FindBoost.cmake:956 ] Boost_NO_SYSTEM_PATHS = -- [ C:/Program Files/CMake/share/cmake-3.6/Modules/FindBoost.cmake:1024 ] Declared as CMake or Environmental Variables: -- [ C:/Program Files/CMake/share/cmake-3.6/Modules/FindBoost.cmake:1026 ] BOOST_ROOT = -- [ C:/Program Files/CMake/share/cmake-3.6/Modules/FindBoost.cmake:1028 ] BOOST_INCLUDEDIR = -- [ C:/Program Files/CMake/share/cmake-3.6/Modules/FindBoost.cmake:1030 ] BOOST_LIBRARYDIR = -- [ C:/Program Files/CMake/share/cmake-3.6/Modules/FindBoost.cmake:1032 ] _boost_TEST_VERSIONS = 1.61.0;1.61;1.60.0;1.60;1.59.0;1.59;1.58.0;1.58;1.57.0;1.57;1.56.0;1.56;1.55.0;1.55;1.54.0;1.54;1.53.0;1.53;1.52.0;1.52;1.51.0;1.51;1.50.0;1.50;1.49.0;1.49;1.48.0;1.48;1.47.0;1.47;1.46.1;1.46.0;1.46;1.45.0;1.45;1.44.0;1.44;1.43.0;1.43;1.42.0;1.42;1.41.0;1.41;1.40.0;1.40;1.39.0;1.39;1.38.0;1.38;1.37.0;1.37;1.36.1;1.36.0;1.36;1.35.1;1.35.0;1.35;1.34.1;1.34.0;1.34;1.33.1;1.33.0;1.33 -- [ C:/Program Files/CMake/share/cmake-3.6/Modules/FindBoost.cmake:1101 ] Include debugging info: -- [ C:/Program Files/CMake/share/cmake-3.6/Modules/FindBoost.cmake:1103 ] _boost_INCLUDE_SEARCH_DIRS = C:/env/mingw64/include/boost-1_62;C:/env/mingw64/include;C:/env/mingw64;PATHS;C:/boost/include;C:/boost;/sw/local/include -- [ C:/Program Files/CMake/share/cmake-3.6/Modules/FindBoost.cmake:1105 ] _boost_PATH_SUFFIXES = boost-1_61_0;boost_1_61_0;boost/boost-1_61_0;boost/boost_1_61_0;boost-1_61;boost_1_61;boost/boost-1_61;boost/boost_1_61;boost-1_60_0;boost_1_60_0;boost/boost-1_60_0;boost/boost_1_60_0;boost-1_60;boost_1_60;boost/boost-1_60;boost/boost_1_60;boost-1_59_0;boost_1_59_0;boost/boost-1_59_0;boost/boost_1_59_0;boost-1_59;boost_1_59;boost/boost-1_59;boost/boost_1_59;boost-1_58_0;boost_1_58_0;boost/boost-1_58_0;boost/boost_1_58_0;boost-1_58;boost_1_58;boost/boost-1_58;boost/boost_1_58;boost-1_57_0;boost_1_57_0;boost/boost-1_57_0;boost/boost_1_57_0;boost-1_57;boost_1_57;boost/boost-1_57;boost/boost_1_57;boost-1_56_0;boost_1_56_0;boost/boost-1_56_0;boost/boost_1_56_0;boost-1_56;boost_1_56;boost/boost-1_56;boost/boost_1_56;boost-1_55_0;boost_1_55_0;boost/boost-1_55_0;boost/boost_1_55_0;boost-1_55;boost_1_55;boost/boost-1_55;boost/boost_1_55;boost-1_54_0;boost_1_54_0;boost/boost-1_54_0;boost/boost_1_54_0;boost-1_54;boost_1_54;boost/boost-1_54;boost/boost_1_54;boost-1_53_0;boost_1_53_0;boost/boost-1_53_0;boost/boost_1_53_0;boost-1_53;boost_1_53;boost/boost-1_53;boost/boost_1_53;boost-1_52_0;boost_1_52_0;boost/boost-1_52_0;boost/boost_1_52_0;boost-1_52;boost_1_52;boost/boost-1_52;boost/boost_1_52;boost-1_51_0;boost_1_51_0;boost/boost-1_51_0;boost/boost_1_51_0;boost-1_51;boost_1_51;boost/boost-1_51;boost/boost_1_51;boost-1_50_0;boost_1_50_0;boost/boost-1_50_0;boost/boost_1_50_0;boost-1_50;boost_1_50;boost/boost-1_50;boost/boost_1_50;boost-1_49_0;boost_1_49_0;boost/boost-1_49_0;boost/boost_1_49_0;boost-1_49;boost_1_49;boost/boost-1_49;boost/boost_1_49;boost-1_48_0;boost_1_48_0;boost/boost-1_48_0;boost/boost_1_48_0;boost-1_48;boost_1_48;boost/boost-1_48;boost/boost_1_48;boost-1_47_0;boost_1_47_0;boost/boost-1_47_0;boost/boost_1_47_0;boost-1_47;boost_1_47;boost/boost-1_47;boost/boost_1_47;boost-1_46_1;boost_1_46_1;boost/boost-1_46_1;boost/boost_1_46_1;boost-1_46_0;boost_1_46_0;boost/boost-1_46_0;boost/boost_1_46_0;boost-1_46;boost_1_46;boost/boost-1_46;boost/boost_1_46;boost-1_45_0;boost_1_45_0;boost/boost-1_45_0;boost/boost_1_45_0;boost-1_45;boost_1_45;boost/boost-1_45;boost/boost_1_45;boost-1_44_0;boost_1_44_0;boost/boost-1_44_0;boost/boost_1_44_0;boost-1_44;boost_1_44;boost/boost-1_44;boost/boost_1_44;boost-1_43_0;boost_1_43_0;boost/boost-1_43_0;boost/boost_1_43_0;boost-1_43;boost_1_43;boost/boost-1_43;boost/boost_1_43;boost-1_42_0;boost_1_42_0;boost/boost-1_42_0;boost/boost_1_42_0;boost-1_42;boost_1_42;boost/boost-1_42;boost/boost_1_42;boost-1_41_0;boost_1_41_0;boost/boost-1_41_0;boost/boost_1_41_0;boost-1_41;boost_1_41;boost/boost-1_41;boost/boost_1_41;boost-1_40_0;boost_1_40_0;boost/boost-1_40_0;boost/boost_1_40_0;boost-1_40;boost_1_40;boost/boost-1_40;boost/boost_1_40;boost-1_39_0;boost_1_39_0;boost/boost-1_39_0;boost/boost_1_39_0;boost-1_39;boost_1_39;boost/boost-1_39;boost/boost_1_39;boost-1_38_0;boost_1_38_0;boost/boost-1_38_0;boost/boost_1_38_0;boost-1_38;boost_1_38;boost/boost-1_38;boost/boost_1_38;boost-1_37_0;boost_1_37_0;boost/boost-1_37_0;boost/boost_1_37_0;boost-1_37;boost_1_37;boost/boost-1_37;boost/boost_1_37;boost-1_36_1;boost_1_36_1;boost/boost-1_36_1;boost/boost_1_36_1;boost-1_36_0;boost_1_36_0;boost/boost-1_36_0;boost/boost_1_36_0;boost-1_36;boost_1_36;boost/boost-1_36;boost/boost_1_36;boost-1_35_1;boost_1_35_1;boost/boost-1_35_1;boost/boost_1_35_1;boost-1_35_0;boost_1_35_0;boost/boost-1_35_0;boost/boost_1_35_0;boost-1_35;boost_1_35;boost/boost-1_35;boost/boost_1_35;boost-1_34_1;boost_1_34_1;boost/boost-1_34_1;boost/boost_1_34_1;boost-1_34_0;boost_1_34_0;boost/boost-1_34_0;boost/boost_1_34_0;boost-1_34;boost_1_34;boost/boost-1_34;boost/boost_1_34;boost-1_33_1;boost_1_33_1;boost/boost-1_33_1;boost/boost_1_33_1;boost-1_33_0;boost_1_33_0;boost/boost-1_33_0;boost/boost_1_33_0;boost-1_33;boost_1_33;boost/boost-1_33;boost/boost_1_33 -- [ C:/Program Files/CMake/share/cmake-3.6/Modules/FindBoost.cmake:1125 ] location of version.hpp: C:/env/mingw64/include/boost-1_62/boost/version.hpp -- [ C:/Program Files/CMake/share/cmake-3.6/Modules/FindBoost.cmake:1149 ] version.hpp reveals boost 1.62.0 -- [ C:/Program Files/CMake/share/cmake-3.6/Modules/FindBoost.cmake:1235 ] guessed _boost_COMPILER = -mgw62 -- [ C:/Program Files/CMake/share/cmake-3.6/Modules/FindBoost.cmake:1245 ] _boost_MULTITHREADED = -mt -- [ C:/Program Files/CMake/share/cmake-3.6/Modules/FindBoost.cmake:1288 ] _boost_RELEASE_ABI_TAG = - -- [ C:/Program Files/CMake/share/cmake-3.6/Modules/FindBoost.cmake:1290 ] _boost_DEBUG_ABI_TAG = -d -- [ C:/Program Files/CMake/share/cmake-3.6/Modules/FindBoost.cmake:1344 ] _boost_LIBRARY_SEARCH_DIRS_RELEASE = C:/env/mingw64/lib;C:/env/mingw64/lib;C:/env/mingw64/stage/lib;C:/env/mingw64/include/boost-1_62/lib;C:/env/mingw64/include/boost-1_62/../lib;C:/env/mingw64/include/boost-1_62/stage/lib;PATHS;C:/boost/lib;C:/boost;/sw/local/lib_boost_LIBRARY_SEARCH_DIRS_DEBUG = C:/env/mingw64/lib;C:/env/mingw64/lib;C:/env/mingw64/stage/lib;C:/env/mingw64/include/boost-1_62/lib;C:/env/mingw64/include/boost-1_62/../lib;C:/env/mingw64/include/boost-1_62/stage/lib;PATHS;C:/boost/lib;C:/boost;/sw/local/lib CMake Warning at C:/Program Files/CMake/share/cmake-3.6/Modules/FindBoost.cmake:743 (message): Imported targets not available for Boost version 106200 Call Stack (most recent call first): C:/Program Files/CMake/share/cmake-3.6/Modules/FindBoost.cmake:842 (_Boost_COMPONENT_DEPENDENCIES) C:/Program Files/CMake/share/cmake-3.6/Modules/FindBoost.cmake:1395 (_Boost_MISSING_DEPENDENCIES) CMakeLists.txt:3 (find_package) -- [ C:/Program Files/CMake/share/cmake-3.6/Modules/FindBoost.cmake:1483 ] Searching for SYSTEM_LIBRARY_RELEASE: boost_system-mgw62-mt-1_62;boost_system-mgw62-mt;boost_system-mt-1_62;boost_system-mt;boost_system -- [ C:/Program Files/CMake/share/cmake-3.6/Modules/FindBoost.cmake:1525 ] Searching for SYSTEM_LIBRARY_DEBUG: boost_system-mgw62-mt-d-1_62;boost_system-mgw62-mt-d;boost_system-mt-d-1_62;boost_system-mt-d;boost_system-mt;boost_system -- [ C:/Program Files/CMake/share/cmake-3.6/Modules/FindBoost.cmake:1595 ] Boost_FOUND = 1 CMake Error at C:/Program Files/CMake/share/cmake-3.6/Modules/FindBoost.cmake:1753 (message): Unable to find the requested Boost libraries. Boost version: 1.62.0 Boost include path: C:/env/mingw64/include/boost-1_62 Could not find the following Boost libraries: boost_system No Boost libraries were found. You may need to set BOOST_LIBRARYDIR to the directory containing Boost libraries or BOOST_ROOT to the location of Boost. Call Stack (most recent call first): CMakeLists.txt:3 (find_package) -- Configuring incomplete, errors occurred! See also "C:/Users/S0077863/Desktop/boost/build/CMakeFiles/CMakeOutput.log". What's wrong? Do I need another variable? -- Demelier David From sergey.nikulov at gmail.com Mon Nov 14 10:00:28 2016 From: sergey.nikulov at gmail.com (Sergei Nikulov) Date: Mon, 14 Nov 2016 18:00:28 +0300 Subject: [CMake] FindBoost not finding MinGW libraries In-Reply-To: References: Message-ID: 14 ??? 2016 ?. 4:36 PM ???????????? "David Demelier" < demelier.david at gmail.com> ???????: > > Hello, > > I've installed boost under C:\env\mingw64 so I basically have the > following content: > > - C:\env\mingw64\include\boost-1_62\boost\* > - C:\env\mingw64\lib\libboost_libname-mgw62-1_62.dll(.a) > > I've also set the following environment variables: > > - BOOST_INCLUDEDIR=C:\env\mingw64\include\boost-1_62 > - BOOST_LIBRARYDIR=C:\env\mingw64\lib > - BOOST_ROOT=C:\env\mingw64 > > The following CMakeLists could not find boost: > > cmake_minimum_required(VERSION 3.5) > project(boosttest) > find_package(Boost REQUIRED COMPONENTS system) > > running cmake -G"MinGW Makefiles" -DBoost_DEBUG=On ends with this: > > -- The C compiler identification is GNU 6.2.0 > -- The CXX compiler identification is GNU 6.2.0 > -- Check for working C compiler: C:/mingw64/bin/gcc.exe > -- Check for working C compiler: C:/mingw64/bin/gcc.exe -- works > -- Detecting C compiler ABI info > -- Detecting C compiler ABI info - done > -- Detecting C compile features > -- Detecting C compile features - done > -- Check for working CXX compiler: C:/mingw64/bin/g++.exe > -- Check for working CXX compiler: C:/mingw64/bin/g++.exe -- works > -- Detecting CXX compiler ABI info > -- Detecting CXX compiler ABI info - done > -- Detecting CXX compile features > -- Detecting CXX compile features - done > -- [ C:/Program > Files/CMake/share/cmake-3.6/Modules/FindBoost.cmake:946 ] > _boost_TEST_VERSIONS = > 1.61.0;1.61;1.60.0;1.60;1.59.0;1.59;1.58.0;1.58;1.57.0;1.57;1.56.0;1.56;1.55.0;1.55;1.54.0;1.54;1.53.0;1.53;1.52.0;1.52;1.51.0;1.51;1.50.0;1.50;1.49.0;1.49;1.48.0;1.48;1.47.0;1.47;1.46.1;1.46.0;1.46;1.45.0;1.45;1.44.0;1.44;1.43.0;1.43;1.42.0;1.42;1.41.0;1.41;1.40.0;1.40;1.39.0;1.39;1.38.0;1.38;1.37.0;1.37;1.36.1;1.36.0;1.36;1.35.1;1.35.0;1.35;1.34.1;1.34.0;1.34;1.33.1;1.33.0;1.33 > -- [ C:/Program > Files/CMake/share/cmake-3.6/Modules/FindBoost.cmake:948 ] > Boost_USE_MULTITHREADED = TRUE > -- [ C:/Program > Files/CMake/share/cmake-3.6/Modules/FindBoost.cmake:950 ] > Boost_USE_STATIC_LIBS = > -- [ C:/Program > Files/CMake/share/cmake-3.6/Modules/FindBoost.cmake:952 ] > Boost_USE_STATIC_RUNTIME = > -- [ C:/Program > Files/CMake/share/cmake-3.6/Modules/FindBoost.cmake:954 ] > Boost_ADDITIONAL_VERSIONS = > -- [ C:/Program > Files/CMake/share/cmake-3.6/Modules/FindBoost.cmake:956 ] > Boost_NO_SYSTEM_PATHS = > -- [ C:/Program > Files/CMake/share/cmake-3.6/Modules/FindBoost.cmake:1024 ] Declared as > CMake or Environmental Variables: > -- [ C:/Program > Files/CMake/share/cmake-3.6/Modules/FindBoost.cmake:1026 ] > BOOST_ROOT = > -- [ C:/Program > Files/CMake/share/cmake-3.6/Modules/FindBoost.cmake:1028 ] > BOOST_INCLUDEDIR = > -- [ C:/Program > Files/CMake/share/cmake-3.6/Modules/FindBoost.cmake:1030 ] > BOOST_LIBRARYDIR = > -- [ C:/Program > Files/CMake/share/cmake-3.6/Modules/FindBoost.cmake:1032 ] > _boost_TEST_VERSIONS = > 1.61.0;1.61;1.60.0;1.60;1.59.0;1.59;1.58.0;1.58;1.57.0;1.57;1.56.0;1.56;1.55.0;1.55;1.54.0;1.54;1.53.0;1.53;1.52.0;1.52;1.51.0;1.51;1.50.0;1.50;1.49.0;1.49;1.48.0;1.48;1.47.0;1.47;1.46.1;1.46.0;1.46;1.45.0;1.45;1.44.0;1.44;1.43.0;1.43;1.42.0;1.42;1.41.0;1.41;1.40.0;1.40;1.39.0;1.39;1.38.0;1.38;1.37.0;1.37;1.36.1;1.36.0;1.36;1.35.1;1.35.0;1.35;1.34.1;1.34.0;1.34;1.33.1;1.33.0;1.33 > -- [ C:/Program > Files/CMake/share/cmake-3.6/Modules/FindBoost.cmake:1101 ] Include > debugging info: > -- [ C:/Program > Files/CMake/share/cmake-3.6/Modules/FindBoost.cmake:1103 ] > _boost_INCLUDE_SEARCH_DIRS = > C:/env/mingw64/include/boost-1_62;C:/env/mingw64/include;C:/env/mingw64;PATHS;C:/boost/include;C:/boost;/sw/local/include > -- [ C:/Program > Files/CMake/share/cmake-3.6/Modules/FindBoost.cmake:1105 ] > _boost_PATH_SUFFIXES = > boost-1_61_0;boost_1_61_0;boost/boost-1_61_0;boost/boost_1_61_0;boost-1_61;boost_1_61;boost/boost-1_61;boost/boost_1_61;boost-1_60_0;boost_1_60_0;boost/boost-1_60_0;boost/boost_1_60_0;boost-1_60;boost_1_60;boost/boost-1_60;boost/boost_1_60;boost-1_59_0;boost_1_59_0;boost/boost-1_59_0;boost/boost_1_59_0;boost-1_59;boost_1_59;boost/boost-1_59;boost/boost_1_59;boost-1_58_0;boost_1_58_0;boost/boost-1_58_0;boost/boost_1_58_0;boost-1_58;boost_1_58;boost/boost-1_58;boost/boost_1_58;boost-1_57_0;boost_1_57_0;boost/boost-1_57_0;boost/boost_1_57_0;boost-1_57;boost_1_57;boost/boost-1_57;boost/boost_1_57;boost-1_56_0;boost_1_56_0;boost/boost-1_56_0;boost/boost_1_56_0;boost-1_56;boost_1_56;boost/boost-1_56;boost/boost_1_56;boost-1_55_0;boost_1_55_0;boost/boost-1_55_0;boost/boost_1_55_0;boost-1_55;boost_1_55;boost/boost-1_55;boost/boost_1_55;boost-1_54_0;boost_1_54_0;boost/boost-1_54_0;boost/boost_1_54_0;boost-1_54;boost_1_54;boost/boost-1_54;boost/boost_1_54;boost-1_53_0;boost_1_53_0;boost/boost- > 1_53_0;boost/boost_1_53_0;boost-1_53;boost_1_53;boost/boost-1_53;boost/boost_1_53;boost-1_52_0;boost_1_52_0;boost/boost-1_52_0;boost/boost_1_52_0;boost-1_52;boost_1_52;boost/boost-1_52;boost/boost_1_52;boost-1_51_0;boost_1_51_0;boost/boost-1_51_0;boost/boost_1_51_0;boost-1_51;boost_1_51;boost/boost-1_51;boost/boost_1_51;boost-1_50_0;boost_1_50_0;boost/boost-1_50_0;boost/boost_1_50_0;boost-1_50;boost_1_50;boost/boost-1_50;boost/boost_1_50;boost-1_49_0;boost_1_49_0;boost/boost-1_49_0;boost/boost_1_49_0;boost-1_49;boost_1_49;boost/boost-1_49;boost/boost_1_49;boost-1_48_0;boost_1_48_0;boost/boost-1_48_0;boost/boost_1_48_0;boost-1_48;boost_1_48;boost/boost-1_48;boost/boost_1_48;boost-1_47_0;boost_1_47_0;boost/boost-1_47_0;boost/boost_1_47_0;boost-1_47;boost_1_47;boost/boost-1_47;boost/boost_1_47;boost-1_46_1;boost_1_46_1;boost/boost-1_46_1;boost/boost_1_46_1;boost-1_46_0;boost_1_46_0;boost/boost-1_46_0;boost/boost_1_46_0;boost-1_46;boost_1_46;boost/boost-1_46;boost/boost_1_46;boost-1_45_ > 0;boost_1_45_0;boost/boost-1_45_0;boost/boost_1_45_0;boost-1_45;boost_1_45;boost/boost-1_45;boost/boost_1_45;boost-1_44_0;boost_1_44_0;boost/boost-1_44_0;boost/boost_1_44_0;boost-1_44;boost_1_44;boost/boost-1_44;boost/boost_1_44;boost-1_43_0;boost_1_43_0;boost/boost-1_43_0;boost/boost_1_43_0;boost-1_43;boost_1_43;boost/boost-1_43;boost/boost_1_43;boost-1_42_0;boost_1_42_0;boost/boost-1_42_0;boost/boost_1_42_0;boost-1_42;boost_1_42;boost/boost-1_42;boost/boost_1_42;boost-1_41_0;boost_1_41_0;boost/boost-1_41_0;boost/boost_1_41_0;boost-1_41;boost_1_41;boost/boost-1_41;boost/boost_1_41;boost-1_40_0;boost_1_40_0;boost/boost-1_40_0;boost/boost_1_40_0;boost-1_40;boost_1_40;boost/boost-1_40;boost/boost_1_40;boost-1_39_0;boost_1_39_0;boost/boost-1_39_0;boost/boost_1_39_0;boost-1_39;boost_1_39;boost/boost-1_39;boost/boost_1_39;boost-1_38_0;boost_1_38_0;boost/boost-1_38_0;boost/boost_1_38_0;boost-1_38;boost_1_38;boost/boost-1_38;boost/boost_1_38;boost-1_37_0;boost_1_37_0;boost/boost-1_37_0;boo > st/boost_1_37_0;boost-1_37;boost_1_37;boost/boost-1_37;boost/boost_1_37;boost-1_36_1;boost_1_36_1;boost/boost-1_36_1;boost/boost_1_36_1;boost-1_36_0;boost_1_36_0;boost/boost-1_36_0;boost/boost_1_36_0;boost-1_36;boost_1_36;boost/boost-1_36;boost/boost_1_36;boost-1_35_1;boost_1_35_1;boost/boost-1_35_1;boost/boost_1_35_1;boost-1_35_0;boost_1_35_0;boost/boost-1_35_0;boost/boost_1_35_0;boost-1_35;boost_1_35;boost/boost-1_35;boost/boost_1_35;boost-1_34_1;boost_1_34_1;boost/boost-1_34_1;boost/boost_1_34_1;boost-1_34_0;boost_1_34_0;boost/boost-1_34_0;boost/boost_1_34_0;boost-1_34;boost_1_34;boost/boost-1_34;boost/boost_1_34;boost-1_33_1;boost_1_33_1;boost/boost-1_33_1;boost/boost_1_33_1;boost-1_33_0;boost_1_33_0;boost/boost-1_33_0;boost/boost_1_33_0;boost-1_33;boost_1_33;boost/boost-1_33;boost/boost_1_33 > -- [ C:/Program > Files/CMake/share/cmake-3.6/Modules/FindBoost.cmake:1125 ] location of > version.hpp: C:/env/mingw64/include/boost-1_62/boost/version.hpp > -- [ C:/Program > Files/CMake/share/cmake-3.6/Modules/FindBoost.cmake:1149 ] version.hpp > reveals boost 1.62.0 > -- [ C:/Program > Files/CMake/share/cmake-3.6/Modules/FindBoost.cmake:1235 ] guessed > _boost_COMPILER = -mgw62 > -- [ C:/Program > Files/CMake/share/cmake-3.6/Modules/FindBoost.cmake:1245 ] > _boost_MULTITHREADED = -mt > -- [ C:/Program > Files/CMake/share/cmake-3.6/Modules/FindBoost.cmake:1288 ] > _boost_RELEASE_ABI_TAG = - > -- [ C:/Program > Files/CMake/share/cmake-3.6/Modules/FindBoost.cmake:1290 ] > _boost_DEBUG_ABI_TAG = -d > -- [ C:/Program > Files/CMake/share/cmake-3.6/Modules/FindBoost.cmake:1344 ] > _boost_LIBRARY_SEARCH_DIRS_RELEASE = > C:/env/mingw64/lib;C:/env/mingw64/lib;C:/env/mingw64/stage/lib;C:/env/mingw64/include/boost-1_62/lib;C:/env/mingw64/include/boost-1_62/../lib;C:/env/mingw64/include/boost-1_62/stage/lib;PATHS;C:/boost/lib;C:/boost;/sw/local/lib_boost_LIBRARY_SEARCH_DIRS_DEBUG > = C:/env/mingw64/lib;C:/env/mingw64/lib;C:/env/mingw64/stage/lib;C:/env/mingw64/include/boost-1_62/lib;C:/env/mingw64/include/boost-1_62/../lib;C:/env/mingw64/include/boost-1_62/stage/lib;PATHS;C:/boost/lib;C:/boost;/sw/local/lib > CMake Warning at C:/Program > Files/CMake/share/cmake-3.6/Modules/FindBoost.cmake:743 (message): > Imported targets not available for Boost version 106200 > Call Stack (most recent call first): > C:/Program Files/CMake/share/cmake-3.6/Modules/FindBoost.cmake:842 > (_Boost_COMPONENT_DEPENDENCIES) > C:/Program Files/CMake/share/cmake-3.6/Modules/FindBoost.cmake:1395 > (_Boost_MISSING_DEPENDENCIES) > CMakeLists.txt:3 (find_package) > > > -- [ C:/Program > Files/CMake/share/cmake-3.6/Modules/FindBoost.cmake:1483 ] Searching > for SYSTEM_LIBRARY_RELEASE: > boost_system-mgw62-mt-1_62;boost_system-mgw62-mt;boost_system-mt-1_62;boost_system-mt;boost_system > -- [ C:/Program > Files/CMake/share/cmake-3.6/Modules/FindBoost.cmake:1525 ] Searching > for SYSTEM_LIBRARY_DEBUG: > boost_system-mgw62-mt-d-1_62;boost_system-mgw62-mt-d;boost_system-mt-d-1_62;boost_system-mt-d;boost_system-mt;boost_system > -- [ C:/Program > Files/CMake/share/cmake-3.6/Modules/FindBoost.cmake:1595 ] Boost_FOUND > = 1 > CMake Error at C:/Program > Files/CMake/share/cmake-3.6/Modules/FindBoost.cmake:1753 (message): > Unable to find the requested Boost libraries. > > Boost version: 1.62.0 > > Boost include path: C:/env/mingw64/include/boost-1_62 > > Could not find the following Boost libraries: > > boost_system > > No Boost libraries were found. You may need to set BOOST_LIBRARYDIR to the > directory containing Boost libraries or BOOST_ROOT to the location of > Boost. > Call Stack (most recent call first): > CMakeLists.txt:3 (find_package) > > > -- Configuring incomplete, errors occurred! > See also "C:/Users/S0077863/Desktop/boost/build/CMakeFiles/CMakeOutput.log". > > What's wrong? Do I need another variable? > Add option -DBoost_ADDITIONAL_VERSIONS="1.62.00;1.62" to command line or Update you findboost.cmake module from CMake repository. > > -- > Demelier David > -- > > 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 mario.werner at iaik.tugraz.at Mon Nov 14 10:29:45 2016 From: mario.werner at iaik.tugraz.at (Mario Werner) Date: Mon, 14 Nov 2016 16:29:45 +0100 Subject: [CMake] Are the current scoping rules for functions intended and documented? Message-ID: Hi, I was just surprised by the scoping rules of CMake when it comes to function definitions and sub scopes (i.e., subdirectories). I expected that function definitions adhere to the same scoping rules as variables. More concretely, I assumed that function definitions in a sub scope are only valid in the same (or deeper) scope(s) but do not influence definitions in potential parent scopes. However, as it turns out, (at least CMake 3.5.1) this is not the case. CMake seems to use the last definition of a function it encounters, independent of current scope. I uploaded a quick minimal working example which shows what I mean under [1]. I just discovered this behaviour by hunting down a bug in our build system which was caused by the fact that a function definition in a sub project overwrote an identically named function in the parent project. Now I am wondering if this behaviour is actually intended or if it is a corner case which just never surfaced before. The documentation on functions [2] unfortunately also omits how this is supposed to behave. Any pointers would be appreciated. Regards, Mario [1] https://github.com/niosHD/mwe-cmake-function-scopes [2] https://cmake.org/cmake/help/v3.7/command/function.html From tiagomacarios at gmail.com Mon Nov 14 13:37:23 2016 From: tiagomacarios at gmail.com (Tiago Macarios) Date: Mon, 14 Nov 2016 10:37:23 -0800 Subject: [CMake] clang-format In-Reply-To: <20161114080800.3309eb27@posteo.de> References: <20161114080800.3309eb27@posteo.de> Message-ID: Well, I don't really mind how it is implemented. During compilation, or as a separate target, but it would be a nice feature. On Sun, Nov 13, 2016 at 11:08 PM, Patrick Boettcher < patrick.boettcher at posteo.de> wrote: > Hi, > > On Mon, 7 Nov 2016 12:06:15 -0800 > Tiago Macarios wrote: > > CMake has "built-in" support for clang_tidy and include-what-you-use. > > I was wondering why there is not support for clang_format. No one ever > > contributed, or people think this should not be part of CMake? > > First thought which came to my mind when reading your mail was that no > automatic tool should change (source-)files during compilation which > are, possibly, opened in an editor. > > But, it would, maybe, be nice to have a custom, optional target to run > it on demand. > > If your editor supports it (mine does, even for selected code-lines, \o/ > ) integrate clang-format as source-code-indentation-tool. > > regards > -- > Patrick. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Mon Nov 14 13:47:29 2016 From: brad.king at kitware.com (Brad King) Date: Mon, 14 Nov 2016 13:47:29 -0500 Subject: [CMake] Are the current scoping rules for functions intended and documented? In-Reply-To: References: Message-ID: On 11/14/2016 10:29 AM, Mario Werner wrote: > I was just surprised by the scoping rules of CMake when it comes to > function definitions and sub scopes (i.e., subdirectories). I expected > that function definitions adhere to the same scoping rules as variables. That would be nice behavior. > However, as it turns out, (at least CMake 3.5.1) this is not the case. > CMake seems to use the last definition of a function it encounters, > independent of current scope. Commands (builtin+functions+macros) are currently scoped globally. > Now I am wondering if this behaviour is actually intended or if it is a > corner case which just never surfaced before. It just happened to be implemented that way from the beginning back in our wild west days without much thought to scoping. It is indeed not documented AFAIK, but a good place to add this to the docs might be here: https://cmake.org/cmake/help/v3.7/manual/cmake-language.7.html#command-definitions It is also something that could be changed by the introduction of a new CMake Policy, though it would be a bit of work to get right. -Brad From kimberly.kryger at gmail.com Mon Nov 14 16:05:07 2016 From: kimberly.kryger at gmail.com (Kim Kryger) Date: Mon, 14 Nov 2016 16:05:07 -0500 Subject: [CMake] Force MSVC runtime for debug builds In-Reply-To: References: <465919898.71405621.1478618462782.JavaMail.zimbra@elemtech.com> Message-ID: I ran into this today. I tried to use /MD to link against a custom md library, but because _DEBUG was defined *by CMake* I couldn't use it out of the box. Why is CMake defining _DEBUG for MSVC projects anyways? _DEBUG is automatically defined when using /MDd, and I don't believe it should be defining it itself. I've had to remove it for multiple projects because it's making assumptions as to what I want defined. Default for CMAKE_CXX_FLAGS_DEBUG_INIT /D_DEBUG /MDd /Zi /Ob0 /Od /RTC1 I don't think that first define should be there. Reference: https://github.com/Kitware/CMake/blob/5d29506811c5b75ae48e12de6c317f6440874215/Modules/Platform/Windows-MSVC.cmake#L294 https://msdn.microsoft.com/en-us/library/0b98s6w8.aspx On Fri, Nov 11, 2016 at 9:42 AM, Stephan Menzel wrote: > > On Tue, Nov 8, 2016 at 4:21 PM, wrote: >> >> If you are going to use /MD instead of /MDd, then you probably also need >> to remove the _DEBUG preprocessor flag. >> IIRC, I've seen cases where defining _DEBUG includes symbols only >> defined by the debug runtimes. >> >> Clint >> > > What a surprise. Removing _DEBUG did the trick. I was under the impression > _DEBUG only controls Microsoft STL impl's debug iterator stuff but > apparently it also makes the resulting exe link with /MD rather than /MDd. > Guess that was wrong. > > So yes, problem solved. > > Thank you! > > Stephan > > -- > > 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 stephen at egroat.com Mon Nov 14 19:11:37 2016 From: stephen at egroat.com (Stephen Groat) Date: Tue, 15 Nov 2016 00:11:37 +0000 Subject: [CMake] System is unknown to cmake Platform/MINGW64_NT-6.3 Message-ID: Received this error message ( https://ci.appveyor.com/project/stephengroat/unicorn/build/1.0.23/job/ybemjtabbbwvab86#L200) but don't know where to look in the directory for the config file. I'm running Mingw-w64 with msys and bash. Any advice? Thanks, Stephen -------------- next part -------------- An HTML attachment was scrubbed... URL: From Johannes.Sebastian.Mueller-Roemer at igd.fraunhofer.de Tue Nov 15 03:47:38 2016 From: Johannes.Sebastian.Mueller-Roemer at igd.fraunhofer.de (Mueller-Roemer, Johannes Sebastian) Date: Tue, 15 Nov 2016 08:47:38 +0000 Subject: [CMake] Force MSVC runtime for debug builds In-Reply-To: References: <465919898.71405621.1478618462782.JavaMail.zimbra@elemtech.com> Message-ID: <8D981219EEA621479C112DA9BDC39A8E640D735E@EXMBS2.ad.igd.fraunhofer.de> I agree that CMake should not be defining _DEBUG explicitly, as it is used by Microsoft?s headers to match the chosen runtime. Maybe this warrants a bug report on gitlab. From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Kim Kryger Sent: Monday, November 14, 2016 22:05 To: Stephan Menzel Cc: cmake Subject: Re: [CMake] Force MSVC runtime for debug builds I ran into this today. I tried to use /MD to link against a custom md library, but because _DEBUG was defined *by CMake* I couldn't use it out of the box. Why is CMake defining _DEBUG for MSVC projects anyways? _DEBUG is automatically defined when using /MDd, and I don't believe it should be defining it itself. I've had to remove it for multiple projects because it's making assumptions as to what I want defined. Default for CMAKE_CXX_FLAGS_DEBUG_INIT /D_DEBUG /MDd /Zi /Ob0 /Od /RTC1 I don't think that first define should be there. Reference: https://github.com/Kitware/CMake/blob/5d29506811c5b75ae48e12de6c317f6440874215/Modules/Platform/Windows-MSVC.cmake#L294 https://msdn.microsoft.com/en-us/library/0b98s6w8.aspx On Fri, Nov 11, 2016 at 9:42 AM, Stephan Menzel > wrote: On Tue, Nov 8, 2016 at 4:21 PM, > wrote: If you are going to use /MD instead of /MDd, then you probably also need to remove the _DEBUG preprocessor flag. IIRC, I've seen cases where defining _DEBUG includes symbols only defined by the debug runtimes. Clint What a surprise. Removing _DEBUG did the trick. I was under the impression _DEBUG only controls Microsoft STL impl's debug iterator stuff but apparently it also makes the resulting exe link with /MD rather than /MDd. Guess that was wrong. So yes, problem solved. Thank you! Stephan -- 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 demelier.david at gmail.com Tue Nov 15 04:26:50 2016 From: demelier.david at gmail.com (David Demelier) Date: Tue, 15 Nov 2016 10:26:50 +0100 Subject: [CMake] FindBoost not finding MinGW libraries In-Reply-To: References: Message-ID: 2016-11-14 16:00 GMT+01:00 Sergei Nikulov : > Add option -DBoost_ADDITIONAL_VERSIONS="1.62.00;1.62" to command line > or > Update you findboost.cmake module from CMake repository. I've tried the additional the variable with no luck. I've also updated CMake to 3.7 with no luck. I will try by downloading the FindBoost.cmake from the git. -- Demelier David From sergey.nikulov at gmail.com Tue Nov 15 06:10:49 2016 From: sergey.nikulov at gmail.com (Sergei Nikulov) Date: Tue, 15 Nov 2016 14:10:49 +0300 Subject: [CMake] FindBoost not finding MinGW libraries In-Reply-To: References: Message-ID: 2016-11-15 12:26 GMT+03:00 David Demelier : > 2016-11-14 16:00 GMT+01:00 Sergei Nikulov : >> Add option -DBoost_ADDITIONAL_VERSIONS="1.62.00;1.62" to command line >> or >> Update you findboost.cmake module from CMake repository. > > I've tried the additional the variable with no luck. I've also updated > CMake to 3.7 with no luck. I will try by downloading the > FindBoost.cmake from the git. > > -- > Demelier David Anyway, you should add additional versions. According to your output there is no version 1.62 in find module. > Files/CMake/share/cmake-3.6/Modules/FindBoost.cmake:1032 ] _boost_TEST_VERSIONS = 1.61.0;1.61;1.60.0;1.60;1.59.0;1.59;1.58.0;1.58;1.57.0;1.57;1.56.0;1.56;1.55.0;1.55;1.54.0;1.54;1.53.0;1.53;1.52.0;1.52;1.51.0;1.51;1.50.0;1.50;1.49.0;1.49;1.48.0;1.48;1.47.0;1.47;1.46.1;1.46.0;1.46;1.45.0;1.45;1.44.0;1.44;1.43.0;1.43;1.42.0;1.42;1.41.0;1.41;1.40.0;1.40;1.39.0;1.39;1.38.0;1.38;1.37.0;1.37;1.36.1;1.36.0;1.36;1.35.1;1.35.0;1.35;1.34.1;1.34.0;1.34;1.33.1;1.33.0;1.33 And option -DBOOST_ROOT=C:\env\mingw64 also should be enough. -- Best Regards, Sergei Nikulov From mario.werner at iaik.tugraz.at Tue Nov 15 07:49:16 2016 From: mario.werner at iaik.tugraz.at (Mario Werner) Date: Tue, 15 Nov 2016 13:49:16 +0100 Subject: [CMake] Are the current scoping rules for functions intended and documented? In-Reply-To: References: Message-ID: Hi Brad, thank you very much for the clarification and the background information! I definitely have to scrutinize our CMake code to make sure that no additional problems are lurking in our build system. For now, I am going to file a feature request to keep track of the idea of properly scoping function and macro definitions. As soon as I have more time on my hands I may come back to it and give it try. Cheers, Mario On 2016-11-14 19:47, Brad King wrote: > On 11/14/2016 10:29 AM, Mario Werner wrote: >> I was just surprised by the scoping rules of CMake when it comes to >> function definitions and sub scopes (i.e., subdirectories). I expected >> that function definitions adhere to the same scoping rules as variables. > > That would be nice behavior. > >> However, as it turns out, (at least CMake 3.5.1) this is not the case. >> CMake seems to use the last definition of a function it encounters, >> independent of current scope. > > Commands (builtin+functions+macros) are currently scoped globally. > >> Now I am wondering if this behaviour is actually intended or if it is a >> corner case which just never surfaced before. > > It just happened to be implemented that way from the beginning back in > our wild west days without much thought to scoping. It is indeed not > documented AFAIK, but a good place to add this to the docs might be here: > > https://cmake.org/cmake/help/v3.7/manual/cmake-language.7.html#command-definitions > > It is also something that could be changed by the introduction of a > new CMake Policy, though it would be a bit of work to get right. > > -Brad > From foss at grueninger.de Tue Nov 15 09:16:19 2016 From: foss at grueninger.de (=?UTF-8?Q?Christoph_Gr=c3=bcninger?=) Date: Tue, 15 Nov 2016 15:16:19 +0100 Subject: [CMake] CMake 3.7: Test #379: RunCMake.CPack_RPM fails In-Reply-To: References: Message-ID: <30b93f76-00ec-d343-5141-35445b9bc723@grueninger.de> Hi Domen, thanks for your answer. > > CMake 3.7 compiles so far, but test #379 (RunCMake.CPack_RPM) fails, see > > the error below from OBS. I had a brief look at our patches and I am apt > > to think they are unrelated. > > Can someone have a look and give some hint? > > > I'll test it today in the afternoon but for now since sources are > missing from the package I'm guessing that debuginfo rpm packaging > rpmbuild macro on openSUSE has some differences compared to the one in > other distros. CPack/RPM overrides it to compensate for the fact that > sources can be generated during build (rpmbuild debuginfo macro only > supports packaging of sources located in source dir during packaging so > that works only for insource builds...). I don't know enough about openSuse rpmbuild macro. But I know it works for CMake 3.6.2 and broke for 3.7.0. Is test #379 new or was it changed? Bye Christoph From kimberly.kryger at gmail.com Tue Nov 15 10:00:03 2016 From: kimberly.kryger at gmail.com (Kim Kryger) Date: Tue, 15 Nov 2016 10:00:03 -0500 Subject: [CMake] Force MSVC runtime for debug builds In-Reply-To: <8D981219EEA621479C112DA9BDC39A8E640D735E@EXMBS2.ad.igd.fraunhofer.de> References: <465919898.71405621.1478618462782.JavaMail.zimbra@elemtech.com> <8D981219EEA621479C112DA9BDC39A8E640D735E@EXMBS2.ad.igd.fraunhofer.de> Message-ID: Issue created: https://gitlab.kitware.com/cmake/cmake/issues/16430 On Tue, Nov 15, 2016 at 3:47 AM, Mueller-Roemer, Johannes Sebastian < Johannes.Sebastian.Mueller-Roemer at igd.fraunhofer.de> wrote: > I agree that CMake should not be defining _DEBUG explicitly, as it is used > by Microsoft?s headers to match the chosen runtime. > > Maybe this warrants a bug report on gitlab. > > > > *From:* CMake [mailto:cmake-bounces at cmake.org] *On Behalf Of *Kim Kryger > *Sent:* Monday, November 14, 2016 22:05 > *To:* Stephan Menzel > *Cc:* cmake > *Subject:* Re: [CMake] Force MSVC runtime for debug builds > > > > I ran into this today. I tried to use /MD to link against a custom md > library, but because _DEBUG was defined *by CMake* I couldn't use it out of > the box. > > > > Why is CMake defining _DEBUG for MSVC projects anyways? _DEBUG is > automatically defined when using /MDd, and I don't believe it should be > defining it itself. I've had to remove it for multiple projects because > it's making assumptions as to what I want defined. > > > > > > Default for CMAKE_CXX_FLAGS_DEBUG_INIT > > /D_DEBUG /MDd /Zi /Ob0 /Od /RTC1 > > > > I don't think that first define should be there. > > > > > > Reference: > > https://github.com/Kitware/CMake/blob/5d29506811c5b75ae48e12de6c317f > 6440874215/Modules/Platform/Windows-MSVC.cmake#L294 > > https://msdn.microsoft.com/en-us/library/0b98s6w8.aspx > > > > > > On Fri, Nov 11, 2016 at 9:42 AM, Stephan Menzel > wrote: > > > > On Tue, Nov 8, 2016 at 4:21 PM, wrote: > > If you are going to use /MD instead of /MDd, then you probably also need > to remove the _DEBUG preprocessor flag. > > IIRC, I've seen cases where defining _DEBUG includes symbols only > defined by the debug runtimes. > > > > Clint > > > > What a surprise. Removing _DEBUG did the trick. I was under the impression > _DEBUG only controls Microsoft STL impl's debug iterator stuff but > apparently it also makes the resulting exe link with /MD rather than /MDd. > Guess that was wrong. > > > > So yes, problem solved. > > > > Thank you! > > > > Stephan > > > -- > > 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 domen.vrankar at gmail.com Tue Nov 15 09:59:35 2016 From: domen.vrankar at gmail.com (Domen Vrankar) Date: Tue, 15 Nov 2016 15:59:35 +0100 Subject: [CMake] CMake 3.7: Test #379: RunCMake.CPack_RPM fails In-Reply-To: <30b93f76-00ec-d343-5141-35445b9bc723@grueninger.de> References: <30b93f76-00ec-d343-5141-35445b9bc723@grueninger.de> Message-ID: 2016-11-15 15:16 GMT+01:00 Christoph Gr?ninger : > Hi Domen, > thanks for your answer. > > > > CMake 3.7 compiles so far, but test #379 (RunCMake.CPack_RPM) fails, > see > > > the error below from OBS. I had a brief look at our patches and I am > apt > > > to think they are unrelated. > > > Can someone have a look and give some hint? > > > > > > I'll test it today in the afternoon but for now since sources are > > missing from the package I'm guessing that debuginfo rpm packaging > > rpmbuild macro on openSUSE has some differences compared to the one in > > other distros. CPack/RPM overrides it to compensate for the fact that > > sources can be generated during build (rpmbuild debuginfo macro only > > supports packaging of sources located in source dir during packaging so > > that works only for insource builds...). > > I don't know enough about openSuse rpmbuild macro. But I know it works > for CMake 3.6.2 and broke for 3.7.0. Is test #379 new or was it changed? > This is a new test for new functionality - CPackRPM can now generate debuginfo rpm and source rpm packages (and in git repository there is also single debuginfo package for all components which missed the 3.7 release schedule so even more tests that will fail on openSUSE :)). Yesterday I managed to confirm that the issue is with overriding debuginfo template macro but failed to find the reason why (openSUSE seems to generate debuginfo packages without using that macro - it is defined in main rpm macros file but as far as I can tell it's not used). I'll try to find a solution for that but since other tests pass the only drawback is that people won't be able to use this new feature so this shouldn't be a showstopper for you packaging a new CMake release. Regards, Domen -------------- next part -------------- An HTML attachment was scrubbed... URL: From ramey at rrsd.com Tue Nov 15 11:39:10 2016 From: ramey at rrsd.com (Robert Ramey) Date: Tue, 15 Nov 2016 08:39:10 -0800 Subject: [CMake] FindBoost not finding MinGW libraries In-Reply-To: References: Message-ID: On 11/14/16 5:36 AM, David Demelier wrote: I spent some time getting CMake to work with with boost libraries. My conclusions is that FindBoost can be relied upon only for header only libraries. To used build libraries, you'll have to explicitly set the specific library variable to the path where the library is located. For example, in order to link with the boost.filesystem library debug version I set Boost_FILESYSTEM_LIBRARY_DEBUG to /Users/robertramey/WorkingProjects/modular-boost/stage/lib/Debug/libboost_filesystem-clang-darwin-mt-d-1_62.a I haven't tried with with shard libraries. Basically, FindBoost needs some improvement before it can be expected to automagically find libraries to link to. Robert Ramey From foss at grueninger.de Tue Nov 15 17:59:18 2016 From: foss at grueninger.de (=?UTF-8?Q?Christoph_Gr=c3=bcninger?=) Date: Tue, 15 Nov 2016 23:59:18 +0100 Subject: [CMake] Compiling CMake without libuv? Message-ID: <6edda3f6-bcdd-9c92-0df9-86589abf0530@grueninger.de> Dear CMake folks, I am trying to package CMake for openSuse. I was a bit surprised that the new dependency libuv was nowhere mentioned. Can it be disabled by a configure switch for older systems? Currently it errors out when libuv is not found. It should be only necessary for cmake-server, right? Bye Christoph From robert.maynard at kitware.com Wed Nov 16 00:04:26 2016 From: robert.maynard at kitware.com (Robert Maynard) Date: Wed, 16 Nov 2016 00:04:26 -0500 Subject: [CMake] Compiling CMake without libuv? In-Reply-To: <6edda3f6-bcdd-9c92-0df9-86589abf0530@grueninger.de> References: <6edda3f6-bcdd-9c92-0df9-86589abf0530@grueninger.de> Message-ID: You can ask CMake to use its own copy of libuv by specifying CMAKE_USE_SYSTEM_LIBRARY_LIBUV to false. If building even the CMake version of libuv is not possible you can just disable building server mode by setting CMake_ENABLE_SERVER_MODE On Tue, Nov 15, 2016 at 5:59 PM, Christoph Gr?ninger wrote: > Dear CMake folks, > I am trying to package CMake for openSuse. I was a bit surprised that > the new dependency libuv was nowhere mentioned. > Can it be disabled by a configure switch for older systems? > Currently it errors out when libuv is not found. It should be only > necessary for cmake-server, right? > > Bye > Christoph > -- > > 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 sergey.nikulov at gmail.com Wed Nov 16 02:19:14 2016 From: sergey.nikulov at gmail.com (Sergei Nikulov) Date: Wed, 16 Nov 2016 10:19:14 +0300 Subject: [CMake] FindBoost not finding MinGW libraries In-Reply-To: References: Message-ID: 15 ??? 2016 ?. 7:40 PM ???????????? "Robert Ramey" ???????: > > On 11/14/16 5:36 AM, David Demelier wrote: > I spent some time getting CMake to work with with boost libraries. > > My conclusions is that FindBoost can be relied upon only for header only libraries. To used build libraries, you'll have to explicitly set the specific library variable to the path where the library is located. > > For example, in order to link with the boost.filesystem library debug version I set > > Boost_FILESYSTEM_LIBRARY_DEBUG to > > /Users/robertramey/WorkingProjects/modular-boost/stage/lib/Debug/libboost_filesystem-clang-darwin-mt-d-1_62.a > > I haven't tried with with shard libraries. > > Basically, FindBoost needs some improvement before it can be expected to automagically find libraries to link to. > > Robert Ramey > Never heard about such problems before. Always works well on Windows platform with msvc and mingw. Setting BOOST_ROOT to folder used as prefix in 'b2 intsall' command should suffice. > > -- > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Wed Nov 16 07:22:15 2016 From: brad.king at kitware.com (Brad King) Date: Wed, 16 Nov 2016 07:22:15 -0500 Subject: [CMake] Compiling CMake without libuv? In-Reply-To: References: <6edda3f6-bcdd-9c92-0df9-86589abf0530@grueninger.de> Message-ID: <74197ed0-6885-1586-50c1-a3aba91bc586@kitware.com> On 11/16/2016 12:04 AM, Robert Maynard wrote: > You can ask CMake to use its own copy of libuv by specifying > CMAKE_USE_SYSTEM_LIBRARY_LIBUV to false. > > If building even the CMake version of libuv is not possible you can > just disable building server mode by setting CMake_ENABLE_SERVER_MODE There is also the CMAKE_USE_LIBUV option that can be set to OFF. One can pass it to the bootstrap script via ../cmake/bootstrap ... -- -DCMAKE_USE_LIBUV=OFF > On Tue, Nov 15, 2016 at 5:59 PM, Christoph Gr?ninger wrote: >> It should be only necessary for cmake-server, right? Correct, though that is a major new feature that would typically be expected to exist in distro-packaged builds. IDEs may soon look for it. -Brad From mario.werner at iaik.tugraz.at Wed Nov 16 08:32:46 2016 From: mario.werner at iaik.tugraz.at (Mario Werner) Date: Wed, 16 Nov 2016 14:32:46 +0100 Subject: [CMake] Are the current scoping rules for functions intended and documented? In-Reply-To: References: Message-ID: Hi Brad, unfortunately I failed to file an issue to keep track of this feature request. Gitlab always recognizes the text as spam and discards it. I tried the following title and text: ```````````````````````````````````````````````````````````` Title ----- Function and macro definitions should obey the same scoping rules as variables Text ---- Hi all, as Brad confirmed on the [mailing list](https://www.mail-archive.com/cmake at cmake.org/msg55886.html), functions and macros are currently scoped globally. This means that any function definition in a sub scope (e.g., created via `add_subdirectory`) can redefine functions for the parent. The fact that CMake also always picks the last definition it encounters additionally introduces the problem that the order in which CMakeLists are processed can change the behaviour of the build system. This feature request therefore propose that function and macro definitions should obey the same scoping rules as variables to mitigate this potential pitfall. ```````````````````````````````````````````````````````````` Do you have any recommendations on how I can resolve this? Cheers, Mario From mika.fischer at zoopnet.de Wed Nov 16 11:36:53 2016 From: mika.fischer at zoopnet.de (Mika Fischer) Date: Wed, 16 Nov 2016 17:36:53 +0100 Subject: [CMake] Relinking with Ninja broken in 3.7.0 Message-ID: Hi, I get the following error even though I'm on Linux and thus an ELF-based platform. This breaks all our builds... `The install of the target requires changing an RPATH from the build tree, but this is not supported with the Ninja generator unless on an ELF-based platform. The CMAKE_BUILD_WITH_INSTALL_RPATH variable may be set to avoid this relinking step.` Looking at cmGeneratorTarget.cxx#L1214, I see that there's no switch for ELF-based platforms, it just unconditionally throws a fatal error when relinking is required and ninja is being used... Is the error message misleading and this should actually work on Linux? Or is this not supposed to be working, and we should no longer use ninja? If so, why? CMAKE_BUILD_WITH_INSTALL_RPATH is not a viable alternative for us... Best, Mika -------------- next part -------------- An HTML attachment was scrubbed... URL: From annulen at yandex.ru Wed Nov 16 11:56:03 2016 From: annulen at yandex.ru (Konstantin Tokarev) Date: Wed, 16 Nov 2016 19:56:03 +0300 Subject: [CMake] Relinking with Ninja broken in 3.7.0 In-Reply-To: References: Message-ID: <160881479315363@web24j.yandex.ru> 16.11.2016, 19:44, "Mika Fischer" : > Hi, > > I get the following error even though I'm on Linux and thus an ELF-based platform. This breaks all our builds... > > `The install of the target requires changing an RPATH from > the build tree, but this is not supported with the Ninja generator unless > on an ELF-based platform.? The CMAKE_BUILD_WITH_INSTALL_RPATH variable may > be set to avoid this relinking step.` > > Looking at cmGeneratorTarget.cxx#L1214, I see that there's no switch for ELF-based platforms, it just unconditionally throws a fatal error when relinking is required and ninja is being used... > > Is the error message misleading and this should actually work on Linux? > Or is this not supposed to be working, and we should no longer use ninja? If so, why? > > CMAKE_BUILD_WITH_INSTALL_RPATH is not a viable alternative for us... I just fix up cmake_install.cmake with sed to replace CMakeRelink.dir with real library location > > Best, > ?Mika > ,-- > > 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 bill.hoffman at kitware.com Wed Nov 16 12:21:45 2016 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Wed, 16 Nov 2016 12:21:45 -0500 Subject: [CMake] Relinking with Ninja broken in 3.7.0 In-Reply-To: References: Message-ID: On 11/16/2016 11:36 AM, Mika Fischer wrote: > > I get the following error even though I'm on Linux and thus an ELF-based > platform. This breaks all our builds... > > `The install of the target requires changing an RPATH from > the build tree, but this is not supported with the Ninja generator unless > on an ELF-based platform. The CMAKE_BUILD_WITH_INSTALL_RPATH variable may > be set to avoid this relinking step.` > > Looking at cmGeneratorTarget.cxx#L1214, I see that there's no switch for > ELF-based platforms, it just unconditionally throws a fatal error when > relinking is required and ninja is being used... > > Is the error message misleading and this should actually work on Linux? > Or is this not supposed to be working, and we should no longer use > ninja? If so, why? > > CMAKE_BUILD_WITH_INSTALL_RPATH is not a viable alternative for us... > Did you start with a completely clean build tree? Or did you maybe just remove the CMakeCache.txt file? -Bill From mwoehlke.floss at gmail.com Wed Nov 16 12:50:14 2016 From: mwoehlke.floss at gmail.com (Matthew Woehlke) Date: Wed, 16 Nov 2016 12:50:14 -0500 Subject: [CMake] exporting targets from build tree In-Reply-To: References: Message-ID: On 2016-07-27 18:49, Michael Legleux wrote: > I have 2 projects (one built with cmake, one in the process of being > converted to using it) > > Project A (built with cmake) builds lib_a that Project B requires. > I'm thinking I'm doing something wrong around here: > project(lib_a) > .... > add_library(lib_a STATIC ${SRC}) > target_link_libraries(${PROJECT_NAME} > PRIVATE lib_b > ) > export(TARGETS lib_a FILE lib_a.cmake) > > cmake complains that lib_b is not in the target export set. I do not WANT > it exported and it is not required by project b. > I simply want lib_a to be found/used by Project B via find_package(Project > A) > > I do not want to have to install/ or create a package for this behavior, > just allow another project to reference the libs in the build tree and > headers in the source tree. > > I can't seem to find the correct way to express this with cmake despite > looking at many solutions of near similar functionality. Did you ever solve this? Offhand, I would guess that lib_a is a static library. If this is the case, using lib_a requires also linking to lib_b, because the symbols in lib_a require lib_b, and lib_a is not actually linked yet. -- Matthew From mwoehlke.floss at gmail.com Wed Nov 16 13:37:16 2016 From: mwoehlke.floss at gmail.com (Matthew Woehlke) Date: Wed, 16 Nov 2016 13:37:16 -0500 Subject: [CMake] Is there a default value for CMAKE_MODULE_PATH? In-Reply-To: <8045330.BrvOJs8lRZ@wadner> References: <8045330.BrvOJs8lRZ@wadner> Message-ID: On 2016-11-09 10:05, Jayesh Badwaik wrote: > Over past few days, Boost has updated from version 1.61 to version 1.62. The > latest version of CMake that I have (3.6.3) does not yet have the appropriate > FindBoost.cmake and hence, issues warnings as shown in the postscript. > > As I see this is temporary, and there is a correct FindBoost.cmake in the git > repository which works fine. So, I want to use this new module file till the > time when the new version of CMake comes out and I won't have to use this > special file anymore. > > All the solutions that I have found on internet require me to put a line > setting the CMAKE_MODULE_PATH in my project source code. I don't want to do it > since the change is supposed to be temporary anyway. So, I was wondering if > there is a location inside the PROJECT_SOURCE_DIR which is scanned by default > by cmake? > > If there is no such location, I can live with the warnings for a little while, > but I was just curious. I don't think you can avoid setting CMAKE_MODULE_PATH. Also, it's only "temporary" until you bump your cmake_minimum_required. What I've done in some projects is include the module in a directory named after the version of CMake that will include the updated version. You can then iterate over such directories and compare the name to the CMake version to decide whether or not to add that directory. This way someone with new enough CMake to not need the module will use the built-in version, while someone with older CMake will get your copy. -- Matthew From mika.fischer at zoopnet.de Wed Nov 16 13:47:47 2016 From: mika.fischer at zoopnet.de (Mika Fischer) Date: Wed, 16 Nov 2016 19:47:47 +0100 Subject: [CMake] Relinking with Ninja broken in 3.7.0 In-Reply-To: References: Message-ID: 2016-11-16 18:21 GMT+01:00 Bill Hoffman : > On 11/16/2016 11:36 AM, Mika Fischer wrote: > >> >> I get the following error even though I'm on Linux and thus an ELF-based >> platform. This breaks all our builds... >> >> `The install of the target requires changing an RPATH from >> the build tree, but this is not supported with the Ninja generator unless >> on an ELF-based platform. The CMAKE_BUILD_WITH_INSTALL_RPATH variable may >> be set to avoid this relinking step.` >> >> Looking at cmGeneratorTarget.cxx#L1214, I see that there's no switch for >> ELF-based platforms, it just unconditionally throws a fatal error when >> relinking is required and ninja is being used... >> >> Is the error message misleading and this should actually work on Linux? >> Or is this not supposed to be working, and we should no longer use >> ninja? If so, why? >> >> CMAKE_BUILD_WITH_INSTALL_RPATH is not a viable alternative for us... >> >> Did you start with a completely clean build tree? Or did you maybe just > remove the CMakeCache.txt file? Ah yes, that was the problem. Thanks a lot and sorry for the noise! Best, Mika -------------- next part -------------- An HTML attachment was scrubbed... URL: From nikita.kakuev at gmail.com Wed Nov 16 16:32:58 2016 From: nikita.kakuev at gmail.com (Nikita) Date: Thu, 17 Nov 2016 00:32:58 +0300 Subject: [CMake] CXX_CLANG_TIDY doesn't handle multiple arguments correctly Message-ID: Hi, I've noticed that CXX_CLANG_TIDY property doesn't work correctly if I specify several arguments to clang-tidy. Here's an example: set_property( TARGET ${PROJECT_NAME} PROPERTY CXX_CLANG_TIDY clang-tidy;-checks=*;-warnings-as-errors=*) Building a target with this property produces no output. It seems like clang-tidy doesn't get called. However, if I remove '-warnings-as-errors', everything works fine. The same goes for other options as well. Specifying '-header-filter' or '-line-filter' results in no output. Is there a way to get additional clang-tidy options working? Regards, Nikita From tiagomacarios at gmail.com Wed Nov 16 16:35:53 2016 From: tiagomacarios at gmail.com (Tiago Macarios) Date: Wed, 16 Nov 2016 13:35:53 -0800 Subject: [CMake] CXX_CLANG_TIDY doesn't handle multiple arguments correctly In-Reply-To: References: Message-ID: This works for me: CXX_CLANG_TIDY "/usr/bin/clang-tidy" "-checks=modernize-*,readability-*,performance-*" "-fix" I think the difference are the semicolons in the checks instead of commas. On Wed, Nov 16, 2016 at 1:32 PM, Nikita wrote: > Hi, > > I've noticed that CXX_CLANG_TIDY property doesn't work correctly if I > specify several arguments to clang-tidy. Here's an example: > set_property( > TARGET ${PROJECT_NAME} > PROPERTY CXX_CLANG_TIDY clang-tidy;-checks=*;-warnings-as-errors=*) > > Building a target with this property produces no output. It seems like > clang-tidy doesn't get called. However, if I remove > '-warnings-as-errors', everything works fine. > > The same goes for other options as well. Specifying '-header-filter' > or '-line-filter' results in no output. > > Is there a way to get additional clang-tidy options working? > > Regards, > Nikita > -- > > 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 foss at grueninger.de Wed Nov 16 16:49:48 2016 From: foss at grueninger.de (=?UTF-8?Q?Christoph_Gr=c3=bcninger?=) Date: Wed, 16 Nov 2016 22:49:48 +0100 Subject: [CMake] Compiling CMake without libuv? In-Reply-To: <74197ed0-6885-1586-50c1-a3aba91bc586@kitware.com> References: <6edda3f6-bcdd-9c92-0df9-86589abf0530@grueninger.de> <74197ed0-6885-1586-50c1-a3aba91bc586@kitware.com> Message-ID: Hi Brad, thanks for the answer, I wasn't aware that I can pass CMake options to the bootstrap script. > There is also the CMAKE_USE_LIBUV option that can be set to OFF. > One can pass it to the bootstrap script via > > ../cmake/bootstrap ... -- -DCMAKE_USE_LIBUV=OFF > Works, that will ensure all package will have libuv. Bye Christoph From nikita.kakuev at gmail.com Wed Nov 16 17:01:07 2016 From: nikita.kakuev at gmail.com (Nikita) Date: Thu, 17 Nov 2016 01:01:07 +0300 Subject: [CMake] CXX_CLANG_TIDY doesn't handle multiple arguments correctly In-Reply-To: References: Message-ID: It works for me with '-fix' as well. However, it doesn't work with "-warnings-as-errors", '-header-filter', and '-line-filter'. The problem is definitely not in semicolons. Regards, Nikita On Thu, Nov 17, 2016 at 12:35 AM, Tiago Macarios wrote: > This works for me: > > CXX_CLANG_TIDY > "/usr/bin/clang-tidy" > "-checks=modernize-*,readability-*,performance-*" > "-fix" > > I think the difference are the semicolons in the checks instead of commas. > > On Wed, Nov 16, 2016 at 1:32 PM, Nikita wrote: >> >> Hi, >> >> I've noticed that CXX_CLANG_TIDY property doesn't work correctly if I >> specify several arguments to clang-tidy. Here's an example: >> set_property( >> TARGET ${PROJECT_NAME} >> PROPERTY CXX_CLANG_TIDY clang-tidy;-checks=*;-warnings-as-errors=*) >> >> Building a target with this property produces no output. It seems like >> clang-tidy doesn't get called. However, if I remove >> '-warnings-as-errors', everything works fine. >> >> The same goes for other options as well. Specifying '-header-filter' >> or '-line-filter' results in no output. >> >> Is there a way to get additional clang-tidy options working? >> >> Regards, >> Nikita >> -- >> >> 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 bill.hoffman at kitware.com Wed Nov 16 17:18:02 2016 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Wed, 16 Nov 2016 17:18:02 -0500 Subject: [CMake] CXX_CLANG_TIDY doesn't handle multiple arguments correctly In-Reply-To: References: Message-ID: <2cbfc281-8c25-c158-4411-a63517a59c51@kitware.com> On 11/16/2016 5:01 PM, Nikita wrote: > It works for me with '-fix' as well. However, it doesn't work with > "-warnings-as-errors", '-header-filter', and '-line-filter'. > The problem is definitely not in semicolons. It is the * that causes trouble. -Bill From nikita.kakuev at gmail.com Wed Nov 16 17:32:55 2016 From: nikita.kakuev at gmail.com (Nikita) Date: Thu, 17 Nov 2016 01:32:55 +0300 Subject: [CMake] CXX_CLANG_TIDY doesn't handle multiple arguments correctly In-Reply-To: <2cbfc281-8c25-c158-4411-a63517a59c51@kitware.com> References: <2cbfc281-8c25-c158-4411-a63517a59c51@kitware.com> Message-ID: Indeed, specifying '-line-filter=[]' doesn't cause any troubles. Should I file a bug about this? Regards, Nikita On Thu, Nov 17, 2016 at 1:18 AM, Bill Hoffman wrote: > On 11/16/2016 5:01 PM, Nikita wrote: >> >> It works for me with '-fix' as well. However, it doesn't work with >> "-warnings-as-errors", '-header-filter', and '-line-filter'. >> The problem is definitely not in semicolons. > > It is the * that causes trouble. > > -Bill > > > -- > > 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 Wed Nov 16 17:37:13 2016 From: mellery451 at gmail.com (Michael Ellery) Date: Wed, 16 Nov 2016 14:37:13 -0800 Subject: [CMake] CXX_CLANG_TIDY doesn't handle multiple arguments correctly In-Reply-To: References: <2cbfc281-8c25-c158-4411-a63517a59c51@kitware.com> Message-ID: <028EF5D6-ABF8-4189-A92D-866BC3352585@gmail.com> > On Nov 16, 2016, at 2:32 PM, Nikita wrote: > > Indeed, specifying '-line-filter=[]' doesn't cause any troubles. > Should I file a bug about this? > > Regards, > Nikita > FWIW, I brought up the same issue a few weeks ago: http://stackoverflow.com/questions/40433573/how-can-i-specify-additional-arguments-for-use-with-cmake-cxx-clang-tidy-variabl http://public.kitware.com/pipermail/cmake/2016-November/064501.html I think this is a bug, but wasn?t sure how to classify it. -Mike From nikita.kakuev at gmail.com Thu Nov 17 02:24:29 2016 From: nikita.kakuev at gmail.com (Nikita) Date: Thu, 17 Nov 2016 10:24:29 +0300 Subject: [CMake] CXX_CLANG_TIDY doesn't handle multiple arguments correctly In-Reply-To: <028EF5D6-ABF8-4189-A92D-866BC3352585@gmail.com> References: <2cbfc281-8c25-c158-4411-a63517a59c51@kitware.com> <028EF5D6-ABF8-4189-A92D-866BC3352585@gmail.com> Message-ID: Thanks for the info. I've filed a bug about this issue - https://gitlab.kitware.com/cmake/cmake/issues/16435 Regards, Nikita On Thu, Nov 17, 2016 at 1:37 AM, Michael Ellery wrote: > >> On Nov 16, 2016, at 2:32 PM, Nikita wrote: >> >> Indeed, specifying '-line-filter=[]' doesn't cause any troubles. >> Should I file a bug about this? >> >> Regards, >> Nikita >> > > FWIW, I brought up the same issue a few weeks ago: > > http://stackoverflow.com/questions/40433573/how-can-i-specify-additional-arguments-for-use-with-cmake-cxx-clang-tidy-variabl > > http://public.kitware.com/pipermail/cmake/2016-November/064501.html > > I think this is a bug, but wasn?t sure how to classify it. > > -Mike > > From joachim.pouderoux at kitware.com Thu Nov 17 08:50:29 2016 From: joachim.pouderoux at kitware.com (Joachim Pouderoux) Date: Thu, 17 Nov 2016 09:50:29 -0400 Subject: [CMake] Issue with Fortran/C binding with Intel compilers Message-ID: Hi, I am using something like this in my CMake script: enable_language(Fortran) include(FortranCInterface) FortranCInterface_VERIFY() FortranCInterface_HEADER(${CMAKE_CURRENT_BINARY_DIR}/FortranBinding.h MACRO_NAMESPACE "FC_" SYMBOL_NAMESPACE "FC_") So far, with gfortran/gcc/clang, I never had any issues and the generated FortranBinding.h is correct, defining FC_GLOBAL, FC_GLOBAL_, FC_MODULE and FC_MODULE_ macros. However, I am facing issues with Intel compilers (icc+ifort) (I am using v17.0.0), VERIFY macro claims that it is OK but then, the FortranBinding.h header is empty (only the #ifndef,#define,#endif stuff), no macro definition. Any idea? Thanks! Best, *Joachim Pouderoux*, PhD *Technical Expert - Scientific Computing Team* *Kitware SAS * -------------- next part -------------- An HTML attachment was scrubbed... URL: From elizabeth.fischer at columbia.edu Thu Nov 17 09:48:36 2016 From: elizabeth.fischer at columbia.edu (Elizabeth A. Fischer) Date: Thu, 17 Nov 2016 09:48:36 -0500 Subject: [CMake] Issue with Fortran/C binding with Intel compilers In-Reply-To: References: Message-ID: Can you use the Fortran/C interop that is now an ISO standard for Fortran 2003 and beyond? That should eliminate the issues you're facing here. https://gcc.gnu.org/onlinedocs/gfortran/Interoperability-with-C.html On Thu, Nov 17, 2016 at 8:50 AM, Joachim Pouderoux < joachim.pouderoux at kitware.com> wrote: > Hi, > > I am using something like this in my CMake script: > enable_language(Fortran) > include(FortranCInterface) > FortranCInterface_VERIFY() > FortranCInterface_HEADER(${CMAKE_CURRENT_BINARY_DIR}/FortranBinding.h > MACRO_NAMESPACE "FC_" > SYMBOL_NAMESPACE "FC_") > > So far, with gfortran/gcc/clang, I never had any issues and the generated > FortranBinding.h is correct, defining FC_GLOBAL, FC_GLOBAL_, FC_MODULE and > FC_MODULE_ macros. > However, I am facing issues with Intel compilers (icc+ifort) (I am using > v17.0.0), VERIFY macro claims that it is OK but then, the FortranBinding.h > header is empty (only the #ifndef,#define,#endif stuff), no macro > definition. > Any idea? > > Thanks! > Best, > > *Joachim Pouderoux*, PhD > > *Technical Expert - Scientific Computing Team* > *Kitware SAS * > > > -- > > 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 joachim.pouderoux at kitware.com Thu Nov 17 10:12:02 2016 From: joachim.pouderoux at kitware.com (Joachim Pouderoux) Date: Thu, 17 Nov 2016 11:12:02 -0400 Subject: [CMake] Issue with Fortran/C binding with Intel compilers In-Reply-To: References: Message-ID: Unfortunately I can't (Fortran95 only), that's why CMake feature is important. Joachim *Joachim Pouderoux*, PhD *Technical Expert - Scientific Computing Team* *Kitware SAS * 2016-11-17 10:48 GMT-04:00 Elizabeth A. Fischer < elizabeth.fischer at columbia.edu>: > Can you use the Fortran/C interop that is now an ISO standard for Fortran > 2003 and beyond? That should eliminate the issues you're facing here. > > https://gcc.gnu.org/onlinedocs/gfortran/Interoperability-with-C.html > > > On Thu, Nov 17, 2016 at 8:50 AM, Joachim Pouderoux < > joachim.pouderoux at kitware.com> wrote: > >> Hi, >> >> I am using something like this in my CMake script: >> enable_language(Fortran) >> include(FortranCInterface) >> FortranCInterface_VERIFY() >> FortranCInterface_HEADER(${CMAKE_CURRENT_BINARY_DIR}/FortranBinding.h >> MACRO_NAMESPACE "FC_" >> SYMBOL_NAMESPACE "FC_") >> >> So far, with gfortran/gcc/clang, I never had any issues and the generated >> FortranBinding.h is correct, defining FC_GLOBAL, FC_GLOBAL_, FC_MODULE >> and FC_MODULE_ macros. >> However, I am facing issues with Intel compilers (icc+ifort) (I am using >> v17.0.0), VERIFY macro claims that it is OK but then, the >> FortranBinding.h header is empty (only the #ifndef,#define,#endif >> stuff), no macro definition. >> Any idea? >> >> Thanks! >> Best, >> >> *Joachim Pouderoux*, PhD >> >> *Technical Expert - Scientific Computing Team* >> *Kitware SAS * >> >> >> -- >> >> 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 damian.campeanu at gmail.com Thu Nov 17 11:15:44 2016 From: damian.campeanu at gmail.com (Damian) Date: Thu, 17 Nov 2016 11:15:44 -0500 Subject: [CMake] CMake Project Generation Speedup Message-ID: Hi all, We are still in the process of switching our large Make-based build to CMake. One of the issues we're running into is the time it takes to reparse and regenerate the CMake project (whether ninja, VS, or make) after touching any CMake file. To give you an idea, we have about 1000 targets and that takes a good 2 min for CMake to rerun. Are there any plans to speed this up? Maybe parallelize it in some way or do a better job regenerating only what needs regenerating? Is there anything we can do on our side to reduce our regeneration times? For example, if using a VS generator, each directory in the source that has a CMakeLists.txt gets a .vcproj and .sln generated. Ideally, if I touch one of those CMakeLists.txt, only that .sln/.vcproj would get regenerated. Thanks for any help. -------------- next part -------------- An HTML attachment was scrubbed... URL: From irwin at beluga.phys.uvic.ca Thu Nov 17 14:21:26 2016 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Thu, 17 Nov 2016 11:21:26 -0800 (PST) Subject: [CMake] Issue with Fortran/C binding with Intel compilers In-Reply-To: References: Message-ID: On 2016-11-17 11:12-0400 Joachim Pouderoux wrote: > Unfortunately I can't (Fortran95 only), that's why CMake feature is > important. Hi Joachim: I have helped convert two projects (PLplot and the ephcom subproject of timeephem) recently to use the iso_c_binding module provided by Fortran 2003, and that approach (at least for providing a Fortran binding to a C library since we have had no need for a C binding to a Fortran library) is absolutely great and works fine with fairly recent versions of the Intel compiler, the gfortran compiler, and likely most importantly from our point of view, the NAG compiler (which advertises itself as being the Fortran compiler that is most demanding concerning compliance with Fortran standards). So my advice is to go ahead and at least experimentally provide the option of using the iso_c_binding module to future-proof your work, and once that new interfacing works I would push (assuming Fortran95 only is a committee decision) to make an exception for at least the iso_c_binding module so you don't have to maintain some home-brew C/fortran interface forever. >From my recent very positive experience with the iso_c_binding module, the only reason not to go with that module for C/Fortran interfacing needs is if if it doesn't work for those needs (which is not my experience for a Fortran binding to a C API in the PLplot case with a large variety of types of C calls including callbacks) or if there is a Fortran compiler out there that does not support it. I haven't found such a compiler yet, but my search has only involved the 3 compilers referred to above so obviously has not been exhaustive. Is there some Fortran compiler you are aware of (aside from really old versions of any of them) that does not provide a working iso_c_binding module? And if such a beast exists that does not even support this important part of Fortran 2003, do you want to cater to this beast indefinitely? After all, 2003 is quite a few years ago so if a compiler doesn't support that, it is almost by definition unsupported. 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 joachim.pouderoux at kitware.com Thu Nov 17 14:31:41 2016 From: joachim.pouderoux at kitware.com (Joachim Pouderoux) Date: Thu, 17 Nov 2016 15:31:41 -0400 Subject: [CMake] Issue with Fortran/C binding with Intel compilers In-Reply-To: References: Message-ID: Alan, Thanks for the advice, I think you are absolutely right, we should update to Fortran2003 to allow use of iso_c_binding module. Anyway I have actually been able to make CMake FortranCInterface work using a more recent version of CMake. Best, Joachim *Joachim Pouderoux*, PhD *Technical Expert - Scientific Computing Team* *Kitware SAS * 2016-11-17 15:21 GMT-04:00 Alan W. Irwin : > On 2016-11-17 11:12-0400 Joachim Pouderoux wrote: > > Unfortunately I can't (Fortran95 only), that's why CMake feature is >> important. >> > > Hi Joachim: > > I have helped convert two projects (PLplot and the ephcom subproject > of timeephem) recently to use the iso_c_binding module provided by > Fortran 2003, and that approach (at least for providing a Fortran > binding to a C library since we have had no need for a C binding to a > Fortran library) is absolutely great and works fine with fairly recent > versions of the Intel compiler, the gfortran compiler, and likely most > importantly from our point of view, the NAG compiler (which advertises > itself as being the Fortran compiler that is most demanding concerning > compliance with Fortran standards). > > So my advice is to go ahead and at least experimentally provide the > option of using the iso_c_binding module to future-proof your work, > and once that new interfacing works I would push (assuming Fortran95 > only is a committee decision) to make an exception for at least the > iso_c_binding module so you don't have to maintain some home-brew > C/fortran interface forever. > > From my recent very positive experience with the iso_c_binding module, > the only reason not to go with that module for C/Fortran interfacing > needs is if if it doesn't work for those needs (which is not my > experience for a Fortran binding to a C API in the PLplot case with a > large variety of types of C calls including callbacks) or if there is > a Fortran compiler out there that does not support it. I haven't > found such a compiler yet, but my search has only involved the 3 > compilers referred to above so obviously has not been exhaustive. Is > there some Fortran compiler you are aware of (aside from really old > versions of any of them) that does not provide a working iso_c_binding > module? And if such a beast exists that does not even support this > important part of Fortran 2003, do you want to cater to this beast > indefinitely? After all, 2003 is quite a few years ago so if a compiler > doesn't support that, it is almost by definition unsupported. > > 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 > __________________________ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike.jackson at bluequartz.net Thu Nov 17 15:02:04 2016 From: mike.jackson at bluequartz.net (Michael Jackson) Date: Thu, 17 Nov 2016 15:02:04 -0500 Subject: [CMake] Issue with Fortran/C binding with Intel compilers In-Reply-To: References: Message-ID: <582E0CBC.2080005@bluequartz.net> Just to add my 2 cents to this. This past year a collaborator of mine updated his F95 code to F2003 and the ISO_C_BINDING syntax and this made the interaction between our C/C++ codes and their Fortran codes extremely easy. No more macros to try to figure out. It oddly, just seems to work. Well worth our time investment. -- Mike Jackson [mike.jackson at bluequartz.net] Joachim Pouderoux wrote: > Alan, > > Thanks for the advice, I think you are absolutely right, we should update > to Fortran2003 to allow use of iso_c_binding module. > Anyway I have actually been able to make CMake FortranCInterface work using > a more recent version of CMake. > > Best, > Joachim > > > *Joachim Pouderoux*, PhD > > /Technical Expert - Scientific Computing Team/ > *Kitware SAS * > > > 2016-11-17 15:21 GMT-04:00 Alan W. Irwin >: > > On 2016-11-17 11:12-0400 Joachim Pouderoux wrote: > > Unfortunately I can't (Fortran95 only), that's why CMake feature is > important. > > > Hi Joachim: > > I have helped convert two projects (PLplot and the ephcom subproject > of timeephem) recently to use the iso_c_binding module provided by > Fortran 2003, and that approach (at least for providing a Fortran > binding to a C library since we have had no need for a C binding to a > Fortran library) is absolutely great and works fine with fairly recent > versions of the Intel compiler, the gfortran compiler, and likely most > importantly from our point of view, the NAG compiler (which advertises > itself as being the Fortran compiler that is most demanding concerning > compliance with Fortran standards). > > So my advice is to go ahead and at least experimentally provide the > option of using the iso_c_binding module to future-proof your work, > and once that new interfacing works I would push (assuming Fortran95 > only is a committee decision) to make an exception for at least the > iso_c_binding module so you don't have to maintain some home-brew > C/fortran interface forever. > > From my recent very positive experience with the iso_c_binding module, > the only reason not to go with that module for C/Fortran interfacing > needs is if if it doesn't work for those needs (which is not my > experience for a Fortran binding to a C API in the PLplot case with a > large variety of types of C calls including callbacks) or if there is > a Fortran compiler out there that does not support it. I haven't > found such a compiler yet, but my search has only involved the 3 > compilers referred to above so obviously has not been exhaustive. Is > there some Fortran compiler you are aware of (aside from really old > versions of any of them) that does not provide a working iso_c_binding > module? And if such a beast exists that does not even support this > important part of Fortran 2003, do you want to cater to this beast > indefinitely? After all, 2003 is quite a few years ago so if a compiler > doesn't support that, it is almost by definition unsupported. > > 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 b.lindahl at gmail.com Fri Nov 18 03:54:21 2016 From: b.lindahl at gmail.com (b.lindahl) Date: Fri, 18 Nov 2016 01:54:21 -0700 (MST) Subject: [CMake] Is search order for multiple HINTS/PATHS well defined? Message-ID: <1479459261551-7594623.post@n2.nabble.com> Reading the documentation I interpret it that I should write multiple find-commands in order to search multiple paths from most to less specific places. To keep CMake files as short as possible I'd like to list the paths to HINTS/PATH in a well defined order directly. I have to list multiple paths though to support different placements for different build configuration I have to support. So the question is, is the order of the paths given to HINTS/PATHS well defined? i.e. will be searched before before for libname in this example or is it not known? find_library(LIBRARY_RELEASE libname HINTS ) -- View this message in context: http://cmake.3232098.n2.nabble.com/Is-search-order-for-multiple-HINTS-PATHS-well-defined-tp7594623.html Sent from the CMake mailing list archive at Nabble.com. From amiblit at gmail.com Fri Nov 18 05:26:07 2016 From: amiblit at gmail.com (Davide Calaminici) Date: Fri, 18 Nov 2016 11:26:07 +0100 Subject: [CMake] Error bootstrapping cmake Message-ID: Hello everyone, i'm trying to port the latest cmake version (3.7.0) to AmigaOS4. I've setup the CC and CXX variable pointing to my gnu compilers. Btw i receive this error as you can see in the bootstrap log file: ________________________________________________________________ Try: AmigaOS:SDK/SDK/gcc/bin/gcc Line: AmigaOS:SDK/SDK/gcc/bin/gcc cmake_bootstrap_1586378720_test.c -o cmake_bootstrap_1586378720_test ---------- file ----------------------- #ifdef __cplusplus # error "The CMAKE_C_COMPILER is set to a C++ compiler" #endif #include #if defined(__CLASSIC_C__) int main(argc, argv) int argc; char* argv[]; #else int main(int argc, char* argv[]) #endif { printf("%d%c", (argv != 0), (char)0x0a); return argc-1; } ------------------------------------------ gcc: fatal error: input file 'cmake_bootstrap_1586378720_test' is the same as output file compilation terminated. Test failed to compile ________________________________________________________________________ Any hint on this? Thank you very much KR Davide -------------- next part -------------- An HTML attachment was scrubbed... URL: From ycollette.nospam at free.fr Fri Nov 18 07:35:26 2016 From: ycollette.nospam at free.fr (ycollette.nospam at free.fr) Date: Fri, 18 Nov 2016 13:35:26 +0100 (CET) Subject: [CMake] Using cpack on an install directory In-Reply-To: <395732275.93554130.1479472371605.JavaMail.root@zimbra35-e6.priv.proxad.net> Message-ID: <237434658.93559512.1479472526754.JavaMail.root@zimbra35-e6.priv.proxad.net> Hello, I would like to know if it's possible to use cpack on an install directory (without CMakeLists.txt file). I've got a "complicated" build: - one build in 64 bits - one build in 32 bits - one with license check - one without Every thing is installed in an install directory (64 bits files went to bin/x64 and 32 bits files into bin/x32). I wante to use cpack by configuring a CPackConfig.cmake file but it's no clear which variable I must fill to be able to pack my install directory). For example: SET(CPACK_INSTALL_CMAKE_PROJECTS "/Users/jenkins/workspace/MyBuild/build;MyProject;ALL;/") I don't think this variable is required if I use cpack on a non cmake directory ... Best regards, YC From nicholas.ohs at hest.ethz.ch Fri Nov 18 07:38:52 2016 From: nicholas.ohs at hest.ethz.ch (Ohs Nicholas) Date: Fri, 18 Nov 2016 12:38:52 +0000 Subject: [CMake] FindHDF5 works on Linux, fails on Windows Message-ID: <51DBD51170BABC488977835C84BD0C31053502CD@MBX215.d.ethz.ch> Hello, When I use FindHDF5 to setup my project it works perfect on Arch-Linux to produce make scripts. However, when I generate Visual Studio 2015 64bit solutions, I get an error during compile, as Visual Studio is trying to link against hdf5_cpp.dll directly throwing a LNK1107 error. Instead of linking directly against the *.dll I think on windows it should link against the corresponding *.lib. Is this a bug in FindHDF5? Can anybody reproduce the issue? Info about the System: - Windows 10 64bit - Visual Studio 2015 64bit project - CMake 3.7.0 - HDF5 1.10.0 Here what I do: Create build folder, call: "cmake -G "Visual Studio 14 2105 Win64" .." With part of the output being "Found HDF5: C:/Program Files/HDF_Group/HDF5/1.10.0/bin/hdf5_cpp.dll (found version "1.10.0") found components: CXX" Here is the CMakeLists.txt cmake_minimum_required(VERSION 3.6 FATAL_ERROR) project("justTesting") find_package(HDF5 COMPONENTS CXX REQUIRED) include_directories(${HDF5_INCLUDE_DIRS}) add_executable(hdf5_test test.cpp) target_link_libraries(hdf5_test ${HDF5_CXX_LIBRARIES}) and here the test.cpp #define H5_BUILT_AS_DYNAMIC_LIB #include int main() { H5::H5File file = H5::H5File("test.h5", H5F_ACC_EXCL); file.close(); } Then I open the solution, click on ALL_BUILD and build it. The output is in short: LNK1107 Invalid or corrupt file: cannot read at 0x380, File: hdf5_cpp.dll The entire log: 1>------ Build started: Project: ZERO_CHECK, Configuration: Debug x64 ------ 1> Checking Build System 1> CMake does not need to re-run because C:/=======================/test_hdf5_cmake/build/CMakeFiles/generate.stamp is up-to-date. 2>------ Build started: Project: hdf5_test, Configuration: Debug x64 ------ 2> Building Custom Rule C:/=======================/test_hdf5_cmake/CMakeLists.txt 2> CMake does not need to re-run because C:\ =======================\test_hdf5_cmake\build\CMakeFiles\generate.stamp is up-to-date. 2> test.cpp 2>c:\program files\hdf_group\hdf5\1.10.0\include\H5Exception.h(93): warning C4251: 'H5::Exception::detail_message': class 'std::basic_string,std::allocator>' needs to have dll-interface to be used by clients of class 'H5::Exception' 2> C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include\xstring(2633): note: see declaration of 'std::basic_string,std::allocator>' 2>c:\program files\hdf_group\hdf5\1.10.0\include\H5Exception.h(94): warning C4251: 'H5::Exception::func_name': class 'std::basic_string,std::allocator>' needs to have dll-interface to be used by clients of class 'H5::Exception' 2> C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include\xstring(2633): note: see declaration of 'std::basic_string,std::allocator>' 2>C:\Program Files\HDF_Group\HDF5\1.10.0\bin\hdf5_cpp.dll : fatal error LNK1107: invalid or corrupt file: cannot read at 0x380 3>------ Build started: Project: ALL_BUILD, Configuration: Debug x64 ------ 3> Building Custom Rule C:/=======================/test_hdf5_cmake/CMakeLists.txt 3> CMake does not need to re-run because C:\=======================\test_hdf5_cmake\build\CMakeFiles\generate.stamp is up-to-date. ========== Build: 2 succeeded, 1 failed, 0 up-to-date, 0 skipped ========== So my question again from above: - Can anybody reproduce the issue? - Is this a bug in FindHDF5? Cheers Nicholas -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric.noulard at gmail.com Fri Nov 18 08:10:41 2016 From: eric.noulard at gmail.com (Eric Noulard) Date: Fri, 18 Nov 2016 14:10:41 +0100 Subject: [CMake] Using cpack on an install directory In-Reply-To: <237434658.93559512.1479472526754.JavaMail.root@zimbra35-e6.priv.proxad.net> References: <395732275.93554130.1479472371605.JavaMail.root@zimbra35-e6.priv.proxad.net> <237434658.93559512.1479472526754.JavaMail.root@zimbra35-e6.priv.proxad.net> Message-ID: 2016-11-18 13:35 GMT+01:00 : > Hello, > > I would like to know if it's possible to use cpack on an install directory > (without CMakeLists.txt file). > I've got a "complicated" build: > - one build in 64 bits > - one build in 32 bits > - one with license check > - one without > > Every thing is installed in an install directory (64 bits files went to > bin/x64 and 32 bits files into bin/x32). > I wante to use cpack by configuring a CPackConfig.cmake file but it's no > clear which variable I must fill to be able to pack my install directory). > > For example: SET(CPACK_INSTALL_CMAKE_PROJECTS "/Users/jenkins/workspace/ > MyBuild/build;MyProject;ALL;/") > I don't think this variable is required if I use cpack on a non cmake > directory ... > Yep you are right. When you barely want to package a (set of) directory I think you should try to set: CPACK_INSTALLED_DIRECTORIES which should contain (list of) pairs of and . The can be '.' to be installed in the toplevel directory of installation. there is almost no documentation about this but this is used for "package_source" by cpack.itself. see the any " CPackSourceConfig.cmake" generated for a CMakeified project using CPack. -- Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From ycollette.nospam at free.fr Fri Nov 18 08:45:51 2016 From: ycollette.nospam at free.fr (ycollette.nospam at free.fr) Date: Fri, 18 Nov 2016 14:45:51 +0100 (CET) Subject: [CMake] Using cpack on an install directory In-Reply-To: Message-ID: <1652501428.93740850.1479476751452.JavaMail.root@zimbra35-e6.priv.proxad.net> Thanks a lot, I will try this. YC ----- Mail original ----- De: "Eric Noulard" ?: "Yann COLLETTE" Cc: "cmake" Envoy?: Vendredi 18 Novembre 2016 14:10:41 Objet: Re: [CMake] Using cpack on an install directory 2016-11-18 13:35 GMT+01:00 < ycollette.nospam at free.fr > : Hello, I would like to know if it's possible to use cpack on an install directory (without CMakeLists.txt file). I've got a "complicated" build: - one build in 64 bits - one build in 32 bits - one with license check - one without Every thing is installed in an install directory (64 bits files went to bin/x64 and 32 bits files into bin/x32). I wante to use cpack by configuring a CPackConfig.cmake file but it's no clear which variable I must fill to be able to pack my install directory). For example: SET(CPACK_INSTALL_CMAKE_PROJECTS "/Users/jenkins/workspace/MyBuild/build;MyProject;ALL;/") I don't think this variable is required if I use cpack on a non cmake directory ... Yep you are right. When you barely want to package a (set of) directory I think you should try to set: CPACK_INSTALLED_DIRECTORIES which should contain (list of) pairs of and . The can be '.' to be installed in the toplevel directory of installation. there is almost no documentation about this but this is used for "package_source" by cpack.itself. see the any " CPackSourceConfig.cmake" generated for a CMakeified project using CPack. -- Eric From pwburge at sandia.gov Fri Nov 18 12:34:28 2016 From: pwburge at sandia.gov (Burgess, Wade) Date: Fri, 18 Nov 2016 17:34:28 +0000 Subject: [CMake] Problem with ACME_Climate project on my.cdash.org In-Reply-To: References: Message-ID: To whom it may concern, Firstly, if this is not the way I should seek assistance from Kitware, please help me learn the correct way to do so. Secondly, the ACME_Climate project on my.cdash.org is experiencing a problem with the graphical reflection of a machine that reported. See below. The second row, melvin, reported to the dashboard 11 hours ago, but three of the cells in the row (the Test columns of Not Run, Fail, & Pass? are not reflected; they are white instead of red, yellow, or green. Please help us resolve this problem. Thanks, Wade Burgess [cid:image001.png at 01D24187.5701ECA0] -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 244167 bytes Desc: image001.png URL: From eike at sf-mail.de Fri Nov 18 15:07:00 2016 From: eike at sf-mail.de (Rolf Eike Beer) Date: Fri, 18 Nov 2016 21:07 +0100 Subject: [CMake] Problem with ACME_Climate project on my.cdash.org In-Reply-To: References: Message-ID: <4458753.R7T6L72sAB@daneel.sf-tec.de> Am Freitag, 18. November 2016, 17:34:28 schrieb Burgess, Wade: > To whom it may concern, > > Firstly, if this is not the way I should seek assistance from Kitware, > please help me learn the correct way to do so. > Secondly, the ACME_Climate project on my.cdash.org is experiencing a problem > with the graphical reflection of a machine that reported. See below. The > second row, melvin, reported to the dashboard 11 hours ago, but three of > the cells in the row (the Test columns of Not Run, Fail, & Pass? are not > reflected; they are white instead of red, yellow, or green. > Please help us resolve this problem. This often happens if the submission was incomplete, e.g. if there was timeout submitting the last 3 xml files. Eike -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part. URL: From amiblit at gmail.com Sat Nov 19 13:04:18 2016 From: amiblit at gmail.com (Davide Calaminici) Date: Sat, 19 Nov 2016 19:04:18 +0100 Subject: [CMake] Bootstrap error porting cmake to AmigaOS Message-ID: Hello everyone, i'm trying to port the latest cmake version (3.7.0) to AmigaOS4. I've setup the CC and CXX variable pointing to my gnu compilers. Btw i receive this error as you can see in the bootstrap log file: ________________________________________________________________ Try: AmigaOS:SDK/SDK/gcc/bin/gcc Line: AmigaOS:SDK/SDK/gcc/bin/gcc cmake_bootstrap_1586378720_test.c -o cmake_bootstrap_1586378720_test ---------- file ----------------------- #ifdef __cplusplus # error "The CMAKE_C_COMPILER is set to a C++ compiler" #endif #include #if defined(__CLASSIC_C__) int main(argc, argv) int argc; char* argv[]; #else int main(int argc, char* argv[]) #endif { printf("%d%c", (argv != 0), (char)0x0a); return argc-1; } ------------------------------------------ gcc: fatal error: input file 'cmake_bootstrap_1586378720_test' is the same as output file compilation terminated. Test failed to compile ________________________________________________________________________ Any hint on this? Thank you very much KR Davide -------------- next part -------------- An HTML attachment was scrubbed... URL: From cmake at deinzer.biz Sat Nov 19 15:56:42 2016 From: cmake at deinzer.biz (Frank) Date: Sat, 19 Nov 2016 21:56:42 +0100 Subject: [CMake] CMake and Code Signing in XCode 8 for iOS projects Message-ID: Hi all, CMake was able to configure automatic code signing for XCode <=7 and iOS projects with a target property setting like set_target_properties(app PROPERTIES XCODE_ATTRIBUTE_CODE_SIGN_IDENTITY "PROPER IDENTIFIER") XCode 8 changed the signing process. It now is required that the option "Automatically manage signing" in the project settings "General tab -> Signing" is checked. If I check this options manually for a cmake generated project, signing works well. But I did not find a way to enable this option from the cmake project by default. Can this be done for cmake (>=3.7.0)? Thanks for any help, Frank From mike.jackson at bluequartz.net Mon Nov 21 08:04:53 2016 From: mike.jackson at bluequartz.net (Michael Jackson) Date: Mon, 21 Nov 2016 08:04:53 -0500 Subject: [CMake] List all "include_directories" for a given project or target Message-ID: <5832F0F5.9020504@bluequartz.net> Is there a command or variable or a code snippet from someone that essentially has a list of all the "include_directories" that have been used/created in a given project? Or can I get a list of all the targets(created and imported) and then get the list of "include_directories" from those targets? I am messing about with the "VSCode.app" on OS X and their code completion extension. For this to work one needs to get a list of all the include directories possible so that clang knows where to look for the headers. Wasn't there a cmake command that would dump all the compile commands to a file or something? Thanks -- Michael A. Jackson BlueQuartz Software, LLC [e]: mike.jackson at bluequartz.net From mellery451 at gmail.com Mon Nov 21 11:00:49 2016 From: mellery451 at gmail.com (Michael Ellery) Date: Mon, 21 Nov 2016 08:00:49 -0800 Subject: [CMake] List all "include_directories" for a given project or target In-Reply-To: <5832F0F5.9020504@bluequartz.net> References: <5832F0F5.9020504@bluequartz.net> Message-ID: <6E809EA2-DD50-429A-B860-B12CAE34357A@gmail.com> > On Nov 21, 2016, at 5:04 AM, Michael Jackson wrote: > > Is there a command or variable or a code snippet from someone that essentially has a list of all the "include_directories" that have been used/created in a given project? Or can I get a list of all the targets(created and imported) and then get the list of "include_directories" from those targets? > > I am messing about with the "VSCode.app" on OS X and their code completion extension. For this to work one needs to get a list of all the include directories possible so that clang knows where to look for the headers. > > Wasn't there a cmake command that would dump all the compile commands to a file or something? > > Thanks > > The clang compilation database might give you what you need - it?s what several autocompletion tools already use. To generate this, just pass -DCMAKE_EXPORT_COMPILE_COMMANDS=ON when running cmake. You would have to extract the -I options from the command entries, I guess. -Mike From parag at ionicsecurity.com Mon Nov 21 10:01:44 2016 From: parag at ionicsecurity.com (Parag Chandra) Date: Mon, 21 Nov 2016 15:01:44 +0000 Subject: [CMake] [EXTERNAL]: CMake and Code Signing in XCode 8 for iOS projects In-Reply-To: References: Message-ID: Hi Frank, I got curious about this myself, and it looks like the checkbox alters the following in the .pbxproj: TargetAttributes = { 2BA1B86D1DE33AA300073B96 = { CreatedOnToolsVersion = 8.1; ProvisioningStyle = Manual; }; }; With it checked, ?ProvisioningStyle = Automatic?. To the best of my knowledge, XCODE_ATTRIBUTE_* can only be used for items that show up with a corresponding ?Declaration? field when viewed in Xcode?s Quick Help pane, e.g. ?ARCHS? can be set via XCODE_ATTRIBUTE_ARCHS. I had a similar problem targeting NaCl with the Visual Studio generator ? there was a property in the .vcxproj file that I couldn?t access directly from CMake. I ended up writing a simple Python script to massage the generated vcxproj in order to give me the desired end result. Not a great solution, but it?s worked out pretty well for me because in practice I don?t run CMake directly on the cmd line. I drive it from a Gradle script which feeds it all the necessary cmd line args I need, so I just tacked on this bit of Python to the end of my Gradle script. Hope this helps. Parag Chandra Technical Lead, Mobile Team Mobile: +1.919.824.1410 Ionic Security Inc. 1170 Peachtree St. NE STE 400, Atlanta, GA 30309 On 11/19/16, 3:56 PM, "CMake on behalf of Frank" wrote: Hi all, CMake was able to configure automatic code signing for XCode <=7 and iOS projects with a target property setting like set_target_properties(app PROPERTIES XCODE_ATTRIBUTE_CODE_SIGN_IDENTITY "PROPER IDENTIFIER") XCode 8 changed the signing process. It now is required that the option "Automatically manage signing" in the project settings "General tab -> Signing" is checked. If I check this options manually for a cmake generated project, signing works well. But I did not find a way to enable this option from the cmake project by default. Can this be done for cmake (>=3.7.0)? Thanks for any help, Frank -- 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 p.jansen at computer.org Mon Nov 21 12:33:51 2016 From: p.jansen at computer.org (Peter Jansen) Date: Mon, 21 Nov 2016 10:33:51 -0700 (MST) Subject: [CMake] Errors with cmake for VS2105 (update 3) + clang + nmake Message-ID: <1479749631787-7594637.post@n2.nabble.com> I am trying to use cmake to generate a "Nmake Makefiles" project in a Windows 10 VS2015 (update 3) environment using the VS2015 clang compiler (which is the MS Clang/C2 compiler, version 3.8.0), but in doing so receive these errors : C:\Qsync\Source\Hello_World_C\build\clang_x64_nmake>cmake -G "NMake Makefiles" ..\.. -DCMAKE_C_COMPILER:FILEPATH="C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\ClangC2\bin\amd64\clang.exe" -DCMAKE_CXX_COMPILER:FILEPATH="C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\ClangC2\bin\amd64\clang.exe" -- The C compiler identification is Clang 3.8.0 -- The CXX compiler identification is Clang 3.8.0 -- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio 14.0/VC/ClangC2/bin/amd64/clang.exe -- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio 14.0/VC/ClangC2/bin/amd64/clang.exe -- b roken CMake Error at C:/Program Files/CMake/share/cmake-3.7/Modules/CMakeTestCCompiler.cmake:51 (message): The C compiler "C:/Program Files (x86)/Microsoft Visual Studio 14.0/VC/ClangC2/bin/amd64/clang.exe" is not able to compile a simple test program. It fails with the following output: Change Dir: C:/Qsync/Source/Hello_World_C/build/clang_x64_nmake/CMakeFiles/CMakeTmp Run Build Command:"nmake" "/NOLOGO" "cmTC_6a3b7\fast" "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\BIN\amd64\nmake.exe" -f CMakeFiles\cmTC_6a3b7.dir\build.make /nologo -L CMakeFiles\cmTC_6a3b7.dir\build Building C object CMakeFiles/cmTC_6a3b7.dir/testCCompiler.c.obj C:\PROGRA~2\MICROS~1.0\VC\ClangC2\bin\amd64\clang.exe @C:\Users\Peter\AppData\Local\Temp\nm1768.tmp clang.exe: error: no such file or directory: '/nologo' clang.exe: error: no such file or directory: '/DWIN32' clang.exe: error: no such file or directory: '/D_WINDOWS' clang.exe: error: no such file or directory: '/W3' clang.exe: error: no such file or directory: '/D_DEBUG' clang.exe: error: no such file or directory: '/MDd' clang.exe: error: no such file or directory: '/Zi' clang.exe: error: no such file or directory: '/Ob0' clang.exe: error: no such file or directory: '/Od' clang.exe: error: no such file or directory: '/RTC1' clang.exe: error: no such file or directory: '/FoCMakeFiles\cmTC_6a3b7.dir\testCCompiler.c.obj' clang.exe: error: no such file or directory: '/FdCMakeFiles\cmTC_6a3b7.dir -c' NMAKE : fatal error U1077: 'C:\PROGRA~2\MICROS~1.0\VC\ClangC2\bin\amd64\clang.exe' : return code '0x1' Stop. NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\BIN\amd64\nmake.exe"' : return code '0x2' Stop. CMake will not be able to correctly generate this project. Call Stack (most recent call first): CMakeLists.txt:1 (project) -- Configuring incomplete, errors occurred! See also "C:/Qsync/Source/Hello_World_C/build/clang_x64_nmake/CMakeFiles/CMakeOutput.log". See also "C:/Qsync/Source/Hello_World_C/build/clang_x64_nmake/CMakeFiles/CMakeError.log". I might be doing something wrong, as I am quite new to cmake, although I got the above clang to work for a regular "Visual Studio 15 Win64" generated project (Hello_World.c , i.e. the minimal C program). Or is this a known problem or not even supported combination with nmake ? Any help will be very much appreciated. Peter Jansen -- View this message in context: http://cmake.3232098.n2.nabble.com/Errors-with-cmake-for-VS2105-update-3-clang-nmake-tp7594637.html Sent from the CMake mailing list archive at Nabble.com. From parag at ionicsecurity.com Mon Nov 21 13:02:42 2016 From: parag at ionicsecurity.com (Parag Chandra) Date: Mon, 21 Nov 2016 18:02:42 +0000 Subject: [CMake] [EXTERNAL]: Errors with cmake for VS2105 (update 3) + clang + nmake In-Reply-To: <1479749631787-7594637.post@n2.nabble.com> References: <1479749631787-7594637.post@n2.nabble.com> Message-ID: Hi Peter, Seems like CMake is continuing to pass cmd line args that are only suitable for the default msvc compiler, which clang is treating as invalid paths. You need to override more than just the C_COMPILER. Try the instructions here: http://stackoverflow.com/questions/38171878/how-do-i-tell-cmake-to-use-clang-on-windows Parag Chandra Technical Lead, Mobile Team Mobile: +1.919.824.1410 Ionic Security Inc. 1170 Peachtree St. NE STE 400, Atlanta, GA 30309 On 11/21/16, 12:33 PM, "CMake on behalf of Peter Jansen" wrote: I am trying to use cmake to generate a "Nmake Makefiles" project in a Windows 10 VS2015 (update 3) environment using the VS2015 clang compiler (which is the MS Clang/C2 compiler, version 3.8.0), but in doing so receive these errors : C:\Qsync\Source\Hello_World_C\build\clang_x64_nmake>cmake -G "NMake Makefiles" ..\.. -DCMAKE_C_COMPILER:FILEPATH="C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\ClangC2\bin\amd64\clang.exe" -DCMAKE_CXX_COMPILER:FILEPATH="C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\ClangC2\bin\amd64\clang.exe" -- The C compiler identification is Clang 3.8.0 -- The CXX compiler identification is Clang 3.8.0 -- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio 14.0/VC/ClangC2/bin/amd64/clang.exe -- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio 14.0/VC/ClangC2/bin/amd64/clang.exe -- b roken CMake Error at C:/Program Files/CMake/share/cmake-3.7/Modules/CMakeTestCCompiler.cmake:51 (message): The C compiler "C:/Program Files (x86)/Microsoft Visual Studio 14.0/VC/ClangC2/bin/amd64/clang.exe" is not able to compile a simple test program. It fails with the following output: Change Dir: C:/Qsync/Source/Hello_World_C/build/clang_x64_nmake/CMakeFiles/CMakeTmp Run Build Command:"nmake" "/NOLOGO" "cmTC_6a3b7\fast" "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\BIN\amd64\nmake.exe" -f CMakeFiles\cmTC_6a3b7.dir\build.make /nologo -L CMakeFiles\cmTC_6a3b7.dir\build Building C object CMakeFiles/cmTC_6a3b7.dir/testCCompiler.c.obj C:\PROGRA~2\MICROS~1.0\VC\ClangC2\bin\amd64\clang.exe @C:\Users\Peter\AppData\Local\Temp\nm1768.tmp clang.exe: error: no such file or directory: '/nologo' clang.exe: error: no such file or directory: '/DWIN32' clang.exe: error: no such file or directory: '/D_WINDOWS' clang.exe: error: no such file or directory: '/W3' clang.exe: error: no such file or directory: '/D_DEBUG' clang.exe: error: no such file or directory: '/MDd' clang.exe: error: no such file or directory: '/Zi' clang.exe: error: no such file or directory: '/Ob0' clang.exe: error: no such file or directory: '/Od' clang.exe: error: no such file or directory: '/RTC1' clang.exe: error: no such file or directory: '/FoCMakeFiles\cmTC_6a3b7.dir\testCCompiler.c.obj' clang.exe: error: no such file or directory: '/FdCMakeFiles\cmTC_6a3b7.dir -c' NMAKE : fatal error U1077: 'C:\PROGRA~2\MICROS~1.0\VC\ClangC2\bin\amd64\clang.exe' : return code '0x1' Stop. NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\BIN\amd64\nmake.exe"' : return code '0x2' Stop. CMake will not be able to correctly generate this project. Call Stack (most recent call first): CMakeLists.txt:1 (project) -- Configuring incomplete, errors occurred! See also "C:/Qsync/Source/Hello_World_C/build/clang_x64_nmake/CMakeFiles/CMakeOutput.log". See also "C:/Qsync/Source/Hello_World_C/build/clang_x64_nmake/CMakeFiles/CMakeError.log". I might be doing something wrong, as I am quite new to cmake, although I got the above clang to work for a regular "Visual Studio 15 Win64" generated project (Hello_World.c , i.e. the minimal C program). Or is this a known problem or not even supported combination with nmake ? Any help will be very much appreciated. Peter Jansen -- View this message in context: http://cmake.3232098.n2.nabble.com/Errors-with-cmake-for-VS2105-update-3-clang-nmake-tp7594637.html Sent from the CMake mailing list archive at Nabble.com. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake From rcdailey.lists at gmail.com Tue Nov 22 13:58:05 2016 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Tue, 22 Nov 2016 12:58:05 -0600 Subject: [CMake] VS2017 + CMake integration Message-ID: First of all, I personally find the CMake integration in Visual Studio just absolutely amazing. Granted I am not doing any cross-compiling with Android yet, but for just building on Windows it's phenomenal. I noticed that Visual Studio 2017 RC is actually packaging its own version of CMake: E:\PROGRAM FILES (X86)\MICROSOFT VISUAL STUDIO\2017\PROFESSIONAL\COMMON7\IDE\COMMONEXTENSIONS\MICROSOFT\CMAKE\CMake\bin\cmake.exe Is Microsoft patching the CMake code base to support what they are doing? And if so, are those changes not upstream yet? Personally, I'd rather have the ability to tell Visual Studio to use my external version of CMake that is on PATH, rather than its own. I can understand if that isn't possible right now due to custom changes, but I'm curious to learn more, assuming Kitware has had a partnership with Microsoft for this integration with Visual Studio. Would anyone be able to provide more news here? Is there a way to make VS 2017 use my separate install of CMake? Are the Microsoft-specific patches contributed to upstream (or planned to be)? From cedric.doucet at inria.fr Wed Nov 23 09:55:03 2016 From: cedric.doucet at inria.fr (Cedric Doucet) Date: Wed, 23 Nov 2016 15:55:03 +0100 (CET) Subject: [CMake] Find packages coming from homebrew In-Reply-To: <251100723.2205374.1479912325128.JavaMail.zimbra@inria.fr> Message-ID: <109796284.2209902.1479912903699.JavaMail.zimbra@inria.fr> Hello, I would like to write some FindFoo.cmake files to find packages installed on different systems including Mac. I have noticed that homebrew install packages in a repertory whose name depends on the version of the package. For example, I have installed a scientific library called scotch, and it is now installed here: /usr/local/Cellar/scotch/6.0.4_4 What is the best way to handle such a path in FindScotch.cmake? I have think about these ones: - looking for /usr/local/Cellar/scotch/${SCOTCH_VERSION} where SCOTCH_VERSION has to be provided by users; - force users to install a specific version of Scotch which is hardcoded in SCOTCH_VERSION variable. I think the latter option is better since there is no reason that any version of scotch will be compatible with my own code. Is there a better way? Best regards, C?dric -------------- next part -------------- An HTML attachment was scrubbed... URL: From Harry at codexdigital.com Wed Nov 23 12:40:38 2016 From: Harry at codexdigital.com (Harry Mallon) Date: Wed, 23 Nov 2016 17:40:38 +0000 Subject: [CMake] Find packages coming from homebrew Message-ID: Hi Cedric, You might be interested in "brew --prefix" which gives you the location of the brew install. e.g. for me. % brew --prefix /usr/local Also brew symlinks the current version of all programs into the "brew --prefix" folder. Do "ls -lah /usr/local/bin" and you should see what I mean. I hope some of this is helpful. Harry Harry Mallon CODEX | Software Engineer 60 Poland Street | London | England | W1F 7NT E harry at codexdigital.com | T +44 203 7000 989 Website | Facebook | Twitter [http://codex.online/?action=asset&id=5B21DF7C-EC27-4199-852F-D596F5F28DA9] -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike.jackson at bluequartz.net Wed Nov 23 13:34:17 2016 From: mike.jackson at bluequartz.net (Michael Jackson) Date: Wed, 23 Nov 2016 13:34:17 -0500 Subject: [CMake] Determine which files have changed during a CMake run Message-ID: <5835E129.5010304@bluequartz.net> Is there a way to determine which files in my build directory have changed for a given run of CMake? The use case is that I made what I thought was a small change to my configuration using cmake and when I went to build it was basically a full recompile. During our cmake run we do use configure_file(...) to generate headers and sources some of which basically get included in every source file. I am thinking that I have a dependency on generating those files when I probably do not have to. I use Ninja as my build system if that helps. I could always just hack a local git repo for the build folder, commit everything, run cmake and see what got changed. Anybody have a better idea? Thanks -- Mike Jackson [mike.jackson at bluequartz.net] From craig.scott at crascit.com Wed Nov 23 15:01:29 2016 From: craig.scott at crascit.com (Craig Scott) Date: Thu, 24 Nov 2016 07:01:29 +1100 Subject: [CMake] Determine which files have changed during a CMake run In-Reply-To: <5835E129.5010304@bluequartz.net> References: <5835E129.5010304@bluequartz.net> Message-ID: Does "ninja -d explain" tell you what you need? On Thu, Nov 24, 2016 at 5:34 AM, Michael Jackson < mike.jackson at bluequartz.net> wrote: > Is there a way to determine which files in my build directory have changed > for a given run of CMake? The use case is that I made what I thought was a > small change to my configuration using cmake and when I went to build it > was basically a full recompile. During our cmake run we do use > configure_file(...) to generate headers and sources some of which basically > get included in every source file. I am thinking that I have a dependency > on generating those files when I probably do not have to. > > I use Ninja as my build system if that helps. I could always just hack a > local git repo for the build folder, commit everything, run cmake and see > what got changed. Anybody have a better idea? > > Thanks > > -- > Mike Jackson [mike.jackson at bluequartz.net] > -- > > 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 > -- Craig Scott Melbourne, Australia https://crascit.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From DLRdave at aol.com Wed Nov 23 15:12:09 2016 From: DLRdave at aol.com (David Cole) Date: Wed, 23 Nov 2016 15:12:09 -0500 Subject: [CMake] Determine which files have changed during a CMake run In-Reply-To: <5835E129.5010304@bluequartz.net> References: <5835E129.5010304@bluequartz.net> Message-ID: Using git like that is actually the perfect way to do it if you just want to analyze it manually. I've actually done that with other projects source trees when something seems to appear there even when doing an out of source build... It's a great way to see what's changed (and how) easily. You could also write a CMake script that iterates files in the build directory, and uses IS_NEWER in conjunction with a reference file touched just prior to running CMake if you need to generate a report like this frequently for some reason. HTH, David C. On Wednesday, November 23, 2016, Michael Jackson < mike.jackson at bluequartz.net> wrote: > Is there a way to determine which files in my build directory have changed > for a given run of CMake? The use case is that I made what I thought was a > small change to my configuration using cmake and when I went to build it > was basically a full recompile. During our cmake run we do use > configure_file(...) to generate headers and sources some of which basically > get included in every source file. I am thinking that I have a dependency > on generating those files when I probably do not have to. > > I use Ninja as my build system if that helps. I could always just hack a > local git repo for the build folder, commit everything, run cmake and see > what got changed. Anybody have a better idea? > > Thanks > > -- > Mike Jackson [mike.jackson at bluequartz.net] > -- > > 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 mike.jackson at bluequartz.net Wed Nov 23 15:25:07 2016 From: mike.jackson at bluequartz.net (Michael Jackson) Date: Wed, 23 Nov 2016 15:25:07 -0500 Subject: [CMake] Determine which files have changed during a CMake run In-Reply-To: References: <5835E129.5010304@bluequartz.net> Message-ID: <5835FB23.70206@bluequartz.net> Thanks! This worked for my needs. Ninja said my command line changed. So I used the generated compile_commands.json before and after a cmake run, diff'ed those two files and was able to zero in on the issue. Thanks for the tip. Worked great. Have to store that one away for future use. -- Mike Jackson [mike.jackson at bluequartz.net] Craig Scott wrote: > Does "ninja -d explain" tell you what you need? > > On Thu, Nov 24, 2016 at 5:34 AM, Michael Jackson > > wrote: > > Is there a way to determine which files in my build directory have > changed for a given run of CMake? The use case is that I made what I > thought was a small change to my configuration using cmake and when > I went to build it was basically a full recompile. During our cmake > run we do use configure_file(...) to generate headers and sources > some of which basically get included in every source file. I am > thinking that I have a dependency on generating those files when I > probably do not have to. > > I use Ninja as my build system if that helps. I could always just > hack a local git repo for the build folder, commit everything, run > cmake and see what got changed. Anybody have a better idea? > > Thanks > > -- > Mike Jackson [mike.jackson at bluequartz.net > ] > -- > > 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 From mluparu at microsoft.com Wed Nov 23 14:57:19 2016 From: mluparu at microsoft.com (Marian Luparu) Date: Wed, 23 Nov 2016 19:57:19 +0000 Subject: [CMake] VS2017 + CMake integration In-Reply-To: References: Message-ID: Thanks Robert -- this is great feedback Yes, VS ships with a patched 3.6 CMake that includes both changes to find the VS 2017 installation as well as the CMake-Server functionality needed for the IDE services. We have not yet started upstreaming these changes (got totally sidetracked by getting the VS 2017 RC release out the door) but are absolutely committed to do so. As a first step, we will be rebasing our changes to the 3.7 CMake release and then start contributing these pieces. Once the changes are in PR, at a minimum, you will be able to compile your own version of CMake if you wanted to, to replace the one shipping in VS. But currently, to answer your other question, we have no capability of pointing VS to a different version of CMake. That's primarily because of the thick-coupling between VS and the custom patches we need in CMake to make the end-to-end experience work. Thanks, Marian Luparu Visual C++ PM Lead -----Original Message----- From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Robert Dailey Sent: Tuesday, November 22, 2016 10:58 AM To: CMake Subject: [CMake] VS2017 + CMake integration First of all, I personally find the CMake integration in Visual Studio just absolutely amazing. Granted I am not doing any cross-compiling with Android yet, but for just building on Windows it's phenomenal. I noticed that Visual Studio 2017 RC is actually packaging its own version of CMake: E:\PROGRAM FILES (X86)\MICROSOFT VISUAL STUDIO\2017\PROFESSIONAL\COMMON7\IDE\COMMONEXTENSIONS\MICROSOFT\CMAKE\CMake\bin\cmake.exe Is Microsoft patching the CMake code base to support what they are doing? And if so, are those changes not upstream yet? Personally, I'd rather have the ability to tell Visual Studio to use my external version of CMake that is on PATH, rather than its own. I can understand if that isn't possible right now due to custom changes, but I'm curious to learn more, assuming Kitware has had a partnership with Microsoft for this integration with Visual Studio. Would anyone be able to provide more news here? Is there a way to make VS 2017 use my separate install of CMake? Are the Microsoft-specific patches contributed to upstream (or planned to be)? -- Powered by https://na01.safelinks.protection.outlook.com/?url=www.kitware.com&data=02%7C01%7Cmluparu%40microsoft.com%7C00957bc2ac4847ee794f08d413098464%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636154378985417863&sdata=Plv73v%2B4m3KwGsh6VinIPPgg1qUsCdmDlx%2F9U2urOqA%3D&reserved=0 Please keep messages on-topic and check the CMake FAQ at: https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.cmake.org%2FWiki%2FCMake_FAQ&data=02%7C01%7Cmluparu%40microsoft.com%7C00957bc2ac4847ee794f08d413098464%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636154378985417863&sdata=qBtWeiauHkzD7ISZxtqz3Q72SaDZZwKwdY%2F1voAI2U8%3D&reserved=0 Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcmake.org%2Fcmake%2Fhelp%2Fsupport.html&data=02%7C01%7Cmluparu%40microsoft.com%7C00957bc2ac4847ee794f08d413098464%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636154378985417863&sdata=NZgcc%2BxtLPkIWXjqcIwItZr7KXAe6cqbcQaLpAMMA9Q%3D&reserved=0 CMake Consulting: https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcmake.org%2Fcmake%2Fhelp%2Fconsulting.html&data=02%7C01%7Cmluparu%40microsoft.com%7C00957bc2ac4847ee794f08d413098464%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636154378985417863&sdata=YXiCCEGtOMh3qvpKtXTgiL86czKy8xedQbUOoFaTsXA%3D&reserved=0 CMake Training Courses: https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcmake.org%2Fcmake%2Fhelp%2Ftraining.html&data=02%7C01%7Cmluparu%40microsoft.com%7C00957bc2ac4847ee794f08d413098464%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636154378985417863&sdata=Paz%2Ft%2Bm63qi1AavokeWDNrR69wIUD2Tzjuyp7gUHORk%3D&reserved=0 Visit other Kitware open-source projects at https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.kitware.com%2Fopensource%2Fopensource.html&data=02%7C01%7Cmluparu%40microsoft.com%7C00957bc2ac4847ee794f08d413098464%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636154378985417863&sdata=MkwbFPZ3eC9DrFysQTnnHA6CYFuNLTCt5%2FLdCrxLaXo%3D&reserved=0 Follow this link to subscribe/unsubscribe: https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpublic.kitware.com%2Fmailman%2Flistinfo%2Fcmake&data=02%7C01%7Cmluparu%40microsoft.com%7C00957bc2ac4847ee794f08d413098464%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636154378985417863&sdata=JYhOwViUGadM%2FOGbf3X8cs3fwjCArFZnUz92Q1wK5VY%3D&reserved=0 From rleigh at codelibre.net Wed Nov 23 16:12:27 2016 From: rleigh at codelibre.net (Roger Leigh) Date: Wed, 23 Nov 2016 21:12:27 +0000 Subject: [CMake] Find packages coming from homebrew In-Reply-To: <109796284.2209902.1479912903699.JavaMail.zimbra@inria.fr> References: <109796284.2209902.1479912903699.JavaMail.zimbra@inria.fr> Message-ID: On 23/11/16 14:55, Cedric Doucet wrote: > > Hello, > > I would like to write some FindFoo.cmake files to find packages > installed on different systems including Mac. > I have noticed that homebrew install packages in a repertory whose name > depends on the version of the package. > For example, I have installed a scientific library called scotch, and it > is now installed here: > > /usr/local/Cellar/scotch/6.0.4_4 You should never need to use the Cellar directories directly. It should also be linked under /usr/local/opt/scotch *and* linked directly into /usr/local. When writing a FindFoo.cmake file, you shouldn't need to do anything special to handle this. Just find the headers and libraries as usual. If it's linked into /usr/local (brew link scotch) then it should be picked up without any special action If it's not linked into /usr/local then the user should be able to add /usr/local/opt/scotch (or /usr/local/Cellar/scotch/nnnn) to CMAKE_PREFIX_PATH and it should then be picked up, again with no special casing in your FindFoo script Regards, Roger From zbeekman at gmail.com Wed Nov 23 18:05:08 2016 From: zbeekman at gmail.com (Zaak Beekman) Date: Wed, 23 Nov 2016 23:05:08 +0000 Subject: [CMake] FindMPI Message-ID: Hi, I want to be able to pass FC=mpif90 (or FC=$(which mpif90)) and CC=mpicc etc. OR also be able to pass a compiler and use FindMPI to add link, compile and include flags. I'm encountering an issue when my MPI implementation is not on my PATH, I want CMake to be able to look in an additional location (our build script can download and build MPICH and by default installs it in user space) and also resolve where mpif90 is coming from and look there too. Whats the correct way to pass HINTS or PATHS to FindMPI? i.e., how do I specify additional locations to search? Using `find_package` with HINTS and PATHS means that it doesn't use FindMPI. I also tried setting CMAKE_SYSTEM PREFIX_PATH, but I think that's a cache variable set early, so it's not having an effect. It would be great if FindMPI used the realpath of mpif90 etc when passed as $FC. TIA -------------- next part -------------- An HTML attachment was scrubbed... URL: From tobias.bauer1988 at gmx.de Thu Nov 24 02:51:47 2016 From: tobias.bauer1988 at gmx.de (Zlatan) Date: Thu, 24 Nov 2016 00:51:47 -0700 (MST) Subject: [CMake] Change C_INCLUDES in flags.make In-Reply-To: <1479918816665-7594641.post@n2.nabble.com> References: <1479918816665-7594641.post@n2.nabble.com> Message-ID: <1479973907202-7594650.post@n2.nabble.com> I tried: get_directory_property(cmake_include_directories INCLUDE_DIRECTORIES) set(include_dirs) foreach(it ${cmake_include_directories}) set(include_dirs ${include_dirs} "${it}/") endforeach() set_directory_properties(PROPERTIES INCLUDE_DIRECTORIES "${include_dirs}") #set_property(TARGET ${PROJECT_NAME}.hex PROPERTY INCLUDE_DIRECTORIES ${include_dirs}) message(STATUS "New Dir: ${include_dirs}") but the values in include_dir will not override the values in INCLUDE_DIRECTORIES -- View this message in context: http://cmake.3232098.n2.nabble.com/Change-C-INCLUDES-in-flags-make-tp7594641p7594650.html Sent from the CMake mailing list archive at Nabble.com. From p.jansen at computer.org Thu Nov 24 08:20:55 2016 From: p.jansen at computer.org (Peter Jansen) Date: Thu, 24 Nov 2016 06:20:55 -0700 (MST) Subject: [CMake] [EXTERNAL]: Errors with cmake for VS2105 (update 3) + clang + nmake In-Reply-To: References: <1479749631787-7594637.post@n2.nabble.com> Message-ID: <1479993655162-7594651.post@n2.nabble.com> Hi Parag, Thanks for your feedback. The instructions you are referring to are for this cmake command : cmake -G"Visual Studio 14 2015" -T"LLVM-vs2014" .. But in my case I'd like (1) to use the MS VS 2015 "Nmake Makefiles" as -G option, and (2) the MS VS 2015 (update 3) included "clang" (which is version 3.8.0) compiler, referred to as Clang/C2 (i.e. using the MS VS 2015 linker etc., NOT the Clang/LLVM system) . I have been trying to find information whether an appropriate -T option is available for this, but was unsuccessful at this. Any continued support with this would be appreciated. Thanks, Peter -- View this message in context: http://cmake.3232098.n2.nabble.com/Errors-with-cmake-for-VS2105-update-3-clang-nmake-tp7594637p7594651.html Sent from the CMake mailing list archive at Nabble.com. From roman.wueger at gmx.at Thu Nov 24 13:08:56 2016 From: roman.wueger at gmx.at (=?iso-8859-1?Q?Roman_W=FCger?=) Date: Thu, 24 Nov 2016 19:08:56 +0100 Subject: [CMake] C++11/C++14 doesn't work in check_cxx_source_compiles Message-ID: <01cb01d2467d$d2f7fed0$78e7fc70$@gmx.at> Hello, If I use a small piece of code which uses , then it fails with check_cxx_source_compiles. If I copy the piece of code into a file and run the following on the command line, then it works: clang++ main.cpp -std=c++14 -stdlib=libc++ Here is the piece of code: #include #include int main() { const std::string text = "Roses are #ff0000, other flowers have other colors."; const std::regex pattern("#([a-f0-9]{2})"); std::smatch match; std::regex_search(text, match, pattern); return 0; } I use this code in CMake as a platform check as followed: # C++11 Regular Expression set(CMAKE_REQUIRED_FLAGS "${CMAKE_CXX_FLAGS}") check_cxx_source_compiles( "#include #include int main() { const std::string text = \"Roses are #ff0000, other flowers have other colors.\"; const std::regex pattern(\"#([a-f0-9]{2})\"); std::smatch match; std::regex_search(text, match, pattern); return 0; }" HAVE_CXX11_REGULAR_EXPRESSIONS ) set(CMAKE_REQUIRED_FLAGS "") CMakeFiles/CMakeError.log shows: Undefined symbols for architecture x86_64: "std::__1::basic_string, std::__1::allocator >::compare(char const*) const", referenced from: std::__1::basic_regex >::__start_matching_list(bool) in src.o "std::__1::__vector_base_common::__throw_length_error() const", referenced from: std::__1::vector, std::__1::allocator > >::assign(unsigned long, std::__1::sub_match const&) in src.o std::__1::vector, std::__1::allocator > >::allocate(unsigned long) in src.o void std::__1::vector, std::__1::allocator > >::__push_back_slow_path >(std::__1::__state&&) in src.o std::__1::vector, std::__1::allocator > >::__append(unsigned long, std::__1::sub_match const&) in src.o std::__1::vector, std::__1::allocator > >::__append(unsigned long) in src.o std::__1::vector, std::__1::allocator > >::allocate(unsigned long) in src.o void std::__1::vector >::__push_back_slow_path(char&&) in src.o ... "std::__1::__basic_string_common::__throw_length_error() const", referenced from: std::__1::enable_if<__is_forward_iterator::value, void>::type std::__1::basic_string, std::__1::allocator >::__init(char*, char*) in src.o std::__1::enable_if<__is_forward_iterator::value, void>::type std::__1::basic_string, std::__1::allocator >::__init(char const*, char const*) in src.o std::__1::enable_if<__is_forward_iterator >::value, void>::type std::__1::basic_string, std::__1::allocator >::__init >(std::__1::__wrap_iter, std::__1::__wrap_iter) in src.o "std::__1::__match_any_but_newline::__exec(std::__1::__state&) const", referenced from: vtable for std::__1::__match_any_but_newline in src.o "std::__1::locale::name() const", referenced from: std::__1::basic_regex >::__start_matching_list(bool) in src.o "std::__1::locale::use_facet(std::__1::locale::id&) const", referenced from: std::__1::regex_traits::__init() in src.o "std::__1::regex_error::regex_error(std::__1::regex_constants::error_type)", referenced from: char const* std::__1::basic_regex >::__parse(char const*, char const*) in src.o char const* std::__1::basic_regex >::__parse_basic_reg_exp(char const*, char const*) in src.o char const* std::__1::basic_regex >::__parse_extended_reg_exp(char const*, char const*) in src.o char const* std::__1::basic_regex >::__parse_assertion(char const*, char const*) in src.o char const* std::__1::basic_regex >::__parse_atom(char const*, char const*) in src.o char const* std::__1::basic_regex >::__parse_ERE_dupl_symbol(char const*, char const*, std::__1::__owns_one_state*, unsigned int, unsigned int) in src.o bool std::__1::basic_regex >::__match_at_start_ecma > >(char const*, char const*, std::__1::match_results > >&, std::__1::regex_constants::match_flag_type, bool) const in src.o ... "std::__1::regex_error::~regex_error()", referenced from: char const* std::__1::basic_regex >::__parse(char const*, char const*) in src.o char const* std::__1::basic_regex >::__parse_basic_reg_exp(char const*, char const*) in src.o char const* std::__1::basic_regex >::__parse_extended_reg_exp(char const*, char const*) in src.o char const* std::__1::basic_regex >::__parse_assertion(char const*, char const*) in src.o char const* std::__1::basic_regex >::__parse_atom(char const*, char const*) in src.o char const* std::__1::basic_regex >::__parse_ERE_dupl_symbol(char const*, char const*, std::__1::__owns_one_state*, unsigned int, unsigned int) in src.o bool std::__1::basic_regex >::__match_at_start_ecma > >(char const*, char const*, std::__1::match_results > >&, std::__1::regex_constants::match_flag_type, bool) const in src.o ... "std::__1::basic_string, std::__1::allocator >::__init(char const*, unsigned long)", referenced from: _main in src.o "std::__1::basic_string, std::__1::allocator >::__init(unsigned long, char)", referenced from: std::__1::__bracket_expression >::__exec(std::__1::__state&) const in src.o "std::__1::basic_string, std::__1::allocator >::reserve(unsigned long)", referenced from: std::__1::basic_string, std::__1::allocator > std::__1::regex_traits::__lookup_collatename(char*, char*, char) const in src.o char const* std::__1::basic_regex >::__parse_collating_symbol(char const*, char const*, std::__1::basic_string, std::__1::allocator >&) in src.o std::__1::basic_string, std::__1::allocator > std::__1::regex_traits::__lookup_collatename(char const*, char const*, char) const in src.o "std::__1::basic_string, std::__1::allocator >::basic_string(std::__1::basic_string, std::__1::allocator > const&)", referenced from: char const* std::__1::basic_regex >::__parse_equivalence_class(char const*, char const*, std::__1::__bracket_expression >*) in src.o void std::__1::vector, std::__1::allocator >, std::__1::allocator, std::__1::allocator > > >::__push_back_slow_path, std::__1::allocator > const&>(std::__1::basic_string, std::__1::allocator > const&&&) in src.o "std::__1::basic_string, std::__1::allocator >::~basic_string()", referenced from: _main in src.o std::__1::basic_regex >::__start_matching_list(bool) in src.o std::__1::__bracket_expression >::__exec(std::__1::__state&) const in src.o std::__1::__vector_base, std::__1::allocator >, std::__1::allocator, std::__1::allocator > > >::~__vector_base() in src.o std::__1::pair, std::__1::allocator >, std::__1::basic_string, std::__1::allocator > >::~pair() in src.o std::__1::basic_string, std::__1::allocator > std::__1::regex_traits::transform(char*, char*) const in src.o std::__1::basic_string, std::__1::allocator > std::__1::regex_traits::__lookup_collatename(char*, char*, char) const in src.o ... "std::__1::basic_string, std::__1::allocator >::operator=(std::__1::basic_string, std::__1::allocator > const&)", referenced from: std::__1::basic_string, std::__1::allocator > std::__1::regex_traits::__lookup_collatename(char*, char*, char) const in src.o std::__1::basic_string, std::__1::allocator > std::__1::regex_traits::__lookup_collatename(char const*, char const*, char) const in src.o "std::__1::basic_string, std::__1::allocator >::operator=(char)", referenced from: char const* std::__1::basic_regex >::__parse_character_escape(char const*, char const*, std::__1::basic_string, std::__1::allocator >*) in src.o char const* std::__1::basic_regex >::__parse_expression_term(char const*, char const*, std::__1::__bracket_expression >*) in src.o char const* std::__1::basic_regex >::__parse_class_escape(char const*, char const*, std::__1::basic_string, std::__1::allocator >&, std::__1::__bracket_expression >*) in src.o char const* std::__1::basic_regex >::__parse_awk_escape(char const*, char const*, std::__1::basic_string, std::__1::allocator >*) in src.o "std::__1::__get_classname(char const*, bool)", referenced from: unsigned int std::__1::regex_traits::__lookup_classname(char const*, char const*, bool, char) const in src.o "std::__1::__shared_weak_count::__add_shared()", referenced from: std::__1::basic_regex >::basic_regex(std::__1::basic_regex > const&) in src.o "std::__1::__shared_weak_count::__release_shared()", referenced from: std::__1::shared_ptr >::~shared_ptr() in src.o "std::__1::__shared_weak_count::~__shared_weak_count()", referenced from: std::__1::__shared_ptr_pointer*, std::__1::default_delete >, std::__1::allocator > >::~__shared_ptr_pointer() in src.o "std::__1::__get_collation_name(char const*)", referenced from: std::__1::basic_string, std::__1::allocator > std::__1::regex_traits::__lookup_collatename(char*, char*, char) const in src.o std::__1::basic_string, std::__1::allocator > std::__1::regex_traits::__lookup_collatename(char const*, char const*, char) const in src.o "std::__1::ctype::id", referenced from: std::__1::regex_traits::__init() in src.o "std::__1::locale::locale(std::__1::locale const&)", referenced from: std::__1::regex_traits::regex_traits(std::__1::regex_traits const&) in src.o std::__1::basic_regex >::__start_matching_list(bool) in src.o "std::__1::locale::locale()", referenced from: std::__1::regex_traits::regex_traits() in src.o "std::__1::locale::~locale()", referenced from: std::__1::regex_traits::~regex_traits() in src.o std::__1::regex_traits::regex_traits() in src.o std::__1::basic_regex >::__start_matching_list(bool) in src.o "std::__1::collate::id", referenced from: std::__1::regex_traits::__init() in src.o "typeinfo for std::__1::regex_error", referenced from: char const* std::__1::basic_regex >::__parse(char const*, char const*) in src.o char const* std::__1::basic_regex >::__parse_basic_reg_exp(char const*, char const*) in src.o char const* std::__1::basic_regex >::__parse_extended_reg_exp(char const*, char const*) in src.o char const* std::__1::basic_regex >::__parse_assertion(char const*, char const*) in src.o char const* std::__1::basic_regex >::__parse_atom(char const*, char const*) in src.o char const* std::__1::basic_regex >::__parse_ERE_dupl_symbol(char const*, char const*, std::__1::__owns_one_state*, unsigned int, unsigned int) in src.o bool std::__1::basic_regex >::__match_at_start_ecma > >(char const*, char const*, std::__1::match_results > >&, std::__1::regex_constants::match_flag_type, bool) const in src.o ... "typeinfo for std::__1::__shared_weak_count", referenced from: typeinfo for std::__1::__shared_ptr_pointer*, std::__1::default_delete >, std::__1::allocator > > in src.o "vtable for std::__1::__shared_count", referenced from: std::__1::shared_ptr >::shared_ptr >(std::__1::__empty_state*, std::__1::enable_if*, std::__1::__empty_state*>::value, std::__1::shared_ptr >::__nat>::type) in src.o NOTE: a missing vtable usually means the first non-inline virtual member function has no definition. "vtable for std::__1::__shared_weak_count", referenced from: std::__1::shared_ptr >::shared_ptr >(std::__1::__empty_state*, std::__1::enable_if*, std::__1::__empty_state*>::value, std::__1::shared_ptr >::__nat>::type) in src.o NOTE: a missing vtable usually means the first non-inline virtual member function has no definition. ld: symbol(s) not found for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation) ** BUILD FAILED ** Did I forget something? Thanks in advance Best Regards Roman -------------- next part -------------- An HTML attachment was scrubbed... URL: From roman.wueger at gmx.at Thu Nov 24 13:43:20 2016 From: roman.wueger at gmx.at (=?utf-8?Q?Roman_W=C3=BCger?=) Date: Thu, 24 Nov 2016 19:43:20 +0100 Subject: [CMake] [cmake-developers] C++11/C++14 doesn't work in check_cxx_source_compiles In-Reply-To: <01cb01d2467d$d2f7fed0$78e7fc70$@gmx.at> References: <01cb01d2467d$d2f7fed0$78e7fc70$@gmx.at> Message-ID: It is working now, after I added -lc++ to CMAKE_REQUIRED_LIBRARIES before the check_cxx_source_compiles() call. Shouldn't this be done by CMAKE_CXX_STANDARD? Best Regards Roman > Am 24.11.2016 um 19:08 schrieb Roman W?ger : > > Hello, > > If I use a small piece of code which uses , then it fails with check_cxx_source_compiles. If I copy the piece of code into a file and run the following on the command line, then it works: > > clang++ main.cpp -std=c++14 -stdlib=libc++ > > Here is the piece of code: > > #include > #include > > int main() { > const std::string text = "Roses are #ff0000, other flowers have other colors."; > const std::regex pattern("#([a-f0-9]{2})"); > > std::smatch match; > std::regex_search(text, match, pattern); > > return 0; > } > > I use this code in CMake as a platform check as followed: > > # C++11 Regular Expression > set(CMAKE_REQUIRED_FLAGS "${CMAKE_CXX_FLAGS}") > check_cxx_source_compiles( > "#include > #include > > int main() { > const std::string text = \"Roses are #ff0000, other flowers have other colors.\"; > const std::regex pattern(\"#([a-f0-9]{2})\"); > > std::smatch match; > std::regex_search(text, match, pattern); > > return 0; > }" > HAVE_CXX11_REGULAR_EXPRESSIONS > ) > set(CMAKE_REQUIRED_FLAGS "") > > CMakeFiles/CMakeError.log shows: > > Undefined symbols for architecture x86_64: > "std::__1::basic_string, std::__1::allocator >::compare(char const*) const", referenced from: > std::__1::basic_regex >::__start_matching_list(bool) in src.o > "std::__1::__vector_base_common::__throw_length_error() const", referenced from: > std::__1::vector, std::__1::allocator > >::assign(unsigned long, std::__1::sub_match const&) in src.o > std::__1::vector, std::__1::allocator > >::allocate(unsigned long) in src.o > void std::__1::vector, std::__1::allocator > >::__push_back_slow_path >(std::__1::__state&&) in src.o > std::__1::vector, std::__1::allocator > >::__append(unsigned long, std::__1::sub_match const&) in src.o > std::__1::vector, std::__1::allocator > >::__append(unsigned long) in src.o > std::__1::vector, std::__1::allocator > >::allocate(unsigned long) in src.o > void std::__1::vector >::__push_back_slow_path(char&&) in src.o > ... > "std::__1::__basic_string_common::__throw_length_error() const", referenced from: > std::__1::enable_if<__is_forward_iterator::value, void>::type std::__1::basic_string, std::__1::allocator >::__init(char*, char*) in src.o > std::__1::enable_if<__is_forward_iterator::value, void>::type std::__1::basic_string, std::__1::allocator >::__init(char const*, char const*) in src.o > std::__1::enable_if<__is_forward_iterator >::value, void>::type std::__1::basic_string, std::__1::allocator >::__init >(std::__1::__wrap_iter, std::__1::__wrap_iter) in src.o > "std::__1::__match_any_but_newline::__exec(std::__1::__state&) const", referenced from: > vtable for std::__1::__match_any_but_newline in src.o > "std::__1::locale::name() const", referenced from: > std::__1::basic_regex >::__start_matching_list(bool) in src.o > "std::__1::locale::use_facet(std::__1::locale::id&) const", referenced from: > std::__1::regex_traits::__init() in src.o > "std::__1::regex_error::regex_error(std::__1::regex_constants::error_type)", referenced from: > char const* std::__1::basic_regex >::__parse(char const*, char const*) in src.o > char const* std::__1::basic_regex >::__parse_basic_reg_exp(char const*, char const*) in src.o > char const* std::__1::basic_regex >::__parse_extended_reg_exp(char const*, char const*) in src.o > char const* std::__1::basic_regex >::__parse_assertion(char const*, char const*) in src.o > char const* std::__1::basic_regex >::__parse_atom(char const*, char const*) in src.o > char const* std::__1::basic_regex >::__parse_ERE_dupl_symbol(char const*, char const*, std::__1::__owns_one_state*, unsigned int, unsigned int) in src.o > bool std::__1::basic_regex >::__match_at_start_ecma > >(char const*, char const*, std::__1::match_results > >&, std::__1::regex_constants::match_flag_type, bool) const in src.o > ... > "std::__1::regex_error::~regex_error()", referenced from: > char const* std::__1::basic_regex >::__parse(char const*, char const*) in src.o > char const* std::__1::basic_regex >::__parse_basic_reg_exp(char const*, char const*) in src.o > char const* std::__1::basic_regex >::__parse_extended_reg_exp(char const*, char const*) in src.o > char const* std::__1::basic_regex >::__parse_assertion(char const*, char const*) in src.o > char const* std::__1::basic_regex >::__parse_atom(char const*, char const*) in src.o > char const* std::__1::basic_regex >::__parse_ERE_dupl_symbol(char const*, char const*, std::__1::__owns_one_state*, unsigned int, unsigned int) in src.o > bool std::__1::basic_regex >::__match_at_start_ecma > >(char const*, char const*, std::__1::match_results > >&, std::__1::regex_constants::match_flag_type, bool) const in src.o > ... > "std::__1::basic_string, std::__1::allocator >::__init(char const*, unsigned long)", referenced from: > _main in src.o > "std::__1::basic_string, std::__1::allocator >::__init(unsigned long, char)", referenced from: > std::__1::__bracket_expression >::__exec(std::__1::__state&) const in src.o > "std::__1::basic_string, std::__1::allocator >::reserve(unsigned long)", referenced from: > std::__1::basic_string, std::__1::allocator > std::__1::regex_traits::__lookup_collatename(char*, char*, char) const in src.o > char const* std::__1::basic_regex >::__parse_collating_symbol(char const*, char const*, std::__1::basic_string, std::__1::allocator >&) in src.o > std::__1::basic_string, std::__1::allocator > std::__1::regex_traits::__lookup_collatename(char const*, char const*, char) const in src.o > "std::__1::basic_string, std::__1::allocator >::basic_string(std::__1::basic_string, std::__1::allocator > const&)", referenced from: > char const* std::__1::basic_regex >::__parse_equivalence_class(char const*, char const*, std::__1::__bracket_expression >*) in src.o > void std::__1::vector, std::__1::allocator >, std::__1::allocator, std::__1::allocator > > >::__push_back_slow_path, std::__1::allocator > const&>(std::__1::basic_string, std::__1::allocator > const&&&) in src.o > "std::__1::basic_string, std::__1::allocator >::~basic_string()", referenced from: > _main in src.o > std::__1::basic_regex >::__start_matching_list(bool) in src.o > std::__1::__bracket_expression >::__exec(std::__1::__state&) const in src.o > std::__1::__vector_base, std::__1::allocator >, std::__1::allocator, std::__1::allocator > > >::~__vector_base() in src.o > std::__1::pair, std::__1::allocator >, std::__1::basic_string, std::__1::allocator > >::~pair() in src.o > std::__1::basic_string, std::__1::allocator > std::__1::regex_traits::transform(char*, char*) const in src.o > std::__1::basic_string, std::__1::allocator > std::__1::regex_traits::__lookup_collatename(char*, char*, char) const in src.o > ... > "std::__1::basic_string, std::__1::allocator >::operator=(std::__1::basic_string, std::__1::allocator > const&)", referenced from: > std::__1::basic_string, std::__1::allocator > std::__1::regex_traits::__lookup_collatename(char*, char*, char) const in src.o > std::__1::basic_string, std::__1::allocator > std::__1::regex_traits::__lookup_collatename(char const*, char const*, char) const in src.o > "std::__1::basic_string, std::__1::allocator >::operator=(char)", referenced from: > char const* std::__1::basic_regex >::__parse_character_escape(char const*, char const*, std::__1::basic_string, std::__1::allocator >*) in src.o > char const* std::__1::basic_regex >::__parse_expression_term(char const*, char const*, std::__1::__bracket_expression >*) in src.o > char const* std::__1::basic_regex >::__parse_class_escape(char const*, char const*, std::__1::basic_string, std::__1::allocator >&, std::__1::__bracket_expression >*) in src.o > char const* std::__1::basic_regex >::__parse_awk_escape(char const*, char const*, std::__1::basic_string, std::__1::allocator >*) in src.o > "std::__1::__get_classname(char const*, bool)", referenced from: > unsigned int std::__1::regex_traits::__lookup_classname(char const*, char const*, bool, char) const in src.o > "std::__1::__shared_weak_count::__add_shared()", referenced from: > std::__1::basic_regex >::basic_regex(std::__1::basic_regex > const&) in src.o > "std::__1::__shared_weak_count::__release_shared()", referenced from: > std::__1::shared_ptr >::~shared_ptr() in src.o > "std::__1::__shared_weak_count::~__shared_weak_count()", referenced from: > std::__1::__shared_ptr_pointer*, std::__1::default_delete >, std::__1::allocator > >::~__shared_ptr_pointer() in src.o > "std::__1::__get_collation_name(char const*)", referenced from: > std::__1::basic_string, std::__1::allocator > std::__1::regex_traits::__lookup_collatename(char*, char*, char) const in src.o > std::__1::basic_string, std::__1::allocator > std::__1::regex_traits::__lookup_collatename(char const*, char const*, char) const in src.o > "std::__1::ctype::id", referenced from: > std::__1::regex_traits::__init() in src.o > "std::__1::locale::locale(std::__1::locale const&)", referenced from: > std::__1::regex_traits::regex_traits(std::__1::regex_traits const&) in src.o > std::__1::basic_regex >::__start_matching_list(bool) in src.o > "std::__1::locale::locale()", referenced from: > std::__1::regex_traits::regex_traits() in src.o > "std::__1::locale::~locale()", referenced from: > std::__1::regex_traits::~regex_traits() in src.o > std::__1::regex_traits::regex_traits() in src.o > std::__1::basic_regex >::__start_matching_list(bool) in src.o > "std::__1::collate::id", referenced from: > std::__1::regex_traits::__init() in src.o > "typeinfo for std::__1::regex_error", referenced from: > char const* std::__1::basic_regex >::__parse(char const*, char const*) in src.o > char const* std::__1::basic_regex >::__parse_basic_reg_exp(char const*, char const*) in src.o > char const* std::__1::basic_regex >::__parse_extended_reg_exp(char const*, char const*) in src.o > char const* std::__1::basic_regex >::__parse_assertion(char const*, char const*) in src.o > char const* std::__1::basic_regex >::__parse_atom(char const*, char const*) in src.o > char const* std::__1::basic_regex >::__parse_ERE_dupl_symbol(char const*, char const*, std::__1::__owns_one_state*, unsigned int, unsigned int) in src.o > bool std::__1::basic_regex >::__match_at_start_ecma > >(char const*, char const*, std::__1::match_results > >&, std::__1::regex_constants::match_flag_type, bool) const in src.o > ... > "typeinfo for std::__1::__shared_weak_count", referenced from: > typeinfo for std::__1::__shared_ptr_pointer*, std::__1::default_delete >, std::__1::allocator > > in src.o > "vtable for std::__1::__shared_count", referenced from: > std::__1::shared_ptr >::shared_ptr >(std::__1::__empty_state*, std::__1::enable_if*, std::__1::__empty_state*>::value, std::__1::shared_ptr >::__nat>::type) in src.o > NOTE: a missing vtable usually means the first non-inline virtual member function has no definition. > "vtable for std::__1::__shared_weak_count", referenced from: > std::__1::shared_ptr >::shared_ptr >(std::__1::__empty_state*, std::__1::enable_if*, std::__1::__empty_state*>::value, std::__1::shared_ptr >::__nat>::type) in src.o > NOTE: a missing vtable usually means the first non-inline virtual member function has no definition. > ld: symbol(s) not found for architecture x86_64 > clang: error: linker command failed with exit code 1 (use -v to see invocation) > > ** BUILD FAILED ** > > Did I forget something? > > Thanks in advance > > Best Regards > Roman > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake-developers -------------- next part -------------- An HTML attachment was scrubbed... URL: From craig.scott at crascit.com Thu Nov 24 16:01:02 2016 From: craig.scott at crascit.com (Craig Scott) Date: Fri, 25 Nov 2016 08:01:02 +1100 Subject: [CMake] [cmake-developers] C++11/C++14 doesn't work in check_cxx_source_compiles In-Reply-To: References: <01cb01d2467d$d2f7fed0$78e7fc70$@gmx.at> Message-ID: You might also need to set CMAKE_CXX_EXTENSIONS to OFF (it's ON by default). This controls which c++ library is linked for some compilers, with clang and gcc being two cases where it does this. You may also find this article about the related CMake variables and commands to be of interest. On Fri, Nov 25, 2016 at 5:43 AM, Roman W?ger wrote: > It is working now, after I added -lc++ to CMAKE_REQUIRED_LIBRARIES before > the check_cxx_source_compiles() call. > > Shouldn't this be done by CMAKE_CXX_STANDARD? > > Best Regards > Roman > > Am 24.11.2016 um 19:08 schrieb Roman W?ger : > > Hello, > > > > If I use a small piece of code which uses , then it fails with > check_cxx_source_compiles. If I copy the piece of code into a file and run > the following on the command line, then it works: > > > > clang++ main.cpp -std=c++14 -stdlib=libc++ > > > > Here is the piece of code: > > > > #include > > #include > > > > int main() { > > const std::string text = "Roses are #ff0000, other flowers have other > colors."; > > const std::regex pattern("#([a-f0-9]{2})"); > > > > std::smatch match; > > std::regex_search(text, match, pattern); > > > > return 0; > > } > > > > I use this code in CMake as a platform check as followed: > > > > # C++11 Regular Expression > > set(CMAKE_REQUIRED_FLAGS "${CMAKE_CXX_FLAGS}") > > check_cxx_source_compiles( > > "#include > > #include > > > > int main() { > > const std::string text = \"Roses are #ff0000, other flowers have > other colors.\"; > > const std::regex pattern(\"#([a-f0-9]{2})\"); > > > > std::smatch match; > > std::regex_search(text, match, pattern); > > > > return 0; > > }" > > HAVE_CXX11_REGULAR_EXPRESSIONS > > ) > > set(CMAKE_REQUIRED_FLAGS "") > > > > CMakeFiles/CMakeError.log shows: > > > > Undefined symbols for architecture x86_64: > > "std::__1::basic_string, > std::__1::allocator >::compare(char const*) const", referenced from: > > std::__1::basic_regex > >::__start_matching_list(bool) in src.o > > "std::__1::__vector_base_common::__throw_length_error() const", > referenced from: > > std::__1::vector, > std::__1::allocator > >::assign(unsigned > long, std::__1::sub_match const&) in src.o > > std::__1::vector, > std::__1::allocator > > >::allocate(unsigned long) in src.o > > void std::__1::vector, > std::__1::allocator > > >::__push_back_slow_path > >(std::__1::__state&&) in src.o > > std::__1::vector, > std::__1::allocator > > >::__append(unsigned long, std::__1::sub_match const&) in src.o > > std::__1::vector, > std::__1::allocator > > >::__append(unsigned long) in src.o > > std::__1::vector, > std::__1::allocator > > >::allocate(unsigned long) in src.o > > void std::__1::vector > >::__push_back_slow_path(char&&) in src.o > > ... > > "std::__1::__basic_string_common::__throw_length_error() const", > referenced from: > > std::__1::enable_if<__is_forward_iterator::value, > void>::type std::__1::basic_string, > std::__1::allocator >::__init(char*, char*) in src.o > > std::__1::enable_if<__is_forward_iterator::value, > void>::type std::__1::basic_string, > std::__1::allocator >::__init(char const*, char const*) > in src.o > > std::__1::enable_if<__is_forward_iterator > >::value, void>::type std::__1::basic_string std::__1::char_traits, std::__1::allocator > >::__init >(std::__1::__wrap_iter, > std::__1::__wrap_iter) in src.o > > "std::__1::__match_any_but_newline::__exec(std::__1::__state&) > const", referenced from: > > vtable for std::__1::__match_any_but_newline in src.o > > "std::__1::locale::name() const", referenced from: > > std::__1::basic_regex > >::__start_matching_list(bool) in src.o > > "std::__1::locale::use_facet(std::__1::locale::id&) const", referenced > from: > > std::__1::regex_traits::__init() in src.o > > "std::__1::regex_error::regex_error(std::__1::regex_constants::error_type)", > referenced from: > > char const* std::__1::basic_regex > >::__parse(char const*, char const*) in src.o > > char const* std::__1::basic_regex > >::__parse_basic_reg_exp(char const*, char const*) in src.o > > char const* std::__1::basic_regex > >::__parse_extended_reg_exp(char const*, char const*) in > src.o > > char const* std::__1::basic_regex > >::__parse_assertion(char const*, char const*) in src.o > > char const* std::__1::basic_regex > >::__parse_atom(char const*, char const*) in src.o > > char const* std::__1::basic_regex > >::__parse_ERE_dupl_symbol(char const*, char const*, > std::__1::__owns_one_state*, unsigned int, unsigned int) in src.o > > bool std::__1::basic_regex > >::__match_at_start_ecma const*> > >(char const*, char const*, std::__1::match_results std::__1::allocator > >&, > std::__1::regex_constants::match_flag_type, bool) const in src.o > > ... > > "std::__1::regex_error::~regex_error()", referenced from: > > char const* std::__1::basic_regex > >::__parse(char const*, char const*) in src.o > > char const* std::__1::basic_regex > >::__parse_basic_reg_exp(char const*, char const*) in src.o > > char const* std::__1::basic_regex > >::__parse_extended_reg_exp(char const*, char const*) in > src.o > > char const* std::__1::basic_regex > >::__parse_assertion(char const*, char const*) in src.o > > char const* std::__1::basic_regex > >::__parse_atom(char const*, char const*) in src.o > > char const* std::__1::basic_regex > >::__parse_ERE_dupl_symbol(char const*, char const*, > std::__1::__owns_one_state*, unsigned int, unsigned int) in src.o > > bool std::__1::basic_regex > >::__match_at_start_ecma const*> > >(char const*, char const*, std::__1::match_results std::__1::allocator > >&, > std::__1::regex_constants::match_flag_type, bool) const in src.o > > ... > > "std::__1::basic_string, > std::__1::allocator >::__init(char const*, unsigned long)", > referenced from: > > _main in src.o > > "std::__1::basic_string, > std::__1::allocator >::__init(unsigned long, char)", referenced from: > > std::__1::__bracket_expression > >::__exec(std::__1::__state&) const in src.o > > "std::__1::basic_string, > std::__1::allocator >::reserve(unsigned long)", referenced from: > > std::__1::basic_string, > std::__1::allocator > std::__1::regex_traits:: > __lookup_collatename(char*, char*, char) const in src.o > > char const* std::__1::basic_regex > >::__parse_collating_symbol(char const*, char const*, > std::__1::basic_string, > std::__1::allocator >&) in src.o > > std::__1::basic_string, > std::__1::allocator > std::__1::regex_traits::__lookup_collatename const*>(char const*, char const*, char) const in src.o > > "std::__1::basic_string, > std::__1::allocator >::basic_string(std::__1::basic_string std::__1::char_traits, std::__1::allocator > const&)", > referenced from: > > char const* std::__1::basic_regex > >::__parse_equivalence_class(char const*, char const*, > std::__1::__bracket_expression >*) in > src.o > > void std::__1::vector std::__1::char_traits, std::__1::allocator >, > std::__1::allocator std::__1::char_traits, std::__1::allocator > > > >::__push_back_slow_path std::__1::char_traits, std::__1::allocator > > const&>(std::__1::basic_string, > std::__1::allocator > const&&&) in src.o > > "std::__1::basic_string, > std::__1::allocator >::~basic_string()", referenced from: > > _main in src.o > > std::__1::basic_regex > >::__start_matching_list(bool) in src.o > > std::__1::__bracket_expression > >::__exec(std::__1::__state&) const in src.o > > std::__1::__vector_base std::__1::char_traits, std::__1::allocator >, > std::__1::allocator std::__1::char_traits, std::__1::allocator > > > >::~__vector_base() in src.o > > std::__1::pair std::__1::char_traits, std::__1::allocator >, > std::__1::basic_string, > std::__1::allocator > >::~pair() in src.o > > std::__1::basic_string, > std::__1::allocator > std::__1::regex_traits::transform(char*, > char*) const in src.o > > std::__1::basic_string, > std::__1::allocator > std::__1::regex_traits:: > __lookup_collatename(char*, char*, char) const in src.o > > ... > > "std::__1::basic_string, > std::__1::allocator >::operator=(std::__1::basic_string std::__1::char_traits, std::__1::allocator > const&)", > referenced from: > > std::__1::basic_string, > std::__1::allocator > std::__1::regex_traits:: > __lookup_collatename(char*, char*, char) const in src.o > > std::__1::basic_string, > std::__1::allocator > std::__1::regex_traits::__lookup_collatename const*>(char const*, char const*, char) const in src.o > > "std::__1::basic_string, > std::__1::allocator >::operator=(char)", referenced from: > > char const* std::__1::basic_regex > >::__parse_character_escape(char const*, char const*, > std::__1::basic_string, > std::__1::allocator >*) in src.o > > char const* std::__1::basic_regex > >::__parse_expression_term(char const*, char const*, > std::__1::__bracket_expression >*) in > src.o > > char const* std::__1::basic_regex > >::__parse_class_escape(char const*, char const*, > std::__1::basic_string, > std::__1::allocator >&, std::__1::__bracket_expression std::__1::regex_traits >*) in src.o > > char const* std::__1::basic_regex > >::__parse_awk_escape(char const*, char const*, > std::__1::basic_string, > std::__1::allocator >*) in src.o > > "std::__1::__get_classname(char const*, bool)", referenced from: > > unsigned int std::__1::regex_traits::__lookup_classname const*>(char const*, char const*, bool, char) const in src.o > > "std::__1::__shared_weak_count::__add_shared()", referenced from: > > std::__1::basic_regex > >::basic_regex(std::__1::basic_regex > > const&) in src.o > > "std::__1::__shared_weak_count::__release_shared()", referenced from: > > std::__1::shared_ptr >::~shared_ptr() > in src.o > > "std::__1::__shared_weak_count::~__shared_weak_count()", referenced > from: > > std::__1::__shared_ptr_pointer*, > std::__1::default_delete >, > std::__1::allocator > > >::~__shared_ptr_pointer() in src.o > > "std::__1::__get_collation_name(char const*)", referenced from: > > std::__1::basic_string, > std::__1::allocator > std::__1::regex_traits:: > __lookup_collatename(char*, char*, char) const in src.o > > std::__1::basic_string, > std::__1::allocator > std::__1::regex_traits::__lookup_collatename const*>(char const*, char const*, char) const in src.o > > "std::__1::ctype::id", referenced from: > > std::__1::regex_traits::__init() in src.o > > "std::__1::locale::locale(std::__1::locale const&)", referenced from: > > std::__1::regex_traits::regex_traits(std::__1::regex_traits > const&) in src.o > > std::__1::basic_regex > >::__start_matching_list(bool) in src.o > > "std::__1::locale::locale()", referenced from: > > std::__1::regex_traits::regex_traits() in src.o > > "std::__1::locale::~locale()", referenced from: > > std::__1::regex_traits::~regex_traits() in src.o > > std::__1::regex_traits::regex_traits() in src.o > > std::__1::basic_regex > >::__start_matching_list(bool) in src.o > > "std::__1::collate::id", referenced from: > > std::__1::regex_traits::__init() in src.o > > "typeinfo for std::__1::regex_error", referenced from: > > char const* std::__1::basic_regex > >::__parse(char const*, char const*) in src.o > > char const* std::__1::basic_regex > >::__parse_basic_reg_exp(char const*, char const*) in src.o > > char const* std::__1::basic_regex > >::__parse_extended_reg_exp(char const*, char const*) in > src.o > > char const* std::__1::basic_regex > >::__parse_assertion(char const*, char const*) in src.o > > char const* std::__1::basic_regex > >::__parse_atom(char const*, char const*) in src.o > > char const* std::__1::basic_regex > >::__parse_ERE_dupl_symbol(char const*, char const*, > std::__1::__owns_one_state*, unsigned int, unsigned int) in src.o > > bool std::__1::basic_regex > >::__match_at_start_ecma const*> > >(char const*, char const*, std::__1::match_results std::__1::allocator > >&, > std::__1::regex_constants::match_flag_type, bool) const in src.o > > ... > > "typeinfo for std::__1::__shared_weak_count", referenced from: > > typeinfo for std::__1::__shared_ptr_pointer*, > std::__1::default_delete >, > std::__1::allocator > > in src.o > > "vtable for std::__1::__shared_count", referenced from: > > std::__1::shared_ptr > >::shared_ptr >(std::__1::__empty_state*, > std::__1::enable_if*, > std::__1::__empty_state*>::value, std::__1::shared_ptr > >::__nat>::type) in src.o > > NOTE: a missing vtable usually means the first non-inline virtual member > function has no definition. > > "vtable for std::__1::__shared_weak_count", referenced from: > > std::__1::shared_ptr > >::shared_ptr >(std::__1::__empty_state*, > std::__1::enable_if*, > std::__1::__empty_state*>::value, std::__1::shared_ptr > >::__nat>::type) in src.o > > NOTE: a missing vtable usually means the first non-inline virtual member > function has no definition. > > ld: symbol(s) not found for architecture x86_64 > > clang: error: linker command failed with exit code 1 (use -v to see > invocation) > > > > ** BUILD FAILED ** > > > > Did I forget something? > > > > Thanks in advance > > > > Best Regards > > Roman > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/ > opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake-developers > > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/ > opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake-developers > -- Craig Scott Melbourne, Australia https://crascit.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From jackie at sdiwc.info Thu Nov 24 22:03:32 2016 From: jackie at sdiwc.info (Jackie Blanco) Date: Thu, 24 Nov 2016 20:03:32 -0700 Subject: [CMake] Call for Participation - 5th International Conference on Cyber Security, Cyber Welfare and Digital Forensic Message-ID: <9dab345b18334537effb6346775c0abc@sdiwc.info> ********************************************************************* Call for Participation CyberSec2017: The Fifth International Conference on Cyber Security, Cyber Welfare and Digital Forensic 22-24 April 2017, St. Mary's University, Addis Ababa, Ethiopia https://goo.gl/mbDr7F ********************************************************************* You are cordially invited to participate the 5th International Conference on Cyber Security, Cyber Welfare and Digital Forensic (CyberSec2017). CyberSec aims to enable researchers build connections between different digital applications and engineering. The event will be held over three days, with presentations delivered by researchers from the international community, including presentations from keynote speakers and state-of-the-art lectures. The International Cyber Security, Cyber Welfare and Digital Forensic is now on its fifth version as it is held annually in different countries. As of year 2017, the first conference in Ethiopia with the coordination of St. Mary's University and Society of Digital Information and Wireless Communications will held the Fifth International Conference on Cyber Security, Cyber Welfare and Digital Forensic (CyberSec2017). This conference is looking forward for participation of delegates in contribution to CyberSec field of topics. The conference welcomes papers on the following research topics: - Cyber Security - Privacy issues - Security in Cloud Computing - Cyber Welfare - Information Hiding - Large-Scale Investigations - Digital Forensic - Fraud Management - Laws and Regulations - Cyber Crimes - Security Protocol - Social engineering - Surveillance Systems The conference uses double-blind review by at least two reviewers, which means that both the reviewer and author identities are concealed from the reviewers, and vice versa, throughout the review process. To facilitate this, authors need to ensure that their manuscripts are prepared in a way that does not give away their identity. Full paper submission is due on March 1, 2017. From kit.chambers.kc at gmail.com Fri Nov 25 04:04:53 2016 From: kit.chambers.kc at gmail.com (Kit Chambers) Date: Fri, 25 Nov 2016 09:04:53 +0000 Subject: [CMake] Executing python though CMake and linking libraries Message-ID: <0AA0C3D8-580A-464F-A241-C934AD9FD45E@googlemail.com> I have a Cmake custom target which runs a python script: add_custom_target(run COMMAND python myscript.py ) And the script myscript.py imports a Compiled library import myproj.mylilb where mylib is actually a C++ library generated with python bindings (using vtkPython). This intern links against some other C++ libraries I use etc. When I run the script normally from the command line everything works fine, but if I try to run the target I get linker errors. $ make run Traceback (most recent call last): File "myscript.py", line 8, in import myproj.mylilb ImportError: dlopen(/Users/kitchambers/Applications/ogFramework/lib/python2.7/site-packages/myproj/mylib.so, 2): Library not loaded: libSpProcSupport.so Referenced from: /Users/kitchambers/Applications/ogFramework/lib/python2.7/site-packages/myproj/mylib.so Reason: image not found To me it looks like my LD_LIBRARY_PATH and DYLD_LIBRARY_PATH are not being passed through CMake to Python so it cannot find all the necessary sub libraries. However, i cannot work out how to pass this information through. Any help would be greatly appreciated. Cheers Kit From roman.wueger at gmx.at Fri Nov 25 05:25:19 2016 From: roman.wueger at gmx.at (=?utf-8?Q?Roman_W=C3=BCger?=) Date: Fri, 25 Nov 2016 11:25:19 +0100 Subject: [CMake] [cmake-developers] C++11/C++14 doesn't work in check_cxx_source_compiles In-Reply-To: References: <01cb01d2467d$d2f7fed0$78e7fc70$@gmx.at> Message-ID: <963950B0-96D1-4D9C-A46E-CB3DA8D5A904@gmx.at> but it does not set/add the required library > Am 24.11.2016 um 22:01 schrieb Craig Scott : > > You might also need to set CMAKE_CXX_EXTENSIONS to OFF (it's ON by default). This controls which c++ library is linked for some compilers, with clang and gcc being two cases where it does this. You may also find this article about the related CMake variables and commands to be of interest. > >> On Fri, Nov 25, 2016 at 5:43 AM, Roman W?ger wrote: >> It is working now, after I added -lc++ to CMAKE_REQUIRED_LIBRARIES before the check_cxx_source_compiles() call. >> >> Shouldn't this be done by CMAKE_CXX_STANDARD? >> >> Best Regards >> Roman >> >>> Am 24.11.2016 um 19:08 schrieb Roman W?ger : >>> >>> Hello, >>> >>> >>> >>> If I use a small piece of code which uses , then it fails with check_cxx_source_compiles. If I copy the piece of code into a file and run the following on the command line, then it works: >>> >>> >>> >>> clang++ main.cpp -std=c++14 -stdlib=libc++ >>> >>> >>> >>> Here is the piece of code: >>> >>> >>> >>> #include >>> >>> #include >>> >>> >>> >>> int main() { >>> >>> const std::string text = "Roses are #ff0000, other flowers have other colors."; >>> >>> const std::regex pattern("#([a-f0-9]{2})"); >>> >>> >>> >>> std::smatch match; >>> >>> std::regex_search(text, match, pattern); >>> >>> >>> >>> return 0; >>> >>> } >>> >>> >>> >>> I use this code in CMake as a platform check as followed: >>> >>> >>> >>> # C++11 Regular Expression >>> >>> set(CMAKE_REQUIRED_FLAGS "${CMAKE_CXX_FLAGS}") >>> >>> check_cxx_source_compiles( >>> >>> "#include >>> >>> #include >>> >>> >>> >>> int main() { >>> >>> const std::string text = \"Roses are #ff0000, other flowers have other colors.\"; >>> >>> const std::regex pattern(\"#([a-f0-9]{2})\"); >>> >>> >>> >>> std::smatch match; >>> >>> std::regex_search(text, match, pattern); >>> >>> >>> >>> return 0; >>> >>> }" >>> >>> HAVE_CXX11_REGULAR_EXPRESSIONS >>> >>> ) >>> >>> set(CMAKE_REQUIRED_FLAGS "") >>> >>> >>> >>> CMakeFiles/CMakeError.log shows: >>> >>> >>> >>> Undefined symbols for architecture x86_64: >>> >>> "std::__1::basic_string, std::__1::allocator >::compare(char const*) const", referenced from: >>> >>> std::__1::basic_regex >::__start_matching_list(bool) in src.o >>> >>> "std::__1::__vector_base_common::__throw_length_error() const", referenced from: >>> >>> std::__1::vector, std::__1::allocator > >::assign(unsigned long, std::__1::sub_match const&) in src.o >>> >>> std::__1::vector, std::__1::allocator > >::allocate(unsigned long) in src.o >>> >>> void std::__1::vector, std::__1::allocator > >::__push_back_slow_path >(std::__1::__state&&) in src.o >>> >>> std::__1::vector, std::__1::allocator > >::__append(unsigned long, std::__1::sub_match const&) in src.o >>> >>> std::__1::vector, std::__1::allocator > >::__append(unsigned long) in src.o >>> >>> std::__1::vector, std::__1::allocator > >::allocate(unsigned long) in src.o >>> >>> void std::__1::vector >::__push_back_slow_path(char&&) in src.o >>> >>> ... >>> >>> "std::__1::__basic_string_common::__throw_length_error() const", referenced from: >>> >>> std::__1::enable_if<__is_forward_iterator::value, void>::type std::__1::basic_string, std::__1::allocator >::__init(char*, char*) in src.o >>> >>> std::__1::enable_if<__is_forward_iterator::value, void>::type std::__1::basic_string, std::__1::allocator >::__init(char const*, char const*) in src.o >>> >>> std::__1::enable_if<__is_forward_iterator >::value, void>::type std::__1::basic_string, std::__1::allocator >::__init >(std::__1::__wrap_iter, std::__1::__wrap_iter) in src.o >>> >>> "std::__1::__match_any_but_newline::__exec(std::__1::__state&) const", referenced from: >>> >>> vtable for std::__1::__match_any_but_newline in src.o >>> >>> "std::__1::locale::name() const", referenced from: >>> >>> std::__1::basic_regex >::__start_matching_list(bool) in src.o >>> >>> "std::__1::locale::use_facet(std::__1::locale::id&) const", referenced from: >>> >>> std::__1::regex_traits::__init() in src.o >>> >>> "std::__1::regex_error::regex_error(std::__1::regex_constants::error_type)", referenced from: >>> >>> char const* std::__1::basic_regex >::__parse(char const*, char const*) in src.o >>> >>> char const* std::__1::basic_regex >::__parse_basic_reg_exp(char const*, char const*) in src.o >>> >>> char const* std::__1::basic_regex >::__parse_extended_reg_exp(char const*, char const*) in src.o >>> >>> char const* std::__1::basic_regex >::__parse_assertion(char const*, char const*) in src.o >>> >>> char const* std::__1::basic_regex >::__parse_atom(char const*, char const*) in src.o >>> >>> char const* std::__1::basic_regex >::__parse_ERE_dupl_symbol(char const*, char const*, std::__1::__owns_one_state*, unsigned int, unsigned int) in src.o >>> >>> bool std::__1::basic_regex >::__match_at_start_ecma > >(char const*, char const*, std::__1::match_results > >&, std::__1::regex_constants::match_flag_type, bool) const in src.o >>> >>> ... >>> >>> "std::__1::regex_error::~regex_error()", referenced from: >>> >>> char const* std::__1::basic_regex >::__parse(char const*, char const*) in src.o >>> >>> char const* std::__1::basic_regex >::__parse_basic_reg_exp(char const*, char const*) in src.o >>> >>> char const* std::__1::basic_regex >::__parse_extended_reg_exp(char const*, char const*) in src.o >>> >>> char const* std::__1::basic_regex >::__parse_assertion(char const*, char const*) in src.o >>> >>> char const* std::__1::basic_regex >::__parse_atom(char const*, char const*) in src.o >>> >>> char const* std::__1::basic_regex >::__parse_ERE_dupl_symbol(char const*, char const*, std::__1::__owns_one_state*, unsigned int, unsigned int) in src.o >>> >>> bool std::__1::basic_regex >::__match_at_start_ecma > >(char const*, char const*, std::__1::match_results > >&, std::__1::regex_constants::match_flag_type, bool) const in src.o >>> >>> ... >>> >>> "std::__1::basic_string, std::__1::allocator >::__init(char const*, unsigned long)", referenced from: >>> >>> _main in src.o >>> >>> "std::__1::basic_string, std::__1::allocator >::__init(unsigned long, char)", referenced from: >>> >>> std::__1::__bracket_expression >::__exec(std::__1::__state&) const in src.o >>> >>> "std::__1::basic_string, std::__1::allocator >::reserve(unsigned long)", referenced from: >>> >>> std::__1::basic_string, std::__1::allocator > std::__1::regex_traits::__lookup_collatename(char*, char*, char) const in src.o >>> >>> char const* std::__1::basic_regex >::__parse_collating_symbol(char const*, char const*, std::__1::basic_string, std::__1::allocator >&) in src.o >>> >>> std::__1::basic_string, std::__1::allocator > std::__1::regex_traits::__lookup_collatename(char const*, char const*, char) const in src.o >>> >>> "std::__1::basic_string, std::__1::allocator >::basic_string(std::__1::basic_string, std::__1::allocator > const&)", referenced from: >>> >>> char const* std::__1::basic_regex >::__parse_equivalence_class(char const*, char const*, std::__1::__bracket_expression >*) in src.o >>> >>> void std::__1::vector, std::__1::allocator >, std::__1::allocator, std::__1::allocator > > >::__push_back_slow_path, std::__1::allocator > const&>(std::__1::basic_string, std::__1::allocator > const&&&) in src.o >>> >>> "std::__1::basic_string, std::__1::allocator >::~basic_string()", referenced from: >>> >>> _main in src.o >>> >>> std::__1::basic_regex >::__start_matching_list(bool) in src.o >>> >>> std::__1::__bracket_expression >::__exec(std::__1::__state&) const in src.o >>> >>> std::__1::__vector_base, std::__1::allocator >, std::__1::allocator, std::__1::allocator > > >::~__vector_base() in src.o >>> >>> std::__1::pair, std::__1::allocator >, std::__1::basic_string, std::__1::allocator > >::~pair() in src.o >>> >>> std::__1::basic_string, std::__1::allocator > std::__1::regex_traits::transform(char*, char*) const in src.o >>> >>> std::__1::basic_string, std::__1::allocator > std::__1::regex_traits::__lookup_collatename(char*, char*, char) const in src.o >>> >>> ... >>> >>> "std::__1::basic_string, std::__1::allocator >::operator=(std::__1::basic_string, std::__1::allocator > const&)", referenced from: >>> >>> std::__1::basic_string, std::__1::allocator > std::__1::regex_traits::__lookup_collatename(char*, char*, char) const in src.o >>> >>> std::__1::basic_string, std::__1::allocator > std::__1::regex_traits::__lookup_collatename(char const*, char const*, char) const in src.o >>> >>> "std::__1::basic_string, std::__1::allocator >::operator=(char)", referenced from: >>> >>> char const* std::__1::basic_regex >::__parse_character_escape(char const*, char const*, std::__1::basic_string, std::__1::allocator >*) in src.o >>> >>> char const* std::__1::basic_regex >::__parse_expression_term(char const*, char const*, std::__1::__bracket_expression >*) in src.o >>> >>> char const* std::__1::basic_regex >::__parse_class_escape(char const*, char const*, std::__1::basic_string, std::__1::allocator >&, std::__1::__bracket_expression >*) in src.o >>> >>> char const* std::__1::basic_regex >::__parse_awk_escape(char const*, char const*, std::__1::basic_string, std::__1::allocator >*) in src.o >>> >>> "std::__1::__get_classname(char const*, bool)", referenced from: >>> >>> unsigned int std::__1::regex_traits::__lookup_classname(char const*, char const*, bool, char) const in src.o >>> >>> "std::__1::__shared_weak_count::__add_shared()", referenced from: >>> >>> std::__1::basic_regex >::basic_regex(std::__1::basic_regex > const&) in src.o >>> >>> "std::__1::__shared_weak_count::__release_shared()", referenced from: >>> >>> std::__1::shared_ptr >::~shared_ptr() in src.o >>> >>> "std::__1::__shared_weak_count::~__shared_weak_count()", referenced from: >>> >>> std::__1::__shared_ptr_pointer*, std::__1::default_delete >, std::__1::allocator > >::~__shared_ptr_pointer() in src.o >>> >>> "std::__1::__get_collation_name(char const*)", referenced from: >>> >>> std::__1::basic_string, std::__1::allocator > std::__1::regex_traits::__lookup_collatename(char*, char*, char) const in src.o >>> >>> std::__1::basic_string, std::__1::allocator > std::__1::regex_traits::__lookup_collatename(char const*, char const*, char) const in src.o >>> >>> "std::__1::ctype::id", referenced from: >>> >>> std::__1::regex_traits::__init() in src.o >>> >>> "std::__1::locale::locale(std::__1::locale const&)", referenced from: >>> >>> std::__1::regex_traits::regex_traits(std::__1::regex_traits const&) in src.o >>> >>> std::__1::basic_regex >::__start_matching_list(bool) in src.o >>> >>> "std::__1::locale::locale()", referenced from: >>> >>> std::__1::regex_traits::regex_traits() in src.o >>> >>> "std::__1::locale::~locale()", referenced from: >>> >>> std::__1::regex_traits::~regex_traits() in src.o >>> >>> std::__1::regex_traits::regex_traits() in src.o >>> >>> std::__1::basic_regex >::__start_matching_list(bool) in src.o >>> >>> "std::__1::collate::id", referenced from: >>> >>> std::__1::regex_traits::__init() in src.o >>> >>> "typeinfo for std::__1::regex_error", referenced from: >>> >>> char const* std::__1::basic_regex >::__parse(char const*, char const*) in src.o >>> >>> char const* std::__1::basic_regex >::__parse_basic_reg_exp(char const*, char const*) in src.o >>> >>> char const* std::__1::basic_regex >::__parse_extended_reg_exp(char const*, char const*) in src.o >>> >>> char const* std::__1::basic_regex >::__parse_assertion(char const*, char const*) in src.o >>> >>> char const* std::__1::basic_regex >::__parse_atom(char const*, char const*) in src.o >>> >>> char const* std::__1::basic_regex >::__parse_ERE_dupl_symbol(char const*, char const*, std::__1::__owns_one_state*, unsigned int, unsigned int) in src.o >>> >>> bool std::__1::basic_regex >::__match_at_start_ecma > >(char const*, char const*, std::__1::match_results > >&, std::__1::regex_constants::match_flag_type, bool) const in src.o >>> >>> ... >>> >>> "typeinfo for std::__1::__shared_weak_count", referenced from: >>> >>> typeinfo for std::__1::__shared_ptr_pointer*, std::__1::default_delete >, std::__1::allocator > > in src.o >>> >>> "vtable for std::__1::__shared_count", referenced from: >>> >>> std::__1::shared_ptr >::shared_ptr >(std::__1::__empty_state*, std::__1::enable_if*, std::__1::__empty_state*>::value, std::__1::shared_ptr >::__nat>::type) in src.o >>> >>> NOTE: a missing vtable usually means the first non-inline virtual member function has no definition. >>> >>> "vtable for std::__1::__shared_weak_count", referenced from: >>> >>> std::__1::shared_ptr >::shared_ptr >(std::__1::__empty_state*, std::__1::enable_if*, std::__1::__empty_state*>::value, std::__1::shared_ptr >::__nat>::type) in src.o >>> >>> NOTE: a missing vtable usually means the first non-inline virtual member function has no definition. >>> >>> ld: symbol(s) not found for architecture x86_64 >>> >>> clang: error: linker command failed with exit code 1 (use -v to see invocation) >>> >>> >>> >>> ** BUILD FAILED ** >>> >>> >>> >>> Did I forget something? >>> >>> >>> >>> Thanks in advance >>> >>> >>> >>> Best Regards >>> >>> Roman >>> >>> -- >>> >>> Powered by www.kitware.com >>> >>> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ >>> >>> Kitware offers various services to support the CMake community. For more information on each offering, please visit: >>> >>> CMake Support: http://cmake.org/cmake/help/support.html >>> CMake Consulting: http://cmake.org/cmake/help/consulting.html >>> CMake Training Courses: http://cmake.org/cmake/help/training.html >>> >>> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html >>> >>> Follow this link to subscribe/unsubscribe: >>> http://public.kitware.com/mailman/listinfo/cmake-developers >> >> -- >> >> Powered by www.kitware.com >> >> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ >> >> Kitware offers various services to support the CMake community. For more information on each offering, please visit: >> >> CMake Support: http://cmake.org/cmake/help/support.html >> CMake Consulting: http://cmake.org/cmake/help/consulting.html >> CMake Training Courses: http://cmake.org/cmake/help/training.html >> >> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/cmake-developers > > > > -- > Craig Scott > Melbourne, Australia > https://crascit.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From tonka3100 at gmail.com Fri Nov 25 08:23:01 2016 From: tonka3100 at gmail.com (tonka3100 at gmail.com) Date: Fri, 25 Nov 2016 14:23:01 +0100 Subject: [CMake] Executing python though CMake and linking libraries In-Reply-To: <0AA0C3D8-580A-464F-A241-C934AD9FD45E@googlemail.com> References: <0AA0C3D8-580A-464F-A241-C934AD9FD45E@googlemail.com> Message-ID: Hey, I think your actual working directory is wrong. I would recommend to use absolute paths for the python interperter (there is a find_package module for the interpreter) and maybe also for your script. The custom command support a workingdirectory variable as far as i know. Hope that help you. Greetings Tonka > Am 25.11.2016 um 10:04 schrieb Kit Chambers : > > I have a Cmake custom target which runs a python script: > > add_custom_target(run > COMMAND python myscript.py > ) > > And the script myscript.py imports a Compiled library > > import myproj.mylilb > > where mylib is actually a C++ library generated with python bindings (using vtkPython). This intern links against some other C++ libraries I use etc. > > > When I run the script normally from the command line everything works fine, but if I try to run the target I get linker errors. > > $ make run > > Traceback (most recent call last): > File "myscript.py", line 8, in > import myproj.mylilb > ImportError: dlopen(/Users/kitchambers/Applications/ogFramework/lib/python2.7/site-packages/myproj/mylib.so, 2): Library not loaded: libSpProcSupport.so > Referenced from: /Users/kitchambers/Applications/ogFramework/lib/python2.7/site-packages/myproj/mylib.so > Reason: image not found > > To me it looks like my LD_LIBRARY_PATH and DYLD_LIBRARY_PATH are not being passed through CMake to Python so it cannot find all the necessary sub libraries. However, i cannot work out how to pass this information through. > > Any help would be greatly appreciated. > > Cheers > > Kit > -- > > 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 kit.chambers.kc at gmail.com Fri Nov 25 13:21:21 2016 From: kit.chambers.kc at gmail.com (Kit Chambers) Date: Fri, 25 Nov 2016 18:21:21 +0000 Subject: [CMake] Executing python though CMake and linking libraries In-Reply-To: References: <0AA0C3D8-580A-464F-A241-C934AD9FD45E@googlemail.com> Message-ID: <4A143128-06AB-4FBA-8A17-81FEB6B3005A@googlemail.com> Hmmm? I get the same error if I use absolute paths. I don?t really understand why the shell environment used to launch CMake and make is not being inherited by the executed commands. Kit > On 25 Nov 2016, at 13:23, tonka3100 at gmail.com wrote: > > Hey, > > I think your actual working directory is wrong. I would recommend to use absolute paths for the python interperter (there is a find_package module for the interpreter) and maybe also for your script. The custom command support a workingdirectory variable as far as i know. > > Hope that help you. > > Greetings > Tonka > >> Am 25.11.2016 um 10:04 schrieb Kit Chambers : >> >> I have a Cmake custom target which runs a python script: >> >> add_custom_target(run >> COMMAND python myscript.py >> ) >> >> And the script myscript.py imports a Compiled library >> >> import myproj.mylilb >> >> where mylib is actually a C++ library generated with python bindings (using vtkPython). This intern links against some other C++ libraries I use etc. >> >> >> When I run the script normally from the command line everything works fine, but if I try to run the target I get linker errors. >> >> $ make run >> >> Traceback (most recent call last): >> File "myscript.py", line 8, in >> import myproj.mylilb >> ImportError: dlopen(/Users/kitchambers/Applications/ogFramework/lib/python2.7/site-packages/myproj/mylib.so, 2): Library not loaded: libSpProcSupport.so >> Referenced from: /Users/kitchambers/Applications/ogFramework/lib/python2.7/site-packages/myproj/mylib.so >> Reason: image not found >> >> To me it looks like my LD_LIBRARY_PATH and DYLD_LIBRARY_PATH are not being passed through CMake to Python so it cannot find all the necessary sub libraries. However, i cannot work out how to pass this information through. >> >> Any help would be greatly appreciated. >> >> Cheers >> >> Kit >> -- >> >> 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 nathanrsizemore at gmail.com Fri Nov 25 13:25:38 2016 From: nathanrsizemore at gmail.com (Nathan Sizemore) Date: Fri, 25 Nov 2016 13:25:38 -0500 Subject: [CMake] v3.7.0 - archive_cryptor_private.h - compile error Message-ID: Hello, I receive the following when building: [ 40%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_cryptor.c.o In file included from /home/nathan/development/cmake/Utilities/cmlibarchive/libarchive/archive_cryptor.c:32:0: /home/nathan/development/cmake/Utilities/cmlibarchive/libarchive/archive_cryptor_private.h:107:17: error: field ?ctx? has incomplete type EVP_CIPHER_CTX ctx; $ cat /etc/issue Debian GNU/Linux 8 $ gcc --version gcc (Debian 4.9.2-10) 4.9.2 Any ideas on how to resolve? Nathan Sizemore 937-668-7495 | @nathansizemore From craig.scott at crascit.com Fri Nov 25 17:23:24 2016 From: craig.scott at crascit.com (Craig Scott) Date: Sat, 26 Nov 2016 09:23:24 +1100 Subject: [CMake] [cmake-developers] C++11/C++14 doesn't work in check_cxx_source_compiles In-Reply-To: <963950B0-96D1-4D9C-A46E-CB3DA8D5A904@gmx.at> References: <01cb01d2467d$d2f7fed0$78e7fc70$@gmx.at> <963950B0-96D1-4D9C-A46E-CB3DA8D5A904@gmx.at> Message-ID: Sorry, I misunderstood. I had a look through the check_cxx_source_compiles() implementation and it basically forwards through to a try_compile() call. Looking at the docs for try_compile() , it says only the following are passed through to the temporary CMake project created for the test compilation: - CMAKE_ENABLE_EXPORTS - CMAKE_LINK_SEARCH_START_STATIC - CMAKE_LINK_SEARCH_END_STATIC - CMAKE_POSITION_INDEPENDENT_CODE A few more can be passed through depending on policy settings, but it looks like CMAKE_CXX_STANDARD, CMAKE_CXX_STANDARD_REQUIRED and CMAKE_CXX_EXTENSIONS don't get passed through. So it looks like, at the moment, you would have to manually pass through the relevant compiler and linker flags to get sources built via try_compile() and therefore via check_cxx_source_compiles(). I've recorded a new issue in the issue tracker for this. On Fri, Nov 25, 2016 at 9:25 PM, Roman W?ger wrote: > but it does not set/add the required library > > Am 24.11.2016 um 22:01 schrieb Craig Scott : > > You might also need to set CMAKE_CXX_EXTENSIONS > > to OFF (it's ON by default). This controls which c++ library is linked for > some compilers, with clang and gcc being two cases where it does this. You > may also find this article > about the > related CMake variables and commands to be of interest. > > On Fri, Nov 25, 2016 at 5:43 AM, Roman W?ger wrote: > >> It is working now, after I added -lc++ to CMAKE_REQUIRED_LIBRARIES before >> the check_cxx_source_compiles() call. >> >> Shouldn't this be done by CMAKE_CXX_STANDARD? >> >> Best Regards >> Roman >> >> Am 24.11.2016 um 19:08 schrieb Roman W?ger : >> >> Hello, >> >> >> >> If I use a small piece of code which uses , then it fails with >> check_cxx_source_compiles. If I copy the piece of code into a file and run >> the following on the command line, then it works: >> >> >> >> clang++ main.cpp -std=c++14 -stdlib=libc++ >> >> >> >> Here is the piece of code: >> >> >> >> #include >> >> #include >> >> >> >> int main() { >> >> const std::string text = "Roses are #ff0000, other flowers have other >> colors."; >> >> const std::regex pattern("#([a-f0-9]{2})"); >> >> >> >> std::smatch match; >> >> std::regex_search(text, match, pattern); >> >> >> >> return 0; >> >> } >> >> >> >> I use this code in CMake as a platform check as followed: >> >> >> >> # C++11 Regular Expression >> >> set(CMAKE_REQUIRED_FLAGS "${CMAKE_CXX_FLAGS}") >> >> check_cxx_source_compiles( >> >> "#include >> >> #include >> >> >> >> int main() { >> >> const std::string text = \"Roses are #ff0000, other flowers have >> other colors.\"; >> >> const std::regex pattern(\"#([a-f0-9]{2})\"); >> >> >> >> std::smatch match; >> >> std::regex_search(text, match, pattern); >> >> >> >> return 0; >> >> }" >> >> HAVE_CXX11_REGULAR_EXPRESSIONS >> >> ) >> >> set(CMAKE_REQUIRED_FLAGS "") >> >> >> >> CMakeFiles/CMakeError.log shows: >> >> >> >> Undefined symbols for architecture x86_64: >> >> "std::__1::basic_string, >> std::__1::allocator >::compare(char const*) const", referenced from: >> >> std::__1::basic_regex >> >::__start_matching_list(bool) in src.o >> >> "std::__1::__vector_base_common::__throw_length_error() const", >> referenced from: >> >> std::__1::vector, >> std::__1::allocator > >> >::assign(unsigned long, std::__1::sub_match const&) in src.o >> >> std::__1::vector, >> std::__1::allocator > >> >::allocate(unsigned long) in src.o >> >> void std::__1::vector, >> std::__1::allocator > >> >::__push_back_slow_path >> >(std::__1::__state&&) in src.o >> >> std::__1::vector, >> std::__1::allocator > >> >::__append(unsigned long, std::__1::sub_match const&) in src.o >> >> std::__1::vector, >> std::__1::allocator > >> >::__append(unsigned long) in src.o >> >> std::__1::vector, >> std::__1::allocator > >> >::allocate(unsigned long) in src.o >> >> void std::__1::vector >> >::__push_back_slow_path(char&&) in src.o >> >> ... >> >> "std::__1::__basic_string_common::__throw_length_error() const", >> referenced from: >> >> std::__1::enable_if<__is_forward_iterator::value, >> void>::type std::__1::basic_string, >> std::__1::allocator >::__init(char*, char*) in src.o >> >> std::__1::enable_if<__is_forward_iterator::value, >> void>::type std::__1::basic_string, >> std::__1::allocator >::__init(char const*, char const*) >> in src.o >> >> std::__1::enable_if<__is_forward_iterator >> >::value, void>::type std::__1::basic_string> std::__1::char_traits, std::__1::allocator >> >::__init >(std::__1::__wrap_iter, >> std::__1::__wrap_iter) in src.o >> >> "std::__1::__match_any_but_newline::__exec(std::__1::__state&) >> const", referenced from: >> >> vtable for std::__1::__match_any_but_newline in src.o >> >> "std::__1::locale::name() const", referenced from: >> >> std::__1::basic_regex >> >::__start_matching_list(bool) in src.o >> >> "std::__1::locale::use_facet(std::__1::locale::id&) const", referenced >> from: >> >> std::__1::regex_traits::__init() in src.o >> >> "std::__1::regex_error::regex_error(std::__1::regex_constants::error_type)", >> referenced from: >> >> char const* std::__1::basic_regex> std::__1::regex_traits >::__parse(char const*, char >> const*) in src.o >> >> char const* std::__1::basic_regex> std::__1::regex_traits >::__parse_basic_reg_exp(char >> const*, char const*) in src.o >> >> char const* std::__1::basic_regex> std::__1::regex_traits >::__parse_extended_reg_exp> const*>(char const*, char const*) in src.o >> >> char const* std::__1::basic_regex> std::__1::regex_traits >::__parse_assertion(char const*, >> char const*) in src.o >> >> char const* std::__1::basic_regex> std::__1::regex_traits >::__parse_atom(char const*, char >> const*) in src.o >> >> char const* std::__1::basic_regex> std::__1::regex_traits >::__parse_ERE_dupl_symbol> const*>(char const*, char const*, std::__1::__owns_one_state*, >> unsigned int, unsigned int) in src.o >> >> bool std::__1::basic_regex >> >::__match_at_start_ecma> const*> > >(char const*, char const*, std::__1::match_results> std::__1::allocator > >&, >> std::__1::regex_constants::match_flag_type, bool) const in src.o >> >> ... >> >> "std::__1::regex_error::~regex_error()", referenced from: >> >> char const* std::__1::basic_regex> std::__1::regex_traits >::__parse(char const*, char >> const*) in src.o >> >> char const* std::__1::basic_regex> std::__1::regex_traits >::__parse_basic_reg_exp(char >> const*, char const*) in src.o >> >> char const* std::__1::basic_regex> std::__1::regex_traits >::__parse_extended_reg_exp> const*>(char const*, char const*) in src.o >> >> char const* std::__1::basic_regex> std::__1::regex_traits >::__parse_assertion(char const*, >> char const*) in src.o >> >> char const* std::__1::basic_regex> std::__1::regex_traits >::__parse_atom(char const*, char >> const*) in src.o >> >> char const* std::__1::basic_regex> std::__1::regex_traits >::__parse_ERE_dupl_symbol> const*>(char const*, char const*, std::__1::__owns_one_state*, >> unsigned int, unsigned int) in src.o >> >> bool std::__1::basic_regex >> >::__match_at_start_ecma> const*> > >(char const*, char const*, std::__1::match_results> std::__1::allocator > >&, >> std::__1::regex_constants::match_flag_type, bool) const in src.o >> >> ... >> >> "std::__1::basic_string, >> std::__1::allocator >::__init(char const*, unsigned long)", >> referenced from: >> >> _main in src.o >> >> "std::__1::basic_string, >> std::__1::allocator >::__init(unsigned long, char)", referenced from: >> >> std::__1::__bracket_expression >> >::__exec(std::__1::__state&) const in src.o >> >> "std::__1::basic_string, >> std::__1::allocator >::reserve(unsigned long)", referenced from: >> >> std::__1::basic_string, >> std::__1::allocator > std::__1::regex_traits:: >> __lookup_collatename(char*, char*, char) const in src.o >> >> char const* std::__1::basic_regex> std::__1::regex_traits >::__parse_collating_symbol> const*>(char const*, char const*, std::__1::basic_string> std::__1::char_traits, std::__1::allocator >&) in src.o >> >> std::__1::basic_string, >> std::__1::allocator > std::__1::regex_traits::__lookup_collatename> const*>(char const*, char const*, char) const in src.o >> >> "std::__1::basic_string, >> std::__1::allocator >::basic_string(std::__1::basic_string> std::__1::char_traits, std::__1::allocator > const&)", >> referenced from: >> >> char const* std::__1::basic_regex> std::__1::regex_traits >::__parse_equivalence_class> const*>(char const*, char const*, std::__1::__bracket_expression> std::__1::regex_traits >*) in src.o >> >> void std::__1::vector> std::__1::char_traits, std::__1::allocator >, >> std::__1::allocator> std::__1::char_traits, std::__1::allocator > > >> >::__push_back_slow_path> std::__1::char_traits, std::__1::allocator > >> const&>(std::__1::basic_string, >> std::__1::allocator > const&&&) in src.o >> >> "std::__1::basic_string, >> std::__1::allocator >::~basic_string()", referenced from: >> >> _main in src.o >> >> std::__1::basic_regex >> >::__start_matching_list(bool) in src.o >> >> std::__1::__bracket_expression >> >::__exec(std::__1::__state&) const in src.o >> >> std::__1::__vector_base> std::__1::char_traits, std::__1::allocator >, >> std::__1::allocator> std::__1::char_traits, std::__1::allocator > > >> >::~__vector_base() in src.o >> >> std::__1::pair> std::__1::char_traits, std::__1::allocator >, >> std::__1::basic_string, >> std::__1::allocator > >::~pair() in src.o >> >> std::__1::basic_string, >> std::__1::allocator > std::__1::regex_traits::transform(char*, >> char*) const in src.o >> >> std::__1::basic_string, >> std::__1::allocator > std::__1::regex_traits:: >> __lookup_collatename(char*, char*, char) const in src.o >> >> ... >> >> "std::__1::basic_string, >> std::__1::allocator >::operator=(std::__1::basic_string> std::__1::char_traits, std::__1::allocator > const&)", >> referenced from: >> >> std::__1::basic_string, >> std::__1::allocator > std::__1::regex_traits:: >> __lookup_collatename(char*, char*, char) const in src.o >> >> std::__1::basic_string, >> std::__1::allocator > std::__1::regex_traits::__lookup_collatename> const*>(char const*, char const*, char) const in src.o >> >> "std::__1::basic_string, >> std::__1::allocator >::operator=(char)", referenced from: >> >> char const* std::__1::basic_regex> std::__1::regex_traits >::__parse_character_escape> const*>(char const*, char const*, std::__1::basic_string> std::__1::char_traits, std::__1::allocator >*) in src.o >> >> char const* std::__1::basic_regex> std::__1::regex_traits >::__parse_expression_term> const*>(char const*, char const*, std::__1::__bracket_expression> std::__1::regex_traits >*) in src.o >> >> char const* std::__1::basic_regex> std::__1::regex_traits >::__parse_class_escape(char >> const*, char const*, std::__1::basic_string> std::__1::char_traits, std::__1::allocator >&, >> std::__1::__bracket_expression >*) in >> src.o >> >> char const* std::__1::basic_regex> std::__1::regex_traits >::__parse_awk_escape(char >> const*, char const*, std::__1::basic_string> std::__1::char_traits, std::__1::allocator >*) in src.o >> >> "std::__1::__get_classname(char const*, bool)", referenced from: >> >> unsigned int std::__1::regex_traits::__lookup_classname> const*>(char const*, char const*, bool, char) const in src.o >> >> "std::__1::__shared_weak_count::__add_shared()", referenced from: >> >> std::__1::basic_regex >> >::basic_regex(std::__1::basic_regex >> > const&) in src.o >> >> "std::__1::__shared_weak_count::__release_shared()", referenced from: >> >> std::__1::shared_ptr >> >::~shared_ptr() in src.o >> >> "std::__1::__shared_weak_count::~__shared_weak_count()", referenced >> from: >> >> std::__1::__shared_ptr_pointer*, >> std::__1::default_delete >, >> std::__1::allocator > >> >::~__shared_ptr_pointer() in src.o >> >> "std::__1::__get_collation_name(char const*)", referenced from: >> >> std::__1::basic_string, >> std::__1::allocator > std::__1::regex_traits:: >> __lookup_collatename(char*, char*, char) const in src.o >> >> std::__1::basic_string, >> std::__1::allocator > std::__1::regex_traits::__lookup_collatename> const*>(char const*, char const*, char) const in src.o >> >> "std::__1::ctype::id", referenced from: >> >> std::__1::regex_traits::__init() in src.o >> >> "std::__1::locale::locale(std::__1::locale const&)", referenced from: >> >> std::__1::regex_traits::regex_traits(std::__1::regex_traits >> const&) in src.o >> >> std::__1::basic_regex >> >::__start_matching_list(bool) in src.o >> >> "std::__1::locale::locale()", referenced from: >> >> std::__1::regex_traits::regex_traits() in src.o >> >> "std::__1::locale::~locale()", referenced from: >> >> std::__1::regex_traits::~regex_traits() in src.o >> >> std::__1::regex_traits::regex_traits() in src.o >> >> std::__1::basic_regex >> >::__start_matching_list(bool) in src.o >> >> "std::__1::collate::id", referenced from: >> >> std::__1::regex_traits::__init() in src.o >> >> "typeinfo for std::__1::regex_error", referenced from: >> >> char const* std::__1::basic_regex> std::__1::regex_traits >::__parse(char const*, char >> const*) in src.o >> >> char const* std::__1::basic_regex> std::__1::regex_traits >::__parse_basic_reg_exp(char >> const*, char const*) in src.o >> >> char const* std::__1::basic_regex> std::__1::regex_traits >::__parse_extended_reg_exp> const*>(char const*, char const*) in src.o >> >> char const* std::__1::basic_regex> std::__1::regex_traits >::__parse_assertion(char const*, >> char const*) in src.o >> >> char const* std::__1::basic_regex> std::__1::regex_traits >::__parse_atom(char const*, char >> const*) in src.o >> >> char const* std::__1::basic_regex> std::__1::regex_traits >::__parse_ERE_dupl_symbol> const*>(char const*, char const*, std::__1::__owns_one_state*, >> unsigned int, unsigned int) in src.o >> >> bool std::__1::basic_regex >> >::__match_at_start_ecma> const*> > >(char const*, char const*, std::__1::match_results> std::__1::allocator > >&, >> std::__1::regex_constants::match_flag_type, bool) const in src.o >> >> ... >> >> "typeinfo for std::__1::__shared_weak_count", referenced from: >> >> typeinfo for std::__1::__shared_ptr_pointer >> *, std::__1::default_delete >> >, std::__1::allocator > > in src.o >> >> "vtable for std::__1::__shared_count", referenced from: >> >> std::__1::shared_ptr >> >::shared_ptr >> >(std::__1::__empty_state*, std::__1::enable_if> ible*, std::__1::__empty_state*>::value, >> std::__1::shared_ptr >::__nat>::type) in >> src.o >> >> NOTE: a missing vtable usually means the first non-inline virtual >> member function has no definition. >> >> "vtable for std::__1::__shared_weak_count", referenced from: >> >> std::__1::shared_ptr >> >::shared_ptr >> >(std::__1::__empty_state*, std::__1::enable_if> ible*, std::__1::__empty_state*>::value, >> std::__1::shared_ptr >::__nat>::type) in >> src.o >> >> NOTE: a missing vtable usually means the first non-inline virtual >> member function has no definition. >> >> ld: symbol(s) not found for architecture x86_64 >> >> clang: error: linker command failed with exit code 1 (use -v to see >> invocation) >> >> >> >> ** BUILD FAILED ** >> >> >> >> Did I forget something? >> >> >> >> Thanks in advance >> >> >> >> Best Regards >> >> Roman >> >> -- >> >> Powered by www.kitware.com >> >> Please keep messages on-topic and check the CMake FAQ at: >> http://www.cmake.org/Wiki/CMake_FAQ >> >> Kitware offers various services to support the CMake community. For more >> information on each offering, please visit: >> >> CMake Support: http://cmake.org/cmake/help/support.html >> CMake Consulting: http://cmake.org/cmake/help/consulting.html >> CMake Training Courses: http://cmake.org/cmake/help/training.html >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/cmake-developers >> >> >> -- >> >> Powered by www.kitware.com >> >> Please keep messages on-topic and check the CMake FAQ at: >> http://www.cmake.org/Wiki/CMake_FAQ >> >> Kitware offers various services to support the CMake community. For more >> information on each offering, please visit: >> >> CMake Support: http://cmake.org/cmake/help/support.html >> CMake Consulting: http://cmake.org/cmake/help/consulting.html >> CMake Training Courses: http://cmake.org/cmake/help/training.html >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/cmake-developers >> > > > > -- > 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 Fri Nov 25 17:26:57 2016 From: craig.scott at crascit.com (Craig Scott) Date: Sat, 26 Nov 2016 09:26:57 +1100 Subject: [CMake] [cmake-developers] C++11/C++14 doesn't work in check_cxx_source_compiles In-Reply-To: References: <01cb01d2467d$d2f7fed0$78e7fc70$@gmx.at> <963950B0-96D1-4D9C-A46E-CB3DA8D5A904@gmx.at> Message-ID: Sorry, bad link in that last email. The try_compile() docs I meant to link to are here: https://cmake.org/cmake/help/latest/command/try_compile.html#other-behavior-settings On Sat, Nov 26, 2016 at 9:23 AM, Craig Scott wrote: > Sorry, I misunderstood. I had a look through the > check_cxx_source_compiles() implementation and it basically forwards > through to a try_compile() call. Looking at the docs for try_compile(), > it says only the following are passed through to the temporary CMake > project created for the test compilation: > > > - CMAKE_ENABLE_EXPORTS > - CMAKE_LINK_SEARCH_START_STATIC > - CMAKE_LINK_SEARCH_END_STATIC > - CMAKE_POSITION_INDEPENDENT_CODE > > A few more can be passed through depending on policy settings, but it > looks like CMAKE_CXX_STANDARD, CMAKE_CXX_STANDARD_REQUIRED and > CMAKE_CXX_EXTENSIONS don't get passed through. So it looks like, at the > moment, you would have to manually pass through the relevant compiler and > linker flags to get sources built via try_compile() and therefore via > check_cxx_source_compiles(). I've recorded a new issue > in the issue > tracker for this. > > > > > > On Fri, Nov 25, 2016 at 9:25 PM, Roman W?ger wrote: > >> but it does not set/add the required library >> >> Am 24.11.2016 um 22:01 schrieb Craig Scott : >> >> You might also need to set CMAKE_CXX_EXTENSIONS >> >> to OFF (it's ON by default). This controls which c++ library is linked for >> some compilers, with clang and gcc being two cases where it does this. You >> may also find this article >> about the >> related CMake variables and commands to be of interest. >> >> On Fri, Nov 25, 2016 at 5:43 AM, Roman W?ger wrote: >> >>> It is working now, after I added -lc++ to CMAKE_REQUIRED_LIBRARIES >>> before the check_cxx_source_compiles() call. >>> >>> Shouldn't this be done by CMAKE_CXX_STANDARD? >>> >>> Best Regards >>> Roman >>> >>> Am 24.11.2016 um 19:08 schrieb Roman W?ger : >>> >>> Hello, >>> >>> >>> >>> If I use a small piece of code which uses , then it fails with >>> check_cxx_source_compiles. If I copy the piece of code into a file and run >>> the following on the command line, then it works: >>> >>> >>> >>> clang++ main.cpp -std=c++14 -stdlib=libc++ >>> >>> >>> >>> Here is the piece of code: >>> >>> >>> >>> #include >>> >>> #include >>> >>> >>> >>> int main() { >>> >>> const std::string text = "Roses are #ff0000, other flowers have >>> other colors."; >>> >>> const std::regex pattern("#([a-f0-9]{2})"); >>> >>> >>> >>> std::smatch match; >>> >>> std::regex_search(text, match, pattern); >>> >>> >>> >>> return 0; >>> >>> } >>> >>> >>> >>> I use this code in CMake as a platform check as followed: >>> >>> >>> >>> # C++11 Regular Expression >>> >>> set(CMAKE_REQUIRED_FLAGS "${CMAKE_CXX_FLAGS}") >>> >>> check_cxx_source_compiles( >>> >>> "#include >>> >>> #include >>> >>> >>> >>> int main() { >>> >>> const std::string text = \"Roses are #ff0000, other flowers have >>> other colors.\"; >>> >>> const std::regex pattern(\"#([a-f0-9]{2})\"); >>> >>> >>> >>> std::smatch match; >>> >>> std::regex_search(text, match, pattern); >>> >>> >>> >>> return 0; >>> >>> }" >>> >>> HAVE_CXX11_REGULAR_EXPRESSIONS >>> >>> ) >>> >>> set(CMAKE_REQUIRED_FLAGS "") >>> >>> >>> >>> CMakeFiles/CMakeError.log shows: >>> >>> >>> >>> Undefined symbols for architecture x86_64: >>> >>> "std::__1::basic_string, >>> std::__1::allocator >::compare(char const*) const", referenced from: >>> >>> std::__1::basic_regex >>> >::__start_matching_list(bool) in src.o >>> >>> "std::__1::__vector_base_common::__throw_length_error() const", >>> referenced from: >>> >>> std::__1::vector, >>> std::__1::allocator > >>> >::assign(unsigned long, std::__1::sub_match const&) in src.o >>> >>> std::__1::vector, >>> std::__1::allocator > >>> >::allocate(unsigned long) in src.o >>> >>> void std::__1::vector, >>> std::__1::allocator > >>> >::__push_back_slow_path >>> >(std::__1::__state&&) in src.o >>> >>> std::__1::vector, >>> std::__1::allocator > >>> >::__append(unsigned long, std::__1::sub_match const&) in src.o >>> >>> std::__1::vector, >>> std::__1::allocator > >>> >::__append(unsigned long) in src.o >>> >>> std::__1::vector, >>> std::__1::allocator > >>> >::allocate(unsigned long) in src.o >>> >>> void std::__1::vector >>> >::__push_back_slow_path(char&&) in src.o >>> >>> ... >>> >>> "std::__1::__basic_string_common::__throw_length_error() >>> const", referenced from: >>> >>> std::__1::enable_if<__is_forward_iterator::value, >>> void>::type std::__1::basic_string, >>> std::__1::allocator >::__init(char*, char*) in src.o >>> >>> std::__1::enable_if<__is_forward_iterator::value, >>> void>::type std::__1::basic_string, >>> std::__1::allocator >::__init(char const*, char const*) >>> in src.o >>> >>> std::__1::enable_if<__is_forward_iterator >>> >::value, void>::type std::__1::basic_string>> std::__1::char_traits, std::__1::allocator >>> >::__init >(std::__1::__wrap_iter, >>> std::__1::__wrap_iter) in src.o >>> >>> "std::__1::__match_any_but_newline::__exec(std::__1::__state&) >>> const", referenced from: >>> >>> vtable for std::__1::__match_any_but_newline in src.o >>> >>> "std::__1::locale::name() const", referenced from: >>> >>> std::__1::basic_regex >>> >::__start_matching_list(bool) in src.o >>> >>> "std::__1::locale::use_facet(std::__1::locale::id&) const", >>> referenced from: >>> >>> std::__1::regex_traits::__init() in src.o >>> >>> "std::__1::regex_error::regex_error(std::__1::regex_constants::error_type)", >>> referenced from: >>> >>> char const* std::__1::basic_regex>> std::__1::regex_traits >::__parse(char const*, char >>> const*) in src.o >>> >>> char const* std::__1::basic_regex>> std::__1::regex_traits >::__parse_basic_reg_exp(char >>> const*, char const*) in src.o >>> >>> char const* std::__1::basic_regex>> std::__1::regex_traits >::__parse_extended_reg_exp>> const*>(char const*, char const*) in src.o >>> >>> char const* std::__1::basic_regex>> std::__1::regex_traits >::__parse_assertion(char const*, >>> char const*) in src.o >>> >>> char const* std::__1::basic_regex>> std::__1::regex_traits >::__parse_atom(char const*, char >>> const*) in src.o >>> >>> char const* std::__1::basic_regex>> std::__1::regex_traits >::__parse_ERE_dupl_symbol>> const*>(char const*, char const*, std::__1::__owns_one_state*, >>> unsigned int, unsigned int) in src.o >>> >>> bool std::__1::basic_regex >>> >::__match_at_start_ecma>> const*> > >(char const*, char const*, std::__1::match_results>> std::__1::allocator > >&, >>> std::__1::regex_constants::match_flag_type, bool) const in src.o >>> >>> ... >>> >>> "std::__1::regex_error::~regex_error()", referenced from: >>> >>> char const* std::__1::basic_regex>> std::__1::regex_traits >::__parse(char const*, char >>> const*) in src.o >>> >>> char const* std::__1::basic_regex>> std::__1::regex_traits >::__parse_basic_reg_exp(char >>> const*, char const*) in src.o >>> >>> char const* std::__1::basic_regex>> std::__1::regex_traits >::__parse_extended_reg_exp>> const*>(char const*, char const*) in src.o >>> >>> char const* std::__1::basic_regex>> std::__1::regex_traits >::__parse_assertion(char const*, >>> char const*) in src.o >>> >>> char const* std::__1::basic_regex>> std::__1::regex_traits >::__parse_atom(char const*, char >>> const*) in src.o >>> >>> char const* std::__1::basic_regex>> std::__1::regex_traits >::__parse_ERE_dupl_symbol>> const*>(char const*, char const*, std::__1::__owns_one_state*, >>> unsigned int, unsigned int) in src.o >>> >>> bool std::__1::basic_regex >>> >::__match_at_start_ecma>> const*> > >(char const*, char const*, std::__1::match_results>> std::__1::allocator > >&, >>> std::__1::regex_constants::match_flag_type, bool) const in src.o >>> >>> ... >>> >>> "std::__1::basic_string, >>> std::__1::allocator >::__init(char const*, unsigned long)", >>> referenced from: >>> >>> _main in src.o >>> >>> "std::__1::basic_string, >>> std::__1::allocator >::__init(unsigned long, char)", referenced from: >>> >>> std::__1::__bracket_expression >>> >::__exec(std::__1::__state&) const in src.o >>> >>> "std::__1::basic_string, >>> std::__1::allocator >::reserve(unsigned long)", referenced from: >>> >>> std::__1::basic_string, >>> std::__1::allocator > std::__1::regex_traits:: >>> __lookup_collatename(char*, char*, char) const in src.o >>> >>> char const* std::__1::basic_regex>> std::__1::regex_traits >::__parse_collating_symbol>> const*>(char const*, char const*, std::__1::basic_string>> std::__1::char_traits, std::__1::allocator >&) in src.o >>> >>> std::__1::basic_string, >>> std::__1::allocator > std::__1::regex_traits::__lookup_collatename>> const*>(char const*, char const*, char) const in src.o >>> >>> "std::__1::basic_string, >>> std::__1::allocator >::basic_string(std::__1::basic_string>> std::__1::char_traits, std::__1::allocator > const&)", >>> referenced from: >>> >>> char const* std::__1::basic_regex>> std::__1::regex_traits >::__parse_equivalence_class>> const*>(char const*, char const*, std::__1::__bracket_expression>> std::__1::regex_traits >*) in src.o >>> >>> void std::__1::vector>> std::__1::char_traits, std::__1::allocator >, >>> std::__1::allocator>> std::__1::char_traits, std::__1::allocator > > >>> >::__push_back_slow_path>> std::__1::char_traits, std::__1::allocator > >>> const&>(std::__1::basic_string, >>> std::__1::allocator > const&&&) in src.o >>> >>> "std::__1::basic_string, >>> std::__1::allocator >::~basic_string()", referenced from: >>> >>> _main in src.o >>> >>> std::__1::basic_regex >>> >::__start_matching_list(bool) in src.o >>> >>> std::__1::__bracket_expression >>> >::__exec(std::__1::__state&) const in src.o >>> >>> std::__1::__vector_base>> std::__1::char_traits, std::__1::allocator >, >>> std::__1::allocator>> std::__1::char_traits, std::__1::allocator > > >>> >::~__vector_base() in src.o >>> >>> std::__1::pair>> std::__1::char_traits, std::__1::allocator >, >>> std::__1::basic_string, >>> std::__1::allocator > >::~pair() in src.o >>> >>> std::__1::basic_string, >>> std::__1::allocator > std::__1::regex_traits::transform(char*, >>> char*) const in src.o >>> >>> std::__1::basic_string, >>> std::__1::allocator > std::__1::regex_traits:: >>> __lookup_collatename(char*, char*, char) const in src.o >>> >>> ... >>> >>> "std::__1::basic_string, >>> std::__1::allocator >::operator=(std::__1::basic_string>> std::__1::char_traits, std::__1::allocator > const&)", >>> referenced from: >>> >>> std::__1::basic_string, >>> std::__1::allocator > std::__1::regex_traits:: >>> __lookup_collatename(char*, char*, char) const in src.o >>> >>> std::__1::basic_string, >>> std::__1::allocator > std::__1::regex_traits::__lookup_collatename>> const*>(char const*, char const*, char) const in src.o >>> >>> "std::__1::basic_string, >>> std::__1::allocator >::operator=(char)", referenced from: >>> >>> char const* std::__1::basic_regex>> std::__1::regex_traits >::__parse_character_escape>> const*>(char const*, char const*, std::__1::basic_string>> std::__1::char_traits, std::__1::allocator >*) in src.o >>> >>> char const* std::__1::basic_regex>> std::__1::regex_traits >::__parse_expression_term>> const*>(char const*, char const*, std::__1::__bracket_expression>> std::__1::regex_traits >*) in src.o >>> >>> char const* std::__1::basic_regex>> std::__1::regex_traits >::__parse_class_escape(char >>> const*, char const*, std::__1::basic_string>> std::__1::char_traits, std::__1::allocator >&, >>> std::__1::__bracket_expression >*) >>> in src.o >>> >>> char const* std::__1::basic_regex>> std::__1::regex_traits >::__parse_awk_escape(char >>> const*, char const*, std::__1::basic_string>> std::__1::char_traits, std::__1::allocator >*) in src.o >>> >>> "std::__1::__get_classname(char const*, bool)", referenced from: >>> >>> unsigned int std::__1::regex_traits::__lookup_classname>> const*>(char const*, char const*, bool, char) const in src.o >>> >>> "std::__1::__shared_weak_count::__add_shared()", referenced from: >>> >>> std::__1::basic_regex >>> >::basic_regex(std::__1::basic_regex >>> > const&) in src.o >>> >>> "std::__1::__shared_weak_count::__release_shared()", referenced from: >>> >>> std::__1::shared_ptr >>> >::~shared_ptr() in src.o >>> >>> "std::__1::__shared_weak_count::~__shared_weak_count()", referenced >>> from: >>> >>> std::__1::__shared_ptr_pointer*, >>> std::__1::default_delete >, >>> std::__1::allocator > >>> >::~__shared_ptr_pointer() in src.o >>> >>> "std::__1::__get_collation_name(char const*)", referenced from: >>> >>> std::__1::basic_string, >>> std::__1::allocator > std::__1::regex_traits:: >>> __lookup_collatename(char*, char*, char) const in src.o >>> >>> std::__1::basic_string, >>> std::__1::allocator > std::__1::regex_traits::__lookup_collatename>> const*>(char const*, char const*, char) const in src.o >>> >>> "std::__1::ctype::id", referenced from: >>> >>> std::__1::regex_traits::__init() in src.o >>> >>> "std::__1::locale::locale(std::__1::locale const&)", referenced from: >>> >>> std::__1::regex_traits::regex_traits(std::__1::regex_traits >>> const&) in src.o >>> >>> std::__1::basic_regex >>> >::__start_matching_list(bool) in src.o >>> >>> "std::__1::locale::locale()", referenced from: >>> >>> std::__1::regex_traits::regex_traits() in src.o >>> >>> "std::__1::locale::~locale()", referenced from: >>> >>> std::__1::regex_traits::~regex_traits() in src.o >>> >>> std::__1::regex_traits::regex_traits() in src.o >>> >>> std::__1::basic_regex >>> >::__start_matching_list(bool) in src.o >>> >>> "std::__1::collate::id", referenced from: >>> >>> std::__1::regex_traits::__init() in src.o >>> >>> "typeinfo for std::__1::regex_error", referenced from: >>> >>> char const* std::__1::basic_regex>> std::__1::regex_traits >::__parse(char const*, char >>> const*) in src.o >>> >>> char const* std::__1::basic_regex>> std::__1::regex_traits >::__parse_basic_reg_exp(char >>> const*, char const*) in src.o >>> >>> char const* std::__1::basic_regex>> std::__1::regex_traits >::__parse_extended_reg_exp>> const*>(char const*, char const*) in src.o >>> >>> char const* std::__1::basic_regex>> std::__1::regex_traits >::__parse_assertion(char const*, >>> char const*) in src.o >>> >>> char const* std::__1::basic_regex>> std::__1::regex_traits >::__parse_atom(char const*, char >>> const*) in src.o >>> >>> char const* std::__1::basic_regex>> std::__1::regex_traits >::__parse_ERE_dupl_symbol>> const*>(char const*, char const*, std::__1::__owns_one_state*, >>> unsigned int, unsigned int) in src.o >>> >>> bool std::__1::basic_regex >>> >::__match_at_start_ecma>> const*> > >(char const*, char const*, std::__1::match_results>> std::__1::allocator > >&, >>> std::__1::regex_constants::match_flag_type, bool) const in src.o >>> >>> ... >>> >>> "typeinfo for std::__1::__shared_weak_count", referenced from: >>> >>> typeinfo for std::__1::__shared_ptr_pointer >>> *, std::__1::default_delete >>> >, std::__1::allocator > > in src.o >>> >>> "vtable for std::__1::__shared_count", referenced from: >>> >>> std::__1::shared_ptr >>> >::shared_ptr >>> >(std::__1::__empty_state*, std::__1::enable_if>> ible*, std::__1::__empty_state*>::value, >>> std::__1::shared_ptr >::__nat>::type) in >>> src.o >>> >>> NOTE: a missing vtable usually means the first non-inline virtual >>> member function has no definition. >>> >>> "vtable for std::__1::__shared_weak_count", referenced from: >>> >>> std::__1::shared_ptr >>> >::shared_ptr >>> >(std::__1::__empty_state*, std::__1::enable_if>> ible*, std::__1::__empty_state*>::value, >>> std::__1::shared_ptr >::__nat>::type) in >>> src.o >>> >>> NOTE: a missing vtable usually means the first non-inline virtual >>> member function has no definition. >>> >>> ld: symbol(s) not found for architecture x86_64 >>> >>> clang: error: linker command failed with exit code 1 (use -v to see >>> invocation) >>> >>> >>> >>> ** BUILD FAILED ** >>> >>> >>> >>> Did I forget something? >>> >>> >>> >>> Thanks in advance >>> >>> >>> >>> Best Regards >>> >>> Roman >>> >>> -- >>> >>> Powered by www.kitware.com >>> >>> Please keep messages on-topic and check the CMake FAQ at: >>> http://www.cmake.org/Wiki/CMake_FAQ >>> >>> Kitware offers various services to support the CMake community. For more >>> information on each offering, please visit: >>> >>> CMake Support: http://cmake.org/cmake/help/support.html >>> CMake Consulting: http://cmake.org/cmake/help/consulting.html >>> CMake Training Courses: http://cmake.org/cmake/help/training.html >>> >>> Visit other Kitware open-source projects at >>> http://www.kitware.com/opensource/opensource.html >>> >>> Follow this link to subscribe/unsubscribe: >>> http://public.kitware.com/mailman/listinfo/cmake-developers >>> >>> >>> -- >>> >>> Powered by www.kitware.com >>> >>> Please keep messages on-topic and check the CMake FAQ at: >>> http://www.cmake.org/Wiki/CMake_FAQ >>> >>> Kitware offers various services to support the CMake community. For more >>> information on each offering, please visit: >>> >>> CMake Support: http://cmake.org/cmake/help/support.html >>> CMake Consulting: http://cmake.org/cmake/help/consulting.html >>> CMake Training Courses: http://cmake.org/cmake/help/training.html >>> >>> Visit other Kitware open-source projects at >>> http://www.kitware.com/opensource/opensource.html >>> >>> Follow this link to subscribe/unsubscribe: >>> http://public.kitware.com/mailman/listinfo/cmake-developers >>> >> >> >> >> -- >> 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 gjasny at googlemail.com Sat Nov 26 03:29:14 2016 From: gjasny at googlemail.com (Gregor Jasny) Date: Sat, 26 Nov 2016 09:29:14 +0100 Subject: [CMake] v3.7.0 - archive_cryptor_private.h - compile error In-Reply-To: References: Message-ID: <8e0a995c-2506-b6ad-d0b3-1bfe5201ddfa@googlemail.com> Hello, On 25/11/2016 19:25, Nathan Sizemore wrote: > I receive the following when building: > > [ 40%] Building C object > Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_cryptor.c.o > In file included from > /home/nathan/development/cmake/Utilities/cmlibarchive/libarchive/archive_cryptor.c:32:0: > /home/nathan/development/cmake/Utilities/cmlibarchive/libarchive/archive_cryptor_private.h:107:17: > error: field ?ctx? has incomplete type > EVP_CIPHER_CTX ctx; You are using the embedded copy of libarchive. I would suggest you install the Debian CMake package build dependencies: apt-get build-dep cmake so that you use the system libraries instead of the embedded ones. Hopefully this will resolve your issue. Thanks, Gregor From post at hendrik-sattler.de Sat Nov 26 04:03:02 2016 From: post at hendrik-sattler.de (Hendrik Sattler) Date: Sat, 26 Nov 2016 10:03:02 +0100 Subject: [CMake] v3.7.0 - archive_cryptor_private.h - compile error In-Reply-To: <8e0a995c-2506-b6ad-d0b3-1bfe5201ddfa@googlemail.com> References: <8e0a995c-2506-b6ad-d0b3-1bfe5201ddfa@googlemail.com> Message-ID: I assume that maybe he tries to build with openssl 1.1 Am 26. November 2016 09:29:14 MEZ, schrieb Gregor Jasny via CMake : >Hello, > >On 25/11/2016 19:25, Nathan Sizemore wrote: >> I receive the following when building: >> >> [ 40%] Building C object >> >Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_cryptor.c.o >> In file included from >> >/home/nathan/development/cmake/Utilities/cmlibarchive/libarchive/archive_cryptor.c:32:0: >> >/home/nathan/development/cmake/Utilities/cmlibarchive/libarchive/archive_cryptor_private.h:107:17: >> error: field ?ctx? has incomplete type >> EVP_CIPHER_CTX ctx; > >You are using the embedded copy of libarchive. I would suggest you >install the Debian CMake package build dependencies: > > apt-get build-dep cmake > >so that you use the system libraries instead of the embedded ones. >Hopefully this will resolve your issue. > >Thanks, >Gregor >-- > >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 gjasny at googlemail.com Sat Nov 26 12:52:11 2016 From: gjasny at googlemail.com (Gregor Jasny) Date: Sat, 26 Nov 2016 18:52:11 +0100 Subject: [CMake] v3.7.0 - archive_cryptor_private.h - compile error In-Reply-To: References: <8e0a995c-2506-b6ad-d0b3-1bfe5201ddfa@googlemail.com> Message-ID: On 26/11/2016 10:03, Hendrik Sattler wrote: > I assume that maybe he tries to build with openssl 1.1 You're right. I assumed that "Debian GNU/Linux 8" does not contain OpenSSL 1.1 but either the Debian version or OpenSSL version on Nathans system is wrong. > Am 26. November 2016 09:29:14 MEZ, schrieb Gregor Jasny via CMake : >> Hello, >> >> On 25/11/2016 19:25, Nathan Sizemore wrote: >>> I receive the following when building: >>> >>> [ 40%] Building C object >>> >> Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_cryptor.c.o >>> In file included from >>> >> /home/nathan/development/cmake/Utilities/cmlibarchive/libarchive/archive_cryptor.c:32:0: >>> >> /home/nathan/development/cmake/Utilities/cmlibarchive/libarchive/archive_cryptor_private.h:107:17: >>> error: field ?ctx? has incomplete type >>> EVP_CIPHER_CTX ctx; >> >> You are using the embedded copy of libarchive. I would suggest you >> install the Debian CMake package build dependencies: >> >> apt-get build-dep cmake >> >> so that you use the system libraries instead of the embedded ones. >> Hopefully this will resolve your issue. I reproduced the error on my Debian Sid machine, filed a bug against CMake (https://gitlab.kitware.com/cmake/cmake/issues/16459) only to discover that Brad King already filed a PR against upstream libarchive. The following should solve Nathans problem: apt-get build-dep cmake apt-get install librhash-dev cd <> mkdir _build cd _build ../bootstrap --system-libs make See: https://anonscm.debian.org/cgit/pkg-cmake/cmake.git/tree/debian/rules#n43 Debians libarchive does not use OpenSSL but nettle instead so the OpenSSL incompatibility does not show up. Thanks, Gregor From nathanrsizemore at gmail.com Sat Nov 26 23:40:38 2016 From: nathanrsizemore at gmail.com (Nathan Sizemore) Date: Sat, 26 Nov 2016 23:40:38 -0500 Subject: [CMake] v3.7.0 - archive_cryptor_private.h - compile error In-Reply-To: References: <8e0a995c-2506-b6ad-d0b3-1bfe5201ddfa@googlemail.com> Message-ID: Yes, it was the OpenSSL version. I have a few installed, but didn't know to build against a certain version, thanks! Debian 8 has 1.0.1t currently. Nathan Sizemore 937-668-7495 | @nathansizemore On Sat, Nov 26, 2016 at 12:52 PM, Gregor Jasny wrote: > On 26/11/2016 10:03, Hendrik Sattler wrote: >> I assume that maybe he tries to build with openssl 1.1 > > You're right. I assumed that "Debian GNU/Linux 8" does not contain > OpenSSL 1.1 but either the Debian version or OpenSSL version on Nathans > system is wrong. > >> Am 26. November 2016 09:29:14 MEZ, schrieb Gregor Jasny via CMake : >>> Hello, >>> >>> On 25/11/2016 19:25, Nathan Sizemore wrote: >>>> I receive the following when building: >>>> >>>> [ 40%] Building C object >>>> >>> Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_cryptor.c.o >>>> In file included from >>>> >>> /home/nathan/development/cmake/Utilities/cmlibarchive/libarchive/archive_cryptor.c:32:0: >>>> >>> /home/nathan/development/cmake/Utilities/cmlibarchive/libarchive/archive_cryptor_private.h:107:17: >>>> error: field ?ctx? has incomplete type >>>> EVP_CIPHER_CTX ctx; >>> >>> You are using the embedded copy of libarchive. I would suggest you >>> install the Debian CMake package build dependencies: >>> >>> apt-get build-dep cmake >>> >>> so that you use the system libraries instead of the embedded ones. >>> Hopefully this will resolve your issue. > > I reproduced the error on my Debian Sid machine, filed a bug against > CMake (https://gitlab.kitware.com/cmake/cmake/issues/16459) only to > discover that Brad King already filed a PR against upstream libarchive. > > The following should solve Nathans problem: > > apt-get build-dep cmake > apt-get install librhash-dev > cd <> > mkdir _build > cd _build > ../bootstrap --system-libs > make > > See: > https://anonscm.debian.org/cgit/pkg-cmake/cmake.git/tree/debian/rules#n43 > > Debians libarchive does not use OpenSSL but nettle instead so the > OpenSSL incompatibility does not show up. > > Thanks, > Gregor From kit.chambers.kc at gmail.com Mon Nov 28 04:28:33 2016 From: kit.chambers.kc at gmail.com (Kit Chambers) Date: Mon, 28 Nov 2016 09:28:33 +0000 Subject: [CMake] Executing python though CMake and linking libraries In-Reply-To: References: <0AA0C3D8-580A-464F-A241-C934AD9FD45E@googlemail.com> Message-ID: <69BA8E31-6039-4A0A-B4A2-D4AE75A787A0@googlemail.com> I just got this working, so am posting to the list in case this helps someone else in the future. Essentially you invoke the python script through CMakes -E command and specify your library paths so it picks up all your shared libraries. Something like: add_custom_target(run COMMAND cmake "-E" "env" ?LD_LIBRARY_PATH=/your/library/path DYLD_LIBRARY_PATH=/library/path/for/mac/" ?python? ?./myscript.py? WORKING_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR} ) However, I will be the first to admit this is not a particularly elegant solution so I would be interested to here if anyone out there has a better way of getting invoked commands to pick up the environment paths correctly. Kit > On 25 Nov 2016, at 13:23, tonka3100 at gmail.com wrote: > > Hey, > > I think your actual working directory is wrong. I would recommend to use absolute paths for the python interperter (there is a find_package module for the interpreter) and maybe also for your script. The custom command support a workingdirectory variable as far as i know. > > Hope that help you. > > Greetings > Tonka > >> Am 25.11.2016 um 10:04 schrieb Kit Chambers : >> >> I have a Cmake custom target which runs a python script: >> >> add_custom_target(run >> COMMAND python myscript.py >> ) >> >> And the script myscript.py imports a Compiled library >> >> import myproj.mylilb >> >> where mylib is actually a C++ library generated with python bindings (using vtkPython). This intern links against some other C++ libraries I use etc. >> >> >> When I run the script normally from the command line everything works fine, but if I try to run the target I get linker errors. >> >> $ make run >> >> Traceback (most recent call last): >> File "myscript.py", line 8, in >> import myproj.mylilb >> ImportError: dlopen(/Users/kitchambers/Applications/ogFramework/lib/python2.7/site-packages/myproj/mylib.so, 2): Library not loaded: libSpProcSupport.so >> Referenced from: /Users/kitchambers/Applications/ogFramework/lib/python2.7/site-packages/myproj/mylib.so >> Reason: image not found >> >> To me it looks like my LD_LIBRARY_PATH and DYLD_LIBRARY_PATH are not being passed through CMake to Python so it cannot find all the necessary sub libraries. However, i cannot work out how to pass this information through. >> >> Any help would be greatly appreciated. >> >> Cheers >> >> Kit >> -- >> >> Powered by www.kitware.com >> >> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ >> >> Kitware offers various services to support the CMake community. For more information on each offering, please visit: >> >> CMake Support: http://cmake.org/cmake/help/support.html >> CMake Consulting: http://cmake.org/cmake/help/consulting.html >> CMake Training Courses: http://cmake.org/cmake/help/training.html >> >> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/cmake From brad.king at kitware.com Mon Nov 28 09:57:50 2016 From: brad.king at kitware.com (Brad King) Date: Mon, 28 Nov 2016 09:57:50 -0500 Subject: [CMake] [cmake-developers] C++11/C++14 doesn't work in check_cxx_source_compiles In-Reply-To: References: <01cb01d2467d$d2f7fed0$78e7fc70$@gmx.at> Message-ID: On 11/24/2016 01:43 PM, Roman W?ger wrote: > Shouldn't this be done by CMAKE_CXX_STANDARD? Yes, this is a known problem with try_compile. It needs to learn to honor the CMAKE__STANDARD. CMake itself works around this problem in some cases, e.g. * https://gitlab.kitware.com/cmake/cmake/blob/v3.7.0/Source/Checks/cm_cxx14_cstdio.cmake#L8 Here is a new issue for this: * https://gitlab.kitware.com/cmake/cmake/issues/16456 -Brad From chuck.atkins at kitware.com Mon Nov 28 09:58:17 2016 From: chuck.atkins at kitware.com (Chuck Atkins) Date: Mon, 28 Nov 2016 09:58:17 -0500 Subject: [CMake] FindMPI In-Reply-To: References: Message-ID: Pass the following CMake options at configure time: -DMPI_C_COMPILER=/path/to/mpicc -DMPI_CXX_COMPILER=/path/to/mpiCC -DMPI_Fortran_COMPILER=/path/to/mpif90 ---------- Chuck Atkins Staff R&D Engineer, Scientific Computing Kitware, Inc. On Wed, Nov 23, 2016 at 6:05 PM, Zaak Beekman wrote: > Hi, > > I want to be able to pass FC=mpif90 (or FC=$(which mpif90)) and CC=mpicc > etc. OR also be able to pass a compiler and use FindMPI to add link, > compile and include flags. I'm encountering an issue when my MPI > implementation is not on my PATH, I want CMake to be able to look in an > additional location (our build script can download and build MPICH and by > default installs it in user space) and also resolve where mpif90 is coming > from and look there too. > > Whats the correct way to pass HINTS or PATHS to FindMPI? i.e., how do I > specify additional locations to search? > > Using `find_package` with HINTS and PATHS means that it doesn't use > FindMPI. I also tried setting CMAKE_SYSTEM PREFIX_PATH, but I think that's > a cache variable set early, so it's not having an effect. > > It would be great if FindMPI used the realpath of mpif90 etc when passed > as $FC. > > TIA > > -- > > 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 chuck.atkins at kitware.com Mon Nov 28 10:02:09 2016 From: chuck.atkins at kitware.com (Chuck Atkins) Date: Mon, 28 Nov 2016 10:02:09 -0500 Subject: [CMake] FindMPI In-Reply-To: References: Message-ID: Hi Zaak, When using CMake, it's generally best to use the actual compiler rather than any compiler wrappers (with Cray being the exception). Given that, set the CC, CXX, and FC environment variables to the actual compilers you want to use and then the MPI_{C,CXX,Fortan}_COMPILER CMake variables the MPI wrappers. FindMPI will then interrogate the MPI wrappers to extract the appropriate include and link options. ---------- Chuck Atkins Staff R&D Engineer, Scientific Computing Kitware, Inc. On Mon, Nov 28, 2016 at 9:58 AM, Chuck Atkins wrote: > Pass the following CMake options at configure time: > > -DMPI_C_COMPILER=/path/to/mpicc > -DMPI_CXX_COMPILER=/path/to/mpiCC > -DMPI_Fortran_COMPILER=/path/to/mpif90 > > ---------- > Chuck Atkins > Staff R&D Engineer, Scientific Computing > Kitware, Inc. > > > On Wed, Nov 23, 2016 at 6:05 PM, Zaak Beekman wrote: > >> Hi, >> >> I want to be able to pass FC=mpif90 (or FC=$(which mpif90)) and CC=mpicc >> etc. OR also be able to pass a compiler and use FindMPI to add link, >> compile and include flags. I'm encountering an issue when my MPI >> implementation is not on my PATH, I want CMake to be able to look in an >> additional location (our build script can download and build MPICH and by >> default installs it in user space) and also resolve where mpif90 is coming >> from and look there too. >> >> Whats the correct way to pass HINTS or PATHS to FindMPI? i.e., how do I >> specify additional locations to search? >> >> Using `find_package` with HINTS and PATHS means that it doesn't use >> FindMPI. I also tried setting CMAKE_SYSTEM PREFIX_PATH, but I think that's >> a cache variable set early, so it's not having an effect. >> >> It would be great if FindMPI used the realpath of mpif90 etc when passed >> as $FC. >> >> TIA >> >> -- >> >> 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 zbeekman at gmail.com Mon Nov 28 10:02:26 2016 From: zbeekman at gmail.com (Zaak Beekman) Date: Mon, 28 Nov 2016 15:02:26 +0000 Subject: [CMake] FindMPI In-Reply-To: References: Message-ID: Chuck, thanks for the response! The issue with your technique is that I don't want to put the burden on the users... I took a look at the FindMPI CMake module, and it seems as though you can set MPI_HOME to a list of directories to search. Would KitWare accept a pull request or a patch that expands the documentation of FindMPI and/or adds some clearer additional features to the call signature (like HINTS and PATHS)? Thanks, -Zaak On Mon, Nov 28, 2016 at 9:58 AM Chuck Atkins wrote: > Pass the following CMake options at configure time: > > -DMPI_C_COMPILER=/path/to/mpicc > -DMPI_CXX_COMPILER=/path/to/mpiCC > -DMPI_Fortran_COMPILER=/path/to/mpif90 > > ---------- > Chuck Atkins > Staff R&D Engineer, Scientific Computing > Kitware, Inc. > > > On Wed, Nov 23, 2016 at 6:05 PM, Zaak Beekman wrote: > > Hi, > > I want to be able to pass FC=mpif90 (or FC=$(which mpif90)) and CC=mpicc > etc. OR also be able to pass a compiler and use FindMPI to add link, > compile and include flags. I'm encountering an issue when my MPI > implementation is not on my PATH, I want CMake to be able to look in an > additional location (our build script can download and build MPICH and by > default installs it in user space) and also resolve where mpif90 is coming > from and look there too. > > Whats the correct way to pass HINTS or PATHS to FindMPI? i.e., how do I > specify additional locations to search? > > Using `find_package` with HINTS and PATHS means that it doesn't use > FindMPI. I also tried setting CMAKE_SYSTEM PREFIX_PATH, but I think that's > a cache variable set early, so it's not having an effect. > > It would be great if FindMPI used the realpath of mpif90 etc when passed > as $FC. > > TIA > > -- > > 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 zbeekman at gmail.com Mon Nov 28 10:09:27 2016 From: zbeekman at gmail.com (Zaak Beekman) Date: Mon, 28 Nov 2016 15:09:27 +0000 Subject: [CMake] FindMPI In-Reply-To: References: Message-ID: Thanks for the additional pointers Chuck! I am aware that it is preferred practice to pass the actual compilers rather than the wrappers as FC etc. but per Brad's advice I think Damian had setup the OpenCoarrays CMake build system to accept FC=mpif90 etc. and I'm in the process of migrating to the more normal FC=gfortran etc. approach but I don't want users who use the old method to get caught out. I'll try setting MPI_{C,etc.}_COMPILER (rather than MPI_HOME) before calling `find_package(MPI)` and see if that works as well as setting MPI_HOME does. Thanks for the tips! On Mon, Nov 28, 2016 at 10:02 AM Chuck Atkins wrote: > Hi Zaak, > > When using CMake, it's generally best to use the actual compiler rather > than any compiler wrappers (with Cray being the exception). Given that, > set the CC, CXX, and FC environment variables to the actual compilers you > want to use and then the MPI_{C,CXX,Fortan}_COMPILER CMake variables the > MPI wrappers. FindMPI will then interrogate the MPI wrappers to extract > the appropriate include and link options. > > ---------- > Chuck Atkins > Staff R&D Engineer, Scientific Computing > Kitware, Inc. > > > On Mon, Nov 28, 2016 at 9:58 AM, Chuck Atkins > wrote: > > Pass the following CMake options at configure time: > > -DMPI_C_COMPILER=/path/to/mpicc > -DMPI_CXX_COMPILER=/path/to/mpiCC > -DMPI_Fortran_COMPILER=/path/to/mpif90 > > ---------- > Chuck Atkins > Staff R&D Engineer, Scientific Computing > Kitware, Inc. > > > On Wed, Nov 23, 2016 at 6:05 PM, Zaak Beekman wrote: > > Hi, > > I want to be able to pass FC=mpif90 (or FC=$(which mpif90)) and CC=mpicc > etc. OR also be able to pass a compiler and use FindMPI to add link, > compile and include flags. I'm encountering an issue when my MPI > implementation is not on my PATH, I want CMake to be able to look in an > additional location (our build script can download and build MPICH and by > default installs it in user space) and also resolve where mpif90 is coming > from and look there too. > > Whats the correct way to pass HINTS or PATHS to FindMPI? i.e., how do I > specify additional locations to search? > > Using `find_package` with HINTS and PATHS means that it doesn't use > FindMPI. I also tried setting CMAKE_SYSTEM PREFIX_PATH, but I think that's > a cache variable set early, so it's not having an effect. > > It would be great if FindMPI used the realpath of mpif90 etc when passed > as $FC. > > TIA > > -- > > 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 chuck.atkins at kitware.com Mon Nov 28 10:21:54 2016 From: chuck.atkins at kitware.com (Chuck Atkins) Date: Mon, 28 Nov 2016 10:21:54 -0500 Subject: [CMake] FindMPI In-Reply-To: References: Message-ID: Hi Zaak, Sorry for the first mail being so abrupt, I didn't mean to hit "send" so soon. > I took a look at the FindMPI CMake module, and it seems as though you can > set MPI_HOME to a list of directories to search. > That's also another way of doing it, which would probably be easier than what I iniitially suggested; the former has just become my own habbit since MPI_HOME isn't always set. MPI_HOME is used as a hint to search for mpiexec. If mpiexec is found, it then uses it's location as a basis for locating the compiler wrappers. That being said, if using MPI through an environment module (as is the typical use case) then FindMPI should "just work" as the wrappers generally end up in the path when the appropriate MPI module is loaded. If you need to point to an entirely external MPI not part of your environment at all though, then using the MPI_HOME env var or MPI__COMPILER CMake vars is the way to do it. > Would KitWare accept a pull request or a patch that expands the > documentation of FindMPI > Of course :-). Expanding the "Usage" section in FindMPI to include using the MPI_HOME environment variable would be a good place for that. > and/or adds some clearer additional features to the call signature (like > HINTS and PATHS)? > Could you clarify what you mean by this? To which call signature? - Chuck -------------- next part -------------- An HTML attachment was scrubbed... URL: From mwoehlke.floss at gmail.com Mon Nov 28 12:27:38 2016 From: mwoehlke.floss at gmail.com (Matthew Woehlke) Date: Mon, 28 Nov 2016 12:27:38 -0500 Subject: [CMake] Executing python though CMake and linking libraries In-Reply-To: <0AA0C3D8-580A-464F-A241-C934AD9FD45E@googlemail.com> References: <0AA0C3D8-580A-464F-A241-C934AD9FD45E@googlemail.com> Message-ID: On 2016-11-25 04:04, Kit Chambers wrote: > I have a Cmake custom target which runs a python script: > > add_custom_target(run > COMMAND python myscript.py > ) > > ... > > To me it looks like my LD_LIBRARY_PATH and DYLD_LIBRARY_PATH are not being passed through CMake to Python so it cannot find all the necessary sub libraries. However, i cannot work out how to pass this information through. As written, your custom target will be run with whatever environment your build tool decides to use. *Probably* that will be the environment when you actually run the build tool (make, ninja, etc.), but it's possible some build too might monkey with the environment in which it runs build commands. Also, requiring people building your software to modify their local environment is probably not ideal. You probably want to wrap your custom target's command with `${CMAKE_COMMAND} -E env ...` to ensure it gets the necessary environment. (Also, you should probably use `${PYTHON_EXECUTABLE}` instead of `python`, and, similarly, note `${CMAKE_COMMAND}` instead of `cmake`.) (Personally, I wouldn't mind seeing CMake learn an `ENVIRONMENT` option to add_custom_command / add_custom_target that would set up this wrapping automatically.) -- Matthew From annulen at yandex.ru Mon Nov 28 13:56:04 2016 From: annulen at yandex.ru (Konstantin Tokarev) Date: Mon, 28 Nov 2016 21:56:04 +0300 Subject: [CMake] Executing python though CMake and linking libraries In-Reply-To: References: <0AA0C3D8-580A-464F-A241-C934AD9FD45E@googlemail.com> Message-ID: <338771480359364@web34m.yandex.ru> 28.11.2016, 21:53, "Matthew Woehlke" : > On 2016-11-25 04:04, Kit Chambers wrote: >> ?I have a Cmake custom target which runs a python script: >> >> ?add_custom_target(run >> ??????????????????COMMAND python myscript.py >> ???????????????????) >> >> ?... >> >> ?To me it looks like my LD_LIBRARY_PATH and DYLD_LIBRARY_PATH are not being passed through CMake to Python so it cannot find all the necessary sub libraries. However, i cannot work out how to pass this information through. > > As written, your custom target will be run with whatever environment > your build tool decides to use. *Probably* that will be the environment > when you actually run the build tool (make, ninja, etc.), but it's > possible some build too might monkey with the environment in which it > runs build commands. Also, requiring people building your software to > modify their local environment is probably not ideal. > > You probably want to wrap your custom target's command with > `${CMAKE_COMMAND} -E env ...` to ensure it gets the necessary > environment. (Also, you should probably use `${PYTHON_EXECUTABLE}` > instead of `python`, and, similarly, note `${CMAKE_COMMAND}` instead of > `cmake`.) > > (Personally, I wouldn't mind seeing CMake learn an `ENVIRONMENT` option > to add_custom_command / add_custom_target that would set up this > wrapping automatically.) +1 > > -- > Matthew > > -- > > 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 rcdailey.lists at gmail.com Mon Nov 28 11:35:26 2016 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Mon, 28 Nov 2016 10:35:26 -0600 Subject: [CMake] VS2017 + CMake integration In-Reply-To: References: Message-ID: Thanks for the feedback Marian! If/when you rebase to CMake 3.7, how will that package be delivered to Visual Studio customers? My real concern stems from basically our minimum required version of CMake for our specific scripts. The minimum is 3.7 due to the awesome Android integration added in that version. Which means obviously I can't use the bundled version of CMake in VS currently. On Wed, Nov 23, 2016 at 1:57 PM, Marian Luparu wrote: > Thanks Robert -- this is great feedback > > Yes, VS ships with a patched 3.6 CMake that includes both changes to find the VS 2017 installation as well as the CMake-Server functionality needed for the IDE services. We have not yet started upstreaming these changes (got totally sidetracked by getting the VS 2017 RC release out the door) but are absolutely committed to do so. As a first step, we will be rebasing our changes to the 3.7 CMake release and then start contributing these pieces. > > Once the changes are in PR, at a minimum, you will be able to compile your own version of CMake if you wanted to, to replace the one shipping in VS. But currently, to answer your other question, we have no capability of pointing VS to a different version of CMake. That's primarily because of the thick-coupling between VS and the custom patches we need in CMake to make the end-to-end experience work. > > Thanks, > Marian Luparu > Visual C++ PM Lead > > -----Original Message----- > From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Robert Dailey > Sent: Tuesday, November 22, 2016 10:58 AM > To: CMake > Subject: [CMake] VS2017 + CMake integration > > First of all, I personally find the CMake integration in Visual Studio just absolutely amazing. Granted I am not doing any cross-compiling with Android yet, but for just building on Windows it's phenomenal. > > I noticed that Visual Studio 2017 RC is actually packaging its own version of CMake: > > E:\PROGRAM FILES (X86)\MICROSOFT VISUAL > STUDIO\2017\PROFESSIONAL\COMMON7\IDE\COMMONEXTENSIONS\MICROSOFT\CMAKE\CMake\bin\cmake.exe > > Is Microsoft patching the CMake code base to support what they are doing? And if so, are those changes not upstream yet? Personally, I'd rather have the ability to tell Visual Studio to use my external version of CMake that is on PATH, rather than its own. I can understand if that isn't possible right now due to custom changes, but I'm curious to learn more, assuming Kitware has had a partnership with Microsoft for this integration with Visual Studio. > > Would anyone be able to provide more news here? Is there a way to make VS 2017 use my separate install of CMake? Are the Microsoft-specific patches contributed to upstream (or planned to be)? > -- > > Powered by https://na01.safelinks.protection.outlook.com/?url=www.kitware.com&data=02%7C01%7Cmluparu%40microsoft.com%7C00957bc2ac4847ee794f08d413098464%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636154378985417863&sdata=Plv73v%2B4m3KwGsh6VinIPPgg1qUsCdmDlx%2F9U2urOqA%3D&reserved=0 > > Please keep messages on-topic and check the CMake FAQ at: https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.cmake.org%2FWiki%2FCMake_FAQ&data=02%7C01%7Cmluparu%40microsoft.com%7C00957bc2ac4847ee794f08d413098464%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636154378985417863&sdata=qBtWeiauHkzD7ISZxtqz3Q72SaDZZwKwdY%2F1voAI2U8%3D&reserved=0 > > Kitware offers various services to support the CMake community. For more information on each offering, please visit: > > CMake Support: https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcmake.org%2Fcmake%2Fhelp%2Fsupport.html&data=02%7C01%7Cmluparu%40microsoft.com%7C00957bc2ac4847ee794f08d413098464%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636154378985417863&sdata=NZgcc%2BxtLPkIWXjqcIwItZr7KXAe6cqbcQaLpAMMA9Q%3D&reserved=0 > CMake Consulting: https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcmake.org%2Fcmake%2Fhelp%2Fconsulting.html&data=02%7C01%7Cmluparu%40microsoft.com%7C00957bc2ac4847ee794f08d413098464%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636154378985417863&sdata=YXiCCEGtOMh3qvpKtXTgiL86czKy8xedQbUOoFaTsXA%3D&reserved=0 > CMake Training Courses: https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcmake.org%2Fcmake%2Fhelp%2Ftraining.html&data=02%7C01%7Cmluparu%40microsoft.com%7C00957bc2ac4847ee794f08d413098464%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636154378985417863&sdata=Paz%2Ft%2Bm63qi1AavokeWDNrR69wIUD2Tzjuyp7gUHORk%3D&reserved=0 > > Visit other Kitware open-source projects at https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.kitware.com%2Fopensource%2Fopensource.html&data=02%7C01%7Cmluparu%40microsoft.com%7C00957bc2ac4847ee794f08d413098464%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636154378985417863&sdata=MkwbFPZ3eC9DrFysQTnnHA6CYFuNLTCt5%2FLdCrxLaXo%3D&reserved=0 > > Follow this link to subscribe/unsubscribe: > https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpublic.kitware.com%2Fmailman%2Flistinfo%2Fcmake&data=02%7C01%7Cmluparu%40microsoft.com%7C00957bc2ac4847ee794f08d413098464%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636154378985417863&sdata=JYhOwViUGadM%2FOGbf3X8cs3fwjCArFZnUz92Q1wK5VY%3D&reserved=0 From parag at ionicsecurity.com Mon Nov 28 11:50:46 2016 From: parag at ionicsecurity.com (Parag Chandra) Date: Mon, 28 Nov 2016 16:50:46 +0000 Subject: [CMake] [EXTERNAL]: Errors with cmake for VS2105 (update 3) + clang + nmake In-Reply-To: <1479993655162-7594651.post@n2.nabble.com> References: <1479749631787-7594637.post@n2.nabble.com> <1479993655162-7594651.post@n2.nabble.com> Message-ID: I?m not sure if the toolset parameter will have any effect if you?re *not* also going to output vcxproj files, but can you try ?v140_clang_c2? as the toolset? Parag Chandra Technical Lead, Mobile Team Mobile: +1.919.824.1410 Ionic Security Inc. 1170 Peachtree St. NE STE 400, Atlanta, GA 30309 On 11/24/16, 8:20 AM, "CMake on behalf of Peter Jansen" wrote: Hi Parag, Thanks for your feedback. The instructions you are referring to are for this cmake command : cmake -G"Visual Studio 14 2015" -T"LLVM-vs2014" .. But in my case I'd like (1) to use the MS VS 2015 "Nmake Makefiles" as -G option, and (2) the MS VS 2015 (update 3) included "clang" (which is version 3.8.0) compiler, referred to as Clang/C2 (i.e. using the MS VS 2015 linker etc., NOT the Clang/LLVM system) . I have been trying to find information whether an appropriate -T option is available for this, but was unsuccessful at this. Any continued support with this would be appreciated. Thanks, Peter -- View this message in context: http://cmake.3232098.n2.nabble.com/Errors-with-cmake-for-VS2105-update-3-clang-nmake-tp7594637p7594651.html Sent from the CMake mailing list archive at Nabble.com. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake From mluparu at microsoft.com Mon Nov 28 20:53:50 2016 From: mluparu at microsoft.com (Marian Luparu) Date: Tue, 29 Nov 2016 01:53:50 +0000 Subject: [CMake] VS2017 + CMake integration In-Reply-To: References: Message-ID: Once we have it ready, it will be updated in-place in VS in one of the future releases. We can't commit yet that CMake 3.7 will be in VS 2017 RTW but it will definitely be in one of the VS Updates. VS ships every 1-2 months a preview update and every 3-4 months a major update. In parallel, we'll also start the PR process to make sure that the changes needed by VS are available eventually in the official CMake builds too. -----Original Message----- From: rcdailey at gmail.com [mailto:rcdailey at gmail.com] On Behalf Of Robert Dailey Sent: Monday, November 28, 2016 8:35 AM To: Marian Luparu Cc: CMake Subject: Re: [CMake] VS2017 + CMake integration Thanks for the feedback Marian! If/when you rebase to CMake 3.7, how will that package be delivered to Visual Studio customers? My real concern stems from basically our minimum required version of CMake for our specific scripts. The minimum is 3.7 due to the awesome Android integration added in that version. Which means obviously I can't use the bundled version of CMake in VS currently. On Wed, Nov 23, 2016 at 1:57 PM, Marian Luparu wrote: > Thanks Robert -- this is great feedback > > Yes, VS ships with a patched 3.6 CMake that includes both changes to find the VS 2017 installation as well as the CMake-Server functionality needed for the IDE services. We have not yet started upstreaming these changes (got totally sidetracked by getting the VS 2017 RC release out the door) but are absolutely committed to do so. As a first step, we will be rebasing our changes to the 3.7 CMake release and then start contributing these pieces. > > Once the changes are in PR, at a minimum, you will be able to compile your own version of CMake if you wanted to, to replace the one shipping in VS. But currently, to answer your other question, we have no capability of pointing VS to a different version of CMake. That's primarily because of the thick-coupling between VS and the custom patches we need in CMake to make the end-to-end experience work. > > Thanks, > Marian Luparu > Visual C++ PM Lead > > -----Original Message----- > From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Robert > Dailey > Sent: Tuesday, November 22, 2016 10:58 AM > To: CMake > Subject: [CMake] VS2017 + CMake integration > > First of all, I personally find the CMake integration in Visual Studio just absolutely amazing. Granted I am not doing any cross-compiling with Android yet, but for just building on Windows it's phenomenal. > > I noticed that Visual Studio 2017 RC is actually packaging its own version of CMake: > > E:\PROGRAM FILES (X86)\MICROSOFT VISUAL > STUDIO\2017\PROFESSIONAL\COMMON7\IDE\COMMONEXTENSIONS\MICROSOFT\CMAKE\ > CMake\bin\cmake.exe > > Is Microsoft patching the CMake code base to support what they are doing? And if so, are those changes not upstream yet? Personally, I'd rather have the ability to tell Visual Studio to use my external version of CMake that is on PATH, rather than its own. I can understand if that isn't possible right now due to custom changes, but I'm curious to learn more, assuming Kitware has had a partnership with Microsoft for this integration with Visual Studio. > > Would anyone be able to provide more news here? Is there a way to make VS 2017 use my separate install of CMake? Are the Microsoft-specific patches contributed to upstream (or planned to be)? > -- > > Powered by > https://na01.safelinks.protection.outlook.com/?url=www.kitware.com&dat > a=02%7C01%7Cmluparu%40microsoft.com%7C00957bc2ac4847ee794f08d413098464 > %7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636154378985417863&sdata > =Plv73v%2B4m3KwGsh6VinIPPgg1qUsCdmDlx%2F9U2urOqA%3D&reserved=0 > > Please keep messages on-topic and check the CMake FAQ at: > https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.cm > ake.org%2FWiki%2FCMake_FAQ&data=02%7C01%7Cmluparu%40microsoft.com%7C00 > 957bc2ac4847ee794f08d413098464%7C72f988bf86f141af91ab2d7cd011db47%7C1% > 7C0%7C636154378985417863&sdata=qBtWeiauHkzD7ISZxtqz3Q72SaDZZwKwdY%2F1v > oAI2U8%3D&reserved=0 > > Kitware offers various services to support the CMake community. For more information on each offering, please visit: > > CMake Support: > https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcmake. > org%2Fcmake%2Fhelp%2Fsupport.html&data=02%7C01%7Cmluparu%40microsoft.c > om%7C00957bc2ac4847ee794f08d413098464%7C72f988bf86f141af91ab2d7cd011db > 47%7C1%7C0%7C636154378985417863&sdata=NZgcc%2BxtLPkIWXjqcIwItZr7KXAe6c > qbcQaLpAMMA9Q%3D&reserved=0 CMake Consulting: > https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcmake. > org%2Fcmake%2Fhelp%2Fconsulting.html&data=02%7C01%7Cmluparu%40microsof > t.com%7C00957bc2ac4847ee794f08d413098464%7C72f988bf86f141af91ab2d7cd01 > 1db47%7C1%7C0%7C636154378985417863&sdata=YXiCCEGtOMh3qvpKtXTgiL86czKy8 > xedQbUOoFaTsXA%3D&reserved=0 CMake Training Courses: > https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcmake. > org%2Fcmake%2Fhelp%2Ftraining.html&data=02%7C01%7Cmluparu%40microsoft. > com%7C00957bc2ac4847ee794f08d413098464%7C72f988bf86f141af91ab2d7cd011d > b47%7C1%7C0%7C636154378985417863&sdata=Paz%2Ft%2Bm63qi1AavokeWDNrR69wI > UD2Tzjuyp7gUHORk%3D&reserved=0 > > Visit other Kitware open-source projects at > https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.ki > tware.com%2Fopensource%2Fopensource.html&data=02%7C01%7Cmluparu%40micr > osoft.com%7C00957bc2ac4847ee794f08d413098464%7C72f988bf86f141af91ab2d7 > cd011db47%7C1%7C0%7C636154378985417863&sdata=MkwbFPZ3eC9DrFysQTnnHA6CY > FuNLTCt5%2FLdCrxLaXo%3D&reserved=0 > > Follow this link to subscribe/unsubscribe: > https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpublic > .kitware.com%2Fmailman%2Flistinfo%2Fcmake&data=02%7C01%7Cmluparu%40mic > rosoft.com%7C00957bc2ac4847ee794f08d413098464%7C72f988bf86f141af91ab2d > 7cd011db47%7C1%7C0%7C636154378985417863&sdata=JYhOwViUGadM%2FOGbf3X8cs > 3fwjCArFZnUz92Q1wK5VY%3D&reserved=0 From Robert.Bielik at dirac.com Tue Nov 29 09:21:43 2016 From: Robert.Bielik at dirac.com (Robert Bielik) Date: Tue, 29 Nov 2016 14:21:43 +0000 Subject: [CMake] Function declaration scope Message-ID: <39ff7d4b0f934572947b4a33cf92f907@hosted3-mb01.itm.host> Question: When declaring a function within a sub CMakeLists.txt file, is that function "scoped", i.e. non-existing in parent scope ? Regards /Robert From Robert.Bielik at dirac.com Tue Nov 29 09:42:49 2016 From: Robert.Bielik at dirac.com (Robert Bielik) Date: Tue, 29 Nov 2016 14:42:49 +0000 Subject: [CMake] Function declaration scope In-Reply-To: <39ff7d4b0f934572947b4a33cf92f907@hosted3-mb01.itm.host> References: <39ff7d4b0f934572947b4a33cf92f907@hosted3-mb01.itm.host> Message-ID: <14b9928c37b84206b94b685e9b5768b3@hosted3-mb01.itm.host> Hmm.. using v3.7 the answer is no, i.e. a function declared in a subfolder will be available in parent scope. Seems a bit odd, doesn't it ? Regards /R >-----Original Message----- >From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Robert Bielik >Sent: den 29 november 2016 15:22 >To: Cmake at cmake.org >Subject: [CMake] Function declaration scope > >Question: When declaring a function within a sub CMakeLists.txt file, is that >function "scoped", i.e. non-existing in parent scope ? > >Regards >/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 a.neundorf-work at gmx.net Tue Nov 29 16:18:05 2016 From: a.neundorf-work at gmx.net (Alexander Neundorf) Date: Tue, 29 Nov 2016 22:18:05 +0100 Subject: [CMake] Function declaration scope In-Reply-To: <14b9928c37b84206b94b685e9b5768b3@hosted3-mb01.itm.host> References: <39ff7d4b0f934572947b4a33cf92f907@hosted3-mb01.itm.host> <14b9928c37b84206b94b685e9b5768b3@hosted3-mb01.itm.host> Message-ID: <3021448.X5HH832dtE@linux-l7nd> On 2016 M11 29, Tue 14:42:49 CET Robert Bielik wrote: > Hmm.. using v3.7 the answer is no, i.e. a function declared in a subfolder > will be available in parent scope. Seems a bit odd, doesn't it ? this has been discussed here just recently... Functions and macros are global. Once they are defined, they are available everywhere, also in parent directories etc. Alex From henryborchers at gmail.com Wed Nov 30 11:55:12 2016 From: henryborchers at gmail.com (Henry Borchers) Date: Wed, 30 Nov 2016 10:55:12 -0600 Subject: [CMake] Using a header only library that links uses Objective-C headers Message-ID: First time poster so I hope I get the etiquette right. I'm a novice CMake user and I've never come across the type of issue before. I'm trying to figure out how to use this cross platform header only dialog library in my project. https://github.com/guillaumechereau/noc When using this on OSX, it links to "AppKit.h" which is an Objective-c header. How can I tell CMake that this header only library file needs to be compiled as Objective-C if I'm compiling on OSX? Thanks, Henry -------------- next part -------------- An HTML attachment was scrubbed... URL: From florent.castelli at gmail.com Wed Nov 30 12:01:39 2016 From: florent.castelli at gmail.com (Florent Castelli) Date: Wed, 30 Nov 2016 18:01:39 +0100 Subject: [CMake] Using a header only library that links uses Objective-C headers In-Reply-To: References: Message-ID: <1532b63c-8f68-f488-7e86-0feed308a691@gmail.com> You don't compile a header only library (unless you're talking about precompiled headers, which I think you don't). What you need is compiling the sources using it as Objective C. Which is a matter of adding target_compile_options( PRIVATE "-ObjC") on the target with the sources if I remember correctly. /Florent On 30/11/2016 17:55, Henry Borchers wrote: > First time poster so I hope I get the etiquette right. I'm a novice > CMake user and I've never come across the type of issue before. > > I'm trying to figure out how to use this cross platform header only > dialog library in my project. > https://github.com/guillaumechereau/noc > > When using this on OSX, it links to "AppKit.h" which is an Objective-c > header. How can I tell CMake that this header only library file needs > to be compiled as Objective-C if I'm compiling on OSX? > > Thanks, > Henry > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From konstantin at podsvirov.pro Wed Nov 30 12:12:09 2016 From: konstantin at podsvirov.pro (Konstantin Podsvirov) Date: Wed, 30 Nov 2016 20:12:09 +0300 Subject: [CMake] [SUGGESTION] Add %ONLY alternative for configure_file command Message-ID: <1160691480525929@web29j.yandex.ru> An HTML attachment was scrubbed... URL: From robert.maynard at kitware.com Wed Nov 30 14:46:10 2016 From: robert.maynard at kitware.com (Robert Maynard) Date: Wed, 30 Nov 2016 14:46:10 -0500 Subject: [CMake] [ANNOUNCE] CMake 3.7.1 available for download Message-ID: We are pleased to announce that CMake 3.7.1 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.7.1 since 3.7.0: Ben Boeckel (1): ARMCC: Fix flag used for response files Brad King (9): VS: Update VS 15 generator for Preview 5 FindBISON: Do not rebuild every time when not VERBOSE Android: Always set CMAKE_ANDROID_NDK_TOOLCHAIN_VERSION Android: Add CMAKE_ANDROID_NDK_TOOLCHAIN_HOST_TAG variable Android: Add CMAKE__ANDROID_TOOLCHAIN_MACHINE Help: Document CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT variable libarchive: Add headers to adapt between OpenSSL 1.1 and older versions libarchive: Add support for building with OpenSSL 1.1 CMake 3.7.1 Gregor Jasny (1): Revert "Xcode: Obey SYSTEM keyword for includes (#15687)" Roman W?ger (1): VS: Rename VS 15 generator to 'Visual Studio 15 2017' Tobias Hunger (2): server-mode: Prevent possible crash when watching directories server-mode: Reset GlobalGenerator before configure From henryborchers at gmail.com Wed Nov 30 16:59:34 2016 From: henryborchers at gmail.com (Henry Borchers) Date: Wed, 30 Nov 2016 15:59:34 -0600 Subject: [CMake] Using a header only library that links uses Objective-C headers In-Reply-To: <1532b63c-8f68-f488-7e86-0feed308a691@gmail.com> References: <1532b63c-8f68-f488-7e86-0feed308a691@gmail.com> Message-ID: > > You don't compile a header only library That's what I thought but this is my first time dealing with header only libraries. Thanks for clearing up that confusion. What you need is compiling the sources using it as Objective C. > Which is a matter of adding target_compile_options( PRIVATE > "-ObjC") on the target with the sources if I remember correctly. Yup! That worked! Thanks. Henry On Wed, Nov 30, 2016 at 11:01 AM, Florent Castelli < florent.castelli at gmail.com> wrote: > You don't compile a header only library (unless you're talking about > precompiled headers, which I think you don't). > > What you need is compiling the sources using it as Objective C. > Which is a matter of adding target_compile_options( PRIVATE > "-ObjC") on the target with the sources if I remember correctly. > > /Florent > > > On 30/11/2016 17:55, Henry Borchers wrote: > > First time poster so I hope I get the etiquette right. I'm a novice CMake > user and I've never come across the type of issue before. > > I'm trying to figure out how to use this cross platform header only dialog > library in my project. > https://github.com/guillaumechereau/noc > > When using this on OSX, it links to "AppKit.h" which is an Objective-c > header. How can I tell CMake that this header only library file needs to be > compiled as Objective-C if I'm compiling on OSX? > > Thanks, > Henry > > > > > -- > > 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: