You folks are correct.. I'm not suggesting dropping the code model machinery.
My goal is to simply get it working as is. Then take the next step.. It's definitely a lot of work but can probably be drastically improved because of JEP-362 and JEP-381.. -brad w. -brad w. On Thu, Apr 30, 2020 at 1:50 AM Jan Lahoda <lah...@gmail.com> wrote: > > > 30. dubna 2020 9:15:19 SELČ, Ivan Soleimanipour < > ivan.soleimanip...@sbcglobal.net> napsal: > >I don't think Brad was suggesting ditching the code model machinery > >(C++ parsers). > > Right, I don't think he was suggesting that. > > But I guess what I am saying is: if we want to have C/C++ support in > NetBeans, we need a group of developers working on that. So, as a > mitigation plan, I sketched out cpplite, where the group of maintainers > could be very small. If we can have full CND, that is even better, but are > there enough contributors? What are your opinions on how to evolve the > model for new versions of C++? Do we use the antlr parser, clank, or both? > These are all questions I don't know answers to. > > As you can see below, I did also some work on CND - do you have > improvements to that? Because in the current state, it cannot be released. > I am willing to help, but I can only contribute a little, and this is a > huge project. > > Jan > > >None of that, in general, is Studio specific. > > > >CND does have a plugin interface. It's best to illustrate it with > >debuggers. There's a > >debugger_common module and two plugins, a gdb debugger and a dbx > >debugger. > >The dbx debugger part was Oracle prorprietay so I don't think there's > >anything to get rid of. > >The other part which had to be customized was make (gnu-make vs > >sun-make) and compiler > >customizations. For example, to find out the list of predefined macros > >CND has to invoke > >each compiler with a slightly different magical incantation. > > > >So I think Brad was talking about getting rid of Studio-specific > >customizations, not code > >that was written by people (mostly StPetersburg folk) employed by > >Oracle. > > > >Brads suggestion makes sense tho I don't think it's that much stuff and > >getting rid of > >it won't simplify things _that_ much. > >More importantly, once you ditch Studio support CND will become a > >plugin/customization infrastructure with only one plugin: GNU stuff. > >And we all know what > >happens in such circumstances. The generic part of the code ends up > >getting polluted with > >features to support it's only plugin. > > > >On 4/29/20 10:57 AM, Jan Lahoda wrote: > >> To elaborate on the C/C++ support in NetBeans a little more: I think > >we > >> have two main directions which we can take: 1) take more or less the > >full > >> CND as donated, adjust to Apache standards and maintain; 2) attempt > >to do > >> something simpler (taking from CND what we need). > >> > >> Using the full CND has some advantages, like a much more > >fully-featured > >> support, having a model of the source code inside the IDE, which can > >be > >> used to implement any feature, etc. The disadvantages are that a) we > >need > >> to bring it up to Apache standards; b) we need to maintain it (I may > >be > >> wrong, but my understanding is that there are two C/C++ parsers > >there: an > >> ANTLR based one, and clank, which is clang converted to Java). This > >would > >> include, for example, adding support for new C++ versions. > >> > >> There is a very crude start of this in branch cnd-building in my > >NetBeans > >> repo: > >> https://github.com/jlahoda/netbeans/tree/cnd-building > >> > >> There is a simple README available for it: > >> https://github.com/jlahoda/netbeans/blob/cnd-building/README.cnd > >> > >> I guess that for this to work, we need some serious effort. At very > >least, > >> the readme lists a number of files that need to be added, to make > >code > >> buildable, and for each, we need to find out if we can use it, > >provide a > >> replacement, or drop it. Some might be reasonably simple, but I am > >worried > >> about things like CPPParserEx.java, CPPSymbol.java and cppparser.g - > >these > >> feel like difficult to replace; and possibly difficult to use the > >original > >> versions (as, presumably, these need to be updated when a new > >language > >> feature is added). > >> > >> > >> Using something simpler could be to use a C/C++ Language Protocol > >Server, > >> like ccls (https://github.com/MaskRay/ccls). This would provide > >features > >> like code completion, without the need to maintain the code to > >compute the > >> proposals, etc. inside NetBeans. Then there is a need for (simple?) > >> projects and (simple?) debugger. I tried to prototype it here: > >> https://github.com/jlahoda/netbeans/tree/cpplite > >> > >> To use it, checkout the branch, and then build using: > >> ant -Dcluster.config=cpplite > >> > >> Then do "ant tryme" to get the IDE. In New Project, there is > >> C/C++/Lightweight C/C++ Project - it is primarily intended to open > >existing > >> projects in NetBeans. It allows to specify compile_commands.json (for > >ccls) > >> and build commands. Path to "ccls" needs to be specified in > >Tools/Options > >> (otherwise most editor features don't work). > >> > >> The advantage of this is that it should be fairly reasonable to > >write; and > >> hopefully easy to maintain for the long term. The disadvantage is > >that some > >> (many?) features from CND may be missing. > >> > >> > >> I guess I'd like hear: > >> a) who is willing to help with either of these projects? Which you > >prefer? > >> b) any other ideas? > >> c) if someone would be willing to try cpplite and say how much is > >missing > >> to make it useful, I'd be grateful. My primary personal reason to > >look at > >> C/C++ support is to allow developer of native sources from OpenJDK - > >and I > >> think/hope cpplite could evolve fairly easily into something useful > >for > >> this usecase. > >> > >> What do you think? > >> > >> Thanks, > >> Jan > >> > >> On Wed, Apr 29, 2020 at 1:20 AM Ernie Rael <err...@raelity.com> > >wrote: > >> > >>> On 4/28/2020 3:58 PM, Brad Walker wrote: > >>>> I'm starting to wade into helping get the C/C++ module up and > >running on > >>>> Apache Netbeans. As a result, I have quick project question for the > >more > >>>> "senior" folks on this group. Or anyone else who cares to comment. > >8-) > >>>> > >>>> I would like to propose that we drop support for the SunStudio > >tools > >>> (i.e. > >>>> compiler and debugger, etc.). The reason is because it makes > >porting more > >>>> difficult. In addition, it doesn't really make sense for a project > >like > >>>> Apache Netbeans to carry all this technical debt that it incurs for > >which > >>>> no one really is going to support. > >>>> > >>>> So what are the collective thoughts and opinions about dropping > >SunStudio > >>>> support in Apache Netbeans? > >>>> > >>>> The assumption here is that GDB and friends would continue to work > >and be > >>>> supported. > >>>> > >>>> -brad w. > >>>> > >>> There's this tantalizing message from Jan > >>> > >>> > >>> > > > http://mail-archives.apache.org/mod_mbox/netbeans-dev/202004.mbox/%3CCALd%3D3dH2vqLx8rrP2yDh76%3DDVKsok-g0Qeaf9zpeaVG2aeALhA%40mail.gmail.com%3E > >>> > >>> which suggests > >>> > >>> alternative idea is to use a Language Server Protocol (LSP) > >server > >>> > >>> You might find that thread interesting... > >>> > >>> -ernie > >>> > >>> > >>> > >--------------------------------------------------------------------- > >>> 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 > >>> > >>> > >>> > >>> > >> > > -- > Odesláno aplikací K-9 Mail ze systému Android. Omluvte prosím moji > stručnost. > > --------------------------------------------------------------------- > 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 > > > >
