SVN succesful-compilation tag

Kurt Pfeifle k1pfeifle at
Fri Feb 3 14:58:41 GMT 2006

On Thursday 02 February 2006 20:55, Frans Englich wrote:
> On Thursday 02 February 2006 18:24, Mantia Andras wrote:
> > On Thursday 02 February 2006 03:22, Marcos Mayorga wrote:
> > > Hi all
> > > I think a process is building the repository constantly, isn't it?
> > >
> > > Could it be a good idea to have a tags indicating the most modern
> > > version of the repository which is known to compile?
> >
> > It is the branches/KDE/3.5, in other words the latest stable branch.
> > This is what is known to compile and should compile almost any time any
> > where. ;-)
> >
> > But giving such a tag/revision for the development branch (trunk), ah,
> > that would be a hard job.
> But when I think about it, it would perhaps nevertheless be a good idea. 

But when you actually start *doing* it (not just thinking about the
"good idea" in an abstract way), you'd nevertheless see why this will
not work in a practical way.

Do you even compile (the complete) KDE from branch or trunk on a regular 

It seems not -- because your comments must be originating from a very 
limited KDE compilatation experience.

I saw and still see (complete) KDE branch (3.5) and trunk (before it 
became 4.0) builds *daily*.

I make this happen on at least 3 different machines (SUSE 9.1, 9.3 and
10.0 for i386 and SUSE-9.x for x64). Thanks to scripted automation with 
the help of Michael Pyne's marvellous kdesvn-build script, this is less 
time consuming than it sounds (but looking into compile logs of the 4 
machines still takes at least one hour of attention in order to fix 
build problems).

Soooo... it *very* often happens, that one machine built the module 
were the other one failed. Looking at the SVN revision, I'll see that 
the one succeeding had a slightly earlier or later rev. number than 
the failing one; updating both at the same time (within 10 seconds) 
may still give different results, even with reversed successes; 
looking again at the SVN revision number will show that the revisions 
*again* do differ (though I kicked off both "svn up"s within 10 
seconds: network latency, intermediate commits and more factors make 
it impossible to reliably get the same revision for different machines 
doing updates even at the same time.

OK -- I could check out the exact SVN revision to all machines. Well, 
I did for curiosity, about 6 months ago for a few days. Result: there 
are *still* occassions where moduls will not build on one machine, but
on all others. Reason: differnt compiler versions, different versions 
of ependency libs, different platform, different moon phase,...

That said -- KDE branch's modules (as well as trunk while it did lead 
to the later 3.5) compiled at about 95% of the time (with exception 
of a few "notorious" ones containing some, hmmm..., let's say 
"not-so-well-maintained" apps, or kdebindings, which didnt compile 
lots of times. Usually, a "do-not-compile kverbos" line for the kdeedu 
module in the kdesvn-buildrc would circumvent that problem).

Usually, when I reported a compilation error (one that didn't go away
after another "svn up", and was still there after 2 more hours), I 
found other people in IRC saying "compiles for me" -- but of course,
they had another distro, another platform, another compiler, another

To get a reliable "succesful-compilation" tag, you'd need to have a
*huge* compile farm, that continuously builds KDE from SVN...

And if we *had* such a compile farm at all (Brad Hards once announced
his willingness to lead the building of one, if only there came some 
more volunteers to his help -- what happened to this idea?) -- well, 
then this compile farm could be put to much better use than just 
creating a "successful-compilation" tag. One side effect of such a 
compile farm would probably be that compilation success on avarage 
goes up overall (from 95% to 99% maybe?) -- now what is the practical 
use of tagging 99% of all SVN revisions with "successful-compilation" 

I do not see the benefit of such a tag when we have in fact a SVN
that compiles in more than 90% of the cases. When success rate is much 
less (such as current trunk leading to KDE4), we have a separate 
branch, kdelibs4_snapshot, that is doing what you want...

And just *who* would benefit from such a "successful-compilation" 
flag, anyway? Would it be people *hacking* on KDE code & contributing 
to it? Or wouldn't it be rather those rare people who just want to run 
"bleeding edge" for the sake of running bleeding edge to impress
their (girl)friends, and without contributing to KDE?

> A  
> script could somehow figure out what most receent revision that builds, and 
> then commit a snapshot of that. What revision that builds could be determined 
> by iteratively building, or query one of those cmake build farms(that's 
> possible? no?).

Which of the (supposedly multiple) cmake build farms??

Do you have an idea about what you talk here?


More information about the kde-core-devel mailing list