SVN succesful-compilation tag
k1pfeifle at gmx.net
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
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?
> 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