1
<appendix id="unixdev">
11
<!-- ROLES_OF_TRANSLATORS -->
16
>Utveckling på &UNIX;</title>
18
<indexterm zone="unixdev"
22
<indexterm zone="unixdev">
26
>utveckling</secondary
31
>Några historiska anmärkningar</title>
33
<indexterm zone="history"
37
<indexterm zone="history"
41
<indexterm zone="history">
47
<indexterm zone="history">
51
>rörledning</secondary
53
<indexterm zone="history">
59
<indexterm zone="history">
67
>Från början har &UNIX; upprätthållit två mycket olika utvecklingsmodeller. Den ena är sfären av programspråk för <emphasis
68
>system och tillämpningar</emphasis
69
>, där en källkod översätts till maskinkod med en <emphasis
73
>. 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.) </para>
75
>Den andra modellen är sfären med <emphasis
76
>skriptspråk</emphasis
77
>, 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. <command
83
>. 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 <emphasis
85
>, 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. </para>
87
>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. </para>
91
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
93
<sect1 id="unixdev-scripting-languages">
95
>Moderna skriptspråk</title>
97
>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. </para>
99
>Alla skriptspråk har gemensamt att de ofta är flyttbara mellan många &UNIX;-varianter, &Microsoft; &Windows;, &MacOS; eller till och med VMS. Dessutom har de alla implementeringar som kan distribueras fritt. </para>
101
<sect2 id="unixdev-SL-Perl">
105
<indexterm zone="unixdev-SL-Perl"
109
<indexterm zone="unixdev-SL-Perl">
111
>skriptspråk</primary>
117
><ulink url="http://www.perl.com"
119
> 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 <command
121
> 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. </para>
123
>För mer information se webbplatsen <ulink url="http://cpan.org"
124
>Comprehensive Perl Archive Network (<acronym
129
> <!-- unixdev-SL-Perl -->
131
<sect2 id="unixdev-SL-Python">
135
<indexterm zone="unixdev-SL-Python"
139
<indexterm zone="unixdev-SL-Python">
141
>skriptspråk</primary>
147
><ulink url="http://www.python.org"
149
> 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. </para>
151
> <!-- unixdev-SL-Python -->
153
<sect2 id="unixdev-SL-PHP">
157
<indexterm zone="unixdev-SL-PHP"
161
<indexterm zone="unixdev-SL-PHP">
163
>skriptspråk</primary>
169
><ulink url="http://www.php.net"
171
> 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. </para>
173
> <!-- unixdev-SL-PHP -->
175
> <!-- unixdev-scripting-languages -->
177
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
178
<sect1 id="unixdev-hl-script">
180
>Högnivåskript</title>
183
>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;. </para>
185
>Försök har gjorts att tillhandahålla liknande mekanismer som fungerar på en högre programnivå, bland de mest nämnvärda är <link linkend="unixdev-corba"
187
>, och i &kde;-miljön, <link linkend="unixdev-dcop"
191
<sect2 id="unixdev-corba">
193
>CORBA-protokollet</title>
195
<indexterm zone="unixdev-corba"
199
<indexterm zone="unixdev-corba">
201
>skriptspråk</primary>
205
<indexterm zone="unixdev-corba">
207
>kommunikation</primary>
213
><ulink url="http://www.omg.org/gettingstarted/corbafaq.htm"
216
>Common Object Request Broker Architecture</emphasis
217
>) är ett försök att låta datorprogram arbeta tillsammans via nätverk. Det togs fram av den privata, leverantörsoberoende kommittén <ulink url="http://www.omg.org"
219
> (Object Management Group). </para>
221
>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. </para>
223
>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. </para>
226
> <!-- unixdev-corba -->
228
<sect2 id="unixdev-dcop">
230
>&DCOP;-gränssnittet</title>
232
<indexterm zone="unixdev-dcop"
236
<indexterm zone="unixdev-dcop">
238
>skriptspråk</primary>
242
<indexterm zone="unixdev-dcop">
244
>kommunikation</primary>
250
>En annan evolution av &UNIX;-liknande skript är <ulink url="http://developer.kde.org/documentation/library/kdeqt/dcop.html"
254
>-protokollet, som uppfanns för kommunikation mellan &kde;-program för att bemästra CORBA:s begränsningar. </para>
256
>&DCOP; betyder <emphasis
257
>Desktop COmmunikation Protocol</emphasis
258
> (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;. </para>
260
>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. </para>
262
>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. </para>
264
>För ytterligare information, se artikeln <ulink url="http://developer.kde.org/documentation/library/kdeqt/dcop.html"
265
>DCOP: Desktop COmmunications Protocol</ulink
266
> eller <ulink url="developer.kde.org/documentation/library/cvs-api/dcop/html/index.html"
267
>The DCOP Desktop Communication Protocol library</ulink
268
>, dokumentation av användargränssnittet för &kde;:s DCOP-bibliotek. </para>
270
> <!-- unixdev-dcop -->
273
> <!-- unixdev-hl-script -->
275
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
277
<sect1 id="unixdev-buildsystems">
282
>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. </para>
284
>För att åstadkomma detta, är de grundläggande verktyg som behövs: <itemizedlist>
288
>texteditor</emphasis
289
> för att skriva källkodsfilerna, </para
293
>ett översättningsprogram, oftast en <emphasis
294
>kompilator</emphasis
295
> för att omvandla källkoden till objektfiler, </para
300
>biblioteksprogram</emphasis
301
> som samlar objektfiler i bibliotek, som enkelt kan återanvändas utan att behöva kompileras om, </para
307
>, som binder ihop flera objektfiler och bibliotek till ett körbart program, </para
312
>byggsystem</emphasis
313
>, som erbjuder något sätt att hantera allt detta, och inte att förglömma, </para
319
> för att (förhoppningsvis) hitta alla fel i programmet, och möjligen ytterligare diagnosverktyg för att få allt att köra smidigt. </para
325
>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. </para>
327
>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. </para>
329
<sect2 id="unixdev-buildsystems-make">
331
>Byggprocessen</title>
333
<indexterm zone="unixdev-buildsystems-make">
337
<indexterm zone="unixdev-buildsystems-make">
341
<indexterm zone="unixdev-buildsystems-make">
345
<indexterm zone="unixdev-buildsystems-make">
347
>omkompileringar</primary
349
<indexterm zone="unixdev-buildsystems-make">
353
<indexterm zone="unixdev-buildsystems-make">
357
<indexterm zone="unixdev-buildsystems-make">
363
>Ett verktyg som tar hand om omkompileringar är <command
365
>. Det håller reda på allt arbete med en uppsättning <emphasis
367
>, 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 <filename
369
>, som behandlas av <command
371
> så fort du vill uppdatera arbetet. </para>
373
>Varje regel består av flera byggblock, närmare bestämt <itemizedlist>
378
>, dvs filen som ska byggas </para
382
>en uppsättning <emphasis
384
>, 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 </para
390
> som ska köras för att <quote
392
> målet (dvs. för att kompilera det eller länka ihop andra objektfiler för att skapa en körbar programfil). </para
397
>Enkelt uttryckt, läser kommandot <command
399
> 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. </para>
401
>Det finns flera ytterligare möjligheter att styra en sådan byggprocess, och en <filename
403
> 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 <command
405
>. Även om du inte normalt använder det direkt, kan en förståelse för grunderna i byggsystemet vara användbar. Se <ulink url="info://make/Top"
407
>GNU make manualen</citetitle
409
> för mer information. </para>
411
>För mer detaljinformation specifik för &kdevelop;, se <link linkend="project-management"
412
>Bygga och projekthantering</link
413
> i den här handboken. </para>
415
>Det finns flera handledningar tillgängliga, se <link linkend="automake-references"
417
> i kapitlet Bygga och projekthantering. </para>
419
> <!-- unixdev-buildsystems-make -->
422
> <!-- unixdev-buildsystems -->
424
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
426
<sect1 id="unixdev-guidevelopment">
428
>Utveckling av grafiska gränssnitt</title>
430
<indexterm zone="unixdev-guidevelopment">
434
<indexterm zone="unixdev-guidevelopment">
436
>grafiskt användargränssnitt</primary
438
<indexterm zone="unixdev-guidevelopment">
440
>användargränssnitt</primary>
446
>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. </para>
448
>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. </para>
450
>För utveckling av grafiska gränssnitt för &kde; finns en stilguide tillgänglig. Den finns som <ulink url="http://developer.kde.org/documentation/standards/kde/style/basics/index.html"
451
>&kde;:s guide för användargränssnitt</ulink
452
> på sidan &kde;:s utvecklingshörna. </para>
454
>En kort introduktion till gemensamma principer för konstruktion av grafiska gränssnitt finns <ulink url="http://axp16.iie.org.mx/Monitor/v01n03/ar_ihc2.htm"
459
> <!-- unixdev-guidevelopment -->
461
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
463
<sect1 id="unixdev-ide">
465
>Integration av koncept och verktyg: den integrerade utvecklingsmiljön</title>
467
<indexterm zone="unixdev-ide">
471
<indexterm zone="unixdev-ide">
473
>integrerad utvecklingsmiljö</primary
475
<indexterm zone="unixdev-ide">
477
>utveckling</primary>
481
<indexterm zone="unixdev-ide">
489
>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. </para>
491
>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. </para>
493
>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? </para>
495
>För att enklare uppnå ett sådant fall, togs <emphasis
496
>integrerade utvecklingsmiljöer</emphasis
497
> (IDE:er) fram. En sådan miljö integrerar alla mallar, verktyg och skript som ofta behövs i utvecklingsprocessen i en enda omgivning. </para>
499
>&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. </para>
501
<sect2 id="unixdev-ide-kdevelop">
503
>Grundläggande funktioner i &kdevelop; &kdevrelease;</title>
505
<indexterm zone="unixdev-ide-kdevelop">
507
>&kdevelop;</primary>
509
>funktioner</secondary
511
<indexterm zone="unixdev-ide-kdevelop">
516
<!-- ### copied from web page, needs to be updated -->
521
>Hanterar alla <emphasis
522
>utvecklingsverktyg</emphasis
523
> som behövs för C++ programmering, som kompilator, länkare, avlusare och byggsystem.</para>
527
>Tillhandahåller en <emphasis
528
>programguide</emphasis
529
> som skapar fullständiga, körklara exempelprogram.</para>
533
>Låter användaren välja en <emphasis
534
>integrerad editor</emphasis
535
> baserad på &kde;:s programmeringseditor &kwrite;, TrollTechs <application
536
>Qeditor</application
537
> eller andra.</para>
542
>klassgenerator</emphasis
543
> för att skapa nya klasser och integrera dem i det nuvarande projektet.</para>
548
>Filhantering</emphasis
549
> för källkod, deklarationer, dokumentation, etc. som ska ingå i projektet.</para>
553
>Hjälp med att <emphasis
554
>skapa en användarhandbok</emphasis
555
> för programmet skriven med &kde;-verktyg.</para>
559
>Automatisk HTML-baserad <emphasis
560
>dokumentation av programmeringsgränssnittet</emphasis
561
> för projektets klasser med korsreferens till använda bibliotek.</para>
566
>Översättningsstöd</emphasis
567
> 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;.</para>
571
>Stöd för att hantera ett projekt via ett av flera <emphasis
572
>versionshanteringssystem</emphasis
573
> (t.ex. &CVS;), genom att tillhandahålla ett lättanvänt gränssnitt till funktionerna som oftast behövs.</para>
577
>Ett integrerat gränssnitt för <emphasis
583
>En integrerad emulator av en <emphasis
584
>skalkonsol</emphasis
590
>Syntaxfärgläggning</emphasis
591
> i källkodstext.</para>
595
>En funktion för <emphasis
596
>automatisk kodkomplettering</emphasis
597
> för klassvariabler, klassmetoder, funktionsargument med mera.</para>
602
>Mallar för att skapa diverse projekt</emphasis
603
> (moduler i inställningscentralen, miniprogram i panelen &kicker;, I/O-slavar, insticksprogram till &konqueror; och skrivbordsstilar).</para>
609
> för att enkelt byta mellan källkodsfiler, deklarationsfiler, klasser och dokumentation, vilket gör det onödigt med en extern filhanterare.</para>
614
>Stöd för korskompilering</emphasis
615
>, med möjlighet att ange olika kompilatorer, kompilatorflaggor, målarkitektur etc.</para>
619
>Stöd för projekt med <emphasis
620
>Qt/Embedded</emphasis
621
> (som Zaurus och IPAQ).</para>
625
>Möjlighet att <emphasis
626
>inkludera vilket annat program</emphasis
627
> som helst som du behöver för utveckling genom att lägga till det i menyn <guimenuitem
628
>Verktyg</guimenuitem
629
>, enligt dina individuella behov.</para>
634
> <!-- unixdev-ide-kdevelop -->
637
> <!-- unixdev-ide -->
added
removed
docs/kdevelop/kdevelop/unixdev.docbook
