[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: [abc] not compiling in [xyz]
From:       David Faure <faure () kde ! org>
Date:       2004-09-14 13:38:20
Message-ID: 200409141538.20421.faure () kde ! org
[Download RAW message or body]

On Tuesday 14 September 2004 14:26, J. Preiss wrote:
> > I hope you don't mean you use cvs checkout everytime - it's much faster to
> > use cvs update and rebuild things incrementally (like e.g.
> > kdesdk/scripts/kde-build does).
> No, I use update. But I still used the term "checkout". My fault...
> And i simply call make. If this is not incrementally enough, I must take a 
> look at those tools (?).
make can fail when e.g. a new subdirectory was added. kde-build detects that
and re-runs Makefile.cvs on error, to fix such problems automatically (without
the cost of a full Makefile.cvs everytime).

> > > When I try to compile everything (never got that far), I think it
> > > takes a weekend. At least. So inbetween there is so much time to have
> > > errors... without matter how fast the errors will be fixed.
> > > When an error occurs within a package, I could set a flag somewhere to
> > > prevent others to run in the same error.
> >
> > But that's the point: by the time you see the problem, especially if you're
> > on anoncvs, there are great chances that the problem is already fixed in
> > CVS. So it's far too late to mark things as non-compileable - on the
> > contrary, this would only create trouble, since you would mark as broken
> > something that has been fixed already.
> So the delay is only between anoncvs and the root-cvs of KDE itself? 
Not sure what you mean by "only" here. But there is such a delay - 2 hours IIRC.

> Shouldn't I use anoncvs?
It's still the best thing to use for anonymous cvs access.

-- 
David Faure, faure@kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]