MantisBT - CMake
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005063CMakeCMakepublic2007-05-20 04:562016-06-10 14:30
Reporterstuart.herring 
Assigned ToBill Hoffman 
PrioritynormalSeveritymajorReproducibilityalways
StatusclosedResolutionmoved 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Summary0005063: VS6 Generator not using separate directories per target
DescriptionThe Visual Studio 6 generator doesn't appear to use separate directories per target for object files - so including the same source file in two targets in the same directory with different compile options doesn't work (the second target uses the existing .obj from the first one)
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2008-10-09 13:14Bill HoffmanNote Added: 0013803
2008-10-09 18:14stuart.herringNote Added: 0013827
2009-02-02 13:12Leo BreebaartNote Added: 0014750
2011-11-15 04:57Kovarththanan RajaratnamNote Added: 0027801
2016-06-10 14:27Kitware RobotNote Added: 0041359
2016-06-10 14:27Kitware RobotStatusassigned => resolved
2016-06-10 14:27Kitware RobotResolutionopen => moved
2016-06-10 14:30Kitware RobotStatusresolved => closed

Notes
(0013803)
Bill Hoffman   
2008-10-09 13:14   
Is this still an issue, do you still use vs6?
(0013827)
stuart.herring   
2008-10-09 18:14   
Yes, we still use VS6 - mostly because the project is pure C (not C++), and Microsoft haven't made any improvements to their C implementation in ten years, but the build times are much slower in the newer versions.
We've worked around it, so I'm not sure if it's still an issue in 2.6 - I'll retest.
(0014750)
Leo Breebaart   
2009-02-02 13:12   
I am encountering the same problem: in my CMakeLists.txt I have sourcefiles dir1/foo.c and dir2/foo.c. On Linux, or when using nmake files on Windows, this is absolutely no problem, but the generated VS 6 project file will just put all *.lib files in e.g. 'Debug/' -- so the builds fail for the targets that need the separate foo.obj files.

I would already be very much helped if the workaround for this problem was documented. One thing a colleague came up with is manually adding /Fo flags to the compiler command line, but I do not know if that is the best solution.
(0027801)
Kovarththanan Rajaratnam   
2011-11-15 04:57   
Yes, I still see this issue with 2.8.6
(0041359)
Kitware Robot   
2016-06-10 14:27   
Resolving issue as `moved`.

This issue tracker is no longer used. Further discussion of this issue may take place in the current CMake Issues page linked in the banner at the top of this page.