Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 368163 - Microsoft.Targets.Win32 fails to detect compiler version when configuro run as custom build step under Microsoft Visual Studio 2008
Summary: Microsoft.Targets.Win32 fails to detect compiler version when configuro run a...
Status: ASSIGNED
Alias: None
Product: RTSC
Classification: Technology
Component: Targets (show other bugs)
Version: unspecified   Edit
Hardware: PC Windows 7
: P3 minor (vote)
Target Milestone: ---   Edit
Assignee: Sasha Slijepcevic CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-01-09 09:21 EST by Gordon Deane CLA
Modified: 2012-01-13 04:42 EST (History)
0 users

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Gordon Deane CLA 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 CLA 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 CLA 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.