| Re: [ptp-dev] Thinking about rsync-before-make hybrid local/remote projects |
Hi Jeff,
> One option is to copy header files from the include paths on the remote
> machine into the local project (or rsync them on every build). So,
> e.g., /MyEclipseProject/.remote-includes/mpi.h would be a local copy of
> mpi.h from the remote machine. Then the we would just add
> "/MyEclipseProject/.remote-includes" to the list of include paths, and
> features like Open Declaration and Search would more or less work
> correctly. (Maybe?)
It's possible but I wouldn't recommend it, for a few reasons.
- All the time it's going to take to copy those headers down.
- Are you even permitted by the license terms of the OS or whatever library you are using to copy them to another machine? You may only be licensed to use them in one place.
- Are you permitted by your organization's security policy to copy said headers to another machine? Imagine you work for some three letter agency in the government and are using some super secret code. You probably can't.
- Keeping the headers in sync with the canonical copy on the remote machine is going to be a pain.
- Include statements on the local machine might use absolute paths. This would either mean putting the headers in the exact same place on the local machine so that #including with the same path will work (which might kind of work if you are going from one UNIX-like OS to another, but definitely not when going from UNIX-like to Windows). This is also assuming you don't have a similarly named header file on the local machine that you don't want to stomp upon. You could maybe create a new preprocessor that supported some notion of mapping include paths to new paths, but that's a lot of work.
> If that's too hack-ish for your taste, we could also modify the
> preprocessor to load files directly from the remote machine, perhaps
> caching them locally to improve performance. The problem there is that
> the indexer would then have references to non-local files, so it would
> have to be modified to distinguish these (e.g., use URIs instead of file
> paths), and various UI actions (e.g., Open Declaration and Search) would
> have to be modified to be able to open the remote file in an editor.
> That seems like an expensive change.
I tried EFS converting the parser and indexer a while back, and it was a big nightmare. I got something kind of working (I got the existing JUnits passing at least), but there were a ton of gaps in the API that I couldn't address without overhauling a lot of the older parts of CDT. E.g. the scanner config and scanner discovery portions of CDT are not EFS aware. The debugger is not EFS aware either.
I can tell you that if you want to go down the EFS path, caching will be a must, or the performance will be so horrendous no one will want to use it. I did not attempt to solve the caching problem yet when I tried looking at the EFS conversion.
CDT is pretty much already using URIs to open files, so I don't think any significant work is required for that part. Whatever work on top of what's in CDT that would have to be done, we already did in RDT.
> Then, there's actually doing the rsync and remote make. I would hope
> that we could basically reuse the existing Remote Make builder for the
> latter part.
>
> For sync'ing the source, the main points would be:
>
> (1) the user should be able to specify what directory on the remote
> machine the source should be uploaded (rsync'd) to
>
> (2) the user will probably want to be able to exclude some files (e.g.,
> documentation) from the rsync
We definitely need some way of doing sync before build. I am not sure yet though how or where to hook that in. I think there are pre-build events that get fired that we could hook into in order to trigger a sync. I am guessing there are at least because the save-on-build feature must be hooking into something. Need to confirm that.
The sync mechanism will have to be extensible. Not everyone will be using rsync. In fact, they may not be using any external program to sync at all. They may wish to sync via SSH, or dstore, for example. There may be other Eclipse-based mechanisms they want to use for synching.
> Finally, we would need a way to launch the remote executable. I have no
> idea how to do this, since there's no file in the local project which
> can be launched...
>
> Also, I'm not sure how source lookup works (for debugging), although I
> expect problems here too...
Well as long as you somehow know the path to the executable, it should be possible to create a launch config that targets it. But if the binary is not a part of your project, you will miss out on being able to do nice things like Right Click->Debug As...
Source lookup I will warn you, is not EFS aware. It just maps paths as found by the debug engine to paths in the workspace or on the local machine. Handling arbitrary remote files outside of the workspace is a bit tricky, but possible.
===========================
Chris Recoskie
Team Lead, IBM CDT and RDT
IBM Toronto
Jeffrey Overbey ---12/14/2009 06:20:10 PM---I wanted to bring this up for discussion. I'm particularly hoping to hear from Chris, Doug, and th
From: | Jeffrey Overbey <subscribe-ptp-dev@xxxxxxxxxxxx> |
To: | Parallel Tools Platform general developers <ptp-dev@xxxxxxxxxxx> |
Date: | 12/14/2009 06:20 PM |
Subject: | [ptp-dev] Thinking about rsync-before-make hybrid local/remote projects |
Sent by: | ptp-dev-bounces@xxxxxxxxxxx |
