<?xml version="1.0" ?>
<!DOCTYPE book PUBLIC "-//KDE//DTD DocBook XML V4.5-Based Variant V1.1//EN" "dtd/kdedbx45.dtd" [
  <!--
    Documentation for kdesrc-build.
    Copyright (c) 2005-2008, 2010-2022 Michael Pyne <mpyne@kde.org>

    Copyright (c) 2005 Carlos Leonhard Woelz <carloswoelz@imap-mail.com>
    Copyright (c) 2009 Burkhard Lück <lueck@hube-lueck.de>
    Copyright (c) 2007, 2011 Federico Zenith <federico.zenith@members.fsf.org>
    Copyright (c) 2009-2011 Yuri Chornoivan <yurchor@ukr.net>
    ... and possibly others. Check the git source repository for specifics.

    Permission is granted to copy, distribute and/or modify this document under
    the terms of the GNU Free Documentation License, Version 1.2 or any later
    version published by the Free Software Foundation; with no Invariant
    Sections, no Front-Cover Texts, and no Back-Cover Texts.

    A copy of the license is included in COPYING.DOC. The license will be
    included in the generated documentation as well.
   -->
  <!ENTITY kappname "kdesrc-build">
  <!ENTITY package "kdesdk">
  <!ENTITY % addindex "IGNORE">
  <!ENTITY % Swedish "INCLUDE"
> <!-- Change language only here -->
  <!ENTITY kdesrc-build "<application
>kdesrc-build</application
>">
  <!ENTITY BSD '<acronym
>BSD</acronym
>'>
  <!ENTITY git '<application
>Git</application
>'>
  <!ENTITY cmake '<application
>CMake</application
>'>
  <!ENTITY make '<application
>Make</application
>'>
  <!ENTITY ninja '<application
>Ninja</application
>'>
  <!ENTITY ssh '<application
>SSH</application
>'>
  <!ENTITY cron '<application
>Cron</application
>'>
  <!ENTITY sudo '<application
>Sudo</application
>'>
  <!ENTITY url '<acronym
>URL</acronym
>'>

  <!-- These define shortcut entities for some of the configuration options.
       Just add them as necessary.
  -->

  <!ENTITY configure-flags '<link linkend="conf-configure-flags"
>configure-flags</link
>'>
  <!ENTITY kdedir '<link linkend="conf-kdedir"
>kdedir</link
>'>
  <!ENTITY qtdir '<link linkend="conf-qtdir"
>qtdir</link
>'>
  <!ENTITY build-dir '<link linkend="conf-build-dir"
>build-dir</link
>'>
  <!ENTITY module-base-path '<link linkend="conf-module-base-path"
>module-base-path</link
>'>
  <!ENTITY override-url '<link linkend="conf-override-url"
>override-url</link
>'>
  <!ENTITY source-dir '<link linkend="conf-source-dir"
>source-dir</link
>'>
  <!ENTITY colorful-output '<link linkend="conf-colorful-output"
>colorful-output</link
>'>
  <!ENTITY tag '<link linkend="conf-tag"
>tag</link
>'>
  <!ENTITY branch '<link linkend="conf-branch"
>branch</link
>'>
  <!ENTITY do-not-compile '<link linkend="conf-do-not-compile"
>do-not-compile</link
>'>
  <!ENTITY repository '<link linkend="conf-repository"
>repository</link
>'>
  <!ENTITY make-install-prefix '<link linkend="conf-make-install-prefix"
>make-install-prefix</link
>'>
  <!ENTITY niceness '<link linkend="conf-niceness"
>niceness</link
>'>
  <!ENTITY set-env '<link linkend="conf-set-env"
>set-env</link
>'>
  <!ENTITY libname '<link linkend="conf-libname"
>libname</link
>'>
  <!ENTITY libpath '<link linkend="conf-libpath"
>libpath</link
>'>
  <!ENTITY binpath '<link linkend="conf-binpath"
>binpath</link
>'>

  <!-- These define shortcut entities for some of the command line options.
       Just add them as necessary.
  -->
  <!ENTITY cmd-nice '<link linkend="cmdline-nice"
>--nice</link
>'>
  <!ENTITY cmd-ignore-modules '<link linkend="cmdline-ignore-modules"
>--ignore-modules</link
>'>
  <!ENTITY cmd-resume-from '<link linkend="cmdline-resume-from"
>--resume-from</link
>'>
  <!ENTITY cmd-resume-after '<link linkend="cmdline-resume-after"
>--resume-after</link
>'>
  <!ENTITY cmd-reconfigure '<link linkend="cmdline-reconfigure"
>--reconfigure</link
>'>
  <!ENTITY cmd-refresh-build '<link linkend="cmdline-refresh-build"
>--refresh-build</link
>'>
]>

<book id="kdesrc-build" lang="&language;">

<bookinfo>
<title
>Handbok för skriptet &kdesrc-build;</title>

<authorgroup id="authors">
    <author
><personname
><firstname
>Michael</firstname
><surname
>Pyne</surname
></personname
> <email
></email
></author>
    <author
><personname
><firstname
>Carlos</firstname
><surname
>Woelz</surname
></personname
> <email
>carloswoelz@imap-mail.com</email
> </author>

<othercredit role="translator"
> <firstname
>Stefan</firstname
> <surname
>Asserhäll</surname
> <affiliation
><address
><email
>stefan.asserhall@bredband.net</email
></address
></affiliation
> <contrib
>Översättare</contrib
></othercredit
> 

</authorgroup>

<copyright>
<year
>2006</year>
<year
>2007</year>
<year
>2008</year>
<year
>2009</year>
<year
>2010</year>
<year
>2011</year>
<year
>2012</year>
<year
>2013</year>
<year
>2014</year>
<year
>2015</year>
<year
>2016</year>
<year
>2017</year>
<year
>2018</year>
<year
>2019</year>
<holder
>Michael Pyne</holder>
</copyright>

<copyright>
<year
>2005</year>
<holder
>Carlos Woelz</holder>
</copyright>

<legalnotice
>&FDLNotice;</legalnotice>

<date
>2018-01-20</date>
<releaseinfo
>&kdesrc-build; 17.12</releaseinfo>

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

<keywordset>
<keyword
>KDE</keyword>
<keyword
>kdesdk</keyword>
<keyword
>git</keyword>
<keyword
>KDE-utveckling</keyword>
</keywordset>

</bookinfo>

<chapter id="introduction">
<title
>Inledning</title>

<sect1 id="brief-intro">
<title
>En kortfattad introduktion till &kdesrc-build;</title>

<sect2 id="whatis-kdesrc-build">
<title
>Vad är &kdesrc-build;?</title>

<para
>&kdesrc-build; är ett skript för att hjälpa &kde;-gemenskapen installer <ulink url="https://www.kde.org/"
>&kde;-programvara</ulink
> från <ulink url="https://git-scm.com/"
>&git;</ulink
> källkodsarkiv, och fortsätta att uppdatera programvaran efteråt. Det är i synnerhet avsett att stödja de som behöver hantera testning och utveckling av &kde;-programvara, inklusive användare som testar felrättningar och utvecklare som arbetar på nya funktioner. </para>

<para
>Skriptet &kdesrc-build; kan användas för att underhålla en enskild individuell modul, ett fullständigt &plasma;-skrivbord med &kde;:s programuppsättning, eller någonting däremellan. </para>

<para
>Se <xref linkend="getting-started"/> för att komma igång, eller fortsätt läsa för mer detaljerad information om hur &kdesrc-build; fungerar och vad som omfattas av den här dokumentationen. </para>
</sect2>

<sect2 id="operation-in-a-nutshell">
<title
>Funktionen hos &kdesrc-build; <quote
>i ett nötskal</quote
></title>

<para
>&kdesrc-build; fungerar genom att använda verktygen tillgängliga för användaren på kommandoraden, och använder samma gränssnitt som är tillgängliga för användaren. När &kdesrc-build; kör, utförs följande sekvens: </para>

<orderedlist>
<listitem
><para
>&kdesrc-build; läser in <link linkend="cmdline"
>kommandoraden</link
> och en <link linkend="configure-data"
>inställningsfil</link
> för att bestämma vad som ska byggas, var det ska installeras, etc.</para
></listitem>

<listitem
><para
>&kdesrc-build; utför en källkodsuppdatering för varje <link linkend="module-concept"
>modul</link
>. Uppdateringen fortsätter tills alla moduler har uppdaterats. Moduler vars uppdatering misslyckas stoppar normalt inte bygget: du blir informerad i slutet om vilka moduler som inte uppdaterades.</para
></listitem>

<listitem
><para
>Moduler som uppdaterades med lyckat resultat byggs, deras testsviter körs, och installeras därefter. För att reducera den totala tiden som går åt, börjar &kdesrc-build; normalt bygga koden så snart uppdateringen av den första modulen är klar, och låta återstående uppdateringar fortsätta bakom kulisserna. </para
></listitem>
</orderedlist>

<tip
><para
>En <emphasis
>mycket bra</emphasis
> översikt av hur &kde;-moduler byggs, inklusive informativa diagram, är tillgänglig i <ulink url="https://www.davidrevoy.com/article193/guide-building-krita-on-linux-for- cats"
>en artikel på nätet som beskriver &kde;-programmet &krita;</ulink
>. Det här arbetsflödet är vad &kdesrc-build; automatiserar för alla &kde;-moduler.</para>
</tip>

</sect2>
</sect1>

<sect1 id="intro-toc">
<title
>Översikt över dokumentationen</title>

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

<itemizedlist>
<listitem
><para
>En <link linkend="getting-started"
>översikt</link
> av stegen som krävs för att komma igång.</para
></listitem>
<listitem
><para
><link linkend="features"
>Funktioner</link
> värda att lägga märke till.</para
></listitem>
<listitem
><para
><link linkend="configure-data"
>Inställningsfilen</link
>s syntax och alternativ. </para
></listitem>
<listitem
><para
><link linkend="cmdline"
>Kommandoradsväljarna</link
>.</para
></listitem>
</itemizedlist>

<para
>Dessutom dokumenteras stegen du måste utföra med andra verktyg (dvs. steg som inte utförs automatiskt av &kdesrc-build;). </para>

</sect1>
</chapter>

<chapter id="getting-started">
<title
>Komma igång</title>

<para
>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 källkodsstruktur och stegen du måste utföra innan skriptet körs. </para>

<para
>Alla ämnen som presenteras i det här kapitlet täcks med ännu mer detaljer i artikeln <ulink url="https://community.kde.org/Guidelines_and_HOWTOs/Build_from_source"
> Build from Source</ulink
> på webbplatsen <ulink url="https://community.kde.org/"
>&kde; Community Wiki</ulink
>. 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. </para>

<sect1 id="before-building">
<title
>Förbereda systemet för att bygga &kde;</title>

<sect2 id="before-building-users">
<title
>Ställa in ett nytt användarkonto</title>

<para
>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;. </para>

<tip
><para
>Att lämna systemets &kde; orört, låter dig också ha en reservutväg i nödfall om ett kodningsmisstag gör att den senaste programvarubyggningen är oanvändbar. </para
></tip>

<para
>Du kan också ställa in att installera i en systemkatalog (t.ex. <filename class="directory"
>/usr/src/local</filename
>) om du vill. Det här dokumentet omfattar inte den installationstypen, eftersom vi antar att du vet vad du gör. </para>

</sect2>
<sect2 id="before-building-preparation">
<title
>Försäkra dig om att systemet är klart att bygga &kde;:s källkod</title>

<para
>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 nästan fullständiga listan med verktyg som behövs finns på <ulink url="https://community.kde.org/Guidelines_and_HOWTOs/Build_from_source#Install_required_devel_packages"
>sidan med byggkrav på &kde; Community Wiki </ulink
>. </para>

<para
>Här är en lista med några av de saker du kommer att behöva:</para>
<itemizedlist>

<listitem
><para
>Du behöver &cmake;, eftersom denna programvara är vad &kde; använder för att hantera byggkonfiguration av källkoden och generering av de specifika byggkommandona för systemet. Versionen som krävs varierar beroende på vilken version av &kde;-programvaran som byggs (se teknikbasen för närmare detaljer), men med moderna distributioner bör den &cmake; som är inkluderad i distributionen vara fullt tillräcklig. </para
></listitem>

<listitem
><para
>Du måste också installera klientprogram för källkodshantering som används för att checka ut &kde;:s källkod. Det betyder att du åtminstone behöver följande:</para>

<itemizedlist>
<listitem
><para
><ulink url="https://git-scm.com/"
>Källkodshanteringssystemet Git</ulink
> som används för all <ulink url="https://commits.kde.org/"
>källkod i &kde;</ulink
>.</para
></listitem>

<listitem
><para
>Även om det inte krävs, används källkodshanteringssystemet <ulink url="http://bazaar.canonical.com/"
>Bazaar</ulink
> för en enda modul (libdbusmenu-qt) som krävs av &kde;-biblioteken. De flesta användare kan installera biblioteket via distributionens paket, men &kdesrc-build; stöder att också bygga det om du så önskar. Men för att bygga libdbusmenu-qt, måste du ha installerat Bazaar.</para
></listitem>
</itemizedlist
></listitem>

<listitem
><para
>Skriptspråket Perl krävs för &kdesrc-build;, vissa &kde;-arkiv och &Qt; (om det byggs från källkod).</para>

<para
>Perl som levereras med distributionen bör vara lämplig (det måste vara minst Perl 5.14), men vissa ytterligare moduler behövs också (&kdesrc-build; varnar dig om de inte är tillgängliga):</para>

<itemizedlist>
    <listitem
><para
>IO::Socket::SSL</para
></listitem>
    <listitem
><para
>JSON::PP eller JSON::XS</para
></listitem>
    <listitem
><para
>YAML::PP, YAML::XS eller YAML::Syck</para
></listitem>
</itemizedlist>
</listitem>

<listitem
><para
>En fullständig C++ utvecklingsmiljö behövs (kompilator, standardbibliotek, körtidsbibliotek och alla utvecklingspaket som krävs). De äldsta nödvändiga versionerna varierar baserat på &kde;-modulen: samlingen &kde;-ramverk 5 stöder de äldsta kompilatorerna, medan &kde; Plasma 5 och &kde;-program brukar kräva nyare kompilatorer.</para>
<para
>Kompilatorerna GCC 4.8 eller Clang 4 är de äldsta som rekommenderas. Många distributioner stöder att enkelt installera verktygen genom att använda paketet <quote
>build-essentials</quote
>, ett alternativ att installera "byggberoenden" &Qt; eller liknande funktioner. KDE-gemenskapens Wiki har en sida som <ulink url="https://community.kde.org/Guidelines_and_HOWTOs/Build_from_source/Install_the_dependencies"
>följer rekommenderade paket för större distributioner</ulink
>. </para>
</listitem>

<listitem
><para
>Ett byggverktyg som faktiskt utför kompileringsstegen behövs (de som genereras av &cmake;). GNU Make rekommenderas och bör vara tillgängligt via pakethanteraren. &cmake; stöder andra alternativ, såsom byggverktyget &ninja;, som kan utnyttjas av &kdesrc-build; genom att använda inställningsfilens alternativ <link linkend="conf-custom-build-command"
>custom-build-command</link
>. </para
></listitem>

<listitem
><para
>Slutligen behövs lämpliga &Qt;-bibliotek (inklusive utvecklingspaket) för versionen av &kde;-programvara som du bygger. &kdesrc-build; stöder inte officiellt att bygga &Qt; 5 (nuvarande huvudversion), alltså rekommenderas du att använda distributionens utvecklingspaket, eller att titta på KDE-gemenskapens Wiki sida om att <ulink url="https://community.kde.org/Guidelines_and_HOWTOs/Build_from_source/OwnQt5"
>bygga Qt 5 själv</ulink
>. </para
></listitem>
</itemizedlist>

<note
><para
>De flesta distributioner av operativsystem inkluderar en metod att enkelt installera nödvändiga utvecklingsverktyg. Konsultera avsnittet <ulink url="https://community.kde.org/Guidelines_and_HOWTOs/Build_from_source#Install_required_devel_packages"
>Required devel packages</ulink
> på Community Wiki, för att se om instruktioner redan är tillgängliga.</para
></note>

<important
><para
>Vissa av paketen är uppdelade i bibliotek (eller program, eller verktyg) och utvecklingspaket Du behöver åtminstone programmet eller biblioteket <emphasis
>och</emphasis
> dess utvecklingspaket. </para
></important>

</sect2>

<sect2 id="before-building-prepare-script">
<title
>Inställning av &kdesrc-build;</title>

<sect3 id="get-kdesrc-build">
<title
>Installera &kdesrc-build;</title>
<para
>&kde;-utvecklarna gör täta förändringar av &kdesrc-build; för att hålla det synkroniserat med framsteg i &kde;-utvecklingen, inklusive förbättringar av den rekommenderade inställningen av &kdesrc-build;, tillägg av moduler, förbättring av flaggor i &cmake;, etc.</para>

<para
>På grund av detta, rekommenderar vi att hämta &kdesrc-build; direkt från dess källkodsarkiv och därefter uppdatera det periodiskt.</para>

<para
>Du kan hämta &kdesrc-build; från dess källkodsarkiv, genom att köra:</para>
<programlisting
><prompt
>$ </prompt
><userinput
><command
>git <option
>clone</option
> <option
>https://invent.kde.org/sdk/kdesrc-build.git</option
> <option
><filename class="directory"
><replaceable
>~/kdesrc-build</replaceable
></filename
></option
></command
></userinput
>
</programlisting>

<para
>Ersätt <option
><replaceable
>~/kdesrc-build</replaceable
></option
> med katalogen du vill installera i. </para>

<para
>Du kan senare uppdatera &kdesrc-build; genom att köra:</para>
<programlisting
><prompt
>$ </prompt
><userinput
><command
>cd <option
><filename class="directory"
><replaceable
>~/kdesrc-build</replaceable
></filename
></option
></command
></userinput>
<prompt
>$ </prompt
><userinput
><command
>git <option
>pull</option
></command
></userinput
>
</programlisting>

<tip
><para
>Vi rekommenderar att lägga till installationskatalogen för &kdesrc-build; i miljövariabeln <envar
>PATH</envar
>, så att &kdesrc-build; kan köras utan att behöva ange hela sökvägen varje gång.</para
></tip>
</sect3>

<sect3 id="setup-rcfile">
<title
>Färdigställa inställningsfilen</title>

<para
>&kdesrc-build; använder en <link linkend="configure-data"
>inställningsfil</link
> för att bestämma vilka moduler som byggs, var de installeras, etc. Filen heter <filename
>~/.config/kdesrc-buildrc</filename
> (<filename
>$XDG_CONFIG_HOME/kdesrc-buildrc</filename
>, om <envar
>$XDG_CONFIG_HOME</envar
> är angivet).</para>

<para
>Du kan använda ett program som ingår tillsammans med &kdesrc-build;, vid namn <application
>kdesrc-build-setup</application
> för att skapa en enkel inställning för kdesrc-build. Därefter kan du redigera inställningsfilen <filename
>~/.config/kdesrc-buildrc</filename
> för att göra eventuella ändringar du har behov av.</para>

<para
>Själva <application
>kdesrc-build-setup</application
> körs från en terminal (istället för att använda ett grafiskt gränssnitt), precis som &kdesrc-build;, så du kan använda det även om du inte har något grafiskt gränssnitt tillgängligt ännu.</para>

<sect4 id="setup-rcfile-manually">
<title
>Manuell uppdatering av inställningsfilen</title>

<para
>Det går också att uppdatera inställningsfilen för hand, genom att kopiera det inkluderade exemplet på en inställningsfil <filename
>kdesrc-buildrc-kf5-sample</filename
> till <filename
>~/.config/kdesrc-buildrc</filename
> och sedan redigera filen. En användbar referens för detta är <xref linkend="kdesrc-buildrc"/>, i synnerhet dess <link linkend="conf-options-table"
>tabell över inställningsalternativ</link
>. </para>

<para
>&kdesrc-build; innehåller många rekommenderade inställningsfiler för att stödja &kde; Ramverk 5, &plasma; 5 och andra &kde;-program. <application
>kdesrc-build-setup</application
> hänvisar till dessa filer i inställningsfilen som skapas, men du kan också använda dem själv. Se <xref linkend="kdesrc-buildrc-including"/> för information om hur andra inställningsfiler används från din egen <filename
>kdesrc-buildrc</filename
>. </para>

<para
>Du hittar mer information om syntaxen i en <link linkend="configure-data"
>inställningsfil</link
> i <xref linkend="configure-data"/> och <xref linkend="kdesrc-buildrc"/>. </para>
</sect4>
</sect3>
</sect2>
</sect1>

<sect1 id="configure-data">
<title
>Ange inställningsinformation</title>

<para
>För att använda &kdesrc-build; ska du ha en fil i katalogen <filename
>~/.config</filename
> (eller i <envar
>$XDG_CONFIG_HOME</envar
>, om angivet) vid namn <filename
>kdesrc-buildrc</filename
>, som ställer in allmänna alternativ och anger modulerna som du vill ladda ner och bygga. </para>

<note
><para
>Det är möjligt att använda andra inställningsfiler för &kdesrc-build;, som beskrivs i <xref linkend="kdesrc-buildrc"/>. Om du behöver använda flera inställningar, se det avsnittet.Här antar vi att inställningarna är lagrade i <filename
>~/.config/kdesrc-buildrc</filename
>. </para
></note>

<para
>Det enklaste sättet att fortsätta är att använda filen <filename
>kdesrc-buildrc-kf5-sample</filename
> 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. </para>

<para
>Standardinställningarna bör vara lämpliga för att utföra byggprocessen för &kde;. Vissa inställningar som du kan vilja ändra omfattar: </para>

<itemizedlist>
<listitem
><para
><link linkend="conf-kdedir"
>kdedir</link
>, som ändrar målkatalogen som &kde;-programvaran installeras i. Standardvärdet är <filename
>~/kde</filename
>, som är en enanvändarinstallation.</para
></listitem>

<listitem
><para
><link linkend="conf-branch-group"
>branch-group</link
> som kan användas för att välja lämplig utvecklingsgren för &kde;-moduler som helhet. Det finns många byggkonfigurationer som stöds, men det är troligtvis <option
>kf5-qt5</option
> som du ska välja så att &kdesrc-build; laddar ner den senaste koden baserad på &Qt; 5 och &kde; Ramverk 5.</para>

<tip
><para
>&kdesrc-build; använder en standardgrupp om du inte väljer någon, men standardvärdet ändras med tiden, så det är bättre att välja en så att inte grengruppen oväntat ändras.</para
></tip>
</listitem>

<listitem
><para
><link linkend="conf-source-dir"
>source-dir</link
>, för att bestämma katalogen som &kdesrc-build; använder för att ladda ner källkoden, köra byggprocessen och spara loggar. Standardvärdet är <filename class="directory"
>~/kdesrc</filename
>.</para
></listitem>

<listitem
><para
><link linkend="conf-cmake-options"
>cmake-options</link
> som ställer in alternativ att skicka till kommandot &cmake; när varje modul byggs. Oftast används det för att välja mellan byggvarianterna <quote
>debug</quote
> och <quote
>release</quote
>, för att aktivera (eller inaktivera) valfria funktioner, eller för att skicka information till byggprocessen om platsen för nödvändiga bibliotek. </para
></listitem>

<listitem
><para
><link linkend="conf-make-options"
>make-options</link
> som ställer in väljare använda när kommandot <application
>make</application
> faktiskt utförs för att bygga varje modul (när väl &cmake; har etablerat byggsystemet). </para>

<para
>Den mest typiska väljaren är <option
>-j<replaceable
>N</replaceable
></option
>, där <replaceable
>N</replaceable
> ska ersättas med det maximala antal kompileringsjobb som du vill tillåta. Ett större tal (upp till antalet logiska processorer som systemet har tillgängligt) leder till en snabbare byggprocess, men kräver mer systemresurser. </para>

<tip
><para
>&kdesrc-build; ställer in alternativet <option
><link linkend="conf-num-cores"
>num-cores</link
></option
> till detekterat antal processorkärnor. Du kan använda värdet i din egen inställningsfil för att undvika att behöva ange det manuellt. </para
></tip>

<example id="make-options-example">
<title
>Anpassa Make för att använda alla tillgängliga processorer, med undantag</title>
<screen
>global
    # Miljövariabeln används automatiskt av make, inklusive
    # make-kommandon som inte direkt körs av kdesrc-build, såsom Qt:s configure
    set-env MAKEFLAGS -j<literal
>${num-cores}</literal>
    &hellip;
end global

&hellip;

module-set <replaceable
>big-module-set</replaceable>
    repository kde-projects
    use-modules <replaceable
>calligra</replaceable>
    make-options -j2 # Reducerat antal byggjobb för bara dessa moduler
end module-set
</screen>
</example>

<note
><para
>Några mycket stora Git-arkiv kan översvämma systemet om du försöker kompilera med för många byggjobb på en gång, särskilt arkiv som &Qt; Webkit och &Qt; WebEngine. För att behålla systemets interaktivitet måste du kanske reducera antal byggjobb för specifika moduler.</para>
<para
><xref linkend="make-options-example"/> ger ett exempel på hur man kan göra det.</para>
</note>

</listitem>
</itemizedlist>

<para
>Du kanske vill välja andra moduler att bygga, vilket beskrivs i <xref linkend="selecting-modules"/>.</para>

</sect1>

<sect1 id="building-and-troubleshooting">
<title
>Att använda skriptet &kdesrc-build;</title>
<para
>När inställningsdata är upprättad, är du redo att köra skriptet. Även om du fortfarande har en del finjustering eller annat som du vill läsa, är det en god idé att åtminstone läsa in &kde;-projektets metadata.</para>

<sect2 id="loading-kdesrc-build-metadata">
<title
>Läsa in projektmetadata</title>

<para
>Logga in till användaren som du använder för att kompilera &kde;:s programvara i ett terminalfönster, och kör skriptet: </para>
<screen
><prompt
>&percnt;</prompt
> <userinput
><command
>kdesrc-build</command
> <option
>--metadata-only</option
></userinput
>
</screen>

<para
>Kommandot ställer in källkodskatalogen och ansluter till KDE:s &git;-arkiv för att ladda ner databasen med &kde;:s git-arkiv, och databasen med metadata över beroenden, utan att göra några ytterligare ändringar. Det är användbart att göra det separat, eftersom metadata är användbar för andra kommandon i &kdesrc-build;. </para>

</sect2>

<sect2 id="pretend-mode">
<title
>Förhandsgranska vad som kommer att hända när kdesrc-build kör</title>

<para
>När projektets metadata är installerad är det möjligt att granska vad &kdesrc-build; kommer att göra när det startas. Det kan åstadkommas med kommandoradsväljaren <option
><link linkend="cmdline-pretend"
>--pretend</link
></option
>.</para>

<screen
><prompt
>&percnt; </prompt
><command
>./kdesrc-build</command
> <option
>--pretend</option
>
</screen>

<para
>Du ska se ett meddelande som talar om att några paket har byggts med lyckat resultat (även om ingenting faktiskt byggdes). Om inga väsentliga problem visas, kan du fortsätta att verkligen köra skriptet.</para>

<screen
><prompt
>&percnt;</prompt
> <userinput
><command
>kdesrc-build</command
></userinput
>
</screen>

<para
>Kommandot laddar ner lämplig källkod, bygger och installerar varje modul i tur och ordning. Efteråt ska du se utmatning som liknar den i <xref linkend="example-build-sequence"/>.</para>

<example id="example-build-sequence">
<title
>Exempel på utmatning från en kdesrc-build körning</title>
<screen
><prompt
>&percnt;</prompt
> <userinput
><command
>kdesrc-build</command
></userinput>
Updating kde-build-metadata (to branch master)
Updating sysadmin-repo-metadata (to branch master)

Building libdbusmenu-qt (1/200)
        No changes to libdbusmenu-qt source, proceeding to build.
        Compiling... succeeded (after 0 seconds)
        Installing.. succeeded (after 0 seconds)

Building taglib (2/200)
        Updating taglib (to branch master)
        Source update complete for taglib: 68 files affected.
        Compiling... succeeded (after 0 seconds)
        Installing.. succeeded (after 0 seconds)

Building extra-cmake-modules from &lt;module-set at line 32&gt; (3/200)
        Updating extra-cmake-modules (to branch master)
        Source update complete for extra-cmake-modules: 2 files affected.
        Compiling... succeeded (after 0 seconds)
        Installing.. succeeded (after 0 seconds)

        ...

Building kdevelop from kdev (200/200)
        Updating kdevelop (to branch master)
        Source update complete for kdevelop: 29 files affected.
        Compiling... succeeded (after 1 minute, and 34 seconds)
        Installing.. succeeded (after 2 seconds)

&lt;&lt;&lt;  PACKAGES SUCCESSFULLY BUILT  &gt;&gt;&gt;
Built 200 modules

Your logs are saved in /home/kde-src/kdesrc/log/2018-01-20-07
</screen>
</example>
</sect2>

<sect2 id="fixing-build-failures">
<title
>Lösa byggfel</title>

<para
>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;:s programvara. Ge inte upp hoppet! </para>

<para
>&kdesrc-build; loggar utmatningen från varje kommando som körs. Normalt lagras loggfilerna i <filename class="directory"
>~/kdesrc/log</filename
>. 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 <filename class="directory"
>~/kdesrc/log/latest/<replaceable
>modulnamn</replaceable
>/error.log</filename
>.</para>

<tip
><para
>Det kanske enklaste sättet att ta reda på vilka fel som gör att bygget av en modul misslyckas är att söka bakåt efter ordet <literal
>error</literal
> från slutet av filen med en sökning som inte är skiftlägeskänslig. När det hittats, rulla uppåt för att vara säker på att det inte finns några andra felmeddelanden i närheten. Det första felmeddelandet i en grupp är ofta det bakomliggande problemet.</para
></tip>

<para
>I filen ser du felet som orsakade att byggprocessen misslyckades för modulen. Om det står (längst ner) i filen att vissa paket saknas, försök att installera paketet (inklusive eventuella lämpliga -dev paket) innan du försöker bygga modulen igen. Försäkra dig om att skicka med väljaren <link linkend="cmdline-reconfigure"
>--reconfigure</link
> när &kdesrc-build; körs igen, så att &kdesrc-build; gör att modulen letar efter de saknade paketen igen.</para>

<para
>Eller om felet verkar vara ett byggfel (som ett syntaxfel, <quote
>incorrect prototype</quote
>, <quote
>unknown type</quote
> eller likande) ä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 <email
>kde-devel@kde.org</email
> (prenumeration kan krävas först) för att rapportera byggfelet.</para>

<para
>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;:s programvara i <ulink url="https://community.kde.org/Guidelines_and_HOWTOs/Build_from_source"
> Build from Source</ulink
>. </para>

<para
>Å andra sidan, under förutsättning att allt gick bra, ska en ny &kde;-version vara installerad på datorn, och nu är det helt enkelt bara en fråga om att köra den, vilket beskrivs härnäst i <xref linkend="environment"/>.</para>

<note
><para
>För mer information om loggningssystemet i &kdesrc-build;, se <xref linkend="kdesrc-build-logging"/>.</para
></note>
</sect2>

</sect1>

<sect1 id="building-specific-modules">
<title
>Bygga specifika moduler</title>

<para
>Istället för att bygga alla moduler hela tiden, kanske man vill bygga en enstaka modul, eller någon annan liten delmängd. Istället för att redigera inställningsfilen, kan man helt enkelt skicka med namn på moduler eller moduluppsättningar att bygga på kommandoraden.</para>

<example id="example-subset-build">
<title
>Exempel på utmatning när en specifik modul byggs av kdesrc-build</title>
<screen
><prompt
>&percnt;</prompt
> <userinput
><command
>kdesrc-build</command
> <option
>--include-dependencies</option
> <replaceable
>dolphin</replaceable
></userinput>
Updating kde-build-metadata (to branch master)
Updating sysadmin-repo-metadata (to branch master)

Building extra-cmake-modules from frameworks-set (1/79)
        Updating extra-cmake-modules (to branch master)
        No changes to extra-cmake-modules source, proceeding to build.
        Running cmake...
        Compiling... succeeded (after 0 seconds)
        Installing.. succeeded (after 0 seconds)

Building phonon from phonon (2/79)
        Updating phonon (to branch master)
        No changes to phonon source, proceeding to build.
        Compiling... succeeded (after 0 seconds)
        Installing.. succeeded (after 0 seconds)

Building attica from frameworks-set (3/79)
        Updating attica (to branch master)
        No changes to attica source, proceeding to build.
        Compiling... succeeded (after 0 seconds)
        Installing.. succeeded (after 0 seconds)

        ...

Building dolphin from base-apps (79/79)
        Updating dolphin (to branch master)
        No changes to dolphin source, proceeding to build.
        Compiling... succeeded (after 0 seconds)
        Installing.. succeeded (after 0 seconds)

&lt;&lt;&lt;  PACKAGES SUCCESSFULLY BUILT  &gt;&gt;&gt;
Built 79 modules

Your logs are saved in /home/kde-src/kdesrc/log/2018-01-20-07
</screen>
</example>

<para
>Även om bara programmet <replaceable
>dolphin</replaceable
> angavs i detta fall, orsakade väljaren <option
>--include-dependencies</option
> att &kdesrc-build; inkluderade beroenden listade för <replaceable
>dolphin</replaceable
> (genom att ange väljaren <link linkend="conf-include-dependencies"
>include-dependencies</link
>). </para>

<note
><para
>I detta fall fungerade beroendehanteringen bara eftersom <replaceable
>dolphin</replaceable
> råkar vara angiven i en moduluppsättning baserad på <literal
>kde-projects</literal
> (kallad <literal
>base-apps</literal
> i exemplet). Se <xref linkend="module-sets-kde"/>. </para
></note>

</sect1>

<sect1 id="environment">
<title
>Ställa in miljön för att köra ditt &kde; &plasma;-skrivbord</title>

<para
>Med antagandet att du använder en särskild användare för att bygga &kde; &plasma; och redan har en installerad version av &plasma;, kan det vara något krångligt att köra det nya &plasma;, eftersom det nya måste ges företräde över det gamla. Du måste ändra miljövariabler i inloggningsskript för att försäkra dig om att det nyss byggda skrivbordet används. </para>

<sect2 id="session-driver">
<title
>Installerar automatiskt en drivrutin för inloggning</title>

<para
>Från och med version 1.16 försöker &kdesrc-build; installera en lämplig drivrutin för inloggning, som låter dig logga in på &kde;-skrivbordet som byggts av &kdesrc-build; från din inloggningshanterare. Det kan inaktiveras genom att använda inställningsalternativet <option
><link linkend="conf-install-session-driver"
>install-session-driver</link
></option
> i inställningsfilen.</para>

<note
><para
>Sessionsinställning sker inte medan &kdesrc-build; gör i låtsasläge.</para
></note>

<para
>Drivrutinen fungerar genom att skapa en egen <quote
><literal
>xsession</literal
></quote
> sessionstyp. Denna typ av session ska fungera direkt med inloggningshanteraren sddm (där den visas som en <quote
>Egen</quote
> session), men andra inloggningshanterare (som <application
>LightDM</application
> och <application
>gdm</application
>) kan kräva att ytterligare filer installeras för att aktivera stöd för <literal
>xsession</literal
>.</para>

<sect3 id="xsession-distribution-setup">
<title
>Lägger till xsession-stöd för distributioner</title>

<para
>Den förinställda inloggningshanteraren för vissa distributioner kan kräva att ytterligare paket installeras för att stödja inloggning med <literal
>xsession</literal
>.</para>

<itemizedlist>
<listitem
><para
>Distributionen <ulink url="https://getfedora.org/"
>Fedora</ulink
> &Linux; kräver att paketet <literal
>xorg-x11-xinit-session</literal
> är installerat för att stödja inloggning med en egen <literal
>xsession</literal
>.</para
></listitem>

<listitem
><para
><ulink url="https://www.debian.org/"
>Debian</ulink
> och &Linux;-distributioner baserade på Debian ska stödja inloggning med en egen <literal
>xsession</literal
>, men kräver att alternativet <option
><userinput
>allow-user-xsession</userinput
></option
> ställs in i <filename
>/etc/X11/Xsession.options</filename
>. Se också Debians <ulink url="https://www.debian.org/doc/manuals/debian-referencech07.en.html#_customizing_the_x_session_classic_method"
>dokumentation om att anpassa en X-session</ulink
>.</para
></listitem>

<listitem
><para
>För övriga distributioner, se <xref linkend="xsession-manual-setup"/>.</para
></listitem>
</itemizedlist>

</sect3>

<sect3 id="xsession-manual-setup">
<title
>Manuellt tillägg av stöd för xsession</title>

<para
>Om det inte fanns några distributionsspecifika anvisningar för din distribution i <xref linkend="xsession-distribution-setup"/>, kan du lägga till en post i distributionens lista med sessionstyper för <quote
>inloggning med egen xsession</quote
> på följande sätt:</para>

<procedure id="proc-adding-xsession-type">
<title
>Lägga till en .xsession inloggningssessionstyp.</title>

<note
><para
>Proceduren kräver troligen administratörsrättigheter för att kunna göras färdig. </para
></note>

<step performance="required">
<para
>Skapa filen <filename
>/usr/share/xsessions/kdesrc-build.desktop</filename
>.</para>
</step>

<step performance="required">
<para
>Försäkra dig om att filen som just skapas innehåller följande text:</para>
<literallayout
><userinput>
Type=XSession
Exec=<co id="session-homedir"/><replaceable
>$HOME</replaceable
>/.xsession
Name=KDE Plasma Desktop (unstable; kdesrc-build)
</userinput
></literallayout>

<calloutlist>
<callout arearefs="session-homedir"
><para
>Värdet <replaceable
>$HOME</replaceable
> måste ersättas av den fullständiga sökvägen till din hemkatalog (exempelvis <filename class="directory"
>/home/<replaceable
>användare</replaceable
></filename
>). Specifikationen av skrivbordsposter tillåter inte generella användarfiler. </para
></callout>

</calloutlist>
</step>

<step performance="optional"
><para
>När inloggningshanteraren startas om, ska den visa en ny sessionstyp, <quote
>KDE Plasma Desktop (unstable; kdesrc-build)</quote
> i listan med sessioner, vilket ska försöka köra filen <filename
>.xsession</filename
> som installerats av &kdesrc-build;, om den är markerad när du loggar in.</para>

<note
><para
>Det kan vara enklast att starta om datorn för att starta om inloggningshanteraren, om inloggningshanteraren inte bevakar uppdateringar av katalogen <filename class="directory"
>/usr/share/xsessions</filename
>.</para
></note>

</step>

</procedure>

</sect3>

</sect2>

<sect2 id="old-profile-instructions">
<title
>Ange miljön för hand</title>
<para
>Dokumentationen innehöll tidigare instruktioner om vilka miljövariabler som ska ställas in för att kunna läsa in det nybyggda skrivbordet. Dessa instruktioner har flyttats till ett appendix (<xref linkend="old-profile-setup"/>).</para>

<para
>Om du har för avsikt att ställa in eget stöd för inloggning, kan du titta i appendixet eller öppna filen <filename
>sample-kde-env-master.sh</filename
> som ingår i källkoden för &kdesrc-build;.</para>

</sect2>

</sect1>

<sect1 id="kde-modules-and-selection">
<title
>Organisation och urval av moduler</title>

<sect2 id="kde-layers">
<title
>Organisation av KDE-programvara</title>

<para
>&kde;-programvara är uppdelad i olika komponenter, där en stor del kan byggas av &kdesrc-build;. Att förstå organisationen hjälper till att välja programvarumoduler att bygga. </para>

<orderedlist>
<listitem
><para
>På lägsta nivån finns &Qt;-biblioteket, som är en mycket kraftfull, plattformsoberoende <quote
>verktygslåda</quote
>. &kde; är baserat på &Qt; och vissa av de bibliotek som inte hör till &kde;, men krävs av &kde;, är också baserade på &Qt;. &kdesrc-build; kan bygga &Qt; eller använda ett som redan är installerat på systemet om versionen är tillräckligt ny.</para
></listitem>

<listitem
><para
>Ovanpå &Qt; finns nödvändiga bibliotek som krävs för att &kde;-programvara ska fungera. Vissa av dessa bibliotek anses inte vara en del av själva &kde;, på grund av deras generella natur, med är ändå väsentliga för &kde;-plattformen. Dessa bibliotek samlas i modulen<literal
>kdesupport</literal
>, men anses inte vara en del av <quote
>Ramverk-biblioteken</quote
>.</para>
</listitem>

<listitem
><para
>Ovanpå de här väsentliga biblioteken kommer <ulink url="https://community.kde.org/Frameworks"
>&kde; Ramverk</ulink
>, ibland förkortat som KF5, vilka är väsentliga bibliotek för &kde;:s Plasma-skrivbord, &kde;-program och annan tredjepartsprogramvara. </para
> </listitem>

<listitem
><para
>Ovanpå ramverket, finns flera olika saker:</para>
    <itemizedlist>
        <listitem
><para
><quote
>Tredjepartsprogram</quote
>. Detta är program som använder &kde;:s ramverk eller är konstruerade för att köra med &kde; Plasma, men inte skapas av eller i samröre med &kde;-projektet.</para
></listitem>

        <listitem
><para
>Plasma, som är en komplett skrivbordsmiljö, <quote
>arbetsyta</quote
>. Det är vad användare normalt ser när de <quote
>loggar in med &kde;</quote
>.</para
></listitem>

        <listitem
><para
>&kde;:s programvarusvit. Det är en samling användbar programvara som inkluderas med plattformen och &plasma;-skrivbord, grupperade i individuella moduler, inklusive verktyg som &dolphin;, spel som <application
>Ksudoku</application
> och produktivitetsprogram som ges ut av &kde;, såsom &kontact;.</para
></listitem>

        <listitem
><para
>Till sist, finns en samling programvara (också samlad i moduler) vars utveckling stöds av resurser som tillhandahålls av &kde; (såsom översättning, källkodskontroll, feluppföljning, etc.), men inte ges ut av &kde; eller som en del av Plasma eller programvarusamlingen. Dessa moduler kallas för <quote
>extragear</quote
>. </para
></listitem>
    </itemizedlist>
</listitem>
</orderedlist>
</sect2>

<sect2 id="selecting-modules">
<title
>Välja moduler att bygga</title>

<para
>Att välja vilka av möjliga moduler som ska byggas styrs av <link linkend="kdesrc-buildrc"
>inställningsfilen</link
>. Efter sektionen <literal
>global</literal
> finns en lista av moduler att bygga, omgivna av raderna module ... end module. Ett exempel på en post för en modul visas i <xref linkend="conf-module-example"/>.</para>

<example id="conf-module-example">
<title
>Exempel på modulpost i inställningsfilen</title>
<programlisting
>module <replaceable
>kdesrc-build-git</replaceable>
    # Alternativ för modulen anges här, exempelvis:
    <link linkend="conf-repository"
>repository</link
> kde:kdesrc-build
    <link linkend="conf-make-options"
>make-options</link
> -j4 # Kör 4 kompileringar samtidigt
end module
</programlisting>
</example>

<note
><para
>I praktiken används oftast inte modulkonstruktionen direkt. Istället anges de flesta moduler via moduluppsättningar som beskrivs nedan.</para
></note>

<para
>När bara poster som <literal
>module</literal
> används, bygger &kdesrc-build; dem i ordningen som anges, och försöker inte ladda ner några andra arkiv utom de som är direkt angivna. </para>

</sect2>

<sect2 id="module-sets">
<title
>Moduluppsättningar</title>

<para
>&kde;:s källkod är uppdelad i ett stort antal relativ små Git-baserade arkiv. För att göra det enklare att hantera det stora antalet arkiv som är inblandade i alla användbara &kde;-baserade installationer, stöder &kdesrc-build; gruppering av flera moduler och att behandla gruppen som en <quote
>moduluppsättning</quote
>. </para>

<sect3 id="module-set-concept">
<title
>Moduluppsättningarnas grundkoncept</title>

<para
>Genom att använda en moduluppsättning kan man enkelt deklarera att många Git-moduler ska laddas ner och byggas, som om en separat moduldeklaration skrevs ut för var och en av dem. Alternativet <link linkend="conf-repository"
>repository</link
> hanteras på ett särskilt sätt för att ställa in varifrån varje modul laddas ner, medan alla andra alternativ som finns i moduluppsättningen kopieras till varje modul som skapas på detta sätt.</para>

<example id="example-using-module-sets">
<title
>Använda moduluppsättningar</title>
<programlisting
>global
    <option
><link linkend="conf-git-repository-base"
>git-repository-base</link
></option
> <replaceable
>kde-git</replaceable
> <replaceable
>kde:</replaceable>
end global

module <replaceable
>qt</replaceable>
    # Alternativ borttagna för korthets skull
end module

module-set <replaceable
>kde-support-libs</replaceable>
    <option
><link linkend="conf-repository"
>repository</link
></option
> <replaceable
>kde-git</replaceable>
    <option
><link linkend="conf-use-modules"
>use-modules</link
></option
> <replaceable
>automoc</replaceable
> <replaceable
>attica</replaceable
> <replaceable
>akonadi</replaceable>
end module-set

# Övriga moduler efter behov...
module <replaceable
>kdesupport</replaceable>
end module
</programlisting>
</example>

<para
>I <xref linkend="example-using-module-sets"/> visas en kortfattad moduluppsättning. När &kdesrc-build; träffar på moduluppsättningen, beter det sig som om en individuell modul har skapats för varje modul angiven i <option
>use-modules</option
> lika med moduluppsättningens <option
>repository</option
> omedelbart följt av det angivna modulnamnet.</para>

<para
>Dessutom kan andra alternativ tas med i en moduluppsättning, som kopieras till varje ny modul som skapas på detta sätt. Genom att använda moduluppsättningar är det möjligt att snabbt deklarera många Git-moduler som är baserade på webbadressen för samma arkiv. Dessutom är det möjligt att namnge moduluppsättningar (som visas i exemplet), vilket gör det möjligt att snabbt referera till hela gruppen av moduler på kommandoraden.</para>

</sect3>
<sect3 id="module-sets-kde">
<title
>Särskilt stöd för KDE:s moduluppsättningar</title>

<para
>Stödet för moduluppsättningar som hittills beskrivits är generell för vilken Git-baserad modul som helst. För &kde;:s Git-arkiv innehåller &kdesrc-build; ytterligare funktioner för att göra saker lättare för användare och utvecklare. Stödet aktiveras genom att ange <literal
>kde-projects</literal
> som <option
>repository</option
> för moduluppsättningen. </para>

<para
>&kdesrc-build; bygger normalt bara modulerna som är listade i inställningsfilen, i ordningen som de listas. Men med moduluppsättningen <literal
>kde-projects</literal
>, kan &kdesrc-build; utföra beroendehantering för &kde;-specifika moduler, och dessutom automatiskt inkludera moduler i bygget även om de bara specificeras indirekt.</para>

<example id="example-using-kde-module-sets">
<title
>Använda kde-projects moduluppsättningar</title>
<programlisting
># Lägger bara till en modul för juk (arkivet kde/kdemultimedia/juk)
module-set <replaceable
>juk-set</replaceable>
    <option
>repository</option
> kde-projects
    <option
>use-modules</option
> <replaceable
>juk</replaceable>
end module-set

# Lägger till alla moduler som finns i kde/multimedia/*, inklusive juk,
# men inga andra beroenden
module-set <replaceable
>multimedia-set</replaceable>
    <option
>repository</option
> kde-projects
    <option
>use-modules</option
> <replaceable
>kde/multimedia</replaceable>
end module-set

# Lägger till alla moduler som finns i kde/multimedia/*, och alla beroenden
# på kde-projects utanför kde/kdemultimedia
module-set <replaceable
>multimedia-deps-set</replaceable>
    <option
>repository</option
> kde-projects
    <option
>use-modules</option
> <replaceable
>kde/multimedia</replaceable>
    <option
>include-dependencies</option
> <replaceable
>true</replaceable>
end module-set

# Alla moduler som skapas av dessa tre moduluppsättningar läggs automatiskt i
# korrekt beroendeordning, oberoende av inställningen av include-dependencies
</programlisting>
</example>

<tip
><para
>Konstruktionen med moduluppsättningen <literal
>kde-projects</literal
> är huvudmetoden för att ange vilka moduler som man vill bygga.</para
></tip>

<para
>Alla moduluppsättningar använder alternativen <link linkend="conf-repository"
>repository</link
> och <link linkend="conf-use-modules"
>use-modules</link
>. Moduluppsättningarna <link linkend="kde-projects-module-sets"
><literal
>kde-projects</literal
></link
> har ett fördefinierat värde på <option
>repository</option
>, men andra typer av moduluppsättningar använder också alternativet <link linkend="conf-git-repository-base"
>git-repository-base</link
>. </para>
</sect3>

</sect2>

<sect2 id="kde-projects-module-sets">
<title
>&kde;:s officiella moduldatabas</title>

<para
>&kde;:s Git-arkiv tillåter att relaterade Git-moduler grupperas i samlingar av relaterade moduler (t.ex. kdegraphics). Git känner inte till sådana grupperingar, men &kdesrc-build; kan förstå grupperna genom att använda <link linkend="module-sets"
>moduluppsättningar</link
> med alternativet <option
>repository</option
> inställt till <quote
><literal
>kde-projects</literal
></quote
>.</para>

<para
>&kdesrc-build; förstår att arkivet <literal
>kde-projects</literal
> kräver särskild hantering, och justerar kompileringsprocessen därefter. Bland annat kommer &kdesrc-build; att:</para>

<itemizedlist>

<listitem
><para
>Ladda ner den senaste moduldatabasen från <ulink url=" https://commits.kde.org/"
>&kde;:s git-arkiv</ulink
>.</para
></listitem>

<listitem
><para
>Försök att hitta en modul med det givna namnet i moduluppsättningens inställning i databasen, <option
>use-modules</option
>.</para
></listitem>

<listitem
><para
>För varje modul som hittas, slår &kdesrc-build; upp lämpligt arkiv i databasen, i själva verket baserat på inställningen <link linkend="conf-branch-group"
>branch-group</link
>. Om ett arkiv finns och är aktivt för grengruppen, använder &kdesrc-build; det automatiskt för att ladda ner eller uppdatera källkoden. </para
></listitem>

</itemizedlist>

<note
><para
>I den nuvarande databasen har vissa modulgrupper inte bara en samling moduler, utan de anger <emphasis
>också</emphasis
> sitt eget &git;-arkiv. I dessa situationer föredrar &kdesrc-build; för närvarande gruppens &git;-arkiv istället för att inkludera delmodulernas arkiv. </para
></note>

<para
>Nästa exempel visar hur man använder &kde;s moduldatabas för att installera multimediabiblioteket Phonon.</para>

<informalexample>
<programlisting
>module-set <replaceable
>media-support</replaceable>
    # Denna väljare måste vara kde-projects för att använda moduldatabasen.
    <option
><link linkend="conf-repository"
>repository</link
></option
> <literal
>kde-projects</literal>

    # Denna väljare anger vilken modul som ska sökas efter i databasen.
    <option
><link linkend="conf-use-modules"
>use-modules</link
></option
> <replaceable
>phonon/phonon</replaceable
> <replaceable
>phonon-gstreamer</replaceable
> <replaceable
>phonon-vlc</replaceable>
end module-set
</programlisting>
</informalexample>

<tip
><para
>Här används <literal
>phonon/phonon</literal
> eftersom &kdesrc-build; annars skulle behöva välja mellan projektgruppen vid namn <quote
>phonon</quote
> eller det enskilda projektet vid namn <quote
>phonon</quote
> (med den nuvarande projektdatabasen). För närvarande skulle &kdesrc-build; välja det första, vilket skulle bygga många fler gränssnitt än vad som behövs.</para
></tip>

<para
>Nästa exempel är kanske mer realistiskt, och visar en funktion som bara är tillgänglig med &kde;s moduldatabas: Att bygga alla &kde;:s grafikprogram med en enda deklaration.</para>

<informalexample>
<programlisting
>module-set <replaceable
>kdegraphics</replaceable>
    # Denna väljare måste vara kde-projects för att använda moduldatabasen.
    <option
><link linkend="conf-repository"
>repository</link
></option
> <literal
>kde-projects</literal>

    # Denna väljare anger vilka moduler som ska sökas efter i databasen.
    <option
><link linkend="conf-use-modules"
>use-modules</link
></option
> <literal
>kdegraphics/libs</literal
> <literal
>kdegraphics/*</literal>
end module-set
</programlisting>
</informalexample>

<para
>Här åskådliggörs två viktiga möjligheter:</para>

<orderedlist>

<listitem
><para
>&kdesrc-build; låter dig ange moduler som är härstammar från en given modul, utan att bygga modulen själv, genom att använda syntaxen <userinput
><replaceable
>modulnamn</replaceable
>/*</userinput
>. Det krävs i själva verket i det här fallet, eftersom basmodulen, kdegraphics, är markerad som inaktiv, så att den inte av misstag byggs med sina ättlingar. Att ange ättlingar låter &kdesrc-build; hoppa förbi den inaktiverade modulen. </para
></listitem>

<listitem
><para
>&kdesrc-build; lägger inte heller till en given modul i bygglistan mer än en gång. Det låter oss manuellt ange att <literal
>kdegraphics/libs</literal
> ska byggas först, innan resten av <literal
>kdegraphics</literal
> utan att försöka bygga <literal
>kdegraphics/libs</literal
> två gånger. Det krävdes tidigare för riktig beroendehantering, och är idag ett reservalternativ i fall &kde;:s projektdatabas saknar metadata för beroenden. </para
></listitem>
</orderedlist>
</sect2>

<sect2 id="ignoring-project-modules">
<title
>Filtrera bort &kde;:s projektmoduler</title>

<para
>Du kan bestämma dig för att du vill bygga alla program i en gruppering av &kde;-moduler <emphasis
>utom</emphasis
> ett visst program.</para>

<para
>Exempelvis inkluderar gruppen <literal
>kdeutils</literal
> ett program som heter <application
>kremotecontrol</application
>. Om datorn inte har lämplig hårdvara för att ta emot signaler som skickas från fjärrkontroller kanske du bestämmer att du inte vill ladda ner, bygga och installera <application
>kremotecontrol</application
> varje gång som <literal
>kdeutils</literal
> uppdateras.</para>

<para
>Du kan åstadkomma det genom att använda inställningsalternativet <link linkend="conf-ignore-modules"
>ignore-modules</link
>. På kommandoraden gör väljaren <link linkend="ignoring-modules"
>&cmd-ignore-modules;</link
> samma sak, men är bekvämare för att bara filtrera bort en modul en enstaka gång. </para>

<example id="example-ignoring-a-module">
<title
>Exempel på att ignorera en kde-project modul i en grupp</title>
<programlisting
>module-set <replaceable
>utils</replaceable>
    <option
><link linkend="conf-repository"
>repository</link
></option
> <literal
>kde-projects</literal>

     # Denna väljare anger vilka moduler som ska sökas efter i databasen.
    <option
><link linkend="conf-use-modules"
>use-modules</link
></option
> <replaceable
>kdeutils</replaceable>

    # Denna väljare "subtraherar bort" moduler från modulerna som väljes av use-modules ovan.
    <option
><link linkend="conf-ignore-modules"
>ignore-modules</link
></option
> <replaceable
>kremotecontrol</replaceable>
end module-set

module-set <replaceable
>graphics</replaceable>
    <option
><link linkend="conf-repository"
>repository</link
></option
> <literal
>kde-projects</literal>

    # Denna väljare anger vilka moduler som ska sökas efter i databasen.
    <option
><link linkend="conf-use-modules"
>use-modules</link
></option
> <replaceable
>extragear/graphics</replaceable>

    #  Denna väljare "subtraherar bort" moduler från modulerna som väljes av use-modules ovan.
    # I detta fall, ignoreras *både* extragear/graphics/kipi-plugins
    # och extragear/graphics/kipi-plugins/kipi-plugins-docs
    <option
><link linkend="conf-ignore-modules"
>ignore-modules</link
></option
> <replaceable
>extragear/graphics/kipi-plugins</replaceable>
end module-set
</programlisting>
</example>

</sect2>

</sect1>

<sect1 id="quick-start-conclusion">
<title
>Avslutning av komma igång</title>
<para
>Detta är huvudfunktionerna och koncepten som behövs för att komma igång med &kdesrc-build;</para>

<para
>För ytterligare information kan man fortsätta läsa igenom den här dokumentationen. I synnerhet är <link linkend="supported-cmdline-params"
>listan över kommandoradsväljare</link
> och <link linkend="conf-options-table"
>tabellen över inställningsalternativ</link
> användbara referenser.</para>

<para
>&kde;-gemenskapen upprätthåller också <ulink url="https://community.kde.org/Guidelines_and_HOWTOs/Build_from_source"
>en Wiki-referens på nätet om hur man bygger källkoden</ulink
>, som hänvisar till &kdesrc-build; och inkluderar tips och andra riktlinjer om hur verktyget används.</para>

</sect1>

</chapter>

<chapter id="features">
<title
>Skriptets funktioner</title>

<sect1 id="features-overview">
<title
>Översikt över funktioner</title>

<para
>Funktionerna i &kdesrc-build; omfattar: </para>

<itemizedlist>

<listitem
><para
>Du kan <quote
>låtsas</quote
> att utföra åtgärden. Om du skickar med <option
>--pretend</option
> eller <option
>-p</option
> på kommandoraden, ger skriptet en utförlig beskrivning av de kommandon som ska göras, utan att i själva verket utföra dem. Om du dock aldrig tidigare har kört &kdesrc-build;, bör du köra kommandot <command
>kdesrc-build <option
><link linkend="cmdline-metadata-only"
>--metadata-only</link
></option
></command
> först för att <option
>--pretend</option
> ska fungera. <tip
><para
>För en ännu utförligare beskrivning av vad &kdesrc-build; gör, prova att använda väljaren <option
>--debug</option
>. </para
></tip>

</para
></listitem>

<listitem
><para
>&kdesrc-build; kan (med hjälp av &kde;:s FTP-server) tillåta snabb utcheckning av 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å datorn. </para>

<tip
><para
>Det finns i regel inget behov för någon särskild förberedelse för att utföra en inledande utcheckning av en Git-modul, eftersom hela Git-arkivet ändå måste laddas ner, så det är lätt för servern att avgöra vad som ska sändas.</para
></tip>

<para
>Det är snabbare för dig, och hjälper till att minska lasten på de anonyma &git;-servrarna.</para>
</listitem>

<listitem
><para
>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). </para
></listitem>

<listitem
><para
>Utmärkt stöd för att bygga &Qt;-biblioteket (i det fall då &kde;-programvaran som du försöker bygga beror på en nyare version av &Qt;, som inte är tillgänglig i distributionen). </para
></listitem>

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

<listitem
><para
>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.</para>

<para
>Dessutom lägger &kdesrc-build; till <link linkend="kdesrc-build-std-flags"
>standardflaggor</link
> 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. Observera: det gäller dock inte när en (egen) verktygskedja är inställd, t.ex. <link linkend="conf-cmake-toolchain"
>cmake-toolchain</link
>. </para
></listitem>

<listitem
><para
>&kdesrc-build; kan checka ut en särskilt <link linkend="using-branches"
>gren eller tagg</link
> av en modul. Du kan också försäkra dig om att en specifik <link linkend="conf-revision"
>revision</link
> av en modul checkas ut. </para
></listitem>

<listitem
><para
>&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 <link linkend="cmdline-src-only"
>--src-only</link
> för att tala om för &kdesrc-build; att det är acceptabelt att utföra bytet. </para
></listitem>

<listitem
><para
>&kdesrc-build; kan <link linkend="partial-builds"
>checka ut delar av en modul</link
>, för de situationer där du bara behöver ett program från en stor modul. </para
></listitem>

<listitem
><para
>För utvecklare: &kdesrc-build; kommer att <link linkend="ssh-agent-reminder"
>påminna dig</link
> om du använder git+ssh:// men <application
>ssh-agent</application
> inte kör, eftersom det leder till upprepad begäran om lösenord från &ssh;. </para
></listitem>

<listitem
><para
>Kan <link linkend="deleting-build-dir"
>ta bort byggkatalogen</link
> för en modul efter den har installerats för att spara utrymme till bekostnad av framtida kompileringstid. </para
></listitem>

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

<listitem
><para
>Kan använda &sudo;, eller ett annat användarspecificerat kommando för att <link linkend="root-installation"
>installera moduler</link
> så att &kdesrc-build; inte behöver köras som systemadministratör. </para
></listitem>

<listitem
><para
>&kdesrc-build; kör normalt <link linkend="build-priority"
>med reducerad prioritet</link
> för att låta dig fortsätta använda datorn medan &kdesrc-build; arbetar. </para
></listitem>

<listitem
><para
>Har stöd för att använda &kde;:s <link linkend="using-branches"
>taggar och grenar</link
>. </para
></listitem>

<listitem
><para
>Det finns stöd för att <link linkend="resuming"
>återuppta en byggprocess</link
> från en given modul. Du kan till och med <link linkend="ignoring-modules"
>ignorera vissa moduler</link
> tillfälligt för en given byggprocess. </para
></listitem>

<listitem
><para
>&kdesrc-build; visar <link linkend="build-progress"
>förloppet för byggprocessen</link
>när &cmake; används, och tar alltid tid på byggprocessen så att du i efterhand vet hur lång tid den tog. </para
></listitem>

<listitem
><para
>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 de anonyma källkodsarkiven. </para
></listitem>

<listitem
><para
>Expanderar dina inställningsalternativ med tilde. Du kan till exempel ange: <programlisting
>qtdir ~/kdesrc/build/qt</programlisting>
</para
></listitem>

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

<listitem
><para
>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. </para
></listitem>

<listitem
><para
>Tvinga fullständig omkompilering genom att köra &kdesrc-build; med väljaren <option
>--refresh-build</option
>. </para
></listitem>

<listitem
><para
>Du kan ange diverse miljövariabler som ska användas under byggprocessen, inklusive <envar
>KDEDIR</envar
>, <envar
>QTDIR</envar
>, <envar
>DO_NOT_COMPILE</envar
> och <envar
>CXXFLAGS</envar
>. </para
></listitem>

<listitem
><para
>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. </para
></listitem>

</itemizedlist>

</sect1>

<sect1 id="kdesrc-build-logging">
<title
>Byggloggning i &kdesrc-build;</title>

<sect2 id="logging-overview">
<title
>Översikt över loggning</title>

<para
>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.</para>

<sect3 id="log-directory-layout">
<title
>Loggningskatalogens layout</title>

<para
>Loggarna lagras alltid i loggkatalogen. Platsen för loggkatalogen styrs av alternativet <link linkend="conf-log-dir"
>log-dir</link
>, som normalt är <filename class="directory"
><symbol
>${source-dir}</symbol
>/log</filename
> (där  <symbol
>${source-dir}</symbol
> är värdet av alternativet <link linkend="conf-source-dir"
>source-dir</link
>. I resten av avsnittet kallas värdet <symbol
>${log-dir}</symbol
>).</para>

<para
>I <symbol
>${log-dir}</symbol
> 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 <filename
>2004-05-26-02</filename
> skapas, där 2004-05-26 står för datumet och -02 är körnumret.</para>

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

<para
>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 <filename
>build-status</filename
> i katalogen, som låter dig avgöra vilka moduler som byggdes och vilka som misslyckades.</para>

<note
><para
>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 <filename class="directory"
><symbol
>${log-dir}</symbol
>/latest/KDE/kdelibs</filename
>, och inte i <filename class="directory"
><symbol
>${log-dir}</symbol
>/latest/kdelibs</filename
>. </para
></note>

<para
>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 <filename
>git-checkout-update.log</filename
> (för en utcheckning av en modul eller när en modul uppdateras som redan har checkats ut). Om kommandot <command
>configure</command
> kördes, kan du förvänta dig att se filen <filename
>configure.log</filename
> i katalogen.</para>

<para
>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 <filename
>build-1.log</filename
> till en fil som heter <filename
>error.log</filename
>).</para>

<para
>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 <filename
><symbol
>${log-dir}</symbol
>/latest/<replaceable
>modulnamn</replaceable
>/error.log</filename
>. </para>

<tip
><para
>Om filen <filename
>error.log</filename
> ä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.</para>

<para
>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 &git; sker), och felutmatningen finns inte i loggfilen i detta fall, utan istället i terminalen där &kdesrc-build; kördes</para>
</tip>

</sect3>
</sect2>
</sect1>

</chapter>

<chapter id="kdesrc-buildrc">
<title
>Anpassa &kdesrc-build;</title>

<sect1 id="kdesrc-buildrc-overview">
<title
>Översikt av &kdesrc-build; anpassning</title>

<para
>För att använda skriptet måste du ha en fil i din hemkatalog som heter <filename
>.kdesrc-buildrc</filename
>, som beskriver modulerna som du vill ladda ner och bygga, och eventuella alternativ eller inställningsparametrar att använda för dessa moduler. </para>

<sect2 id="kdesrc-buildrc-layout">
<title
>Inställningsfilens layout</title>

<sect3 id="kdesrc-buildrc-layout-global">
<title
>Allmän inställning</title>

<para
>Inställningsfilen börjar med allmänna alternativ, angivna enligt följande: </para>

<programlisting
>global
<replaceable
>alternativ-namn alternativ-värde</replaceable>
<replaceable
>[...]</replaceable>
end global
</programlisting>

</sect3>
<sect3 id="kdesrc-buildrc-layout-modules">
<title
>Modulinställning</title>

<para
>Den följs därefter av en eller flera modulsektioner, angivna på ett av följande två sätt: </para>

<itemizedlist>
<listitem>
<programlisting
>module <replaceable
>modul-namn</replaceable>
<replaceable
>alternativ-namn alternativ-värde</replaceable>
<replaceable
>[...]</replaceable>
end module
</programlisting>
</listitem>

<listitem>
<programlisting
>module-set <replaceable
>module-set-name</replaceable>
  repository <userinput
>kde-projects</userinput
> eller <userinput
><replaceable
>git://host.org/path/to/repo.git</replaceable
></userinput>
  use-modules <replaceable
>modulnamn</replaceable>

# Andra alternativ kan också anges
<replaceable
>alternativnamn alternativvärde</replaceable>
<replaceable
>[...]</replaceable>
end module-set
</programlisting>
</listitem>
</itemizedlist>

<important
><para
>Observera att det andra sättet, med moduluppsättningar, <emphasis
>bara fungerar för Git-baserade moduler</emphasis
>.</para
></important>

<para
>För Git-moduler måste <replaceable
>modul-namn</replaceable
> vara en modul i &kde;:s &git;-arkiv (till exempel kdeartwork eller kde-wallpapers), även om det går att undvika det om du <link linkend="conf-override-url"
>anger webbadressen i &git; manuellt</link
>. </para>

<para
>För Git-moduler kan modulnamnet vara i stort sett vad du vill, under förutsättning att det inte är en dubblett av något annat modulnamn i inställningen. Kom ihåg att källkod- och byggkatalogens layout kommer att baseras på modulnamnet om du inte använder väljaren <link linkend="conf-dest-dir"
>dest-dir</link
>. </para>

<para
>För Git <emphasis
>moduluppsättningar</emphasis
> måste dock <replaceable
>modulnamn</replaceable
> motsvara verkliga Git-moduler i det valda arkivet. Se <link linkend="conf-git-repository-base"
>git-repository-base</link
> eller <link linkend="conf-use-modules"
>use-modules</link
> för mer information. </para>

</sect3>

<sect3 id="kdesrc-buildrc-option-values">
<title
>Behandling av alternativvärden</title>

<para
>I allmänhet används hela radens innehåll efter <replaceable
>alternativnamn</replaceable
> som <replaceable
>alternativvärde</replaceable
>.</para>

<para
>En modifikation som &kdesrc-build; utför är att följden <userinput
>${<replaceable
>alternativnamn</replaceable
>}</userinput
> ersätts med värdet av det alternativet från den globala inställningen. Det låter dig referera till värden på befintliga alternativ, inklusive alternativ som redan ställts in av &kdesrc-build;.</para>

<para
>För att se ett exempel på detta i användning, se <xref linkend="make-options-example"/>.</para>

</sect3>

<sect3 id="kdesrc-buildrc-options-groups">
<title
><quote
>options</quote
>-moduler</title>

<para
>Det finns en sista typ av post i inställningsfilen, <literal
>options</literal
>-grupper, som kan anges var som helst där <literal
>module</literal
> eller <literal
>module-set</literal
> kan användas.</para>

<programlisting
>options <replaceable
>modul-namn</replaceable>
<replaceable
>alternativ-namn alternativ-värde</replaceable>
<replaceable
>[...]</replaceable>
end options
</programlisting>

<para
>En <literal
>options</literal
>-grupp kan ha inställda alternativ precis som en moduldeklaration, och är kopplad till en befintlig modul. Alla alternativ som ställs in på detta sätt används för att <emphasis
>överskrida</emphasis
> alternativ inställda för den tillhörande modulen.</para>

<important
><para
>Den tillhörande modulens namn <emphasis
>måste</emphasis
> stämma med namnet som anges i deklarationen av <literal
>options</literal
>. Var försiktig så att inte ett felstavat namn skrivs in.</para
></important>

<para
>Detta är användbart för att göra det möjligt att deklarera en hel <literal
>module-set</literal
> med moduler, som alla använder samma alternativ, och därefter använda <literal
>options</literal
>-grupper för att göra individuella ändringar.</para>

<para
>Gruppen <literal
>options</literal
> kan också gälla namngivna moduluppsättningar. Det låter expertanvändare använda en gemensam inställningsfil (som inkluderar deklarationer av <literal
>module-set</literal
>) som grundinställning, och sedan göra ändringar av alternativen som används av sådana moduluppsättningar i inställningsfiler med kommandot <literal
><link linkend="kdesrc-buildrc-including"
>include</link
></literal
> för att referera till grundinställningen.</para>

<example id="ex-options-group">
<title
>Exempel på användning av alternativ</title>

<para
>I det här exemplet väljer vi att bygga alla moduler från &kde;:s multimediaprogramvara. Dock vill vi använda en annan version av programmet &kmix; (kanske för att prova en felrättning). Det fungerar på följande sätt:</para>

<programlisting
>module-set <replaceable
>kde-multimedia-set</replaceable>
  repository <userinput
>kde-projects</userinput>
  use-modules <replaceable
>kde/kdemultimedia</replaceable>
  branch <replaceable
>master</replaceable>
end module-set

# kmix är en del av kde/kdemultimedia group, även om vi aldrig namngav
# kmix tidigare i den här filen, räknar &kdesrc-build; ut ändringen.
options <replaceable
>kmix</replaceable>
  branch <replaceable
>KDE/4.12</replaceable>
end options
</programlisting>

<para
>När &kdesrc-build; nu körs, byggs alla &kde;:s multimediaprogram från grenen <quote
>master</quote
> i källkodsarkivet, men &kmix; byggs från den äldre grenen <quote
>KDE/4.12</quote
>. Genom att använda <literal
>options</literal
>, behövde man inte lista alla de <emphasis
>andra</emphasis
> programmen i &kde;:s multimedia individuellt för att ge dem rätt grenalternativ.</para>

</example>

<note>
<para
>Observera att funktionen är bara tillgänglig i &kdesrc-build; från version 1.16, eller genom att använda utvecklingsversionen av &kdesrc-build; efter 2014-01-12.</para
></note>

</sect3>

</sect2>

<sect2 id="kdesrc-buildrc-including">
<title
>Inkludera andra inställningsfiler</title>

<para
>Inne i inställningsfilen kan du referera till andra filer genom att använda nyckelordet <literal
>include</literal
> med en fil, vilket fungerar som om den refererade filen hade infogats i inställningsfilen på det stället. </para>

<informalexample
><para
>Du skulle exempelvis kunna göra något liknande:</para>
<programlisting
>global
    include <replaceable
>~/common-kdesrc-build-options</replaceable>

    # Infoga specifika alternativ här.

end global
</programlisting>
</informalexample>

<note
><para
>Om du inte anger fullständig sökväg för filen som ska inkluderas, eftersöks filen med början i katalogen som innehåller källkodsfilen. Det fungerar också rekursivt.</para
></note>

</sect2>

<sect2 id="kdesrc-buildrc-common">
<title
>Ofta använda inställningsalternativ</title>

<para
>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 <xref linkend="conf-options-table"/>. </para>

<itemizedlist>
<listitem
><para
><link linkend="conf-cmake-options"
>cmake-options</link
> för att ange vilka flaggor en modul ska ställas in med vid användning av &cmake;.</para
></listitem>
<listitem
><para
><link linkend="conf-branch"
>branch</link
>, för att checka ut från en gren istället för <literal
>master</literal
>.</para
></listitem>
<listitem
><para
><link linkend="conf-configure-flags"
>configure-flags</link
> för att ange vilka flaggor &Qt; ska ställas in med.</para
></listitem>
<listitem
><para
><link linkend="conf-kdedir"
>kdedir</link
>, för att ange katalogen där &kde; ska installeras.</para
></listitem>
<listitem
><para
><link linkend="conf-make-options"
>make-options</link
>, för att skicka väljare till byggprogrammet &make; (såsom antal processorer att använda).</para
></listitem>
<listitem
><para
><link linkend="conf-qtdir"
>qtdir</link
>, för att ange sökvägen till &Qt;.</para
></listitem>
<listitem
><para
><link linkend="conf-source-dir"
>source-dir</link
>, för att ändra vart källkoden laddas ner.</para
></listitem>
</itemizedlist>

</sect2>
</sect1>
<sect1 id="conf-options-table">
<title
>Tabell av tillgängliga inställningsalternativ</title>

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

<itemizedlist>

<listitem
><para
>Alternativets namn</para
></listitem>

<listitem
><para
>En beskrivning av hur &kdesrc-build; beter sig om alternativet både är angivet i den allmänna sektionen och modulsektionen i <link linkend="configure-data"
>inställningsfilen</link
> när modulen byggs.</para
></listitem>

<listitem
><para
>Särskilda kommentarer om alternativets syfte och användning.</para
></listitem>

</itemizedlist>

<table id="option-table">
<title
>Alternativtabell</title>
<tgroup cols="3">

<thead>
<row>
<entry
>Alternativnamn</entry>
<entry
>Modul -&gt; Allmänt beteende</entry>
<entry
>Anmärkningar</entry>
</row>
</thead>

<tbody>

<row id="conf-async">
<entry
>async</entry>
<entry
>Kan inte överskridas</entry>
<entry
><para
>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 <userinput
>false</userinput
>.</para>
<para
>Alternativet är tillgängligt från och med utgåva 1.6.</para
></entry>
</row>

<row id="conf-binpath">
<entry
>binpath</entry>
<entry
>Modulinställning överskrider allmän</entry>
<entry
><para
>Ange alternativet för att sätta miljövariabeln PATH under byggprocessen. Du kan inte överskrida alternativet i ett modulalternativ. Förvalt värde är $<envar
>PATH</envar
> som är inställd när skriptet startar. Miljövariabeln ska innehålla sökvägar till utvecklingsverktygen åtskilda med kolon. Sökvägarna <filename class="directory"
>$<envar
>KDEDIR</envar
>/bin</filename
> och <filename class="directory"
>$<envar
>QTDIR</envar
>/bin</filename
> läggs automatiskt till. Du kan använda tilde (~) för eventuella sökvägar du lägger till med det här alternativet.</para>
</entry>
</row>

<row id="conf-branch">
<entry
>branch</entry>
<entry
>Modulinställning överskrider allmän</entry>
<entry
><para
>Ställ in alternativet för att checka ut från en gren av &kde; istället för standardvärdet <replaceable
>master</replaceable
> där utveckling av &kde; sker.</para>

<para
>För att till exempel checka ut grenen &kde; 4.6, skulle du ställa in alternativet till <replaceable
>4.6</replaceable
>.</para>

<para
>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 <link linkend="conf-module-base-path"
>module-base-path</link
> eller <link linkend="conf-override-url"
>override-url</link
>.</para>

<note
><para
>För de flesta &kde;-moduler vill man troligtvis använda alternativet <link linkend="conf-branch-group"
>branch-group</link
> istället och använda det här alternativet för undantag från fall till fall.</para
></note>

</entry>
</row>

<row id="conf-branch-group">
<entry
>branch-group</entry>
<entry
>Modulinställning överskrider allmän</entry>
<entry>

<para
>Ställ in alternativet till en allmän grupp som du vill att moduler ska väljas från.</para>

<para
>För modultyper i &git; som stöds, bestämmer &kdesrc-build; den verkliga grenen att använda baserat på regler kodade av &kde;-utvecklarna (reglerna kan ses i källkodsarkivet <literal
>kde-build-metadata</literal
> i din källkodskatalog). Efter att en gren har bestämts används den som om du hade angivit den själv med alternativet <link linkend="conf-branch"
>branch</link
>. </para>

<para
>Det är användbart om du bara försöker upprätthålla senaste version för ett antal normala utvecklingsspår utan att behöva ta hänsyn till alla ändringar av namn på grenar.</para>

<para
>Observera att om du <emphasis
>själv</emphasis
> använder <literal
>branch</literal
> överskrider det den här inställningen. Samma sak gäller andra specifika alternativ för att välja gren såsom <link linkend="conf-tag"
>tag</link
>.</para>

<para
>Väljaren lades till i &kdesrc-build; 1.16-pre2.</para>

<note
><para
>Väljaren gäller bara &git; moduler i <literal
>kde-projects</literal
> (det vanliga fallet). Se också <xref linkend="kde-projects-module-sets"/>. </para
></note>

</entry>
</row>

<row id="conf-build-dir">
<entry
>build-dir</entry>
<entry
>Modulinställning överskrider allmän</entry>
<entry
>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: <orderedlist
><listitem
><para
>Relativt till &kde;:s &git;-källkodskatalog (se <link linkend="conf-source-dir"
>alternativet source-dir</link
>). Det är förvalt, och väljes om du skriver in ett katalognamn som inte börjar med tilde (~) eller snedstreck (/).</para
><para
>Förvalt värde är <filename class="directory"
>build</filename
></para
></listitem
><listitem
><para
>Absolut sökväg. Om du anger en sökväg som börjar med /, används sökvägen direkt. Till exempel <filename class="directory"
>/tmp/kde-obj-dir/</filename
></para
></listitem
><listitem
><para
>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 <filename class="directory"
>~/builddir</filename
> ställa in byggkatalogen till <filename class="directory"
>/home/användarnamn/builddir</filename
></para
></listitem
> </orderedlist
>Alternativet kan, kanske något oväntat, ändras per modul. </entry>
</row>

<row id="conf-build-when-unchanged">
<entry
>build-when-unchanged</entry>
<entry
>Modulinställning överskrider allmän</entry>
<entry
><para
>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.</para>

<para
>Genom att ställa in <option
>build-when-unchanged</option
> till <userinput
>true</userinput
>, 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.</para>

<para
>Genom att ställa in <option
>build-when-unchanged</option
> till <userinput
>false</userinput
>, 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.</para>

<important
><para
>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 eller kdelibs leda till att andra moduler måste byggas om, även om källkoden inte ändras alls.</para
></important>
</entry>
</row>

<row id="conf-cmake-generator">
<entry
>cmake-generator</entry>
<entry
>Modulinställning överskrider allmän</entry>
<entry
><para
>Använd alternativet för att ange vilken generator som ska användas med &cmake;. För närvarande stöds både <literal
>Ninja</literal
> och <literal
>Unix Makefiles</literal
> samt extra generatorer baserade på dem såsom <literal
>Eclipse CDT4 - Ninja</literal
>. Ogiltiga värden (som inte stöds) ignoreras, och behandlas som inte angivet. Om inte angivet används <literal
>Unix Makefiles</literal
> som förval. </para>

<para
>Observera att om en giltig generator också anges via <link linkend="conf-cmake-options"
>cmake-options</link
> överskrider den värdet på <literal
>cmake-generator</literal
>.</para
></entry>
</row>

<row id="conf-cmake-toolchain">
<entry
>cmake-toolchain</entry>
<entry
>Modulinställning överskrider allmän</entry>
<entry
><para
>Använd alternativet för att ange en verktygskedjefil att använda med &cmake;. </para>
<para
>När en giltig verktygskedjefil är inställd, kommer &kdesrc-build; <emphasis
>inte ställa in miljövariabler automatiskt</emphasis
>. Du kan använda &set-env;, &binpath; och &libpath; för att manuellt rätta miljön om verktygskedjefilen inte fungerar som den är med &kdesrc-build;. Se <link linkend="kdesrc-build-std-flags"
>översikten över standardflaggor som läggs till av &kdesrc-build;</link
> för mer information. </para>
<para
>Observera att om en giltig verktygskedja också anges via <link linkend="conf-cmake-options"
>cmake-options</link
> överskrider den värdet på <literal
>cmake-toolchain</literal
>.</para
></entry>
</row>

<row id="conf-cmake-options">
<entry
>cmake-options</entry>
<entry
>Lägger till globala alternativ för det normala byggsystemet, överskrider global för andra byggsystem.</entry>
<entry
><para
>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.</para>

<para
>Alternativet gäller inte för qt (som inte använder &cmake;). Använd <link linkend="conf-configure-flags"
>configure-flags</link
> istället.</para>

<para
>Om en giltig generator anges bland de listade alternativen överskrider den värdet på <link linkend="conf-cmake-generator"
>cmake-generator</link
>. Ogiltiga generatorer (som inte stöds) ignoreras och skickas inte till &cmake;. </para>

<para
>Om en giltig verktygskedja anges bland de listade alternativen överskrider den värdet på <link linkend="conf-cmake-toolchain"
>cmake-toolchain</link
>. Ogiltiga verktygskedjor ignoreras och skickas inte till &cmake;. </para>

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

<screen
>cmake-options -DCMAKE_BUILD_TYPE=RelWithDebInfo
</screen>

<para
>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, <emphasis
>nödvändiga</emphasis
> parametrar för &cmake; ställs in automatiskt åt dig.)</para
></entry>
</row>

<row id="conf-colorful-output">
<entry
>colorful-output</entry>
<entry
>Kan inte överskridas</entry>
<entry
>Ställ in alternativet till <userinput
>false</userinput
> för att inaktivera den färgglada utmatningen från &kdesrc-build;. Alternativet har standardvärdet <replaceable
>true</replaceable
>. 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;). </entry>
</row>

<row id="conf-compile-commands-export">
<entry
>compile-commands-export</entry>
<entry
>Modulinställning överskrider allmän</entry>
<entry>
<para
>Aktiverar generering av <literal
>compile_commands.json</literal
> via CMake i byggkatalogen. Alternativet har förvalt värde <replaceable
>true</replaceable
>, ställ in det till <userinput
>false</userinput
> för att inaktivera beteendet. </para>
</entry>
</row>

<row id="conf-compile-commands-linking">
<entry
>compile-commands-linking</entry>
<entry
>Modulinställning överskrider allmän</entry>
<entry>
<para
>Aktiverar att skapa symboliska länkar från <literal
>compile_commands.json</literal
> genererad via CMake i byggkatalogen till motsvarande källkodskatalog. Alternativet har förvalt värde <replaceable
>false</replaceable
>, ställ in det till <userinput
>true</userinput
> för att aktivera att den symboliska länken automatiskt skapas. </para>
</entry>
</row>

<row id="conf-configure-flags">
<entry
>configure-flags</entry>
<entry
>Lägger till globala alternativ för det normala byggsystemet, överskrider global för andra byggsystem.</entry>
<entry
><para
>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. <emphasis
>Alternativet  fungerar bara för qt.</emphasis
></para>

<para
>För att ändra konfigurationsinställningar för KDE-moduler, se <link linkend="conf-cmake-options"
>cmake-options</link
>. </para>
</entry>
</row>

<row id="conf-custom-build-command">
<entry
>custom-build-command</entry>
<entry
>Modulinställning överskrider global (alternativ i byggsystemet)</entry>
<entry>
    <para
>Alternativet kan anges för att köra ett annorlunda kommando (exempelvis annat än <command
>make</command
>) för att utföra byggprocessen. &kdesrc-build; bör i allmänhet göra rätt, så alternativet ska inte behövas anges. Det kan dock vara användbart för att använda alternativa byggsystem. </para>

    <para
>Alternativets värde används som kommandoraden att köra, ändrad av <link linkend="conf-make-options"
>make-options</link
> som vanligt. </para>
</entry>
</row>

<row id="conf-cxxflags">
<entry
>cxxflags</entry>
<entry
>Lägger till globala alternativ för det normala byggsystemet, överskrider global för andra byggsystem.</entry>
<entry
><para
>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 <link linkend="conf-configure-flags"
>configure-flags</link
> eller <link linkend="conf-cmake-options"
>cmake-options</link
> eftersom alternativet också sätter miljövariabeln <envar
>CXXFLAGS</envar
> under byggprocessen.</para>

<para
>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 <userinput
>none</userinput
> när modulen konfigureras. Det kan göras med alternativet <link linkend="conf-cmake-options"
>cmake-options</link
>. </para>
</entry>
</row>

<row id="conf-dest-dir">
<entry
>dest-dir</entry>
<entry
>Modulinställning överskrider allmän</entry>
<entry
>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 <link linkend="conf-build-dir"
>build-dir</link
> eller <link linkend="conf-source-dir"
>source-dir</link
> alternativ. </entry>
</row>

<row id="conf-disable-agent-check">
<entry
>disable-agent-check</entry>
<entry
>Kan inte överskridas</entry>
<entry
>Om du använder &ssh; för att ladda ner källkod från &git; (om du använder protokollet git+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 <option
>disable-agent-check</option
> till <userinput
>true</userinput
>. </entry>
</row>

<row id="conf-do-not-compile">
<entry
>do-not-compile</entry>
<entry
>Modulinställning överskrider allmän</entry>
<entry
><para
>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.</para>

<para
>Observera att källkoden till programmen fortfarande laddas ner.</para>

<para
>För att exempelvis inaktivera bygge av katalogerna <literal
>codeeditor</literal
> och <literal
>minimaltest</literal
> i ramverket <literal
>syntaxhighlighting</literal
>, skulle du lägga till <userinput
>do-not-compile codeeditor minimaltest</userinput
>, och lägga till "do-not-compile juk kscd" i alternativen för syntaxfärgläggning.</para>

<para
>Se <xref linkend="not-compiling"/> för ett exempel.</para>
</entry>
</row>

<row id="conf-git-desired-protocol">
<entry
>git-desired-protocol</entry>
<entry
>Kan inte överskridas</entry>
<entry
><para
>Väljaren gäller bara moduler från ett arkiv som ingår i <link linkend="kde-projects-module-sets"
>&kde;-projektet</link
>.</para>

<para
>Vad väljaren i själva verket gör är att ställa in vilket nätverksprotokoll som ska föredras när källkod för dessa moduler laddas upp. Normalt används det mycket effektiva protokollet <literal
>git</literal
>, men det kan vara blockerat i vissa nätverk (t.ex. interna företagsnätverk, öppna wifi-nätverk). Ett alternativt protokoll som stöds mycket bättre är protokollet <literal
>https</literal
> som används för webbplatser på Internet.</para>

<para
>Om du använder ett av dessa begränsade nätverk kan du ändra väljaren till <userinput
>http</userinput
> för att föredra kommunikation med <literal
>https</literal
> istället.</para>

<tip
><para
>Du kan också behöva väljaren <link linkend="conf-http-proxy"
>http-proxy</link
>, om en HTTP-proxy också behövs för nätverkstrafik.</para
></tip>

<para
>I alla andra situationer ska väljaren inte användas, eftersom standardprotokollet är det effektivaste.</para>

<para
>Väljaren lades till i &kdesrc-build; 1.16. Innan 20.06 användes väljaren för att ställa in hämtningswebbadressen istället för uppladdningswebbadressen. Från 20.06 används alltid <literal
>https</literal
> när KDE-projekt uppdateras.</para>
</entry>
</row>

<row id="conf-git-repository-base">
<entry
>git-repository-base</entry>
<entry
>Kan inte överskridas</entry>
<entry
><para
>Det här alternativet, tillagt i version 1.12.1, används för att skapa ett kort namn för att hänvisa till en specifik baswebbadress för ett Git-arkiv i senare deklarationer av <link linkend="module-sets"
>moduluppsättningar</link
>, vilket är användbart för att snabbt deklarera många Git-moduler att bygga.</para>

<para
>Två saker måste anges (åtskilda med ett mellanslag): Namnet som baswebbadressen ska tilldelas till, och själva baswebbadressen. Till exempel:</para>

<para>
<informalexample>
<programlisting
>global
   # Andra alternativ

   # Det här är den gemensamma sökvägen till alla anonyma Git-servermoduler.
   git-repository-base <replaceable
>kde-git</replaceable
><replaceable
>kde:</replaceable>
end global

# Moduldeklarationer

module-set
   # Nu kan det alias som definierades tidigare användas, men 
   # <emphasis
>bara</emphasis
>i en moduluppsättning.
   repository <replaceable
>kde-git</replaceable>

   <link linkend="conf-use-modules"
>use-modules</link
> <replaceable
>module1.git</replaceable
> <replaceable
>module2.git</replaceable>
end module-set
</programlisting>
</informalexample>
</para>

<para
>Moduluppsättningarnas alternativ <literal
>use-modules</literal
> skapar två moduler internt, och &kdesrc-build; beter sig som om det hade läst in:</para>

<programlisting
>module module1
    repository kde:<replaceable
>module1.git</replaceable>
end module

module module2
    repository kde:<replaceable
>module2.git</replaceable>
end module
</programlisting>

<para
>Prefixet <literal
>kde:</literal
> för &git;-arkiv som används ovan är en genväg som automatiskt ställs in av &kdesrc-build;. Se teknikbasens artikel <ulink url="https://techbase.kde.org/Development/Git/Configuration#URL_Renaming"
>URL Renaming</ulink
> för mer information. Observera att i motsats till de flesta andra alternativ kan detta anges flera gånger för att skapa så många alias som behövs.</para>

<tip
><para
>Det är inte nödvändigt att använda alternativet för att dra fördel av moduluppsättningar. Alternativet finns för att göra det enkelt att använda samma arkiv för många olika moduluppsättningar.</para
></tip>
</entry>
</row>

<row id="conf-git-user">
<entry
>git-user</entry>
<entry
>Modulinställning överskrider allmän</entry>
<entry>
<para
>Alternativet är avsett för &kde;-utvecklare. Om det anges, används det för att automatiskt ställa in identitetsinformation för källkodshanteringssystemet &git; för <emphasis
>nyligen nerladdade</emphasis
> &git;-moduler (inklusive det stora flertalet &kde;-moduler).</para>

<para
>Specifikt fylls användarens namn och e-postfält i till de värden som anges med alternativet för varje nytt &git;-arkiv.</para>

<para
>Värdet måste anges på formen <option
><replaceable
>Användarnamn</replaceable
> &lt;<replaceable
>e-post@exempel.se</replaceable
>&gt;</option
>.</para>

<para>
<informalexample>
<para
>Exempelvis skulle en utvecklare vid namn <quote
>Anna Johansson</quote
> med e-postadressen <quote
>anna@exempel.se</quote
> använda:</para>

<screen
><symbol
>git-user</symbol
> <replaceable
>Anna Johansson</replaceable
> &lt;<replaceable
>anna@exempel.se</replaceable
>&gt;
</screen>
</informalexample>
</para>

<para
>Alternativet introducerades i &kdesrc-build; 15.09. </para>
</entry>
</row>

<row id="conf-http-proxy">
<entry
>http-proxy</entry>
<entry
>Modulinställning överskrider allmän</entry>

<entry
><para
>Alternativet, om det anges, använder den givna webbadressen som proxyserver för all nätverkskommunikation via HTTP (till exempel när sparade versioner laddas ner för nya moduler, eller <link linkend="kde-projects-module-sets"
>KDE:s projektdatabas</link
>).</para>

<para
>Dessutom försöker &kdesrc-build; försäkra sig om att verktygen det beror på också använder proxyservern, om möjligt, genom att ställa in miljövariabeln <envar
>http_proxy</envar
> till den angivna servern, <emphasis
>om denna miljövariabel inte redan finns</emphasis
>.</para>

<para
>Alternativet lades till i &kdesrc-build; 1.16.</para>
</entry>
</row>

<row id="conf-directory-layout">
<entry
>directory-layout</entry>
<entry
>Modulinställning överskrider allmän</entry>
<entry
><para
>Alternativet används för att ställa in den layout som &kdesrc-build; ska använda när källkods- och byggkataloger skapas.</para>
<para
>För närvarande finns tre möjliga värden: <userinput
>flat</userinput
>, <userinput
>invent</userinput
> och <userinput
>metadata</userinput
></para>
<para
>Layouten <userinput
>flat</userinput
> är förvalt värde grupperar alla moduler direkt under källkods- och byggkatalogerna på toppnivå. Exempelvis skulle <literal
>source/extragear/network/telepathy/ktp-text-ui</literal
> med layouten<userinput
>metadata</userinput
> vara <literal
>source/ktp-text-ui</literal
> vid användning av layouten <userinput
>flat</userinput
> istället. </para>
<para
>Layouten <userinput
>invent</userinput
> skapar en kataloghierarki som speglar de relativa sökvägarna för arkiv på <ulink url="https://invent.kde.org/"
>invent.kde.org</ulink
>. Exempelvis skulle <literal
>source/kde/applications/kate</literal
> med layouten <userinput
>metadata</userinput
> vara <literal
>source/utilities/kate</literal
> vid användning av layouten <userinput
>invent</userinput
> istället. Layouten påverkar bara KDE-projekt. Det är ett bra val för folk som börjar använda &kdesrc-build;. </para>
<para
>Slutligen är layouten <userinput
>metadata</userinput
> samma som det tidigare förvalda beteendet. Layouten organiserar KDE-projekt enligt projektsökvägarna specificerade i projektets metadata för modulerna. Det är ett bra val om du vill ha en kataloglayout som följer vissa KDE-processer, men observera att sökvägen därför inte alltid är stabil. Resultatet kan bli att &kdesrc-build; överger en gammal kopia av arkivet och skapar en dubblett för ett projekt på grund av ändringar av projektets metadata.</para>
</entry>
</row>

<row id="conf-ignore-modules">
<entry
>ignore-modules</entry>
<entry
>Kan inte överskridas</entry>
<entry
><para
>Moduler som namnges av alternativet, som skulle ha valts av &kdesrc-build; på grund av alternativet <link linkend="conf-use-modules"
>use-modules</link
>, hoppas istället över helt. Använd alternativet när du vill bygga en hel gruppering av <link linkend="kde-projects-module-sets"
>kde-project</link
> projekt <emphasis
>utom</emphasis
> några specifika moduler.</para>

<para
>Alternativets värde behöver inte nödvändigtvis namnge modulen direkt. Vilken modul som helst där fullständiga delar i följd av dess <link linkend="kde-projects-module-sets"
>&kde; projektmodul-sökväg</link
> matchar ett av alternativets värden ignoreras, så det går alltså att ignorera flera moduler på detta sätt.</para>

<para
>Exempelvis skulle alternativvärdet <replaceable
>libs</replaceable
> göra att både <symbol
>kde/kdegraphics/libs</symbol
> och <symbol
>playground/libs</symbol
> skulle exkluderas (dock inte <symbol
>kde/kdelibs</symbol
> eftersom den fullständiga delen <quote
>kdelibs</quote
> är det som jämförs med).</para>

<tip
><para
>Se också <xref linkend="example-ignoring-a-module"/>.</para
></tip>

<para
>Alternativet lades till i &kdesrc-build; 1.16.</para>
</entry>
</row>

<row id="conf-include-dependencies">
<entry
>include-dependencies</entry>
<entry
>Modulinställning överskrider allmän</entry>
<entry>
<para
>När alternativet är <userinput
>true</userinput
>, begär det att &kdesrc-build; också ska inkludera den här modulens kända beroenden i bygget, utan att kräva att du nämner dessa beroenden (inte ens indirekt).</para>

<note
><para
>Alternativet fungerar bara för moduler baserade på <link linkend="kde-projects-module-sets"
><literal
>kde-project</literal
></link
>, och kräver att metadata som underhålls av &kde;-utvecklare är korrekt för vald <link linkend="conf-branch-group"
>branch-group</link
>.</para
></note>

<para
>Alternativet är normalt aktiverat för att stödja att bygga program som behöver versioner av &Qt; eller &plasma; som är senare en de som stöds av vanliga operativsystem.</para>
</entry>
</row>

<row id="conf-install-after-build">
<entry
>install-after-build</entry>
<entry
>Modulinställning överskrider allmän</entry>
<entry
>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 <userinput
>false</userinput
> i <link linkend="configure-data"
>inställningsfilen</link
>. Du kan också använda kommandoradsväljaren <link linkend="cmdline-no-install"
><option
>--no-install</option
></link
>. </entry>
</row>

<row id="conf-install-environment-driver">
<entry
>install-environment-driver</entry>
<entry
>Kan inte överskridas</entry>
<entry
><para
>Normalt försöker &kdesrc-build; installera ett skalskript som kan anropas i användarens profilinställningsskript för att enkelt upprätta nödvändiga miljövariabler för att köra Plasma-skrivbordet som byggts av &kdesrc-build;.</para>

<para
>Drivrutinen ändra följande filer:</para>

<itemizedlist>
<listitem
><para
><filename
>$XDG_CONFIG_HOME/kde-env-master.sh</filename
> (som normalt finns som <filename
>~/.config/kde-env-master.sh</filename
>).</para
></listitem>
<listitem
><para
><filename
>$XDG_CONFIG_HOME/kde-env-user.sh</filename
> (som normalt finns som <filename
>~/.config/kde-env-user.sh</filename
>).</para
></listitem>
</itemizedlist>

<para
>Skriptet <filename
>kde-env-user.sh</filename
> är valfritt. Det är avsett för användaranpassning (se avsnittet <ulink url="https://userbase.kde.org/KDE_System_Administration/Environment_Variables#Troubleshooting_and_Debugging"
>Troubleshooting and Debugging</ulink
> på &kde;:s användarbas för exempel på anpassningsbara inställningar), men inställningarna kan göras på andra ställen av användaren i befintliga profilinställningsskript.</para>

<para
>Funktionen kan inaktiveras genom att ställa in alternativet till <replaceable
>false</replaceable
>, och försäkra att också alternativet <link linkend="conf-install-session-driver"
>install-session-driver</link
> är inaktiverat.</para>

<para
>Alternativet lades till i &kdesrc-build; 17.08.</para>

<tip
><para
>&kdesrc-build; skriver inte över befintliga filer om du inte också anger kommandoradsväljaren <option
><link linkend="cmdline-delete-my-settings"
>--delete-my-settings</link
></option
>.</para
></tip>
</entry>
</row>

<row id="conf-install-session-driver">
<entry
>install-session-driver</entry>
<entry
>Kan inte överskridas</entry>
<entry
><para
>Om aktiverat, försöker &kdesrc-build; installera en drivrutin för den grafiska inloggningshanteraren som låter dig logga in på &kde;-skrivbordet som byggts med &kdesrc-build;.</para>

<para
>Drivrutinen ändra följande filer:</para>

<itemizedlist>
<listitem
><para
><filename
>~/.xsession</filename
></para
></listitem>
<listitem
><para
><filename
>$XDG_CONFIG_HOME/kde-env-master.sh</filename
> (som normalt finns som <filename
>~/.config/kde-env-master.sh</filename
>).</para
></listitem>
<listitem
><para
><filename
>$XDG_CONFIG_HOME/kde-env-user.sh</filename
> (som normalt finns som <filename
>~/.config/kde-env-user.sh</filename
>).</para
></listitem>
</itemizedlist>

<para
>Om du hanterar en egen inloggningshanterare kan du inaktivera funktionen genom att ställa in alternativet till <replaceable
>false</replaceable
>. Om aktiverad, aktiverar funktionen också funktionen <link linkend="conf-install-environment-driver"
>install-environment-driver</link
>.</para>

<para
>Alternativet lades till i &kdesrc-build; 1.16.</para>

<tip
><para
>&kdesrc-build; skriver inte över befintliga filer om du inte också anger kommandoradsväljaren <option
><link linkend="cmdline-delete-my-settings"
>--delete-my-settings</link
></option
>.</para
></tip>
</entry>
</row>

<row id="conf-kdedir">
<entry
>kdedir</entry>
<entry
>Modulinställning överskrider allmän</entry>
<entry
>Det här alternativet anger katalogen som &kde; installeras i efter det har byggts. Förvalt värde är <filename class="directory"
>~/kde</filename
>. Om du ändrar det till en katalog som kräver åtkomst som systemadministratör, bör du också läsa om alternativet <link linkend="conf-make-install-prefix"
>make-install-prefix</link
>.</entry>
</row>

<row id="conf-libname">
<entry
>libname</entry>
<entry
>Modulinställning överskrider allmän</entry>
<entry
>Ställ in det här alternativet för att ändra standardnamnet på det installerade bibliotekskatalogen inuti $<envar
>KDEDIR</envar
> och $<envar
>QTDIR</envar
>. På många system är detta antingen "lib" eller "lib64". Automatisk identifiering försöker göras för att ställa in rätt namn som förval, men om gissningen är fel så kan det ändras med inställningen. </entry>
</row>

<row id="conf-libpath">
<entry
>libpath</entry>
<entry
>Modulinställning överskrider allmän</entry>
<entry
>Ange alternativet för att sätta miljövariabeln <envar
>LD_LIBRARY_PATH</envar
> under byggprocessen. Du kan inte överskrida inställningen med ett modulalternativ. Förvalt värde är tomt, men sökvägarna <filename class="directory"
>$<envar
>KDEDIR</envar
>/$<envar
>LIBNAME</envar
></filename
> och <filename class="directory"
>$<envar
>QTDIR</envar
>/$<envar
>LIBNAME</envar
></filename
> läggs automatiskt till. Du kan använda tilde (~) i alla sökvägar du lägger till med alternativet. </entry>
</row>

<row id="conf-log-dir">
<entry
>log-dir</entry>
<entry
>Modulinställning överskrider allmän</entry>
<entry
>Använd det här alternativet för att ändra katalogen som används för att lagra loggfiler som skapas av skriptet. </entry>
</row>

<row id="conf-make-install-prefix">
<entry
>make-install-prefix</entry>
<entry
>Modulinställning överskrider allmän</entry>
<entry
>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 <userinput
><command
>make</command
> <option
>install</option
></userinput
> 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.</entry>
</row>

<row id="conf-make-options">
<entry
>make-options</entry>
<entry
>Modulinställning överskrider global (alternativ i byggsystemet)</entry>
<entry
><para
>Ange den här variabeln för att skicka kommandoradsväljare till kommandot <command
>make</command
>. Det är användbart för program som <ulink url="https://github.com/distcc/distcc"
><application
>distcc</application
></ulink
> eller system med mer än en processorkärna.</para>
<para
>Observera att inte alla byggsystem som stöds använder <command
>make</command
>. För byggsystem som använder <command
>ninja</command
> för att bygga (såsom  <link linkend="conf-override-build-system"
>byggsystemet <application
>Meson</application
></link
>, se inställningen <link linkend="conf-ninja-options"
>ninja-options</link
>.</para>
</entry>
</row>

<row id="conf-manual-build">
<entry
>manual-build</entry>
<entry
>Modulinställning överskrider allmän</entry>
<entry
>Sätt alternativvärdet till <userinput
>true</userinput
> för att förhindra att byggprocessen försöker bygga modulen. Den hålls fortfarande uppdaterad vid uppdatering från &git;. Alternativet motsvarar exakt kommandoradsväljaren <link linkend="cmdline-no-build"
><option
>--no-build</option
></link
>. </entry>
</row>

<row id="conf-manual-update">
<entry
>manual-update</entry>
<entry
>Modulinställning överskrider allmän</entry>
<entry
>Sätt alternativvärdet till <userinput
>true</userinput
> 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. </entry>
</row>

<row id="conf-module-base-path">
<entry
>module-base-path</entry>
<entry
>Modulinställning överskrider allmän</entry>
<entry
><para
>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. <ulink url="https://invent.kde.org/"
>&kde;:s källkodsvisning</ulink
> är ovärderlig som hjälp för att välja rätt sökväg.</para>

<para
>Observera att &kdesrc-build; konstruerar den slutliga sökvägen enligt följande mall: <filename class="directory"
><varname
>$repository</varname
>/home/kde/<varname
>$module-base-path</varname
></filename
>. </para>

<para
>Förvalt värde är antingen <filename class="directory"
><varname
>$module</varname
></filename
> eller <filename class="directory"
>KDE/<varname
>$module</varname
></filename
>, beroende på modulnamnet.</para>

<tip
><para
>Använd alternativen <link linkend="conf-branch"
>branch</link
> eller <link linkend="conf-tag"
>tag</link
> istället så snart de är tillämpliga. </para
></tip>
</entry>
</row>

<row id="conf-niceness">
<entry
>niceness</entry>
<entry
>Kan inte överskridas</entry>
<entry
>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. </entry>
</row>

<row id="conf-ninja-options">
<entry
>ninja-options</entry>
<entry
>Modulinställning överskrider global (alternativ i byggsystemet)</entry>
<entry
><para
>Ställ in variabeln för att skicka kommandoradsväljare till byggkommandot <command
>ninja</command
>. Det kan vara användbart för att aktivera <quote
>detaljerad</quote
> utmatning eller för att manuellt reducera antal byggjobb som <command
>ninja</command
> skulle använda.</para>

<note
><para
>Observera att inställningen bara styr ninja när det används med &kdesrc-build;. &Qt;-modulen <quote
>webengine</quote
> använder <command
>ninja</command
> indirekt, men stöder bara officiellt att byggas med <command
>make</command
>. I detta fall kan <literal
>NINJAFLAGS</literal
> ställas in som ett sätt att låta <command
>make</command
> skicka lämpliga flaggor när det senare anropar <command
>ninja</command
>, genom att använda <link linkend="conf-make-options"
>make-options</link
>.</para>

<informalexample>
<programlisting
>options <replaceable
>qtwebengine</replaceable>
    # Begränsa make och ninja att inte använda fler än 6 separata kompileringsjobb
    # även om fler processorer är tillgängliga, för att undvika att få slut på minne
    <option
><link linkend="conf-make-options"
>make-options</link
></option
> -j<replaceable
>6</replaceable
> NINJAFLAGS=-j<replaceable
>6</replaceable>
end options
</programlisting>
</informalexample>
</note>
</entry>
</row>

<row id="conf-no-src">
<entry
>no-src</entry>
<entry
>Modulinställning överskrider allmän</entry>
<entry
>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.</entry>
</row>

<row id="conf-num-cores">
<entry
>num-cores</entry>
<entry
>Kan inte överskridas</entry>
<entry>
<para
>Alternativet definieras av &kdesrc-build; (när verktyget kdesrc-build-setup används eller <command
>kdesrc-build --initial-setup</command
>) till antal tillgängliga processorer (som indikeras av det externa programmet <application
>nproc</application
>). Om &kdesrc-build; inte kan detektera antal processorer, ställs värdet in till 4.</para>

<para
>Se <xref linkend="make-options-example"/> för ett exempel på användning av alternativet. Alternativet lades till i version 20.07.</para>
</entry>
</row>

<row id="conf-num-cores-low-mem">
<entry
>num-cores-low-mem</entry>
<entry
>Kan inte överskridas</entry>
<entry>
<para
>Alternativet definieras av &kdesrc-build; (när verktyget kdesrc-build-setup används eller <command
>kdesrc-build --initial-setup</command
>) till antal processorer som anses vara säkert för tunga eller andra högintensiva moduler, såsom <literal
>qtwebengine</literal
>, för att undvika att minnet tar slut under bygget.</para>

<para
>Den typiska beräkningen är en processorkärna per 2 Gibibyte (GiB) totalt minne. Åtminstone en kärna anges, och inte fler än <option
><link linkend="conf-num-cores"
>num-cores</link
></option
>.</para>

<para
>Även om alternativet är avsett att stödja &Qt;-moduler, kan det användas för vilken modul som helst på samma sätt som <option
>num-cores</option
> används.</para>

<para
>Om &kdesrc-build; inte kan detektera tillgängligt minne ställs värdet in till 2.</para>

<para
>Alternativet lades till i version 20.07.</para>
</entry>
</row>

<row id="conf-override-build-system">
<entry
>override-build-system</entry>
<entry
>Modulinställning överskrider allmän</entry>
<entry
><para
>Det här är en avancerad väljare, tillagd i &kdesrc-build; 1.16.</para>

<para
>Normalt detekterar &kdesrc-build; lämpligt byggsystem att använda för en modul när den har laddats ner. Det görs genom att kontrollera att specifika filer finns i modulens källkodskatalog.</para>

<para
>Vissa moduler kan innehålla mer än en uppsättning filer som krävs, vilket skulle kunna förvirra den automatiska detekteringen. I detta fall kan du ange rätt byggtyp manuellt.</para>

<para
>De byggtyper som för närvarande stöds och kan anges är:</para>

<variablelist>
    <varlistentry>
        <term
>KDE</term>
        <listitem
><para
>Används för att bygga &kde;-moduler. I själva verket kan den användas för att bygga nästan vilken modul som helst som använder &cmake;, men det är bäst att inte förlita sig på det.</para
></listitem>
    </varlistentry>
    <varlistentry>
        <term
>Qt</term>
        <listitem
><para
>Används för att bygga själva &Qt;-biblioteket.</para
></listitem>
    </varlistentry>
    <varlistentry>
        <term
>qmake</term>
        <listitem
><para
>Används för att bygga &Qt;-moduler som använder <literal
>.pro</literal
>-filer i enlighet med <application
>qmake</application
>.</para
></listitem>
    </varlistentry>
    <varlistentry>
        <term
>generic</term>
        <listitem
><para
>Används för att bygga moduler som använder enkla Makefiles och inte kräver någon särskild konfigurering.</para
></listitem>
    </varlistentry>
    <varlistentry>
        <term
>autotools</term>
        <listitem
><para
>Det här är det standardiserade konfigureringsverktyget som används för de flesta programvaror med fri och öppen källkod som inte ingår i någon av de övriga kategorierna.</para
></listitem>
    </varlistentry>
    <varlistentry>
        <term
>meson</term>
        <listitem
><para
>Detta är ett <ulink url="https://mesonbuild.com"
>relativt nytt verktyg</ulink
> som ökar i popularitet som en ersättning till autotools, och kan krävas för vissa moduler som inte ingår i &kde;.</para
></listitem>
    </varlistentry>
</variablelist>

</entry>
</row>

<row id="conf-override-url">
<entry
>override-url</entry>
<entry
>Modulinställning överskrider allmän</entry>
<entry
>Om du anger det här alternativet, använder &kdesrc-build; dess värde som webbadress att skicka till &git; <emphasis
>helt oförändrad</emphasis
>. 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 <link linkend="conf-branch"
>branch</link
>. </entry>
</row>

<row id="conf-persistent-data-file">
<entry
>persistent-data-file</entry>
<entry
>Kan inte överskridas</entry>
<entry
><para
>Använd väljaren för att ändra var &kdesrc-build; lagrar bestående data. Normalt lagras sådan data i en fil som heter <filename
>.kdesrc-build-data</filename
> i samma katalog som inställningsfilen som används. Om den allmänna inställningsfilen används, lagras den i <filename
>~/.local/state/kdesrc-build-data</filename
> (<filename
>$XDG_STATE_HOME/kdesrc-build-data</filename
>, om <envar
>$XDG_STATE_HOME</envar
> är angivet). Om du har flera tillgängliga inställningar i samma katalog, kan det vara bra att ställa in alternativet så att de olika inställningarna inte råkar ut för konflikter i bestående data. </para>

<para
>Väljaren lades till i &kdesrc-build; 1.15.</para>
</entry>
</row>

<row id="conf-prefix">
<entry
>prefix</entry>
<entry
>Modulinställning överskrider allmän</entry>
<entry
><para
>Alternativet bestämmer var en modul installeras (normalt används inställningen <option
><link linkend="conf-kdedir"
>kdedir</link
></option
>). 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.</para>
<para
>Du kan använda <varname
>${MODULE}</varname
> eller <varname
>$MODULE</varname
> i sökvägen för att expandera dem till modulens namn.</para>
</entry>
</row>

<row id="conf-purge-old-logs">
<entry
>purge-old-logs</entry>
<entry
>Modulinställning överskrider allmän</entry>
<entry
><para
>Alternativet bestämmer om gamla loggkataloger automatiskt tas bort eller inte. Standardvärdet är <replaceable
>true</replaceable
>.</para>
</entry>
</row>

<row id="conf-qmake-options">
<entry
>qmake-options</entry>
<entry
>Modulinställning överskrider allmän</entry>

<entry
><para
>Alla väljare som anges här skickas till kommandot <command
>qmake</command
>, för moduler som använder byggsystemet <symbol
>qmake</symbol
>. Det går exempelvis att använda väljaren <userinput
>PREFIX=/sökväg/till/qt</userinput
> i qmake för att överskrida var modulen installeras. </para>
<para
>Väljaren lades till i &kdesrc-build; 1.16.</para>
</entry>
</row>

<row id="conf-qtdir">
<entry
>qtdir</entry>
<entry
>Modulinställning överskrider allmän</entry>
<entry
>Ange alternativet för att sätta miljövariabeln <envar
>QTDIR</envar
> under byggprocessen. Om alternativet inte anges, antar &kdesrc-build; att &Qt; tillhandahålls av operativsystemet. </entry>
</row>

<row id="conf-remove-after-install">
<entry
>remove-after-install</entry>
<entry
>Modulinställning överskrider allmän</entry>
<entry
><para
>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. </para>
<para
>Möjliga värden för alternativet är: <itemizedlist>
<listitem
><para
>none - Ta inte bort någonting (det är normalvärdet).</para
></listitem>
<listitem
><para
>builddir - Ta bort byggkatalogen men inte källkoden.</para
></listitem>
<listitem
><para
>all - Ta både bort källkoden och byggkatalogen.</para
></listitem>
</itemizedlist>
</para>

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

<row id="conf-repository">
<entry
>repository</entry>
<entry
>Modulinställning överskrider allmän</entry>
<entry
><para
>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) behöver alternativet, samt diverse &kde;-moduler som håller på att konverteras att använda &git;.</para
></entry>
</row>

<row id="conf-revision">
<entry
>revision</entry>
<entry
>Modulinställning överskrider allmän</entry>
<entry
><para
>Om alternativet ställs in till ett annat värde än 0 (noll), tvingar &kdesrc-build; uppdateringen att ge modulen exakt den version som anges, även om alternativ som <link linkend="conf-branch"
>branch</link
> gäller. Om modulen redan har angiven version, kommer den inte att uppdateras ytterligare om inte alternativet ändras eller tas bort från konfigurationen.</para>

<note
><para
>Väljaren fungerade inte för git-baserade moduler (inklusive moduler från <link linkend="kde-projects-module-sets"
>kde-projects</link
>) innan &kdesrc-build; version 1.16.</para
></note>

</entry>
</row>

<row id="conf-run-tests">
<entry
>run-tests</entry>
<entry
>Modulinställning överskrider global (alternativ i byggsystemet)</entry>
<entry
>Om satt till <userinput
>true</userinput
>, 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.</entry>
</row>

<row id="conf-set-env">
<entry
>set-env</entry>
<entry
>Modulinställning överskrider allmän</entry>
<entry
><para
>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 <envar
>RONALD</envar
> till McDonald, skulle du skriva följande kommando under lämplig sektion:</para>
<screen
><command
>set-env</command
> <envar
>RONALD</envar
> <userinput
>McDonald</userinput
></screen>
<para
>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 <link linkend="configure-data"
>inställningsfilen</link
>. På så sätt kan du ställa in mer än en miljövariabel per modul (eller allmänt).</para>
</entry>
</row>

<row id="conf-source-dir">
<entry
>source-dir</entry>
<entry
>Modulinställning överskrider allmän</entry>
<entry
>Det här alternativet används för att ange katalogen på datorn där &kde;:s &git;-källkod ska lagras. Om du inte anger värdet, är förvalt värde <filename class="directory"
>~/kde/src</filename
>. Tilde (~) kan utnyttjas för att representera hemkatalogen om alternativet används. </entry>
</row>

<row id="conf-ssh-identity-file">
<entry
>ssh-identity-file</entry>
<entry
>Kan inte överskridas</entry>
<entry>
<para
>Sätt alternativet för att bestämma vilken privat SSH nyckelfil används av kommandot <command
>ssh-add</command
> när &kdesrc-build; laddar ner källkod från arkiv som kräver behörighetskontroll. Se också: <xref linkend="ssh-agent-reminder"/>.</para>

<para
>Alternativet lades till i version 1.14.2.</para>
</entry>
</row>

<row id="conf-stop-on-failure">
<entry
>stop-on-failure</entry>
<entry
>Modulinställning överskrider allmän</entry>
<entry
>Ställ in det här alternativvärdet till <userinput
>false</userinput
> för att låta skriptet fortsätta köra efter ett fel uppstår i bygg- eller installationsprocessen. Normalvärdet är <literal
>true</literal
>. </entry>
</row>

<row id="conf-tag">
<entry
>tag</entry>
<entry
>Modulinställning överskrider allmän</entry>
<entry
><para
>Använd väljaren för att ladda ner en specifik utgåva av en modul.</para>
<para
><emphasis
>Observera:</emphasis
> Chansen är mycket stor att du <emphasis
>inte vill</emphasis
> använda alternativet. Utgåvor av &kde; är tillgängliga som komprimerade tar-arkiv från <ulink url="https://download.kde.org/"
>&kde;:s nerladdningsplats</ulink
>.</para>

<note
><para
>Väljaren har bara varit stödd för git-baserade moduler sedan &kdesrc-build; 1.16.</para
></note>
</entry>
</row>

<row id="conf-use-clean-install">
<entry
>use-clean-install</entry>
<entry
>Modulinställning överskrider global (alternativ i byggsystemet)</entry>
<entry
><para
>Sätt det här alternativet till <userinput
>true</userinput
> för att få &kdesrc-build; att köra <command
>make uninstall</command
> direkt innan <command
>make install</command
> körs.</para>

<para
>Det kan vara användbart för att försäkra sig om att inte några kvarblivna gamla biblioteksfiler, &cmake; metadata, etc. kan orsaka problem i långlivade installationer av &kde;. Dock fungerar det bara med byggsystem som stöder <command
>make uninstall</command
>.</para>

<para
>Väljaren lades till i &kdesrc-build; 1.12, men dokumenterades inte förrän i &kdesrc-build; 1.16.</para>
</entry>
</row>

<row id="conf-use-idle-io-priority">
<entry
>use-idle-io-priority</entry>
<entry
>Kan inte överskridas</entry>
<entry
>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 <userinput
>true</userinput
>. </entry>
</row>

<row id="conf-use-inactive-modules">
<entry
>use-inactive-modules</entry>
<entry
>Kan inte överskridas</entry>
<entry
>När det aktiveras låter det här alternativet kdesrc-build också klona och hämta från arkiv som är markerade som inaktiva. Förval är att det är inaktiverat, för att tillåta inaktiva moduler att ställa in det till <userinput
>true</userinput
>. </entry>
</row>

<row id="conf-use-modules">
<entry
>use-modules</entry>
<entry
>Kan bara användas i <link linkend="module-sets"
>moduluppsättningar</link
></entry>
<entry
><para
>Det här alternativet, tillagt i &kdesrc-build; 1.12.1, gör det möjligt att enkelt specificera många olika moduler som ska byggas på samma ställe i <link linkend="kdesrc-buildrc"
>inställningsfilen</link
>.</para>

<para
>Det här alternativet <emphasis
>måste</emphasis
> användas med en <literal
>moduluppsättning</literal
>. Varje identifierare som används i alternativet konverteras internt till en &kdesrc-build;-modul, med alternativet <link linkend="conf-repository"
><option
>repository</option
></link
> inställt till moduluppsättningens arkiv, kombinerat med identifierarens namn för att slutgiltigt kunna bestämma arkivet att ladda ner från. Alla andra alternativ som finns i moduluppsättningen kopieras också till de skapade modulerna utan ändring.</para>

<para
>Ordningen som modulerna definieras i alternativet är viktigt eftersom det också är ordningen som &kdesrc-build; kommer att behandla de skapade modulerna vid uppdatering, byggning och installation. Alla moduler definierade i en given moduluppsättning kommer att hanteras innan &kdesrc-build; går vidare till nästa modul efter moduluppsättningen.</para>

<para
>Om alternativ för en skapad modul måste ändras, deklarera helt enkelt modulen igen efter den har definierats i moduluppsättningen och ställ in alternativen efter behov. Även om alternativen som modulen använder kommer att ändras på detta sätt, uppdateras och byggs modulen ändå i ordningen som anges av moduluppsättningen (dvs. du kan inte ordna om byggföljden genom att göra det).</para>

<important
><para
>Namnet att använda för modulen om du gör det, är helt enkelt namnet du angav i <option
>use-modules</option
>, med undantag för att ett eventuellt <literal
>.git</literal
> tas bort.</para
></important>

<para
>Se <xref linkend="module-sets"/> och <link linkend="conf-git-repository-base"
>git-repository-base</link
> för en beskrivning av dess användning och ett exempel.</para>
</entry>
</row>

</tbody>

</tgroup>
</table>

</sect1>
</chapter>

<chapter id="cmdline">
<title
>Kommandoradsväljare och miljövariabler</title>

<sect1 id="cmdline-usage">
<title
>Användning av kommandoraden</title>

<para
>&kdesrc-build; är konstruerat för att köras på följande sätt:</para>

<cmdsynopsis
><command
>kdesrc-build</command
> <arg rep="repeat"
><replaceable
>--väljare</replaceable
></arg
> <arg rep="repeat"
><replaceable
>moduler att bygga</replaceable
></arg
> </cmdsynopsis>

<para
>Om inga moduler att bygga anges på kommandoraden, bygger &kdesrc-build; alla moduler som är definierade i inställningsfilen, i den ordning de anges i filen (även om det kan ändras av diverse alternativ i inställningsfilen).</para>

<sect2 id="cmdline-usage-options">
<title
>Ofta använda kommandoradsväljare</title>

<para
>Den fullständiga listan med kommandoradsväljare anges i <xref linkend="supported-cmdline-params"/>. De oftast använda väljarna omfattar:</para>

<variablelist>
  <varlistentry>
    <term
><option
>--pretend</option
> (eller <option
>-p</option
>)</term>
    <listitem
><para
>Väljaren gör att &kdesrc-build; indikerar vilka åtgärder som skulle utföras, utan att verkligen implementera dem. Det kan vara användbart för att försäkra dig om att modulerna som du tror du bygger verkligen kommer att byggas.</para
></listitem>
  </varlistentry>

  <varlistentry>
    <term
><option
>--refresh-build</option
></term>
    <listitem
><para
>Väljaren tvingar &kdesrc-build; att bygga de angivna modulerna från en fullständigt ren utgångspunkt. Eventuella befintliga byggkataloger för modulerna tas bort och byggs om. Väljaren är användbar om du får fel när en modul byggs, och krävs ibland när &Qt;- eller &kde;-bibliotek ändras.</para
></listitem>
  </varlistentry>

  <varlistentry>
    <term
><option
>--no-src</option
></term>
    <listitem
><para
>Alternativet hoppar över uppdateringsprocessen av källkoden. Du kan vilja använda det om du uppdaterade källkoden nyligen (kanske gjorde du det manuellt, eller körde nyligen &kdesrc-build;), men ändå vill bygga om vissa moduler.</para
></listitem>
  </varlistentry>

  <varlistentry>
    <term
><option
>--no-build</option
></term>
    <listitem
><para
>Väljaren liknar <option
>--no-src</option
> ovan, men den här gången hoppas byggprocessen över.</para
></listitem>
  </varlistentry>
</variablelist>

</sect2>

<sect2 id="cmdline-usage-modules">
<title
>Ange moduler att bygga</title>

<para
>I allmänhet är det så enkelt som att ange modulnamnet definierat i inställningsfilen för att ange moduler att bygga. Du kan också ange moduler som ingår i en moduluppsättning, antingen som de namnges under <link linkend="conf-use-modules"
>use-modules</link
>, eller med hela moduluppsättningen, om du har givit den ett namn.</para>

<para
>I det specifika fallet med moduluppsättningar baserade på <link linkend="kde-projects-module-sets"
>KDE:s projektdatabas</link
>, expanderar &kdesrc-build; modulnamnets komponenter för att bestämma exakt den modul du vill ha. Exempelvis placerar KDE:s projektposten för &kdesrc-build; projektet i <literal
>extragear/utils/kdesrc-build</literal
>. Du måste ange något av följande för att bygga &kdesrc-build;:</para>

<informalexample>
<screen
><prompt
>&percnt;</prompt
> <command
>kdesrc-build</command
> <option
><replaceable
>+extragear/utils/kdesrc-build</replaceable
></option>
<prompt
>&percnt;</prompt
> <command
>kdesrc-build</command
> <option
><replaceable
>+utils/kdesrc-build</replaceable
></option>
<prompt
>&percnt;</prompt
> <command
>kdesrc-build</command
> <option
><replaceable
>+kdesrc-build</replaceable
></option
>
</screen>
</informalexample>

<note
><para
>Kommandona i föregående exempel inledde modulnamn med <symbol
>+</symbol
>. Det tvingar modulnamnet att tolkas som en modul från KDE:s projektdatabas, även om modulen inte har definierats i inställningsfilen. </para
></note>

<para
>Var försiktig med att ange mycket generella projekt (t.ex. <literal
>extragear/utils</literal
> ensamt), eftersom det kan leda till att ett stort antal moduler byggs. Du bör använda väljaren <option
>--pretend</option
> innan en ny modul byggs för att försäkra dig om att bara de moduler du vill kommer att byggas.</para>

</sect2>
</sect1>

<sect1 id="supported-envvars">
<title
>Miljövariabler som stöds</title>

<para
>&kdesrc-build; använder inte miljövariabler. Om du behöver sätta miljövariabler för bygg- eller installationsprocessen, se alternativet <link linkend="conf-set-env"
>set.-env</link
>. </para>

</sect1>

<sect1 id="supported-cmdline-params">
<title
>Kommandoradsväljare som stöds</title>

<para
>Skriptet accepterar följande kommandoradsväljare: </para>

<variablelist>

<varlistentry id="cmdline-async">
<term
><parameter
>--async</parameter
></term>
<listitem
><para
>Aktiverar <link linkend="conf-async"
>asynkront användningssätt</link
> 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. </para
></listitem>
</varlistentry>

<varlistentry id="cmdline-help">
<term
><parameter
>--help</parameter
> (eller <parameter
>-h</parameter
>)</term>
<listitem
><para
>Visa bara enkel hjälp om skriptet. </para
></listitem>
</varlistentry>

<varlistentry id="cmdline-version">
<term
><parameter
>--version</parameter
> (eller <parameter
>-v</parameter
>)</term>
<listitem
><para
>Visa programmets version. </para
></listitem>
</varlistentry>

<varlistentry id="cmdline-show-info">
<term
><parameter
>--show-info</parameter
></term>
<listitem
><para
>Visar information om &kdesrc-build; och operativsystemet, vilket kan vara användbart i felrapporter eller när hjälp efterfrågas på forum eller e-postlistor. </para>
<para
>Tillgängligt sedan version 18.11.</para>
</listitem>
</varlistentry>

<varlistentry id="cmdline-initial-setup">
<term
><parameter
>--initial-setup</parameter
></term>
<listitem
><para
>Låter &kdesrc-build; utföra en initial engångsinställning nödvändig för att förbereda systemet så att &kdesrc-build; kan fungera, och så att den nyinstallerade &kde;-programvaran kan köra. </para>
<para
>Det omfattar:</para>
<itemizedlist>
<listitem
><para
>Installera kända beroenden (på &Linux;-distributioner som stöds)</para
></listitem>
<listitem
><para
>Lägga till nödvändiga miljövariabler i <literal
>~/.bashrc</literal
></para
></listitem>
<listitem
><para
>Ställa in en <link linkend="setup-rcfile"
>inställningsfil</link
></para
></listitem>
</itemizedlist>

<para
>Tillgängligt sedan version 18.11.</para>
</listitem>
</varlistentry>

<varlistentry id="cmdline-author">
<term
><parameter
>--author</parameter
></term>
<listitem
><para
>Visa upphovsmannens kontaktinformation. </para
></listitem>
</varlistentry>

<varlistentry id="cmdline-color">
<term
><parameter
>--color</parameter
></term>
<listitem
><para
>Aktivera färglagd utmatning. (Det är förval för interaktiva terminaler.) </para
></listitem>
</varlistentry>

<varlistentry id="cmdline-nice">
<term
><parameter
>--nice=<replaceable
>värde</replaceable
></parameter
></term>
<listitem
><para
>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 <quote
>snällt</quote
>), 20 är lägst prioritet. &kdesrc-build; har förvalt värde 10. </para
></listitem>
</varlistentry>

<varlistentry id="cmdline-no-async">
<term
><parameter
>--no-async</parameter
></term>
<listitem
><para
>Inaktiverar <link linkend="conf-async"
>asynkront användningssätt</link
> 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 <ulink url="https://bugs.kde.org/"
>felrapport</ulink
>. </para
></listitem>
</varlistentry>

<varlistentry id="cmdline-no-color">
<term
><parameter
>--no-color</parameter
></term>
<listitem
><para
>Inaktivera färglagd utmatning. </para
></listitem>
</varlistentry>

<varlistentry id="cmdline-pretend">
<term
><parameter
>--pretend</parameter
> (eller <parameter
>-p</parameter
>)</term>
<listitem
><para
>&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.).</para>

<note
><para
>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). </para
></note>

<important
><para
>Alternativet kräver att viss nödvändig metadata är tillgänglig, vilken normalt laddas ner automatiskt, men nerladdningar är inaktiverade i låtsasläge. Om du aldrig har kört &kdesrc-build; (och därför inte har denna metadata), måste du först köra kommandot <command
>kdesrc-build <option
>--metadata-only</option
></command
> för att ladda ner nödvändig metadata. </para
></important>
</listitem>
</varlistentry>

<varlistentry id="cmdline-quiet">
<term
><parameter
>--quiet</parameter
> (eller <parameter
>-q</parameter
>)</term>
<listitem
><para
>Var inte så högljudd med utmatningen. Med den här väljaren matas bara det viktigaste ut. </para
></listitem>
</varlistentry>

<varlistentry id="cmdline-really-quiet">
<term
><parameter
>--really-quiet</parameter
></term>
<listitem
><para
>Mata bara ut varningar och fel. </para
></listitem>
</varlistentry>

<varlistentry id="cmdline-verbose">
<term
><parameter
>--verbose</parameter
></term>
<listitem
><para
>Beskriv i detalj vad som händer, och vad &kdesrc-build; gör. </para
></listitem>
</varlistentry>

<varlistentry id="cmdline-src-only">
<term
><parameter
>--src-only</parameter
> (eller <parameter
>-s</parameter
>)</term>
<listitem
><para
>Utför bara uppdatering av källkoden. </para
></listitem>
</varlistentry>

<varlistentry id="cmdline-build-only">
<term
><parameter
>--build-only</parameter
></term>
<listitem
><para
>Utför bara byggprocessen. </para
></listitem>
</varlistentry>

<varlistentry id="cmdline-install-only">
<term
><parameter
>--install-only</parameter
></term>
<listitem
><para
>Utför bara installationsprocessen. </para
></listitem>
</varlistentry>

<varlistentry id="cmdline-metadata-only">
<term
><parameter
>--metadata-only</parameter
></term>
<listitem
><para
>Utför bara processen för nerladdning av metadata. &kdesrc-build; hanterar det normalt automatiskt, men det går att använda detta för att få  kommandoradsväljaren <option
><link linkend="cmdline-pretend"
>--pretend</link
></option
> att fungera. </para
></listitem>
</varlistentry>

<varlistentry id="cmdline-rebuild-failures">
<term
><parameter
>--rebuild-failures</parameter
></term>
<listitem
><para
>Använd väljaren för att bara bygga moduler som misslyckades byggas vid en tidigare körning av &kdesrc-build;. Det är användbart om ett väsentligt antal misslyckanden inträffade, blandat med lyckade byggen. Efter att ha rättat problemet som orsakade misslyckade byggen är det enkelt att bara bygga modulerna som tidigare misslyckades.</para>

<note
><para
>Observera att listan med <quote
>tidigare misslyckade moduler</quote
> nollställs varje gång en körning av &kdesrc-build; blir klar med några misslyckade moduler. Den nollställs dock inte av ett fullständigt lyckat bygge, så det är möjligt att bygga om några moduler med lyckat resultat och ändå använda väljaren.</para
></note>

<para
>Väljaren lades till i &kdesrc-build; 15.09.</para>
</listitem>
</varlistentry>

<varlistentry id="cmdline-include-dependencies">
<term
><parameter
>--include-dependencies</parameter
> (eller <parameter
>-d</parameter
>)</term>
<term
><parameter
>--no-include-dependencies</parameter
> (eller <parameter
>-D</parameter
>)</term>
<listitem
><para
>Väljaren gör att &kdesrc-build; automatiskt inkluderar andra &kde;- och &Qt;-moduler i byggprocessen, om det krävs för modulerna som du har krävt ska byggas på kommandoraden eller i <link linkend="configure-data"
>inställningsfilen</link
>.</para>

<para
>Modulerna som läggs till lagras i &kde;:s källkodshanteringssystem. Se <xref linkend="kde-projects-module-sets"/>.</para>

<para
>Motsvarande alternativ i inställningsfilen är <link linkend="conf-include-dependencies"
>include-dependencies</link
>.</para>

<para
>Du kan också använda <parameter
>--no-include-dependencies</parameter
>, som stänger av att automatiskt inkludera ytterligare beroendemoduler.</para>
</listitem>
</varlistentry>

<varlistentry id="cmdline-ignore-modules">
<term
><parameter
>--ignore-modules</parameter
> (eller <parameter
>-!</parameter
>)</term>
<listitem
><para
>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 <link linkend="configure-data"
>inställningsfilen</link
> och bara hoppa över några få). </para
></listitem>
</varlistentry>

<varlistentry id="cmdline-no-src">
<term
><parameter
>--no-src</parameter
> (eller <parameter
>-S</parameter
>)</term>
<listitem
><para
>Hoppa över att kontakta &git;-servern. </para
></listitem>
</varlistentry>

<varlistentry id="cmdline-no-build">
<term
><parameter
>--no-build</parameter
></term>
<listitem
><para
>Hoppa över byggprocessen. </para
></listitem>
</varlistentry>

<varlistentry id="cmdline-no-metadata">
<term
><parameter
>--no-metadata</parameter
></term>
<listitem
><para
>Ladda inte automatiskt ner den extra metadata som behövs för &kde;:s git-moduler. Uppdateringen av själva modulernas källkod sker ändå om du inte också använder <link linkend="cmdline-no-src"
>--no-src</link
>. </para
><para
>Detta kan vara användbart om du ofta kör om &kdesrc-build;, eftersom metadata inte ändras särskilt ofta. Observera dock att många andra funktioner kräver att metadata är tillgänglig. Du bör fundera på att köra &kdesrc-build; med väljaren <link linkend="cmdline-metadata-only"
>--metadata-only</link
> en gång och därefter använda den här väljaren för efterföljande körningar. </para
></listitem>
</varlistentry>

<varlistentry id="cmdline-no-install">
<term
><parameter
>--no-install</parameter
></term>
<listitem
><para
>Installera inte automatiskt paket efter de har byggts. </para
></listitem>
</varlistentry>

<varlistentry id="cmdline-no-build-when-unchanged">
<term
><parameter
>--no-build-when-unchanged</parameter
></term>
<term
><parameter
>--force-build</parameter
></term>
<listitem
><para
>Det här alternativet inaktiverar explicit att hoppa över byggprocessen (en optimering styrd av alternativet <link linkend="conf-build-when-unchanged"
>build-when-unchanged</link
>). 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.</para>

<para
><parameter
>--force-build</parameter
> utför exakt samma funktion, och är kanske enklare att komma ihåg.</para>
</listitem>
</varlistentry>

<varlistentry id="cmdline-debug">
<term
><parameter
>--debug</parameter
></term>
<listitem
><para
>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. </para
></listitem>
</varlistentry>

<varlistentry id="cmdline-query">
<term
><parameter
>--query</parameter
>=<userinput
><replaceable
>typ</replaceable
></userinput
></term>
<listitem
><para
>Det här kommandot gör att &kdesrc-build; frågar efter en parameter i modulerna i bygglistan (antingen angivna på kommandoraden eller inlästa från inställningsfilen), och skriver ut resultatet på skärmen (en modul per rad).</para>

<para
>Väljaren måste anges med en <quote
>frågetyp</quote
>, som ska vara en av följande:</para>
    <itemizedlist>
    <listitem
><para
><option
>source-dir</option
>, vilket gör att &kdesrc-build; skriver ut den fullständiga sökvägen där modulens källkod är lagrad. </para
></listitem>
    <listitem
><para
><option
>build-dir</option
>, vilket gör att &kdesrc-build; skriver ut den fullständiga sökvägen där modulens byggprocess sker. </para
></listitem>
    <listitem
><para
><option
>install-dir</option
>, vilket gör att &kdesrc-build; skriver ut den fullständiga sökvägen där modulen installeras. </para
></listitem>
    <listitem
><para
><option
>project-path</option
>, vilket gör att &kdesrc-build;  skriver ut modulens plats i hierarkin av KDE:s källkodsarkiv. Se <xref linkend="kde-projects-module-sets"/> för mer information om denna hierarki. </para
></listitem>
    <listitem
><para
><option
>branch</option
>, vilket gör att &kdesrc-build; skriver ut den upplösta grenen i git som används för varje modul, baserat på gällande inställningar för <link linkend="conf-tag"
>tag</link
>, <link linkend="conf-branch"
>branch</link
> och <link linkend="conf-branch-group"
>branch-group</link
>. </para
></listitem>
    <listitem
><para
>Annars kan namn som är giltiga för moduler i <link linkend="conf-options-table"
>inställningsfilen</link
> användas som väljare, så listas det upplösta värdet för varje modul. </para
></listitem>
    </itemizedlist>

<para
>Om en enda modul anges på kommandoraden är utdata helt enkelt värdet på parametern som efterfrågas. Om flera (eller inga) moduler anges på kommandoraden, inleds varje rad med modulens namn. I båda fall slutar &kdesrc-build; att köra när värdena är utskrivna. </para>

<para
>Väljaren lades till i &kdesrc-build; 16.05.</para>

<informalexample>
<para
>Exempelvis kommandot <quote
><command
>kdesrc-build</command
> <parameter
>--query</parameter
> <parameter
><replaceable
>branch</replaceable
></parameter
> <parameter
><replaceable
>kactivities</replaceable
></parameter
> <parameter
><replaceable
>kdepim</replaceable
></parameter
></quote
> kan sluta med följande utdata:</para>
<screen
>kactivities: master
kdepim: master
</screen>
</informalexample>
</listitem>
</varlistentry>

<varlistentry id="cmdline-refresh-build">
<term
><parameter
>--refresh-build</parameter
> (eller <parameter
>-r</parameter
>)</term>
<listitem
><para
>Skapa om byggsystemet och bygg från grunden. </para
></listitem>
</varlistentry>

<varlistentry id="cmdline-reconfigure">
<term
><parameter
>--reconfigure</parameter
></term>
<listitem
><para
>Kör <command
>cmake</command
> (för &kde;-moduler) eller <command
>configure</command
> (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 <parameter
><link linkend="cmdline-refresh-build"
>--refresh-build</link
></parameter
> används. </para
></listitem>
</varlistentry>

<varlistentry id="cmdline-resume-from">
<term
><parameter
>--resume-from</parameter
> (eller <parameter
>--from</parameter
> eller <parameter
>-f</parameter
>)</term>
<listitem
><para
>Alternativet är användbart för att återuppta byggprocessen från den angivna modulen, som ska vara nästa alternativ på kommandoraden. Man ska inte ange andra modulnamn på kommandoraden. </para>

<note
><para
>Alternativet lade tidigare till <link linkend="cmdline-no-src"
><parameter
>--no-src</parameter
></link
>, men gör inte det längre (sedan &kdesrc-build; 1.13). Om du vill undvika uppdateringar av källkod vid återupptagande, skicka helt enkelt också med <option
><userinput
>--no-src</userinput
></option
> förutom övriga alternativ. </para
></note>

<para
>Se också: <xref linkend="cmdline-resume-after"/> och <xref linkend="resuming-failed"/>. 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.</para
></listitem>
</varlistentry>

<varlistentry id="cmdline-resume-after">
<term
><parameter
>--resume-after</parameter
> (eller <parameter
>--after</parameter
> eller <parameter
>-a</parameter
>)</term>
<listitem
><para
>Alternativet används för att återuppta byggprocessen efter den angivna modulen, som ska vara nästa alternativ på kommandoraden. Man ska inte ange andra modulnamn på kommandoraden. </para>

<note
><para
>Alternativet lade tidigare till <link linkend="cmdline-no-src"
><parameter
>--no-src</parameter
></link
>, men gör inte det längre (sedan &kdesrc-build; 1.13). Om du vill undvika uppdateringar av källkod vid återupptagande, skicka helt enkelt också med <option
><userinput
>--no-src</userinput
></option
> förutom övriga alternativ. </para
></note>

<para
>Se också: <xref linkend="cmdline-resume-from"/> och <xref linkend="resuming-failed"/>.  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.</para
></listitem>
</varlistentry>

<varlistentry id="cmdline-resume">
<term
><parameter
>--resume</parameter
></term>
<listitem
><para
>Väljaren används för att köra &kdesrc-build; efter ett byggfel har uppstått. </para
><para
>Den återupptar bygget från modulen som misslyckades, med användning av listan över moduler som tidigare väntade på att byggas, och inaktiverar dessutom källkods- och metadatauppdateringar. När felet väl har rättats kan du snabbt komma tillbaka till att bygga modulerna som du tidigare byggde utan att mixtra med <option
><link linkend="cmdline-resume-from"
>--resume-from</link
></option
> och <option
><link linkend="cmdline-stop-before"
>--stop-before</link
></option
>. </para
><para
>Väljaren lades till i &kdesrc-build; 1.16. </para
></listitem>
</varlistentry>

<varlistentry id="cmdline-stop-before">
<term
><parameter
>--stop-before</parameter
> (eller <parameter
>--until</parameter
>)</term>
<listitem
><para
>Kommandoradsväljaren används för att stoppa den normala byggprocessen precis <emphasis
>innan</emphasis
> en modul normalt skulle ha byggts. </para
><para
>Om den normala bygglistan exempelvis var <simplelist type="inline"
> <member
>modul-A</member
><member
>modul-B</member
><member
>modul-C</member
></simplelist
>, skulle <option
>--stop-before=<replaceable
>modul-B</replaceable
></option
> göra att &kdesrc-build; bara bygger <literal
>modul-A</literal
>. </para
><para
>Kommandoradsväljaren lades till i &kdesrc-build; 1.16. </para
></listitem>
</varlistentry>

<varlistentry id="cmdline-stop-after">
<term
><parameter
>--stop-after</parameter
> (eller <parameter
>--to</parameter
>)</term>
<listitem
><para
>Kommandoradsväljaren används för att stoppa den normala byggprocessen precis <emphasis
>efter</emphasis
> en modul normalt skulle ha byggts. </para
><para
>Om den normala bygglistan exempelvis var <simplelist type="inline"
> <member
>modul-A</member
><member
>modul-B</member
><member
>modul-C</member
></simplelist
>, skulle <option
>--stop-after=<replaceable
>modul-B</replaceable
></option
> göra att &kdesrc-build; bygger <literal
>modul-A</literal
> och <literal
>modul-B</literal
>. </para
><para
>Kommandoradsväljaren lades till i &kdesrc-build; 1.16. </para
></listitem>
</varlistentry>

<varlistentry id="cmdline-stop-on-failure">
<term
><parameter
>--stop-on-failure</parameter
></term>
<term
><parameter
>--no-stop-on-failure</parameter
></term>
<listitem
><para
>Väljaren gör att bygget avbryts så fort ett fel uppstår. Det normala beteendet är --stop-on-failure. Det går att överskrida om du vill fortsätta med återstående moduler i bygget, för att undvika att slösa tid ifall problemet gäller en enskild modul. </para
><para
>Alternativet lades till i &kdesrc-build; 1.16. Se också inställningsfilens alternativ <link linkend="conf-stop-on-failure"
>stop-on-failure</link
>. </para
></listitem>
</varlistentry>

<varlistentry id="cmdline-rc-file">
<term
><parameter
>--rc-file</parameter
></term>
<listitem
><para
>Det tolkar nästa kommandoradsväljare som filen att läsa konfigurationsinställningarna från. Förvalt värde för väljaren är <filename
>kdesrc-buildrc</filename
> (kontrolleras i arbetskatalogen). Om filen inte finns, används <filename
>~/.config/kdesrc-buildrc</filename
> (<filename
>$XDG_CONFIG_HOME/kdesrc-buildrc</filename
>, om <envar
>$XDG_CONFIG_HOME</envar
> är angivet) istället. Se också <xref linkend="kdesrc-buildrc"/>. </para
></listitem>
</varlistentry>

<varlistentry id="cmdline-print-modules">
<term
><parameter
>--print-modules</parameter
></term>
<listitem>
<para
>Utför alla åtgärder till och med beroendeomordning av modulerna angivna på kommandoraden (eller i inställningsfilen), skriver ut modulerna som skulle behandlats en per rad, och avslutar därefter utan ytterligare åtgärder. </para>
<para
>Metadata för <literal
>kde-project</literal
> laddas först ner (se dock <link linkend="cmdline-pretend"
><option
>--pretend</option
></link
> eller <link linkend="cmdline-no-src"
><option
>--no-src</option
></link
>). </para>
<para
>Utmatningen är inte fullständigt kompatibel med skriptanvändning, eftersom andra utmatningsmeddelanden kan genereras innan listan över moduler visas. </para>
<para
>Detta är i huvudsak användbart för att snabbt avgöra vad &kdesrc-build; anser vara beroenden för en modul, vilket betyder att det bara är användbart för moduler i <link linkend="kde-projects-module-sets"
><literal
>kde-projects</literal
></link
>. Väljaren är också kompatibel med <link linkend="cmdline-resume-from"
><option
>--resume-from</option
></link
>, <link linkend="cmdline-resume-after"
><option
>--resume-after</option
></link
>, <link linkend="cmdline-stop-before"
><option
>--stop-before</option
></link
> och <link linkend="cmdline-stop-after"
><option
>--stop-after</option
></link
>. </para
></listitem>
</varlistentry>

<varlistentry id="cmdline-list-build">
<term
><parameter
>--list-build</parameter
></term>
<listitem>
<para
>Listar modulerna som skulle byggas, i den ordning de skulle byggas. Om tillämpligt, nämner listan också vilken incheckning, gren eller etikett som skulle väljas för utcheckning. </para>
<para
>Väljaren liknar <link linkend="cmdline-print-modules"
><option
>--print-modules</option
></link
>. För mer information om hur moduler är relaterade till varandra, se också: <link linkend="cmdline-dependency-tree"
><option
>--dependency-tree</option
></link
>. </para>
</listitem>
</varlistentry>

<varlistentry id="cmdline-dependency-tree">
<term
><parameter
>--dependency-tree</parameter
></term>
<listitem>
<para
>Skriver ut beroendeinformation för modulerna som skulle byggas genom att använda ett (rekursivt) trädformat. Den listade informationen omfattar också vilken specifik incheckning, gren eller etikett som de beror på, och om de beroende modulerna skulle byggas eller inte. Observera: Genererad utdata kan bli ganska omfattande för program med många beroenden. </para>
</listitem>
</varlistentry>

<varlistentry id="cmdline-run">
<term
><parameter
>--run</parameter
></term>
<listitem
><para
>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.</para>

<para
>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 <envar
>PATH</envar
> och <envar
>KDEDIRS</envar
>) under startsekvensen. </para>

<tip
><para
>Om du vill se miljön som används av &kdesrc-build; kan du köra kommandot <command
>printenv</command
>:</para>
<informalexample>
<screen
>$ <command
>kdesrc-build</command
> <parameter
>--run</parameter
> <parameter
>printenv</parameter>
KDE_SESSION_VERSION=4
SDL_AUDIODRIVER=alsa
LANGUAGE=
XCURSOR_THEME=Oxygen_Blue
LESS=-R -M --shift 5
QMAIL_CONTROLDIR=/var/qmail/control
... etc.
</screen>
</informalexample
></tip>
</listitem>
</varlistentry>

<varlistentry id="cmdline-prefix">
<term
><parameter
>--prefix=&lt;/sökväg/till/kde&gt;</parameter
></term>
<listitem
><para
>Det här låter dig ändra katalogen som &kde; installeras i från kommandoraden. Alternativet inbegriper <link linkend="cmdline-reconfigure"
><parameter
>--reconfigure</parameter
></link
>, men det kan ändå krävas att <link linkend="cmdline-refresh-build"
><parameter
>--refresh-build</parameter
></link
> används. </para
></listitem>
</varlistentry>

<varlistentry id="cmdline-revision">
<term
><parameter
>--revision</parameter
></term>
<listitem
><para
>Väljaren gör att &kdesrc-build; checkar ut en särskilt numrerad version av varje &git;-modul, och överskrider eventuella alternativ som <link linkend="conf-branch"
>branch</link
>, <link linkend="conf-tag"
>tag</link
> eller <link linkend="conf-revision"
>revision</link
> redan är angivna för modulerna.</para>

<para
>Väljaren är troligen inte en god idé, och stöds bara för kompatibilitet med äldre skript. </para
></listitem>
</varlistentry>

<varlistentry id="cmdline-build-system-only">
<term
><parameter
>--build-system-only</parameter
></term>
<listitem
><para
>Väljaren gör att &kdesrc-build; avbryter bygga en modul precis innan kommandot <command
>make</command
> 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;. </para
></listitem>
</varlistentry>

<varlistentry id="cmdline-install"
><term
><parameter
>--install</parameter
></term>
<listitem
><para
>Om detta är den enda kommandoradsväljaren, försöker det installera alla moduler som finns i <filename
>log/latest/build-status</filename
>. Om kommandoradsväljare anges efter <parameter
>--install</parameter
>, antas de alla vara moduler att installera (även om de inte byggdes med lyckat resultat vid den senaste körningen). </para
></listitem>
</varlistentry>

<varlistentry id="cmdline-no-snapshots"
><term
><parameter
>--no-snapshots</parameter
></term>
<listitem
><para
>Att ange den här väljaren gör att &kdesrc-build; alltid utför en normal ursprunglig utcheckning av en modul istället för att använda en sparad version för snabbstart (bara tillgängligt för Git-moduler från arkivet <literal
>kde-projects</literal
>). Observera att alternativet bör bara användas om ett fel uppstår vid användning av en sparad version, eftersom sparade versioner för snabbstart reducerar belastningen på KDE:s källkodsarkiv. </para>

<note
><para
>Sparade versioner av modulen <emphasis
>är</emphasis
> riktiga utcheckningar. Du ska inte behöva ange den här väljaren, den är bara till hjälp vid felsökning.</para
></note>
</listitem>
</varlistentry>

<varlistentry id="cmdline-delete-my-patches">
<term
><parameter
>--delete-my-patches</parameter
></term>
<listitem
><para
>Väljaren används för att låta &kdesrc-build; ta bort källkataloger som kan innehålla användardata, så att modulerna kan laddas ner igen. Den är normalt bara användbar för &kde;-utvecklare (som kan ha lokala ändringar som skulle tas bort).</para>

<para
>Normalt ska inte väljaren användas, utan &kdesrc-build; ber att få köras om med den vid behov.</para>
</listitem>
</varlistentry>

<varlistentry id="cmdline-delete-my-settings">
<term
><parameter
>--delete-my-settings</parameter
></term>
<listitem
><para
>Väljaren används för att låta &kdesrc-build; skriva över befintliga filer som kan innehålla användardata.</para>

<para
>För närvarande används den bara för inställning av en xsession för inloggningshanteraren. Normalt ska inte väljaren användas, utan &kdesrc-build; ber att få köras om med den vid behov.</para>
</listitem>
</varlistentry>

<varlistentry id="cmdline-global-option">
<term
><parameter
>--<replaceable
>&lt;alternativnamn&gt;</replaceable
>=</parameter
></term>
<listitem
><para
>Du kan använda alternativet för att överskrida ett alternativ i <link linkend="configure-data"
>inställningsfilen</link
> för alla moduler. För att till exempel överskrida alternativet <link linkend="conf-log-dir"
>log-dir</link
>, skulle du skriva <userinput
><parameter
>--log-dir=<filename class="directory"
><replaceable
>/sökväg/till/katalog</replaceable
></filename
></parameter
></userinput
>. </para>

<note
><para
>Funktionen kan bara användas för alternativnamn som redan känns igen av &kdesrc-build; som ännu inte stöds av relevanta kommandoradsväljare. Exempelvis har inställningsfilens alternativ <link linkend="conf-async"
>async</link
> de specifika kommandoradsväljarna <link linkend="cmdline-async"
>--async</link
> och <link linkend="cmdline-no-async"
>--no-async</link
> som föredras av &kdesrc-build;. </para
></note>

</listitem>
</varlistentry>

<varlistentry id="cmdline-module-option">
<term
><parameter
>--set-module-option-value=<replaceable
>&lt;modulnamn&gt;</replaceable
>,<replaceable
>&lt;alternativnamn&gt;</replaceable
>,<replaceable
>&lt;alternativvärde&gt;</replaceable
></parameter
></term>
<listitem
><para
>Du kan använda alternativet för att överskrida ett alternativ i <link linkend="configure-data"
>inställningsfilen</link
> för en specifik modul. </para
></listitem>
</varlistentry>

</variablelist>

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

</sect1>

</chapter>

<chapter id="using-kdesrc-build">
<title
>Använda &kdesrc-build;</title>

<sect1 id="using-kdesrc-build-preface">
<title
>Förord</title>

<para
>Efter du har gått igenom <xref linkend="getting-started"/>, är det normalt så enkelt att använda &kdesrc-build; som att skriva följande från en terminal:</para>

<screen
><prompt
>&percnt;</prompt
> <command
><userinput
>kdesrc-build</userinput
></command
>
</screen>

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

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

</sect1>

<sect1 id="basic-features">
<title
>Grundläggande funktioner i &kdesrc-build;</title>

<sect2 id="using-qt">
<title
>stöd för qt</title>
<para
>&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.</para>

<note
><para
>&Qt; utvecklas i ett separat arkiv från &kde;-programvara, lokaliserat på <ulink url="http://code.qt.io/cgit/qt/"
>http://code.qt.io/cgit/qt/</ulink
>.</para
></note>

<para
>För att bygga &Qt; måste du försäkra dig om att inställningen <link linkend="conf-qtdir"
>qtdir</link
> pekar på katalogen där du vill att &Qt; ska installeras, som beskrivs i <xref linkend="configure-data"/>.</para>

<para
>Därefter måste du försäkra dig om att modulen qt läggs till i <filename
>kdesrc-buildrc</filename
>, 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.</para>

<para
>Nu bör du kontrollera att alternativet <link linkend="conf-repository"
>repository</link
> och alternativen <link linkend="conf-branch"
>branch</link
> är lämpligt inställda:</para>

<orderedlist>
<listitem
><para
>Det första möjligheten är att bygga &Qt; med användning av en spegelplats som underhålls i &kde;:s källkodsarkiv (inga andra ändringar har lagts till, det är helt enkelt en klon av den officiella källan). Det rekommenderas starkt på grund av att det ibland uppstår problem med  att klona hela &Qt;-modulen från det officiella arkivet.</para>

<para
>Alternativet <option
>repository</option
> kan ställas in till <userinput
>kde:qt</userinput
> för modulen qt, för att använda den möjligheten.</para>
</listitem>

<listitem
><para
>Annars, för att bygga standard-&Qt;, ställ in alternativet <option
>repository</option
> till <userinput
>git://gitorious.org/qt/qt.git</userinput
>. Observera att det kan uppstå problem att skapa den ursprungliga klonen av &Qt; från detta arkiv.</para
></listitem>
</orderedlist>

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

</sect2>

<sect2 id="kdesrc-build-std-flags">
<title
>Standardflaggor tillagda av &kdesrc-build;</title>
<para
>Observera: avsnittet gäller inte för moduler där  du har ställt in en egen verktygskedja, t.ex. genom att använda <link linkend="conf-cmake-toolchain"
>cmake-toolchain</link
>.</para>

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

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

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

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

<listitem
><para
>Inställningen av &kdedir; skickas automatiskt vidare till miljövariabeln <envar
>KDEDIR</envar
> under byggprocessen.  (<envar
>KDEDIRS</envar
> påverkas inte). </para
></listitem>

<listitem
><para
>Inställningen av &qtdir; skickas automatiskt vidare till miljövariabeln <envar
>QTDIR</envar
> under byggprocessen. </para
></listitem>

</itemizedlist>

</sect2>

<sect2 id="build-priority">
<title
>Ändra byggprioritet i &kdesrc-build;</title>
<para
>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. </para>

<para
>&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. </para>

<para
>&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 <ulink url="http://setiathome.ssl.berkeley.edu/"
>Seti@Home</ulink
>. </para>

<para
>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 <link linkend="configure-data"
>inställningsfilen</link
>. Alternativet &niceness; styr hur <quote
>snällt</quote
> &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).</para>

<para
>Du kan också tillfälligt ändra prioritet hos &kdesrc-build; genom att använda <link linkend="cmdline"
>kommandoradsväljaren</link
> &cmd-nice;. Väljarens värde är exakt samma som för &niceness;.</para>

<note
><para
>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. </para
></note>

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

<screen
><prompt
>&percnt;</prompt
> <userinput
><command
>kdesrc-build</command
> <option
>--nice=<replaceable
>15</replaceable
></option
></userinput
>
</screen>

<para
>Eller kan du redigera <link linkend="configure-data"
>inställningsfilen</link
> för att göra ändringen permanent:</para>

<screen
>&niceness; <replaceable
>15</replaceable
>
</screen>
</informalexample>

<tip>
<para
>Alternativet <link linkend="conf-niceness"
>niceness</link
> 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 (<acronym
>I/O</acronym
>) som ett program använder. För att bestämma hur mycket <acronym
>I/O</acronym
> ett program kan använda, stöder moderna &Linux;-operativsystem ett liknande verktyg som kallas <application
>ionice</application
>. &kdesrc-build; stöder <application
>ionice</application
> (men bara för att aktivera eller inaktivera det helt och hållet), med alternativet  <link linkend="conf-use-idle-io-priority"
>use-idle-io-priority</link
>, sedan &kdesrc-build; version 1.12. </para>
</tip>

</sect2>

<sect2 id="root-installation">
<title
>Installera som systemadministratör</title>
<para
>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. </para>

<para
>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.</para>

<para
>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. </para>

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

<screen
>global
  &make-install-prefix; <replaceable
>sudo</replaceable>
  # Övriga alternativ
end global
</screen>

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

<screen
>module <replaceable
>något-modul-namn</replaceable>
  &make-install-prefix; <replaceable
>sudo</replaceable>
end module
</screen>
</informalexample>

</sect2>

<sect2 id="build-progress">
<title
>Visa förloppet för en byggprocess av en modul</title>
<para
>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. </para>

</sect2>

</sect1>

<sect1 id="advanced-features">
<title
>Avancerade funktioner</title>

<sect2 id="partial-builds">
<title
>Delvis bygga en modul</title>
<para
>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. </para>

<sect3 id="not-compiling">
<title
>Ta bort kataloger från en byggplats</title>
<para
>Det möjligt att ladda ner ett helt arkiv men låta byggsystemet utelämna ett antal kataloger när byggprocessen utförs. Det kräver att modulen använder &cmake; och att modulens byggsystem tillåter att katalogen som ska tas bort är valfri. </para>

<para
>Det bestäms med alternativet &do-not-compile;.</para>

<important
><para
>Alternativet kräver minst att byggsystemet för modulen konfigureras om efter det har ändrats. Det görs med kommandot <userinput
><command
>kdesrc-build</command
> <option
>&cmd-reconfigure;</option
> <option
><replaceable
>modul</replaceable
></option
></userinput
>. </para
></important>

<informalexample>
<para
>För att ta bort katalogen <filename class="directory"
>python</filename
> från byggprocessen för kdebindings:</para>

<screen
>module <replaceable
>kdebindings</replaceable>
  &do-not-compile; <replaceable
>python</replaceable>
end module
</screen>

</informalexample>

<note
><para
>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.</para
></note>

</sect3>

</sect2>

<sect2 id="using-branches">
<title
>Stöd för grenar och taggar i &kdesrc-build;</title>

<sect3 id="branches-and-tags">
<title
>Vad är grenar och taggar?</title>

<para
>&git; 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. </para>

<para
>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 master) kan ha pågående utveckling. </para>

<para
>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. </para>

</sect3>

<sect3 id="branch-support">
<title
>Hur man använder grenar och taggar</title>

<para
>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. </para>

<para
>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.</para>

<informalexample>
<para
>För att ladda ner kdelibs från &kde; 4.6 (som helt enkelt är känt som grenen 4.6): </para>

<screen
>module kdelibs
  branch <replaceable
>4.6</replaceable>
  # övriga alternativ...
end module
</screen>

<para
>Eller, för att ladda ner kdemultimedia som det var när det gavs ut med &kde; 4.6.1:</para>

<screen
>module kdemultimedia
  tag <replaceable
>4.6.1</replaceable>
  # övriga alternativ...
end module
</screen>

</informalexample>

<tip
><para
>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. </para
></tip>
</sect3>

<sect3 id="advanced-branches">
<title
>Stöd för avancerade grenalternativ</title>

<para
>&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;. </para>

<itemizedlist>
<listitem
><para
>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 <filename class="directory"
>gitRoot/module-base-path/<replaceable
>modulnamn</replaceable
></filename
>. 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: </para>

<informalexample>
<screen
>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
</screen>

<para
>Det skulle göra att &kdesrc-build; laddar ner kdesupport från (i det här exemplet) <filename
>git://invent.kde.org/home/kde<replaceable
>tags/kdesupport-for-4.5</replaceable
></filename
>. </para>
</informalexample>
<tip
><para
>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 <link linkend="cmdline-pretend"
>--pretend</link
>. </para
></tip>
</listitem>

<listitem
><para
>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 Git källkod. </para>

<important
><para
>&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 &repository;, kan du också behöva uppdatera det här. </para
></important>

</listitem>
</itemizedlist>

</sect3>

</sect2>

<sect2 id="stopping-the-build-early">
<title
>Stoppar bygget i förtid</title>

<sect3 id="the-build-continues">
<title
>Bygget fortsätter normalt även om allvarliga fel uppstår</title>

<para
>&kdesrc-build; uppdaterar, bygger och installerar normalt alla moduler i den angivna listan över moduler att bygga, även om en modul misslyckas att bygga. Detta är vanligtvis en bekvämlighet för att du ska kunna uppdatera programvarupaket även om ett enkelt misstag görs i ett av källkodsarkiven under utvecklingen som gör att bygget fallerar. </para>

<para
>Du kan dock önska att &kdesrc-build; stoppar vad det gör när det inte lyckas att bygga och installera en modul. Det kan hjälpa dig att spara tid som kommer att gå till spillo på att komma vidare när moduler som finns kvar i bygglistan inte heller kommer att kunna byggas med lyckat resultat, särskilt om du aldrig har lyckats bygga modulerna i listan. </para>

</sect3>

<sect3 id="stop-on-failure-stops-early">
<title
>Stoppar inte i förtid med --no-stop-on-failure</title>

<para
>Den primära metoden för att göra det är att använda kommandoradsväljaren <link linkend="cmdline-stop-on-failure"
>--no-stop-on-failure</link
> när &kdesrc-build; körs. </para>

<para
>Väljaren kan också anges i <link linkend="configure-data"
>inställningsfilen</link
> för att göra den till normalt beteende. </para>

<para
>Det är också möjligt att tala om för &kdesrc-build; att sluta bygga under körning <emphasis
>efter</emphasis
> att ha slutfört den aktuella modulen den arbetar med. Det är i motsats till att avbryta &kdesrc-build; med ett kommando som <keycombo action="simul"
>&Ctrl;<keycap
>C</keycap
></keycombo
>, vilket avbryter &kdesrc-build; omedelbart, och förlorar arbetet för den aktuella modulen. </para>

<important
><para
>Avbryta &kdesrc-build; under installation av en module när alternativet <link linkend="conf-use-clean-install"
>use-clean-install</link
> är aktiverat innebär att den avbrutna modulen är otillgänglig tills &kdesrc-build; kan bygga modulen med lyckat resultat.</para>

<para
>Om du behöver avbryta &kdesrc-build; utan att tillåta en snygg avstängning i detta fall, försök åtminstone undvika att göra detta medan &kdesrc-build; installerar en modul.</para>
</important>

</sect3>

<sect3 id="stopping-early-without-stop-on-failure">
<title
>Stoppar &kdesrc-build; snyggt när stop-on-failure är false</title>

<para
>Som nämnts ovan är det möjligt att få &kdesrc-build; att snyggt avsluta tidigt när det väl har slutfört modulen det arbetar med. För att göra det måste du skicka signalen POSIX <literal
>HUP</literal
> till &kdesrc-build; </para>

<para
>Du kan göra detta med ett kommando som <command
>pkill</command
> (på &Linux;-system) enligt följande:</para>

<programlisting
><prompt
>$ </prompt
><userinput
><command
>pkill <option
>-HUP</option
> kdesrc-build</command
></userinput
>
</programlisting>

<para
>Om det lyckas kommer du att se ett meddelande i utmatningen från &kdesrc-build; som liknar:</para>

<programlisting
>[ build ] tog emot SIGHUP, kommer att avsluta efter den här modulen
</programlisting>

<note>
<para
>&kdesrc-build; kan visa meddelandet flera gånger beroende på antalet individuella &kdesrc-build; processer som är aktiva. Det är normalt och inte en indikation av ett fel.</para>
</note>

<para
>När &kdesrc-build; har bekräftat signalen kommer den att sluta bearbetningen efter att den aktuella modulen har byggts och installerats. Om &kdesrc-build; fortfarande uppdaterar källkoden när begäran tas emot, kommer &kdesrc-build; att stoppa efter uppdateringen av modulens källkod är klar. När både uppdaterings- och byggprocessen har stoppats tidigt, kommer &kdesrc-build; skriva ut sina delresultat och avsluta. </para>

</sect3>

</sect2>

<sect2 id="building-successfully">
<title
>Hur &kdesrc-build; försöker försäkra sig om en lyckad byggprocess</title>

<sect3 id="automatic-rebuilds">
<title
>Automatisk ombyggnad</title>

<para
>&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.</para>

<itemizedlist>

<listitem
><para
>Om du ändrar <link linkend="conf-configure-flags"
>configure-flags</link
> eller <link linkend="conf-cmake-options"
>cmake-options</link
> för en modul, detekterar &kdesrc-build; det och kör automatiskt om configure eller cmake för modulen.</para
></listitem>

<listitem
><para
>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 <link linkend="cmdline-refresh-build"
>--refresh-build</link
> för en specifik modul utan att den utförs för andra moduler.</para
></listitem>

</itemizedlist>

</sect3>

<sect3 id="manual-rebuilds">
<title
>Bygga om en modul manuellt</title>
<para
>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.</para>

<para
>Du kan göra det genom att helt enkelt köra <userinput
><command
>kdesrc-build</command
> <option
>--refresh-build</option
> <option
><replaceable
>modul</replaceable
></option
></userinput
>. </para>

<para
>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 <filename
>.refresh-me</filename
> 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.</para>

<tip>
<para
>Normalt är byggkatalogen <filename class="directory"
>~/kdesrc/build/<replaceable
>modul</replaceable
>/</filename
>. Om du ändrar inställning av alternativet &build-dir;, använd den istället för <filename class="directory"
>~/kdesrc/build</filename
>.</para>
</tip>

<informalexample>
<para
>Bygg om med <filename
>.refresh-me</filename
> för modulen <replaceable
>kdelibs</replaceable
>:</para>
<screen
><prompt
>&percnt;</prompt
> <userinput
><command
>touch</command
> <filename
>~/kdesrc/build/<replaceable
>kdelibs</replaceable
>/.refresh-me</filename
></userinput>
<prompt
>&percnt;</prompt
> <userinput
><command
>kdesrc-build</command
></userinput
>
</screen>
</informalexample>
</sect3>

</sect2>

<sect2 id="changing-environment">
<title
>Ändra inställning av miljövariabler</title>
<para
>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.</para>

<para
>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;.</para>

<para
>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.</para>

<informalexample>
<para
>Ställ in <userinput
><envar
>DISTRO</envar
>=<replaceable
>BSD</replaceable
></userinput
> för alla moduler:</para>
<screen
>global
  set-env <replaceable
>DISTRO</replaceable
> <replaceable
>BSD</replaceable>
end global
</screen>
</informalexample>

</sect2>

<sect2 id="resuming">
<title
>Återuppta byggprocesser</title>

<sect3 id="resuming-failed">
<title
>Återuppta en misslyckad eller avbruten byggprocess</title>

<para
>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;.</para>

<note
><para
>Äldre versioner av &kdesrc-build; hoppade över uppdatering av källkod när ett bygge återupptogs. Det görs inte längre standardmässigt, men man kan alltid använda kommandoradsväljaren <option
>--no-src</option
> för att hoppa över uppdateringen.</para
></note>

<informalexample>
<para
>Återuppta byggprocessen med början på kdebase:</para>

<screen
><prompt
>&percnt;</prompt
> <userinput
><command
>kdesrc-build</command
> <option
>--resume-from=<replaceable
>kdebase</replaceable
></option
></userinput
>
</screen>
</informalexample>

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

<screen
><prompt
>&percnt;</prompt
> <userinput
><command
>kdesrc-build</command
> <option
>--resume-after=<replaceable
>kdebase</replaceable
></option
></userinput
>
</screen>
</informalexample>

<para
>Om det senaste bygget med &kdesrc-build; slutade med ett byggfel, kan du också använda kommandoradsväljaren <link linkend="cmdline-resume"
>--resume</link
>, som återupptar det senaste bygget med modulen som misslyckades. Källkods- och metadatauppdateringar hoppas också över (men om du behöver dem, är det i allmänhet bättre att använda <link linkend="cmdline-resume-from"
>--resume-from</link
> istället).</para>


</sect3>

<sect3 id="ignoring-modules">
<title
>Ignorera moduler i en byggprocess</title>

<para
>På samma sätt som du kan <link linkend="resuming-failed"
>återuppta byggprocessen från en modul</link
>, kan du istället välja att uppdatera och bygga normalt, men ignorera en uppsättning moduler.</para>

<para
>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.</para>

<informalexample>
<para
>Ignorera extragear/multimedia och kdereview under en fullständig körning:</para>
<screen
><prompt
>&percnt;</prompt
> <userinput
><command
>kdesrc-build</command
> <option
>--ignore-modules</option
> <replaceable
>extragear/multimedia kdereview</replaceable
></userinput
>
</screen>
</informalexample>

</sect3>
</sect2>

<sect2 id="changing-env-from-cmd-line">
<title
>Ändra alternativ från kommandoraden</title>

<sect3 id="changing-global-opts">
<title
>Ändra allmänna alternativ</title>
<para
>Du kan ändra uppsättningen alternativ som läses från <link linkend="configure-data"
>inställningsfilen</link
> 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.</para>

<para
>&kdesrc-build; låter dig ändra alternativ namngivna som <replaceable
>alternativnamn</replaceable
> genom att ange en väljare på kommandoraden på formen <userinput
><option
>--<replaceable
>alternativnamn</replaceable
>=värde</option
></userinput
>. &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.</para>

<informalexample>
<para
>Ställa in alternativet &source-dir; till <filename
>/dev/null</filename
> för test:</para>

<screen
><prompt
>&percnt;</prompt
> <userinput
><command
>kdesrc-build</command
> <option
>--pretend</option
> <option
>--<replaceable
>källkodskatalog</replaceable
>=<replaceable
>/dev/null</replaceable
></option
></userinput
>
</screen>

</informalexample>

</sect3>

<sect3 id="changing-module-opts">
<title
>Ändra modulalternativ</title>
<para
>Det är också möjligt att bara ändra alternativ för en viss modul. Syntaxen är liknande: --<replaceable
>modul</replaceable
>,<replaceable
>alternativnamn</replaceable
>=<replaceable
>värde</replaceable
>. </para>

<para
>Ändringen överskrider eventuell duplicerad inställning för modulen som hittas i <link linkend="configure-data"
>inställningsfilen</link
>, och gäller bara när alternativet skickas med på kommandoraden.</para>

<informalexample>
<para
>Använda en annan byggkatalog för modulen kdeedu:</para>

<screen
><prompt
>&percnt;</prompt
> <userinput
><command
>kdesrc-build</command
> <option
>--<replaceable
>kdeedu</replaceable
>,<replaceable
>byggkatalog</replaceable
>=<replaceable
>temporärbygg</replaceable
></option
></userinput
>
</screen>

</informalexample>

</sect3>

</sect2>

</sect1>

<sect1 id="developer-features">
<title
>Funktioner för &kde;-utvecklare</title>

<sect2 id="ssh-agent-reminder">
<title
>Kontroll av &ssh;-agent</title>
<para
>&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. </para>

<note
><para
>Det görs bara för &kde;-utvecklare som användare &ssh;. </para
></note>

<para
>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 <option
>disable-agent-check</option
> till <userinput
>true</userinput
>.</para>

<informalexample>
<para
>Inaktivera &ssh;-agentkontroll:</para>
<screen
>global
  disable-agent-check true
end global
</screen>
</informalexample>

</sect2>

</sect1>

<sect1 id="other-features">
<title
>Andra funktioner i &kdesrc-build;</title>

<sect2 id="changing-verbosity">
<title
>Ändra mängden utmatning från &kdesrc-build;</title>
<para
>&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.</para>

<itemizedlist>
<listitem
><para
>Väljaren <option
>--quiet</option
> (den korta formen är <option
>-q</option
>) 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.</para
></listitem>

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

<listitem
><para
>Väljaren <option
>--verbose</option
> (kortformen är <option
>-v</option
>) gör att &kdesrc-build; är mycket detaljerad i utmatningen.</para
></listitem>

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

</sect2>

<sect2 id="kdesrc-build-color">
<title
>Färgutmatning</title>
<para
>När &kdesrc-build; körs från &konsole; eller en annan terminal, visas normalt färglagd text.</para>

<para
>Du kan inaktivera det genom att använda väljaren <option
>--no-color</option
> på kommandoraden, eller ställa in alternativet &colorful-output; i <link linkend="configure-data"
>inställningsfilen</link
> till <userinput
>false</userinput
>. </para>

<informalexample>
<para
>Inaktivera färgutmatning i inställningsfilen:</para>
<screen
>global
  colorful-output false
end global
</screen>
</informalexample>

</sect2>

<sect2 id="deleting-build-dir">
<title
>Ta bort onödiga kataloger efter en byggprocess</title>
<para
>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 &git;.</para>

<note
><para
>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:</para
></note>

<orderedlist>
<listitem
><para
>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 <link linkend="configure-data"
>inställningsfilen</link
>, 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 <emphasis
>ska inte</emphasis
> ta bort dem om du faktiskt använder dem, åtminstone till du är klar med användning av &kdesrc-build;.</para>

<para
>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. Det hyvlar av omkring 200 Mibyte från källkodsstorleken på disk.</para>
</listitem>

<listitem>
<para
>&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.</para>

<para
>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.</para>
</listitem>

<listitem
><para
>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. </para
></listitem>
</orderedlist>

<para
>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;. </para>

<warning
><para
>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! </para
></warning>

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

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

<para
>Ta bort byggkatalogen efter installation, utan felsökningsinformation, med storleksoptimering.</para>

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

</sect1>

</chapter>

<chapter id="kde-cmake">
<title
>&cmake;, byggsystemet för &kde;</title>

<sect1 id="kde-cmake-intro">
<title
>Introduktion till &cmake;</title>

<para
>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; hade använt från början.</para>

<para
>En sida med en introduktion till &cmake; är tillgänglig på <ulink url="https://community.kde.org/Guidelines_HOWTOs/CMake"
>&kde; Community Wiki</ulink
>. Istället för att köra <userinput
><command
>make</command
> <option
>-f</option
> <filename
>Makefile.cvs</filename
></userinput
>, därefter <command
>configure</command
> och sedan &make;, kör vi helt enkelt &cmake; och därefter &make;. </para>

<para
>&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 <link linkend="conf-configure-flags"
>configure-flags</link
> och <link linkend="conf-do-not-compile"
>do-not-compile</link
>. När motsvarande funktioner är tillgängliga, tillhandahålls de. Motsvarigheten till alternativet configure-flags är till exempel <link linkend="conf-cmake-options"
>cmake-options</link
>, och alternativet <link linkend="conf-do-not-compile"
>do-not-compile</link
> stöds också för &cmake; från och med &kdesrc-build; version 1.6.3. </para>

</sect1>
</chapter>

<chapter id="credits-and-license">
<title
>Tack till och licens</title>

<para
>Översättning Stefan Asserhäll <email
>stefan.asserhall@bredband.net</email
></para
> &underFDL; </chapter>

<appendix id="appendix-modules">
<title
>&kde;-moduler och organisation av källkoden</title>
<sect1 id="module-concept">
<title
><quote
>Modulen</quote
></title>

<para
>&kde; grupperar programvaran i <quote
>moduler</quote
> av olika storlek. Det var från början en lös gruppering av några få stora moduler, men vid introduktionen av <ulink url="https://git-scm.com/"
>Git</ulink
>-baserade <ulink url="https://commits.kde.org/"
>källkodsarkiv</ulink
>, delades dessa stora moduler ytterligare i många mindre moduler. </para>

<para
>&kdesrc-build; använder också modulkonceptet. I stort sett är en <quote
>modul</quote
> en gruppering av kod som kan laddas ner, byggas, testas och installeras. </para>

<sect2 id="single-modules">
<title
>Enskilda moduler</title>

<para
>Det är enkelt att ställa in &kdesrc-build; att bygga en enstaka modul. Följande listning är ett exempel på hur en deklaration för en modul baserad på Git skulle se ut i <link linkend="kdesrc-buildrc"
>inställningsfilen</link
>.</para>

<programlisting
>module <replaceable
>kdexxx</replaceable>
    <option
><replaceable
>cmake-options -DCMAKE_BUILD_TYPE=Debug</replaceable
></option>
end module
</programlisting>

<tip
><para
>Det är en modul baserad på Git eftersom den inte använder alternativet <link linkend="conf-repository"
>repository</link
>. Dessutom listas alternativet <option
>cmake-options</option
> bara som ett exempel, det krävs inte.</para
></tip>

</sect2>
<sect2 id="module-groups">
<title
>Grupper av relaterade moduler</title>

<para
>Nu är de flesta &kde;-moduler baserade på Git, och kombineras normalt i modulgrupper.</para>

<para
>Därför stöder &kdesrc-build; också modulgrupper, med <link linkend="module-sets"
>module sets</link
>. Ett exempel:</para>

<programlisting
>module-set <replaceable
>base-modules</replaceable>
    <option
>repository</option
> kde-projects
    <option
>use-modules</option
> <replaceable
>kde-runtime kde-workspace kde-baseapps</replaceable>
end module-set
</programlisting>

<tip
><para
>Du kan lämna moduluppsättningens namn tomt om du vill (<replaceable
>base-modules</replaceable
> i detta fall). Inställningen <option
>repository</option
> talar om för &kdesrc-build; varifrån källkoden ska laddas ner, men du kan också använda en webbadress som börjar med <symbol
>git://</symbol
>.</para
></tip>

<para
>En särskild funktion med <quote
><option
>repository</option
> <literal
>kde-projects</literal
></quote
> är att &kdesrc-build; automatiskt inkluderar alla Git-moduler som är grupperade under modulerna du listar (i KDE:s projekdatabas).</para>
</sect2>

<sect2 id="module-branch-groups">
<title
>Modulen <quote
>branch groups</quote
></title>

<para
>När konceptet med en <link linkend="module-groups"
>grupp av moduler</link
> fördes vidare, fann &kde;-utvecklarna till slut att synkronisering av namnen på Git-grenarna över ett stort antal arkiv började bli svårt, särskilt under utvecklingsoffensiven av det nya &kde;-ramverket för &Qt; 5. </para>

<para
>Alltså utvecklades konceptet <quote
>branch groups</quote
> (grengrupper) för att låta användare bara välja en eller några få grupper och låta skriptet automatiskt välja lämplig Git-gren. </para>

<para
>&kdesrc-build; stöder funktionen från version 1.16-pre2, via alternativet <link linkend="conf-branch-group"
>branch-group</link
>. </para>

<example id="ex-branch-group">
<title
>Exempel på användning av branch-group</title>

<para
>branch-group kan användas på följande sätt i inställningsfilen: </para>

<programlisting
>global
    # Välj KDE Frameworks 5 och andra Qt5-baserade program
    <option
>branch-group</option
> <replaceable
>kf5-qt5</replaceable>

    # Andra globala alternativ här ...
end global

module-set
    # branch-group fungerar bara för kde-projects
    <option
>repository</option
> kde-projects

    # branch-group ärvs från den som ställs in globalt, men skulle kunna
    # specificeras här.

    <option
>use-modules</option
> <replaceable
>kdelibs kde-workspace</replaceable>
end module-set

# Gren för kdelibs kommer att vara "frameworks"
# Gren för kde-workspace kommer att vara "master" (från augusti 2013)
</programlisting>

<para
>I detta fall ger samma <literal
>branch-group</literal
> som ger olika namn på grenar för varje Git-modul. </para>
</example>

<para
>Funktionen kräver att en del data underhålls av &kde;-utvecklarna i Git-arkivet vid namn <literal
>kde-build-metadata</literal
>. Dock inkluderas modulen automatiskt av &kdesrc-build; (även om du kan se den visas i skriptets utdata). </para>

<tip
><para
>För &kde;-moduler som inte har ett inställt namn på grenen för grengruppen du väljer,  får normalt ett lämpligt grennamn, som om du inte hade angivit <literal
>branch-group</literal
> alls. </para
></tip>

</sect2>

</sect1>
</appendix>

<appendix id="appendix-profile">
<title
>Ersatta procedurer för att ställa in en profil</title>

<sect1 id="old-profile-setup">
<title
>Ställa in en inloggningsprofil för &kde;</title>

<para
>Instruktionerna täcker hur man ställer in profilen som krävs för att säkerställa att datorn kan logga in på det nybyggda &kde; &plasma;-skrivbordet. &kdesrc-build; försöker normalt göra det automatiskt (se <xref linkend="session-driver"/>). Detta appendix kan vara användbart för de som inte kan använda det inbyggda stödet i &kdesrc-build; för inställning av inloggningsprofil. Dock kanske instruktionerna inte alltid är aktuella, och det kan också vara användbart att titta i filen <filename
>kde-env-master.sh</filename
> som ingår i källkoden för &kdesrc-build;.</para>

<sect2 id="changing-profile">
<title
>Ändra startprofilinställningar</title>

<important
><para
>Filen <filename
>.bash_profile</filename
> är inloggningsinställningarna för det populära skalet <application
>bash</application
> 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.</para
></important>

<para
>Öppna eller skapa filen <filename
>.bash_profile</filename
> i hemkatalogen med din favoriteditor, och lägg till följande i slutet på filen. Om du bygger modulen qt (det gör du normalt), lägg istället till: <programlisting>
QTDIR=(sökväg till qtdir)   # Såsom normalt ~/kdesrc/build/qt.
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
</programlisting
> eller om du inte bygger qt (och använder systemets &Qt;) lägg till det här istället: <programlisting
>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
</programlisting>
</para>

<para
>Om du inte använder en särskild användare ställ in en annan $<envar
>KDEHOME</envar
> för din nya miljö i <filename
>.bash_profile</filename
>: <programlisting
>export KDEHOME="${HOME}/.kde-git"

# Create it if needed
[ ! -e ~/.kde-git ] &amp;&amp; mkdir ~/.kde-git
</programlisting>
</para>

<note>
<para
>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 <acronym
>XDG</acronym
> i din <filename
>.bash_profile</filename
>: <programlisting
>XDG_CONFIG_DIRS="/etc/xdg"
XDG_DATA_DIRS="${KDEDIR}/share:/usr/share"
export XDG_CONFIG_DIRS XDG_DATA_DIRS
</programlisting>

</para>
</note>

</sect2>
<sect2 id="starting-kde">
<title
>Starta &kde;</title>

<para
>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 <command
>startkde</command
>-skriptet också används. </para>

<para
>Öppna textfilen <filename
>.xinitrc</filename
> från hemkatalogen, eller skapa den om det behövs. Lägg till raden: <programlisting
><command
>exec</command
> <option
>${KDEDIR}/bin/startkde</option
>
</programlisting>
</para>

<important
><para
>Det kan vara nödvändigt att utföra samma steg med filen <filename
>.xsession</filename
>, också i hemkatalogen. Det är särskilt sant om grafiska inloggningshanterare som sddm, <application
>gdm</application
> eller <application
>xdm</application
> används.</para>
</important>

<para
>Starta nu det nya &kde;: i &BSD;- och &Linux;-system med stöd för virtuella terminaler, används tangentkombinationerna <keycombo action="simul"
>&Ctrl;&Alt;<keycap
>F1</keycap
></keycombo
> ... <keycombo action="simul"
>&Ctrl;&Alt;<keycap
>F12</keycap
></keycombo
> 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. </para>

<para
>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 sddm, har ett alternativ att använda en <quote
>Egen session</quote
> när du loggar in. Med det alternativet laddas dina sessionsinställningar från filen <filename
>.xsession</filename
> i din hemkatalog. Om du redan har ändrat filen som beskrivs ovan, ska alternativet starta den nya &kde;-installationen. </para>

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

<screen
><command
>startx</command
> <option
>--</option
> <option
>:1</option
>
</screen>

<tip>
<para
>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å <keycombo action="simul"
>&Ctrl;&Alt;<keycap
>F2</keycap
></keycombo
> (eller <keycap
>F1</keycap
>, <keycap
>F3</keycap
>, etc.) så visas en textterminal. Logga in som den särskilda &kde; &git;-användaren och skriv:</para>

<screen
><command
>startx</command
> <option
>--</option
> <option
>:1</option
>
</screen>

<para
>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 <keycombo action="simul"
>&Ctrl;&Alt;<keycap
>F7</keycap
></keycombo
>, men du kanske måste använda <keycap
>F6</keycap
> eller <keycap
>F8</keycap
> 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 <keycombo action="simul"
>&Ctrl;&Alt;<keycap
>F7</keycap
></keycombo
> för att byta till det vanliga &kde;, skulle du behöva skriva <keycombo action="simul"
>&Ctrl;&Alt;<keycap
>F8</keycap
></keycombo
> för att gå tillbaka till &kde; byggt med &kdesrc-build;.</para>
</tip>

</sect2>
</sect1>

</appendix>
</book>
