MantisBT - CMake |
View Issue Details |
|
ID | Project | Category | View Status | Date Submitted | Last Update |
0011899 | CMake | CMake | public | 2011-02-26 03:53 | 2014-02-18 09:59 |
|
Reporter | Yuri | |
Assigned To | Brad King | |
Priority | normal | Severity | tweak | Reproducibility | always |
Status | closed | Resolution | fixed | |
Platform | Visual Studio 2005 | OS | Windows | OS Version | |
Product Version | CMake 2.8.4 | |
Target Version | CMake 2.8.12 | Fixed in Version | CMake 2.8.12 | |
|
Summary | 0011899: Put compiler's program database files into intermediate directory rather than output one for VS 2005 |
Description | 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. |
Steps To Reproduce | |
Additional Information | |
Tags | No tags attached. |
Relationships | related to | 0010370 | closed | Kitware Robot | CMAKE_USE_RELATIVE_PATHS doesn't apply to ProgramDataBaseFileName in .vcproj files | related to | 0009042 | closed | David Cole | Relative Path for VC++ 8.0*.pdb file | related to | 0010830 | closed | Brad King | Add option to specify output of Visual Studio .pdb files (Debug symbols) | related to | 0003277 | closed | Brad King | <config>_OUTPUT_NAME not used for pdb and idb files | related to | 0003738 | closed | Bill Hoffman | Error in generated VS7 project file | related to | 0000091 | closed | | PDB files for static libraries | related to | 0014062 | closed | Brad King | Setting Compiler and Linker PDB to the same path in Visual Studio is unsupported. | related to | 0014577 | closed | Brad King | Need to map /Fd to ProgramDataBaseFileName in VS 7,8,9 | related to | 0014600 | closed | Brad King | Document PDB behavior w.r.t. static libraries | related to | 0014763 | closed | Brad King | Add target properties to specify MS compiler PDB files |
|
Attached Files | |
|
Issue History |
Date Modified | Username | Field | Change |
2011-02-26 03:53 | Yuri | New Issue | |
2011-02-28 09:02 | Brad King | Relationship added | duplicate of 0010830 |
2011-02-28 09:02 | Brad King | Relationship deleted | 0010830 |
2011-02-28 09:03 | Brad King | Assigned To | => Brad King |
2011-02-28 09:03 | Brad King | Status | new => assigned |
2011-02-28 09:03 | Brad King | Relationship added | related to 0010370 |
2011-02-28 09:11 | Brad King | Assigned To | Brad King => |
2011-02-28 09:11 | Brad King | Assigned To | => Brad King |
2011-02-28 09:11 | Brad King | Relationship added | related to 0009042 |
2011-02-28 09:13 | Brad King | Note Added: 0025594 | |
2011-02-28 09:28 | Brad King | Note Added: 0025595 | |
2011-02-28 09:32 | Brad King | Relationship added | related to 0010830 |
2011-02-28 09:33 | Brad King | Note Edited: 0025595 | bug_revision_view_page.php?bugnote_id=25595#r220 |
2011-02-28 09:41 | Brad King | Note Edited: 0025595 | bug_revision_view_page.php?bugnote_id=25595#r221 |
2011-02-28 09:49 | Brad King | Note Added: 0025596 | |
2011-02-28 09:57 | Brad King | Note Edited: 0025594 | bug_revision_view_page.php?bugnote_id=25594#r223 |
2011-02-28 09:58 | Brad King | Relationship added | related to 0003277 |
2011-02-28 09:58 | Brad King | Relationship added | related to 0003738 |
2011-02-28 10:01 | Brad King | Relationship added | related to 0000091 |
2011-02-28 10:02 | Brad King | Note Added: 0025597 | |
2011-02-28 10:05 | Yuri | Note Added: 0025598 | |
2011-02-28 10:12 | Brad King | Note Added: 0025600 | |
2011-02-28 10:17 | Yuri | Note Added: 0025601 | |
2012-08-13 10:37 | Brad King | Status | assigned => backlog |
2012-08-13 10:37 | Brad King | Note Added: 0030519 | |
2012-09-09 00:24 | Yuchen Deng | Note Added: 0030962 | |
2013-04-05 07:58 | Brad King | Relationship added | related to 0014062 |
2013-05-20 08:50 | Brad King | Note Added: 0033101 | |
2013-05-20 08:51 | Brad King | Status | backlog => resolved |
2013-05-20 08:51 | Brad King | Resolution | open => fixed |
2013-05-20 08:51 | Brad King | Fixed in Version | => CMake 2.8.12 |
2013-05-20 08:51 | Brad King | Target Version | => CMake 2.8.12 |
2013-10-07 10:09 | Robert Maynard | Note Added: 0034052 | |
2013-10-07 10:09 | Robert Maynard | Status | resolved => closed |
2013-11-18 08:35 | Brad King | Relationship added | related to 0014577 |
2013-11-27 10:29 | Brad King | Relationship added | related to 0014600 |
2014-02-18 09:59 | Brad King | Relationship added | related to 0014763 |
Notes |
|
(0025594)
|
Brad King
|
2011-02-28 09:13
(edited on: 2011-02-28 09:57) |
|
|
|
(0025595)
|
Brad King
|
2011-02-28 09:28
(edited on: 2011-02-28 09:41) |
|
|
|
(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
|
|
|
|
(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
|
|
|
|
(0034052)
|
Robert Maynard
|
2013-10-07 10:09
|
|
Closing resolved issues that have not been updated in more than 4 months. |
|