# Användarmanual &kdevelop;

## Om den här manualen

Den här användarmanualen är avsedd att beskriva innehållet och användningen av den integrerade utvecklingsmiljön (IDE) &kdevelop; från användarens perspektiv. Det är inte en programmeringsmanual, och inte heller beskriver den utvecklingsprocessen i detalj. Det enda målet är att hjälpa dig med hanteringen av den integrerade utvecklingsmiljön.

Här hittar du information om följande ämnen:

- I korthet: En snabbreferens till de oftast använda kommandona och åtgärderna.

- Utveckling på Unix: En historisk översikt över Unix programutveckling, de viktigaste verktygen som behövs och varför man behöver en integrerad utvecklingsmiljö.

- Installera &kdevelop;: Talar om var man skaffar &kdevelop;, och hur man får det att köra.

- Översikt: Funktioner i &kdevelop;: Någon form av uppvärmning, som ger en kort översikt av vad som är inbyggt i &kdevelop; och gör dig bekant med utseendet och känslan i denna integrerade utvecklingsmiljö.

- Översikt över menyer och verktygsrader: Tillhandahåller en kort översikt över tillgängliga meny- och verktygsradsalternativ (i appendix).

- Anpassa &kdevelop;: Visar hur du kan skräddarsy den integrerade utvecklingsmiljön för att passa dina behov.

- Komma igång: Programguiden: Beskriver grunderna i hur ett nytt projekt skapas i &kdevelop; med den inbyggda programguiden.

- Redigeringsverktyg: Allt du behöver för att skriva källkoden. Från hur editorn används, hur textsökning både lokalt och i hela projektet görs, till hur nya filer och klasser integreras i projektet.

- Filbläddrarna: Demonstrerar diverse verktyg för att titta på projektets struktur och hur du kommer åt filerna du vill arbeta med.

- Klassbläddraren: Beskriver en av de mest kraftfulla verktygen i &kdevelop;, som låter dig navigera i klassberoenden och gör det möjligt att enkelt skapa och komma åt de klasser och metoder du behöver.

- Dokumentation: Visar hur man kommer åt den omfattande inbyggda dokumentationen som &kdevelop; tillhandahåller, och talar om hur du skapar dokumentation av projektet, en koncis och kraftfull dokumentation av programmeringsgränssnittet, som ger dig en översikt över all källkod i projektet samt en docbook-baserad användardokumentation.

- Bygga och projekthantering: Handlar om att skapa och hantera projekt, beskriver grunderna i användning av autoconf och automake, samt hur egna byggfiler skapas och hur kompilator- och bygginställningar används för att skräddarsy programmet för att passa dina behov.

- Avancerad användning av autoprojekt: Tittar på sätt att hålla flera bygginställningar, för att korskompilera till olika plattformar, eller skapa inbyggda system med biblioteket Qt/embedded.

- Avlusargränssnittet: Beskriver hur det integrerade avlusargränssnittet till avlusaren gdb används, så att du kan jaga fel utan att lämna &kdevelop; för att alltid behålla möjligheten att enkelt komma åt det aktuella programmets källkod.

- Använda CVS: Talar om för dig hur du kan underhålla projektet med CVS-versionshanteringssystem, en nödvändighet särskilt om många utvecklare arbetar med samma projekt.

- Dra nytta av externa program: Visar hur man kommer åt externa program och verktyg inifrån &kdevelop;, och på så sätt starkt utökar dess möjligheter.

- Insticksverktyg: Ger en översikt över de delar som utgör &kdevelop;, och hur du kan anpassa det för att passa dina behov genom att bara ladda nödvändiga delar, både för den integrerade utvecklingsmiljön och för hela projektet.

## I korthet

Informationen i det här kapitlet är avsett som en snabbreferens för att genast komma igång om du (tillfälligt) glömt bort några grundläggande koncept. Om du vill ha mer information om ett ämne, följ bara länken i rubriken som erbjuder det.

## Projekt

- ## Skapa nytt projekt

  Projekt Nytt projekt... startar programguiden.

- ## Använd projektalternativ från början

  Så fort du skapat ett nytt projekt, glöm inte att ställa in Projekt Projektinställningar.. enligt dina behov.

## Hantering av automake

- ## Skapa nya filer i ett projekt

  Välj delprojekt i övre delen av Hantering av automake, och högerklicka sedan i nedre delen på grupprubriken där du vill lägga till filerna och välj Skapa ny fil...

- ## Lägga till befintliga filer i ett projekt

  Välj delprojekt i övre delen av Hantering av automake, och högerklicka sedan i nedre delen på grupprubriken där du vill lägga till filerna och välj Lägg till befintliga filer...

- ## Ta bort en fil från ett projekt

  Välj delprojekt i övre delen av Hantering av automake, och högerklicka sedan i nedre delen på grupprubriken där du vill ta bort filerna och välj Ta bort.

## Problem med att kompilera och bygga

- ## Fel`version av` autoconf, etc.

  Det finns flera felmeddelanden som berör för gamla versioner av autoconf, etc. som förhindrar att `configure` fungerar som det ska. Kör `autoreconf` i katalogträdet där filerna `configure.in` i fråga finns. Kommandot försöker uppdatera informationen i &GNU; byggsystemfiler. Se `man autoreconf` för mer information.

## Utveckling på Unix

### Några historiska anmärkningar

Från början har Unix upprätthållit två mycket olika utvecklingsmodeller. Den ena är sfären av programspråk för system och tillämpningar, där en källkod översätts till maskinkod med en kompilator eller tolk. Programspråket C är ett exempel på detta. Unix var den första operativsystemkärnan som skrevs i ett högnivåspråk istället för maskinnära assembler, som var vanligt innan dess. (I själva verket uppfanns till och med språket C för att skriva Unix-kärnan, och tillhörande program, på en DEC PDP-11 dator.)

Den andra modellen är sfären med skriptspråk, som startade med uppfinningen av Unix-skalet, som samtidigt var operativsystemets användargränssnitt, och ett programspråk på mycket hög nivå. Ett skalskript byggs upp av en mängd små verktyg som t.ex. `grep`, `sed` eller `find`. Varje sådant verktyg är konstruerat för en väl avgränsad uppgift. Tricket är att alla sådana verktyg kan kopplas ihop med varandra via en enkel överföringsmekanism, kallat rörledning, som skickar utmatningen från föregående verktyg till inmatningen för nästa. Det ger grunden till en mycket kraftfull och flexibel programmeringsmetod.

Med tiden har båda sfärerna utvecklats. Medan C fortfarande i huvudsak används som ett systemprogramspråk, har C++, som en variant av C berikad med objektorienterade och generiska utökningar, funnit sin plats vid utveckling av komplexa program under 1990-talet. Det finns många andra programspråk, till och med äldre behåller sin plats. FORTRAN77 och Ada har t.ex. fortfarande sina fästen i numeriska tillämpningar.

### Moderna skriptspråk

I skriptområdet har det skett ett skifte bort från skalet, som lider av flyttbarhetsproblem, till språk som samlar alla vanliga funktioner i standardbibliotek, medan de fortfarande kan ha gränssnitt mot omvärlden via rörledningar när det behövs.

Alla skriptspråk har gemensamt att de ofta är flyttbara mellan många Unix-varianter, &Microsoft; &Windows;, &Mac;-OS eller till och med VMS. Dessutom har de alla implementeringar som kan distribueras fritt.

#### &perl;

&perl; har blivit populärt som textbehandlings- och systemadministrationsspråk. Från starten av webben användes CGI-skript skrivna i &perl; som ett utbrett sätt att skapa dynamiska webbsidor från databaser. Idag har den metoden ofta ersatts med insticksprogrammet `mod_perl` för webbservern &apache;. Bland &perl;s styrkor är dess inbyggda stöd för avancerade reguljära uttryck, och rika arkiv med fritt distribuerade moduler, se CPAN.

#### Python

&python; glänser med elegansen i sitt klassystem och enkelheten och flexibiliteten som yttre bibliotek kan förpackas, på så sätt att de förefaller vara standardklasser och -funktioner i &python;. I motsats till &perl;, har &python; ett klart och koncist inbäddningsgränssnitt, som gör det till bästa val för att möjliggöra skript för C och C++ program.

#### PHP

&php; uppfanns som ett språk för direkt inbäddning på HTML-sidor, och har av den orsaken huvudanvändningen att leverera dynamisk innehåll för webben.

### DCOP-gränssnittet

En annan evolution av Unix-liknande skript är DCOP-protokollet. DCOP betyder Desktop COmmunikation Protocol (protokollet för skrivbordskommunikation), och är implementerat som en enkel IPC/RPC-mekanism byggd för att fungera via uttag. Sluteffekten är att erbjuda funktioner som liknar den traditionella rörledningsmekanismen i Unix.

Traditionella skalskript är baserade på ganska små programverktyg, som konstruerades för att enbart fungera baserade på ren text. DCOP tillåter att avancerade grafiska program kommunicerar med varandra på ett motsvarande sätt. Det gör det till exempel möjligt för ett &kde;-program att skicka meddelanden till ett annat &kde;-program, eller ta emot data från det för sitt eget syfte.

Det finns dock nackdelar. För att använda DCOP, måste programmet vara konstruerat med ett speciellt DCOP-gränssnitt. Dessutom går DCOP-kommunikationsprocessen något långsamt. Ändå så ger det mycket av styrkan och flexibiliteten i Unix-skript till högnivåprogram som är baserade på ett grafiskt användargränssnitt.

För ytterligare information, se DCOP Desktop COmmunication Protocol library, dokumentation av användargränssnittet hos &kde;:s DCOP-bibliotek.

### Byggsystem

Utom i mycket enkla fall, kommer programmeringsprojekt att bestå av många byggblock med källkod, vart och ett placerat i en enskild fil för enklare underhåll. För att få allt att köra, måste du effektivt kunna översätta allt detta till några få maskinkodsenheter med lämpligt format, som gör att operativsystemet kan ladda och köra programmet.

För att åstadkomma detta, är de grundläggande verktyg du behöver:

- en texteditor för att skriva källkodsfilerna,

- ett översättningsprogram, oftast en kompilator för att omvandla källkoden till objektfiler,

- ett biblioteksprogram som samlar objektfiler i bibliotek, som enkelt kan återanvändas utan att behöva kompileras om,

- en länkare, som binder ihop flera objektfiler och bibliotek till ett körbart program,

- ett byggsystem, som erbjuder något sätt att hantera allt detta, och inte att förglömma,

- en avlusare för att (förhoppningsvis) hitta alla fel i programmet, och möjligen ytterligare diagnosverktyg för att få allt att köra smidigt.

När man har ett stort projekt, som kan bestå av upp till hundratals källkodsfiler, kan kompileringsprocessen bli riktigt arbetsintensiv. Man vill inte kompilera om alla filer varje gång några av dem har ändrats. Istället vill man bara kompilera om de filer som påverkas av ändringen. I allmänhet är det inte självklart vilka det är. När en funktionsprototyp i en deklarationsfil har ändrats, måste alla filer som beror på deklarationsfilen kompileras om.

#### Byggprocessen

Ett verktyg som tar hand om omkompileringar är `make`. Det håller reda på allt arbete med en uppsättning regler, som beskriver vad som ska göras i händelse någon viss information (oftast en källkods- eller objektkodsfil) ändrades. Alla regler som hör till ett visst projekt lagras i en så kallad `Makefile`, som behandlas av `make` så fort du vill uppdatera arbetet.

Varje regel består av flera byggblock, närmare bestämt

- ett mål, dvs filen som ska byggas

- en uppsättning beroenden, i grunden namnen på de filer som målet beror på (t.ex. namnet på en källkodsfil, när målet är namnet på objektfilen som ska byggas) och

- de kommandon som ska köras för att bygga målet (dvs. för att kompilera det eller länka ihop andra objektfiler för att skapa en körbar programfil).

Enkelt uttryckt, läser kommandot `make` reglerna en i taget, kontrollerar varje fil i beroendelistan för ett givet mål, och bygger målet igen om någon av filerna har ändrats, med de kommandon som listas i regeln.

Det finns flera ytterligare möjligheter att styra en sådan byggprocess, och en `Makefile` kan på så sätt växa sig mycket komplex. Vi kan inte gå in på detaljer här. Hur som helst, rekommenderar vi att du gör dig bekant med syntaxen för `make`. Även om du inte normalt använder det direkt, kan en förståelse för grunderna i byggsystemet vara användbar. Se GNU make manualen för mer information.

För mer detaljinformation specifik för &kdevelop;, se Bygga och projekthantering i den här handboken.

Det finns flera handledningar tillgängliga, se referenserna i kapitlet Bygga och projekthantering.

### Utveckling av grafiska gränssnitt

Programutvecklare blir ännu mer belastade genom att de inte bara måste skapa programbibliotek och logiken, men också tillhandahålla lättanvända egenbyggda användargränssnitt som både är enkla att förstå och funktionella. De flesta programmerare får liten eller ingen utbildning i utveckling av grafiska gränssnitt, och som ett resultat är användargränssnitt ofta dåligt konstruerade.

Under många år har några gemensamma designprinciper utvecklats. Du rekommenderas starkt att hålla dig till dem. På så sätt behåller ditt användargränssnitt ett gemensamt utseende och känsla, som användare av programmet tacksamt uppskattar.

För utveckling av grafiska gränssnitt för &kde; finns en stilguide tillgänglig. Den finns som &kde;:s guide för användargränssnitt på sidan &kde;:s utvecklingshörna.

### Integration av koncept och verktyg: den integrerade utvecklingsmiljön

Det finns separata verktyg tillgängliga för nästan varje steg i programmeringsprocessen: planering, redigering, processen för att hantera filer och kompilering, avlusning, dokumentation med mera. Men när projekten växer, blir programmeringsprocessen troligtvis ganska omständlig.

Mycket repetitivt arbete måste göras vid konstruktion, kompilering och avlusning av ett program. En hel del arbete kan sparas genom att använda mallar och skript. Ytterligare arbete kan sparas genom att ha verktygen lätt tillgängliga, och med möjlighet att kommunicera med varandra i ett gemensamt grafiskt gränssnitt. Det är verkligen bekvämt om till exempel en avlusare kunde öppna källkoden i fråga i en editor, och placera markören direkt på platsen för felet som just hittats.

För att enklare uppnå ett sådant fall, togs integrerade utvecklingsmiljöer (IDE) fram. En sådan miljö integrerar alla mallar, verktyg och skript som behövs i utvecklingsprocessen i en enda omgivning.

&kdevelop; är en sådan integrerad utvecklingsmiljö för &kde;-plattformen. Den erbjuder ett brett spektrum av verktyg som underlättar programutveckling och underhåll, till och med för olika programspråk och olika plattformar.

#### Grundläggande funktioner i &kdevelop;

- Hanterar alla utvecklingsverktyg som behövs för C++ programmering, som kompilatorn, länkaren, avlusaren och byggsystemet

- Tillhandahåller programguiden som skapar fullständiga, körklara exempelprogram

- En integrerad editor baserad på programmeringseditorn Kwrite eller TrollTechs Qeditor

- En klassgenerator för att skapa nya klasser och integrera dem i det nuvarande projektet

- Filhantering för källkod, deklarationer, dokumentation, etc. som ska ingå i projektet

- Hjälp med att skapa en användarhandbok för programmet skriven med KDE-verktyg

- Automatisk HTML-baserad dokumentation av programmeringsgränssnitt för projektets klasser med korsreferens till använda bibliotek

- Översättningsstöd som gör det möjligt för översättare att enkelt lägga till sitt modersmål i projektet, inklusive stöd för Kbabel

- Stöd för att hantera ett projekt via CVS, genom att tillhandahålla ett lättanvänt gränssnitt till funktionerna som oftast behövs

- Integrerad avlusning

- En terminal

- Syntaxfärgläggning

- Automatisk kodkomplettering för klassvariabler, klassmetoder, funktionsargument med mera

- Mallar för att skapa diverse projekt (moduler i inställningscentralen, miniprogram i panelen Kicker, I/O-slavar, insticksprogram till Konqueror och skrivbordsstilar)

- Fyra trädvyer för att enkelt byta mellan källkodsfiler, deklarationsfiler, klasser och dokumentation, vilket gör det onödigt med en extern filhanterare

- Stöd för korskompilering, med möjlighet att ange olika kompilatorer, kompilatorflaggor, målarkitektur etc.

- Stöd för projekt med Qt/Embedded (som Zaurus och IPAQ)

- Möjlighet att inkludera vilket annat program som helst som du behöver för utveckling genom att lägga till det i menyn Verktyg, enligt dina individuella behov

## Installera &kdevelop;

Här hittar du alla steg som behövs för att kompilera och installera den integrerade utvecklingsmiljön &kdevelop;:

- Hur man skaffar &kdevelop; koncentrerar sig på hur man laddar ner den senaste källkoden för &kdevelop; från CVS.

- Krav för &kdevelop; listar programmen och biblioteken som du måste ha installerade för att kompilera den integrerade utvecklingsmiljön med lyckat resultat.

- Kompilering och installation av &kdevelop; leder dig igenom alla steg för kompilering och installation av programmet.

- Hur man skaffar dokumentation av programmeringsgränssnittet för &kdevelop; talar om vad ett programmeringsgränssnitt är och hur du skaffar ett så användbart verktyg för navigering i källkoden för &kdevelop;.

### Hur man skaffar &kdevelop;

&kdevelop; är tillgänglig i binärform från många olika &Linux;-distributioner som SuSE, RedHat med flera. Binärfilerna är paketerade på något bekvämt sätt, oftast RPM, för att enkelt kunna installeras. Följ standardinstruktionerna som ges i distributionen för att installera.

Du kan mycket väl skaffa källkoden för &kdevelop;, kompilera och installera den själv. Källkoden hittas via projektets hemsida på http://www.kdevelop.org eller via &kde;:s FTP-plats.

#### Hämta dagsfärska versioner av &kdevelop; från &CVS;

Om du vill vara en del av den nuvarande utvecklingen, är versioner via anonym &CVS; från arkivet också tillgängliga. Modulnamnet är kdevelop på `:pserver:anonymous@anoncvs.kde.org:/home/kde`.

##### Ursprunglig utcheckning från &CVS;

För att skaffa en ursprunglig version av &kdevelop; måste du ladda ner den (en så kallad utcheckningsåtgärd) från anonym &CVS;. Följ bara stegen nedan. (Vi antar att du vill placera din kopia av &kdevelop; i katalogen `kde3src`.)

- `~>` `mkdir kde3src`
- `~>` `cd kde3src`
- `~/kde3src>` `cvs -z3 -d :pserver:anonymous@anoncvs.kde.org:/home/kde co kdevelop`
- `~/kde3src>` `cd kdevelop`

Nu kan du kompilera din version av &kdevelop; som visas i kapitlet Kompilering och installation av &kdevelop;.

När du väl har lyckats checka ut din version av &kdevelop;, kan du hänga med i ändringarna genom att använda uppdateringsproceduren som visas i nästa avsnitt. Var vänlig att inte checka ut varje gång du vill få en aktuell version av &kdevelop;!

##### Hålla din kopia av&CVS; aktuell

Efter du checkat ut &kdevelop; från CVS som visas ovan (och kompilerat med lyckat resultat), vill du hålla den aktuell för att få med alla programfixar. Följ då stegen nedan. (Återigen antar vi att du har placerat din kopia av &kdevelop; i katalogen `kde3src`.)

Observera kommandot `up` (= update) istället för `co` (vilket betyder checkout).

- `~>` `cd kde3src`
- `~/kde3src>` `cvs -z3 -d :pserver:anonymous@anoncvs.kde.org:/home/kde up kdevelop`
- `~/kde3src>` `cd kdevelop`

Håll ett öga på meddelanden som &CVS; visar under uppdateringssekvensen. De exakta stegen i kompileringssekvensen beror på dem.

Nu kan du kompilera en ny version av &kdevelop; som visas i kapitlet Särskilda hänsyn vid kompilering från &CVS;.

### Krav för &kdevelop;

För att kompilera och använda &kdevelop; med lyckat resultat, behöver du följande program och bibliotek. De är tillgängliga på de flesta plattformar som distributionspaket, och kan därigenom lätt installeras.

### Krävs

- gcc/g++ 2.95.3 eller senare (eller motsvarande)

- &gnu; make (eller motsvarande)

- &perl; 5.004

- autoconf 2.52 eller senare

- automake 1.6.1 eller senare

- flex 2.5.4

- Qt 3.0.3 eller senare

- KDE 3.0.4 eller senare

### Valfritt:

- Verktyget ctags för källkodsnavigering, från http://ctags.sourceforge.net, som ger dig snabb åtkomst till deklarationer och definitioner med några få enkla klick på ett namn i editorn.

- Kompilatorn dot för grafikspråk, från http:/www.graphviz.org. Verktyget behövs tillsammans med &doxygen; nedan, om du vill visa klassförhållanden grafiskt (vilket starkt rekommenderas).

- Dokumentationsverktyget &doxygen;, från http://www.doxygen.org, om du vill skapa koncis och kraftfull dokumentation av programmeringsgränssnittet för dina projekt.

- Valgrind från http://developer.kde.org/~sewardj/ hjälper dig att hitta minneshanteringsproblem i program.

- CVS från http://www.cvshome.org, om du vill använda versionshanteringssystemet &CVS;.

- Eventuellt andra kompilatorer och/eller verktyg om du vill utveckla för ett annat språk eller plattform än C++/&kde;, eller använda någon annan specialfunktion.

1. Du kan kringgå behovet av &autoconf; ≥ 2.52 och &automake; ≥1.6.1. Ta bara bort katalogen `admin` i installationskatalogen för &kdevelop;, och skriv:

   `(din kdevelop-katalog)>` `ln -s $KDEDIR/share/apps/kdelibs/admin admin`

   i terminalen. Det gör att &kdevelop; använder standardinställningarna i &kde;:s `admin`-katalog istället.

2. Var försiktig så att du inte blandar olika versioner av &qt;. Länka alltid &kdevelop; med samma version av &qt; som &kde;-biblioteket kompilerades med. Annars råkar du troligen ut för mycket konstigt beteende.

### Kompilering och installation av &kdevelop;

#### Förberedande steg

Innan du påbörjar kompileringssekvensen, måste du försäkra dig om att alla bibliotek och verktyg är tillgängliga för byggsystemet. För att uppnå detta, måste vissa miljövariabler ställas in riktigt. Stegen som ska utföras beror på vilket skal du använder i terminalen.

För att undvika att skriva in alla satserna som ställer in nödvändiga miljövariabler varje gång du vill kompilera, kan du placera dem i filen `.bashrc` eller `.cshrc`. På så sätt ställs miljövariablerna in riktigt varje gång du startar skalet.

##### bash-skalet

Om du använder bash-skalet, lägg till följande rader:

    export KDEDIR=(där din kde3 finns)
    export QTDIR=(där ditt qt-bibliotek finns)
    export LD_LIBRARY_PATH=$QTDIR/lib:$KDEDIR/lib:$LD_LIBRARY_PATH
    export LIBRARY_PATH=$QTDIR/lib:$KDEDIR/lib:$LIBRARY_PATH
    export PATH=$QTDIR/bin:$KDEDIR/bin:$PATH

##### tcsh-skalet

Om du använder tcsh-skalet, lägg till följande rader:

    setenv KDEDIR (där din kde3 finns)
    setenv QTDIR (där ditt qt-bibliotek finns)
    setenv LD_LIBRARY_PATH $QTDIR/lib:$KDEDIR/lib:$LD_LIBRARY_PATH
    setenv LIBRARY_PATH $QTDIR/lib:$KDEDIR/lib:$LIBRARY_PATH
    setenv PATH $QTDIR/bin:$KDEDIR/bin:$PATH

#### Kompilera &kdevelop;

I följande beskrivning antar vi att du har placerat källkoden för &kdevelop; i katalogen `~/kde3src/kdevelop`.

##### Särskilda hänsyn vid kompilering från &CVS;

Om du använder en aktuell version av &kdevelop; från &CVS;, beror de första kompileringsstegen på om du just gjort en fullständig utcheckning, eller bara uppdaterat källkoden.

##### Efter en utcheckning från CVS

Du måste initiera byggsystemet efter en ny utcheckning. Samma sak gäller varje gång du måste starta om från början. (Observera att du måste ha tillgång till &CVS;-arkivet för att rensa.) Skriv:

`~/kde3src/kdevelop>` `make -f admin/Makefile.common cvs-clean`

och därefter alla följande steg.

##### Efter en uppdatering från CVS

Nästa steg beror på utmatningen från &CVS;-uppdateringssekvensen. Om du fick något som liknar följande (observera markören U till vänster):

    U /någon_sökväg/Makefile.am

eller om du precis gjort en fullständig utcheckning, måste du skriva:

`~/kde3src/kdevelop>` `make -f Makefile.cvs`

innan du fortsätter med alla följande steg.

##### Grundläggande kommandosekvens med `make`

När det grundläggande byggsystemet har ställts in på detta sätt, måste du bestämma dig för vilket sorts &kdevelop;-system du vill använda. Det görs med följande konfigureringssteg, som bygger de verkliga filerna med namn `Makefile`, som `make` kommandot kommer att använda.

Du kan utelämna väljaren `--prefix` i följande kommandorader med `configure`, om du vill att &kdevelop; ska installeras i &kde;:s standardkatalog. Se kapitlet Några anmärkningar om väljare till `configure` om detta.

##### En version kompilerad för avlusning

Om du vill hålla ordning på vad programmet &kdevelop; gör när det kör, kan du bygga en version kompilerad med avlusning. Tala bara om för `configure` att göra det:

`~/kde3src/kdevelop>` `./configure --enable-debug=full --prefix=(där din kde3 finns)`

##### En version kompilerad för distribution

Om du bara vill använda &kdevelop; som det är (mindre och snabbare), räcker det med en version kompilerad för distribution. Det är förvalt i `configure`.

`~/kde3src/kdevelop>` `./configure --prefix=(var din kde3 finns)`

Om du vill skapa din egen dokumentation av programmeringsgränssnittet för &kdevelop;, måste du ta med ytterligare en väljare i kommandot `configure`:

`~/kde3src/kdevelop>` `./configure --(väljare enligt ovan) --with-kdelibsdoxy-dir=$KDEDIR/share/doc/HTML/en/kdelibs-apidocs`

##### Bygga och installera &kdevelop;

Kommandot `configure` kontrollerar systemet och bygger en `Makefile` enligt vad det hittar. Kommandot `make` använder normalt denna `Makefile`. Alltså är

`~/kde3src/kdevelop>` `make`

tillräckligt. Om nödvändigt, skaffa rättigheter som systemadministratör genom att skriva

`~/kde3src/kdevelop>` `su`

och ange systemadministratörens lösenord. Installera sedan programmet:

`~/kde3src/kdevelop>` `make install`

Det är allt. Om du installerade &kdevelop; i &kde;:s standardkatalog, kan du nu köra den integrerade utvecklingsmiljön. Annars är några ytterligare steg nödvändiga, som visas i avsnittet Annan installationskatalog än standard nedan.

#### Hur man kompilerar på FreeBSD

Om du vill kompilera och installera &kdevelop; på ett FreeBSD-system, följ de normala instruktionerna, men därefter

`~/kde3src/kdevelop>` `make -f Makefile.cvs`

gör:

`~/kde3src/kdevelop>` `export CXXFLAGS="-L/usr/X11R6/lib -I/usr/local/include/db41 -I/usr/local/include -L/usr/local/lib -I/usr/X11R6/include"`

Du måste ha installerat Berkeley db 4.1. Om du har en annan version, måste du justera sökvägen.

##### Kontrollera version av Berkeley db

För att ta reda på vilken version av Berkeley db du har installerat, kör:

`~>` `pkg_info | grep db41`

Det ska returnera något som liknar:

    db41-4.1.25_1       The Berkeley DB package, revision 4.1

##### Mer ändringar

Ändra raden

`ac_cv_bdb=no`

till

`ac_cv_bdb=yes`

i filen `configure`, annars hittar inte configure db-biblioteken.

Eftersom `make -f Makefile.cvs` bygger om filen `configure`, måste du dessutom alltid ändra den här raden.

FreeBSD-utvecklarna bytte namn på `libdb.so` till `libdbxx.so`. Så ersätt

`libkdevcatalog_la_LIBADD = -ldb`

med

`libkdevcatalog_la_LIBADD = -ldb41`

i `lib/catalog/Makefile.am`.

Därefter kan du fortsätta med de vanliga stegen `configure` och `make`, som visas ovan.

#### Några anmärkningar om väljare till `configure`

##### Annan installationskatalog än standard

Normalt förbereder `configure` för att installera den grafiska utvecklingsmiljön i &kde;:s standardkatalog. Det behövs, eftersom &kdevelop; antar att det går att direkt komma åt vissa verktyg och delprogram som finns där. Om du vill använda din egen installationskatalog, måste du tala om det för `configure` med väljaren `--prefix`:

`~/kde3src/kdevelop>` `./configure --prefix=(var din kde3 finns)`

Det finns ett problem om du gör det. Du måste ge möjlighet för &kdevelop; att komma åt nödvändiga verktyg och delprogram i &kde;:s katalog. (Du kan fortfarande använda den integrerade utvecklingsmiljön utan att göra det, men med mycket begränsade funktioner.) Du måste använda ett skal, och följande kommandon måste köras innan du kan starta &kdevelop; från skalet.

(Observera S:et som sista bokstav: KDEDIRS, inte bara KDEDIR)

- `(din kdevelop-katalog)>` `export KDEDIRS=/usr/local/kde:/opt/kde3`
- `(din kdevelop-katalog)>` `kbuildsycoca`

I ett tcsh-skal måste du ställa in miljövariablerna genom att använda:

`(din kdevelop-katalog)>` `setenv KDEDIRS /usr/local/kde:/opt/kde3`

Kommandot `kbuildsycoca` (bygg systemkontrollcache) söker efter bibliotek och lagrar deras plats och version i en cache, så att &kdevelop; kan hitta dem. Problemet är att det tar märkbart med tid, och måste köras varje gång du använder skalet för att starta &kdevelop; med en annan installationskatalog än standardkatalogen. Du skulle kunna skriva in ovanstående kommandon i ett skalskript för att reducera ansträngningen att skriva in det.

(Du skulle också kunna skriva in raderna i filen `.bashrc` eller `.cshrc`, men det är inte önskvärt eftersom då körs `kbuildsycoca` varje gång du använder skalet.)

Kommandot `kbuildsycoca` kör inte för systemadministratören. Du måste anropa det som en annan användare. (Men det är inte en särskild god idé att utveckla som systemadministratör!)

##### Andra alternativ

(... ännu inte skrivet ...)

### Hur man skaffar dokumentation av programmeringsgränssnittet för &kdevelop;

Programmeringsgränssnittet, Application Program Interface på engelska, ofta förkortat API, är i själva verket en följd av beskrivningar (dvs. anropsmodeller) som ett program använder för att komma åt operativsystem och andra tjänster. I vårt fall har dock en mer omfattande definition använts. Programmeringsgränssnittet för ett &kde;- eller &Qt;-program är en sammanfattning av klasser och metodgränssnitt, en översikt som kan användas som uppslagsbok för navigation i källkoden.

Det finns en version av det senaste programmeringsgränssnittet på KDevelops hemsida. Den uppdateras automatiskt varje dygn så att du kan hänga med.

Tyvärr används den här versionen bäst bara för att läsa via Internet. Du kan ändå lika väl bygga din egen dokumentation av programmeringsgränssnittet från källkoden för &kdevelop;. För att göra det, måste du tala om det för automake-systemet när du ska kompilera &kdevelop; källkoden. Det åstadkoms med en särskild väljare i kommandot `configure`:

`~/kde3src/kdevelop>` `./configure --(vanliga väljare) --with-kdelibsdoxy-dir=$KDEDIR/share/doc/HTML/en/kdelibs-apidocs`

(`make` ersätter `$KDEDIR` med den verkliga &kde;-katalogen). Utför sedan kommandot `make` som vanligt. Efter att den integrerade utvecklingsmiljön &kdevelop; har byggts, har du möjlighet att också bygga programmeringsgränssnittet. För att göra det måste du skriva:

`~/kde3src/kdevelop>` `make apidocs`

Detta bygger en `Doxyfile` i baskatalogen för &kdevelop;, som i sin tur behandlas av programmet doxygen för att skapa en hel del `.html`-filer för programmeringsgränssnittet. När den ganska långa byggprocessen för programmeringsgränssnittet till sist är klar, måste du installera programmeringsgränssnittet precis som du måste installera själva den integrerade utvecklingsmiljön &kdevelop;. Skaffa rättigheter som systemadministratör om det behövs med:

`~/kde3src/kdevelop>` `su`

och ange systemadministratörens lösenord. Installera sedan dokumentationsfilerna:

`~/kde3src/kdevelop>` `make install-apidox`

När det här väl är gjort, informerar `make` dig om katalogen där du till sist kan titta på innehållet i dokumentationen av programmeringsgränssnittet. Observera adressen, eftersom du kan använda den från &konqueror; samt inne i &kdevelop;, om du har ställt in den egna källkoden för &kdevelop; som projektet att arbeta med.

## Översikt: Funktioner i &kdevelop;

&kdevelop; integrerar många verktyg, skript och mallar med ett gemensamt användargränssnitt. De grundläggande delarna är

- flera lägen för användargränssnittet som du kan använda för att välja arbetsområdets utseende och känsla,

- en programguide, som hjälper dig ställa in ett nytt projekt,

- flera system för projekthantering, som hjälper till att bygga och hantera projektet,

- några redigeringsverktyg för att enkelt kunna arbeta med programtexten,

- diverse filbläddrare, som ger dig olika vyer av filsystemet,

- diverse klassbläddrare för att hjälpa dig underhålla klasser och deras förhållanden i ett objektorienterat programmeringsprojekt,

- ett avlusningsgränssnitt för att hitta och ta bort programfel inifrån &kdevelop;, och

- flera insticksverktyg, utökningsbara moduler, eller delprogram, som laddas när programmet kör och vid behov. Det gör det möjligt för dig att bara aktivera de funktioner som du verkligen behöver.

- en uppsättning andra diagnos-, dokumentations- och optimeringsverktyg.

### Tillgängliga lägen för användargränssnitt

&kdevelop; erbjuder fyra olika gränssnittslägen (klicka på lägesnamnet för att se ett exempel):

- Underramsfönster

  - Alla verktygsvyer är från början dockade i huvudramen.

  - Editor- och bläddrarfönster existerar som toppnivåfönster inne i ett vyområde i huvudramen.

- Fliksidor

  - Alla verktygsvyer är från början dockade i huvudramen.

  - Editor- och bläddrarfönster överlagras i ett fönster med flikar.

- Toppnivåfönster

  - Alla editor-, bläddrar- och verktygsfönster är toppnivåfönster direkt på skrivbordet.

  - Huvudkomponenten innehåller bara menyraden, verktygsrader och statusraden.

- IDEA-fönster

  Det här är ett nytt sorts användargränssnitt som både optimerar arbetsutrymmet och ger en intuitiv användning av verktygen.

  - Alla verktygsfönster är dockade som en flikrad omkring huvudramens område. De är grupperade till vänster, längst ner och till höger enligt de tjänster de erbjuder.

  - Editor- och bläddrarfönster överlagras i ett stort fönster med flikar mitt i huvudramens område.

#### Hur man byter läge för användargränssnitt

För att byta läge för användargränssnittet, välj Inställningar Anpassa KDevelop... i menyraden. Dialogrutan Anpassa KDevelop dyker upp, där du måste välja Användargränssnitt i fältet till vänster. Då kommer du till inställningssidan som visas nedan:

Välj ett användargränssnittsläge

Markera alternativknappen för gränssnittsläget du vill byta till, och tryck därefter på Ok.

1. Om du byter till eller från IDEA-läget (utan fönster), måste du starta om &kdevelop;.

2. För närvarande tillhandahålls två IDEA-lägen, ett IDEA-läge med fönster och ett standard IDEA-läge (understa raden bland alternativknapparna). Fönsterläget passar ihop med övriga lägen med flera fönster, men är fortfarande experimentell. Du behöver inte starta om &kdevelop; om du väljer detta bland övriga tre lägen med flera fönster. För närvarande rekommenderas det dock att använda standardläget för dagligt arbete.

#### Hur man maximerar arbetsområdet

Det finns ett fullskärmsläge tillgängligt för att maximera utrymmet, som expanderar huvudramens område till skärmkanterna. Ytterligare utrymme kan återtas genom att dölja menyraden. Du kan förstås också dölja alla verktygsrader, som vanligt i KDE-program.

#### Fullskärmsläge

För att byta från eller till fullskärmsläge, välj Visa Fullskärmsläge i menyraden, eller tryck på Ctrl Skift F. Det finns också en ikon för Fullskärmsläge i Bläddringsverktygsraden.

#### Visa eller dölj menyraden

För att dölja menyraden, välj Inställningar Visa menyrad i menyraden, eller tryck på Ctrl M. Du kan också lägga till en ikon för Visa menyrad i en lämplig verktygsrad, t.ex. Bläddringsverktygsraden, för ändamålet. För att visa menyraden, måste du trycka på Ctrl M eller använda ikonen Visa menyrad om den är tillgänglig.

### Element i användargränssnittet

(... ännu inte skrivet ...)

### Projekthanteringssystem

Totalt sett beror ett projekt på någon form av projekthanteringssystem. &kdevelop; erbjuder fyra projekthanteringssystem som programmeraren kan välja bland när ett nytt projekt skapas.

- Automake-projekt använder de vanliga utvecklingsverktygen för &gnu;.

- Qmake-projekt använder Trolltechs Qmake-projekthantering.

- ANT-projekt använder Apaches ANT-projekthantering för Java-utveckling.

- Eget projekt kräver att du underhåller din egen `Makefile`.

#### Automake-projekt

Projekt som skapats med Hantering av automake i &kdevelop; gör det mycket lätt för utvecklare att använda de vanliga &gnu; utvecklingsverktygen. De tillhandahåller

- ett bättre sätt att skapa en `Makefile` och

- ett bra och säkert sätt för snabb anpassning till olika system med `configure`-skript skapade av autoconf.

#### Qmake-projekt

För utvecklare som glädjer sig åt flexibiliteten och känslan i &qt;:s qmake-system, erbjuder &kdevelop; möjlighet att hantera qmake-baserade projekt (.pro-filer) inne i det grafiska gränssnittet.

För mer information om Qmake-projekthantering se Qmake User Guide, som ska finnas med i distributionen, eller ta en titt på hemsidan Trolltech Documentation där du hittar Qmake-dokumentationen under Qt C++ GUI Application Development Toolkit.

#### ANT-projekt

Java-utvecklare kan vilja använda Apaches ANT-projekthantering för sina projekt. För att skapa ett nytt ANT-projekt i &kdevelop;, välj Projekt Nytt projekt... Java Ant project Application.

För mer information se Ant-projektets hemsida.

#### Eget projekt

Om du föredrar att underhålla din egen `Makefile` för projektet, kan du använda alternativet med ett eget projekt i &kdevelop;. Det kan vara passande i projekt med ovanlig struktur, eller om du vill behålla fullständig kontroll över byggprocessen.

Om du ändå inte verkligen behöver den egna projekthanteringens extra flexibilitet och kontroll, bör du fundera på Automake eller någon annan projekthantering, eftersom de förenklar bygg- och distributionsprocessen för program väsentligt.

#### Hur du kan distribuera ditt program

Distributionen av ditt program kräver inte att slutanvändaren har installerat något ytterligare än

- en lämplig kompilator,

- en länkare, och

- de lämpliga utvecklingsbiblioteken,

vilket åtminstone för C++ program oftast är fallet. Men du kan lika väl distribuera binärpaket av programmet. Hur som helst, behöver inte slutanvändaren av produkten installera &kdevelop;.

Om du ger bort din källkod, råder vi dig att också ta med projektfilen för &kdevelop;. Det gör det mycket enkelt för andra utvecklare, om de använder &kdevelop;, att arbeta med källkoden.

För projekt där flera utvecklare, som kanske arbetar på olika ställen, är inblandade, bör detta vara fallet ändå. Du kan försäkra dig om överensstämmelse för alla `Makefile`, för att inte råka ut för bekymmer.

Särskilt för program med flera språk, arbetar inte översättare direkt med källkoden, utom i fall som kräver rättning för att göra det möjligt med översättningsstöd.

## Anpassa &kdevelop;

(... ännu inte skrivet ...)

### Allmänna inställningsfrågor

(... ännu inte skrivet ...)

### Avancerade inställningar

(... ännu inte skrivet ...)

## Komma igång: Programguiden

Arbete med att utveckla programvara i &kdevelop; organiseras i projekt. Ett sådant projekt håller samman allt som hör till en fullständig programmeringsuppgift: källkodsfiler, ytterligare datafiler, alla hanteringsfunktioner som behövs som byggsystemet samt åtkomst till alla komponenter och ytterligare verktyg som behövs för att få programmet klart att köras.

Att organisera utvecklingsarbetet i projekt låter dig enkelt byta mellan befintliga övergripande uppgifter. Det här riktigt bekvämt om du till exempel arbetar med flera program samtidigt, vilket ofta är fallet. Tala om för &kdevelop; att öppna projektet du vill arbeta med, och du kan fortsätta i miljön precis där du tidigare lämnade den.

### Nya projekt

Så fort du vill starta ett nytt programmeringsprojekt, behöver en helt del formella inställningsprocedurer göras. En startstruktur för kataloger måste skapas, nya deklarationsfiler och källkodsfiler måste skapas, byggsystemet måste initieras, etc.

&kdevelop; tillhandahåller ett enkelt sätt att starta ett nytt programmeringsprojekt: programguiden. Du hittar programguiden via menyalternativet Projekt Nytt projekt.

Det behövs bara ett fåtal steg för att skapa ett nytt programmeringsprojekt med programguiden:

1. Välj programspråk du vill använda, och typ av program som du vill skapa från en uppsättning fördefinierade mallar.

2. Tillhandahåll en del allmän information som programnamn, katalog där programmet ska byggas, etc.

3. Bestäm om du vill använda ett versionskontrollsystem, som t.ex. CVS, och tillhandahåll nödvändig information som behövs.

4. Ställ in några mallar för ursprunglig deklarationsfil och källkodsfil (om nödvändigt).

5. Tala till sist om för programguiden att skapa alla nya saker, katalogstruktur, startmallar för deklarationsfiler och källkodsfiler, och hanteringsverktyg som ett startskelett för att bygga programmet, etc.

Voilà, det är allt. Programguiden har nu gett dig en första fungerade uppsättning programfiler, där du enkelt kan börja arbeta.

Låt oss nu ta en mer detaljerad titt på allt detta...

#### Inledande steg

För att skapa ett nytt projekt i &kdevelop;, välj Nytt projekt i menyn Projekt. Du ska då se guiden för att skapa nytt projekt, som visas nedan:

Inledande dialogruta för att skapa ett nytt projekt

Som du kan se, är dialogrutan uppdelad i en övre och undre del. I den övre delen kan du bestämma dig för programspråk och programtyp. Den under delen innehåller en del allmän information.

##### Välj programspråk och programtyp

Du gör dina val på vänstersidan längst upp i dialogrutan. När den visas finns en lista med kataloger, var och en med namnet på ett programspråk, som till exempel:

- Ada

- C

- C++

- Fortran

- Java

- PHP

- Pascal

- Perl

- Python

- Ruby

- Skal

För att precisera, innehåller katalogerna i själva verket inte riktiga programmeringsverktyg. De leder till fördefinierade mallar som du kan använda som utgångspunkt för utveckling i ett språk. För att få en idé om vad som erbjuds, öppna bara en katalog i taget. Det finns en följd underkataloger i vissa, men bara en eller flera enkla beteckningar i andra. Underkatalogerna du ser organiserar de tillgängliga mallarna enligt vissa uppgifter, de enkla beteckningarna namnger mallar som du kan välja.

Här kan vi inte i detalj gå in på vilka uppgifter varje mall tillhandahåller, men det är enkelt att ta reda på. Så fort du markerar en mallbeteckning, visas viss information i fälten till höger. I det nedre fältet ser du en kort beskrivning om vad mallen är avsedd att göra. I fältet ovanför visas en bild, om tillgänglig, med hur programmet som mallen producerar ser ut om du kompilerar och kör det utan ändring. Oftast är det en skärmbild av huvudfönstret som programmet visar.

Välj mallen som bäst passar målen för ditt program som startpunkt. Skriv därefter in information om allmänna egenskaper i de nedre fälten, som visas i nästa kapitel.

##### Ange allmän information

Den undre delen av sidan Allmänt i dialogrutan Skapa nytt projekt är ett inramat fält som heter Egenskaper. Du måste tillhandahålla en del allmän information om projektet här, så att programguiden vet hur den ursprungliga strukturen ska byggas.

##### Programnamn

Ditt program behöver förstås ett namn. Skriv in det i det övre fältet under Egenskaper, som heter Programnamn.

När du gör det, märker du att programguiden vägrar att acceptera specialtecken av något slag. De enda tecken som accepteras är:

- små och stora bokstäver

- siffror

- tecknet understreck

En framträdande orsak till begränsningen är att programguiden kommer att använda programnamnet som bas för vissa klassnamn som den skapar när den bygger upp projektet från början. Alltså måste projektets namn följa reglerna för programspråket som används.

##### Projektkatalogen

Den andra utmärkande orsaken för begränsningen ser du på nedersta raden i området Egenskaper. Den heter Slutgiltig plats, och visar katalogen där programguiden skapar programmet.

När du skriver in programmets namn märker du att programguiden repeterar det du skriver in längst ner på raden Slutgiltig plats, men bara med små bokstäver.

Alltså måste du välja namn på det nya programmet med försiktighet. Om du slutar med en katalog som redan används, låter inte programguiden dig fortsätta till nästa steg, genom att behålla knappen Nästa > inaktiv (grå). Den varnar dig också genom att lägga till (fil eller katalog finns redan) sist på raden Slutgiltig plats.

##### Startsökväg

Det finns två sätt att välja en annan sökväg till det nya programmet. En är att använda ett annat namn. Det är dock inte alltid möjligt (t.ex. skapar du kanske en ny version av ett befintligt program). Som ett alternativ kan du välja en annan sökväg till programkatalogen.

Det görs i den andra radens inmatningsfält under Egenskaper, som heter Plats. Det du skriver in här är överliggande sökväg för det nya programmets utvecklingskatalog. Programguiden lägger till programnamnet sist i sökvägen när det nya projektet skapas. Resultatet visas på raden Slutgiltig plats för att bättre visa vad som händer.

Programguiden kopierar ett startvärde till fältet Plats från början. Det hämtas från det du har valt under fältet Standardprojektkatalog under den allmänna inställningen.

Ändra innehållet i fältet Plats, så att utvecklingskatalogen för programmet som visas på raden Slutgiltig plats är unik.

Försäkra dig om att sökvägen du skriver in i fältet Plats redan finns. Annars kommer du inte att kunna fortsätta till nästa steg. Programguiden varnar dig om sökvägar som inte finns, genom att lägga till (ogiltig) sist på raden Slutgiltig plats.

##### Personlig information

Fälten som följer är inte så kritiska. Ange bara ditt namn (dvs. namnet på personen som är ansvarig för programmet) i fältet Upphovsman, och en giltig e-postadress i fältet E-post, så att användare kan ge dig återmatning om programmet.

1. Programguiden fyller i fälten med förvalda värden, som tas från e-postinställningarna i KDE:s inställningscentral. Om de förvalda värdena i fälten Upphovsman och E-post under Skapa nytt projekt inte passar, bör du kontrollera e-postinställningarna i KDE:s inställningscentral.

2. Programguiden sammanställer informationen till startprogrammallar om de finns. För KDE C++ program, hittar du den till exempel i början av källkodsfilen `main.cpp`.

3. Fältet E-post är det valfria bland fälten, vilket beror på att inte alla utvecklare har tillgång till Internet. Du kan lämna fältet tomt, och ändå fortsätta.

##### Versions- och licensinformation

Skriv till sist in startversion för det nya programmet i fältet Version, och välj licensen du vill ska gälla för ditt program i kombinationsrutan Licens.

Om du väljer en programtyp där programguiden tillhandahåller gemensamma källkodstextmallar (t.ex. C/C++), bör du titta på licensinformationstexten på tredje sidan i dialogrutan Skapa nytt projekt (se kapitlet Ange mallar för deklarationer och källkod nedan).

Om du valde Egen i kombinationsrutan Licens måste du själv tillhandahålla en licenstext.

Både version och licensinformation kommer också att infogas i startmallarna på ett lämpligt format som programtypen du väljer erbjuder.

När du har skrivit in all den här informationen på ett riktigt sätt, tryck på knappen Nästa > för att fortsätta, som visas i följande kapitel.

#### Ange information om versionssystem

I det andra steget, leder programguiden dig till sidan Versionskontrollsystem, där du kan bestämma vilket versionskontrollsystem du vill använda.

Den här beskrivningen koncentreras endast på behoven för att skapa projekt. För mer information om CVS, se kapitlet Använda CVS nedan.

#### Inget versionskontrollsystem önskas

Från början är Inget valt i kombinationsrutan Versionskontrollsystem, och sidan är för övrigt tom. Om du inte vill använda ett versionskontrollsystem, klicka bara på knappen Nästa för att fortsätta.

#### Använda CVS

Annars måste du välja versionskontrollsystemet som du vill använda i kombinationsrutan Versionskontrollsystem. För närvarande är bara &cvs; tillgängligt. Om du väljer det, visar programguiden sidan igen, men nu innehåller den ett antal fält som du måste fylla i.

Ställa in ett nytt projekt för CVS

Ett versionskontrollsystem som &CVS; (vilket betyder Concurrent Versions System) lagrar kopior av valda projektfiler i någon sorts databas. Om du använder &CVS;, kan du bland annat ladda upp (arkivera) filerna eller ladda ner dem till din projektkatalog (checka ut, eller uppdatera). Det särskilda med detta är att filerna i versionsdatabasen lagras på ett strukturerat sätt, vilket gör att du alltid kan återgå till ett tidigare utvecklingssteg om du behöver. &CVS; tillåter också flera utvecklare att ganska enkelt samarbeta i ett stort projekt (som &kdevelop;), utan att störa varandras arbete.

#### CVS-rot

&cvs; måste hantera versionsdatabasen som det har med dina projektfiler. För att åstadkomma det har det en del speciell databasinformation i en egen katalog, som kallas &cvs;-roten. Det första steget för att ställa in &cvs; för det nya projektet, är alltså att tala om för &kdevelop; var roten finns.

Lokal &cvs;-rot. Det finns två grundläggande möjligheter. Antingen vill du använda en lokal CVS-databas, eller använder du en databas som finns på en fjärrserver. Om du utvecklar på egen hand, kan du vilja använda &cvs;-databasen som ett sorts säkerhetskopieringssystem på din egen dator. Oftast skapas den i din hemkatalog och ges namnet `cvsroot`. Det kan se ut på följande sätt:

``/home/utveckling/cvsroot`` (där `devel` helt enkelt anger användaren utveckling, bara som ett exempel)

I själva verket är det här en förkortad form. Mer fullständigt ska den lokala &cvs;-roten adresseras med prefixet `:local:`. Den förkortade formen tillåts bara i fallen då filnamnet börjar med ett snedstreck (`/`). Det fullständiga namnet på vår lokala &cvs;-rot i exemplet skulle exakt se ut som: `:local:/home/utveckling/cvsroot`.

Skriv in namnet på &cvs;-rotkatalogen som systemet har ställts in för i fältet CVS-rot. I princip kan du välja vilket namn som helst, och till och med använda flera &cvs;-databaser, men det är lämpligt att behålla &cvs;-roten när den väl har ställts in.

Initiera en ny &cvs;-rot. Om det inte finns en&cvs;-root, ännu kan &kdevelop; ställa in &CVS;-systemet att skapa ett åt dig i den givna katalogen. Markera bara kryssrutan Initiera rot under fältet CVS-rot.

Som sagt, beordrar bara &kdevelop; &CVS;-systemet att initiera en ny &cvs;-rot. Det gör ingenting själv med katalogen. Som tur är, är &cvs; smart nog att kontrollera om &cvs;-rotkatalogen redan finns. Därför gör det ingen skada om du skulle ha markerat Initiera rot för en befintlig &cvs;-rotkatalog.

Fjärr &cvs;-rot. Det finns tillfällen då &cvs;-databasen ska finnas på en fjärrserver, särskilt när flera utvecklare arbetar med samma projekt. Då måste du skriva in &cvs;-rotens webbadress till servern i fältet CVS-rot. Om du till exempel vill komma åt &kde;:s &cvs;-server:

``:pserver:min_inloggning@cvs.kde.org:/home/kde`` (där `min_inloggning` anger inloggningsnamnet som är inställt i ditt &kde; &cvs;-konto)

#### Servertyper för fjärr-&cvs;

Det finns i huvudsak två fjärrservertyper för &cvs; med bred användning: pserver som använder ett lösenordssäkrat okrypterat protokoll, och ext-servern som använder krypterad dataöverföring via rsh eller ssh. De skiljs åt av webbadressprefixet de använder:

`:pserver:`

för den okrypterade typen lösenordsskyddad server, och

`:ext:`

för en servertyp krypterad med rsh eller ssh. Till exempel

``:ext:mylogin@cvs.cervisia.sourceforge.net:/cvsroot/cervisia``

kommer åt &cvs;-roten för det brett använda &cvs;-hanteringsverktyget Cervisia på servern SourceForge.

Om du vill använda en krypterad server via rsh eller ssh för att komma åt &cvs;, måste du tala om för &kdevelop; vilket krypteringsprotokoll som ska användas. Skriv bara in `rsh` eller `ssh` i fältet CVS_RSH på sidan Versionskontrollsystem i Skapa nytt projekt.

Det finns ett problem om du använder en krypterad server för &cvs; inne i &kdevelop;. Se kapitlet Använda CVS för detaljinformation.

#### &cvs;-arkivet

Hittills har du talat om för &kdevelop; var &cvs;-roten finns, som hanterar versionsdatabasen och hur den ska kommas åt. Nu måste du tala om för &kdevelop; vilket namn du vill att &CVS; ska använda för att spara dina projektfiler i databasen. Ett sådan ställe där projektfilerna lagras i &cvs;, kallas ett arkiv.

I princip kan du använda vilket namn som helst för projektfilernas &cvs;-arkiv, så länge det uppfyller specifikationerna för att namnge en fil. Oftast använder ändå de flesta utvecklare själva programmets namn. &CVS; bygger en katalog med namnet under &cvs;-roten, därför hittas det enklare om du behåller programnamnet för det.

Skriv bara in arkivnamnet som du vill använda i fältet CVS-arkiv på sidan Versionskontrollsystem under Skapa nytt projekt. I vårt exempel är det `Mitt_nya_program`.

Försäkra dig om att inte använda ett arkiv som redan finns!. &CVS;-systemet varnar inte för duplicerade filer, utan skyfflar in allting som inte producerar en formell konflikt. Du ställer till allting!

#### Återstående fält

Det återstår inte mycket arbete. Programguiden har redan ställt in återstående fält åt dig. Mer detaljerat:

Fältet Leverantörstagg används endast av kompatibilitetsskäl. Du kan behålla standardvärdet leverantör som programguiden skrivit in här.

Fältet Meddelande gör det möjligt att skriva in en kommentar om innehållet i &cvs; från början. Använd vilken text du vill, eller behåll bara standardvärdet nytt projekt som programguiden skrivit in.

Utgåvetagg innehåller namnet som används som tagg för det ursprungliga tillståndet för projektet. En sådan tagg namnger ett visst tillstånd i &CVS;-arkivet, som du senare kan använda för att komma åt det tillståndet för utvecklingen. (Se vidare i kapitlet Använda CVS.)

Programguiden har skrivit in standardtaggen start här, som är ett värdigt förslag. Behåll det bara.

Om något i all den här informationen är fel, märker &kdevelop; det oftast inte förrän projektet skapas. Det är &CVS;-systemet som hittar felen när det försöker skapa arkivet. Därför måste du hålla ett öga på fönstret Meddelanden i &kdevelop; när projektet skapas under det sista inställningssteget. Om det var något fel med &CVS;, ser du oftast ett felmeddelande som det här:

    * cd '/home/utveckling/test' && cvs -d '/home/utveckling/min_cvsrot' \
      import -m 'nytt projekt' '' 'leverantör' 'start' &&\
      sh /opt/kde3/share/apps/kdevcvs/buildcvs.sh . '' \
      '/home/utveckling/min_cvsrot'
    * cvs [import aborted]: /home/utveckling/min_cvsrot/CVSROOT: No such file or
      directory
    * *** Exited with status: 1 ***

Om det här händer, måste du antingen ställa in &cvs; för hand (&kdevelop; ska ha lyckats initiera dina projektfiler vid detta tillfälle) eller ta bort projektkatalogen och börja om igen med Nytt projekt i menyn Projekt.

Efter du har skrivit in all informationrelaterad till &CVS;, klicka på knappen Nästa > för att fortsätta.

Om du vill rätta ett fel på föregående sida i Skapa nytt projekt, tryck bara på knappen < Tillbaka. Programguiden kommer ihåg dina inställningar på nuvarande sida, så du kan enkelt fortsätta när du kommer tillbaka.

#### Ange mallar för deklarationer och källkod

Nästa steg tar dig till en serie sidor, där du kan ställa in vanlig information som du vill inkludera i dina källkods- och deklarationsfiler, om uppgiften i fråga tillåter.

Både deklarationsmallar och källkodsmallar tillhandahålls för C och C++ program, var och en på sin egen sida. För andra språk kanske det bara finns källkodsmallar. I vissa fall ser du till och med att mallsidan är tom.

Om sidan används, fyller programguiden i några vanliga kommentarer i sidhuvudet, som kan se ut så här för ett C++ baserat program:

    /***************************************************************************
     *   Copyright (C) 2003 by Ditt namn                                       *
     *   du@du.se                                                           *
     *                                                                         *
     *   This program is free software; you can redistribute it and/or modify  *
     *   it under the terms of the GNU General Public License as published by  *
     *   the Free Software Foundation; either version 2 of the License, or     *
     *   (at your option) any later version.                                   *
     *                                                                         *
     *   This program is distributed in the hope that it will be useful,       *
     *   but WITHOUT ANY WARRANTY; without even the implied warranty of        *
     *   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the         *
     *   GNU General Public License for more details.                          *
     *                                                                         *
     *   You should have received a copy of the GNU General Public License     *
     *   along with this program; if not, write to the                         *
     *   Free Software Foundation, Inc.,                                       *
     *   59 Temple Place - Suite 330, Boston, MA  02111-1307, USA.             *
     ***************************************************************************/

Andra mallar tillhandahåller liknande information på ett format enligt definitionen av programspråket du vill använda.

Som du kanske märkt, har programhanteringen redan fyllt i viss information som du angav på den fösta sidan Allmänt i dialogrutan Skapa nytt projekt, närmare bestämt innehållet i fälten Upphovsman och E-post. Riktig licensinformation har också infogats, enligt ditt val i kombinationsrutan Licens.

##### Hur mallarna kan redigeras

Mallarna som du ställer in i dialogrutan Skapa nytt projekt behandlas varje gång du talar om för &kdevelop; att skapa en ny källkodsfil och/eller deklarationsfil. Informationen som du anger här, inkluderas längst upp i ett dokumentationshuvud, innan koden börjar.

Du är dock inte begränsad till ren text. &kdevelop; känner till flera variabler, som låter dig inkludera riktig information i filen. Programguiden använda i själva verket just några sådana variabler för att inkludera information om Upphovsman, E-post och Licens i den ursprungliga malltexten.

##### Infoga filinformation från &doxygen;

Om du till exempel vill att dokumentationen av programvarugränssnittet som &doxygen; skapar, ska visa ytterligare information om filens innehåll i listan med filnamn, kan du lägga till följande rader i källkodsfilens mall:

    /**
     * \file $MODULE$.cpp
     * \brief (skriv en kort beskrivning här).
     **/

Så fort du skapar en ny källkodsfil, ersätter &kdevelop; variabeln `$MODULE$` med namnet på den nyskapade filen. Om du till exempel skapar en ny C++ klass som heter `EnEnkelTest`, ser du följande rader i filen `enenkeltest.cpp`:

    /**
     * \file enenkeltest.cpp
     * \brief (skriv en kort beskrivning här).
     **/

Du måste fortfarande tillhandahålla den korta beskrivningen efter nyckelordet \brief, men en del av jobbet har redan gjorts automatiskt åt dig.

##### Textfilen med licensen

Som ett annat exempel skulle du kunna inkludera en explicit referens till licenstexten som du vill använda i mallen. Använd variabeln `$LICENSEFILE$` för detta, och lägg till exempel till följande rad:

    //   Se $LICENSEFILE$ för den fullständiga licenstexten.

Programguiden ersätter `$LICENSEFILE$` med namnet på filen där den fullständiga licenstexten finns, nämligen:

    //   Se COPYING för den fullständiga licenstexten.

för GPL-licensen, eller

    //   Se LICENSE.BSD för den fullständiga licenstexten.

om du bestämmer dig för att använda BSD-license för programmet.

Det finns förstås fler variabler som &kdevelop; känner till. Se avsnittet Redigera mallarna i kapitlet Redigeringsverktyg för att hitta vad som är möjligt.

Mallarna som du definierar här får ingen effekt förrän programguiden skapar det nya projektet. Du hittar informationen längst upp i filerna som du själv skapar under utvecklingsprocessen. När de ursprungliga filerna skapas, använder programguiden några fördefinierade standardmallar. Du måste anpassa de ursprungliga filerna till dina behov för hand.

#### Bygg de ursprungliga projektfilerna

Nu är nästan allt klart. På den sista sidan i mallen, har knappen Nästa > ändrats så att den nu lyder Slutför.

Tänk efter innan du klickar på den! Du har fortfarande möjlighet att granska allting genom att använda knappen < Tillbaka upprepade gånger. Eftersom programguiden kommer ihåg all information du hittills matat in, kan det vara lämpligt att ta dig tid att titta tillbaka en gång till. Om du använder lokal CVS, glöm inte att kontrollera namnet på CVS-arkivet igen (det ska inte redan finnas någon underkatalog med det namnet i CVS-rotkatalogen. Om det gör det, försök med ett annat arkivnamn).

Om du någon gång inte vill att det nya projektet ska byggas, avbryt dialogrutan Skapa nytt projekt med knappen Avbryt. Klicka annars på Slutför, och se i fönstret Meddelanden hur programguiden skapar projektet.

Om du vill använda ett versionshanteringssystem (&CVS;), sker det i själva verket två genomgångar. Programguiden bygger först projektkatalogerna och anropar sedan &CVS;-programmet som återstartar fönstret Meddelanden med sitt eget innehåll. Om något fel uppstår i någon av genomgångarna, stannar processen och visar dig motsvarande felmeddelande i fönstret.

I IDEA-fönsterläge, kan fönstret Meddelanden automatiskt ha stängts efter körningen, om du inte fixerade det på plats. Glöm inte att öppna det igen för att se eventuella meddelanden om lyckat resultat eller fel.

Glöm inte att kontrollera vad programguiden tillhandahåller från början. Du kanske till exempel vill ändra ursprunglig information i filhuvuden enligt dina egna mallar. Oftast hittar du dem i underkatalogen `templates` i projektkatalogen. Några enkla kopieringsåtgärder räcker oftast.

Därefter är det lämpligt att du kompilerar det ursprungliga projektet innan du försöker ändra någon kod. I de flesta fall ska den här första kompileringen vara möjlig. På så sätt kan du avgöra om projektet verkligen skapades enligt dina behov. Om det inte gjorde det, ta helt enkelt bort projektkatalogen (i den lokala &CVS;-roten också, om du använder en) och börja om.

Innan du kompilerar det nya projektet för första gången, ta en titt på Projekt Bygginställning. Om det finns tre alternativ som visas: default, optimized och debug, med debug markerat, behåll det för all del, eller använd optimized istället.

På grund av vissa begränsningar i den nuvarande inställningen av autoconf och automake, ska du under inga omständigheter bygga med inställningen default. Det förstör vissa interna kataloginställningar, och gör att `configure` klagar när du senare försöker använda det med bygginställningarna optimized eller debug.

(Det här gäller bara för dessa flervalsmöjligheter. Om programtypen du valde bara tillhandahåller bygginställningen default, ska du förstås använda den.)

### Bakom ridån

Det är alltid lämpligt att titta på utskrivna meddelanden och försöka förstå vad som har hänt. Åtminstone i princip bör du veta vad som ska göras när programguiden skapar det nya projektet. Vi kan inte gå in på detaljer, men ger en översikt över dessa meddelanden för att få en idé om vad som pågick bakom ridån.

Om projektet ställdes in för lokal &CVS;, fick du två uppsättningar med meddelanden, där den första uppsättningen försvann innan du kunde läsa den ordentligt, eftersom &CVS; använde fönstret Meddelanden för sitt eget syfte. Så vi sparade båda följderna i separata körningar: skapade programmet två gånger, en gång utan &CVS;, tog bort katalogen och började om, den här gången med inställning av programmet med &CVS;.

Du bör följa samma procedur om något konstigt hände, och du bara inte kunde fånga meddelanden från det första inställningssteget.

Vi tar en titt i utmatningen under Meddelanden för båda stegen:

- Ställa in programmet samt

- Ställa in &CVS;.

#### Ställa in programmet

Om du ställt in Mitt_nya_program som i föregående exempel, ska programguiden ha skrivit ut följande meddelanden (vi arrangerade om utmatningen en del för ökad läsbarhet, och du kan klicka på vilken rad som helst för att gå till beskrivningen av den):

    * perl /opt/kde3/share/apps/kdevappwizard/template-kapp/script \
      --author='Ditt namn' \
      --email='du@du.se' \
      --version='0.1' \
      --appname='Mitt_nya_program' \
      --dest='/home/utveckling/mitt_nya_program' \
      --source='/opt/kde3/share/apps/kdevappwizard' \
      --license='GPL' \
      --licensefile='COPYING' \
      --filetemplates='h,/tmp/kde-devel/gideoncDE5Ja.tmp,\
                       cpp,/tmp/kde-devel/gideonsRrLab.tmp'
    * Making destination directory
    * Installing file templates
    * Installing license file
    * Installing admin directory
    * Installing GNU coding standard files
    * Installing Docbook template
    * Installing project file
    * Installing application framework
    * Installing application sources
    * Finished
    * *** Success ***

#### Ett anropat &perl;-skript

Som du ser på första raden, skapade programguiden ett anrop till ett &perl;-program från inställningarna som du gjorde i dialogrutan Skapa nytt projekt. Det anropade skriptet `script` finns i en katalog som bestäms av typen av programmall du valde i övre delen på sidan Allmänt i dialogrutan Skapa nytt projekt.

I vårt fall finns filen `script` i katalogen `/opt/kde3/share/apps/kdevappwizard/template-kapp/`. Ersätt bara `/opt/kde3/` med &kde;-katalogen på ditt system.

Det här &perl;-skriptet `script` anropas med en följd kommandoradsväljare, alla markerade med prefixet `--`, där programguiden placerar information från de övriga valen du gjorde i dialogrutan Skapa nytt projekt.

Den exakta följden av initieringssteg beror på vilket &perl;-skript `script` som anropades. Om du vill kontrollera det, titta bara i filen `script` som anropades av kommandot `perl` på första raden i fönstret Meddelanden.

Inställningsskripten använder ett antal subrutiner i &perl; samlade i filen `kdevelop.pm`, som du hittar i underkatalogen `share/apps/kdevwizard/template-common/` i din &kde;-installation.

#### Programmets baskatalog

När &perl;-skriptet körs, får du en följd meddelanden om vad som ska göras i nästa installationssteg. Först skapas en `målkatalog`. Det är programmets baskatalog, precis det som visades på raden Slutgiltig plats på sidan Allmänt i dialogrutan Skapa nytt projekt. Skriptet använder värdet på väljaren `--dest` i &perl;-kommandot ovan.

#### Filmallarna

I nästa steg kopieras filmallarna du ställde in i dialogrutan Skapa nytt projekt till underkatalogen `templates` i denna målkatalog. Som du kan se från väljaren `--filetemplates` anges mallarna i par: Suffixet de används för först, följt av namnet på den tillfälliga fil dit projektguiden har kopierat innehållet i dialogrutans mallsidor. Suffixen används som filnamn där malltexterna lagras.

I vårt exempel, installerades två sådana mallfiler, nämligen `templates/h` för C++ deklarationsfiler och `templates/cpp` för C++ källkodsfiler.

#### Licensfilen

På sidan Allmänt i dialogrutan Skapa nytt projekt, valde du licensen som du vill ska gälla för programmet. Programguiden utför två åtgärder baserat på detta. En är licensinformationen som den skrev i mallarna. Den andra åtgärden gör att motsvarande licensfil kopieras till programmets baskatalog.

Väljaren `--licensefile` talar om för &perl;-skriptet `script` vilken licenstextfil som ska kopieras. I vårt exempel kommer filen `/home/utveckling/mitt_nya_program/COPYING` att ha installerats.

#### Administrationskatalogen

&kdevelop; behöver en uppsättning filer för att administrera projektet. De läggs i underkatalogen `admin` i ditt programs baskatalog.

Programguiden skapar underkatalogen `admin` i det här steget, och extraherar standarduppsättningen filer som behövs från det komprimerade arkivet `share/apps/kdevappwizard/template-common/admin.tar.gz` allt från &kde;-katalogen.

&kdevelop; använder alltid samma uppsättning standardfiler för administrativa ändamål. Därför behövs ingen parameter i anropet till &perl;-skriptet `script` för att skapa underkatalogen `admin`.

#### Filer i &gnu;:s kodningsstandard

Det finns flera standardfiler som ska distribueras med alla program som följer &gnu; kodningsstandard. &perl;-skriptet `script` hämtar dessa filer från det komprimerade arkivet `share/apps/kdevappwizard/template-common/gnu.tar.gz` i &kde;:s installationskatalog, och anpassar dem enligt informationen som du angav i dialogrutan Skapa nytt projekt.

Efter det här steget hittar du följande filer i programmets baskatalog:

- `AUTHORS`, som från början innehåller information från väljarna `--author` och `--email`.

- `COPYING`, det här är den allmänna &gnu;-licensen, som alla program som följer &gnu; måste innehålla, även om du bestämmer att ditt program ska ha en annan licens.

- `ChangeLog`, från början tom. Du bör protokollföra alla större ändringar här.

- `INSTALL` innehåller generella installationsinstruktioner. Ändra detta om särskild försiktighet eller särskilda procedurer kan behövas för att installera programmet.

- `README`, från början tom. Skriv in all information som användaren bör känna till innan programmet installeras.

- `TODO`, från början tom. Skriv in information om vad som måste göras för att utveckla programmet ytterligare här. Du kan använda detta som ett anteckningsblock för eget syfte, men det är dessutom till stor hjälp när programmet är publicerat för allmänheten.

#### Den ursprungliga programdokumentationen

Alla projekt du skapar, kommer att innehålla en ursprunglig DocBook-mall, som du kan använda när du börjar skriva programdokumentationen. I det här steget har &perl;-skriptet `script` skapat underkatalogerna `doc` och `doc/en` i programmets baskatalog med den ursprungliga mallen `doc/en/index.docbook` och några &automake; `Makefile.am` filer, som &kdevelop; senare kan använda för att bygga hjälpsystemfiler.

#### Projektfilen

Hittills har det mesta av det allmänna sakerna skapats, det som mer eller mindre finns i alla &kdevelop;-projekt. Med det här steget börjar den mer programspecifika inställningsprocessen. Den kan variera beroende på programtyp du valt. Ta en titt på det verkliga &perl;-skriptet `script` som programguiden anropade åt dig för att skapa det nya programmet, om du vill titta på detaljerna. Vi fortsätter att följa stegen i exemplet som listas ovan.

I det första av dessa steg, kopieras projekthanteringsfilen i &kdevelop; från mallkatalogen, där &perl;-skriptet `script` finns. I vårt fall kopierades filen `share/apps/kdevappwizard/template-kapp/app.kdevelop` till programmets baskatalog och anpassades enligt de val som gjorts i dialogrutan Skapa nytt projekt.

Du kanske vill ta en titt på den resulterande projektfilen, som i vårt fall sparades som `/home/devel/yournewapplication/yournewapplication.kdevelop`. Den är skriven på XML-format, och kan enkelt visas med Kate eller någon annan texteditor. Men var försiktig så att ingenting ändras, eftersom &kdevelop; är beroende av innehållet.

#### Programramverket

Nu är det hög tid att katalogstrukturen och andra underhållsfiler skapas, att lägga det nya programmet i och göra det möjligt att underhålla det. Ett så kallat programramverk skapas i detta steg. Dess struktur beror i grunden på programtyp som du valde i dialogrutan Skapa nytt projekt, men delar av det är nog vanliga för att också hittas i andra projekt.

I vårt fall har följande katalogstruktur skapats i programmets baskatalog `/home/utveckling/mitt_nya_program/`.

- Underkatalogen `src` är avsedd att innehålla programmets källkodsfiler.

- Underkatalogen `debug` innehåller den kompilerade utmatningen från bygginställningen för avlusning. (Se kapitlet Bygginställningar för att lära dig mer om detta.) Som namnet anger, ska du använda den här katalogen för avlusningssyfte.

- Underkatalogen `optimized` innehåller den kompilerade utmatningen från den optimerade bygginställningen. Du bör testa en optimerad version av programmet därifrån.

- Underkatalogen `po` är avsett för översättningssyften. Det kommer att innehålla filer som kallas Portable Object (`.po`-filer) och mallar (`.pot`-filer), som behandlas av ett översättningsprogram, som t.ex. Kbabel.

Alla dessa kataloger förblir inte tomma, utan fylls med en följ av `Makefile` och andra filer som &kdevelop; använder för att behandla programmets källkod. Några ursprungliga ikoner för det nya programmet har också placerats i underkatalogen `src`, om nödvändigt. I vårt fall hittar du två stycken: `src/hi16-app-mitt_nya_program.png` och `src/hi32-app-mitt_nya_program.png` som båda innehåller vanliga &kde;-programikoner.

#### Installerad programkällkod

Ramverket kommer till sist användas för att lägga till ursprungliga källkodsfiler för det nya projektet i katalogen `src`. De verkliga filerna beror helt och hållet på programtypen du valde i dialogrutan Skapa nytt projekt. Du ser snart själv, eftersom det här är vad du verkligen måste arbeta med.

#### Ställa in &CVS;

Låt oss nu ta en titt på vad fönstret Meddelanden innehåller när programguiden fortsätter att bygga vårt projektexempel. Om inget fel uppstod under första genomgången, återställs innehållet i Meddelanden för att skapa det lokala &cvs;-arkivet.

Som tidigare formaterade vi om de utskrivna raderna lite grant för ökad läsbarhet. Vi tog också bort några onödiga rader (där punkterna . . . finns).

    * cd '/home/utveckling/mitt_nya_program' \
      && cvs -d '/home/utveckling/cvsroot' \
             import -m 'nytt projekt' \
                    'Mitt_nya_program' \
                    'leverantör' \
                    'start' \
      && sh /opt/kde3/share/apps/kdevcvs/buildcvs.sh . \
                                                     'Mitt_nya_program' \
                                                     '/home/utveckling/cvsroot'
      . . .
    * N Mitt_nya_program/NEWS
    * N Mitt_nya_program/TODO
    * N Mitt_nya_program/README
      . . .
    * N Mitt_nya_program/admin/configure.in.bot.end
    * N Mitt_nya_program/templates/h
    * N Mitt_nya_program/templates/cpp
    *
    * No conflicts created by this import
    *
    * *** Success ***

Som du ser från den första meddelanderaden, skapade programguiden en ny skalkommandorad som styr arbetet som &cvs; ska göra. Först går skalet till den nyskapade baskatalogen för programmet, för att använda det som standardkatalog för följande steg.

#### Bygga &CVS;-arkivet

På den andra delen av kommandoraden, anropas &CVS;-programmet för att importera det ursprungliga projektinnehållet till det önskade arkivet. Återigen styrs arbetet i detalj av ett antal kommandoradsväljare i anropet till &CVS;-programmet.

- `-d '/home/utveckling/cvsroot'`: väljaren `-d` talar om för &CVS; vilken rotkatalog som ska användas. I vårt fall är det den lokala &cvs;-roten som finns i `/home/utveckling/cvsroot`.

- `import`: Talar om för &CVS;-programmet vilken åtgärd som ska utföras med roten. Vi vill importera filer till &cvs;-databasen. För att åstadkomma det, måste kommandot `import` ha några egna väljare:

  - `-m 'nytt projekt'`; Väljaren `-m` ger en meddelandetext till import för åtgärden. Den kommer att lagras i databasen, och kan senare hämtas för att identifiera data som lagrades i det här steget. I vårt fall anger `nytt projekt` att vi lagrar våra första filer i databasen.

  - `'Mitt_nya_program'`: Den andra väljaren talar om för &CVS; vilket arkiv som ska användas. Om det inte finns, skapas det innan filimportåtgärderna. i det här fallet skapas arkivet `Mitt_nya_program`.

  - `'leveratör'`: Den följande väljaren är en tagg, ett symboliskt namn som markerar en följd av filer i katalogen. Det finns flera betydelser en sådan tagg kan ha (se Använda CVS för mer information). Den här markerar i princip hela gruppen med filer som någonsin lagras i det här arkivet i framtiden. Den är inte av någon särskild nytta för oss, så `leveratör` är ett lika bra namn som något annat.

  - `'start'` är en annan tagg. Den markerar utgåvan, med enkla ord en följd av senare sparade filer som hör ihop. Vi använder `start` här, en beskrivning som passar in på användningen av den här ursprungliga följden.

#### De importerade filerna

&CVS;-programmet skapar arkivet, och börjar sedan importera alla filer från katalogen `/home/utveckling/mitt_nya_projekt`. Det rapporterar därefter alla filer som laddas. Det är innehållet i en hel mängd rader med `N` som följer i fönstret Meddelanden. Bokstaven `N` anger att filen är ny och importerades till arkivet.

Beroende på det nya programmets typ finns det en hel del av raderna med `N`. Vi avkortade utmatningen, för att bara visa den första och de tre sista raderna som ett exempel.

#### Meddelande att &CVS; lyckades

&CVS; rapporterar alltid när en åtgärd utförts med lyckat resultat. I vårt fall skrevs meddelandet `No conflicts created by this import` ut, följt av den allmänna raden `*** Success ***` eftersom ingen ytterligare åtgärd behövde utföras.

Det skulle kunnat finnas några felmeddelanden om filer med konflikter om arkivet redan fanns, eftersom &CVS; kontrollerar filinnehållet enligt vissa formella kriterier, och rapporterar alla konflikter som det möjligen hittar.

#### Bygga &cvs; administrativa poster

&CVS;-importåtgärden är avslutat i detta ögonblick. Arkivet har skapats, och alla filer vi vill behålla har lagrats i databasen. Ändå så återstår mer arbete, eftersom &CVS;-programmet behöver ha viss administrativ information i varje katalog under programmet. Det använder informationen senare, för att kommunicera med CVS-roten och arkivet.

Om vi arbetade enbart med &CVS;, skulle vi behöva ge en möjlighet för &CVS; att lagra informationen i arbetskatalogen. Vi skulle till exempel kunna checka ut filerna igen i en tom baskatalog, då &CVS; automatiskt skulle utföra alla administrativa åtgärderna tillsammans med de utcheckade filerna.

Det finns ett enklare sätt i &kdevelop;, som tur är. Det tillhandahåller skalskriptet `buildcvs.sh` i katalogen `/opt/kde3/share/apps/kdevcvs/` (igen, ersätt `/opt/kde3` med &kde;:s installationskatalog), som programguiden anropar efter &CVS;-programmet har utfört sitt arbete med lyckat resultat.

Skriptet `buildcvs.sh` skapar i huvudsak en `CVS`-underkatalog i varje katalog i programmets stomme. Var och en av dessa `CVS`-underkataloger innehåller följande tre filer:

- `Root` innehåller namnet på servern där &cvs;-roten finns. I vårt fall är det den lokala roten `/home/utveckling/cvsroot`. Orsaken till detta är att alltid samma arkiv ska användas för filerna, eftersom &CVS; inte lagrar hela filerna, utan bara skillnaderna för följande delar. Det sparar mycket diskutrymme, men gör det nödvändigt att all följande information hålls samman under alla omständigheter.

- `Repository` tjänar samma syfte. &CVS; har namnet på arkivet som ska användas här, i vårt fall `Mitt_nya_program`.

- `Entries` innehåller namnen och en del annan information om filerna som &CVS; tar hand om i katalogen. Det beror på att &CVS; inte nödvändigtvis lägger alla programfiler i arkivet. Du kan tala om vilka filer som ska lagras, och vilka som ska ignoreras. Denna information finns i filen `Entries`.

All denna möda är nödvändig eftersom &CVS; arbete är katalogbaserat. Eftersom &CVS; tidigare lagrade alla filer i ramverket `Mitt_nya_program`, söker skriptet `buildcvs.sh` helt enkelt igenom alla kataloger och lägger till namnen på alla programfiler som det hittar i motsvarande fil `CVS/Entries`.

Skriptet kör utan utmatning, och avslutas bara utan några fler rader i fönstret Meddelanden, när arbetet är klart.

### Befintliga projekt

#### Importera befintliga projekt

För att importera en befintlig katalog till &kdevelop;, välj Importera befintligt projekt i menyn Projekt. Du ska då se guiden för att importera ett projekt, som visas nedan:

##### Dialogrutan för importera projekt

#### Konvertera gamla KDevelop projektfiler

&kdevelop; tillåter att du öppnar gamla KDevelop 2.x projektfiler och konverterar dem till &kdevelop;-filer. För att göra det, gå till Öppna projekt... och välj KDevelop 2 projektfiler under Filter:. Välj därefter projektfilen som du vill öppna. Projektet konverteras till &kdevelop; och sparas som en &kdevelop; projektfil.

### En snabb titt på projektinställningar

(... ännu inte skrivet ...)

## Redigeringsverktyg

### Tangentanvändning

I det följande listar vi normala tangentbindningar för standardeditorn. Du kan anpassa dem som du vill (hur då?).

Vänster | Flyttar ett tecken åt vänster
Höger | Flyttar ett tecken åt höger
Ctrl Vänster | Flyttar ett ord åt vänster
Ctrl Höger | Flyttar ett ord åt höger
Upp | Flyttar upp en rad
Ner | Flyttar ner en rad
Page Up | Flyttar upp en sida
Page Down | Flyttar ner en sida
Ctrl Page Up | Går till början av filen
Ctrl Page Down | Går till slutet av filen
Hem | Går till början av raden
End | Går till slutet av raden

För alla tangenter ovan, kan dessutom skifttangenten tryckas ner, för att markera text från markörens nuvarande position till den nya.

Backsteg | Tar bort ett tecken åt vänster
Ta bort | Tar bort tecknet under markören
Ctrl C | Kopierar den markerade texten till klippbordet
Ctrl V | Klistrar in den markerade texten från klippbordet
Ctrl X | Tar bort den markerade texten och lägger den på klippbordet
Ctrl Z | Ångra
Skift Ctrl Z | Gör om

### Problemrapporter

(... ännu inte skrivet ...)

### Sökning och flerfilssökning

#### Söka efter text

Ctrl F- Sök, Ctrl R- Ersätt

#### I-sök

Den vanliga sökningen med Redigera Sök kräver att du anger hela sökbegreppet innan du startar. Oftast är det mycket snabbare att söka inkrementellt. Om du klickar på sökfältet som heter I-sök i verktygsraden, sker sökningen medan du skriver. Du kommer att märka att det önskade resultatet redan hittas när du har skrivit in 3 eller 4 tecken.

#### Flerfilsökning

Båda sökmekanismerna som beskrivs ovan är begränsade till sökning i en källkodsfil. Ett ytterligare verktyg som låter dig söka igenom ett (möjligtvis stort) antal filer är tillgängligt via alternativet Sök i filer... i menyn Redigera. Det är i grunden ett gränssnitt för programmet &grep;(1).

I dialogrutan kan du ange vilka filer som ska sökas i. Det finns ett antal jokertecken tillgängliga i en kombinationsruta. På det här sättet kan du lätt begränsa sökmekanismen till deklarationsfiler. Dessutom anger du en katalog där sökningen startas. Om du markerar rutan Rekursiv, går sökningen igenom alla kataloger i hierarkin under den angivna.

Sökbegreppet är i grunden ett reguljärt uttryck som följer POSIX-syntax. Du kan till exempel använda begreppet `"\<K.*"`, om du vill hitta alla ord som börjar med bokstaven K. Följande tecken tolkas på ett särskilt sätt:

`.` | Matchar alla tecken
`^` | Matchar början av en rad
`$` | Matchar slutet av en rad
`\<` | Matchar början av ett ord
`\>` | Matchar slutet av ett ord
`?` | Föregående objekt matchar mindre än en gång
`*` | Föregående objekt matchar noll eller flera gånger
`+` | Föregående objekt matchar en eller flera gånger
`{n}` | Föregående objekt matchar exakt n gånger
`{n,}` | Föregående objekt matchar n eller flera gånger
`{,n}` | Föregående objekt matchar mindre än n gånger
`{n,m}` | Föregående objekt matchar minst `n` gånger, men mindre än `m` gånger

Bakåtreferenser till deluttryck inom parenteser är också tillgängliga med notationen `\n`.

Som en särskild bonus för C++ programmerare, finns några sökmallar tillgängliga för typiska mönster. De låter dig till exempel söka efter alla anrop av medlemsfunktioner för ett visst objekt.

När du väl har startat sökningen genom att klicka på knappen Sök, utförs den av en yttre, asynkron process. Alla objekt som hittas syns i vyn som heter Flerfilsökning. Därefter kan du hoppa till objekt som hittas genom att klicka på dem. Observera att grep söker igenom filerna som de är lagrade i filsystemet. Om du har ändrade versioner av dem i editorn, kan du få felaktiga radnummer, eller vissa ogiltiga hittade objekt. Du kan undvika detta genom att spara alla filer innan.

### Kodkomplettering

(... ännu inte skrivet ...)

### Skapa nya filer och klasser

(... ännu inte skrivet ...)

#### Redigera mallarna

(... ännu inte skrivet ...)

## Filbläddrarna

På vänstra sidan i huvudfönstret, kan &kdevelop; visa olika sorters listor och träd för att välja filer:

- ## Filträd

  Det visar en trädvy av filhierarkin under projektkatalogen. Om du klickar på en fil, laddas den i editorn. För filer som inte innehåller text, startar KDevelop ett program som kan hantera motsvarande MIME-typ.

  Filträdet uppdateras regelbundet så fort någonting ändras i filsystemet. Om du till exempel skapar nya filer eller kataloger (till och med utanför &kdevelop;), syns det omedelbart i fillistan. På Linux använder den här funktionen FAM-biblioteket. På andra operativsystem, eller via NFS, kontrolleras katalogerna som visas med korta intervall.

  Filträdet döljer filer som oftast inte är intressanta, som objektfiler. I Projektalternativ under Filvyer, kan du anpassa vilka mönster som används för att filtrera bort ointressanta filer (som en lista med jokertecken, åtskilda med kommatecken).

  Du kan dessutom välja att begränsa filträdet så att det bara visar filer som hör till projektet som för närvarande är laddat. Det kan ändras genom att klicka med höger musknapp på trädets rot.

  ### En skärmbild av filträdet

- ## Filgrupper

  Det här visar filerna som tillhör projektet, grupperade enligt filändelsen. Som i filträdet, kan du redigera en fil genom att klicka på den med vänster musknapp.

  Grupperna som visas i vyn kan ställas in under Filvyer i dialogrutan Projektinställningar. För att anpassa vyn enligt dina behov, är det viktigt att förstå hur filer tilldelas till grupperna. För varje fil, går &kdevelop; igenom grupperna uppifrån och ner. I varje grupp kontrolleras om filnamnet matchar ett av mönstren. Vid en träff, visas filen i gruppen och upprepningen avbryts. Detta klargör att mer generella mönster ska placeras under mer specifika. Till exempel ska en asterisk för gruppen Övriga vara det sista mönstret.

## Klassbläddraren

Vid arbete med ett projekt i ett objektorienterat språk, läggs inte tonvikten på källkodsfilerna och deras namn, utan på klasserna och deras samband. För att hjälpa dig navigera bland definierade klasser och symboler, innehåller &kdevelop; diverse klassbläddrare som synliggör klasstrukturen på olika sätt.

### Klassvy

Den här vyn visas till vänster i huvudfönstret och innehåller en linjär lista av alla klasser, variabler och funktioner i projektet. Den är konstruerad som en trädvy. Om du öppnar en klassnod genom att klicka på den, visas en lista med alla metoder och egenskaper som respektive klass har.

#### En skärmbild av klassbläddraren

Klassvyn arbetar i två olika lägen. Normalt grupperas alla symboler i Klasser, Struct:ar, Funktioner, Variabler och Namnrymder. I den sammanhangsberoende menyn, kan du välja Lista enligt namnrymder. Med detta läge, visas namnrymdshierarkin, och symboler grupperas i respektive namnrymd där de definieras. Det här kan vara mer användbart i projekt som använder många (hierarkiska) namnrymder. Det är mindre användbart i projekt utan namnrymder.

Du kan också ändra sättet som klassnamn visas. Normalt visas klassernas namn, utan namnrymden där de definieras. Det betyder att du inte omedelbart kan skilja på klasser med samma namn i olika namnrymder. Om du håller musen still ett ögonblick över ett namn, visas dock det fullständiga namnet som ett verktygstips. Du kan välja att alltid visa det fullständiga klassnamnet genom att välja Fullständig räckvidd för identifierare i den sammanhangsberoende menyn.

Genom att klicka på en klass eller metod i en klassvy kommer du till dess definition. Du kan också hoppa till en metods deklaration genom att välja Gå till deklaration i den sammanhangsberoende menyn. I den sammanhangsberoende menyn för klasser finns också alternativen Lägg till metod... och Lägg till egenskap.... De öppnar dialogrutor där du kan skapa nya metoder och variabeldeklarationer för respektive klass, tillsammans med en tom implementering.

### Klassverktyg

Klassverktygsdialogrutan aktiveras genom att högerklicka på en klass i klassvyn och välja Klassverktyg....

### Klasshierarki

(... ännu inte skrivet ...)

## Dokumentation

Dokumentation hör tyvärr till de mer förbisedda sakerna i programmering. Ändå så erbjuder riktigt upprättad och underhållen intern och extern dokumentation ytterst värdefull hjälp.

Dokumentation har flera aspekter. Det finns

- intern projektdokumentation, som i huvudsak består av

  - kommentarer i deklarationsfiler och källkodsfiler

  - Intern dokumentation av programmeringsgränssnittet för projektet, som har skapats från programfilerna av särskilda verktyg, t.ex. &doxygen;

- extern projektdokumentation, som bland annat består av

  - extern dokumentation av programmeringsgränssnitt, till exempel för gemensamma systembibliotek (KDE, Qt, etc.)

  - all övrig dokumentation (manualer för programspråk, allmän systeminformation, handledningar och liknande)

All denna dokumentation ska vara enkel att underhålla och lätt tillgänglig så fort du behöver den. &kdevelop; har stöd för just detta.

### Dokumentationsbläddraren

#### En skärmbild av dokumentationsträdet

## Bygga och projekthantering

Det här kapitlet behandlar bara kompilerade projekt, som projekt med C++, Java eller Fortran. Projekt för skriptspråk som Python och PHP, fungerar mycket annorlunda.

Här hittar du information om följande ämnen:

- Sammanfattning av Hantering av automake innehåller en översikt över Hantering av automake,

- Användning av Hantering av automake beskriver grunderna i hur man arbetar med Hantering av automake.

### Sammanfattning av Hantering av automake

(Det här kapitlet är ett bidrag från Ian Wadham, ianw@netspace.net.au)

I kapitlet Byggsystem har vi gett en grov översikt av de byggsystem som vanligen används på Unix-system. I följande avsnitt tittar vi på detta i mer detalj.

Det finns en viss förvirring angående hur sådana ting ska namnges. GNU kallar dem byggsystem när Automake, Autoconf och Libtool beskrivs. Qmake kallas ett verktyg att skriva Makefiles för olika kompilatorer och plattformar. I KDE används ofta uttrycket projekthanteringssystem. Vi använder det uttrycket i en vidare bemärkelse för att beskriva de inbyggda miljöer i &kdevelop; som används för att organisera och bygga projekt. I det här avsnittets sammanhang, talar vi dock i huvudsak om automatiserade byggsystem.

#### Behovet av ett automatiserat byggsystem

Om du har ett enkelt program som skriver ut Hej allihop, skrivet i C, kan du kompilera och länka det med `gcc` `-o hej hej.c` och köra det med `./hej`, så du behöver inte ens en `Makefile`.

Om du har ett C-program med flera moduler och deklarationsfiler och du bara ska köra det på din dator (dvs. det är ett lokalt program), behöver du bara en enkelt `Makefile`, som är ganska enkel att skriva för hand (använd `info Make` för att lära dig mer).

Komplikationerna börjar när:

- Din källkod, dokumentation, grafik, ljud, översättningar, datafiler etc. finns i mer än en katalog,

- Du har en hierarki av kataloger och underkataloger,

- Du använder bibliotek som inte är en del av den traditionella uppsättningen på &UNIX;, som &Qt;-objektbiblioteket eller &kde;-skrivbordsbibliotek,

- Du använder en preprocessor för att skapa en del av din källkod, som Qt:s MOC prekompilator,

- Du siktar på att distribuera programmet i hela världen, till personer som inte har samma &UNIX;- eller &Linux;-system, programvara och hårdvara som du,

- Du kräver en automatisk funktion för installation och avinstallation,

- Du siktar på att göra ditt program en del av &kde;:s uppsättning med skrivbordsprogram.

Om du befinner dig i några eller alla av ovanstående situationer, behöver du troligen ett byggsystem. I exemplet ovan använde vi kommandot `gcc` för att kompilera och bygga programmet Hej, men alla C-kompilatorer heter inte `gcc`. Så om du distribuerar programmet till någon som använder en annan C-kompilator, måste din Makefile på något sätt använda namnet på den personens kompilator, annars misslyckas kompileringen av programmet. Detta är bara ett av många exempel på vad som kan gå fel.

Ett byggsystem jämnar ut skillnaderna åt dig.

- Det kontrollerar att biblioteken som behövs finns på varje dator som tar emot programmet,

- avsöker automatiskt alla programkataloger efter filer att förbehandla, kompilera eller installera och

- installerar komponenterna som programmet består av i rätt kataloger, och försäkrar att

- katalogerna på datorn som tar emot programmet skapas efter behov.

I korthet erbjuder ett byggsystem säkra metoder för att kompilera och installera programmet på alla datorer som tar emot programmet. Som vi har visat tidigare i översikten Projekthanteringssystem, erbjuder &kdevelop; tre automatiserade byggsystem och möjlighet att skapa din egen Makefile. I korthet (klicka på projektnamnen för mer information):

- Automake-projekt som använder de vanliga utvecklingsverktygen för &gnu;.

- Qmake-projekt som använder Trolltechs Qmake-projekthantering.

- ANT-projekt som använder Apaches ANT-projekthantering för Java-utveckling.

- Eget projekt som kräver att du underhåller din egen `Makefile`.

Ett av de fyra alternativen måste väljas när du skapar ett projekt, och valet är svårt att senare ändra, så du bör tänka efter innan du börjar.

#### Handledningar om Autoconf, Automake och Libtool

Det finns flera handledningar tillgängliga om &GNU;:s byggsystem (`Autoconf`, `Automake` och `Libtool`) som Hantering av automake använder sig av.

- En kort handledning om autoconf, skriven av Christopher W. Curtis finns tillgänglig på KDevelops hemsida. Den koncentrerar sig på några grundläggande steg för att ändra en `Makefile`.

- En mer detaljerad handledning finns på . Den är en del av en större uppsättning handledningar som kallas Utveckla programvara med GNU.

- Den berömda getboken, som heter Autoconf, Automake, and Libtool, finns också på . Den är en lättläst, men ändå kortfattad, introduktion till alla viktiga aspekter av &GNU;:s autoverktyg.

#### Vad gör Hantering av automake?

Programguiden har skapat några ursprungliga `Makefile.am` filer när du skapade ett nytt projekt av en typ som använder &GNU;:s byggsystem, som C++ KDE Application framework. Under utvecklingen skapar Hantering av automake alla ytterligare `Makefile.am` filer för projekt som använder &GNU;:s byggsystem, och underhåller alla, både de som skapats med programguiden och Hantering av automake.

Det finns en `Makefile.am` i varje projektkatalog som innehåller filer som ska kompileras eller installeras. Den innehåller dina specifikationer för att kompilera, bygga och installera filer och en referens till alla underkataloger som också har en `Makefile.am` och möjligen några filer att kompilera, bygga och installera.

Projektets kataloger och källkodsfiler kan struktureras till vilket djup som helst, eller du kanske föredrar en platt projektstruktur med alla underkataloger på toppnivå.

Målet med &GNU;:s byggsystem är att skapa filstrukturer för källkod som kan kompileras, byggas och installeras på vilket &UNIX;- eller &Linux;-system som helst med de enkla kommandona:

    ./configure
    make
    make install    # Oftast som systemadministratör.

och kan avinstalleras med kommandot `make uninstall` (oftast som systemadministratör).

Hur fungerar det? Ja, `configure` är ett skript som:

- arbetar fram detaljinformation om systemet som det körs på, som vilken kompilator och vilka bibliotek som ska användas, var de finns, och därefter

- rekursivt skapar filerna `Makefile` genom att fylla i det som ska ersättas i motsvarande `Makefile.in`.

Filen `Makefile.am` är indata, en mall som ger grundläggande information för den `Makefile` som ska skapas, genom att fylla i viss systemberoende information. Den skapas av verktyget `Automake` från filen `Makefile.am`.

Processen att komma från en `Makefile.am` (där `.am` anger mallfiler för Automake) till `Makefile` hanteras automatiskt av Kdevelops Hantering av automake med verktyget `Autoconf`, `M4`-makron och andra mysterier vi inte behöver gå in på här.

Så när `make` kör, hämtar det automatiskt rätt information från den nuvarande miljön, som kompilatorer och bibliotek. På samma sätt, placerar `make install` delarna av programmet, som körbara filer, dokumentation och datafiler på rätt plats i den miljön.

Om du distribuerar programmet som ett tar-arkiv (en enda komprimerad fil som KDevelop kan skapa åt dig), innehåller den filerna `Makefile.in` och skriptfilen `configure`, så att mottagaren kan kompilera, bygga och installera programmet utan att ha `Automake`, `Autoconf` eller KDevelop på sin dator. Filerna `Makefile.am` ingår också, ifall mottagaren måste göra några ändringar i källkoden.

Reglerna är väsentligt annorlunda om du distribuerar via ett webbaserat källkodsarkiv som KDE:s CVS.

#### Sammanfattning av vad Hantering av automake gör

- Skapar filerna `Makefile.am` i underkatalogerna som det känner till som delprojekt.

- Uppdaterar filerna `Makefile.am` när projektstrukturen ändras.

- Uppdaterar filerna `Makefile.am` när filer läggs till i eller tas bort från projekt.

- Accepterar definitioner om hur de olika filerna ska byggas eller installeras, och ändrar `Makefile.am` enligt dem.

- Accepterar parametrar som används vid byggning eller installation (t.ex. biblioteksnamn), och försäkrar att de används i de nödvändiga kompilerings- och byggstegen.

#### Innehåll i automake-filer

Filen `Makefile.am` har rader som innehåller variabelnamn följda av ett likhetstecken och en lista med filer eller parametervärden. Variabler har tvådelade namn, som `bin_PROGRAMS`, `mittpgm_SOURCES` eller `kdelnk_DATA`. Den andra delen kallas den primära och representerar något som ska byggas eller installeras. Den första delen kallas prefix och representerar:

- En katalog där installationen ska göras (t.ex. `bin`),

- En kvalifikation för den primära delen (t.ex. mittpgm för `SOURCES`, som anger att källkodsfiler som listas efter `mittpgm_SOURCES` ingår i att bygga `mittpgm`.

- Ett särskilt prefix `noinst` (kort för ingen installation), som oftast används för att lista programmets deklarationsfiler (`.h`),

- Eller det speciella prefixet `EXTRA`, för konfigurationsberoende saker.

För mer information om `Automake` och filerna `Makefile.am`, slå upp den med `info Automake`.

I huvudsak skapar och uppdaterar Hantering av automake variabelnamn och fillistor eller parametrar. Se följande exempel på en `Makefile.am` för ett typiskt program, som kallas `mittpgm`.

    ## Makefile.am för mittpgm

    # det här är programmet som installeras. dess namn används för alla
    # andra Makefile.am variablerna
    bin_PROGRAMS = mittpgm

    # ställ in sökvägen för deklarationsfiler till X, Qt och KDE
    INCLUDES = $(all_includes)

    # bibliotekssökvägen.
    mittpgm_LDFLAGS = $(KDE_RPATH) $(all_libraries)

    # biblioteken att länka med.
    mittpgm_LDADD   = $(LIB_KFILE) $(LIB_KDEPRINT)

    # vilka källkodsfiler ska kompileras för mittpgm
    mittpgm_SOURCES = main.cpp mittpgm.cpp mittpgmvy.cpp

    # det här är deklarationsfilerna för projektet
    noinst_HEADERS = mittpgm.h mittpgmvy.h

    # låt automoc hantera alla metakällfiler (moc)
    METASOURCES = AUTO

    KDE_ICON = mittpgm

    # det är här kdelnk-filen hamnar
    kdelnkdir = $(kde_appsdir)/Utilities
    kdelnk_DATA = mittpgm.desktop

    # det är här XML-GUI resursfilen hamnar
    rcdir = $(kde_datadir)/mittpgm
    rc_DATA = mittpgm_ui.rc

    AM_CXXFLAGS = -DMITT_C++_PREPROCESSOR_ALTERNATIV

Som du kan se är många av objekten på högersidan symboler på formen `$(xxxx)`. De är miljövariabler som definieras i själva &kde;-miljön och ersätts med riktiga värden när `./configure` skapar de slutliga filerna `Makefile` på datorn som tar emot programmet.

Det är också en god idé att köra kommandot `./configure --help` någon gång efter du har börjat med KDevelop, som visar dig de olika saker du kan ändra vid bygg- och installationstid, såsom en testmiljö. I synnerhet kommandot:

    ./configure --prefix=/var/du/vill

flyttar hela installationen till en katalogstruktur som du väljer, genom att ändra den interna variabeln `$(prefix)` till värdet `/var/du/vill`.

### Användning av Hantering av automake

(Det här kapitlet är ett bidrag från Ian Wadham, ianw@netspace.net.au)

I det här kapitlet hittar du en grundläggande beskrivning av elementen i Hantering av automake, och hur de används. Det täcker:

- Fönstret Hantering av automake beskriver den grundläggande strukturen hos huvudfönstret i Hantering av automake.

- Översiktsfönstret beskriver elementen i det övre delfönstret.

- Detaljfönstret beskriver elementen i det undre delfönstret.

- Navigera i Hantering av automake listar några grundläggande åtgärder du kan utföra i Hantering av automake.

- Sammanhangsberoende menyer i Hantering av automake beskriver menyerna som dyker upp när du väljer en åtgärd i Hantering av automake.

#### Fönstret Hantering av automake

| Hantering av automake använder ett delat fönster. Den övre delen kallas Översiktsfönstret och den undre delen kallas Detaljfönstret. Mellan dem finns en smal rad som kan dras med musen för att justera fönsterstorlekarna. I IDEA-fönsterläge kan du också dra sidokanten på det delade fönstret för att ändra bredden. Ovanför varje fönster finns en verktygsrad, där knapparna blir aktiva när ett element i fönstret markeras. Det här erbjuder ett sätt som du kan komma åt åtgärderna som tillhandahålls för det elementet. Det andra sättet är sammanhangsberoende menyer, som dyker upp vid klick med höger musknapp som beskrivs nedan. I IDEA-fönsterläge finns det ytterligare två små knappar till vänster i namnlisten på fönstret Hantering av automake: en triangelformat högerpil, och en knapp med en punkt. Pilknappen används för att stänga fönstret. Å andra sidan, behåller punktknappen fönstret öppet även om ett annat fönster väljs i &kdevelop;. (Annars stängs fönstret Hantering av automake automatiskt så fort ett annat fönster får inmatningsfokus.)

#### Översiktsfönstret

Översiktsfönstret innehåller en trädlista med alla kataloger i projektet som innehåller programfiler, dokumentation eller data. Varje sådan katalog innehåller en fil `Makefile.am` och är känd som ett delprojekt i Hantering av automake. Det finns tre typiska delprojekt i ett &kde;-baserat projekt, som visas på bilden ovan:

- `src`: källkodsfiler för programmet,

- `doc`: användarmanualen eller handboken,

- `po`: utdrag av strängar i dina källkodsfiler som kräver översättning till andra mänskliga språk (t.ex. fönsterrubriker, menynamn, namn på knappar, text i dialogrutor och meddelanden av olika slag).

Observera att delprojektet `doc` alltid har ett delprojekt som heter `en`, som du kan se om du klickar på symbolen + intill ordet `doc`. Det beror på att grundspråket för all dokumentation i KDE är engelska (en). Om programmet blir en del av KDE, kan KDE:s översättningsgrupper översätta din dokumentation från engelska till andra språk, och översättningarna hamnar då i andra delprojekt, som `sv` (svenska), `de` (tyska) eller `fr` (franska). Strängarna i delprojektet `po` kan också översättas och lagras i andra filer under `po`, för att på så sätt låta programmet hanteras av personer som inte kan engelska.

Delprojekten `doc` och `po` tjänar olika syften. `doc` innehåller dokumentation, som en användarhandbok, medan `po` innehåller textsträngar som kan översättas från användargränssnittet som ingår i programmets källkod.

Översiktsfönstret fungerar bland annat som ett navigeringsverktyg. Om du väljer ett delprojekt i översiktsfönstret, visas motsvarande detaljinformation i detaljfönstret.

#### Detaljfönstret

Detaljfönstret innehåller en lista med alla filer i delprojektet som för närvarande är markerat i översiktsfönstret, samt kompilerings-, bygg- och installationsreglerna för delprojektet. På så sätt kan fönstren tillsammans ge dig möjlighet att komma åt alla komponenter i programmet, och all information om hur det ska kompileras, byggas och installeras.

#### Mål

Trädlistan i detaljfönstret har två nivåer. Den översta nivån består av så kallade mål i Hantering av automake, och nästa nivå innehåller listor med filer som används för att skapa varje mål.

Det här konceptet med ett mål i Hantering av automake, skiljer sig något från vad ett mål i en `Makefile` oftast är. I korthet:

- Definitionen av hur ett antal filer ska kompileras, byggas eller installeras är känt som ett mål i Hantering av automake, men som en variabel i själva `Automake`.

- Ett mål i `make` är ofta något helt annat, eftersom det kan vara en väljare till kommandot `make` (t.ex. `make install`, `make clean`).

  Vissa av variablerna i `Makefile.am` representerar dock ett underliggande delmål för `make`.

#### Navigera i Hantering av automake

Både i översiktsfönstret och detaljfönstret kan du vänsterklicka på + eller - intill ett delprojekt eller målnamn för att expandera eller dra ihop trädvyn. Om du gör det med ett delprojekt i översiktsfönstret, visas eller döljs delprojektets nästa underliggande nivå (om det finns någon). Om du gör det med ett mål i detaljfönstret, visas eller döljs listan med filer som ingår i målet.

#### Öppna en fil för redigering

Om du vänsterklickar på ett filnamn i detaljfönstret, öppnas motsvarande fil i KDevelops redigeringsfönster.

#### Aktivera verktygsradsknapparna i Hantering av automake

Om du vänsterklickar på ett delprojektnamn i översiktsfönstret eller ett mål i detaljfönstret, markeras namnet och vissa knappar i verktygsraden blir aktiva längst upp i fönstret.

Du rekommenderas använda höger musknapp och sammanhangsberoende menyer, istället för knapparna i verktygsraden, eftersom det är då mycket enklare att se och förstå vad du gör.

Åtgärder för delprojekt och mål har långtgående effekter för struktur, kompilering, byggning och installation av programmet.

#### Välja åtgärder och sammanhangsberoende menyer

Om du högerklickar på ett delprojektnamn, mål eller fil, dyker en meny upp och du kan därefter välja åtgärder att utföra för delprojektet, målet eller filen, som att lägga till ett mål i delprojektet, lägga till en fil i målet eller logiskt ta bort den markerade filen från sitt mål.

#### Sammanhangsberoende menyer i Hantering av automake

Följande avsnitt förklarar kortfattat vilka åtgärder som menyerna gör tillgängliga, som dyker upp vid klick med höger musknapp i fönstret Hantering av automake. Avsnitten är bara avsedda som en översikt. Du hittar detaljerade beskrivningar av de flesta åtgärderna i ett senare kapitel.

##### Sammanhangsberoende menyn för en fil

När du högerklickar på ett filnamn i detaljfönstret, dyker följande meny upp som låter dig välja en av flera åtgärder att utföra med filen. I bilden nedan, markerades ikonfilen `hi-16app-mittpgm.png` i målet Ikondata i kde_icon från delprojektet mittpgm/src.

| Det huvudsakliga alternativet i den sammanhangsberoende menyn är att Ta bort filen från målet (dvs. den kommer inte längre att användas för att kompilera, bygga eller installera det målet). Alternativet CVS erbjuder en hel del olika CVS-åtgärder för filen. Alternativet Öppna med låter dig öppna filen med ett antal editorer eller med vilket program som helst (t.ex. kan du öppna ikonfilen i vårt exempel med Kiconedit). Alternativet Perforce används för liknande åtgärder som i CVS, men med det kommersiella versionshanteringssystemet Perforce.

##### Sammanhangsberoende menyn för ett mål

När du högerklickar på ett mål i detaljfönstret, dyker följande meny upp som låter dig välja en av flera åtgärder att utföra med det. I bilden nedan, markerades målet mittpgm (Program i bin) i delprojektet mittpgm/src.

| Alternativet Inställningar för ett mål gäller bara källkodsfiler. I motsvarande dialogruta kan du ange länkargument och sökvägar där bibliotek kan hittas, och du kan ange en lista med verkliga bibliotek som ska länkas med i programmet. Alternativet Skapa ny fil visar en dialogruta där du kan ange filnamnet och filtypen som ska skapas (i en kombinationsruta). Alternativet Lägg till befintliga filer visar en dialogruta där du kan lägga till en befintlig fil till målet. Alternativet Ta bort för ett mål låter dig logiskt ta bort målet och alla dess filer från projektstrukturen. Alternativet Gör mål aktivt gäller bara för mål som innehåller källkodsfiler. Nya filer läggs alltid till i ett sådant aktivt mål. Alternativet Bygg mål anropar alla nödvändiga kompilerings- och byggåtgärder för att bygga koden enbart för detta mål.

##### Sammanhangsberoende menyn för ett delprojekt

När du högerklickar på ett delprojekt i översiktsfönstret, dyker följande meny upp som låter dig göra större ändringar i projektets struktur och sättet det kompileras, byggs och installeras. Du kan använda den för att utöka eller ändra den grundläggande projektstrukturen som programguiden har skapat.

| Alternativet Inställningar för ett delprojekt styr sättet som delprojektet kompileras, byggs och installeras. Dialogrutan som dyker upp har flikar för Kompilator, Deklarationsfiler, Prefix och Byggordning. Alternativet Lägg till delprojekt skapar en ny katalog och Makefile.am skelettfil. Alternativet Lägg till mål visar en dialogruta, där du kan ställa in regler för kompilering, byggning eller installation för en filgrupp inne i delprojektet. Lägg till tjänst (... ännu inte skrivet ...) Lägg till program (... ännu inte skrivet ...) Lägg till befintliga delprojekt (... ännu inte skrivet ...) Alternativet Ta bort delprojekt i den sammanhangsberoende menyn för ett delprojekt är det riktiga sättet att ta bort ett delprojekt. Det justerar filerna `Makefile.am` på motsvarande sätt. Du erbjuds också möjlighet att ta bort alla filer (eller länkar) i motsvarande underkatalog. Uppenbarligen ska funktionen användas med försiktighet. Alternativet Bygg anropar alla nödvändiga kompilerings- och byggåtgärder för att bygga koden för enbart detta delprojekt. Tvinga omredigering (... ännu inte skrivet ...) Rensa (... ännu inte skrivet ...) Installera (... ännu inte skrivet ...) Installera (som systemadministratör) (... ännu inte skrivet ...)

### Automake-projekt

(... ännu inte skrivet ...)

#### Autoconf

##### Effekten av configure-skriptet

`Makefile.in` till `Makefile`

    prefix = @prefix@
    INSTALL = @INSTALL@
    build_triplet = @build@
    CXX = @CXX@

    prefix = /home/bernd/kde3
    INSTALL = /usr/bin/ginstall -c -p
    build_triplet = i686-pc-linux-gnu
    CXX = g++

`config.h.in` till `config.h`

    /* Define if you have libz */
    #undef HAVE_LIBZ
    /* The size of a `int', as computed by sizeof. */
    #undef SIZEOF_INT

    /* Define if you have libz */
    #define HAVE_LIBZ 1
    /* The size of a `int', as computed by sizeof. */
    #define SIZEOF_INT 4

#### Automake

(... ännu inte skrivet ...)

#### KDevelops Hantering av automake

##### En skärmbild av Hantering av automake

#### Bygga och installera bibliotek

- -rpath

- PIC

- static

- insticksprogram: no-undefined

### Egna byggfiler och byggskript

(... ännu inte skrivet ...)

### Kompilatorinställningar

(... ännu inte skrivet ...)

### Byggalternativ

(... ännu inte skrivet ...)

## Avancerad användning av autoprojekt

### Flera bygginställningar

(... ännu inte skrivet ...)

### Korskompilering

Om du har lämpliga korskompilatorer tillgängliga, kan du kompilera dina program för processorer och operativsystem som skiljer sig från systemet där &kdevelop; och kompilatorn kör. &gnu;-kompilatorn, GCC, kan konfigureras och kompileras som en korskompilator om du kompilerar den själv. Rådfråga GCC infosidorna för mer information. Vissa Linux-distributioner tillhandahåller också binärpaket.

Ett automake-baserat paket kan lätt korskompileras genom att ange väljaren `--host` till configure-skriptet och ställa in miljövariablerna `CC` och `CXX` till motsvarande korskompilatorer. Ofta vill du byta mellan en korskompilerad version av programmet, och en som kompilerats för utvecklingssystemet. För att göra det, är det en fördel att använda möjligheten i &kdevelop; att skapa flera byggkonfigurationer, som förklaras under buildconfigurations. När du har skapat en ny byggkonfiguration för korskompilering i dialogrutan Projekt Projektalternativ..., lägg till väljaren

    --host=plattform

till configure-väljarna. Värdet `plattform` är en kombination av formen

    cpu-tillverkare-operativsystem

eller

    cpu-tillverkare-kärna-operativsystem

För många kombinationer kan du använda en kortform, till exempel i386-linux eller arm-elf.

### Qt/Embedded

&qte; är en version av &qt;-biblioteket som inte använder X-window systemet, utan ritar direkt i rambuffern på Linuxsystem. Den är därför intressant för inbäddade system som har hårda begränsningar för minnesanvändningen i hela systemet. Dess programmeringsgränssnitt överensstämmer fullständigt med X11-versionen.

Att utveckla ett program för &qte; med &kdevelop; skiljer sig inte mycket från att utveckla ett program för X11-versionen av Qt. I själva verket kan du använda samma grundkod för båda versionerna. Om du använder projekthantering med autoprojekt, byter du till den inbäddade versionen genom att skicka väljaren `--enable-embedded` till configure-skriptet. Du kan ställa in det i dialogrutan Projekt Projektinställningar... under Inställning av configure. Med väljaren `--with-qt-dir=KATALOG`, ställer du in katalogen där &qte; är installerad.

Efter att ha konfigurerat och kompilerat programmet med dessa väljare, länkas det med biblioteket `libqpe.so`. Den här versionen av programmet kör inte normalt när du använder X11. För att prova den, kör den med hjälp av programmet qvfb (Qt:s virtuella rambuffer). Det görs genom att starta qvfb och därefter starta programmet med

    program -qws -display QVFb:0

När du har en version av programmet som fungerar, vill du naturligtvis använda den på målprocessorn. Det kan troligen vara bekvämt att kunna skapa flera byggkonfigurationer, som förklaras ovan, så att du snabbt kan byta mellan versionen som kör på utvecklingssystemet och versionen som kör på målsystemet.

Program för &qte; kör normalt som enkla program på enheten de är konstruerade för. Trolltech stöder också Qtopia, som är en samling program för personlig information, webbläsning och diverse andra områden som fungerar tillsammans på ett konsekvent sätt. Det är till exempel standardomgivningen på Sharp Zaurus. Du kan skriva program som passar in i denna omgivning genom att använda Qtopias utvecklingsmiljö (SDK). Det medför att ditt program måste vara en delklass till `QPEApplication` och det måste länkas med biblioteket `libqpe.so`. Om du utvecklar programmet med projekthanteringen autoprojekt, måste du lägga till `--enable-qtopia` till konfigurationsväljarna.

## Avlusargränssnittet

&kdevelop; innehåller en intern avlusare för C och C++, som är direkt integrerad med editorn. Tekniskt sett är den implementerad som ett gränssnitt som använder den flyttbara &gnu;-avlusaren gdb via en rörledning. Avlusaren kan startas på flera sätt:

- Huvudprogrammet i projektet laddas i avlusaren med Avlusa Starta.

- Genom att använda Avlusa Starta (annan) Undersök minnesdump, laddar du en minnesdump till minnet, som skapats av operativsystemets kärna när programmet kraschade. (Att skapa minnesdumpar kan vara avstängt på systemet, se ulimit(1)). Det här är användbart för en post-mortem analys av ett program.

- Du startar avlusaren för ett program som redan kör med Avlusa Starta (annan) Anslut till process. En processlista visas där du kan välja processen som avlusaren ska överta.

- Observera att avlusning bara är möjlig om projektet har kompilerats med avlusningsinformation aktiverad. Den kan aktiveras i dialogrutan Kompilatorinställningar. När alternativet är aktiverat, skapar kompilatorn ytterligare information som låter avlusaren associera filnamn och radnummer med adresser i det körbara programmet.

Gränssnittet till avlusaren erbjuder flera vyer in i processen:

- ## Variabler

  Det här fönstret visar värden för alla lokala variabler vid det nuvarande stället i programmet. Det täcker variablerna i kompilatorns anropsstack, dvs. funktionen där processen bröts, funktionen som anropade den här funktionen, och så vidare hela vägen till funktionen `main()`.

  En annan gren i variabelfönstret innehåller bevakningsvariabler. Du kan själv ställa in vilka variabler som syns här. Både lokala och globala variabler kan bevakas. Du kan antingen lägga till en variabel genom att klicka på knappen Lägg till eller trycka på returtangenten när posten Bevaka är markerad. Variablerna kan tas bort igen med den sammanhangsberoende menyn.

- ## Brytpunkter

- ## Aktiveringspoststack

- ## Visa assemblerkod

### Ange brytpunkter

(... ännu inte skrivet ...)

### Alternativ

### Visa behandlade namn

Funktionsnamn i det körbara programmet är behandlade för C++, dvs. funktionsnamnet innehåller information om argumentens typer. Detta är nödvändigt för att stödja överlastade funktioner. Behandlingsalgoritmen är inte standardiserad, och skiljer sig till och med mellan olika versioner av &gnu;:s C++ kompilator.

I assemblerkodfönstret visas normalt obehandlade namn, så funktionssignaturer liknar utseendet i källkoden, och är lätt läsbara. Alternativt, kan du välja att se behandlade namn.

### Försök sätta brytpunkter när bibliotek laddas

Avlusarens bakgrundsprogram gdb tillåter inte att brytpunkter sätts i kod som inte för närvarande är laddad. I ett riktigt modulärt program, där kod ofta bara laddas vid behov som insticksprogram (med användning av C-bibliotekets funktion `dlopen(3)`), kan detta vara besvärande. Därför hanterar &kdevelop; själv stöd för brytpunkter i delade bibliotek. Om du aktiverar det här alternativet, kan du sätta brytpunkter i bibliotek som inte laddats. Därefter, så fort gdb talar om att ett bibliotek har laddats, försöker &kdevelop; sätta de vilande brytpunkterna.

### Aktivera flytande verktygsrad

(... ännu inte skrivet ...)

## Använda CVS

### &CVS; grunder

&CVS; är versionshanteringssystemet som många projekt med öppen källkod, inklusive &kde;, använder. Det lagrar all källkod på en centralt plats, som kallas arkivet. Utvecklare hämtar en aktuell version av projektet eller versioner av det vid godtyckliga tidpunkter, från arkivet. I motsats till vissa andra versionshanteringssystem, är det inte nödvändigt att låsa filer som man ska arbeta med. Alltså kan utveckling ske parallellt i stor utsträckning.

Så fort en utvecklare är klar med en uppgift, arkiverar han sin kod (tillsammans med ett loggmeddelande). &CVS; tar hand om arbetet att sammanfoga ändringar som görs av flera utvecklare. Det kan förstås hända att utvecklare arbetar med samma kodavsnitt, vilket ger upphov till ändringar med konflikter (i praktiken inträffar detta sällan, och är ofta ett tecken på bristande kommunikation). I detta fall, förkastar &CVS; arkiveringen. En fil kan bara arkiveras efter alla konflikter har lösts upp.

Hittills har de grundläggande funktionerna i &CVS;, som man oftast måste hantera, beskrivits. Men &CVS; erbjuder mycket mer: Man kan hantera flera grenar av ett projekt (t.ex. var &kde; 1.1.2 och &kde; 2 grenar i &kde;:s utvecklingsträd), sammanfoga ändringar från en gren till en annan, fråga efter skillnader mellan versioner och filers versionshistorik, etc.

&CVS; implementeras som ett klient-serversystem. Som användare, sker all kommunikation med arkivet via kommandoradsprogrammet &cvs;. Gränssnitt på högre nivå är tillgängligt via program som Cervisia ( ) eller TkCVS (). Bara en liten del av &cvs; funktioner, som är viktiga under det dagliga arbetet, kan användas direkt i &kdevelop;.

Grundläggande kunskap om användning av &CVS; förutsätts. I synnerhet bör du veta hur ett givet projekt hämtas från arkivet. Vi rekommenderar boken Open Source Development With CVS av Karl Fogel, som kan spridas fritt (utom de icke-tekniska kapitlen). Se .

### &CVS;-kommandon i &kdevelop;

Följande alternativ är tillgängliga i filvyernas sammanhangsberoende menyer:

- ### Lägg till i arkivet

  Förbereder en fil för att läggas till i arkivet. Filen överförs till arkivet när du arkiverar den (eller katalogen som den finns i) nästa gång.

- ### Ta bort från arkivet

  Förbereder en fil för att tas bort från arkivet. Det här tar också bort filen från det lokala filsystemet, så använd funktionen med försiktighet!

- ### Uppdatera

  Kör kommandot `cvs update` för att sammanfoga eventuella ändringar från andra användare till din arbetskatalog. När du använder menyalternativet för en katalog, sker uppdateringen normalt rekursivt, utom om du har stängt av det i inställningsfilen `.cvsrc`.

- ### Arkivera

  Kör `cvs commit` för att arkivera alla lokala ändringar i arkivet. Observera att du bör uppdatera innan du gör detta. Om en annan användare tidigare har arkiverat sina ändringar, kan &CVS; annars ge ett felmeddelande.

Alla kommandon startas som underprocesser av &kdevelop;, utan ytterligare kommandoradsväljare eller miljövariabler. Det här kan vara ett problem om anslutningen till &CVS;-servern går via en &ssh;-anslutning, och kräver att du skriver in ett lösenord varje gång du arkiverar eller uppdaterar. Det här är till exempel nödvändigt om projektets värd är `sourceforge.net`. Ett sätt att gå runt problemet beskrivs i vanliga frågor om CVS/SSH, som du hittar i SourceForge-dokumentationen.

### Bakom ridån

#### Vad &CVS; sparar i arbetskatalogen

(... ännu inte skrivet ...)

## Dra nytta av externa program

Även om &kdevelop; är en så kallad integrerad utvecklingsmiljö, kommer den aldrig att innehålla alla funktioner som du kan vilja använda, och möjligheterna i dess editor kommer aldrig att räcka till för att utföra ofta använda textbehandlingsåtgärder. Som ett verkligt Unix-program innehåller &kdevelop; flera möjligheter att starta externa program, att koppla in externa program för att behandla filer, eller använda externa filter för att behandla editorns nuvarande innehåll.

Den mest generella och enkla funktionen av den här typen är verktygsmenyn, som du kan anpassa fritt. Det görs i dialogrutan Inställningar Anpassa KDevelop... under Externa verktyg.

Andra verktyg beskrivs i kapitlet plugintools.

## Insticksverktyg

&kdevelop; innehåller ett stort antal små verktyg, som hjälper dig att utföra vissa uppgifter. De flesta fungerar som insticksprogram. Det betyder att om du inte tycker om något av dem, kan du helt enkelt stänga av det i dialogrutan Projektinställningar under Insticksprogram (för insticksprogram som gäller hela projektet) eller under Inställningar Anpassa KDevelop.... Insticksprogram som stängs av belastar inte menyer och laddas inte i minnet.

- ## Insticksprogrammet `abbrev`

  Det här insticksprogrammet fyller i förkortningar av ofta använda kodfragment. Det aktiveras genom att trycka på Ctrl Mellanslag. Om du till exempel skriver in `"ife"` i C++ editorn, och trycker på Ctrl Mellanslag, får du en `if-else` kodmall och sparar några tangentnertryckningar. Uppsättningen med förkortningar som stöds beror på den redigerade filens programspråk. För till exempel PHP är du naturligtvis intresserad av andra kodmallar än för Java.

  Uppsättningen med kodmallar kan anpassas. Du kan se vilka som är tillgängliga i dialogrutan Inställningar Anpassa KDevelop... under Förkortningar.

- ## Insticksprogrammet `filter`

  Detta erbjuder två funktioner. Om du väljer Verktyg Kör kommando kan du skriva in ett skalkommando. Utmatningen från kommandot infogas i editorns buffer när du trycker på knappen Starta.

  En liknande funktion är tillgänglig under Verktyg Filtrera markering genom kommando.... För att använda det här, måste du markera ett textområde i editorn. Om du nu skriver in ett skalkommando och trycker på knappen Starta, så startas kommandot och markeringen används som standardinmatning till det. Standardutmatningen infogas sedan i editorn.

- ## Insticksprogrammet &doxygen;

  Detta hjälper dig att använda API-dokumentationsverktyget &doxygen; (). Du kan välja Projekt Kör Doxygen för att skapa API-dokumentation för det nuvarande projektet baserat på konfigurationen som anges av filen `Doxyfile` i projektkatalogen.

  Dessutom kan du anpassa &doxygen; med dialogrutan Projekt Projektinställningar.... Dialogrutan är mycket lik verktyget &doxywizard;.

- ## Insticksprogrammet &ctags;

  Även om klassbläddraren ger dig utförlig överblick över symboler och klasser i projektet, kan du också vilja använda ctags-verktyget. Det stöder i synnerhet många fler språk än klassbläddraren.

  Du aktiverar insticksprogrammet under Verktyg CTags.... När du startar det för första gången, blir du tillfrågad om att först skapa en sökdatabas. När du accepterar detta, startas &ctags;-programmet och skapar en fil som heter `tags` i projektkatalogen. Detta är en textfil som innehåller alla symboler i källkodsfilerna.

  Du kan söka på två sätt i symboldatabasen: när rutan Matcha med reguljärt uttryck är markerad, tolkas texten som du skriver in som ett reguljärt uttryck (POSIX-varianten) och matchas med befintliga symboler. Texten `.*Widget` söker till exempel efter alla symboler som slutar med `Widget`. Om rutan inte är markerad, är sökningen verbatim.

  Under sökningen visas en lista med matchade symboler, tillsammans med radnummer där de definieras. Du hoppar till respektive ställe genom att klicka i listan.

  För vissa språk skiljer &ctags; mellan olika typer av symboler. Python har till exempel klasser och funktioner. Du kan söka enbart efter klasser genom att kryssa in motsvarande typ i dialogrutan.

  Symboldatabasen uppdateras normalt inte när källkoden ändras. På grund av detta kommer inte radnumren vara riktiga längre efter ett tag, och nytillagda klasser och funktioner kommer att saknas. Därför bör du uppdatera filen `tags` med regelbundna intervall, genom att trycka på knappen Skapa om.

- ## Insticksprogrammet `astyle`

  (... ännu inte skrivet ...)

- ## Insticksprogrammet `regexptest`

  Att konstruera reguljära uttryck kan vara ett hårt arbete. Ofta matchar det första försöket med ett uttryck för många strängar. I synnerhet vid arbete med ett kompilerat språk kan cykeltiden vid avlusning av ett reguljärt uttryck vara besvärlig. Insticksprogrammet regexptest låter dig direkt utforska ändringar i ett reguljärt uttryck. Det aktiveras genom att välja Verktyg Avlusa reguljärt uttryck....

  I variantkombinationsrutan kan du välja vilken variant av reguljära uttryck som ska användas. För närvarande stöds varianten som definieras av POSIX-standarden, som används av programmet &grep;, och den utökade POSIX-syntaxen som används av programmet &egrep;.

  När du skriver in ett uttryck, får du omedelbart återmatning om eventuella syntaxfel i det. Genom att skriva in en text under Teststräng, kan du se om uttrycket matchar strängen. I synnerhet om det reguljära uttrycket innehåller grupper, som `"([a-z])"`, visas innehållet av de matchade delgrupperna i en listruta.

- ## Insticksprogrammet `konsole`

### Översikt

&kdevelop; erbjuder utökningsbara moduler, eller delprogram, som laddas när programmet kör och vid behov. Det gör det möjligt för utvecklare att bara aktivera funktioner som de behöver eller vill ha för utvecklingen.

Vissa delprogram anses vara allmänna, dvs. de påverkar hela funktionen hos &kdevelop;. Till exempel uimode-delprogrammet låter en utvecklare välja vilket användargränssnitt som ska användas.

Andra delprogram är projektspecifika, och används bara när ett projekt av den typen laddas. Hantering av automake, behöver till exempel bara vara aktiv när ett automake-baserat projekt är laddat. Annars är den inte aktiv.

Aktiva delar kan påverka &kdevelop; på många sätt. Beroende på funktion, kan de lägga till extra menyer, extra menyalternativ, extra verktygsknappar etc.

### Delprogram för projekthantering i &kdevelop;

antproject | ANT-projekthantering (Java-program)
autoproject | Automake projekthantering
customproject | Egen projekthantering
trollproject | Qmake-baserad projekthantering

### Allmänna delprogram i &kdevelop;

Delprogramnamn | Beskrivning
appwizard | Ny projektguide
historik |
konsole | Inbäddad terminal
editor-chooser | Väljer en intern texteditor
doctreeview | Dokumentationsbläddrare
openwith |
fileselector | En komponent för att välja filer
uimode | Anpassa gränssnittsläget
texttools | Ytterligare textverktyg
tipofday | Dagens tips
grepview | Ett grafiskt flerfilsökningsverktyg
cvs | Stöd för CVS
verktyg |
regexptest | Verktyg för att prova reguljära uttryck
abbrev | Expansion av förkortningar
filter |
valgrind | Ett grafiskt gränssnitt till valgrind

### Delprogram för språkstöd i &kdevelop;

cppsupport | Stöd för C/C++
fortransupport | Stöd för Fortran
javasupport | Stöd för Java
perlsupport | Stöd för Perl
phpsupport | Stöd för PHP
pythonsupport | Stöd för Python

### Projektspecifika delprogram i &kdevelop;

astyle |
buglist |
classview | Klassvyhantering
ctags |
debugger | Hantering av &gnu;-avlusare
diff |
distpart |
doxygen |
fileview |
javadebugger |
manager |
nedit |
outputviews |
perforce |
qeditor |
scripting |
scriptproject |
sourcenav |
svn |
visualboyadvance |
windowmenu |

## Översikt över menyer och verktygsrader

(... ännu inte skrivet ...)

## Exempel på lägen i användargränssnittet för &kdevelop;

### Underramsläge

Klicka här för att återgå till översikten över lägen.

Skärmbild

&kdevelop; underramsläge

Klicka här för att återgå till översikten över lägen.

### Fliksidläge

Klicka här för att återgå till översikten över lägen.

Skärmbild

&kdevelop; fliksidläge

Klicka här för att återgå till översikten över lägen.

### Toppnivåläge

Klicka här för att återgå till översikten över lägen.

Skärmbild

&kdevelop; toppnivåläge

Klicka här för att återgå till översikten över lägen.

### IDEA-fönsterläge

Klicka här för att återgå till översikten över lägen.

Skärmbild

&kdevelop; IDEA-fönsterläge

Klicka här för att återgå till översikten över lägen.

## Ytterligare information

### Hämta information

### Rapportera fel

### Licenser

&underFDL; &underGPL;

## Ändringar

### Ändringar i dokumentet

- 2003-01-03 — Startade ändringsloggen

## Bibliografi

(... ännu inte skrivet ...)

(... ännu inte skrivet ...)