Much of the rest of your email seems to be at issue with whether this becomes a part of CDT itself. As I am primarily interested in sustainability of the ecosystem, whether it is in the CDT repo or not is unimportant to me. Having good collaboration and governance of such projects that ensure their viability beyond a single maintainer's time is much more important.
>
> Are you still willing to consider that - and join the Eclipse CDT project as a committer to help with ongoing maintenance? What I would expect is that we deprecate & remove the existing cmake implementation in Eclipse CDT and include only the one you developed starting in CDT 10. That would mean that cmake4eclipse is shipped to all CDT users via the Eclipse IDE for C/C++ Developers package on eclipse.org/download.
cmake4eclipse is for managed buld. AFAIK from this list, managed buld
is going to be phased out. I do not hink it is worth the effort of
moving it to eclipse foundation.
The GME plug-ins, which use managed make, are currently being migrated to the Eclipse Foundation umbrella and I am really pleased with that. GME plug-ins are staying as their own project, with their own leadership and code/issues are staying on GitHub too.
The reality is that we are trying to figure out a way forward. The core build may be a good idea, but no one is contributing back outside of the core CDT team. However that is the case for Managed Make too. So we have to figure out a way forward. In the past this meant that Manged Make was announced as deprecated by Doug in the hope that would stimulate either maintenance of replacement of it. But neither has happened as of yet.
I see the need for users to have good cmake support easily installed
until core build is mature, but actiually I do not want to maintain it
as a CDT maintainer. Reasons are:
1) I do not do much C devlopment any longer. If it were under the CDT
umbrella, I fear I will loose interest in maintaining it over time.
Having the source on github and the artifacts on bintray, I can enjoy
user feedback and download stats [1] and stay exited.
Cool download stats. The Eclipse Foundation does provide that too to Eclipse Committers. I'm always curious as to what the numbers represent (check for updates vs. installations vs. builds).
2) It is easier for users to file issues on github since most of them
already have an account on github. If the plugin is a CDT project,
user will have to create an account on CDT to file issues. And it
might be more likely that issues of the plugin get ignored on the CDT
bug tracker.
I think that is why lots of the newer Eclipse projects are just staying on GitHub. If I can continue to encourage you to consider closer collaboration with CDT and the Eclipse community more generally there is nothing to force you to move to gerrit/bugzilla. Indeed, new CDT components are being developed in GitHub too.
(And I do wonder if it is time the Eclipse CDT project revisit the gerrit vs github flow - as a reviewer I find the gerrit flow far superior, but it is an extra thing to learn for contributors)
3) cmake4eclipse is already well-known (google for it) and even some
open source projects mention it in their 'build with Eclipse' FAQs.
Cool. You have been maintaining this on your own for quite a while and I am grateful on behalf of the extended CDT community. Having an Eclipse project called cmake4eclipse hopefully wouldn't detract from that.
4) Sorry for the rant here: To develop the plugin, I had to deeply
dive into the CDT code base. What a mess: Almost no code
documentation, documentation that lies, no real developer FAQ and lot
of unsued code. Sorry, I do want want to see my properly documented
code among that mess.
I am sorry that documentation has lied to you - that is worse than the normal expectations of undocumented open source code. I have been spending the last few weeks painstakingly working through the CDT Wiki and trying to at least mark out of date and incorrect information by adding appropriate warnings and moving them out of the main CDT site (to CDT/Archive or CDT/Obsolete). I came across lots of pages on their showing various works in progress that have long since stalled.
I couldn't find a bug report or edit on any of the egregious documentation error you have found. Perhaps you found them after you were already disillusioned with the CDT project. I hope I can work with you to heal old wounds and find a way forward for another successful generation of Eclipse CDT.
If the CDT team want good cmake support for CDT managed build,
wouldn't it be possible to add one of the cmake4eclipse download repos
on bintray [2] to the CDT product? These are build from pristine
sources on travis-ci..org. Or just mirror the github repo inside
Eclipse foundation and build & publish it there?
This has been discussed in the past. The Eclipse CDT project probably can't itself depend on cmake4eclipse as we would have quite a circular dependency!
However the "Eclipse for C/C++ Developers" on the
eclipse.org/download site is downstream for CDT. It may be possible to add cmake4eclipse into there, but I don't know the current licensing plans on such requirements. AFAIK in the past it was virtually impossible.
Thanks and lets continue the conversation on public cdt-dev mailing list
Jonah
Martin
[1] 5022721 downloads
https://bintray.com/beta/#/15knots/p2-zip/cmake4eclipse?tab=overview
[2] https://bintray.com/15knots/p2-zip/cmake4eclipse#files
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/cdt-dev
