JHbuild delle mie brame - parte 1

Una doverosa premessa. JHbuild è da utilizzare solo se avete intenzione di scaricare i sorgenti e compilarli, magari perché vi interessa sbirciare nel codice, magari perché il vostro computer nuovo fiammante usa solo il 5% della CPU per il 95% del tempo, magari perché avete intenzione di partecipare alla scoperta e risoluzione del bug. Se non vi interessano i sorgenti e la compilazione, ci sono altri modi, ma personalmente non li ho sperimentati.

JHbuild è un comodo strumento che permette, con uno sforzo non titanico, di compilare e tenere aggiornata l'installazione di un determinato programma o di un intero ambiente grafico direttamente dalla versione in via di sviluppo, senza interferire oppure sovrascrivere quanto installato attraverso i pacchetti dal proprio vendor o distributore.

JHbuild è costituito da tre parti fondamentali:

• il comando stesso (ossia l'insieme di script in python), che funge da "frontend" ai comandi specifici per l'aggiornamento e la compilazione dei sorgenti, il tutto condito con la definizione di opportune variabili d'ambiente - esempi: mi basta scrive jhbuild update PROGRAMMA invece del comando specifico (cvs, svn, git, bzr) per aggiornare, oppure jhbuild buildone PROGRAMMA invece della sequenza configure/make/makeinstall e senza dover specificare il percorso in cui sono installati i programmi e le librerie che voglio usare;
  
• l'insieme dei moduli disponibili, ossia l'elenco di programmi "conosciuti" che si possono compilare, ognuno con le indicazioni su come reperire i sorgenti e sulle dipendenze da cui (tautologicamente) dipendono;
• la configurazione specifica dell'utente, nel file $HOME/.jhbuildrc, che serve a integrare quanto definito dalle due precedenti parti con le esigenze specifiche di chi sta usando JHbuild (cosa si vuole compilare, cosa no, eventuali aggiustamenti per la propria distribuzione...).

C'è gente in giro che dice che JHbuild non funziona, senza spiegare con assoluta precisione con chi ce l'ha e con chi non ce l'ha.

JHbuild è uno strumento che va capito e poi "domato", adattandolo al proprio sistema e comunque, trattandosi di compilazione di software prelevato da sistemi di version control, è sempre probabile che qualcosa non vada a buon fine (anche se, per esperienza, con i programmi sotto version control basta aprire un bug e aspettare un paio di giorni, mentre per compilare Firefox da targz bisogna chiedere aiuto alla jakuza).

Le difficoltà che si possono incontrare nell'usare JHbuild sono per lo più riferibili o a mancate dipendenze "esterne-esterne" (vedi dopo) oppure alla mancata/parziale/inadatta configurazione utente.

Visto che questa dovrebbe essere una guida "definitiva" a JHbuild e vista la mole di informazioni che sto per riversavi addosso, ho pensato fosse meglio (per me) dividere il tutto in più parti. Anzi, vi preannuncio che in questa puntata non faremo un bel niente, tranne parlare di massimi sistemi e filosofie di compilazione.

Premessa su come funzionano e come non funziono le cose

JHbuild è nato per permettere agli sviluppatori di GNOME di avere una versione aggiornata all'ultimo minuto della versione di sviluppo dello stesso, tant'è che in modo predefinito l'esecuzione del comando jhbuild build va a prelevare, compilare e installare i circa 200 moduli che compongono lo/il/la/un/una GNOME Desktop and Development Platform.

Per chi fosse nuovo di queste cose o non se ne è mai interessato, con GNOME Desktop and Development Platform (nel seguito indicato per brevità come GD&DP) si intende un ben definito gruppo di librerie e programmi il cui sviluppo è in qualche modo gestito dallo GNOME Project. A cavallo tra un rilascio stabile e un altro la comunità di GNOME si interroga su cosa sia il caso di includere nel GD&DP: nuove librerie per gli sviluppatori, nuove applicazioni per gli utenti (oppure applicazioni già esistenti finalmente giudicate stabili e aderenti agli standard).

Il GD&DP altro non è che la lista di tali moduli ufficiali (e relativa versione), che soddisfano una serie di criteri come internazionalizzazione, supporto all'accessibilità, aderenza agli standard nel codice e nell'interfaccia, utilità per l'utente finale... Tale lunga lista è divisa in altre sottoliste:

• piattaforma di sviluppo - librerie per sviluppatori giudicate essenziali, gestite dallo GNOME Project e alle quali tutte le altre applicazioni e librerie GNOMEsche possono fare riferimento, con garanzia di stabilità delle API e delle ABI per tutta la serie 2.x;
• ambiente grafico - insieme di applicazioni visibili all'utente e librerie di supporto (a differenza delle precedenti tali librerie non sono giudicate essenziali e non vi è garanzia di stabilità delle API e delle ABI);
• strumenti di amministazione - insieme di applicazioni rivolte all'amministrazione del sistema;
• strumenti di sviluppo - insieme di applicazioni rivolte allo sviluppo di applicazioni per GNOME;
• binding - librerie per scrivere applicazioni GNOME-compliant in linguaggi diversi dal C
  

A ciò è affiancata la lista delle dipendenze esterne, ossia moduli che non sono gestiti o sviluppati direttamente dallo GNOME Project, ma che sono comunque necessari all'intero ambiente e che possono essere ufficialmente usati come dipendenza dai moduli dello GD&DP senza timore. La dicitura "senza timore" è rivolta più agli sviluppatori che agli utenti, non riferita alle funzionalità fornite, ma alla stabilità delle API: non potendola garantire direttamente, si fa riferimento a una prefissata versione. Queste dipendenze esterne sono gestite da JHbuild proprio perché da una versione all'altra di GNOME potrebbe essere necessario usare una versione più recente.

Modulo extaparlamentare

In questa ottica quindi, quando prima parlavo di dipendenze "esterne-esterne" intendevo tutto ciò che non è gestito direttamente da JHbuild, come per esempio tutti i vari pacchetti -dev di X11, o libpng-dev o il gcc, ossia tutto ciò che serve ma che non è "ufficiale" per GNOME perché talmente necessario o basilare da servire all'intero sistema.

Tanto per cominciare, vi dico subito che, per mia esperienza, si deve installare una buona dose di pacchetti per far funzionare JHbuild al meglio.

E qui innesto la questione bootstrap. Una piccola e limitata quantità di dipendenze "esterne-esterne" è gestita da JHbuild e può essere recuperata, compilata e installata con il comando jhbuild bootstrap. In teoria sarebbe possibile installare direttamente dai pacchetti forniti dal vendor e saltare questo passaggio, ma per esperienza personale è meglio passare per il bootstrap. Ora, potrei anche stare qui a spiegarvi i motivi, ma poi non troverei mai il tempo di passare alla parte due. Quindi per ora accontentatevi e sperate che in settimana prossima arrivi la nuova uscita di questa interessssaaantisssssima serie.