From brad.king at kitware.com Tue Nov 1 08:42:38 2016 From: brad.king at kitware.com (Brad King) Date: Tue, 1 Nov 2016 08:42:38 -0400 Subject: [cmake-developers] LINK_FLAGS and STATIC_LIBRARY_FLAGS target properties In-Reply-To: References: Message-ID: <1a5a81b6-d64b-3afc-1c90-1b386d3f4775@kitware.com> On 10/30/2016 12:01 AM, Craig Scott wrote: > Looking at the latest CMake docs for the LINK_FLAGS and STATIC_LIBRARY_FLAGS > target properties, neither mentions support for generator expressions. > Is it just a case of the linker properties haven't had their documentation > updated or do they not yet have generator expression support? Support for generator expressions has not been implemented for those. > The situation for the INTERFACE_LINK_LIBRARIES target property is also > a bit odd in that it's documentation doesn't mention support for generator > expressions, but that for LINK_LIBRARIES does. That is just missing documentation. > are there plans to add such support any time soon? No, but we wouldn't be opposed to having them implemented. Thanks, -Brad From brad.king at kitware.com Tue Nov 1 08:44:36 2016 From: brad.king at kitware.com (Brad King) Date: Tue, 1 Nov 2016 08:44:36 -0400 Subject: [cmake-developers] Developer workflow with gitlab In-Reply-To: <6dc0de7b-57e8-f8b3-36f9-f0f957803a22@googlemail.com> References: <6dc0de7b-57e8-f8b3-36f9-f0f957803a22@googlemail.com> Message-ID: On 10/31/2016 02:26 PM, Gregor Jasny via cmake-developers wrote: > I wonder what's the recommended workflow for CMake developers with > commit access to stage? I'd like to use feature branches in gitlab but > wonder how those are best merged into 'next'? We can review in GitLab first and once mature then merge to `next` for testing. If fixups are needed in `next` they should be pushed back to the MR too. > Could you please advise or point me to some documentation? As Ben said in his reply we're working on some new infrastructure to better integrate the workflow. Once that is ready we'll have documentation for it. -Brad 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-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-developers] [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-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 florent.castelli at gmail.com Tue Nov 1 14:05:50 2016 From: florent.castelli at gmail.com (Florent Castelli) Date: Tue, 1 Nov 2016 19:05:50 +0100 Subject: [cmake-developers] CMake integration in Gradle (Android Studio) In-Reply-To: References: <267ae9a6-d4bb-accc-7617-76d2ded27c46@gmail.com> Message-ID: Switching IDE is fine during development. Personally, I prefer to build in a terminal with Ninja and switch back to the IDE to fix any warning or error. But that's not working for Continuous Integration builds. You don't want your build to lock up for 30 minutes (because you have a large app) with no output while it's building one of the four architectures. Most build servers will abort the build long before that as it is considered stuck. It makes it really unlikely that people will actually fix warnings too since they won't see them. I'd like to experiment with a Gradle task running CMake that would stream the output, but my knowledge with the tool is really lacking and I have currently other priorities (I kind of hope that there will be good solutions out there by the time I get to it too...). /Florent On 01/11/2016 16:30, Cong Monkey wrote: > 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 maikelvandenhurk at hotmail.com Tue Nov 1 16:30:06 2016 From: maikelvandenhurk at hotmail.com (maikel van den Hurk) Date: Tue, 1 Nov 2016 20:30:06 +0000 Subject: [cmake-developers] Add property to get all linked libraries including transitive ones In-Reply-To: References: Message-ID: It would be nice to extend the current properties set of LINK_LIBRARIES and INTERFACE_LINK_LIBRARIES with a property to obtain actually all transitive linked libraries of a specific target. Currently you will have to traverse yourself over all targets to get in CMake a full overview of all linked libraries. This information should already be present internally to write out accordingly all the generator files accordingly. I do understand the fact that this information is only fully available during generation time. Would you be open for such extension point or is there are already one maybe? For example: add_library(Library1 library1.cpp) target_link_libraries(Library1 PRIVATE Library2 PUBLIC Library3) add_library(Library2 SHARED library2.cpp) add_library(Library3 SHARED library3.cpp) add_library(Library4 SHARED library4.cpp) target_link_libraries(Library4 PRIVATE Library1 PUBLIC Library2) get_target_property(ALL_DEPENDENCIES1 Library1 LINK_LIBRARIES) get_target_property(ALL_DEPENDENCIES2 Library2 LINK_LIBRARIES) get_target_property(ALL_DEPENDENCIES3 Library3 LINK_LIBRARIES) get_target_property(ALL_DEPENDENCIES4 Library4 LINK_LIBRARIES) get_target_property(INTERFACE_DEPENDENCIES1 Library1 INTERFACE_LINK_LIBRARIES) get_target_property(INTERFACE_DEPENDENCIES2 Library2 INTERFACE_LINK_LIBRARIES) get_target_property(INTERFACE_DEPENDENCIES3 Library3 INTERFACE_LINK_LIBRARIES) get_target_property(INTERFACE_DEPENDENCIES4 Library4 INTERFACE_LINK_LIBRARIES) message("All dependencies of Library1 are: ${ALL_DEPENDENCIES1}") message("All dependencies of Library2 are: ${ALL_DEPENDENCIES2}") message("All dependencies of Library3 are: ${ALL_DEPENDENCIES3}") message("All dependencies of Library4 are: ${ALL_DEPENDENCIES4}") message("Interface dependencies of Library1 are: ${INTERFACE_DEPENDENCIES1}") message("Interface dependencies of Library2 are: ${INTERFACE_DEPENDENCIES2}") message("Interface dependencies of Library3 are: ${INTERFACE_DEPENDENCIES3}") message("Interface dependencies of Library4 are: ${INTERFACE_DEPENDENCIES4}") That would result in: All dependencies of Library1 are: Library2;Library3 All dependencies of Library2 are: ALL_DEPENDENCIES2-NOTFOUND All dependencies of Library3 are: ALL_DEPENDENCIES3-NOTFOUND All dependencies of Library4 are: Library1;Library2 Interface dependencies of Library1 are: $;Library3 Interface dependencies of Library2 are: INTERFACE_DEPENDENCIES2-NOTFOUND Interface dependencies of Library3 are: INTERFACE_DEPENDENCIES3-NOTFOUND Interface dependencies of Library4 are: Library2 It would be nice to request with a property for example from target Library4 all its linked libraries (i.e. the actual linker line), so in the example case you would get then Library1, Library2, Library3. -------------- 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-developers] [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 brad.king at kitware.com Wed Nov 2 07:56:00 2016 From: brad.king at kitware.com (Brad King) Date: Wed, 2 Nov 2016 07:56:00 -0400 Subject: [cmake-developers] Add property to get all linked libraries including transitive ones In-Reply-To: References: Message-ID: <7a00d177-ba7a-6f55-2af3-4e604ab495cc@kitware.com> On 11/01/2016 04:30 PM, maikel van den Hurk wrote: > obtain actually all transitive linked libraries of a specific target. [snip] > this information is only fully available during generation time. What is an example use case for this? I don't think we can offer a configure-time solution but perhaps there is a generate-time solution to the use case. -Brad From morrison.levi at gmail.com Wed Nov 2 15:32:57 2016 From: morrison.levi at gmail.com (Levi Morrison) Date: Wed, 2 Nov 2016 13:32:57 -0600 Subject: [cmake-developers] Add CXX_STANDARD support for Intel C++ compilers In-Reply-To: <565F10EF.4000609@kitware.com> References: <564CAB28.9020101@kitware.com> <564CDA4F.9070503@kitware.com> <564DED8E.1030907@kitware.com> <565C9683.6060209@kitware.com> <565DAAAC.3010108@kitware.com> <565DE2D3.6090807@kitware.com> <565F10EF.4000609@kitware.com> Message-ID: On Wed, Dec 2, 2015 at 8:40 AM, Brad King wrote: > On 12/02/2015 10:31 AM, Levi Morrison wrote: >> Hmm. What is the purpose of this module? I verified that indeed my >> changeset somehow breaks this test but I don't even understand what it >> is trying to do. At a glance it looks like even *more* duplication of >> feature detection. Please tell me I'm wrong. > > It re-uses the Modules/Compiler/--FeatureTests.cmake information > to generate a header file that projects can include to check for the > availability of features. The header can then be installed and re-used > by clients of such projects even if they do not use CMake. > > The test checks that those results are consistent with the features detected > by CMake. > > -Brad > Brad, here it is a year later and thought I would get around to finishing this work. Then I discovered you had already completed it! Thank you so much! I now have access to the 2017 Intel C++ compiler; is there anything in particular you'd like me to check with it? From brad.king at kitware.com Wed Nov 2 15:48:50 2016 From: brad.king at kitware.com (Brad King) Date: Wed, 2 Nov 2016 15:48:50 -0400 Subject: [cmake-developers] Add CXX_STANDARD support for Intel C++ compilers In-Reply-To: References: <564CAB28.9020101@kitware.com> <564CDA4F.9070503@kitware.com> <564DED8E.1030907@kitware.com> <565C9683.6060209@kitware.com> <565DAAAC.3010108@kitware.com> <565DE2D3.6090807@kitware.com> <565F10EF.4000609@kitware.com> Message-ID: <5dafca5e-79f2-50a8-9037-7dbc6d419a20@kitware.com> On 11/02/2016 03:32 PM, Levi Morrison wrote: > Brad, here it is a year later and thought I would get around to > finishing this work. Then I discovered you had already completed it! > Thank you so much! > > I now have access to the 2017 Intel C++ compiler; is there anything in > particular you'd like me to check with it? No, thanks. I have it installed and have tested on Linux and Windows. Please proceed with normal usage. -Brad From maikelvandenhurk at hotmail.com Wed Nov 2 16:23:51 2016 From: maikelvandenhurk at hotmail.com (maikel van den Hurk) Date: Wed, 2 Nov 2016 20:23:51 +0000 Subject: [cmake-developers] Add property to get all linked libraries including transitive ones In-Reply-To: <7a00d177-ba7a-6f55-2af3-4e604ab495cc@kitware.com> References: , <7a00d177-ba7a-6f55-2af3-4e604ab495cc@kitware.com> Message-ID: We are trying to develop a proper C++ dependency management tool which will combine Ivy together with CMake. Our intention is to open source this this modules later for everyone. As we need to keep track of all dependencies we would like to be able to get all transitive linked libraries to be able to write out properly ivy module descriptor. We could try to write some logic which will go over all the targets and get from them LINK_LIBRARIES and INTERFACE_LINK_LIBRARIES, but given the knowledge of all transitive is available internally in CMake already it would great if this could be exposed at generate-time. Maikel -------------- next part -------------- An HTML attachment was scrubbed... URL: From florent.castelli at gmail.com Wed Nov 2 18:25:26 2016 From: florent.castelli at gmail.com (Florent Castelli) Date: Wed, 2 Nov 2016 23:25:26 +0100 Subject: [cmake-developers] Add property to get all linked libraries including transitive ones In-Reply-To: <7a00d177-ba7a-6f55-2af3-4e604ab495cc@kitware.com> References: <7a00d177-ba7a-6f55-2af3-4e604ab495cc@kitware.com> Message-ID: <3de6041c-8632-67dc-1932-e26764b98def@gmail.com> One usage I would have had for this feature would have been to generate a pre-linked library. Basically, merging a static library and its dependencies together (check ld -r) and output an object file for static linking (not a shared library). This is required as merging static libraries may conflict on filenames in the archive (they could be renamed though) or generate huge archives (hey, here's 1000 copies of std::string and std::vector methods and their debug symbols). Instead, I recursed on all the dependencies to generate an extra build step to merge everything. The file is small and can be cached. We did that to save time for our iOS devs so they didn't have to rebuild our big C++ library all the time. We targeted iOS 7, so shared libraries were not available. It's a bit more involved, but it would have been useful. Though, I understand it can be tricky to get the on-disk path to a library with all generators (we had 2 code paths, one for Xcode builds and another one for Ninja). /Florent On 02/11/2016 12:56, Brad King wrote: > On 11/01/2016 04:30 PM, maikel van den Hurk wrote: >> obtain actually all transitive linked libraries of a specific target. > [snip] >> this information is only fully available during generation time. > What is an example use case for this? I don't think we can offer a > configure-time solution but perhaps there is a generate-time solution > to the use case. > > -Brad > From brad.king at kitware.com Thu Nov 3 07:53:53 2016 From: brad.king at kitware.com (Brad King) Date: Thu, 3 Nov 2016 07:53:53 -0400 Subject: [cmake-developers] Add property to get all linked libraries including transitive ones In-Reply-To: References: <7a00d177-ba7a-6f55-2af3-4e604ab495cc@kitware.com> Message-ID: <0e473bd0-69b3-f208-6a84-96a42105a918@kitware.com> On 11/02/2016 04:23 PM, maikel van den Hurk wrote: > We are trying to develop a proper C++ dependency management tool > ...be able to get all transitive linked libraries The cmake-server mode introduced in 3.7 was created to support tooling. Perhaps something with that can be made to work if it doesn't provide the needed information already. -Brad From robert.maynard at kitware.com Thu Nov 3 12:32:36 2016 From: robert.maynard at kitware.com (Robert Maynard) Date: Thu, 3 Nov 2016 12:32:36 -0400 Subject: [cmake-developers] [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 christensen.erik at siemens.com Thu Nov 3 18:05:15 2016 From: christensen.erik at siemens.com (Christensen, Erik) Date: Thu, 3 Nov 2016 22:05:15 +0000 Subject: [cmake-developers] Visual Studio Project Upgrade Prompt Message-ID: Hi, When opening projects in the Visual Studio IDE that are using an older toolset version (ie. a VS 2012 project under VS 2015) for the first time, a prompt is displayed asking if you'd like to upgrade the projects to the newer version of Visual Studio. This gets annoying pretty quickly when you're generating projects over and over. Now, there's a VS project property that can be set, which will prevent this prompt from being shown. It can be applied to any (known) CMake target like so: set_property(TARGET target PROPERTY VS_GLOBAL_VCProjectUpgraderObjectName NoUpgrade) Unfortunately, you still get upgrade prompts for all of the predefined and automoc targets (ie. ALL_BUILD, ZERO_CHECK, etc.). Is there any way to assign that property to the built-in targets? Really, it seems like this is a property that should be applied by default to any CMake generated Visual Studio projects. I'm not sure why anyone would want to do a project upgrade within Visual Studio itself when you can just reconfigure the toolset in CMake. I imagine anyone specifying an older toolset version is doing so on purpose so that they can use the latest IDE with projects that need to be kept on older compilers. But maybe I'm wrong. Erik -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.adam at megware.com Fri Nov 4 04:14:40 2016 From: alexander.adam at megware.com (Alexander Adam) Date: Fri, 04 Nov 2016 09:14:40 +0100 Subject: [cmake-developers] (Re-)Added RPM Suggested Dependency Support Message-ID: <1869145.53KBLA42Ab@alphameg> Hello, after searching how to use the documented CPACK_RPM__PACKAGE_SUGGESTS feature, I stumbled across the following ticket: https://gitlab.kitware.com/cmake/cmake/issues/13423 After reading through the discussion, I tried to fix the remaining issues and came up with the attached patch (against master). I also added the patched CPackRPM.cmake for security. Alexander -------------- next part -------------- A non-text attachment was scrubbed... Name: CPackRPM.cmake Type: text/x-cmake Size: 96494 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: cpack_rpm_fix_suggest.patch Type: text/x-patch Size: 1795 bytes Desc: not available URL: From domen.vrankar at gmail.com Fri Nov 4 04:34:46 2016 From: domen.vrankar at gmail.com (Domen Vrankar) Date: Fri, 4 Nov 2016 09:34:46 +0100 Subject: [cmake-developers] (Re-)Added RPM Suggested Dependency Support In-Reply-To: <1869145.53KBLA42Ab@alphameg> References: <1869145.53KBLA42Ab@alphameg> Message-ID: > > after searching how to use the documented > CPACK_RPM__PACKAGE_SUGGESTS feature, I stumbled across the > following ticket: https://gitlab.kitware.com/cmake/cmake/issues/13423 > > After reading through the discussion, I tried to fix the remaining issues > and > came up with the attached patch (against master). I also added the patched > CPackRPM.cmake for security. > At first glance I like the solution. I'll take a more detailed look at it in the afternoon. Would you be willing to also write a test for the SUGGESTS tag? The tests are located in Tests/RunCMake/CPack, you add the test to RunCMakeTest.cmake and for an example of a test similar to what you'd need to write you can search the CPack directory for all files containing PER_COMPONENT_FIELDS in their name. Thanks, Domen -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Fri Nov 4 08:19:03 2016 From: brad.king at kitware.com (Brad King) Date: Fri, 4 Nov 2016 08:19:03 -0400 Subject: [cmake-developers] Visual Studio Project Upgrade Prompt In-Reply-To: References: Message-ID: <9d53ff21-b3a0-2b3e-fb4d-d0044fe0fcaf@kitware.com> On 11/03/2016 06:05 PM, Christensen, Erik wrote: > VS_GLOBAL_VCProjectUpgraderObjectName NoUpgrade [snip] > Really, it seems like this is a property that should be applied by > default to any CMake generated Visual Studio projects. Yes. Please look at cmVisualStudio10TargetGenerator.cxx to try that. Thanks, -Brad From alexander.adam at megware.com Fri Nov 4 09:15:00 2016 From: alexander.adam at megware.com (Alexander Adam) Date: Fri, 04 Nov 2016 14:15:00 +0100 Subject: [cmake-developers] (Re-)Added RPM Suggested Dependency Support In-Reply-To: References: <1869145.53KBLA42Ab@alphameg> Message-ID: <2080676.LRZ0lY3U1Q@alphameg> On Freitag, 4. November 2016 09:34:46 CET you wrote: > Would you be willing to also write a test for the SUGGESTS tag? > The tests are located in Tests/RunCMake/CPack, you add the test to > RunCMakeTest.cmake and for an example of a test similar to what you'd need > to write you can search the CPack directory for all files containing > PER_COMPONENT_FIELDS in their name. I took the LONG_FILENAME test for deb packages as a template for the following patch. Is it more or less what you had in mind? Alexander -------------- next part -------------- A non-text attachment was scrubbed... Name: add_rpm_suggests_test.patch Type: text/x-patch Size: 3259 bytes Desc: not available URL: From Robert.Goulet at autodesk.com Fri Nov 4 09:02:41 2016 From: Robert.Goulet at autodesk.com (Robert Goulet) Date: Fri, 4 Nov 2016 13:02:41 +0000 Subject: [cmake-developers] Starting new project with no build flags set Message-ID: Hi all, What is the clean way to start a new project with no build flags at all. i.e. CMAKE_C_FLAGS, CMAKE_C_FLAGS_DEBUG, etc. all set to no value? Is there a way to force this for all platforms/compilers? Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From maikelvandenhurk at hotmail.com Fri Nov 4 09:52:24 2016 From: maikelvandenhurk at hotmail.com (maikel van den Hurk) Date: Fri, 4 Nov 2016 13:52:24 +0000 Subject: [cmake-developers] Add property to get all linked libraries including transitive ones In-Reply-To: <0e473bd0-69b3-f208-6a84-96a42105a918@kitware.com> References: <7a00d177-ba7a-6f55-2af3-4e604ab495cc@kitware.com> , <0e473bd0-69b3-f208-6a84-96a42105a918@kitware.com> Message-ID: What about doing what was targeted with this bug: https://cmake.org/Bug/view.php?id=12435? That would really help a lot. Is this information already present in cmake-server right now? Still I believe that the suggestion of the bug mentioned is actually the better path. ________________________________ Van: Brad King Verzonden: donderdag 3 november 2016 12:53 Aan: maikel van den Hurk CC: cmake-developers at cmake.org; Tobias Hunger Onderwerp: Re: [cmake-developers] Add property to get all linked libraries including transitive ones On 11/02/2016 04:23 PM, maikel van den Hurk wrote: > We are trying to develop a proper C++ dependency management tool > ...be able to get all transitive linked libraries The cmake-server mode introduced in 3.7 was created to support tooling. Perhaps something with that can be made to work if it doesn't provide the needed information already. -Brad -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Fri Nov 4 10:49:49 2016 From: brad.king at kitware.com (Brad King) Date: Fri, 4 Nov 2016 10:49:49 -0400 Subject: [cmake-developers] Starting new project with no build flags set In-Reply-To: References: Message-ID: On 11/04/2016 09:02 AM, Robert Goulet wrote: > What is the clean way to start a new project with no build flags at all. > i.e. CMAKE_C_FLAGS, CMAKE_C_FLAGS_DEBUG, etc. all set to no value? > Is there a way to force this for all platforms/compilers? Thanks! There is a hook just before the flags are initialized in the cache that gives project code a chance to change the initializers. See https://cmake.org/cmake/help/v3.7/variable/CMAKE_USER_MAKE_RULES_OVERRIDE.html There is also a per-language CMAKE_USER_MAKE_RULES_OVERRIDE_{C,CXX} version. -Brad From brad.king at kitware.com Fri Nov 4 10:50:00 2016 From: brad.king at kitware.com (Brad King) Date: Fri, 4 Nov 2016 10:50:00 -0400 Subject: [cmake-developers] Add property to get all linked libraries including transitive ones In-Reply-To: References: <7a00d177-ba7a-6f55-2af3-4e604ab495cc@kitware.com> <0e473bd0-69b3-f208-6a84-96a42105a918@kitware.com> Message-ID: <125594d6-4db6-40cf-4cf0-b9a527eea1ea@kitware.com> On 11/04/2016 09:52 AM, maikel van den Hurk wrote: > What about doing what was targeted with this bug: https://cmake.org/Bug/view.php?id=12435? That issue is now tracked here: https://gitlab.kitware.com/cmake/cmake/issues/12435 I've just added some notes to the discussion. Steve, do you recall why $ is not transitive as genexes for other usage requirements are? > Is this information already present in cmake-server right now? Not sure. > Still I believe that the suggestion of the bug mentioned is actually the better path. [snip] > write out properly ivy module descriptor Without knowing more about an "ivy module descriptor" I cannot say whether cmake-server or a generate-time solution from CMake is better. I can say I don't think it should be the responsibility of project code to generate files for external tooling unrelated to the build process. The tooling should be able to extract the information from any CMake project, and the cmake-server approach would allow that. -Brad From brad.king at kitware.com Fri Nov 4 10:50:09 2016 From: brad.king at kitware.com (Brad King) Date: Fri, 4 Nov 2016 10:50:09 -0400 Subject: [cmake-developers] Importing platform SDK libraries without a full path In-Reply-To: <5613E90D.40901@kitware.com> References: <555DE535.4020707@kitware.com> <5564BCB2.2000600@kitware.com> <5565C35B.9090108@kitware.com> <55662CE2.4090002@kitware.com> <55688316.3040306@kitware.com> <5613E90D.40901@kitware.com> Message-ID: <51bf7bfc-9099-87eb-c4db-a5d66deef424@kitware.com> On 10/06/2015 11:30 AM, Brad King wrote: > On 10/04/2015 10:49 AM, Stephen Kelly wrote: >> I wonder if you plan do resolve this part in the coming cycle? I think >> resolving that part would help me to understand the rest of your proposal in >> the thread. > > I don't know if/when I'll ever have time to return to that work :( I've continued it here: https://gitlab.kitware.com/cmake/cmake/merge_requests/236 I realized that the confusion over interface library configuration selection was due to me having mis-read the original code. Part of the previous iteration of these changes was wrong along with the last paragraph of the commit message about adding support for `MAP_IMPORTED_CONFIG_` to interface libraries. In fact they already supported it. I have a new version of the changes that is now only about selecting the proper `IMPORTED_LIBNAME` for the current configuration. -Brad From maikelvandenhurk at hotmail.com Fri Nov 4 11:55:15 2016 From: maikelvandenhurk at hotmail.com (maikel van den Hurk) Date: Fri, 4 Nov 2016 15:55:15 +0000 Subject: [cmake-developers] Add property to get all linked libraries including transitive ones In-Reply-To: <125594d6-4db6-40cf-4cf0-b9a527eea1ea@kitware.com> References: <7a00d177-ba7a-6f55-2af3-4e604ab495cc@kitware.com> <0e473bd0-69b3-f208-6a84-96a42105a918@kitware.com> , <125594d6-4db6-40cf-4cf0-b9a527eea1ea@kitware.com> Message-ID: Thanks for tracking the issue! Just checked the code and there is the following part https://gitlab.kitware.com/cmake/cmake/blob/v3.6.3/Source/cmGeneratorExpressionNode.cxx#L944 which you will hit when adding LINK_LIBRARIES to the list of items to expand transitively. If I understand this part correctly then this shouldn't be a real problem as the recursion could as well happen in INCLUDE_DIRECTORIES, but please correct me if I am wrong here. -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.maynard at kitware.com Fri Nov 4 15:37:35 2016 From: robert.maynard at kitware.com (Robert Maynard) Date: Fri, 4 Nov 2016 15:37:35 -0400 Subject: [cmake-developers] [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 domen.vrankar at gmail.com Sat Nov 5 07:09:17 2016 From: domen.vrankar at gmail.com (Domen Vrankar) Date: Sat, 5 Nov 2016 12:09:17 +0100 Subject: [cmake-developers] (Re-)Added RPM Suggested Dependency Support In-Reply-To: <2080676.LRZ0lY3U1Q@alphameg> References: <1869145.53KBLA42Ab@alphameg> <2080676.LRZ0lY3U1Q@alphameg> Message-ID: 2016-11-04 14:15 GMT+01:00 Alexander Adam : > On Freitag, 4. November 2016 09:34:46 CET you wrote: > > > Would you be willing to also write a test for the SUGGESTS tag? > > The tests are located in Tests/RunCMake/CPack, you add the test to > > RunCMakeTest.cmake and for an example of a test similar to what you'd > need > > to write you can search the CPack directory for all files containing > > PER_COMPONENT_FIELDS in their name. > > I took the LONG_FILENAME test for deb packages as a template for the > following > patch. Is it more or less what you had in mind? > That was more or less what I needed, thanks. I've made some changes to the patch and test and also extended it to work correctly for some tags that are not listed by rpmbuild --querytags. The topic is now in next for testing: https://cmake.org/gitweb?p=cmake.git;a=commit;h=838fd5c Thanks, Domen -------------- next part -------------- An HTML attachment was scrubbed... URL: From steveire at gmail.com Sun Nov 6 19:23:39 2016 From: steveire at gmail.com (Stephen Kelly) Date: Mon, 07 Nov 2016 00:23:39 +0000 Subject: [cmake-developers] Add property to get all linked libraries including transitive ones References: <7a00d177-ba7a-6f55-2af3-4e604ab495cc@kitware.com> <0e473bd0-69b3-f208-6a84-96a42105a918@kitware.com> <125594d6-4db6-40cf-4cf0-b9a527eea1ea@kitware.com> Message-ID: Brad King wrote: > On 11/04/2016 09:52 AM, maikel van den Hurk wrote: >> What about doing what was targeted with this bug: >> https://cmake.org/Bug/view.php?id=12435? > > That issue is now tracked here: > > https://gitlab.kitware.com/cmake/cmake/issues/12435 > > I've just added some notes to the discussion. > > Steve, do you recall why $ > is not transitive as genexes for other usage requirements are? I believe it's because of a chicken-egg concern - the link libraries are the basis for transitivity for other properties. I remember discussing that in the mailing list back in the design phase. Thanks, Steve. From Robert.Goulet at autodesk.com Tue Nov 8 13:59:34 2016 From: Robert.Goulet at autodesk.com (Robert Goulet) Date: Tue, 8 Nov 2016 18:59:34 +0000 Subject: [cmake-developers] cmake 3.7.0-rc3 regression Message-ID: <3cfd82b735894466afee73cbee59d2cb@CO1PR79MB010.MGDADSK.autodesk.com> Hi, After trying to upgrade to CMake 3.7.0-rc3, we've found the following regression: Previously, we were able to put multiple platform CMake executables in the same root by just renaming the "bin" folder, so that they don't overlap each other, as such: cmake/win/cmake.exe cmake/mac/cmake cmake/linux/cmake cmake/share/... cmake/doc/... However in 3.7.0-rc3 this is broken, no longer works if the CMake binary folder isn't named specifically "bin". CMake will fail to start, reporting "CMake Error: Could not find CMAKE_ROOT !!!". Traced it back to this commit: Commit: 18bfbc972fd3daf3e973f80072c4de09ec7e852b Add option to control 'bin' directory of CMake's own installation (#16076) Add a `CMAKE_BIN_DIR` cache entry to CMake's own build configuration. Add a `--bindir` option to the `bootstrap` script to set it. If this wasn't intentional, can we get a fix before 3.7.0 is released? Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From Robert.Goulet at autodesk.com Tue Nov 8 14:09:18 2016 From: Robert.Goulet at autodesk.com (Robert Goulet) Date: Tue, 8 Nov 2016 19:09:18 +0000 Subject: [cmake-developers] cmake 3.7.0-rc3 regression In-Reply-To: <2918862.2kSMebckN0@daneel.sf-tec.de> References: <3cfd82b735894466afee73cbee59d2cb@CO1PR79MB010.MGDADSK.autodesk.com> <2918862.2kSMebckN0@daneel.sf-tec.de> Message-ID: <58e20ee7acc44ee1b369924c10846f14@CO1PR79MB010.MGDADSK.autodesk.com> Not sure I understand why is this part of a build switch now? And what if we don't build CMake ourselves but instead, using prebuilt binaries from the CMake website? -----Original Message----- From: Rolf Eike Beer [mailto:eike at sf-mail.de] Sent: Tuesday, November 8, 2016 2:04 PM To: cmake-developers at cmake.org Cc: Robert Goulet Subject: Re: [cmake-developers] cmake 3.7.0-rc3 regression Am Dienstag, 8. November 2016, 18:59:34 schrieb Robert Goulet: > Hi, > > After trying to upgrade to CMake 3.7.0-rc3, we've found the following > regression: > > Previously, we were able to put multiple platform CMake executables in > the same root by just renaming the "bin" folder, so that they don't > overlap each other, as such: > > cmake/win/cmake.exe > cmake/mac/cmake > cmake/linux/cmake > cmake/share/... > cmake/doc/... > > However in 3.7.0-rc3 this is broken, no longer works if the CMake > binary folder isn't named specifically "bin". CMake will fail to > start, reporting "CMake Error: Could not find CMAKE_ROOT !!!". > > Traced it back to this commit: > > Commit: 18bfbc972fd3daf3e973f80072c4de09ec7e852b > > Add option to control 'bin' directory of CMake's own installation > (#16076) > > Add a `CMAKE_BIN_DIR` cache entry to CMake's own build configuration. > Add a `--bindir` option to the `bootstrap` script to set it. > > If this wasn't intentional, can we get a fix before 3.7.0 is released? If you read the commit message you should be able to fix your problem: just build the different CMake instances with different --bindir switches. Eike From eike at sf-mail.de Tue Nov 8 14:04:24 2016 From: eike at sf-mail.de (Rolf Eike Beer) Date: Tue, 08 Nov 2016 20:04:24 +0100 Subject: [cmake-developers] cmake 3.7.0-rc3 regression In-Reply-To: <3cfd82b735894466afee73cbee59d2cb@CO1PR79MB010.MGDADSK.autodesk.com> References: <3cfd82b735894466afee73cbee59d2cb@CO1PR79MB010.MGDADSK.autodesk.com> Message-ID: <2918862.2kSMebckN0@daneel.sf-tec.de> Am Dienstag, 8. November 2016, 18:59:34 schrieb Robert Goulet: > Hi, > > After trying to upgrade to CMake 3.7.0-rc3, we've found the following > regression: > > Previously, we were able to put multiple platform CMake executables in the > same root by just renaming the "bin" folder, so that they don't overlap > each other, as such: > > cmake/win/cmake.exe > cmake/mac/cmake > cmake/linux/cmake > cmake/share/... > cmake/doc/... > > However in 3.7.0-rc3 this is broken, no longer works if the CMake binary > folder isn't named specifically "bin". CMake will fail to start, reporting > "CMake Error: Could not find CMAKE_ROOT !!!". > > Traced it back to this commit: > > Commit: 18bfbc972fd3daf3e973f80072c4de09ec7e852b > > Add option to control 'bin' directory of CMake's own installation > (#16076) > > Add a `CMAKE_BIN_DIR` cache entry to CMake's own build configuration. > Add a `--bindir` option to the `bootstrap` script to set it. > > If this wasn't intentional, can we get a fix before 3.7.0 is released? If you read the commit message you should be able to fix your problem: just build the different CMake instances with different --bindir switches. 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 brad.king at kitware.com Tue Nov 8 14:13:20 2016 From: brad.king at kitware.com (Brad King) Date: Tue, 8 Nov 2016 14:13:20 -0500 Subject: [cmake-developers] cmake 3.7.0-rc3 regression In-Reply-To: <3cfd82b735894466afee73cbee59d2cb@CO1PR79MB010.MGDADSK.autodesk.com> References: <3cfd82b735894466afee73cbee59d2cb@CO1PR79MB010.MGDADSK.autodesk.com> Message-ID: <523f3533-ba17-0156-03b3-b889454af592@kitware.com> On 11/08/2016 01:59 PM, Robert Goulet wrote: > Commit: 18bfbc972fd3daf3e973f80072c4de09ec7e852b > Add option to control 'bin' directory of CMake's own installation (#16076) I suspect it is caused by this hunk: > - // Install tree has "/bin/cmake" and "". > - std::string dir = cmSystemTools::GetFilenamePath(exe_dir); > - cmSystemToolsCMakeRoot = dir + CMAKE_DATA_DIR; > - if (!cmSystemTools::FileExists( > + // Install tree has > + // - "/cmake" > + // - "" > + if (cmHasSuffix(exe_dir, CMAKE_BIN_DIR)) { > + std::string const prefix = > + exe_dir.substr(0, exe_dir.size() - strlen(CMAKE_BIN_DIR)); > + cmSystemToolsCMakeRoot = prefix + CMAKE_DATA_DIR; > + } > + if (cmSystemToolsCMakeRoot.empty() || > + !cmSystemTools::FileExists( Prior to that we would blindly strip one directory off the location no matter its name. Now we need to look for and strip the exactly-configured name of the bin directory because it may be more than one layer deep. CMake locates its own resources relative to its executable in order to make it relocatable. This means we don't expect the layout of the install tree to be changed after installation. You're doing that, so your use case is not supported. However, what the above commit did was give you a first-class way of supporting your use case by building with `CMAKE_BIN_DIR` set to the platform-specific name. You can use that to achieve the same result. Alternatively, if you *really* want to support your original use case you can work on a change to the above logic to count the number of path components in CMAKE_BIN_DIR and strip that many blindly instead of looking for the exact suffix. I won't be holding up 3.7 for that though. -Brad From Robert.Goulet at autodesk.com Tue Nov 8 14:16:27 2016 From: Robert.Goulet at autodesk.com (Robert Goulet) Date: Tue, 8 Nov 2016 19:16:27 +0000 Subject: [cmake-developers] cmake 3.7.0-rc3 regression In-Reply-To: <58e20ee7acc44ee1b369924c10846f14@CO1PR79MB010.MGDADSK.autodesk.com> References: <3cfd82b735894466afee73cbee59d2cb@CO1PR79MB010.MGDADSK.autodesk.com> <2918862.2kSMebckN0@daneel.sf-tec.de> <58e20ee7acc44ee1b369924c10846f14@CO1PR79MB010.MGDADSK.autodesk.com> Message-ID: <3dd5cb2c855f4322b8a891d431a1ecfb@CO1PR79MB010.MGDADSK.autodesk.com> Anyhow, here's a quick patch that fixes it. Thanks. -----Original Message----- From: Robert Goulet Sent: Tuesday, November 8, 2016 2:09 PM To: 'Rolf Eike Beer' ; cmake-developers at cmake.org Subject: RE: [cmake-developers] cmake 3.7.0-rc3 regression Not sure I understand why is this part of a build switch now? And what if we don't build CMake ourselves but instead, using prebuilt binaries from the CMake website? -----Original Message----- From: Rolf Eike Beer [mailto:eike at sf-mail.de] Sent: Tuesday, November 8, 2016 2:04 PM To: cmake-developers at cmake.org Cc: Robert Goulet Subject: Re: [cmake-developers] cmake 3.7.0-rc3 regression Am Dienstag, 8. November 2016, 18:59:34 schrieb Robert Goulet: > Hi, > > After trying to upgrade to CMake 3.7.0-rc3, we've found the following > regression: > > Previously, we were able to put multiple platform CMake executables in > the same root by just renaming the "bin" folder, so that they don't > overlap each other, as such: > > cmake/win/cmake.exe > cmake/mac/cmake > cmake/linux/cmake > cmake/share/... > cmake/doc/... > > However in 3.7.0-rc3 this is broken, no longer works if the CMake > binary folder isn't named specifically "bin". CMake will fail to > start, reporting "CMake Error: Could not find CMAKE_ROOT !!!". > > Traced it back to this commit: > > Commit: 18bfbc972fd3daf3e973f80072c4de09ec7e852b > > Add option to control 'bin' directory of CMake's own installation > (#16076) > > Add a `CMAKE_BIN_DIR` cache entry to CMake's own build configuration. > Add a `--bindir` option to the `bootstrap` script to set it. > > If this wasn't intentional, can we get a fix before 3.7.0 is released? If you read the commit message you should be able to fix your problem: just build the different CMake instances with different --bindir switches. Eike -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Fix-CMake-regression-unable-to-locate-cmake-root-dir.patch Type: application/octet-stream Size: 1068 bytes Desc: 0001-Fix-CMake-regression-unable-to-locate-cmake-root-dir.patch URL: From brad.king at kitware.com Tue Nov 8 14:23:49 2016 From: brad.king at kitware.com (Brad King) Date: Tue, 8 Nov 2016 14:23:49 -0500 Subject: [cmake-developers] cmake 3.7.0-rc3 regression In-Reply-To: <3dd5cb2c855f4322b8a891d431a1ecfb@CO1PR79MB010.MGDADSK.autodesk.com> References: <3cfd82b735894466afee73cbee59d2cb@CO1PR79MB010.MGDADSK.autodesk.com> <2918862.2kSMebckN0@daneel.sf-tec.de> <58e20ee7acc44ee1b369924c10846f14@CO1PR79MB010.MGDADSK.autodesk.com> <3dd5cb2c855f4322b8a891d431a1ecfb@CO1PR79MB010.MGDADSK.autodesk.com> Message-ID: <4dd7004f-38e6-c2d0-f9ea-ef918f76902e@kitware.com> On 11/08/2016 02:16 PM, Robert Goulet wrote: > + if (cmSystemToolsCMakeRoot.empty()) { > + std::string dir = cmSystemTools::GetFilenamePath(exe_dir); Please see my sibling response for why more logic is needed. -Brad From Robert.Goulet at autodesk.com Wed Nov 9 11:18:47 2016 From: Robert.Goulet at autodesk.com (Robert Goulet) Date: Wed, 9 Nov 2016 16:18:47 +0000 Subject: [cmake-developers] cmake 3.7.0-rc3 regression In-Reply-To: <523f3533-ba17-0156-03b3-b889454af592@kitware.com> References: <3cfd82b735894466afee73cbee59d2cb@CO1PR79MB010.MGDADSK.autodesk.com> <523f3533-ba17-0156-03b3-b889454af592@kitware.com> Message-ID: Ok thanks, we'll just build CMake for all platform from now on. -----Original Message----- From: Brad King [mailto:brad.king at kitware.com] Sent: Tuesday, November 8, 2016 2:13 PM To: Robert Goulet Cc: cmake-developers at cmake.org Subject: Re: [cmake-developers] cmake 3.7.0-rc3 regression On 11/08/2016 01:59 PM, Robert Goulet wrote: > Commit: 18bfbc972fd3daf3e973f80072c4de09ec7e852b > Add option to control 'bin' directory of CMake's own installation > (#16076) I suspect it is caused by this hunk: > - // Install tree has "/bin/cmake" and "". > - std::string dir = cmSystemTools::GetFilenamePath(exe_dir); > - cmSystemToolsCMakeRoot = dir + CMAKE_DATA_DIR; > - if (!cmSystemTools::FileExists( > + // Install tree has > + // - "/cmake" > + // - "" > + if (cmHasSuffix(exe_dir, CMAKE_BIN_DIR)) { > + std::string const prefix = > + exe_dir.substr(0, exe_dir.size() - strlen(CMAKE_BIN_DIR)); > + cmSystemToolsCMakeRoot = prefix + CMAKE_DATA_DIR; } if > + (cmSystemToolsCMakeRoot.empty() || > + !cmSystemTools::FileExists( Prior to that we would blindly strip one directory off the location no matter its name. Now we need to look for and strip the exactly-configured name of the bin directory because it may be more than one layer deep. CMake locates its own resources relative to its executable in order to make it relocatable. This means we don't expect the layout of the install tree to be changed after installation. You're doing that, so your use case is not supported. However, what the above commit did was give you a first-class way of supporting your use case by building with `CMAKE_BIN_DIR` set to the platform-specific name. You can use that to achieve the same result. Alternatively, if you *really* want to support your original use case you can work on a change to the above logic to count the number of path components in CMAKE_BIN_DIR and strip that many blindly instead of looking for the exact suffix. I won't be holding up 3.7 for that though. -Brad From maikelvandenhurk at hotmail.com Wed Nov 9 13:28:59 2016 From: maikelvandenhurk at hotmail.com (maikel van den Hurk) Date: Wed, 9 Nov 2016 18:28:59 +0000 Subject: [cmake-developers] Add property to get all linked libraries including transitive ones In-Reply-To: References: <7a00d177-ba7a-6f55-2af3-4e604ab495cc@kitware.com> <0e473bd0-69b3-f208-6a84-96a42105a918@kitware.com> <125594d6-4db6-40cf-4cf0-b9a527eea1ea@kitware.com>, Message-ID: When trying to remove the limitation I couldn't find any issue actually. Do I overlook something here? If not I can make a PR on gitlab which will make this possible. Maikel ________________________________ Van: cmake-developers namens Stephen Kelly Verzonden: maandag 7 november 2016 01:23 Aan: cmake-developers at cmake.org Onderwerp: Re: [cmake-developers] Add property to get all linked libraries including transitive ones Brad King wrote: > On 11/04/2016 09:52 AM, maikel van den Hurk wrote: >> What about doing what was targeted with this bug: >> https://cmake.org/Bug/view.php?id=12435? > > That issue is now tracked here: > > https://gitlab.kitware.com/cmake/cmake/issues/12435 [https://gitlab.kitware.com/uploads/project/avatar/541/cmakelogo-centered.png] Possibility to get all link libraries for a target? (#12435) ? Issues ? CMake / CMake gitlab.kitware.com This issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=12435). Further discussion may take place here. > > I've just added some notes to the discussion. > > Steve, do you recall why $ > is not transitive as genexes for other usage requirements are? I believe it's because of a chicken-egg concern - the link libraries are the basis for transitivity for other properties. I remember discussing that in the mailing list back in the design phase. Thanks, Steve. -- 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 brad.king at kitware.com Wed Nov 9 14:25:32 2016 From: brad.king at kitware.com (Brad King) Date: Wed, 9 Nov 2016 14:25:32 -0500 Subject: [cmake-developers] Add property to get all linked libraries including transitive ones In-Reply-To: References: <7a00d177-ba7a-6f55-2af3-4e604ab495cc@kitware.com> <0e473bd0-69b3-f208-6a84-96a42105a918@kitware.com> <125594d6-4db6-40cf-4cf0-b9a527eea1ea@kitware.com> Message-ID: On 11/09/2016 01:28 PM, maikel van den Hurk wrote: >> Stephen Kelly wrote: >> I believe it's because of a chicken-egg concern - the link libraries are the >> basis for transitivity for other properties. I remember discussing that in >> the mailing list back in the design phase. > > When trying to remove the limitation I couldn't find any issue actually. I think what may have happened was that originally we attempted to make the value of each usage requirement property itself (get_property) have the transitive closure already filled out. Later we changed to making the property itself non-transitive but have the genex evaluation take care of transitivity instead. This means there is no chicken-n-egg problem for LINK_LIBRARIES anymore. > I can make a PR on gitlab which will make this possible. Thanks. Note that changing $ behavior will require a policy. -Brad From ruslan_baratov at yahoo.com Thu Nov 10 10:05:28 2016 From: ruslan_baratov at yahoo.com (Ruslan Baratov) Date: Thu, 10 Nov 2016 23:05:28 +0800 Subject: [cmake-developers] Android variables Message-ID: <1a7b05c8-2073-43a6-a111-707e12a9f34a@yahoo.com> Hi, I wonder if it's possible to introduce next variables describing Android tools: * C preprocessor. Similar to CMAKE_CXX_COMPILER the variable that will contain the path to preprocessor. Example: * CMAKE_CXX_COMPILER = /toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64/bin/arm-linux-androideabi-g++ * CMAKE_C_PREPROCESSOR = /toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64/bin/arm-linux-androideabi-cpp * ANDROID_TOOLCHAIN_MACHINE_NAME. In fact I'm not sure what this variable mean but it's an important part of move from taka-no-me toolchain to CMake 3.7. I guess it's like * CMAKE_CXX_COMPILER = /toolchains/${ANDROID_TOOLCHAIN_MACHINE_NAME}-4.9/prebuilt/linux-x86_64/bin/${ANDROID_TOOLCHAIN_MACHINE_NAME}-g++ Of course if I'm not missing something and they are not already somewhere :) Ruslo From brad.king at kitware.com Thu Nov 10 11:29:27 2016 From: brad.king at kitware.com (Brad King) Date: Thu, 10 Nov 2016 11:29:27 -0500 Subject: [cmake-developers] Android variables In-Reply-To: <1a7b05c8-2073-43a6-a111-707e12a9f34a@yahoo.com> References: <1a7b05c8-2073-43a6-a111-707e12a9f34a@yahoo.com> Message-ID: On 11/10/2016 10:05 AM, Ruslan Baratov via cmake-developers wrote: > variables describing Android tools: See: * https://cmake.org/cmake/help/v3.7/variable/CMAKE_LANG_ANDROID_TOOLCHAIN_PREFIX.html * https://cmake.org/cmake/help/v3.7/variable/CMAKE_LANG_ANDROID_TOOLCHAIN_SUFFIX.html * https://gitlab.kitware.com/cmake/cmake/blob/v3.7.0-rc3/Tests/RunCMake/Android/common.cmake#L9-13 -Brad From ruslan_baratov at yahoo.com Thu Nov 10 22:46:06 2016 From: ruslan_baratov at yahoo.com (Ruslan Baratov) Date: Fri, 11 Nov 2016 11:46:06 +0800 Subject: [cmake-developers] Android variables In-Reply-To: References: <1a7b05c8-2073-43a6-a111-707e12a9f34a@yahoo.com> Message-ID: <66c8b5a5-358e-9c73-0841-dafea8167a69@yahoo.com> Okay, thanks. But this doesn't answer my question. So can we introduce new variable CMAKE_C_PREPROCESSOR with the value |"${CMAKE_CXX_ANDROID_TOOLCHAIN_PREFIX}cpp${CMAKE_CXX_ANDROID_TOOLCHAIN_SUFFIX}"? Similar to CMAKE_C_COMPILER, CMAKE_CXX_COMPILER, CMAKE_AR. What about ANDROID_TOOLCHAIN_MACHINE_NAME? Your proposal is to parse the last component of |||CMAKE_CXX_ANDROID_TOOLCHAIN_PREFIX? Does this one look good: || ||get_filename_component(ANDROID_TOOLCHAIN_MACHINE_NAME "${CMAKE_CXX_ANDROID_TOOLCHAIN_PREFIX}" NAME)|| ||string(REGEX REPLACE "-$" "" ||||||ANDROID_TOOLCHAIN_MACHINE_NAME|| "${||||||ANDROID_TOOLCHAIN_MACHINE_NAME||}") |||||| ||? Ruslo ||On 11-Nov-16 00:29, Brad King wrote: > On 11/10/2016 10:05 AM, Ruslan Baratov via cmake-developers wrote: >> variables describing Android tools: > See: > > * https://cmake.org/cmake/help/v3.7/variable/CMAKE_LANG_ANDROID_TOOLCHAIN_PREFIX.html > * https://cmake.org/cmake/help/v3.7/variable/CMAKE_LANG_ANDROID_TOOLCHAIN_SUFFIX.html > * https://gitlab.kitware.com/cmake/cmake/blob/v3.7.0-rc3/Tests/RunCMake/Android/common.cmake#L9-13 > > -Brad > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Fri Nov 11 08:09:56 2016 From: brad.king at kitware.com (Brad King) Date: Fri, 11 Nov 2016 08:09:56 -0500 Subject: [cmake-developers] Android variables In-Reply-To: <66c8b5a5-358e-9c73-0841-dafea8167a69@yahoo.com> References: <1a7b05c8-2073-43a6-a111-707e12a9f34a@yahoo.com> <66c8b5a5-358e-9c73-0841-dafea8167a69@yahoo.com> Message-ID: <0bf8b3c5-9372-c98a-45df-351bb591c3ba@kitware.com> On 11/10/2016 10:46 PM, Ruslan Baratov wrote: > the value "${CMAKE_CXX_ANDROID_TOOLCHAIN_PREFIX}cpp${CMAKE_CXX_ANDROID_TOOLCHAIN_SUFFIX}" This expression is the documented way to get the paths to the Android tools. I see no reason to add a pre-evaluated copy for every tool. > ANDROID_TOOLCHAIN_MACHINE_NAME? In your original message it looked like you needed this only to construct the path above. > get_filename_component(ANDROID_TOOLCHAIN_MACHINE_NAME "${CMAKE_CXX_ANDROID_TOOLCHAIN_PREFIX}" NAME) > string(REGEX REPLACE "-$" "" ANDROID_TOOLCHAIN_MACHINE_NAME "${ANDROID_TOOLCHAIN_MACHINE_NAME}") AFAICT the only meaning this value has is exactly what that code expresses. What is your use case for getting this value and why is it needed separately? -Brad From ruslan_baratov at yahoo.com Fri Nov 11 08:11:13 2016 From: ruslan_baratov at yahoo.com (Ruslan Baratov) Date: Fri, 11 Nov 2016 21:11:13 +0800 Subject: [cmake-developers] Android variables In-Reply-To: <1a7b05c8-2073-43a6-a111-707e12a9f34a@yahoo.com> References: <1a7b05c8-2073-43a6-a111-707e12a9f34a@yahoo.com> Message-ID: <302946f2-e390-c806-b00e-1c09e2071594@yahoo.com> On 10-Nov-16 23:05, Ruslan Baratov via cmake-developers wrote: > * CMAKE_CXX_COMPILER = > /toolchains/${ANDROID_TOOLCHAIN_MACHINE_NAME}-4.9/prebuilt/linux-x86_64/bin/${ANDROID_TOOLCHAIN_MACHINE_NAME}-g++ Actually there are more variables here, ANDROID_COMPILER_VERSION and ANDROID_NDK_HOST_SYSTEM_NAME: /toolchains/${ANDROID_TOOLCHAIN_MACHINE_NAME}-${ANDROID_COMPILER_VERSION}/prebuilt/${ANDROID_NDK_HOST_SYSTEM_NAME}/bin/${ANDROID_TOOLCHAIN_MACHINE_NAME}-g++ ANDROID_COMPILER_VERSION is similar to CMAKE_ANDROID_NDK_TOOLCHAIN_VERSION. However CMAKE_ANDROID_NDK_TOOLCHAIN_VERSION is designed to be set by user as far as I understand. It is empty by default. ANDROID_NDK_HOST_SYSTEM_NAME called _ANDROID_HOST_DIR in CMake 3.7 and used only internally. What about making it public? Ruslo From brad.king at kitware.com Fri Nov 11 08:20:46 2016 From: brad.king at kitware.com (Brad King) Date: Fri, 11 Nov 2016 08:20:46 -0500 Subject: [cmake-developers] Android variables In-Reply-To: <302946f2-e390-c806-b00e-1c09e2071594@yahoo.com> References: <1a7b05c8-2073-43a6-a111-707e12a9f34a@yahoo.com> <302946f2-e390-c806-b00e-1c09e2071594@yahoo.com> Message-ID: <1aa35321-2e6e-c9e7-2326-ed6f4e2c9f17@kitware.com> On 11/11/2016 08:11 AM, Ruslan Baratov wrote: > What about making it public? Please explain your use case for each piece of information you request. Maybe there is already a way to do it. -Brad From ruslan_baratov at yahoo.com Fri Nov 11 08:28:46 2016 From: ruslan_baratov at yahoo.com (Ruslan Baratov) Date: Fri, 11 Nov 2016 21:28:46 +0800 Subject: [cmake-developers] Android variables In-Reply-To: <0bf8b3c5-9372-c98a-45df-351bb591c3ba@kitware.com> References: <1a7b05c8-2073-43a6-a111-707e12a9f34a@yahoo.com> <66c8b5a5-358e-9c73-0841-dafea8167a69@yahoo.com> <0bf8b3c5-9372-c98a-45df-351bb591c3ba@kitware.com> Message-ID: <1faaf1a1-e46d-4f0f-45c9-1e1f3d3857a6@yahoo.com> On 11-Nov-16 21:09, Brad King wrote: > On 11/10/2016 10:46 PM, Ruslan Baratov wrote: >> the value "${CMAKE_CXX_ANDROID_TOOLCHAIN_PREFIX}cpp${CMAKE_CXX_ANDROID_TOOLCHAIN_SUFFIX}" > This expression is the documented way to get the paths to the Android tools. > I see no reason to add a pre-evaluated copy for every tool. Reason is the same as with CMAKE_GDBSERVER variable. Instead of forcing users to redefine (probably with different names) this variable each time we can do it once in CMake. > >> ANDROID_TOOLCHAIN_MACHINE_NAME? > In your original message it looked like you needed this only to construct > the path above. Nope, this one needed too. > >> get_filename_component(ANDROID_TOOLCHAIN_MACHINE_NAME "${CMAKE_CXX_ANDROID_TOOLCHAIN_PREFIX}" NAME) >> string(REGEX REPLACE "-$" "" ANDROID_TOOLCHAIN_MACHINE_NAME "${ANDROID_TOOLCHAIN_MACHINE_NAME}") > AFAICT the only meaning this value has is exactly what that code expresses. > > What is your use case for getting this value and why is it needed separately? Even if they may not be needed in regular CMake code such variables can be useful "outside". Autotools based projects use ANDROID_TOOLCHAIN_MACHINE_NAME variable: `./configure --host=${ANDROID_TOOLCHAIN_MACHINE_NAME}`. Preprocessor is required too: `CPP=${CMAKE_C_PREPROCESSOR} ./configure`. Variables ANDROID_NDK_HOST_SYSTEM_NAME and ANDROID_COMPILER_VERSION is used in tool `androiddeployqt` which do build Qt application for Android. Ruslo -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Fri Nov 11 13:51:27 2016 From: brad.king at kitware.com (Brad King) Date: Fri, 11 Nov 2016 13:51:27 -0500 Subject: [cmake-developers] Android variables In-Reply-To: <1faaf1a1-e46d-4f0f-45c9-1e1f3d3857a6@yahoo.com> References: <1a7b05c8-2073-43a6-a111-707e12a9f34a@yahoo.com> <66c8b5a5-358e-9c73-0841-dafea8167a69@yahoo.com> <0bf8b3c5-9372-c98a-45df-351bb591c3ba@kitware.com> <1faaf1a1-e46d-4f0f-45c9-1e1f3d3857a6@yahoo.com> Message-ID: On 11/11/2016 08:28 AM, Ruslan Baratov wrote: > Even if they may not be needed in regular CMake code such variables can be useful "outside". Okay, thanks. I'll investigate how to properly expose this information. -Brad From robert.maynard at kitware.com Fri Nov 11 14:32:03 2016 From: robert.maynard at kitware.com (Robert Maynard) Date: Fri, 11 Nov 2016 14:32:03 -0500 Subject: [cmake-developers] [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 florent.castelli at gmail.com Fri Nov 11 19:21:11 2016 From: florent.castelli at gmail.com (Florent Castelli) Date: Sat, 12 Nov 2016 01:21:11 +0100 Subject: [cmake-developers] Android variables In-Reply-To: <1a7b05c8-2073-43a6-a111-707e12a9f34a@yahoo.com> References: <1a7b05c8-2073-43a6-a111-707e12a9f34a@yahoo.com> Message-ID: <7bed5423-6555-4854-3e6a-e7e8eabec0b0@gmail.com> On 10/11/2016 16:05, Ruslan Baratov via cmake-developers wrote: > Hi, > > I wonder if it's possible to introduce next variables describing Android > tools: > * C preprocessor. Similar to CMAKE_CXX_COMPILER the variable that will > contain the path to preprocessor. Example: > * CMAKE_CXX_COMPILER = > /toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64/bin/arm-linux-androideabi-g++ > * CMAKE_C_PREPROCESSOR = > /toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64/bin/arm-linux-androideabi-cpp > * ANDROID_TOOLCHAIN_MACHINE_NAME. In fact I'm not sure what this > variable mean but it's an important part of move from taka-no-me > toolchain to CMake 3.7. I guess it's like > * CMAKE_CXX_COMPILER = > /toolchains/${ANDROID_TOOLCHAIN_MACHINE_NAME}-4.9/prebuilt/linux-x86_64/bin/${ANDROID_TOOLCHAIN_MACHINE_NAME}-g++ > > Of course if I'm not missing something and they are not already somewhere :) > > Ruslo How about ${CMAKE_C/CXX_COMPILER} -E to call the preprocessor? Calling it directly is kind of dangerous though since you will probably be missing the proper language information and other options that might affect the predefined preprocessor defines. gcc has different binaries for different target archs and has some defines baked in, but this won't apply to Clang that uses only one binary and a target triple. You'll also lose the c/c++ language definition (unless you pass -x c++), language standard in use... gcc (or clang) are just "drivers". They will call the proper programs automatically. Either the preprocessor, the compiler (cc1) or the linker, so you should be able to do everything with it directly! As for the ANDROID_TOOLCHAIN_MACHINE_NAME that is used for gcc prefix, it shouldn't be needed. If you rely on gcc, you should investigate on using Clang which is the supported compiler now in the NDK. What is your exact usage of the variable? /Florent From ruslan_baratov at yahoo.com Sat Nov 12 00:53:05 2016 From: ruslan_baratov at yahoo.com (Ruslan Baratov) Date: Sat, 12 Nov 2016 13:53:05 +0800 Subject: [cmake-developers] Android variables In-Reply-To: <7bed5423-6555-4854-3e6a-e7e8eabec0b0@gmail.com> References: <1a7b05c8-2073-43a6-a111-707e12a9f34a@yahoo.com> <7bed5423-6555-4854-3e6a-e7e8eabec0b0@gmail.com> Message-ID: <0536d034-1574-5462-5b02-7924dbec63f9@yahoo.com> On 12-Nov-16 08:21, Florent Castelli wrote: > On 10/11/2016 16:05, Ruslan Baratov via cmake-developers wrote: >> Hi, >> >> I wonder if it's possible to introduce next variables describing Android >> tools: >> * C preprocessor. Similar to CMAKE_CXX_COMPILER the variable that will >> contain the path to preprocessor. Example: >> * CMAKE_CXX_COMPILER = >> /toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64/bin/arm-linux-androideabi-g++ >> >> * CMAKE_C_PREPROCESSOR = >> /toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64/bin/arm-linux-androideabi-cpp >> >> * ANDROID_TOOLCHAIN_MACHINE_NAME. In fact I'm not sure what this >> variable mean but it's an important part of move from taka-no-me >> toolchain to CMake 3.7. I guess it's like >> * CMAKE_CXX_COMPILER = >> /toolchains/${ANDROID_TOOLCHAIN_MACHINE_NAME}-4.9/prebuilt/linux-x86_64/bin/${ANDROID_TOOLCHAIN_MACHINE_NAME}-g++ >> >> >> Of course if I'm not missing something and they are not already >> somewhere :) >> >> Ruslo > > How about ${CMAKE_C/CXX_COMPILER} -E to call the preprocessor? I have no idea and not planning to test it because the old code was using `cpp` preprocessor and I see no point of changing it. > Calling it directly is kind of dangerous though since you will > probably be missing the proper language information and other options > that might affect the predefined preprocessor defines. I'm not calling it directly, it was used by `configure` script of 3rd party. > gcc has different binaries for different target archs and has some > defines baked in, but this won't apply to Clang that uses only one > binary and a target triple. For clang based android toolchain the CMAKE_CXX_ANDROID_TOOLCHAIN_PREFIX variable points to the directory with gcc, so it will find `cpp` preprocessor too. I don't know if it's good or bad :) Ruslo > You'll also lose the c/c++ language definition (unless you pass -x > c++), language standard in use... From florent.castelli at gmail.com Sat Nov 12 06:09:10 2016 From: florent.castelli at gmail.com (Florent Castelli) Date: Sat, 12 Nov 2016 12:09:10 +0100 Subject: [cmake-developers] Android variables In-Reply-To: <0536d034-1574-5462-5b02-7924dbec63f9@yahoo.com> References: <1a7b05c8-2073-43a6-a111-707e12a9f34a@yahoo.com> <7bed5423-6555-4854-3e6a-e7e8eabec0b0@gmail.com> <0536d034-1574-5462-5b02-7924dbec63f9@yahoo.com> Message-ID: <23d7fa86-b4ff-d96e-a28b-9456447f7a20@gmail.com> On 12/11/2016 06:53, Ruslan Baratov wrote: > On 12-Nov-16 08:21, Florent Castelli wrote: >> On 10/11/2016 16:05, Ruslan Baratov via cmake-developers wrote: >>> Hi, >>> >>> I wonder if it's possible to introduce next variables describing Android >>> tools: >>> * C preprocessor. Similar to CMAKE_CXX_COMPILER the variable that will >>> contain the path to preprocessor. Example: >>> * CMAKE_CXX_COMPILER = >>> /toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64/bin/arm-linux-androideabi-g++ >>> >>> * CMAKE_C_PREPROCESSOR = >>> /toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64/bin/arm-linux-androideabi-cpp >>> >>> * ANDROID_TOOLCHAIN_MACHINE_NAME. In fact I'm not sure what this >>> variable mean but it's an important part of move from taka-no-me >>> toolchain to CMake 3.7. I guess it's like >>> * CMAKE_CXX_COMPILER = >>> /toolchains/${ANDROID_TOOLCHAIN_MACHINE_NAME}-4.9/prebuilt/linux-x86_64/bin/${ANDROID_TOOLCHAIN_MACHINE_NAME}-g++ >>> >>> >>> Of course if I'm not missing something and they are not already >>> somewhere :) >>> >>> Ruslo >> How about ${CMAKE_C/CXX_COMPILER} -E to call the preprocessor? > I have no idea and not planning to test it because the old code was > using `cpp` preprocessor and I see no point of changing it. Well, you can define your preprocessor to be "${CMAKE_C_COMPILER} -E" locally and it will work with GCC-like compilers. That's a more robust way to call it as there is no CMAKE_C_PREPROCESSOR standard value in any CMake file. Nobody should call "cpp" manually anymore, but use the compiler driver instead to do it for you. That's why there's no standard CPP variable in CMake, it's not needed at all. For the same reasons, you rarely have to call the linker directly, it's usually done through the compiler driver. >> Calling it directly is kind of dangerous though since you will >> probably be missing the proper language information and other options >> that might affect the predefined preprocessor defines. > I'm not calling it directly, it was used by `configure` script of 3rd party. > >> gcc has different binaries for different target archs and has some >> defines baked in, but this won't apply to Clang that uses only one >> binary and a target triple. > For clang based android toolchain the CMAKE_CXX_ANDROID_TOOLCHAIN_PREFIX > variable points to the directory with gcc, so it will find `cpp` > preprocessor too. I don't know if it's good or bad :) I think that's an implementation detail you shouldn't rely on. The compilers in the NDK are changing, GCC is deprecated and you shouldn't expect that. Clang is mostly self contained and using very little from the GCC distribution (binutils), it will be gone at some point, so you should be ready for the future. If you're updating CMake and changing the toolchain file, then I would expect that some work has to be done, including making changes to the invocation of a 3rd party script that is using custom variables from the old toolchain. Overall, I consider that taka-no-me Android toolchain to be tech debt. It hasn't been updated for a long time, doesn't work with recent NDK (unless you resort to use a standalone toolchain), locks people with some custom variables making them believe they are standard and has tons of other small bugs and issues. I understand its appeal for most people, but to me, it has caused more trouble than help. It could have been done so much better. /Florent From ruslan_baratov at yahoo.com Sat Nov 12 07:35:46 2016 From: ruslan_baratov at yahoo.com (Ruslan Baratov) Date: Sat, 12 Nov 2016 20:35:46 +0800 Subject: [cmake-developers] Android variables In-Reply-To: <23d7fa86-b4ff-d96e-a28b-9456447f7a20@gmail.com> References: <1a7b05c8-2073-43a6-a111-707e12a9f34a@yahoo.com> <7bed5423-6555-4854-3e6a-e7e8eabec0b0@gmail.com> <0536d034-1574-5462-5b02-7924dbec63f9@yahoo.com> <23d7fa86-b4ff-d96e-a28b-9456447f7a20@gmail.com> Message-ID: <343c4ea0-cfeb-8e3b-f948-96894259401a@yahoo.com> On 12-Nov-16 19:09, Florent Castelli wrote: > On 12/11/2016 06:53, Ruslan Baratov wrote: >> On 12-Nov-16 08:21, Florent Castelli wrote: >>> On 10/11/2016 16:05, Ruslan Baratov via cmake-developers wrote: >>>> Hi, >>>> >>>> I wonder if it's possible to introduce next variables describing >>>> Android >>>> tools: >>>> * C preprocessor. Similar to CMAKE_CXX_COMPILER the variable that will >>>> contain the path to preprocessor. Example: >>>> * CMAKE_CXX_COMPILER = >>>> /toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64/bin/arm-linux-androideabi-g++ >>>> >>>> >>>> * CMAKE_C_PREPROCESSOR = >>>> /toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64/bin/arm-linux-androideabi-cpp >>>> >>>> >>>> * ANDROID_TOOLCHAIN_MACHINE_NAME. In fact I'm not sure what this >>>> variable mean but it's an important part of move from taka-no-me >>>> toolchain to CMake 3.7. I guess it's like >>>> * CMAKE_CXX_COMPILER = >>>> /toolchains/${ANDROID_TOOLCHAIN_MACHINE_NAME}-4.9/prebuilt/linux-x86_64/bin/${ANDROID_TOOLCHAIN_MACHINE_NAME}-g++ >>>> >>>> >>>> >>>> Of course if I'm not missing something and they are not already >>>> somewhere :) >>>> >>>> Ruslo >>> How about ${CMAKE_C/CXX_COMPILER} -E to call the preprocessor? >> I have no idea and not planning to test it because the old code was >> using `cpp` preprocessor and I see no point of changing it. > Well, you can define your preprocessor to be "${CMAKE_C_COMPILER} -E" > locally and it will work with GCC-like compilers. > That's a more robust way to call it as there is no > CMAKE_C_PREPROCESSOR standard value in any CMake file. > Nobody should call "cpp" manually anymore, but use the compiler driver > instead to do it for you. > > That's why there's no standard CPP variable in CMake, it's not needed > at all. > For the same reasons, you rarely have to call the linker directly, > it's usually done through the compiler driver. Just like I said I'm not using it - this variable needed for 3rd party package. I have no idea how it was used, the only thing I know is that if I remove this variable the package stop working. > >>> Calling it directly is kind of dangerous though since you will >>> probably be missing the proper language information and other options >>> that might affect the predefined preprocessor defines. >> I'm not calling it directly, it was used by `configure` script of 3rd >> party. >> >>> gcc has different binaries for different target archs and has some >>> defines baked in, but this won't apply to Clang that uses only one >>> binary and a target triple. >> For clang based android toolchain the CMAKE_CXX_ANDROID_TOOLCHAIN_PREFIX >> variable points to the directory with gcc, so it will find `cpp` >> preprocessor too. I don't know if it's good or bad :) > > I think that's an implementation detail you shouldn't rely on. The > compilers in the NDK are changing, GCC is deprecated and you shouldn't > expect that. > Clang is mostly self contained and using very little from the GCC > distribution (binutils), it will be gone at some point, so you should > be ready for the future. My goal now is to move from taka-no-me to CMake 3.7+ Android. I don't bother about the destiny of GCC distribution. When this stuff will change the problems will appear in both taka-no-me and CMake 3.7+. > > If you're updating CMake and changing the toolchain file, then I would > expect that some work has to be done, including making changes to the > invocation of a 3rd party script that is using custom variables from > the old toolchain. There is a tricky part about that. I do define variables like CMAKE_SYSTEM_VERSION or CMAKE_ANDROID_ARCH_ABI and CMake gives me back CMAKE_CXX_ANDROID_TOOLCHAIN_PREFIX. But CMAKE_CXX_ANDROID_TOOLCHAIN_PREFIX is only available **after** toolchain processed hence I can't use such variable in toolchain to create my custom variables. So if we want to have everything play nice this should be defined in CMake. > Overall, I consider that taka-no-me Android toolchain to be tech debt. > It hasn't been updated for a long time, doesn't work with recent NDK > (unless you resort to use a standalone toolchain), locks people with > some custom variables making them believe they are standard and has > tons of other small bugs and issues. > I understand its appeal for most people, but to me, it has caused more > trouble than help. Just like I said before, those variables needed in 3rd party tools which is not related neither to CMake nor to taka-no-me toolchain. I see no point of discussing issues you have with taka-no-me toolchain. > It could have been done so much better. It's open source world. From my opinion every question like "why it's not so good?" should really be "why I'm not improving it?" or "why I'm not doing something better?". Ruslo -------------- next part -------------- An HTML attachment was scrubbed... URL: From florent.castelli at gmail.com Sat Nov 12 11:48:39 2016 From: florent.castelli at gmail.com (Florent Castelli) Date: Sat, 12 Nov 2016 17:48:39 +0100 Subject: [cmake-developers] Android variables In-Reply-To: <343c4ea0-cfeb-8e3b-f948-96894259401a@yahoo.com> References: <1a7b05c8-2073-43a6-a111-707e12a9f34a@yahoo.com> <7bed5423-6555-4854-3e6a-e7e8eabec0b0@gmail.com> <0536d034-1574-5462-5b02-7924dbec63f9@yahoo.com> <23d7fa86-b4ff-d96e-a28b-9456447f7a20@gmail.com> <343c4ea0-cfeb-8e3b-f948-96894259401a@yahoo.com> Message-ID: <14434876-e42f-8cfc-90c9-c9ed362b8027@gmail.com> On 12/11/2016 13:35, Ruslan Baratov wrote: > On 12-Nov-16 19:09, Florent Castelli wrote: >> On 12/11/2016 06:53, Ruslan Baratov wrote: >>> On 12-Nov-16 08:21, Florent Castelli wrote: >>>> On 10/11/2016 16:05, Ruslan Baratov via cmake-developers wrote: >>>>> Hi, >>>>> >>>>> I wonder if it's possible to introduce next variables describing >>>>> Android >>>>> tools: >>>>> * C preprocessor. Similar to CMAKE_CXX_COMPILER the variable that >>>>> will >>>>> contain the path to preprocessor. Example: >>>>> * CMAKE_CXX_COMPILER = >>>>> /toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64/bin/arm-linux-androideabi-g++ >>>>> >>>>> >>>>> * CMAKE_C_PREPROCESSOR = >>>>> /toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64/bin/arm-linux-androideabi-cpp >>>>> >>>>> >>>>> * ANDROID_TOOLCHAIN_MACHINE_NAME. In fact I'm not sure what this >>>>> variable mean but it's an important part of move from taka-no-me >>>>> toolchain to CMake 3.7. I guess it's like >>>>> * CMAKE_CXX_COMPILER = >>>>> /toolchains/${ANDROID_TOOLCHAIN_MACHINE_NAME}-4.9/prebuilt/linux-x86_64/bin/${ANDROID_TOOLCHAIN_MACHINE_NAME}-g++ >>>>> >>>>> >>>>> >>>>> Of course if I'm not missing something and they are not already >>>>> somewhere :) >>>>> >>>>> Ruslo >>>> How about ${CMAKE_C/CXX_COMPILER} -E to call the preprocessor? >>> I have no idea and not planning to test it because the old code was >>> using `cpp` preprocessor and I see no point of changing it. >> Well, you can define your preprocessor to be "${CMAKE_C_COMPILER} -E" >> locally and it will work with GCC-like compilers. >> That's a more robust way to call it as there is no >> CMAKE_C_PREPROCESSOR standard value in any CMake file. >> Nobody should call "cpp" manually anymore, but use the compiler >> driver instead to do it for you. >> >> That's why there's no standard CPP variable in CMake, it's not needed >> at all. >> For the same reasons, you rarely have to call the linker directly, >> it's usually done through the compiler driver. > Just like I said I'm not using it - this variable needed for 3rd party > package. I have no idea how it was used, the only thing I know is that > if I remove this variable the package stop working. Then just set it yourself as I said. You don't even need 3.7.0, you can just override it in the current version of CMake and previous toolchain you used. The 3rd party package using it should still work. Use small incremental steps, in order to migrate. It will be easier. > >> >>>> Calling it directly is kind of dangerous though since you will >>>> probably be missing the proper language information and other options >>>> that might affect the predefined preprocessor defines. >>> I'm not calling it directly, it was used by `configure` script of >>> 3rd party. >>> >>>> gcc has different binaries for different target archs and has some >>>> defines baked in, but this won't apply to Clang that uses only one >>>> binary and a target triple. >>> For clang based android toolchain the >>> CMAKE_CXX_ANDROID_TOOLCHAIN_PREFIX >>> variable points to the directory with gcc, so it will find `cpp` >>> preprocessor too. I don't know if it's good or bad :) >> >> I think that's an implementation detail you shouldn't rely on. The >> compilers in the NDK are changing, GCC is deprecated and you >> shouldn't expect that. >> Clang is mostly self contained and using very little from the GCC >> distribution (binutils), it will be gone at some point, so you should >> be ready for the future. > My goal now is to move from taka-no-me to CMake 3.7+ Android. I don't > bother about the destiny of GCC distribution. When this stuff will > change the problems will appear in both taka-no-me and CMake 3.7+. Well, you should care as the cpp program will likely disappear and you will need other means to preprocess anything directly (gcc/clang -E). Better do it now and break one of the last dependency you have and migrate away from old custom variables. > >> >> If you're updating CMake and changing the toolchain file, then I >> would expect that some work has to be done, including making changes >> to the invocation of a 3rd party script that is using custom >> variables from the old toolchain. > There is a tricky part about that. I do define variables like > CMAKE_SYSTEM_VERSION or CMAKE_ANDROID_ARCH_ABI and CMake gives me back > CMAKE_CXX_ANDROID_TOOLCHAIN_PREFIX. But > CMAKE_CXX_ANDROID_TOOLCHAIN_PREFIX is only available **after** > toolchain processed hence I can't use such variable in toolchain to > create my custom variables. So if we want to have everything play nice > this should be defined in CMake. Why do you need that variable to be defined in the toolchain? It shouldn't be a problem to define it outside of it or just before you use the 3rd party package that is using it. > >> Overall, I consider that taka-no-me Android toolchain to be tech >> debt. It hasn't been updated for a long time, doesn't work with >> recent NDK (unless you resort to use a standalone toolchain), locks >> people with some custom variables making them believe they are >> standard and has tons of other small bugs and issues. >> I understand its appeal for most people, but to me, it has caused >> more trouble than help. > Just like I said before, those variables needed in 3rd party tools > which is not related neither to CMake nor to taka-no-me toolchain. I > see no point of discussing issues you have with taka-no-me toolchain. So the content of the variables is needed by the 3rd party tools, but the variables are used by your script initially, so it's your responsibility to pass another content, like the one I suggested. > >> It could have been done so much better. > It's open source world. From my opinion every question like "why it's > not so good?" should really be "why I'm not improving it?" or "why I'm > not doing something better?". > The problem is that the owner abandoned it and isn't answering to issues or merging any pull request. Sure people can fork it, but they will likely not be found by users. People who didn't check the PRs on the project are probably stuck at some older version of the NDK, inhibiting progress. > Ruslo -------------- next part -------------- An HTML attachment was scrubbed... URL: From ruslan_baratov at yahoo.com Sun Nov 13 00:10:09 2016 From: ruslan_baratov at yahoo.com (Ruslan Baratov) Date: Sun, 13 Nov 2016 13:10:09 +0800 Subject: [cmake-developers] Android variables In-Reply-To: <14434876-e42f-8cfc-90c9-c9ed362b8027@gmail.com> References: <1a7b05c8-2073-43a6-a111-707e12a9f34a@yahoo.com> <7bed5423-6555-4854-3e6a-e7e8eabec0b0@gmail.com> <0536d034-1574-5462-5b02-7924dbec63f9@yahoo.com> <23d7fa86-b4ff-d96e-a28b-9456447f7a20@gmail.com> <343c4ea0-cfeb-8e3b-f948-96894259401a@yahoo.com> <14434876-e42f-8cfc-90c9-c9ed362b8027@gmail.com> Message-ID: <7b01088e-2061-14db-577e-26957d6e3df9@yahoo.com> On 13-Nov-16 00:48, Florent Castelli wrote: > On 12/11/2016 13:35, Ruslan Baratov wrote: >> On 12-Nov-16 19:09, Florent Castelli wrote: >>> On 12/11/2016 06:53, Ruslan Baratov wrote: >>>> On 12-Nov-16 08:21, Florent Castelli wrote: >>>>> On 10/11/2016 16:05, Ruslan Baratov via cmake-developers wrote: >>>>>> Hi, >>>>>> >>>>>> I wonder if it's possible to introduce next variables describing >>>>>> Android >>>>>> tools: >>>>>> * C preprocessor. Similar to CMAKE_CXX_COMPILER the variable that >>>>>> will >>>>>> contain the path to preprocessor. Example: >>>>>> * CMAKE_CXX_COMPILER = >>>>>> /toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64/bin/arm-linux-androideabi-g++ >>>>>> >>>>>> >>>>>> * CMAKE_C_PREPROCESSOR = >>>>>> /toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64/bin/arm-linux-androideabi-cpp >>>>>> >>>>>> >>>>>> * ANDROID_TOOLCHAIN_MACHINE_NAME. In fact I'm not sure what this >>>>>> variable mean but it's an important part of move from taka-no-me >>>>>> toolchain to CMake 3.7. I guess it's like >>>>>> * CMAKE_CXX_COMPILER = >>>>>> /toolchains/${ANDROID_TOOLCHAIN_MACHINE_NAME}-4.9/prebuilt/linux-x86_64/bin/${ANDROID_TOOLCHAIN_MACHINE_NAME}-g++ >>>>>> >>>>>> >>>>>> >>>>>> Of course if I'm not missing something and they are not already >>>>>> somewhere :) >>>>>> >>>>>> Ruslo >>>>> How about ${CMAKE_C/CXX_COMPILER} -E to call the preprocessor? >>>> I have no idea and not planning to test it because the old code was >>>> using `cpp` preprocessor and I see no point of changing it. >>> Well, you can define your preprocessor to be "${CMAKE_C_COMPILER} >>> -E" locally and it will work with GCC-like compilers. >>> That's a more robust way to call it as there is no >>> CMAKE_C_PREPROCESSOR standard value in any CMake file. >>> Nobody should call "cpp" manually anymore, but use the compiler >>> driver instead to do it for you. >>> >>> That's why there's no standard CPP variable in CMake, it's not >>> needed at all. >>> For the same reasons, you rarely have to call the linker directly, >>> it's usually done through the compiler driver. >> Just like I said I'm not using it - this variable needed for 3rd >> party package. I have no idea how it was used, the only thing I know >> is that if I remove this variable the package stop working. > Then just set it yourself as I said. You don't even need 3.7.0, you > can just override it in the current version of CMake and previous > toolchain you used. I'm trying to move to 3.7.0 variables (that now became standard) and drop old toolchain. And you're giving me advice to not rely on 3.7.0 and use previous toolchain? > The 3rd party package using it should still work. > Use small incremental steps, in order to migrate. It will be easier. That's exactly what I'm doing now. > >> >>> >>>>> Calling it directly is kind of dangerous though since you will >>>>> probably be missing the proper language information and other options >>>>> that might affect the predefined preprocessor defines. >>>> I'm not calling it directly, it was used by `configure` script of >>>> 3rd party. >>>> >>>>> gcc has different binaries for different target archs and has some >>>>> defines baked in, but this won't apply to Clang that uses only one >>>>> binary and a target triple. >>>> For clang based android toolchain the >>>> CMAKE_CXX_ANDROID_TOOLCHAIN_PREFIX >>>> variable points to the directory with gcc, so it will find `cpp` >>>> preprocessor too. I don't know if it's good or bad :) >>> >>> I think that's an implementation detail you shouldn't rely on. The >>> compilers in the NDK are changing, GCC is deprecated and you >>> shouldn't expect that. >>> Clang is mostly self contained and using very little from the GCC >>> distribution (binutils), it will be gone at some point, so you >>> should be ready for the future. >> My goal now is to move from taka-no-me to CMake 3.7+ Android. I don't >> bother about the destiny of GCC distribution. When this stuff will >> change the problems will appear in both taka-no-me and CMake 3.7+. > Well, you should care as the cpp program will likely disappear and you > will need other means to preprocess anything directly (gcc/clang -E). > Better do it now and break one of the last dependency you have and > migrate away from old custom variables. There are a lot of "small" and "obvious" things to improve during migration, however I will never end it if I will rush to fix them all. I'm focused now on using new variables. Just like you said "Use small incremental steps". > >> >>> >>> If you're updating CMake and changing the toolchain file, then I >>> would expect that some work has to be done, including making changes >>> to the invocation of a 3rd party script that is using custom >>> variables from the old toolchain. >> There is a tricky part about that. I do define variables like >> CMAKE_SYSTEM_VERSION or CMAKE_ANDROID_ARCH_ABI and CMake gives me >> back CMAKE_CXX_ANDROID_TOOLCHAIN_PREFIX. But >> CMAKE_CXX_ANDROID_TOOLCHAIN_PREFIX is only available **after** >> toolchain processed hence I can't use such variable in toolchain to >> create my custom variables. So if we want to have everything play >> nice this should be defined in CMake. > Why do you need that variable to be defined in the toolchain? It > shouldn't be a problem to define it outside of it or just before you > use the 3rd party package that is using it. Where outside? If they used by several projects I have to duplicate this code. Or create extra module with such variables... Similar variables already defined by toolchain. Those variables are obviously strongly coupled with Android toolchain and not with the package. > >> >>> Overall, I consider that taka-no-me Android toolchain to be tech >>> debt. It hasn't been updated for a long time, doesn't work with >>> recent NDK (unless you resort to use a standalone toolchain), locks >>> people with some custom variables making them believe they are >>> standard and has tons of other small bugs and issues. >>> I understand its appeal for most people, but to me, it has caused >>> more trouble than help. >> Just like I said before, those variables needed in 3rd party tools >> which is not related neither to CMake nor to taka-no-me toolchain. I >> see no point of discussing issues you have with taka-no-me toolchain. > So the content of the variables is needed by the 3rd party tools, but > the variables are used by your script initially, so it's your > responsibility to pass another content, like the one I suggested. Sibling variables defined by CMake, some of the variables defined internally already and all that need to be done is to make them public. "Do it locally" - I don't understand that point at all. CMAKE_CXX_COMPILER_VERSION - why we need this? You can always do `CMAKE_CXX_COMPILER -version`. CMAKE_HOST_SYSTEM - why we need this? Just parse `uname`, etc. > >> >>> It could have been done so much better. >> It's open source world. From my opinion every question like "why it's >> not so good?" should really be "why I'm not improving it?" or "why >> I'm not doing something better?". >> > The problem is that the owner abandoned it and isn't answering to > issues or merging any pull request. And what is the problem exactly? Did he made a promise to you? Did you pay him money and then he refused to keep supporting you? According to the history it started in 2011 so it's about 5 years now of saving developers from headache of creating their own Android toolchains. And note that it's **CMake** toolchain for development on **Android** platform, so why you're not asking Google and/or CMake first where they were all this years? > Sure people can fork it, but they will likely not be found by users. > People who didn't check the PRs on the project are probably stuck at > some older version of the NDK, inhibiting progress. This sounds like 1000 plus one reason to not to do anything about it. Developers should take the responsibility and move on in such cases, instead of whining and complaining. Ruslo -------------- next part -------------- An HTML attachment was scrubbed... URL: From irwin at beluga.phys.uvic.ca Sun Nov 13 01:48:13 2016 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Sat, 12 Nov 2016 22:48:13 -0800 (PST) Subject: [cmake-developers] Current deficiencies of automoc In-Reply-To: <8ac54358-a98a-1751-325c-af7f79d16489@xwmw.org> References: <8ac54358-a98a-1751-325c-af7f79d16489@xwmw.org> Message-ID: On 2016-10-22 19:49+0200 Sebastian Holtermann wrote: [...] > Actually I made an implementation in 3.6.0 that generated the moc files > in the a build tree subdirectory correspoding to the header path. > But that blew up on some projects because the generated paths got too long > for some compi?ers. That implementation was theefore reverted. > In 3.7 there is a new approatch that generates the moc files in > ${CMAKE_BINARY_DIR}/ > ${TARGETNAME}_automoc.dir/ > ${HEADERNAME}_${HEADERPATHCHECKSUM}.cpp > This ensures that the paths don't get too long and that there won't be any > name collisions. Hi Sebastian: After a substantial break to finish off a different project, I have now had a chance to return to the present topic using my attached test_automoc project. (Also available in the cmake/test_automoc subdirectory of the PLplot git master branch that can be accessed at .) The project builds 6 separate simple Qt5 applications that #include a header that needs moc processing. The only differences between the source code files for the various executables is the name and directory location of that #include'd file and the various instructions given to automoc (and in one case qt5_wrap_cpp) to process that file. With that test project, I now confirm (sorry about the noise to the contrary before) that automoc does use the approach you mentioned above for CMake-3.7.0 to reduce the name collisions that occur for that same project for earlier versions of CMake. Concerning the collisions still expected for 3.7.0, the automoc documentation (see ) states the following: "However, if multiple source files in different directories do this [i.e., contain an "#include "moc_.cpp" when the header name is .h] then their generated moc files would collide. In this case a diagnostic will be issued." For the life of me, I cannot find a way to generate that diagnostic. Instead, three different targets (two targets concerning the same implementation code and header in the same directory and a third target for a copy of that same implementation code and header in a different directory) generate at build time a file named moc_test_q_object.cpp in the same build directory at different times. This is a clear example of a three-way name collision, but CMake does not issue a diagnostic for any of these targets concerning that collision contrary to the above documentation. Could you please take a look at the three last executables configured for this test case (helloworld_automoc_same_include, helloworld_automoc_same_include1, and helloworld_automoc_same_include2) to see why that collision diagnostic is not being issued with cmake-3.7.0? Better yet, of course, would be to solve these remaining name collisions completely by using a modification of your idea above, i.e., for this special case where users implementation code contained #include "moc_.cpp" then moc should generate the file ${CMAKE_BINARY_DIR}/${TARGETNAME}_automoc.dir/${HEADERPATHCHECKSUM}/moc_${HEADERNAME}.cpp Note, the generated moc file has the name expected by the #include so I believe this idea would work so long as automoc automatically appended ${CMAKE_BINARY_DIR}/${TARGETNAME}_automoc.dir/${HEADERPATHCHECKSUM} to the target INCLUDE_DIRECTORIES property. 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 -------------- A non-text attachment was scrubbed... Name: test_automoc.tar.gz Type: application/x-gtar-compressed Size: 2882 bytes Desc: Simple project to test automoc for various header file locations and names URL: From seblist at xwmw.org Mon Nov 14 03:06:36 2016 From: seblist at xwmw.org (Sebastian Holtermann) Date: Mon, 14 Nov 2016 09:06:36 +0100 Subject: [cmake-developers] Current deficiencies of automoc In-Reply-To: References: <8ac54358-a98a-1751-325c-af7f79d16489@xwmw.org> Message-ID: <73dfbf9b-f480-08fc-9632-4f665437e7cb@xwmw.org> Am 13.11.2016 um 07:48 schrieb Alan W. Irwin: > On 2016-10-22 19:49+0200 Sebastian Holtermann wrote: > > [...] >> Actually I made an implementation in 3.6.0 that generated the moc files >> in the a build tree subdirectory correspoding to the header path. >> But that blew up on some projects because the generated paths got too >> long for some compi?ers. That implementation was theefore reverted. >> In 3.7 there is a new approatch that generates the moc files in >> ${CMAKE_BINARY_DIR}/ >> ${TARGETNAME}_automoc.dir/ >> ${HEADERNAME}_${HEADERPATHCHECKSUM}.cpp >> This ensures that the paths don't get too long and that there won't be >> any name collisions. > > Hi Sebastian: > > After a substantial break to finish off a different project, I have > now had a chance to return to the present topic using my attached > test_automoc project. (Also available in the cmake/test_automoc > subdirectory of the PLplot git master branch that can be accessed at > .) The > project builds 6 separate simple Qt5 applications that #include a > header that needs moc processing. The only differences between the > source code files for the various executables is the name and > directory location of that #include'd file and the various instructions > given to automoc (and in one case qt5_wrap_cpp) to process that file. > > With that test project, I now confirm (sorry about the noise to the > contrary before) that automoc does use the approach you mentioned > above for CMake-3.7.0 to reduce the name collisions that occur for > that same project for earlier versions of CMake. > > Concerning the collisions still expected for 3.7.0, the automoc > documentation (see > ) states the > following: > > "However, if multiple source files in different directories do this > [i.e., contain an "#include "moc_.cpp" when the header > name is .h] then their generated moc files would > collide. In this case a diagnostic will be issued." > > For the life of me, I cannot find a way to generate that diagnostic. > Instead, three different targets (two targets concerning the same > implementation code and header in the same directory and a third > target for a copy of that same implementation code and header in a > different directory) generate at build time a file named > moc_test_q_object.cpp in the same build directory at different times. > This is a clear example of a three-way name collision, but CMake does > not issue a diagnostic for any of these targets concerning that > collision contrary to the above documentation. > > Could you please take a look at the three last executables configured > for this test case (helloworld_automoc_same_include, > helloworld_automoc_same_include1, and > helloworld_automoc_same_include2) to see why that collision diagnostic > is not being issued with cmake-3.7.0? Better yet, of course, would be > to solve these remaining name collisions completely by using a > modification of your idea above, i.e., for this special case where > users implementation code contained > > #include "moc_.cpp" > > then moc should generate the file > > ${CMAKE_BINARY_DIR}/${TARGETNAME}_automoc.dir/${HEADERPATHCHECKSUM}/moc_${HEADERNAME}.cpp > > > Note, the generated moc file has the name expected by the #include so > I believe this idea would work so long as automoc automatically > appended > ${CMAKE_BINARY_DIR}/${TARGETNAME}_automoc.dir/${HEADERPATHCHECKSUM} to > the target INCLUDE_DIRECTORIES property. > Hi Alan, the automoc diagnostic checks for name collisions within a single target only, not across multiple targets - as in your example. The problem I see is that all moc files included by the #include "moc_.cpp" scheme get generated in ${CMAKE_BINARY_DIR}. It would be better to generate them in ${CMAKE_BINARY_DIR}/${TARGETNAME}_automoc.dir to avoid inter target name collisions. Your solution using the path checksum as well would be event better as it avoids name collisions even within a target. The problem there is though that it would require to add a .cpp file specific -I compiler statement for every .cpp file that includes a moc file. This is hard to do with the current automoc implementation. I would not want to do it. What probably could be done is to add ${CMAKE_BINARY_DIR}/${TARGETNAME}_automoc.dir to the INCLUDE_DIRECTORIES of the target and then generate all #included moc file there, accepting the risk of intra target name collisions. -Sebastian From irwin at beluga.phys.uvic.ca Mon Nov 14 06:41:06 2016 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Mon, 14 Nov 2016 03:41:06 -0800 (PST) Subject: [cmake-developers] Current deficiencies of automoc In-Reply-To: <73dfbf9b-f480-08fc-9632-4f665437e7cb@xwmw.org> References: <8ac54358-a98a-1751-325c-af7f79d16489@xwmw.org> <73dfbf9b-f480-08fc-9632-4f665437e7cb@xwmw.org> Message-ID: On 2016-11-14 09:06+0100 Sebastian Holtermann wrote: > What probably could be done is to add > ${CMAKE_BINARY_DIR}/${TARGETNAME}_automoc.dir > to the INCLUDE_DIRECTORIES of the target and then generate all > #included moc file there, accepting the risk of intra target name > collisions. Hi Sebastian: Your compromise idea above sounds good to me! 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 seblist at xwmw.org Mon Nov 14 07:25:18 2016 From: seblist at xwmw.org (Sebastian Holtermann) Date: Mon, 14 Nov 2016 13:25:18 +0100 Subject: [cmake-developers] Current deficiencies of automoc In-Reply-To: References: <8ac54358-a98a-1751-325c-af7f79d16489@xwmw.org> <73dfbf9b-f480-08fc-9632-4f665437e7cb@xwmw.org> Message-ID: Am 14.11.2016 um 12:41 schrieb Alan W. Irwin: > On 2016-11-14 09:06+0100 Sebastian Holtermann wrote: > >> What probably could be done is to add >> ${CMAKE_BINARY_DIR}/${TARGETNAME}_automoc.dir >> to the INCLUDE_DIRECTORIES of the target and then generate all >> #included moc file there, accepting the risk of intra target name >> collisions. > > Hi Sebastian: > > Your compromise idea above sounds good to me! > Btw. I liked your ${CMAKE_BINARY_DIR}/ ${TARGETNAME}_automoc.dir/ ${HEADERPATHCHECKSUM}/ moc_${HEADERNAME}.cpp approach. It could be used for the moc_.cpp files that are not manually #included and therefore can have any name. Over the current ${CMAKE_BINARY_DIR}/ ${TARGETNAME}_automoc.dir/ moc_${HEADERNAME}_${HEADERPATHCHECKSUM}.cpp scheme it has the advantages that 1) moc_.cpp files are grouped by their source directory 2) ${HEADERNAME} is kept intact and does not get shortened 3) fewer weird looking checksum names ;) 1) and 2) are generally helpful to find and debug moced files I think. There are a some other changes to the automoc system I would like to propose / work on. I'm currently busy with an other project though. -Sebastian From brad.king at kitware.com Mon Nov 14 10:13:09 2016 From: brad.king at kitware.com (Brad King) Date: Mon, 14 Nov 2016 10:13:09 -0500 Subject: [cmake-developers] [PATCH] Discussion needed: FindBISON: refine VERBOSE feature of BISON_TARGET In-Reply-To: <4addf8b8-e244-a251-e4f1-44ef20d0097f@kitware.com> References: <55880FFB.20303@kitware.com> <558ACCD4.60701@kitware.com> <784194f0-a710-2dc8-ce38-4491c92a482e@kitware.com> <20160715154425.GA18154@megas.kitware.com> <4addf8b8-e244-a251-e4f1-44ef20d0097f@kitware.com> Message-ID: On 07/18/2016 09:14 AM, Brad King wrote: > FindBISON: Change usage of [VERBOSE ] to [VERBOSE []] > https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ad2497aa BTW, this caused a regression reported here: * https://gitlab.kitware.com/cmake/cmake/issues/16426 Please take a look at the fix here: * https://gitlab.kitware.com/cmake/cmake/merge_requests/250 Thanks, -Brad From brad.king at kitware.com Mon Nov 14 14:41:38 2016 From: brad.king at kitware.com (Brad King) Date: Mon, 14 Nov 2016 14:41:38 -0500 Subject: [cmake-developers] Android variables In-Reply-To: References: <1a7b05c8-2073-43a6-a111-707e12a9f34a@yahoo.com> <66c8b5a5-358e-9c73-0841-dafea8167a69@yahoo.com> <0bf8b3c5-9372-c98a-45df-351bb591c3ba@kitware.com> <1faaf1a1-e46d-4f0f-45c9-1e1f3d3857a6@yahoo.com> Message-ID: <1d08d72f-7bbd-043c-62b0-6eea9075a231@kitware.com> On 11/11/2016 01:51 PM, Brad King wrote: > Okay, thanks. I'll investigate how to properly expose this information. Please see: https://gitlab.kitware.com/cmake/cmake/merge_requests/254 -Brad From Roberto.Regalino at autodesk.com Mon Nov 14 16:38:12 2016 From: Roberto.Regalino at autodesk.com (Roberto Regalino) Date: Mon, 14 Nov 2016 21:38:12 +0000 Subject: [cmake-developers] =?windows-1252?q?CMAKE_3=2E7_=28for_Android_ta?= =?windows-1252?q?rget=29_error=3A_crtbegin=5Fdynamic=2Eo=3Acrtbrand=2Ec?= =?windows-1252?q?=3Afunction_=5Fstart=3A_error=3A_undefined_reference_to_?= =?windows-1252?q?=27main=92?= Message-ID: <8654e6f70cde4384a1393564de2fe206@BLUPR79MB017.MGDADSK.autodesk.com> Hi, Not sure if this is the place to ask my question but here we go: I am trying to build C++ code targeting the Android platform. I already have the whole system setup to generate VisualStudio projects and it is using the Nsight Tegra plug-in. I?ve been asked to update the CMake files so we can still target Android but not using VisualStudio in hope to migrate to AndroidStudio. So far, I managed to create a new toolchain file containing the following: set(CMAKE_SYSTEM_NAME Android) set(CMAKE_ANDROID_NDK_TOOLCHAIN_VERSION clang) set(CMAKE_ANDROID_API 21) set(CMAKE_ANDROID_NDK $ENV{ANDROID_HOME}) set(CMAKE_ANDROID_SKIP_ANT_STEP 0) set(CMAKE_ANDROID_JAVA_SOURCE_DIR java) set(CMAKE_ANDROID_BUILD_SYSTEM GradleBuild) With these settings, I can successfully compile the whole project source files but when I get to the link pass, it fails with the error: C:/NVPACK/android-ndk-r10e/platforms/android-21/arch-arm/usr/lib/../lib\crtbegin_dynamic.o:crtbrand.c:function _start: error: undefined reference to 'main? I believe that I am missing the equivalent steps that are taken care by the ?Gradle Build? steps found in the VisualStudio project. My understanding is that these Gradle steps are responsible for embedding the AndroidManifest (that, I?ve been told, will define the ?main?) and generate the apk file from the so. Is this indeed what I am missing? Also, can anyone confirm if CMake 3.7 does provide the equivalent steps or if I need to define them myself? Thank you in advance Regalir -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Tue Nov 15 08:12:11 2016 From: brad.king at kitware.com (Brad King) Date: Tue, 15 Nov 2016 08:12:11 -0500 Subject: [cmake-developers] =?utf-8?q?CMAKE_3=2E7_=28for_Android_target=29?= =?utf-8?q?_error=3A_crtbegin=5Fdynamic=2Eo=3Acrtbrand=2Ec=3Afunction_=5Fs?= =?utf-8?q?tart=3A_error=3A_undefined_reference_to_=27main=E2=80=99?= In-Reply-To: <8654e6f70cde4384a1393564de2fe206@BLUPR79MB017.MGDADSK.autodesk.com> References: <8654e6f70cde4384a1393564de2fe206@BLUPR79MB017.MGDADSK.autodesk.com> Message-ID: <37c546b5-e51d-fa92-2236-ff58c3a7816b@kitware.com> On 11/14/2016 04:38 PM, Roberto Regalino wrote: > still target Android but not using VisualStudio What generator are you now using? > So far, I managed to create a new toolchain file containing the following: > > set(CMAKE_ANDROID_API 21) > set(CMAKE_ANDROID_SKIP_ANT_STEP 0) > set(CMAKE_ANDROID_JAVA_SOURCE_DIR java) > set(CMAKE_ANDROID_BUILD_SYSTEM GradleBuild) These are all settings for the Nsight Tegra Visual Studio Edition generation. See documentation here: * https://cmake.org/cmake/help/v3.7/manual/cmake-toolchains.7.html#cross-compiling-for-android for how to configure the Ninja or Makefile generators with a toolchain file. > crtbegin_dynamic.o:crtbrand.c:function _start: error: undefined reference to 'main? For a purely-native binary created via add_executable then one of the sources should have "main". For creating an apk then additional steps are needed IIUC, but I'm not very familiar with them. > My understanding is that these Gradle steps are responsible for embedding > the AndroidManifest (that, I?ve been told, will define the ?main?) and > generate the apk file from the so. > > can anyone confirm if CMake 3.7 does provide the equivalent steps or if > I need to define them myself? We don't have first-class support for those steps outside of Nsight Tegra. They need to be done with add_custom_target/add_custom_command. Can anyone more familiar with APK generation add more? -Brad From Roberto.Regalino at autodesk.com Tue Nov 15 09:07:56 2016 From: Roberto.Regalino at autodesk.com (Roberto Regalino) Date: Tue, 15 Nov 2016 14:07:56 +0000 Subject: [cmake-developers] =?windows-1252?q?CMAKE_3=2E7_=28for_Android_ta?= =?windows-1252?q?rget=29_error=3A_crtbegin=5Fdynamic=2Eo=3Acrtbrand=2Ec?= =?windows-1252?q?=3Afunction_=5Fstart=3A_error=3A_undefined_reference_to_?= =?windows-1252?q?=27main=92?= In-Reply-To: <37c546b5-e51d-fa92-2236-ff58c3a7816b@kitware.com> References: <8654e6f70cde4384a1393564de2fe206@BLUPR79MB017.MGDADSK.autodesk.com> <37c546b5-e51d-fa92-2236-ff58c3a7816b@kitware.com> Message-ID: <342cac414a564175bcd46a1a8961b7a2@BLUPR79MB017.MGDADSK.autodesk.com> Hi Thank you for the quick response. >> What generator are you now using? Right! I forgot to mention this. I am using the "NMake Makefiles JOM" >> We don't have first-class support for those steps outside of Nsight Tegra. >> They need to be done with add_custom_target/add_custom_command. This is what I thought! Regalir -----Original Message----- From: Brad King [mailto:brad.king at kitware.com] Sent: Tuesday, November 15, 2016 8:12 AM To: Roberto Regalino Cc: cmake-developers at cmake.org Subject: Re: [cmake-developers] CMAKE 3.7 (for Android target) error: crtbegin_dynamic.o:crtbrand.c:function _start: error: undefined reference to 'main? On 11/14/2016 04:38 PM, Roberto Regalino wrote: > still target Android but not using VisualStudio What generator are you now using? > So far, I managed to create a new toolchain file containing the following: > > set(CMAKE_ANDROID_API 21) > set(CMAKE_ANDROID_SKIP_ANT_STEP 0) > set(CMAKE_ANDROID_JAVA_SOURCE_DIR java) set(CMAKE_ANDROID_BUILD_SYSTEM > GradleBuild) These are all settings for the Nsight Tegra Visual Studio Edition generation. See documentation here: * https://cmake.org/cmake/help/v3.7/manual/cmake-toolchains.7.html#cross-compiling-for-android for how to configure the Ninja or Makefile generators with a toolchain file. > crtbegin_dynamic.o:crtbrand.c:function _start: error: undefined reference to 'main? For a purely-native binary created via add_executable then one of the sources should have "main". For creating an apk then additional steps are needed IIUC, but I'm not very familiar with them. > My understanding is that these Gradle steps are responsible for > embedding the AndroidManifest (that, I?ve been told, will define the > ?main?) and generate the apk file from the so. > > can anyone confirm if CMake 3.7 does provide the equivalent steps or > if I need to define them myself? We don't have first-class support for those steps outside of Nsight Tegra. They need to be done with add_custom_target/add_custom_command. Can anyone more familiar with APK generation add more? -Brad From yves.frederix+cmake at gmail.com Wed Nov 16 05:06:20 2016 From: yves.frederix+cmake at gmail.com (Yves Frederix) Date: Wed, 16 Nov 2016 11:06:20 +0100 Subject: [cmake-developers] Automatic project generation with Visual Studio generators In-Reply-To: <52ffcc2c-c08f-1684-e204-4b4818011ff3@kitware.com> References: <2b8ca07b-5e2c-f03b-26a7-04b9b4d588a3@kitware.com> <52ffcc2c-c08f-1684-e204-4b4818011ff3@kitware.com> Message-ID: Hi Brad, I finally got to creating a pull request for this, see https://gitlab.kitware.com/cmake/cmake/merge_requests/262. Regards, Yves On Fri, Sep 16, 2016 at 2:38 PM, Brad King wrote: > On 09/16/2016 03:37 AM, Yves Frederix wrote: >> This would work, but it would make all builds using 'cmake --build' >> more verbose as before actually starting the msbuild-build, this would >> always print an often large number of lines like: >> >> CMake does not need to re-run because .../CMakeFiles/generate.stamp >> is up-to-date. > [snip] >> Or alternatively I could add an option '--verbose|-V' to cmake that >> would control whether to print them? > > We don't need to invoke the `--check-stamp-list` command by executing > another process. The `cmake --build` process can just invoke the same > APIs internally, and with options to be quiet. After regeneration is > complete (or not done) then it can run the normal build command. > > -Brad > From konstantin at podsvirov.pro Wed Nov 16 22:57:26 2016 From: konstantin at podsvirov.pro (Konstantin Podsvirov) Date: Thu, 17 Nov 2016 06:57:26 +0300 Subject: [cmake-developers] QtSDK integration Message-ID: <723521479355046@web37m.yandex.ru> An HTML attachment was scrubbed... URL: From gjasny at googlemail.com Thu Nov 17 17:07:42 2016 From: gjasny at googlemail.com (Gregor Jasny) Date: Thu, 17 Nov 2016 23:07:42 +0100 Subject: [cmake-developers] cm(Generator)Target::IsFrameworkOnApple Message-ID: <246be28b-dac9-10e4-a68c-6fef9cafa293@googlemail.com> Hello, it looks like that during Generator Target refactoring the cm(Generator)Target::IsFrameworkOnApple and similar got duplicated. Is there a reason for this or could the GeneratorTarget simply query the Target? Do you have by any chance some high level design documentation about the most important involves classes like the various generators, target, makefile, etc? I sometimes wonder where to place a new function and would like to get some more background. Thanks, Gregor From steveire at gmail.com Thu Nov 17 19:26:10 2016 From: steveire at gmail.com (Stephen Kelly) Date: Fri, 18 Nov 2016 00:26:10 +0000 Subject: [cmake-developers] cm(Generator)Target::IsFrameworkOnApple References: <246be28b-dac9-10e4-a68c-6fef9cafa293@googlemail.com> Message-ID: Gregor Jasny via cmake-developers wrote: > Hello, > > it looks like that during Generator Target refactoring the > cm(Generator)Target::IsFrameworkOnApple and similar got duplicated. Is > there a reason for this or could the GeneratorTarget simply query the > Target? Hi Gregor, The intention of my refactoring effort was to make generate-time classes like cmGeneratorTarget not depend on configure-time classes like cmTarget and cmMakefile at all. The cmMakefile class at least is tightly integrated to the current cmake language. I've made some effort to remove some of the other non-language related responsibilities it has, but there is more to do. I've also put work into to making cmGeneratorTarget not depend on cmTarget, but there is more to do there too. Isolating the different classes would be a step along the way to introducing a new cmake language. It would also make better cross-compiling features possible such as multi-configuration builds (host+target etc). > Do you have by any chance some high level design documentation about the > most important involves classes like the various generators, target, > makefile, etc? I sometimes wonder where to place a new function and > would like to get some more background. I think such a thing would be out of date quite quickly, but the best guideline I can give is to try to separate the code which is dependent on cmMakefile+cmTarget from the code dependent on generators+cmGeneratorTarget. Do you have a more-specific query? Thanks, Steve. From craig.scott at crascit.com Sat Nov 19 06:06:16 2016 From: craig.scott at crascit.com (Craig Scott) Date: Sat, 19 Nov 2016 22:06:16 +1100 Subject: [cmake-developers] Docs for CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT Message-ID: There seems to be a number of references online to a variable named CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT which is recommended for checking if CMAKE_INSTALL_PREFIX has been overridden or not. This variable is not mentioned in CMake's documentation, but some of those online references claim it was recommended by CMake devs to use this variable. Is it formally supported? If so, can documentation be added for it so that users can have confidence that they are using a supported feature? Even just something very simple would be enough to meet that need. Some example references to this: http://public.kitware.com/pipermail/cmake/2010-December/041135.html http://stackoverflow.com/a/16076855/1938798 -- Craig Scott Melbourne, Australia https://crascit.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From irwin at beluga.phys.uvic.ca Sun Nov 20 02:24:28 2016 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Sat, 19 Nov 2016 23:24:28 -0800 (PST) Subject: [cmake-developers] Thanks for the nice way that CMP0054 was implemented Message-ID: Hi Nils: According to "git log" you were the author of the first commit that referred to CMP0054 so I wanted to publicly thank you and others that helped you with CMP0054 for the very nice way that is implemented in practice for developers of CMake-based build systems like me. Note the PLplot CMake minimum version and corresponding uniform policy is 3.0.2. We adopt that version to make it easier to build PLplot on virtually all modern Linux distributions including Debian stable (which currently only packages 3.0.2). I do have plans in 5 months or so (likely coinciding fairly closely with when a new Debian stable is released that will package at least CMake-3.7.0) to bump our minimum CMake version and uniform policy to at least 3.7.x. But for now we will be sticking with a policy that conforms to 3.0.2 because of this modern Linux packaging constraint limiting what versions of cmake are readily available to Linux users who do not want to have to build CMake in order to build PLplot. I now want to move to the issue where the design of CMP0054 saved the day for me. The PLplot build system had the following "innocuous" if statement in one of its heavily used functions: if(BINDING STREQUAL "c") That CMake logic has worked well for years in the obvious way (treating "c" as a simple string) because there was no CMake variable named c in our build system that would nameclash with that string. But apparently 4.7.0 does define such a variable and that nameclash with the "c" string (with CMP0054 OLD behaviour allowing that c variable to be dereferenced) caused a major issue for that version of CMake. But because of the nice way that CMP0054 is implemented, CMake immediately warned about this nameclash when running CMake-3.7.0, and I was able to temporarily workaround the issue by replacing the above if statement by if("X${BINDING}X" STREQUAL "XcX") (since there is evidentally no variable named XcX to nameclash with that string). Of course, once we are able to bump our minimum version to a modern version of CMake like 3.7.0 that allows us to use the much more logical NEW form of CMP0054 that eliminates the possibility of such nameclashes, and that vastly preferred policy will allow me to revert the above workaround necessary for CMP0054 OLD. In sum, I wanted to acknowledge the forward thinking of everybody that worked on CMP0054 since that nice implementation saved my ass today when one of our users who had good success with the PLplot build for 3.6.x reported major PLplot build-system trouble with CMake-3.7.0. 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 timmerov+cmake at gmail.com Sun Nov 20 19:19:25 2016 From: timmerov+cmake at gmail.com (tim cotter) Date: Sun, 20 Nov 2016 16:19:25 -0800 Subject: [cmake-developers] improved CodeBlocks group support Message-ID: i've patched my local cmake to automatically add a virtual folder group option for every file in a code blocks project. it's not proper support for cmake source groups. but it does what i want it to do. the patch is small. would the community be interested in such a thing? if so, how would i go about submitting it? -timmer -------------- next part -------------- An HTML attachment was scrubbed... URL: From tobias.hunger at gmail.com Mon Nov 21 10:21:14 2016 From: tobias.hunger at gmail.com (Tobias Hunger) Date: Mon, 21 Nov 2016 16:21:14 +0100 Subject: [cmake-developers] improved CodeBlocks group support In-Reply-To: References: Message-ID: Hi Tim, Am 21.11.2016 01:19 schrieb "tim cotter" : > > i've patched my local cmake to automatically add a virtual folder group option for every file in a code blocks project. > > it's not proper support for cmake source groups. > but it does what i want it to do. > > the patch is small. > > would the community be interested in such a thing? Have you tested this with the IDEs that user this extra generator? CodeBlocks and QtCreator are the ones I know to be using this. > if so, how would i go about submitting it? If you can create a merge request at gitlab.kitware.com, then that would be the best option. Not sure you can get an account there (that is able to create merge requests). Otherwise sending it here will probably work, too. Best Regards, Tobias -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel at pfeifer-mail.de Mon Nov 21 10:46:09 2016 From: daniel at pfeifer-mail.de (Daniel Pfeifer) Date: Mon, 21 Nov 2016 16:46:09 +0100 Subject: [cmake-developers] improved CodeBlocks group support In-Reply-To: References: Message-ID: On Mon, Nov 21, 2016 at 4:21 PM, Tobias Hunger wrote: > Hi Tim, > > Am 21.11.2016 01:19 schrieb "tim cotter" : > > > > i've patched my local cmake to automatically add a virtual folder group > option for every file in a code blocks project. > > > > it's not proper support for cmake source groups. > > but it does what i want it to do. > > > > the patch is small. > > > > would the community be interested in such a thing? > > Have you tested this with the IDEs that user this extra generator? > CodeBlocks and QtCreator are the ones I know to be using this. > > > if so, how would i go about submitting it? > > If you can create a merge request at gitlab.kitware.com, then that would > be the best option. Not sure you can get an account there (that is able to > create merge requests). > https://gitlab.kitware.com/cmake/cmake/blob/master/CONTRIBUTING.rst -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at boostpro.com Mon Nov 21 11:06:13 2016 From: dave at boostpro.com (Dave Abrahams) Date: Mon, 21 Nov 2016 08:06:13 -0800 Subject: [cmake-developers] How to use JOB_POOLS? Message-ID: Hi all, I'm finding that the documentation for JOB_POOLS is... sparse, to say the least. I understand the principle at work, but it's really unclear how JOB_POOL_LINK and JOB_POOL_COMPILE are supposed to work when set per-target. When set globally, it's clear that JOB_POOL_COMPILE is supposed to affect ?compilation? targets (which I presume means compilation of languages that CMake knows about?) while JOB_POOL_LINK is supposed to affect link targets (a little more constrained; I think CMake knows about most linkers) but what about custom targets? I have lots of those and their compilations can't be distributed with distcc. Can they be assigned to job pools? Can anyone explain this stuff? Thanks, Dave P.S. Someone should build up an example that illustrates how this all works. From brad.king at kitware.com Mon Nov 21 11:34:22 2016 From: brad.king at kitware.com (Brad King) Date: Mon, 21 Nov 2016 11:34:22 -0500 Subject: [cmake-developers] How to use JOB_POOLS? In-Reply-To: References: Message-ID: On 11/21/2016 11:06 AM, Dave Abrahams wrote: > the documentation for JOB_POOLS is sparse Yes, it is bare-bones reference documentation for someone that already knows how Ninja job pools work. A sufficiently motivated contributor could add more to the `Help/generator/Ninja.rst` document in a new "Job Pools" section. > I understand the principle at work, but it's really unclear > how JOB_POOL_LINK and JOB_POOL_COMPILE are supposed to work when set > per-target. They assign link rules and compile rules for that target to the named pool. Each pool can have a different size assigned in the global JOB_POOLS property. Different targets could be in different pools, though typically the global settings are sufficient. > I presume means compilation of languages that CMake knows about? Yes. It is for the compilation and linking commands that CMake generates. > what about custom targets? We currently have no interface to assign custom commands or custom targets to any pool, simply because no one implemented such support. It would have to be a new optional argument to the add_custom_command and add_custom_target commands. -Brad From brad.king at kitware.com Mon Nov 21 11:54:03 2016 From: brad.king at kitware.com (Brad King) Date: Mon, 21 Nov 2016 11:54:03 -0500 Subject: [cmake-developers] Docs for CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT In-Reply-To: References: Message-ID: On 11/19/2016 06:06 AM, Craig Scott wrote: > can documentation be added for it Yes, it was simply missing the docs: https://gitlab.kitware.com/cmake/cmake/merge_requests/271 Thanks, -Brad From dave at boostpro.com Mon Nov 21 17:00:11 2016 From: dave at boostpro.com (Dave Abrahams) Date: Mon, 21 Nov 2016 14:00:11 -0800 Subject: [cmake-developers] How to use JOB_POOLS? In-Reply-To: (Brad King's message of "Mon, 21 Nov 2016 11:34:22 -0500") References: Message-ID: on Mon Nov 21 2016, Brad King wrote: > On 11/21/2016 11:06 AM, Dave Abrahams wrote: >> the documentation for JOB_POOLS is sparse > > Yes, it is bare-bones reference documentation for someone that already > knows how Ninja job pools work. I know perfectly well how Ninja job pools work. The docs in CMake are inadequate for understanding how CMake interacts with them. > A sufficiently motivated contributor could add more to the > `Help/generator/Ninja.rst` document in a new "Job Pools" section. I do appreciate the hint, Brad, but I'm currently unable to make contributions to arbitrary open-source projects. >> I understand the principle at work, but it's really unclear >> how JOB_POOL_LINK and JOB_POOL_COMPILE are supposed to work when set >> per-target. > > They assign link rules and compile rules for that target to the > named pool. Each pool can have a different size assigned in the > global JOB_POOLS property. Different targets could be in different > pools, though typically the global settings are sufficient. Ah. >> I presume means compilation of languages that CMake knows about? > > Yes. It is for the compilation and linking commands that CMake > generates. > >> what about custom targets? > > We currently have no interface to assign custom commands or > custom targets to any pool, simply because no one implemented > such support. It would have to be a new optional argument to > the add_custom_command and add_custom_target commands. Wow, that's too bad. It gets kinda awkward when my Swift build, which uses distcc over 100 cpus for C++ compilation, tries to do 100 parallel swift compilations (not supported by distcc) on my poor local 4-core machine. I may have to resort to postprocessing the generated Ninja files if I can't modify CMake. -- -Dave 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-developers] 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-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 seblist at xwmw.org Fri Nov 25 17:37:34 2016 From: seblist at xwmw.org (Sebastian Holtermann) Date: Fri, 25 Nov 2016 23:37:34 +0100 Subject: [cmake-developers] QtAutogen suggestions Message-ID: <555ed48a-c934-8517-b56f-4f4b8685ddcc@xwmw.org> Hi. There are some issues with QtAutogen that still bother me and that I would like to change. 1) Most files get generated in ${CMAKE_CURRENT_BINARY_DIR}/${TARGETNAME}_automoc.dir Is the ".dir" suffix neccessary? I think is should be removed. 2) Moc files that are manually included by a #include "moc_.cpp" statement get generated in ${CMAKE_CURRENT_BINARY_DIR} This is not ideal because - ${CMAKE_CURRENT_BINARY_DIR} must be added to the INCLUDE_DIRECTORIES manually in CMakeLists.txt - Multiple targets may write divergent content concurrently to the same moc_.cpp file. A better solution would be to generate the moc_.cpp files in ${CMAKE_CURRENT_BINARY_DIR}/${TARGETNAME}_automoc/include. AUTOMOC then should automatically add that directory to the INCLUDE_DIRECTORIES of the origin target. The same issue is present for AUTOUIC btw. which generates header files in ${CMAKE_CURRENT_BINARY_DIR}. It could be adapted in the same way. 3) The mocs compilation file currently gets generated as ${CMAKE_CURRENT_BINARY_DIR}/${TARGETNAME}_automoc.cpp The file could be generated as ${CMAKE_CURRENT_BINARY_DIR}/${TARGETNAME}_automoc/compilation.cpp This way and along with the changes in 2) all files would be generated in ${CMAKE_CURRENT_BINARY_DIR}/${TARGETNAME}_automoc. This is nice and contained and allows perfect cleanup by adding the directory to ADDITIONAL_MAKE_CLEAN_FILES. The moc/uic cleanup is broken/incomplete in CMake 3.7 btw.. 4) AUTOMOC AUTOUIC and AUTORCC perform different independent tasks that in the current implementation get processed serially inside a single custom target named ${TARGETNAME}_automoc. I think each of the three could be handled in an own target. Then instead on one custom target there would be three custom targets: - ${TARGETNAME}_automoc - ${TARGETNAME}_autouic - ${TARGETNAME}_autorcc Also each target would generate all files in an own directory: - ${CMAKE_CURRENT_BINARY_DIR}/${TARGETNAME}_automoc - ${CMAKE_CURRENT_BINARY_DIR}/${TARGETNAME}_autouic - ${CMAKE_CURRENT_BINARY_DIR}/${TARGETNAME}_autorcc Once in place this would also be easier to maintain compared to now where all three target logics are mixed together in a single C++ class. Please share your opinion on the points. If there is no fundamental opposition I will simply go ahead and work on the patches. -Sebastian From stryku2393 at gmail.com Sat Nov 26 05:17:05 2016 From: stryku2393 at gmail.com (mateusz janek) Date: Sat, 26 Nov 2016 11:17:05 +0100 Subject: [cmake-developers] Questions about C++ version and third party libraries Message-ID: Hello CMake community, First of all, I want to say "Hello" to everyone, I am new to the CMake developers community. I have some questions about developing rules, before I'll start to write the code: -In which version of C++ is CMake written? -Am I right that it is forbidden to use third party libraries? Thanks, Stryku -------------- next part -------------- An HTML attachment was scrubbed... URL: From lode.leroy at gmail.com Mon Nov 28 08:41:08 2016 From: lode.leroy at gmail.com (Lode Leroy) Date: Mon, 28 Nov 2016 14:41:08 +0100 Subject: [cmake-developers] Fwd: cmVisualStudio10TargetGenerator should not generate a rule for an ImportLibrary for executables In-Reply-To: References: Message-ID: Please consider the following patch for inclusion in cmake. The problem is that when a project contains a FOO.DLL and a FOO.EXE, the cmake generator tries to build FOO.LIB for both. The FOO.EXE does not need a FOO.LIB. $ diff -urp CMake-3.7.0-orig/ CMake-3.7.0 Only in CMake-3.7.0: build diff -urp CMake-3.7.0-orig/Source/cmVisualStudio10TargetGenerator.cxx CMake-3.7.0/Source/cmVisualStudio10TargetGenerator.cxx --- CMake-3.7.0-orig/Source/cmVisualStudio10TargetGenerator.cxx 2016-11-11 15:24:18.000000000 +0100 +++ CMake-3.7.0/Source/cmVisualStudio10TargetGenerator.cxx 2016-11-28 14:28:26.344898900 +0100 @@ -2310,7 +2310,9 @@ bool cmVisualStudio10TargetGenerator::Co imLib += "/"; imLib += targetNameImport; - linkOptions.AddFlag("ImportLibrary", imLib.c_str()); + if (this->GeneratorTarget->GetType() != cmState::EXECUTABLE) { + linkOptions.AddFlag("ImportLibrary", imLib.c_str()); + } linkOptions.AddFlag("ProgramDataBaseFile", pdb.c_str()); // A Windows Runtime component uses internal .NET metadata, From konstantin at podsvirov.pro Mon Nov 28 08:49:38 2016 From: konstantin at podsvirov.pro (Konstantin Podsvirov) Date: Mon, 28 Nov 2016 16:49:38 +0300 Subject: [cmake-developers] QtSDK integration In-Reply-To: <723521479355046@web37m.yandex.ru> References: <723521479355046@web37m.yandex.ru> Message-ID: <2257991480340978@web19h.yandex.ru> An HTML attachment was scrubbed... URL: From daniel at pfeifer-mail.de Mon Nov 28 09:08:46 2016 From: daniel at pfeifer-mail.de (Daniel Pfeifer) Date: Mon, 28 Nov 2016 15:08:46 +0100 Subject: [cmake-developers] Questions about C++ version and third party libraries In-Reply-To: References: Message-ID: On Sat, Nov 26, 2016 at 11:17 AM, mateusz janek wrote: > Hello CMake community, > > First of all, I want to say "Hello" to everyone, I am new to the CMake > developers community. > Hello and welcome! > I have some questions about developing rules, before I'll start to write > the code: > -In which version of C++ is CMake written? > CMake can still be built with Visual Studio 2008. It is mostly written in C++98 but built with C++14 where possible. We use some abstractions like CM_NULLPTR or CM_OVERRIDE. The parts for the language server are written in C++14. -Am I right that it is forbidden to use third party libraries? > CMake uses several third party libraries. Have a look at the Utilities directory. -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel at pfeifer-mail.de Mon Nov 28 09:16:33 2016 From: daniel at pfeifer-mail.de (Daniel Pfeifer) Date: Mon, 28 Nov 2016 15:16:33 +0100 Subject: [cmake-developers] Fwd: cmVisualStudio10TargetGenerator should not generate a rule for an ImportLibrary for executables In-Reply-To: References: Message-ID: On Mon, Nov 28, 2016 at 2:41 PM, Lode Leroy wrote: > Please consider the following patch for inclusion in cmake. > > The problem is that when a project contains a FOO.DLL and a FOO.EXE, > the cmake generator tries to build FOO.LIB for both. > The FOO.EXE does not need a FOO.LIB. > > $ diff -urp CMake-3.7.0-orig/ CMake-3.7.0 > Only in CMake-3.7.0: build > diff -urp CMake-3.7.0-orig/Source/cmVisualStudio10TargetGenerator.cxx > CMake-3.7.0/Source/cmVisualStudio10TargetGenerator.cxx > --- CMake-3.7.0-orig/Source/cmVisualStudio10TargetGenerator.cxx > 2016-11-11 15:24:18.000000000 +0100 > +++ CMake-3.7.0/Source/cmVisualStudio10TargetGenerator.cxx > 2016-11-28 14:28:26.344898900 +0100 > @@ -2310,7 +2310,9 @@ bool cmVisualStudio10TargetGenerator::Co > imLib += "/"; > imLib += targetNameImport; > > - linkOptions.AddFlag("ImportLibrary", imLib.c_str()); > + if (this->GeneratorTarget->GetType() != cmState::EXECUTABLE) { > + linkOptions.AddFlag("ImportLibrary", imLib.c_str()); > + } > linkOptions.AddFlag("ProgramDataBaseFile", pdb.c_str()); > > // A Windows Runtime component uses internal .NET metadata, > -- > > I am no windows expert, but I think the import library is required when you want to link against the executable. Please see https://cmake.org/cmake/help/v3.7/prop_tgt/ENABLE_EXPORTS.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Mon Nov 28 09:58:00 2016 From: brad.king at kitware.com (Brad King) Date: Mon, 28 Nov 2016 09:58:00 -0500 Subject: [cmake-developers] Fwd: cmVisualStudio10TargetGenerator should not generate a rule for an ImportLibrary for executables In-Reply-To: References: Message-ID: On 11/28/2016 09:16 AM, Daniel Pfeifer wrote: > On Mon, Nov 28, 2016 at 2:41 PM, Lode Leroy wrote: >> The problem is that when a project contains a FOO.DLL and a FOO.EXE, >> the cmake generator tries to build FOO.LIB for both. >> The FOO.EXE does not need a FOO.LIB. > Please see https://cmake.org/cmake/help/v3.7/prop_tgt/ENABLE_EXPORTS.html Correct. The `ImportLibrary` setting in a `.vcxproj` file only tells the tools where to put the `.lib` file *if* there are exports. No file will be generated unless the project code is using `dllexport` or other means to export a symbol from the executable. To prevent one from showing up, check the project code to make sure it doesn't try to export something. -Brad From brad.king at kitware.com Mon Nov 28 09:57:55 2016 From: brad.king at kitware.com (Brad King) Date: Mon, 28 Nov 2016 09:57:55 -0500 Subject: [cmake-developers] QtAutogen suggestions In-Reply-To: <555ed48a-c934-8517-b56f-4f4b8685ddcc@xwmw.org> References: <555ed48a-c934-8517-b56f-4f4b8685ddcc@xwmw.org> Message-ID: On 11/25/2016 05:37 PM, Sebastian Holtermann wrote: > There are some issues with QtAutogen that still bother me and > that I would like to change. Great! We currently have no dedicated maintainer for it and I have little understanding of the tools and use cases associated with it myself. It will be useful to have your help. > 1) Most files get generated in > ${CMAKE_CURRENT_BINARY_DIR}/${TARGETNAME}_automoc.dir > > Is the ".dir" suffix neccessary? I think is should be removed. That suffix is the convention used for all intermediate files (e.g. object files) associated with a particular target of any kind. The _automoc targets are simply following that convention, but there is no strong reason this has to be the case for the generated sources. > 2) Moc files that are manually included by a > #include "moc_.cpp" > statement get generated in ${CMAKE_CURRENT_BINARY_DIR} > > A better solution would be to generate the moc_.cpp files in > ${CMAKE_CURRENT_BINARY_DIR}/${TARGETNAME}_automoc/include. > AUTOMOC then should automatically add that directory to the > INCLUDE_DIRECTORIES of the origin target. Yes, I think that has been discussed before but no one ever implemented it. > 3) The mocs compilation file currently gets generated as > ${CMAKE_CURRENT_BINARY_DIR}/${TARGETNAME}_automoc.cpp > > The file could be generated as > ${CMAKE_CURRENT_BINARY_DIR}/${TARGETNAME}_automoc/compilation.cpp Okay. > 4) AUTOMOC AUTOUIC and AUTORCC perform different independent tasks that > in the current implementation get processed serially inside a single > custom target named ${TARGETNAME}_automoc. > > I think each of the three could be handled in an own target. In VS IDE and Xcode each target becomes another user-visible entity so we try to keep generated targets to a minimum. IIRC in some cases we even try to use a PRE_BUILD step in the VS targets to avoid an extra target altogether. The breakdown could be made generator-specific to improve behavior on Ninja and Makefile generators. In the case that a common target is needed it could be renamed to `_autogen` instead. Thanks, -Brad 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-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 seblist at xwmw.org Mon Nov 28 10:25:51 2016 From: seblist at xwmw.org (Sebastian Holtermann) Date: Mon, 28 Nov 2016 16:25:51 +0100 Subject: [cmake-developers] QtAutogen suggestions In-Reply-To: References: <555ed48a-c934-8517-b56f-4f4b8685ddcc@xwmw.org> Message-ID: Am 28.11.2016 um 15:57 schrieb Brad King: > On 11/25/2016 05:37 PM, Sebastian Holtermann wrote: >> There are some issues with QtAutogen that still bother me and >> that I would like to change. > > Great! We currently have no dedicated maintainer for it and I have > little understanding of the tools and use cases associated with it > myself. It will be useful to have your help. Okay. >> 1) Most files get generated in >> ${CMAKE_CURRENT_BINARY_DIR}/${TARGETNAME}_automoc.dir >> >> Is the ".dir" suffix neccessary? I think is should be removed. > > That suffix is the convention used for all intermediate files > (e.g. object files) associated with a particular target of any kind. > The _automoc targets are simply following that convention, but there > is no strong reason this has to be the case for the generated sources. Okay, I'm going to remove it then in this place. It is easier to read IMO. >> 2) Moc files that are manually included by a >> #include "moc_.cpp" >> statement get generated in ${CMAKE_CURRENT_BINARY_DIR} >> >> A better solution would be to generate the moc_.cpp files in >> ${CMAKE_CURRENT_BINARY_DIR}/${TARGETNAME}_automoc/include. >> AUTOMOC then should automatically add that directory to the >> INCLUDE_DIRECTORIES of the origin target. > > Yes, I think that has been discussed before but no one ever implemented it. > >> 3) The mocs compilation file currently gets generated as >> ${CMAKE_CURRENT_BINARY_DIR}/${TARGETNAME}_automoc.cpp >> >> The file could be generated as >> ${CMAKE_CURRENT_BINARY_DIR}/${TARGETNAME}_automoc/compilation.cpp > > Okay. > >> 4) AUTOMOC AUTOUIC and AUTORCC perform different independent tasks that >> in the current implementation get processed serially inside a single >> custom target named ${TARGETNAME}_automoc. >> >> I think each of the three could be handled in an own target. > > In VS IDE and Xcode each target becomes another user-visible entity so > we try to keep generated targets to a minimum. IIRC in some cases we > even try to use a PRE_BUILD step in the VS targets to avoid an extra > target altogether. The breakdown could be made generator-specific > to improve behavior on Ninja and Makefile generators. In the case that > a common target is needed it could be renamed to `_autogen` instead. For VS tries to use PRE_BUILD when possible for all other generators a custom target is used. I took that from the source but I'm not familiar with VS and can't test any changes. It safer to leave this the way is is for now. I'm going ahead then. -Sebastian From brad.king at kitware.com Mon Nov 28 11:00:11 2016 From: brad.king at kitware.com (Brad King) Date: Mon, 28 Nov 2016 11:00:11 -0500 Subject: [cmake-developers] QtAutogen suggestions In-Reply-To: References: <555ed48a-c934-8517-b56f-4f4b8685ddcc@xwmw.org> Message-ID: On 11/28/2016 10:25 AM, Sebastian Holtermann wrote: > I'm going ahead then. Thanks. BTW, please sign up for a gitlab.kitware.com account (optionally via GitHub OAuth) so that we can include you in discussion of related issues. For example: * https://gitlab.kitware.com/cmake/cmake/issues/16460 Thanks, -Brad From seblist at xwmw.org Mon Nov 28 11:05:15 2016 From: seblist at xwmw.org (Sebastian Holtermann) Date: Mon, 28 Nov 2016 17:05:15 +0100 Subject: [cmake-developers] QtAutogen suggestions In-Reply-To: References: <555ed48a-c934-8517-b56f-4f4b8685ddcc@xwmw.org> Message-ID: <93bbb0d2-7bdb-eae9-18bd-e2fd7f2df7d8@xwmw.org> Am 28.11.2016 um 17:00 schrieb Brad King: > On 11/28/2016 10:25 AM, Sebastian Holtermann wrote: >> I'm going ahead then. > > Thanks. BTW, please sign up for a gitlab.kitware.com account > (optionally via GitHub OAuth) so that we can include you in > discussion of related issues. For example: https://gitlab.kitware.com/sebholt -Sebastian From brad.king at kitware.com Mon Nov 28 14:14:35 2016 From: brad.king at kitware.com (Brad King) Date: Mon, 28 Nov 2016 14:14:35 -0500 Subject: [cmake-developers] QtSDK integration In-Reply-To: <2257991480340978@web19h.yandex.ru> References: <723521479355046@web37m.yandex.ru> <2257991480340978@web19h.yandex.ru> Message-ID: <9e2d0b7f-fcf1-f030-af13-dd7242f4ad13@kitware.com> On 11/28/2016 08:49 AM, Konstantin Podsvirov wrote: > Anybody known where Brad King? > > Or anybody can help me to review and merge !280, !281 and !282 MRs > into 'next' for testing? I was on vacation for the US Thanksgiving holiday. I'll get to these when I can. Thanks, -Brad From Harry at codexdigital.com Mon Nov 28 14:27:38 2016 From: Harry at codexdigital.com (Harry Mallon) Date: Mon, 28 Nov 2016 19:27:38 +0000 Subject: [cmake-developers] GitLab speed Message-ID: Hello all, While I appreciate having an integrated workflow and well defined contributing rules is useful for CMake I am finding it hard to get used to GitLab. The main reason is speed. Creating merge requests, moving around the interface and even pushing to repos seems to be much slower than the equivalent thing on github. I am not sure whether this report is constructive at all so feel free to dismiss my moaning. Yours, Harry Harry Mallon CODEX | Software Engineer 60 Poland Street | London | England | W1F 7NT E harry at codexdigital.com | T +44 203 7000 989 From brad.king at kitware.com Mon Nov 28 15:01:17 2016 From: brad.king at kitware.com (Brad King) Date: Mon, 28 Nov 2016 15:01:17 -0500 Subject: [cmake-developers] GitLab speed In-Reply-To: References: Message-ID: On 11/28/2016 02:27 PM, Harry Mallon wrote: > moving around the interface and even pushing to repos seems to be > much slower than the equivalent thing on github. Has it only been today or the last few days that you've noticed this? It does feel slower today than usual. I'll check with our admins. > I am not sure whether this report is constructive It is legitimate feedback presented in a civil tone. Thanks, -Brad From konstantin at podsvirov.pro Mon Nov 28 16:34:59 2016 From: konstantin at podsvirov.pro (Konstantin Podsvirov) Date: Tue, 29 Nov 2016 00:34:59 +0300 Subject: [cmake-developers] QtSDK integration In-Reply-To: <9e2d0b7f-fcf1-f030-af13-dd7242f4ad13@kitware.com> References: <723521479355046@web37m.yandex.ru> <2257991480340978@web19h.yandex.ru> <9e2d0b7f-fcf1-f030-af13-dd7242f4ad13@kitware.com> Message-ID: <547511480368899@web37m.yandex.ru> An HTML attachment was scrubbed... URL: From Harry at codexdigital.com Tue Nov 29 05:01:49 2016 From: Harry at codexdigital.com (Harry Mallon) Date: Tue, 29 Nov 2016 10:01:49 +0000 Subject: [cmake-developers] GitLab speed In-Reply-To: References: Message-ID: <5D236720-27FC-4EA7-A5E0-0DE737EA5265@codex.london> Hi Brad, Harry Mallon CODEX | Software Engineer 60 Poland Street | London | England | W1F 7NT E harry at codexdigital.com | T +44 203 7000 989 > On 28 Nov 2016, at 20:01, Brad King wrote: > > On 11/28/2016 02:27 PM, Harry Mallon wrote: >> moving around the interface and even pushing to repos seems to be >> much slower than the equivalent thing on github. > > Has it only been today or the last few days that you've noticed this? > It does feel slower today than usual. I'll check with our admins. I am not sure of the answer to this. I have only just moved over to prepare a tiny merge request. > >> I am not sure whether this report is constructive > > It is legitimate feedback presented in a civil tone. > > Thanks, > -Brad > Harry From michael.stuermer at schaeffler.com Tue Nov 29 06:13:35 2016 From: michael.stuermer at schaeffler.com (Stuermer, Michael SP/HZA-ZSEP) Date: Tue, 29 Nov 2016 11:13:35 +0000 Subject: [cmake-developers] GitLab speed In-Reply-To: <5D236720-27FC-4EA7-A5E0-0DE737EA5265@codex.london> References: <5D236720-27FC-4EA7-A5E0-0DE737EA5265@codex.london> Message-ID: >From my side access to the web interface as well as repo handling is also slower than github. I personally consider this more to be a luxury problem than a real issue. Would be great if were faster but it works well for me. On the other hand I like the whole workflow, that is great! I suppose the whole repo&build&test infrastructure is hosted at kitware and the bandwidth to the internet is just limited at some point. > -----Original Message----- > From: cmake-developers [mailto:cmake-developers-bounces at cmake.org] > On Behalf Of Harry Mallon > Sent: Tuesday, November 29, 2016 11:02 AM > To: cmake-developers at cmake.org > Cc: Harry Mallon > Subject: Re: [cmake-developers] GitLab speed > > Hi Brad, > > > Harry Mallon > CODEX | Software Engineer > 60 Poland Street | London | England | W1F 7NT E harry at codexdigital.com | T > +44 203 7000 989 > > On 28 Nov 2016, at 20:01, Brad King wrote: > > > > On 11/28/2016 02:27 PM, Harry Mallon wrote: > >> moving around the interface and even pushing to repos seems to be > >> much slower than the equivalent thing on github. > > > > Has it only been today or the last few days that you've noticed this? > > It does feel slower today than usual. I'll check with our admins. > > I am not sure of the answer to this. I have only just moved over to prepare a > tiny merge request. > > > > >> I am not sure whether this report is constructive > > > > It is legitimate feedback presented in a civil tone. > > > > Thanks, > > -Brad > > > > Harry > > -- > > 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 tobias.hunger at gmail.com Wed Nov 30 12:06:47 2016 From: tobias.hunger at gmail.com (Tobias Hunger) Date: Wed, 30 Nov 2016 18:06:47 +0100 Subject: [cmake-developers] How to use cmake::SetCacheArgs(...)? Message-ID: Hello CMake developers, I am trying to pass a number of arguments to cmake server-mode's configure command. The exact call is: [== "CMake Server" ==[ { "cacheArguments": [ "-DCMAKE_BUILD_TYPE:STRING=Debug", "-DCMAKE_CXX_COMPILER:STRING=/usr/lib/ccache/bin/g++", "-DCMAKE_C_COMPILER:STRING=/usr/lib/ccache/bin/gcc", "-DCMAKE_PREFIX_PATH:STRING=/usr", "-DQT_QMAKE_EXECUTABLE:STRING=/usr/bin/qmake" ], "cookie": 2, "type": "configure" } ]== "CMake Server" ==] These are then fed into cmake::SetCacheArgs(...) by server-mode. That call succeeds and I do see my values in the Cache once that is done (via cmCacheManager::PrintCache(...)). I then proceed to call cmake::Configure(...). That says something about having to start over with a clean cache since the compiler changed (which is correct). After cmake::Configure(...) returns values some of the values are gone again. E.g. CMAKE_BUILD_TYPE changed back from "Debug" to "". Is this expected behavior? When I resend the configure command to the cmake server all values stick. Is that what I need to do? How do I know whether or not I need to rerun configure again? Is there any telltale sign or at any machine-readable notification that I need to send my data again? Or is the procedure to just rerun configure with all arguments till the cache no longer changes? Best Regards, Tobias From ayb.serti at gmail.com Wed Nov 30 12:29:42 2016 From: ayb.serti at gmail.com (Serti Ayoub) Date: Wed, 30 Nov 2016 17:29:42 +0000 Subject: [cmake-developers] VS2015 /Zc:inline Message-ID: Hello, I'm using CMake 3.6 to generate VS2015 solution/projects. I found that cmake automatically add /Zc:inline for all projects configuration which make some of my symbols non-visible in release mode. https://msdn.microsoft.com/en-us/library/dn642448(v=vs.120).aspx Is there any policy for that? or A way to deactive use of /Zc:inline Thank you in advance. -Ayb -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Wed Nov 30 13:10:04 2016 From: brad.king at kitware.com (Brad King) Date: Wed, 30 Nov 2016 13:10:04 -0500 Subject: [cmake-developers] How to use cmake::SetCacheArgs(...)? In-Reply-To: References: Message-ID: <39d975f0-2475-bd8c-d476-1e3b3087d58b@kitware.com> On 11/30/2016 12:06 PM, Tobias Hunger wrote: > start over with a clean cache since the compiler changed (which is correct). > > After cmake::Configure(...) returns values some of the values are gone > again. E.g. CMAKE_BUILD_TYPE changed back from "Debug" to "". > > Is this expected behavior? Yes, though not really ever intended. The auto-rerun-on-compiler-change is a horrible hack that was done to make changing the compiler through ccmake possible on initial configuration. In general one should not try to change the compiler of an existing build tree, especially not from a scripted environment. If you want to ensure a fresh one-step configuration then always remove CMakeCache.txt and CMakeFiles/ before configuring. -Brad From brad.king at kitware.com Wed Nov 30 13:12:38 2016 From: brad.king at kitware.com (Brad King) Date: Wed, 30 Nov 2016 13:12:38 -0500 Subject: [cmake-developers] VS2015 /Zc:inline In-Reply-To: References: Message-ID: <3f62fcd8-2111-8762-67b6-154fac75806c@kitware.com> On 11/30/2016 12:29 PM, Serti Ayoub wrote: > I'm using CMake 3.6 to generate VS2015 solution/projects. > I found that cmake automatically add /Zc:inline for all projects > configuration which make some of my symbols non-visible in release mode. I'm not aware of any code in CMake that does that. There is no mention of that flag or of RemoveUnreferencedCodeData in the 3.6 source code. Please try a simple test project. -Brad From ayb.serti at gmail.com Wed Nov 30 13:37:47 2016 From: ayb.serti at gmail.com (Serti Ayoub) Date: Wed, 30 Nov 2016 18:37:47 +0000 Subject: [cmake-developers] VS2015 /Zc:inline In-Reply-To: <3f62fcd8-2111-8762-67b6-154fac75806c@kitware.com> References: <3f62fcd8-2111-8762-67b6-154fac75806c@kitware.com> Message-ID: Hello, Here: https://github.com/Kitware/CMake/blob/1b592b6458ce033b04ba2aa0ee4cf5ace0fd042c/Source/cmVS141CLFlagTable.h#L174 I think it need also an entry : { "RemoveUnreferencedCodeData", "Zc:inline-", "", "false", 0 } What do you think ? -Ayb 2016-11-30 18:12 GMT+00:00 Brad King : > On 11/30/2016 12:29 PM, Serti Ayoub wrote: > > I'm using CMake 3.6 to generate VS2015 solution/projects. > > I found that cmake automatically add /Zc:inline for all projects > > configuration which make some of my symbols non-visible in release mode. > > I'm not aware of any code in CMake that does that. There is no mention > of that flag or of RemoveUnreferencedCodeData in the 3.6 source code. > > Please try a simple test project. > > -Brad > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ayb.serti at gmail.com Wed Nov 30 14:13:28 2016 From: ayb.serti at gmail.com (Serti Ayoub) Date: Wed, 30 Nov 2016 19:13:28 +0000 Subject: [cmake-developers] VS2015 /Zc:inline In-Reply-To: References: <3f62fcd8-2111-8762-67b6-154fac75806c@kitware.com> Message-ID: Sorry, I think it's an error on VS2015 documentation. They pretend that, I quote "By default, this option is off (*/Zc:inline-*)." However the default value is */Zc:inline* https://msdn.microsoft.com/en-us/library/dn642448.aspx Is the any way to remove this from CFlags, It seems that > set_target_properties(${ProjectTarget} PROPERTIES COMPILE_FLAGS > "/Zc:inline-" ) > Doesn't work 2016-11-30 18:37 GMT+00:00 Serti Ayoub : > Hello, > Here: https://github.com/Kitware/CMake/blob/1b592b6458ce033b04ba2aa0ee4cf5 > ace0fd042c/Source/cmVS141CLFlagTable.h#L174 > I think it need also an entry : { "RemoveUnreferencedCodeData", " > Zc:inline-", "", "false", 0 } > What do you think ? > > -Ayb > > 2016-11-30 18:12 GMT+00:00 Brad King : > >> On 11/30/2016 12:29 PM, Serti Ayoub wrote: >> > I'm using CMake 3.6 to generate VS2015 solution/projects. >> > I found that cmake automatically add /Zc:inline for all projects >> > configuration which make some of my symbols non-visible in release mode. >> >> I'm not aware of any code in CMake that does that. There is no mention >> of that flag or of RemoveUnreferencedCodeData in the 3.6 source code. >> >> Please try a simple test project. >> >> -Brad >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Wed Nov 30 14:14:45 2016 From: brad.king at kitware.com (Brad King) Date: Wed, 30 Nov 2016 14:14:45 -0500 Subject: [cmake-developers] VS2015 /Zc:inline In-Reply-To: References: <3f62fcd8-2111-8762-67b6-154fac75806c@kitware.com> Message-ID: On 11/30/2016 01:37 PM, Serti Ayoub wrote: > Here: https://github.com/Kitware/CMake/blob/1b592b6458ce033b04ba2aa0ee4cf5ace0fd042c/Source/cmVS141CLFlagTable.h#L174 > I think it need also an entry : { "RemoveUnreferencedCodeData", "Zc:inline-", "", "false", 0} Yes, thanks: * https://gitlab.kitware.com/cmake/cmake/merge_requests/298 Note that that code does not exist in CMake 3.6, and that flag table is used only for the v141 toolset that comes with VS 2017 RC. According to the documentation you linked for the -Zcinline option the default is OFF if it is not specified, so regardless of the above it should still not appear in a CMake-generated project by default. -Brad From brad.king at kitware.com Wed Nov 30 14:17:44 2016 From: brad.king at kitware.com (Brad King) Date: Wed, 30 Nov 2016 14:17:44 -0500 Subject: [cmake-developers] VS2015 /Zc:inline In-Reply-To: References: <3f62fcd8-2111-8762-67b6-154fac75806c@kitware.com> Message-ID: <0c233590-a79b-a4b8-8642-69ad08185e0e@kitware.com> On 11/30/2016 02:13 PM, Serti Ayoub wrote: > Sorry, I think it's an error on VS2015 documentation. Okay. My previous response crossed with this one. > Is the any way to remove this from CFlags, It seems that > > set_target_properties(${ProjectTarget} PROPERTIES COMPILE_FLAGS "/Zc:inline-" ) We need to add the flag table entry for the v140 toolset to map that flag. -Brad From ayb.serti at gmail.com Wed Nov 30 14:24:13 2016 From: ayb.serti at gmail.com (Serti Ayoub) Date: Wed, 30 Nov 2016 19:24:13 +0000 Subject: [cmake-developers] VS2015 /Zc:inline In-Reply-To: <0c233590-a79b-a4b8-8642-69ad08185e0e@kitware.com> References: <3f62fcd8-2111-8762-67b6-154fac75806c@kitware.com> <0c233590-a79b-a4b8-8642-69ad08185e0e@kitware.com> Message-ID: Ok, Thank you. I will check CMake 3.7.2 when released. -Ayb 2016-11-30 19:17 GMT+00:00 Brad King : > On 11/30/2016 02:13 PM, Serti Ayoub wrote: > > Sorry, I think it's an error on VS2015 documentation. > > Okay. My previous response crossed with this one. > > > Is the any way to remove this from CFlags, It seems that > > > > set_target_properties(${ProjectTarget} PROPERTIES COMPILE_FLAGS > "/Zc:inline-" ) > > We need to add the flag table entry for the v140 toolset to > map that flag. > > -Brad > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Wed Nov 30 14:35:15 2016 From: brad.king at kitware.com (Brad King) Date: Wed, 30 Nov 2016 14:35:15 -0500 Subject: [cmake-developers] VS2015 /Zc:inline In-Reply-To: References: <3f62fcd8-2111-8762-67b6-154fac75806c@kitware.com> <0c233590-a79b-a4b8-8642-69ad08185e0e@kitware.com> Message-ID: <49e0daad-edd8-36f4-f9a6-247c4e876f4f@kitware.com> On 11/30/2016 02:24 PM, Serti Ayoub wrote: > Ok, Thank you. I will check CMake 3.7.2 when released. I updated the MR to include the changes for the v140 toolset as well. You should be able to try the next nightly binary that appears here: * https://cmake.org/files/dev/?C=M;O=D -Brad From brad.king at kitware.com Wed Nov 30 14:36:20 2016 From: brad.king at kitware.com (Brad King) Date: Wed, 30 Nov 2016 14:36:20 -0500 Subject: [cmake-developers] VS2015 /Zc:inline In-Reply-To: References: <3f62fcd8-2111-8762-67b6-154fac75806c@kitware.com> Message-ID: On 11/30/2016 02:13 PM, Serti Ayoub wrote: > Sorry, I think it's an error on VS2015 documentation. They pretend that, > I quote "By default, this option is off (*/Zc:inline-*)." However the > default value is */Zc:inline* Actually that documentation is for the MSVC compiler itself (`cl`), and it is accurate for that. It is VS or MSBuild that decides to add this flag by default. -Brad From robert.maynard at kitware.com Wed Nov 30 14:46:15 2016 From: robert.maynard at kitware.com (Robert Maynard) Date: Wed, 30 Nov 2016 14:46:15 -0500 Subject: [cmake-developers] [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