Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 316569

Summary:	[Scanner Discovery] PATH environment variable oddities (Discovery Sanner, Launching)
Product:	[Tools] CDT	Reporter:	Sebastian Bauer <mail>
Component:	cdt-build	Assignee:	cdt-build-inbox <cdt-build-inbox>
Status:	RESOLVED FIXED	QA Contact:	Andrew Gvozdev <angvoz.dev>
Severity:	major
Priority:	P3	CC:	ilg
Version:	7.0
Target Milestone:	8.2
Hardware:	PC
OS:	Windows XP
Whiteboard:

Description Sebastian Bauer

2010-06-11 02:07:52 EDT

Build Identifier: I20100527-1700

For Managed Build projects, it seems that the PATH environment variable that is set in C/C++ > Build > Environment is not used when the the discovery scanner is invoked and Cygwin is used (didn't try MinGW). That is, if I don't have the path of Cygwin binaries in the global system PATH variable, but list it instead in the mentioned page to point to the Cygwin bin directory, invoking the discovery scanner doesn't result in the setup of the proper include paths. Although I briefly see a progress window telling that the discovery scanner runs, I cannot see an error message or a hint in the build console about the failure after the windows close. It would be in general nice, to see what is going on in the discovery scanner.

Now, if I supply the cygwin binary directory outside the Eclipse CDT environment in a global manner, then the discovery scanner works as expected. Therefore I conclude that the defect of the discovery scanner could possibly be explained some oddities in the setup/forwarding of environment variables directly within Eclipse CDT. I.e., the discovery scanner simply ignores the CDT specific environment variables.

The same is BTW for launching cygwin compiled applications directly within Eclipse. Basically, I cannot launch a single application if I do not add the cygwin bin directory in the global path (i.e., outside Eclipse) direcly from Eclipse. This probably has something to with the fact that cygwin binaries depend on cygwin1.dll that usually is located in the cygwin bin directory. Note that if I add the cygwin bin directory to be contained in the enviroment variable section of the launch configuration (Environment page) the program starts. (I realize that CDT's Environment page has been moved into the a Build category so strictly speaking the behaviour of CDT is okay, because launching is not building, but this page was in a more general category at least in CDT 5.0 and I think it is useful to specify CDT specific environment variables to ease multiple development environments).

What is very surprising is that the compiling process (i.e., the invocation of make) works even if I don't supply the cygwin bin directory (neigther in the system preferences nor in the CDT preferences).

Reproducible: Always

Steps to Reproduce:
1. Make sure that cygwin bin is not in the system global path
2. Add the cygwin bin directory to PATH variable of the CDT specific build environment variable page (e.g. PATH=D:\cygwin\bin).
3. Create the Hello World sample managed build application.
4. Realize that there are unresolved include files. Also realize that the binary has been produced.

5. Add cygwin bin directory to the global system path.
6. Restart eclipse
7. Rebuild the project created in 3.
8. Realize that the include paths can be resolved now.

Comment 1 Sebastian Bauer

2010-06-12 15:00:59 EDT

I can give some more details now. 

It seems that, if the PATH env variable is not set to the Cygwin bin dir prior to the start of Eclipse/CDT, the CygpathTranslator class is not operating correctly. In line 113 of /org.eclipse.cdt.make.core/src/org/eclipse/cdt/make/internal/core/scannerconfig/util/CygpathTranslator.java the condition 
 "if (cygpath.isAvailable)"
is false. This is due to the fact, that the "cygpath" command cannot be located when the CygpathTranslator object is constructed (BTW it would be nice to inform the user about this failure). I suggest that if "cygpath" command is searched that the entries of the Environment preferences is taken into account as well (there is also the default cygwin path tried, but I didn't install cygwin in the default path).

As said, it also makes sense to generalize the scope of the Environment settings as the launching is affected as well. Obviously, the environment variables are also useful with non-build related stuff. But this is probably something for post-CDT 7.0.0

Comment 2 Liviu Ionescu

2010-08-13 15:49:37 EDT

The problem is probably deeper, I'm facing it on Mac OS X too. According to my tests, when trying to run the compiler for discovery purposes, the PATH defined in Environment is not used properly and the compiler is not found (a warning is displayed in the Error Log). Running the same compiler to compile a C source works properly.

I did the tests by changing the compiler name to an ARM cross compiler.

When setting the PATH outside Eclipse, everything works just fine, both discovery and compile.

Another possibility would be that the compiler is executed, but when processing the output some incompatibility triggers the error and the message is the same as when the program is not found. (need to do some more tests).

Liviu

Comment 3 Andrew Gvozdev

2013-03-10 13:50:53 EDT

I believe this was fixed with changes for bug 357442 for Cygwin. Please, retest with nightly build.