Visual Studio 2010 和 Visual Studio 2010 2008无法处理不同文件夹中同名的源文件？

Question

直接问题：如果我有两个同名的文件（但在不同的目录中），似乎只有 Visual Studio 2005 可以透明地处理这个问题？ VS 2008 & 2008 2010 年需要大量调整吗？除了我的命名约定之外，我做错了什么吗？

背景：

我正在开发 C++ 统计库...我有两个文件夹：

/ Univariate

Normal.cpp
Normal.h
Beta.cpp
Beta.h
Adaptive.cpp
Adaptive.h

/ Multivariate

Normal.cpp
Normal.h
Beta.cpp
Beta.h
Adaptive.cpp
Adaptive.h

我需要支持交叉编译 - 我正在使用 g++/make 将这些相同的文件编译到 Linux 中的库中。他们工作得很好。

我一直在使用 Visual Studio 2005，没有任何问题，但我需要升级到 Visual Studio 2008 或 2010（目前对 nVidia 的 nsight 工具垂涎欲滴）。但是，如果我将文件添加到具有相同名称的项目（即使它们位于不同的目录中），我就会遇到麻烦。我愿意更改我的命名约定，但我很好奇其他人是否遇到过这个问题并找到任何详细记录的解决方案？

更让我困惑的是，如果我从 2005 年的项目升级到 2010 年的项目，VS 2010 似乎能够正确处理不同目录中同名的两个源文件；但是，如果我删除其中一个重复文件，然后将其添加回项目，则会收到以下警告：

Distributions\Release\Adaptive.obj：警告 LNK4042：多次指定对象；忽略额外内容

现在我将中间目录指定为 $(ProjectName)\$(Configuration) - 我需要将目标文件放在与源树不同的位置。所以我可以明白为什么它会相互复制目标文件，但是当项目从 2005 年转换为 2008 年或 2010 年时，会添加一堆条件编译：

<ObjectFileName Condition="'$(Configuration)|$(Platform)'=='Release|x64'">$(IntDir)%(Filename)1.obj</ObjectFileName>
<XMLDocumentationFileName Condition="'$(Configuration)|$(Platform)'=='Release|x64'">$(IntDir)%(Filename)1.xdc</XMLDocumentationFileName>

这些可以从 C/C++ 中的“源文件属性”页面访问->输出文件 -> “对象文件名”& “XML 文档文件名”。但是，如果我只是直接添加文件（或删除并重新添加它们），VS 不会抱怨，直到我尝试编译，但也永远不会添加条件指令 - 所以为了让事情正常工作，我必须自己为每个配置添加条件指令。我是否犯了一个错误/错误的假设，或者我是否在 VS 2008 / 2010 中发现了一个有效的错误？

Answer 1

所以@Hans Passant 指出了正确的方向，谢谢！您不必列出文件，一个文件夹就足够了。然后，如果您查看 VS 2010 列表底部定义的宏，您将看到：

%(RelativeDir)/ Univariate/

正如所发布的，该问题实际上是我正在处理的问题的简化版本 -单个项目中有几个级别的文件夹，并且存在一些名称冲突。因此，我真的想以某种方式“修复”它......

如果您右键单击解决方案资源管理器中的项目，选择 C/C++ -> “输出文件”并在“对象文件名”框中键入以下内容：

$(IntDir)/%(RelativeDir)/

请注意，我还从下拉列表中选择了（所有配置、所有平台）。这将编译镜像源树的目录层次结构中的每个文件。如果这些目录不存在，VS2010 将通过创建这些目录来开始构建。此外，对于那些讨厌目录名称中的空格的人来说，此宏确实会删除所有空格，因此在使用它时无需使用双引号。

这正是我想要的——与我的 Makefile 在 Ubuntu 端的工作方式相同，同时仍然保持源代码树干净。

Answer 2

这在 IDE 中很容易修复。单击文件夹中的第一个文件，然后按住 Shift 键并单击最后一个文件，以便选择所有文件。右键单击，属性，C++，输出文件。将对象文件名从 $(IntDir)\ 更改为 $(IntDir)\Univariate\。您可以对多元文件组重复此操作，但这并不是绝对必要的。

Answer 3

你是对的，VS 无法处理这个问题，而且永远无法处理。根本问题是它为项目中的每个 .cpp 文件生成一个 .obj 文件，并且它们都放在同一个文件夹中。例如，在您的情况下，您最终会得到多个 .cpp 文件编译为 Adaptive.obj 的情况。

至少链接器现在会为其生成警告。情况并非总是如此。

您应该能够通过确保文件使用不同的中间目录路径来解决此问题，但这对应该可能的事情来说是一种黑客攻击。

当然，您始终可以在 Microsoft Connect 上提交错误报告或功能请求

Answer 4

请注意，在我的实例（带有 VS2010 平台工具集的 Visual Studio 2013）中，使用 $(IntDir)\%(RelativeDir) 无法正常工作，并且它会忽略中间目录，这会在构建多个配置时导致链接器错误，因为所有每个配置（即调试和发布）的目标文件都放置在同一文件夹中。如果您在切换配置时清理项目，这些就会消失。

错误示例：

MSVCRTD.lib(MSVCR100D.dll): 错误 LNK2005: _fclose 已在 LBCMTD.lib(fclose.obj) 中定义

解决方案：

$(IntDir)\%(目录)

为了解决这个问题，我必须使用 $(IntDir)\%(Directory) ，它将所有 *.obj 文件正确放置在中间目录下，并允许构建和链接多个配置而无需清理。唯一的缺点是文件所在的整个（可能很长）文件夹层次结构将在 Debug/Release/etc 文件夹下完全重新创建。

Answer 5

该线程中的其他解决方案遭受基于relativedir的../..问题，并且必须在每个源文件上手动设置。

更不用说，他们会破坏/MP。任何为 %(ObjectFileName) 指定精确 .obj 的解决方案都会导致传递给 CL.exe 的每个 .cpp 文件（将其映射到特定 .obj 文件）有不同的 /Fo，因此 Visual Studio 无法对它们进行批处理。如果不使用相同的命令行（包括 /Fo）批处理多个 .cpp 文件，则 /MP 无法工作。

这是一种新方法。这至少适用于 vs2010 到 vs2015。将其添加到中的 vcxproj 中

<!-- ================ UNDUPOBJ ================ -->
<!-- relevant topics -->
<!-- https://stackoverflow.com/questions/3729515/visual-studio-2010-2008-cant-handle-source-files-with-identical-names-in-diff/26935613 -->
<!-- https://stackoverflow.com/questions/7033855/msvc10-mp-builds-not-multicore-across-folders-in-a-project -->
<!-- https://stackoverflow.com/questions/18304911/how-can-one-modify-an-itemdefinitiongroup-from-an-msbuild-target -->
<!-- other maybe related info -->
<!-- https://stackoverflow.com/questions/841913/modify-msbuild-itemgroup-metadata -->
<UsingTask TaskName="UNDUPOBJ_TASK" TaskFactory="CodeTaskFactory" AssemblyFile="$(MSBuildToolsPath)\Microsoft.Build.Tasks.v4.0.dll">
  <ParameterGroup>
    <OutputDir ParameterType="System.String" Required="true" />
    <ItemList ParameterType="Microsoft.Build.Framework.ITaskItem[]" Required="true" />
    <OutputItemList ParameterType="Microsoft.Build.Framework.ITaskItem[]" Output="true" />
  </ParameterGroup>
  <Task>
    <Code><![CDATA[
            //general outline: for each item (in ClCompile) assign it to a subdirectory of $(IntDir) by allocating subdirectories 0,1,2, etc., as needed to prevent duplicate filenames from clobbering each other
            //this minimizes the number of batches that need to be run, since each subdirectory will necessarily be in a distinct batch due to /Fo specifying that output subdirectory

            var assignmentMap = new Dictionary<string,int>();
            HashSet<string> neededDirectories = new HashSet<string>();
            foreach( var item in ItemList )
            {
              //solve bug e.g. Checkbox.cpp vs CheckBox.cpp
              var filename = item.GetMetadata("Filename").ToUpperInvariant(); 

              //assign reused filenames to increasing numbers
              //assign previously unused filenames to 0
              int assignment = 0;
              if(assignmentMap.TryGetValue(filename, out assignment))
                assignmentMap[filename] = ++assignment;
              else
                assignmentMap[filename] = 0;

              var thisFileOutdir = Path.Combine(OutputDir,assignment.ToString()) + "/"; //take care it ends in / so /Fo knows it's a directory and not a filename
              item.SetMetadata( "ObjectFileName", thisFileOutdir );
            }

            foreach(var needed in neededDirectories)
              System.IO.Directory.CreateDirectory(needed);

            OutputItemList = ItemList;
            ItemList = new Microsoft.Build.Framework.ITaskItem[0];

        ]]></Code>
  </Task>
</UsingTask>

<Target Name="UNDUPOBJ">
  <!-- see stackoverflow topics for discussion on why we need to do some loopy copying stuff here -->
  <ItemGroup>
    <ClCompileCopy Include="@(ClCompile)"/>
    <ClCompile Remove="@(ClCompile)"/>
  </ItemGroup>
  <UNDUPOBJ_TASK OutputDir="$(IntDir)" ItemList="@(ClCompileCopy)" OutputItemList="@(ClCompile)">
    <Output ItemName="ClCompile" TaskParameter="OutputItemList"/>
  </UNDUPOBJ_TASK>
</Target>
<!-- ================ UNDUPOBJ ================ -->

然后修改结果如下：

<Project InitialTargets="UNDUPOBJ" ...

结果将类似于 myproj/src/a/x.cpp 和 myproj/src/b/x.cpp 编译为 Debug/0/x.obj 和 Debug/1/x.obj。 relativedirs 没有被雇用，所以不是问题。

此外，在这种情况下，只会有两个不同的 /Fo 传递给 CL.exe：Debug/0/ 和 Debug/1/。因此，不会向 CL.exe 发出超过两批，从而使 /MP 能够更有效地工作。

其他方法是将 .obj 子目录基于 .cpp 子目录，或者使 .obj 文件名包含原始 .cpp 目录的一些备忘录，以便您可以轻松地看到 .cpp->.obj 映射，但这些会导致/Fo 越多，批处理就越少。也许未来的工作可以转储映射文件以供快速参考。

有关 /MP 和批处理的更多详细信息，请参阅此： MSVC10 /MP 不会在项目中跨文件夹构建多核

我已经在生产环境中在各种工具链上的 vs2010 和 vs2015 上测试了这一点。它看起来是无懈可击的，但它总是有可能与其他 msbuild 自定义或外来工具链发生不良交互。

从 vs2015 开始，如果您收到警告“警告 MSB8027：两个或多个名为 X.cpp 的文件将在同一位置生成输出”，那么您可以将其添加到您的项目或 msbuild 文件中：

<PropertyGroup Label="Globals"><IgnoreWarnCompileDuplicatedFilename>true</IgnoreWarnCompileDuplicatedFilename></PropertyGroup>

查看更多信息 https://connect .microsoft.com/VisualStudio/feedback/details/797460/in Correct-warning-msb8027-reported-for-files-excluded-from-build 和 如何抑制特定的 MSBuild 警告

---

2019 年 9 月更新：

我认为上述内容存在问题，其中 ItemList 可以任意排序，从而导致重新分配给定源文件到不同编号的目录。因此，每当源文件列表发生更改时，可能会出现对象的重复副本。这也可能导致依赖性跟踪变得有点混乱，因为输入->输出映射可能会发生令人惊讶的变化，从而使时间戳变得毫无意义。

我们可以通过散列排序的 ItemList 并将其添加到输出目录的前缀来解决此问题，但这会创建额外的重建和大量垃圾。

这可以通过删除列出输入->输出映射的文件并使源文件到目标编号目录的映射成为一次性事件（直到项目被清理）来改进。

我还没有更深入地调查这一点。

Answer 6

使用配置属性> C/C++>输出文件> $(IntDir)\%(RelativeDir)\%(Filename)

这将复制调试目录下的源文件结构，并将每个目录的目标文件存放在调试下的同名文件夹中目录

Answer 7

也可以在 Visual Studio 中创建一个 .cpp 文件，然后将其重命名为 .h。尽管该文件已重命名，但 Visual Studio 仍将其编译为 cpp 文件，因此会创建两个 obj 文件并显示链接器警告。

Answer 8

%(RelativeDir) 解决方案仅适用于 Visual Studo 2010。

对于 Visual Studio 2008，您需要右键单击每个重复的 .cpp 文件名并选择“属性”。它可能并不明显，但您实际上可以修改每个单独文件的“配置属性 -> C/C++ -> Ouptut Files”部分。

将子文件夹添加到每个重复 .cpp 文件的“对象文件名”设置中，请注意，不需要修改 .h 文件，因为 .cpp 文件决定 .obj 文件输出。

例如，如果您的项目有两个冲突的文件：

internal\example.cpp
base\example.cpp

您可以将每个文件的“对象文件名”设置为：

$(IntDir)\internal\
$(IntDir)\base\

您需要对所有配置发布/调试等执行此操作。