search

rolandschulz / PTP

Eclipse Parallel Tools Platform
http://www.eclipse.org/ptp/
6 stars 2 forks source link

Try to make sync projects work with managed projects #4

Closed rolandschulz closed 13 years ago

rolandschulz commented 13 years ago

Currently we don't call the function from our builder to create the makefile and in your GUI I get the following exception:

java.lang.StringIndexOutOfBoundsException: String index out of range: 44 at java.lang.String.substring(String.java:1067) at org.eclipse.ptp.rdt.sync.ui.properties.BuildRemotePropertiesTab.setValues(BuildRemotePropertiesTab.java:349) at org.eclipse.ptp.rdt.sync.ui.properties.BuildRemotePropertiesTab.createControls(BuildRemotePropertiesTab.java:182)

May be we can subclass our builder from CommonBuilder and use its performPrebuildGeneration to generate the make files.

eblen commented 13 years ago

Raising priority, as Greg is interested in having this for Indigo.

eblen commented 13 years ago

It looks like remote projects do, in fact, automatically generate directories and makefiles when building is activated. I see nothing, however, in the RemoteMakeBuilder that could trigger this behavior. So I'm stumped at this point. Let me know if you have any ideas...

rolandschulz commented 13 years ago

I don't understand. When you say they generate directories and makefile, does it mean it works correctly? And if so what works? Only for the workspace configuration or also for remote? And do you mean with remote projects std-rdt or sync?

On Thu, May 26, 2011 at 1:46 PM, eblen < reply@reply.github.com>wrote:

It looks like remote projects do, in fact, automatically generate directories and makefiles when building is activated. I see nothing, however, in the RemoteMakeBuilder that could trigger this behavior. So I'm stumped at this point. Let me know if you have any ideas...

Reply to this email directly or view it on GitHub: https://github.com/rolandschulz/PTP/issues/4#comment_1244029

ORNL/UT Center for Molecular Biophysics cmb.ornl.gov 865-241-1537, ORNL PO BOX 2008 MS6309

eblen commented 13 years ago

I was trying Remote projects (not sync) with RC1. Just now I looked at the builders. For managed projects, they are using the CDT builder! For unmanaged projects, though, they still use the RemoteMakeBuilder. I had assumed they were always using RemoteMakeBuilder, and so I could not figure out how they were able to generate makefiles.

So I will look into how they use the CDT Builder.

rolandschulz commented 13 years ago

maybe we should ask why they still use the RemoteMakeBuilder for unamanged ones. Because that way, I guess, you cannot switch between managed/unmaged in existing project. This is possible with standard C projects but I doubt that RDT is switching the builder in that case.

Also it seems to be more simple to me to use always the same builder. Thus I think I would prefer to always use the CDT builder, both for simplicity and so that the user can switch.

They don't really use the CDT builder itself, but a RDT child-class of the CDT builder, right?

eblen commented 13 years ago

I agree. It makes more sense to use the same builder. I think they are using the CDT builder itself. In the rdt.core list of extensions, I see the RemoteMakeBuilder but no other builders. It seems they have two wizards - one for remote makefile projects and another one for everything else.

rolandschulz commented 13 years ago

that's odd. how do they make the standard cdt builder execute the make command remotely?

On Thu, May 26, 2011 at 3:48 PM, eblen < reply@reply.github.com>wrote:

I agree. It makes more sense to use the same builder. I think they are using the CDT builder itself. In the rdt.core list of extensions, I see the RemoteMakeBuilder but no other builders. It seems they have two wizards - one for remote makefile projects and another one for everything else.

Reply to this email directly or view it on GitHub: https://github.com/rolandschulz/PTP/issues/4#comment_1244853

ORNL/UT Center for Molecular Biophysics cmb.ornl.gov 865-241-1537, ORNL PO BOX 2008 MS6309

eblen commented 13 years ago

Yes, that's what I was wondering. Not just make, but also creating directories and so forth. Such commands in the CommonBuilder are all local. So I think they execute commands locally and then push files to the remote site. That doesn't make sense for make, though, unless managed projects can only be compiled locally.

rolandschulz commented 13 years ago

did you try whether it works?

On Thu, May 26, 2011 at 4:12 PM, eblen < reply@reply.github.com>wrote:

Yes, that's what I was wondering. Not just make, but also creating directories and so forth. Such commands in the CommonBuilder are all local. So I think they execute commands locally and then push files to the remote site. That doesn't make sense for make, though, unless managed projects can only be compiled locally.

Reply to this email directly or view it on GitHub: https://github.com/rolandschulz/PTP/issues/4#comment_1245035

ORNL/UT Center for Molecular Biophysics cmb.ornl.gov 865-241-1537, ORNL PO BOX 2008 MS6309

eblen commented 13 years ago

It's surprisingly hard to test. I was never able to successfully compile, and thus unable to trace where the compilation occurs. Regardless, the GUI indicates it is a remote compiler. I think I know how this is done. The build service provider of the service configuration has the connection to use for builds. They only need a single service configuration, so they just set the build provider to use the remote host. All other commands are run locally. Since sync switches between multiple service configurations, it would need its own builder in order to switch just before building.

rolandschulz commented 13 years ago

If I create a new remote project, I don't have anything else in "Project type" than "Remote Makefile Project->Empty Project". You see more than that there?

eblen commented 13 years ago

That's all I see for my development build, but there are more options if you use RC1.

eblen commented 13 years ago

I don't think my earlier explanation is correct. The CommonBuilder does not seem to use the service configuration. Instead, a "CommandLauncher" class is used. So it is still a mystery how RDT can run remote builds using the CommonBuilder. Unfortunately, there is no way to set the launcher, even from the CommonBuilder code. Otherwise, we could define our own sync launcher.

rolandschulz commented 13 years ago

I don't think it does. Even for the "managed" project I always see the RemoteMakeBuilder. I was never able to create an rdt project and see the CDT builder in the settings.

Send from ASUS Tranformer On May 31, 2011 12:13 PM, "eblen" < reply@reply.github.com> wrote:

I don't think my earlier explanation is correct. The CommonBuilder does not seem to use the service configuration. Instead, a "CommandLauncher" class is used. So it is still a mystery how RDT can run remote builds using the CommonBuilder. Unfortunately, there is no way to set the launcher, even from the CommonBuilder code. Otherwise, we could define our own sync launcher.

Reply to this email directly or view it on GitHub: https://github.com/rolandschulz/PTP/issues/4#comment_1268125

eblen commented 13 years ago

RDT works by extending the plug-in org.eclipse.cdt.managedbuilder.core.buildDefinitions, which supports many options for configuring managed builds. Most importantly, it has an option to specify a command launcher. In commit 456f75f2c5d651c951d15c5c51f8052697d0ea37 I have added the extension point and command launcher. For the latter, I copied RDT's RemoteCommandLauncher, which has code very similar to that in RemoteMakeBuilder, and then added the changes we had made to the builder for sync.

eblen commented 13 years ago

Managed build now seems to work out-of-the-box as of commit 992427c6582249ff05c2a2cbf42e9a846f37c5a3. The "Sync Builder" is set as default, but the user can still select other builders, which of course will not work. I would like to completely remove RemoteMakeBuilder, but it seems entrenched (removing it produces multiple errors), so at the moment it is still there.

eblen commented 13 years ago

No problems found during Indigo testing, so closing this issue.