So on one of the deltas listed I see it removing gnu debugger in place of what looked like the proprietary one. Could the gnu debugger be resurrection and used instead?
If clank is basically a third party product can an external dependency be added and used instead of including it directly as part of the code base? Eric Bresie ebre...@gmail.com > On February 9, 2020 at 3:28:31 AM CST, Geertjan Wielenga > <geert...@apache.org> wrote: > Thanks a lot for this history lesson -- so great that we have people with > this long perspective on where the code came from and so on. > > I have also seen "Target "all-cnd" does not exist in the project "main"". > > But then sometimes it just goes away. Reminds me a bit of this discussion: > > http://mail-archives.apache.org/mod_mbox/netbeans-dev/201809.mbox/%3ccackjaxssrrl66sua9heyqqxy4oyrxygkyemvg50rktrda-e...@mail.gmail.com%3E > > If you/we can get further with this, that would be great -- and please feel > free to provide pull requests to my fork. > > Gj > > On Sat, Feb 8, 2020 at 7:53 AM Ivan Soleimanipour < > ivan.soleimanip...@sbcglobal.net> wrote: > > > I took a look at geertjans branch (https://github.com/geertjanw/netbeans) > > > > building "ant -Dcluster.config=cnd" ... > > > > You should be able to deal with the dbx dependency simply by removing > > 'cnd.debugger.dbx' from the 'nb.cluster.cnd' > > list in "nbbuild/cluster.properties". There's also 'libs.dbx.support' in > > that list but that only contains > > a Bundle file so won't affect the build. The same goes for 'libs.clank'. > > > > I also had to remove 'nb.cluster.dlight' from 'nb.cluster.cnd.depends' in > > "nbbuild/cluster.properties". > > > > But then I ran into > > > /home/open/nb-geertjan/nbbuild/build.xml:660: Target "all-cnd" does not > > exist in the project "main". > > > It is used from target "nbmerge-build-one-cluster". > > I might pursue that in a bit (but I really hope someone else has the > > answer :-) > > > > In the meantime ... > > > > ... A bit of history. > > > > dbx is the Solaris source level debugger with origins dating back to the > > original days of BSD and Sun. > > > > The tools group at Sun/Oracle was subdivided into the IDE (CND) group in > > StPetersburg (SPB) and the dbx group > > in SiliconValley. There was also a performance tool group in SV which was > > in charge of the Performance Analyzer > > > > > > https://www.oracle.com/technetwork/server-storage/solarisstudio/features/performance-analyzer-2292312.html > > The only reason I'm entioning this group is because it was the > > primary performance analysis tool as opposed to > > "dlight" which is a very simple and lightweight performance and > > resource monitoring system. > > > > The bulk of the IDE functionality was done in an open-source manner by the > > CND group. This included all the project > > mgmt stuff, machinery to execute native binaries (like make and > > compilers), and remotely so, and all the work needed for > > code-completion (as in a C++ parser written in Java) and rich language > > support in the editor. It also included > > support for the GDB debugger which was initially done by the dbx team. > > It's called cnd.debugger.gdb2 because there > > was an older Q&D hack-and-slash cnd.debugger.gdb. > > > > clank ... has it's own rich history and I'm not sure I can do > > justice to it. > > > > To support a model for code completion the IDE has to parse C++. > > THe initial impl. used a bespoke > > antlr based C++ parser. That's what cnd.apt is all about. > > > > Clank is the brainchild of Vladimir Voskresensky and its github > > page (https://github.com/java-port/clank) > > says "Clank is a Java-port of popular Clang frontend". It's > > actually hela cooler than the title says. > > Take a look at > > http://llvm.org/devmtg/2017-03/assets/slides/clank_java_port_of_c_cxx_compiler_frontend.pdf > > What I don't know is what is the relationship of clank and NB as > > in why github.com/java-port/clank > > isn't in NB. > > > > Meanwhile Oracle had a tools (compilers, debugger, ide) product, > > SolarisStudio (SS), the IDE part of which built > > on top of NB and added some extra modules the most important one being the > > GUI for dbx support. > > > > For a long time the NB gdb and SS dbx modules evolved independently until, > > in a big flurry of factoring, > > common code was isolated in cnd.debugger.common2 with cnd.debugger.gdb2 > > and, what you now see as cnd.debugger.dbx, > > becoming different debugger "adapters". Yet, cnd.debugger.dbx remained > > proprietary. The main reason was that it > > had dependencies on even more proprietary stuff (e.g. glue). The CND group > > lobbied hard to come up with > > a way to make cnd.debugger.dbx go into NB proper (mainly because of > > convenience) but despite many heated > > discussions AFAIK "cnd.debugger.dbx" always stayed proprietary. > > > > This is why the appearance of cnd.debugger.dbx in this deliverable is a > > bit surprising to me. > > > > It may be that after I stopped being involved with Oracle (Or maybe even > > while I was there and my memory is > > totally shot) the CND group got to have its way, with the blessing of > > Oracle legal, and moved cnd.debugger.dbx > > into NB proper. > > > > No matter, The point is that cnd.debugger.dbx is, as you have discovered, > > unbuildable and ultimately useless because > > it needs a dbx binary to connect to, and a bunch of JNI code to do so, all > > of which must come from Solaris Studio. > > > > > > > > > > > > > > --------------------------------------------------------------------- > > 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 > > > > > > > >
