Hi,
Wow, that seems a lot of work to do _on cpplite_ in order to have cnd
integrated. Also it seems to me there're lots of unknowns in the road!
The blockers I see are:
-A) If the cpplite.debugger is to be kept "for native image debugging"
then cpplite.editor MIME registration should also be kept, because
NetBeans breakpoints are mime-type dependent (see [1], for instance).
-B) And if cpplite.editor MIME registration is to be kept then CND
cannot register mime types, as NetBeans is unable to assign mime types
"text/x-c" (CND) and "text/X-c" (cpplite, note upper case X)
simultaneously for files with the same extension (*.c, *.cxx, etc.).
So, to summarize: the blocker is that a file with extension ".c" cannot
be registered with different mime-types (with different breakpoints),
which is required if wishing to have two different debuggers with
different breakpoints.
To solve the situation the only think I can think of is:
1.- keep a single debugger which, due to code length, should be the pair
cnd.debugger.common2/cnd.debugger.gdb2 (cpplite.debugger uses these in
binary form, after all).
2.- regarding cpplite.project, I think this should be transformed in
some sort of "cnd.cpplite.project" or similar (some sort of CND
free-form project), in the cnd cluster, integrating the
CProjectConfigurationProvider and UnconfiguredHint currently in
cpp.editor (these are project-specific APIs, right?).
3.- with a single debugger and a cnd.cpplite.project similar to
cpplite.project, then cpplite.editor is superfluous and could be
removed, I think. Note that ide/nativeimage.api has a test dependency
with cpplite/cpplite.editor [2]! that should clarified (what's this used
for?, how does a module in the ide cluster depend on the cpplite cluster?).
I think I could give a "cnd.cpplite.project" a try, incorporating stuff
from cpplite.project and cpplite.editor, but then I'll need to know how
this "native image debugging" works. Is anyone using this "native image
debugging" functionality? How is it used?
If the experiment fails then cnd and cpplite could not coexist, and we
should devise another alternative (CND release without cpplite, or
letting the user choose betwween cpplite/cnd at runtime, disabling one
or the other).
Cheers,
Antonio
P.S.: Some clarifications about CND:
- cnd.lsp, does not "not compute the compile_commands.json itself", as
stated. This is delegated to cnd's make based projects: only cnd make
based projects generate a compile_commands.json automatically.
- cnd.lsp is agnostic about compile_commands.json: if the file is there
the LSP server will detect and use it. Otherwise the LSP server will
have no compile_commands.json (LSP servers usually provide some hints
even if the file is missing).
- cnd.lsp currently starts clangd, but could also launch ccls if
required (ccls expects offsets based in UTF-16 encoding, as the LSP
specification mandates, which is not the case in NetBeans, where offsets
are UTF-8 based, AFAIK).
[1]
https://github.com/apache/netbeans/blob/b5a8baff7408fb4f07633a38d47c3279453f6fc6/cpplite/cpplite.debugger/src/org/netbeans/modules/cpplite/debugger/breakpoints/CPPLiteBreakpointActionProvider.java#L43
[2]
https://github.com/apache/netbeans/blob/b5a8baff7408fb4f07633a38d47c3279453f6fc6/ide/nativeimage.api/nbproject/project.xml#L97
On 16/9/23 15:31, Jan Lahoda wrote:
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 <[email protected]> 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: [email protected]
For additional commands, e-mail: [email protected]
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
