30. dubna 2020 9:15:19 SELČ, Ivan Soleimanipour
<[email protected]> 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 <[email protected]>
>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: [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
>>>
>>>
>>>
>>>
>>
--
Odesláno aplikací K-9 Mail ze systému Android. Omluvte prosím moji stručnost.
---------------------------------------------------------------------
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
