2

Background:

My team wants Visual Studio for development on an existing codebase, for its various tools, and that's what most developers are used to using. However, the existing build system (an internal flavor of Jam) is very entrenched, and for a variety of factors cannot be changed.

The idea:

  1. Create a project for each component. I did this using a description generated by Jam of what files go into each library, and making that into a QT project file. I call qmake on this to generate Visual Studio projects with "qmake -tp vc".

  2. Disable Visual Studio's build. I did this by changing the Type of each source file to "does not participate in build" (by changing each to )

  3. Add a pre-build event that calls the Jam build.

Problem:

Now, when I try to build from Visual Studio, it works, in that it calls Jam. However, I would expect Visual Studio to think the project is always up-to-date, considering it is not actually tracking any source files for compile. But it is always out-of-date, and must call the pre-build command before debugging (which attaches the debugger to the executable, and works just fine).

I used DebugView to see what was going on, and for many of my projects, I get the following in the log

[12900] Project '<my project's name>' is not up to date because 1 build inputs were missing. 
[12900] devenv.exe Information: 0 : 
[12900]  up to date is missing: '<my project's location>\@ECHO'

I've searched high and low, but cannot find any reference to @echo as a file input to anything anywhere. Does anybody know, and/or is there a way to track down why it is looking for this?

Clare Macrae
  • 3,473
  • 2
  • 26
  • 42
EmersonKnapp
  • 80
  • 6
  • `@echo` looks very much like the first line of a DOS "batch file" script (a file ending in `.bat`). It's how you make a batch file display some text. I don't know what's going on, but that may be a clue. – librik Feb 12 '13 at 07:06
  • Visual Studio generates batch files for its builds. The problem is that the combination of maximum Windows command line lengths, typical Windows file paths, required number of directories, and cumbersome UI to specify relative directories together mean that VS cannot call CL.EXE directly. – MSalters Feb 12 '13 at 09:39

0 Answers0