Community
Participate
Working Groups
The parallel launcher should be configurable in the same way as the launcher for C/C++ and Fortran projects (under the "Main" tab). This includes enabling/disabling auto build as well as specifying the build configuration. The latter is important for synchronization projects, since it also specifies the remote site used for building.
Adding this functionality would make the PTP launcher dependent on CDT. Currently there is no such dependency, and I'm not sure if we want to require installation of CDT to use the launcher (see bug 364191.) Specifying the build configuration without introducing a dependency would require an extension point and an additional plugin. Is this complexity worth the extra functionality? We could still provide the enable/disable launch part if that would be useful.
I think this is rather important for synchronized projects. If you use both
(In reply to comment #2) > I think this is rather important for synchronized projects. If you use both sorry submitted accidentally. If you use both local and remote configuration (or more than one remote configuration) than it isn't guranteed that the application is build before it is launched because we might build the local (or other remote) instead. If we can't gurantee that the application is built on the correct machine, than it seems to me worse than no build-before-run at all.
Adding few more error scenarios that could happen if the remote launch is executed on one host, but the build prior to the launch is executed on a different host, as specified via active build configuration. * The remote launch stops claiming that there is no executable. This happens if the executables have different names on different hosts. * If the executables happen to have the same name on both hosts, the synchronized projects mechanism would replicate (say) an AIX xcoff executable on an ELF64 environment and the remote launch would crash claiming that this is not the right executable format. * The recompile might be due to a source change, but this change is only reflected in the executable that is re-made, not the one that is actually executed. This might lead to prolonged bug chasing because the bug is looked for in the wrong executable. To avoid these confusing scenarios, I would suggest that the remote launch changes the build configuration such that build host and launch host match.
This blocks bug 393244, on which I am currently working, so I have been looking at possible solutions. I think this can be solved without introducing a dependency on CDT. Our eventual goal is to have CDT-independent configurations for synchronized projects. So I could go ahead and create a "RemoteInfo" class for this purpose that encapsulates the CDT build configurations. Only the launcher would use this class for now, but later it would be used throughout the code to address bug 364191 (removing CDT dependencies). I propose that in the launcher UI, the Resources tab be changed so that users select project and configuration, instead of connection, and that project selection be removed from the Application tab. Given the recent changes to the launcher, in what package should these UI changes be made? Is the answer different between master and ptp_6_0? Please let me know your thoughts on these proposed changes.
I can't comment on the definition of a class "RemoteInfo", as I am not familiar with the code and the implications that such a definition would have. But encapsulation and removal of dependencies sounds like a plan at any rate. As for the proposed changes for the launcher UI, I just started eclipse for having a close look at my "Run configurations". As a result, I would strongly vote for the proposed changes. In my view, it would bring the "parallel Application" UI closer to "C/C++ Application" UI. The latter has a "Main" tab, which allows to choose the Build Configuration, either by pull down menu or by "Select configuration using C/C++ Application".
(In reply to comment #5) > > I propose that in the launcher UI, the Resources tab be changed so that users > select project and configuration, instead of connection, and that project > selection be removed from the Application tab. The problem with this is that it ties the launch to a project. While this may be desirable in some cases, it prevents using PTP to launch an application that does not have an associated Eclipse project (e.g. the sysmon application).
What is the current expected behavior, post-Kepler, for building prior to launching? I tried launching jobs in Kepler and no builds occurred, even though a sync CDT project was specified in the "Application" tab. In my development environment, though, launching a job triggered a build of every project in the workspace, even though a non-CDT sync project was specified.
(In reply to Greg Watson from comment #7) > (In reply to comment #5) > > > > I propose that in the launcher UI, the Resources tab be changed so that users > > select project and configuration, instead of connection, and that project > > selection be removed from the Application tab. > > The problem with this is that it ties the launch to a project. While this > may be desirable in some cases, it prevents using PTP to launch an > application that does not have an associated Eclipse project (e.g. the > sysmon application). Probably the best way to resolve this, is add a new run-configuration type "Parallel C/C++/Fortran Application". The existing "Parallel Application" could stay as is and the new one could be tied to a project and a CDT build configuration. Then the auto-build would work for that configuration.
