Community
Participate
Working Groups
It's not yet possible to set environment variable for C/C++ Remote Application.
patch proposal submitted here: https://git.eclipse.org/r/20042
When testing I noticed a strange behaviour. The Environment tab has options at the bottom to: "Append env to native end" OR "Replace native env with specified env" Does that make sense in the case of a remote launch? What do we mean by the 'native' env? I'm thinking the 'native' env would be the one on the remote machine, no? Currently, we use the local's machine 'native' env and push it to the remote machine. This probably wrong. Furthermore, doing this causes the other strange behaviour that if we define a variable in the new env tab and leave 'append' selected, the remote environment will have many variables defined (the one we defined plus all 'native' of the host); on the contrary, if we don't define any vars in the new env tab, no environment is sent to the remote at all. I think that when nothing is define, we should leave the remote env as it is (I'm not sure this is what was happening before this change). If we do define a variable and choose 'append' we should keep the remote env and add the var. If we define a var and choose 'replace', then we should only use the new var. I'm not sure this is possible, as it may require obtaining the remote env... What do you think?
Hi Marc, Many thanks for your comments. As far as I know, before this patch, commands are run in a empty environment. Yes, empty env, not the default environment of the target. For now, I do not know how to retrieve the target environment. I will check. Perhaps we have to define our own Environment Tab, with 3 options: * Append to remote env * Append to local env, and use it on remote * Replace remote env with specified env
(In reply to Xavier Raynaud from comment #3) > As far as I know, before this patch, commands are run in a empty > environment. Yes, empty env, not the default environment of the target. You are right. I wasn't aware of this. I think it would have been better to keep the default target env, but I'm not sure if RSE supports that, or if we have to find the target env first and pass it to RSE. > For now, I do not know how to retrieve the target environment. I will check. Thanks. I don't know either. > Perhaps we have to define our own Environment Tab, with 3 options: > * Append to remote env Yes. > * Append to local env, and use it on remote I'm not sure this one is really necessary. A target can often be very different than the host so the local env often will not make sense for the target. And if it does make sense, it should/could be made part of the default remote env anyway. I don't think we need to provide this option. > * Replace remote env with specified env Yes. So, the good news is that we can keep the env tab as it is, we just have to treat the "native env" it mentions as the one of the remote target.
for info: https://bugs.eclipse.org/bugs/show_bug.cgi?id=162018
(In reply to Xavier Raynaud from comment #5) > for info: https://bugs.eclipse.org/bugs/show_bug.cgi?id=162018 Xavier, do you want to implement the fix in CDT anyway? If I understand correctly, we could work around RSE's current behaviour to provide partial functionality now and full functionality automatically once RSE's bug is fixed. But I didn't look deeply into it so maybe I'm wrong. Or maybe it is not worth the effort until RSE's bug is fixed?
The issue with current implementation in RSE is that we cannot retrieve environment of the target system when using ssh. Therefore, it's not possible to implement the behaviour described in comment #2 to #4. I've logged a comment in the RSE bug, in order to know if there is a fix or workaround.
(In reply to Xavier Raynaud from comment #7) > The issue with current implementation in RSE is that we cannot retrieve > environment of the target system when using ssh. > Therefore, it's not possible to implement the behaviour described in comment > #2 to #4. Currently, the only thing the remote launch supports is an empty remote environment. What we could do to improve this is to add the Env tab with the two options "Replace native env with specified env" "Append env to native end" The "replace" case would work as expected by only setting the variables set in the Env tab on the target. The "append" case would not work perfectly because of the RSE bug and would end up doing the same thing as the "replace" case. But it would automatically start to work as soon as the RSE bug was fixed (no need to update CDT). I think this would be an improvement on the current situation. I find that having a broken "append" case is not worse than the current behaviour of always having an empty remote env.
Ok for me. I will submit a patch proposal ASAP.
Xavier, I just remembered Bug 384050 where some of this work was discussed before. I believe your efforts got further along, but I thought you should know about it.
*** Bug 384050 has been marked as a duplicate of this bug. ***
(In reply to Xavier Raynaud from comment #5) > for info: https://bugs.eclipse.org/bugs/show_bug.cgi?id=162018 There hasn't been any progress on the RSE side, or at least nothing mentioned in the bug. However, we plan of migrating from RSE to o.e.remote. See bug 452356. Once that is done, we can get this bug fixed.
