[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [cdt-dev] CMake plugins
|
+1 If you do automatically add source files, the CMakeLists.txt file must only contain a single target or you'd never get it right. And what if the user doesn't want to add certain ones? The scenarios get confusing very fast.
Our biggest need at the moment is a good editor. In fact, if we do a good job of content assist, we could provide source files as a completion proposals in the right contexts. That might turn out to be better than automatically adding them.
Thanks!
Doug
> -----Original Message-----
> From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx]
> On Behalf Of Jesper Eskilson
> Sent: Thursday, October 19, 2017 9:20 AM
> To: cdt-dev@xxxxxxxxxxx
> Subject: Re: [cdt-dev] CMake plugins
>
>
> Hi,
>
> Automatic editing of the CMakeLists.txt file sounds like a bad idea. It is
> impossible to do right in the general case; even if you have a full syntax tree,
> there is no way of knowing where the user wants the code to go. Also, I
> would suspect that this is not a very requested feature among people who
> use CMake. Syntax highlighting, completion, and automatic indexer setup (so
> that code navigation works correctly) is probably more important.
>
> Regards,
>
> /Jesper
>
> Jesper Eskilson Development Engineer
> IAR Systems AB
>
>
> ________________________________________
> From: cdt-dev-bounces@xxxxxxxxxxx <cdt-dev-bounces@xxxxxxxxxxx> on
> behalf of Morgner Felix <felix.morgner@xxxxxx>
> Sent: Thursday, October 19, 2017 2:52 PM
> To: cdt-dev@xxxxxxxxxxx
> Subject: 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
> _______________________________________________
> 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