[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cdt-dev] CMake plugins
|
Hi
So I spoke to my co-advisor on Monday to get an idea on how to go forward with
my project. I would like to give a short outline of the features I have/had
planned to implement as part of my project:
- Project creation (obviously, this is already implemented in CDT, so not much
to do there.
- Project import (I guess that is what the "empty" CMake Project option is for?
If yes, then there is not much left to do there, except for maybe allowing the
user to set CMake configuration options during import.)
- Project management: Adding new files to a project should also add them to the
respective target in the corresponding CMakeLists.txt. Since CMake can have an
arbitrary number of targets defined, it is crucial to provide a way for the user
to disambiguate which target to add the file to if automatic detection is not
possible. This might involve changes to the "New File" wizard to allow target
selection (if it is not in place already) or to allow the user to add files
"via" the target they'd like to add the file to.
- Editor with syntax highlighting and semantic completion: While providing
syntax highlighting could be achieved by using TextMate's syntax bundle,
semantic completion would require us to understand the actual configuration
language. I plan to implement a parser and indexer for CMake's configuration
language in order to provide semantic completion in the editor.
- A UI to manipulate/configure the cache of a generated CMake project. I propose
to integrate these configuration abilities with CDT's current build
configuration infrastructure, as to provide a unified user experience. The CMake
cache is an integral part of the build configuration and thus should be
accessible to the user. As far as I can tell, CMake Server only allows for
global settings (not cache values) to be changed.
- Integration of standard (and possibly user-defined) CMake build types with
CDTs build infrastructure (I am still unsure on how much of this is already
implemented)
I would be thankful for any feedback on the features I planned, especially
regarding what may have already been implemented that I have overlooked.
@Doug: with 'indexer', do you mean the CDT C/C++ indexer?
-----Original Message-----
From: Doug Schaefer <dschaefer@xxxxxxxxxxxxxx>
Reply-to: CDT General developers list. <cdt-dev@xxxxxxxxxxx>
To: CDT General developers list. <cdt-dev@xxxxxxxxxxx>
Subject: Re: [cdt-dev] CMake plugins
Date: Mon, 16 Oct 2017 14:20:44 +0000
Cool, thanks Felix! We are sorely lacking an editor and would love help with
that. I know Jesper here on the list has looked at the server integration but
I'm not sure what state that is at the moment.
We do have a lot in place for project creation, build and syncing build
information for our indexer. That will be a big part of my CDT talk next week at
EclipseCon Europe. But if you have ideas there too, I'm interested in them as
well.
Thanks!
Doug.
> -----Original Message-----
> From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx]
> On Behalf Of Morgner Felix
> Sent: Sunday, October 15, 2017 4:03 PM
> To: cdt-dev@xxxxxxxxxxx
> Subject: Re: [cdt-dev] CMake plugins
>
> Hi list,
>
> I am currently working on CDT based CMake integration myself for my
> semester project. I plan on implementing project creation as well as
> import/sync, an editor with semantic completion, and CMake server
> integration. I feel it would be reasonable to join forces on this. I will be
> talking
> to my supervisor tomorrow, and wanted you to know that I would be very
> much interested in contributing to the CDT CMake integration.
>
> Felix
>
> On Wed, 2017-06-07 at 14:43 +0000, Doug Schaefer wrote:
> > I think it would be good to aim at the December release for official CMake
>
> support.
> >
> > Ideally we need an editor with at least syntax highlighting. Content assist
>
> would be awesome. We can either build our own editor, maybe using the
> new Generic Text Editor, or try and convince the CMakeEd gang to relicense
> and contribute. (Despite old copyright dates, it looks like it’s actively
> developed by a couple of people).
> >
> > The other major item is to make sure users can create different build
>
> configurations. Right now everything is driven by the Launch Bar and the
> configuration is selected based on Launch Mode and Launch Target type. I
> have a start on a Build settings tab on the launch configuration which may be
> close to enough.
> >
> > The CMake Server support would be cool too. Then I think we’d be in good
>
> shape.
> >
> > I do have an itch to scratch to learn the Generic Editor but if someone has
> > a
>
> start on one already, please let us know.
> > Cheers,
> > Doug.
> >
> >
> > From: <cdt-dev-bounces@xxxxxxxxxxx> on behalf of Jesper Eskilson
> > <Jesper.Eskilson@xxxxxxx>
> > Reply-To: "CDT General developers list." <cdt-dev@xxxxxxxxxxx>
> > Date: Wednesday, June 7, 2017 at 2:56 AM
> > To: "CDT General developers list." <cdt-dev@xxxxxxxxxxx>
> > Subject: Re: [cdt-dev] CMake plugins
> >
> > > I've been meaning to allocate some time to improve the CMake-plugins,
>
> but I haven't got very far. I have implemented support for the CMake server
> API (which is still in Gerrit), but not much else:
> https://git.eclipse.org/r/#/c/94349/.
> > >
> > > /Jesper
> > >
> > > From: cdt-dev-bounces@xxxxxxxxxxx <cdt-dev-bounces@xxxxxxxxxxx> on
> > > behalf of Doug Schaefer <dschaefer@xxxxxxxxxxxxxx>
> > > Sent: Monday, June 5, 2017 8:58 PM
> > > To: CDT General developers list.
> > > Subject: Re: [cdt-dev] CMake plugins
> > >
> > >
> > > From: <cdt-dev-bounces@xxxxxxxxxxx> on behalf of Jonah Graham
> > > <jonah@xxxxxxxxxxxxxxxx>
> > > Reply-To: "CDT General developers list." <cdt-dev@xxxxxxxxxxx>
> > > Date: Monday, June 5, 2017 at 2:55 PM
> > > To: "CDT General developers list." <cdt-dev@xxxxxxxxxxx>
> > > Subject: [cdt-dev] CMake plugins
> > >
> > > > Hi devs,
> > > >
> > > > Is it intentional that the CMake plug-ins are not published to Oxygen
>
> simrel repo? I know they are experimental, but it ia harder to find them not
> on the simrel.
> > >
> > > Yes. They are experimental. So experimental I don’t really want the
>
> general public using them. There are still a lot of workflows that are
> cumbersome, hard coded, etc.
> > >
> > > > Thanks,
> > > > Jonah
> >
> > _______________________________________________
> > cdt-dev mailing list
> > cdt-dev@xxxxxxxxxxx
> > To change your delivery options, retrieve your password, or
> > unsubscribe from this list, visit
> > https://dev.eclipse.org/mailman/listinfo/cdt-dev
>
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe
> from this list, visit https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from
this list, visit
https://dev.eclipse.org/mailman/listinfo/cdt-dev
