Re: [cmake-developers] Extracting target metadata, IDE integration
On Sunday, March 15, 2015 18:00:25 Nils Gladitz wrote: On 15.03.2015 16:42, Tobias Hunger wrote: Hi Peter, CMake does know all the headers or it could not decide which files need rebuilding. The build system that CMake generates knows the header dependencies and decides when which files need rebuilding. CMake itself doesn't know. How header dependencies are determined and where and how they are recorded is generator specific. I have spent enough time on this code, so: nitpicking for the makefile-generators, the header dependencies are generated by cmake (not at cmake time, but at build time), which results in the depend.make file. /nitpicking Alex -- 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 Sun, Mar 15, 2015 at 6:17 PM, Peter Kümmel syntheti...@gmx.net wrote: The idea was that qtcreator then also could parse and change the CMakeLists.txt file (like it is done with qbs files, I assume). That would be a nice to have feature, yes, but I doubt that this will ever be an option with cmake. And I personally do not want to pile anything on top of cmake to enable this for a small subset of still-to-be-written projects. I would like to get to the point where you are able to build cmake projects, configure them and have creator open the correct CMakeLists.txt for you when you need to add/remove files to/from some target. It will need work in Creator to get there, and I really do not want that to end up relying on what I consider to be a implementation detail of cmake -- like the format of (probably even undocumented) files somewhere in the build directory that were meant for other consumers. This JSON file can be a step forward here: It is actually meant to be used by IDEs, it has a format straight forward to parse, it does not depend on the generator used, it will (hopefully;-) end up being documented, it provides versioning, etc. I see some potential there. 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 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
Tobias Hunger wrote: This JSON file can be a step forward here: It is actually meant to be used by IDEs, it has a format straight forward to parse, it does not depend on the generator used, it will (hopefully;-) end up being documented, it provides versioning, etc. I see some potential there. I asked for this thread to be discontinued. I provided a patch which has documentation. There is no 'hopefully' to it. You're simply responding to the wrong thread. 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
Re: [cmake-developers] Extracting target metadata, IDE integration
Hi Peter, CMake does know all the headers or it could not decide which files need rebuilding. How would making cmake parse a file in the syntax of another build system help creator understand existing cmake projects? This is not about extending cmake language: It makes cmake generate another description of the project in a format that IDEs can use, in addition to the description stored in the Makefiles (or whichever other build tool). 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 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 15.03.2015 16:42, Tobias Hunger wrote: Hi Peter, CMake does know all the headers or it could not decide which files need rebuilding. How would making cmake parse a file in the syntax of another build system help creator understand existing cmake projects? The idea was that qtcreator then also could parse and change the CMakeLists.txt file (like it is done with qbs files, I assume). This is not about extending cmake language: It makes cmake generate another description of the project in a format that IDEs can use, in addition to the description stored in the Makefiles (or whichever other build tool). 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 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 15.03.2015 16:42, Tobias Hunger wrote: Hi Peter, CMake does know all the headers or it could not decide which files need rebuilding. The build system that CMake generates knows the header dependencies and decides when which files need rebuilding. CMake itself doesn't know. How header dependencies are determined and where and how they are recorded is generator specific. Nils -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Extracting target metadata, IDE integration
On Saturday, March 14, 2015 09:40:41 Peter Kümmel wrote: On 12.03.2015 16:24, Tobias Hunger wrote: A list of *all* headers used during the building of the target would be fine. There is no need to filter that list down in any way. CMake has that information: Without it cmake could not possibly know when a cpp file needs rebuilding. It would not be as successful a build system when it did not know that:-) Even cmake does not know all headers need for compilation, this is done by the compiler providing the dependency files. the cmake dependency scanning does find all (and potentially some more) used headers, see depend.internal in the CMakeFiles/ tree. Alex -- 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 12.03.2015 16:24, Tobias Hunger wrote: A list of *all* headers used during the building of the target would be fine. There is no need to filter that list down in any way. CMake has that information: Without it cmake could not possibly know when a cpp file needs rebuilding. It would not be as successful a build system when it did not know that:-) Even cmake does not know all headers need for compilation, this is done by the compiler providing the dependency files. Overall, wouldn't it be better cmake could parse something like a QBS syntax? Or is also QBS's description not complete enough for an IDE? Is it good enough for QtCreator? I don't think extending CMake's language until eternity is a good idea, the way should go away from it to a common scripting language, so that generating meta-files becomes superfluous. Also we don't really have information about where to put them. You can use the minimum common denominator among the sources I guess. I don't understand that part, sorry. } ], installed : true, I guess this means make install will install it. Where will this file end up? Yes. I tried to figure it out but didn't manage to find the correct way to query it. I can try harder. :D 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? It's important in case the output path is overriden, see last e-mail by Alexander Neundorf. type : STATIC_LIBRARY Which types are possible here? It's an enum internal to cmake. At the moment: EXECUTABLE, STATIC_LIBRARY, SHARED_LIBRARY, MODULE_LIBRARY, OBJECT_LIBRARY, UTILITY, GLOBAL_TARGET, INTERFACE_LIBRARY, UNKNOWN_LIBRARY. }, 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? as discussed above, I'll look into that next thing. I am a cmake noob, but maybe I can help? 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. We can do that, I mentioned earlier in this thread that currently we're using compile_commands.json for that ( CMAKE_EXPORT_COMPILE_COMMANDS). I agree it could be interesting to add it. In other words, if nobody disagrees, I'll add it although I see how this will make the output grow a lot. I found parsing of compiler commands non-trivial: It gets messy when some file gets built twice, especially when different defines, etc. are set at the different times. E.g. once it is built with -DENABLE_TEST by some unit test and once it is built without any flags by the normal application. 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 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 Wed, Mar 11, 2015 at 3:15 PM, Ben Boeckel ben.boec...@kitware.com wrote: On Tue, Mar 10, 2015 at 01:25:16 +0100, Aleix Pol wrote: output : /home/kde-devel/tmp/llvm/build/lib/libLLVMPowerPCInfo.a, Can this be a list? It's 1 output per target, no? Not on Windows with .dll and .lib splits. So it needs to be a list:-) 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 ignore it, on the other hand I'm quite a n00b when it comes to cmake codebase and internals. I'm sure if somebody knows where to get that information, he is reading this mailing list. (hello) CMake has options for RPATH for the relevant platforms. By default, binaries have the RPATH set for the build tree. Relevant CMake target properties (there are variables to set default values as well): - BUILD_WITH_INSTALL_RPATH - SKIP_BUILD_RPATH Without SKIP_BUILD_RPATH set, LD_LIBRARY_PATH should not be necessary for running targets. We try hard to have Creator do the right thing, not usually do the right thing. That may sound arrogant, but it is simply that we found that devs are highly suspicious folks: If something is not absolutely reliable they won't use it:-) Setting LD_LIBRARY_PATH will not hurt, even when unneeded, will it? So we should set it, just in case somebody tries to shoot himself into the foot by setting SKIP_BUILD_RPATH:-) 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 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,
On Tue, Mar 10, 2015 at 1:25 AM, Aleix Pol aleix...@kde.org wrote:
Thank you for taking some of your time.
Thank you for doing the work:-)
On Sat, Mar 7, 2015 at 11:46 AM, Tobias Hunger tobias.hun...@gmail.com
wrote:
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.
I can look into that, I can see if I can extract the projects tree
somehow and dispose them like it's doing with the targets.
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)?
The sources are listed within the targets, separately for each
configuration (as you can have different sources for debug builds and
release).
No, which source directory was this created from? How was this build
configured (e.g. which compiler is used, which Qt version does it link
to, that kind of thing).
For qmake projects you can point to some directories that you built
when loading a project and that build is then imported into Qt
Creator. That is rather convenient as it can save a lot of time
rebuilding stuff just to make the IDE happy:-)
For that we need to sanity check: Is this indeed a build-directory of
the project we are opening? Which Kit (== configuration) was used to
generate that build?
Regarding ninja/make, in KDevelop we just check if there's a
rules.ninja file or a Makefile. Alternatively you can also check the
CMAKE_GENERATOR value in the CMakeCache.txt. Or we can introduce it if
you find it useful. I don't have a strong opinion there.
My -- maybe naive -- hope is that I can integrate cmake into an IDE
*without looking outside this json-file*.
I do not want to figure out which files are generated by which
generators, how those are structured internally or under which set of
conditions they may or may not be generated:-) Basically the less the
IDE needs to know about the cmake implementation (outside of the IDE
integration file) the more robust the support can be.
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, ... ]
What does that tell me? That file is even in the build directory, so
it is most likely not the CMakeLists.txt you built. There are also
more than one CMakeLists.txt in that file, so which one is the one?
And there is no hint as to how the project is configured... That is
probably available in CMakeCache.txt, but again, ideally I would not
need to know about that file.
configs :
[
{
name : ,
Why is the name empty?
Because it was built without specifying any name. (i.e. it didn't pass
-DCMAKE_BUILD_TYPE=...).
There is no default for CMAKE_BUILD_TYPE?
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?
I looked into how the CodeBlocks did it to provide the header files.
It's just brute-forcing to see if the file renamed to *.h/*.hpp/*.hxx
is present.
CMake doesn't have this kind of information, so I think it's better
that the IDE's do the hacky parts than cmake.
A list of *all* headers used during the building of the target would
be fine. There is no need to filter that list down in any way.
CMake has that information: Without it cmake could not possibly know
when a cpp file needs rebuilding. It would not be as successful a
build system when it did not know that:-)
Also we don't really have information about where to put them. You can
use the minimum common denominator among the sources I guess.
I don't understand that part, sorry.
}
],
installed : true,
I guess this means make install will install it. Where will this file end
up?
Yes. I tried to figure it out but didn't manage to find the correct
way to query it. I can try harder. :D
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?
It's important in case the output path is overriden, see last e-mail
by Alexander Neundorf.
type : STATIC_LIBRARY
Which types are possible here?
It's an enum internal to cmake. At the moment:
EXECUTABLE, STATIC_LIBRARY, SHARED_LIBRARY, MODULE_LIBRARY,
OBJECT_LIBRARY, UTILITY, GLOBAL_TARGET, INTERFACE_LIBRARY,
UNKNOWN_LIBRARY.
},
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
Re: [cmake-developers] Extracting target metadata, IDE integration
On Tue, Mar 10, 2015 at 01:25:16 +0100, Aleix Pol wrote: output : /home/kde-devel/tmp/llvm/build/lib/libLLVMPowerPCInfo.a, Can this be a list? It's 1 output per target, no? Not on Windows with .dll and .lib splits. 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? I looked into how the CodeBlocks did it to provide the header files. It's just brute-forcing to see if the file renamed to *.h/*.hpp/*.hxx is present. CMake doesn't have this kind of information, so I think it's better that the IDE's do the hacky parts than cmake. Also we don't really have information about where to put them. You can use the minimum common denominator among the sources I guess. There's the source_group() command which could be changed to affect this as well. 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 ignore it, on the other hand I'm quite a n00b when it comes to cmake codebase and internals. I'm sure if somebody knows where to get that information, he is reading this mailing list. (hello) CMake has options for RPATH for the relevant platforms. By default, binaries have the RPATH set for the build tree. Relevant CMake target properties (there are variables to set default values as well): - BUILD_WITH_INSTALL_RPATH - SKIP_BUILD_RPATH Without SKIP_BUILD_RPATH set, LD_LIBRARY_PATH should not be necessary for running targets. --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
Re: [cmake-developers] Extracting target metadata, IDE integration
Aleix Pol wrote: I just pushed my change into a github clone for easier testing and reviewing. https://github.com/aleixpol/CMake Hi Aleix, Thanks for your efforts. Here are some things that are required before a feature like this can be committed to the cmake repo: * Discuss the feature with collaborators on the mailing list. * Design the feature. Determine at least the following: * Target use cases * How files are produced * What files are produced * Features required by various tools and IDEs * What is in the files * What is not in the files * Why ^ * Write documentation describing the file format and how to consume it. * More exact unit testing * Unit testing for 'interesting' cases. * Implement the feature satisfying the design for all of the targets IDEs and all relevant features of CMake. * Testing with existing third party cmake-using projects. All of the above must be done before cmake can accept a branch implementing metadata generation. Because this is important to get right, and because it requires up-to-date knowledge of the current cmake implementation and features in the master branch, I'm going to take over the 'ownership' of this feature and drive it myself. I'll start soon by creating a new mailing list thread to determine the design of the feature in collaboration with you, Tobias and Anton. We can iterate on the design, tests and implementation until it is complete. 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
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
Re: [cmake-developers] Extracting target metadata, IDE integration
On Wed, Mar 4, 2015 at 9:05 PM, Brad King brad.k...@kitware.com wrote: On 03/02/2015 09:10 PM, Aleix Pol wrote: I created a new version of the patch: http://proli.net/meu/kdevelop/0001-cmake-Add-option-to-generate-target-metadata-for-IDE-v2.patch Thanks. Samples: LLVM: https://paste.kde.org/pelr1ditp A small random KDE project: https://paste.kde.org/pgkbecv5p The location values need to be inside the configs elements because they can vary with the configuration in multi-config generators. Also the name location may not be specific enough. Some targets may have multiple output files (e.g. .dll, .lib). See the breakdown of $TARGET*FILE:... generator expressions: http://www.cmake.org/cmake/help/v3.2/manual/cmake-generator-expressions.7.html#informational-expressions Some set of values like that will be more useful. Good point, I changed it to use $TARGET_FILE:tgt. Showing a directory didn't make much sense anyway as we have more information with the full file path. If the the directory value is GetCurrentOutputDirectory, the build tree location of the project file, then that does not need to be per-configuration. In that case perhaps the name should be something like build_directory or project_directory. Used output_directory to match internal cmake naming. https://paste.kde.org/p5ogjqi2n https://paste.kde.org/puzgrgkzy And the new version of the patch (sorry my hosting seems down and I can't connect). https://paste.kde.org/pq0xungvq 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
Re: [cmake-developers] Extracting target metadata, IDE integration
On 03/02/2015 09:10 PM, Aleix Pol wrote: I created a new version of the patch: http://proli.net/meu/kdevelop/0001-cmake-Add-option-to-generate-target-metadata-for-IDE-v2.patch Thanks. Samples: LLVM: https://paste.kde.org/pelr1ditp A small random KDE project: https://paste.kde.org/pgkbecv5p The location values need to be inside the configs elements because they can vary with the configuration in multi-config generators. Also the name location may not be specific enough. Some targets may have multiple output files (e.g. .dll, .lib). See the breakdown of $TARGET*FILE:... generator expressions: http://www.cmake.org/cmake/help/v3.2/manual/cmake-generator-expressions.7.html#informational-expressions Some set of values like that will be more useful. If the the directory value is GetCurrentOutputDirectory, the build tree location of the project file, then that does not need to be per-configuration. In that case perhaps the name should be something like build_directory or project_directory. Thanks, -Brad -- 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 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 created a new version of the patch: http://proli.net/meu/kdevelop/0001-cmake-Add-option-to-generate-target-metadata-for-IDE-v2.patch Main differences are: * Uses JsonCpp to generate json (makes the code much easier to read!). * Adds a CMAKE_EXPORT_PROJECT_METADATA.rst file for documentation. * Adds a test that checks some of the parameters in the file. * Uses for directory the directory where the target was generated rather than the output directory. I hope this helps. Aleix Samples: LLVM: https://paste.kde.org/pelr1ditp A small random KDE project: https://paste.kde.org/pgkbecv5p -- 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 Sat, Feb 14, 2015 at 1:02 PM, Stephen Kelly steve...@gmail.com wrote: Aleix Pol wrote: Hi guys, It's been since August with this. I understand we're all busy but this step is important for KDevelop as well as for other IDE's and I wouldn't like this to rot. Please, let's keep it moving forward. As far as I'm aware, it needs to move forward from this point: http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/focus=12151 I'm not certain the design is finished (eg what the file should contain now or eventually). I asked for tests/documentation as a way to trigger getting the design finished. Having either would give us a list of use-cases and we would know what's in scope and what's not in scope (eg whether compile options/link options are in scope and why). I can look further into documentation, if that's what holding us back. Another question: do you have any opinion about whether this should be one global file or one file per directory? I don't know - it seems like something that might or might not be relevant for tooling. Is the size of the generated file a consideration? I think the best is to have it all in 1 directory. You don't really want to have watchers on many files over there. How well does this feature work with large projects like VTK or a combined build of LLVM/Clang/lldb/libcxx/other ll projects. I just generated the file for LLVM: https://paste.kde.org/pxl8ozwah It's a 127KiB file, I don't think it's too mental considering it's a 330 MiB repository. 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
Re: [cmake-developers] Extracting target metadata, IDE integration
On Monday, February 16, 2015 21:31:45 Aleix Pol wrote:
On Sat, Feb 14, 2015 at 1:02 PM, Stephen Kelly steve...@gmail.com wrote:
Aleix Pol wrote:
Hi guys,
It's been since August with this. I understand we're all busy but this
step is important for KDevelop as well as for other IDE's and I
wouldn't like this to rot.
Please, let's keep it moving forward.
As far as I'm aware, it needs to move forward from this point:
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/fo
cus=12151
I'm not certain the design is finished (eg what the file should contain
now
or eventually). I asked for tests/documentation as a way to trigger
getting
the design finished. Having either would give us a list of use-cases and
we
would know what's in scope and what's not in scope (eg whether compile
options/link options are in scope and why).
I can look further into documentation, if that's what holding us back.
Another question: do you have any opinion about whether this should be one
global file or one file per directory? I don't know - it seems like
something that might or might not be relevant for tooling. Is the size of
the generated file a consideration?
I think the best is to have it all in 1 directory. You don't really
want to have watchers on many files over there.
How well does this feature work with large projects like VTK or a combined
build of LLVM/Clang/lldb/libcxx/other ll projects.
I just generated the file for LLVM: https://paste.kde.org/pxl8ozwah
It's a 127KiB file, I don't think it's too mental considering it's a
330 MiB repository.
I didn't follow the whole thread, just a few quick questions from looking at
the file:
{
name: obj2yaml,
type: EXECUTABLE,
configs: [
],
directory: /home/kde-devel/tmp/llvm/build/bin,
location: /home/kde-devel/tmp/llvm/build/bin/obj2yaml,
backtrace: [/home/kde-devel/tmp/llvm/cmake/modules/AddLLVM.cmake:452,
/home/kde-devel/tmp/llvm/cmake/modules/AddLLVM.cmake:485,
/home/kde-devel/tmp/llvm/tools/obj2yaml/CMakeLists.txt:6],
installed: true
},
I guess name is the name of the target, type, configs, location, backtrace
and installed seem to be clear.
What about directory ?
This is not the build dir where the target is defined (i.e.
cmake_binary_dir(llvm/tools/obj2yaml/), is it ?
This directory would seem useful to me, e.g. you can run make help there to
get the list of targets to compile/assemble/preprocess the files for that
target. Or you can run the clean-script for that target.
Alex
--
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
Aleix Pol wrote: Hi guys, It's been since August with this. I understand we're all busy but this step is important for KDevelop as well as for other IDE's and I wouldn't like this to rot. Please, let's keep it moving forward. As far as I'm aware, it needs to move forward from this point: http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/focus=12151 I'm not certain the design is finished (eg what the file should contain now or eventually). I asked for tests/documentation as a way to trigger getting the design finished. Having either would give us a list of use-cases and we would know what's in scope and what's not in scope (eg whether compile options/link options are in scope and why). Another question: do you have any opinion about whether this should be one global file or one file per directory? I don't know - it seems like something that might or might not be relevant for tooling. Is the size of the generated file a consideration? How well does this feature work with large projects like VTK or a combined build of LLVM/Clang/lldb/libcxx/other ll projects. 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
Re: [cmake-developers] Extracting target metadata, IDE integration
On Thu, Feb 5, 2015 at 6:03 PM, Aleix Pol aleix...@kde.org wrote:
On Mon, Feb 2, 2015 at 5:36 PM, Aleix Pol aleix...@kde.org wrote:
On Mon, Jan 26, 2015 at 9:15 PM, Tobias Hunger tobias.hun...@gmail.com
wrote:
I gave this patch a try with the cmake project data.
I had hoped that this file would contain all the information an IDE
might need, but there seems quite a bit missing for that. E.g. there
is no information on which files are used to build a target. What am I
missing?
Best Regards,
Tobias
On Mon, Jan 26, 2015 at 4:23 PM, Brad King brad.k...@kitware.com wrote:
On 01/25/2015 08:26 AM, Tobias Hunger wrote:
I just had a bit of time to play with cmake this weekend: Is this
patch available somewhere by now?
Aleix sent it in a message of this thread on 2015-01-09:
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/focus=12061
Some review comments elsewhere in this thread are still pending.
-Brad
It does provide them. For example [1].
Isn't that what you meant?
Aleix
[1]
{
name: kdevcmakebuilder,
type: MODULE_LIBRARY,
configs: [
{
name: debug,
sources: [
/home/kde-devel/frameworks/kdevelop/projectbuilders/cmakebuilder/cmakebuilder.cpp,
/home/kde-devel/frameworks/kdevelop/projectbuilders/cmakebuilder/cmakejob.cpp,
/home/kde-devel/frameworks/kdevelop/projectbuilders/cmakebuilder/prunejob.cpp,
/home/kde-devel/frameworks/kdevelop/projectbuilders/cmakebuilder/cmakebuilderpreferences.cpp,
/home/kde-devel/build-frameworks/kdevelop/projectbuilders/cmakebuilder/ui_cmakebuildersettings.h,
/home/kde-devel/build-frameworks/kdevelop/projectbuilders/cmakebuilder/cmakebuilderconfig.cpp,
/home/kde-devel/build-frameworks/kdevelop/projectbuilders/cmakebuilder/cmakebuilderconfig.h,
/home/kde-devel/build-frameworks/kdevelop/projectbuilders/cmakebuilder/kdevcmakebuilder_automoc.cpp,
/home/kde-devel/frameworks/kdevelop/projectbuilders/cmakebuilder/cmakebuildersettings.ui,
/home/kde-devel/frameworks/kdevelop/projectbuilders/cmakebuilder/cmakebuilderconfig.kcfgc
]
}
],
directory:
/home/kde-devel/build-frameworks/kdevelop/projectbuilders/cmakebuilder,
location:
/home/kde-devel/build-frameworks/kdevelop/projectbuilders/cmakebuilder/kdevcmakebuilder.so,
backtrace:
[/home/kde-devel/frameworks/kdevelop/projectbuilders/cmakebuilder/CMakeLists.txt:20],
installed: true
}
Bump?
Aleix
Hi guys,
It's been since August with this. I understand we're all busy but this
step is important for KDevelop as well as for other IDE's and I
wouldn't like this to rot.
Please, let's keep it moving forward.
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
Re: [cmake-developers] Extracting target metadata, IDE integration
On Mon, Feb 2, 2015 at 5:36 PM, Aleix Pol aleix...@kde.org wrote:
On Mon, Jan 26, 2015 at 9:15 PM, Tobias Hunger tobias.hun...@gmail.com
wrote:
I gave this patch a try with the cmake project data.
I had hoped that this file would contain all the information an IDE
might need, but there seems quite a bit missing for that. E.g. there
is no information on which files are used to build a target. What am I
missing?
Best Regards,
Tobias
On Mon, Jan 26, 2015 at 4:23 PM, Brad King brad.k...@kitware.com wrote:
On 01/25/2015 08:26 AM, Tobias Hunger wrote:
I just had a bit of time to play with cmake this weekend: Is this
patch available somewhere by now?
Aleix sent it in a message of this thread on 2015-01-09:
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/focus=12061
Some review comments elsewhere in this thread are still pending.
-Brad
It does provide them. For example [1].
Isn't that what you meant?
Aleix
[1]
{
name: kdevcmakebuilder,
type: MODULE_LIBRARY,
configs: [
{
name: debug,
sources: [
/home/kde-devel/frameworks/kdevelop/projectbuilders/cmakebuilder/cmakebuilder.cpp,
/home/kde-devel/frameworks/kdevelop/projectbuilders/cmakebuilder/cmakejob.cpp,
/home/kde-devel/frameworks/kdevelop/projectbuilders/cmakebuilder/prunejob.cpp,
/home/kde-devel/frameworks/kdevelop/projectbuilders/cmakebuilder/cmakebuilderpreferences.cpp,
/home/kde-devel/build-frameworks/kdevelop/projectbuilders/cmakebuilder/ui_cmakebuildersettings.h,
/home/kde-devel/build-frameworks/kdevelop/projectbuilders/cmakebuilder/cmakebuilderconfig.cpp,
/home/kde-devel/build-frameworks/kdevelop/projectbuilders/cmakebuilder/cmakebuilderconfig.h,
/home/kde-devel/build-frameworks/kdevelop/projectbuilders/cmakebuilder/kdevcmakebuilder_automoc.cpp,
/home/kde-devel/frameworks/kdevelop/projectbuilders/cmakebuilder/cmakebuildersettings.ui,
/home/kde-devel/frameworks/kdevelop/projectbuilders/cmakebuilder/cmakebuilderconfig.kcfgc
]
}
],
directory:
/home/kde-devel/build-frameworks/kdevelop/projectbuilders/cmakebuilder,
location:
/home/kde-devel/build-frameworks/kdevelop/projectbuilders/cmakebuilder/kdevcmakebuilder.so,
backtrace:
[/home/kde-devel/frameworks/kdevelop/projectbuilders/cmakebuilder/CMakeLists.txt:20],
installed: true
}
Bump?
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
Re: [cmake-developers] Extracting target metadata, IDE integration
On Mon, Jan 26, 2015 at 9:15 PM, Tobias Hunger tobias.hun...@gmail.com wrote:
I gave this patch a try with the cmake project data.
I had hoped that this file would contain all the information an IDE
might need, but there seems quite a bit missing for that. E.g. there
is no information on which files are used to build a target. What am I
missing?
Best Regards,
Tobias
On Mon, Jan 26, 2015 at 4:23 PM, Brad King brad.k...@kitware.com wrote:
On 01/25/2015 08:26 AM, Tobias Hunger wrote:
I just had a bit of time to play with cmake this weekend: Is this
patch available somewhere by now?
Aleix sent it in a message of this thread on 2015-01-09:
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/focus=12061
Some review comments elsewhere in this thread are still pending.
-Brad
It does provide them. For example [1].
Isn't that what you meant?
Aleix
[1]
{
name: kdevcmakebuilder,
type: MODULE_LIBRARY,
configs: [
{
name: debug,
sources: [
/home/kde-devel/frameworks/kdevelop/projectbuilders/cmakebuilder/cmakebuilder.cpp,
/home/kde-devel/frameworks/kdevelop/projectbuilders/cmakebuilder/cmakejob.cpp,
/home/kde-devel/frameworks/kdevelop/projectbuilders/cmakebuilder/prunejob.cpp,
/home/kde-devel/frameworks/kdevelop/projectbuilders/cmakebuilder/cmakebuilderpreferences.cpp,
/home/kde-devel/build-frameworks/kdevelop/projectbuilders/cmakebuilder/ui_cmakebuildersettings.h,
/home/kde-devel/build-frameworks/kdevelop/projectbuilders/cmakebuilder/cmakebuilderconfig.cpp,
/home/kde-devel/build-frameworks/kdevelop/projectbuilders/cmakebuilder/cmakebuilderconfig.h,
/home/kde-devel/build-frameworks/kdevelop/projectbuilders/cmakebuilder/kdevcmakebuilder_automoc.cpp,
/home/kde-devel/frameworks/kdevelop/projectbuilders/cmakebuilder/cmakebuildersettings.ui,
/home/kde-devel/frameworks/kdevelop/projectbuilders/cmakebuilder/cmakebuilderconfig.kcfgc
]
}
],
directory:
/home/kde-devel/build-frameworks/kdevelop/projectbuilders/cmakebuilder,
location:
/home/kde-devel/build-frameworks/kdevelop/projectbuilders/cmakebuilder/kdevcmakebuilder.so,
backtrace:
[/home/kde-devel/frameworks/kdevelop/projectbuilders/cmakebuilder/CMakeLists.txt:20],
installed: true
}
--
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 01/25/2015 08:26 AM, Tobias Hunger wrote: I just had a bit of time to play with cmake this weekend: Is this patch available somewhere by now? Aleix sent it in a message of this thread on 2015-01-09: http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/focus=12061 Some review comments elsewhere in this thread are still pending. -Brad -- 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
I gave this patch a try with the cmake project data. I had hoped that this file would contain all the information an IDE might need, but there seems quite a bit missing for that. E.g. there is no information on which files are used to build a target. What am I missing? Best Regards, Tobias On Mon, Jan 26, 2015 at 4:23 PM, Brad King brad.k...@kitware.com wrote: On 01/25/2015 08:26 AM, Tobias Hunger wrote: I just had a bit of time to play with cmake this weekend: Is this patch available somewhere by now? Aleix sent it in a message of this thread on 2015-01-09: http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/focus=12061 Some review comments elsewhere in this thread are still pending. -Brad -- 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 Everybody, I just had a bit of time to play with cmake this weekend: Is this patch available somewhere by now? Best Regards, Tobias On Sat, Jan 10, 2015 at 7:23 PM, Stephen Kelly steve...@gmail.com wrote: Aleix Pol wrote: I'll attach it in this e-mail, to make sure it reaches. PS: there's no changes system for cmake like reviewboard, is there? Nope, review is communicated on the mailing list, but if you want you can push the patch on a branch in a public repo. It could be more convenient. 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 -- 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 12/18/2014 09:02 PM, Aleix Pol wrote: I would like to propose this as a final version of this patch. http://proli.net/meu/kdevelop/0001-cmake-Add-option-to-generate-target-metadata-for-IDE.patch For reference, this was also attached in a later message of this thread on 2015-01-09: http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/focus=12061 I have a working proof of concept in KDevelop already I'm quite happy with. Can you post a link to that implementation so others may try it? Steve K. posted a review of your patch on 2014-12-19: http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/focus=11972 that has not yet received a response. Also, for unrelated reasons we've now added JsonCpp into the CMake build process. You could consider using that to write the .json file so that no manual formatting or escaping code is needed. The current patch does not add potentially needed json escapes. Thanks, -Brad -- 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 Tue, Jan 20, 2015 at 3:47 PM, Brad King brad.k...@kitware.com wrote: On 12/18/2014 09:02 PM, Aleix Pol wrote: I would like to propose this as a final version of this patch. http://proli.net/meu/kdevelop/0001-cmake-Add-option-to-generate-target-metadata-for-IDE.patch For reference, this was also attached in a later message of this thread on 2015-01-09: http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/focus=12061 I have a working proof of concept in KDevelop already I'm quite happy with. Can you post a link to that implementation so others may try it? It can be found by: git clone git://anongit.kde.org/kdevelop -b cmakePossibleTargetsFile https://projects.kde.org/projects/extragear/kdevelop/kdevelop/repository/show?rev=cmakePossibleTargetsFile Steve K. posted a review of your patch on 2014-12-19: http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/focus=11972 that has not yet received a response. Will look into these tonight. Also, for unrelated reasons we've now added JsonCpp into the CMake build process. You could consider using that to write the .json file so that no manual formatting or escaping code is needed. The current patch does not add potentially needed json escapes. I will consider to. 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
Re: [cmake-developers] Extracting target metadata, IDE integration
Aleix Pol wrote: I'll attach it in this e-mail, to make sure it reaches. PS: there's no changes system for cmake like reviewboard, is there? Nope, review is communicated on the mailing list, but if you want you can push the patch on a branch in a public repo. It could be more convenient. 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
Re: [cmake-developers] Extracting target metadata, IDE integration
On Thu, Jan 8, 2015 at 5:42 PM, Anton Makeev anton.mak...@jetbrains.com wrote:
Aleix Pol aleixpol@... writes:
I'd really appreciate your feedback on the patch I provided, I'll be
happy to provide the information you miss.
Aleix
Aleix, could you please point me to the most recent patch version?
--
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
I'll attach it in this e-mail, to make sure it reaches.
Aleix
PS: there's no changes system for cmake like reviewboard, is there?
From 806d6788ca93b5dbd0dc6e25947c07f149f64a38 Mon Sep 17 00:00:00 2001
From: Aleix Pol aleix...@kde.org
Date: Mon, 6 Oct 2014 17:35:31 +0200
Subject: [PATCH] cmake: Add option to generate target metadata for IDEs
Create a CMAKE_EXPORT_PROJECT_METADATA option that can be used to enable
generation of a 'ProjectTargets.json' file. Write into the file a JSON
description of the build targets that an IDE might load.
---
Modules/CMakeGenericSystem.cmake | 5 ++
Source/cmGlobalGenerator.cxx | 133 ++-
Source/cmGlobalGenerator.h | 1 +
3 files changed, 137 insertions(+), 2 deletions(-)
diff --git a/Modules/CMakeGenericSystem.cmake b/Modules/CMakeGenericSystem.cmake
index 8a14aea..0e7f48a 100644
--- a/Modules/CMakeGenericSystem.cmake
+++ b/Modules/CMakeGenericSystem.cmake
@@ -67,6 +67,11 @@ if(CMAKE_GENERATOR MATCHES Ninja)
mark_as_advanced(CMAKE_EXPORT_COMPILE_COMMANDS)
endif()
+set(CMAKE_EXPORT_PROJECT_METADATA CACHE STRING
+Enables the output of a ProjectTargets.json file during generation when a version is provided.
+)
+mark_as_advanced(CMAKE_EXPORT_PROJECT_METADATA)
+
# GetDefaultWindowsPrefixBase
#
# Compute the base directory for CMAKE_INSTALL_PREFIX based on:
diff --git a/Source/cmGlobalGenerator.cxx b/Source/cmGlobalGenerator.cxx
index dd7fbc8..7fef858 100644
--- a/Source/cmGlobalGenerator.cxx
+++ b/Source/cmGlobalGenerator.cxx
@@ -2899,6 +2899,7 @@ void cmGlobalGenerator::WriteRuleHashes(std::string const pfile)
}
//
+
void cmGlobalGenerator::WriteSummary()
{
cmMakefile* mf = this-LocalGenerators[0]-GetMakefile();
@@ -2908,8 +2909,6 @@ void cmGlobalGenerator::WriteSummary()
fname += cmake::GetCMakeFilesDirectory();
fname += /TargetDirectories.txt;
cmGeneratedFileStream fout(fname.c_str());
-
- // Generate summary information files for each target.
for(TargetMap::const_iterator ti =
this-TotalTargets.begin(); ti != this-TotalTargets.end(); ++ti)
{
@@ -2920,6 +2919,136 @@ void cmGlobalGenerator::WriteSummary()
this-WriteSummary(ti-second);
fout ti-second-GetSupportDirectory() \n;
}
+
+ const char* version = mf-GetDefinition(CMAKE_EXPORT_PROJECT_METADATA);
+ if(version *version)
+{
+ if (std::string(version) == 1.0)
+WriteProjectTargetsJson();
+ else
+cmSystemTools::Error(
+ Generator implementation error,
+ Unknown export metadata version.);
+}
+}
+
+void printBacktraceJson(const cmListFileBacktrace bt, cmGeneratedFileStream stream)
+{
+ stream '[';
+ for(cmListFileBacktrace::const_iterator it = bt.begin(); it!=bt.end(); ++it)
+{
+ const cmListFileContext ctx = *it;
+
+ if(it!=bt.begin())
+stream , ;
+
+ stream '\';
+ stream ctx.FilePath;
+ stream ':';
+ stream ctx.Line;
+ stream '\';
+}
+ stream ']';
+}
+
+void cmGlobalGenerator::WriteProjectTargetsJson()
+{
+ cmMakefile* mf = this-LocalGenerators[0]-GetMakefile();
+ std::string projectTargetsPath = mf-GetHomeOutputDirectory();
+ projectTargetsPath += /ProjectTargets.json;
+ cmGeneratedFileStream aout(projectTargetsPath.c_str());
+ aout
+{\n
+ \version\: \ cmVersion::GetCMakeVersion() \,\n
+ \dependencies\: [\n
+;
+
+ for(std::vectorcmLocalGenerator*::const_iterator i =
+this-LocalGenerators.begin(); i != this-LocalGenerators.end(); ++i)
+{
+std::vectorstd::string const lf = (*i)-GetMakefile()-GetListFiles();
+for(std::vectorstd::string::const_iterator fi = lf.begin();
+fi != lf.end(); ++fi)
+ {
+ bool last = (fi+1) == lf.end() (i+1) == this-LocalGenerators.end();
+ aout \ *fi (last ? \\n : \,\n);
+ }
+}
+ aout
+ ],\n
+ \targets\: [\n
+;
+
+ // Generate summary
Re: [cmake-developers] Extracting target metadata, IDE integration
Aleix Pol aleixpol@... writes: I'd really appreciate your feedback on the patch I provided, I'll be happy to provide the information you miss. Aleix Aleix, could you please point me to the most recent patch version? -- 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 Tuesday, December 23, 2014 01:30:58 Aleix Pol wrote: On Thu, Sep 25, 2014 at 9:14 AM, Anton Makeev ... * No progress indication. Since the generation may take several minutes, providing feedback is crucial. I never found such case, I would argue that a project which has a cmake script that takes several minutes is broken, but maybe we can open a thread to discuss it? On network file systems things can get slow... (even if the file system feels really fast in general usage, i.e. has high data throuhgput). ... * Not sure if it’s possible at all - a lightweight phase where CMake only collects necessary information (list of files/targets, compiler settings). This will help IDE react to the changes much faster. That would be extra-cool, agreed. Maybe it's an iteration we can consider in the future. Yes, this would be cool, but until now whenever I thought about this my conclusion was that this is unfortunately not possible, since the targets/files/etc. can depend on anything, if() clauses, execution of commands, results of find_package(), etc. Alex -- 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 2014-12-22 19:30, Aleix Pol wrote: On Thu, Sep 25, 2014 at 9:14 AM, Anton Makeev wrote: * No progress indication. Since the generation may take several minutes, providing feedback is crucial. I never found such case, ParaView. (To a lesser extent, VTK.) I would argue that a project which has a cmake script that takes several minutes is broken, but maybe we can open a thread to discuss it? Well, yes, one might argue that :-). * When there are existing in-source generated files in the project dir, CMake doesn't allow generating into a separate out-of-source folder. An IDE has to invent workarounds here. Arguably, in-source generation is broken by definition... Also, because CMake allows either a source OR BUILD directory to be given, such a configuration is almost certainly doomed. IMO, trying to do an out-of-source build of a source directory that already contains an in-source build *is* broken (i.e. no arguably about it)... and so is an IDE trying to work around such situation. At most, detect the situation and nicely report the problem to the user. -- Matthew -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Extracting target metadata, IDE integration
On Thu, Sep 25, 2014 at 9:14 AM, Anton Makeev anton.mak...@jetbrains.com wrote: Hey everyone, We are developing CLion at JetBrains that utilizes CMake as its main project model. Stephen Kelly timely drew our attention to this discussion, and I’d like to share some thoughts. Here are the general ones and I’ll also comment on separate messages in the thread. We’ve managed to get almost all the necessary project information, using ‘GNU/MinGW Makefiles’ generators: * list of targets comes from 'CMakeFiles/TargetDirectories.txt' * list of source files from ‘CMakeFiles/A.dir/DependInfo.cmake’ * list of headers and resources from ‘codeblocks.cbp’ file * per-file/target compiler and its flags from ‘CMakeFiles/Target.dir/flags.make’ * location of product files from ‘CMakeFiles/Target.dir/build.make’ What we miss (not all of them are directly related the targets metadata, but I'd like to share anyway since the topic is about IDE integration): * Location of every source file and target in CMakeLists - it would greatly help to refactorings, navigation etc. In the implementation I'm proposing, the target is specified. The file is hard to figure out given that it's passed as a string argument and it could come virtually from anywhere (i.e. glob, operations, a set() somewhere else, etc.). My conclusion is that knowing the target position is already a good enough help. * Complete list of headers and resource files - they are only listed in special generators like code blocks. I'll look into it, what do you need exactly? The headers in each target? * An easily parseable list of errors and warnings with origin information. At the moment we parse error output but not everything can be parsed reliably. Agreed, It's something we're missing as well. I also don't really like the fact that sometimes the paths are absolute and sometimes they're relative, especially in the relative case, since it's hard to tell if it's relative to the build directory or source directory. * No progress indication. Since the generation may take several minutes, providing feedback is crucial. I never found such case, I would argue that a project which has a cmake script that takes several minutes is broken, but maybe we can open a thread to discuss it? * Ability to distinguish a library from an executable target. This will help to offer a better UI for run/debug configurations. It's included in the proposed implementation. * Possibility to collect information for every build target in one run. Currently, we have to invoke generator for every CMAKE_BUILT_TYPE separately. Well, that's because you use CodeBlocks generators. It seems like for example in MSVC they generate many build configurations at once. This implementation supports having parallel debug/release builds. Then we can fix make/ninja generators or even create new ones. * CMake stops processing when it find a missing file, so that IDE cannot have full project model, until this files is created. Well, it's related to the error generation issue we discussed. I think it's something we should discuss in parallel. * When there are existing in-source generated files in the project dir, CMake doesn't allow generating into a separate out-of-source folder. An IDE has to invent workarounds here. Arguably, in-source generation is broken by definition... * Not sure if it’s possible at all - a lightweight phase where CMake only collects necessary information (list of files/targets, compiler settings). This will help IDE react to the changes much faster. That would be extra-cool, agreed. Maybe it's an iteration we can consider in the future. Here is why I think the discussed functionality should not be a separate generator: CLion doesn’t have it’s own project model nor is intended as build tool replacement. Currently, the only option for CLion users is makefiles build, that is not a best option for everyone: there is a good and fast alternative ‘Ninja’. Ideally, users should be able to choose whatever tool better suites them. The problem is that the generated Makefiles are used both, for internal needs, like reading project structure, and also to build and run the user’s program. If we wanted to support Ninja generator, we would need to rewrite all the logic that retrieves the project information, using the files that are created by Ninja generator. While I suppose it’s possible, it’s not the best option - very error prone and resource demanding. If CMake generated a separate descriptor, regardless the generator used (Makefiles, Ninja), it would be much easier to support; and the users will benefit from better, more reliable and faster CMake integration in an IDE. I'd really appreciate your feedback on the patch I provided, I'll be happy to provide the information you miss. Aleix -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at:
Re: [cmake-developers] Extracting target metadata, IDE integration
On Tue, Dec 23, 2014 at 1:30 AM, Aleix Pol aleix...@kde.org wrote: On Thu, Sep 25, 2014 at 9:14 AM, Anton Makeev anton.mak...@jetbrains.com wrote: Hey everyone, We are developing CLion at JetBrains that utilizes CMake as its main project model. Stephen Kelly timely drew our attention to this discussion, and I’d like to share some thoughts. Here are the general ones and I’ll also comment on separate messages in the thread. We’ve managed to get almost all the necessary project information, using ‘GNU/MinGW Makefiles’ generators: * list of targets comes from 'CMakeFiles/TargetDirectories.txt' * list of source files from ‘CMakeFiles/A.dir/DependInfo.cmake’ * list of headers and resources from ‘codeblocks.cbp’ file * per-file/target compiler and its flags from ‘CMakeFiles/Target.dir/flags.make’ * location of product files from ‘CMakeFiles/Target.dir/build.make’ What we miss (not all of them are directly related the targets metadata, but I'd like to share anyway since the topic is about IDE integration): * Location of every source file and target in CMakeLists - it would greatly help to refactorings, navigation etc. In the implementation I'm proposing, the target is specified. The file is hard to figure out given that it's passed as a string argument and it could come virtually from anywhere (i.e. glob, operations, a set() somewhere else, etc.). My conclusion is that knowing the target position is already a good enough help. * Complete list of headers and resource files - they are only listed in special generators like code blocks. I'll look into it, what do you need exactly? The headers in each target? * An easily parseable list of errors and warnings with origin information. At the moment we parse error output but not everything can be parsed reliably. Agreed, It's something we're missing as well. I also don't really like the fact that sometimes the paths are absolute and sometimes they're relative, especially in the relative case, since it's hard to tell if it's relative to the build directory or source directory. * No progress indication. Since the generation may take several minutes, providing feedback is crucial. I never found such case, I would argue that a project which has a cmake script that takes several minutes is broken, but maybe we can open a thread to discuss it? * Ability to distinguish a library from an executable target. This will help to offer a better UI for run/debug configurations. It's included in the proposed implementation. * Possibility to collect information for every build target in one run. Currently, we have to invoke generator for every CMAKE_BUILT_TYPE separately. Well, that's because you use CodeBlocks generators. It seems like for example in MSVC they generate many build configurations at once. This implementation supports having parallel debug/release builds. Then we can fix make/ninja generators or even create new ones. * CMake stops processing when it find a missing file, so that IDE cannot have full project model, until this files is created. Well, it's related to the error generation issue we discussed. I think it's something we should discuss in parallel. * When there are existing in-source generated files in the project dir, CMake doesn't allow generating into a separate out-of-source folder. An IDE has to invent workarounds here. Arguably, in-source generation is broken by definition... * Not sure if it’s possible at all - a lightweight phase where CMake only collects necessary information (list of files/targets, compiler settings). This will help IDE react to the changes much faster. That would be extra-cool, agreed. Maybe it's an iteration we can consider in the future. Here is why I think the discussed functionality should not be a separate generator: CLion doesn’t have it’s own project model nor is intended as build tool replacement. Currently, the only option for CLion users is makefiles build, that is not a best option for everyone: there is a good and fast alternative ‘Ninja’. Ideally, users should be able to choose whatever tool better suites them. The problem is that the generated Makefiles are used both, for internal needs, like reading project structure, and also to build and run the user’s program. If we wanted to support Ninja generator, we would need to rewrite all the logic that retrieves the project information, using the files that are created by Ninja generator. While I suppose it’s possible, it’s not the best option - very error prone and resource demanding. If CMake generated a separate descriptor, regardless the generator used (Makefiles, Ninja), it would be much easier to support; and the users will benefit from better, more reliable and faster CMake integration in an IDE. I'd really appreciate your feedback on the patch I provided, I'll be happy to provide the information you miss. Aleix By the way, I just
Re: [cmake-developers] Extracting target metadata, IDE integration
Hey Stephen,
On Sun, Oct 19, 2014 at 2:26 PM, Stephen Kelly steve...@gmail.com wrote:
No problem, thanks! I recently discovered that Creator makes fragile guesses
about source files and targets
https://codereview.qt-project.org/#/c/96594/1/src/plugins/cmakeprojectmanager/cmakeproject.cpp,unified
so I would really like to create a solution which makes that unnecessary.
I am no expert on this part of the codebase, but I would not be
surprised if it did do some stupid things when seeing cmake. We do not
support that too well.
On Mon, Sep 22, 2014 at 4:03 PM, Stephen Kelly
steve...@gmail.com wrote:
The first is should this be run in a terminal or is this a GUI. Not
sure whether cmake has that information.
CMake only knows whether the WIN32_EXECUTABLE property has been set on a
target.
http://www.cmake.org/cmake/help/v3.0/prop_tgt/WIN32_EXECUTABLE.html
The property is harmless on non-Windows, so KDE sets it on non-Windows
for gui applications IIRC, but others may not.
This is a hint only.
If it works correctly it is nice, otherwise the user will have to
toggle some checkbox
to change it to his or her liking.
Yes. I suppose beyond the WIN32_EXECUTABLE/ SUBSYSTEM:console / Mac Bundle
stuff the gui/console distinction doesn't really fit into the buildsystem.
Maybe such a checkbox, pre-populated with the hint, is needed anyway.
Not into a build system, but into an IDE:-)
There is a overlap in what an IDE needs to know and what a build
system then needs to generate binaries, but it both also need some
information the other does not provide.
But why not have groups of sources?
[
name: testc1
sourceGroups [
{
sources: [ foo.cpp ],
defines: [BUILD_TEST=1, QT_CORE_LIB, EXTRA_FOO=1],
includes: [/opt/bat/include, /usr/include/qt5]
},
{
sources: [ bar.cpp ],
defines: [BUILD_TEST=1, QT_CORE_LIB],
includes: [/opt/bat/include, /usr/include/qt5]
}
]
]
Would be simpler to parse for us.
Perhaps. CMake already has a source group concept (for IDEs to group
sources), and your concept of a source group here seems to be about grouping
files with common includes/defines/build properties? The two concepts may be
in conflict.
Right, my sourceGroups are sets of sources that have the same settings
applied to them.
I was coming from the CMAKE_EXPORT_COMPILE_COMMANDS output which does
have the information we need for the code model, but in a rather
inconvenient form. Having the files with similar flags/defines/etc.
grouped would make parsing them a lot faster. Not having to parse
compiler command lines would further improve things:-) So I am all for
you adding this information into some JSON file.
I do not think there is a conflict between CMake source groups and
what I was referring to, except maybe in my poorly chosen name.
For comparison, does any other buildsystem require header listings like
this? With qmake, I can populate HEADERS, but I don't have to (for headers
which do not require moc).
I am aware that listing all headers is not necessary for the build
system. It is one of those things where the needs of an IDE and those
of a build system differ.
Qmake asks for the headers to be listed. So does Qbs, which we want to
be great for IDE integration. Both will most likely not notice if you
forget some, but they won't be listed in Creator then.
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 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
Tobias Hunger wrote: Hey Stephen, On Sun, Oct 19, 2014 at 2:26 PM, Stephen Kelly steve...@gmail.com wrote: No problem, thanks! I recently discovered that Creator makes fragile guesses about source files and targets https://codereview.qt-project.org/#/c/96594/1/src/plugins/cmakeprojectmanager/cmakeproject.cpp,unified so I would really like to create a solution which makes that unnecessary. I am no expert on this part of the codebase, but I would not be surprised if it did do some stupid things when seeing cmake. We do not support that too well. What I mean is: the problem seems to be that source files are not listed per-target in the codeblock files CMake generates, so creator is forced to guess. I don't know if better information can be put into the C::B files, but I think the proposed json file is a better solution anyway. I don't generally like that creator (and clion) have to rely on parsing a foreign generators files. Yes. I suppose beyond the WIN32_EXECUTABLE/ SUBSYSTEM:console / Mac Bundle stuff the gui/console distinction doesn't really fit into the buildsystem. Maybe such a checkbox, pre-populated with the hint, is needed anyway. Not into a build system, but into an IDE:-) Yes, I wrote 'doesn't fit into the buildsystem' - implying it fits into the IDE, maybe in the form of a checkbox. I do not think there is a conflict between CMake source groups and what I was referring to, except maybe in my poorly chosen name. I was thinking about a case where the source groups defined in http://www.cmake.org/cmake/help/v3.0/command/source_group.html commands would be exported in the JSON. I don't know if that's a good idea or not, but if it is, then yes, namespacing may be the only issue. 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
Re: [cmake-developers] Extracting target metadata, IDE integration
Tobias Hunger wrote:
Sorry, I am a bit late with replying to this... I do not follow this
list too closely and got distracted by mails in between where I could
not contribute anything:-/
No problem, thanks! I recently discovered that Creator makes fragile guesses
about source files and targets
https://codereview.qt-project.org/#/c/96594/1/src/plugins/cmakeprojectmanager/cmakeproject.cpp,unified
so I would really like to create a solution which makes that unnecessary.
On Mon, Sep 22, 2014 at 4:03 PM, Stephen Kelly
steve...@gmail.com wrote:
The first is should this be run in a terminal or is this a GUI. Not
sure whether cmake has that information.
CMake only knows whether the WIN32_EXECUTABLE property has been set on a
target.
http://www.cmake.org/cmake/help/v3.0/prop_tgt/WIN32_EXECUTABLE.html
The property is harmless on non-Windows, so KDE sets it on non-Windows
for gui applications IIRC, but others may not.
This is a hint only.
If it works correctly it is nice, otherwise the user will have to
toggle some checkbox
to change it to his or her liking.
Yes. I suppose beyond the WIN32_EXECUTABLE/ SUBSYSTEM:console / Mac Bundle
stuff the gui/console distinction doesn't really fit into the buildsystem.
Maybe such a checkbox, pre-populated with the hint, is needed anyway.
Secondly the linker flags would be nice to know. That way the
LD_LIBRARY_PATH can be set correctly by the IDE so that all the
libraries are found.
If the linker flags were provided, you would have to parse them. Maybe a
runtimeLinkDirectories/linkDependentLibraries can be provided, similar to
the content passed to the option -rpath. I have no idea if similar
information can be acquired for MSVC/Windows. As Nils said, CMake might
not know the location of the import library.
If CMake knows the locations, then put them in, please.
I'm sure that won't be a problem.
But why not have groups of sources?
[
name: testc1
sourceGroups [
{
sources: [ foo.cpp ],
defines: [BUILD_TEST=1, QT_CORE_LIB, EXTRA_FOO=1],
includes: [/opt/bat/include, /usr/include/qt5]
},
{
sources: [ bar.cpp ],
defines: [BUILD_TEST=1, QT_CORE_LIB],
includes: [/opt/bat/include, /usr/include/qt5]
}
]
]
Would be simpler to parse for us.
Perhaps. CMake already has a source group concept (for IDEs to group
sources), and your concept of a source group here seems to be about grouping
files with common includes/defines/build properties? The two concepts may be
in conflict.
Afaik, CMake does not know all the files included by your cpp files.
However, some buildsystems can add them to the list of sources if desired
for better IDE integration.
https://gitorious.org/grantlee/grantlee/commit/3eb40cf94
That is the big issue I have with CMake... it makes it impossible to use
CMakeLists.txt as a sole source of project configuration.
For comparison, does any other buildsystem require header listings like
this? With qmake, I can populate HEADERS, but I don't have to (for headers
which do not require moc).
I want to know which files are part of the project and which are part
of the current build.
At least Qt Creator does not need information on which conditions to
be met for a file to become part of the current build.
Ok, good feedback, 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
Re: [cmake-developers] Extracting target metadata, IDE integration
Sorry, I am a bit late with replying to this... I do not follow this
list too closely and got distracted by mails in between where I could
not contribute anything:-/
On Mon, Sep 22, 2014 at 4:03 PM, Stephen Kelly steve...@gmail.com wrote:
The first is should this be run in a terminal or is this a GUI. Not
sure whether cmake has that information.
CMake only knows whether the WIN32_EXECUTABLE property has been set on a
target.
http://www.cmake.org/cmake/help/v3.0/prop_tgt/WIN32_EXECUTABLE.html
The property is harmless on non-Windows, so KDE sets it on non-Windows for
gui applications IIRC, but others may not.
This is a hint only.
If it works correctly it is nice, otherwise the user will have to
toggle some checkbox
to change it to his or her liking.
Secondly the linker flags would be nice to know. That way the
LD_LIBRARY_PATH can be set correctly by the IDE so that all the
libraries are found.
If the linker flags were provided, you would have to parse them. Maybe a
runtimeLinkDirectories/linkDependentLibraries can be provided, similar to
the content passed to the option -rpath. I have no idea if similar
information can be acquired for MSVC/Windows. As Nils said, CMake might not
know the location of the import library.
If CMake knows the locations, then put them in, please.
If not then there is little you can do, is there?
Combined with CMAKE_EXPORT_COMPILE_COMMANDS this should allow for a
pretty good integration into creator. Ideally the exported compile
commands would be a bit more aggregated along the lines of the
following list of files will be build using these defines/include
paths/flags, just because that would be way shorter and most likely
faster to parse.
What would that looks like? I guess listing the sources in a target together
with its includes/defines should be possible, together with extra per-source
defines, if present?
[
name : testc1
sources : [foo.cpp, bar.cpp]
defines : [BUILD_TEST=1, QT_CORE_LIB]
includes : [/opt/bat/include, /usr/include/qt5]
extraDefines : {
foo.cpp : [EXTRA_FOO=1]
}
]
I was thinking more along the lines of a somewhat aggregated
CMAKE_EXPORT_COMPILE_COMMANDS, but this is even better:-)
But why not have groups of sources?
[
name: testc1
sourceGroups [
{
sources: [ foo.cpp ],
defines: [BUILD_TEST=1, QT_CORE_LIB, EXTRA_FOO=1],
includes: [/opt/bat/include, /usr/include/qt5]
},
{
sources: [ bar.cpp ],
defines: [BUILD_TEST=1, QT_CORE_LIB],
includes: [/opt/bat/include, /usr/include/qt5]
}
]
]
Would be simpler to parse for us.
With this target description and the compile commands there is just
one piece of the puzzle missing for a great Qt Creator integration: We
need to generate a list of files that are part of the project. I
currently do not know how to extract that list from cmake. This list
must include all the header files that belong to the project, which is
what makes this hard to get this information from cmake -- at least at
the time I stopped working with cmake.
Afaik, CMake does not know all the files included by your cpp files.
However, some buildsystems can add them to the list of sources if desired
for better IDE integration.
https://gitorious.org/grantlee/grantlee/commit/3eb40cf94
That is the big issue I have with CMake... it makes it impossible to use
CMakeLists.txt as a sole source of project configuration.
Creator tries to not need any extra files to manage the project, so this
hits us pretty hard.
Ideally we could get the list of files that belong to the project in
general and the files that are actually part of the currently
configured built.
In CMake master at least, the user can list config-specific files
declaratively. Eg, add the foo_debug.cpp file only in the debug
configuration:
add_library(foo
foo.cpp
$$CONFIG:Debug:foo_debug.cpp
)
But how can I know that something_win.h will not be used when
building on my Linux box?
The current style is indeed difficult to parse, where that might be inside
an if() inside a macro etc. Again though, CMake master will allow users to
do better:
add_library(foo
foo.cpp
$$PLATFORM_ID:Windows:foo_win.cpp
)
I wonder how those kinds of conditions would need to be represented in the
ProjectTargets.json file.
This is actually a bit too detailed for my needs:-)
I want to know which files are part of the project and which are part
of the current build.
At least Qt Creator does not need information on which conditions to
be met for a file to become part of the current build.
One option would be to write them directly to the
json, instead of, for example, creating individual lists for each
configuration, and expecting the consumer to evaluate the expressions. A
possible problem with that is that consumers would have to transitively
evaluate each property over the link closure. Apart from the potential for
bugs,
Re: [cmake-developers] Extracting target metadata, IDE integration
On 10/17/2014 06:44 AM, Tobias Hunger wrote: On Mon, Sep 22, 2014 at 4:03 PM, Stephen Kelly steve...@gmail.com wrote: Afaik, CMake does not know all the files included by your cpp files. However, some buildsystems can add them to the list of sources if desired for better IDE integration. https://gitorious.org/grantlee/grantlee/commit/3eb40cf94 That is the big issue I have with CMake... it makes it impossible to use CMakeLists.txt as a sole source of project configuration. Creator tries to not need any extra files to manage the project, so this hits us pretty hard. We've discussed this in the past a few times. One solution is for the project spec to be in a declarative format, e.g. a JSON document. The spec would not be in a CMakeLists.txt but could be loaded by a command invoked from it. Then it could also be loaded and manipulated separately by IDEs or other tools. So, rather than having CMake generate a project spec file from the CMakeLists.txt files, we have CMakeLists.txt files load a project spec file. The declarative information goes in the project spec file, and imperative things like try_compile can be done in the CMake config step. The imperative step also loads the project spec and evaluates the declarations based on discovered information about the target platform. Other than this basic design, no one has taken the time to design such a format. -Brad -- 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, Oct 3, 2014 at 3:52 PM, Rolf Eike Beer e...@sf-mail.de wrote: Brad King wrote: On 10/01/2014 07:46 PM, Aleix Pol wrote: I'm very interested in getting this in and iterating forward. Any comments? How do changes get integrated? My main concern is that the format has not been proven with a corresponding implementation of an actual IDE/plugin to use it. Once we start producing a format changing it later will be problematic for compatibility. Even though we added a version number to the file, an IDE might not be updated along with a CMake that produces a newer version. This probably needs a way to query for the IDE which versions the given CMake version supports, no? Otherwise a newer IDE may request version 3 and just get nothing because the CMake binary only supports 1 and 2. Eike -- If it's not available then it should just error out. Aleix PS: I'm alive, working on this, when I get some free time -- 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 Thu, Oct 2, 2014 at 2:43 PM, Brad King brad.k...@kitware.com wrote: On 10/01/2014 07:46 PM, Aleix Pol wrote: I'm very interested in getting this in and iterating forward. Any comments? How do changes get integrated? My main concern is that the format has not been proven with a corresponding implementation of an actual IDE/plugin to use it. Once we start producing a format changing it later will be problematic for compatibility. Even though we added a version number to the file, an IDE might not be updated along with a CMake that produces a newer version. Perhaps rather than a boolean CMAKE_EXPORT_IDE_METADATA setting to enable this, the value should be a version number. That way enabling it requires explicit specification of which format version is desired. In this case we would need to use a format version number that is independent of th CMake version number. It would simply be incremented every time changes are made. If the version number has the form major.minor then we could increment the minor number whenever fields are added and the major number whenever fields are removed or changed. -Brad Ok, I can start working on it in a KDevelop branch and see what needs to be changed. Regarding passing the version rather than ON probably makes sense. I'll work on a patch to make it work this way. 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
Re: [cmake-developers] Extracting target metadata, IDE integration
Brad King wrote: On 10/01/2014 07:46 PM, Aleix Pol wrote: I'm very interested in getting this in and iterating forward. Any comments? How do changes get integrated? My main concern is that the format has not been proven with a corresponding implementation of an actual IDE/plugin to use it. Once we start producing a format changing it later will be problematic for compatibility. Even though we added a version number to the file, an IDE might not be updated along with a CMake that produces a newer version. This probably needs a way to query for the IDE which versions the given CMake version supports, no? Otherwise a newer IDE may request version 3 and just get nothing because the CMake binary only supports 1 and 2. Eike -- signature.asc Description: This is a digitally signed message part. -- 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 10/01/2014 07:46 PM, Aleix Pol wrote: I'm very interested in getting this in and iterating forward. Any comments? How do changes get integrated? My main concern is that the format has not been proven with a corresponding implementation of an actual IDE/plugin to use it. Once we start producing a format changing it later will be problematic for compatibility. Even though we added a version number to the file, an IDE might not be updated along with a CMake that produces a newer version. Perhaps rather than a boolean CMAKE_EXPORT_IDE_METADATA setting to enable this, the value should be a version number. That way enabling it requires explicit specification of which format version is desired. In this case we would need to use a format version number that is independent of th CMake version number. It would simply be incremented every time changes are made. If the version number has the form major.minor then we could increment the minor number whenever fields are added and the major number whenever fields are removed or changed. -Brad -- 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 Wed, Sep 24, 2014 at 6:51 PM, Aleix Pol aleix...@kde.org wrote:
On Wed, Sep 24, 2014 at 3:55 PM, Brad King brad.k...@kitware.com wrote:
On 09/22/2014 07:15 PM, Aleix Pol wrote:
{
version: 1.0,
targets: [...]
}
Yes. The version number could either be maintained as its own
thing, or just the CMake version number could be used. Either way
the Help/variable/CMAKE_OUTPUT_PROJECT_TARGETS.rst documentation
should specify the format of each version.
BTW, the phrase output project targets is not particularly
clear without knowing the feature already. Perhaps some other
name like CMAKE_EXPORT_IDE_METADATA would be better?
I've never worked with those, but it sounds like it would make sense.
What about:
{
version: ..
configurations: {
{ name: Debug, targets: [...] },
{ name: Release, targets: [...] }
}
}
Yes, something like that. I think you meant to use [] rather than
{} around the list of configurations. In the case that there is
only one configuration for the generator we should still use a
list but have only one entry.
Sure :)
-Brad
Hi,
Here's another iteration of the patch [1].
Basically adopts the possibility to move some information to depend on the
configuration. Currently it's only showing the I source files, I guess
location, directory and installed should be moved as well. Correct?
Aleix
[1]
New patch:
http://proli.net/meu/kdevelop/0001-cmake-Add-option-to-generate-target-metadata-for-IDE.patch
New output: http://proli.net/meu/kdevelop/ProjectTargets.json
Bump.
I'm very interested in getting this in and iterating forward.
Any comments? How do changes get integrated?
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
Re: [cmake-developers] Extracting target metadata, IDE integration
On Fri, Sep 26, 2014 at 1:27 AM, Stephen Kelly steve...@gmail.com wrote: Aleix Pol wrote: Hi, Here's another iteration of the patch [1]. Thanks for this. Can you tell me why exportName is part of the output? http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/focus=11009 Thanks, Steve. I just looked into it, GetOutputName is a private method. Now that you mention it though, we can just probably not output the exportName, at least for now. I can provide a new version of the patch if requested. 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
Re: [cmake-developers] Extracting target metadata, IDE integration
Hey everyone, We are developing CLion at JetBrains that utilizes CMake as its main project model. Stephen Kelly timely drew our attention to this discussion, and I’d like to share some thoughts. Here are the general ones and I’ll also comment on separate messages in the thread. We’ve managed to get almost all the necessary project information, using ‘GNU/MinGW Makefiles’ generators: * list of targets comes from 'CMakeFiles/TargetDirectories.txt' * list of source files from ‘CMakeFiles/A.dir/DependInfo.cmake’ * list of headers and resources from ‘codeblocks.cbp’ file * per-file/target compiler and its flags from ‘CMakeFiles/Target.dir/flags.make’ * location of product files from ‘CMakeFiles/Target.dir/build.make’ What we miss (not all of them are directly related the targets metadata, but I'd like to share anyway since the topic is about IDE integration): * Location of every source file and target in CMakeLists - it would greatly help to refactorings, navigation etc. * Complete list of headers and resource files - they are only listed in special generators like code blocks. * An easily parseable list of errors and warnings with origin information. At the moment we parse error output but not everything can be parsed reliably. * No progress indication. Since the generation may take several minutes, providing feedback is crucial. * Ability to distinguish a library from an executable target. This will help to offer a better UI for run/debug configurations. * Possibility to collect information for every build target in one run. Currently, we have to invoke generator for every CMAKE_BUILT_TYPE separately. * CMake stops processing when it find a missing file, so that IDE cannot have full project model, until this files is created. * When there are existing in-source generated files in the project dir, CMake doesn't allow generating into a separate out-of-source folder. An IDE has to invent workarounds here. * Not sure if it’s possible at all - a lightweight phase where CMake only collects necessary information (list of files/targets, compiler settings). This will help IDE react to the changes much faster. Here is why I think the discussed functionality should not be a separate generator: CLion doesn’t have it’s own project model nor is intended as build tool replacement. Currently, the only option for CLion users is makefiles build, that is not a best option for everyone: there is a good and fast alternative ‘Ninja’. Ideally, users should be able to choose whatever tool better suites them. The problem is that the generated Makefiles are used both, for internal needs, like reading project structure, and also to build and run the user’s program. If we wanted to support Ninja generator, we would need to rewrite all the logic that retrieves the project information, using the files that are created by Ninja generator. While I suppose it’s possible, it’s not the best option - very error prone and resource demanding. If CMake generated a separate descriptor, regardless the generator used (Makefiles, Ninja), it would be much easier to support; and the users will benefit from better, more reliable and faster CMake integration in an IDE. Regards, Anton Makeev -- 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 Thursday, September 25, 2014 07:14:38 Anton Makeev wrote: ... Here is why I think the discussed functionality should not be a separate generator: CLion doesn’t have it’s own project model nor is intended as build tool replacement. Currently, the only option for CLion users is makefiles build, that is not a best option for everyone: there is a good and fast alternative ‘Ninja’. Ideally, users should be able to choose whatever tool better suites them. The problem is that the generated Makefiles are used both, for internal needs, like reading project structure, and also to build and run the user’s program. If we wanted to support Ninja generator, we would need to rewrite all the logic that retrieves the project information, using the files that are created by Ninja generator. While I suppose it’s possible, it’s not the best option - very error prone and resource demanding. If CMake generated a separate descriptor, regardless the generator used (Makefiles, Ninja), it would be much easier to support; and the users will benefit from better, more reliable and faster CMake integration in an IDE. not sure I fully understand, but it seems you are maybe not aware how the extra generators in cmake work. Those are basically run additionally to a normal generator. I.e. cmake generates makefiles or ninja files, and additionally project files for an IDE. This project file typically contains the list of targets, and for each target the build command. At that point it doesn't matter much anymore for the IDE whether the main generator is make or ninja. This is implemented with the Eclipse generator, the CodeBlocks generator and the Kate generator. They all write a project file for the IDE additionally to the makefiles/ninja files for the actual building. Alex -- 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
Anton Makeev wrote: Hey everyone, We are developing CLion at JetBrains that utilizes CMake as its main project model. Stephen Kelly timely drew our attention to this discussion, and I’d like to share some thoughts. Here are the general ones and I’ll also comment on separate messages in the thread. Thanks! * Location of every source file and target in CMakeLists - it would greatly help to refactorings, navigation etc. Ok, that seems to already be part of the current design/implementation. * Complete list of headers and resource files - they are only listed in special generators like code blocks. That generator guesses that if foo.cpp is in the project and foo.h exists, then foo.h must also be part of the project: http://www.cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmExtraCodeBlocksGenerator.cxx;h=56a6edbb;hb=HEAD#l449 That might not be true, but you can probably make the same guess inside CLion anyway? * An easily parseable list of errors and warnings with origin information. At the moment we parse error output but not everything can be parsed reliably. That non-reliability of parsing that stuff might be something to file bugs about. I think it's out of scope of the metadata file design. * No progress indication. Since the generation may take several minutes, providing feedback is crucial. There is feedback during the configure stage, and as the generation stage may take longer as of the last few releases, I have thought that showing some progress could be worthwhile. I haven't looked into it though. I filed http://public.kitware.com/Bug/view.php?id=15172 to track the idea. Again though, this is out of scope of the target metadata file. * Ability to distinguish a library from an executable target. This will help to offer a better UI for run/debug configurations. This is already part of the current design/implementation. * Possibility to collect information for every build target in one run. Currently, we have to invoke generator for every CMAKE_BUILD_TYPE separately. This is part of the updated design. http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/focus=11041 * CMake stops processing when it find a missing file, so that IDE cannot have full project model, until this files is created. True. However, if cmake stops processing (because of a missing file or many other reasons, such as a missing dependency), the full project model is not known. I'm not sure this is 'fixable'. * When there are existing in-source generated files in the project dir, CMake doesn't allow generating into a separate out-of-source folder. An IDE has to invent workarounds here. I'm not sure CMake can provide a better solution to this. Would you want to run cmake in a mode which clears out such files somehow? I'm not sure that would be accepted. Here is why I think the discussed functionality should not be a separate generator: I think that ship has sailed. The feature is being implemented with a variable for control, not a generator. Thanks for the feedback! 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
Re: [cmake-developers] Extracting target metadata, IDE integration
On 09/22/2014 07:15 PM, Aleix Pol wrote:
{
version: 1.0,
targets: [...]
}
Yes. The version number could either be maintained as its own
thing, or just the CMake version number could be used. Either way
the Help/variable/CMAKE_OUTPUT_PROJECT_TARGETS.rst documentation
should specify the format of each version.
BTW, the phrase output project targets is not particularly
clear without knowing the feature already. Perhaps some other
name like CMAKE_EXPORT_IDE_METADATA would be better?
I've never worked with those, but it sounds like it would make sense. What
about:
{
version: ..
configurations: {
{ name: Debug, targets: [...] },
{ name: Release, targets: [...] }
}
}
Yes, something like that. I think you meant to use [] rather than
{} around the list of configurations. In the case that there is
only one configuration for the generator we should still use a
list but have only one entry.
-Brad
--
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 Wed, Sep 24, 2014 at 3:55 PM, Brad King brad.k...@kitware.com wrote:
On 09/22/2014 07:15 PM, Aleix Pol wrote:
{
version: 1.0,
targets: [...]
}
Yes. The version number could either be maintained as its own
thing, or just the CMake version number could be used. Either way
the Help/variable/CMAKE_OUTPUT_PROJECT_TARGETS.rst documentation
should specify the format of each version.
BTW, the phrase output project targets is not particularly
clear without knowing the feature already. Perhaps some other
name like CMAKE_EXPORT_IDE_METADATA would be better?
I've never worked with those, but it sounds like it would make sense.
What about:
{
version: ..
configurations: {
{ name: Debug, targets: [...] },
{ name: Release, targets: [...] }
}
}
Yes, something like that. I think you meant to use [] rather than
{} around the list of configurations. In the case that there is
only one configuration for the generator we should still use a
list but have only one entry.
Sure :)
-Brad
Hi,
Here's another iteration of the patch [1].
Basically adopts the possibility to move some information to depend on the
configuration. Currently it's only showing the I source files, I guess
location, directory and installed should be moved as well. Correct?
Aleix
[1]
New patch:
http://proli.net/meu/kdevelop/0001-cmake-Add-option-to-generate-target-metadata-for-IDE.patch
New output: http://proli.net/meu/kdevelop/ProjectTargets.json
--
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 09/20/2014 09:57 PM, Tobias Hunger wrote:
Hello!
Sorry for breaking the threading, I only joined this ML just now to
comment on this thread:-) Thanks Stephen for pointing me here!
I am not a regular cmake user (used to be a couple of years ago), but
I im interested in this topic since I work on Qt Creator. While cmake
currently is not our focus, I would personally like to see better
cmake integration into our tool. Unfortunately I do not have the time
to work on this myself:-/
I do want to provide some input to this discussion though.
From my experience we would need a bit more information than proposed
in
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/focus=1100
This is the structure suggested for each target:
snip
{
name: testc1,
type: STATIC_LIBRARY,
directory: /tmp/COnly-bld,
location: /tmp/COnly-bld//libtestc1.a,
exportName: testc1,
backtrace: [/tmp/COnly-src/CMakeLists.txt:6],
installed: false
},
snip
That information will be valuable.
I would love to see two additional field with information:
The first is should this be run in a terminal or is this a GUI. Not
sure whether cmake has that information.
At least on windows where there are distinct link time subsystems for
console and gui applications the information is known; don't think it is
available anywhere else(?)
Secondly the linker flags would be nice to know. That way the
LD_LIBRARY_PATH can be set correctly by the IDE so that all the
libraries are found.
That might not be necessary since CMake automatically constructs build
time RPATHs by default.
Might be nice for platforms where RPATHs aren't supported (e.g. Windows)
though a generic, non IDE specific solution might be preferable:
http://public.kitware.com/pipermail/cmake-developers/2014-September/011373.html
Nils
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Extracting target metadata, IDE integration
Nils Gladitz wrote: Might be nice for platforms where RPATHs aren't supported (e.g. Windows) though a generic, non IDE specific solution might be preferable: The proposed ProjectTargets.json isn't particularly IDE specific. That's only the motivation. 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
Re: [cmake-developers] Extracting target metadata, IDE integration
On 09/22/2014 03:39 PM, Stephen Kelly wrote: Nils Gladitz wrote: Might be nice for platforms where RPATHs aren't supported (e.g. Windows) though a generic, non IDE specific solution might be preferable: The proposed ProjectTargets.json isn't particularly IDE specific. That's only the motivation. I meant it would be imo preferable if CMake could implement a solution for this directly rather than leaving it to any IDE or target buildsystem. e.g. something that would also work without an IDE (like RPATHs where currently supported). Nils -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Extracting target metadata, IDE integration
Tobias Hunger wrote:
The first is should this be run in a terminal or is this a GUI. Not
sure whether cmake has that information.
CMake only knows whether the WIN32_EXECUTABLE property has been set on a
target.
http://www.cmake.org/cmake/help/v3.0/prop_tgt/WIN32_EXECUTABLE.html
The property is harmless on non-Windows, so KDE sets it on non-Windows for
gui applications IIRC, but others may not.
Secondly the linker flags would be nice to know. That way the
LD_LIBRARY_PATH can be set correctly by the IDE so that all the
libraries are found.
If the linker flags were provided, you would have to parse them. Maybe a
runtimeLinkDirectories/linkDependentLibraries can be provided, similar to
the content passed to the option -rpath. I have no idea if similar
information can be acquired for MSVC/Windows. As Nils said, CMake might not
know the location of the import library.
Combined with CMAKE_EXPORT_COMPILE_COMMANDS this should allow for a
pretty good integration into creator. Ideally the exported compile
commands would be a bit more aggregated along the lines of the
following list of files will be build using these defines/include
paths/flags, just because that would be way shorter and most likely
faster to parse.
What would that looks like? I guess listing the sources in a target together
with its includes/defines should be possible, together with extra per-source
defines, if present?
[
name : testc1
sources : [foo.cpp, bar.cpp]
defines : [BUILD_TEST=1, QT_CORE_LIB]
includes : [/opt/bat/include, /usr/include/qt5]
extraDefines : {
foo.cpp : [EXTRA_FOO=1]
}
]
With this target description and the compile commands there is just
one piece of the puzzle missing for a great Qt Creator integration: We
need to generate a list of files that are part of the project. I
currently do not know how to extract that list from cmake. This list
must include all the header files that belong to the project, which is
what makes this hard to get this information from cmake -- at least at
the time I stopped working with cmake.
Afaik, CMake does not know all the files included by your cpp files.
However, some buildsystems can add them to the list of sources if desired
for better IDE integration.
https://gitorious.org/grantlee/grantlee/commit/3eb40cf94
Ideally we could get the list of files that belong to the project in
general and the files that are actually part of the currently
configured built.
In CMake master at least, the user can list config-specific files
declaratively. Eg, add the foo_debug.cpp file only in the debug
configuration:
add_library(foo
foo.cpp
$$CONFIG:Debug:foo_debug.cpp
)
But how can I know that something_win.h will not be used when
building on my Linux box?
The current style is indeed difficult to parse, where that might be inside
an if() inside a macro etc. Again though, CMake master will allow users to
do better:
add_library(foo
foo.cpp
$$PLATFORM_ID:Windows:foo_win.cpp
)
I wonder how those kinds of conditions would need to be represented in the
ProjectTargets.json file. One option would be to write them directly to the
json, instead of, for example, creating individual lists for each
configuration, and expecting the consumer to evaluate the expressions. A
possible problem with that is that consumers would have to transitively
evaluate each property over the link closure. Apart from the potential for
bugs, that would mean there would need to be a target entry for each
IMPORTED target too.
It would probably be easier to try to generate something like
defines : {
noconfig : [FOO=1, QT_CORE_LIB]
debug : [QT_DEBUG]
release : [RELEASE_MODE=1]
}
from
target_compile_definitions(foo PRIVATE
FOO=1
$$CONFIG:Release:RELEASE_MODE=1
)
target_link_libraries(foo PRIVATE
Qt5::Core # Uses the Qt defines in the foo target.
)
But that will mean adding more complexity to generator expression evaluation
to find out which condition groups are needed (Eg, Do I need to create per-
platform/per-config/per-compiler groups?).
So, we'd have to decide how much exactness to aim for, and how much
complexity to push to the user.
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
Re: [cmake-developers] Extracting target metadata, IDE integration
On 09/20/2014 09:18 AM, Stephen Kelly wrote: I don't know why I added it. There is also a 'new' +location += /; in that patch further down which might be removable. Thanks for pointing that one out too. I've removed both with a commit message that explains one hypothesis as to why they appeared: Remove extra slashes from LOCATION target property value http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=92b2c618 Thanks, -Brad -- 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, Sep 19, 2014 at 7:44 PM, Brad King brad.k...@kitware.com wrote:
On 09/18/2014 08:10 PM, Aleix Pol wrote:
I added a CMAKE_OUTPUT_PROJECT_TARGETS variable that can be used to
enable the generation of the file.
I also renamed the file to ProjectTargets.json.
http://www.proli.net/meu/kdevelop/cmake-targetsdata.patch
Thanks. I made some style updates and converted it to a patch
generated with 'git format-patch'. See attached. I also
attached a sample ProjectTargets.json generated for the COnly
test from our test suite.
Cool! Thanks a lot for taking your time to look into this!
I'd really like to hear from others on the file format itself.
Some comments on the format:
* A version number field is needed at the top.
Sure, can't hurt.
So you'd encapsulate it such as:
{
version: 1.0,
targets: [...]
}
* There needs to be support for multi-config generators.
Perhaps everything that can be affected by the configuration
needs to be inside a list that enumerates all configurations.
In single-configuration generators the list would have only
one entry for the CMAKE_BUILD_TYPE. In multi-configuration
generators it would be all of the CMAKE_CONFIGURATION_TYPES.
I've never worked with those, but it sounds like it would make sense. What
about:
{
version: ..
configurations: {
{ name: Debug, targets: [...] },
{ name: Release, targets: [...] }
}
}
* Don't IDEs want to know the list of source files so they can
be used for editing?
It would probably make sense, yes. We can introduce an input field.
I haven't looked at what the Extra generators produce in a
while but since they are meant for IDEs they would be a good
reference for the information needed. However, AFAIK there
is not an extra generator for a multi-config generator.
-Brad
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
Re: [cmake-developers] Extracting target metadata, IDE integration
On Friday, September 19, 2014 21:53:40 Alexander Neundorf wrote: On Friday, September 19, 2014 13:44:45 Brad King wrote: ... * Don't IDEs want to know the list of source files so they can be used for editing? I haven't looked at what the Extra generators produce in a while but since they are meant for IDEs they would be a good reference for the information needed. typically a list of targets, the command to build each target, source files for each target, used include dirs and defines (-D) for code completion. However, AFAIK there is not an extra generator for a multi-config generator. Yes. also after reading the other replies, I still don't understand why this shouldn't be a generator. If I understand correctly, this is for people who simply run cmake and later on want to use kdevelop on the existing build tree. How about simply adding support for an environment variable like CMAKE_GENERATOR, which, when set, will be used as generator as long as no other generator has been set via -G ? KDE developers could set this variable, still run their build scripts, and later on use kdevelop. I have a hard time imagining a user who uses let's say Eclipse with the Eclipse generator, who then suddenly wants to use kdevelop on his build tree. Alex -- 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
Brad King wrote: Steve, do you remember why it was added? All lines below that append a slash before appending other content, so it will always end up with a double slash. Is there any reason you see that it cannot be removed? I don't know why I added it. Perhaps to deal with a dashboard error that would emerge again if removed. There is also a 'new' +location += /; in that patch further down which might be removable. 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
Re: [cmake-developers] Extracting target metadata, IDE integration
Brad King wrote: I'd really like to hear from others on the file format itself. * There needs to be support for multi-config generators. This presumable affects the directory and location. I wonder what the usefulness of putting exportName in the file is? Is it possible there is confusion with OUTPUT_NAME? Or do you want some richer information if an IDE opens a file in the build dir generated by export()? Does this generated file enable use-cases like 'Add new file to target' or is that already easy? Or what kind of features are enabled by this? 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
Re: [cmake-developers] Extracting target metadata, IDE integration
Hello!
Sorry for breaking the threading, I only joined this ML just now to
comment on this thread:-) Thanks Stephen for pointing me here!
I am not a regular cmake user (used to be a couple of years ago), but
I im interested in this topic since I work on Qt Creator. While cmake
currently is not our focus, I would personally like to see better
cmake integration into our tool. Unfortunately I do not have the time
to work on this myself:-/
I do want to provide some input to this discussion though.
From my experience we would need a bit more information than proposed
in
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/focus=1100
This is the structure suggested for each target:
snip
{
name: testc1,
type: STATIC_LIBRARY,
directory: /tmp/COnly-bld,
location: /tmp/COnly-bld//libtestc1.a,
exportName: testc1,
backtrace: [/tmp/COnly-src/CMakeLists.txt:6],
installed: false
},
snip
That information will be valuable.
I would love to see two additional field with information:
The first is should this be run in a terminal or is this a GUI. Not
sure whether cmake has that information.
Secondly the linker flags would be nice to know. That way the
LD_LIBRARY_PATH can be set correctly by the IDE so that all the
libraries are found.
Combined with CMAKE_EXPORT_COMPILE_COMMANDS this should allow for a
pretty good integration into creator. Ideally the exported compile
commands would be a bit more aggregated along the lines of the
following list of files will be build using these defines/include
paths/flags, just because that would be way shorter and most likely
faster to parse.
With this target description and the compile commands there is just
one piece of the puzzle missing for a great Qt Creator integration: We
need to generate a list of files that are part of the project. I
currently do not know how to extract that list from cmake. This list
must include all the header files that belong to the project, which is
what makes this hard to get this information from cmake -- at least at
the time I stopped working with cmake.
Ideally we could get the list of files that belong to the project in
general and the files that are actually part of the currently
configured built.
The general list can be clutched around by just assuming that all
source files in the current project directory belong to the project.
But how can I know that something_win.h will not be used when
building on my Linux box?
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 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 09/18/2014 08:10 PM, Aleix Pol wrote:
I added a CMAKE_OUTPUT_PROJECT_TARGETS variable that can be used to
enable the generation of the file.
I also renamed the file to ProjectTargets.json.
http://www.proli.net/meu/kdevelop/cmake-targetsdata.patch
Thanks. I made some style updates and converted it to a patch
generated with 'git format-patch'. See attached. I also
attached a sample ProjectTargets.json generated for the COnly
test from our test suite.
I'd really like to hear from others on the file format itself.
Some comments on the format:
* A version number field is needed at the top.
* There needs to be support for multi-config generators.
Perhaps everything that can be affected by the configuration
needs to be inside a list that enumerates all configurations.
In single-configuration generators the list would have only
one entry for the CMAKE_BUILD_TYPE. In multi-configuration
generators it would be all of the CMAKE_CONFIGURATION_TYPES.
* Don't IDEs want to know the list of source files so they can
be used for editing?
I haven't looked at what the Extra generators produce in a
while but since they are meant for IDEs they would be a good
reference for the information needed. However, AFAIK there
is not an extra generator for a multi-config generator.
-Brad
From b36c309dd2aa622692b7ae70d5270bc6d56e3251 Mon Sep 17 00:00:00 2001
Message-Id: b36c309dd2aa622692b7ae70d5270bc6d56e3251.1411148212.git.brad.k...@kitware.com
From: Aleix Pol aleix...@kde.org
Date: Fri, 19 Sep 2014 02:10:12 +0200
Subject: [PATCH] cmake: Add option to generate target metadata for IDEs
Create a CMAKE_OUTPUT_PROJECT_TARGETS option that can be used to enable
generation of a 'ProjectTargets.json' file. Write into the file a JSON
description of the build targets that an IDE might load.
---
Modules/CMakeGenericSystem.cmake | 5 +++
Source/cmGlobalGenerator.cxx | 80 +++-
Source/cmGlobalGenerator.h | 1 +
3 files changed, 84 insertions(+), 2 deletions(-)
diff --git a/Modules/CMakeGenericSystem.cmake b/Modules/CMakeGenericSystem.cmake
index 8a14aea..5ef28d8 100644
--- a/Modules/CMakeGenericSystem.cmake
+++ b/Modules/CMakeGenericSystem.cmake
@@ -67,6 +67,11 @@ if(CMAKE_GENERATOR MATCHES Ninja)
mark_as_advanced(CMAKE_EXPORT_COMPILE_COMMANDS)
endif()
+set(CMAKE_OUTPUT_PROJECT_TARGETS OFF CACHE BOOL
+Enable/Disable output of a ProjectTargets.json file during generation.
+)
+mark_as_advanced(CMAKE_OUTPUT_PROJECT_TARGETS)
+
# GetDefaultWindowsPrefixBase
#
# Compute the base directory for CMAKE_INSTALL_PREFIX based on:
diff --git a/Source/cmGlobalGenerator.cxx b/Source/cmGlobalGenerator.cxx
index 4375114..8e28fec 100644
--- a/Source/cmGlobalGenerator.cxx
+++ b/Source/cmGlobalGenerator.cxx
@@ -2876,6 +2876,26 @@ void cmGlobalGenerator::WriteRuleHashes(std::string const pfile)
}
//
+static void printBacktraceJson(const cmListFileBacktrace bt,
+ cmGeneratedFileStream stream)
+{
+ stream [;
+ for(cmListFileBacktrace::const_iterator it = bt.begin(); it!=bt.end(); ++it)
+{
+ const cmListFileContext ctx = *it;
+
+ if(it!=bt.begin())
+stream , ;
+
+ stream '\';
+ stream ctx.FilePath;
+ stream ':';
+ stream ctx.Line;
+ stream '\';
+}
+ stream ']';
+}
+
void cmGlobalGenerator::WriteSummary()
{
cmMakefile* mf = this-LocalGenerators[0]-GetMakefile();
@@ -2885,8 +2905,6 @@ void cmGlobalGenerator::WriteSummary()
fname += cmake::GetCMakeFilesDirectory();
fname += /TargetDirectories.txt;
cmGeneratedFileStream fout(fname.c_str());
-
- // Generate summary information files for each target.
for(TargetMap::const_iterator ti =
this-TotalTargets.begin(); ti != this-TotalTargets.end(); ++ti)
{
@@ -2897,6 +2915,64 @@ void cmGlobalGenerator::WriteSummary()
this-WriteSummary(ti-second);
fout ti-second-GetSupportDirectory() \n;
}
+
+ if(mf-IsOn(CMAKE_OUTPUT_PROJECT_TARGETS))
+{
+this-WriteProjectTargetsJson();
+}
+}
+
+void cmGlobalGenerator::WriteProjectTargetsJson()
+{
+ cmMakefile* mf = this-LocalGenerators[0]-GetMakefile();
+ std::string projectTargetsPath = mf-GetHomeOutputDirectory();
+ projectTargetsPath += /ProjectTargets.json;
+ cmGeneratedFileStream aout(projectTargetsPath.c_str());
+ aout [\n;
+
+ // Generate summary information files for each target.
+ for(TargetMap::const_iterator ti =
+this-TotalTargets.begin(); ti != this-TotalTargets.end(); ++ti)
+{
+if ((ti-second)-GetType() == cmTarget::INTERFACE_LIBRARY)
+ {
+ continue;
+ }
+
+cmTarget* t = ti-second;
+aout
+{\n
+ \name\: \ ti-first \,\n
+ \type\: \ cmTarget::GetTargetTypeName(t-GetType())
+ \,\n
+ ;
+if(t-GetType() != cmTarget::UTILITY)
+ {
+ aout
+
Re: [cmake-developers] Extracting target metadata, IDE integration
On 09/19/2014 01:57 PM, Rolf Eike Beer wrote:
I see duplicated slashes in the JSON file.
It looks like those come from cmTarget::GetLocationForBuild.
An extra
+ if(!location.empty())
+{
+location += /;
+}
appears to have been added by this commit:
Remove the Location member from cmTarget.
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=638843af
Steve, do you remember why it was added? All lines below
that append a slash before appending other content, so it
will always end up with a double slash. Is there any reason
you see that it cannot be removed?
Thanks,
-Brad
--
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 Friday, September 19, 2014 13:44:45 Brad King wrote: ... * Don't IDEs want to know the list of source files so they can be used for editing? I haven't looked at what the Extra generators produce in a while but since they are meant for IDEs they would be a good reference for the information needed. typically a list of targets, the command to build each target, source files for each target, used include dirs and defines (-D) for code completion. However, AFAIK there is not an extra generator for a multi-config generator. Yes. Alex -- 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 Mon, Sep 8, 2014 at 2:51 PM, Brad King brad.k...@kitware.com wrote: On 09/03/2014 12:12 PM, Aleix Pol wrote: On Wed, Sep 3, 2014 at 5:48 PM, Alexander Neundorf wrote: I still don't understand why this shouldn't be an additional ExtraGenerator. Because it's not possible to change the generator of a build directory once it's set up. You need to nuke it and re-create it. [snip] On 09/01/2014 07:27 PM, Aleix Pol wrote: Ok, how does it sound if we have a variable, such as CMAKE_EXPORT_COMPILE_COMMANDS? Let's say, CMAKE_EXPORT_TARGETS_INFORMATION. A control variable like that sounds good to me. The purpose looks very similar to CMAKE_EXPORT_COMPILE_COMMANDS, but is distinct enough to have its own control. Thanks, -Brad -- 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 I added a CMAKE_OUTPUT_PROJECT_TARGETS variable that can be used to enable the generation of the file. I also renamed the file to ProjectTargets.json. http://www.proli.net/meu/kdevelop/cmake-targetsdata.patch Does it look better like this? 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
Re: [cmake-developers] Extracting target metadata, IDE integration
On 09/03/2014 12:12 PM, Aleix Pol wrote: On Wed, Sep 3, 2014 at 5:48 PM, Alexander Neundorf wrote: I still don't understand why this shouldn't be an additional ExtraGenerator. Because it's not possible to change the generator of a build directory once it's set up. You need to nuke it and re-create it. [snip] On 09/01/2014 07:27 PM, Aleix Pol wrote: Ok, how does it sound if we have a variable, such as CMAKE_EXPORT_COMPILE_COMMANDS? Let's say, CMAKE_EXPORT_TARGETS_INFORMATION. A control variable like that sounds good to me. The purpose looks very similar to CMAKE_EXPORT_COMPILE_COMMANDS, but is distinct enough to have its own control. Thanks, -Brad -- 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 Tue, Sep 2, 2014 at 3:58 PM, David Cole dlrd...@aol.com wrote: It makes sense. But what IDE are you referring to? Eclipse? Some other concrete example? Or just any IDE and this feature should work everywhere CMake works...? I'm working on KDevelop, I know for a fact though, that other IDEs are looking for something similar too, such as QtCreator. 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
Re: [cmake-developers] Extracting target metadata, IDE integration
On Tue, Sep 2, 2014 at 9:45 PM, Alexander Neundorf neund...@kde.org wrote: On Tuesday, September 02, 2014 09:58:37 David Cole via cmake-developers wrote: It makes sense. But what IDE are you referring to? Eclipse? Some other concrete example? Or just any IDE and this feature should work everywhere CMake works...? AFAIK it is kdevelop4, and the goal is that developers don't have to tell cmake to run a kdevelop4 generator, but just the normal makefile generator, and still be able to use kdevelop4 on these build trees. Alex Yes, essentially. Makefile, or ninja, or whatever they use on mac and Windows and any of our supported platforms. 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
Re: [cmake-developers] Extracting target metadata, IDE integration
On Wednesday, September 03, 2014 12:30:21 Aleix Pol wrote: On Tue, Sep 2, 2014 at 3:58 PM, David Cole dlrd...@aol.com wrote: It makes sense. But what IDE are you referring to? Eclipse? Some other concrete example? Or just any IDE and this feature should work everywhere CMake works...? I'm working on KDevelop, I know for a fact though, that other IDEs are looking for something similar too, such as QtCreator. I still don't understand why this shouldn't be an additional ExtraGenerator. It will generate a special file intended to be used by KDevelop and maybe QtCreator additionally to makefiles/ninja files. Could be called GenericJSON or so. Other IDEs which don't support this file type but which need their own project file obviously still need their own specific generator. Alex -- 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 Wed, Sep 3, 2014 at 5:48 PM, Alexander Neundorf neund...@kde.org wrote: On Wednesday, September 03, 2014 12:30:21 Aleix Pol wrote: On Tue, Sep 2, 2014 at 3:58 PM, David Cole dlrd...@aol.com wrote: It makes sense. But what IDE are you referring to? Eclipse? Some other concrete example? Or just any IDE and this feature should work everywhere CMake works...? I'm working on KDevelop, I know for a fact though, that other IDEs are looking for something similar too, such as QtCreator. I still don't understand why this shouldn't be an additional ExtraGenerator. It will generate a special file intended to be used by KDevelop and maybe QtCreator additionally to makefiles/ninja files. Could be called GenericJSON or so. Other IDEs which don't support this file type but which need their own project file obviously still need their own specific generator. Alex Because it's not possible to change the generator of a build directory once it's set up. You need to nuke it and re-create it. Also because changing the generator could potentially change the interaction the user has with the build directory, we don't want to get in the way. 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
Re: [cmake-developers] Extracting target metadata, IDE integration
Ok, how does it sound if we have a variable, such as CMAKE_EXPORT_COMPILE_COMMANDS? Let's say, CMAKE_EXPORT_TARGETS_INFORMATION. I would prefer CMAKE_EXPORT_TARGETS_FILE, or some name that implies it is a filename value, with the value of the variable being the name of the file to generate. Who's the consumer of this file? Is it just one particular IDE, or is it meant to be general and possibly be used by multiple IDE generators? (I'm not sure I fully understand the context of the intent here based on the prior emails Can you explain it a little more?) Thanks, David C. -- 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 Tue, Sep 2, 2014 at 1:03 PM, David Cole dlrd...@aol.com wrote: Ok, how does it sound if we have a variable, such as CMAKE_EXPORT_COMPILE_COMMANDS? Let's say, CMAKE_EXPORT_TARGETS_INFORMATION. I would prefer CMAKE_EXPORT_TARGETS_FILE, or some name that implies it is a filename value, with the value of the variable being the name of the file to generate. I think it's better to do an ON/OFF setting, given that from an IDE point of view what we want is to be able to run cmake again and get the file. If Eclipse generated the file I will still want to open it, and then we'd have to agree on a file name or need to modify the build directory, which kind of defeats the purpose. Who's the consumer of this file? Is it just one particular IDE, or is it meant to be general and possibly be used by multiple IDE generators? (I'm not sure I fully understand the context of the intent here based on the prior emails Can you explain it a little more?) The consumer of this file is the IDE or anyone who needs to be able to figure out the project's data. We need ways to describe the targets generated by the project to let the IDE user know what targets the project has and to be able to use them. To get some context, let me define one of our use-cases, which would be a KDE user. To build a KDE Plasma 5 installation you need 100 repositories to be built and configured. This means that all these are configured and installed to a prefix, possibly with an external tool. Our user will want to develop one of those projects. To do so, he will open the project and choose the build directory tied to it, from there we need to infer all the information he will need to develop the project. Here's where the targets file comes into place, the IDE will just need to open this file and the compile_commands.json files. If they're not created the IDE will set the cache values then generate to be able to access them. I hope it makes sense now. 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
Re: [cmake-developers] Extracting target metadata, IDE integration
On Tuesday, September 02, 2014 09:58:37 David Cole via cmake-developers wrote: It makes sense. But what IDE are you referring to? Eclipse? Some other concrete example? Or just any IDE and this feature should work everywhere CMake works...? AFAIK it is kdevelop4, and the goal is that developers don't have to tell cmake to run a kdevelop4 generator, but just the normal makefile generator, and still be able to use kdevelop4 on these build trees. Alex -- 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 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! Bump? -- 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
The approach looks reasonable, but having it unconditionally spit out a file in cmGlobalGenerator regardless of generator is probably not what we want. Seems like it should be based on a variable, or be in a specific generator, or somehow have a limited scope. HTH, David C. -- 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 Monday, September 01, 2014 15:26:12 David Cole via cmake-developers wrote: The approach looks reasonable, but having it unconditionally spit out a file in cmGlobalGenerator regardless of generator is probably not what we want. Seems like it should be based on a variable, or be in a specific generator, or somehow have a limited scope. I agree. IMO this should be a generator, I don't see why it should work around that. Alex -- 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 Mon, Sep 1, 2014 at 9:26 PM, David Cole dlrd...@aol.com wrote: The approach looks reasonable, but having it unconditionally spit out a file in cmGlobalGenerator regardless of generator is probably not what we want. Seems like it should be based on a variable, or be in a specific generator, or somehow have a limited scope. HTH, David C. Ok, how does it sound if we have a variable, such as CMAKE_EXPORT_COMPILE_COMMANDS? Let's say, CMAKE_EXPORT_TARGETS_INFORMATION. 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] Extracting target metadata, IDE integration
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! -- 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
