Re: [cmake-developers] [Qt-creator] CMake daemon for user tools
Hey, I'll be going to Berlin the weekend of the 14th May (Board meeting, I'll be busy during the weekend). Would it make sense for me to book one day before/after to meet and hack on this? Aleix On Thu, Feb 18, 2016 at 2:20 PM, Aleix Pol wrote: > On Wed, Feb 17, 2016 at 10:59 PM, Stephen Kelly wrote: >> On 02/15/2016 07:24 PM, Tobias Hunger wrote: >> >> Hi Dominik, >> >> Am 15.02.2016 19:01 schrieb "Dominik Haumann" : >>> 1. Wouldn't it make sense you have a developer sprint ASAP for this? >> >> I'd be in, but I do not have the time to organize one. I could probably get >> a room in our office though (in Berlin). > > Eh... sorry for my silence. > > I'll be happy to join a small sprint. > > 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] [Qt-creator] CMake daemon for user tools
On Wed, Feb 17, 2016 at 10:59 PM, Stephen Kelly wrote: > On 02/15/2016 07:24 PM, Tobias Hunger wrote: > > Hi Dominik, > > Am 15.02.2016 19:01 schrieb "Dominik Haumann" : >> 1. Wouldn't it make sense you have a developer sprint ASAP for this? > > I'd be in, but I do not have the time to organize one. I could probably get > a room in our office though (in Berlin). Eh... sorry for my silence. I'll be happy to join a small sprint. 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] CMake daemon for user tools
On Sun, Jan 10, 2016 at 12:10 PM, Stephen Kelly wrote: > > Hello, > > I've been working on adding a daemon mode for cmake to provide > information to user tools - such as IDEs - about the buildsystem. > > Following the discussion about providing metadata for IDEs to consume > I proposed creating a long-running process which would provide a protocol > to access information about the buildsystem, and about the content of the > cmake files themselves: > > > http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/12658/focus=13004 > > The original post in that thread lists design goals. > > This design is independent of any generator, and compared to the solution of > writing json to a file, this solution doesn't require generating > anything that is > not asked for. This also side-steps the problem of 'stale' files remaining > in the build directory, and the problem of needing to trigger re-generation > of the file, or watching it for changes. This solution also allows > parameters (eg the config) to be specified in requests, side-stepping a > difficulty we encountered before to represent things like that. This > solution also does not require actually generating the buildsystem > files. Only the configure and compute steps of cmake are executed. > > I am scheduled to give a talk at FOSDEM about the feature and how user > tools can interact with it: > > https://fosdem.org/2016/schedule/event/enabling_gui_tools_for_cmake_code > > with a preview in Berlin: > > http://www.meetup.com/berlincplusplus/events/227896427/ > > I have now also pushed a branch to my github clone with the start of the > server mode: > > https://github.com/steveire/CMake/commits/cmake-daemon > > Currently the branch only makes targets and backtraces etc available via > the protocol. I have also created a plan for extending the protocol to > make code completion and variable debugging possible, and analysed the > depedencies of the tasks: > > http://www.steveire.com/cmake-daemon-tasks.png > > However, I can't complete those tasks myself: I don't have > relevant experience building IDEs to know how best to design the > protocol, what IDE tools really need, how to design a fail-safe parser > etc. Additionally, I think a design which incorporates design ideas > and implementation from more than one person will be better in the end. > > So, this needs to be a collaborative effort if it is to go anywhere, with > more people writing commits in the cmake repo. > > The above (copied below) task list would be enough to get a read-only > browser of a cmake project quite quickly. > > Following that, an effort would be needed to handle the difference > between the dirty state of an editor and the on-disk file content. That's > a solvable problem and together with filesystem notifications provided > by libuv, it will lead to features like code completion. > > Also necessary eventually would be to make the cmake parser more > fail-safe, so that information is still available if the user > had not yet closed a command argument list for example, and make the > processing more fail-safe in the case where they have written > add_subdirectory(foo), but have not yet created foo/CMakeLists.txt. > > I would be looking to people who work on IDEs for guidance on how to do > things like that, as some of them are likely already for handling C++ > code in the IDEs. > > So, this needs to be a collaborative effort. I can provide guidance to > anyone who wishes to participate in changing the source code of CMake > to make it possible. > > Is anyone interested enough in this potential cmake feature to > join the development effort? > > Thanks, > > Steve. > > > * Provide basic daemon mode with event loop and communication protocol > -- Written, but not reviewed > * Provide protocol to query the buildsystem structure > -- Written, but not complete or reviewed > * Extend cmListFileParser to record location of start and end of commands > * Rewrite cmIfCommand to record which branches are executed > * Store the location of start and end of user-defined functions > * Provide protocol to query for unexecuted lines > * Define a new snapshot type to occur at an arbitrary point > * Create snapshots after branching to other files (after an include() or > find_package() or add_subdirectory etc) > * Create snapshots after points with external effects (file(WRITE), > configure_file(), execute_process etc) > * Find most recent snapshot occuring before a specified line > * Implement feature to start at a specific snapshot and execute commands > up to a particular line > * Make server find correct snapshot to start at and execute required > commands up to specified line > * Provide protocol to dump variable defintions at a particular line > * Extract implementation of IssueMessage from cmMakefile and > cmLocalGenerator into cmake > * Extract computed target properties from cmTarget::GetProperty into > cmComputedTargetProperties > * Implement cmGeneratorTarget::GetPro
[cmake-developers] Linked library paths
Hi, I need to get the linked libraries of a target. I was moving the code away from get_target_property to generator expressions that should get into a generated file, although I haven't managed yet. Is there any possibility to do that already? I've been thinking of adding something like a map function, so we can turn the target name we get from INTERFACE_LINK_LIBRARIES into a path, using the LOCATION property. Would that make sense? Otherwise, is it possible to properly get a function called right before cmake generation? Thanks, 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] Generating buildsystem metadata from CMake
On Sat, Apr 18, 2015 at 11:56 AM, Stephen Kelly wrote: > Stephen Kelly wrote: > >> The aim is to generate a structured file containing metadata relating the >> buildsystem. > > > I've been quiet on this thread for a while, so I think it is time for an > update. > > I became more ambitious in mid March and started prototyping a more-complete > design for CMake IDE integration. > > Instead of teaching CMake to generate a metadata file, I want to add a > server mode to CMake, so that IDEs can run the server in the build directory > and query it for buildsystem metadata, code completion, etc. It can be > implemented efficiently and it doesn't have to re-configure the build from > the beginning each time. A lot of things become possible with such a design, > but I'm being economic with details because I don't want to make promises I > don't deliver in the end, even though I have high confidence that I actually > can :). > > The good news is that I have done some proof of concept work on all aspects > of this, but I don't yet have one branch which contains all of the > individual proof of concepts combined. Doing this properly requires > refactoring CMake quite a bit, which I've already been doing for a while to > create a cmState class. > > The bad news is that because this is more ambitious, it will take more time > and will not be part of the CMake 3.3 release early this summer. I do > believe it can be implemented for the following release 3 months later > though. > > Here's some prior art in other tools: > > http://thread.gmane.org/gmane.comp.compilers.clang.devel/21780 > https://sourceware.org/gdb/onlinedocs/gdb/GDB_002fMI.html > http://thread.gmane.org/gmane.comp.lib.boost.build/26905 > > We can use JSON as the wire protocol, and we can talk about exactly what the > protocol will be once the refactoring of CMake is done (that will take some > more weeks). I'll post a more complete design proposal and my prototype at > that point too. > > 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 Hi Stephen, Is there any news on the subject? 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] Generating buildsystem metadata from CMake
On Sat, Mar 14, 2015 at 10:02 AM, Stephen Kelly wrote:
>
>
> On Saturday, March 14, 2015, Aleix Pol wrote:
>> On Wed, Mar 11, 2015 at 11:10 AM, Stephen Kelly
>> wrote:
>>> Hi,
>>>
>>> Following from the thread here:
>>>
>>>
>>> http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/focus=12394
>>>
>>> http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/focus=12650
>>>
>>> I'm starting to gather requirements and make sure the feature is
>>> well designed to satisfy the needs we're already aware of, and fits with
>>> the features CMake currently has.
>>>
>>> The aim is to generate a structured file containing metadata relating the
>>> buildsystem.
>>>
>>> To help with completing the design of this feature, I've written
>>> documentation (documentation driven design), and a unit test
>>> containing a CMakeLists.txt file which exercises many modern CMake
>>> features in the "generate-metadata" branch in my clone.
>>>
>>> Mostly the design I propose can be read in the documentation I wrote. I'm
>>> interested in any feedback.
>>>
>>>
>>> https://gitorious.org/cmake/steveires-cmake/source/generate-metadata:Tests/Metadata/CMakeLists.txt
>>>
>>> http://www.steveire.com/cmake-future/manual/cmake-metadata-generation.7.html
>>>
>>> I expect to require a few iterations to figure out what the metadata
>>> files
>>> should contain in the end. Note that there are already some differences
>>> between my design and Aleix's implementation, such as that my design
>>> proposes one metadata file per config. There are also some things
>>> missing like location, because it is not yet clear to me whether build
>>> or install locations are needed etc.
>>>
>>> The content of the metadata file is determined by the build properties,
>>> and
>>> is necessarily similar to the compile-related content created when
>>> generating the actual buildsystem. It additionally contains information
>>> about the output locations of build artifacts and information relating to
>>> the cmake description itself.
>>>
>>> Goals include:
>>>
>>> * Make it possible for IDEs to access the compile-related information for
>>> autocompletion and code navigation etc purposes.
>>>
>>> * Remove the need for IDEs to parse generated Makefiles or Ninja files to
>>> access compile-related information. The structure of those files is
>>> not
>>> 'stable', while the content of the metadata file is stable.
>>> http://thread.gmane.org/gmane.comp.programming.tools.cmake.user/48412
>>>
>>>
>>> http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/focus=11081
>>>
>>> * Remove the need for users to create a new build directory and new build
>>> in order to use or switch IDEs. QtCreator requires that
>>> the C::B 'extra generator is used as it parses compile information from
>>> that. Other 'extra generators' such as for eclipse, sublime, kate etc
>>> also require fresh/new build directories, although the actual
>>> buildsystem
>>> they create is identical (assuming using all Makefile based or
>>> all Ninja based 'extra generators')
>>>
>>> * Make it possible to write a plugin for the editors/IDEs such as sublime
>>> which consumes the metadata file and invokes the build using whatever
>>> buildsystem the user already has a build directory for, instead of
>>> writing an 'extra generator' and maintaining it in the cmake repo.
>>> http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/9004
>>>
>>> * Make it possible for editors/IDEs to allow specifying the configuration
>>> at build-time, where the IDE has that feature, and where a multi-config
>>> generator is available. That is, QtCreator provides user-interface for
>>> choosing debug/release config to build. Currently it can't offer that
>>> when using cmake, because it only allows the use of Makefile or Ninja
>>> generators, in order to make use of the C::B file. QtCreator should be
>>> able to use the Xcode or Visual Studio generators, generate the
>>> metadata
>>> file(s), and invoke `cmake --build . --config ${CONFIG}` as
>>> appropriate. Eclipse, Sublime and ot
Re: [cmake-developers] Generating buildsystem metadata from CMake
On Wed, Mar 11, 2015 at 11:10 AM, Stephen Kelly wrote:
> Hi,
>
> Following from the thread here:
>
>
> http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/focus=12394
>
> http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/focus=12650
>
> I'm starting to gather requirements and make sure the feature is
> well designed to satisfy the needs we're already aware of, and fits with
> the features CMake currently has.
>
> The aim is to generate a structured file containing metadata relating the
> buildsystem.
>
> To help with completing the design of this feature, I've written
> documentation (documentation driven design), and a unit test
> containing a CMakeLists.txt file which exercises many modern CMake
> features in the "generate-metadata" branch in my clone.
>
> Mostly the design I propose can be read in the documentation I wrote. I'm
> interested in any feedback.
>
>
> https://gitorious.org/cmake/steveires-cmake/source/generate-metadata:Tests/Metadata/CMakeLists.txt
> http://www.steveire.com/cmake-future/manual/cmake-metadata-generation.7.html
>
> I expect to require a few iterations to figure out what the metadata files
> should contain in the end. Note that there are already some differences
> between my design and Aleix's implementation, such as that my design
> proposes one metadata file per config. There are also some things
> missing like location, because it is not yet clear to me whether build
> or install locations are needed etc.
>
> The content of the metadata file is determined by the build properties, and
> is necessarily similar to the compile-related content created when
> generating the actual buildsystem. It additionally contains information
> about the output locations of build artifacts and information relating to
> the cmake description itself.
>
> Goals include:
>
> * Make it possible for IDEs to access the compile-related information for
> autocompletion and code navigation etc purposes.
>
> * Remove the need for IDEs to parse generated Makefiles or Ninja files to
> access compile-related information. The structure of those files is not
> 'stable', while the content of the metadata file is stable.
> http://thread.gmane.org/gmane.comp.programming.tools.cmake.user/48412
>
> http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/focus=11081
>
> * Remove the need for users to create a new build directory and new build
> in order to use or switch IDEs. QtCreator requires that
> the C::B 'extra generator is used as it parses compile information from
> that. Other 'extra generators' such as for eclipse, sublime, kate etc
> also require fresh/new build directories, although the actual buildsystem
> they create is identical (assuming using all Makefile based or
> all Ninja based 'extra generators')
>
> * Make it possible to write a plugin for the editors/IDEs such as sublime
> which consumes the metadata file and invokes the build using whatever
> buildsystem the user already has a build directory for, instead of
> writing an 'extra generator' and maintaining it in the cmake repo.
> http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/9004
>
> * Make it possible for editors/IDEs to allow specifying the configuration
> at build-time, where the IDE has that feature, and where a multi-config
> generator is available. That is, QtCreator provides user-interface for
> choosing debug/release config to build. Currently it can't offer that
> when using cmake, because it only allows the use of Makefile or Ninja
> generators, in order to make use of the C::B file. QtCreator should be
> able to use the Xcode or Visual Studio generators, generate the metadata
> file(s), and invoke `cmake --build . --config ${CONFIG}` as
> appropriate. Eclipse, Sublime and other editors have similar abilities
> to invoke config-specific builds after generation.
>
> * Provide a list of 'build targets', which can be listed and invoked in
> IDE/editor user interface. Build targets for all linked binaries
> and utilties are provided. The tooling is expected to perform filtering
> on the target types to show only executables and utilities for
> execution, for example.
>
> * Provide a list of source files per target per type of source file, eg
> object sources, header files, generated files, files excluded from the
> active configuration/platform/compiler, non-compiled files.
>
> * Make it more easy for an IDE to support actions such as 'remove file
> from the project', which requires removing it from the CMakeLists.txt
> at the appropriate place, and 'add new file/class to target', which
> involves adding code to the CMakeLists.txt file at the appropriate
> place. Most likely the easiest way to do the latter is using the
> target_sources() command, and to support the former, the location of
> the declaration of the target, and all target_sources() calls would
> need to b
Re: [cmake-developers] Extracting target metadata, IDE integration
Hi Tobias,
Thank you for taking some of your time.
On Sat, Mar 7, 2015 at 11:46 AM, Tobias Hunger wrote:
> 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?
Thats an LLVM code clone. It's a big CMake-based project, that's why I
chose it, that's all.
>
>> {
>
> 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).
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.
>
> 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?
Yes, also they are the files that will be providing the relevant
information for the current file. It can be important at some point.
>
>> "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?
Because it was built without specifying any name. (i.e. it didn't pass
-DCMAKE_BUILD_TYPE=...).
>
>>"output" :
>> "/home/kde-devel/tmp/llvm/build/lib/libLLVMPowerPCInfo.a",
>
> Can this be a list?
It's 1 output per target, no?
>
>>"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.
>
>>}
>>],
>>"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 structu
Re: [cmake-developers] Extracting target metadata, IDE integration
On Fri, Aug 29, 2014 at 4:20 AM, Aleix Pol wrote: > Dear cmake'rs, > I'm rewriting the KDevelop plugin from scratch to fetch the information from > the build directory. > > Now in the first implementation I'm using the compile_commands.json file > that cmake already can generate for some time. It works quite well already, > given how data just comes out ready to be consumed (almost). The problem now > is that we're lacking some information, namely information about the > targets, their location and such *. > > To that end, I wrote a little patch to be taken as a proof of concept, that > generates (some of) the needed information. I would like to know if you > think it's an approach that would be accepted in the cmake code-base or if I > need to take a different approach. > > Patch http://proli.net/meu/kdevelop/cmake-targetsdata.patch > Output: http://proli.net/meu/kdevelop/AwesomeTargets.json > > Cheers! > Aleix > > * Yes, I'm aware of generators, but I'm not comfortable with the idea of > tying a build directory to an editor (even if it's my editor). Our users > usually build the projects with different tools and asking them to re-create > their build only for being comfortable with KDevelop sometimes is a burden. > It would be for me too! I just pushed my change into a github clone for easier testing and reviewing. https://github.com/aleixpol/CMake Aleix -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Extracting target metadata, IDE integration
On Wed, Mar 4, 2015 at 9:05 PM, Brad King 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 $ 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 $. 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 Fri, Aug 29, 2014 at 4:20 AM, Aleix Pol wrote: > Dear cmake'rs, > I'm rewriting the KDevelop plugin from scratch to fetch the information from > the build directory. > > Now in the first implementation I'm using the compile_commands.json file > that cmake already can generate for some time. It works quite well already, > given how data just comes out ready to be consumed (almost). The problem now > is that we're lacking some information, namely information about the > targets, their location and such *. > > To that end, I wrote a little patch to be taken as a proof of concept, that > generates (some of) the needed information. I would like to know if you > think it's an approach that would be accepted in the cmake code-base or if I > need to take a different approach. > > Patch http://proli.net/meu/kdevelop/cmake-targetsdata.patch > Output: http://proli.net/meu/kdevelop/AwesomeTargets.json > > Cheers! > Aleix > > * Yes, I'm aware of generators, but I'm not comfortable with the idea of > tying a build directory to an editor (even if it's my editor). Our users > usually build the projects with different tools and asking them to re-create > their build only for being comfortable with KDevelop sometimes is a burden. > It would be for me too! I 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 Tue, Mar 3, 2015 at 2:15 AM, Aleix Pol wrote:
> On Mon, Feb 16, 2015 at 10:44 PM, Alexander Neundorf wrote:
>> On Monday, February 16, 2015 21:31:45 Aleix Pol wrote:
>>> On Sat, Feb 14, 2015 at 1:02 PM, Stephen Kelly 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.
>
> You are correct, it would be more useful indeed. Do you know how to
> get the value? I've been trying to figure it out but I can't find the
> correct method in cmTarget.
>
> Aleix
If I'm not correct this can be provided through
GetMakefile()->GetCurrentOutputDirectory(). I'll upload in a moment a
new version with this implemented (and some other things).
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 16, 2015 at 10:44 PM, Alexander Neundorf wrote:
> On Monday, February 16, 2015 21:31:45 Aleix Pol wrote:
>> On Sat, Feb 14, 2015 at 1:02 PM, Stephen Kelly 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.
You are correct, it would be more useful indeed. Do you know how to
get the value? I've been trying to figure it out but I can't find the
correct method in cmTarget.
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 Sat, Feb 14, 2015 at 1:02 PM, Stephen Kelly 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 Thu, Feb 5, 2015 at 6:03 PM, Aleix Pol wrote:
> On Mon, Feb 2, 2015 at 5:36 PM, Aleix Pol wrote:
>> On Mon, Jan 26, 2015 at 9:15 PM, Tobias Hunger
>> 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 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 wrote:
> On Mon, Jan 26, 2015 at 9:15 PM, Tobias Hunger
> 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 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 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 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 Tue, Jan 20, 2015 at 3:47 PM, Brad King 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
On Thu, Jan 8, 2015 at 5:42 PM, Anton Makeev wrote:
> Aleix Pol 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
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
Re: [cmake-developers] Extracting target metadata, IDE integration
On Tue, Dec 23, 2014 at 1:30 AM, Aleix Pol wrote: > On Thu, Sep 25, 2014 at 9:14 AM, 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. >> >> >> 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 t
Re: [cmake-developers] Extracting target metadata, IDE integration
On Thu, Sep 25, 2014 at 9:14 AM, 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. > > > 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
Re: [cmake-developers] Extracting target metadata, IDE integration
On Wed, Oct 15, 2014 at 1:46 AM, Aleix Pol wrote: > On Fri, Oct 3, 2014 at 3:52 PM, Rolf Eike Beer 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 Hi, 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 I have a working proof of concept in KDevelop already I'm quite happy with. Any thoughts? 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, Oct 3, 2014 at 3:52 PM, Rolf Eike Beer 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 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 . 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
On Wed, Sep 24, 2014 at 6:51 PM, Aleix Pol wrote:
> On Wed, Sep 24, 2014 at 3:55 PM, Brad King 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 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
On Wed, Sep 24, 2014 at 3:55 PM, Brad King 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 Fri, Sep 19, 2014 at 7:44 PM, Brad King 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 Mon, Sep 8, 2014 at 2:51 PM, Brad King 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 Wed, Sep 3, 2014 at 6:12 PM, Aleix Pol wrote: > On Wed, Sep 3, 2014 at 5:48 PM, Alexander Neundorf > wrote: > >> On Wednesday, September 03, 2014 12:30:21 Aleix Pol wrote: >> > On Tue, Sep 2, 2014 at 3:58 PM, David Cole 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 > Bump! Can I get some pointers about how to proceed? 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, Sep 3, 2014 at 5:48 PM, Alexander Neundorf wrote: > On Wednesday, September 03, 2014 12:30:21 Aleix Pol wrote: > > On Tue, Sep 2, 2014 at 3:58 PM, David Cole 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
On Tue, Sep 2, 2014 at 9:45 PM, Alexander Neundorf 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 Tue, Sep 2, 2014 at 3:58 PM, David Cole 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 1:03 PM, David Cole 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 Mon, Sep 1, 2014 at 9:26 PM, David Cole 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
Re: [cmake-developers] Extracting target metadata, IDE integration
On Fri, Aug 29, 2014 at 4:20 AM, Aleix Pol wrote: > Dear cmake'rs, > I'm rewriting the KDevelop plugin from scratch to fetch the information > from the build directory. > > Now in the first implementation I'm using the compile_commands.json file > that cmake already can generate for some time. It works quite well already, > given how data just comes out ready to be consumed (almost). The problem > now is that we're lacking some information, namely information about the > targets, their location and such *. > > To that end, I wrote a little patch to be taken as a proof of concept, > that generates (some of) the needed information. I would like to know if > you think it's an approach that would be accepted in the cmake code-base or > if I need to take a different approach. > > Patch http://proli.net/meu/kdevelop/cmake-targetsdata.patch > Output: http://proli.net/meu/kdevelop/AwesomeTargets.json > > Cheers! > Aleix > > * Yes, I'm aware of generators, but I'm not comfortable with the idea of > tying a build directory to an editor (even if it's my editor). Our users > usually build the projects with different tools and asking them to > re-create their build only for being comfortable with KDevelop sometimes is > a burden. It would be for me too! > 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
[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
Re: [cmake-developers] Improving GraphViz output, clustering
On Mon, Sep 16, 2013 at 10:03 PM, Alexander Neundorf wrote: > On Monday 16 September 2013, Aleix Pol wrote: > > On Mon, Sep 16, 2013 at 7:39 PM, Aleix Pol wrote: > > > Hi, > > > I've been trying to get a good outlook of the internal dependencies of > > > one of our projects (KDE Frameworks 5). > > > > > > One thing that I've found useful is adding clustering to external > > > dependencies that, while needed in the graph, having them grouped as a > > > separate entity is desirable. > > > > > > Attached, I'm providing a patch that adds this functionality. I hope > you > > > find it useful. > > > > > > Aleix > > > > And of course, I forgot the attachment. :) > > Hmm, I still don't see the attachement... > > Alex > I uploaded the patch, gmail seems to hate me today... My apologies. http://proli.net/meu/kde/cmake-clusteredgraphs.patch Aleix -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] Improving GraphViz output, clustering
Hi, I've been trying to get a good outlook of the internal dependencies of one of our projects (KDE Frameworks 5). One thing that I've found useful is adding clustering to external dependencies that, while needed in the graph, having them grouped as a separate entity is desirable. Attached, I'm providing a patch that adds this functionality. I hope you find it useful. Aleix -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Improving GraphViz output, clustering
On Mon, Sep 16, 2013 at 7:39 PM, Aleix Pol wrote: > Hi, > I've been trying to get a good outlook of the internal dependencies of one > of our projects (KDE Frameworks 5). > > One thing that I've found useful is adding clustering to external > dependencies that, while needed in the graph, having them grouped as a > separate entity is desirable. > > Attached, I'm providing a patch that adds this functionality. I hope you > find it useful. > > Aleix > > > And of course, I forgot the attachment. :) Aleix -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
