MantisBT - CMake
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0009042CMakeCMakeSetuppublic2009-05-17 18:152010-12-14 18:49
ReporterGuy Volckaert 
Assigned ToDavid Cole 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product VersionCMake-2-6 
Target VersionFixed in Version 
Summary0009042: Relative Path for VC++ 8.0*.pdb file
DescriptionHi all,

I noticed that eventhough the CMAKE_USE_RELATIVE_PATH is set to ON, the Program Database File name (*.pdb) in the *.vcproj still uses an absolute path.

However, all other paths in the *.vcproj seem to use relative paths.

Regards,
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0011899closed Brad King Put compiler's program database files into intermediate directory rather than output one for VS 2005 
related to 0010370closed Kitware Robot CMAKE_USE_RELATIVE_PATHS doesn't apply to ProgramDataBaseFileName in .vcproj files 
Attached Filespatch pdb_relativepath.patch (1,587) 2009-12-19 19:02
https://public.kitware.com/Bug/file/2734/pdb_relativepath.patch
cxx cmLocalVisualStudio7Generator.cxx (70,325) 2009-12-19 19:02
https://public.kitware.com/Bug/file/2735/cmLocalVisualStudio7Generator.cxx
zip cmake.zip (1,036,001) 2009-12-19 19:14
https://public.kitware.com/Bug/file/2736/cmake.zip
zip BulletPhysicsEffect.zip (1,395,635) 2009-12-23 11:51
https://public.kitware.com/Bug/file/2741/BulletPhysicsEffect.zip
Issue History
Date ModifiedUsernameFieldChange
2009-05-17 18:15Guy VolckaertNew Issue
2009-09-14 12:45Bill HoffmanNote Added: 0017438
2009-09-14 12:45Bill HoffmanStatusnew => assigned
2009-09-14 12:45Bill HoffmanAssigned To => Bill Hoffman
2009-12-19 17:53erwincoumansNote Added: 0018953
2009-12-19 19:02erwincoumansFile Added: pdb_relativepath.patch
2009-12-19 19:02erwincoumansFile Added: cmLocalVisualStudio7Generator.cxx
2009-12-19 19:06erwincoumansNote Added: 0018954
2009-12-19 19:09erwincoumansNote Added: 0018955
2009-12-19 19:14erwincoumansFile Added: cmake.zip
2009-12-21 10:55Bill HoffmanAssigned ToBill Hoffman =>
2009-12-21 10:56Bill HoffmanAssigned To => David Cole
2009-12-22 12:02David ColeNote Added: 0018977
2009-12-23 00:22erwincoumansNote Added: 0018983
2009-12-23 10:15Bill HoffmanNote Added: 0018985
2009-12-23 11:49erwincoumansNote Added: 0018987
2009-12-23 11:51erwincoumansFile Added: BulletPhysicsEffect.zip
2009-12-23 12:00erwincoumansNote Edited: 0018987
2009-12-23 12:01erwincoumansNote Edited: 0018987
2009-12-23 12:03erwincoumansNote Edited: 0018987
2009-12-23 12:05erwincoumansNote Edited: 0018987
2009-12-23 12:07erwincoumansNote Edited: 0018987
2009-12-23 12:09erwincoumansNote Edited: 0018987
2009-12-23 12:11erwincoumansNote Edited: 0018987
2009-12-23 12:21erwincoumansNote Edited: 0018987
2009-12-23 14:18David ColeNote Added: 0018990
2009-12-23 14:18David ColeStatusassigned => resolved
2009-12-23 14:18David ColeResolutionopen => fixed
2009-12-24 11:43David ColeStatusresolved => feedback
2009-12-24 11:43David ColeResolutionfixed => reopened
2009-12-24 11:45David ColeNote Added: 0018994
2009-12-24 11:45David ColeStatusfeedback => resolved
2009-12-24 11:45David ColeResolutionreopened => fixed
2010-12-14 18:49David ColeNote Added: 0024052
2010-12-14 18:49David ColeStatusresolved => closed
2011-02-28 09:11Brad KingRelationship addedrelated to 0011899
2011-02-28 09:18Brad KingRelationship addedrelated to 0010370

Notes
(0017438)
Bill Hoffman   
2009-09-14 12:45   
Relative path is not really supported any more...
(0018953)
erwincoumans   
2009-12-19 17:53   
>> Relative path is not really supported any more...

Not supported anymore?

An important use case of cmake is for projects to ship auto-generated projectfiles that don't require cmake to be installed. (using CMAKE_SUPPRESS_REGENERATION and CMAKE_USE_RELATIVE_PATHS).

What is the issue of just fixing this .pdb bug ignoring this CMAKE_USE_RELATIVE_PATHS?
(0018954)
erwincoumans   
2009-12-19 19:06   
Attached is a patch for relative pdb files when using CMAKE_USE_RELATIVE_PATHS

It seems to work fine, and visual studio builds the project fine, when moving the project directory (no custom build steps or other fancy stuff).

Can you please consider applying this patch?
Thanks a lot,
Erwin
(0018955)
erwincoumans   
2009-12-19 19:09   
A Windows precompiled binary cmake.exe of CMake 2.8 and patch files are also at this location

http://gamekit.googlecode.com/files/cmake2.8_patched.zip [^]
(0018977)
David Cole   
2009-12-22 12:02   
I would like to apply this patch, but I have a question first......

tmpname is declared/defined but never used. Is it supposed to be used as the "ProgramDataBaseFile" value?

Does everything still work as you expect it to if you use tmpname in place of the existing "ProgramDataBaseFile" value?

Are there really no other problems with generated Visual Studio files using CMAKE_SUPPRESS_REGENERATION and CMAKE_USE_RELATIVE_PATHS...? Common wisdom on the CMake mailing list would seem to indicate that it doesn't work as most people expect it to work -- perhaps in your case you avoid those issues by not having complexities in your project files?


Thanks,
David
(0018983)
erwincoumans   
2009-12-23 00:22   
Please remove tmpname, I found out that ConvertToXMLOutputPathSingle already deals with the relative name.


>>Are there really no other problems with generated Visual Studio files using
>>CMAKE_SUPPRESS_REGENERATION and CMAKE_USE_RELATIVE_PATHS...?
>>Common wisdom on the CMake mailing list

I wonder if that is wisdom or plain reluctance :-)

There are no problem here, the generated projectfiles are portable. If I need more complex projectfiles that break portability, I might just fix them and submit a new patch, ok?

Hope you can apply the patch soon,
Thanks,
Erwin
(0018985)
Bill Hoffman   
2009-12-23 10:15   
There are custom command sequences that will not work without cmake being installed on the target machine. If cmake -E commands are used in the project, it will not work as well. That is what the ZERO_TARGET does, it runs cmake, and sometimes it needs to for the build to even work. In addition if the project uses find_library, find_package, or other try compile type things, the system introspection would not always work on the other machine. Anyway, glad it works for you, but for a general CMake project it will never work because of the system discovery and build time use of cmake by many projects.
(0018987)
erwincoumans   
2009-12-23 11:49   
(edited on: 2009-12-23 12:21)
I understand the limitations and I can live with those restrictions.

I avoid all those issues in my Bullet Physics Library project and the Microsoft Visual Studio project files don't require system discovery, no build time use of cmake, no custom build steps, no system introspection, no 'install', and including all external dependencies the library needs. I'm doing the same for an Irrlicht and Ogre graphics project. I'll attach a Windows project with cmake pre-generated msvc projectfiles, so you can verify it all works (in msvc/9 folder). Attached BulletPhysicsEffects.zip is a small test project that is Windows only, not our regular Bullet library.


Luckily I focus on physics simulation and mainly use OpenGL, so I don't require advanced build steps. If I were to require Cg (which I don't), I would rather use the NVidia environment variables on Windows ($(CG_LIB_PATH) and $(CG_INC_PATH) on Windows, instead of FindCg for those pre-generated projectfiles.

Of course I still include the option for users to use cmake, and I ship with cross-platform CMakeList.txt files.

In particular for Windows and Mac OSX I want to ship project files that work out-of-the-box without requiring cmake to be installed, because that makes it easiest for most of the users/developers of my software (90% are Windows users using Microsoft Visual Studio). For the last 5 years I used jam+msvcgen for this, but I plan on switching to cmake for project generation. Note that our Bullet physics library ships with several build systems (autotools/cmake/jam/pre-generated msvc projectfiles).

In fact, Google developed a new build system (Gyp) primarily (but not exclusively) to have those features. Personally I prefer cmake over Gyp and premake, the only drawback of cmake is that projectfile templates are in C/C++ code, I rather would have them customizable.

Anyway, CMAKE_SUPPRESS_REGENERATION and CMAKE_USE_RELATIVE_PATH lets me do that, so with applied patch I'm happy.
(0018990)
David Cole   
2009-12-23 14:18   
Fixed in CVS HEAD of CMake.

cvs commit -m "Fix issue 0009042 - use relative path for pdb file name when CMAKE_USE_RELATIVE_PATHS is on."

/cvsroot/CMake/CMake/Source/cmLocalVisualStudio7Generator.cxx,v <-- cmLocalVisualStudio7Generator.cxx
new revision: 1.259; previous revision: 1.258
(0018994)
David Cole   
2009-12-24 11:45   
Really fixed this time in CVS HEAD of CMake. (Yesterday's commit caused several failing tests on the VS 7, 8 and 9 dashboards because it did not handle double-quoted path names dues to spaces in the name...)

cvs commit -m "Fix issue 0009042 - correctly this time. Fix failing tests on VS 7, 8 and 9 dashboards. Use ConvertToXMLOutputPathSingle instead of ConvertToOptionallyRelativeOutputPath to handle spaces in the path and double quoting properly. Related to commit trying to fix issue 0009042 from yesterday."

/cvsroot/CMake/CMake/Source/cmLocalVisualStudio7Generator.cxx,v <-- cmLocalVisualStudio7Generator.cxx
new revision: 1.260; previous revision: 1.259
(0024052)
David Cole   
2010-12-14 18:49   
Closing bugs that have been resolved for more than 3 months without any further updates.