MantisBT - CMake
View Issue Details
0011899CMakeCMakepublic2011-02-26 03:532014-02-18 09:59
Yuri 
Brad King 
normaltweakalways
closedfixed 
Visual Studio 2005Windows
CMake 2.8.4 
CMake 2.8.12CMake 2.8.12 
0011899: Put compiler's program database files into intermediate directory rather than output one for VS 2005
Now in cmLocalVisualStudio7Generator.cxx the path for *compiler's* program database files is hard-coded:
    // We need to specify a program database file name even for
    // non-debug configurations because VS still creates .idb files.
    fout << "\t\t\t\tProgramDataBaseFileName=\""
         << this->ConvertToXMLOutputPathSingle(
              target.GetDirectory(configName).c_str())
         << "/"
         << target.GetPDBName(configName) << "\"\n";

However, these files are temporary and used only by linker to produce the final .pdb file. Moreover, these files aren't usable by debugger (AFAIK).

So the main complaint is when I put all output into single directory, it becomes clogged with idb files. The things much worse when using tools like IncrediBuild - it generates one idb file per source (or per job), therefore the number of files there grows too rapidly.

Why not Just put $(IntDir) there, like it is done for object files? I suppose this can solve other issues, like 0010370.
No tags attached.
related to 0010370closed Kitware Robot CMAKE_USE_RELATIVE_PATHS doesn't apply to ProgramDataBaseFileName in .vcproj files 
related to 0009042closed David Cole Relative Path for VC++ 8.0*.pdb file 
related to 0010830closed Brad King Add option to specify output of Visual Studio .pdb files (Debug symbols) 
related to 0003277closed Brad King <config>_OUTPUT_NAME not used for pdb and idb files 
related to 0003738closed Bill Hoffman Error in generated VS7 project file 
related to 0000091closed  PDB files for static libraries 
related to 0014062closed Brad King Setting Compiler and Linker PDB to the same path in Visual Studio is unsupported. 
related to 0014577closed Brad King Need to map /Fd to ProgramDataBaseFileName in VS 7,8,9 
related to 0014600closed Brad King Document PDB behavior w.r.t. static libraries 
related to 0014763closed Brad King Add target properties to specify MS compiler PDB files 
Issue History
2011-02-26 03:53YuriNew Issue
2011-02-28 09:02Brad KingRelationship addedduplicate of 0010830
2011-02-28 09:02Brad KingRelationship deleted0010830
2011-02-28 09:03Brad KingAssigned To => Brad King
2011-02-28 09:03Brad KingStatusnew => assigned
2011-02-28 09:03Brad KingRelationship addedrelated to 0010370
2011-02-28 09:11Brad KingAssigned ToBrad King =>
2011-02-28 09:11Brad KingAssigned To => Brad King
2011-02-28 09:11Brad KingRelationship addedrelated to 0009042
2011-02-28 09:13Brad KingNote Added: 0025594
2011-02-28 09:28Brad KingNote Added: 0025595
2011-02-28 09:32Brad KingRelationship addedrelated to 0010830
2011-02-28 09:33Brad KingNote Edited: 0025595bug_revision_view_page.php?bugnote_id=25595#r220
2011-02-28 09:41Brad KingNote Edited: 0025595bug_revision_view_page.php?bugnote_id=25595#r221
2011-02-28 09:49Brad KingNote Added: 0025596
2011-02-28 09:57Brad KingNote Edited: 0025594bug_revision_view_page.php?bugnote_id=25594#r223
2011-02-28 09:58Brad KingRelationship addedrelated to 0003277
2011-02-28 09:58Brad KingRelationship addedrelated to 0003738
2011-02-28 10:01Brad KingRelationship addedrelated to 0000091
2011-02-28 10:02Brad KingNote Added: 0025597
2011-02-28 10:05YuriNote Added: 0025598
2011-02-28 10:12Brad KingNote Added: 0025600
2011-02-28 10:17YuriNote Added: 0025601
2012-08-13 10:37Brad KingStatusassigned => backlog
2012-08-13 10:37Brad KingNote Added: 0030519
2012-09-09 00:24Yuchen DengNote Added: 0030962
2013-04-05 07:58Brad KingRelationship addedrelated to 0014062
2013-05-20 08:50Brad KingNote Added: 0033101
2013-05-20 08:51Brad KingStatusbacklog => resolved
2013-05-20 08:51Brad KingResolutionopen => fixed
2013-05-20 08:51Brad KingFixed in Version => CMake 2.8.12
2013-05-20 08:51Brad KingTarget Version => CMake 2.8.12
2013-10-07 10:09Robert MaynardNote Added: 0034052
2013-10-07 10:09Robert MaynardStatusresolved => closed
2013-11-18 08:35Brad KingRelationship addedrelated to 0014577
2013-11-27 10:29Brad KingRelationship addedrelated to 0014600
2014-02-18 09:59Brad KingRelationship addedrelated to 0014763

Notes
(0025594)
Brad King   
2011-02-28 09:13   
(edited on: 2011-02-28 09:57)
History of interest:

http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=712345ff [^]
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=33ee8371 [^]
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=770ffb16 [^]
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=8952f498 [^]
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=68ed752b [^]

(0025595)
Brad King   
2011-02-28 09:28   
(edited on: 2011-02-28 09:41)
Documentation of interest:

http://msdn.microsoft.com/en-us/library/9wst99a9%28v=vs.80%29.aspx [^] (cl /Fd Program Database File Name)
http://msdn.microsoft.com/en-us/library/kwx19e36%28v=VS.80%29.aspx [^] (link /PDB Use Program Database)
http://msdn.microsoft.com/en-us/library/958x11bc%28v=vs.80%29.aspx [^] (cl /Z Debug Information Format)
http://msdn.microsoft.com/en-us/library/1d5fbft1%28v=VS.80%29.aspx [^] (link: .pdb Files as Linker Input)
http://msdn.microsoft.com/en-us/library/h34w59b3%28v=VS.80%29.aspx [^] (lib.exe)

(0025596)
Brad King   
2011-02-28 09:49   
I think the current code may be based on a misunderstanding of the relationship between the compiler's and linker's .pdb files. I'm not sure though because it was written a long time ago and the refactored and moved about.

Okay, so "cl /Fd..." puts the debug information into a temporary .pdb file that is referenced by each .obj file written. Then "link /pdb:..." copies the information referenced by each .obj file into a final .pdb file corresponding to the .dll or .exe produced. This works well for shared libraries and executables.

However, for static libraries consider this note from the "cl /Z" documentation linked in 0011899:0025595:
  If you create a library from objects that were compiled using
  this option, the associated .pdb file must be available when the
  library is linked to a program. Thus, if you distribute the
  library, you must distribute the PDB.

This says that if a static .lib were to be distributed then all the debug symbols should be in a single matching .pdb file. Since the librarian does not copy/consolidate debug symbols this means all the /Fd options used when compiling objects in the static library must reference the same .pdb file.
(0025597)
Brad King   
2011-02-28 10:02   
It looks like the current behavior was a result of development specifically for the static library case. See issue 0000091:

http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=62bd5b7c [^]
(0025598)
Yuri   
2011-02-28 10:05   
That's exactly what I was trying to say in this bug: compiler's PDBs are different from linker's PDBs.

But this is good point: for static libraries compiler's pdb files are useful, however, for dynamic ones (including executables), they are successfully found at linking time and only resulting linker's pdb matters.

That's why allowing to specify directory for .pdb files is generally good idea.

But in real world, if you want to redistribute your static libraries it's better to use C7-compatible debug info. If you don't redistribute static libraries (for example, use it locally to build different application form the same source) - you don't need compiler's pdb either.
(0025600)
Brad King   
2011-02-28 10:12   
Any work on this issue should account for issue 0010830 too because the changes will otherwise conflict.
(0025601)
Yuri   
2011-02-28 10:17   
I also encountered problems with these compiler's PDB output - when you build in parallel several files (accidentally or not) and they write to the same PDB file, this file becomes corrupted or contains only part of information.
It was during my experiments to make single PCH file for multiple similar projects (with pure VS projects). PCH is also bound to some PDB file.
(0030519)
Brad King   
2012-08-13 10:37   
Sending issues I'm not actively working on to the backlog to await someone with time for them.

If an issue you care about is sent to the backlog when you feel it should have been addressed in a different manner, please bring it up on the CMake mailing list for discussion. Sign up for the mailing list here, if you're not already on it:

 http://www.cmake.org/mailman/listinfo/cmake [^]

It's easy to re-activate a bug here if you can find a CMake developer or contributor who has the bandwidth to take it on.
(0030962)
Yuchen Deng   
2012-09-09 00:24   
So sad! It should been fixed soon.
(0033101)
Brad King   
2013-05-20 08:50   
This issue has been addressed along with 0014062 as described in 0014062:0032818.
(0034052)
Robert Maynard   
2013-10-07 10:09   
Closing resolved issues that have not been updated in more than 4 months.