1

I have recently gotten into the guts of MSBuild to factor out commonalities among nearly twenty *.vcxproj project files. Previously I had been manually setting everything with Visual Studio, but the commonalities were too much to ignore in the face of the fact that I have several new configurations to produce now.

I'd like to compare the compiler and linker switches used in the old and new build process. I noticed that this information seems to be contained in e.g. cl.command.1.tlog and link.command.1.tlog files in the $(IntDir)$(TLogLocation) directory after building. They seem to be there whether I use MSBuild or use Visual Studio to perform the build. I've scoured C:\Program Files (x86)\MSBuild's files, and I have located places where I would think this should occur, but have come up short. I realize that I could just aggregate these outputs with a script and compare them, but for my own edification I was trying to locate the MSBuild variable that contains the switches for each *.c / *.cpp / *.obj file. When I couldn't locate that, I started looking for where these *.tlog files were being generated.

At this point I have theorized that perhaps it is the executables themselves doing this work (cl.exe / link.exe), but I'm not 100% convinced of this. Normally I suppose I would move on, but it raises a question in my mind as to how someone would integrate a new tool into MSBuild. Is there an interface somewhere that dictates that you have to follow this paradigm? e.g. if the new tool were called foo.exe, it would be required to place foo.command.1.tlog and other foo.*.1.tlog files for tracking?

mathonnapkins
  • 61
  • 9
  • 1
    The name doesn't *have* to be the same as the tool's name, the tracker just seems to look at *.tlog files. And those files aren't required per se, it's just to get incremental builds working. But I got all that from trying things out and posts like https://stackoverflow.com/questions/5729519/file-tracker-log-file-format: in the past there never was any official documentation regarding file tracking, not sure if that changed already. – stijn Nov 15 '17 at 13:08
  • Thanks for the comment. I did some digging with Process Monitor and found that the *.command.1.tlog files are generated by MSBuild.exe itself. The tools that are invoked, like cl.exe and rc.exe, do interact with *.read.1.tlog and *.write.1.t.log files, but seem to be directed to do so, probably by MSBuild. I didn't want to take this deep a plunge but I think I shall use this: https://blogs.msdn.microsoft.com/visualstudio/2010/07/06/debugging-msbuild-script-with-visual-studio/ to debug MSBuild in combination with Process Monitor to see when the *.command.1.tlog files are written... – mathonnapkins Nov 15 '17 at 18:50
  • Yeesh, I also didn't realize MSBuild was open source. I will have to take a peek at what it's doing. Silly that I didn't think to look before =T – mathonnapkins Nov 16 '17 at 19:00

0 Answers0