MantisBT - CDash
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0010295CDashpublic2010-02-16 06:232010-02-22 10:51
ReporterNoel OBoyle 
Assigned To 
PrioritynormalSeverityminorReproducibilityalways
StatusnewResolutionopen 
PlatformOSOS Version
Product Version1.7 
Target VersionFixed in Version 
Summary0010295: Incorrect link to SVN log for Windows builds
DescriptionI am submitting builds to the Open Babel project on Windows XP. The link to the SVN repository logs is incorrect:

e.g. reference to http://openbabel.svn.sourceforge.net/viewvc/openbabel/openbabel/trunk/C:/Tools/openbabel/src/formats/tinkerformat.cpp?view=log [^]
at http://my.cdash.org/viewBuildError.php?type=1&onlydeltan&buildid=48905 [^]
instead of
http://openbabel.svn.sourceforge.net/viewvc/openbabel/openbabel/trunk/src/formats/tinkerformat.cpp?view=log [^]

Note that the links to the repository diffs *are* correct: e.g.
http://my.cdash.org/viewUpdate.php?buildid=48717 [^]

Please find attached my ctest build file. I tried playing around with relative paths, but I couldn't make any progress. Besides, it works just fine on Linux, so I assume it's a CDash bug.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files? ob-win.cmake (1,714) 2010-02-16 06:23
https://public.kitware.com/Bug/file/2869/ob-win.cmake
Issue History
Date ModifiedUsernameFieldChange
2010-02-16 06:23Noel OBoyleNew Issue
2010-02-16 06:23Noel OBoyleFile Added: ob-win.cmake
2010-02-17 06:30Noel OBoyleNote Added: 0019542
2010-02-22 10:51David ColeNote Added: 0019573

Notes
(0019542)
Noel OBoyle   
2010-02-17 06:30   
Actually, a better example is:
http://my.cdash.org/viewBuildError.php?type=1&buildid=48717 [^]

where there are two warnings. One has the correct link to SVN, the other doesn't! It's clearly something to do with relative versus absolute paths.
(0019573)
David Cole   
2010-02-22 10:51   
For the raw data behind the following page...
http://my.cdash.org/viewBuildError.php?type=1&buildid=48717 [^]

Execute the following query in the my.cdash.org database:
SELECT * FROM `builderror` WHERE buildid =48717

You will see that the text of the first warning starts with:
1>c:\tools\openbabel\nightly\openbabel\src\stereo\squareplanar.cpp

And the text of the second warning starts with:
28>..\..\..\openbabel\src\formats\tinkerformat.cpp

All that ctest can do to generate the relative link to the name of the source file is strip away the value of CMAKE_SOURCE_DIR from the beginning of such strings as these that are scraped from the build logs. When it encounters a "../../.." relative path in the log output, it does not know what context the warning or error was generated in. (i.e. -- there's no way for it to know what the cwd was, and so no way to resolve ".." style paths...)

A better way to collect errors is to use the CTEST_USE_LAUNCHERS functionality added to ctest 2.8... but it only works with Makefile generators. It would not work with Visual Studio or Xcode generators.

Not sure what the best approach is for dealing with this problem.

We could:
- suppress links when the path to a file is a ".." style relative path
- put a link to the root of the project only instead...
- other ideas?