Bug 411236 - Build doesn't run on active remote host but on localhost instead
Summary: Build doesn't run on active remote host but on localhost instead
Status: NEW
Alias: None
Product: PTP
Classification: Tools
Component: RDT.sync (show other bugs)
Version: unspecified   Edit
Hardware: PC Linux Qt
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: Project Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords: needinfo
Depends on:
Blocks:
 
Reported: 2013-06-20 08:27 EDT by Daniel Rohe CLA
Modified: 2014-06-02 02:09 EDT (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Daniel Rohe CLA 2013-06-20 08:27:09 EDT
OS: SuSE Linux
Version: Kepler Release
Build id: 20130529-2219
RC 2 (or 3) updated with nightly builds

Sometimes the build process invoked from within PtP runs on localhost instead of the active target host. This happens regularly, but not always and not in a completely reproducable manner.

Context:

i) I defined remote connections and synchronizations

ii) I defined additional build configurations

iii) when I set a remote connection to 'active' and choose one of the NEW build configurations, the build process does not run on the corresponding remote host, but on localhost. 
Initially, I can see that the console does an ssh on the remote machine, and also that a certain part of the make process runs on the remote machine, but apparently the connection closes at a certain stage and returns to localhost and continues there.

Note: I can only see this because I echo out the host name during the make process, otherwise the console view does not contain any information on the machine it runs on (at least I could not figure out where such information would be).

iv) once this behavior has set in, it remains. When I first define new configurations it works for a while, but after a certain time it changes to the above.

v) if I chose one of the original build configurations all is good and the build process completes on the remote host, even when it is completely identical to the new configuration which fails.
Comment 1 John Eblen CLA 2013-06-27 14:19:44 EDT
Could you provide some more information:

1) Are you using multiple remote hosts?
2) Are you also creating additional sync configurations?
3) What project type and toolchains were initially selected in the wizard?
4) What was altered in the new build configurations? (toolchain, builder, etc.)
5) How is the host name printed? Note that since files are synchronized, it may not be clear which version of a file is on what machine. The Makefile itself may be sync'ed before and after the compile occurs.


Thanks!
Comment 2 Daniel Rohe CLA 2013-06-28 03:42:04 EDT
1) Yes, I use several remote hosts.

2) For each remote host I have one remote connection and one entry in the 'Synchronize' section. Is that what is meant?

3) It's a C/C++ synchronized project with GCC toolchain.

4) I derive a new build configuration from an existing one by copying it and change only the value of a parameter that is passed to the make command.

5) The hostname is printed by an echo within the Makefile when the first action is done. Before that I can infer from the output that the process initially runs on the remote host, but then it changes to the local host. The Makefile is not changed before compilation.

NOTE: When I delete the new build configurations and set them up again they do work for a period of time. I don't know what triggers the odd behaviour, but once the problem arises it persists. I'll let you know if I can observe any reproducable actions that may trigger this.

What I would find extremely helpful would be some means of showing the remote host on which things are happening in the console view.
Comment 3 John Eblen CLA 2013-06-28 11:36:55 EDT
Okay, that is odd because the location (machine and directory) where the build occurs is that of the active 'sync configuration' (the entries in the 'Synchronize' section) and is mostly independent of the CDT 'build configuration'. (It is possible to alter the directory from inside the build configuration, but that seems irrelevant here.) This is different from PTP versions prior to Kepler, where the sync location was bundled with the build configurations.

When switching sync configurations the build configuration is switched to the default as listed in the 'Synchronize' section. Changing build configurations, though, does not change the active sync configuration. This automatic switching may cause some confusion if you create a new build configuration and then switch the sync configuration.

This information doesn't answer your question, of course, but may be helpful for gaining insight into what is happening.

Are you using an old project created under Juno? If so, that could be causing some odd behavior. Be sure that the project has been rebuilt under Kepler.
Comment 4 Daniel Rohe CLA 2013-07-01 03:26:52 EDT
I am using a project created in Kepler, therefore I'd think that's not the cause. 

The hint towards a possible connection between the automatic switch to the default configuration could be very helpful.

I have not yet been able to pin down a deterministic way of reproducing the issue, but it did seem to me that it happened whenever I touched the Synchronize settings in the project properties pane, or when I change the active host several times.

I'll let you know as soon as I know more.
Comment 5 Daniel Rohe CLA 2014-06-02 02:09:20 EDT
As a matter of fact I have changed to using an ssh terminal within PTP to log in to the different machines and do a build there explicitely. It turned out to be the more convenient way, albeit a step or two more. But it's safe.

I'd suggest I'll try it again with the upcoming version.