On Mon, Sep 18, 2023 at 10:02 PM Antonio <anto...@vieiro.net.invalid> wrote:
> 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). > On this, I wrote: > - 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. I.e. the breakpoints from cnd.debugger.common2 would be used in "cpplite.debugger", which should resolve the MIME type clashes. AFAIK there used to be two separate debugger implementations, both based on cnd.debugger.common2, and we probably can have two now. At least until someone can merge the native image stuff from cpplite.debugger to cnd.debugger.gdb2. > -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). > I am not sure if there must be a single debugger, see above. > > 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?). > Regarding CProjectConfigurationProvider, that is the way (API) the location of compile_commands.json is passed from the project to the editor/LSP server. So, it does not make much sense to push that into the project. Some API like this should be near cnd.lsp, unless it already exists. An implementation of the API should be in the project, replacing the current: https://github.com/apache/netbeans/blob/72a8dada6db920234b961b8af5631f44bbe4d73d/cpplite/cpplite.project/src/org/netbeans/modules/cpplite/project/CPPLiteCProjectConfigurationProvider.java#L32 UnconfiguredHint has two parts: a) a warning the user that there's no clangd/ccls configured - unless cnd already has something like that, it probably would be reasonable to have it; and b) that the compile_commands.json is not configured in the project, and this is cpplite specific. > > 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?). > On this, I wrote: > After all this, the cpplite.editor module should probably disappear. It was > always intended to disappear eventually. > > 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 > cpplite.project is probably not an urgent thing, that should mostly resolve by itself, I hope. Probably the more important step is to resolve the debugger. I think it would be useful to try to rebased the cpplite.debugger on top of cnd.debugger.common2, dropping the breakpoints from cpplite.debugger, and using breakpoints from common2. It seems it possibly may not be that difficult. > 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. > Ok, I probably misunderstood something, but I've seen this: https://github.com/apache/netbeans/blob/72a8dada6db920234b961b8af5631f44bbe4d73d/cnd/cnd.lsp/src/org/netbeans/modules/cnd/lsp/compilationdb/ClangCDBGenerationTask.java#L133 and it seemed to me like code generating the compile_commands.json. But I probably misunderstood that. > > - 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). > Good - all we need is an API similar to: https://github.com/apache/netbeans/blob/cnd/cpplite/cpplite.editor/src/org/netbeans/modules/cpplite/editor/spi/CProjectConfigurationProvider.java which could be implemented by projects, and which would allow to pass the location of compile_commands.json from projects to the editor/LSP server. Maybe something like that already exists? > > - 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). > Java's char is basically UTF-16, so I am not sure if there's any clash between how NetBeans represents positions and how ccls represents positions? Note the first version of ide/lsp.client was written against and for ccls. Supporting C/C++ using ccls was the driving reason for ide/lsp.client. So, unless something significant changed, supporting ccls should be viable. Jan > > > [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 <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 > >> > >> > >> > >> > > > > --------------------------------------------------------------------- > 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 > > > >
