Re: [cmake-developers] Using CMake as a library from Python
Charles, I'd like to comment on a minor issue: CMakeLists.txt files don't specify user-specific data like source and build dirs (for a reason) yet your POC listfile contains this line: cmake.init("Ninja", "/media/dev/src/cmaketest", "/media/dev/build/cmaketest") which sets the source and build directories. Is this some temporary solution for the POC only? Tamas On Mon, Jan 4, 2016 at 8:41 AM, Charles Huetwrote: > Hi, > > Because of the above, I worry that you are basing your work on an old >> version of CMake. As of April 2015 cmState is used as the interface to the >> cache. > > > Yeah, that is sadly right. I wanted to rebase on master before publishing, > thinking it should not be too hard, and I have lots to re-do, mostly > understand how things are done now. > > I did something similar some years ago with QML instead of python, so it >> sounds interesting to me. > > > I'm trying to be as declarative as possible, because really like how > readable simple QML programs are, and I think it would be perfect for a > buildsystem. > > My guess is that you are using python to instantiate a cmAddLibraryCommand >> and then executing it. > > > Actually, I'm directly using the cmMakefile, because I did not want to > wrap all the commands, and it seemed backwards to me to wrap them. > > Even much of cmMakefile shouldn't be used by a new language. Instead >> certain >> parts of cmMakefile should be extracted as other classes >> (cmVariableExpander >> which should have the ExpandVariablesInString and ConfigureString stuff, >> cmMessenger for the IssueMessage stuff, some other class for the >> CompileFeature stuff etc). Then cmMakefile would be just about executing >> and >> scoping the CMake language. A new language would not need that, but would >> use the refactored extracted classes. > > > Ah, this is very interesting, thanks. > > > Having said all that, Brad favors Lua I believe, and he favors a different >> approach (which no one is working on as far as I know) to adding a new >> language. So wait to hear from him to know whether it is something that >> would be upstreamable. > > > Have any details on the approach in question ? SWIG would allow for Lua > bindings as easily, but I don't think having multiple languages would be a > good idea. > I went with Python because I'm familiar with it and have already written > bindings for it with SWIG. Also, buildbot is written in python and it could > provide a really interesting integration I think. > > I would guide/support you in refactoring cmake as needed. The refactoring >> part would definitely be upstreamable. I would very much like to see a >> proof >> of concept alternative language even if that wasn't upstreamed. It would >> prove that another language is possible, and that's one of the steps to >> replacing the current cmake language I think. > > > I will need to work on it to make it work again with master, but I'll try > and do this soon. > > Here is what my test POC looked like for generating a simple shared > library: > > #!/usr/bin/env python >> # -*- coding: utf-8 -*- >> import cmake >> cmake.init("Ninja", "/media/dev/src/cmaketest", >> "/media/dev/build/cmaketest") >> myProject = cmake.Project("MyTestProject") >> myProject.targets = [ cmake.SharedLibrary("testLibrary", ["lib.cxx"]) ] >> cmake.generate() > > > Thanks a lot for your comments, I'm happy to see this was not just a dumb > idea, and that others have thought about it. > > I'll update with the github as soon as I get it working. > > Best > > > Le lun. 4 janv. 2016 à 01:16, Stephen Kelly a écrit : > >> Charles Huet wrote: >> >> > * cmCacheManager::AddCacheEntry was made public, as cmake::Configure >> > cannot be used from python (it check for the existence of a >> CMakeLists.txt >> > file, which does not exist in this scenario) and the cache variables it >> > sets seem to be necessary. >> >> Because of the above, I worry that you are basing your work on an old >> version of CMake. As of April 2015 cmState is used as the interface to the >> cache. >> >> https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a6b1ad13 >> >> Also note that the C++ interfaces in CMake are not stable. In the last >> year >> they have been changed utterly and that will continue to happen without >> notice. I'm sure you know this, but I thought I'd say it anyway. >> >> > I will try to make a layer of abstraction on top of the python bindings >> > before publishing this work on github, in order to show the syntactic >> > sugar python can provide, but I will publish this before if anybody is >> > interested in working on this. >> >> I would be interested in seeing it. >> >> > Now, does anyone beside me think this is a good idea ? >> >> I did something similar some years ago with QML instead of python, so it >> sounds interesting to me. >> >> In fact, one of the reasons for introducing cmState and doing all the >> refactoring I did in cmake was to make it possible to
Re: [cmake-developers] Using CMake as a library from Python
I took the time to make it work again, so I pushed it here: https://github.com/packadal/CMake/tree/cmake-python The whole branch is ugly as can be, and because I started with an old CMake and recently rebased, the python abstraction might be bloated already, but it works in the nominal case, and it would be pretty easy to add most of the CMake basic functionalities. I am not used to writing python, so it might not be idiomatic either, but hey, it works as a simple proof of concept, and it's all I wanted to do for now :) Le lun. 4 janv. 2016 à 08:41, Charles Hueta écrit : > Hi, > > Because of the above, I worry that you are basing your work on an old >> version of CMake. As of April 2015 cmState is used as the interface to the >> cache. > > > Yeah, that is sadly right. I wanted to rebase on master before publishing, > thinking it should not be too hard, and I have lots to re-do, mostly > understand how things are done now. > > I did something similar some years ago with QML instead of python, so it >> sounds interesting to me. > > > I'm trying to be as declarative as possible, because really like how > readable simple QML programs are, and I think it would be perfect for a > buildsystem. > > My guess is that you are using python to instantiate a cmAddLibraryCommand >> and then executing it. > > > Actually, I'm directly using the cmMakefile, because I did not want to > wrap all the commands, and it seemed backwards to me to wrap them. > > Even much of cmMakefile shouldn't be used by a new language. Instead >> certain >> parts of cmMakefile should be extracted as other classes >> (cmVariableExpander >> which should have the ExpandVariablesInString and ConfigureString stuff, >> cmMessenger for the IssueMessage stuff, some other class for the >> CompileFeature stuff etc). Then cmMakefile would be just about executing >> and >> scoping the CMake language. A new language would not need that, but would >> use the refactored extracted classes. > > > Ah, this is very interesting, thanks. > > > Having said all that, Brad favors Lua I believe, and he favors a different >> approach (which no one is working on as far as I know) to adding a new >> language. So wait to hear from him to know whether it is something that >> would be upstreamable. > > > Have any details on the approach in question ? SWIG would allow for Lua > bindings as easily, but I don't think having multiple languages would be a > good idea. > I went with Python because I'm familiar with it and have already written > bindings for it with SWIG. Also, buildbot is written in python and it could > provide a really interesting integration I think. > > I would guide/support you in refactoring cmake as needed. The refactoring >> part would definitely be upstreamable. I would very much like to see a >> proof >> of concept alternative language even if that wasn't upstreamed. It would >> prove that another language is possible, and that's one of the steps to >> replacing the current cmake language I think. > > > I will need to work on it to make it work again with master, but I'll try > and do this soon. > > Here is what my test POC looked like for generating a simple shared > library: > > #!/usr/bin/env python >> # -*- coding: utf-8 -*- >> import cmake >> cmake.init("Ninja", "/media/dev/src/cmaketest", >> "/media/dev/build/cmaketest") >> myProject = cmake.Project("MyTestProject") >> myProject.targets = [ cmake.SharedLibrary("testLibrary", ["lib.cxx"]) ] >> cmake.generate() > > > Thanks a lot for your comments, I'm happy to see this was not just a dumb > idea, and that others have thought about it. > > I'll update with the github as soon as I get it working. > > Best > > > Le lun. 4 janv. 2016 à 01:16, Stephen Kelly a écrit : > >> Charles Huet wrote: >> >> > * cmCacheManager::AddCacheEntry was made public, as cmake::Configure >> > cannot be used from python (it check for the existence of a >> CMakeLists.txt >> > file, which does not exist in this scenario) and the cache variables it >> > sets seem to be necessary. >> >> Because of the above, I worry that you are basing your work on an old >> version of CMake. As of April 2015 cmState is used as the interface to the >> cache. >> >> https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a6b1ad13 >> >> Also note that the C++ interfaces in CMake are not stable. In the last >> year >> they have been changed utterly and that will continue to happen without >> notice. I'm sure you know this, but I thought I'd say it anyway. >> >> > I will try to make a layer of abstraction on top of the python bindings >> > before publishing this work on github, in order to show the syntactic >> > sugar python can provide, but I will publish this before if anybody is >> > interested in working on this. >> >> I would be interested in seeing it. >> >> > Now, does anyone beside me think this is a good idea ? >> >> I did something similar some years ago with QML instead of python, so it >>
Re: [cmake-developers] Using CMake as a library from Python
Yes, this is POC-only. I felt too lazy to make an argparse object and properly perform these tasks. Obviously, the generator and source dir should be arguments. The build dir should be the execution dir of the script, to mimic CMake behavior. This should not be difficult, but as I said I wanted first to get this disussion started. Le lun. 4 janv. 2016 à 11:54, Tamás Kenéza écrit : > Charles, > > I'd like to comment on a minor issue: > > CMakeLists.txt files don't specify user-specific data like source and > build dirs (for a reason) yet your POC listfile contains this line: > > cmake.init("Ninja", "/media/dev/src/cmaketest", > "/media/dev/build/cmaketest") > > which sets the source and build directories. Is this some temporary > solution for the POC only? > > Tamas > > On Mon, Jan 4, 2016 at 8:41 AM, Charles Huet > wrote: > >> Hi, >> >> Because of the above, I worry that you are basing your work on an old >>> version of CMake. As of April 2015 cmState is used as the interface to >>> the >>> cache. >> >> >> Yeah, that is sadly right. I wanted to rebase on master before >> publishing, thinking it should not be too hard, and I have lots to re-do, >> mostly understand how things are done now. >> >> I did something similar some years ago with QML instead of python, so it >>> sounds interesting to me. >> >> >> I'm trying to be as declarative as possible, because really like how >> readable simple QML programs are, and I think it would be perfect for a >> buildsystem. >> >> My guess is that you are using python to instantiate a cmAddLibraryCommand >>> and then executing it. >> >> >> Actually, I'm directly using the cmMakefile, because I did not want to >> wrap all the commands, and it seemed backwards to me to wrap them. >> >> Even much of cmMakefile shouldn't be used by a new language. Instead >>> certain >>> parts of cmMakefile should be extracted as other classes >>> (cmVariableExpander >>> which should have the ExpandVariablesInString and ConfigureString stuff, >>> cmMessenger for the IssueMessage stuff, some other class for the >>> CompileFeature stuff etc). Then cmMakefile would be just about executing >>> and >>> scoping the CMake language. A new language would not need that, but would >>> use the refactored extracted classes. >> >> >> Ah, this is very interesting, thanks. >> >> >> Having said all that, Brad favors Lua I believe, and he favors a different >>> approach (which no one is working on as far as I know) to adding a new >>> language. So wait to hear from him to know whether it is something that >>> would be upstreamable. >> >> >> Have any details on the approach in question ? SWIG would allow for Lua >> bindings as easily, but I don't think having multiple languages would be a >> good idea. >> I went with Python because I'm familiar with it and have already written >> bindings for it with SWIG. Also, buildbot is written in python and it could >> provide a really interesting integration I think. >> >> I would guide/support you in refactoring cmake as needed. The refactoring >>> part would definitely be upstreamable. I would very much like to see a >>> proof >>> of concept alternative language even if that wasn't upstreamed. It would >>> prove that another language is possible, and that's one of the steps to >>> replacing the current cmake language I think. >> >> >> I will need to work on it to make it work again with master, but I'll try >> and do this soon. >> >> Here is what my test POC looked like for generating a simple shared >> library: >> >> #!/usr/bin/env python >>> # -*- coding: utf-8 -*- >>> import cmake >>> cmake.init("Ninja", "/media/dev/src/cmaketest", >>> "/media/dev/build/cmaketest") >>> myProject = cmake.Project("MyTestProject") >>> myProject.targets = [ cmake.SharedLibrary("testLibrary", ["lib.cxx"]) ] >>> cmake.generate() >> >> >> Thanks a lot for your comments, I'm happy to see this was not just a dumb >> idea, and that others have thought about it. >> >> I'll update with the github as soon as I get it working. >> >> Best >> >> >> Le lun. 4 janv. 2016 à 01:16, Stephen Kelly a >> écrit : >> >>> Charles Huet wrote: >>> >>> > * cmCacheManager::AddCacheEntry was made public, as cmake::Configure >>> > cannot be used from python (it check for the existence of a >>> CMakeLists.txt >>> > file, which does not exist in this scenario) and the cache variables it >>> > sets seem to be necessary. >>> >>> Because of the above, I worry that you are basing your work on an old >>> version of CMake. As of April 2015 cmState is used as the interface to >>> the >>> cache. >>> >>> https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a6b1ad13 >>> >>> Also note that the C++ interfaces in CMake are not stable. In the last >>> year >>> they have been changed utterly and that will continue to happen without >>> notice. I'm sure you know this, but I thought I'd say it anyway. >>> >>> > I will try to make a layer of abstraction
[cmake-developers] [CMake 0015901]: `-Og` dose not produce debug symbol in CMake
The following issue has been SUBMITTED. == https://cmake.org/Bug/view.php?id=15901 == Reported By:acgtyrant Assigned To: == Project:CMake Issue ID: 15901 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2016-01-04 03:50 EST Last Modified: 2016-01-04 03:50 EST == Summary:`-Og` dose not produce debug symbol in CMake Description: Use `-Og` in CMAKE_CXX_FLAGS, the compiled result does not contain any `.debug_*` section. Steps to Reproduce: CMakeList.txt: set(CMAKE_CXX_FLAGS "-std=c++11 -Wall -Wextra -Og") add_executable(Demo tmp.cc) tmp.cc: #include int main(void) { std::cout << "Hello, world" << std::endl; return 0; } Put CMakeList.txt and tmp.cc in the same directory, then execute `cmake .; make; objdump -h Demo | grep .debug`, no result. For comparison, I compile the tmp.cc by myself: `g++ -std=c++11 -Wall -Wextra -Og tmp.cc; objdump -h a.out | grep .debug`. It returns: 26 .debug_aranges 0030 0d32 2**0 27 .debug_info 2a64 0d62 2**0 28 .debug_abbrev 0651 37c6 2**0 29 .debug_line 0372 3e17 2**0 30 .debug_str1a02 4189 2**0 31 .debug_loc009e 5b8b 2**0 Additional Information: $ LANG=C gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-unknown-linux-gnu/5.3.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: /build/gcc/src/gcc-5.3.0/configure --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/ --enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared --enable-threads=posix --enable-libmpx --with-system-zlib --with-isl --enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object --enable-linker-build-id --enable-lto --enable-plugin --enable-install-libiberty --with-linker-hash-style=gnu --enable-gnu-indirect-function --disable-multilib --disable-werror --enable-checking=release Thread model: posix gcc version 5.3.0 (GCC) == Issue History Date ModifiedUsername FieldChange == 2016-01-04 03:50 acgtyrant New Issue == -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Add command line options for deprecation message control
Hi Brad, To round off the -W options functionality, I've implemented the -Werror and -Wno-error set of options for the two current types of messages, dev and deprecated. This includes updating the QT GUI to include new options for controlling this functionality. The third patch is not for new functionality, but addresses two small inconsistencies relating to dev and deprecated messages functionality, it's not needed at the end of the day but I thought it would be good to make the code consistent while I was in the area. Lastly I'm also looking at changing all the current usages of the cmake::IssueMessage command, where the message type is dev warning. To check if the warning got upgraded to an error (by checking if the error state has been signalled with the cmSystemTools class), and change the return value of the calling function for example. I think this was discussed previously, however I think this might not be the right change to make. There's quite a few instances of the above code and changing them all is dangerous I imagine where I don't know exactly what all of the callers are generally doing and should be doing. It also implies an undocumented rule that future users of the above functionality should also do this check, which doesn't sound like a good idea to me. What are your thoughts on this last point? Cheers, Michael >From 319afb022cae89d64bc9075e2a686966971cda1c Mon Sep 17 00:00:00 2001 From: Michael ScottDate: Mon, 21 Dec 2015 21:39:27 + Subject: [PATCH 1/3] Implement -Werror and -Wno-error cmake options Expanded the -W set of cmake options to include support for the -Werror and -Wno-error format, which is used to control upgrading and downgrading warning and error messages. Implemented support for these new formats for the dev and deprecated message types. Added tests and updated documentation for new options. --- Help/manual/OPTIONS_BUILD.txt | 24 +++ Help/release/dev/cmake-W-options.rst | 7 + Source/cmMessageCommand.cxx| 29 +-- Source/cmake.cxx | 200 - Source/cmake.h | 42 - Tests/RunCMake/CommandLine/RunCMakeTest.cmake | 22 +++ Tests/RunCMake/CommandLine/W_bad-arg3-result.txt | 1 + Tests/RunCMake/CommandLine/W_bad-arg3-stderr.txt | 2 + .../CommandLine/Werror_deprecated-result.txt | 1 + .../CommandLine/Werror_deprecated-stderr.txt | 4 + Tests/RunCMake/CommandLine/Werror_deprecated.cmake | 1 + Tests/RunCMake/CommandLine/Werror_dev-result.txt | 1 + Tests/RunCMake/CommandLine/Werror_dev-stderr.txt | 11 ++ Tests/RunCMake/CommandLine/Werror_dev.cmake| 7 + .../CommandLine/Wno-error_deprecated-stderr.txt| 4 + .../CommandLine/Wno-error_deprecated.cmake | 2 + .../RunCMake/CommandLine/Wno-error_dev-stderr.txt | 11 ++ Tests/RunCMake/CommandLine/Wno-error_dev.cmake | 7 + Tests/RunCMake/message/RunCMakeTest.cmake | 6 +- Tests/RunCMake/message/errormessage-result.txt | 1 - Tests/RunCMake/message/errormessage-stderr.txt | 4 - Tests/RunCMake/message/errormessage.cmake | 4 - .../message/errormessage_deprecated-result.txt | 1 + .../message/errormessage_deprecated-stderr.txt | 4 + .../RunCMake/message/errormessage_deprecated.cmake | 3 + Tests/RunCMake/message/errormessage_dev-result.txt | 1 + Tests/RunCMake/message/errormessage_dev-stderr.txt | 5 + Tests/RunCMake/message/errormessage_dev.cmake | 3 + 28 files changed, 372 insertions(+), 36 deletions(-) create mode 100644 Tests/RunCMake/CommandLine/W_bad-arg3-result.txt create mode 100644 Tests/RunCMake/CommandLine/W_bad-arg3-stderr.txt create mode 100644 Tests/RunCMake/CommandLine/Werror_deprecated-result.txt create mode 100644 Tests/RunCMake/CommandLine/Werror_deprecated-stderr.txt create mode 100644 Tests/RunCMake/CommandLine/Werror_deprecated.cmake create mode 100644 Tests/RunCMake/CommandLine/Werror_dev-result.txt create mode 100644 Tests/RunCMake/CommandLine/Werror_dev-stderr.txt create mode 100644 Tests/RunCMake/CommandLine/Werror_dev.cmake create mode 100644 Tests/RunCMake/CommandLine/Wno-error_deprecated-stderr.txt create mode 100644 Tests/RunCMake/CommandLine/Wno-error_deprecated.cmake create mode 100644 Tests/RunCMake/CommandLine/Wno-error_dev-stderr.txt create mode 100644 Tests/RunCMake/CommandLine/Wno-error_dev.cmake delete mode 100644 Tests/RunCMake/message/errormessage-result.txt delete mode 100644 Tests/RunCMake/message/errormessage-stderr.txt delete mode 100644 Tests/RunCMake/message/errormessage.cmake create mode 100644 Tests/RunCMake/message/errormessage_deprecated-result.txt create mode 100644 Tests/RunCMake/message/errormessage_deprecated-stderr.txt create mode 100644 Tests/RunCMake/message/errormessage_deprecated.cmake create mode 100644
[Cmake-commits] CMake branch, master, updated. v3.4.1-763-ga6cbc89
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "CMake". The branch, master has been updated via a6cbc89179f7fc6e4ac359df48eb1d31abe027cb (commit) from 3d2d17c00c2b20185b7fe0af22ba06bba3730d7c (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a6cbc89179f7fc6e4ac359df48eb1d31abe027cb commit a6cbc89179f7fc6e4ac359df48eb1d31abe027cb Author: Kitware Robot <kwro...@kitware.com> AuthorDate: Tue Jan 5 00:01:05 2016 -0500 Commit: Kitware Robot <kwro...@kitware.com> CommitDate: Tue Jan 5 00:01:05 2016 -0500 CMake Nightly Date Stamp diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake index b1225b7..29fdd3f 100644 --- a/Source/CMakeVersion.cmake +++ b/Source/CMakeVersion.cmake @@ -1,5 +1,5 @@ # CMake version number components. set(CMake_VERSION_MAJOR 3) set(CMake_VERSION_MINOR 4) -set(CMake_VERSION_PATCH 20160104) +set(CMake_VERSION_PATCH 20160105) #set(CMake_VERSION_RC 1) --- Summary of changes: Source/CMakeVersion.cmake |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/mailman/listinfo/cmake-commits
Re: [CMake] Get target name from command line for IF statement
Hi Yann, I have no idea what LINKER_SCATTER_FILE does, but... if( TARGET ) is a check that will evaluate to true if a target named *exists*. In this configuration neither "target_1" or "target_2" exist at the point when you run this check. So LINKER_SCATTER_FILE will always be set to "file_2". I think you're mixing what happens when configuring your build, and when actually executing it. In this setup you seem to always want to build both target_1 and target_2. So you'll need to set some property on these targets to assign the different "scatter files" to them. (I have absolutely no idea what a "scatter file" is supposed to be...) Could you elaborate on what you're really trying to do? Cheers, Attila > On 30 Dec 2015, at 11:29, yann suisiniwrote: > > Hi, > > I have a cmake file with 2 targets defined inside. > For each target I have to specify a different scatter file for my linker > > so I want to use : > if (TARGET target_1) > SET (LINKER_SCATTER_FILE file_1) > else () > SET (LINKER_SCATTER_FILE file_2) > endif () > > add_executable(target_1 ${srcs_target_1}) > add_executable(target_2 ${srcs_target_2}) > > > But if I'm calling cmake from my IDE to build my target using the --target > command line option > does it set the TARGET variable ? If not the case how I can link the targer > name from the command line to my IF statement ? > > Regards, > > Yann. > > > > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] fixup bundle vs Qy 5.5.1 and rpaths
That solved my problem indeed. Thank you very much (and happy new year). Kind regards, Greg. > On 18 Dec 2015, at 16:15, clin...@elemtech.com wrote: > > > It appears you need to add the directory(ies) in the Qt installation > containing the Qt libraries to your DIRS. > > set( DIRS > ${APP}/Contents/plugins/platforms > ${QT_BINARY_DIR} > ${QT_LIBRARY_DIR} > ) > > I think it should have been that way, even with Qt 5.3. > > Clint > > - On Dec 18, 2015, at 6:12 AM, Gregory Van Vooren> wrote: > > I have a project containing several applications (which are sub projects), > each of which links against some Qt libraries which are built as dylibs, but > are not part of the project. Qt libraries and headers are found using > find-package which is working perfectly. > > I’m currently trying to switch from Qt 5.3.1 to Qt 5.5.1, but am experiencing > problems with fixup_bundle on OS X (everything else seems to work fine). > As far as I’ve gathered Qt has introduced support for rpaths between those > two version and this seems to be the cause of my problems. > > Building a single application works and said application starts up correctly, > but building the install target will give me the following output: > > -- fixup_bundle: preparing... > -- > warning: cannot resolve item 'libQt5Core_debug.5.dylib' > > possible problems: > need more directories? > need to use InstallRequiredSystemLibraries? > run in install tree instead of build tree? > > -- warning: gp_resolved_file_type non-absolute file > 'libQt5Core_debug.5.dylib' returning type 'other' -- possibly incorrect > -- > warning: cannot resolve item 'libQt5Core_debug.5.dylib' > > possible problems: > need more directories? > need to use InstallRequiredSystemLibraries? > run in install tree instead of build tree? > > warning: target 'libQt5Core_debug.5.dylib' is not absolute... > warning: target 'libQt5Core_debug.5.dylib' does not exist... > CMake Error at > /Applications/CMake.app/Contents/share/cmake-3.4/Modules/GetPrerequisites.cmake:800 > (message): > > > /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/otool > failed: 1 > > error: > > /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/otool: > can't open file: libQt5Core_debug.5.dylib (No such file or directory) > > Call Stack (most recent call first): > > /Applications/CMake.app/Contents/share/cmake-3.4/Modules/GetPrerequisites.cmake:925 > (get_prerequisites) > > /Applications/CMake.app/Contents/share/cmake-3.4/Modules/BundleUtilities.cmake:555 > (get_prerequisites) > > /Applications/CMake.app/Contents/share/cmake-3.4/Modules/BundleUtilities.cmake:804 > (get_bundle_keys) > someApplication/someApplication/cmake_install.cmake:115 (fixup_bundle) > > > I’ll try to provide sufficient yet minimal information to pinpoint the root > cause of the problem. > In my top CMakeLists.txt I have the following: > > set ( > QT_REQUIRED_PACKAGES > Core > Gui > Widgets > ) > > set( QT_ROOT_PATH "/usr/local/Qt-5.5.1" ) > set( QT_REQUIRED_PACKAGES ${QT_REQUIRED_PACKAGES} MacExtras ) > > set( > QT_PLUGINS_DIR > "${QT_ROOT_PATH}/plugins" > ) > > set ( CMAKE_PREFIX_PATH ${CMAKE_PREFIX_PATH} "${QT_ROOT_PATH}/bin/" ) > > FOREACH(QT_PACKAGE ${QT_REQUIRED_PACKAGES}) > set( QT_PACKAGE_WITH_PREFIX "Qt5${QT_PACKAGE}" ) > set( "${QT_PACKAGE_WITH_PREFIX}_DIR" > "${QT_ROOT_PATH}/lib/cmake/${QT_PACKAGE_WITH_PREFIX}" ) > find_package( "${QT_PACKAGE_WITH_PREFIX}" REQUIRED ) > include_directories( ${${QT_PACKAGE_WITH_PREFIX}_INCLUDE_DIRS} ) > > set_target_properties( "Qt5::${QT_PACKAGE}" PROPERTIES > MAP_IMPORTED_CONFIG_DEBUG "DEBUG") > set_target_properties( "Qt5::${QT_PACKAGE}" PROPERTIES > MAP_IMPORTED_CONFIG_RELEASE "RELEASE") > set_target_properties( "Qt5::${QT_PACKAGE}" PROPERTIES > MAP_IMPORTED_CONFIG_RELWITHDEBINFO "RELEASE") > ENDFOREACH(QT_PACKAGE) > > add_definitions( ${QT_DEFINITIONS} ) > set( CMAKE_INSTALL_PREFIX ${CMAKE_CURRENT_BINARY_DIR} ) > > set( CMAKE_MACOSX_RPATH “" ) > > set_property( GLOBAL PROPERTY USE_FOLDERS ON ) > > add_subdirectory( someApplication ) > > > > > in the someApplication CMakeLists.txt I have the following: > > set( > someApplication_Qt_LIBRARIES > ${Qt5Core_LIBRARIES} > ${Qt5Widgets_LIBRARIES} > ) > set_target_properties( someApplication PROPERTIES INSTALL_RPATH > "${QT_ROOT_PATH}/lib" ) > foreach( OUTPUTCONFIG ${CMAKE_CONFIGURATION_TYPES} ) > install( TARGETS someApplication DESTINATION bin/${OUTPUTCONFIG} > CONFIGURATIONS ${OUTPUTCONFIG} ) > endforeach() > > add_custom_command( TARGET someApplication POST_BUILD COMMAND mkdir -p >
[cmake-developers] [CMake 0015902]: ExternalProject Module doesn't work with GHS Multi Generator and Git
The following issue has been SUBMITTED. == https://public.kitware.com/Bug/view.php?id=15902 == Reported By:iainmeikle Assigned To: == Project:CMake Issue ID: 15902 Category: CMake Reproducibility:always Severity: major Priority: normal Status: new == Date Submitted: 2016-01-04 09:09 EST Last Modified: 2016-01-04 09:09 EST == Summary:ExternalProject Module doesn't work with GHS Multi Generator and Git Description: When using the ExternalProject module with the GHS Multi generator external project dependencies are not obtained and built, rule files are missing but the external project GPJ files still report success when building. Steps to Reproduce: 1. Create a CMake project which makes use of the ExternalProject module to pull in an external project using Git. 2. Execute CMake to generate the GPJ files. 3. Build the generated default GPJ. 4. Note that the dependency is not resolved and that *.rule files referenced by any "CMake Rules.gpj" which is in turn referenced by each external project GPJ, which is referenced by the ExternalProjectTargets.gpj are missing. == Issue History Date ModifiedUsername FieldChange == 2016-01-04 09:09 iainmeikle New Issue == -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [CMake] I can not set CMAKE_BUILD_TYPE in CMakeList.txt
Hi Isaac, ccmake will only allow you to modify cache variables. When you call set( CMAKE_BUILD_TYPE RelWithDebInfo ) , this creates a local variable in your CMakeLists.txt file. This way it should *always* override whatever you set on the command line, or as a cache variable. If you want to set the default value to RelWithDebInfo, but allow the user to override it either with ccmake or a command line argument, you should do something like: set( CMAKE_BUILD_TYPE RelWithDebInfo CACHE STRING "Build type" ) At least I think it should work like this... Cheers, Attila > On 05 Jan 2016, at 08:11, Isaac Gewrote: > > Hi anyone, I find the `set(CMAKE_BUILD_TYPE RelWithDebInfo)` in CMakeList.txt > does not work, because the actual build type show by ccmake is empty. So I > have to enter the correct build type in ccmake or add command argument `-D > CMAKE_BUILD_TYPE=RelWithDebInfo` while cmake. > > Any idea? Thank you! > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
[CMake] I can not set CMAKE_BUILD_TYPE in CMakeList.txt
Hi anyone, I find the `set(CMAKE_BUILD_TYPE RelWithDebInfo)` in CMakeList.txt does not work, because the actual build type show by ccmake is empty. So I have to enter the correct build type in ccmake or add command argument `-D CMAKE_BUILD_TYPE=RelWithDebInfo` while cmake. Any idea? Thank you! -- 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
[cmake-developers] [CMake 0015903]: pkg_search_module no longer caches _PREFIX, _LIBDIR, _INCLUDEDIR
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=15903 == Reported By:Bernd Lörwald Assigned To: == Project:CMake Issue ID: 15903 Category: Modules Reproducibility:always Severity: major Priority: normal Status: new == Date Submitted: 2016-01-04 17:49 CET Last Modified: 2016-01-04 17:49 CET == Summary:pkg_search_module no longer caches _PREFIX, _LIBDIR, _INCLUDEDIR Description: Beginning with https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=70e8db6e20749a484dd677d7094780c5f4b451c6, the pkgconfig module no longer caches the _PREFIX, _LIBDIR, _INCLUDEDIR variables. This was introduced by using pkg_get_variable which sets for PARENT_SCOPE but not CACHE as _pkgconfig_set did previously. Instead, a helper variable is cached. Steps to Reproduce: $ cat > CMakeLists.txt cmake_minimum_required (VERSION 3.3) find_package (PkgConfig) pkg_search_module (PREFIX REQUIRED gl) if (NOT PREFIX_PREFIX) message (FATAL_ERROR "BUMMER") endif() ^D $ cmake-3.4.1 . -- […snip] -- Found PkgConfig: /usr/bin/pkg-config (found version "0.28") -- Checking for one of the modules 'gl' -- Configuring done -- Generating done -- Build files have been written to: […snip] $ cmake-3.4.1 . CMake Error at CMakeLists.txt:5 (message): BUMMER $ grep -E "prefix_result|PREFIX_PREFIX" CMakeCache.txt PREFIX_PREFIX:INTERNAL= prefix_result:INTERNAL=/usr/lib64 $ cmake-3.3.2 . -- […snip] -- Found PkgConfig: /usr/bin/pkg-config (found version "0.28") -- checking for one of the modules 'gl' -- Configuring done -- Generating done -- Build files have been written to: […snip] $ cmake-3.3.2 . -- Configuring done -- Generating done -- Build files have been written to: […snip] $ grep -E "prefix_result|PREFIX_PREFIX" CMakeCache.txt PREFIX_PREFIX:INTERNAL=/usr == Issue History Date ModifiedUsername FieldChange == 2016-01-04 17:49 Bernd Lörwald New Issue == -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
[CMake] Using "Fixup_Bundle" on a single library?
During our packaging process one of our support libraries is getting missed for various reasons (severe edge case). Is it possible to use the “Fixup_bundle” CMake function with a single library? Or add that single library as an additional library that needs to be adjusted? Thanks -- Michael A. Jackson BlueQuartz Software, LLC [e]: mike.jack...@bluequartz.net -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] Error generating using "NMake Makefiles JOM"
Yes, jom is in the path. However, someone very brilliant in the IT department made it such that the system PATH and user PATH equaled the same strings, causing my overall PATH to be way too long for Windows' liking. So the jom part of the path was being truncated out. I wouldn't have thought of that, but noticed it when I doubled checked based on your feedback. Thanks Tom. It's all working lovely now. On Mon, Jan 4, 2016 at 11:34 AM, Tom Kacvinskywrote: > > > On Sun, Jan 3, 2016 at 11:05 PM, Bill Church > wrote: > >> I've used this option successfully for a while, but with an older version >> of CMake (3.x, unsure which one exactly). Recently had to do a full >> wipe/reinstall of my machine, so I pulled down the latest CMake 3.4.1, but >> when I go to generate my project I get the following error: >> >> CMake Error: Generator: execution of make failed. Make command was: "jom" >> "/NOLOGO" "cmTC_4f467\fast" >> >> I'm also now using the latest version of Jom, which is 1.1.0. Any help >> resolving this issue would be much appreciated. >> >> > Is jom in your path? I have seen this before and sure enough, jom was no > tin my path. > > -- 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
Re: [CMake] Error generating using "NMake Makefiles JOM"
On Sun, Jan 3, 2016 at 11:05 PM, Bill Churchwrote: > I've used this option successfully for a while, but with an older version > of CMake (3.x, unsure which one exactly). Recently had to do a full > wipe/reinstall of my machine, so I pulled down the latest CMake 3.4.1, but > when I go to generate my project I get the following error: > > CMake Error: Generator: execution of make failed. Make command was: "jom" > "/NOLOGO" "cmTC_4f467\fast" > > I'm also now using the latest version of Jom, which is 1.1.0. Any help > resolving this issue would be much appreciated. > > Is jom in your path? I have seen this before and sure enough, jom was no tin my path. -- 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
Re: [cmake-developers] Profile Cmake scripts
On Sun, Dec 27, 2015 at 22:04:14 +0100, Dimitar Yordanov wrote: > I agree with you. Running valgrind directly on the cmake binary > provides useful information: I can see which internal cmake functions > are used the most and consume most of the time. > > Nevertheless, I think it would be useful to have a higher level > overview. E.g. to see if there are some issues with the scripts > themselves that I use in my project ... I had patches which did this, but it doesn't really help much. At least I didn't think it did. The problems are mainly in CMake itself (regular expressions, path parsing, etc.). I think the next big improvement would be caching variable values which are parsed as numbers, on/off, and paths as a more structured state so that if you have a path, path operations don't have to keep searching for directory separators since it is already in a std::vector structure. > > Usually you see mostly string handling related functions. > > malloc and free are on the top of what I see for a random project used > mostly by std::string. Maybe we can optimize something here too? I did a lot of profiling of CMake two years ago. I fixed the low-hanging fruit (rewriting the CMakeLists.txt parser/variable expander (CMP0053 if you aren't using it), fixing other mini-parsers (escape routines, the genex parser) to chunk rather than do char-by-char iteration, etc.). The big remaining problem is passing char* as an argument where functions do std::string(arg) right away. I fixed all of those which did explicit std::string conversions (via assignment or otherwise), but those which are conditional should get std::string overloads to avoid a malloc/copy/free penalty. There is a *lot* of work here though. The branch I had been working on (which is now woefully out-of-date) is 100 commits long. --Ben -- 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