from:"Aleix Pol"

Re: [cmake-developers] [Qt-creator] CMake daemon for user tools

2016-02-18 Thread Aleix Pol

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

2016-01-11 Thread Aleix Pol

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

[cmake-developers] Linked library paths

2015-07-30 Thread Aleix Pol

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

2015-07-25 Thread Aleix Pol

On Sat, Apr 18, 2015 at 11:56 AM, Stephen Kelly steve...@gmail.com 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

2015-03-14 Thread Aleix Pol

On Sat, Mar 14, 2015 at 10:02 AM, Stephen Kelly steve...@gmail.com wrote:

On Saturday, March 14, 2015, Aleix Pol aleix...@kde.org wrote:
On Wed, Mar 11, 2015 at 11:10 AM, Stephen Kelly steve...@gmail.com
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

Re: [cmake-developers] Generating buildsystem metadata from CMake

2015-03-13 Thread Aleix Pol

On Wed, Mar 11, 2015 at 11:10 AM, Stephen Kelly steve...@gmail.com 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.

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 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.

Re: [cmake-developers] Extracting target metadata, IDE integration

2015-03-07 Thread Aleix Pol

On Fri, Aug 29, 2014 at 4:20 AM, Aleix Pol aleix...@kde.org wrote:
 Dear cmake'rs,
 I'm rewriting the KDevelop plugin from scratch to fetch the information from
 the build directory.

 Now in the first implementation I'm using the compile_commands.json file
 that cmake already can generate for some time. It works quite well already,
 given how data just comes out ready to be consumed (almost). The problem now
 is that we're lacking some information, namely information about the
 targets, their location and such *.

 To that end, I wrote a little patch to be taken as a proof of concept, that
 generates (some of) the needed information. I would like to know if you
 think it's an approach that would be accepted in the cmake code-base or if I
 need to take a different approach.

 Patch http://proli.net/meu/kdevelop/cmake-targetsdata.patch
 Output: http://proli.net/meu/kdevelop/AwesomeTargets.json

 Cheers!
 Aleix

 * Yes, I'm aware of generators, but I'm not comfortable with the idea of
 tying a build directory to an editor (even if it's my editor). Our users
 usually build the projects with different tools and asking them to re-create
 their build only for being comfortable with KDevelop sometimes is a burden.
 It would be for me too!

I just pushed my change into a github clone for easier testing and reviewing.
https://github.com/aleixpol/CMake

Aleix
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] Extracting target metadata, IDE integration

2015-03-06 Thread Aleix Pol

On Wed, Mar 4, 2015 at 9:05 PM, Brad King brad.k...@kitware.com wrote:
On 03/02/2015 09:10 PM, Aleix Pol wrote:
I created a new version of the patch:
http://proli.net/meu/kdevelop/0001-cmake-Add-option-to-generate-target-metadata-for-IDE-v2.patch

Thanks.

Samples:
LLVM: https://paste.kde.org/pelr1ditp
A small random KDE project: https://paste.kde.org/pgkbecv5p

The location values need to be inside the configs elements because
they can vary with the configuration in multi-config generators.
Also the name location may not be specific enough. Some targets
may have multiple output files (e.g. .dll, .lib). See the breakdown
of $TARGET*FILE:... generator expressions:

http://www.cmake.org/cmake/help/v3.2/manual/cmake-generator-expressions.7.html#informational-expressions

Some set of values like that will be more useful.
Good point, I changed it to use $TARGET_FILE:tgt. Showing a
directory didn't make much sense anyway as we have more information
with the full file path.

If the the directory value is GetCurrentOutputDirectory, the
build tree location of the project file, then that does not need
to be per-configuration. In that case perhaps the name should be
something like build_directory or project_directory.
Used output_directory to match internal cmake naming.

https://paste.kde.org/p5ogjqi2n
https://paste.kde.org/puzgrgkzy

And the new version of the patch (sorry my hosting seems down and I
can't connect).
https://paste.kde.org/pq0xungvq

Aleix
--

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

2015-03-02 Thread Aleix Pol

On Fri, Aug 29, 2014 at 4:20 AM, Aleix Pol aleix...@kde.org wrote:
Dear cmake'rs,
I'm rewriting the KDevelop plugin from scratch to fetch the information from
the build directory.

Now in the first implementation I'm using the compile_commands.json file
that cmake already can generate for some time. It works quite well already,
given how data just comes out ready to be consumed (almost). The problem now
is that we're lacking some information, namely information about the
targets, their location and such *.

To that end, I wrote a little patch to be taken as a proof of concept, that
generates (some of) the needed information. I would like to know if you
think it's an approach that would be accepted in the cmake code-base or if I
need to take a different approach.

Patch http://proli.net/meu/kdevelop/cmake-targetsdata.patch
Output: http://proli.net/meu/kdevelop/AwesomeTargets.json

Cheers!
Aleix

* Yes, I'm aware of generators, but I'm not comfortable with the idea of
tying a build directory to an editor (even if it's my editor). Our users
usually build the projects with different tools and asking them to re-create
their build only for being comfortable with KDevelop sometimes is a burden.
It would be for me too!

I created a new version of the patch:
http://proli.net/meu/kdevelop/0001-cmake-Add-option-to-generate-target-metadata-for-IDE-v2.patch

Main differences are:
* Uses JsonCpp to generate json (makes the code much easier to read!).
* Adds a CMAKE_EXPORT_PROJECT_METADATA.rst file for documentation.
* Adds a test that checks some of the parameters in the file.
* Uses for directory the directory where the target was generated
rather than the output directory.

I hope this helps.
Aleix

Samples:
LLVM: https://paste.kde.org/pelr1ditp
A small random KDE project: https://paste.kde.org/pgkbecv5p
--

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

2015-02-16 Thread Aleix Pol

On Sat, Feb 14, 2015 at 1:02 PM, Stephen Kelly steve...@gmail.com wrote:
 Aleix Pol wrote:

 Hi guys,
 It's been since August with this. I understand we're all busy but this
 step is important for KDevelop as well as for other IDE's and I
 wouldn't like this to rot.

 Please, let's keep it moving forward.

 As far as I'm aware, it needs to move forward from this point:

  
 http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/focus=12151

 I'm not certain the design is finished (eg what the file should contain now
 or eventually). I asked for tests/documentation as a way to trigger getting
 the design finished. Having either would give us a list of use-cases and we
 would know what's in scope and what's not in scope (eg whether compile
 options/link options are in scope and why).
I can look further into documentation, if that's what holding us back.


 Another question: do you have any opinion about whether this should be one
 global file or one file per directory? I don't know - it seems like
 something that might or might not be relevant for tooling. Is the size of
 the generated file a consideration?
I think the best is to have it all in 1 directory. You don't really
want to have watchers on many files over there.


 How well does this feature work with large projects like VTK or a combined
 build of LLVM/Clang/lldb/libcxx/other ll projects.

I just generated the file for LLVM: https://paste.kde.org/pxl8ozwah
It's a 127KiB file, I don't think it's too mental considering it's a
330 MiB repository.

Aleix
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] Extracting target metadata, IDE integration

2015-02-13 Thread Aleix Pol

On Thu, Feb 5, 2015 at 6:03 PM, Aleix Pol aleix...@kde.org wrote:
 On Mon, Feb 2, 2015 at 5:36 PM, Aleix Pol aleix...@kde.org wrote:
 On Mon, Jan 26, 2015 at 9:15 PM, Tobias Hunger tobias.hun...@gmail.com 
 wrote:
 I gave this patch a try with the cmake project data.

 I had hoped that this file would contain all the information an IDE
 might need, but there seems quite a bit missing for that. E.g. there
 is no information on which files are used to build a target. What am I
 missing?

 Best Regards,
 Tobias

 On Mon, Jan 26, 2015 at 4:23 PM, Brad King brad.k...@kitware.com wrote:
 On 01/25/2015 08:26 AM, Tobias Hunger wrote:
 I just had a bit of time to play with cmake this weekend: Is this
 patch available somewhere by now?

 Aleix sent it in a message of this thread on 2015-01-09:

  
 http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/focus=12061

 Some review comments elsewhere in this thread are still pending.

 -Brad


 It does provide them. For example [1].

 Isn't that what you meant?

 Aleix

 [1]
 {
  name: kdevcmakebuilder,
  type: MODULE_LIBRARY,
  configs: [
{
  name: debug,
  sources: [

 /home/kde-devel/frameworks/kdevelop/projectbuilders/cmakebuilder/cmakebuilder.cpp,

 /home/kde-devel/frameworks/kdevelop/projectbuilders/cmakebuilder/cmakejob.cpp,

 /home/kde-devel/frameworks/kdevelop/projectbuilders/cmakebuilder/prunejob.cpp,

 /home/kde-devel/frameworks/kdevelop/projectbuilders/cmakebuilder/cmakebuilderpreferences.cpp,

 /home/kde-devel/build-frameworks/kdevelop/projectbuilders/cmakebuilder/ui_cmakebuildersettings.h,

 /home/kde-devel/build-frameworks/kdevelop/projectbuilders/cmakebuilder/cmakebuilderconfig.cpp,

 /home/kde-devel/build-frameworks/kdevelop/projectbuilders/cmakebuilder/cmakebuilderconfig.h,

 /home/kde-devel/build-frameworks/kdevelop/projectbuilders/cmakebuilder/kdevcmakebuilder_automoc.cpp,

 /home/kde-devel/frameworks/kdevelop/projectbuilders/cmakebuilder/cmakebuildersettings.ui,

 /home/kde-devel/frameworks/kdevelop/projectbuilders/cmakebuilder/cmakebuilderconfig.kcfgc
  ]
}
  ],
  directory:
 /home/kde-devel/build-frameworks/kdevelop/projectbuilders/cmakebuilder,
  location:
 /home/kde-devel/build-frameworks/kdevelop/projectbuilders/cmakebuilder/kdevcmakebuilder.so,
  backtrace:
 [/home/kde-devel/frameworks/kdevelop/projectbuilders/cmakebuilder/CMakeLists.txt:20],
  installed: true
}

 Bump?

 Aleix

Hi guys,
It's been since August with this. I understand we're all busy but this
step is important for KDevelop as well as for other IDE's and I
wouldn't like this to rot.

Please, let's keep it moving forward.
Aleix
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] Extracting target metadata, IDE integration

2015-02-05 Thread Aleix Pol

On Mon, Feb 2, 2015 at 5:36 PM, Aleix Pol aleix...@kde.org wrote:
 On Mon, Jan 26, 2015 at 9:15 PM, Tobias Hunger tobias.hun...@gmail.com 
 wrote:
 I gave this patch a try with the cmake project data.

 I had hoped that this file would contain all the information an IDE
 might need, but there seems quite a bit missing for that. E.g. there
 is no information on which files are used to build a target. What am I
 missing?

 Best Regards,
 Tobias

 On Mon, Jan 26, 2015 at 4:23 PM, Brad King brad.k...@kitware.com wrote:
 On 01/25/2015 08:26 AM, Tobias Hunger wrote:
 I just had a bit of time to play with cmake this weekend: Is this
 patch available somewhere by now?

 Aleix sent it in a message of this thread on 2015-01-09:

  
 http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/focus=12061

 Some review comments elsewhere in this thread are still pending.

 -Brad


 It does provide them. For example [1].

 Isn't that what you meant?

 Aleix

 [1]
 {
  name: kdevcmakebuilder,
  type: MODULE_LIBRARY,
  configs: [
{
  name: debug,
  sources: [

 /home/kde-devel/frameworks/kdevelop/projectbuilders/cmakebuilder/cmakebuilder.cpp,

 /home/kde-devel/frameworks/kdevelop/projectbuilders/cmakebuilder/cmakejob.cpp,

 /home/kde-devel/frameworks/kdevelop/projectbuilders/cmakebuilder/prunejob.cpp,

 /home/kde-devel/frameworks/kdevelop/projectbuilders/cmakebuilder/cmakebuilderpreferences.cpp,

 /home/kde-devel/build-frameworks/kdevelop/projectbuilders/cmakebuilder/ui_cmakebuildersettings.h,

 /home/kde-devel/build-frameworks/kdevelop/projectbuilders/cmakebuilder/cmakebuilderconfig.cpp,

 /home/kde-devel/build-frameworks/kdevelop/projectbuilders/cmakebuilder/cmakebuilderconfig.h,

 /home/kde-devel/build-frameworks/kdevelop/projectbuilders/cmakebuilder/kdevcmakebuilder_automoc.cpp,

 /home/kde-devel/frameworks/kdevelop/projectbuilders/cmakebuilder/cmakebuildersettings.ui,

 /home/kde-devel/frameworks/kdevelop/projectbuilders/cmakebuilder/cmakebuilderconfig.kcfgc
  ]
}
  ],
  directory:
 /home/kde-devel/build-frameworks/kdevelop/projectbuilders/cmakebuilder,
  location:
 /home/kde-devel/build-frameworks/kdevelop/projectbuilders/cmakebuilder/kdevcmakebuilder.so,
  backtrace:
 [/home/kde-devel/frameworks/kdevelop/projectbuilders/cmakebuilder/CMakeLists.txt:20],
  installed: true
}

Bump?

Aleix
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] Extracting target metadata, IDE integration

2015-02-02 Thread Aleix Pol

On Mon, Jan 26, 2015 at 9:15 PM, Tobias Hunger tobias.hun...@gmail.com wrote:
 I gave this patch a try with the cmake project data.

 I had hoped that this file would contain all the information an IDE
 might need, but there seems quite a bit missing for that. E.g. there
 is no information on which files are used to build a target. What am I
 missing?

 Best Regards,
 Tobias

 On Mon, Jan 26, 2015 at 4:23 PM, Brad King brad.k...@kitware.com wrote:
 On 01/25/2015 08:26 AM, Tobias Hunger wrote:
 I just had a bit of time to play with cmake this weekend: Is this
 patch available somewhere by now?

 Aleix sent it in a message of this thread on 2015-01-09:

  
 http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/focus=12061

 Some review comments elsewhere in this thread are still pending.

 -Brad


It does provide them. For example [1].

Isn't that what you meant?

Aleix

[1]
{
 name: kdevcmakebuilder,
 type: MODULE_LIBRARY,
 configs: [
   {
 name: debug,
 sources: [
   
/home/kde-devel/frameworks/kdevelop/projectbuilders/cmakebuilder/cmakebuilder.cpp,
   
/home/kde-devel/frameworks/kdevelop/projectbuilders/cmakebuilder/cmakejob.cpp,
   
/home/kde-devel/frameworks/kdevelop/projectbuilders/cmakebuilder/prunejob.cpp,
   
/home/kde-devel/frameworks/kdevelop/projectbuilders/cmakebuilder/cmakebuilderpreferences.cpp,
   
/home/kde-devel/build-frameworks/kdevelop/projectbuilders/cmakebuilder/ui_cmakebuildersettings.h,
   
/home/kde-devel/build-frameworks/kdevelop/projectbuilders/cmakebuilder/cmakebuilderconfig.cpp,
   
/home/kde-devel/build-frameworks/kdevelop/projectbuilders/cmakebuilder/cmakebuilderconfig.h,
   
/home/kde-devel/build-frameworks/kdevelop/projectbuilders/cmakebuilder/kdevcmakebuilder_automoc.cpp,
   
/home/kde-devel/frameworks/kdevelop/projectbuilders/cmakebuilder/cmakebuildersettings.ui,
   
/home/kde-devel/frameworks/kdevelop/projectbuilders/cmakebuilder/cmakebuilderconfig.kcfgc
 ]
   }
 ],
 directory:
/home/kde-devel/build-frameworks/kdevelop/projectbuilders/cmakebuilder,
 location:
/home/kde-devel/build-frameworks/kdevelop/projectbuilders/cmakebuilder/kdevcmakebuilder.so,
 backtrace:
[/home/kde-devel/frameworks/kdevelop/projectbuilders/cmakebuilder/CMakeLists.txt:20],
 installed: true
   }
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] Extracting target metadata, IDE integration

2015-01-20 Thread Aleix Pol

On Tue, Jan 20, 2015 at 3:47 PM, Brad King brad.k...@kitware.com wrote:
On 12/18/2014 09:02 PM, Aleix Pol wrote:
I would like to propose this as a final version of this patch.
http://proli.net/meu/kdevelop/0001-cmake-Add-option-to-generate-target-metadata-for-IDE.patch

For reference, this was also attached in a later message of this
thread on 2015-01-09:

http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/focus=12061

I have a working proof of concept in KDevelop already I'm quite happy with.

Can you post a link to that implementation so others may try it?
It can be found by:
git clone git://anongit.kde.org/kdevelop -b cmakePossibleTargetsFile

https://projects.kde.org/projects/extragear/kdevelop/kdevelop/repository/show?rev=cmakePossibleTargetsFile

Steve K. posted a review of your patch on 2014-12-19:

http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/focus=11972

that has not yet received a response.
Will look into these tonight.

Also, for unrelated reasons we've now added JsonCpp into the CMake
build process. You could consider using that to write the .json
file so that no manual formatting or escaping code is needed.
The current patch does not add potentially needed json escapes.

I will consider to.

Aleix
--

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

2015-01-08 Thread Aleix Pol

On Thu, Jan 8, 2015 at 5:42 PM, Anton Makeev anton.mak...@jetbrains.com wrote:
 Aleix Pol aleixpol@... writes:



 I'd really appreciate your feedback on the patch I provided, I'll be
 happy to provide the information you miss.
 Aleix

 Aleix, could you please point me to the most recent patch version?








 --

 Powered by www.kitware.com

 Please keep messages on-topic and check the CMake FAQ at: 
 http://www.cmake.org/Wiki/CMake_FAQ

 Kitware offers various services to support the CMake community. For more 
 information on each offering, please visit:

 CMake Support: http://cmake.org/cmake/help/support.html
 CMake Consulting: http://cmake.org/cmake/help/consulting.html
 CMake Training Courses: http://cmake.org/cmake/help/training.html

 Visit other Kitware open-source projects at 
 http://www.kitware.com/opensource/opensource.html

 Follow this link to subscribe/unsubscribe:
 http://public.kitware.com/mailman/listinfo/cmake-developers

I'll attach it in this e-mail, to make sure it reaches.

Aleix

PS: there's no changes system for cmake  like reviewboard, is there?
From 806d6788ca93b5dbd0dc6e25947c07f149f64a38 Mon Sep 17 00:00:00 2001
From: Aleix Pol aleix...@kde.org
Date: Mon, 6 Oct 2014 17:35:31 +0200
Subject: [PATCH] cmake: Add option to generate target metadata for IDEs

Create a CMAKE_EXPORT_PROJECT_METADATA option that can be used to enable
generation of a 'ProjectTargets.json' file.  Write into the file a JSON
description of the build targets that an IDE might load.
---
 Modules/CMakeGenericSystem.cmake |   5 ++
 Source/cmGlobalGenerator.cxx | 133 ++-
 Source/cmGlobalGenerator.h   |   1 +
 3 files changed, 137 insertions(+), 2 deletions(-)

diff --git a/Modules/CMakeGenericSystem.cmake b/Modules/CMakeGenericSystem.cmake
index 8a14aea..0e7f48a 100644
--- a/Modules/CMakeGenericSystem.cmake
+++ b/Modules/CMakeGenericSystem.cmake
@@ -67,6 +67,11 @@ if(CMAKE_GENERATOR MATCHES Ninja)
   mark_as_advanced(CMAKE_EXPORT_COMPILE_COMMANDS)
 endif()
 
+set(CMAKE_EXPORT_PROJECT_METADATA  CACHE STRING
+Enables the output of a ProjectTargets.json file during generation when a version is provided.
+)
+mark_as_advanced(CMAKE_EXPORT_PROJECT_METADATA)
+
 # GetDefaultWindowsPrefixBase
 #
 # Compute the base directory for CMAKE_INSTALL_PREFIX based on:
diff --git a/Source/cmGlobalGenerator.cxx b/Source/cmGlobalGenerator.cxx
index dd7fbc8..7fef858 100644
--- a/Source/cmGlobalGenerator.cxx
+++ b/Source/cmGlobalGenerator.cxx
@@ -2899,6 +2899,7 @@ void cmGlobalGenerator::WriteRuleHashes(std::string const pfile)
 }
 
 //
+
 void cmGlobalGenerator::WriteSummary()
 {
   cmMakefile* mf = this-LocalGenerators[0]-GetMakefile();
@@ -2908,8 +2909,6 @@ void cmGlobalGenerator::WriteSummary()
   fname += cmake::GetCMakeFilesDirectory();
   fname += /TargetDirectories.txt;
   cmGeneratedFileStream fout(fname.c_str());
-
-  // Generate summary information files for each target.
   for(TargetMap::const_iterator ti =
 this-TotalTargets.begin(); ti != this-TotalTargets.end(); ++ti)
 {
@@ -2920,6 +2919,136 @@ void cmGlobalGenerator::WriteSummary()
 this-WriteSummary(ti-second);
 fout  ti-second-GetSupportDirectory()  \n;
 }
+
+  const char* version = mf-GetDefinition(CMAKE_EXPORT_PROJECT_METADATA);
+  if(version  *version)
+{
+  if (std::string(version) == 1.0)
+WriteProjectTargetsJson();
+  else
+cmSystemTools::Error(
+  Generator implementation error, 
+  Unknown export metadata version.);
+}
+}
+
+void printBacktraceJson(const cmListFileBacktrace bt, cmGeneratedFileStream stream)
+{
+  stream  '[';
+  for(cmListFileBacktrace::const_iterator it = bt.begin(); it!=bt.end(); ++it)
+{
+  const cmListFileContext ctx = *it;
+
+  if(it!=bt.begin())
+stream  , ;
+
+  stream  '\';
+  stream  ctx.FilePath;
+  stream  ':';
+  stream  ctx.Line;
+  stream  '\';
+}
+  stream  ']';
+}
+
+void cmGlobalGenerator::WriteProjectTargetsJson()
+{
+  cmMakefile* mf = this-LocalGenerators[0]-GetMakefile();
+  std::string projectTargetsPath = mf-GetHomeOutputDirectory();
+  projectTargetsPath += /ProjectTargets.json;
+  cmGeneratedFileStream aout(projectTargetsPath.c_str());
+  aout 
+{\n
+  \version\: \  cmVersion::GetCMakeVersion()  \,\n
+  \dependencies\: [\n
+;
+
+  for(std::vectorcmLocalGenerator*::const_iterator i =
+this-LocalGenerators.begin(); i != this-LocalGenerators.end(); ++i)
+{
+std::vectorstd::string const lf = (*i)-GetMakefile()-GetListFiles();
+for(std::vectorstd::string::const_iterator fi = lf.begin();
+fi != lf.end(); ++fi)
+  {
+  bool last = (fi+1) == lf.end()  (i+1) == this-LocalGenerators.end();
+  aout  \  *fi  (last ? \\n : \,\n);
+  }
+}
+  aout 
+  ],\n
+  \targets\: [\n
+;
+
+  // Generate summary

Re: [cmake-developers] Extracting target metadata, IDE integration

2014-12-22 Thread Aleix Pol

On Thu, Sep 25, 2014 at 9:14 AM, Anton Makeev
anton.mak...@jetbrains.com wrote:
 Hey everyone,

 We are developing CLion at JetBrains that utilizes CMake as its main project
 model. Stephen Kelly timely drew our attention to this discussion, and I’d 
 like
 to share some thoughts. Here are the general ones and I’ll also comment on
 separate messages in the thread.


 We’ve managed to get almost all the necessary project information,
 using ‘GNU/MinGW Makefiles’ generators:

 * list of targets comes from 'CMakeFiles/TargetDirectories.txt'
 * list of source files from ‘CMakeFiles/A.dir/DependInfo.cmake’
 * list of headers and resources from ‘codeblocks.cbp’ file
 * per-file/target compiler and its flags from 
 ‘CMakeFiles/Target.dir/flags.make’
 * location of product files from ‘CMakeFiles/Target.dir/build.make’


 What we miss (not all of them are directly related the targets metadata,
 but I'd like to share anyway since the topic is about IDE integration):

 * Location of every source file and target in CMakeLists
   - it would greatly help to refactorings, navigation etc.
In the implementation I'm proposing, the target is specified. The file
is hard to figure out given that it's passed as a string argument and
it could come virtually from anywhere (i.e. glob, operations, a set()
somewhere else, etc.). My conclusion is that knowing the target
position is already a good enough help.

 * Complete list of headers and resource files
   - they are only listed in special generators like code blocks.
I'll look into it, what do you need exactly? The headers in each target?

 * An easily parseable list of errors and warnings with origin information.
   At the moment we parse error output but not everything can be parsed 
 reliably.
Agreed, It's something we're missing as well. I also don't really like
the fact that sometimes the paths are absolute and sometimes they're
relative, especially in the relative case, since it's hard to tell if
it's relative to the build directory or source directory.

 * No progress indication. Since the generation may take several minutes,
   providing feedback is crucial.
I never found such case, I would argue that a project which has a
cmake script that takes several minutes is broken, but maybe we can
open a thread to discuss it?

 * Ability to distinguish a library from an executable target.
   This will help to offer a better UI for run/debug configurations.
It's included in the proposed implementation.

 * Possibility to collect information for every build target in one run.
   Currently, we have to invoke generator for every CMAKE_BUILT_TYPE 
 separately.
Well, that's because you use CodeBlocks generators. It seems like for
example in MSVC they generate many build configurations at once. This
implementation supports having parallel debug/release builds. Then we
can fix make/ninja generators or even create new ones.

 * CMake stops processing when it find a missing file, so that IDE cannot have
   full project model, until this files is created.
Well, it's related to the error generation issue we discussed. I think
it's something we should discuss in parallel.

 * When there are existing in-source generated files in the project dir,
   CMake doesn't allow generating into a separate out-of-source folder.
   An IDE has to invent workarounds here.
Arguably, in-source generation is broken by definition...

 * Not sure if it’s possible at all - a lightweight phase where CMake only
   collects necessary information (list of files/targets, compiler settings).
   This will help IDE react to the changes much faster.
That would be extra-cool, agreed. Maybe it's an iteration we can
consider in the future.



 Here is why I think the discussed functionality should not be a separate
 generator:

 CLion doesn’t have it’s own project model nor is intended as build tool
 replacement. Currently, the only option for CLion users is makefiles build, 
 that
 is not a best option for everyone: there is a good and fast alternative 
 ‘Ninja’.
 Ideally, users should be able to choose whatever tool better suites them.

 The problem is that the generated Makefiles are used both, for internal needs,
 like reading project structure, and also to build and run the user’s program.
 If we wanted to support Ninja generator, we would need to rewrite all the 
 logic
 that retrieves the project information, using the files that are created by
 Ninja generator. While I suppose it’s possible, it’s not the best option - 
 very
 error prone and resource demanding.

 If CMake generated a separate descriptor, regardless the generator used
 (Makefiles, Ninja), it would be much easier to support; and the users will
 benefit from better, more reliable and faster CMake integration in an IDE.

I'd really appreciate your feedback on the patch I provided, I'll be
happy to provide the information you miss.

Aleix
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at:

Re: [cmake-developers] Extracting target metadata, IDE integration

2014-12-22 Thread Aleix Pol

On Tue, Dec 23, 2014 at 1:30 AM, Aleix Pol aleix...@kde.org wrote:
 On Thu, Sep 25, 2014 at 9:14 AM, Anton Makeev
 anton.mak...@jetbrains.com wrote:
 Hey everyone,

 We are developing CLion at JetBrains that utilizes CMake as its main project
 model. Stephen Kelly timely drew our attention to this discussion, and I’d 
 like
 to share some thoughts. Here are the general ones and I’ll also comment on
 separate messages in the thread.


 We’ve managed to get almost all the necessary project information,
 using ‘GNU/MinGW Makefiles’ generators:

 * list of targets comes from 'CMakeFiles/TargetDirectories.txt'
 * list of source files from ‘CMakeFiles/A.dir/DependInfo.cmake’
 * list of headers and resources from ‘codeblocks.cbp’ file
 * per-file/target compiler and its flags from 
 ‘CMakeFiles/Target.dir/flags.make’
 * location of product files from ‘CMakeFiles/Target.dir/build.make’


 What we miss (not all of them are directly related the targets metadata,
 but I'd like to share anyway since the topic is about IDE integration):

 * Location of every source file and target in CMakeLists
   - it would greatly help to refactorings, navigation etc.
 In the implementation I'm proposing, the target is specified. The file
 is hard to figure out given that it's passed as a string argument and
 it could come virtually from anywhere (i.e. glob, operations, a set()
 somewhere else, etc.). My conclusion is that knowing the target
 position is already a good enough help.

 * Complete list of headers and resource files
   - they are only listed in special generators like code blocks.
 I'll look into it, what do you need exactly? The headers in each target?

 * An easily parseable list of errors and warnings with origin information.
   At the moment we parse error output but not everything can be parsed 
 reliably.
 Agreed, It's something we're missing as well. I also don't really like
 the fact that sometimes the paths are absolute and sometimes they're
 relative, especially in the relative case, since it's hard to tell if
 it's relative to the build directory or source directory.

 * No progress indication. Since the generation may take several minutes,
   providing feedback is crucial.
 I never found such case, I would argue that a project which has a
 cmake script that takes several minutes is broken, but maybe we can
 open a thread to discuss it?

 * Ability to distinguish a library from an executable target.
   This will help to offer a better UI for run/debug configurations.
 It's included in the proposed implementation.

 * Possibility to collect information for every build target in one run.
   Currently, we have to invoke generator for every CMAKE_BUILT_TYPE 
 separately.
 Well, that's because you use CodeBlocks generators. It seems like for
 example in MSVC they generate many build configurations at once. This
 implementation supports having parallel debug/release builds. Then we
 can fix make/ninja generators or even create new ones.

 * CMake stops processing when it find a missing file, so that IDE cannot have
   full project model, until this files is created.
 Well, it's related to the error generation issue we discussed. I think
 it's something we should discuss in parallel.

 * When there are existing in-source generated files in the project dir,
   CMake doesn't allow generating into a separate out-of-source folder.
   An IDE has to invent workarounds here.
 Arguably, in-source generation is broken by definition...

 * Not sure if it’s possible at all - a lightweight phase where CMake only
   collects necessary information (list of files/targets, compiler settings).
   This will help IDE react to the changes much faster.
 That would be extra-cool, agreed. Maybe it's an iteration we can
 consider in the future.



 Here is why I think the discussed functionality should not be a separate
 generator:

 CLion doesn’t have it’s own project model nor is intended as build tool
 replacement. Currently, the only option for CLion users is makefiles build, 
 that
 is not a best option for everyone: there is a good and fast alternative 
 ‘Ninja’.
 Ideally, users should be able to choose whatever tool better suites them.

 The problem is that the generated Makefiles are used both, for internal 
 needs,
 like reading project structure, and also to build and run the user’s program.
 If we wanted to support Ninja generator, we would need to rewrite all the 
 logic
 that retrieves the project information, using the files that are created by
 Ninja generator. While I suppose it’s possible, it’s not the best option - 
 very
 error prone and resource demanding.

 If CMake generated a separate descriptor, regardless the generator used
 (Makefiles, Ninja), it would be much easier to support; and the users will
 benefit from better, more reliable and faster CMake integration in an IDE.

 I'd really appreciate your feedback on the patch I provided, I'll be
 happy to provide the information you miss.

 Aleix

By the way, I just

Re: [cmake-developers] Extracting target metadata, IDE integration

2014-10-14 Thread Aleix Pol

On Fri, Oct 3, 2014 at 3:52 PM, Rolf Eike Beer e...@sf-mail.de wrote:

 Brad King wrote:
  On 10/01/2014 07:46 PM, Aleix Pol wrote:
   I'm very interested in getting this in and iterating forward.
  
   Any comments? How do changes get integrated?
 
  My main concern is that the format has not been proven with a
  corresponding implementation of an actual IDE/plugin to use it.
  Once we start producing a format changing it later will be
  problematic for compatibility.  Even though we added a version
  number to the file, an IDE might not be updated along with a
  CMake that produces a newer version.

 This probably needs a way to query for the IDE which versions the given
 CMake
 version supports, no? Otherwise a newer IDE may request version 3 and just
 get
 nothing because the CMake binary only supports 1 and 2.

 Eike
 --


If it's not available then it should just error out.

Aleix

PS: I'm alive, working on this, when I get some free time
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] Extracting target metadata, IDE integration

2014-10-03 Thread Aleix Pol

On Thu, Oct 2, 2014 at 2:43 PM, Brad King brad.k...@kitware.com wrote:

 On 10/01/2014 07:46 PM, Aleix Pol wrote:
  I'm very interested in getting this in and iterating forward.
 
  Any comments? How do changes get integrated?

 My main concern is that the format has not been proven with a
 corresponding implementation of an actual IDE/plugin to use it.
 Once we start producing a format changing it later will be
 problematic for compatibility.  Even though we added a version
 number to the file, an IDE might not be updated along with a
 CMake that produces a newer version.

 Perhaps rather than a boolean CMAKE_EXPORT_IDE_METADATA
 setting to enable this, the value should be a version number.
 That way enabling it requires explicit specification of which
 format version is desired.  In this case we would need to use
 a format version number that is independent of th CMake version
 number.  It would simply be incremented every time changes are
 made.  If the version number has the form major.minor then
 we could increment the minor number whenever fields are added
 and the major number whenever fields are removed or changed.

 -Brad


Ok, I can start working on it in a KDevelop branch and see what needs to be
changed.

Regarding passing the version rather than ON probably makes sense. I'll
work on a patch to make it work this way.

Aleix
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] Extracting target metadata, IDE integration

2014-10-01 Thread Aleix Pol

On Wed, Sep 24, 2014 at 6:51 PM, Aleix Pol aleix...@kde.org wrote:

On Wed, Sep 24, 2014 at 3:55 PM, Brad King brad.k...@kitware.com wrote:

On 09/22/2014 07:15 PM, Aleix Pol wrote:
{
version: 1.0,
targets: [...]
}

Yes. The version number could either be maintained as its own
thing, or just the CMake version number could be used. Either way
the Help/variable/CMAKE_OUTPUT_PROJECT_TARGETS.rst documentation
should specify the format of each version.

BTW, the phrase output project targets is not particularly
clear without knowing the feature already. Perhaps some other
name like CMAKE_EXPORT_IDE_METADATA would be better?

I've never worked with those, but it sounds like it would make sense.
What about:

{
version: ..
configurations: {
{ name: Debug, targets: [...] },
{ name: Release, targets: [...] }
}
}

Yes, something like that. I think you meant to use [] rather than
{} around the list of configurations. In the case that there is
only one configuration for the generator we should still use a
list but have only one entry.

Sure :)

-Brad

Hi,
Here's another iteration of the patch [1].

Basically adopts the possibility to move some information to depend on the
configuration. Currently it's only showing the I source files, I guess
location, directory and installed should be moved as well. Correct?

Aleix

[1]
New patch:
http://proli.net/meu/kdevelop/0001-cmake-Add-option-to-generate-target-metadata-for-IDE.patch
New output: http://proli.net/meu/kdevelop/ProjectTargets.json

Bump.

I'm very interested in getting this in and iterating forward.

Any comments? How do changes get integrated?

Aleix
--

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

2014-09-26 Thread Aleix Pol

On Fri, Sep 26, 2014 at 1:27 AM, Stephen Kelly steve...@gmail.com wrote:

 Aleix Pol wrote:
  Hi,
  Here's another iteration of the patch [1].

 Thanks for this.

 Can you tell me why exportName is part of the output?


 http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/focus=11009

 Thanks,

 Steve.


I just looked into it, GetOutputName is a private method. Now that you
mention it though, we can just probably not output the exportName, at least
for now.

I can provide a new version of the patch if requested.

Aleix
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] Extracting target metadata, IDE integration

2014-09-24 Thread Aleix Pol

On Wed, Sep 24, 2014 at 3:55 PM, Brad King brad.k...@kitware.com wrote:

On 09/22/2014 07:15 PM, Aleix Pol wrote:
{
version: 1.0,
targets: [...]
}

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: [...] }
}
}

Sure :)

-Brad

Hi,
Here's another iteration of the patch [1].

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
--

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

2014-09-22 Thread Aleix Pol

On Fri, Sep 19, 2014 at 7:44 PM, Brad King brad.k...@kitware.com wrote:

 On 09/18/2014 08:10 PM, Aleix Pol wrote:
  I added a CMAKE_OUTPUT_PROJECT_TARGETS variable that can be used to
  enable the generation of the file.
  I also renamed the file to ProjectTargets.json.
 
  http://www.proli.net/meu/kdevelop/cmake-targetsdata.patch

 Thanks.  I made some style updates and converted it to a patch
 generated with 'git format-patch'.  See attached.  I also
 attached a sample ProjectTargets.json generated for the COnly
 test from our test suite.

Cool! Thanks a lot for taking your time to look into this!



 I'd really like to hear from others on the file format itself.

 Some comments on the format:

 * A version number field is needed at the top.

Sure, can't hurt.
So you'd encapsulate it such as:
{
version: 1.0,
targets: [...]
}



 * There needs to be support for multi-config generators.
   Perhaps everything that can be affected by the configuration
   needs to be inside a list that enumerates all configurations.
   In single-configuration generators the list would have only
   one entry for the CMAKE_BUILD_TYPE.  In multi-configuration
   generators it would be all of the CMAKE_CONFIGURATION_TYPES.

I've never worked with those, but it sounds like it would make sense. What
about:

{
version: ..
configurations: {
{ name: Debug, targets: [...] },
{ name: Release, targets: [...] }
}
}



 * Don't IDEs want to know the list of source files so they can
   be used for editing?

It would probably make sense, yes. We can introduce an input field.



 I haven't looked at what the Extra generators produce in a
 while but since they are meant for IDEs they would be a good
 reference for the information needed.  However, AFAIK there
 is not an extra generator for a multi-config generator.

 -Brad


Aleix
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] Extracting target metadata, IDE integration

2014-09-18 Thread Aleix Pol

On Mon, Sep 8, 2014 at 2:51 PM, Brad King brad.k...@kitware.com wrote:

 On 09/03/2014 12:12 PM, Aleix Pol wrote:
  On Wed, Sep 3, 2014 at 5:48 PM, Alexander Neundorf wrote:
  I still don't understand why this shouldn't be an additional
 ExtraGenerator.
 
  Because it's not possible to change the generator of a build directory
  once it's set up. You need to nuke it and re-create it.
 [snip]
 On 09/01/2014 07:27 PM, Aleix Pol wrote:
  Ok, how does it sound if we have a variable, such as
 CMAKE_EXPORT_COMPILE_COMMANDS?
  Let's say, CMAKE_EXPORT_TARGETS_INFORMATION.

 A control variable like that sounds good to me.  The purpose looks very
 similar to CMAKE_EXPORT_COMPILE_COMMANDS, but is distinct enough to have
 its own control.

 Thanks,
 -Brad

 --

 Powered by www.kitware.com

 Please keep messages on-topic and check the CMake FAQ at:
 http://www.cmake.org/Wiki/CMake_FAQ

 Kitware offers various services to support the CMake community. For more
 information on each offering, please visit:

 CMake Support: http://cmake.org/cmake/help/support.html
 CMake Consulting: http://cmake.org/cmake/help/consulting.html
 CMake Training Courses: http://cmake.org/cmake/help/training.html

 Visit other Kitware open-source projects at
 http://www.kitware.com/opensource/opensource.html

 Follow this link to subscribe/unsubscribe:
 http://public.kitware.com/mailman/listinfo/cmake-developers


I added a CMAKE_OUTPUT_PROJECT_TARGETS variable that can be used to enable
the generation of the file.
I also renamed the file to ProjectTargets.json.

http://www.proli.net/meu/kdevelop/cmake-targetsdata.patch

Does it look better like this?
Aleix
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] Extracting target metadata, IDE integration

2014-09-03 Thread Aleix Pol

On Tue, Sep 2, 2014 at 3:58 PM, David Cole dlrd...@aol.com wrote:

 It makes sense. But what IDE are you referring to? Eclipse? Some other
 concrete example? Or just any IDE and this feature should work everywhere
 CMake works...?


I'm working on KDevelop, I know for a fact though, that other IDEs are
looking for something similar too, such as QtCreator.

Aleix
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] Extracting target metadata, IDE integration

2014-09-03 Thread Aleix Pol

On Tue, Sep 2, 2014 at 9:45 PM, Alexander Neundorf neund...@kde.org wrote:

 On Tuesday, September 02, 2014 09:58:37 David Cole via cmake-developers
 wrote:
  It makes sense. But what IDE are you referring to? Eclipse? Some other
  concrete example? Or just any IDE and this feature should work
  everywhere CMake works...?

 AFAIK it is kdevelop4, and the goal is that developers don't have to tell
 cmake to run a kdevelop4 generator, but just the normal makefile generator,
 and still be able to use kdevelop4 on these build trees.

 Alex


Yes, essentially.
Makefile, or ninja, or whatever they use on mac and Windows and any of our
supported platforms.

Aleix
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] Extracting target metadata, IDE integration

2014-09-03 Thread Aleix Pol

On Wed, Sep 3, 2014 at 5:48 PM, Alexander Neundorf neund...@kde.org wrote:

 On Wednesday, September 03, 2014 12:30:21 Aleix Pol wrote:
  On Tue, Sep 2, 2014 at 3:58 PM, David Cole dlrd...@aol.com wrote:
   It makes sense. But what IDE are you referring to? Eclipse? Some other
   concrete example? Or just any IDE and this feature should work
 everywhere
   CMake works...?
 
  I'm working on KDevelop, I know for a fact though, that other IDEs are
  looking for something similar too, such as QtCreator.

 I still don't understand why this shouldn't be an additional
 ExtraGenerator.
 It will generate a special file intended to be used by KDevelop and maybe
 QtCreator additionally to makefiles/ninja files. Could be called
 GenericJSON
 or so.
 Other IDEs which don't support this file type but which need their own
 project
 file obviously still need their own specific generator.

 Alex


Because it's not possible to change the generator of a build directory once
it's set up. You need to nuke it and re-create it.
Also because changing the generator could potentially change the
interaction the user has with the build directory, we don't want to get in
the way.

Aleix
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] Extracting target metadata, IDE integration

2014-09-02 Thread Aleix Pol

On Tue, Sep 2, 2014 at 1:03 PM, David Cole dlrd...@aol.com wrote:

  Ok, how does it sound if we have a variable, such as
  CMAKE_EXPORT_COMPILE_COMMANDS?
  Let's say, CMAKE_EXPORT_TARGETS_INFORMATION.


 I would prefer CMAKE_EXPORT_TARGETS_FILE, or some name that implies it
 is a filename value, with the value of the variable being the name of
 the file to generate.

I think it's better to do an ON/OFF setting, given that from an IDE point
of view what
we want is to be able to run cmake again and get the file. If Eclipse
generated the file
I will still want to open it, and then we'd have to agree on a file name or
need to modify
the build directory, which kind of defeats the purpose.



 Who's the consumer of this file? Is it just one particular IDE, or is
 it meant to be general and possibly be used by multiple IDE generators?
 (I'm not sure I fully understand the context of the intent here based
 on the prior emails Can you explain it a little more?)


The consumer of this file is the IDE or anyone who needs to be able to
figure out the project's data. We need ways to describe the targets
generated by the project to let the IDE user know what targets the project
has and to be able to use them.

To get some context, let me define one of our use-cases, which would be a
KDE user.
To build a KDE Plasma 5 installation you need  100 repositories to be
built and configured. This means that all these are configured and
installed to a prefix, possibly with an external tool.
Our user will want to develop one of those projects. To do so, he will open
the project and choose the build directory tied to it, from there we need
to infer all the information he will need to develop the project.
Here's where the targets file comes into place, the IDE will just need to
open this file and the compile_commands.json files. If they're not created
the IDE will set the cache values then generate to be able to access them.

I hope it makes sense now.
Aleix
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] Extracting target metadata, IDE integration

2014-09-01 Thread Aleix Pol

On Fri, Aug 29, 2014 at 4:20 AM, Aleix Pol aleix...@kde.org wrote:

 Dear cmake'rs,
 I'm rewriting the KDevelop plugin from scratch to fetch the information
 from the build directory.

 Now in the first implementation I'm using the compile_commands.json file
 that cmake already can generate for some time. It works quite well already,
 given how data just comes out ready to be consumed (almost). The problem
 now is that we're lacking some information, namely information about the
 targets, their location and such *.

 To that end, I wrote a little patch to be taken as a proof of concept,
 that generates (some of) the needed information. I would like to know if
 you think it's an approach that would be accepted in the cmake code-base or
 if I need to take a different approach.

 Patch http://proli.net/meu/kdevelop/cmake-targetsdata.patch
 Output: http://proli.net/meu/kdevelop/AwesomeTargets.json

 Cheers!
 Aleix

 * Yes, I'm aware of generators, but I'm not comfortable with the idea of
 tying a build directory to an editor (even if it's my editor). Our users
 usually build the projects with different tools and asking them to
 re-create their build only for being comfortable with KDevelop sometimes is
 a burden. It would be for me too!


Bump?
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] Extracting target metadata, IDE integration

2014-09-01 Thread Aleix Pol

On Mon, Sep 1, 2014 at 9:26 PM, David Cole dlrd...@aol.com wrote:

 The approach looks reasonable, but having it unconditionally spit out a
 file in cmGlobalGenerator regardless of generator is probably not what we
 want. Seems like it should be based on a variable, or be in a specific
 generator, or somehow have a limited scope.

 HTH,
 David C.


Ok, how does it sound if we have a variable, such as
CMAKE_EXPORT_COMPILE_COMMANDS?
Let's say, CMAKE_EXPORT_TARGETS_INFORMATION.

Aleix
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

[cmake-developers] Extracting target metadata, IDE integration

2014-08-28 Thread Aleix Pol

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

2013-09-16 Thread Aleix Pol

On Mon, Sep 16, 2013 at 7:39 PM, Aleix Pol aleix...@kde.org 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

[cmake-developers] Improving GraphViz output, clustering

2013-09-16 Thread Aleix Pol

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

2013-09-16 Thread Aleix Pol

On Mon, Sep 16, 2013 at 10:03 PM, Alexander Neundorf neund...@kde.orgwrote:

 On Monday 16 September 2013, Aleix Pol wrote:
  On Mon, Sep 16, 2013 at 7:39 PM, Aleix Pol aleix...@kde.org 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

Re: [cmake-developers] [Qt-creator] CMake daemon for user tools

Re: [cmake-developers] CMake daemon for user tools

[cmake-developers] Linked library paths

Re: [cmake-developers] Generating buildsystem metadata from CMake

Re: [cmake-developers] Generating buildsystem metadata from CMake

Re: [cmake-developers] Generating buildsystem metadata from CMake

Re: [cmake-developers] Extracting target metadata, IDE integration

Re: [cmake-developers] Extracting target metadata, IDE integration

Re: [cmake-developers] Extracting target metadata, IDE integration

Re: [cmake-developers] Extracting target metadata, IDE integration

Re: [cmake-developers] Extracting target metadata, IDE integration

Re: [cmake-developers] Extracting target metadata, IDE integration

Re: [cmake-developers] Extracting target metadata, IDE integration

Re: [cmake-developers] Extracting target metadata, IDE integration

Re: [cmake-developers] Extracting target metadata, IDE integration

Re: [cmake-developers] Extracting target metadata, IDE integration

Re: [cmake-developers] Extracting target metadata, IDE integration

Re: [cmake-developers] Extracting target metadata, IDE integration

Re: [cmake-developers] Extracting target metadata, IDE integration

Re: [cmake-developers] Extracting target metadata, IDE integration

Re: [cmake-developers] Extracting target metadata, IDE integration

Re: [cmake-developers] Extracting target metadata, IDE integration

Re: [cmake-developers] Extracting target metadata, IDE integration

Re: [cmake-developers] Extracting target metadata, IDE integration

Re: [cmake-developers] Extracting target metadata, IDE integration

Re: [cmake-developers] Extracting target metadata, IDE integration

Re: [cmake-developers] Extracting target metadata, IDE integration

Re: [cmake-developers] Extracting target metadata, IDE integration

Re: [cmake-developers] Extracting target metadata, IDE integration

Re: [cmake-developers] Extracting target metadata, IDE integration

[cmake-developers] Extracting target metadata, IDE integration

Re: [cmake-developers] Improving GraphViz output, clustering

[cmake-developers] Improving GraphViz output, clustering

Re: [cmake-developers] Improving GraphViz output, clustering

34 matches

Site Navigation

Mail list logo

Footer information