View Issue Details [ Jump to Notes ] [ Print ]
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.
TagsNo tags attached.
Attached Files? file icon ob-win.cmake [^] (1,714 bytes) 2010-02-16 06:23

 Relationships

  Notes
(0019542)
Noel OBoyle (reporter)
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 (manager)
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?

 Issue History
Date Modified Username Field Change
2010-02-16 06:23 Noel OBoyle New Issue
2010-02-16 06:23 Noel OBoyle File Added: ob-win.cmake
2010-02-17 06:30 Noel OBoyle Note Added: 0019542
2010-02-22 10:51 David Cole Note Added: 0019573

Copyright © 2000 - 2018 MantisBT Team