Visual Studio 2010 & 2008 can't handle source

Question

Direct Question: If I have two files with the same name (but in different directories), it appears that only Visual Studio 2005 can handle this transparently?? VS 2008 & 2010 require a bunch of tweaking? Aside from my naming convention, am I doing something wrong?

Background:

I'm developing C++ statistical libraries... I have two folders:

/ 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

I need to support cross compilation -- I'm using g++/make to compile these same files into a library in Linux. They work just fine.

I had been using Visual Studio 2005 without issue, but I need to upgrade to Visual Studio 2008 or 2010 (currently drooling over nVidia's nsight tool). However, I'm having trouble if I add files to a project with the same name (even if they're in a different directory). I'm willing to change my naming convention, but I'm curious if others have encountered this problem and have found any well documented solutions??

I'm further boggled by the fact that if I upgrade from 2005 projects to 2010 projects, it appears that VS 2010 is able to correctly handle two source files with the same name in different directories; however, if I remove one of the duplicate files and then add it back to the project I am greeted by the following warning:

Distributions\Release\Adaptive.obj : warning LNK4042: object specified more than once; extras ignored

Now I have the intermediate directory specified as $(ProjectName)\$(Configuration) -- I need to have my object files in a different location from my source tree. So I can see why it's copying the object files on top of each other, but when the projects are converted from 2005 to 2008 or 2010, a bunch of conditional compiles are added:

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

These are accessible from the Source file Properties page in C/C++ -> Output Files -> "Object File Name" & "XML Documentation File Name". But if I simply add the file directly (or remove and re-add them), VS doesn't complain until I try to compile, but also never adds the conditional directives -- So in order for things to work correctly, I have to add the conditional directives myself for every single configuration. Am I making a mistake / poor assumption or have I uncovered a valid bug in VS 2008 / 2010?

Answer 1

It also can be that you create a .cpp file in visual studio and later rename it to .h. Although the file is renamed visual studio still compiles it as a cpp file and therefore two obj files are created and linker warning shown.

Answer 2

Note that in my instance (Visual Studio 2013 with VS2010 platform toolset), using $(IntDir)\%(RelativeDir) doesn't work correctly, and it ignores the intermediate directory which results in linker errors when building multiple configurations because all of the object files for every configuration (ie, Debug and Release) are placed in the same folder. These go away if you clean the project when switching configurations.

Error Example:

MSVCRTD.lib(MSVCR100D.dll) : error LNK2005: _fclose already defined in LIBCMTD.lib(fclose.obj)

Solution:

$(IntDir)\%(Directory)

To get around this, I had to use $(IntDir)\%(Directory) which correctly placed all of the *.obj files under the intermediate directory and allowed building and linking multiple configurations without cleaning. The only downside is the entire (potentially long) folder hierarchy that your files are in will be completely re-created under the Debug/Release/etc folder.

Answer 3

This is easy to fix in the IDE. Click the first file in the folder, Shift+Click the last file so all of them are selected. Right-click, Properties, C++, Output Files. Change the Object File Name from $(IntDir)\ to, say, $(IntDir)\Univariate\. You can repeat for the Multivariate file group although that's not strictly necessary.

Answer 4

use Configuration Properties > C/C++ > Ouptut Files> $(IntDir)\%(RelativeDir)\%(Filename)

this will duplicate the source file structure under the debug directory and deposit the object file for each directory in a folder of the same name under the Debug directory

Answer 5

The %(RelativeDir) solution only works for Visual Studo 2010.

For Visual Studio 2008 you need to right click on each duplicate .cpp filename and choose "Properties". It may not be obvious but you can actually modify the "Configuration Properties -> C/C++ -> Ouptut Files" section for each individual file.

Add a sub folder to the "Object File Name" setting of each of the duplicate .cpp files, note that .h files do not need to be modified as the .cpp file determines the .obj file output.

For example, if your project has two conflicting files:

internal\example.cpp base\example.cpp

You would set the "Object File Name" for each to:

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

You will need to do this for all configurations Release/Debug etc.

Answer 6

So @Hans Passant pointed in the right direction, Thanks!! You don't have to list the file, a folder is sufficient. Then if you look in the defined macros at the bottom of the VS 2010 list, you'll see:

%(RelativeDir)/ Univariate/

The problem, as posted, was actually a simplified version of what I'm working on -- a couple of levels of folders in a single project and there are a couple of name conflicts. Hence, I really wanted someway to just "fix" it...

If you right click on the project in the solution explorer, choose C/C++ -> "Output Files" and type the following into the "Object File Name" box:

$(IntDir)/%(RelativeDir)/

Note that I also selected (All Configurations, All Platforms) from the drop downs. This will compile every file in a directory hierarchy which mirrors the source tree. VS2010 will begin the build by creating these directories if they don't exist. Further, for those who hate white space in their directory names, this macro does remove all spaces, so there is no need to play around with double quotes when using it.

This is exactly what I wanted -- identical to the way my Makefiles work on the Ubuntu side, while still keeping the source tree clean.