Re: [cdt-dev] CMake plugins

[Doug Schaefer <dschaefer@xxxxxxxxxxxxxx>]

Cool. Let me think about this and take a closer look at your repo. I need to think about how this all fits.

To contribute to Eclipse, we will need to have copyright notices on all the source files which include the names of the copyright holders for each file. Generally we use the original author "and others", along with the date of the original commit. You can look at files like CMakeBuildConfiguration for an example.

Your project proposal was probably removed since it wasn't following the process. If we make this a CDT contribution then we wouldn't need to do that. We would just need a Gerrit review to start. Once we get there, I would take care of the legal review request that all large contributions must go through.

Doug.

> -----Original Message-----
> From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On
> Behalf Of Martin Weber
> Sent: Monday, November 20, 2017 2:47 PM
> To: CDT General developers list. <cdt-dev@xxxxxxxxxxx>
> Subject: Re: [cdt-dev] CMake plugins
> 
> Am Montag, 20. November 2017, 16:10:12 CET schrieb Doug Schaefer:
> > > -----Original Message-----
> > > From: cdt-dev-bounces@xxxxxxxxxxx
> > > [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Martin Weber
> > > Sent: Saturday, November 18, 2017 4:53 PM
> > > To: CDT General developers list. <cdt-dev@xxxxxxxxxxx>
> > > Subject: Re: [cdt-dev] CMake plugins
> > >
> > > Am Donnerstag, 9. November 2017, 20:36:03 CET schrieb Doug Schaefer:
> > > > Well, the good news is that all we have today in the CDT is the
> > > > Core Build integration and project templates. Plenty of room to
> > > > expand and grow that in other areas, especially the editor. I look
> > > > forward to all of your contributions and help.
> > >
> > > Good news!
> > > All original copyright holders of CmakeEd approved to change the
> > > license to EPL. I will mail the approvals PM, if requested.
> >
> > That's awesome. Thank you for getting that together. I think that
> > action of changing the copyright notices would be sufficient evidence
> > of the agreement.
> 
> Actually, I did not change the copyright lines in each source file. I changed the
> license in the main license file, in the pom and in the feature.xml to EPL. These
> were the only location mentioning 'CPL' or 'common public'.
> The source files did not and do not mention any license, so I did not take a step
> to add these. But that can be added, if required.
> 
> IMHO changing the license is a thing between me and the to original authors, I
> do not see that eclipse.org should be concerned. BTW: I did change the license
> already (yesterday).
> 
> ...
> 
> >
> > > NOTE: CmakeEd roughly follows the releases cycles of cmake as they
> > > evolve their language, which is about every 3-4 weeks currently. EPP
> > > cycles are much longer.
> >
> > Does the language actually change every 3-4 weeks? Are these minor
> > releases or maintenance releases. Projects can release maintenance
> > releases at
> 
> Those are minor releases [1]. Most of the time cmake learns some new
> keywords [2] or commands, the syntax stays nearly unchanged. Since I recently
> added a script that updates that can update syntax highlighting data and tool
> tips data from cmake source. That makes it easy to cope with cmake`s release
> cycles now.
> 
> ...
> 
> > We can make CMake be its own component so it has a clean slate. And CDT
> > doesn't have 65K open issues. It's only around 4k. And if we actually
> > triage them, there would be way less.
> > > - cmake itself is not tied to just C/C++. According to [1], cmake can
> > > generate build scripts to compile at least eight source languages. I
> > > think it`s better to have CmakeEd below some kind of 'Eclipse Source
> > > Editors' umbrella.
> >
> > That same argument could be made for most CDT features like build and
> debug.
> > Only the editor and source navigation are C/C++ specific. And we have plans
> > to bring target management into the fold.
> >
> > We could make it a subproject of CDT. There are certain project management
> > things that need to be done for Eclipse projects, release reviews, CQ's,
> > etc. It's a non-trivial amount of work that we're already doing in CDT. It
> > is well documented here: https://eclipse.org/projects/handbook if you
> > haven't already seen it.
> 
> Yes the project management things are a lot of work to do, nothing I really
> like to deal with. So either lets make it a subcomponent of CDT or put it
> under some other umbrella umbrella under eclipse.org.
> I already filed a project proposal [3], but today I cannot find it. Maybe you
> could chime in there.
> 
> 
> About the project code itself: I inherited in 2016 and did not touch much of
> its code (only fixed 2 annoying bugs).
> My contribution mainly were: Move project from SF to github, keeping ist
> change history. Add a build script (maven tycho). Set up CI to build from
> pristine source and upload artifact  to bintray. Plus I added a composite
> update site and made the marketplace point to it, as you already know.
> 
> The plugin also comes with cmake documentation in form of eclipse help, but
> that is really outdated. This bloat could/should be removed, no-one ever
> raised an issue about the outdated docs, and each user of cmake has the docs
> already on disk.
> 
> Awaiting to here how to proceed,
> 	Martin
> 
> [1] https://cmake.org/files/v3.9/?C=M;O=A
> [2] https://cmake.org/cmake/help/v3.9/release/3.9.html
> [3] https://www.eclipse.org/forums/index.php/f/202/
> 
> --
> Cd wrttn wtht vwls s mch trsr.
> 
> 
> _______________________________________________
> 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