2012-01-23 11 views
12

Sto preparando un pacchetto R che includerà un eseguibile compilato da terze parti. Il piano è di interfacciarlo a R usando le chiamate system(). Ho il permesso di distribuire questo eseguibile, ma non il suo codice sorgente. Sfortunatamente è compilato solo sotto Windows 32 bit, e non è possibile ricompilarlo facilmente in architetture diverse.Distribuzione di un eseguibile compilato con un pacchetto R

Comprendendo che questo pacchetto avrà un pubblico un po 'limitato, come deve essere distribuito l'eseguibile? Riconosco anche che non sarà consentito su CRAN per questo motivo.

Ad esempio, se l'eseguibile deve essere incluso nella sottocartella/bin/dell'installazione del pacchetto, o in alternativa se il pacchetto scarica in qualche modo l'eseguibile quando viene installato.

Inoltre, quali problemi di licenza, se presenti, in questo scenario?

+0

Domanda interessante e ben fatta, ma in realtà non _programmazione_. –

+2

Penso che questa domanda sia coperta dallo scopo del sito, qualcosa in linea (dalle FAQ): strumenti software comunemente usati dai programmatori –

+3

Grazie Joshua. Questo è vero, non è strettamente una domanda di programmazione. Tuttavia, una domanda sicuramente interessante per i programmatori R e gli sviluppatori di pacchetti. – digitalmaps

risposta

9

Ho lavorato su due pacchetti che fanno qualcosa di simile, entrambi ospitati su R-forge a causa della restrizione binaria CRAN (che, a proposito, sembra perfettamente ragionevole per me). (Non credo che ti manca qualcosa di ovvio nella sua interrogazione -. Solo dicendo qui quello che ho scelto di fare)

  • il cpcbp pacchetto (componenti principali comuni/retroproiezione) utilizza un binario compilato da codice scritto da Patrick Phillips; il codice sorgente non è ridistribuibile poiché utilizza alcune routine di ricette numeriche. Ho intenzione di riscrivere questo core in R (è solo una semplice algebra lineare numerica, non sarebbe così difficile). Mi sembra che probabilmente dovrò modificare la licenza su questo - probabilmente ho detto "GPL" ma non credo di poterlo fare dato il componente non ridistribuibile ...
  • il pacchetto glmmADMB utilizza liberamente codice sorgente ridistribuibile (licenza BSD), ma la toolchain è sufficiente complicato che non desidera che gli utenti devono scaricare l'intero pacchetto di supporto

in entrambi i casi metto i binari in inst/bin e possibilmente sotto specifica architettura sottodirectory (che vengono installate in /bin) e utilizzano la logica appropriata per rilevare l'architettura ed eseguire il binario corretto.

Credo che in linea di principio si potrebbe aggirare l'impossibilità di licenza tramite GPL, rendendo la parte non ridistribuibile in un download (come lei suggerisce), ma che sembrerebbe violare lo spirito ...

+0

Grazie a @Ben. Questi sono ottimi punti di partenza da cui modellare il pacchetto. – digitalmaps

+0

Buona risposta. Per quanto riguarda le licenze e GPL: la GPL affronta questioni interessanti relative a librerie binarie non libere, librerie di sistema, ecc. E ciò può essere interessante per quanto riguarda il fatto che il pacchetto * in toto * si adatti o meno alle regole FOSS. Vedi i link da [questo post] (http://stackoverflow.com/questions/1854843/does-gpl-code-linking-with-proprietary-library-depend-which-is-created-first) per ulteriori chiarimenti. – Iterator

3

Il l'approccio suggerito da Ben Bolker è anche usato dal pacchetto CRAN "dismo" - per far funzionare la funzione maxent(), devi scaricare il maxi binario java e metterlo nella sottodirectory appropriata all'interno della cartella del pacchetto principale.

Problemi correlati