Hi Antonio, Great to see progress on CND!
First, the mime types in cpplite were intended to automatically "disable" the cpplite functionality when CND is installed. So, these are not intended to be used at the same time. OTOH, it is true cpplite is used a little bit more than anticipated. So, let us analyze the parts of cpplite: - cpplite.editor does three (or four) things: -- registers the MIME types, and creates DataObjects for the C/C++ files. It should be possible to delete these, only keeping the CND version of this functionality, assuming the rest of the code is adjusted to this, see below. -- starts the C/C++ LSP server + provides configuration for it. This should be deleted, and the version from CND should be used. But, IMO, the CND version should be extended to support "ccls" (as the cpplite version has been extended to support both ccls and clangd, unless there's a compelling reason to not support ccls). Also requires the API from the next point. -- provides a (friend) API using which the projects can provide the compile_commands.json for the server: https://github.com/apache/netbeans/blob/master/cpplite/cpplite.editor/src/org/netbeans/modules/cpplite/editor/spi/CProjectConfigurationProvider.java I suspect a similar API should be adopted by CND (and, maybe, the cnd.lsp module should not compute the compile_commands.json itself - the projects should do it, and cnd.lsp should only use the provided data). This API is used by cpplite.project and IIRC also by java.openjdk.project. -- the "Unconfigured" hint, I wonder if there's something like it in CND, or if there should be something like that: https://github.com/apache/netbeans/blob/master/cpplite/cpplite.editor/src/org/netbeans/modules/cpplite/editor/UnconfiguredHint.java After all this, the cpplite.editor module should probably disappear. It was always intended to disappear eventually. - cpplite.project provides a lightweight project. We might want to de-emphasize, but I would prefer if this is kept, at least for now, for multiple reasons (esp. because it is readily usable outside of C/C++). As long the API above exists, and the debugger (see next step) is adjusted, this by itself should not conflict with anything. - cpplite.debugger, which provides a debugger. Internally, I believe it provides roughly 3 things: a) the debugger itself; b) breakpoints; c) some UI is added (for watches, for example). I suspect the debugger itself might need to be kept (for native image debugging), although it is (hopefully!) mostly superseded by cnd.debugger.gdb2. But both the breakpoints and the UI additions would probably conflict with CND, and might (hopefully!!) be dropped, reusing what cnd.debugger.common2 does, basically re-basing cpplite.debugger to cnd.debugger.common2. As long as the breakpoints and UI additions are resolved, I hope the debuggers will be able to coexist well. Projects would decide which debugger they want to use, and the CND projects would use cnd.debugger.gdb2. And possibly cpplite.project as well, we would see. Martin E. might need to weight in on this. Overall, my hope is that cpplite can be blended into CND, keeping just pieces of cpplite that are useful (and as long as they are useful). Jan On Sat, Sep 16, 2023 at 12:53 PM Antonio <anto...@vieiro.net.invalid> wrote: > Hi all, > > So it seems people is interested in the CND branch for C/C++ > development, and we now have three PRs from external contributors [1]. > > STATUS: > > As you may know the CND branch has been pruned from the original Oracle > donation (due to license restrictions and code provenance issues), and > it's clean from a license point of view. It currently collides with the > cpplite cluster (see [2] for details). > > When compiled without "cpplite" the "cnd" branch is able to open old > "C/C++" projects, run and debug them, add syntax highliting, etc. cnd is > also able to automatically generate a "compile_commands.json" from > "C/C++" make based projects (with compiler settings and external library > dependencies, including "pkg-config" dependencies), and it starts and > connects to the "clangd" LSP server for extra features. > > Since the "cpplite" suite is used elsewhere (some people in the OpenJDK > Team use it for debugging GraalVM stuff, I think) somebody asked to keep > "cpplite" around. > > OPTIONS: > > So we have now two opposite forces: the "cpplite" users and the "cnd" > contributors wanting to move things forward. > > To satisfy both forces I think we could: > > A) Allow the user to switch between "cpplite" or "cnd" at runtime (I > don't know how to do this). > > B) Create a "cnd-only NetBeans edition" without "cpplite". Release > schedule for cnd could go with a different frequency from the official > NetBeans release. > > C) Make a separate repository for "cnd", transforming it into a plugin, > possibly under the Apache NetBeans umbrella, so people can contribute to > it. > > Depending on the solution above, and to ease development we could: > > D) Merge "cnd" into "master", disabling the "cnd" branch for release (as > we currently do with the "rust" suite). > > Note also that cnd has some characteristics of its own (see [3]), that > should also be taken into account before a decission is made. > > So, what say? Any opinion ideas on how to evolve cnd? Any other > alternatives you may think of? > > Cheers, > Antonio > > > [1] > https://github.com/apache/netbeans/pull/6439 > https://github.com/apache/netbeans/pull/6440 > https://github.com/apache/netbeans/pull/6441 > > [2] > Both "cpplite" and "cnd" want to assign different mime types ("text/X-c" > and "text/c-c" to files with extensions ".c" (".cpp", ".CC", etc.). > > NetBeans has difficulties handling different mime types for the same > file extension. > > I tried using a custom MimeResolver (that tries to guess if a file with > ".c" extension is owned by cpplite or cnd) without success. > > So currently "cpplite" and "cnd" are exclusive: only one of them may be > active for handling files with ".c" (".cc", ".cxx", etc.) extensions. > > [3] > Some considerations on the cnd branch: > > 3.1- Many modules specify JDK8 as the base jdk version. > 3.2- AFAIK cnd has not been tested with the most recent GitHub actions > testing stuff. > 3.3- cnd still has many redudant code (legacy from the Sun/Oracle Studio > days?) that should be pruned and updated. There're many > "System.getProperty" flags that affect logging and behaviour, this > should be cleaned up in the future, I think. > 3.4- IMHO there's little interest in the NetBeans committers about cnd > (users may still want to use cnd, though). > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org > For additional commands, e-mail: dev-h...@netbeans.apache.org > > For further information about the NetBeans mailing lists, visit: > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists > > > >
