path: root/tde-i18n-it/docs/kdevelop/kdevelop/unixdev.docbook

<appendix id="unixdev">

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

<title
>Sviluppo su &UNIX;</title>

<indexterm zone="unixdev"
><primary
>sviluppo</primary
></indexterm>
<indexterm zone="unixdev">
  <primary
>&UNIX;</primary>
  <secondary
>sviluppo</secondary
></indexterm>

<sect1 id="history">
<title
>Alcune note storiche</title>

<indexterm zone="history"
><primary
>storia</primary
></indexterm>
<indexterm zone="history"
><primary
>linguaggi di scripting</primary
></indexterm>
<indexterm zone="history">
  <primary
>&UNIX;</primary>
  <secondary
>storia</secondary
></indexterm>
<indexterm zone="history">
  <primary
>&UNIX;</primary>
  <secondary
>pipe</secondary
></indexterm>
<indexterm zone="history">
  <primary
>&UNIX;</primary>
  <secondary
>shell</secondary
></indexterm>
<indexterm zone="history">
  <primary
>shell</primary>
  <secondary
>&UNIX;</secondary
></indexterm>

<para
>Fin dall'inizio &UNIX; ha mantenuto due paradigmi di sviluppo molto diversi tra loro. Uno è costituito dal mondo dei <emphasis
>linguaggi di programmazione</emphasis
>, dove il codice sorgente è tradotto in linguaggio macchina da un programma di traduzione, solitamente un <emphasis
>compilatore</emphasis
> o un <emphasis
>interprete</emphasis
>. Il linguaggio di programmazione C ne è un esempio. &UNIX; fu il primo kernel di sistema operativo ad essere scritto interamente in un linguaggio di alto livello, invece del linguaggio assembler, fortemente legato alla macchina, che era comunemente usato prima di allora. (Di fatto, il linguaggio C venne addirittura inventato per scrivere il kernel &UNIX; e i programmi associati su un computer DEC PDP-11). </para>
<para
>L'altro paradigma è costituito dai <emphasis
>linguaggi di scripting</emphasis
>. Si è evoluto con l'invenzione della shell &UNIX; che era l'interfaccia utente del sistema operativo &mdash; e allo stesso tempo un linguaggio di programmazione ad un livello molto alto. Uno script della shell è formato da un insieme di piccoli programmi di utilità come &eg; <command
>grep</command
>, <command
>sed</command
> o <command
>find</command
>. Ognuno di essi è progettato per un compito ben definito. Il trucco consiste nel fatto che ogni programma di questo tipo può essere connesso ad un altro attraverso un semplice meccanismo di trasferimento chiamato <emphasis
>pipe</emphasis
>, che direziona l'output di una utility nell'input di un'altra successiva. Questo lo rende uno strumento di programmazione molto potente e altamente flessibile. </para>
<para
>Col passare del tempo si sono evoluti entrambi gli ambiti. Mentre il C viene ancora usato principalmente come un linguaggio di programmazione di sistema, il C++, una variante del C arricchito dell'orientamento agli oggetti e della programmazione generica, ha trovato  negli anni '90 il suo posto nello sviluppo di applicazioni complesse. Esistono numerosi altri linguaggi di programmazione e anche quelli più antichi hanno conservato il loro impiego &mdash; il FORTRAN77 e Ada &eg; hanno ancora il loro punto di forza nelle applicazioni numeriche. </para>
</sect1
> <!-- history -->

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

<sect1 id="unixdev-scripting-languages">
<title
>Linguaggi di scripting contemporanei</title>
<para
>Nell'area dello scripting, c'è stato un allontanamento dalla shell, che soffriva di problemi di portabilità, verso linguaggi che unificavano tutte le funzionalità necessarie nelle loro librerie standard e se necessario potevano comunque interfacciarsi verso l'esterno attraverso le pipe. </para>
<para
>Tutti questi linguaggi di scripting avevano in comune il fatto che erano ampiamente portabili attraverso le varianti di &UNIX;, Microsoft &Windows;, &MacOS; e anche VMS. Inoltre tutti disponevano di implementazioni che erano liberamente distribuibili. </para>

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

<indexterm zone="unixdev-SL-Perl"
><primary
>Perl</primary
></indexterm>
<indexterm zone="unixdev-SL-Perl">
  <primary
>linguaggi di scripting</primary>
  <secondary
>Perl</secondary
></indexterm>

<para
>Il <ulink url="http://www.perl.com"
>&perl;</ulink
> divenne popolare come elaboratore di testo e linguaggio di amministrazione di sistema. All'inizio del World Wide Web, gli script CGI in &perl; erano largamente usati per creare pagine Web dinamiche connesse ai database. Oggi questo metodo è stato rimpiazzato prevalentemente dal plugin <command
>mod_perl</command
> del server web &apache;. Tra i punti di forza del &perl; c'è il suo supporto incorporato per le espressioni regolari avanzate e il suo ricco archivio di moduli liberamente distribuibili. </para>
<para
>Per ulteriori informazioni vedere il sito <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
>linguaggi di scripting</primary>
  <secondary
>Python</secondary
></indexterm>

<para
>Il <ulink url="http://www.python.org"
>&python;</ulink
> spicca per l'eleganza del suo sistema di classi e la facilità e flessibilità con la quale le librerie esterne possono essere incapsulate in modo da farle apparire come classi e funzioni standard di &python;. In contrasto con il &perl;, &python; ha incluso delle &API; chiare e concise che lo rendono un linguaggio di prima qualità per rendere scriptabili i programmi C e C++. </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
>linguaggi di scripting</primary>
  <secondary
>PHP</secondary
></indexterm>

<para
><ulink url="http://www.php.net"
>&php;</ulink
> fu inventato come un linguaggio includibile nelle pagine &HTML;, di conseguenza ha il suo principale utilizzo nel trasmettere contenuti dinamici nel web. </para>
</sect2
> <!-- unixdev-SL-PHP -->
</sect1
> <!-- unixdev-scripting-languages -->

<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<sect1 id="unixdev-hl-script">
<title
>Scripting di alto livello</title>

<para
>Le applicazioni &UNIX; di alto livello generalmente non sono veloci e flessibili come i tradizionali script di shell. Questo vale soprattutto per le interfacce grafiche (&GUI;) come &eg; &kde;. </para>
<para
>Sono stati fatti tentativi per creare meccanismi simili operanti ad alto livello come <link linkend="unixdev-corba"
>CORBA</link
> e <link linkend="unixdev-dcop"
>&DCOP;</link
> nell'ambiente &kde;. </para>

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

<indexterm zone="unixdev-corba"
><primary
>CORBA</primary
></indexterm>
<indexterm zone="unixdev-corba">
  <primary
>linguaggi di scripting</primary>
  <secondary
>CORBA</secondary
></indexterm>
<indexterm zone="unixdev-corba">
  <primary
>comunicazione</primary>
  <secondary
>CORBA</secondary
></indexterm>

<para
><ulink url="http://www.omg.org/gettingstarted/corbafaq.htm"
>CORBA</ulink
> (<emphasis
>Common Object Request Broker Architecture</emphasis
>) permette alle applicazioni di operare assieme attraverso una rete. È stato ideato dal comitato <ulink url="http://www.omg.org"
>OMG</ulink
> (Object Management Group). </para>
<para
>I programmi basati su CORBA comunicano usando il protocollo standard IIOP. Sono disponibili implementazioni di IIOP per molti sistemi operativi, linguaggi di programmazione e reti, che rendono questo protocollo molto portabile. </para>
<para
>Il principale svantaggio è costituito dalla lentezza, che può essere accettabile in un network ma diventa un vero e proprio ostacolo per le comunicazioni in un ambiente costituito da un singolo computer come &kde;. </para>

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

<sect2 id="unixdev-dcop">
<title
>L'interfaccia &DCOP;</title>

<indexterm zone="unixdev-dcop"
><primary
>DCOP</primary
></indexterm>
<indexterm zone="unixdev-dcop">
  <primary
>linguaggi di scripting</primary>
  <secondary
>DCOP</secondary
></indexterm>
<indexterm zone="unixdev-dcop">
  <primary
>comunicazione</primary>
  <secondary
>DCOP</secondary
></indexterm>

<para
>Un'altra evoluzione dello scripting è il protocollo <ulink url="http://developer.kde.org/documentation/library/kdeqt/dcop.html"
><emphasis
>DCOP</emphasis
></ulink
> progettato per superare le limitazioni di CORBA e usato per le comunicazioni tra applicazioni &kde;. </para>
<para
>&DCOP; significa <emphasis
>Desktop Communication Protocol</emphasis
> ed è implementato come un semplice meccanismo IPC/RPC costruito per operare con i socket. In pratica esso fornisce funzioni simili ai tradizionali meccanismi pipe di &UNIX;. </para>
<para
>Lo scripting shell tradizionale è basato completamente su piccoli programmi che sono progettati per lavorare su basi strettamente testuali. &DCOP; permette a programmi grafici complicati di comunicare con altri in modo simile. Questo permette &eg; ad un programma &kde; di inviare messaggi ad un altro programma &kde;, oppure ricevere dati da esso per vari scopi.  </para>
<para
>Sono comunque presenti alcuni svantaggi: per usare &DCOP; un programma deve essere progettato per contenere una speciale interfaccia &DCOP;, e il processo di comunicazione è piuttosto lento (sebbene sia molto più veloce di CORBA). Tuttavia rende disponibile molto del potere e della flessibilità tipici dello scripting &UNIX; a programmi di alto livello basati sull'interfaccia grafica.  </para>
<para
>Per ulteriori informazioni, vedere il documento <ulink url="http://developer.kde.org/documentation/library/kdeqt/dcop.html"
>DCOP: Desktop COmmunications Protocol</ulink
> o la documentazione di riferimento alle &API; della <ulink url="developer.kde.org/documentation/library/cvs-api/dcop/html/index.html"
>libreria &DCOP;</ulink
> di &kde;. </para>
</sect2
> <!--  unixdev-dcop -->

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

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

<sect1 id="unixdev-buildsystems">
<title
>Sistemi di compilazione</title>

<para
>Salvo i casi semplici il proprio progetto consisterà di molti blocchi di codice sorgente collocati in diversi file, in modo da semplificare da manutenzione. Per farlo funzionare è necessario tradurre questo codice in poche unità di linguaggio macchina in un formato appropriato che permetta al sistema operativo di caricare ed eseguire il programma. </para>
<para
>I principali strumenti necessari sono: <itemizedlist>
  <listitem
><para
>un <emphasis
>editor di testi</emphasis
> per scrivere i file sorgente, </para
></listitem>
  <listitem
><para
>un programma di traduzione, normalmente un <emphasis
>compilatore</emphasis
>, per convertire il codice sorgente in file oggetto, </para
></listitem>
  <listitem
><para
>un <emphasis
>librarian</emphasis
> che raccoglie i file oggetto in librerie per poterli riutilizzare facilmente senza la necessità di ricompilare, </para
></listitem>
  <listitem
><para
>un <emphasis
>linker</emphasis
> che riunisce i vari file oggetto e le librerie in un eseguibile, </para
></listitem>
  <listitem
><para
>un <emphasis
>sistema make</emphasis
> che fornisce i mezzi per gestire tutte queste cose e &mdash; da non dimenticare </para
></listitem>
  <listitem
><para
>un <emphasis
>debugger</emphasis
> per (si spera) trovare tutti gli errori nel programma e altri strumenti di diagnosi. </para
></listitem>
</itemizedlist>
</para>

<para
>Il processo di compilazione può diventare laborioso quando si lavora ad un grande progetto che può contenere anche centinaia di file sorgente. Quando si vogliono modificare alcuni di questi file non è opportuno ricompilare tutto il progetto, ma solo i file interessati. Generalmente non è immediato capire quali file debbano essere ricompilati.  </para>
<para
>Ad esempio, quando si modifica il prototipo di una funzione in un file header si devono ricompilare tutti i file che lo includono. Nel caso di un grande progetto si possono facilmente dimenticare alcuni file che devono essere ricompilati. Quindi è necessario un qualche sistema automatico. </para>

<sect2 id="unixdev-buildsystems-make">
<title
>Il processo make</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
>regola</primary
></indexterm>
<indexterm zone="unixdev-buildsystems-make">
  <primary
>ricompilazioni</primary
></indexterm>
<indexterm zone="unixdev-buildsystems-make">
  <primary
>target</primary
></indexterm>
<indexterm zone="unixdev-buildsystems-make">
  <primary
>dipendenze</primary
></indexterm>
<indexterm zone="unixdev-buildsystems-make">
  <primary
>comandi</primary
></indexterm>

<para
>Uno strumento che si occupa della ricompilazione è <command
>make</command
>. Esso mantiene la traccia di tutto il lavoro usando un insieme di <emphasis
>regole</emphasis
> che descrivono cosa fare nel caso vengano cambiate alcune parti di informazione (normalmente un file sorgente o oggetto). Tutte le regole che appartengono a un certo progetto sono conservate in un file chiamato <filename
>Makefile</filename
> che è analizzato da <command
>make</command
> ogni volta che si vuole aggiornare il proprio lavoro. </para>
<para
>Ogni regola consiste di diversi blocchi: <itemizedlist>
  <listitem
><para
>un <emphasis
>target</emphasis
>, cioè il file che deve essere compilato </para
></listitem>
  <listitem
><para
>un insieme di <emphasis
>dipendenze</emphasis
>, fondamentalmente il nome dei file dai quali dipende il target (ad esempio se il target è un file oggetto che deve essere costruito la dipendenza sarà il nome del file sorgente) e  </para
></listitem>
  <listitem
><para
>i <emphasis
>comandi</emphasis
> che devono essere eseguiti per costruire il target (es. compilarlo o collegare vari file oggetto per costruire il file eseguibile). </para
></listitem>
</itemizedlist>
</para>
<para
>Sostanzialmente il comando <command
>make</command
> leggerà le regole una per una, controllando ogni file contenuto nella lista delle dipendenze di un determinato target. Se qualcuno di questi file è stato modificato verrà ricostruito il target usando i comandi elencati nella regola.  </para>
<para
>Ci sono diversi sistemi per controllare questo processo di compilazione e un <filename
>Makefile</filename
> può diventare molto complesso. Si raccomanda di abituarsi alla sintassi di <command
>make</command
>: anche se non lo si usa direttamente può essere utile comprendere le nozioni fondamentali del sistema di compilazione. Vedere il <ulink url="info://make/Top"
> <citetitle
>Manuale di GNU Make</citetitle
></ulink
> per maggiori informazioni. </para>
<para
>Per maggiori dettagli relativi a &tdevelop; vedere il capitolo <link linkend="project-management"
>Compilazione e gestione dei progetti</link
> di questo manuale. </para>
<para
>Esistono diversi tutorial disponibili, vedere i <link linkend="automake-references"
>riferimenti</link
> nel capitolo riguardante la compilazione e la gestione dei progetti. </para>
</sect2
> <!-- unixdev-buildsystems-make -->

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

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

<sect1 id="unixdev-guidevelopment">
<title
>Sviluppo di &GUI;</title>

<indexterm zone="unixdev-guidevelopment">
  <primary
>GUI</primary
></indexterm>
<indexterm zone="unixdev-guidevelopment">
  <primary
>interfaccia utente grafica</primary
></indexterm>
<indexterm zone="unixdev-guidevelopment">
  <primary
>interfaccia utente</primary>
  <secondary
>GUI</secondary
></indexterm>

<para
>In aggiunta alla logica e alle librerie di un programma gli sviluppatori devono anche creare una interfaccia utente facile da usare che sia intuitiva e funzionale. Tuttavia molti programmatori hanno una scarsa preparazione nello sviluppo di &GUI;, che spesso vengono progettate male. </para>
<para
>Attraverso gli anni si sono evoluti alcuni principi di progettazione comuni. Si raccomanda caldamente di seguirli, in modo da costruire interfacce utente con un aspetto uniforme che verranno apprezzate dagli utenti. </para>
<para
>Per lo sviluppo di &GUI; in &kde; è disponibile una guida allo stile che si può trovare all'indirizzo <ulink url="http://developer.kde.org/documentation/standards/kde/style/basics/index.html"
> &kde; User Interface Guidelines</ulink
> della pagina Developer's Corner di &kde;. </para>
<para
><ulink url="http://axp16.iie.org.mx/Monitor/v01n03/ar_ihc2.htm"
>Qui</ulink
> è disponibile una breve introduzione ai principi guida più usati nella progettazione di &GUI;. </para>

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

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

<sect1 id="unixdev-ide">
<title
>Integrare concetti e strumenti &ndash; l'IDE</title>

<indexterm zone="unixdev-ide">
  <primary
>IDE</primary
></indexterm>
<indexterm zone="unixdev-ide">
  <primary
>ambiente di sviluppo integrato</primary
></indexterm>
<indexterm zone="unixdev-ide">
  <primary
>sviluppo</primary>
  <secondary
>IDE</secondary
></indexterm>
<indexterm zone="unixdev-ide">
  <primary
>ambiente</primary>
  <secondary
>IDE</secondary
></indexterm>

<para
>Per quasi tutte le fasi della programmazione &mdash; pianificazione, modifica e gestione dei file, compilazione, debug e documentazione sono disponibili diversi strumenti. Tuttavia quando la complessità di un progetto aumenta il processo di programmazione tende a diventare scomodo. </para>
<para
>La progettazione, la compilazione e il debug di un programma sono attività molto ripetitive. Si può risparmiare molto lavoro attraverso l'uso di modelli e script e utilizzando strumenti facilmente disponibili e capaci di comunicare tra loro attraverso un'interfaccia utente comune.  </para>
<para
>Ad esempio&mdash; non sarebbe pratico se un debugger potesse aprire il file sorgente in un editor e posizionare il cursore nella posizione in cui viene trovato il bug? </para>
<para
>A questo scopo vennero ideati gli <emphasis
>Ambienti di sviluppo integrato Integrated Development Environments, (&IDE;)</emphasis
>. Un &IDE; integra in un singolo ambiente tutti i modelli, gli strumenti e gli script necessari al processo di sviluppo. </para>
<para
>&tdevelop; è un &IDE; per la piattaforma &kde;. Esso fornisce una vasta gamma di strumenti che semplificano lo sviluppo di programmi e la loro manutenzione, anche per diversi linguaggi di programmazione e differenti piattaforme. </para>

<sect2 id="unixdev-ide-tdevelop">
<title
>Caratteristiche di base di &tdevelop; &kdevrelease;</title>

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

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

<itemizedlist>
  <listitem>
  <para
>Gestisce tutti gli <emphasis
>strumenti di sviluppo</emphasis
> necessari per la programmazione in C++, come il compilatore, il linker, il debugger e il sistema di compilazione.</para>
  </listitem>
  <listitem>
  <para
>Fornisce una <emphasis
>procedura guidata</emphasis
> che genera applicazioni di esempio complete e pronte ad essere eseguite.</para>
  </listitem>
  <listitem>
  <para
>Permette all'utente di selezionare un <emphasis
>editor integrato</emphasis
> basato sull'editor di &kde; &kwrite;, sul QEditor di Trolltech o su altri.</para>
  </listitem>
  <listitem>
  <para
>Fornisce un <emphasis
>generatore di classi</emphasis
>, per creare nuove classi e integrarle nel progetto corrente.</para>
  </listitem>
  <listitem>
  <para
><emphasis
>Gestisce i file</emphasis
> dei sorgenti, degli header, della documentazione, ecc. da includere nel progetto.</para>
  </listitem>
  <listitem>
  <para
>Assiste nella <emphasis
>creazione dei manuali utente</emphasis
> delle applicazioni scritte con gli strumenti di &kde;.</para>
  </listitem>
  <listitem>
  <para
>Permette di scrivere la <emphasis
>documentazione &API;</emphasis
> in &HTML; delle classi del progetto con riferimenti incrociati alle librerie usate.</para>
  </listitem>
  <listitem>
  <para
><emphasis
>Supporta l'internazionalizzazione</emphasis
>, che permette ai traduttori di aggiungere in modo semplice il loro linguaggio ad un progetto, includendo il supporto per &kbabel;.</para>
  </listitem>
  <listitem>
  <para
>Supporta la gestione di un progetto attraverso un <emphasis
>versioning system</emphasis
> (&eg; &CVS;) fornendo un frontend facile da usare per le funzioni più importanti.</para>
  </listitem>
  <listitem>
  <para
>Include un frontend integrato per il <emphasis
>debugger</emphasis
>.</para>
  </listitem>
  <listitem>
  <para
>Fornisce un emulatore integrato di <emphasis
>shell</emphasis
>.</para>
  </listitem>
  <listitem>
  <para
>Fornisce <emphasis
>l'evidenziazione della sintassi</emphasis
> nel codice sorgente.</para>
  </listitem>
  <listitem>
  <para
>Effettua il <emphasis
>completamento automatico del codice</emphasis
> per le variabili di classe, i metodi, gli argomenti di funzione e altro.</para>
  </listitem>
  <listitem>
  <para
>Sono presenti vari <emphasis
>modelli per la creazione di vari progetti</emphasis
> (moduli del &kcontrol;, applet di &kicker; (panel), KIOSlaves, plugin di &konqueror; e stili del desktop).</para>
  </listitem>
  <listitem>
  <para
>Possiede quattro <emphasis
>viste ad albero</emphasis
> per passare velocemente attraverso file sorgente, file header, classi e documentazione, evitando la necessità di un gestore file esterno.</para>
  </listitem>
  <listitem>
  <para
><emphasis
>Supporta la cross-compilazione</emphasis
>, con la possibilità di specificare diversi compilatori, opzioni, architetture di destinazione, ecc.</para>
  </listitem>
  <listitem>
  <para
>Supporta i progetti <emphasis
>Qt/Embedded</emphasis
> (come Zaurus e iPAQ)</para>
  </listitem>
  <listitem>
  <para
>Include <emphasis
>vari programmi</emphasis
> necessari allo sviluppo che possono essere aggiunti al menu <guimenuitem
>Strumenti</guimenuitem
> a seconda delle proprie necessità.</para>
  </listitem>
</itemizedlist>

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

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

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