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:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support
Re: [cmake-developers] Extracting target metadata, IDE integration
On Fri, Aug 29, 2014 at 4:20 AM, Aleix Pol aleix...@kde.org 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
[cmake-developers] [PATCH 1/2] Fix deprecation warning about non-writeable strings
Signed-off-by: Gregor Jasny gja...@googlemail.com
---
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 gja...@googlemail.com
---
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=$TARGET_PROPERTY:Environment,FOO
+ 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] [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
