[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [linuxtools-dev] PTP/RDT and remote linuxtools
|
On 10/14/2011 02:01 PM, Jeff Johnston wrote:
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.
Ick!
If RDT already has a Makefile builder and scanner discovery etc..,
It doesn't have a Makefile builder (yet), but it does have scanner
discovery.
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?
The combo box seems clear enough.
It's not clear to me why the PTP/RDT developers chose to use a separate
project type "Remote C/C++ project" and introducing a different
mechanism for choosing toolchains, instead of reusing the C/C++ project
type. Maybe Greg Watson can fill us in here...
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:"?
I don't see why not.
Is there an RDT-specific id to look
for as well?
Yep! As a simple example, I just created a remote project using Remote
Tools, and here's URL visible in the project properties (under Resource):
remotetools://elm3a85/home/corey/test_project
- Corey
