13

I am trying to convert a static library from VC++2008 to VC++2010, and I get these warnings about TargetPath and TargetName. I have had a look into my configuration and I'm not sure how to make these go away. Is it serious or is it really just an ignorable warning, for a static library that I usually build once and rarely rebuild.

I think it has something to do with the fact that the project is named itk32, but the debug version of the library is named itk32d.lib, and the old way that this is configured in Visual C++ 6.0 era has resulted in some kind of weird settings staying in the vc2010 project, which was converted a while ago from VC6 to 2008, and I am now converting to 2010:

1>------ Build started: Project: Itk32, Configuration: Debug Win32 ------
1>...\Microsoft.CppBuild.targets(1151,5): warning MSB8012: TargetPath(C:\...\Libraries\Itk\.\Debug\Itk32d.lib.lib) does not match the Library's OutputFile property value (C:\...\Libraries\Itk\Debug\Itk32d.lib). This may cause your project to build incorrectly. To correct this, please make sure that $(OutDir), $(TargetName) and $(TargetExt) property values match the value specified in %(Lib.OutputFile).
1>...\Microsoft.CppBuild.targets(1153,5): warning MSB8012: TargetName(Itk32d.lib) does not match the Library's OutputFile property value (Itk32d). This may cause your project to build incorrectly. To correct this, please make sure that $(OutDir), $(TargetName) and $(TargetExt) property values match the value specified in %(Lib.OutputFile).
========== Build: 1 succeeded, 0 failed, 0 up-to-date, 0 skipped ==========
Warren P
  • 65,725
  • 40
  • 181
  • 316

3 Answers3

22

The build system was dramatically overhauled in VS2010, it now uses MSBuild instead of the custom VCBuild system. The same build system used by other languages supported by VS. They did a pretty good job of making that invisible, old projects normally build just fine. But there are a few places where you can get in trouble when you import old projects. Which is what this warning is saying.

Using the linker's General + Output File setting to name the output file is one such troublespot. Not actually that sure what can go wrong, it probably has something to do with dependency checking. The default setting for it is $(OutDir)$(TargetName)$(TargetExt). The best way to rename the output file is therefore to change the $(TargetName) macro value.

Which is available on the main General page as the "Target Name" setting. It didn't exist in earlier VS versions. So change that one to "itk32d". Or better, $(ProjectName)d. And reset the linker setting.

Hans Passant
  • 922,412
  • 146
  • 1,693
  • 2,536
  • So it looks like previous versions of Visual C++ allowed some rather odd structures for copying resulting .dll, .exe and .lib results (output files) to different directories, and if I reset the output settings, and then do a post-build step that does the file "move to new location" part, it will keep the MSBUILD system happy? – Warren P Jun 01 '13 at 20:48
  • I have absolutely no idea how you drew that conclusion from my answer :) I focused on the specific settings that cause the warning and how the adjust your project settings to avoid it. Shouldn't take but a few minutes to try them. – Hans Passant Jun 01 '13 at 20:57
  • I spent an hour playing with the settings you mention, and my brain is now conformed to the underlying reality. In other words, thanks, man. In my case, the comment above is more about my own project's structure, where it seems that upon importing into VS 2010, it was indeed not generating a target and output file name property that matched up. (Different directory levels, one had a few more `..\..\..\` type relative up-the-path walks than the other) – Warren P Jun 04 '13 at 17:38
  • Change the linker setting, worked for me as well, same as this [answer](http://stackoverflow.com/a/29728807/1257607) – DanielV Apr 01 '16 at 11:17
1

I had this problem but could not find a valid answer here in SO, eventually I found out that it was solved by fixing the Intermediate Directory from ".\Debug" to "..\Debug", and ".\Release" to "..\Release" in each build configuration.

I'm sorry this is only worth for a comment but I don't have enough points to add comments to other people's posts.

blit
  • 396
  • 5
  • 12
-1

have experienced similar looking problem but i was able to resolve changing $(ConfigurationName) of parameter using previous version's convention to $(Configuration).. I would not imagine such a thing but when I checked that was the case, naming convention is changed and re-intrepretation is mostly works and there but for few things it is not fully interpreted and that was the cause..

Fiko
  • 1