««« | »»»
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, possiamo 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:
- dato che usiamo dei compilati, ogni StarPack sarà specifico per un dato sistema operativo;
- gli StarPack non possono auto–modificarsi 1.
La contropartita è 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.
È interessante notare che gli stessi TclKit sono creati come StarPack, StarPack che non hanno codice applicativo ma solo l’interprete e librerie necessarie 2
- parleremo più avanti di questa possibilità per gli StarKit ↩
- Credo sia anche questo il motivo per cui, durante la creazione di uno StarPack, non possiamo lo stesso TclKit sia per eseguire
sdxche 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.