CDash of kdelibs
vkrause at kde.org
Fri Jul 22 07:47:25 BST 2011
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=1&buildid=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=1&buildid=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
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 190 bytes
Desc: This is a digitally signed message part.
More information about the kde-core-devel