Re: CDash of kdelibs
On Thursday 21 July 2011 21:44:48 Alexander Neundorf wrote: On Thursday 21 July 2011, Volker Krause wrote: On Wednesday 20 July 2011 21:51:43 Alexander Neundorf wrote: Hi, Dave, if you find some time, could you please have a look at the issue here, whether it behaves as it should with using CTEST_USE_LAUNCHERS ? A link to a dashboard before and the new one with the launchers are below. On Wednesday 20 July 2011, Rolf Eike Beer wrote: Am Dienstag, 19. Juli 2011, 09:03:17 schrieb Volker Krause: On Monday 18 July 2011 21:21:36 Alexander Neundorf wrote: Volker, are you still doing make Nightly ? well, something inbetween I guess, manual ctest calls but not using the script in quality. If so, this is quite limited and has a bootstrapping problem. Did you consider using the ctest scripts in svn in quality/ ? That didn't exist back when I set up this build (it's running for more than 1.5 years now) I think :) Whatever you did two days ago it made things worse IMHO. There is the I wouldn't say it got worse. Here you see the compile commands and I actually didn't see an occasion where warnings for multiple files were mixed into one entry: http://my.cdash.org/viewBuildError.php?type=1buildid=210655 You also see the command which was invoked Not quite sure why it considers Generating parts.moc a warning. Adding this to the exceptions regexp should help here. I think we need a more general solution for that. If you look at e.g. the Akonadi build, you'll see it consideres an entire generated file as warning. The number of warnings changed from 2400 to 300, this seems a bit much. Here is the old build: http://my.cdash.org/viewBuildError.php?type=1buildid=209926 Since it seems to combine all warnings for a file now, I think those numbers are plausible. Ie. the 300 is the number of files with warnings, not the total amount of warnings anymore. No idea if that's intentional or desired though. 300 is a lot, too much to keep an eye on. Are there warnings which we want to have enabled, but we don't want to see them on the dashboard ? Probably for all moc and lex files, so we should add exceptions for those. What about all the 'Ksomething' is deprecated warnings ? That's slightly more complicated than just filtering them out on CDash IMHO. Deprecation warnings are quite important, especially regarding the KDE Frameworks 5 efforts, those should obviously be fixed by porting away from the obsolete API. However, if you look at the kdelibs warnings, you'll notice that most of them are for K3Network classes used inside K3Network itself. That's obviously something we are never going to fix (apart from dropping K3Network altogether). So, these warnings are useless, but this can't be fixed with CDash filters but needs real code changes (e.g. a K3NETWORK_DEPERECATED define that's empty inside K3Network itself). And the lots of warnings: 'virtual bool KFoo::doSomething(...)' was hidden by 'virtual ... ? Do we want to see them there ? Hard to say, they can be anything from really useless to indicating tricky to find bugs. regards Volker signature.asc Description: This is a digitally signed message part.
Re: CDash of kdelibs
On Wednesday 20 July 2011 21:51:43 Alexander Neundorf wrote: Hi, Dave, if you find some time, could you please have a look at the issue here, whether it behaves as it should with using CTEST_USE_LAUNCHERS ? A link to a dashboard before and the new one with the launchers are below. On Wednesday 20 July 2011, Rolf Eike Beer wrote: Am Dienstag, 19. Juli 2011, 09:03:17 schrieb Volker Krause: On Monday 18 July 2011 21:21:36 Alexander Neundorf wrote: Volker, are you still doing make Nightly ? well, something inbetween I guess, manual ctest calls but not using the script in quality. If so, this is quite limited and has a bootstrapping problem. Did you consider using the ctest scripts in svn in quality/ ? That didn't exist back when I set up this build (it's running for more than 1.5 years now) I think :) Whatever you did two days ago it made things worse IMHO. There is the I wouldn't say it got worse. Here you see the compile commands and I actually didn't see an occasion where warnings for multiple files were mixed into one entry: http://my.cdash.org/viewBuildError.php?type=1buildid=210655 You also see the command which was invoked Not quite sure why it considers Generating parts.moc a warning. Adding this to the exceptions regexp should help here. I think we need a more general solution for that. If you look at e.g. the Akonadi build, you'll see it consideres an entire generated file as warning. The number of warnings changed from 2400 to 300, this seems a bit much. Here is the old build: http://my.cdash.org/viewBuildError.php?type=1buildid=209926 Since it seems to combine all warnings for a file now, I think those numbers are plausible. Ie. the 300 is the number of files with warnings, not the total amount of warnings anymore. No idea if that's intentional or desired though. regards Volker signature.asc Description: This is a digitally signed message part.
Re: CDash of kdelibs
2011/7/20 Alexander Neundorf neund...@kde.org Hi, Dave, if you find some time, could you please have a look at the issue here, whether it behaves as it should with using CTEST_USE_LAUNCHERS ? A link to a dashboard before and the new one with the launchers are below. On Wednesday 20 July 2011, Rolf Eike Beer wrote: Am Dienstag, 19. Juli 2011, 09:03:17 schrieb Volker Krause: On Monday 18 July 2011 21:21:36 Alexander Neundorf wrote: Volker, are you still doing make Nightly ? well, something inbetween I guess, manual ctest calls but not using the script in quality. If so, this is quite limited and has a bootstrapping problem. Did you consider using the ctest scripts in svn in quality/ ? That didn't exist back when I set up this build (it's running for more than 1.5 years now) I think :) Whatever you did two days ago it made things worse IMHO. There is the I wouldn't say it got worse. Here you see the compile commands and I actually didn't see an occasion where warnings for multiple files were mixed into one entry: http://my.cdash.org/viewBuildError.php?type=1buildid=210655 You also see the command which was invoked Not quite sure why it considers Generating parts.moc a warning. Adding this to the exceptions regexp should help here. The number of warnings changed from 2400 to 300, this seems a bit much. Here is the old build: http://my.cdash.org/viewBuildError.php?type=1buildid=209926 I think there is some size limit for the submission to cdash (which is IIRC configurable). Maybe with the new format it is more data and so stuff has been cut ? Alex It looks ok to me. The 2400 was lines of warnings that match the regexes. The 300 is: there were warnings in that many invocations of the compiler. (i.e. if there are 100 warnings in a single C++ source file, it will only show up as 1 on the dashboard) Before, the measurement was number of warnings themselves, with launchers on, it's number of files with warnings. The Generating parts.moc is considered a warning because there is output even though the exit condition is 0. (At least, I think that's what it is...) Let me know if you suspect something specific is incorrect. HTH, David C.
Re: CDash of kdelibs
On Thursday 21 July 2011, Volker Krause wrote: On Wednesday 20 July 2011 21:51:43 Alexander Neundorf wrote: Hi, Dave, if you find some time, could you please have a look at the issue here, whether it behaves as it should with using CTEST_USE_LAUNCHERS ? A link to a dashboard before and the new one with the launchers are below. On Wednesday 20 July 2011, Rolf Eike Beer wrote: Am Dienstag, 19. Juli 2011, 09:03:17 schrieb Volker Krause: On Monday 18 July 2011 21:21:36 Alexander Neundorf wrote: Volker, are you still doing make Nightly ? well, something inbetween I guess, manual ctest calls but not using the script in quality. If so, this is quite limited and has a bootstrapping problem. Did you consider using the ctest scripts in svn in quality/ ? That didn't exist back when I set up this build (it's running for more than 1.5 years now) I think :) Whatever you did two days ago it made things worse IMHO. There is the I wouldn't say it got worse. Here you see the compile commands and I actually didn't see an occasion where warnings for multiple files were mixed into one entry: http://my.cdash.org/viewBuildError.php?type=1buildid=210655 You also see the command which was invoked Not quite sure why it considers Generating parts.moc a warning. Adding this to the exceptions regexp should help here. I think we need a more general solution for that. If you look at e.g. the Akonadi build, you'll see it consideres an entire generated file as warning. The number of warnings changed from 2400 to 300, this seems a bit much. Here is the old build: http://my.cdash.org/viewBuildError.php?type=1buildid=209926 Since it seems to combine all warnings for a file now, I think those numbers are plausible. Ie. the 300 is the number of files with warnings, not the total amount of warnings anymore. No idea if that's intentional or desired though. 300 is a lot, too much to keep an eye on. Are there warnings which we want to have enabled, but we don't want to see them on the dashboard ? Probably for all moc and lex files, so we should add exceptions for those. What about all the 'Ksomething' is deprecated warnings ? And the lots of warnings: 'virtual bool KFoo::doSomething(...)' was hidden by 'virtual ... ? Do we want to see them there ?
Re: CDash of kdelibs
Am Dienstag, 19. Juli 2011, 09:03:17 schrieb Volker Krause: On Monday 18 July 2011 21:21:36 Alexander Neundorf wrote: Volker, are you still doing make Nightly ? well, something inbetween I guess, manual ctest calls but not using the script in quality. If so, this is quite limited and has a bootstrapping problem. Did you consider using the ctest scripts in svn in quality/ ? That didn't exist back when I set up this build (it's running for more than 1.5 years now) I think :) Whatever you did two days ago it made things worse IMHO. There is the output format Alex wanted but many warnings seem to got lost, some entries contain text but no warning, others contain 2 warnings at once. So something is screwed there. Eike signature.asc Description: This is a digitally signed message part.
Re: CDash of kdelibs
Hi, Dave, if you find some time, could you please have a look at the issue here, whether it behaves as it should with using CTEST_USE_LAUNCHERS ? A link to a dashboard before and the new one with the launchers are below. On Wednesday 20 July 2011, Rolf Eike Beer wrote: Am Dienstag, 19. Juli 2011, 09:03:17 schrieb Volker Krause: On Monday 18 July 2011 21:21:36 Alexander Neundorf wrote: Volker, are you still doing make Nightly ? well, something inbetween I guess, manual ctest calls but not using the script in quality. If so, this is quite limited and has a bootstrapping problem. Did you consider using the ctest scripts in svn in quality/ ? That didn't exist back when I set up this build (it's running for more than 1.5 years now) I think :) Whatever you did two days ago it made things worse IMHO. There is the I wouldn't say it got worse. Here you see the compile commands and I actually didn't see an occasion where warnings for multiple files were mixed into one entry: http://my.cdash.org/viewBuildError.php?type=1buildid=210655 You also see the command which was invoked Not quite sure why it considers Generating parts.moc a warning. Adding this to the exceptions regexp should help here. The number of warnings changed from 2400 to 300, this seems a bit much. Here is the old build: http://my.cdash.org/viewBuildError.php?type=1buildid=209926 I think there is some size limit for the submission to cdash (which is IIRC configurable). Maybe with the new format it is more data and so stuff has been cut ? Alex
Re: CDash of kdelibs
Am Sonntag, 17. Juli 2011, 12:47:36 schrieb Rolf Eike Beer: When I look at the kdelibs test results at http://my.cdash.org/index.php?project=kdelibs I see the following things that IMHO need to be changed: -the limit of 3000 warnings is reached, do we need to increase the limit? We don't, we are now down to 2422 warnings by fixing problem #2. -the moc files are counted in the coverage results even if CTestConfig.cmake contains set(CTEST_CUSTOM_COVERAGE_EXCLUDE .moc$ moc_ ui_) So something is wrong there. This also adds to the number of warnings as the first to warning messages are no relevant classes found ones which should be suppressed. IIRC those lines need to be moved to the CTestCustom.cmake to take effect. Alex? This is fixed now, I backported this into 4.7 in case anyone starts doing builds there sometime. -I think that all testcases should also be removed from the coverage results, i.e. those list should be extended by /tests/. For this I would like to hear some more opinions. Eike signature.asc Description: This is a digitally signed message part.
CDash of kdelibs
When I look at the kdelibs test results at http://my.cdash.org/index.php?project=kdelibs I see the following things that IMHO need to be changed: -the limit of 3000 warnings is reached, do we need to increase the limit? -the moc files are counted in the coverage results even if CTestConfig.cmake contains set(CTEST_CUSTOM_COVERAGE_EXCLUDE .moc$ moc_ ui_) So something is wrong there. This also adds to the number of warnings as the first to warning messages are no relevant classes found ones which should be suppressed. IIRC those lines need to be moved to the CTestCustom.cmake to take effect. Alex? -I think that all testcases should also be removed from the coverage results, i.e. those list should be extended by /tests/. Opinions? Eike signature.asc Description: This is a digitally signed message part.
Re: CDash of kdelibs
Am Sonntag 17 Juli 2011, 12:58:35 schrieben Sie: On Sunday 17 July 2011, Rolf Eike Beer wrote: -the moc files are counted in the coverage results even if CTestConfig.cmake contains set(CTEST_CUSTOM_COVERAGE_EXCLUDE .moc$ moc_ ui_) So something is wrong there. This also adds to the number of warnings as the first to warning messages are no relevant classes found ones which should be suppressed. IIRC those lines need to be moved to the CTestCustom.cmake to take effect. Alex? I think so. Ok, pushed that into master. If that shows any effect in dashboard tomorrow I'll do that also for 4.[67]. -I think that all testcases should also be removed from the coverage results, i.e. those list should be extended by /tests/. Shouldn't the coverage for the testcases itself be around 100%, so they don't cause fixing work. Beside that I don't have an opinion whether they should be included or not. The overall coverage is computed with the testcases. So a coverage of 50% may actually mean 35% of relevant code are tested and the rest is testcases. Eike signature.asc Description: This is a digitally signed message part.
