| Re: [linuxtools-dev] PTP/RDT and remote linuxtools |
I created a new C project (not Remote C/C++ project, because that doesn't have any autotools toolchains I can select) and selected the GNU Autotools Toolchain. I selected Remote Tools as the filesystem provider, and a valid remote directory and connection. It created all of the files for the example Hello World ANSI C Autotools Project. When I go to build it, I get this NPE:Have you seen this?No, but I know what is causing it. I am trying to get the Project's location and add a path to it, then using the proxy File Manager to do a getResource(). The getLocation() call tries to return an IPath or null. I should be using getLocationURI() instead. I am looking into it. I will have to change this in a number of places.I performed a similar experiment to yours whereby I chose RSE as my filesystem and picked a localhost location for the new project. I got the following sequence in getSavedConfigs() to work for both a regular local project and an RSE filesystem (localhost) project: URI projectLocation = project.getLocationURI(); URI fileLocation = new URI(projectLocation.toString() + "/" + CFG_FILE_NAME); // $NON-NLS-1$ IRemoteFileProxy proxy = RemoteProxyManager.getInstance().getFileProxy(project); IFileStore f = proxy.getResource(proxy.toPath(fileLocation).toString()); I believe this would also work for a remote RDT project. Please correct me if I wrong in this assumption.Yes, it seems like it should.
Just to let people know, I fixed up the other file accesses in Autotools for the RDT branch. I am able to select RSE from the filesystem combo box for an Autotools project. I then selected a local location outside of the workspace. The Autotools part of the build worked fine. The project was configured. As well, the reconfigure action worked fine as did the Autoconf editor.
The build failed on the CDT side when it tried to run the Makefile because it accessed files via normal means. So, what to do about this? One way would be to solve the problem in the CDT similar to how Autotools did it (use a proxy and allow the proxy to be optionally serviced by RDT). A large task.
If RDT already has a Makefile builder and scanner discovery etc.., perhaps an alternative would be to hook these up on the fly when we recognize the situation. Otherwise, we will have to have a special project wizard. I prefer the idea of just using the filesystem combo box to determine where the project resides and thereby leaving all other UI elements the same as well as having common code for local and remote.
Any thoughts?I haven't modified the branch to use the RDT proxy based on project URI. Is it fair to assume that RDT supports RSE so the RDT proxy could support URIs starting with "rse:"? Is there an RDT-specific id to look for as well?
The experiment indicates to me that the proxy cannot base itself on the project nature. It appears that the remote proxy should be used, if present, for all accesses. Seem reasonable?Sorry, I don't understand what you mean. Are you saying the getFileProxy(IProject project) method needs to be re-written not to base on the proxy? Or that the per-nature extension shouldn't look at the nature?That it shouldn't look at the nature. If one can use the filesystem drop down to create the remote project, then there is no special wizard needed and there is no nature requirement.I think the URI string already has service name (e.g. remote tools) already encoded into it, so maybe you could use that instead of the nature to determine which connection service to use?Yes, I think that may be the better way to do this. The extension would then specify which connections it supports rather than natures.- Corey_______________________________________________ linuxtools-dev mailing list linuxtools-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/linuxtools-dev