[cdt-dev] Remote EFS designs
- IPath <==> URI conversions are not always properly handled
Consider the following example:
IPath path = new Path("c:", "/a/b/c"); IFileStore f = EFS.getLocalFileSystem().getStore(path); then print out f.toURI() you get something like: file:/path/to/workspace/c:/a/b/c
Lack of Windows path support
- There is no device field in a URI. I.e., it's not legal to have c: in a URI.
Is there any eclipse EFS URI specification to refer? It seems to be legal to have ":" character in URI according RFC 2396
. You may need to escape it in case of conflicts with schema but it does not look that it is the case in our case.
Building projects: IResources -> Command Line Arguments
Include folders could be expressed using URI. So could build location in project properties. I am not sure how far we want to go with that for now, but suggest to add as part of collecting requirements.
Resolving absolute paths
There is one more case deserving to be considered. The absolute path could be outside of the project but in the workspace as part of some other project. Not sure how important it is for generating makefile but it is very important for parsing error output and assigning markers.
> Feel free to edit / bring up issues you think I may have missed.
I don't think All has permissions to edit the page. If so could you instruct how to do that.
On Thu, May 28, 2009 at 12:08 PM, James Blackburn <jamesblackburn@xxxxxxxxx>
We had a quick brainstorm about generating markers for build output
for the case of remote builds using RDT, and how this might interact
with e4 style flexible resources (effectively glorified linked
resources). I don't think there's much of issue apart from: make
ErrorParserManager support URIs.
I've added some detail to the EFS wiki :
http://wiki.eclipse.org/PTP/designs/remote/EFS adding two sections:
1.1.1 FileStore layers & 1.4 Implementation Assumptions.
This documents what was discussed. i.e. converting IResources to paths
for the builder (which is done now) & the reverse: converting Tool
output paths to IResources.
The approach outlined is that any IResource may be linked, and may
point to an arbitrary EFS URI. The EFS URIs, are assumed to map to a
filesystem tree of the same structure (this assumption is currently
made by the RDT tools and elsewhere). The job is then converting
Console output paths to locationURIs to resolve.
This approach allows fully flexible IResource trees (using Serge's e4
work for ease + a few minor tweaks to ManagedBuild), and is working
well here. I see no reason why this shouldn't work nicely with RDT as
it does for local file systems.
Feel free to edit / bring up issues you think I may have missed.