Windows CE 6.0 R3 Build System Series – 4. Build Phases

Il build dell’immagine di Windows CE è fondamentalmente eseguita in 5 fasi :

  • Pre-Sysgen;
  • Sysgen;
  • Post-Sysgen Build (BSP e Subprojects);
  • Build Release Directory;
  • Make Run-Time Image;

4174.build_phases_5B816E6A

 

Prima di analizzare nel dettaglio le fasi suddette, farò un breve accenno su quelli che sono i file di configurazione dell’immagine che entrano in gioco durante la compilazione.

Configuration Files

Per la generazione dell’immagine, vengono utilizzate le seguenti quattro tipologie di file di configurazione :

  • BIB (Binary Image Builder) : utilizzati per la configurazione della memoria e per specificare i file da includere nell’immagine. La configurazione della memoria è strettamente correlata al target e viene eseguita mediante il file config.bib (%_PLATFORMROOT%\%_TGTPLAT%\FILES). I file da includere vengono specificati attraverso più file relativi al progetto (project.bib in %_PROJECTROOT%\OAK\Files), alla BSP (platform.bib in %_PLATFORMROOT%\%_TGTPLAT%\Files), ai sottoprogetti e per i componenti comuni ed hardware indipendent (common.bib in %_PUBLICROOT%\COMMON\OAK\FILES).
  • REG (Registry) : utilizzati per definire le chiavi di registro del sistema. Anche in questo caso, esistono più file relativi al progetto (project.reg), alla BSP (platform.reg) ai sottoprogetti ed alle impostazioni comuni (common.reg);
  • DAT (dat files): utilizzati per definire una specifica struttura di directory nel file system, aggiungendo o rimuovendo cartelle e creando eventuali link ai file nella directory \Windows. Come negli altri casi abbiamo il project.dat, platform.dat ed i medesimi file per i componenti hardware indipendent ed i subproject;
  • DB (Database) : per l’inizializzazione e creazione di database EDB. Anche in questo caso abbiamo il project.db, platform.db i medesimi file per i componenti hardware indipendent ed i subproject;

Non approfondirò il contenuto dei file suddetti, in quando lo scopo di questa serie di mini articoli è quello di approfondire il sistema di build in relazione ai tools che vengono utilizzati ed al loro scopo.

Pre-Sysgen

Durante questa fase, vengono compilati tutti i codici sorgenti relativi ai componenti all’interno delle directory PUBLIC e PRIVATE, ossia rispettivamente tutto ciò che è hardware indipendet ed il codice sorgente rilasciato da Microsoft. Questa fase NON va mai eseguita, in quanto tali componenti sono rilasciati in forma già compilata al momento dell’installazione del Platform Builder sul PC di sviluppo. Inoltre, se lanciata, impiega anche delle ore per poter eseguire tutte le operazioni di compilazione.

Se si rendesse necessario modificare il comportamento di un componente delle cartelle PUBLIC o PRIVATE, la migliore strada perseguibile è quella del cloning del componente stesso all’interno della directory della BSP (sottocartella di PLATFORM), sulla quale stiamo lavorando, oppure nella directory 3RDPARTY.

Sysgen

Questa fase si rende tipicamente necessaria ogni qual volta aggiungiamo o rimuoviamo un catalog item dall’immagine del sistema operativo.

Infatti, essa ha un compito di filtraggio, ossia di individuare solo ed esclusivamente i componenti da noi selezionati rispetto a tutti quelli disponibili nel Catalog Items, e di risolvere anche tutte le possibili dipendenze che ci sono tra gli items stessi. Infatti, durante il build è possibile che alcuni componenti siano inclusi direttamente nell’immagine, seppur non selezionati da noi esplicitamente, in quanto da essi dipendo altri componenti inclusi esplicitamente.

Durante questa fase, l’operazione di filtraggio viene eseguita sui componenti i cui path sono specificati nella variabile _DEPTREES e per ciascuno di essi vengono analizzate le variabiliSYSGEN_XXX settate in modo da includerli nell’immagine.

Il risultato di questa fase, prevede una copia di tutti i componenti hardware indipendent necessari (per selezione esplicita oppure per dipendenza), all’interno delle sottocartelle al percorso %_PROJECTROOT%\cesysgen, evidenziando che tutto ciò che si vuole includere nell’immagine è strettamente correlato al progetto.

In particolare, le sottocartelle interessate saranno :

  • oak/lib, sdk/lib, ddk/lib : contengono tutte le librerie statiche (file .lib);
  • oak/inc, sdk/inc, ddk/inc : contengono gli headers ed i file .def (esportazione delle funzioni);
  • oak/target : contiene tutti i file eseguibili (.exe) e le librerie dinamiche (.dll);

Post-Sysgen Build

In questa fase, vengono compilati tutti i codici sorgenti relativi alla BSP sulla quale stiamo lavorando e corrispondenti ai componenti che abbiamo selezionato. In particolare, vengono trattati i drivers del target device che vengono compilati utilizzando anche eventuali file headers e librerie statiche (.lib) filtrate nella fase precedente.

Inoltre, subito dopo, viene eseguita la compilazione dei subproject dell’OS design.

Al termine di questa fase, i componenti compilati, tipicamente librerie dinamiche o eseguibili, saranno disponibili in corrispondenza di alcune sottocartelle al percorso %_PLATFORMROOT%\%_TGTPLAT% (dove %_TGTPLAT% indica la target platform, ossia la BSP), evidenziando che tutto ciò che è stato compilato è relativo alla piattaforma.

In particolare, le sottocartelle interessate saranno :

  • lib : contenente tutte le librerie statiche (.lib);
  • target : contenente tutte le librerie dinamiche (.dll) ed eventuali eseguibili (.exe);

Build Release Directory

Questa fase ha il compito di copiare nella cartella _FLATRELEASEDIR, tutti i componenti filtrati e compilati nelle fasi precedenti, in modo da individuare un unico percorso nel quale attraverso l’ultima fase sia possibile generare il file binario dell’immagine.

In realtà, in luogo dell’operazione di copia fisica, vengono utilizzati gli hard links su volumi NTFS. E possibile comunque forzare la copia settando la variabile BUILDREL_USE_COPY (attraverso le Build Options”).

I file da copiare sono prelevati ai percorsi specificati nelle fasi precedenti ma ad essi vanno aggiunti i file di configurazione del sistema (.bib, .reg, .dat, .db) più altri eventuali file che vogliamo includere (es. immagini, documenti, …). Essi vengono tipicamente prelevati da :

  • %_PROJECTROOT%\OAK\Files : tipicamente i file project.bib, project.reg, project.dat e project.db;
  • %_PLATFORMROOT%\%_TGTPLAT%\Files : tipicamente i file config.bib, platform.bib, platform.reg, platform.dat, platform.db ed eventuali altri file che vogliamo includere;
  • %_PUBLICROOT%\COMMON\OAK\FILES : generalmente i file common.bib, common.reg, common.dat, common.db;

Make Run-Time Image

Durante questa fase, il contenuto della _FLATRELEASEDIR viene assemblato in modo da costituire il file binario dell’immagine : NK.bin. Il tool in gioco è il makeimg.exe che a sua volta utilizza altri tool esterni.

In primo luogo viene lanciato il tool Fmerge.exe che esegue il merge dei file di configurazione nel modo seguente :

  • file .bib sono fusi nell’unico file ce.bib;
  • file .reg sono fusi nell’unico file reginit.ini;
  • file .dat sono fusi nell’unico file initobj.dat;
  • file .db sono fusi nell’unico file initdb.ini;

Viene eseguita anche l’operazione di localizzazione dell’immagine in accordo con il linguaggio selezionato (variabile LOCALE).

Infine, viene utilizzato il tool romimage.exe che analizza il file ce.bib per determinare i file da includere nell’immagine e quindi generare il file NK.bin.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s