# Handbok för skriptet &kdesrc-build;

Michael
Pyne

    mpyne@kde.org

Carlos
Woelz

    carloswoelz@imap-mail.com

Stefan
Asserhäll

    stefan.asserhall@comhem.se

Översättare
2006
2007
2008
2009
2010
Michael Pyne
2005
Carlos Woelz
&FDLNotice;
2010-01-30
1.12

&kdesrc-build; är ett skript som bygger och installerar &kde;s programvara, direkt från källkoden som hämtas från .

KDE
kdesdk
SVN
Subversion
git
gitorious
KDE-utveckling
kdesvn-build
kdecvs-build

## Inledning

&kdesrc-build; är ett skript som hjälper användare att installera &kde; från källkodsarkiven &subversion; och &git;.

Den här programvaran hette tidigare kdesvn-build, så man kan fortfarande hitta referenser till kdesvn-build på Internet eller i den installerade dokumentationen.

Den här guiden är en översikt som beskriver följande aspekter vid användning av &kdesrc-build;:

- Funktioner värda att lägga märke till.

- En översikt av stegen som krävs för att komma igång.

- Inställningsfilens syntax och alternativ.

- Kommandoradsväljarna.

Dessutom dokumenteras stegen du måste utföra när andra verktyg används (med andra ord, steg som inte utförs automatiskt av &kdesrc-build;).

## Komma igång

I det här kapitlet visar vi hur &kdesrc-build; används för att checka ut moduler från &kde;-arkivet och bygga dem. Vi tillhandahåller också en grundläggande förklaring av &kde;:s &subversion;-struktur och stegen du måste utföra innan skriptet körs.

Alla ämnen som presenteras i det här kapitlet täcks med ännu mer detaljer i artikeln Building &kde; 4 from Source på webbplatsen &kde; TechBase. Om du kompilerar &kde; för första gången, är det en god idé att läsa den, eller rådfråga den som en referenskälla. Du hittar detaljerad information om paketverktyg och krav, vanliga fallgropar vid kompilering och strategier och information om att köra den nya &kde;-installationen.

### Förbereda systemet för att bygga &kde;

#### Ställa in ett nytt användarkonto

Det rekommenderas att du använder ett annat användarkonto för att bygga, installera och köra din &kde;-programvara från, eftersom färre rättigheter krävs, och för att undvika konflikt med distributionens paket. Om du redan har installerade &kde;-paket, är det bästa valet att skapa en annan (dedicerad) användare för att bygga och köra det nya &kde;.

Att lämna systemets &kde; orört, låter dig också ha en reservutväg i nödfall om ett kompilerat &kde; är instabilt av någon orsak.

Senare kan du installera som systemadministratör om du vill. Det här dokumentet täcker inte en installation som systemadministratör. Om du utför en systeminstallation, vet du troligen ändå vad du gör. Om inte, kan du behöva konsultera dokumentation eller hjälpplatser för din distribution, för att utföra och använda systeminstallationen riktigt.

#### Försäkra dig om att systemet är klart att bygga &kde;:s källkod

Innan du använder skriptet &kdesrc-build; (eller någon annan byggstrategi) måste du installera utvecklingsverktyg och bibliotek som behövs för &kde;. Den fullständiga listan med verktyg som behövs finns på KDE:s teknikbas.

Här är en lista med några av de saker du kommer att behöva:

- Du kommer att behöva &cmake;. Versionen som krävs varierar beroende på vilken version av &kde; 4 du bygger, se TechBase för specifik information.

- Klientprogrammet för &subversion;, inklusive stöd för säker HTTP (https) behövs också. För att försäkra dig om nödvändigt stöd finns, kan du köra ``svn `--version```. Om utmatningen säger att den hanterar metoden https (för skrivåtkomst till svn.kde.org) eller metoden svn (för läsåtkomst till anonsvn.kde.org), ska du vara klar att köra.

- Om du bygger &Qt; eller någon av de olika &kde;-modulerna tillgängliga från Gitorious, behöver du dessutom ha installerat källkodshanteringsverktyget Git.

- Du behöver en utvecklingsmiljö för C++. GCC 3.4 eller senare rekommenderas.

De flesta distributioner av operativsystem inkluderar en metod att enkelt installera nödvändiga utvecklingsverktyg. Konsultera avsnittet Required Packages from your Distribution på sidan Getting Started på TechBase, för att se om instruktioner redan är tillgängliga.

Ett undantag från bibliotek som krävs är &Qt;-biblioteket. &kdesrc-build; installerar normalt en kopia av &Qt; vare sig du har det installerat eller inte, så det är inte nödvändigt att du har det. Om du inte vill använda kopian av &Qt;, måste du göra följande:

- Försäkra dig om att ta bort modulen qt-copy från din inställningsfil eftersom du inte behöver den, och att ha den skulle lägga till extra tid till byggprocessen.

- Ändra inställning av alternativet qtdir i din inställningsfil så att det pekar på systemets &Qt;. Det är normalt samma sak som inställningen av $`QTDIR` i systemet.

- Om du inte redan har installerat &Qt;, installera det, inklusive eventuella relevanta -dev eller -devel paket. Du behöver minst &Qt; 4.6 om du bygger &kde; 4.

Vissa av paketen är uppdelade i bibliotek (eller program, eller verktyg) och utvecklingspaket. Du behöver åtminstone programmet eller biblioteket och dess utvecklingspaket. Om du är tveksam, installera alla. Biblioteken du behöver ändras beroende på modulerna du tänker bygga, eftersom varje modul har sina egna krav. &kde; TechBase har mer information om de specifika verktygen och tekniker som används för att installera och hitta programvara som krävs.

#### Inställning av &kdesrc-build;

##### Installera &kdesrc-build;

Du har troligen redan en version av skriptet &kdesrc-build; installerad på systemet. Om du dock inte har det kan du ladda ner det från hemsidan för &kdesrc-build;, eller hämta det från dess hem i &kde;:s källkodsarkiv.

&kdesrc-build; ingår i modulen kdesdk,, och modulen installeras oftast redan av distributioner. Om du har laddad ner &kdesrc-build;, försäkra dig om att du använder versionen du laddat ner. Du kan använda väljaren --version för att vara säker på att du kör den version du tror att du kör.

1. För att ladda ner &kdesrc-build; från dess hemsida, gå helt enkelt till hemsidan för &kdesrc-build; och ladda ner senaste lämpliga utgåva. Utgåvorna paketeras som ett komprimerat tar-arkiv, som du kan packa upp med &ark; eller `tar`. Innehållet i arkivet omfattar själva skriptet &kdesrc-build;, och ett exempel på en inställningsfil (`kdesrc-buildrc-sample`).

2. Annars kan du skaffa &kdesrc-build; från dess källkodsarkiv, på: http://websvn.kde.org/trunk/KDE/kdesdk/scripts/. Det är skriptkatalogen för &kde;:s programvaruutvecklingsverktyg, som är hemkatalog för &kdesrc-build;. Du kan klicka på posten `kdesrc-build`, vilket leder dig till en sida där du kan ladda ner den senaste utgåvan. Gör det, och spara den på ett praktiskt ställe på din hårddisk. Gör samma sak med `kdesrc-buildrc-sample` om du behöver.

Oberoende av vilken teknik du använder, måste du försäkra dig om att filen `kdesrc-build` är körbar. Av bekvämlighetsskäl bör du försäkra dig om att den finns i en katalog som ingår i miljövariabeln `PATH`, annars kan du få meddelanden som säger att kommandot inte hittades, eller kör du kanske en tidigare installerad version av misstag.

##### Färdigställa inställningsfilen

Även om &kdesrc-build; inte kräver att du skapar en inställningsfil, gör det arbetsflödet mycket enklare. Genom att använda en inställningsfil, kan du styra vilka moduler som installeras, eller ta bort moduler du inte vill installera. &kdesrc-build; installerar normalt en användbar &kde;-installation med mycket generella installationsflaggor, som kan skilja sig från dina behov. Det är alltså bäst att använda en inställningsfil

Inställningsfilen ska heta `.kdesrc-buildrc`. Filen ska installeras i hemkatalogen (`~`), och innehålla all inställningsdata som krävs för att skriptet ska kunna köras, som konfigureringsalternativ, kompileringsalternativ, plats för källkoden, installationens mål (prefix), modulerna som ska byggas, etc. Standardinställningsdata tillhandahålls av filen `kdesrc-buildrc-sample`, som du kan kopiera till `~/.kdesrc-buildrc` och därefter redigera.

Du hittar mer information om syntaxen i en inställningsfil i och .

### Ange inställningsinformation

För att använda &kdesrc-build; ska du ha en fil i hemkatalogen som heter `.kdesrc-buildrc` som ställer in allmänna alternativ och anger modulerna som du vill ladda ner och bygga.

Det är möjligt att använda andra inställningsfiler för &kdesrc-build;, som beskrivs i . Om du behöver använda flera inställningar, se det avsnittet.Här antar vi att inställningarna är lagrade i `~/.kdesrc-buildrc`.

Det enklaste sättet att fortsätta är att använda filen `kdesrc-buildrc-sample` som mall, och ändra allmänna inställningar för att stämma med vad du vill ha, och dessutom ändra listan med moduler du vill bygga.

Standardinställningarna bör i själva verket redan vara lämpliga för att utföra byggprocessen för &kde;. Vissa inställningar som du kan vilja ändra omfattar:

- binpath, för att ändra listan med kataloger som söks igenom efter kommandon. Det är precis samma sak som variabeln `PATH` i skalet.

- kdedir, som ändrar målkatalogen som &kde; installeras i. Standardvärdet är `~/kde`, som är en enanvändarinstallation.

- qtdir, som styr sökvägen till installationen av &Qt; att använda. Standardvärdet är att använda &Qt; kompilerat av &kdesrc-build;, med den särskilda modulen qt-copy och den senast tillgängliga källkoden (`~/kdesrc/build/qt-copy`).

  Det bestämmer också var qt-copy ska installeras.

- svn-server, som väljer vilken webbadress som källkoden laddas ner från. Det är användbart om du är en utvecklare med ett &kde; &subversion;-konto.

Efter den allmänna delen finns en lista med moduler att bygga, omgivna av raderna module ... end module. Kontrollera att de listade modulerna verkligen är de moduler du vill bygga. Standardalternativen från filen `kdesrc-buildrc-sample` ska vara tillräckliga för att få en ganska fullständig installation av &kde;. Spara resultatet som `.kdesrc-buildrc` i din hemkatalog.

Om du vill finjustera `.kdesrc-buildrc`, titta då på för detaljerad information om alla inställningsalternativ.

### Att använda skriptet &kdesrc-build;

Nu är du klar att köra skriptet. Logga in till användaren som du använder för att kompilera &kde; i ett terminalfönster, och kör skriptet:

    $kdesrc-build

Nu ska skriptet börja ladda ner källkoden och kompilera den. Beroende på hur många moduler du laddar ner, är det möjligt att &kdesrc-build; inte lyckas första gången du kompilerar &kde;. Ge inte upp hoppet!

&kdesrc-build; loggar utmatningen från varje kommando som körs. Normalt lagras loggfilerna i `~/kdesrc/log`. För att se vad som orsakade ett fel för en modul vid det senaste &kdesrc-build;-kommandot, är det oftast tillräckligt att titta i `~/kdesrc/log/latest/modulnamn/error.log`.

I filen ser du felet som orsakade att byggprocessen misslyckades för modulen. Om filen säger (längst ner) att vissa paket saknas, försök att installera paketet (inklusive eventuella lämpliga -dev paket) innan du försöker bygga modulen, och skicka med väljaren --reconfigure efter att du har installerat de saknade paketen.

Eller om felet verkar vara ett byggfel är det nog ett fel i &kde;:s källkod, som förhoppningsvis löses inom några dagar. Om det inte har lösts inom den tiden, skicka gärna ett brev till e-postlistan kde-devel@kde.org (prenumeration kan krävas först) för att rapportera byggfelet.

Du hittar fler vanliga exempel på saker som kan gå fel och deras lösningar, samt allmänna tips och strategier för att bygga &kde;i guiden Building &kde; 4 from Source.

För mer information om loggningssystemet i &kdesrc-build;, se .

### Ställa in miljön för att köra det färska &kde;

Med antagandet att du använder en särskild användare för att bygga &kde; och redan har en installerad version av &kde;, kan det vara något krångligt att köra det nya &kde;, eftersom det nya &kde; måste ges företräde över det gamla. Ändra miljövariabler för att försäkra dig om att det gör det.

#### Ändra startprofilinställningar

Filen `.bash_profile` är inloggningsinställningarna för det populära skalet bash som används av många &Linux;-distributioner. Om du använder ett annat skal, kan du behöva justera exemplen som ges i det här avsnittet för ditt specifika skal.

Öppna eller skapa filen `.bash_profile` i hemkatalogen med din favoriteditor, och lägg till följande i slutet på filen. Om du bygger modulen qt-copy (det gör du normalt), lägg istället till:

    QTDIR=(sökväg till qtdir)   # Såsom normalt ~/kdesrc/build/qt-copy.
    KDEDIR=(sökväg till kdedir) # Såsom normalt ~/kde.
    KDEDIRS=$KDEDIR
    PATH=$KDEDIR/bin:$QTDIR/bin:$PATH
    MANPATH=$QTDIR/doc/man:$MANPATH

    # Gör rätt om inte LD_LIBRARY_PATH redan är satt.
    if [ -z $LD_LIBRARY_PATH ]; then
      LD_LIBRARY_PATH=$KDEDIR/lib:$QTDIR/lib
    else
      LD_LIBRARY_PATH=$KDEDIR/lib:$QTDIR/lib:$LD_LIBRARY_PATH
    fi

    export QTDIR KDEDIRS PATH MANPATH LD_LIBRARY_PATH

eller om du inte bygger qt-copy (och använder systemets &Qt;) lägg till det här istället:

    KDEDIR=(sökväg till kdedir)  # Såsom ~/kde normalt.
    KDEDIRS=$KDEDIR
    PATH=$KDEDIR/bin:$QTDIR/bin:$PATH

    # Gör rätt om inte LD_LIBRARY_PATH redan är satt.
    if [ -z $LD_LIBRARY_PATH ]; then
      LD_LIBRARY_PATH=$KDEDIR/lib
    else
      LD_LIBRARY_PATH=$KDEDIR/lib:$LD_LIBRARY_PATH
    fi

    export KDEDIRS PATH LD_LIBRARY_PATH

Om du inte använder en särskild användare ställ in en annan $`KDEHOME` för din nya miljö i `.bash_profile`:

    export KDEHOME="${HOME}/.kde-svn"

    # Skapa om det behövs
    [ ! -e ~/.kde-svn ] && mkdir ~/.kde-svn

Om din K-meny senare är tom eller för tätpackad med program från din distribution, kanske du måste ange miljövariabeln XDG i din `.bash_profile`:

    XDG_CONFIG_DIRS="/etc/xdg"
    XDG_DATA_DIRS="${KDEDIR}/share:/usr/share"
    export XDG_CONFIG_DIRS XDG_DATA_DIRS

#### Starta &kde;

När du nu har justerat dina miljöinställningar för att använda rätt &kde;, är det viktigt att försäkra dig om att det rätta `startkde`-skriptet också används.

Öppna textfilen `.xinitrc` från hemkatalogen, eller skapa den om det behövs. Lägg till raden:

    exec ${KDEDIR}/bin/startkde

Det kan vara nödvändigt att utföra samma steg med filen `.xsession`, också i hemkatalogen. Det är särskilt sant om grafiska inloggningshanterare som &kdm;, gdm eller xdm används.

Starta nu det nya &kde;: i &BSD;- och &Linux;-system med stöd för virtuella terminaler, används tangentkombinationerna &Ctrl;&Alt;F1 ... &Ctrl;&Alt;F12 för att byta till virtuell konsoll 1 till och med 12. Det låter dig köra fler än en skrivbordsmiljö samtidigt. De första sex är textterminaler, och de följande sex är grafiska skärmar.

Om den grafiska inloggningshanteraren visas istället när du startar datorn, kan du använda den nya &kde;-miljön även om den inte anges som ett alternativ. De flesta inloggningshanterare, inklusive &kdm;, har ett alternativ att använda en Egen session när du loggar in. Med det alternativet laddas dina sessionsinställningar från filen `.xsession` i din hemkatalog. Om du redan har ändrat filen som beskrivs ovan, ska alternativet starta den nya &kde;-installationen.

Om det inte gör det, finns det något annat som du kan prova som normalt ska fungera: Tryck på &Ctrl;&Alt;F2, så visas en textterminal. Logga in som den särskilda användaren och skriv:

    startx -- :1

Du kan köra &kde; från källkod och det gamla &kde; samtidigt. Logga in som din vanliga användare, och starta det stabila &kde;-skrivbordet. Tryck på &Ctrl;&Alt;F2 (eller F1, F3, etc.) så visas en textterminal. Logga in som den särskilda &kde; &subversion;-användaren och skriv:

    startx -- :1

Du kan gå tillbaka till &kde;-skrivbordet för din vanliga användare genom att trycka på snabbtangenten för skrivbordet som redan kör. Den är normalt &Ctrl;&Alt;F7, men du kanske måste använda F6 eller F8 istället. För att returnera till &kde; kompilerat med &kdesrc-build;, ska du använda samma sekvens, utom med nästa funktionstangent. Om du till exempel behövde skriva &Ctrl;&Alt;F7 för att byta till det vanliga &kde;, skulle du behöva skriva &Ctrl;&Alt;F8 för att gå tillbaka till &kde; byggt med &kdesrc-build;.

## Skriptets funktioner

### Översikt över funktioner

Funktionerna i &kdesrc-build; omfattar:

- Stöder meddelandenivåer för utmatning som sträcker sig från att vara mycket tyst till en fullständig felsökningsnivå.

- &kdesrc-build; kan med hjälp av &kdesrc-build;s hemsida och &kde;:s FTP-server (FTP sedan &kdesrc-build; 1.4) tillåta snabb utcheckning av vissa moduler. Om modulen du checkar ut redan har paketerats på hemsidan, laddar &kdesrc-build; ner den versionen och förbereder den för användning på din dator.

  Det är snabbare för dig, och hjälper till att minska lasten på de anonyma &subversion;-servrarna.

- En annan uppsnabbning tillhandahålls genom att starta byggprocessen för en modul så fort källkoden för den modulen har laddats ner (tillgänglig sedan version 1.6).

- Har utmärkt stöd för modulen qt-copy, inklusive valfritt införa felrättningar och optimeringsprogramfixar i modulen qt-copy.

- &kdesrc-build; har färglagd utmatning.

- &kdesrc-build; kräver inte att ett grafiskt gränssnitt är tillgängligt för att fungera. Du kan alltså bygga &kde; utan att behöva en alternativ grafisk miljö.

- Stöder inställning av standardalternativ för alla moduler (som kompileringsinställningarna eller konfigureringsalternativen). Sådana alternativ kan dessutom normalt ändras för specifika moduler.

  Dessutom lägger &kdesrc-build; till standardflaggor där det är lämpligt, för att spara dig besvär och möjliga fel från att skriva in dem själv.

- &kdesrc-build; kan checka ut en särskilt gren eller tagg av en modul. Du kan också försäkra dig om att en specifik revision av en modul checkas ut.

- &kdesrc-build; kan automatiskt ändra källkodskatalog för att checka ut från ett annat arkiv, gren eller tagg. Det sker automatiskt när du ändrar ett alternativ som ändrar vad arkivets webbadress är, men du måste använda väljaren --src-only för att tala om för &kdesrc-build; att det är acceptabelt att utföra bytet.

- &kdesrc-build; kan checka ut delar av en modul, för de situationer där du bara behöver ett program från en stor modul.

- Den ursprungliga nerladdningen av vissa moduler kan accelereras av &kdesrc-build;, som automatiskt laddar ner en version av modulen från &kde;:s spegelplatser (om tillgänglig) och använder den för att skapa den ursprungliga utcheckningen. Det sparar tid och bandbredd för både din dator och &kde;:s servrar.

- För utvecklare: &kdesrc-build; kommer att påminna dig om du använder svn+ssh:// men ssh-agent inte kör, eftersom det leder till upprepad begäran om lösenord från &ssh;.

- Kan skicka e-postrapporter med fel till en användare.

- Kan ta bort byggkatalogen för en modul efter den har installerats för att spara utrymme till bekostnad av framtida kompileringstid.

- Platserna för katalogerna som används av &kdesrc-build; kan ställas in (till och med per modul).

- Kan använda &sudo;, eller ett annat användarspecificerat kommando för att installera moduler så att &kdesrc-build; inte behöver köras som systemadministratör.

- &kdesrc-build; kör normalt med reducerad prioritet för att låta dig fortsätta använda datorn medan &kdesrc-build; arbetar.

- Har stöd för att använda &kde;:s &subversion; taggar och grenar.

- &kdesrc-build; använder en uppsättning tekniker för att försöka garantera en lyckad byggprocess.

- Det finns stöd för att återuppta en byggprocess från en given modul. Du kan till och med ignorera vissa moduler tillfälligt för en given byggprocess.

- &kdesrc-build; kan snabbt utföra en partiell byggprocess för en modul direkt från kommandoraden, när du bara behöver uppdatera en del av en modul.

- &kdesrc-build; visar förloppet för byggprocessennär &cmake; används, och tar alltid tid på byggprocessen så att du i efterhand vet hur lång tid den tog.

- Försöker automatiskt bygga om moduler som använder en inkrementell byggprocess, vilken tenderar att misslyckas efter vissa typer av incheckningar.

- Levereras med en inbyggt rimlig uppsättning förvalda alternativ lämpligt för att bygga en grundläggande enanvändarinstallation av &kde; från det anonyma &subversion;-arkivet.

- Expanderar dina inställningsalternativ med tilde. Du kan till exempel ange:

      qtdir ~/kdesrc/build/qt-copy

- Ställer automatiskt in ett byggsystem med källkodskatalogen skild från byggkatalogen, för att hålla källkodskatalogen orörd.

- Du kan ange allmänna alternativ att använda för alla moduler som checkas ut, och du kan dessutom ange alternativ som ska användas för enskilda moduler.

- Eftersom autoverktygen ibland blir osynkroniserade med ändringar i källkodsträdet, kan du tvinga att en modul byggs om genom att skapa en fil som heter refresh-me i byggkatalogen för modulen i fråga, eller genom att köra &kdesrc-build; med väljaren `--refresh-build`.

- Du kan ange diverse miljövariabler som ska användas under byggprocessen, inklusive `KDEDIR`, `QTDIR`, `DO_NOT_COMPILE` och `CXXFLAGS`.

- Kommandologgning. Loggar dateras och numreras så att du alltid har en logg av en körning av skriptet. Dessutom skapas en symbolisk länk som heter latest, som alltid pekar på den senaste loggen i loggkatalogen.

- Om du använder en användarbyggd &kde; istället för en systembyggd (som du måste vara systemadministratör för att installera), kan du låta skriptet installera åt dig. Jag har inte granskat koden, och den använder anropet `system()` flitigt, så jag rekommenderar för närvarande att inte köra den som systemadministratör.

- Du kan använda make-install-prefix för att inleda kommandoraden ``make` `install`` med ett separat kommando, vilket är användbart för &sudo;.

- Du kan checka ut bara en delmängd av en &kde; &subversion;-modul. Du skulle till exempel kunna checka ut bara taglib från kdesupport, eller bara K3B från extragear/multimedia. Skriptet hämtar automatiskt in kde-common om det behövs för att få byggprocessen att fungera.

- Du kan låtsas att utföra åtgärden. Om du skickar med `--pretend` eller `-p` på kommandoraden, ger skriptet en mycket utförlig beskrivning av de kommandon som ska göras, utan att i själva verket utföra dem.

### Byggloggning i &kdesrc-build;

#### Översikt över loggning

Loggning är en funktion i &kdesrc-build; varigenom utmatningen från varje kommando som &kdesrc-build; kör sparas i en fil för senare undersökning, om nödvändigt. Det görs eftersom det ofta är nödvändigt att ha utmatningen från programmen när ett byggfel uppstår, eftersom det finns så många orsaker att en byggprocess kan misslyckas från början.

##### Loggningskatalogens layout

Loggarna lagras alltid i loggkatalogen. Platsen för loggkatalogen styrs av alternativet log-dir, som normalt är `${source-dir}/log` (där ${source-dir} är värdet av alternativet source-dir. I resten av avsnittet kallas värdet ${log-dir}).

I ${log-dir} finns en uppsättning kataloger, en för varje gång &kdesrc-build; kördes. Varje katalog namnges med datum och körnumret. Exempelvis, den andra gången &kdesrc-build; körs 26:e maj, 2004, skulle en katalog som heter `2004-05-26-02` skapas, där 2004-05-26 står för datumet och -02 är körnumret.

För din bekvämlighet skapar &kdesrc-build; också en länk till loggarna för den senaste körningen, som heter `latest`. Loggarna för den senaste körningen av &kdesrc-build; ska alltid finnas under `${log-dir}/latest`.

Varje katalog för en körning av &kdesrc-build; innehåller nu i sin tur en uppsättning kataloger, en för varje &kde;-modul som &kdesrc-build; försöker bygga. Dessutom finns en fil som heter `build-status` i katalogen, som låter dig avgöra vilka moduler som byggdes och vilka som misslyckades.

Om en modul själv har en delmodul (såsom extragear/multimedia, playground/utils eller KDE/kdelibs), finns i själva verket motsvarande struktur i loggkatalogen. Loggarna för KDE/kdelibs efter den senaste körningen av &kdesrc-build; finns till exempel i `${log-dir}/latest/KDE/kdelibs`, och inte i `${log-dir}/latest/kdelibs`.

Du hittar en uppsättning filer för varje åtgärd som &kdesrc-build; utför i varje modulloggkatalog. Om &kdesrc-build; uppdaterar en modul, kan du se filnamn såsom `svn-co.log` (för en utcheckning av en modul) eller `svn-up.log` (när en modul uppdateras som redan har checkats ut). Om kommandot `configure` kördes, kan du förvänta dig att se filen `configure.log` i katalogen.

Om ett fel uppstod, bör du kunna se en förklaring av varför i en av filerna. För att hjälpa till att avgöra vilken fil som innehåller felet, skapar &kdesrc-build; en länk från filen med felet (såsom `build-1.log` till en fil som heter `error.log`).

Slutresultatet av allt detta är att för att se varför en modul misslyckades byggas efter den senaste körningen av &kdesrc-build;, är filen du först ska titta i `${log-dir}/latest/modulnamn/error.log`.

Om filen `error.log` är tom (särskilt efter en installation), kanske det inte var något fel. Vissa verktyg som används av &kde;:s byggsystem rapporterar ibland av misstag ett fel när det inte fanns något.

Dessutom kringgår några kommandon omdirigeringen av utmatning som &kdesrc-build; gör, och går förbi loggfilen under vissa omständigheter (normalt när den första utcheckningen från &subversion; sker), och felutmatningen finns inte i loggfilen i detta fall, utan istället i terminalen där &kdesrc-build; kördes

## Anpassa &kdesrc-build;

### Översikt av &kdesrc-build; anpassning

För att använda skriptet måste du ha en fil i din hemkatalog som heter `.kdesrc-buildrc`, som beskriver modulerna som du vill ladda ner och bygga.

Den börjar med allmänna alternativ, angivna enligt följande:

    global
    alternativ-namn alternativ-värde
    [...]
    end global

De följs därefter av en eller flera modulsektioner, angivna på följande sätt:

    module modul-namn
    alternativ-namn alternativ-värde
    [...]
    end module

modul-namn måste vara en modul i &kde;:s &subversion;-arkiv (till exempel kdelibs eller kdebase). Vissa alternativ överskrider de allmänna alternativen, vissa lägger till i de allmänna alternativen och vissa allmänna alternativ kan helt enkelt inte överskridas.

Följande är en lista med alternativ som ofta används. Klicka på alternativet för att ta reda på mer om det. För att visa den fullständiga listan med alternativ, se .

- branch, för att checka ut från en gren istället för /trunk.

- build-dir, för att ange katalog att bygga i.

- cmake-options för att ange vilka flaggor en modul ska ställas in med vid användning av &cmake;.

- configure-flags för att ange vilka flaggor en modul ska ställas in med.

- cxxflags för att definiera variabeln `CXXFLAGS`.

- kdedir, för att ange katalogen där &kde; ska installeras.

- kde-languages, för att ställa in översättningspaketen att ladda ner och installera.

- make-options, för att skicka väljare till byggprogrammet &make;.

- qtdir, för att ange sökvägen till &Qt;.

- set-env, för att sätta en miljövariabel.

- source-dir, för att ändra vart källkoden laddas ner.

- svn-server, för att ändra servern som källkoden automatiskt laddas ner från.

### Tabell av tillgängliga inställningsalternativ

Här är en tabell med diverse alternativ, som innehåller följande information:

- Alternativets namn

- En beskrivning av hur &kdesrc-build; beter sig om alternativet både är angivet i den allmänna sektionen och modulsektionen i inställningsfilen när modulen byggs.

- Särskilda kommentarer om alternativets syfte och användning.

#### Alternativtabell

Alternativnamn | Modul -> Allmänt beteende | Anmärkningar
--- | --- | ---

apidox

Alternativet användes för att tillåta att KDE-modulens dokumentation av programmeringsgränssnitt byggdes. Det togs bort i &kdesrc-build; 1.6.3 eftersom det inte stöds i KDE 4. Dokumentation av programmeringsgränssnitt är tillgänglig på kde.org. Dessutom är det möjligt att bygga dokumentation av programmeringsgränssnittet i KDE 4 med ett skript som ingår i modulen kdesdk (i katalogen /scripts). Se KDE TechBase för ytterligare detaljinformation. Det är förstås fortfarande möjligt att bygga dokumentation av programmeringsgränssnittet för äldre moduler manuellt.

apply-qt-patches |  | Alternativet togs bort i kdesrc-build 1.10 För att få samma effekt, se och alternativet repository.

async

Kan inte överskridas

Alternativet aktiverar asynkront användningssätt, där uppdatering av källkoden och byggprocessen utförs i parallell, istället för att vänta på alla uppdateringar av källkoden innan byggprocessen startas. Alternativets förvalda värde är att aktivera asynkront användningssätt. För att inaktivera, ställ in alternativet till false.

Alternativet är tillgängligt från och med utgåva 1.6.

binpath

Modulinställning överskrider allmän

Sätt alternativet för att använda miljövariabeln PATH under byggprocessen. Du kan inte överskrida alternativet i ett modulalternativ. Förvalt värde är $`PATH` som är inställd när skriptet startar. Miljövariabeln ska innehålla sökvägar till utvecklingsverktygen åtskilda med kolon. Sökvägarna `$`KDEDIR`/bin` och `$`QTDIR`/bin` läggs automatiskt till. Du kan använda tilde (~) för eventuella sökvägar du lägger till med det här alternativet.

branch

Modulinställning överskrider allmän

Ställ in alternativet för att checka ut från en gren av &kde; istället för standardvärdet trunk där utveckling av &kde; sker. För att till exempel checka ut grenen &kde; 4.5, skulle du ställa in alternativet till 4.5.

Om &kdesrc-build; misslyckas med att ladda ner en gren med väljaren, kan du behöva ange webbadressen att ladda ner från för hand med alternativet module-base-path eller override-url.

Observera: Alternativet fungerar också med källmoduler som använder &git; istället för &subversion;.

build-dir

Modulinställning överskrider allmän

Använd det här alternativet för att byta katalog som innehåller källkoden att bygga. Det finns tre olika sätt att använda det:

1. Relativt till &kde;:s &subversion;-källkodskatalog (se alternativet source-dir). Det är förvalt, och väljes om du skriver in ett katalognamn som inte börjar med tilde (~) eller snedstreck (/).

   Förvalt värde är `build`

2. Absolut sökväg. Om du anger en sökväg som börjar med /, används sökvägen direkt. Till exempel `/tmp/kde-obj-dir/`

3. Relativt till din hemkatalog. Om du anger en sökväg som börjar med ~, används sökvägen relativt till din hemkatalog, på motsvarande sätt som skalets expansion av tilde. Till exempel skulle `~/builddir` ställa in byggkatalogen till `/home/användarnamn/builddir`

Alternativet kan, kanske något oväntat, ändras per modul.

build-when-unchanged

Modulinställning överskrider allmän

Använd alternativet för att bestämma om &kdesrc-build; alltid försöker bygga en modul som inte har några uppdateringar av källkoden.

Genom att ställa in `build-when-unchanged` till true, försöker alltid &kdesrc-build; utföra byggfasen för en modul, även om modulen inte har några uppdateringar av källkoden. Det är standardinställningen, eftersom det är troligare att den leder till en korrekt byggprocess.

Genom att ställa in `build-when-unchanged` till false, försöker &kdesrc-build; bara utföra byggfasen för en modul, om modulen har en uppdateringar av källkoden, eller i andra situationer när det är troligt att det krävs. Det kan spara tid, särskilt om &kdesrc-build; körs dagligen, eller ännu oftare.

Funktionen tillhandahålls enbart som en optimering. Liksom många andra optimeringar, finns det överväganden gällande installationens riktighet. Exempelvis kan ändringar av modulen qt-copy eller kdelibs leda till att andra moduler måste byggas om, även om källkoden inte ändras alls.

checkout-only

Modulinställning överskrider allmän

Sätt det här alternativet för att checka ut källkod från &subversion; del för del. Värdet av alternativet ska vara en lista med kataloger åtskilda med mellanslag att checka ut. Även om alternativet överskrider det allmänna alternativet, var medveten om att ange alternativet som ett allmänt alternativ inte är vettigt.

Observera att inställningen inte har någon effekt för &git;-moduler på grund av sättet som källkodshanteringssystemet &git; fungerar.

Se för ett exempel.

cmake-options

Lägger till i allmänna alternativ (utom för qt-copy)

Använd det här alternativet för att ange vilka flaggor som ska skickas till &cmake; när byggsystemet för modulen skapas. När det används som ett allmänt alternativ, används det för alla moduler som skriptet bygger. När det används som ett modulalternativ, läggs det till i slutet av de allmänna alternativen. Det låter dig ange gemensamma &cmake;-alternativ i den allmänna delen.

Alternativet gäller inte för qt-copy (som inte använder &cmake;). Använd configure-flags istället.

Eftersom alternativen skickas direkt till kommandoraden för &cmake;, ska de anges som de skulle skrivits till &cmake;. Till exempel:

    cmake-options -DCMAKE_BUILD_TYPE=RelWithDebInfo

Eftersom det är krångligt, anstränger sig &kdesrc-build; för att så länge övriga alternativ är rätt inställda, ska du kunna lämna det här alternativet tomt. (Med andra ord, nödvändiga parametrar för &cmake; ställs in automatiskt åt dig.)

colorful-output | Kan inte överskridas | Ställ in alternativet till false för att inaktivera den färgglada utmatningen från &kdesrc-build;. Alternativet har standardvärdet true. Observera att &kdesrc-build; inte matar ut färgkoder till något annat än en terminal (såsom xterm, &konsole; eller den vanliga konsollen i &Linux;).
configure-flags | Modulinställning överskrider allmän | Använd det här alternativet för att ange vilka flaggor som ska skickas till ./configure när byggsystemet för modulen skapas. När det används som ett allmänt alternativ, används det för alla moduler som skriptet bygger. Alternativet fungerar bara för qt-copy. För att ändra konfigurationsinställningar för KDE 4-moduler, se cmake-options.

cxxflags

Lägger till i allmänna alternativ

Använd det här alternativet för att ange vilka flaggor som ska användas för att bygga modulen. Alternativet anges här istället för med configure-flags eller cmake-options eftersom alternativet också sätter miljövariabeln `CXXFLAGS` under byggprocessen.

Observera att för &kde; 4 och alla andra moduler som använder &cmake;, är det nödvändigt att ställa in alternativet CMAKE_BUILD_TYPE option till "none" när modulen konfigureras. Det kan göras med alternativet cmake-options.

dest-dir

Modulinställning överskrider allmän

Använd alternativet för att ändra namnet en modul får på disk. Om modulen till exempel är extragear/network, skulle du kunna ändra det till extragear-network med det här alternativet. Observera att även om detta ändrar modulens namn på disk, är det inte en god idé att låta kataloger eller katalogåtskiljare ingå i namnet, eftersom det kommer i konflikt med eventuella build-dir eller source-dir alternativ.

disable-agent-check

Kan inte överskridas

Om du använder &ssh; för att ladda ner källkod från &subversion; (om du använder protokollet svn+ssh), försöker &kdesrc-build; normalt att försäkra sig om att när du använder ssh-agent, så hanterar det verkligen några &ssh;-identiteter. Det görs för att försöka förhindra att &ssh; frågar efter din lösenordsfras för varje modul. Du kan inaktivera kontrollen genom att sätta `disable-agent-check` till true.

do-not-compile

Modulinställning överskrider allmän

Använd alternativet för att välja en specifik uppsättning kataloger att inte bygga i en modul (istället för alla). Katalogerna att inte bygga ska skiljas åt med mellanslag.

Observera att källkoden till programmen fortfarande laddas ner. Du kan använda direktivet checkout-only för att välja kataloger som du vill checka ut.

För att till exempel vänta med kompilering av &juk; och &kscd; i modulen kdemultimedia, ska du lägga till "do-not-compile juk kscd" i inställningarna för kdemultimedia.

Se för ett exempel.

email-address | Kan inte överskridas | Ställ in alternativet till e-postadressen som &kdesrc-build; ska skicka från om det någonsin behöver skicka e-post. Du behöver inte bekymra dig om det om du inte använder någon funktion som skickar e-post (De är alla normalt inaktiverade). För närvarande behöver bara email-on-compile-error alternativet.

email-on-compile-error

Kan inte överskridas

Du kan ställa in alternativet till e-postadressen dit en rapport ska skickas när en modul misslyckas bygga. &kdesrc-build; väntar till alla moduler är klara och samlar alla resultat i rapporten. Rapporten skickas bara om en modul misslyckas bygga.

Se alternativet email-address för att ställa in adressen som &kdesrc-build; ska skicka från, eftersom förvalt värde oftast inte är vad du vill ha.

inst-apps |  | Väljaren togs bort i version 1.10
install-after-build | Modulinställning överskrider allmän | Alternativet används för att installera paketet efter det har byggts med lyckat resultat. Alternativet är normalt aktiverat. Om du vill inaktivera det, måste du ställa in alternativet till false i inställningsfilen. Du kan också använda kommandoradsväljaren `--no-install`.
kdedir | Modulinställning överskrider allmän | Det här alternativet anger katalogen som &kde; installeras i efter det har byggts. Förvalt värde är `~/kde`. Om du ändrar det till en katalog som kräver åtkomst som systemadministratör, bör du också läsa om alternativet make-install-prefix.

kde-languages

Kan inte överskridas

Alternativet låter dig välja att ladda ner och installera landsinställningspaket tillsammans med &kde;. Du kan göra det om du inte bor i Förenta Staterna och vill ha &kde; översatt till ditt modersmål.

Ställ in alternativet till en lista av språk att installera separerade med mellanslag, för att använda det. Varje språk har en tillhörande språkkod, som du kan slå upp på följande sida: http://i18n.kde.org/teams/.

Det är helt riktigt att bara välja ett språk. Normalt laddas inga ner, vilket betyder att &kde; visas med amerikansk engelska.

Exempelvis, för att välja att installera svenska, skulle du ställa in alternativet till något liknande: ``kde-languages` sv`. Du måste dock ändå använda Systeminställningar för att välja svenska språket.

libpath | Modulinställning överskrider allmän | Ange det här alternativet för att sätta miljövariabeln `LD_LIBRARY_PATH` under byggprocessen. Du kan inte överskrida inställningen med ett modulalternativ. Förvalt värde är tomt, men sökvägarna `$`KDEDIR`/lib` och `$`QTDIR`/lib` läggs automatiskt till. Du kan använda tilde (~) i alla sökvägar du lägger till med alternativet.
log-dir | Modulinställning överskrider allmän | Använd det här alternativet för att ändra katalogen som används för att lagra loggfiler som skapas av skriptet.
make-install-prefix | Modulinställning överskrider allmän | Sätt den här variabeln till en lista åtskilda med mellanslag, som tolkas som ett kommando och dess väljare för att föregå kommandot ``make` `install`` som används för att installera moduler. Det är användbart för att till exempel installera paket med &sudo;, men var försiktig när du hanterar systemadministratörsrättigheter.
make-options | Modulinställning överskrider allmän | Ange den här variabeln för att skicka kommandoradsväljare till kommandot `make`. Det är användbart för program som distcc eller system med mer än en processorkärna.
manual-build | Modulinställning överskrider allmän | Sätt alternativvärdet till true för att förhindra att byggprocessen försöker bygga modulen. Den hålls fortfarande uppdaterad vid uppdatering från &subversion;. Alternativet motsvarar exakt kommandoradsväljaren `--no-build`.
manual-update | Modulinställning överskrider allmän | Sätt alternativvärdet till true för att förhindra att byggprocessen försöker uppdatera (och som en följd, bygga eller installera) modulen. Om du anger alternativet för en modul, är det i stort sett samma som att kommentera bort den.

module-base-path

Modulinställning överskrider allmän

Sätt det här alternativet för att överskrida &kdesrc-build;s förvalda katalogväg till modulen i fråga. Det kan till exempel användas för att hämta specifika grenar eller taggade versioner av bibliotek. &kde;:s källkodsvisning är ovärderlig som hjälp för att välja rätt sökväg.

Observera att &kdesrc-build; konstruerar den slutliga sökvägen enligt följande mall: ``$svn-server`/home/kde/`$module-base-path``.

Förvalt värde är antingen `trunk/`$module`` eller `trunk/KDE/`$module``, beroende på modulnamnet.

Använd alternativen branch eller tag istället så snart de är tillämpliga.

niceness | Kan inte överskridas | Ställ in alternativet till ett tal mellan 20 och 0. Ju högre nummer, desto lägre prioritet ställer &kdesrc-build; in åt sig själv, dvs. ju högre numret är desto "snällare" är programmet. Förvalt värde är 10.
no-svn | Modulinställning överskrider allmän | Om alternativet är sant, uppdaterar inte &kdesrc-build; modulens källkod automatiskt. Det försöker i alla fall bygga modulen om det normalt ändå hade försökt göra det.
no-rebuild-on-fail |  | Väljaren togs bort i version 1.10, eftersom beteendet inte längre hjälper på grund av rättningar av det underliggande byggsystemet.
override-url | Modulinställning överskrider allmän | Om du anger det här alternativet, använder &kdesrc-build; dess värde som webbadress att skicka till &kdesrc-build; helt oförändrad. Du bör i allmänhet använda det om du vill ladda ner en specifik utgåva, men &kdesrc-build; inte kan räkna ut vad du menar genom att använda branch.
prefix | Modulinställning överskrider allmän | Alternativet bestämmer var en modul installeras (normalt används inställningen `kdedir`). Genom att använda alternativet kan du installera en modul i en annan katalog än där KDE:s plattformsbibliotek installeras, om du exempelvis bara använder &kdesrc-build; för att bygga program.

purge-old-logs

Modulinställning överskrider allmän

Alternativet bestämmer om gamla loggkataloger automatiskt tas bort eller inte. Standardvärdet är false.

Även om du inte har ställt in alternativet till true, kan du tömma de gamla loggkatalogerna genom att köra:

`kdesrc-build --no-src --no-build --purge-old-logs kdelibs`

Du kan använda vilket modulnamn som helst på kommandoraden ovan, det måste inte vara kdelibs.

qtdir | Modulinställning överskrider allmän | Sätt alternativet för att använda miljövariabeln `QTDIR` under byggprocessen. Du kan inte överskrida alternativet i ett modulalternativ. Förvalt värde är `$(source-dir)/build/qt-copy`, som använder modulen qt-copy som ingår i &kde;:s källkodsarkiv. Du kan använda tilde (~) för att representera din hemkatalog.

remove-after-install

Modulinställning överskrider allmän

Om du har ont om hårddiskutrymme kan du vilja använda det här alternativet för att automatiskt ta bort byggkatalogen (eller både källkatalogen och byggkatalogen för engångsinstallationer) efter modulen har installerats med lyckat resultat.

Möjliga värden för alternativet är:

- none - Ta inte bort någonting (det är normalvärdet).

- builddir - Ta bort byggkatalogen men inte källkoden.

- all - Ta både bort källkoden och byggkatalogen.

Observera att användning av alternativet kan ha en markant effekt både på användning av bandbredd (om du använder all) och tiden det tar att kompilera &kde;, eftersom &kdesrc-build; inte kommer att kunna utföra inkrementella byggprocesser.

repository | Modulinställning överskrider allmän | Alternativet introducerades i version 1.10, och används för att ange &git;-arkivet för att ladda ner modulens källkod. &Qt; (och därför qt-copy) behöver alternativet, samt diverse &kde;-moduler som håller på att konverteras att använda &git;.
revision | Modulinställning överskrider allmän | Om alternativet ställs in till ett annat värde än 0 (noll), tvingar &kdesrc-build; uppdateringen med &subversion; att ge modulen exakt den version som anges, även om alternativ som branch gäller. Om modulen redan har angiven version, kommer den inte att uppdateras ytterligare om inte alternativet ändras eller tas bort från konfigurationen.
run-tests | Modulinställning överskrider allmän | Om satt till true, byggs modulen med stöd för att köra sin testsvit, och testsviten körs som en del av byggprocessen. &kdesrc-build; visar en enkel rapport med testresultatet. Det är användbar för utvecklare eller de som vill försäkra sig om att systemet är riktigt inställt.

set-env

Modulinställning överskrider allmän

Det här alternativet accepterar en uppsättning värden åtskilda av mellanslag, där det första värdet är miljövariabeln att sätta, och följande värden är vad du vill sätta variabeln till. För att till exempel sätta variabeln `RONALD` till McDonald, skulle du skriva följande kommando under lämplig sektion:

    set-env RONALD McDonald

Alternativet är särskilt på det sätt att det kan upprepas utan att överskrida tidigare inställningar av set-env i samma del av inställningsfilen. På så sätt kan du ställa in mer än en miljövariabel per modul (eller allmänt).

source-dir | Modulinställning överskrider allmän | Det här alternativet används för att ange katalogen på datorn där &kde;:s &subversion;-källkod ska lagras. Om du inte anger värdet, är förvalt värde `~/kdesrc`. Tilde (~) kan utnyttjas för att representera hemkatalogen om alternativet används.
stop-on-failure | Modulinställning överskrider allmän | Ställ in det här alternativvärdet till true för att göra att skriptet slutar köra efter ett fel uppstår i bygg- eller installationsprocessen. Alternativet är normalt av.
svn-server | Modulinställning överskrider allmän | Det här alternativet används för att ange servern som används vid utcheckning från &subversion;. Förval är det anonyma &subversion;-arkivet, svn://anonsvn.kde.org/ Om du utvecklar för KDE, använd &subversion;-arkivet som du tillhandahölls när du erhöll ditt utvecklingskonto, istället för det anonyma arkivet.
tag | Modulinställning överskrider allmän | Använd väljaren för att ladda ner en specifik utgåva av en modul. Observera: Chansen är mycket stor att du inte vill använda alternativet. Utgåvor av &kde; är tillgängliga som komprimerade tar-arkiv från &kde;:s FTP-plats eller en av dess spegelplatser.
use-cmake |  | Väljaren togs bort i &kdesrc-build; 1.4, eftersom alla &kde; 4-moduler kräver &cmake;, och användning av &cmake; inte tillåts för några andra moduler.

use-idle-io-priority

Kan inte överskridas

Det här alternativet, tillagt i &kdesrc-build; 1.12, gör att en lägre prioritet används för disk och annan användning av in- och utmatning, vilket kan förbättra svarsbenägenheten hos resten av systemet signifikant, till kostnad av något längre körtider för &kdesrc-build;. Standardvärdet är att det är inaktiverat. För att aktivera lägre diskprioritet, ställ in det till true.

use-qt-builddir-hack | Modulinställning överskrider allmän | Det här alternativet har tagits bort på grund av förbättringar i &Qt;:s byggsystem.
use-stable-kde |  | Alternativet togs bort i version 1.10, vilken begränsar stöd till KDE 4, och tar bort effekten av det här alternativet.

## Kommandoradsväljare och miljövariabler

### Miljövariabler som stöds

&kdesrc-build; använder inte miljövariabler. Om du behöver sätta miljövariabler för bygg- eller installationsprocessen, se alternativet set.-env.

### Kommandoradsväljare som stöds

Skriptet accepterar följande kommandoradsväljare:

`--async`

  Aktiverar asynkront användningssätt som kan utföra uppdateringar av källkoden och bygga moduler samtidigt. Det är förvalt värde, och väljaren behöver bara anges om du har inaktiverat det i inställningarna.

`--help`

  Visa bara enkel hjälp om skriptet.

`--version`

  Visa programmets version.

`--author`

  Visa upphovsmannens kontaktinformation.

`--color`

  Aktivera färglagd utmatning. (Det är förval för interaktiva terminaler.)

`--nice=värde`

  Värdet justerar datorns processorprioritet som begärs av &kdesrc-build;, och ska vara i intervallet 0-20. 0 är högst prioritet (eftersom det är minst snällt), 20 är lägst prioritet. &kdesrc-build; har förvalt värde 10.

`--no-async`

  Inaktiverar asynkront användningssätt för uppdateringar. Istället utförs hela uppdateringen innan byggningen startas. Väljaren slöar ner totalprocessen, men om du råkar ut för IPC-fel medan du kör &kdesrc-build;, prova den här väljaren, och skicka in en felrapport.

`--no-color`

  Inaktivera färglagd utmatning.

`--pretend` (eller `-p`)

  &kdesrc-build; kör igenom uppdaterings- och byggprocessen, men istället för att utföra några åtgärder för att uppdatera eller bygga, skriver ut vad skriptet skulle ha gjort (t.ex. vilka kommandon att köra, steg att utföra, etc.).

  Observera: Enkla läskommandon (som att läsa information) kan fortfarande utföras, för att göra utmatningen mer relevant (som att simulera om källkod skulle checkas ut eller uppdateras på ett riktigt sätt).

`--quiet` (eller `-q`)

  Var inte så högljudd med utmatningen. Med den här väljaren matas bara det viktigaste ut.

`--really-quiet`

  Mata bara ut varningar och fel.

`--verbose` (eller `-v`)

  Beskriv i detalj vad som händer, och vad &kdesrc-build; gör.

`--src-only` (eller `--svn-only`)

  Utför bara uppdatering av källkod (`--svn-only` stöds bara för kompatibilitet med äldre skript).

`--build-only`

  Utför bara byggprocessen.

`--ignore-modules`

  Inkludera inte moduler som skickas på resten av kommandoraden i uppdaterings- och byggprocessen (det är användbart om du vill bygga de flesta modulerna i inställningsfilen och bara hoppa över några få).

`--no-src` (eller `--no-svn`)

  Hoppa över att kontakta &subversion;-servern (väljaren `--no-svn` stöds bara för kompatibilitet med äldre versioner av skriptet).

`--no-build`

  Hoppa över byggprocessen.

`--no-install`

  Installera inte automatiskt paket efter de har byggts.

`--no-build-when-unchanged`
`--force-build`

  Det här alternativet inaktiverar explicit att hoppa över byggprocessen (en optimering styrd av alternativet build-when-unchanged). Det är användbart för att få &kdesrc-build; att utföra byggprocessen när någonting har ändrats som &kdesrc-build; inte kan kontrollera.

  `--force-build` utför exakt samma funktion, och är kanske enklare att komma ihåg.

`--debug`

  Aktiverar felsökningsläge för skriptet. För närvarande betyder det att all utmatning skickas till standardutmatningen förutom att loggas i loggkatalogen som vanligt. Dessutom är många funktioner mycket utförligare om vad de gör i felsökningsläge.

`--no-rebuild-on-fail`

  Försök inte att bygga om moduler som har misslyckats att byggas från början. &kdesrc-build; försöker aldrig göra detta med en modul där ett försök att bygga från början redan har gjorts.

`--refresh-build`

  Skapa om byggsystemet och bygg från grunden.

`--reconfigure`

  Kör `cmake` (för &kde;-moduler) eller `configure` (för &Qt;) igen, utan att rensa byggkatalogen. Du ska normalt inte behöva ange detta, eftersom &kdesrc-build; detekterar när relevanta alternativ ändras och automatiskt kör om bygginställningen. Väljaren är implicit om `--refresh-build` används.

`--resume-from`

  Alternativet är användbart för att återuppta byggprocessen från den angivna modulen, som ska vara nästa alternativ på kommandoraden. Alternativet inbegriper `--no-src`. Du ska inte ange andra modulnamn på kommandoraden.

  Se också: och . Du bör föredra att använda den här kommandoradsväljaren om du har rättat byggfelet och vill att &kdesrc-build; ska göra färdigt byggprocessen.

`--resume-after`

  Alternativet är användbart för att återuppta byggprocessen efter den angivna modulen, som ska vara nästa alternativ på kommandoraden. Alternativet inbegriper `--no-src`. Du ska inte ange andra modulnamn på kommandoraden.

  Se också: och . Du bör föredra att använda den här kommandoradsväljaren om du har rättat byggfelet och har också byggt och installerat modulen själv, och vill att &kdesrc-build; ska starta igen med nästa modul.

`--rc-file`

  Det tolkar nästa kommandoradsväljare som filen att läsa konfigurationsinställningarna från. Förvalt värde för väljaren är `kdesrc-buildrc` (kontrolleras i arbetskatalogen) om den finns, eller annars `~/.kdesrc-buildrc`. Se också .

`--run`

  Alternativet tolkar nästa parameter på kommandoraden som ett program att köra, och &kdesrc-build; slutar då att läsa inställningsfilen, uppdaterar miljön som vanligt, och kör därefter angivet program.

  Det fungerar dock inte för att starta ett skal med miljön från &kdesrc-build; i de flesta fall, eftersom interaktiva skal typiskt återställer åtminstone vissa av miljövariablerna (som `PATH` och `KDEDIRS`) under startsekvensen.

  Om du vill se miljön som används av &kdesrc-build; kan du köra kommandot `printenv`:

      $ kdesrc-build --run printenv
      KDE_SESSION_VERSION=4
      SDL_AUDIODRIVER=alsa
      LANGUAGE=
      XCURSOR_THEME=Oxygen_Blue
      LESS=-R -M --shift 5
      QMAIL_CONTROLDIR=/var/qmail/control
      ... etc.

`--prefix=</sökväg/till/kde>`

  Det här låter dig ändra katalogen som &kde; installeras i från kommandoraden. Alternativet inbegriper `--reconfigure`, men det kan ändå krävas att `--refresh-build` används.

`--revision`

  Väljaren gör att &kdesrc-build; checkar ut en särskilt numrerad version av varje &subversion;-modul, och överskrider eventuella alternativ som branch, tag eller revision redan är angivna för modulerna.

  Väljaren är troligen inte en god idé, och stöds bara för kompatibilitet med äldre skript.

`--build-system-only`

  Väljaren gör att &kdesrc-build; avbryter bygga en modul precis innan kommandot `make` skulle ha körts. Det stöds bara för kompatibilitet med äldre versioner, effekten är inte till hjälp för det nuvarande byggsystemet för &kde;.

`--install`

  Om detta är den enda kommandoradsväljaren, försöker det installera alla moduler som finns i `log/latest/build-status`. Om kommandoradsväljare anges efter `--install`, antas de alla vara moduler att installera (även om de inte byggdes med lyckat resultat vid den senaste körningen).

`--purge-old-logs`

  Alternativet gör att &kdesrc-build; tar bort loggkataloger som inte behövs efter byggprocessen, för att spara diskutrymme. Alla loggkataloger som inte behövs för att uppfylla en länk från `log/latest` kommer att tas bort. Det är normalt inaktiverat. För att aktivera väljaren i normalfall, se alternativet purge-old-logs.

`--no-snapshots`

  Att ange den här väljaren gör att &kdesrc-build; alltid föredrar en ursprunglig utcheckning av en modul från &subversion;, istället för att använda en sparad version av modulen i &subversion;.

  Sparade versioner av modulen är riktiga utcheckningar från &subversion;. Du ska inte behöva ange den här väljaren, den är bara till hjälp vid felsökning.

`--<option-name>=`

  Du kan använda alternativet för att överskrida ett alternativ i inställningsfilen för alla moduler. För att till exempel överskrida alternativet log-dir, skulle du skriva ``--log-dir=`/sökväg/till/katalog```.

`--<modulnamn>,<alternativnamn>=`

  Du kan använda alternativet för att överskrida ett alternativ i inställningsfilen för en specifik modul.

Alla övriga kommandoradsväljare antas vara moduler att uppdatera och bygga. Blanda helst inte ihop bygga och installera.

## Använda &kdesrc-build;

### Förord

Efter du har gått igenom , är det normalt så enkelt att använda &kdesrc-build; som att skriva följande från en terminal:

    &percnt; kdesrc-build

&kdesrc-build; laddar därefter ner &kde;:s källkod, försöker att konfigurera och bygga den, och därefter installera den.

Läs vidare för att upptäcka hur &kdesrc-build; gör detta, och vad du mer kan göra med verktyget.

### Grundläggande funktioner i &kdesrc-build;

#### stöd för qt-copy

&kdesrc-build; stöder att bygga &Qt;-verktygslådan som används an &kde;-programvara som en bekvämlighet för användaren. Stödet hanteras av en särskild modul som kallas qt-copy.

&Qt; utvecklas i ett separat arkiv från &kde;-programvara, lokaliserat på http://qt.gitorious.org/qt.

För att bygga &Qt; måste du försäkra dig om att inställningen qtdir pekar på katalogen där du vill att &Qt; ska installeras, som beskrivs i .

Därefter måste du försäkra dig om att modulen qt-copy läggs till i `kdesrc-buildrc`, innan några andra moduler i filen. Om du använder exemplet på inställningsfil, kan du helt enkelt ta bort kommentarerna från den befintliga posten för modulen qt-copy.

Nu bör du kontrollera att alternativet repository och alternativen branch är lämpligt inställda:

1. Det första alternativet är att bygga med en grupp rekommenderade programfixar med felrättningar och optimeringar (det bestämdes förut av alternativet som kallades apply-patches). Samlingen utvecklas i ett separat arkiv på http://gitorious.org/+kde-developers/qt/kde-qt. Om du vill bygga med programfixarna (de flesta &kde;-utvecklare gör det), måste du ställa in arkivalternativet till `git://gitorious.org/+kde-developers/qt/kde-qt.git`.

2. Annars, för att bygga standard-&Qt;, ställ in arkivalternativet till `git://gitorious.org/qt/qt.git`.

I båda fall ska alternativet branch ställas in till `master` (om du inte vill bygga en annan gren).

I vissa fall kan inte den underliggande programvaran för källkodshantering fungera när den körs från &kdesrc-build;, men fungerar ändå bra när den körs från kommandoraden. Felet håller fortfarande på att undersökas.

#### Standardflaggor tillagda av &kdesrc-build;

För att spara tid, lägger &kdesrc-build; till några standardsökvägar i miljön åt dig:

- Sökvägen till &kde;- och &Qt;-biblioteken läggs till i variabeln `LD_LIBRARY_PATH` automatiskt. Det betyder att du inte behöver redigera &libpath; för att inkludera dem.

- Sökvägen till program för utvecklingsstöd i &kde; och &Qt; läggs till i variabeln `PATH` automatiskt. Det betyder att du inte behöver redigera &binpath; för att inkludera dem.

- Sökvägen till pkg-config som tillhandahålls av &kde; läggs till i variabeln `PKG_CONFIG_PATH` automatiskt. Det betyder att du inte behöver använda &set-env; för att lägga till dem.

- Inställningen av &kdedir; skickas automatiskt vidare till miljövariabeln `KDEDIR` under byggprocessen. (`KDEDIRS` påverkas inte).

- Inställningen av &qtdir; skickas automatiskt vidare till miljövariabeln `QTDIR` under byggprocessen.

#### Ändra byggprioritet i &kdesrc-build;

Program kan köra med olika prioritetsnivåer på operativsystem, inklusive &Linux; och &BSD;. Det tillåter systemet att tilldela tid för de olika programmen enligt hur viktiga de är.

&kdesrc-build; tilldelar normalt sig själv låg prioritet så att resten av programmen på systemet är opåverkade och kan köra normalt. Genom att använda den här tekniken, använder &kdesrc-build; extra processorkraft när den är tillgänglig.

&kdesrc-build; behåller fortfarande prioritetsnivån nog hög så att det kör innan rutinmässiga bakgrundsprocesser och innan program som donerar processorkraft såsom Seti@Home.

För att ändra &kdesrc-build; så att det använder en högre (eller lägre) prioritetsnivå permanent, måste du justera inställningen av &niceness; i inställningsfilen. Alternativet &niceness; styr hur snällt &kdesrc-build; är mot andra program. Med andra ord, att ha en högre &niceness; ger &kdesrc-build; lägre prioritet. Så för att ge &kdesrc-build; en högre prioritet, reducera &niceness; (och tvärtom). &niceness; kan gå från 0 (inte alls snällt, högsta prioritet) till 20 (supersnällt, lägsta prioritet).

Du kan också tillfälligt ändra prioritet hos &kdesrc-build; genom att använda kommandoradsväljaren &cmd-nice;. Väljarens värde är exakt samma som för &niceness;.

Det är möjligt för vissa program som körs av systemadministratören att ha ett negativt snällhetsvärde, vilket motsvarar ännu högre prioritet för sådana program. Att ange en negativ &niceness; (eller till och med 0) för &kdesrc-build; är inte en god idé, eftersom det inte förbättrar körtiden nämnvärt, men gör att datorn verkar mycket slö om du ändå behöver använda den.

För att köra &kdesrc-build; med snällhetsgrad 15 (en lägre prioritet än normal) skriv:

    &percnt; kdesrc-build --nice=15

Eller kan du redigera inställningsfilen för att göra ändringen permanent:

    &niceness; 15

Alternativet niceness påverkar bara användning av datorns processor(er). En annan stor effekt på datorns prestanda har att göra med hur mycket in- och utmatning av data (I/O) som ett program använder. För att bestämma hur mycket I/O ett program kan använda, stöder moderna &Linux;-operativsystem ett liknande verktyg som kallas ionice. &kdesrc-build; stöder ionice (men bara för att aktivera eller inaktivera det helt och hållet), med alternativet use-idle-io-priority, sedan &kdesrc-build; version 1.12.

#### Installera som systemadministratör

Du kanske också vill att &kdesrc-build; ska köra installationen med rättigheter som systemadministratör. Det kan gälla för systeminstallation, som inte rekommenderas. Det är dock också användbart när den rekommenderade installationen som enanvändare av &kde; används. Det beror på att vissa moduler (i synnerhet kdebase) installerar program som tillfälligt behöver förhöjda rättigheter när de kör. De kan inte uppnå dessa rättighetsnivåer om de inte installeras med förhöjda rättigheter.

Du skulle helt enkelt kunna köra &kdesrc-build; som systemadministratör direkt, men det rekommenderas inte, eftersom programmet inte har granskats för den sortens användning. Även om det bör vara säkert att köra programmet på det sättet, är det bättre att undvika att köra som systemadministratör när det är möjligt.

För att hantera detta, tillhandahåller &kdesrc-build; alternativet &make-install-prefix;. Du kan använda alternativet för att ange ett kommando som används för att utföra installationen som en annan användare. Det rekommenderade sättet att använda kommandot är med programmet &sudo;, som kör installationskommandot som systemadministratör.

För att till exempel installera alla moduler genom att använda &sudo;, skulle du kunna göra något liknande:

    global
      &make-install-prefix; sudo
      # Övriga alternativ
    end global

För att använda &make-install-prefix; för bara en enda modul, skulle det här fungera:

    module kdemultimedia
      &make-install-prefix; sudo
    end module

#### Visa förloppet för en byggprocess av en modul

Funktionen är alltid tillgänglig, och automatiskt aktiverad om möjligt. Vad den gör är att visa ett uppskattat byggförlopp medan en modul byggs, på så sätt vet du hur mycket längre det kommer att ta att bygga en modul.

### Avancerade funktioner

#### Delvis bygga en modul

Det är möjligt att bara bygga delar av en enda &kde;-modul. Du kanske till exempel bara vill kompilera ett program från en modul. &kdesrc-build; har funktioner som gör det enkelt. Det finns flera komplementära sätt att göra det.

##### Checka ut delar av en modul

Det här är troligen det bästa sättet att göra det. När det fungerar sparar det dig nerladdningstid och diskutrymme. Vad som händer är att &kdesrc-build; bara laddar ner delar av modulen som du anger. Det görs med alternativet &checkout-only; för modulen, som anger en lista med kataloger att ladda ner.

Om du inte redan vet vad som ska laddas ner för en modul, kan det vara en god idé att först bläddra i &subversion;-strukturen för en modul, genom att använda WebSVN.

För att bara hämta &kuser; och KSystemLog från kdeadmin, skulle du kunna använda &checkout-only; så här:

    module kdeadmin
      &checkout-only; kuser ksystemlog
    end module

Katalogerna byggs i ordningen de listas i alternativet. Om en av katalogerna behöver någonting annat från modulen för att kunna kompileras, då måste du försäkra dig om att de båda finns med på raden &checkout-only;, och att beroendet som krävs anges före katalogen som behöver det.

Ibland kan ett program också behöva andra kataloger och det är svårt att räkna ut vilka de är, vilket kan kräva ett antal försök med ständiga tillägg av kataloger till alternativet för att räkna ut. Alternativet beror på stöd från modulens byggsystem, så den är bara användbar för moduler som är samlingar av individuella program.

En sista anmärkning om alternativet: Om du ändrar alternativets värde ska du använda ``kdesrc-build` `&cmd-refresh-build;` `modul`` för att försäkra dig om att modulen konfigureras om på ett riktigt sätt. &kdesrc-build; tar aldrig bort befintliga filer om du tar bort ett antal kataloger från alternativet &checkout-only;, eller lägger till alternativet för en modul som redan har checkats ut.

##### Ta bort kataloger från en byggplats

Istället för att begränsa vad som laddas ner, är det möjligt att ladda ner allt men låta byggsystemet utelämna ett antal kataloger när byggprocessen utförs. Det kan vara användbart om en katalog hela tiden ger fel och är onödig för resten av modulen.

Det styrs med alternativet &do-not-compile;. Det fungerar på liknande sätt som &checkout-only; som just beskrivits, på så sätt att det helt enkelt är en lista med kataloger som inte ska kompileras.

Också precis som &checkout-only; kräver alternativet minst att byggsystemet för modulen konfigureras om efter det har ändrats. Det görs med kommandot ``kdesrc-build` `&cmd-reconfigure;` `modul``.

För att ta bort katalogen `python` från byggprocessen för kdebindings:

    module kdebindings
      &do-not-compile; python
    end module

Funktionen beror på vissa standardkonventioner som används i de flesta moduler i &kde;. Därför kanske den inte fungerar för alla program.

#### Stöd för grenar och taggar i &kdesrc-build;

##### Vad är grenar och taggar?

&subversion; stöder hantering av historik för &kde;:s källkod. &kde; använder stödet för att skapa grenar för utveckling, och att ge arkivet en tagg då och då med utgåvan av en ny version.

Till exempel kan utvecklarna av &kmail; arbeta med en ny funktion i en annan gren för att undvika att förstöra versionen som används av de flesta utvecklare. Grenen har pågående utveckling, samtidigt som huvudgrenen (som kallas /trunk) kan ha pågående utveckling.

En tagg är å andra sidan en ögonblicksbild av källkodsarkivet vid en viss tid. Det används av &kde;:s administrationsgrupp för att markera en version av koden som är lämplig för en utgåva och fortfarande tillåta att utvecklare arbetar med koden.

Det finns ingen skillnad i koden mellan grenar, taggar eller huvudgrenen i &subversion;. Det är bara en konvention som används av utvecklarna. Det gör det svårt att stödja grenar och taggar i &kdesrc-build; på ett riktigt sätt. Det finns dock några saker som kan göras.

##### Hur man använder grenar och taggar

Stöd för grenar och taggar hanteras med en uppsättning alternativ, som rör sig från en generell begäran om en version, till en specifik webbadress att ladda ner för avancerade användare.

Det enklaste sättet är att använda alternativen &branch; och &tag;. Du använder helt enkelt alternativet tillsammans med namnet på den önskade grenen eller taggen för en modul, så försöker &kdesrc-build; avgöra lämplig plats i &kde;:s arkiv att ladda ner från. För de flesta moduler i &kde; fungerar det mycket bra.

För att ladda ner kdelibs från &kde; 4.5 (som helt enkelt är känt som grenen 4.5):

    module kdelibs
      branch 4.5
      # övriga alternativ...
    end module

Eller, för att ladda ner kdemultimedia som det var när det gavs ut med &kde; 4.5.1:

    module kdemultimedia
      tag 4.5.1
      # övriga alternativ...
    end module

Du kan ställa in ett allmänt grenvärde, men om du gör det, glöm inte att ange en annan gren för moduler som inte ska använda den allmänna grenen.

##### Stöd för avancerade grenalternativ

&kdesrc-build; stöder två alternativ i situationer då &branch; och &tag; gissar fel angående den riktiga sökvägen: &module-base-path; och &override-url;.

- Alternativet &module-base-path; används för att hjälpa &kdesrc-build; fylla i saknade delar av modulens sökväg. I &kde;:s arkiv är alla sökvägar av formen `svnRoot/module-base-path/modulnamn`. Normalt kan &kdesrc-build; räkna ut den lämpliga delen i mitten själv. När det inte går, kan du använda &module-base-path; så här:

      module kdesupport
          # kdesupport stöder diverse taggar för att enkelt organisera
          # programvaran för en given utgåva av KDE-plattformen.
          module-base-path tags/kdesupport-for-4.5
      end module

  Det skulle göra att &kdesrc-build; laddar ner kdesupport från (i det här exemplet) `svn://anonsvn.kde.org/home/kde/tags/kdesupport-for-4.5`.

  I tidigare versioner av &kdesrc-build;, hanterades &module-base-path; annorlunda. Om du stöter på problem vid användning av en gammal definition av module-base-path, bör du nog verifiera att den verkliga sökvägen är den som &kdesrc-build; förväntar sig genom att använda väljaren --pretend.

- Alternativet &override-url; kräver å andra sidan att du anger den exakta sökvägen att ladda ner från. Det låter dig dock hämta från sökvägar som &kdesrc-build; inte skulle ha någon möjlighet att ladda ner från. För närvarande bör alternativet &module-base-path; vara tillräckligt för alla webbadresser för Subversion källkod.

  &kdesrc-build; rör inte eller korrigerar något värde som du anger för &override-url; överhuvudtaget, så om du byter inställningen &svn-server;, kan du också behöva uppdatera det här.

#### Hur &kdesrc-build; försöker försäkra sig om en lyckad byggprocess

##### Automatisk ombyggnad

&kdesrc-build; innehöll tidigare funktioner för att automatiskt försöka bygga om modulen efter ett fel (eftersom ibland fungerade försöket att göra om, på grund av fel i byggsystemet vid den tiden). Tack vare bytet till &cmake; lider inte byggsystemet längre av dessa fel, och därför försöker inte &kdesrc-build; bygga en modul mer än en gång. Det finns dock situationer då &kdesrc-build; automatiskt utför åtgärder.

- Om du ändrar configure-flags eller cmake-options för en modul, detekterar &kdesrc-build; det och kör automatiskt om configure eller cmake för modulen.

- Om byggsystemet inte finns (även om &kdesrc-build; inte tog bort det) skapar &kdesrc-build; automatiskt om det. Det är användbart för att ge möjligheten att utföra en fullständig --refresh-build för en specifik modul utan att den utförs för andra moduler.

##### Bygga om en modul manuellt

Om du gör en ändring i en moduls inställningsalternativ, eller om modulens källkod ändras på ett sätt som &kdesrc-build; inte känner igen, kan du behöva bygga om modulen manuellt.

Du kan göra det genom att helt enkelt köra ``kdesrc-build` `--refresh-build` `modul``.

Om du skulle vilja att &kdesrc-build; istället automatiskt bygger om modulen under nästa normala bygguppdatering, kan du skapa en särskild fil. Varje modul har en byggkatalog. Om du skapar en fil som heter `.refresh-me` i en moduls byggkatalog, bygger &kdesrc-build; om modulen nästa gång byggprocessen sker, även om det normalt skulle utföra den snabbare inkrementella byggprocessen.

Normalt är byggkatalogen `~/kdesrc/build/modul/`. Om du ändrar inställning av alternativet &build-dir;, använd den istället för `~/kdesrc/build`.

Bygg om med `.refresh-me` för modulen kdelibs:

    % touch ~/kdesrc/build/kdelibs.refresh-me
    % kdesrc-build

#### Ändra inställning av miljövariabler

Normalt använder &kdesrc-build; miljön som är närvarande vid start när program körs för att utföra uppdateringar och bygga. Det är användbart när du kör &kdesrc-build; från kommandoraden.

Dock kan du vilja ändra inställning av miljövariabler som &kdesrc-build; inte direkt tillhandahåller ett alternativ för. (För att exempelvis ställa in eventuella miljövariabler som behövs när &kdesrc-build; körs i bakgrunden via &cron;.) Det är möjligt med alternativet &set-env;.

I motsats till de flesta alternativ kan det anges flera gånger, och accepterar två värden, åtskilda med mellanslag. Det första är namnet på miljövariabeln som ska sättas, och resten av raden är dess värde.

Ställ in ``DISTRO`=BSD` för alla moduler:

    global
      set-env DISTRO BSD
    end global

#### Återuppta byggprocesser

##### Återuppta en misslyckad eller avbruten byggprocess

Du kan tala om för &kdesrc-build; att börja bygga från en annan modul än det normalt skulle göra. Det kan vara användbart när en uppsättning moduler misslyckades, eller om du avbröt en körning i mitten. Du kan styra det med väljarna &cmd-resume-from; och &cmd-resume-after;.

Genom att använda någon av väljarna för att återuppta, hoppas uppdatering av källkod över.

Återuppta byggprocessen med början på kdebase:

    % kdesrc-build --resume-from=kdebase

Återuppta byggprocessen med början efter kdebase (i fallet du fixade problemet för hand och installerade modulen själv):

    % kdesrc-build --resume-after=kdebase

##### Ignorera moduler i en byggprocess

På samma sätt som du kan återuppta byggprocessen från en modul, kan du istället välja att uppdatera och bygga normalt, men ignorera en uppsättning moduler.

Du kan göra det med väljaren &cmd-ignore-modules;. Den talar om för &kdesrc-build; att ignorera alla följande moduler på kommandoraden när en uppdatering och byggprocess utförs.

Ignorera extragear/multimedia och kdereview under en fullständig körning:

    % kdesrc-build --ignore-modules extragear/multimedia kdereview

#### Ändra alternativ från kommandoraden

##### Ändra allmänna alternativ

Du kan ändra uppsättningen alternativ som läses från inställningsfilen direkt från kommandoraden. Ändringen överskrider inställningen i filen, men är bara tillfällig. Den gäller bara så länge den fortfarande är närvarande på kommandoraden.

&kdesrc-build; låter dig ändra alternativ namngivna som alternativnamn genom att ange en väljare på kommandoraden på formen ``--alternativnamn=värde``. &kdesrc-build; känner igen om det inte vet vad alternativet är, ock söker efter namnet i sin lista med alternativnamn. Om det inte känner igen namnet, får du en varning, annars kommer det ihåg värdet du ställde in det till och överskrider en eventuell inställning från filen.

Ställa in alternativet &source-dir; till `/dev/null` för test:

    % kdesrc-build --pretend --källkodskatalog=/dev/null

##### Ändra modulalternativ

Det är också möjligt att bara ändra alternativ för en viss modul. Syntaxen är liknande: --modul,alternativnamn=värde.

Ändringen överskrider eventuell duplicerad inställning för modulen som hittas i inställningsfilen, och gäller bara när alternativet skickas med på kommandoraden.

Använda en annan byggkatalog för modulen kdeedu:

    % kdesrc-build --kdeedu,byggkatalog=temporärbygg

### Funktioner för &kde;-utvecklare

#### Kontroll av &ssh;-agent

&kdesrc-build; kan försäkra sig om att &kde;-utvecklare som använder &ssh; för att komma åt &kde;:s källkodsarkiv inte av misstag glömmer att lämna verktyget &ssh;-agenten aktiverad. Det kan orsaka att &kdesrc-build; hänger sig för alltid medan det väntar på att utvecklaren ska skriva in lösenordet till &ssh;, så normalt kontrollerar &kdesrc-build; att agenten kör innan det utför uppdateringar av källkoden.

Det görs bara för &kde;-utvecklare som använder &ssh;. Det beror på att inget lösenord krävs för den vanliga anonyma utcheckningen. &subversion; hanterar lösenord för det andra möjliga protokollet för &kde;-utvecklare, https.

Du kanske vill inaktivera kontrollen av &ssh;-agenten, i situationer där &kdesrc-build; detektera närvaron av en agent av misstag. För att inaktivera kontroll av agenten, sätt alternativet `disable-agent-check` till true.

Inaktivera &ssh;-agentkontroll:

    global
      disable-agent-check true
    end global

### Andra funktioner i &kdesrc-build;

#### Ändra mängden utmatning från &kdesrc-build;

&kdesrc-build; har flera väljare för att styra mängden utmatning som skriptet skapar. Hur som helst, kommer fel alltid att matas ut.

- Väljaren `--quiet` (den korta formen är `-q`) gör att &kdesrc-build; i huvudsak är tyst. Bara viktiga meddelanden, varningar eller fel visas. Om tillgängligt visas fortfarande förloppsinformation för byggprocessen.

- Väljaren `--really-quiet` (ingen kortform) gör att &kdesrc-build; bara visar viktiga varningar eller fel när det kör.

- Väljaren `--verbose` (kortformen är `-v`) gör att &kdesrc-build; är mycket detaljerad i utmatningen.

- Väljaren `--debug` är bara till för felsökningssyfte. Den gör att &kdesrc-build; beter sig som om `--verbose` är aktiverad, gör också att kommandon matas ut på terminalen, och visar felsökningsinformation för många funktioner.

#### Färgutmatning

När &kdesrc-build; körs från &konsole; eller en annan terminal, visas normalt färglagd text.

Du kan inaktivera det genom att använda väljaren `--no-color` på kommandoraden, eller ställa in alternativet &colorful-output; i inställningsfilen till false.

Inaktivera färgutmatning i inställningsfilen:

    global
      colorful-output false
    end global

#### Skicka e-post med rapporter om en misslyckad byggprocess

&kdesrc-build; kan skicka en rapport via e-post till en e-postadress du väljer, när en modul misslyckas att bygga av någon orsak. Sättet det fungerar är att du väljer en e-postadress som &kdesrc-build; skickar från, och en e-postadress att underrätta när ett fel uppstår.

&kdesrc-build; skapar då ett brev om det fanns någon modul som misslyckades bygga, i slutet av en fullständig körning. Brevet kommer att innehålla en förkortad fellogg för varje modul. Bara ett brev skickas för varje körning, även om 15 moduler misslyckades byggas.

Funktionen är inte normalt aktiverad. För att aktivera den, måste du ange båda alternativen &email-address; och &email-on-compile-error;. Alternativet `email-address` styr adressen som &kdesrc-build; skickar från, och `email-on-compile-error` styr vart brevet ska skickas.

&kdesrc-build; använder standardmodulen Mail::Mailer i Perl för att skicka e-post. Den ingår i Perl 5.8, och kan installeras med Perl 5.6. Mail::Mailer stöder Sendmail (inklusive e-postprogram som fungerar med Sendmail), inbyggd överföring med SMTP, och qmail.

Skicka e-post från bygg@exempel.se till resultat@exempel.se vid byggfel:

    global
      email-address          bygg@exempel.se    # Från: adress för all kdesrc-build e-post
      email-on-compile-error resultat@exempel.se    # Till: adress för e-post om misslyckad bygg
    end global

#### Ta bort onödiga kataloger efter en byggprocess

Har du ont om diskutrymme men vill ändå köra de allra senaste utcheckningen av &kde;? &kdesrc-build; kan hjälpa dig att reducera diskanvändning medan du bygger &kde; från &subversion;.

Var medveten om att det går åt mycket utrymme för att bygga &kde;. Det finns flera stora delar som använder utrymme när &kdesrc-build; används:

1. Själva utcheckningen av källkoden kan uppta ett försvarligt utrymme. Standardmodulerna upptar ungefär 1.6 Gibyte diskutrymme. Du kan reducera storleken genom att försäkra dig om att du bara bygger så många moduler som du verkligen vill ha. &kdesrc-build; tar inte bort källkod från disken även om du tar bort posten från inställningsfilen, så försäkra dig om att du går till och tar bort oanvända utcheckningar i källkodskatalogen. Observera att källkodsfilerna laddas ner från Internet, och du ska inte ta bort dem om du faktiskt använder dem, åtminstone till du är klar med användning av &kdesrc-build;.

   Om du dessutom har installerat &Qt; från distributionen (och chansen är stor att du har det), behöver du troligen inte installera modulen qt-copy. Det hyvlar av omkring 200 Mibyte från källkodsstorleken på disk.

   En sak att observera är att på grund av sättet som &subversion; fungerar, finns det i själva verket två filer på disk för varje fil som checkas ut från arkivet. &kdesrc-build; har för närvarande inte kod för att försöka minimera källkodsstorleken när källkoden inte används.

2. &kdesrc-build; skapar en separat byggkatalog för att bygga källkoden. Ibland måste &kdesrc-build; kopiera en källkodskatalog för att skapa en falsk byggkatalog. När det sker, används platsbesparande symboliska länkar, så det bör inte vara något krångel med diskutrymme. Byggkatalogen är typiskt mycket större än en moduls källkodskatalog. Byggkatalogen för kdebase är till exempel omkring 1050 Mibyte, medan källkoden för kdebase bara är omkring 550 Mibyte.

   Som tur är krävs inte byggkatalogen efter en modul har byggts och installerats med lyckat resultat. &kdesrc-build; kan automatiskt ta bort byggkatalogen efter en modul har installerats. Se exemplen nedan för mer information. Observera att genom att utföra detta steg, blir det omöjligt för &kdesrc-build; att utföra tidsbesparande inkrementella byggprocesser.

3. Till sist krävs diskutrymme för själva installationen av &kde;, som inte körs från byggkatalogen. Det upptar typiskt mindre utrymme än byggkatalogen. Det är dock svårare att få fram exakta siffror.

Hur reducerar man utrymmeskraven för &kde;? Ett sätt är att använda riktiga kompilatorflaggor för att optimera för reducering av utrymme istället för hastighet. Ett annat sätt, som kan ha stor effekt, är att ta bort felsökningsinformation från det färdigbyggda &kde;.

Du bör vara mycket säker på att du vet vad du gör innan du bestämmer dig för att ta bort felsökningsinformation. Att köra den allra senaste programvaran betyder att du kör programvara som potentiellt har mycket större sannolikhet att krascha än stabila utgåvor. Om du kör programvara utan felsökningsinformation kan det vara mycket svårt att skapa en bra felrapport för att få problemet löst, och du måste troligen aktivera felsökning igen för programmet som påverkas och bygga om för att hjälpa en utvecklare att rätta kraschen. Så ta bort felsökningsinformation på egen risk!

Ta bort byggkatalogen efter en modul har installerats. Källkoden behålls fortfarande, och felsökning är aktiverad:

    global
      configure-flags      --enable-debug
      remove-after-install builddir        # Ta bort byggkatalog efter installation
    end global

Ta bort byggkatalogen efter installation, utan felsökningsinformation, med storleksoptimering.

    global
      cxxflags             -Os             # Optimera för storlek
      configure-flags      --disable-debug
      remove-after-install builddir        # Ta bort byggkatalog efter installation
    end global

## &cmake;, byggsystemet för &kde; 4

### Introduktion till &cmake;

Under mars 2006, slog programmet &cmake; ut flera konkurrenter och valdes som byggsystem för &kde; 4, och ersätter systemet baserat på autotools som &kde; har använt från början.

En sida med en introduktion till &cmake; är tillgänglig på &kde; TechBase. Istället för att köra ``make` `-f` `Makefile.cvs``, därefter `configure` och sedan &make;, kör vi helt enkelt &cmake; och därefter &make;.

&kdesrc-build; har initialt stöd för &cmake;. Några funktioner i &kdesrc-build; var i själva verket funktioner i det underliggande byggsystemet, inklusive configure-flags och do-not-compile. När motsvarande funktioner är tillgängliga, tillhandahålls de. Motsvarigheten till alternativet configure-flags är till exempel cmake-options, och alternativet do-not-compile stöds också för &cmake; från och med &kdesrc-build; version 1.6.3.

## Tack till och licenser

Översättning Stefan Asserhäll stefan.asserhall@comhem.se

&underFDL;