Re: [cdt-dev] Extending CDT

["Mary Huang" <mary.huang@xxxxxxxxxxx>]

----- Original Message ----- 
From: "Douglas Schaefer" <dschaefe@xxxxxxxxxx>
To: <cdt-dev@xxxxxxxxxxx>
Sent: Tuesday, July 06, 2004 4:47 PM
Subject: Re: [cdt-dev] Extending CDT


> Hi Mary, this is kind of like deja-vu... :-)

indeed...

> The biggest decision to make when supporting remote resources while still
> leveraging the parser based features of the CDT is how you split the CDT
> to run in a distributed fashion. As with all such systems, the key limiter
> is network bandwidth. You want to minimize the interface, and thus the
> network traffic, between the CDT parts running on the development
> workstation with the CDT parts running remotely. And you also want to do
> that in such a way that when running non-distributed, you do not adversely
> impact performance.

The split will be that the workstation side will have full CDT and the
remote parts will only be those necessary to do the
parsing/scanning/indexing jobs. I suppose I will need some way to register
my "relay" plugin so that it can be notifiied everytime (local) CDT invokes
a parse/scan/indexing so that the message can be sent down the pipe. On the
remote side, I will need to develop a mechanism to "trigger" the same event
and collect the result/data to send back. Are there hooks in CDT already
that will allow me to do this? I may need to develop a caching mechanism to
overcome the network bandwidth/delay issue. For that I need to have a more
in-depth understanding of how, when, how often, why, etc these events are
triggered. And yes, you make a valid point... the non-distributed CDT should
suffer.

> For me, the biggest value features in parser-land are content assist and
> open declaration. Both of these features do a real-time parse of the
> current file and all of it's includes. We are having a hard time doing
> this quickly even with the file local. In a remote scenario with the
> current architecture, I can't see how these features would work with
> reasonable performance. Things like doing incremental and background
> parsing may help but sooner or later you have to pay the performance
> penalty of having to remotely access the information.

If the file is open in the editor, there will be a local replica of the
file, so a full parse of that file should be fine. It's the parsing of all
the includes that worries me. Doesn't CDT maintain a database of some sort
to cache that kind of information and update it incrementally?

> Accomplishing remote development scenario by distributing the CDT is a
> tough task indeed. My current opinion is that you would be better off by
> shadowing the files on the development workstation and hiding the fact
> that the files are remote, and as a side affect, allowing eclipse to be
> "aware" of them. We often do this with network filesystems like NFS and
> invoke remote builds. I'm also interested in the cross-compile scenario
> and only having to debug remotely. I'm not sure the edit/navigate side of
> things can be easily distributed, but I'd be interested to hear any ideas
> that you and your team can come up with!

Shadowing files on the development workstation is not really an option for
our user base.... their code base is usually huge and this also introduces
cross compiler issues. Replicating a subset of the development source code
does not really help either, because CDT will need to reference the entire
base. Using network file systems was the solution we used to provide.
Believe it or not, but connection instability and performance issues are the
two major reasons that prompted us to look at this alternate solution.

>
> Cheers,
> Doug Schaefer, IBM's Eclipse CDT Architect
> Ottawa (Palladium), Ontario, Canada
>
>
>
> "Mary Huang" <mary.huang@xxxxxxxxxxx>
> Sent by: cdt-dev-admin@xxxxxxxxxxx
> 07/06/2004 04:04 PM
> Please respond to
> cdt-dev
>
>
> To
> <cdt-dev@xxxxxxxxxxx>
> cc
>
> Subject
> Re: [cdt-dev] Extending CDT
>
>
>
>
>
>
> We currently have a tcp/ip based framework for accessing these remote
> files
> and for remote execution of commands. All the files reside on the remote
> host and are only replicated/cached locally for editing purposes. All
> tools/commands are run on the remote host where these files reside.
> Eclipse
> is not really "aware" of these remote files... in other words, CDT will
> not
> really "see" these files locally. My team has gone to much lengths writing
> plugins that provides this framework and a project environment in eclipse
> such that end-users can enjoy working with their remote files in the
> (local)
> eclipse environment on their workstation. Now, we have to figure out how
> to
> fit CDT into the picture and work with this non-traditionaly eclipse
> project
> and resources. The option I'm looking into is the federated/distributed
> CDT
> environment.
>
>
> ----- Original Message ----- 
> From: "Johan Walles" <walles@xxxxxx>
> To: <cdt-dev@xxxxxxxxxxx>
> Sent: Tuesday, July 06, 2004 3:05 PM
> Subject: Re: [cdt-dev] Extending CDT
>
>
> > Why not just access the remote files using some Java implementation of
> > the ssh protocol?
> >
> >    //Johan
> >
> > Mary Huang wrote:
> > > Hi,
> > >
> > > I've just started looking at CDT and the possibility of extending
> > > it. My primary reason for extending CDT is to provide support for
> remote
> > > resources in eclipse. Eclipse only recognizes "local" projects and
> > > resources (files and folders). I have to support local (eclipse)
> > > projects (non CDT at this point) which contain
> > > remote resources accessed via a file transport system recognized by my
> > > project type. To leverage the rich C/C++ environment provided by CDT,
> I
> > > have to extend it to support remote resources. Since the remote host I
> > > am supporting is some flavour of unix/linux (the workstation is
> > > windows), I am hoping to be able to run a federated/distributed CDT
> > > environment by installing CDT (no GUI components) on the remote host
> and
> > > then implementing a "bridge" or a "connector" between the CDT on the
> > > workstation and the CDT running on the remote host. When a
> > > parse/scan/indexing is initiated on the workstation, the "bridge" or
> > > "connector" will relay the event to the "remote" CDT, trigger the same
> > > event on the remote host, collect the result, stream the result back
> to
> > > the workstation and somehow combine the results (workstation +
> remote).
> > > This will apply to content assist, outline view, build, search, etc.
> Is
> > > this something that is do-able in CDT 2.0 or 2.x eventually? I need to
> > > do this in the next few months.
> > >
> > > I also want to take over the generation of the makefile in the managed
> > > build scenario. I have read the "Managed Build System Extensibility
> > > Document" and I understand that I can contribute my own tool chain,
> etc.
> > > But I want to take it one step further and generate the makefile as
> > > well... different format/syntax, to a remote host, of course.
> > >
> > > Any comments will be appreciated.
> > >
> > > Mary Huang
> > >
> > _______________________________________________
> > cdt-dev mailing list
> > cdt-dev@xxxxxxxxxxx
> > http://dev.eclipse.org/mailman/listinfo/cdt-dev
>
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/cdt-dev
>
>
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/cdt-dev