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 > > > >
