path: root/tde-i18n-da/docs/tdevelop/tdevelop/unixdev.docbook

<appendix id="unixdev">

<appendixinfo>
  <authorgroup>
    <author
><firstname
>Bernd</firstname
><surname
>Pol</surname
></author>
    <!-- ROLES_OF_TRANSLATORS -->
  </authorgroup>
</appendixinfo>

<title
>Udvikling på Unix</title>

<indexterm zone="unixdev"
><primary
>udvikling</primary
></indexterm>
<indexterm zone="unixdev">
  <primary
>UNIX</primary>
  <secondary
>udvikling</secondary
></indexterm>

<sect1 id="history">
<title
>Nogle historiske bemærkninger</title>

<indexterm zone="history"
><primary
>historie</primary
></indexterm>
<indexterm zone="history"
><primary
>scriptsprog</primary
></indexterm>
<indexterm zone="history">
  <primary
>UNIX</primary>
  <secondary
>historie</secondary
></indexterm>
<indexterm zone="history">
  <primary
>UNIX</primary>
  <secondary
>pipe</secondary
></indexterm>
<indexterm zone="history">
  <primary
>UNIX</primary>
  <secondary
>skal</secondary
></indexterm>
<indexterm zone="history">
  <primary
>skal</primary>
  <secondary
>UNIX</secondary
></indexterm>

<para
>Fra begyndelsen har Unix opretholdt to meget forskellige udviklingsmodeller. Den ene er sfæren af programmeringssprog for <emphasis
>systemer og programmeringssprog</emphasis
>, hvor en kildekode oversættes til maskinkode med en <emphasis
>oversætter</emphasis
> eller <emphasis
>tolk</emphasis
>. Programmeringssproget C er et eksempel på dette. Unix var den første operativsystemkerne som blev skrevet i et højniveausprog i stedet for den maskinnære assembler, som var almindeligt tidligere. (I virkeligheden blev sproget C til og med opfundet for at skrive Unix-kernen, og tilhørende programmer, på en DEC PDP-11 maskine.) </para>
<para
>Den anden model er sfæren med <emphasis
>scriptsprog</emphasis
>, som startede med opfindelsen af Unix-skallen, som samtidigt var operativsystemets brugergrænseflade &mdash; og et programsprog på meget højt niveau. Et skalscript bygges op af en mængde små værktøjer som f.eks. <command
>grep</command
>, <command
>sed</command
> og <command
>find</command
>. Hvert sådant værktøj er konstrueret til en  afgrænset opgave. Tricket er at alle sådanne værktøjer kan forbindes med hinanden via en enkel overføringsmekanisme, der hedder <emphasis
>pipe</emphasis
>, som sender udskriften fra det foregående værktøj til indtastningen for den næste. Det giver grundlaget for en meget kraftfuld og fleksibel programmeringsmetode. </para>
<para
>Med tiden er begge sfærerne udviklet. Mens C stadigvæk i hovedsagen bruges som et systemprogrammeringssprog, har C++, som en variant af C beriget med objektorienterede og generiske udvidelser, fundet sin plads i udvikling af komplekse programmer i 1990'erne. Der er mange andre programmeringssprog, til og med ældre beholder deres plads &mdash; FORTRAN77 og Ada har f.eks. stadigvæk deres tilhængere specielt i numeriske programmer. </para>
</sect1
> <!-- history -->

<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->

<sect1 id="unixdev-scripting-languages">
<title
>Moderne scriptsprog</title>
<para
>På scriptområdet er der sket et skift væk fra skallen, som lider af flytbarhedsproblemer, til sprog som samler alle almindelige funktioner i standardbiblioteker, mens de stadigvæk kan have grænseflader mod omverden via pipes  når det behøves.  </para>
<para
>Alle scriptsprog har det tilfælles at de ofte er flytbare mellem mange Unix-varianter, &Microsoft; &Windows;, &MacOS; eller til og med VMS. Desuden har de alle implementeringer som kan distribueres frit. </para>

<sect2 id="unixdev-SL-Perl">
<title
>&perl;</title>

<indexterm zone="unixdev-SL-Perl"
><primary
>Perl</primary
></indexterm>
<indexterm zone="unixdev-SL-Perl">
  <primary
>scriptsprog</primary>
  <secondary
>Perl</secondary
></indexterm>

<para
>&perl; er blevet populært som tekstbehandlings- og systemadministrationssprog. Fra starten af internettet anvendtes CGI-scripter skrevet i &perl; som en udbredt måde at lave dynamiske netsider fra databaser. I dag er denne metode ofte erstattet med pluginnet <command
>mod_perl</command
> for net-serveren &apache;. Blandt &perl;s styrker er dets indbyggede støtte for avancerede regulære udtryk, og rige arkiver med frit distribuerede moduler. </para>
<para
>For mere information se hjemmesiden <ulink url="http://cpan.org"
>Comprehensive Perl Archive Network (<acronym
>CPAN</acronym
>)</ulink
>. </para>
</sect2
> <!-- unixdev-SL-Perl -->

<sect2 id="unixdev-SL-Python">
<title
>Python</title>

<indexterm zone="unixdev-SL-Python"
><primary
>Python</primary
></indexterm>
<indexterm zone="unixdev-SL-Python">
  <primary
>scriptsprog</primary>
  <secondary
>Python</secondary
></indexterm>

<para
><ulink url="http://www.python.org"
>&python;</ulink
> skinner med elegancen i sit klassesystem og enkelheden og fleksibiliteten som ydre biblioteker kan pakkes ind i, på en sådan måde at de ser ud til at være standardklasser og -funktioner i &python;. I modsætning til &perl;, har &python; en klar og koncis indlejringsgrænseflade, som gør den til det bedste valg for at muliggøre scripter for C og C++ programmer. </para>
</sect2
> <!-- unixdev-SL-Python -->

<sect2 id="unixdev-SL-PHP">
<title
>PHP</title>

<indexterm zone="unixdev-SL-PHP"
><primary
>PHP</primary
></indexterm>
<indexterm zone="unixdev-SL-PHP">
  <primary
>scriptsprog</primary>
  <secondary
>PHP</secondary
></indexterm>

<para
><ulink url="http://www.php.net"
>&php;</ulink
> blev opfundet som et sprog til direkte indlejring på &HTML;-sider, og har af den grund hovedbrugen at leverere dynamisk indhold for nettet. </para>
</sect2
> <!-- unixdev-SL-PHP -->
</sect1
> <!-- unixdev-scripting-languages -->

<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<sect1 id="unixdev-hl-script">
<title
>Højere-niveau scripter</title>

<para
>Højere-niveau UNIX-programmer mangler sædvanligvis den hastighed og fleksibilitet som de traditionelle tegn-orientede skal-script mekanismer har. Dette er især sandt i verdenen af grafiske brugergrænseflader (GUI) som f.eks. &kde;. </para>
<para
>Der har været forsøg på at sørge for lignende mekanismer som vil virke på et højere programniveau, især <link linkend="unixdev-corba"
>CORBA</link
> og, i &kde;-miljøet, <link linkend="unixdev-dcop"
>&DCOP;</link
>. </para>

<sect2 id="unixdev-corba">
<title
>CORBA-Protokollen</title>

<indexterm zone="unixdev-corba"
><primary
>CORBA</primary
></indexterm>
<indexterm zone="unixdev-corba">
  <primary
>scriptsprog</primary>
  <secondary
>CORBA</secondary
></indexterm>
<indexterm zone="unixdev-corba">
  <primary
>kommunikation</primary>
  <secondary
>CORBA</secondary
></indexterm>

<para
><ulink url="http://www.omg.org/gettingstarted/corbafaq.htm"
>CORBA</ulink
> (<emphasis
>Common Object Request Broker Architecture</emphasis
>) er et forsøg på at lade computerens programmer arbejde sammen henover netværk. Det blev lavet af den private, leverandøruafhængige <ulink url="http://www.omg.org"
>OMG</ulink
> (Object Management Group) standardkomite. </para>
<para
>CORBA-baserede programmer bruger IIOP standardprotokollen til at kommunikere. Implementationer baseret på IIOP er tilgængelige på et vidt område af operativsystemer, programmeringssprog og netværk og er således ekstremt flytbart. </para>
<para
>Hovedbagdelen ved CORBA er dens temmelig langsomme hastighed. Mens dette kan tolereres i netværk, er det en ægte hindring for interprogram kommunikationer i et miljø uden netværk såsom &kde; kørende på en enkelt computer. </para>

</sect2
> <!-- unixdev-corba -->

<sect2 id="unixdev-dcop">
<title
>&DCOP;-grænsefladen</title>

<indexterm zone="unixdev-dcop"
><primary
>DCOP</primary
></indexterm>
<indexterm zone="unixdev-dcop">
  <primary
>scriptsprog</primary>
  <secondary
>DCOP</secondary
></indexterm>
<indexterm zone="unixdev-dcop">
  <primary
>kommunikation</primary>
  <secondary
>DCOP</secondary
></indexterm>

<para
>En anden udvikling af UNIX-lignende scripter er <ulink url="http://developer.kde.org/documentation/library/kdeqt/dcop.html"
><emphasis
>DCOP</emphasis
></ulink
>-protokollen som blev lavet til kommunikation mellem &kde; programmer for at komme ud over  CORBA's begrænsninger. </para>
<para
>&DCOP; betyder <emphasis
>Desktop COmmunikation Protocol</emphasis
> (protokollen for desktopkommunikation), og er implementeret som en enkel IPC/RPC-mekanisme bygget til at virke via udtag. Sluteffekten er at tilbyde funktioner som ligner den traditionelle pipe-mekanisme i Unix. </para>
<para
>Traditionelle skalscripter er baserede på ganske små programværktøjer, som blev konstrueret til at virke baseret på ren tekst. &DCOP; tillader at avancerede grafiske programmer kommunikerer med hinanden på en tilsvarende måde. Det gør det for eksempel muligt for et &kde;-program at sende meddelelser til et andet &kde;-program, eller tage imod data fra det til sine egne formål. </para>
<para
>Der er dog bagdele. For at bruge &DCOP;, skal programmet være konstrueret med en speciel &DCOP;-grænseflade. Desuden går &DCOP;-kommunikationsprocessen noget langsomt (selvom den går hurtigere end CORBA). Alligevel så giver det meget af styrken og fleksibiliteten i Unix-scripter til højniveauprogrammer som er baserede på en grafisk brugergrænseflade. </para>
<para
>For yderligere information, se <ulink url="http://developer.kde.org/documentation/library/kdeqt/dcop.html"
>DCOP Desktop COmmunication Protocol library</ulink
> artiklen eller <ulink url="developer.kde.org/documentation/library/cvs-api/dcop/html/index.html"
>The &DCOP; Desktop Communication Protocol library</ulink
>, dokumentation af brugergrænsefladen for &kde;'s DCOP-bibliotek. </para>
</sect2
> <!--  unixdev-dcop -->

</sect1
> <!--  unixdev-hl-script -->

<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->

<sect1 id="unixdev-buildsystems">
<title
>Byggesystemer</title>

<para
>Undtagen i meget enkle tilfælde, vil programmeringsprojekter bestå af mange byggeblokke med kildekode, hvert af dem placeret i en enkelt fil for enklere vedligeholdelse. For at få alt til at køre, skal du effektivt kunne oversætte alt dette til nogen få maskinkodeenheder med passende format, som gør at operativsystemet kan indlæse og køre programmet. </para>
<para
>For at opnå dette, er de grundlæggende værktøjer du behøver <itemizedlist>
  <listitem
><para
>en <emphasis
>teksteditor</emphasis
> til at skrive kildekodefilerne, </para
></listitem>
  <listitem
><para
>et oversættelsesprogram, oftest en <emphasis
>oversætter</emphasis
> til at lave kildekoden om til objektfiler, </para
></listitem>
  <listitem
><para
>et <emphasis
>biblioteksprogram</emphasis
> som samler objektfiler i biblioteker, som nemt kan genbruges uden at behøve at kompileres igen, </para
></listitem>
  <listitem
><para
>en <emphasis
>linker</emphasis
>, som binder flere objektfiler og biblioteker sammen til et kørbart program, </para
></listitem>
  <listitem
><para
>et <emphasis
>byggesystem</emphasis
>, som tilbyder nogle måder at håndtere alt dette, og ikke at forglemme, </para
></listitem>
  <listitem
><para
>en <emphasis
>fejlsøger</emphasis
> til (forhåbentlig) at finde alle fejl i programmet, og muligvis yderligere diagnoseværktøjer for at få alt til at køre smidigt. </para
></listitem>
</itemizedlist>
</para>

<para
>Når man har et stort projekt, som kan bestå af op til hundredvis af  kildekodefiler, kan kompileringsprocessen blive rigtigt arbejdsintensiv. Man vil ikke kompilere alle filer om hver gang en af dem er ændret. I stedet vil man kun kompilere de filer om som er påvirket af ændringen. I almindelighed er det ikke klart hvilke det er. Når en funktionsprototype i en deklarationsfil er ændret, skal alle filer som afhænger af  deklarationsfilen kompileres om. </para>
<para
>Når du f.eks. ændrer en funktionsprototype i en deklarationsfil, skal du kompilere hver fil som inkluderer denne deklarationsfil. Hvis dit projekt indeholder mange sådanne filer, kan du nemt glemme en eller to af dem hvis du skal gøre det manuelt. Således er automatiseringsmetoder en nødvendighed. </para>

<sect2 id="unixdev-buildsystems-make">
<title
>Make-processen</title>

<indexterm zone="unixdev-buildsystems-make">
  <primary
>make</primary
></indexterm>
<indexterm zone="unixdev-buildsystems-make">
  <primary
>Makefile</primary
></indexterm>
<indexterm zone="unixdev-buildsystems-make">
  <primary
>regel</primary
></indexterm>
<indexterm zone="unixdev-buildsystems-make">
  <primary
>genkompileringer</primary
></indexterm>
<indexterm zone="unixdev-buildsystems-make">
  <primary
>mål</primary
></indexterm>
<indexterm zone="unixdev-buildsystems-make">
  <primary
>afhængigheder</primary
></indexterm>
<indexterm zone="unixdev-buildsystems-make">
  <primary
>kommandoer</primary
></indexterm>

<para
>Et værktøj som tager sig af omkompileringer er <command
>make</command
>. Det holder styr på alt arbejde med et sæt <emphasis
>regler</emphasis
>, som beskriver hvad der skal gøres hvis en vis information (oftest en kildekode- eller objektkodefil) er ændret. Alle regler som hører til et vist projekt opbevares i en såkaldt <filename
>Makefile</filename
>, som behandles af <command
>make</command
> så snart du vil opdatere dit arbejde. </para>
<para
>Hver regel består af flere byggeblokke, nærmere bestemt <itemizedlist>
  <listitem
><para
>et <emphasis
>mål</emphasis
>, &ie; filen som skal bygges </para
></listitem>
  <listitem
><para
>et sæt <emphasis
>afhængigheder</emphasis
>, egentlig navnene på de filer som målet afhænger af (&eg; navnet på en kildekodefil, når målet er navnet på objektfilen som skal bygges) og </para
></listitem>
  <listitem
><para
>de <emphasis
>kommandoer</emphasis
> som skal køres for at <quote
>make</quote
> målet (dvs. for at kompilere det eller linke det sammen med andre objektfiler for at lave en kørbar programfil). </para
></listitem>
</itemizedlist>
</para>
<para
>Enkelt udtrykt, læser kommandoen <command
>make</command
> reglerne en af gangen, kontrollerer hver fil i afhængighedslisten for et givet mål, og bygger målet igen hvis nogen af filerne er ændrede, med de kommandoer som er på listen i den regel. </para>
<para
>Der er adskillige yderligere muligheder for at styre en sådan byggeproces, og en <filename
>Makefile</filename
> kan således vokse og blive meget kompleks. Vi kan ikke gå ind på detaljer her. Under alle omstændigheder, anbefaler vi at du gør dig bekendt med syntaksen for <command
>make</command
>. Selv om du ikke normalt bruger det direkte, kan en forståelse for det fundamentale i byggesystemet være nyttigt. Se <ulink url="info://make/Top"
><quote
>GNU make manualen</quote
></ulink
> for mere information. </para>
<para
>For mere detaljeret information specifik for &tdevelop;, se <link linkend="project-management"
>Bygge og projekthåndtering</link
> i denne håndbog. </para>
<para
>Der er flere vejledninger tilgængelige, se <link linkend="automake-references"
>referencer</link
> i kapitlet Bygge og projekthåndtering. </para>
</sect2
> <!-- unixdev-buildsystems-make -->

</sect1
> <!-- unixdev-buildsystems -->

<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->

<sect1 id="unixdev-guidevelopment">
<title
>Udvikling af grafisk grænseflade</title>

<indexterm zone="unixdev-guidevelopment">
  <primary
>GUI</primary
></indexterm>
<indexterm zone="unixdev-guidevelopment">
  <primary
>grafisk brugergrænseflade</primary
></indexterm>
<indexterm zone="unixdev-guidevelopment">
  <primary
>brugergrænseflade</primary>
  <secondary
>GUI</secondary
></indexterm>

<para
>Programudviklere bliver endnu mere belastede ved at de ikke kun skal lave programbibliotekerne og logikken, men også sørge for let anvendelige egenbyggede brugergrænseflader som både er nemme at forstå og funktionelle. De fleste programmører får lidt eller ingen uddannelse i udvikling af grafiske grænseflader, og som et resultat er brugergrænseflader ofte dårligt konstruerede. </para>
<para
>Gennem mange år er nogle fælles designprincipper blevet udviklet. Du anbefales stærkt at holde dig til dem. På den måde beholder din brugergrænseflade fælles udseende og fornemmelse, hvilket brugere af programmet vil sætte pris på. </para>
<para
>For udvikling af grafiske grænseflader for &kde; er der en stilguide tilgængelig. Den findes som <ulink url="http://developer.kde.org/documentation/standards/kde/style/basics/index.html"
>&kde;'s guide for brugergrænseflade</ulink
> på siden &kde;'s udviklingshjørne. </para>
<para
>En kort introduktion til almindelige GUI design-principper kan findes <ulink url="http://axp16.iie.org.mx/Monitor/v01n03/ar_ihc2.htm"
>her</ulink
>. </para>

</sect1
> <!-- unixdev-guidevelopment -->

<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->

<sect1 id="unixdev-ide">
<title
>Integration af begreber og værktøjer: det integrerede udviklingsmiljø</title>

<indexterm zone="unixdev-ide">
  <primary
>IDE</primary
></indexterm>
<indexterm zone="unixdev-ide">
  <primary
>integreret udviklingsmiljø</primary
></indexterm>
<indexterm zone="unixdev-ide">
  <primary
>udvikling</primary>
  <secondary
>IDE</secondary
></indexterm>
<indexterm zone="unixdev-ide">
  <primary
>miljø</primary>
  <secondary
>IDE</secondary
></indexterm>

<para
>Der er separate værktøjer tilgængelige for næsten hvert skridt i programmeringsprocessen &mdash; planlægning, redigering, processen for at håndtere filer og kompilering, fejlsøgning, dokumentation med mere. Men når projekterne vokser, bliver programmeringsprocessen sandsynligvis ganske omstændelig. </para>
<para
>Meget gentagent arbejde skal gøres ved konstruktion, kompilering og fejlsøgning af et program. En hel del arbejde kan gemmes ved at bruge skabeloner og scripter. Yderligere arbejde kan gemmes ved at have værktøjer let tilgængelige, og med mulighed for at kommunikere med hinanden i en fælles grafisk grænseflade. </para>
<para
>For eksempel &mdash; ville det ikke være bekvemt hvis en fejlsøger kunne åbne kildekoden det drejer sig om i en editor, og placere markøren direkte på stedet for fejlen som netop blev fundet. </para>
<para
>For nemmere at opnå et sådant system kom <emphasis
>integrerede udviklingsmiljøer</emphasis
> (IDE) frem. Et sådant miljø integrerer alle skabeloner, værktøjer og scripter som behøves i udviklingsprocessen i en enkelt omgivelse. </para>
<para
>&tdevelop; er et sådant integreret udviklingsmiljø for &kde;-platformen. Den tilbyder et bredt spektrum af værktøjer som letter programudvikling og vedligeholdelse, til og med for forskellige programsprog og forskellige platforme. </para>

<sect2 id="unixdev-ide-tdevelop">
<title
>Grundlæggende funktioner i &tdevelop; &kdevrelease;</title>

<indexterm zone="unixdev-ide-tdevelop">
  <primary
>&tdevelop;</primary>
  <secondary
>funktioner</secondary
></indexterm>
<indexterm zone="unixdev-ide-tdevelop">
  <primary
>funktioner</primary
></indexterm>

<!-- ### copied from web page, needs to be updated -->

<itemizedlist>
  <listitem>
  <para
>Håndterer alle <emphasis
>udviklingsværktøjer</emphasis
> som behøves for C++ programmering, såsom oversætteren, linkeren, fejlsøgeren og byggesystemet</para>
  </listitem>
  <listitem>
  <para
>Sørger for en <emphasis
>programguide</emphasis
> som laver fuldstændige, køreklare eksempelprogrammer</para>
  </listitem>
  <listitem>
  <para
>Tillader brugeren at vælge en <emphasis
>integreret editor</emphasis
> baseret på &kde;'s programmeringseditoren &kwrite;, Trolltec's <application
>QEditor</application
>, eller andre.</para>
  </listitem>
  <listitem>
  <para
>En <emphasis
>klassegenerator</emphasis
> til at oprette nye klasser og integrere dem i det nuværende projekt</para>
  </listitem>
  <listitem>
  <para
><emphasis
>Filhåndtering</emphasis
> for kildekode, deklarationer, dokumentation, osv. som skal indgå i projektet</para>
  </listitem>
  <listitem>
  <para
>Hjælp med at <emphasis
>lave en brugerhåndbog for programmet</emphasis
> skrevet med &kde;-værktøjer.</para>
  </listitem>
  <listitem>
  <para
>Automatisk &HTML;-baseret <emphasis
>dokumentation af programmeringsgrænseflade</emphasis
> for projektets klasser med krydsreference til de brugte biblioteker</para>
  </listitem>
  <listitem>
  <para
><emphasis
>Oversættelsesunderstøttelse</emphasis
> som gør det muligt for oversættere enkelt at tilføje deres modersmål til projektet, inklusive understøttelse for &kbabel;.</para>
  </listitem>
  <listitem>
  <para
>Støtte for at håndtere et projekt via et af adskillige <emphasis
>versionssystemer</emphasis
> (f.eks. &CVS;), ved at sørge for en letanvendelig grænseflade til funktionerne som oftest behøves</para>
  </listitem>
  <listitem>
  <para
>En integreret <emphasis
>fejlsøger</emphasis
> forende.</para>
  </listitem>
  <listitem>
  <para
>En integreret <emphasis
>skal-konsol</emphasis
> emulator.</para>
  </listitem>
  <listitem>
  <para
><emphasis
>kommentarer</emphasis
> i deklarationsfiler og kildekodefiler.</para>
  </listitem>
  <listitem>
  <para
><emphasis
>Automatisk kodekomplettering</emphasis
> for klassevariabler, klassemetoder, funktionsargumenter med mere</para>
  </listitem>
  <listitem>
  <para
><emphasis
>Skabeloner til at oprette diverse projekter</emphasis
> (moduler i kontrolcentret, miniprogrammer i panelet &kicker;, I/O-slaver, plugin til &konqueror; og desktopstiler)</para>
  </listitem>
  <listitem>
  <para
>Fire <emphasis
>navigationstrævisninger</emphasis
> for nemt at kunne skifte mellem kildekodefiler, deklarationsfiler, klasser og dokumentation, hvilket gør det unødvendigt med en ekstern filhåndtering</para>
  </listitem>
  <listitem>
  <para
><emphasis
>Støtte for krydskompilering</emphasis
>, med mulighed for at angive forskellige oversættere, oversætterflag, målarkitektur osv.</para>
  </listitem>
  <listitem>
  <para
>Støtte for <emphasis
>projekter med Qt/Embedded</emphasis
> (som Zaurus og IPAQ)</para>
  </listitem>
  <listitem>
  <para
>Mulighed for  <emphasis
>inklusion af et hvilket som helst andet program</emphasis
> du behøver til udvikling ved at tilføje det i menuen <guimenuitem
>Værktøjer</guimenuitem
>, ifølge dine individuelle behov</para>
  </listitem>
</itemizedlist>

</sect2
> <!-- unixdev-ide-tdevelop -->

</sect1
> <!-- unixdev-ide -->

</appendix
> <!-- unixdev -->