Bernd
Pol

# 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.

För mer information se webbplatsen Comprehensive Perl Archive Network (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.

## Högnivåskript

Högnivåprogram i &UNIX; saknar ofta snabbheten och flexibiliteten hos de traditionella teckenbaserade skalskriptmekanismerna. Det är särskilt sant i de grafiska gränssnittens värld, som t.ex. &kde;.

Försök har gjorts att tillhandahålla liknande mekanismer som fungerar på en högre programnivå, bland de mest nämnvärda är CORBA, och i &kde;-miljön, DCOP.

### CORBA-protokollet

CORBA (Common Object Request Broker Architecture) är ett försök att låta datorprogram arbeta tillsammans via nätverk. Det togs fram av den privata, leverantörsoberoende kommittén OMG (Object Management Group).

CORBA-baserade program använder IIOP-standardprotokollet för att kommunicera. Implementeringar baserade på IIOP är tillgängliga för ett stort antal operativsystem, programspråk och nätverk, och är därför mycket flyttbara.

Den huvudsakliga nackdelen med CORBA är dess ganska långsamma hastighet. Även om det kan tolereras i nätverk, är det ett verkligt hinder för kommunikation mellan program i en miljö utan nätverk, såsom &kde; när det kör på en enda dator.

### DCOP-gränssnittet

En annan evolution av &UNIX;-liknande skript är DCOP-protokollet, som uppfanns för kommunikation mellan &kde;-program för att bemästra CORBA:s begränsningar.

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 (även om den är mycket snabbare än CORBA). Ändå så återger 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 artikeln DCOP: Desktop COmmunications Protocol eller The DCOP Desktop Communication Protocol library, dokumentation av användargränssnittet för &kde;:s DCOP-bibliotek.

## Byggsystem

Utom i mycket enkla fall, kommer ett 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 man 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 som behövs:

- 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 alltid helt uppenbart vilka av filerna som måste kompileras om.

När t.ex. en funktionsprototyp i en deklarationsfil ändras, måste alla filer som beror på deklarationsfilen kompileras om. Om projektet innehåller många sådana filer kan man enkelt missa en eller två av dem om arbetet måste göras för hand. Därför behövs någon form av automatisering.

### 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.

En kort introduktion till gemensamma principer för konstruktion av grafiska gränssnitt finns här.

## 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 programmeringsprocesserna troligtvis ganska omständliga.

Mycket repetitivt arbete måste göras vid konstruktion, kompilering och avlusning av ett program. En hel del sådant 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.

Vore det till exempel inte bekvämt om 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:er) fram. En sådan miljö integrerar alla mallar, verktyg och skript som ofta 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; &kdevrelease;

- Hanterar alla utvecklingsverktyg som behövs för C++ programmering, som kompilator, länkare, avlusare och byggsystem.

- Tillhandahåller en programguide som skapar fullständiga, körklara exempelprogram.

- Låter användaren välja en integrerad editor baserad på &kde;:s programmeringseditor Kwrite, TrollTechs Qeditor eller andra.

- 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änssnittet 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 ett av flera versionshanteringssystem (t.ex. CVS), genom att tillhandahålla ett lättanvänt gränssnitt till funktionerna som oftast behövs.

- Ett integrerat gränssnitt för avlusning.

- En integrerad emulator av en skalkonsol.

- Syntaxfärgläggning i källkodstext.

- En funktion för 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.