---

Jeg har forsøgt at bygge KDE 3 fra CVS, men er stødt på et problem
som jeg gerne vil have hjælpe til.

Opsætning:

Linux (Red Hat 7.2) med KDE 2.2 installeret i /usr
Jeg bygger som brugeren kde3 som har /kde3 som hjemmekatalog
Qt 3 er bygget i /kde3/qt uden problemer
Al kde kildetekst er hentet med CVS og ligger i /kde3/kde-build
$KDEDIR er /kde3/kde
$QTDIR er /kde3/qt

kdesupport er bygget og installeret i $KDEDIR.
kdelibs er bygget og installeret i $KDEDIR.

Jeg kan ikke bygge kdebase idet "make" går i stå i kdebase/kdesktop:

[kde3@ask kdebase]$ make
make all-recursive

... klip ...

Making all in kdesktop
make[2]: Entering directory `/kde3/kde-build/kdebase/kdesktop'
Making all in .
make[3]: Entering directory `/kde3/kde-build/kdebase/kdesktop'
/bin/sh ../libtool --mode=link --tag=CXX c++ -O2 -fno-exceptions -fno-check-new -DQT_CLEAN_NAMESPACE -DQT_NO_COMPAT -DQT_NO_ASCII_CAST -o kdmdesktop -R /kde3/kde/lib -R /kde3/qt/lib -R /usr/X11R6/lib -L/usr/X11R6/lib -L/kde3/qt/lib -L/kde3/kde/lib kdmdesktop.o kdmdesktop_meta_unload.o ../kcontrol/background/libbgnd.la
c++ -O2 -fno-exceptions -fno-check-new -DQT_CLEAN_NAMESPACE -DQT_NO_COMPAT -DQT_NO_ASCII_CAST -o kdmdesktop kdmdesktop.o kdmdesktop_meta_unload.o -L/usr/X11R6/lib -L/kde3/qt/lib -L/kde3/kde/lib ../kcontrol/background/.libs/libbgnd.a /usr/lib/libkio.so -L/usr/lib/qt-2.3.1/lib -L/usr/lib -L/usr/lib/gcc-lib/i386-redhat-linux/2.96 -L/usr/lib/gcc-lib/i386-redhat-linux/2.96/../../.. /usr/lib/libkdesu.so -lutil /usr/lib/libkssl.so /usr/lib/libkdeui.so /usr/lib/libkdecore.so -ldl /usr/lib/libDCOP.so -lqt -lpng /usr/lib/libjpeg.so -lXext -lX11 -lSM -lICE -lresolv -lz /usr/lib/libfam.so -lstdc++ -lm -lc -lgcc -Wl,--rpath -Wl,/kde3/kde/lib -Wl,--rpath -Wl,/kde3/qt/lib -Wl,--rpath -Wl,/usr/X11R6/lib
kdmdesktop.o: In function `MyApplication::tr(char const *, char const *)':
kdmdesktop.o(.text+0x31): undefined reference to `QApplication::translate(char const *, char const *, char const *, QApplication::Encoding) const'
kdmdesktop.o: In function `MyApplication::trUtf8(char const *, char const *)':
kdmdesktop.o(.text+0x71): undefined reference to `QApplication::translate(char const *, char const *, char const *, QApplication::Encoding) const'
kdmdesktop.o: In function `MyApplication::staticMetaObject(void)':
kdmdesktop.o(.text+0xbe): undefined reference to `QMetaObject::new_metaobject(char const *, QMetaObject *, QMetaData const *, int, QMetaData const *, int, QMetaProperty const *, int, QMetaEnum const *, int, QClassInfo const *, int)'
kdmdesktop.o(.text+0xd5): undefined reference to `QMetaObjectCleanUp::setMetaObject(QMetaObject *&)'

... klip mange flere udefinerede referencer ...

collect2: ld returned 1 exit status
make[3]: *** [kdmdesktop] Error 1
make[3]: Leaving directory `/kde3/kde-build/kdebase/kdesktop'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/kde3/kde-build/kdebase/kdesktop'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/kde3/kde-build/kdebase'
make: *** [all-recursive-am] Error 2
[kde3@ask kdebase]$

Jeg synes at det ser ud som om at man forsøger at linke mod nogle af
de kde 2-biblioteker som er installeret i /usr/lib, og spekulerer på
om det er problemet.

Nogen ideer til hvordan jeg kan komme videre med kdebase?
På forhånd tak.

Byrial

---

Byrial Jensen wrote:

> Jeg har forsøgt at bygge KDE 3 fra CVS, men er stødt på et problem
> som jeg gerne vil have hjælpe til.
>
<cut>
>
> kdesupport er bygget og installeret i $KDEDIR.
> kdelibs er bygget og installeret i $KDEDIR.
>
> Jeg kan ikke bygge kdebase idet "make" går i stå i kdebase/kdesktop:
>
Jeg har endnu ikke forsøgt mig med KDE3, men jeg vil foreslå at du
kører en make clean og sletter config.cache

Herefter kører du:
../configure --prefix=/kde3/kde --with-qt-dir=/kde3/qt

Men nu er det jo CVS versionen, og der er derfor ingen garanti for at
det overhovedet virker, uanset hvad du gør.
--
Thomas O.

This area is designed to become quite warm during normal operation.

---

Thomas Overgaard <thover@post2.tele.dk> wrote:
> Men nu er det jo CVS versionen, og der er derfor ingen garanti for at
> det overhovedet virker, uanset hvad du gør.

Jeg har endnu ikke oplevet et eneste projekt, hverken kommercielt eller
open source, hvor "tree breakage" ikke var noget man fik riv for af den
ansvarlige. Jeg kan ikke forestille mig, at der er perioder paa mere end
10-20 minutter hvor et source trae ikke compiler helt.

--
I prefer the dark of the night, after midnight and before four-thirty,
when it's more bare, more hollow. http://a.area51.dk/

---

Alex Holst wrote:

> Jeg har endnu ikke oplevet et eneste projekt, hverken kommercielt eller
> open source, hvor "tree breakage" ikke var noget man fik riv for af den
> ansvarlige. Jeg kan ikke forestille mig, at der er perioder paa mere end
> 10-20 minutter hvor et source trae ikke compiler helt.

Det kan jeg !! Navnlig i KDEs CVS.

Det, der tit sker, er, at der er en udvikler som programmerer og tester
sit program/sine ændringer på sin egen maskine. Det virker fint på hans
maskine, så han committer, og først da opdager andre, at der er problemer
med at kompilere på en anden platform.

Jeg kompilerer selv KDE og har gjort det siden 1.1.2. Næsten hver eneste
/release/ har givet problemer på RedHat (og sikkert mange andre platforme
også).

-Claus

---

Claus Rasmussen <clr@cc-consult.dk> wrote:
> Det, der tit sker, er, at der er en udvikler som programmerer og tester
> sit program/sine ændringer på sin egen maskine. Det virker fint på hans
> maskine, så han committer, og først da opdager andre, at der er problemer
> med at kompilere på en anden platform.

Det lyder rimeligt fjollet. Hvis du er i kontakt med KDE udviklerne kan
du jo fortaelle dem at "Daily Builds Are Your Friend!"

   http://www.joelonsoftware.com/articles/fog0000000023.html

--
I prefer the dark of the night, after midnight and before four-thirty,
when it's more bare, more hollow. http://a.area51.dk/

---

Alex Holst wrote:
>
> Det lyder rimeligt fjollet. Hvis du er i kontakt med KDE udviklerne
> kan du jo fortaelle dem at "Daily Builds Are Your Friend!"
>
KDE udviklerne mener vist at CVS versionen er pre-alpha, og hvis du vil
være med på en "bleeding edge" så må du også acceptere svipsere.
--
Thomas O.

This area is designed to become quite warm during normal operation.

---

Thomas Overgaard <thover@post2.tele.dk> skrev:
> Alex Holst wrote:
>>
>> Det lyder rimeligt fjollet. Hvis du er i kontakt med KDE udviklerne
>> kan du jo fortaelle dem at "Daily Builds Are Your Friend!"
>>
> KDE udviklerne mener vist at CVS versionen er pre-alpha, og hvis du vil
> være med på en "bleeding edge" så må du også acceptere svipsere.

Nej, ikke længere. KDE's HEAD branch har været i beta-test siden KDE
3.0 beta1 blev udgivet i slutningen af december sidste år, og beta2
skulle have være udgivet nu ifølge deres plan
(http://developer.kde.org/development-versions/kde-3.0-release-plan.html),
men er tilsyneladende forsinket - jeg har i hvert fald ikke set en
annoncering endnu. Der er også restrikitioner på hvike patches som
accepteres i øjeblikket, se linket ovenfor.

Derfor havde jeg håbet at den i det mindste kunne bygges uden
videre. Det kan jeg også med alle andre dele af kdebase end
kdebase/kdesktop med make -k. Min udgave er dog nogle få dage
gammel, så jeg vil prøve om en cvs update hjælper.

---

Byrial Jensen wrote:

> Thomas Overgaard <thover@post2.tele.dk> skrev:
>> Alex Holst wrote:
>>>
>>> Det lyder rimeligt fjollet. Hvis du er i kontakt med KDE udviklerne
>>> kan du jo fortaelle dem at "Daily Builds Are Your Friend!"
>>>
>> KDE udviklerne mener vist at CVS versionen er pre-alpha, og hvis du vil
>> være med på en "bleeding edge" så må du også acceptere svipsere.
>
> Nej, ikke længere. KDE's HEAD branch har været i beta-test siden KDE
> 3.0 beta1 blev udgivet i slutningen af december sidste år, og beta2
> skulle have være udgivet nu ifølge deres plan
> (http://developer.kde.org/development-versions/kde-3.0-release-plan.html),
> men er tilsyneladende forsinket - jeg har i hvert fald ikke set en
> annoncering endnu. Der er også restrikitioner på hvike patches som
> accepteres i øjeblikket, se linket ovenfor.

De har taget beta2 ud af cvs for flere dage siden, så den er nok på vej.


>
> Derfor havde jeg håbet at den i det mindste kunne bygges uden
> videre. Det kan jeg også med alle andre dele af kdebase end
> kdebase/kdesktop med make -k. Min udgave er dog nogle få dage
> gammel, så jeg vil prøve om en cvs update hjælper.

Det bør det.

Gunner Poulsen.
--
Aktiv i projektet Gnu Skole.
Et projekt med det formål at udbrede brugen af Open Source Software i
Grundskolen - til gavn for eleverne.
Se på http://www.gnuskole.dk hvordan du kan hjælpe.

---

Byrial Jensen <bjensen@nospam.dk> skrev:
> jeg vil prøve om en cvs update hjælper.

Det gjorde det. Jeg har nu en kørende kde3. Tak til alle som har
givet gode råd i denne tråd.

---

Byrial Jensen wrote:
>
> Det gjorde det. Jeg har nu en kørende kde3. Tak til alle som har
> givet gode råd i denne tråd.

Er den god?

(Jeg sidder og venter på ADSL som er bestildt, så jeg vil ikke belaste
min telefonregning med noget som kan udskydes.)
--
Thomas O.

This area is designed to become quite warm during normal operation.

---

Thomas Overgaard <thover@post2.tele.dk> skrev:
> Byrial Jensen wrote:
>>
>> Det gjorde det. Jeg har nu en kørende kde3. Tak til alle som har
>> givet gode råd i denne tråd.
>
> Er den god?

Jo, den er såmænd udmærket med en del forbedringer i forhold KDE 2
som den ellers ligner meget, rundt omkring. Jeg skal primært bruge
den til at afprøve nogle danske oversættelser som skal på plads før
den endelige udgave.

---

Claus Rasmussen <clr@cc-consult.dk> writes:

> Jeg kompilerer selv KDE og har gjort det siden 1.1.2. Næsten hver eneste
> /release/ har givet problemer på RedHat (og sikkert mange andre platforme
> også).

Hvis det er et roblem, hvorfor goer KDE ikke som Mozillafolkene?

http://tinderbox.mozilla.org/showbuilds.cgi?tree=SeaMonkey
--
Thorbjørn Ravn Andersen
http://bigfoot.com/~thunderbear

---

Byrial Jensen <bjensen@nospam.dk> writes:

> Derfor havde jeg håbet at den i det mindste kunne bygges uden
> videre.

Man bør aldrig satse på at en HEAD cvs checkout kan bygges, så længe
der stadig er nogen der har skrivetilladelse. Det gælder helt uanset
projektets politik, fordi cvs commit ikke er atomisk. Det vil sige at
hvis man har en nok så godt testet ændring der er afhångig af en
samtidig ændring i to filer, kan man risikere kun at få den ene ved en
checkout. Hvis man vil have en virkelig stabil version i CVS er man
nødt til at tagge den.

Uagtet den fejl i cvs mener jeg man altid bør være forberedt på at
HEAD er ødelagt fra tid til anden. At der er tale om en stabil branch
betyder i den sammenhæng blot at det sker forholdsvis sjældent, og
bliver rettet forholdsvis hurtigt.

---

Per Abrahamsen <abraham@dina.kvl.dk> wrote:
> Byrial Jensen <bjensen@nospam.dk> writes:
>
>> Derfor havde jeg håbet at den i det mindste kunne bygges uden
>> videre.
>
> Man bør aldrig satse på at en HEAD cvs checkout kan bygges, så længe
> der stadig er nogen der har skrivetilladelse. Det gælder helt uanset
> projektets politik, fordi cvs commit ikke er atomisk.

Tillad mig at lave reklame for en dejlig erstatning for CVS med blandt
andet atomiske commits -- 1.0 er snart ude.

   http://subversion.tigris.org

--
I prefer the dark of the night, after midnight and before four-thirty,
when it's more bare, more hollow. http://a.area51.dk/

---

Alex Holst <a@area51.dk> writes:

> Per Abrahamsen <abraham@dina.kvl.dk> wrote:
> > Byrial Jensen <bjensen@nospam.dk> writes:
> >
> >> Derfor havde jeg håbet at den i det mindste kunne bygges uden
> >> videre.
> >
> > Man bør aldrig satse på at en HEAD cvs checkout kan bygges, så længe
> > der stadig er nogen der har skrivetilladelse. Det gælder helt uanset
> > projektets politik, fordi cvs commit ikke er atomisk.

(Risikoen for at det går galt afhænger selvfølgelig af hvor aktiv
trafikken er. Det er sket meget sjældent for os. Et par gange er det
gået galt i forbindelse med "branch merges", hvor politikken er at den
der udfører arbejdet *ikke* er forpligtet til at sørge for at alting
kører derefter (fordi man ikke kan forventes at vide hvad meningen med
alle andres kode har været).)

> Tillad mig at lave reklame for en dejlig erstatning for CVS med blandt
> andet atomiske commits -- 1.0 er snart ude.
>
>    http://subversion.tigris.org

Mjo. Vi diskuterede den netop for et par dage siden i R projektet. Det
ser spændende ud men ikke helt uproblematisk.

Problemet er naturligvis at selv om CVS har sine plager, så er det
ikke en triviel sag at skifte til et andet system. CVS er såpas
udbredt at man kan være sikker på at det understøttes i mange år,
medens man er knap så sikker på at nye hotte produkter overlever.
(Den gamle historie: Det skal være en succes for at blive en
succes...)

Desuden er der (måske) knas med krydsplatformsupport til MacClassic
og Win9x platformene. Så vidt vi kunne se så skal platformen være i
stand til at køre Apache for at man kan være sikker på at Subversion
virker idet de bruger samme kompatibilitetsbibliotek.

--
O__ ---- Peter Dalgaard Blegdamsvej 3
c/ /'_ --- Dept. of Biostatistics 2200 Cph. N
(*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918
~~~~~~~~~~ - (p.dalgaard@biostat.ku.dk) FAX: (+45) 35327907

---

Peter Dalgaard BSA <p.dalgaard@biostat.ku.dk> wrote:
>>    http://subversion.tigris.org
>
> Mjo. Vi diskuterede den netop for et par dage siden i R projektet. Det
> ser spændende ud men ikke helt uproblematisk.

Naturligvis. Min kommentar var ikke ment som et gyldent stempel, og jeg
haaber ikke den blev taget saadan. Der er dog situationer hvor
Subversion boer overvejes som en mulig loesning, isaer hvis
implementationsdatoen ligger et stykke tid efter 1.0 release.

At skifte fra CVS til Subversion er en helt ny teknologibase. Den
benytter Apache 2, WebDAV og et par andre ting som ikke er generelt
udviklet eller udbredte. De fleste har ingen eller kun ganske lidt
erfaring med disse.

CVS alene har adskellige aar paa bagen, og det samme har de fleste
fjernadgangsloesninger, f.eks. SSH. Det er ikke saa komplext som
Subversion er.

> Desuden er der (måske) knas med krydsplatformsupport til MacClassic
> og Win9x platformene. Så vidt vi kunne se så skal platformen være i
> stand til at køre Apache for at man kan være sikker på at Subversion
> virker idet de bruger samme kompatibilitetsbibliotek.

Subversion bruger Apache Portable Runtime i baade klient og server for
at goere den saa portabel som muligt. Saa vidt jeg er orienteret giver
dette adgang til samtlige UNIX og Windows systemer, samnt MacOS X. Jeg
ved ikke med Mac Classic.

--
I prefer the dark of the night, after midnight and before four-thirty,
when it's more bare, more hollow. http://a.area51.dk/

---

Thorbjoern Ravn Andersen <thunderbear@bigfoot.com> writes:

> Hvis det er et roblem, hvorfor goer KDE ikke som Mozillafolkene?
>
> http://tinderbox.mozilla.org/showbuilds.cgi?tree=SeaMonkey

Jeg vil gætte på at det skyldes KDE projektet har langt færre
ressourcer end AOL.

---

Per Abrahamsen <abraham@dina.kvl.dk> writes:

> > Hvis det er et roblem, hvorfor goer KDE ikke som Mozillafolkene?
> >
> > http://tinderbox.mozilla.org/showbuilds.cgi?tree=SeaMonkey
>
> Jeg vil gætte på at det skyldes KDE projektet har langt færre
> ressourcer end AOL.

Formentlig.

Hvis oensket var der, kunne man vel lade folk donere compileservere til projektet.

(Stil den her maskine op paa jeres net med Internetforbindelse, traek
det her ud af CVS, start det her script og lad den staa).

Men hvad ved jeg.
--
Thorbjørn Ravn Andersen
http://bigfoot.com/~thunderbear

---

Alex Holst <a@area51.dk> writes:

> Thomas Overgaard <thover@post2.tele.dk> wrote:
>> Men nu er det jo CVS versionen, og der er derfor ingen garanti for at
>> det overhovedet virker, uanset hvad du gør.
>
> Jeg har endnu ikke oplevet et eneste projekt, hverken kommercielt eller
> open source, hvor "tree breakage" ikke var noget man fik riv for af den
> ansvarlige.

Jeg har heller ikke oplevet et eneste aktivt projekt hvor de alligevel
ikke er hyppige.

> Jeg kan ikke forestille mig, at der er perioder paa mere end 10-20
> minutter hvor et source trae ikke compiler helt.

Det kommer an på hvor mange og hvilke platforme der er påvirket. Hvis
det f.eks. "ikke kan bygges på Slackware hvor zsh er installeret i
stedet for bash som /bin/sh" kan det tage lang tid før det bliver
rettet.

Hvis det påvirker alle, og der er mange aktive med skrivetilladelse,
vil det femøse patch hurtigt blive afinstalleret. Men det hjælper jo
ikke den tilfældige bruger der lavede en cvs checkout i mellemtiden,
og naivt forventer alt vil virke.

---

On Fri, 08 Feb 2002 11:10:56 +0100, Per Abrahamsen wrote:

> Alex Holst <a@area51.dk> writes:
>
>> Thomas Overgaard <thover@post2.tele.dk> wrote:
>>> Men nu er det jo CVS versionen, og der er derfor ingen garanti for at
>>> det overhovedet virker, uanset hvad du gør.
>>
>> Jeg har endnu ikke oplevet et eneste projekt, hverken kommercielt eller
>> open source, hvor "tree breakage" ikke var noget man fik riv for af den
>> ansvarlige.
>
> Jeg har heller ikke oplevet et eneste aktivt projekt hvor de alligevel
> ikke er hyppige.
>
>> Jeg kan ikke forestille mig, at der er perioder paa mere end 10-20
>> minutter hvor et source trae ikke compiler helt.
>
> Det kommer an på hvor mange og hvilke platforme der er påvirket. Hvis
> det f.eks. "ikke kan bygges på Slackware hvor zsh er installeret i
> stedet for bash som /bin/sh" kan det tage lang tid før det bliver
> rettet.
>
> Hvis det påvirker alle, og der er mange aktive med skrivetilladelse, vil
> det femøse patch hurtigt blive afinstalleret. Men det hjælper jo ikke
> den tilfældige bruger der lavede en cvs checkout i mellemtiden, og naivt
> forventer alt vil virke.

http://linuxtoday.com/news_story.php3?ltsn=2002-02-08-012-20-PS

Hilsen tommy

---

Thorbjoern Ravn Andersen <thunderbear@bigfoot.com> writes:

> Hvis oensket var der, kunne man vel lade folk donere compileservere
> til projektet.
>
> (Stil den her maskine op paa jeres net med Internetforbindelse, traek
> det her ud af CVS, start det her script og lad den staa).

Det er ikke nok ønsket er der, det kræver stadig en central
administration, og derved en frivillig. Mozilla har en projektleder
der kan prioritere de ansattes tid, fordi så mange kommer fra et
enkelt firma. Men for de fleste fri software projekter afhænger den
slags af at der er en frivillig der enten synes den slags er sjovt,
eller er tilstrækkelig enthusiastisk til at gøre det alligevel. Det
kan være svært, de fleste, både private og ikke-dominerende firmaer,
vil hellere arbejde målrettet mod specifikke features eller
fejlretning der direkte har deres interesse.

---

Alex Holst <a@area51.dk> writes:

> Tillad mig at lave reklame for en dejlig erstatning for CVS med blandt
> andet atomiske commits -- 1.0 er snart ude.
>
>    http://subversion.tigris.org

Der er også arch, et mere ambitiøst projekt der _er_ ude. arch har
ligesom Bitkeeper flere niveauer af repositiories, det betyder at
selvom du arbejder off-line hjemme kan du sagtens have versionskontrol
og lokale branches i dit lokale repository, som du senere kan commite
"upstream" til repositoriet på arbejdet. For et giga-projekt som
Linux betyder det at Linus kan have hovedrepositoriet, mens af
f.eks. Alan Cox, LinuxPPC og IBM hver kan have deres egne
underrepositories, det kan synkroniseres upstream, eller med hinanden.
Bitkeeper er ikke fri software, men det er arch.

De største problemer med arch er at det er nyt, så der er usikkerhed
forbundet med at bruge det, og at det delvist er shell-scripts ovenpå
nogen få primitive kommandoer, ligesom tidlige versioner af cvs. Det
vil gøre det vanskeligt at porte.

<URL: http://www.regexps.com/#arch >