views:

292

answers:

3

I'm developing application for GNU/Linux using gcc 4 and cmake to manage compilation process. I found that is has no problems when there are two files with the same name but in other directory and namespace like this:

.  
|-- gfx  
|   |-- Object.cpp  
|   `-- Object.h  
`-- logic  
    |-- Object.cpp  
    `-- Object.h  

First Object class is in Gfx namespace and second in Logic namespace.

Then I've tried to compile this project using Visual C++ 2008 Express Edition. Linker threw several errors about non-existing implementation of Gfx::Object class. After few checks I found out that:

  • Visual C++ is tracking two of Object.cpp files
  • When change occurs in first or second file the recompilation of Object unit is queued
  • It always recompile only the second Object.cpp regardless of which file was actually modified

I also found out that Visual C++ don't allow to create two classes with same name.

Is there a solution for this? I don't really want to refactor quite big part of code.

+2  A: 

The problem is that by default VC++2008 places all the object files into a single output folder, so the existence of the first object.obj file satisfies the dependency for the second so it is not compiled; and even if it were, it would overwrite the first one.

What you need to be able to do is make the intermediate directory setting dependent in the file being compiled. However I have tried setting it to $(InputDir) and various other combinations, but could not succeed in achieving a configuration that works, although it may be possible. The available macros are documented here.

Failing that you could use a "makefile" project, and manage the build with make, nmake, or cmake or whatever, since there is nothing fundamentally wrong with what you are doing (even if it is ill-advised), it is just that it is not easily supported by the IDE.

Clifford
This $(InputDir) macro acts kinda strange. It puts .obj files in one of source directory (not random but I cannot tell why in specified one) and some of objs are just missing. Linker is expecting obj files to be in right place. Oh my...
Piotr Korzuszek
+4  A: 

Both Object.cpp files will be compiled to Object.obj. Into the same directory. In other words, the last one that is compiled will overwrite the Object.obj of the first one. Yes, the linker isn't going to be thrilled by that, you'll get multiply defined symbols since it links the same Object.obj file twice.

The fix is easy, right-click one of the Object.cpp files, Properties, C/C++, Output Files. Change the Object File Name from $(IntDir)\ to, say, $(IntDir)\$(InputName)2.obj

Hans Passant
That solves my little problem, thanks! But I must argue with you that there was no overwriting. Compiler just ignored one file. I've checked that with adding to cpp file some trashy stuff and hope that it will crash on it. Only when I changed the output file it actually threw errors.
Piotr Korzuszek
Now is there a CMake command to do this?
dvide
I dunno, but maybe I should prepare a Visual C++ project using cmake in first place? Crating new project from existing source directly in Visual C++ sounds to me like a lot easier job than modifying my CMakeFiles for Windows.
Piotr Korzuszek
Isn't that the whole point of using CMake? I would do it, as I've realised it will automatically resolve the conflict for you. See the comment I left on my own answer.
dvide
+1  A: 

This has already been answered, but I also want to add Visual Studio 2010 will automatically put the two .obj files into different directories if there is a conflict, based on my experience with Beta 2.

EDIT: Uh oh, this is wrong! The real answer is that CMake was automatically doing this for me.

dvide
Maybe I will try, because I cannot set proper global macros to make it work. Thanks!
Piotr Korzuszek
Hmm I'm really sorry but this is actually wrong! After a quick test it didn't work. I've figured out that it was CMake that was doing this for me automatically, which is cool! But that makes me wonder why you even had this problem in the first place, if you're using CMake as you said? Maybe try to update CMake to the recent 2.8.0?
dvide
Yes, but my project is not configured to work with Windows platform yet. If you say so, then maybe I should try a little more and use cmake generator instead. :-)
Piotr Korzuszek
I see :) then I would go down that route for sure. The whole point of using CMake is to avoid having to make separate project files and such for all the different platforms.
dvide
Erm, the whole point of using VS is to avoid having to use CMake. But I'm not religious about it.
Hans Passant
@nobugz Why do you think so?
Piotr Korzuszek
@nobugz I'm not sure that makes much sense. I'm sure you know CMake doesn't replace VS but sits above it in the chain. If it's easier to maintain separate project files for different platforms manually go ahead, but if it's a pain then CMake is designed to help there. And if you're already using CMake it strikes me as odd to want to then go and maintain separate project files. For what reason did you start using CMake at all?
dvide
@dvide Looks like cmake is better than I thought! Changes that I made to CMakeLists.txt are minimal and project files are perfectly generted. Now I can rest in peace :-)
Piotr Korzuszek
@Piotr Korzuszek That's great! =)
dvide