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

2016-03-28 Thread Nikolaus Demmel 
Hi Stephen,

> On 03/25/2016 09:25 AM, Tobias Hunger wrote:
>> I am personally rather unsure about how to proceed. I can help make
>> this branch production/merge ready, but I do not want to maintain it
>> indefinitely after it is merged. It touches to many CMake internals
>> for me to be comfortable hacking on that code. 
> 
> Yes, this lack of interest in general in maintaining it upstream is
> currently a demotivator. I think we need a group of people interested in
> doing that.
> 
> Brad/Ben, no response since I posted the blog or the code. Any word of
> interest in any of it?

I just wanted to let you know that I think these additions have huge potential. 
Too much time is spent debugging cmake with `message(…)`. 

Unfortunately I currently do not have any capacity to join the effort, sorry. 
So all I can say is, keep it up! If you can get this to a useable state 
(hopefully with the help of others), it will be very useful indeed.

Cheers,
Nikolaus
-- 

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

2016-03-25 Thread Tobias Hunger 
Am 24.03.2016 16:13 schrieb "Aleix Pol" :
> 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?

Hey Aleix,

I did already do some work on that front, trying to make the JSON API more
complete, less prone to sudden aborts (there used to be asserts that could
be triggered by user input), more consistent, and with better test
coverage. See my fork on github for details.

I am personally rather unsure about how to proceed. I can help make this
branch production/merge ready, but I do not want to maintain it
indefinitely after it is merged. It touches to many CMake internals for me
to be comfortable hacking on that code.

Currently you (Aleix), Domminik and me seem to be the only people that want
this daemon, so I guess it would make sense for us to sit together and
decide what we want, whether we can maintain it together (or where we can
get help) and then hack into that direction.

Best Regards,
Tobias
-- 

Powered by www.kitware.com

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

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

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

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

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

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

2016-02-22 Thread Tobias Hunger 
Am 22.02.2016 23:14 schrieb "Stephen Kelly" :
> If anyone can get me a working java environment and a way to
asynchronously
> write stdin/stdout on long-running processes, I can write a plugin for
> eclipse which would be independent of cevelop afaict.
>
> Do you know enough java to help get started on that?

Can we please focus on getting this ready for inclusion into CMake first?
And fill in the missing pieces while doing that (e.g. find compile flags)?

It has so much potential, but right now it can not provide all the
information needed to feed a serious C++ code model! IMHO that needs to be
fixed first, before running of and plastering the world with more demos.
The ones you have are impressive enough already, now we need something that
is actually useful for real use.

Best Regards,
Tobias
-- 

Powered by www.kitware.com

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

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

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

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

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

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

2016-02-22 Thread Stephen Kelly 
Alexander Neundorf wrote:

> On Monday, February 22, 2016 22:30:42 Stephen Kelly wrote:
>> Jean-Michaël Celerier wrote:
>> > There is also https://www.cevelop.com/ which is an Eclipse derivative,
>> > they may be interested ?
>> 
>> I went all hipster reach-out.io and tweeted at them. :)
> 
> looks like that's an FP7-project, so I wouldn't be too sure about its
> future once the project funding ends...

If anyone can get me a working java environment and a way to asynchronously 
write stdin/stdout on long-running processes, I can write a plugin for 
eclipse which would be independent of cevelop afaict.

Do you know enough java to help get started on that?

Thanks,

Steve


-- 

Powered by www.kitware.com

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

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

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

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

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

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

2016-02-22 Thread Alexander Neundorf 
On Monday, February 22, 2016 22:30:42 Stephen Kelly wrote:
> Jean-Michaël Celerier wrote:
> > There is also https://www.cevelop.com/ which is an Eclipse derivative,
> > they may be interested ?
> 
> I went all hipster reach-out.io and tweeted at them. :)

looks like that's an FP7-project, so I wouldn't be too sure about its future 
once the project funding ends...

Alex


-- 

Powered by www.kitware.com

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

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

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

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

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

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

2016-02-22 Thread Stephen Kelly 
Jean-Michaël Celerier wrote:

> There is also https://www.cevelop.com/ which is an Eclipse derivative,
> they may be interested ?

I went all hipster reach-out.io and tweeted at them. :)

-- 

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

2016-02-22 Thread Jean-Michaël Celerier 
There is also https://www.cevelop.com/ which is an Eclipse derivative, they
may be interested ?

Best,

Jean-Michaël
www.i-score.org

On Fri, Feb 19, 2016 at 11:36 AM, Stephen Kelly  wrote:

> Alexander Neundorf wrote:
>
> > On Wednesday, February 17, 2016 22:59:36 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).
> >>
> >> I'd be up for a sprint in Berlin too, but given the muted response so
> >> far here, it's not clear who would want to join and what we could
> >> achieve.
> >
> > just out of curiosity, did you get any feedback from anybody from
> > Eclipse/CDT ?
>
> Nope. No response from there at all despite reaching out to them.
>
> > Or CodeBlocks maybe ?
>
> I didn't reach out to them, so no.
>
> Thanks,
>
> Steve.
>
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake-developers
>
-- 

Powered by www.kitware.com

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

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

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

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

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

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

2016-02-19 Thread Alexander Neundorf 
On Friday, February 19, 2016 11:36:35 Stephen Kelly wrote:
> Alexander Neundorf wrote:
> > On Wednesday, February 17, 2016 22:59:36 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).
> >> 
> >> I'd be up for a sprint in Berlin too, but given the muted response so
> >> far here, it's not clear who would want to join and what we could
> >> achieve.
> > 
> > just out of curiosity, did you get any feedback from anybody from
> > Eclipse/CDT ?
> 
> Nope. No response from there at all despite reaching out to them.

now that's a pity :-(

Alex

-- 

Powered by www.kitware.com

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

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

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

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

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

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

2016-02-19 Thread Stephen Kelly 
Alexander Neundorf wrote:

> On Wednesday, February 17, 2016 22:59:36 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).
>> 
>> I'd be up for a sprint in Berlin too, but given the muted response so
>> far here, it's not clear who would want to join and what we could
>> achieve.
> 
> just out of curiosity, did you get any feedback from anybody from
> Eclipse/CDT ?

Nope. No response from there at all despite reaching out to them.

> Or CodeBlocks maybe ?

I didn't reach out to them, so no.

Thanks,

Steve.


-- 

Powered by www.kitware.com

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

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

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

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

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

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

2016-02-18 Thread Alexander Neundorf 
On Wednesday, February 17, 2016 22:59:36 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).
> 
> I'd be up for a sprint in Berlin too, but given the muted response so
> far here, it's not clear who would want to join and what we could achieve.

just out of curiosity, did you get any feedback from anybody from Eclipse/CDT 
? Or CodeBlocks maybe ?

Alex

-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] [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] [Qt-creator] CMake daemon for user tools

2016-02-17 Thread Milian Wolff 
On Mittwoch, 17. Februar 2016 22:59:36 CET 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).
> 
> I'd be up for a sprint in Berlin too, but given the muted response so
> far here, it's not clear who would want to join and what we could achieve.

Considering the three of us (Tobias, you and me) are in Berlin, I'd say we at 
least meet for a hackday or so. What do you say? That would get me at least to 
work 8h on this for a full day and see how it integrates with KDevelop and we 
could discuss things in-person. Still, I'm aware that I'll have to play around 
with it before already to not waste too much of your time.

Bye
-- 
Milian Wolff
m...@milianw.de
http://milianw.de

signature.asc
Description: This is a digitally signed message part.
-- 

Powered by www.kitware.com

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

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

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

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

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

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

2016-02-17 Thread Stephen Kelly 
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).
>

I'd be up for a sprint in Berlin too, but given the muted response so
far here, it's not clear who would want to join and what we could achieve.

Thanks,

Steve.

-- 

Powered by www.kitware.com

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

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

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

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

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

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

2016-02-15 Thread Tobias Hunger 
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).

> 2. Reading about this deamon approach, rtags comes to my mind: rtags

I personally do not consider rtags to be very interesting for my use-cases.
But I am the wrong person for that topic anyway.

> Given this background, I can see a lot of benefits in a cmake deamon
> that provides all sorts of infos...

So do I.

I did a bit of hacking on a fork of Stephen's code (
https://github.com/hunger/CMake/tree/cmake-daemon) where I added some
protocol improvements (more unified JSON messages going back and forth,
consistent error reporting, consistent progress reporting, more unit tests,
etc.). No new functionality, just a bit of polish here and there.

Best Regards,
Tobias
-- 

Powered by www.kitware.com

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

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

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

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

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

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

2016-01-14 Thread Stephen Kelly 
Brad King wrote:
> I think the responses in this thread have indicated there is interest
> in working toward the full daemon approach.  Perhaps discussion should
> now proceed on the daemon protocol design over in the thread Tobias
> started on cmake-developers:
> 
>  cmake daemon mode protocol
>  http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/15424

Yes, let's assume that anyone interested in this topic is now subscribed to 
the cmake mailing list use that thread which does not include the other 
mailing lists. 

Thanks,

Steve.



-- 

Powered by www.kitware.com

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

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

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

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

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

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

2016-01-12 Thread Tobias Hunger 
Hello Stephen,

thanks again for your work and interest in IDE integration!

I read Bard's reply as meaning that your cleanup work is a great
benefit to cmake, but will probably not be available in the
foreseeable future (if at all).

Alexander goes back to the generator approach we discussed a year ago
and explicitly says he won't work on that, so nothing will happen
there.

The current state -- as I see it -- is this: While I like cmake for
command line use, it is the worst build system with regards to IDE
integration that I have to support in Qt Creator.  Even autotools
support is less than half the code needed to support cmake -- and
believe me, I never expected to give autotools as a positive
example;-)

So could we please get a *documented* way that an IDE can *rely on to
be available* that provides basic information on a
project/configuration:

* Source directory, build directory
* Files that belong to the project (sources, headers, custom cmake
modules, CMakeLists.txts, resources, ...)
* Files that belong to the build system (anything that needs watching
to re-generate the IDE-integration information at the right times)
* Targets that can be built
* Files that belong to each target
* Compiler flags
* Defines in effect
* Include paths used
* The compilers used to build those files

Ideally I would not need to write files to disk to get that
information. I do not know enough about cmake internals to suggest the
best approach to implement this, but something that can be extended
would be great, as this is really just the very basic information
needed and more information would be welcome at a later point.

Interactive features like syntax highlighting of CMakeFiles or adding
files to the build system in are of little interest to me at this
point: I see little reason to implement anything along those lines
while I can not reliably read the information needed for the code
model.

Best Regards,
Tobias

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

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

2016-01-12 Thread Alexander Neundorf 
On Tuesday, January 12, 2016 10:05:08 Brad King wrote:
> On 01/12/2016 05:15 AM, Tobias Hunger wrote:
> > I read Brad's reply as meaning that your cleanup work is a great
> > benefit to cmake, but will probably not be available in the
> > foreseeable future (if at all).
> 
> Most of Stephen's work completed so far is already in CMake 3.4, and
> a bit more is in 'master' and will be in 3.5.  It has no public-facing
> changes though so yes more work will be needed to get a solution IDEs
> can actually use.
> 
> > Alexander goes back to the generator approach we discussed a year ago
> > and explicitly says he won't work on that, so nothing will happen
> > there.
> 
> The generate-json-description approach remains a valid alternative.
> Aleix's work on it got pretty far before Stephen proposed the daemon
> alternative.  See more below.  IIRC Alexander Neundorf raised concerns
> only about how to activate the generation of the json description, and
> has now proposed an approach to resolve those concerns.

Yes, exactly.
But I really don't have the time to bring my branch up to merge quality: 
tests, documentation, compatibility (?, some generator names will fall away), 
corner cases. But these things are actually not complicated code, It's just 
work.

Alex

-- 

Powered by www.kitware.com

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

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

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

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

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

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

2016-01-12 Thread Stephen Kelly 
Brad King wrote:
>> Alexander goes back to the generator approach we discussed a year ago
>> and explicitly says he won't work on that, so nothing will happen
>> there.
> 
> The generate-json-description approach remains a valid alternative.
> Aleix's work on it got pretty far before Stephen proposed the daemon
> alternative.  

In between I also made a generic-generated-JSON-file-based approach.

> These problems are orthogonal, and your requirements certainly need
> generation-time information regardless of how the build specification
> itself is represented.  

Yes, this is the stuff that the protocol I put on github provides.

> Therefore the discussion here should proceed
> independent of where the alternative language thread goes.

Yes. I count 3 orthogonal ways an IDE and cmake could 'interface':

1) Provide information about translation of sources into objects so that the 
   IDE can understand those sources - eg includes and defines for c++ 
   sources.

2) Provide semantic information about the CMake code, for example to 
   introspect what is defined at what point in the file for debugging 
   purposes, and for code completion purposes.

3) Provide a way for IDEs to *edit* the buildsystem. For example, if an IDE 
   has an 'add class' dialog, or a 'extract class' refactoring action, they 
   need to add a file to a target. 


The first two are what we have mostly discussed in previous threads that I 
linked in the OP.

A generated JSON file in the buildsystem can provide (1), but can not 
provide the other interfaces. 

A well-designed declarative spec could make it easy for an IDE to do (3) but 
can not provide the other interfaces.

A daemon can provide the first two in a high quality way and allows for more 
extensions in the future. As (3) is orthogonal, a daemon and a declarative 
spec for the sources covers all three. 

Even without the declarative spec, the daemon can tell the IDE exactly where 
to put the target_sources() command as an intermediate step (before the 
declarative spec is available), though that's 'ugly' so I didn't list it as 
something 'high quality' that the daemon could provide.
 
> 2.  CMake offers a daemon that IDEs can contact (e.g. via named pipes)
> to ask for the information.  The contract between CMake and IDEs is
> a (to-be-designed) protocol (e.g. JSON snippets).  Updating would
> likely be handled internally by the daemon in response to changes
> to the CMake input files between requests from the IDE.

Right. If only some/deep/nested/CMakeLists.txt changes, and cmake knows that 
definitions do not escape via PARENT_SCOPE, and cmake knows that the targets 
defined in that file are not additionally modified elsewhere, it only has to 
re-evaluate the cmake code for that file and not for the entire buildsystem.

> Stephen no longer has time to continue his work except to guide others.

I can do development, but it would have to be as part of a collaborative 
effort and collaborative future maintenance. The latter part is the main 
reason I want to encourage fresh developers (and particularly IDE 
developers) into the cmake code to work on this, and to have some ownership 
on the code and design.

> Given the above summaries my reaction is that the daemon approach is
> more elegant and desirable in the long run.  However, it will require
> much more time and resources to implement.  It is not clear how much
> more, or if anyone has such time and resources to offer.

Yes. I'm trying to generate interest in people who are capable of joining 
the effort, and interested in doing so. It is difficult :).
 
> An intermediate solution could be to offer the daemon and protocol
> to IDEs but to implement it internally on top of pre-generated JSON
> files.  

That's even more effort, no?

> The schema of the JSON files would remain a private contract
> between "cmake" and "cmake-daemon".  Then over time the implementation
> of the daemon could be improved by computing things internally on
> demand instead of updating and reading the JSON files, but the public-
> facing protocol would not change.  We just need to make sure that the
> protocol is designed to allow such flexibility.  OTOH this approach
> requires designing both the daemon protocol and the JSON format.

Yes. I don't understand the proposal. Why implement the protocol in terms of 
files generated by cmake, instead of implementing the protocol in terms of 
state in cmake (one less step)? 

> Note that the generated JSON approach is essentially what we've been
> doing with the VS IDE since CMake started, just with a different format.

Yes, but also without providing an interface for (2) and (3) above.

> Many developers use the VS IDE to develop their CMake-built projects,
> and they get IntelliSense for completion.  It has worked well for years.
> Perhaps the argument for the daemon approach puts too much focus on the
> updating case while most developer time is simply spent editing existing
>