Community
Participate
Working Groups
To reproduce on windows xp: - Create a new Standard Make C Project - Add a makefile with the following in it: all: printenv - Build project The environment that is displayed in the console is the sysytem environment and does not include variables set programatically such as the PWD and CWD variables that are set to the project working directory in the make builder. Also for our CDT-based application can't modify the path to pick up our tools.
Interesting, The information is simply not use. The idea is that since you can create Target on any folder, the Folder itself is use as the location; For example, if you create a "Target Property" call "all" on /project/src and run this the action "Build Target", you will see that CWD/PWD is set to /project/src no matter what the buildDirctory was set to. So in brief if the build is run __by the platform__ like running "clean" this is where the property working directory will be use. I certainly understanding your point, it seems to be confusing. We should document the behaviour and make things more consistent. Many folks here are on vacation but we'll put this as a most for 2.1 How does it sound ?
The issue isn't what the PWD/CWD get set to, but the fact that they are not being set at all. It looks to me like a call to exec function in org.eclipse.cdt.core.CommandLauncher i.e public Process execute(IPath commandPath, String[] args, String[] env, IPath changeToDirectory) is failing to propagate the "String[] env" variable through to the code that eventually does the exec. As a result, the program being executed (e.g make) always gets executed in the users default system environment rather that with what has been set up programmatically. The bit with the PWD/CWD is just to demonstrate these variables are not being set in CDT 2.0 whereas they were in CDT 1.2.x. This presents a problem for our port because we set up the environment to launch make in so as to pick up our toolchain without requiring it to be on the users path. However, in CDT 2.0 (on Windows XP) it is failing to find the tools as the environment is not being setup correctly. Having tried to debug it the env variable gets propagated properly through to the Spawner class upto the point it hits the native function: native int exec0( String[] cmdarray, String[] envp, String dir, int[] chan) throws IOException; It seems like from this call to the native C/C++ code the envp variable isn't correctly propagated ?
> The issue isn't what the PWD/CWD get set to, but the fact that they are not > being set at all. .... > It seems like from this call to the native C/C++ code the envp variable isn't > correctly propagated ? Allright, For now as a quick remedy, remove/rename the DLL: org.eclipse.cdt.core.win32/os/win32/x86/spawner.dll When this dll is not found the CommandLauncher/Spawner fall back to use java.lang.Runtime.exec(); Resetting the MilesStone to 2.0.1 and escalating to Major. PR reassign to Alex.
Works in the HEAD branch now
> Works in the HEAD branch now Many thanks, Alex. Tracy M., Please let me know if this fix things for you then base on the feedback we will move this to the 2_0 branch
Yes, that fix on the HEAD does the trick - the environment is now being set up correctly. Thanks for the quick response.
> Yes, that fix on the HEAD does the trick Fix in the branch and the head.
It was verified by Tracy and Alex
