Mondi su mondi, sistemi di sistemi.

Gli StarPack

Adesso che abbiamo visto come sono costruiti gli StarKit, è semplice estendere il discorso agli StarPacks.

Premesse

Prima di tutto dobbiamo ricordare che uno StarKit può contenere delle componenti compilate. In virtù di questo fatto, pos­siamo costruire un StarKit che conterrà al suo interno l’interprete specifico per una data piattaforma. In pratica, la differenza fra uno StarKit e uno StarPack sta nel fatto che quest’ultimo usa un eseguibile compilato per avviarsi e include tutte le librerie normalmente incluse con TclKit.

Pregi e difetti

Le limitazioni più importanti di uno StarPack sono:

  1. dato che usiamo dei compilati, ogni StarPack sarà specifico per un dato sistema operativo;
  2. gli StarPack non pos­sono auto–modificarsi 1.

La contro­partita è un sistema di distribuzione completamente auto–contenuto, senza alcuna installazione aggiuntiva.

La creazione di uno StarPack è molto simile a quella di uno StarKit: l’unica differenza è che nel primo caso dovremo specificare il runtime da associare al prodotto finito.

È interes­sante notare che gli stessi TclKit sono creati come StarPack, StarPack che non hanno codice applicativo ma solo l’interprete e librerie neces­sarie 2

  1. parleremo più avanti di questa pos­sibilità per gli StarKit
  2. Credo sia anche questo il motivo per cui, durante la creazione di uno StarPack, non pos­siamo lo stesso TclKit sia per eseguire sdx che runtime da copiare nello StarPack. Probabilmente (non ho trovato informazioni certe) il processo di costruzione prenderà il TclKit, monterà il virtual file system e ci copierà l’applicazione.

Per proseguire

Commenti e trackback sono disabilitati.