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

Bug 368163

Summary:	Microsoft.Targets.Win32 fails to detect compiler version when configuro run as custom build step under Microsoft Visual Studio 2008
Product:	[Technology] RTSC	Reporter:	Gordon Deane <gordon.deane>
Component:	Targets	Assignee:	Sasha Slijepcevic <sascha>
Status:	ASSIGNED ---	QA Contact:
Severity:	minor
Priority:	P3
Version:	unspecified
Target Milestone:	---
Hardware:	PC
OS:	Windows 7
Whiteboard:

Description Gordon Deane

2012-01-09 09:21:03 EST

Am using XDC runtime with target microsoft.targets.Win32 (adapted for MSVC 9 / Visual Studio 2008) and running xdc.tools.configuro under Visual Studio as a Custom Build Step.  

microsoft.targets.ITarget.xs runs "cl.exe" (the command line compiler) with no inputs, capturing the output to determine the compiler version.  This fails when run within Visual Studio: the compiler output (stdout?) appears in the user-visible window and the Javascript in ITarget.xs says 

microsoft.targets: warning: exec of: cl.exe failed

The result is a spurious warning about version incompatibilities of the RTS library.  This can be ignored and the build succeeds.

Comment 1 Sasha Slijepcevic

2012-01-12 16:26:14 EST

I can see that Java's Process, which we use to run the cl.exe process, is not getting anything in its input and error streams. So, it seems cl recognizes it's inside Visual Studio and sends the output directly to the Build Console.
I tested this in VS 2005, so there might be other problems in VS 2008.

Comment 2 Gordon Deane

2012-01-13 04:42:30 EST

VS2008 sets a number of environment variables when it spawns subtasks.  It may be that some of these change the behaviour of CL.EXE?

eg.
VCBuildHelper_CancelEvent={9663CB8B-50FC-4DF6-BBE4-391D5879C5B7}
VCBuildHelper_Command=C:\Windows\SysWow64\cmd.exe

If so, possibly stripping these variables out of the environment might restore stdout?  I haven't got time to experiment at the moment, since I've got a workaround that works.