Re: [cmake-developers] [PATCH 2/2] Add test for generater expressions in test properties
On 07/03/15 22:20, Gregor Jasny wrote: > Surprisingly "new-style" tests support generator expressions > also within all test properties. Add a test for that. This still lacks documentation. The question is what would be the proper place(s) for this. I'd add extend the genex note here: http://www.cmake.org/cmake/help/git-next/command/add_test.html?highlight=add_test But I also think all test properties should receive an individual note. What do you think? If the "old-style" add_test lacks functionality how about deprecating it? Thanks, Gregor -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
[cmake-developers] [PATCH 1/2] Fix deprecation warning about non-writeable strings
Signed-off-by: Gregor Jasny --- Tests/Environment/main.cxx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Tests/Environment/main.cxx b/Tests/Environment/main.cxx index 2e1bf4c..b54a664 100644 --- a/Tests/Environment/main.cxx +++ b/Tests/Environment/main.cxx @@ -3,7 +3,7 @@ int main(int argc, char *argv[]) { - char* var = getenv("CMAKE_ENVIRONMENT_TEST_VAR"); + const char* var = getenv("CMAKE_ENVIRONMENT_TEST_VAR"); if (!var) { var = "(null)"; -- 2.3.0 -- 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-developers] [PATCH 2/2] Add test for generater expressions in test properties
Suprisingly "new-style" tests support generater expressions also within all test properties. Add a test for that. Signed-off-by: Gregor Jasny --- Tests/Environment/CMakeLists.txt | 12 1 file changed, 12 insertions(+) diff --git a/Tests/Environment/CMakeLists.txt b/Tests/Environment/CMakeLists.txt index 2b18d24..13d 100644 --- a/Tests/Environment/CMakeLists.txt +++ b/Tests/Environment/CMakeLists.txt @@ -2,6 +2,7 @@ cmake_minimum_required(VERSION 2.6) project(EnvironmentProj) add_executable(Environment main.cxx) +set_property(TARGET Environment PROPERTY FOO Bar) enable_testing() @@ -24,3 +25,14 @@ set_tests_properties(Environment1 EchoEnvironment1 PROPERTIES set_tests_properties(Environment2 EchoEnvironment2 PROPERTIES FAIL_REGULAR_EXPRESSION "CMAKE_ENV.*Happy Thanksgiving" ) + +# Test with generator expression +# Note: this requires a "new-style" add_test signature +# +add_test(NAME Environment3 COMMAND Environment) +add_test(NAME EchoEnvironment3 COMMAND ${CMAKE_COMMAND} -E environment) + +set_tests_properties(Environment3 EchoEnvironment3 PROPERTIES + ENVIRONMENT "CMAKE_ENVIRONMENT_TEST_VAR=$" + PASS_REGULAR_EXPRESSION "CMAKE_ENV.*Bar" +) -- 2.3.0 -- 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] Extracting target metadata, IDE integration
On Fri, Aug 29, 2014 at 4:20 AM, Aleix Pol wrote: > Dear cmake'rs, > I'm rewriting the KDevelop plugin from scratch to fetch the information from > the build directory. > > Now in the first implementation I'm using the compile_commands.json file > that cmake already can generate for some time. It works quite well already, > given how data just comes out ready to be consumed (almost). The problem now > is that we're lacking some information, namely information about the > targets, their location and such *. > > To that end, I wrote a little patch to be taken as a proof of concept, that > generates (some of) the needed information. I would like to know if you > think it's an approach that would be accepted in the cmake code-base or if I > need to take a different approach. > > Patch http://proli.net/meu/kdevelop/cmake-targetsdata.patch > Output: http://proli.net/meu/kdevelop/AwesomeTargets.json > > Cheers! > Aleix > > * Yes, I'm aware of generators, but I'm not comfortable with the idea of > tying a build directory to an editor (even if it's my editor). Our users > usually build the projects with different tools and asking them to re-create > their build only for being comfortable with KDevelop sometimes is a burden. > It would be for me too! I just pushed my change into a github clone for easier testing and reviewing. https://github.com/aleixpol/CMake Aleix -- 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-developers] [CMake 0015436]: ninja generator fails to produce include statement for rules
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=15436 == Reported By:Benjamin Schindler Assigned To: == Project:CMake Issue ID: 15436 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2015-03-07 06:24 EST Last Modified: 2015-03-07 06:24 EST == Summary:ninja generator fails to produce include statement for rules Description: I tried now cmake-3.0, 2.8.11 and 3.1 and all exhibit this issue: I have a very simple project (helloworld would suffice) and use the ninja generator. The project fails to build with: ninja: error: build.ninja:20: unknown build rule 'CXX_COMPILER' Upon inspection, I noted that on the top, older generators produced this line in the ninja generator: # # Include rules file. include rules.ninja This is not present in the tested versions thus leading to the described bug. Steps to Reproduce: Create hello world project, produce ninja file and build. Should lead to: ninja: error: build.ninja:20: unknown build rule 'CXX_COMPILER' == Issue History Date ModifiedUsername FieldChange == 2015-03-07 06:24 Benjamin SchindlerNew 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] Extracting target metadata, IDE integration
Hi Aleix, thank you for the ping:-) Since I am not fully fluent with cmake (have not really used it in a couple of years) and sometimes have a bit of trouble following the discussion about the details of this patch, I took the liberty to copy/paste (and part of) one of the example files you put up on KDEs codepaster, commenting on what I understood each section to mean. I think that is the best way for me to contribute to this discussion at this point. What are you actually building here? /home/kde-devel/tmp/llvm/CMakeLists.txt? > { How about adding some information on what this is you are actually building here? CMake has the PROJECT command that does provide quite a bit of information that could go here. Where are the sources this thing here is building? How were those sources configured? CMake supports quite a few generators, so which ones where used? Do I need to run ninja or make to build this (or should I use "cmake build" anyway)? Creator does allow existing qmake builds to be imported and that kind of information does help a lot with that functionality. > "dependencies" : > [ > "/home/kde-devel/tmp/llvm/build/CMakeFiles/3.2.20150306-g139588/CMakeSystem.cmake", > "/lots/more/files", ... ] So these are all the files I need to watch for changes? If they change then I should re-run cmake? > "targets" : > [ So now comes a list of the possible things I can build... > { > "backtrace" : > [ > "/home/kde-devel/tmp/llvm/cmake/modules/AddLLVM.cmake:312", > "/home/kde-devel/tmp/llvm/cmake/modules/AddLLVM.cmake:399", > > "/home/kde-devel/tmp/llvm/lib/Target/PowerPC/TargetInfo/CMakeLists.txt:1" > ], That backtrace is nice! >"configs" : >[ >{ >"name" : "", Why is the name empty? >"output" : > "/home/kde-devel/tmp/llvm/build/lib/libLLVMPowerPCInfo.a", Can this be a list? >"sources" : [ "/list/of/cpp/files, ] Any way to also get the headers? Do you see any option to hint where new sources would need to be added to make them a part of this target? >} >], >"installed" : "true", I guess this means "make install" will install it. Where will this file end up? >"name" : "LLVMPowerPCInfo", >"output_directory" : > "/home/kde-devel/tmp/llvm/build/lib/Target/PowerPC/TargetInfo", For what is the output directory relevant? The output above does implicitly list that already, doesn't it? >"type" : "STATIC_LIBRARY" Which types are possible here? > }, There is a lot of useful information here! Thanks for pushing into this direction. I am sure this will help a lot. Ideally this file would be enough to provide all information we need as an IDE to: * Present the project structure as seen by the build system. * Generate the code model * Build the project * Deploy the project * Run and debug parts of the project * Adding and removing files to a project For the project structure this does help: It provides us with a list of all the build targets, which is already nice. CMake does support more structure with Projects and subprojects IIRC and that information is lost. Would it be much work to get that information back? For the code model this is not much help at all: There is no information on compiler used, include directories nor Defines or compiler flags. Where am I supposed to get that information from? Do I need to generate and parse the list of commands run and extract that information from there? Having that information available right in the sources array of each target would be so much more convenient and would also make IDE integration so much easier: You would need to know about one file only and won't need to figure out several. Building the project should be fine with the information provided. Explicitly stating the generators used would help a little bit (even better just giving the command necessary to build, e.g. make or ninja or whatnot. Then we would not need to hard-code the mapping of generators->build tools, which makes it much easier for you to support new things:-) Running/Debugging is a bit tricky again: All the information used for linking the binaries is gone. So there is no way to figure out which LD_LIBRARY_PATH needs to be set or anything. There also seems to be no information where files are going to get installed to. Would it be possible to add that information? I do not see any way to provide a reliable automatic way to add sources to a cmake build system (the others are unfortunately not better:-). For removing the files it would be nice to know where in which file/line the sources were added to the target. Not sure whether it is even possible to get that information... The backtrace you have is already great piece of information: At least that way we should be able to open the right file and have the user edit that manually. Does this help? Best Regards, Tobias -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: ht